Lisper's first look at Haskell | Hacker News Reader

Lisper's first look at Haskell

tourdelisp.blogspot.com

30 pointsfogus39 comments

"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. "

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.)

"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 ? ;-)

Emacs is used by many lispers but not all of them.The most famous non Emacs lisper is Paul Graham. I don't mind using Emacs and Slime on Linux but for a visual type of person they suck compared to modern IDE's. I rely a lot on visual clues and speedbar is a poor man alternative. Franz and Lispworks are making good ides and many commercial organizations are buying and using them. The implementations you mentioned are all open source and don't have resources to develop proper IDE since there is no big company to back them up, such as IBM financing eclipse. So they choose proper course of action of improving their implementations with Emacs + SLIME as their programming environment.

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.

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.

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.)

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.)

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.

It's possible to do without Existential Types, in fact they are only a language extension supported by GHC, not part of any standard. I think the obvious way to "simulate" existential types is with records like

data MyRec = MkMyRec { op1 :: Int -> (MkMyRec, Int); op2 :: MkMyRec }

Existential types just give you direct access to all methods in an existing typeclass, which may or may not be helpful.

Btw., OCaml is on my list of "things to do" right below "create something with more than 200 lines in Haskell" (which is hard because Haskell is so dense). ;-)

"create something with more than 200 lines in Haskell" (which is hard because Haskell is so dense). ;-)

You might succeed by translating USSM http://www.loup-vaillant.fr/projects/ussm The system is written in about 300 lines of Ocaml, and should be easy to translate. Plus, you can rewrite it piece by piece, and still have a system that works.

I find that F#'s (close to OCaml) type system helps me think through problems and lets me get correct programs faster, that somehow just seem to work correctly the first time.

Usually when writing a program in F# I usually write out the types of the functions I need first, before worrying about how the functions work. Because the type system is so descriptive I can validate that a plan to solve a problem is going to work before I start writing code.

Because the type system is powerful, when I need to make a change, it is simple to determine where my assumptions are broken and make the correct fixes.

> Usually when writing a program in F# I usually write out the types of the functions I need first, before worrying about how the functions work.

And that kind of things can give rise to such wonderful tools as hoogle (a type-based Haskell search engine, specify the type you need and it'll find the matching functions, whose types are often quite good insight as to their purpose)

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.

"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.

At first glance, I thought it was Dave Herman's blog (http://calculist.blogspot.com/), due to the similar styling. I would have found it pretty shocking coming from him, but no.

> 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.

> 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.

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.

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.

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.

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

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

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.)

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.

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.

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.

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?

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.

> "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.

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. :/

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

http://www.reddit.com/r/lisp/comments/cs94g/on_preferring_li...

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.

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.

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

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?

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)

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).

This article appeared over at Reddit about a half day earlier: http://www.reddit.com/r/lisp/comments/cs94g/on_preferring_li...

Reply on news.ycombinator.com