Structure and Interpretation of Computer Programs | Hacker News Reader

Structure and Interpretation of Computer Programs

groups.csail.mit.edu

43 pointsnadim26 comments

Philip Wadler wrote an interesting critique of this classic computer science text: http://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.p...

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?

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

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.

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.

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.

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.

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

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

I disagree completely.

It is true that a few years ago, OCaml was more "practical" then haskell. It was faster and had more libraries.

But today haskell is superior to OCaml in nearly all aspects.

As a language, haskell has always been cleaner and more elegant. It has simpler syntax, a more powerful type system, lazy evaluation, and in general more features.

In terms of performance, haskell has caught up with OCaml and exceeded it. The leading haskell compiler(GHC) has been adding in optimizations one after another the past few years. Deforestation, pointer tagging, parallel garbage collection, and other techniques from various research papers. GHC is a top quality professional compiler built by a bunch of geniuses. Haskell also has several implementations and compilers(GHC, Hugs, yhc, nhc, jhc...) while OCaml has only a single implementation.

In terms of tool support, haskell has a debugger(ghci debugger), a profiler(ghc) an excellent documentation generation tool(haddock), and a standard build system(cabal). These are all superior to their OCaml equivalents(where they exist at all: OCaml build systems usually are a mess of makefiles or autohell)

Haskell is catching up to OCaml in the number of libraries available. Haskell now has a CPAN-like website called hackage with hundreds of libraries for all application domains (see the list: http://hackage.haskell.org/packages/archive/pkg-list.html ). Libraries can be downloaded and installed with haskell's build system using a single command, with dependencies also automatically taken care of. The haskell standard library is also a lot better then OCaml's. OCaml has two different incompatible list types(one lazy and one strict). OCaml's file handles can be either written to or read from, not both. (It's not possible to open a file for RW in OCaml). And OCaml infamously requires special syntax for doing arithmatic with floating point numbers(1 + 2 for integer, 3.0 +. 4.0 for floating point).

In terms of community I think that both languages are about equal. Haskell has active and beginner-helpful mailing lists and an IRC channel (one of freenode's most crowded).

Overall, I believe that Haskell is more "practical" then OCaml in nearly every domain. The only thing where OCaml might be preferable is high performance numeric stuff. But this might not be the case for much longer when the haskell GHC compiler will soon get it's new native code generator.

Haskell popularity has been exploding in the past few years, with tons of new libraries and books. There have always been myths about haskell that have caused it to have a perception of being impractical, kind of similar to lisp. But the truth is that haskell is a practical language, and depending on what you need to do, it can even compete with other practical languages like java and python.

First off, thanks for disagreeing constructively. I was hoping somebody would argue with sources that Haskell has gotten better for practical use. It's a really cool language. You've convinced me to give it another look when I have time.

> OCaml build systems usually are a mess of makefiles or autohell

VERY true. OCamlMakefile (http://www.ocaml.info/ocaml_sources/ocaml-make-6.28.1/README) helps, somewhat.

> In terms of community I think that both languages are about equal.

Really? I've gotten the impression that the Haskell community is larger, or at least writes quite a bit more. (And dons on #haskell is really helpful.)

OTOH, OCaml seems to be more portable. Porting GHC to a new platform seems quite a bit more difficult than porting OCaml; its separation of byte- and native compilation helps considerably. (This may or may not be as important to you.) Also, OCaml doesn't need to do as many advanced things for optimization.

All other things aside, I still think that Haskell is probably easier to learn if you are familiar with OCaml first (which was the original question): Haskell requires you to understand several new ideas upfront before you can do much of anything, whereas in OCaml you can pick up functional programming and how to work with the type system before learning to work with lazy evaluation and monads / purity. (You can also use monads in OCaml, Scheme, etc., of course.)

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

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.

Try call/cc when you want a challenge with Lisp (i.e. Scheme).

I studied Miranda in university. It is a beautiful functional language but it wasn't free as in beer. Then around that time I heard about this free language called Haskell that was similar to Miranda. I stopped using Miranda after my course was over. If it was free I wonder if it would be more popular today.

I also did miranda (was my first programming language).

My understanding at the time was that it was only intended for research, and as it was pure, there was no way (at the time ) to do real IO - your program was essentially f(user input as string) = output as a string, and not practical enough.

Since that time they worked out how to use Monads in haskell for a nicer IO experience.

Interesting.

In large part the critiques seem to center around failings of minimal prefix syntax(failings which I would agree with). Minor errors that in bulkier languages are caught by the compiler, become logic errors in a Lisp; an easy way to become frustrated as a learner.

It's interesting how the PLT team dealt with this teaching problem in "How to Design Programs". The first part basically shows how to write simple Java-like code with Scheme syntax, using symbols and fixed records, and including tests as part of a complete program. Then in the later sections, lists and the more dynamic handling of data are introduced gradually. Aren't PLT Scheme structures way more complicated than lists? Yes, but since simple errors show up sooner with a struct, it seems to be a better way to teach brand-new programming students how to work with compound data.

>Minor errors that in bulkier languages are caught by the compiler, become logic errors in a Lisp

doesn't that apply to any less static -> more static typed language comparison?

Hal Abelson is a smart guy. He does a lot of work concerning law, privacy, and technology, including the internet and mobile devices. You may want to take a look at his book Blown to Bits http://www.bitsbook.com

Besides the book itself, are there any transcripts fer these videos? I've watched several of them, but some go by rather slowly. (I know: whine, whine.)

if you're at all interested in self-growth, watch this with intensity.

Agreed. I've watched this series on and off for a few years now and it's always worthwhile.

I've been watching these to get a grasp of lisp, and think they're great - not least because of the amazingly cool retro-look and haircuts of the audience.

These videos and book are certainly way to get some grasp at LISP, but not especially good way, because what is presented as LISP there is Scheme and it is presented in way that I would call too theoretic and oriented towards pedagogical purposes. And intention of SICP is to teach basics of CS, not LISP or Scheme, Scheme is used only as programming language serving this purpose. And for this purpose it is one of best materials that I've seen. But because of this programming style presented here is significantly different from what is useful for practical purposes. So it will help you as programmer in general, but not as LISP programmer.

If you want to learn Common Lisp and especially to use it effectively I would recommend CL-oriented book, for example Practical Common Lisp by Peter Seibel.

But still I'm recommending SICP (at least watch the videos) to anyone who indends to be real programmer.

These videos made me a better python programmer. I wrote a small game in python in a lisp inspired style, and thought it was too lispy and so i tried to rewrite it in scheme, just for comparison. I don't know scheme that much, and because of that, i failed.

Reply on news.ycombinator.com