101–110 of 153 posts
Earlier quoted context omitted.
I'm not sure if you're leading this or not, but to be clear... this is exactly a type system. (Edit: read your blog; it's clear you're leading it. Poe's Law is in effect sometimes here, sorry 'bout that!)
It's a good type system. Many programming languages don't support this kind of type information, notably C.
A lot of commentors are mentioning that this is just a specific case of effect typing. Haskell and monads have been brought up as an example of effects typing, but I'd like to present another example that more closely resemble familiar static type systems. Nim[1], at least at one point (I'm looking at the current manual and can't find it documented), had support for tagging functions with a pragma and the compiler wo…
Also, what about Koka ? http://koka.codeplex.com/ and http://research.microsoft.com/en-us/projects/koka/ From the latter: > The Koka project tries to see if effect inference can be used on larger scale programming. The language is strict (as in ML), but seperates pure values from side effecting computations (as in Haskell). Through the effect types, there is also a strong connection to its denotational semantics, whe…
Have you looked at Frank [0] by any chance? It has a very similar row-effect type (I guess these were both first explored in Eff?) but in a CBPV language which makes it clear how pure values are separated from effectful computation.
[0] http://homepages.inf.ed.ac.uk/slindley/papers/frankly-draft-...
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 car after getting used to automatic. It's just redundant. I've seen better, I've written way cleaner code and got better concurrency. Promises, futures, yielded generators - they are all syntactic hacks. The only language I've used that really addresses this properly is Go (disclaimer: I haven't written any Erlang).
Earlier quoted context omitted.
It's a good type system. Many programming languages don't support this kind of type information, notably C.
I'm always curious how far a sufficiently motivated masochist could go with C... I guess it's just C++ ;)
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…
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.
Are there any large C projects written in this style?
What about FRP?
Earlier quoted context omitted.
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.
>structs (even 1-element structs) for everything. Are there any large C projects written in this style?
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.
In practice however most library callback apis resemble the callback contract enough so that one-line promise-wrapping of the entire library is possible.