The Downfall of Imperative Programming. Functional Programming and the Multicore Revolution : programming
The Downfall of Imperative Programming. Functional Programming and the Multicore Revolution (fpcomplete.com)
Splitting things up into threads is one thing, but how do functional languages help with memory locality?
That's a really good question. There's only some initial thought going into that area, as far
as I know (or maybe there's a fair amount of theoretical work, but very little in terms of actual
implementation). One nice thing is that if you have memory that you know won't mutate, then you
don't have to worry about clones of that data. Similarly, to the extent that communication between
threads is always explicit, then you know a great deal about which memory never needs to be
touched by more than a single thread. Building compilers and runtimes to make good use of this
information is very much an open project, however.
The last major paradigm shift was OOP. It took off because it was the price of admission to GUI toolkits.
Once upon a time, Lisp was the price of admission to AI. It faltered when strong AI didn't pan out.
Functional programming will take off if/when it becomes the price of admission to something really
valuable. Current multi-core hardware and current tasks that can benefit from parallelism aren't
enough motivation to switch - we're still getting benefits from the embarrassingly parallel portions
of current problems.
How can it be the downfall of imperative programming if the main Haskell compilers are
written in C? The JVM is written in C.... UNIX, Mac OS X(UNIX), Windows, Android, all
written in C....
Every few years you get stupid announcements such as this one. "The end of
Java", "the end of C"...
I am in love with Haskell and I am tryign to improve my knowhow of it daily, BUT I
won't be stupid enough to predict the "downfall" of a kind of language just
because Haskell is great.
actually I think GHC is written in Haskell
GHC is itself written in Haskell (in a technique known as bootstrapping), but the runtime
system for Haskell, essential to run programs, is written in C and C--.
So you're both kind of right. And TIL about C--.
Imperative programs will always be vulnerable to data races because they contain mutable variables.
Do they nececarily have to? Rust seems to be immutable by default, but I haven't really looked into it deeper.
Rust does have immutability by default, but mutability is common and easy to achieve. The real
protection against data races is that you can only access shared memory via unique references.
It uses channels for inter-task communication.