What do you LISPers think of Haskell?

What are you LISPers opinion of Haskell?

Pros and cons compared to LISP?

On Aug 19, 2:31*pm, ssecorp <circularf...@gmail.com> wrote:
> What are you LISPers opinion of Haskell?
>
> Pros and cons compared to LISP?

Pros: Haskell is cool loaded with cool features
Cons: Haskell is not Lisp

On Aug 19, 12:31*pm, ssecorp <circularf...@gmail.com> wrote:
> What are you LISPers opinion of Haskell?
>
> Pros and cons compared to LISP?

Caveat: It's been a while since I've used Haskell (2-3 yrs), and I've
only been working in common lisp recently (2 yrs)

I remember Haskell being very succinct, and having a very powerful
typing system. Lisp has more of the former, and much less of the
latter. Although very flexible, and good at catching errors at compile
time, I found the typing system in Haskell sometimes got in the way.
Lisp let's you declare types, but if you don't want to you don't have
to, and this tends to make it more flexible than Haskell. Furthermore,
with good unit testing, the sorts of errors one would catch in
haskell, also get caught early on in lisp.

Likewise, although Haskell has some capacity to define new language
constructs, Lisp's macros are more powerful, and this provides a
further degree of flexibility.

Haskell's built-in syntax has more succinct ways of describing things
like list comprehensions, return of multiple variables from a
function, and function currying. The assumed lazy evaluation also
means that you can do some very pretty stuff with 'infinite' lists,
that get's a little uglier in lisp. However, I also find Haskell to be
harder to read than lisp, largely because of these very features.

I also seem to recall haskell being pretty slow, but that might just
have been the compiler I was using, and what I was using it for. Lisp
on the other hand can be quite fast. (I believe some claim, as fast or
faster than C).

So in summary:

Haskell: a more powerful type checking system, that can catch more
errors, more succinct for some operations. Not quite as readable as
lisp
Lisp: More flexible. Faster. Possibly less succinct for particular
applications, but often the flexibility means you can define
constructs that lead to more succinct code than one would write in
Haskell. Possibly less error catching at compile time, but unit
testing can largely make up for this.

Perhaps I am biased in this regard, but I generally prefer Lisp.
Though I might consider using Haskell for a well defined problem where
I knew the sort of lazy evaluation and pattern matching that is easily
expressed in Haskell would be useful.

DeverLite <derby.little@gmail.com> writes:
> [...] Although very flexible, and good at catching errors at compile
> time, I found the typing system in Haskell sometimes got in the way.
> Lisp let's you declare types, but if you don't want to you don't have
> to, and this tends to make it more flexible than Haskell.

Actually, what the lisp type system means is that in lisp we program
in generic mode by default.

When you write:

int fact(int x){ return (x<=0)?1:x*fact(x-1); }

it's statically typed, but it's also SPECIFICALLY typed.

When you write in lisp:

(defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))

it's already a generic function (not a lisp generic function,
technically, but what other programming languages call a generic
function):

(mapcar 'fact '(4 4.0 4.0l0 5/2))
--> (24 24.0 24.0L0 15/8)

to get the same in C++ you would have to write:

#include <rational.hxx>
template <typename T> fact (T x){ return (x<=0)?1:x*fact(x-1);}

... fact(4),fact(4.0),fact(4.0d0),fact(Rational(5,2)) ...


I hope Haskell is able to derive these instances automatically.


But you can easily get even more genericity, either using non CL
operators that you can easily redefine (eg. as lisp generic
functions), by shadowing them to the same effect, or by using
functions passed in argument. CL:SORT is generic because it takes a
LESSP function, so it can be applied on sequences of any kind of
object.


So what statically checked type system proponents detract as duck
typing is actually that lisp works in the Generic Mode gears by
default.


--
__Pascal Bourguignon__ http://www.informatimago.com/
I need a new toy.
Tail of black dog keeps good time.
Pounce! Good dog! Good dog!

ssecorp wrote:
> What are you LISPers opinion of Haskell?
>
> Pros and cons compared to LISP?

Haskell's success rate at generating widely-used open source code is far
lower than most other languages:

http://flyingfrogblog.blogspot.com/2...virginity.html

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u

On Aug 19, 5:30 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
> ssecorp wrote:
> > What are you LISPers opinion of Haskell?
>
> > Pros and cons compared to LISP?
>
> Haskell's success rate at generating widely-used open source code is far
> lower than most other languages:
>
> http://flyingfrogblog.blogspot.com/2...virginity.html

In summary, Jon's blocg says the haskell compiler is GHC is dropping
the haskell-based darc as its source control system.

good news to know.

See also:

Distributed RCS, Darcs, and Math Sacrilege
http://xahlee.org/UnixResource_dir/writ/darcs.html

plain text version below.
-------------------------

Distributed RCS, Darcs, and Math Sacrilege

Xah Lee, 2007-10-19

When i first heard about distributed revision control system about 2
years ago, i heard of Darcs, which is written in Haskell↗. I was
hugely excited, thinking about the functional programing i love, and
the no-side effect pure system i idolize, and the technology of human
animal i rapture in daily.

I have no serious actual need to use a revision control system (RCS)
in recent years, so i never really tried Darcs (nor actively using any
RCS). I just thought the new-fangled distributed tech in combination
of Haskell was great.

About 2 months ago, i was updating a 5-year old page i wrote on unix
tools (The Unix Pestilence: Tools and Software) and i was trying to
update myself on the current state of the art of revision systems. I
read Wikipedia (Darcs↗) this passage:

Darcs currently has a number of significant bugs (see e.g. [1]).
The most severe of them is "the Conflict bug" - an exponential blowup
in time needed to perform conflict resolution during merges, reaching
into the hours and days for "large" repositories. A redesign of the
repository format and wide-ranging changes in the codebase are planned
in order to fix this bug, and work on this is planned to start in
Spring 2007 [2].

This somewhat bursted my bubble, as there always was some doubt in the
back of my mind about just how Darcs is not just a fantasy-ware
trumpeted by a bunch of functional tech geekers. (i heard of Darcs in
irc emacs channel, who are often student and hobbyists programers)

Also, in my light research, it was to my surprise, that Darcs is not
the only distributed system, and perhaps not the first one neither,
contrary to my impressions. In fact, today there are quite a LOT
distributed revision systems, actually as a norm. When one looks into
these, such as Git↗, one finds that some of them are already used in
the industry for large projects, as opposed to Darcs's academic/
hobbist kind of community.

In addition to these findings, one exacerbation that greatly pissed me
off entirely about Darcs, is the intro of the author (David Roundy)'s
essay about his (questionable-sounding) “theory of patches”used in
Darcs. ( http://darcs.net/manual/node8.html#Patch )

Here's a quote:

I think a little background on the author is in order. I am a
physicist, and think like a physicist. The proofs and theorems given
here are what I would call ``physicist'' proofs and theorems, which is
to say that while the proofs may not be rigorous, they are practical,
and the theorems are intended to give physical insight. It would be
great to have a mathematician work on this, but I am not a
mathematician, and don't care for math.

From the beginning of this theory, which originated as the result
of a series of email discussions with Tom Lord, I have looked at
patches as being analogous to the operators of quantum mechanics. I
include in this appendix footnotes explaining the theory of patches in
terms of the theory of quantum mechanics. I know that for most people
this won't help at all, but many of my friends (and as I write this
all three of darcs' users) are physicists, and this will be helpful to
them. To non-physicists, perhaps it will provide some insight into how
at least this physicist thinks.

I love math. I respect Math. I'm nothing but a menial servant to
Mathematics. Who the fuck is this David guy, who proclaims that he's
no mathematician, then proceed to tell us he doesn't fucking care
about math? Then, he went on about HIS personal fucking zeal for
physics, in particular injecting the highly quacky “quantum mechanics”
with impunity.

-------------------------

Btw, Jon, you often attack Lisp, Haskell. However, i don't think i've
ever seen you criticize OCaml.

Of course, since you sell OCaml thus you are probably very biased.

Is there some criticism of OCaml you could say? so at least to show
you are not that biased?

If you do reply to give some criticism of OCaml, please don't just
give some cursory lip service that appears to be negative criticism
but not. It might be true that you really think OCaml is
comparatively great in all or almost all aspects... but surely there
are some critically negative aspects?

Xah
∑ http://xahlee.org/

☄

ssecorp wrote:
> What are you LISPers opinion of Haskell?
>
> Pros and cons compared to LISP?

All I know is that some google yobbo listened to sean parent try to
explain for 76 minutes why the dataflow paradigm offered two orders of
magnitude code reduction and all the yobbo could ask was, "Why didn't
you use Haskell?" Far it be it from a Lisper to accuse someone of being
obsessed with an obscure niche language, but I just did.

I think only F# is better at turning otherwise intelligent engineers
into frothing at the mouth idiots. I would have added OCaml but I saw
some investment bank in NYC was Actually Using It, and The Kenny hasa
soft spot for Programmers Actually Programming.

hth, kt

On Aug 19, 9:27*pm, Kenny <kentil...@gmail.com> wrote:
> I would have added OCaml but I saw
> some investment bank in NYC was Actually Using It, and The Kenny hasa
> soft spot for Programmers Actually Programming.

Also I think FFTW3, the very well used open source Fourier transform
library, uses OCaml to generate optimized C code...

On Aug 19, 7:07*pm, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> DeverLite <derby.lit...@gmail.com> writes:
> > [...] Although very flexible, and good at catching errors at compile
> > time, I found the typing system in Haskell sometimes got in the way.
> > Lisp let's you declare types, but if you don't want to you don't have
> > to, and this tends to make it more flexible than Haskell.
>
> Actually, what the lisp type system means is that in lisp we program
> in generic mode by default.
>
> When you write:
>
> * *int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>
> it's statically typed, but it's also SPECIFICALLY typed.
>
> When you write in lisp:
>
> * *(defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>
> it's already a generic function (not a lisp generic function,
> technically, but what other programming languages call a generic
> function):
>
> * *(mapcar 'fact '(4 4.0 4.0l0 5/2))
> * * --> (24 24.0 24.0L0 15/8)
>
> to get the same in C++ you would have to write:
>
> * #include <rational.hxx>
> * template <typename T> fact (T x){ return (x<=0)?1:x*fact(x-1);}
>
> * ... fact(4),fact(4.0),fact(4.0d0),fact(Rational(5,2)) ...
>
> I hope Haskell is able to derive these instances automatically.
>
> But you can easily get even more genericity, either using non CL
> operators that you can easily redefine (eg. as lisp generic
> functions), by shadowing them to the same effect, or by using
> functions passed in argument. *CL:SORT is generic because it takes a
> LESSP function, so it can be applied on sequences of any kind of
> object.
>
> So what statically checked type system proponents detract as duck
> typing is actually that lisp works in the Generic Mode gears by
> default.
>
> --
> __Pascal Bourguignon__ * * * * * * * * * *http://www.informatimago.com/
> I need a new toy.
> Tail of black dog keeps good time.
> Pounce! Good dog! Good dog!

Right. Thanks for the clarification. I didn't mean to imply that there
was no typing by default in lisp: just that it wasn't something you
had to *declare*.

Xah Lee wrote:
«
“Distributed RCS, Darcs, and Math Sacrilege”
http://xahlee.org/UnixResource_dir/writ/darcs.html
»

As of 2007-10, the “theory of patches” introduction sectionof darc's
documentation that contains the “don't care for math” phrase is at
“http://darcs.net/manual/node8.html#Patch”. As of 2008-08-19, that
section seems to moved to a different section, in this url “http://
darcs.net/manual/node9.html” , and the “don't care about math” bit has
been removed.

Thanks to Xah Lee, whose harsh criticism on society sometimes takes
effect silently.

Xah
∑ http://xahlee.org/

☄