Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Color Is Your Function?

journal.stuffwithstuff.com

Post reply on HN
Print view View original

111–120 of 153 posts

Re: What Color Is Your Function?

#111

Post by Nitramp »

rntz wrote: post #77
Nitramp wrote: post #73

Earlier quoted context omitted.

Effect Typing and Monads are yet another colour for the lipstick you put on the pig. You still have non-composability (i.e. the async monad spreads through your code), you still have the complexity, you still don't have proper tracebacks without special runtime support, and you still have the inefficiency that Bob didn't actually mention (unwinding all those stacks all the time). Languages with threads (Java, C#) don…

Go's "good, pragmatic engineering" solution to the problem - lightweight threads, channels, and the communicating sequential processes model - is built on the back of decades of academic research, including programming languages research. And now for some computer language geekery: Go solves one "code color" problem (concurrency/asynchrony), by hard-coding the solution into the language. Go programs are written in a…

Indeed, Go only solves one problem by baking it into the language/runtime, it doesn't have a generic mechanism to solve similar problems.

But my point is that it solves the problem much better than monads do - in particular if you don't just look at the syntax/user interface level, but at the non-functional aspects, like debuggability, performance, etc.

I remember a time when Aspect Oriented Programming was all the rage, with point cuts etc to capture cross-cutting aspects of your program. AOP is certainly less generic than monads, but even with rather specialized tools, it turns out the two "killer apps" of AOP were much better served by runtime support in the VM (logging/debugging) and explicit code (transactions).

I'm skeptical about the holy grail that you describe. I see how it's attractive, but in my work experience, the pragmatics of solving a particular issue often turn out to be harder (sometimes much) than the theoretical aspects.

There's certainly influence from more theoretical research in all we do in CS, but for example with Go, it's only based on Hoare's CSP model in the most abstract sense, and its implementation of lightweight threads, its stack model etc are definitely in the domain of clever engineering, not breakthrough research.

Re: What Color Is Your Function?

#112

Post by z3t4 »

Sharlin wrote: post #82
z3t4 wrote: post #21

I don't get it ... But hey, it took about six month for me to figure out how to write asynchronous JavaScript ... The key is to not use anonymous functions, it will flatten out the "Christmas tree" of callbacks. And it makes it possible to read what the code does, or at least what the programmer wants the code to do. It's much better then "then", then what, but, then, why complicate things when it's actually possible…

It helps syntactically but does nothing about the main problem: composability. Each of your functions has to know which function to call next, instead of just having one function that invokes n other functions in order. That's what next() is meant for.

For composability in JS I use small utility modules like "inOrder":

  function beforeWifeComesHome() {
    takeTheTrashOut();
    function takeTheTrashOut() {
      inOrder([openDoor, goOut, emptyTrash, goIn, closeDoor]);
    }
  }
But it would be easier to let the compiler take care of the async calls and insert callbacks automatically so that you can think synchronously while the program works asynchronously. And if you want to run stuff in parallel you should use child processes.

Re: What Color Is Your Function?

#113

Post by [deleted] »

tel wrote: post #10

We 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, except…

[deleted]

Re: What Color Is Your Function?

#114

Post by tel »

lmm wrote: post #104
tel wrote: post #101

Earlier quoted context omitted.

I'm always curious how far a sufficiently motivated masochist could go with C... I guess it's just C++ ;)

You can write very safe code by using structs (even 1-element structs) for everything. But there's no generics system and very little in the way of safe tools for making one; writing a safe "generics runtime" and macros to use it puts you halfway to writing a new language.

I would love to see even small examples of this.

Re: What Color Is Your Function?

#115

Post by [deleted] »

lmm wrote: post #104
tel wrote: post #101

Earlier quoted context omitted.

I'm always curious how far a sufficiently motivated masochist could go with C... I guess it's just C++ ;)

You can write very safe code by using structs (even 1-element structs) for everything. But there's no generics system and very little in the way of safe tools for making one; writing a safe "generics runtime" and macros to use it puts you halfway to writing a new language.

[deleted]

Re: What Color Is Your Function?

#116

Post by larard »

gfxmonk wrote: post #87

It seems like a lot of people are interested in fixing this, and would be keen to see a solution. I believe StratifiedJS is precisely that solution (for JS at least), and it has existed in working form for years: http://stratifiedjs.org/ (it's not just an experiment - it's remarkably stable). StratidiedJS completely eliminates the sync/async distinction at the syntax level, with the compiler/runtime managing continua…

Looks like exactly what this article is talking about. I have no idea why noone else has commented on it....

How does stratifiedjs work under the hood? Does it switch out the stack?

Re: What Color Is Your Function?

#118

Post by vkjv »

platz wrote: post #96
jenius wrote: post #54

So I've been writing javascript full time for a couple years at this point, client, server, and open source, and what I have adopted is coercing everything into promises, which I suppose would be the author's way of saying making everything red. If you have something that is not async mixed in with something that's async, you can still add it to the promise chain and it will resolve right away. If you have a library…

This is great for one's own projects, but if creating something for more than one's immediate project (i.e. libraries), it forces everyone else to adopt the same style. Maybe those other projects are also using other libraries that don't use promises, so now there is a problem. Do you wrap the other library in promises too, if that is even a viable option for you? Colorness is a problem for the whole ecosystem too.

I agree that colorness is a problem, but there are also fantastic libraries that handle easier conversion between most of the common styles. For example, `bluebird` promises allow you to swap between error first callbacks in both directions with `promisify` and `Promise.nodeify`.

Re: What Color Is Your Function?

#119

Post by hawleyal »

edsrzf wrote: post #59
hawleyal wrote: post #2

Seems 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 th…

> Suggestion that threads are way better than other asynchronous implementations. I don't think that's true. The author mentions several languages that use different solutions: * Java uses threads * Lua and Ruby use cooperative multitasking with coroutines and fibers, respectively * Go uses goroutines, which are coroutines multiplexed onto threads There are definitely similarities, but not all are threads. The common…

> Java, Lua, Ruby

These are all under the general term threading. You still have to pass messages or set up semaphores to use them. The code is still separated between main and sub/worker/thread.

> Go HTTP server

Every HTTP server lib handles requests in this way.

You cannot write an HTTP client, however, without explicit asynchronous code like callbacks, threads, or what have you.

Re: What Color Is Your Function?

#120

Post by munificent »

tel wrote: post #70
ufo wrote: post #61

Earlier quoted context omitted.

> It turns out that the are just a simple syntactic transform that isn't powerful enough to express everything that coroutines can. Sure, but at least with async/await you can reuse control flow structures from the original language, like for loops and try-catch. With promises you need to reimplement all of those as a library.

You can recurse and branch just fine, you just lose for/while loops.

Recursing can build up very long promise chains if you aren't careful and also just isn't a natural way for many programmers to express many kinds of code.

Even simple branching gets nasty in many cases if, for example, one branch does something async while the other does not.

You also lose try/catch.

Post reply on HN