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

121–130 of 153 posts

Re: What Color Is Your Function?

#121

Post by munificent »

kmike84 wrote: post #109

https://glyph.twistedmatrix.com/2014/02/unyielding.html is a good read - there are reasons why explicit sync-async "coloring" (i.e. await/yield) is better than green threads/coroutines which author admires.

That's a really long post, and I dimly recall reading it a while back, but after you scrape off it saying the same thing over and over again, I think it reduces down to an uncompelling argument.

It's basically, "I want context switches syntactically explicit in my code. If they aren't, reasoning about it is exponentially harder."

And I think that's pretty clearly a strawman. Everything the author claims about threaded code is true of any re-entrant code, multi-threaded or not. If your function inadvertently calls a function which calls the original function recursively, you have the exact same problem.

But, guess what, that just doesn't happen that often. Most code isn't re-entrant. Most state isn't shared.

For code that is concurrent and does interact in interesting ways, you are going to have to reason about it carefully. Smearing "yield from" all over your code doesn't solve.

In practice, you'll end up with so many "yield from" lines in your code that you're right back to "well, I guess I could context switch just about anywhere", which is the problem you were trying to avoid in the first place.

Re: What Color Is Your Function?

#122

Post by erjiang »

larard wrote: post #116
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?

It compiles down to JavaScript that you can then run on Node or the browser.

I once wrote a big long rant about the mess that JS and Node have made trying to cope with async code and got tons of comments proposing X or Y library that would "fix" the issue. Not a single person mentioned StratifiedJS. I wonder if there was some history to it that prevented it from getting momentum.[0]

[0] http://notes.ericjiang.com/posts/791

Re: What Color Is Your Function?

#123

Post by JadeNB »

Nitramp wrote: post #73
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…

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…

> Effect Typing and Monads are yet another colour for the lipstick you put on the pig.

When I started to read the essay, I thought that it would be an anti-typing screed (it's nothing to do with the author, whom I don't know!), with blue functions being untyped (or, pace Harper, unityped) and red functions being typed. An untyped function can call a typed function by ignoring the types; a typed function cannot call an untyped one, because that might violate its contract. If you buy this analogy, then your first sentence might equally well have said "typing is yet another colour for the lipstick you put on the pig"—but lightweight HM inference shows that is not so. Maybe we're just awaiting the revolutions in effect typing that languages like ML and derivatives, and Haskell, brought to typing itself?

Re: What Color Is Your Function?

#124

Post by erjiang »

dvirsky wrote: post #103

Tornado made async code slightly less painful by using yield and coroutines, but you still have to run blocking methods on thread pools using futures. They abstracted it really nicely and I can now write clean code if I need an occasional blocking library in my tornado code. But after writing tons of Go over the past 2-3 years, going back to async code, even with the tornado sugar, just feels like driving a manual ca…

Really, any language that has threading gives you the easy concurrency that you want. Now, if you limit your choices to "concurrency, but not with OS threads", then your pool is a lot smaller.

I think Clojure (core.async), Haskell (GHC), and Rust would also give you what you're looking for.

Re: What Color Is Your Function?

#125

Post by rntz »

JadeNB wrote: post #123
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…

> Effect Typing and Monads are yet another colour for the lipstick you put on the pig. When I started to read the essay, I thought that it would be an anti-typing screed (it's nothing to do with the author, whom I don't know!), with blue functions being untyped (or, pace Harper, unityped) and red functions being typed. An untyped function can call a typed function by ignoring the types; a typed function cannot call a…

Actually, you can call both ways - from statically typed to dynamically typed and back. This is the premise of the work done in Racket on contracts, and more generally of the "gradual typing" movement. Harper's "unityped" term suggests exactly how this can work. An untyped function takes arguments that are all of one type, and returns one of the same type (that type being the "dynamic" type that includes every possible value, and thus is useless for static checking).

To call an untyped function from typed code, simply cast all your arguments to this type (trivial, since it contains anything), and check its return value has the type you expect (throwing an error if it's of the wrong type). To call a statically typed function from untyped code, simply check the types of all the arguments you wish to pass to it (throwing an error if they don't match its signature), and cast the returned value to the dynamic type (again, trivial).

I'm glossing over a very important difficulty, which is that you can't dynamically check something of a function type -- if I'm handed a function, how do I know at runtime whether it's of type `int -> int`? I can't! So the solution is to "wrap" this function with a contract that delays checking until the function is actually called, at which point you can check the argument is an `int` and the result is an `int`.

Re: What Color Is Your Function?

#126

Post by tel »

munificent wrote: post #120
tel wrote: post #70

Earlier quoted context omitted.

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.

Yeah, agreed. It's functional, but technically weak.

This might be a place to introduce functional pipelines like Haskell's Pipes, Machines, Conduits. They solve the effectfull iteration and streaming problem, but the mechanism is heavily transformer based.

Re: What Color Is Your Function?

#127

Post by tel »

rntz wrote: post #125
JadeNB wrote: post #123

Earlier quoted context omitted.

> Effect Typing and Monads are yet another colour for the lipstick you put on the pig. When I started to read the essay, I thought that it would be an anti-typing screed (it's nothing to do with the author, whom I don't know!), with blue functions being untyped (or, pace Harper, unityped) and red functions being typed. An untyped function can call a typed function by ignoring the types; a typed function cannot call a…

Actually, you can call both ways - from statically typed to dynamically typed and back. This is the premise of the work done in Racket on contracts, and more generally of the "gradual typing" movement. Harper's "unityped" term suggests exactly how this can work. An untyped function takes arguments that are all of one type, and returns one of the same type (that type being the "dynamic" type that includes every possib…

Total agreement generally, but I wanted to mention that the Any -> X downcasting is trouble sometimes. It is difficult to do this in a type-safe way (e.g. without accidentally introducing holes) and if you have typecasing universally then you lose parametricity, one of the most powerful tools in any polymorphic type theory.

Re: What Color Is Your Function?

#128

Post by afri »

erjiang wrote: post #122
larard wrote: post #116

Earlier quoted context omitted.

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?

It compiles down to JavaScript that you can then run on Node or the browser. I once wrote a big long rant about the mess that JS and Node have made trying to cope with async code and got tons of comments proposing X or Y library that would "fix" the issue. Not a single person mentioned StratifiedJS. I wonder if there was some history to it that prevented it from getting momentum.[0] [0] http://notes.ericjiang.com/pos…

I think there are a couple of problems:

1 - SJS effectively 'solves' the concurrency problem, but it is not a problem that is on the top of most people's mind when they write an application. To a first approximation, the concurrency problem in JS looks "solved" to people already (promises, generators, etc), and it is only when you get down to it and look at it in detail you see that SJS is actually a substantially more complete solution to the problem.

2 - Many people see it as a 'cute' solution that doesn't scale to big applications. To counter that point we've developed a complete SJS client/server framework - https://conductance.io - and are writing big complicated apps on it (such as http://magic-angle.com/ ). It's still rough around the edges, but we're pretty confident that the upcoming release (scheduled for end March) will show just how powerful the SJS paradigm is. There is a presentation on it here: http://www.infoq.com/presentations/real-time-app-stratified-...

Disclaimer: I work on SJS!

Re: What Color Is Your Function?

#129

Post by Roboprog »

otakucode wrote: post #25
munificent wrote: post #20

Earlier quoted context omitted.

Thank you! I know the reader's time is precious so I try to cram as much entertainment and information in there as I can.

Spidermouth the Night Clown will stay with me for years.

Positively "Stross-ian" :-)

(see the exploits of a certain fictional Bob Howard, former programmer)

Re: What Color Is Your Function?

#130

Post by Roboprog »

Funny. I thought he was talking about Java 8 for a while. We (eventually, when the rest of the stack catches up) get functors / lambdas, but:

* red = instance methods.

* blue = static methods, which cannot call an instance method.

Post reply on HN