5 ms·

If you're not, here's the link [0]. It's a pretty influential post, it's introduced whole new terminology of "colored functions" into tech jargon that's startin

by OskarS 6y ago

If you're not, here's the link [0]. It's a pretty influential post, it's introduced whole new terminology of "colored functions" into tech jargon that's starting to become reasonably commonly used. You should familiarize yourself with it if you haven't already. The point the original post is making is that in languages that support asynchrony using callbacks, promises or async/await, they've split the language in two: the "synchronous" and "asynchronous" parts, and reconciling them is a pain. The only languages which avoids this split comfortably are Go and a few other more niche ones (notably BEAM languages like Erlang and Elixir). This post makes the counter-argument that it's actually a good thing that functions are "colored" differently, as synchronous and asynchronous functions have different execution models, and that should be reflected in the language. [0]: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

quelltext 6y ago
Sorry, I feel bad that you had to write this. It's of course on me to learn about the linked concepts if I want to follow the post. I was just put off from doing so because of the author's assumption that everyone in tech is on the same page when this isn't necessarily the case. Many or even most folks "in tech" give little thought to PL design, at least not in the way that would have them read that article, though influential it might have been to some folks in tech that are into these discussions 6 years ago.
- rocqua 6y ago
  You should not at all feel bad! This way, others in a similar situation to you get to benefit from GP's explanation. Moreover, GP got to interact with others on this concept. I'd also wager it took less effort for GP to write this, and then for you to read it, than it would have taken you to do all of it yourself. Point being, your question led to a very useful answer, and you should be proud, not sorry.
  - TeMPOraL 6y ago
    I for once read that article twice already (once a few years ago, second time today), and I still gained by reading GGP's comment - reading someone else's summary of a topic is a way of quickly validating your own understanding.
- OskarS 6y ago
  Yeah, don't worry about it. People learn new things all the time, I didn't mind writing the comment :)
- booleandilemma 6y ago
  Don't feel bad, only in tech do we start using a whole new terminology from some random dude's blog post.
- cesarb 6y ago
  As xkcd explains, you are one of the 10000: https://xkcd.com/1053/ https://xkcd.com/1053/ so you shouldn't feel bad about it.
wccrawford 6y ago
I sincerely hope people don't start using just one of the color names at a time. If someone says to me, "That's a red function" I'm going to stop them every single time and ask them which one was red again. It's much clearer and just as easy to say "that's an async function". I think the post was great for making people think about this in an abstract way, but I don't think it was meant to reach beyond that mental exercise.
- ehnto 6y ago
  So abstract that it took a few paragraphs for me to realize they were talking about a problem I'm intimately familiar with, and already have a pretty decent lexicon for.
  - simiones 6y ago
    Is there an alternative word/concept to "function color" that covers not just sync/async, but also (C++-style) const/non-const functions for example?
  - munificent 6y ago
    Yes, that was a deliberate rhetorical trick. It's works for some audiences, but obviously not all of them. At the time I wrote the original article there were a lot of people really excited about the performance of async IO in Node (and JS in general) and were implicitly accepting the async programming style that went along with it. They liked the former so much that it muddled their perspective on the latter. Sort of like how when you go to a shitty diner after an amazing concert and recall the meal as amazing when really it's just because it got wrapped up in the emotional experience of the entire evening. I had many many discussions of people where I tried to talk about how the async programming model is really cumbersome and their response was "but it makes the app go faster!" We were talking at totally different levels. It can be really hard to get people to have a clear perspective on something they have an emotional attachment to. By making up a fake language and a made-up concept of function color, it let me show them "hey here's this thing that kind of sucks" without triggering their "but I love async IO in Node!" response. I had no idea the article would catch on like it did. Something I find interesting about it in retrospect is that because it is kind of strange and abstract, readers take very different things away from it while assuming their interpretation is exactly the one I had in mind. Some folks (like the author here) think it's about effects and static types (even though there is nothing about types at all in the article). Some think it's a love letter to Go (a language I'm not particularly enthused about in general). Really, I just wanted to talk about the unpleasant user experience of a certain programming style without getting hung up on what underlying behavior the style is attached to.
GrumpyNl 6y ago
So we gonna replace sync and async with colors, whats next?
- zwaps 6y ago
  Texture, smell, taste? Why not? This function is a here is a rough function, this function there is smooth. This function yonder is damp, that one is dry. Careful, you are dealing with a sour function! Wait, let me open up my blog
- simias 6y ago
  I think the idea is to make the concept more general (it's not about blocking/async, it's about adding an additional concept into the language) but then the article is specifically about sync/async so I agree that it's just confusing.
- mseepgood 6y ago
  Each function gets a spin, charge and mass.
deleted 6y ago
[deleted]
kaba0 6y ago
Just a note, Java will also avoid function coloring very soon with Project Loom.
- _old_dude_ 6y ago
  for sync vs async, yes ! but Java still have checked exceptions which is also a form of coloring.
  - kaba0 6y ago
    Yeah, you are right! Though I think not every function coloring is necessarily bad and while Java’s implementation of checked exceptions have some edge cases, I think the idea itself is sound and it’s better to have it supported at a language level instead of recreating it with some meta-language in terms of Maybe/Result types, that loose extra-linguistic information like stack traces (yeah I’m sure they can be included, but that should be the default working).
    - _old_dude_ 6y ago
      You can have exceptions like in Erlang, OCaml, C#, Kotlin which all keep the stacktrace without having checked exceptions. If you take a look to the history of Java, checked exceptions was there since the beginning but were weaken several times, first by the introduction of generics+inference (a type parameter can not represent an union of exceptions) then by the introduction of lambdas, the type of a lambda (the function interfaces in Java lingo) used by the standard lib, do not declare checked exceptions. It's so bad that IOException, the king of checked exception, has two unchecked dual defined by default, UncheckedIOException and IOError that are raised randomly by the new APIs like java.nio.file.Files that do not want to deal with the complexity of checked exceptions. Java has a checked exception problem but it does not want to recognize it. BTW, there is another coloring in Java which is primitive vs object, but at least this one is recognized as an issue (see OpenJDK project Valhalla).
  - deleted 6y ago
    [deleted]
- 6y ago
rvanmil 6y ago
Thank you for the clear and concise explanation. That blog post was incredibly annoying to read and imo utterly fails to address an otherwise interesting point.

by OskarS 6y ago

quelltext 6y ago

Sorry, I feel bad that you had to write this. It's of course on me to learn about the linked concepts if I want to follow the post. I was just put off from doing so because of the author's assumption that everyone in tech is on the same page when this isn't necessarily the case. Many or even most folks "in tech" give little thought to PL design, at least not in the way that would have them read that article, though influential it might have been to some folks in tech that are into these discussions 6 years ago.

rocqua 6y ago
You should not at all feel bad! This way, others in a similar situation to you get to benefit from GP's explanation. Moreover, GP got to interact with others on this concept. I'd also wager it took less effort for GP to write this, and then for you to read it, than it would have taken you to do all of it yourself. Point being, your question led to a very useful answer, and you should be proud, not sorry.
- TeMPOraL 6y ago
  I for once read that article twice already (once a few years ago, second time today), and I still gained by reading GGP's comment - reading someone else's summary of a topic is a way of quickly validating your own understanding.
OskarS 6y ago
Yeah, don't worry about it. People learn new things all the time, I didn't mind writing the comment :)
booleandilemma 6y ago
Don't feel bad, only in tech do we start using a whole new terminology from some random dude's blog post.
cesarb 6y ago
As xkcd explains, you are one of the 10000: https://xkcd.com/1053/ https://xkcd.com/1053/ so you shouldn't feel bad about it.

wccrawford 6y ago

I sincerely hope people don't start using just one of the color names at a time. If someone says to me, "That's a red function" I'm going to stop them every single time and ask them which one was red again. It's much clearer and just as easy to say "that's an async function". I think the post was great for making people think about this in an abstract way, but I don't think it was meant to reach beyond that mental exercise.

ehnto 6y ago
So abstract that it took a few paragraphs for me to realize they were talking about a problem I'm intimately familiar with, and already have a pretty decent lexicon for.
- simiones 6y ago
  Is there an alternative word/concept to "function color" that covers not just sync/async, but also (C++-style) const/non-const functions for example?
- munificent 6y ago
  Yes, that was a deliberate rhetorical trick. It's works for some audiences, but obviously not all of them. At the time I wrote the original article there were a lot of people really excited about the performance of async IO in Node (and JS in general) and were implicitly accepting the async programming style that went along with it. They liked the former so much that it muddled their perspective on the latter. Sort of like how when you go to a shitty diner after an amazing concert and recall the meal as amazing when really it's just because it got wrapped up in the emotional experience of the entire evening. I had many many discussions of people where I tried to talk about how the async programming model is really cumbersome and their response was "but it makes the app go faster!" We were talking at totally different levels. It can be really hard to get people to have a clear perspective on something they have an emotional attachment to. By making up a fake language and a made-up concept of function color, it let me show them "hey here's this thing that kind of sucks" without triggering their "but I love async IO in Node!" response. I had no idea the article would catch on like it did. Something I find interesting about it in retrospect is that because it is kind of strange and abstract, readers take very different things away from it while assuming their interpretation is exactly the one I had in mind. Some folks (like the author here) think it's about effects and static types (even though there is nothing about types at all in the article). Some think it's a love letter to Go (a language I'm not particularly enthused about in general). Really, I just wanted to talk about the unpleasant user experience of a certain programming style without getting hung up on what underlying behavior the style is attached to.

GrumpyNl 6y ago

So we gonna replace sync and async with colors, whats next?

zwaps 6y ago
Texture, smell, taste? Why not? This function is a here is a rough function, this function there is smooth. This function yonder is damp, that one is dry. Careful, you are dealing with a sour function! Wait, let me open up my blog
simias 6y ago
I think the idea is to make the concept more general (it's not about blocking/async, it's about adding an additional concept into the language) but then the article is specifically about sync/async so I agree that it's just confusing.
mseepgood 6y ago
Each function gets a spin, charge and mass.

deleted 6y ago

[deleted]

kaba0 6y ago

Just a note, Java will also avoid function coloring very soon with Project Loom.

_old_dude_ 6y ago
for sync vs async, yes ! but Java still have checked exceptions which is also a form of coloring.
- kaba0 6y ago
  Yeah, you are right! Though I think not every function coloring is necessarily bad and while Java’s implementation of checked exceptions have some edge cases, I think the idea itself is sound and it’s better to have it supported at a language level instead of recreating it with some meta-language in terms of Maybe/Result types, that loose extra-linguistic information like stack traces (yeah I’m sure they can be included, but that should be the default working).
  - _old_dude_ 6y ago
    You can have exceptions like in Erlang, OCaml, C#, Kotlin which all keep the stacktrace without having checked exceptions. If you take a look to the history of Java, checked exceptions was there since the beginning but were weaken several times, first by the introduction of generics+inference (a type parameter can not represent an union of exceptions) then by the introduction of lambdas, the type of a lambda (the function interfaces in Java lingo) used by the standard lib, do not declare checked exceptions. It's so bad that IOException, the king of checked exception, has two unchecked dual defined by default, UncheckedIOException and IOError that are raised randomly by the new APIs like java.nio.file.Files that do not want to deal with the complexity of checked exceptions. Java has a checked exception problem but it does not want to recognize it. BTW, there is another coloring in Java which is primitive vs object, but at least this one is recognized as an issue (see OpenJDK project Valhalla).
- deleted 6y ago
  [deleted]
6y ago

rvanmil 6y ago

Thank you for the clear and concise explanation. That blog post was incredibly annoying to read and imo utterly fails to address an otherwise interesting point.