Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lisper's first look at Haskell

tourdelisp.blogspot.com

Post reply on HN
Print view View original

21–30 of 40 posts

Re: Lisper's first look at Haskell

#21

Post by silentbicycle »

drunkpotato wrote: post #17
silentbicycle wrote: post #3

Earlier quoted context omitted.

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 l…

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 prob…

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.

Re: Lisper's first look at Haskell

#22

Post by WilliamLP »

Scriptor wrote: post #13

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

Re: Lisper's first look at Haskell

#23

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

Re: Lisper's first look at Haskell

#24

Post by jerf »

silentbicycle wrote: post #15
aristidb wrote: post #6

Earlier quoted context omitted.

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 enou…

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

Re: Lisper's first look at Haskell

#25

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

Re: Lisper's first look at Haskell

#26

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

Re: Lisper's first look at Haskell

#27

Post by loup-vaillant »

aristidb wrote: post #18
silentbicycle wrote: post #15

Earlier quoted context omitted.

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 enou…

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 m…

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

Re: Lisper's first look at Haskell

#28

Post by silentbicycle »

jerf wrote: post #24
silentbicycle wrote: post #15

Earlier quoted context omitted.

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 enou…

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 select…

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.

Re: Lisper's first look at Haskell

#29

Post by kanak »

neutronicus wrote: post #20

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…

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.

Re: Lisper's first look at Haskell

#30

Post by kanak »

silentbicycle wrote: post #21
drunkpotato wrote: post #17

Earlier quoted context omitted.

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 prob…

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 abs…

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

Post reply on HN