Haskell versus Lisp

This is not a troll, honest, so please bear with me ... I'm a C/C++/VBA programmer (although the former 2 are several years old for me), with a sprinkling of Python. Needless to say, I was looking to see if there were any better ways of doing things. I've given things like Ruby and Scheme a bit of peck, and failed to get particularly enthusiastic about them. Two very interesting choices, though, appear to be Lisp and Haskell. It struck me that Lisp was, perhaps, the Ultimate Programming Language, the One True Language to rule them all; except that I always kept abandoning it for one reason or another (fiddly installation, lack of libraries, compatability problems, cost, possible license issues, etc.). My current foray in Haskell seems encouraging. wxHaskell installed a breeze, and seems quite usable (even though I'm a raw n00b to the language, and admittedly haven't grokked the semantics, and all this cid:part1.01000702.09000407@yahoo.co.uk IO a -> IO () business). On the one hand, it seems kinda academic, but on the other, it looks like it wants to be practical, too. Bearing this in mind, and hoping you can see where I'm coming from, I think my question is: shouldn't you guys be using Lisp? ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

On Fri, Sep 16, 2005 at 12:34:57PM +0100, Mark Carter wrote:
This is not a troll, honest, so please bear with me ...
It struck me that Lisp was, perhaps, the Ultimate Programming Language, the One True Language to rule them all; except that I always kept abandoning it for one reason or another (fiddly installation, lack of libraries, compatability problems, cost, possible license issues, etc.). My current foray in Haskell seems encouraging. wxHaskell installed a breeze, and seems quite usable (even though I'm a raw n00b to the language, and admittedly haven't grokked the semantics, and all this cid:part1.01000702.09000407@yahoo.co.uk IO a -> IO () business). On the one hand, it seems kinda academic, but on the other, it looks like it wants to be practical, too.
Bearing this in mind, and hoping you can see where I'm coming from, I think my question is: shouldn't you guys be using Lisp?
Given the words above, I wonder why the question is this way around :) --
Aqua Regis is HCl+H2SO4, and attacks gold. While applying it to a luser, remember to sing "What a Friend We Have In Regis". -- Patrick Wade

Harri Haataja wrote:
On Fri, Sep 16, 2005 at 12:34:57PM +0100, Mark Carter wrote:
This is not a troll, honest, so please bear with me ...
It struck me that Lisp was, perhaps, the Ultimate Programming Language, the One True Language to rule them all; except that I always kept abandoning it for one reason or another (fiddly installation, lack of libraries, compatability problems, cost, possible license issues, etc.). My current foray in Haskell seems encouraging. wxHaskell installed a breeze, and seems quite usable (even though I'm a raw n00b to the language, and admittedly haven't grokked the semantics, and all this cid:part1.01000702.09000407@yahoo.co.uk IO a -> IO () business). On the one hand, it seems kinda academic, but on the other, it looks like it wants to be practical, too.
Bearing this in mind, and hoping you can see where I'm coming from, I think my question is: shouldn't you guys be using Lisp?
Given the words above, I wonder why the question is this way around :)
The thing that struck me as being really cool about Lisp is the whole macro and the "code is data" idea. In the book Practical Common Lisp they show how data could be expressed as lists, which you could then easily serialise and deserialise to/from a file. How cool is that?! Plus you can use macros to extend the language. Alas, pulling against this seems to be a number of minuses. The commercial Lisp implementations may be good, but what wannabe hacker is going to fork out the cash for those babies? The free ones that work on Windows are GPL, which means that although somebody might be tempted to use them for personal projects, he is not going to sell the idea to his boss that stuff should be developed in Lisp. Plus there are the fragmentation issues. I managed to get wxCL (wxWidgets for Common Lisp) to install and run on CLISP. I figured that ODBC connectivity should be next on the list, and found that I needed defsystem to make it run. So then I have to track down defsystem, get that installed, etc. etc.. It reminds me of one of those adventure games from my ZX81 days. In order to catch the bird you need the cage and the seed, but oh dear, you're carrying the rod which scares the bird, and so on. It's horribly complicated. Well, the following page goes into far greater detail than I ever could: http://c2.com/cgi/wiki?WhyWeHateLisp I daren't post this message on comp.lang.lisp you understand, as that would just be inviting Electric Death, as Douglas Adamas might say. ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Mark Carter wrote:
The free ones that work on Windows are GPL, which means that although somebody might be tempted to use them for personal projects, he is not going to sell the idea to his boss that stuff should be developed in Lisp.
Nonsense. The copyright notice for GNU CLisp specifically clarifies that you are allowed to distribute your clisp programs, whether interpreted or compiled, under any terms you like. Just don't touch clisp internals. Accompany the program with the source for CLisp and you are clear. Anyway, I knew I didn't want to learn lisp when I heard that an implementation is not required to optimize tail calls. That means deep recursions are unreliable. A functional language in which you have to iterate instead of recurse? Impossible! Udo. -- Did you know that if you took all the economists in the world and lined them up end to end, they'd still point in the wrong direction?

I have faced these issues twice, always starting from Lisp and moving on somewhere else. There's more on my travails at http:// wagerlabs.com/tech and http://wagerlabs.com/uptick. I implemented a poker engine in Lisp but it appeared that to deliver it on Windows, Linux and Mac OSX I would need to buy 3 commercial Lisp licenses. The total cost would have been about 4K euro + maintenance fees for LispWorks and about 18K USD + 25% maintenance fees for Allegro CL. Allegro also comes with royalties of less than 10%. Windows Lisps are GPL so I could not use them. What turned me off with poker was trying to write a Reliable UDP protocol handler and having a lot of trouble with threads and timers for some reasons. Fortunately, I discovered Erlang, quickly rewrote my poker backend and have been happy since. That is until I discovered Haskell :-). I'm now thinking of rewriting various chunks of the engine in Haskell (hand ranking for example) to see how it feels and what I gain. Concurrent Haskell coupled with transactional memory looks attractive as well. I also started with Lisp for my trading systems project (Uptick) but was turned off even faster this time. I investigated what it would take to write code that overloaded +, *, etc. for arrays or lists and what it would take to optimize this code. It's possible but it's not elegant or pleasant. I love a good challenge and the challenge of learning Haskell is like no other. It does require me to rewire my brain and to think different. There are a number of applications where Haskell fits nicely, google for papers on audio processing, robotics (Yampa), etc. I have yet to find an application where Lisp would shine over everything else. Joel On Sep 16, 2005, at 3:06 PM, Mark Carter wrote:
Alas, pulling against this seems to be a number of minuses. The commercial Lisp implementations may be good, but what wannabe hacker is going to fork out the cash for those babies? The free ones that work on Windows are GPL, which means that although somebody might be tempted to use them for personal projects, he is not going to sell the idea to his boss that stuff should be developed in Lisp.

Am Freitag, 16. September 2005 15:06 schrieb Mark Carter:
Plus you can use macros to extend the language.
I don't know really about LISP macros but aren't they a bit like Template Haskell? Since Haskell (even without Template Haskell) is a small but flexible language you can construct domain-specific langauges just by writing a library and using Haskell with this library as your domain-specific language. I don't know LISP very much but I suppose that there are many things you can do in LISP which you can also do in Haskell. Two big advantages of Haskell over LISP are lazy evaluation and its strong, flexible type system. Lazy evaluation makes the code a lot easier, cleaner, more functional. Strong typing may be too restricting if the type system is not powerful enough. But since Haskell's type system is very powerful, I practically never miss dynamic typing.
[...]
Best wishes, Wolfgang

Hello Wolfgang, Friday, September 16, 2005, 6:30:45 PM, you wrote: WJ> more functional. Strong typing may be too restricting if the type system is WJ> not powerful enough. But since Haskell's type system is very powerful, I WJ> practically never miss dynamic typing. really, we have dunamic typing in current GHC: 1) rank-2 types 2) Data.Dynamic -- Best regards, Bulat mailto:bulatz@HotPOP.com

Wolfgang Jeltsch wrote:
Am Freitag, 16. September 2005 15:06 schrieb Mark Carter:
Plus you can use macros to extend the language.
I don't know really about LISP macros but aren't they a bit like Template
I wrote a Lisp macro once, and realised that it had a power that I hadn't seen before (the actual problem I was trying to solve that I wanted a logger that, given a variable, printed its name and value). That represented my one dip into Lisp macros, so it's fair to say that I'm not qualified to talk on either of Lisp or Haskells metaprogramming facilities. All I know is, if Haskell Templates provide no greater power than those of C++, be prepared for the Lispers to be, shall we say, "somewhat condescending" about them. ;) ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Hello Mark, Friday, September 16, 2005, 7:42:46 PM, you wrote: MC> facilities. All I know is, if Haskell Templates provide no greater power MC> than those of C++, be prepared for the Lispers to be, shall we say, MC> "somewhat condescending" about them. ;) Template Haskell has nothing common with C templates, it's îíûå a typeful UNIVERSAL preprocessor. C templates equivalent to Haskell polymorhic procedures/types, which exist from the language start -- Best regards, Bulat mailto:bulatz@HotPOP.com

Am Freitag, 16. September 2005 17:42 schrieb Mark Carter:
Wolfgang Jeltsch wrote:
Am Freitag, 16. September 2005 15:06 schrieb Mark Carter:
Plus you can use macros to extend the language.
I don't know really about LISP macros but aren't they a bit like Template
I wrote a Lisp macro once, and realised that it had a power that I hadn't seen before (the actual problem I was trying to solve that I wanted a logger that, given a variable, printed its name and value). That represented my one dip into Lisp macros, so it's fair to say that I'm not qualified to talk on either of Lisp or Haskells metaprogramming facilities. All I know is, if Haskell Templates provide no greater power than those of C++, be prepared for the Lispers to be, shall we say, "somewhat condescending" about them. ;)
I could imagine that Template Haskell has greater power than C++ templates but I'm really no expert here. But one shouldn't think, the more power, the better. In Java you have the "power" to insert objects of totally different classes into one list. I don't think that this is a good thing. Best wishes, Wolfgang

On Fri, 16 Sep 2005, Mark Carter wrote:
This is not a troll, honest, so please bear with me ...
I'm a C/C++/VBA programmer (although the former 2 are several years old for me), with a sprinkling of Python. Needless to say, I was looking to see if there were any better ways of doing things. I've given things like Ruby and Scheme a bit of peck, and failed to get particularly enthusiastic about them. Two very interesting choices, though, appear to be Lisp and Haskell. It struck me that Lisp was, perhaps, the Ultimate Programming Language, the One True Language to rule them all; except that I always kept abandoning it for one reason or another (fiddly installation, lack of libraries, compatability problems, cost, possible license issues, etc.). My current foray in Haskell seems encouraging. wxHaskell installed a breeze, and seems quite usable (even though I'm a raw n00b to the language, and admittedly haven't grokked the semantics, and all this cid:part1.01000702.09000407@yahoo.co.uk IO a -> IO () business). On the one hand, it seems kinda academic, but on the other, it looks like it wants to be practical, too.
Bearing this in mind, and hoping you can see where I'm coming from, I think my question is: shouldn't you guys be using Lisp?
As someone else that has been learning both Haskell and Lisp, I think you should really look at Haskell as a wonderful experiment. Essentially, while Lisp can do pretty much anything, it isn't perfect and shouldn't be the last word., I don't think we should be satisfied with a language just the way it is. Haskell is very, very different than most languages. It's *purely* functional and lazy evaluating. The latter is most interesting to me from the compiler writing aspect. When I have a little more free time and a little more experience I'd love to have a deeper look at ghc and understand how it works. In essence though, I think that Haskell is worth learning simply because it tries something different.

On Fri, Sep 16, 2005 at 12:34:57PM +0100, Mark Carter wrote:
Bearing this in mind, and hoping you can see where I'm coming from, I think my question is: shouldn't you guys be using Lisp?
Lisp is impure, weakly typed and has way too many parentheses. Why would we use lisp? It seems to be lacking almost all the advantages of Haskell, and have an ugly, inflexible syntax to boot. Obviously I don't like lisp, and I also greatly dislike parentheses, sometimes irrationally so... as is reflected by my excessive use of the $ operator. And I abhor dynamcially typed languages... although perl isn't too bad (it goes all the way, and even perl has some static typing--scalars versus arrays versus hashes). The more bugs the compiler is able to find before you actually run your code, the better, in my opinion. -- David Roundy http://www.darcs.net

David Roundy wrote:
Bearing this in mind, and hoping you can see where I'm coming from, I think my question is: shouldn't you guys be using Lisp?
Lisp is impure, weakly typed and has way too many parentheses. Why would we use lisp? It seems to be lacking almost all the advantages of Haskell, and have an ugly, inflexible syntax to boot.
The ability to dynamically generate, manipulate and analyse code in a
structured manner provides a flexibility which is unmatched by any
other language I know of.
A good example is Emacs; lisp is entirely the right language for that,
IMHO.
--
Glynn Clements

Am Freitag, 16. September 2005 15:29 schrieb Glynn Clements:
David Roundy wrote:
Bearing this in mind, and hoping you can see where I'm coming from, I think my question is: shouldn't you guys be using Lisp?
Lisp is impure, weakly typed and has way too many parentheses. Why would we use lisp? It seems to be lacking almost all the advantages of Haskell, and have an ugly, inflexible syntax to boot.
The ability to dynamically generate, manipulate and analyse code in a structured manner provides a flexibility which is unmatched by any other language I know of.
A good example is Emacs; lisp is entirely the right language for that, IMHO.
Could you explain this a bit more, please? To the moment, I cannot imagine cases where you need LISP's way of code analysis and manipulation because Haskell's capabilities are not sufficient. In Haskell, code is data too because code in the sense of imperative actions is described by IO values. You cannot analyse them. But you can use your do expressions etc. to construct action descriptions with a more general type like MonadIO m => m a. Then you can instantiate m with a monad whose values store part of the action's structure so that this information can be used later. Or you use a monad which doesn't keep structural information to use it for later processing but which does the processing upon construction. Best wishes, Wolfgang

On Fri, Sep 16, 2005 at 02:29:33PM +0100, Glynn Clements wrote:
David Roundy wrote:
Bearing this in mind, and hoping you can see where I'm coming from, I think my question is: shouldn't you guys be using Lisp?
Lisp is impure, weakly typed and has way too many parentheses. Why would we use lisp? It seems to be lacking almost all the advantages of Haskell, and have an ugly, inflexible syntax to boot.
The ability to dynamically generate, manipulate and analyse code in a structured manner provides a flexibility which is unmatched by any other language I know of.
True, if you want to write code to modify code, lisp would be nice (everything is a list)... but that's related to my problem with its syntax. Lisp seems to be designed for machines to parse easily without regard to ease of human parsing. That seems backwards to me. On one level, an objection to syntax is pretty lame, but on the other hand, CAVEAT: I know nothing about lisp macros... my lisp knowledge is basically from one course over ten years ago, plus some experience with configuring emacs and with a photonics code (mpb) that used guile for its input files. -- David Roundy

On 16/09/05, Mark Carter
This is not a troll, honest, so please bear with me ...
I'm a C/C++/VBA programmer (although the former 2 are several years old for me), with a sprinkling of Python. Needless to say, I was looking to see if there were any better ways of doing things. I've given things like Ruby and Scheme a bit of peck, and failed to get particularly enthusiastic about them. Two very interesting choices, though, appear to be Lisp and Haskell. It struck me that Lisp was, perhaps, the Ultimate Programming Language, the One True Language to rule them all; except that I always kept abandoning it for one reason or another (fiddly installation, lack of libraries, compatability problems, cost, possible license issues, etc.). My current foray in Haskell seems encouraging. wxHaskell installed a breeze, and seems quite usable (even though I'm a raw n00b to the language, and admittedly haven't grokked the semantics, and all this cid:part1.01000702.09000407@yahoo.co.uk IO a -> IO () business). On the one hand, it seems kinda academic, but on the other, it looks like it wants to be practical, too.
Bearing this in mind, and hoping you can see where I'm coming from, I think my question is: shouldn't you guys be using Lisp?
Well, there are a number of reasons which people might have for choosing one over the other. I think you'll find that many Haskellites are familiar with one or more variants of lisp and ML. I'll try to provide some reasons that I find Haskell a fun and pleasant programming language to write things in. (Actually, a fair bit moreso than any other language that I've come across.) One is that Haskell is lazily evaluated, and I really find that a lot more natural than strict evaluation. It opens up a lot of ways of writing code and thinking about code which would otherwise be unavailable. In a strict language, you have to jump through some hoops whenever infinite or very large amounts of data come along. You tend to have to use different methods than you would for small data structures in order to compute only small parts at any one time, and throw away the parts that you're done with explicitly. In a lazy language, a list is a list, and a tree is a tree, and the same functions and techniques apply to them. Even if your data are moderately sized, there are often times that the easiest algorithm to write involves a large intermediate data structure, though you'll only look at it one piece at a time, and maybe won't look at all of it. With lazy evaluation, you're not penalized for doing things that way. Of course, there are times when you really want strict evaluation, and Haskell has ways to provide that. I find that they are relatively rare. Another reason is that it is statically type checked. The type system in Haskell is quite expressive, and I find that it helps to catch bugs to an incredible extent, and also to structure the way that you think about code. With algebraic datatypes and the collection of standard data structures in the libraries, you also don't lose very much flexibility over dynamically typed structures. The type system also helps you jump into unfamiliar code. People tend to write Haskell code which uses types in order to distinguish and catch those things which are obviously incorrect. When trying to sort out how a piece of code works, or how to extend it, there is a somewhat more restricted way that things could be fitting together at any one point, so it's easier to figure out what's going on, and pin down the places where you might want to extend things. You can often go quite a long way in understanding code just by looking at the types. I also find that just through using Haskell, and being around the Haskell community, I expose myself to a lot of exciting computer science research. I'm still quite impressed that category theory has found practical applications so quickly. :) Haskell people in general seem to be experimenting with new kinds of abstractions and seeing how far they can be taken in being put to practical use. Haskell itself seems to be developing in directions which serve this experimentation, and at the same time is becoming more and more practical. Anyway, these are just some highlights of what I find fun about it, and of course none of this is meant in any way to detract from all the other great languages out there. Exploring different programming languages is a lot of fun and can really expand the way that you think about code. I encourage you to do so as much as possible. - Cale
participants (11)
-
Bulat Ziganshin
-
Cale Gibbard
-
Creighton Hogg
-
David Roundy
-
Glynn Clements
-
Harri Haataja
-
Joel Reymont
-
Malcolm Wallace
-
Mark Carter
-
Udo Stenzel
-
Wolfgang Jeltsch