Re: Glasgow haskell vs. Lispworks

In article <f9id4j$9ut$1@xxxxxxxxx>,
"Rene de Visser" <Rene_de_Visser@xxxxxxxxxxx> wrote:

-- What I prefer about Haskell.

Maintaining large programs is easier. You can obtain the type signature of
any function, and the type signature of a Haskell function pretty well
describes what a Haskell function does. From this I can also understand
better how function works, and how to change it. When I make changes, the
type checker shows me where I need to make further changes, and where I have
made a mistake. On the other hand a unit test only tells me that something
is wrong, but not where or why.

Even if you have static type checking, you will need unit tests.
There is no way around it.

A 'unit test' tests the smallest testable unit if code. So
if a unit test fails, the error is right there in the unit.
By definition.

Sure, a unit test can't tell you why you added two numbers
instead of multiplying it. The type checker will also
not tell you why you wrote a + b, instead of a * b.
But the unit test can detect it.

....

Different libraries can be used together in combination. Too often Common
Lisp libraries have their own version of defun or other standard functions
that are not compatible with each other (and very hard to intergrate).

I don't understand the issue here.

No ugly macro composition problems, or finding that I need to pass a macro
to a HOF as a parameter.

Since a macro is not a function, you cannot pass it. By definition.

If you have a macro foo and you want to pass some code, you
write (lambda (bar) (foo bar)) and pass that.

I find Haskell code prettier and easier to read (I find Common Lisp easy to
read as well, however not as good Haskell).
I find large Haskell programs of similar complexity (IMHO) easier to
understand than Common Lisp ones.

I have made the opposite experience. Also reading source code
in Haskell from other people, I see coding that is some much
behind Lisp coding style it is not even funny. Just yesterday
I compared the coding-style for emacs-style editors in Haskell,
OCAML, Emacs Lisp and Common Lisp. Common Lisp and Emacs Lisp
had much better code. OCAML was kind of readable. The Haskell code
was obfuscated by design. In Lisp you can get very declarative
code. Haskell and OCAML code, though it was functional, was
more low-level.

Haskell does "automatic state management" (an abuse of the term, but I find
that immutably, and functional purity does make it easier for me to reason
about programs). The next step after garbage collection, but as an C
programmer will tell you: garbage collection is evil, it restricts what the
programmer can do with manual memory management.

No, C programmers don't like garbage collectors, because it
comes with a cost they don't like.

Equals works correctly in Haskell. Not need to decide between eq, eql,
equals, equalp and other data structure specific versions.

Equal can't work 'correctly'. You might want to read Kent Pitman's
article about it.

http://www.nhplace.com/kent/PS/EQUAL.html

I have less choices in Haskell.For me this simplifies programming. Code
sometimes follows directly form the types.

Yes, this can be good.

Haskell's type system gives me the option of designing a program in terms of
its types. I find this a useful option.

-- What I prefer about Lispworks

Completely incremental development. No waiting for a file to compile.
Rebuild only once a week to make sure rebuilding from scratch still works.

Great integrated development enviroment. Lispworks is well stress tested
over the years. Problems are often known in advance. And you know others
have found solutions to them.

Good range of libraries available for common lisp.

Macros are easier in common lisp (I don't find template haskell as
friendly).

Embedding DSL's in common lisp is easier and often blends in better
(visually/syntactically).

Switching data structures in a running application is much easier in
Lispworks (note that this also possible in a GHC application, the libraries
our however not really there yet (generate marshalling functions from the
old to the new structures, and then dynamically import the new modules and
perform the marshalling)).

-- Why I can't add the features of Haskell to Common Lisp.

I don't have time to create the complete GHC system as a DSL in Common Lisp.
This is probably around 50 man years work.

It would also not make much sense. But there are/were Haskell-like
languages on top of Lisp. For example there was Yale Haskell
implemented in CL. No longer maintained.

All the Common Lisp libraries would still be in normal Common Lisp, so this
really wouldn't help anyway.

Summary.

Haskell and Common Lisp are both good languages.

No doubt.

Rene
.

Relevant Pages

  • Glasgow haskell vs. Lispworks
    ... Common Lisp for a large number of years, and had learned haskell. ... After around 2 years of Haskell I now prefer it as a language to ... Libraries can often be understood from their interface. ...
    (comp.lang.functional)
  • Re: Learning functional programming
    ... learn some Haskell, but I have to admit I never really liked Haskell (I am ... There is no preference in Common Lisp for imperative programming, and there is no fixation on compilation and optimization in the Common Lisp community. ... Scheme is somewhat neater if you need/have a lot of higher-order functions, ...
    (comp.lang.functional)
  • Re: Flamebait if I ever saw it
    ... ML-style static typing is more popular than Common Lisp. ... Meanwhile, the highest ranked language in the swamp seems to be Haskell, ...
    (comp.lang.lisp)
  • Re: Object Identity [was Re: More static type fun.]
    ... Common Lisp ... Actually I do see one application: observing sharing for serialization to ... yield more compressed output. ... Haskell has only one equality operator. ...
    (comp.lang.lisp)