28 ms·

The "callback hell" example is a rather tame one, since the code is readable in a single location just with some nesting. So when I see the FRP solution which

The "callback hell" example is a rather tame one, since the code is readable in a single location just with some nesting. So when I see the FRP solution which is the same amount of code I'm not certain that in a complex example this actually solves the problem. You can still have lift statements scattered around a program just like you can have callbacks to various functions scattered around. The solution to GOTO was to remove it and replace it with a few control structure forms that enforced locality. I remember converting someone's GOTO-laced code once and basically everything could be re-written with some clever use of do-while with break statements and an occasional flag variable. do-while, while, for, etc. replace GOTO in 99% of cases and enforce the desired code locality for readability. So what syntactical structure could enforce locality of time-connected variables? E.g. some idea like this: data, err <- $.ajax(requestUrl1) if( err ) { console.log(err) return } data2, err <- $.ajax(makeRequestUrl2(data)) Where the <- syntax could be like an = statement but say that the assignment and all following statements are placed in a callback.

romaniv 14y ago
C# 4.0 has async/await to solve this. http://msdn.microsoft.com/en-us/library/vstudio/hh191443.aspx http://msdn.microsoft.com/en-us/library/vstudio/hh191443.asp...
- Someone 14y ago
  Async looks nice, but this (http://www.jayway.com/2012/10/07/asyncawait-in-c-a-disaster-waiting-to-happen/ http://www.jayway.com/2012/10/07/asyncawait-in-c-a-disaster-...) makes me wonder whether it is the right solution for this problem. Breaking what most programmers think are the 'laws' of refactoring is not a good thing.
  - int_19h 14y ago
    The problem in the linked article is not async/await, but rather specifically async void, which you don't get by following the straightforward sync->async refactoring rules. A normal void method would start returning Task when turned async (and a non-void method returning T would start returning Task<T>). Async void is a special, distinct beast which is fire-and-forget by definition, and it only exists in async land. Perhaps they should have used a special new keyword for that instead, but in any case, it's a completely orthogonal problem.
btilly 14y ago
More than 99% of cases. If you have functions, loops, and nested loop control, in 100% of cases you can replace GOTO code with code that is equally efficient. With flag variables and if checks, you can likewise always replace the code, BUT efficiency and verbosity suffers because of the need to check the flag variable repeatedly in the loop. As for your syntax suggestion, I am reminded of http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html which manages to use a preprocessor trick to generate working coroutines in C. (This trick is actually used in PuTTY.) I also think that the strategy that you describe would work well enough for my tastes.
ufo 14y ago
I think there are a couple of async Javascript dialects that already do this: http://tamejs.org/ http://tamejs.org/ The main advantage tat not many people see is that you get backwards compatibility with sync code (if statements, while loops, etc) basically for "free".
- doublerebel 14y ago
  Yes, there are numerous libraries that do this. For instance, Tamejs is now rolled into CoffeeScript, creating IcedCoffeeScript. I didn't think CoffeeScript could get better, but it does. In addition, there is: Q (implementation of the CommonJS Promises spec) https://github.com/kriskowal/q https://github.com/kriskowal/q Streamline.js https://github.com/Sage/streamlinejs https://github.com/Sage/streamlinejs Await.js (New, inspired by Tame/IcedCS) https://github.com/greim/await.js https://github.com/greim/await.js jQuery.Deferred http://api.jquery.com/category/deferred-object/ http://api.jquery.com/category/deferred-object/ ...And less current libs like Node-promises and FuturesJS. Here's a comparison from last year: http://www.infoq.com/articles/surviving-asynchronous-programming-in-javascript http://www.infoq.com/articles/surviving-asynchronous-program... And IcedCS's debut on HN: http://news.ycombinator.com/item?id=3522839 http://news.ycombinator.com/item?id=3522839 In JS devs seem to like to reinvent the wheel. I'd love to see the community rally around one of these solutions, instead of creating new half-finished ones and abandoning them. I'm partial to IcedCS because it's the least verbose, and it also works as a lib outside of CS. The Promises spec has been (partially) implemented by jQuery and I'm sure is here to stay. Elm's syntax won't easily translate to any existing solution I'm aware of. It is a nice research project, but I will be sticking with established, well-tested methods instead of risking my business on another half-finished wheel.

romaniv 14y ago

C# 4.0 has async/await to solve this. http://msdn.microsoft.com/en-us/library/vstudio/hh191443.aspx http://msdn.microsoft.com/en-us/library/vstudio/hh191443.asp...

Someone 14y ago
Async looks nice, but this (http://www.jayway.com/2012/10/07/asyncawait-in-c-a-disaster-waiting-to-happen/ http://www.jayway.com/2012/10/07/asyncawait-in-c-a-disaster-...) makes me wonder whether it is the right solution for this problem. Breaking what most programmers think are the 'laws' of refactoring is not a good thing.
- int_19h 14y ago
  The problem in the linked article is not async/await, but rather specifically async void, which you don't get by following the straightforward sync->async refactoring rules. A normal void method would start returning Task when turned async (and a non-void method returning T would start returning Task<T>). Async void is a special, distinct beast which is fire-and-forget by definition, and it only exists in async land. Perhaps they should have used a special new keyword for that instead, but in any case, it's a completely orthogonal problem.

btilly 14y ago

More than 99% of cases. If you have functions, loops, and nested loop control, in 100% of cases you can replace GOTO code with code that is equally efficient. With flag variables and if checks, you can likewise always replace the code, BUT efficiency and verbosity suffers because of the need to check the flag variable repeatedly in the loop. As for your syntax suggestion, I am reminded of http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html which manages to use a preprocessor trick to generate working coroutines in C. (This trick is actually used in PuTTY.) I also think that the strategy that you describe would work well enough for my tastes.

ufo 14y ago

I think there are a couple of async Javascript dialects that already do this: http://tamejs.org/ http://tamejs.org/ The main advantage tat not many people see is that you get backwards compatibility with sync code (if statements, while loops, etc) basically for "free".

doublerebel 14y ago
Yes, there are numerous libraries that do this. For instance, Tamejs is now rolled into CoffeeScript, creating IcedCoffeeScript. I didn't think CoffeeScript could get better, but it does. In addition, there is: Q (implementation of the CommonJS Promises spec) https://github.com/kriskowal/q https://github.com/kriskowal/q Streamline.js https://github.com/Sage/streamlinejs https://github.com/Sage/streamlinejs Await.js (New, inspired by Tame/IcedCS) https://github.com/greim/await.js https://github.com/greim/await.js jQuery.Deferred http://api.jquery.com/category/deferred-object/ http://api.jquery.com/category/deferred-object/ ...And less current libs like Node-promises and FuturesJS. Here's a comparison from last year: http://www.infoq.com/articles/surviving-asynchronous-programming-in-javascript http://www.infoq.com/articles/surviving-asynchronous-program... And IcedCS's debut on HN: http://news.ycombinator.com/item?id=3522839 http://news.ycombinator.com/item?id=3522839 In JS devs seem to like to reinvent the wheel. I'd love to see the community rally around one of these solutions, instead of creating new half-finished ones and abandoning them. I'm partial to IcedCS because it's the least verbose, and it also works as a lib outside of CS. The Promises spec has been (partially) implemented by jQuery and I'm sure is here to stay. Elm's syntax won't easily translate to any existing solution I'm aware of. It is a nice research project, but I will be sticking with established, well-tested methods instead of risking my business on another half-finished wheel.