[deleted]
What color is your function? (2015)
121–130 of 198 posts
Re: What color is your function? (2015)
#122I believe I remember reading this back at the time of release. Incredible how far we've come from there
Have we? JS has its async/await syntax, and you can even handle exceptions with less pain (just uh try not to put multiple awaits in a try block). But there are still a gazillion async libraries in npm indicating things missing from the language or older libraries, and then the rest of the JS/TS ecosystem that from my perspective has only doubled down on some of its worst aspects. It looks more like regression when developing similar to how the ClojureScript guys have enjoyed things since at least 2014 seems further away now than it did then, or how it can be controversial when people like dhh push a "no build" approach.
Re: What color is your function? (2015)
#123I really don't like this article. It has a catchy, profound-sounding title that people bandy about to argue against stuff they don't like. All functions, even non-async functions, are colored. In any large system codebase you'll have functions that can only be called in certain situations, with the right setup, whatever, and if you're lucky this is communicated by types but regardless those restrictions can't be avoi…
What I like least about this article is that it's completely soured the entire context of asynchronous programming. Invariably, any time someone discusses design of an async functionality, function coloring is brought up, with almost no analysis as to how it applies and why it's a good or bad thing. (Ironically, I probably see more in-depth analysis these days as to why this article isn't apropos than why it is when…
Actually, it's not async programming. It's only async programming the way JS does it... which is unwinding the entire stack, and then starting another stack on the next tick.
Instead, many languages have fibers / coroutines / etc. which simply start new stacks elsewhere, and capture the context.
Re: What color is your function? (2015)
#124I really don't like this article. It has a catchy, profound-sounding title that people bandy about to argue against stuff they don't like. All functions, even non-async functions, are colored. In any large system codebase you'll have functions that can only be called in certain situations, with the right setup, whatever, and if you're lucky this is communicated by types but regardless those restrictions can't be avoi…
Something I have been thinking about recently is this: metaphors are often a way that authors use to make an argument in a way that is more engaging than: here is fact A, here is fact B, etc. But some metaphors are so strong that they make a stronger argument than the actual facts! And when you hear an argument with such a strong metaphor, you can often end up feeling very convinced of a particular point, even though the point itself isn't worth feeling so convicted over! I feel a very strong metaphor hijacks the emotional part of your brain before the rational part of your brain can figure out if it actually makes sense or not.
In the case of this article, the metaphor is extremely strong. Colored functions! What could be dumber! You feel like you see the world clearly after reading the article, and you pity the people who can't see the clear categorization of functions like you can! But, in reality, when has this ever annoyed me? Never! I've worked with async functions in JS/TS for over a decade and there hasn't been a single time in my entire life where I've been frustrated or backed into a corner because I wanted to call an async function from a sync one. At worst I've had to tack on "async" to a couple function declarations and be on with my day.
Re: What color is your function? (2015)
#125I really don't like this article. It has a catchy, profound-sounding title that people bandy about to argue against stuff they don't like. All functions, even non-async functions, are colored. In any large system codebase you'll have functions that can only be called in certain situations, with the right setup, whatever, and if you're lucky this is communicated by types but regardless those restrictions can't be avoi…
Yep. It's not an async vs not async thing. The way some people talk about it, you'd think the async keyword was at fault. It's all about whether a function is callable in some context. Passing in the context as an argument or making it a global variable or returning a monad doesn't do anything to uncolor the function. What's the difference between `async function f()` and `function f(eventloop, callback)`? Only synta…
Ante has some points on this issue: https://antelang.org/blog/why_effects. All of this is just different syntax in other languages and solved but the abstraction provided seems to be neater.
Re: What color is your function? (2015)
#126I really don't like this article. It has a catchy, profound-sounding title that people bandy about to argue against stuff they don't like. All functions, even non-async functions, are colored. In any large system codebase you'll have functions that can only be called in certain situations, with the right setup, whatever, and if you're lucky this is communicated by types but regardless those restrictions can't be avoi…
I agree it is a dumb article.
It made a big fuzz back then but to me it's excellent as a litmus test. Learning async grammar in Javascript takes you an afternoon, after a week it should become familiar. If someone is unable to grasp that ... well, that tells you where they stand.
Re: What color is your function? (2015)
#127I feel like this argument always boils down to explicit vs implicit. It tastes the same as static vs dynamic typing. Personally, I fall well into the explicit camp. I like when I can know stuff about a function without having to read its body, and the bodies of the functions it calls, and the bodies of the functions they call, and so on. And so, I like when I can see from the function signature that it returns an int…
No. The argument boils down into the fact that if you are not making something like Rust, coloring your functions for fine-grained performance issues is bad; if you are not making something like Haskell, coloring your functions for fine details of correctness is bad; if you are not doing something like a DBMS, coloring your objects for what code is reading it is bad; and so on.
Those are not arguments, those are assertions.
Re: What color is your function? (2015)
#128Earlier quoted context omitted.
Java's checked exceptions fit the 5 criteria: 1. It either `throws` or it doesn't 2. If the function `throws` you have to wrap it in try/catch, or make your function `throws` 3. Your function is `red` if it `throws` the same exception. 4. see (2) 5. See the FileReader class in core. Now, C++ exceptions might not satisfy all of these, but the problems CheckedExceptions were meant to solve still exist in C++ and as a r…
> Like async, the biggest problem with exceptions were the ergonomics. I know it's not a popular take, but I prefer the idea of Checked Exceptions over unchecked ones [0], and suspect current opinions would be vastly different if Java had shipped with some sweet syntactic sugar for: "If an exception that is of kind A or B or C occurs, automatically throw another checked exception X with the original exception as a ca…
The problem with checked exceptions is that they don't compose with the rest of the type system. Hence the infamous problems with things like Streams. Result types have basically all the virtues of checked exceptions without the problems.
Re: What color is your function? (2015)
#129I wish the key word was instead dontawait and was used inversely to how await is used. 99% of the time I'm using an async function, despite however slow it is, there's nothing for my code to do but wait for it to finish. But if for some reason I would like the next line of code to run before the current one is done, I'll let you know . Like, why can't my sync function await something asynchronous? If it has to lock u…
At least in JavaScript, it's nice to be able to see explicitly where you can expect the function to yield, so it's clear when race conditions can occur, or if you're calling it in a loop, whether you should consider running things in parallel. Plus, you probably don't want to lock up the whole thread if you're writing anything more than a quick script, like a web server or a GUI.
Probably more importantly, in browser JavaScript locking up the main thread means making the page unresponsive. If your script needs to make a network call, there may be nothing for it to do but wait until that call returns, but the user still needs to be able to scroll, click, etc., while that's happening.
This is why asynchronous I/O APIs became prevalent in JavaScript (initially with callbacks, with promises and then async/await syntax added later to make things nicer). Ryan Dahl then realized that this could also be used in a server-side context and would thereby solve the C10K problem, and so Node.js was initially designed with that same discipline (which was later relaxed a little with APIs like fs.readFileSync).
If Brendan Eich had realized in 1995 that this was how things were going to work, perhaps he'd have added green threads and browser events would spawn new ones (and so could block without locking up the page), but that's not the order things happened in.
Re: What color is your function? (2015)
#130I really don't like this article. It has a catchy, profound-sounding title that people bandy about to argue against stuff they don't like. All functions, even non-async functions, are colored. In any large system codebase you'll have functions that can only be called in certain situations, with the right setup, whatever, and if you're lucky this is communicated by types but regardless those restrictions can't be avoi…
Something I have been thinking about recently is this: metaphors are often a way that authors use to make an argument in a way that is more engaging than: here is fact A, here is fact B, etc. But some metaphors are so strong that they make a stronger argument than the actual facts! And when you hear an argument with such a strong metaphor, you can often end up feeling very convinced of a particular point, even though…
I do find it annoying. Let's say in JS I have `result = list.map(f)` but now `f` returns a Promise.
`result = await Promise.all(list.map(f))` is less pleasant to read. And before writing it, I have to think if I want the `f` function to execute concurrently across all entries of the list, or one at a time: `for (const elem of list) { await f2(elem) }`.
Or maybe I should use a library like `p-map` and carefully set the concurrency level. Or maybe I should create a bulk version of `f` that takes an array and is more efficient than calling `f` N times.
And don't get me started when there's `list.forEach(f)` and `f` becomes async, so now it executes concurrently for all elements, and the engineer who made the change didn't realize it.
And then there's Async Generators ...