The Downfall of Imperative Programming

[Paulo Pinto]

My favourite FP language is Haskell, but I doubt most "code
monkeys"
will ever be able to grasp it, while impure ones are more
approachable
in enterprise environments.

The issues you point out are actually more implementation
issues than language related, right?

--
Paulo

On Tuesday, 10 April 2012 at 17:19:00 UTC, Russel Winder wrote:
> Two quite interesting points to make here:
>
> 1.  OCaml has a GIL and so, like CPython (*), is forced to use 
> operating
> system processes to obtain parallelism. Also OCaml has 
> imperative
> features, it is not a pure functional language.  Clojure 
> followed this
> route as well, using STM to deal with locking issues.
>
> 2. Haskell is a lazy language which means:
> 	a. it can work with infinite data structures; and
> 	b. it is incredibly difficult to create parallel codes.
>
> Simon Peyton Jones and Simon Marlow have had to do a great deal 
> of very
> clever work to make Data Parallel Haskell, but it is to Haskell 
> what
> NumPy is to Python.
>
> I am a fan of declarative expression, I prefer functional 
> approaches
> over explicitly imperative ones.  For the moment though using 
> single
> assignment in imperative languages with all the lambda/closure
> technology and using functional programming thinking is the best
> compromise.  OCaml (and its clone F#) and Haskell are likely to 
> remain
> tiny bit part players for a long while.
>
> On the JVM the interesting question is whether Clojure finally 
> makes
> Lisp a mainstream language outside of one or two domains.
>
>
> (*) PyPy is experimenting with STM to replace use of a GIL.