[Newbie] Why or why not haskell ?

Christophe Plasschaert

10 Dec 2005 10 Dec '05

11:03 a.m.

First, i'd like to say good day to everybody. I didn't find enough information to anwser this question: Being interesting in learning another way of programming besides C and perl i started watching other languages. These are my candidates: - ada; - erlang; - clisp or scheme; and of course - haskell. Haskell seems very interesting indeed (monadic, STM, a good library). Maybe some of you know some or all of these languages and can explain me some pros/cons about them especially for network programming. Thanks for your attention. Have a nice day. C. Plasschaert

Show replies by date

Sebastian Sylvan

10 Dec 10 Dec

12:44 p.m.

On 12/10/05, Christophe Plasschaert wrote:

...

First, i'd like to say good day to everybody.

Good Day.

...

I didn't find enough information to anwser this question: Being interesting in learning another way of programming besides C and perl i started watching other languages.

These are my candidates:

Okay, here we go. This is all very subjective from my own limited experience, of course.

...

- ada;

Never really got into it, but seems better than "some" (I'm looking at you, C++!)

...

- erlang;

Isn't strongly typed, isn't pure, and isn't lazy. However, it IS functional so that makes it quite pleasant to program in. Code is often short and elegant, just like in Haskell. It's excellent for network and concurrent programming. Better than Haskell even, despite STM. Erlang was built with this in mind so it's quite convenient to send messages etc.

...

- clisp or scheme;

I only have limited experience but both seem nice. I can't see a real compelling reason to use it over Haskell. The main reason I think Haskell is a better choice is purity.

...

and of course - haskell.

My language of choice for most problems. Elegant and pure. It does lack some libraries, though. Especially for dealing with "lower level" stuff, and there's no real standard (official or de facto) data structures library (Edison was a great start, but for some reason it never amounted to anything truly useful). If you hadn't mentioned networking specifically, I would've recommended Haskell without hesitation. But you did, and therefor I'll also recommend Erlang. I do think Haskell is a better starter language for FP though, because it's pure and strongly typed. So learn the ropes in Haskell and then take a look at Erlang and hopefully some of your bad C habits will have died off so that you won't abuse the unsafe features of it :-) /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862

Christophe Plasschaert

3:57 p.m.

Hi and thanks for the answer, On Sat, Dec 10, 2005 at 06:44:22PM +0100, Sebastian Sylvan wrote:

...

On 12/10/05, Christophe Plasschaert wrote: [....]

...
- erlang;

Isn't strongly typed, isn't pure, and isn't lazy. However, it IS functional so that makes it quite pleasant to program in. Code is often short and elegant, just like in Haskell. It's excellent for network and concurrent programming. Better than Haskell even, despite STM. Erlang was built with this in mind so it's quite convenient to send messages etc.

With erlang or haskell, can we play with or implement lower network fuction (routing daemon interacting with a kernel) or are we stuck with high level function (application like web server). [....]

...

...
- haskell.

My language of choice for most problems. Elegant and pure. It does lack some libraries, though. Especially for dealing with "lower level" stuff, and there's no real standard (official or de facto) data structures library (Edison was a great start, but for some reason it never amounted to anything truly useful).

If you hadn't mentioned networking specifically, I would've recommended Haskell without hesitation. But you did, and therefor I'll also recommend Erlang. [....] In terms of speed, is haskell good enough ?

Chris

Peter Simons

3:32 p.m.

Christophe Plasschaert writes:

...

With erlang or haskell, can we play with or implement lower network fuction (routing daemon interacting with a kernel) [...]

I can't speak for Erlang, but in Haskell you can. Through the Foreign Function Interface, you can access arbitrary 3rd-party libraries or system calls, including pointer arithmetic and the wonders of memory management.

...

In terms of speed, is haskell good enough ?

You have C/C++'s performance for algorithms that do things the way you would do them in C. Once you start to rely on lazy evaluation, performance may be really good or really bad, depending on your algorithms. Practical experience suggests that writing efficient algorithms in a non-strict language is difficult at first. If you stay away from infinite lists that map to an I/O stream through lazy evaluation, however, you should be fine. ;-) Peter

Marc A. Ziegert

7:21 p.m.

hi Christophe.

...

In terms of speed, is haskell good enough ?

in some cases, optimized haskell may even be faster than C. (that depends on your C-programming skills. i.e. function-inlining will speed C up, too.) how possible? look at the mangler: http://www.haskell.org/ghc/docs/6.4.1/html/building/sec-porting-ghc.html#sec... there were discussions about the efficiency of some compilers and their technics. http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg08729.html networking: hm. sorry, don't know. ...look at the libraries. my personal experience with other languages: - ada nada. - erlang nice. easy to learn, functional, multi-threaded, and more elegant than lisp. see http://en.wikipedia.org/wiki/Wings_3D as example program. - clisp or scheme forget those lisp languages. boooring. brackets everywhere. lisp was one of the first (was the first?) functional languages. if you like to experiment with the lambda-calculus, this is the perfect language. well, you still should learn it, because it is too easy to learn, and it is still used. maybe you will meet that language in the future. spend some time into learning it, before you learn haskell. some hours should be enough. http://en.wikipedia.org/wiki/Lisp_programming_language suggestion: how about learning haskell and lisp at the same time? write an lisp-interpreter as your first haskell-project. ;) - haskell it is like the "c++<stl>" of functional languages, just higher. it is meta-programming. think about it as the tool-language, that replaces thousands of code-monkeys. and it will be really easy, after you started to "think in haskell". that could take some time, so don't give up. it has three giant disadvantages: 1.) you do not feel the need for learning other languages anymore. 2.) waiting for a new ghc release, with new never-thought-of-before high-level language extensions, can make you crazy. 3.) the industry prefers vc++.net, java#, vb-excel-script, php4iexplorer and other bug-friendly (most times proprietary and/or incompatible) languages instead of haskell. to start with a functional language, read about the lambda-calculus. functional languages depend on it. http://en.wikipedia.org/wiki/Lambda_calculus to learn haskell, continue with... http://en.wikipedia.org/wiki/Haskell_programming_language http://haskell.org/hawiki/ (especially about monads and arrows) ...and reading the library. http://haskell.org/ghc/docs/latest/html/libraries/index.html as gui library, i preferr... http://www.haskell.org/gtk2hs/ - marc

Tomasz Zielonka

11 Dec 11 Dec

3:38 a.m.

On Sun, Dec 11, 2005 at 01:21:50AM +0100, Marc A. Ziegert wrote:

...

- clisp or scheme forget those lisp languages. boooring. brackets everywhere. lisp was one of the first (was the first?) functional languages.

What does clisp mean here? A Common Lisp implementation (http://clisp.cons.org/) or a shortcut for Common Lisp? I guess the latter. Common Lisp is definitely not a functional language in the sense that it does not enforce or even encourage functional programming. Common Lisp people will tell you that CL is a multiparadigm language. I may not like CL, but I wouldn't say it's boring.

...

if you like to experiment with the lambda-calculus, this is the perfect language.

CL was not based on lambda-calculus, at least originally. Perhaps scheme more so. Haskell will be much more nice for (typed) lambda-calculus experiments than CL.

...

well, you still should learn it, because it is too easy to learn, and it is still used. maybe you will meet that language in the future. spend some time into learning it, before you learn haskell. some hours should be enough.

Do not confuse Scheme and Common Lisp. While the former probably may be learned in short time, the latter is probably as complicated as C++.

...

http://en.wikipedia.org/wiki/Lisp_programming_language

Have *you* read it? ;-)

...

- haskell it is like the "c++<stl>" of functional languages, just higher.

Please, don't compare Haskell to C++. You are not making any good for Haskell with this, and IMHO C++ doesn't not deserve being compared to Haskell.

...

2.) waiting for a new ghc release, with new never-thought-of-before high-level language extensions, can make you crazy.

This is one very nice thing about GHC - you get some surprise presents almost every year ;-) What I am concerned about is that adding features also means adding errors, or not fixing old errors fast enough. What we need is more people working on fixing bugs. Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland

Bulat Ziganshin

10 Dec 10 Dec

6:25 p.m.

Hello Christophe, Saturday, December 10, 2005, 7:03:57 PM, you wrote: CP> - ada; CP> - erlang; CP> - clisp or scheme; CP> and of course CP> - haskell. CP> Haskell seems very interesting indeed (monadic, STM, a good library). CP> Maybe some of you know some or all of these languages and can explain CP> me some pros/cons about them especially for network programming. what you mean saying "network programming"? Erlang has amazing distributed processing features with fault tolerance (when one processes supervises the others and restart them in case of fault). but Erlang is interpreted language and so it is slow in case of low-level programs. you can use C to make low-level or speed-critical functions Haskell is complied and therefore faster than Erlang. in my experience, it iis about 3-10 times slower than C, depending on what you do (low-level things has much overhead and therefore slower comparing to C, higher-level things has lesser overhead). don't forget that real program will make a lot of I/O and use C libraries, so difference will be less and can be even close to 0. you can use C functions in your Haskell code (this only requires to declare C function in Haskell code). of course, data types are different, so it work good only with functions working on plain types (ints/chars/doubles/pointers/...) and plain structures short resume: Haskell is order of magnitude faster than Erlang, but 3-10 times slower than C. you can use C lower-level routines in Erlang and in Haskell. in Haskell you can also write such routines directly. answer on your question depends on that you want to do besides low-level stuff. Haskell is faster, more robust, and much more extensible than Erlang, while Erlang has cute inter-process communication and distributed processing -- Best regards, Bulat mailto:bulatz@HotPOP.com

Joel Reymont

11:02 p.m.

Erlang can be compiled to machine code with the built-in HiPE compiler. You just have to explicitly make use of this facility. On Dec 10, 2005, at 11:25 PM, Bulat Ziganshin wrote:

...

what you mean saying "network programming"? Erlang has amazing distributed processing features with fault tolerance (when one processes supervises the others and restart them in case of fault). but Erlang is interpreted language and so it is slow in case of low-level programs. you can use C to make low-level or speed-critical functions

-- http://wagerlabs.com/

Bulat Ziganshin

11 Dec 11 Dec

5:43 a.m.

New subject: Re[2]: [Newbie] Why or why not haskell ?

Hello Joel, but anyway Erlang is dynamic alnguage, and this make things go slower. on the other side, it is strict Sunday, December 11, 2005, 7:02:57 AM, you wrote: JR> Erlang can be compiled to machine code with the built-in HiPE compiler. JR> You just have to explicitly make use of this facility. JR> On Dec 10, 2005, at 11:25 PM, Bulat Ziganshin wrote:

...

...
what you mean saying "network programming"? Erlang has amazing distributed processing features with fault tolerance (when one processes supervises the others and restart them in case of fault). but Erlang is interpreted language and so it is slow in case of low-level programs. you can use C to make low-level or speed-critical functions

JR> -- JR> http://wagerlabs.com/ -- Best regards, Bulat mailto:bulatz@HotPOP.com

Joel Reymont

8:54 a.m.

New subject: Re[2]: [Newbie] Why or why not haskell ?

I would surmise that speed is not always the point. This is what's usually used to defend the laziness of Haskell :-). Erlang is _the_ language for network programming, trust me on this one. My dreamhost site seems to be down at the moment but you can poke around the Erlang category at http://wagerlabs.com/ if you want. On the one hand, I wrote a poker server in Erlang and that was a relative breeze. I was able to host many thousands of poker clients. On the other hand, I had a LOT of hard time with my current Haskell project. I'm trying to launch many of thousands of poker clients so there's a lot of similarity. If I were to do this in Erlang I would focus my attention on the actual logic of the app as binary packet parsing, serialization, networking and heavy-duty concurrency are non-issues with Erlang. Simple and absolutely nothing to speak about. This is why Erlang is being used for a lot of telco apps that require massive loads, protocol conversion, etc. I did get my Haskell app to the point where it's about 90% ready and working but most of my attention was spent on... binary packet parsing, serialization, networking and heavy-duty concurrency :-). Yes, it's working now but it took blood, sweat and tears. It's now two months later and I have yet to see the Haskell app launch thousands of poker clients and run them for hours. Joel On Dec 11, 2005, at 10:43 AM, Bulat Ziganshin wrote:

...

Hello Joel,

but anyway Erlang is dynamic alnguage, and this make things go slower. on the other side, it is strict

Sunday, December 11, 2005, 7:02:57 AM, you wrote:

JR> Erlang can be compiled to machine code with the built-in HiPE compiler. JR> You just have to explicitly make use of this facility.

JR> On Dec 10, 2005, at 11:25 PM, Bulat Ziganshin wrote:

...
...
what you mean saying "network programming"? Erlang has amazing distributed processing features with fault tolerance (when one processes supervises the others and restart them in case of fault). but Erlang is interpreted language and so it is slow in case of low-level programs. you can use C to make low-level or speed- critical functions

JR> -- JR> http://wagerlabs.com/

-- Best regards, Bulat mailto:bulatz@HotPOP.com

-- http://wagerlabs.com/

Tomasz Zielonka

3:58 a.m.

On Sun, Dec 11, 2005 at 02:25:55AM +0300, Bulat Ziganshin wrote:

...

don't forget that real program will make a lot of I/O and use C libraries, so difference will be less and can be even close to 0.

I disagree that every real Haskell program has to do a lot of I/O and has to use FFI. Most of the time I want to write my code in pure Haskell, with 95% of it in pure functions. This has the advantage of greater clarity and reliability (and more). What I fear about the future of Haskell, is that we will have so many libraries FFIying to C, that our programs will crash as often as programs written in C. FFI is necessary, but IMO it shouldn't be used when it doesn't have to be. In an (mostly:) ideal world, every library should be clearly divided into a small, trusted, unsafe core and the rest, written entirely in Haskell. I would like to see some support in tools for enforcing such a coding policy. It could look like this - a function written using only safe components would be marked as safe. Every unsafe feature like FFI, unsafePerformIO, etc. would "taint" a module/function, marking it unsafe. You could explicitly tag module/function as trusted/reviewed/etc. There would be different levels of trust. All this would be propagated through the libs and program modules. A Haskell IDE could mark safe/unsafe/trusted code with different background color, etc. You could get statistics about the proportions of safe/unsafe/trusted code. Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland

Sven Panne

7:07 a.m.

Am Sonntag, 11. Dezember 2005 09:58 schrieb Tomasz Zielonka:

...

[...] I would like to see some support in tools for enforcing such a coding policy. It could look like this - a function written using only safe components would be marked as safe. Every unsafe feature like FFI, unsafePerformIO, etc. would "taint" a module/function, marking it unsafe. [...]

... in effect making things like putStrLn, getContents etc. "tainted", resulting in probably > 95% of the hierachical libraries in the fptools repository being "tainted", including lots of stuff from the H98 report. :-) Nice idea, but not very practical IMHO. Cheers, S.

Tomasz Zielonka

12:09 p.m.

On Sun, Dec 11, 2005 at 01:07:47PM +0100, Sven Panne wrote:

...

Am Sonntag, 11. Dezember 2005 09:58 schrieb Tomasz Zielonka:

...
[...] I would like to see some support in tools for enforcing such a coding policy. It could look like this - a function written using only safe components would be marked as safe. Every unsafe feature like FFI, unsafePerformIO, etc. would "taint" a module/function, marking it unsafe. [...]

... in effect making things like putStrLn, getContents etc. "tainted", resulting in probably > 95% of the hierachical libraries in the fptools repository being "tainted", including lots of stuff from the H98 report. :-) Nice idea, but not very practical IMHO.

Those could be marked as trusted with a high level of confidence. Anyway, I haven't thought too long about this idea so it's bound to have problems. It would have to be very well thought out to be practical. For example, imagine that we have a function f implemented using functions g and h. I could mark f as safe, but if someone changes definitions of g or h? Should f be reviewed again? Perhaps the system should use some kind of contracts... Not an easy thing. But what can we do to keep Haskell safe? Does anybody else see the same danger? Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland

Henning Thielemann

12 Dec 12 Dec

12:18 p.m.

On Sun, 11 Dec 2005, Tomasz Zielonka wrote:

...

I would like to see some support in tools for enforcing such a coding policy. It could look like this - a function written using only safe components would be marked as safe. Every unsafe feature like FFI, unsafePerformIO, etc. would "taint" a module/function, marking it unsafe. You could explicitly tag module/function as trusted/reviewed/etc. There would be different levels of trust. All this would be propagated through the libs and program modules. A Haskell IDE could mark safe/unsafe/trusted code with different background color, etc. You could get statistics about the proportions of safe/unsafe/trusted code.

Btw. Modula-3 distinguishs between safe and unsafe code: http://research.compaq.com/SRC/m3defn/html/safety.html

Nils Anders Danielsson

1:20 p.m.

New subject: Enforcing coding policy (was: Why or why not haskell ?)

On Sun, 11 Dec 2005, Tomasz Zielonka wrote:

...

I would like to see some support in tools for enforcing such a coding policy. It could look like this - a function written using only safe components would be marked as safe. Every unsafe feature like FFI, unsafePerformIO, etc. would "taint" a module/function, marking it unsafe. You could explicitly tag module/function as trusted/reviewed/etc. There would be different levels of trust. All this would be propagated through the libs and program modules. A Haskell IDE could mark safe/unsafe/trusted code with different background color, etc. You could get statistics about the proportions of safe/unsafe/trusted code.

This sounds a lot like what they have been doing in the Programatica project. -- /NAD

Tomasz Zielonka

2:42 p.m.

New subject: Enforcing coding policy (was: Why or why not haskell ?)

On Mon, Dec 12, 2005 at 07:20:47PM +0100, Nils Anders Danielsson wrote:

...

On Sun, 11 Dec 2005, Tomasz Zielonka wrote:

...
I would like to see some support in tools for enforcing such a coding policy. It could look like this - a function written using only safe components would be marked as safe. Every unsafe feature like FFI, unsafePerformIO, etc. would "taint" a module/function, marking it unsafe. You could explicitly tag module/function as trusted/reviewed/etc. There would be different levels of trust. All this would be propagated through the libs and program modules. A Haskell IDE could mark safe/unsafe/trusted code with different background color, etc. You could get statistics about the proportions of safe/unsafe/trusted code.

This sounds a lot like what they have been doing in the Programatica project.

Thanks! I'll take a look at Programatica. Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland

Christophe Plasschaert

11 Dec 11 Dec

5:27 p.m.

Hi everybody, First I'd like to thank all of you for the answers and the discussion. On Sun, Dec 11, 2005 at 02:25:55AM +0300, Bulat Ziganshin wrote:

...

Hello Christophe,

Saturday, December 10, 2005, 7:03:57 PM, you wrote:

CP> - ada; CP> - erlang; CP> - clisp or scheme; CP> and of course CP> - haskell.

CP> Haskell seems very interesting indeed (monadic, STM, a good library).

CP> Maybe some of you know some or all of these languages and can explain CP> me some pros/cons about them especially for network programming.

what you mean saying "network programming"? Erlang has amazing distributed processing features with fault tolerance (when one processes supervises the others and restart them in case of fault). but Erlang is interpreted language and so it is slow in case of low-level programs. you can use C to make low-level or speed-critical functions

Well, from all of the information given and my various reading this day, i'll try a little erlang and haskell before deciding with which one i'll play. Again thanks to all of you and have a nice day. Chris

7104

Age (days ago)

7106

Last active (days ago)

List overview

Download

16 comments

10 participants

participants (10)

Bulat Ziganshin
Christophe Plasschaert
Henning Thielemann
Joel Reymont
Marc A. Ziegert
Nils Anders Danielsson
Peter Simons
Sebastian Sylvan
Sven Panne
Tomasz Zielonka