3 ms·

The author offers an alternative that would require a change to the language. Callbacks and their use in "callback hell" are a little different than use of "go

The author offers an alternative that would require a change to the language. Callbacks and their use in "callback hell" are a little different than use of "goto"; "goto" appears to have an obvious alternative that was more logical to use already implemented in the language. For javascript, there is none of the nice syntactic sugar (reminds me a lot of C# recent async changes) that the author suggests and is not even being proposed for ECMA 6. I agree it would be nice to have that stuff, and that callbacks can get a little hairy, but they are the best solution available at present. Shall we stop developing applications in the mean time while the language catches up, or even worse, browsers actually consistently implement the changes?

benregenspan 14y ago
There are alternatives that don't require extending the language or having to work directly with a mess of nested callbacks. A bunch of flow-control libraries here: http://dailyjs.com/2012/02/20/new-flow-control-libraries/ http://dailyjs.com/2012/02/20/new-flow-control-libraries/ This is definitely more hairy to use than if the language supported it natively, but not so bad, and can be implemented in a very lightweight way (this approach http://daemon.co.za/2012/04/simple-async-with-only-underscore/ http://daemon.co.za/2012/04/simple-async-with-only-underscor... is a few lines of code on top of Underscore.js which a lot of sites are using already). (PS: sorry if OP's article already mentioned this stuff, I can't load it at the moment)
dllthomas 14y ago
No, we should stop writing javascript and start writing elm - a language that compiles to javascript, works like described in that page, and is the subject generally of the site hosting the article. At least, that's what the article is saying. There are a few interesting things on the horizon there, but I've been watching elm with some interest.
tactics 14y ago
If you had a program back then full of gotos and an assembly language that didn't support structured blocks, your problem was just as bad. At its core, FPR only requires higher-order functions to work. (And nearly every modern language supports them to some degree). The things that Elm provides are additional niceties: * A type system with parametry polymorphism (aka generics) helps you spot otherwise nasty runtime errors ("expected a function, got a signal"). * Abstract data types - The only way to create a signal is through the API. The only thing you can do with a signal is pass it around and feed it back into the API. * Language purity - This one is probably the hardest sell for average languages, since every modern language (save Haskell) allows for unrestricted side-effects. However, as long as you don't bypass the API and update the UI directly, you don't actually NEED purity. The nice thing about Elm is that it compiles directly to Javascript. You can integrate it into new pages on your existing site without giving up anything. I think the language -- and more generally FPR as a basic tool in your toolkit -- has a lot of potential in the future.

benregenspan 14y ago

There are alternatives that don't require extending the language or having to work directly with a mess of nested callbacks. A bunch of flow-control libraries here: http://dailyjs.com/2012/02/20/new-flow-control-libraries/ http://dailyjs.com/2012/02/20/new-flow-control-libraries/ This is definitely more hairy to use than if the language supported it natively, but not so bad, and can be implemented in a very lightweight way (this approach http://daemon.co.za/2012/04/simple-async-with-only-underscore/ http://daemon.co.za/2012/04/simple-async-with-only-underscor... is a few lines of code on top of Underscore.js which a lot of sites are using already). (PS: sorry if OP's article already mentioned this stuff, I can't load it at the moment)

dllthomas 14y ago

No, we should stop writing javascript and start writing elm - a language that compiles to javascript, works like described in that page, and is the subject generally of the site hosting the article. At least, that's what the article is saying. There are a few interesting things on the horizon there, but I've been watching elm with some interest.

tactics 14y ago

If you had a program back then full of gotos and an assembly language that didn't support structured blocks, your problem was just as bad. At its core, FPR only requires higher-order functions to work. (And nearly every modern language supports them to some degree). The things that Elm provides are additional niceties: * A type system with parametry polymorphism (aka generics) helps you spot otherwise nasty runtime errors ("expected a function, got a signal"). * Abstract data types - The only way to create a signal is through the API. The only thing you can do with a signal is pass it around and feed it back into the API. * Language purity - This one is probably the hardest sell for average languages, since every modern language (save Haskell) allows for unrestricted side-effects. However, as long as you don't bypass the API and update the UI directly, you don't actually NEED purity. The nice thing about Elm is that it compiles directly to Javascript. You can integrate it into new pages on your existing site without giving up anything. I think the language -- and more generally FPR as a basic tool in your toolkit -- has a lot of potential in the future.