7 ms·

That was interesting. I have a question though. Lazy languages are simpler to deal with for strictly functional data... But what about side-effects? Is the pain

by ced 18y ago

That was interesting. I have a question though. Lazy languages are simpler to deal with for strictly functional data... But what about side-effects? Is the pain of a monad less than the pain of explaining to a student that (defun if (then else) ...) doesn't work? I don't have experience with Haskell, can anyone comment? edit: Is there anything better than Lisp macros that makes defining an if possible and that supports side-effects?

silentbicycle 18y ago
You can use side effects with lazy evaluation, it's just that if you guarantee that you won't, various things suddenly become much easier to do safely (and to optimize for). It's a trade-off. Haskell is lazy by default, but you can also do lazy evaluation in Scheme and OCaml, for example. In Scheme (PLT): (define lazy-with-side-effect (delay (begin (print "Hey, a side effect!") #t))) > lazy-with-side-effect #<promise> > (force lazy-with-side-effect) "Hey, a side effect!"#t > (force lazy-with-side-effect) #t In the OCaml toplevel: # let lwse = lazy (print_string "(Side effect)\n"; true);; val lwse : bool lazy_t = <lazy> # lwse;; - : bool lazy_t = <lazy> # Lazy.force lwse;; (Side effect) - : bool = true # Lazy.force lwse;; - : bool = true
shankys 18y ago
I know both Lisp and Haskell, and I'm pretty sure that Haskell for most people is much harder to learn. The two biggest stumbling blocks people encounter when learning Haskell are monads and the (powerful but complex) type system.
- silentbicycle 18y ago
  In my experience, learning OCaml is a good way to become accustomed to the type system Haskell uses without having to also learn how to do everything with functional purity at the same time. The type systems are very similar, though Haskell has type classes and OCaml has a much more elaborate module system.
  - chollida1 18y ago
    > In my experience, learning OCaml is a good way to become accustomed to the type system Haskell uses I'd agree with this. In addition I'd recommend "The Little MLer" as a great book on how to think in terms of types. edit. didn't read further down. Seems as if it is already mentioned:)
    - silentbicycle 18y ago
      Definitely. I'd recommend the book even if you don't use OCaml or Haskell, really; it made me a lot more conscious of how types can help think out a problem. It's one more technique for your conceptual toolbox. It's also a fairly fast read. It's in the same format as _The Little Schemer_, FWIW.
  - whacked_new 18y ago
    Interesting ideas. I can't imagine myself using them for serious work, but am interested in learning these languages for mental exercise (ref http://news.ycombinator.com/item?id=112196 http://news.ycombinator.com/item?id=112196). I attempted nostrademon's Haskell tutorial but had a hard time making sense of things and so forgetting was a problem. Moreso when you don't really spend time poking around for its own sake. Would either of you recommend OCaml as a gentle lead-in to Haskell, so things can be more easily remembered? I was offered a good book in ML, but I have even less idea of where that would fit.
    - silentbicycle 18y ago
      I'd recommend OCaml over Haskell for real use, actually. Where Haskell is experimental ("[...] Haskell has a sort of unofficial slogan: avoid success at all costs." -Simon Peyton-Jones, http://www.techworld.com.au/article/261007/-z_programming_languages_haskell?pp=10 http://www.techworld.com.au/article/261007/-z_programming_la...), OCaml is intended to be a practical multi-paradigm language, building on new ideas from SML. It has some faults (it's somewhat painful until you understand the type system, and the language seems to be all but designed to give a terrible first impression), but it's a very powerful language. It's not good as a glue language, but for stuff involving heavy numeric processing or complex data structures (e.g. compilers) it really shines. I think it's an excellent complement to Python. IMHO, the best English-language book on OCaml is _Developing Applications with Objective CAML_, a French O'Reilly book. There's a free, complete translation available online (http://caml.inria.fr/pub/docs/oreilly-book/ http://caml.inria.fr/pub/docs/oreilly-book/). I haven't read _OCaml for Scientists_, and I found _Practical OCaml_ by Joshua Smith to be a huge disappointment, FWIW. _The Little MLer_ is a pretty good book on ML's type system. If memory serves, everything but the last chapter would also apply to to Haskell, though you'll have to transliterate syntax. Haskell is a really fun and mind-blowing language, and it will teach you a lot, but I haven't found it to be a practical language. (To be fair, you might feel otherwise. This book looks quite good: http://book.realworldhaskell.org/ http://book.realworldhaskell.org/) You could probably get a lot out of see-sawing back and forth between Haskell and OCaml, switching when you get stuck with one or the other. They have a lot of common concepts, but they take them in different directions.
- eru 18y ago
  Try call/cc when you want a challenge with Lisp (i.e. Scheme).
iman 18y ago
The "pain of a monad" is pretty much the same any many other topics in programming that are tricky for beginners: pointers, recursive functions, linked lists, etc. In fact, monads aren't even a language feature, they are a data structure just like a linked list, defined just like any other data structure. There have even been several articles describing how to implement a monad in other popular languages(monads in ruby, monads in C++, monads in lisp). As for your second question, it's funny that you ask it after mentioning haskell. The solution of course is that a collection of haskell features offer tools that are "better than Lisp macros" and support side effects. Lazy evaluation and monads cover most cases where you would use a macro in lisp. There are also more complex things like comonads and arrows. These solve the problems that lisp macros solve in a different way. And if you really need the ultimate power that lisp macros provide, then the haskell equivalent is template haskell.
- michaelneale 18y ago
  In only have a tiny bit of experience with monads (in haskell) but I would say it may be more pain to wrap your head around the maths, but much much less to use and trust. Pointers I would say are the opposite.

by ced 18y ago

silentbicycle 18y ago

You can use side effects with lazy evaluation, it's just that if you guarantee that you won't, various things suddenly become much easier to do safely (and to optimize for). It's a trade-off. Haskell is lazy by default, but you can also do lazy evaluation in Scheme and OCaml, for example. In Scheme (PLT): (define lazy-with-side-effect (delay (begin (print "Hey, a side effect!") #t))) > lazy-with-side-effect #<promise> > (force lazy-with-side-effect) "Hey, a side effect!"#t > (force lazy-with-side-effect) #t In the OCaml toplevel: # let lwse = lazy (print_string "(Side effect)\n"; true);; val lwse : bool lazy_t = <lazy> # lwse;; - : bool lazy_t = <lazy> # Lazy.force lwse;; (Side effect) - : bool = true # Lazy.force lwse;; - : bool = true

shankys 18y ago

I know both Lisp and Haskell, and I'm pretty sure that Haskell for most people is much harder to learn. The two biggest stumbling blocks people encounter when learning Haskell are monads and the (powerful but complex) type system.

silentbicycle 18y ago
In my experience, learning OCaml is a good way to become accustomed to the type system Haskell uses without having to also learn how to do everything with functional purity at the same time. The type systems are very similar, though Haskell has type classes and OCaml has a much more elaborate module system.
- chollida1 18y ago
  > In my experience, learning OCaml is a good way to become accustomed to the type system Haskell uses I'd agree with this. In addition I'd recommend "The Little MLer" as a great book on how to think in terms of types. edit. didn't read further down. Seems as if it is already mentioned:)
  - silentbicycle 18y ago
    Definitely. I'd recommend the book even if you don't use OCaml or Haskell, really; it made me a lot more conscious of how types can help think out a problem. It's one more technique for your conceptual toolbox. It's also a fairly fast read. It's in the same format as _The Little Schemer_, FWIW.
- whacked_new 18y ago
  Interesting ideas. I can't imagine myself using them for serious work, but am interested in learning these languages for mental exercise (ref http://news.ycombinator.com/item?id=112196 http://news.ycombinator.com/item?id=112196). I attempted nostrademon's Haskell tutorial but had a hard time making sense of things and so forgetting was a problem. Moreso when you don't really spend time poking around for its own sake. Would either of you recommend OCaml as a gentle lead-in to Haskell, so things can be more easily remembered? I was offered a good book in ML, but I have even less idea of where that would fit.
  - silentbicycle 18y ago
    I'd recommend OCaml over Haskell for real use, actually. Where Haskell is experimental ("[...] Haskell has a sort of unofficial slogan: avoid success at all costs." -Simon Peyton-Jones, http://www.techworld.com.au/article/261007/-z_programming_languages_haskell?pp=10 http://www.techworld.com.au/article/261007/-z_programming_la...), OCaml is intended to be a practical multi-paradigm language, building on new ideas from SML. It has some faults (it's somewhat painful until you understand the type system, and the language seems to be all but designed to give a terrible first impression), but it's a very powerful language. It's not good as a glue language, but for stuff involving heavy numeric processing or complex data structures (e.g. compilers) it really shines. I think it's an excellent complement to Python. IMHO, the best English-language book on OCaml is _Developing Applications with Objective CAML_, a French O'Reilly book. There's a free, complete translation available online (http://caml.inria.fr/pub/docs/oreilly-book/ http://caml.inria.fr/pub/docs/oreilly-book/). I haven't read _OCaml for Scientists_, and I found _Practical OCaml_ by Joshua Smith to be a huge disappointment, FWIW. _The Little MLer_ is a pretty good book on ML's type system. If memory serves, everything but the last chapter would also apply to to Haskell, though you'll have to transliterate syntax. Haskell is a really fun and mind-blowing language, and it will teach you a lot, but I haven't found it to be a practical language. (To be fair, you might feel otherwise. This book looks quite good: http://book.realworldhaskell.org/ http://book.realworldhaskell.org/) You could probably get a lot out of see-sawing back and forth between Haskell and OCaml, switching when you get stuck with one or the other. They have a lot of common concepts, but they take them in different directions.
eru 18y ago
Try call/cc when you want a challenge with Lisp (i.e. Scheme).

iman 18y ago

The "pain of a monad" is pretty much the same any many other topics in programming that are tricky for beginners: pointers, recursive functions, linked lists, etc. In fact, monads aren't even a language feature, they are a data structure just like a linked list, defined just like any other data structure. There have even been several articles describing how to implement a monad in other popular languages(monads in ruby, monads in C++, monads in lisp). As for your second question, it's funny that you ask it after mentioning haskell. The solution of course is that a collection of haskell features offer tools that are "better than Lisp macros" and support side effects. Lazy evaluation and monads cover most cases where you would use a macro in lisp. There are also more complex things like comonads and arrows. These solve the problems that lisp macros solve in a different way. And if you really need the ultimate power that lisp macros provide, then the haskell equivalent is template haskell.

michaelneale 18y ago
In only have a tiny bit of experience with monads (in haskell) but I would say it may be more pain to wrap your head around the maths, but much much less to use and trust. Pointers I would say are the opposite.