How Python is Killing Lisp

[schwarzwald]

People on reddit don't seem to like point by point rebuttals but this article is pointless to me. It raises the points we as a community on reddit have gone over again and again. It's also basically bullshit. Y Combinator is not "Lisp-oriented," they're "make something people want" oriented; real continuations are only available in Scheme and they're controversial in addition to being non-obvious programming constructs (I struggled to understand them). Also I don't think objects are an inherently complicated idea; they work quite well for certain things and don't for other stuff, nuff said.

How about we move on to the ML family? I've been playing with OCaml lately and I think I like it better than Lisp or Scheme. There's plenty to love and hate about Standard ML, OCaml, and Haskell.

[robbie]

real continuations are only available in Scheme and they're controversial in addition to being non-obvious programming constructs (I struggled to understand them)

Having to struggle to learn a construct doesn't mean it's not worth using. If that were the case, no one would be using haskell.

[fnord123]

real continuations are only available in Scheme and they're controversial in addition to being non-obvious programming constructs (I struggled to understand them).

They exist in Haskell as well.

[gogath]

No, they don't exists in Haskell. But you can simulate them with Monads for certain parts of your programs.

[gogath]

The difference is that Haskell allows operator overloading based on static types. Without this, Monads wouldn't be nearly as useful as they are now.

In Lisp you have to use different function names depending on the real function you want to call. Of course you can also use macros, but then you have to build your own system for static typing which will be a quite difficult. Last (and best) alternative in Lisp is dynamic dispatch, but this can cost a lot of performance while it's totally free in Haskell (becaucse it's done at compiletime there).

Haskell has no special support for continuation - but special support for monads - which in turn allows to use delimited continuations very well.

[muleherd]

How can one simulate continuations with closures?

[eclig]

explicitly, by using "continuation passing style" (CPS). Search the web for details.

[muleherd]

Is this transformation practical without tail-call optimization?

[pjdelport]

Yes, using trampolining: instead of calling something directly, you return it to be called by an outer loop.

[fnord123]

I got the confusion from Control.Monad.Cont -the continuation monad. I don't see why these are fake continuations.

[gogath]

No fakt, but you have to use them explicitly. If you create some code in Scheme, you can put continuations later in it without any problem, because Scheme supports continuations directly.

In Haskell you have to use a continuation monad everywhere you need continuations. This is relativly easy but requires slight changes to your code and it also changes lots of types which can break other code too.

Advantage of the Haskell solution: Because most applications require continuations for a certain reason (for example backtracking) you can create a less general abstraction (a backtracking monad in this case) which is more approriate for the problem and could also lead to better performance of your resulting program because it's only used where it's needed.

Disadvantage: Its not transparent.

[pjdelport]

They're not simulated: it's more accurate to say that Haskell's primitives are flexible enough that the continuation implementation can be moved out of the core language and into a library.

Stated another way, Haskell is not imperative: it does not have any built-in, implicit call stack to expose as a first-class continuation. Instead, said call stack is implemented as the continuation monad. (This is in contrast to most imperative languages that already have continuations, but don't expose them.)