Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Callback Hell (2016)

callbackhell.com

Post reply on HN
Print view View original

121–130 of 170 posts

Re: Callback Hell (2016)

#121

Post by lucideer »

npsimons wrote: post #104
lucideer wrote: post #6

> In other languages like C, Ruby or Python there is the expectation that whatever happens on line 1 will finish before the code on line 2 starts running and so on down the file. As you will learn, JavaScript is different. A lot of beginner guides to various programming languages make this mistake of associating a certain property with a language as if it's inherent. In this case, async code - while sold as a main fe…

> This may seem a nitpick, but I think it's an incredibly important distinction for beginners (or at least, I think it's incredibly important not to mislead beginners into believing in this limitation early on). No, I think it's very important, maybe even more important for some of us old dogs still marvelling at having virtual SMP in a desktop rig. While it might be easier to teach people new to programming the old…

I'm not too sure but you might have misinterpreted my comment?

I was saying one shouldn't tell beginners that JS is inherently async and other languages are never async.

Re: Callback Hell (2016)

#122

Post by kudokatz »

dahart wrote: post #75
increment_i wrote: post #8

As a curious and perhaps naive aside, I've been wondering why the programmer should need to care about asynchronous execution of code at all. Can't it all be abstracted under a procedural layer and let the OS worry about not blocking anything? The advent of promises, async.js, and other paradigms tell me that people still kind of want to write code that does one thing after another, then another, then another.

> Can't it all be abstracted under a procedural layer and let the OS worry about not blocking anything? No. There's no way around understanding that some of your code will run now, and some will run later. It's imperative to understand this in places where you mix sync and async code. It's not possible to avoid mixing them, after all, the async functions have to be called by something . You could hide all async in a…

> You could hide all async in a procedural layer if you accepted the constraint that once an async call starts, none of your own code will run until it returns. It wouldn't block the browser or OS, but it would block you ... I have no choice in the matter. I can't make use of the result of a REST call until I actually have the result.

The core.async library for Clojure makes the code look imperative, but handles locking and selecting threads to run under-the-covers ... you may find it an interesting compromise

https://www.infoq.com/presentations/clojure-core-async

Re: Callback Hell (2016)

#123

Post by lucideer »

hashkb wrote: post #99
lucideer wrote: post #6

> In other languages like C, Ruby or Python there is the expectation that whatever happens on line 1 will finish before the code on line 2 starts running and so on down the file. As you will learn, JavaScript is different. A lot of beginner guides to various programming languages make this mistake of associating a certain property with a language as if it's inherent. In this case, async code - while sold as a main fe…

Are there JS runtimes that are primarily synchronous? Certainly not any popular/widely used ones. Asynchrony is for all practical purposes a property of JS.

Maybe not, but it's irrelevant. The point I was making is that the async features are platform APIs, they have no inherent attachment to the language.

And I personally think not knowing the distinction between the language and APIs provided to it is extremely limiting and misleading for someone approaching learning programming (it was for me, I wish this had been clearer to me earlier).

Re: Callback Hell (2016)

#127

Post by Klathmon »

novaleaf wrote: post #113
lucideer wrote: post #6

> In other languages like C, Ruby or Python there is the expectation that whatever happens on line 1 will finish before the code on line 2 starts running and so on down the file. As you will learn, JavaScript is different. A lot of beginner guides to various programming languages make this mistake of associating a certain property with a language as if it's inherent. In this case, async code - while sold as a main fe…

> In other languages like C, Ruby or Python there is the expectation that whatever happens on line 1 will finish before the code on line 2 starts running actually, if you are into asynchronous programming (I am), I would claim the opposite. When writing an async program in C# you need to be acutely aware that in-between any two sequentially executed lines, entire threads of execution could have been invoked and compl…

While it's not "true multithreading", there are a lot of options for using multiple cores in JS now.

In the browser, there are web workers. When combined with the "transferrable" argument in the postMessage function [0] you can get zero-copy transfers (with the caveat that you can no longer access that variable from the process that sent it, so they are actually "transfers" not "copies" or "references"). They are not only here now, but they have pretty stellar browser support (back to IE10 and even safari 5.1).

Node had it's own thing for a while as well, and there are many libraries on top of it to make it more capable or close to the web worker spec if you want. Sadly none of them seem to fully implement the web worker spec with the transferable objects ability, but there's no reason why that can't happen.

Personally I prefer this method MUCH more than just giving you classic multithreading primitives and telling you to not shoot your eye out. Going along with what you said, it's significantly harder to get race conditions when you are either copying everything, or are actually transferring the data to someone else. It seems limiting at first, but I haven't hit anything personally that requires more than that to use 100% of the cores on a system. (the few times i've used it in production situations was setup to basically have the main thread split the data, then transfer them off to worker threads to be processed and either transferred back, or the result collected in the main thread when ready)

That being said, there is some work happening on "SharedArrayBuffers" and Atomics [1] which are the real deal "you'll shoot your eye out" shared memory. And I believe they are well into the standardization process. Personally I'm going to avoid them like the plague, but I know that there are use cases out there that can't be solved with "transferrable objects". Mozilla has an MDN page on SharedArrayBuffer at [2] which is pretty useful.

[0] https://developer.mozilla.org/en-US/docs/Web/API/Worker/post...

[1] http://tc39.github.io/ecmascript_sharedmem/shmem.html#Atomic...

[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: Callback Hell (2016)

#128

Post by cardiffspaceman »

tyingq wrote: post #107
hashkb wrote: post #99

Earlier quoted context omitted.

Are there JS runtimes that are primarily synchronous? Certainly not any popular/widely used ones. Asynchrony is for all practical purposes a property of JS.

I'm not even sure there's an implementation that could do even the most common synchronous operation. Like opening a socket, sending data, and blocking on the response.

I'm not sure if you mean implementation of JS or of something that supports executing JS. If you start with the bare interpreter and add say, global functions, through the interpreter's extension API, they CAN be synchronous. You COULD produce a JS environment this way and run scripts in it. Your extensions could include synchronous usage of sockets. Your programs in this environment would be synchronous. Writing a decent web server in that environment would be a challenge.

Re: Callback Hell (2016)

#130

Post by crudbug »

I feel this async computational burden has been passed on to the developers without any abstraction, making the life of the foundational platform developers easier.

IMO, platform IO libraries should support async behavior natively. Joe Armstrong [0] explains this beautifully.

[0] http://joearms.github.io/2013/04/02/Red-and-Green-Callbacks....

Post reply on HN