[BenoitEssiambre]

That's interesting. The author of Javascript wanted something lisp like. That must be why Javascript feels a bit like lisp to me with functions and closures being primary building blocks, notwithstanding the recent misguided attempts at making Javascript look more imperative with promises and the like.

I think there is something to the argument in the article about Lisp being too expressive and allowing developers to have too different styles making it difficult to read other peoples code. I wonder if another part of the problem with Lisp is that newbie developers struggle to follow continuation-passing style programs. This would explain why the promise crutch is so popular in Javascript.

I don't think it's the brackets that people dislike, it's having to understand the layers of scoping and closures that the brackets imply. Once you get used to it though it becomes very powerful.

[sansnomme]

Continuation passing isn't suitable for humans. Callback hell is a thing. Leave it for compiler SSAs and use something more sensible for reading.

[flavio81]

>I think there is something to the argument in the article about Lisp being too expressive and allowing developers to have too different styles making it difficult to read other peoples code.

Rest assured this doesn't happen in Common Lisp, because what often happens is that the program is done in the style where it makes more sense.

For example, if the program lends itself to be easily done using OOP, then it is written using CLOS (the lisp OOP system).

If, for example, there is a part that is a state machine, it might be written in the old "goto <label>" style.

If it lends to functional programming, well, lisp was the first FP language, so fine.

If a part of the program requires generation of HTML, the source will resemble HTML.

etc.

[ChristianBundy]

> misguided

Could you recommend a resource that explains why these features are misguided? I've found them to be much nicer than callbacks but it's possible that I'm misguided too. :~)

[BenoitEssiambre]

https://medium.com/@b.essiambre/continuation-passing-style-p...

[akira2501]

With CPS it seems like you have to build and then instrument a lot of additional machinery (CPSMath.pow, seriously?) and occasionally turn your code inside out (the loop completion example) in order to rarely get a more convenient way to extend certain types of computations.

The author also seems to lay the fact that Javascript is often implemented in an odd way in browsers (the iframe complaint) to find fault with the entirety of the concept of Promises in general, which doesn't seem appropriate to the discussion here.

Finally.. he suggests that CPS shows it's power in a "probabilistic programming language" that executes blocks of code in a random order. Perhaps I shouldn't judge an author by their contents, but I think this author is so in love with the idea of CPS that he can't see how ugly and mostly mismatched it's implementations are.

[BenoitEssiambre]

Don't use CPSMath.pow. It's just in there to demonstrate that it's easy to turn direct style into CPS style. When a function doesn't need to be asyncronous, just use direct style.

[ChristianBundy]

Friendly recommendation: when writing examples it's much nicer to use a real use-case rather than abstract functions like `cps4()` or `CPSadditionalProcessing()`.

Anyway, it seems that your point is that you'd like to recommend passing continuables a la callstep: https://github.com/ahdinosaur/callstep

Continuables are a great pattern, but you haven't really answered the question of why you think promises are "misguided".