
Lisper's first look at Haskell - fogus
http://tourdelisp.blogspot.com/2008/03/lisper-first-look-at-haskell.html
======
plinkplonk
"Static typing sucks. It reminds me of the dark ages of programming in the c
family of languages. "

If working in Haskell reminded him of C (and the post is full of rubbish like
this [1]), I'd imagine he didn't understand Haskell at _all_. This is on the
order ranting about how lisp is sucky because of "all those parantheses".

"And don't even dare to mention Emacs, a lot of people don't like it.It's 2008
and creating a simple Haskell editor is not an rocket science"

A supposed "lisper" saying this is hilarious. Many lisps (CLisp, CMUCL,
Clojure) reccomend Emacs + slime as "their" editor (and take a lot of heat
from uninformed ranters for not having an Eclipse like IDE!) .

To top it all he claims Lisp was "divinely inspired" whereas the lowly Haskell
is "unblessed". (The basis fr his weird analogy, the linked martial arts "ryu"
vs "do" article is an interesting read though)

I quote "Haskell is one of those 'unblessed ', modern do languages sharing
company with c++, java, c#, OCaml, F# etc"

He didn't program anything significant in Haskell, didn't "get" it any way and
yet is sure of its inferior nature.

This reminds me of an old HN post of a similar rant by a Clojure fanboi titled
"Clojure VS Python". He had gems like "A man with a thousand knives...of which
none are sharp. It's a chinese proverb ..(which) can also be used to describe
Python. ". I wonder if it is the same guy? [EDIT. No it isn't)

[EDIT here it is <http://news.ycombinator.com/item?id=881642>].

Contrast with what an ultra competent lisper said about Haskell (Rich Hickey,
dismissing another uninformed anti Haskell rant on the Clojure mailing list [
<http://groups.google.com/group/clojure/msg/32b11b22ec104d4d>]

"Everyone, please refrain from language wars. Haskell is a tremendously
ambitious and inspiring language, for which I have the highest respect. There
is zero point in bashing it (or its users) in this forum. "

The post itself is nothing more than uninformed fanboi ranting, but on HN,
even dumb posts result in high quality discussion (as is already happening -
silentbicycle's comments on unification for e.g), but it would have been
really awesome to get an intelligent and well thought out post on "A
(competent) Lisper's reaction to Haskell"

[1] another sample: "Case sensitive - why does types has to start with
uppercase and functions with lowercase. "

~~~
silentbicycle
It surprises me that he's complaining about case sensitivity and praising
Prolog in the same post - Prolog is case sensitive, too. All variable names
are uppercase. Lowercase names are atoms, what Lispers call 'symbols'. This is
where Erlang got that from, by the way. (I like it, but I bet it really
irritates some people.)

~~~
plinkplonk
"It surprises me that he's complaining about case sensitivity and praising
Prolog in the same post - Prolog is case sensitive, too. "

There is a _very_ simple explanation for that ? ;-)

------
silentbicycle
I'm not surprised that he's finding Haskell's static typing to be a hurdle. I
had the same experience when I started learning OCaml after years with Python
and Scheme - it took me a couple days to think in, rather than fight with, its
type system. Nowadays, I strongly recommend reading _The Little MLer_ before
starting with Haskell or OCaml - it does for static typing what _The Little
Schemer_ does for Lisp.

Its type checks can be incredibly useful for finding code needing updates
during refactoring, automatically verifying things that would otherwise
require writing reams of tedious tests, etc. It's a trade-off, though -
_you're deliberately structuring your code so that your assumptions can be
mechanically checked_. This is very much a matter of taste, and I understand
having strong opinions either way. (I go back and forth on it.)

 _Stupid_ type systems suck _hard_ , though - smart static typing (ML and
Haskell) and full dynamic typing (possibly with optional static annotations)
both work well, but in between lies pain and misery.

Also, look at the follow-up:
(<http://tourdelisp.blogspot.com/2008/03/farewell-haskell.html>) I feel like
he barely tried.

~~~
aristidb
It should be noted that Haskell's type system supports a form of dynamic
typing: Existential types
<http://www.haskell.org/haskellwiki/Existential_type> (among other methods).

Also, static polymorphic types are a superior substitute for many uses of
dynamic typing.

~~~
silentbicycle
My type system experience mostly comes from OCaml, not Haskell, and I haven't
done much with existential types.

While I feel vaguely anti-intellectual saying this: I grok the H-M type
inference used by ML* , and the simplest mechanical application of it probably
covers 95% of the things I'd use it for. It simplifies things immensely, yet
it's easy to reason about. I'm not sure that more advanced types are useful
enough to justify the added complexity, personally. (Though if I added one
thing to ML, it would be typeclasses.)

However, I'm sure that, with sufficient experience, they probably also become
second nature. I just prefer languages with relatively small semantics.

* If I had understood unification when I was learning OCaml (I learned Prolog/unification later), though, it would have seemed practically _obvious_. "It's trying to unify the types, based on actual usage...oh! And it infers when they're parametric!" (with a few special cases so that e.g. functions keep their more specific types in recursive calls.)

~~~
jerf
My problem with raw H-M is that it introduces a lot of very tight binding
between modules; this can be good when it comes time to detect things you
missed in a refactoring, but it is often still a bit too much binding even in
my own code base, and it is definitely too much binding in a library. And
large code bases structured sanely should usually be built like libraries
anyhow. Being able to use classes and a selected handful of other constructs
goes a long ways towards making Haskell more _practical_ , even if the
inference engine sometimes needs a bit more help.

(And yes, I know you can hide symbols and such, but with raw H-M you still get
these rigid concrete types. An XML parsing library that emits only XML
datatypes defined in that one library and every function you write then has to
know about these datatypes, and you can forget about changing that library
ever again without entirely rewriting every line of code that touches it.
Theoretically "every line that touches it" should be in some interface that
converts it to your internal concepts, but in practice I am not completely
wrapping every damn library I use so I still end up with some concrete types
from libraries throughout. Mathematically this makes perfect sense, as a
developer it makes my laugh derisively. Fortunately the situation isn't as bad
as all that, though I'm still not 100% convinced that I'm not still at least
chuckling derisively. I've been fiddling with Haskell for nearly a year now
and I'm still completely undecided whether this is the future or an amusing
but futile diversion from the ivory tower. I've never been this undecided
about a language for so long. The awesome is so awesome, then I stumble into
some unbelievably poky briar patch that I could have at least hacked around in
any other language.... it's very odd.)

~~~
silentbicycle
You're absolutely right about modules. I didn't mention them because I tend to
think of the module system as being independent from the type system, but
they're actually closely related.

------
judofyr
I upvoted this, but only because it proves that even Lispers can be as closed-
minded as anyone else. Lisp is often shown as an example of how "enlighten"
you'll get when you understand it, but clearly that doesn't necessarily mean
you're open for different types of enlightenment.

~~~
drunkpotato
"You can write FORTRAN in any language." I wonder how much enlightenment the
author has actually had in Lisp.

Every language has its zealots, Lisp is no exception.

------
Scriptor
> and after few days I already wrote a lengthy essay about Haskell

Can we stop doing this, please? This is just a really cheap way of driving
traffic to a blog. All you have to do is tinker with something for a few days
and write an inflammatory post. I'd rather read the analysis of someone who's
written a decent-sized program in it.

~~~
WilliamLP
> I'd rather read the analysis of someone who's written a decent-sized program
> in it.

The more I read about Haskell, the more I become convinced that the set of
people solving decently sized real programs in the language numbers somewhere
in the double digits.

------
neutronicus
I often find myself wishing for a combination of the two languages. An
S-Expression based Haskell-alike instead of an S-Expression based Python-alike
(yes, yes I know - Lisp came first - _whatever_ ). Bonus points if I can drop
into an S-Expression based Fortran-alike when bashing on a chunk of memory is
the only way to do something fast.

I like macros, but, as a scientific programmer, I _know_ the type of
everything in my program (double-precision floating point numbers and
aggregations thereof), and I don't want to play some guessing game where I
figure out which types I have to declare to get something to run fast. Same
with garbage collection (what! the GC might move this while LAPACK bashes on
it? I need to explicitly tell it not to? Fuck!).

emacs + paredit is also the best structured editing tool I have used in any
language.

~~~
kanak
Racket has a lazy module that can let you have lisp+laziness. There's also
typed scheme which lets you do lisp+types. Now if only someone could make a
lazy typed racket.

~~~
neutronicus
Yeah, I've been more of a racketeer than a lisper of late. I like their
'batteries included' philosophy.

I don't much like the macro system, though.

I might check out typed racket. I don't care too much about lazy evaluation
one way or the other, long as all my doubles get multiplied, added, and
divided, and it happens fast.

~~~
astrange
Well, just as general advice, the fastest way to multiply your doubles is to
use single-precision SIMD. Does it do that?

~~~
jedbrown
Huh? Double precision SIMD? SSE2 instructions aren't slower than SSE.

~~~
astrange
No, single precision, as in "the fastest way to multiply a double is to use
floats instead". I've seen more than enough C programs unnecessarily using
double that I wish floating point constants would just be float by default.

(Although it seems like clang does something special here, as I don't see many
double-to-float conversions in its output.)

~~~
jedbrown
Then you aren't multiplying doubles, it would be a shame to get a completely
wrong answer on an ill-conditioned problem because the implementation
disregarded the spec, cf. "the fastest way to process UTF-8 is to truncate it
to ASCII", "the fastest RSA encryption is ROT-13". Also note that floats are
only faster with packed instructions (often not possible without changing
APIs) or when memory bandwidth is an issue.

------
kanak
I had a similar observation about haskell's pattern matching when I was
learning haskell: " Built in pattern matching - it's very convenient about
programming sometimes. Unfortunately for someone who learned Prolog before
Haskell, Haskells' pattern matching will look very limited.First it doesn't
allows me to repeat a variable in a pattern , second compared with Prolog,
it's one sided. Big issue for someone used to full power of unification."

I much prefer unification.

~~~
silentbicycle
Same here. Unification rocks, though I think to have full unification rather
than just pattern matching, the language needs logic variables first. (Right?)
"Just" pattern matching is still great, though.

FWIW, I'm working on a pattern-matching library for Lua. (tamale:
<http://github.com/silentbicycle/tamale>) It uses linear search and
backtracking rather than compiled decision trees at the moment, though I have
the latter mostly done - there are a few failing tests for variable corner
cases, though. (Maybe I'll get to them this weekend.) It allows repeating
variables in patterns, too.

~~~
drunkpotato
I've worked through some example problems in Prolog, and find logic
programming to be an interesting way to think about a problem.

I have a problem switching thinking between Prolog clauses as logic relations
and thinking of them as a problem solving process. The towers of Hanoi problem
mystifies me, for example. I also have trouble seeing how to use logic
programming in a larger system, to get more than example problems done. Can
you recommend a good resource?

~~~
silentbicycle
First off, you generally want code to read as much like logically valid
relations as possible. A major strength of Prolog is that "clean" Prolog code
is _extremely_ easy to reason about with only local context.

Chcek out _Clause and Effect_ by Clocksin and _The Art of Prolog_ by Sterling
and Shapiro. CAE is sort of like _The Little Schemer_ for Prolog, but has a
couple larger case studies as well. TAoP is one of my absolute favorite
programming books - it's got as much substance as SICP. The newer edition
(1994) is more expensive (though $35 used on Amazon ATM, which is a steal;
it's usually more like $85-100), but adds quite a bit of new material.

_The Craft of Prolog_ by O'Keefe is also good, though disorganized. (I think
it was written as commentary on something else, and without that, its
structure seems a bit arbitrary.)

I mostly use Prolog for prototyping and exploratory programming. It would
probably be more generally useful as an embedded language library, like Lua
(another favorite of mine). It's a bit awkward as a fully standalone language,
since things like IO don't always mix with backtracking. It's great as a rule
engine, though, and would probably also be brilliant as a query language for a
document-oriented database.

~~~
kanak
> "It's a bit awkward as a fully standalone language, since things like IO
> don't always mix with backtracking. It's great as a rule engine, though, and
> would probably also be brilliant as a query language for a document-oriented
> database."

Fully agree. I'm learning prolog too, and it's really fantastic for the types
of problems it was designed (e.g. resolving constraints and expressing
relations), but I didn't enjoy doing IO in Prolog. My solution is to use lisp
as my primary language and use an implementation of prolog-in-lisp (e.g.
racketlog for racket). This way I have the best of both worlds.

~~~
silentbicycle
I would love to write a Prolog dialect designed _primarily_ for embedding,
much like Lua. I just have a half dozen other serious projects I should wrap
up first. :/

------
mahmud
I found the reddit response to this to be more interesting:

[http://www.reddit.com/r/lisp/comments/cs94g/on_preferring_li...](http://www.reddit.com/r/lisp/comments/cs94g/on_preferring_lisp_to_haskell/c0uvcim)

Most programmers who achieve mastery in a fringe language find themselves
having to justify their choice of tool to others. I think that poster did a
good job in that regard.

Btw, Lisp vs Haskell debates can either lead to intellectually stimulating
discussions, or they can devolve into a bum-fight. The decision that leads to
the choice of either language over something more "popular" is the same: a
quest for beauty and profound insight.

------
pohl
_Hogs a lot of brain resources. It's syntax is complex, and ...(snip)...forces
me to spend more resources on dealing with language than with dealing with the
problem._

I love lispers. I always learn something from their writings, and generally
admire their prose. There seems to be some correlation between deftness of
expression in fingernail-clipping languages and deftness of expression in
English.

I don't quote the above part as an example of that, but rather because I find
the contrast to be damned funny. Somewhere in the deep, misty recesses of
history there was a divinely-inspired Ryu for some natural language that was
an ascestor to English, and that Ryu said that sentences were simple -
subject, verb, and an optional direct object: "Thag hunt beast", or "Narg
die".

Yet those who want an obscenely simple syntactic kernel to build everything on
seem to be adroit with compound-complex sentences, replete with gerunds,
prepositional and participle phrases, appositives, interjections, and
modifiers galore.

Just once I'd like to see a critique of a syntactically complex functional
language like haskell that's written entirely in caveman. It would sound more
honest.

~~~
quasi
ah. To pick on a non-native English speaker's English language prowess - very
brave indeed.

~~~
pohl
I wasn't picking on his language prowess at all. Quite the opposite: I
delighted in reading his post. The contrast that I find amusing is that, so
often, those who decry the syntactic complexity of non-lisp programming
languages never seem to have any problem at all with the syntactic complexity
of English. If complex English syntax doesn't get in the way of expression,
why insist that it is such a cognitive burden to have to have to worry about
something other than s-expressions?

------
bobiblazeski
First thanks to everybody for reading my posts. Currently I'm using regularly
common lisp, java, c#,c/c++ and SQL. I bought Programming Clojure & Practical
Clojure and went through them. I would have bought both Clojure in action and
Joy of Clojure (written by starter of this thread fogus) if Manning accepted
credit card payment from Macedonia. I'm little tired of everything Java
related, that includes Clojure, so I'm using my spare time to learn OpenCL.
Regarding Haskell. I haven't programmed in it since I wrote the post farewell
haskell. The reason for that is my programming style for which Haskell is ill
suited which described in the farewell haskell post in the paragraph starting
with: It may interest you to know that most of my development ..
<http://tourdelisp.blogspot.com/2008/03/farewell-haskell.html> I don't hate
Haskell but its not in list my favorite language either( _) though as one
favoring functional style I cheer news like this<http://bit.ly/djs4J5>. Also I
prefer to say what I'm thinking and be rude if necessary then hide my message
between being politically correct watered down politician talk. On the other
hand I have high opinion about SPJ and enjoy his talks <http://bit.ly/4BG5Dp>
and many of his papers. In the end language wars are pointless, use the
language that suits yourself and have a marry hacking.

(_) For those interested my favorite languages are lisp dialects (cl,scheme
and clojure), array languages (j & q), Prolog, Erlang and concatenative
languages (Factor, Cat & Joy)

------
mhd
In my personal experience, any essay that starts with a martial arts (or zen)
analogy usually brings in a lot of touchy-feely arguments. And it seems this
is no exception. (Considering the historical retconning the Japanese like to
do, I wonder how valid that "ancient" distinction is anyway).

------
mhd
In my personal experience, any essay that starts with a martial arts (or zen)
analogy usually brings in a lot of touchy-feely arguments. And it seems this
is no exception. (Considering the historical retconning the Japanese like to
do, I wonder how valid that "ancient" distinction is anyway).

------
klodolph
This article appeared over at Reddit about a half day earlier:
[http://www.reddit.com/r/lisp/comments/cs94g/on_preferring_li...](http://www.reddit.com/r/lisp/comments/cs94g/on_preferring_lisp_to_haskell/)

