Live data from Hacker News

Callbacks as our Generation's Goto Statement

tirania.org

191–200 of 287 posts

Re: Callbacks as our Generation's Goto Statement

#191
You can write any article like this about anything, here is the formula:

- pick a language feature

- write an article with the title " as our Generation's Goto Statement"

- write an example where you misuse and over generalize it

- show a workaround that doesn't really save the trouble of actually thinking before typing

The hard thing about callbacks is that you need to think about asynchronous processes which can be hard, the callbacks are not the problem so replacing them with something else won't help you too much.

Re: Callbacks as our Generation's Goto Statement

#192
callbacks are like goto in that you can create terrible code by using them badly, but also they are vital to implementing good code. if, for, while and co are all syntactic sugar for correct and standardised use of goto with hints to help the compiler make optimisation.

in both cases though we don't something universally evil or bad - just something that bad programmers can and will abuse.

Re: Callbacks as our Generation's Goto Statement

#193

Earlier quoted context omitted.

Aren't you still American? ;) As an Indian I am confused why only people of the US are called Amerians while two entire continents are called America. And also, why we Indians are not considered Asians by the said Americans.

Because "America" is part of the nation's actual name, and the only part that isn't a modifier. What else could you call Americans? Unionized Statists?

Time for bed. "Un-ionized? What is this person trying to say?"

Re: Callbacks as our Generation's Goto Statement

#194

shenanigans. Pyramids (at least in js) can be easily avoided by simply naming your functions. Treating them like the first class objects they are. Naming the function means you are no longer going to an arbitrary code block, but instead going to a concept whose name, doc string, and (through hoisting) position on the page illuminate its purpose. Callbacks aren't bad. Pyramids are bad. Stop writing pyramids. Nodejs al…

I disagree. Callback based programming forces you to modularize around asychronous/IO calls instead of semantic cohesion.

Naming functions doesn't solve that problem. On the contrary, you get seperate lexical units that are not separately reusable and make no sense on their own. They are simply fragments of code that's supposed to be executed before or after some IO operation inside another function.

Re: Callbacks as our Generation's Goto Statement

#195

"Await" is fantastic, and having using it for JavaScript (via TameJS and then IcedCoffeeScript), it makes things a lot easier and clearer. That being said, I don't think the comparison between callbacks and goto is valid. "Goto" allows you to create horrible spaghetti-code programs, and getting rid of it forces you to structure your programs better. "Await", fundamentally, isn't really anything more than syntactic su…

What this suggests is that "await" isn't like all structured programming, it's like one control construct. The history of structured programming is the development of more constructs as people realised that they had a goto pattern that kept popping up in their code, so they named it and thereby got a cognitively-higher-level program. Long after Dijkstra's essay, we could still occasionally find new places where goto…

Another example: a lot of old code bases use "goto" for error handling. I'm assuming the Linux kernel still does this. Now we've formalized that behavior into exceptions.

Re: Callbacks as our Generation's Goto Statement

#196

"Await" is fantastic, and having using it for JavaScript (via TameJS and then IcedCoffeeScript), it makes things a lot easier and clearer. That being said, I don't think the comparison between callbacks and goto is valid. "Goto" allows you to create horrible spaghetti-code programs, and getting rid of it forces you to structure your programs better. "Await", fundamentally, isn't really anything more than syntactic su…

for/while are themselves syntactic sugar around goto. You can in fact write them as macros or even functions (using setjmp/longjmp) in C. However, the abstraction in that case will leak - you'll need to put your label manually where the loop needs to go, you'll still need to know you're using goto and how it works and you'll need to keep in mind the exact code that's generated by the macro, or you will get bit by it. Structured looping constructs also don't change the flow in your program and even force another level of indentation, but they allow you to think about it using higher-level building blocks being sure that those blocks always work properly, i.e. they won't break because you have a typo in some conceptually far away line.

Callbacks really are just like goto. I've seen really awful callback code where you have callbacks that create other callbacks which are passed to callback managers which are themselves finite state automatons and call one of the callbacks based on a return value from another. It's the most horrifying spaghetti code you can think of. It's practically fractal - spaghetti within spaghetti that influence the top layer in an untraceable manner.

While everyone can write spaghetti in any language, few can write good code when given just goto or just lambda. In some cases it's even impossible.

Re: Callbacks as our Generation's Goto Statement

#198
post #164

I'm not buying the c# async/await kool-aid. Async, sure, I'm down with that, but I've used the c# async stuff now, and while it makes it the app somewhat faster, it has three major downsides (that I encountered): - Infects everything; suddenly your whole application has to be async. - Debugging becomes a massive headache, because you end up in weird situations where the request has completed before some async operati…

But doing things by hand with callbacks is going to have all of those same issues isnt it? If you dont want to infect everything then you basically need to just write synchronous code instead...

The issue I see is that with some libraries you either go 100% async or 100% sync with no middle ground.

Re: Callbacks as our Generation's Goto Statement

#199

Earlier quoted context omitted.

What this suggests is that "await" isn't like all structured programming, it's like one control construct. The history of structured programming is the development of more constructs as people realised that they had a goto pattern that kept popping up in their code, so they named it and thereby got a cognitively-higher-level program. Long after Dijkstra's essay, we could still occasionally find new places where goto…

Another example: a lot of old code bases use "goto" for error handling. I'm assuming the Linux kernel still does this. Now we've formalized that behavior into exceptions.

You need C++'s RAII idiom or go's defer syntax to get the same behaviour though. I think try-with-resource in Java also would do the same thing, maybe. Just plainly throwing an exception won't release what you've acquired.

Re: Callbacks as our Generation's Goto Statement

#200

"Await" is fantastic, and having using it for JavaScript (via TameJS and then IcedCoffeeScript), it makes things a lot easier and clearer. That being said, I don't think the comparison between callbacks and goto is valid. "Goto" allows you to create horrible spaghetti-code programs, and getting rid of it forces you to structure your programs better. "Await", fundamentally, isn't really anything more than syntactic su…

I was initially very skeptical at first too. Then I noticed that the positioning of the "Busy = false" statements had been reduced to a structured form exactly as if we had started with an unstructured GOTO or multiple exit point control flow. As a C++ guy, I don't like his "Busy = false" system to begin with. It would seem much better (to me) if he used a non-copyable object to represent the outstanding activity. Su…

I'm sure Busy isn't meant to represent state—it's a property whose setter and getter call a spinning wheel UI element's StartAnimating and StopAnimating. It's a very common practice in iOS view controllers. That's what I read anyway.
Post reply on HN