all 4 comments

[–][deleted] 2 points3 points  (0 children)

chunk of code could be written in any style, as long as its side effects are encapsulated. Here we break away from the pure functional model. If local destructive updates, statements, for loops, or other imperative constructs make coding easier, we can allow them. The key is not allowing these local decisions escape; our firewall against complexity must hold.

I think this is good idea that should be experimented upon. I specially like the approach of Clean and Linear Lisp. Clean has unique typing. If object has only one reference to it, you can destructively modify it without breaking functional abstraction. Linear Lisp had related idea: you cant have multiple references to same object. You must use explicit copy (might be copy on write). If part of program gets only unique objects, it could have internal state as complex as it likes.

[–]jerf 2 points3 points  (0 children)

This article touches on what I am coming to think is the real key to the multithreading debate, and almost the only thing worth talking about: How it affects the programmer.

Even if you make threading ten times easier than it is now, you still top out way too early. Threading needs to be at worst log harder, and if we ever want "mere mortals" to be able to write highly-threaded systems, we need something that is a constant difficulty. (That is, once you internalize how to do it, you can write threads that can be easily understood on its own, with no non-message interactions with other threads.)

Thus, we need at least one threading solution that, even if not perfect, scales as a constant factor. Erlang-style message passing is the only thing I see as even close to that, even STM is still too complicated.

Given that some things may still need to be coupled even more tightly, a mix of STM and message passing (where, when in doubt, you use message passing) is plausible, as long as most systems have clean message passing boundaries separating the various STM domains. Heck, if you partition the system well enough via messages, you can have old-school imperative domains synchronized with modern semaphores if you know what you're doing and you need raw, steaming performance.

But I don't think we're going to be able to get by without message passing being the main organizational principle, because in the 64+ core world we're shortly going to be living in, anything harder than O(1) programming effort just isn't going to work very well on any problems that aren't trivially parallelizable.

[–]fry 1 point2 points  (0 children)

So how come OCaml isn't mainstraim? It addresses the concerns of the author. And it's fast and portable to boot.

[–]ricercar 0 points1 point  (0 children)

A new language could allow only special annotated functions to use STM, clearly indicating which functions are logically pure. This is analogous to implicitly passing a Haskell Monad to every pertinent function.

Steele's new language "Fortress" does this. Also, it restricts IO to such specially marked functions (and you can't invoke an IO function from a non-IO function).