Live data from Hacker News

Callback Hell (2016)

callbackhell.com

1–10 of 170 posts

Re: Callback Hell (2016)

#5
post #4
post #3

Last updated in 2012. A lot has changed since.

Could you elaborate? Coming from Lua I always found the nesting of anonymous functions messy and wondered why they weren't done as in the article.

Promises and, more recently, Observables.

Simply put: A promise resolves to a single value asynchronously, an observable resolves to (or emits) multiple values asynchronously (over time).

Taken from here: http://stackoverflow.com/questions/36064303/what-are-the-dif...

Re: Callback Hell (2016)

#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 feature of the NodeJS platform - is in no way exclusive to, or even an inherent part of, Javascript/ES the language.

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).

Another common example was, up until recently, that Javascript "wasn't powerful enough" to do filesystem access, hardware operations, etc. A simple side-effect of the environment the language was most commonly executing in (the browser) was turned into an inherent limitation of the language in order to "simplify things for beginners".

While bombarding beginners with a lot of info at the start is a bad idea, these kind of misconceptions can be very damaging. They leads to a very narrow idea of what's possible with (any) languages in general, and uninformed decisions on what to learn as a result.

Re: Callback Hell (2016)

#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.

Re: Callback Hell (2016)

#9

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.

Openresty does this quite nicely with Lua: you just write your code as normal and it handles the rest in the background. http://leafo.net/posts/itchio-and-coroutines.html

Re: Callback Hell (2016)

#10

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.

>people still kind of want to write code that does one thing after another, then another, then another.

For the most part - yes. And not because they want it but because there is no other way. You usually need to do something before you do that next thing anyway.

Post reply on HN