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

131–140 of 170 posts

Re: Callback Hell (2016)

#131

Post by tyingq »

cardiffspaceman wrote: post #128
tyingq wrote: post #107

Earlier quoted context omitted.

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 d…

We're saying the same thing. The nature of the environment is slanted to async, thus, commonly available runtimes don't have much functionality that is synchronous.

You can find some of it, but it's the exception, not the rule.

Yes, you can build something specific, just as you can leverage async libraries in languages where it's not the common pattern.

Re: Callback Hell (2016)

#132

Post by jimbokun »

spcoder wrote: post #79

I think this is a fantastic article in many ways. It clearly describes the issues of callback hell and gives simple examples on how to clean it up. Modern JavaScript has gotten very complicated lately because it's so flexible. Many people are developing interesting frameworks to solve niche problems; however, it feels like many of these solutions are overly complicated outside the niche. Yet, developers are adopting…

"I've been a programmer for 18 years now, and I am convinced that simple proven solutions are the way to go."

I would rephrase this slightly to "simple proven solutions that solve the immediate problem at hand, and nothing else."

Bringing in lots of extraneous dependencies, or DSLs offering functionality way beyond whats actually needed for the immediate problem at hand, can quickly lead to code that is very hard to understand, maintain, and debug.

Re: Callback Hell (2016)

#135

Post by Normal_gaussian »

crudbug wrote: post #130

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

> I don't know how you would write this in Javascript. I've written quite a lot of jQuery and know how to setup and remove callbacks. But what happens if an event is triggered in the time interval between removing an event handler and adding a new one. I have no idea, and life is too short to find out.

If you are manipulating inside a single function call it is atomic, JS is single threaded and doesn't interrupt functions.

Re: Callback Hell (2016)

#136

Post by tyingq »

lucideer wrote: post #123
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.

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

>Maybe not, but it's irrelevant

I'm not sure it is. What's available, without custom work on your own, drives the ecosystem.

I can build an asynchronous application with PHP, but there's not much established practice, existing tools, shared learning and so forth. And, whatever I build that way is limited to an audience that will go out of their way to build my custom php interpreter.

Re: Callback Hell (2016)

#137

Post by dllthomas »

zump wrote: post #29

As a C programmer working with a large codebase, I have come to HATE callbacks. Seriously, the worst feeling ever is tracing through a huge function tree, only to run into function pointer dereference. Then you have to go on a wild goose chase to find out when, where and what it will be assigned to. STATIC TYPES PEOPLE.

> STATIC TYPES PEOPLE.

What you are asking for is much more closely related to static dispatch than static typing.

Re: Callback Hell (2016)

#138

Post by alanbernstein »

Callback hell has confused me for a long time. I kept assuming there was a good reason people write code that way, and there was something wrong with naming my functions and passing them by name. The latter approach always made more sense to me - it's more readable, and more intuitive.

If there is no real benefit to the nested anonymous function style, why do people do it that way? It would never even have occurred to me to write code like that if I didn't see it in javascript all over the place.

Re: Callback Hell (2016)

#139

Post by minitech »

dpweb wrote: post #49

The 'asynchonous problem' in JS is twofold. It makes it more difficult to reason about the program, and is hell on readability, and readbility matters. Support, maintenance, etc. The lack of an ability to structure async ops in a simple way is the biggest drawback in the language. Callbacks of course have the drawbacks mentioned. Sure, you can separate the functions, smaller functions and that too is preferred, but s…

Promises did solve the problem; async/await is just syntactic sugar for them. The important thing is being able to start a task and pass around its value on completion without worrying whether that completion has happened yet. If you didn’t see an advantage to promises, you might have just been using them like callbacks.
Post reply on HN