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

41–50 of 170 posts

Re: Callback Hell (2016)

#41

Post by zump »

pwdisswordfish wrote: post #33
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.

What does it have to do with static typing? Function pointers are perfectly valid types. Also, can't you just use a debugger?

Not really in a custom ASIC in an embedded environment.

Re: Callback Hell (2016)

#43

Post by tluyben2 »

insertnickname wrote: post #11
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.

That's how it's done in Go. You write plain, "blocking" code, and if it blocks, the Go runtime will just schedule another goroutine (green thread). In Go there's no need for callbacks or littering your code with `await` keywords to write concurrent software.

I never checked that out but ; https://www.golang-book.com/books/intro/10 looks messy to me. Less messy than callbacks but more messy than async/await imho. Maybe there are nicer examples?

Also I agree with the coroutine LUA rationale you can read in the link in this same thread. It appears that with Go I still need to alter my own code to use libraries that are written to run async or am I wrong?

Re: Callback Hell (2016)

#44

Post by thedjinn »

After working with React Native for a while now I really began to appreciate the usefulness of async/await. By expressing asynchronous operations in a more linear fashion it becomes much easier to reason about them.

Re: Callback Hell (2016)

#47

Post by meowpants »

williamdclt wrote: post #13

Lot of blabbling for a simple concept: do not abuse nesting. It's the case with control statements, it's still the case with functions, and even more with async functions. Oh, and callbacks definitely exist in other languages, like C. What's the deal with this trend of setting up a whole website for a (basic) blog post?

Don't be hatin'. It's a useful read for many.

"Simple concept" is subjective. I'd bet that discussing "simple concepts" with an engineer or scientist would likely cause your mind to grasp and instinctively try to relate to your own memorization of facts. But that shouldn't preclude you from discussing what you do know, or for that matter, sharing it with the world.

Re: Callback Hell (2016)

#48

Post by wildpeaks »

As much as I enjoy async/await, the filesize penalty once Babel-ified can bloat up your bundles; better stick to Promises-only for now, even if it's slightly more verbose.

However they can already be used in Node with the "--harmony-async-await" flag (and without flag in the upcoming Node 8).

Re: Callback Hell (2016)

#49

Post by dpweb »

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 still you get code that can be difficult to reason about and read.

Promises, for all the hype, in my view clearly did not help matters much. Promise code can be as weird looking or worse than callback code. Promises did not solve the problem.

Async/await IS the solution. I've started converting callback and promise code to it. It's a great new enhancement.

Re: Callback Hell (2016)

#50

Post by realharo »

camus2 wrote: post #37
realharo wrote: post #27

Earlier quoted context omitted.

Yeah, I messed it up when quickly typing the code without thinking, it should've been JSON.parse, I fixed it now. Also regarding that article: you can call async functions from non-async functions - you will simply get the Promise object instead of the data. If you're using TypeScript, your editor will immediately highlight the error if you try to use that Promise object as though it were the data, so zero chance of…

> Also regarding that article: you can call async functions from non-async functions - you will simply get the Promise object instead of the data. async function() getZ(){ return promise } function() getX(){ return x = y * getZ() } // sync call globally. let x = getX(); // NaN async/await makes things more readable, it doesn't change the issue of leaky abstraction and you need to know whether the call is blocking or…

That's kind of exactly what the second half of my comment was about - if you have static typing, then this problem just doesn't exist.

If not, then the problem is really no different from not knowing what your functions are returning (are they returing a Promise object? are they returning the data itself?). Not knowing the return type of the functions you use is hardly something new. You would have the exact same issue with functions that take callbacks.

See the link I sent there https://goo.gl/vDk3Gz - you can hover over all the variables and functions (once the editor fully loads), try typing "n.", hover over the highlighted errors, etc. The tooling takes care of everything.

Post reply on HN