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

11–20 of 40 posts

Re: Lisper's first look at Haskell

#11

Post by dagheti »

silentbicycle wrote: post #5

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…

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.

Re: Lisper's first look at Haskell

#12

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

Re: Lisper's first look at Haskell

#13

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

Re: Lisper's first look at Haskell

#14

Post by masklinn »

dagheti wrote: post #11
silentbicycle wrote: post #5

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…

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…

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

Re: Lisper's first look at Haskell

#15

Post by silentbicycle »

aristidb wrote: post #6
silentbicycle wrote: post #5

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…

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

Re: Lisper's first look at Haskell

#16

Post by drunkpotato »

judofyr wrote: post #12

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.

Re: Lisper's first look at Haskell

#17

Post by drunkpotato »

silentbicycle wrote: post #3
kanak wrote: post #2

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

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 problems done. Can you recommend a good resource?

Re: Lisper's first look at Haskell

#18

Post by aristidb »

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…

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

Re: Lisper's first look at Haskell

#19

Post by silentbicycle »

judofyr wrote: post #12

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.

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.

Re: Lisper's first look at Haskell

#20

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

Post reply on HN