What Color Is Your Function?
journal.stuffwithstuff.com
What Color Is Your Function?
1–10 of 153 posts
Re: What Color Is Your Function?
#2Seems like there are couple things going on here. Accusation that asynchronous implementations in all languages are problematic, with which I don't think anyone would disagree. Suggestion that threads are way better than other asynchronous implementations. I don't agree that makes things better or somehow different. You still have disjointed code. I would add this as a third to Fowler's famous quote about two hard things (cache invalidation and naming things).
Re: What Color Is Your Function?
#3I had no clue this was about async functions. I assumed it was safe/unsafe functions until I got to the part about it not being. I think that is a much stronger issue than sync/async.
Re: What Color Is Your Function?
#4I had no clue this was about async functions. I assumed it was safe/unsafe functions until I got to the part about it not being. I think that is a much stronger issue than sync/async.
I was convinced it was going to be about pure vs impure (monadic) code, but then he just picked out one particular monad instance (coroutines/asynchronous operations).
Any time you have side effects, you potentially have "red" code, in that it can add arbitrary restrictions on how you must use the functions.
Re: What Color Is Your Function?
#5I had no clue this was about async functions. I assumed it was safe/unsafe functions until I got to the part about it not being. I think that is a much stronger issue than sync/async.
These kind of distinctions happen all the time. The classic http://www.joelonsoftware.com/articles/Wrong.html - one colour for html-encoded strings, one colour for plain strings. Functions that might fail with an error or functions that never fail. Logging versus non-logging. Database-accessing or not. Callable from user scripts or not.
Keeping track of colour - in a way where correctness is guaranteed by the computer - is such a useful general feature that any serious modern programming language should support it. We should have easy, simple syntax for specifying colour, and should make polychromatic functions almost as easy as monochromatic ones.
When you do that - when the red of "async" is just one colour among a whole rainbow that your program is already tracking - then the cost of making an explicit distinction between async and not is minimal, and the benefits - being able to track, control, and see instantly whether a function is async or not - are more than worth it.
Re: What Color Is Your Function?
#6[1] is a nice read regarding continuations (and the Cont monad), though a bit more advanced.
[1] http://blog.sigfpe.com/2008/12/mother-of-all-monads.html
Re: What Color Is Your Function?
#7[deleted]
Re: What Color Is Your Function?
#8I had no clue this was about async functions. I assumed it was safe/unsafe functions until I got to the part about it not being. I think that is a much stronger issue than sync/async.
[deleted]
Re: What Color Is Your Function?
#9For those that haven't noticed this article is by the chap who wrote the absolutely wonderful http://gameprogrammingpatterns.com/
Re: What Color Is Your Function?
#10We can massively generalize this by calling "blue" "pure" and "red" "impure". The end result is essentially Haskell (but you can take it much further, too!).
---
There's something horrifyingly restrictive about having merely (blue -> pure, red -> impure), though. All "blue" functions behave roughly the same (e.g., very, very nicely and compositionally) but "red" functions come in many classes: async, stateful, exception-throwing, non-deterministic, CPS'd, IO-effectful, combinations of the prior.
What we want is a nice way of representing different kinds of red functions and how they all interact.
What we'd also like is a nice way of composing different kinds of red functions so that the bundled piece has a sensible kind of redness too and we can keep composing.
And this is exactly monads and monad transformers.
There are other ways to achieve this end as well all under the general name "Effect Typing". Very cool stuff.
But what I'd like to emphasize is that Java/C#/Go have not solved this larger problem. They each introduce a fixed number of "rednesses" and very specific ways that different kinds of red can be connected together. Monads are a generalizable solution.
The situation is exactly the same as HOFs themselves. We've had subroutines and functions for a long time, but first-order and higher-order functions are a marked increase in power since you can now refer to these "function things" directly.
Monads take the notion of "CPS Transform" and allow you to refer to it directly, to mark sections of code which use it and compose them intelligently. They allow you to invent your own kinds of redness on the fly and ensure that your custom colorations compose just as nicely as the built-in ones.
If this article is even slightly interesting then you owe it to yourself to learn much more about effect typing. It'll change your world.
(That and sum types, because nobody is served by a bunch of integers named Token.LEFT_BRACKET.)