Functional Programming In Depth, part II:Python and Scala retrospection

This entry is part 15 of 19 in the series Programming Languages

This is the second article on functional programming. In the first one we talked about scala and the type inference system it brings in the Java Way of Life.

I played a bit with python functional howto, building a small game. Before starting I surfing for a bit of libraries and documentation.

This very old “toolkit”, called xoltar, implements some basic functional principles, and it is a good teaching point. There are some nice functional-based libraries, but python has a “mutable state” pattern which is difficult to rip off.  I ended up using collections.namedtuple to get some immutable, side effect free named object. It was good because adding or removing field from a named tuple generates runtime errors like ultra fast rabbits, so changes to the Object protocol are detected early, but you still need a lot fo unit testing because there is no compiler to help you (like Erlang or Scala has instead)

Some days ago I read on the PyPy blog this clever comment:

Implementing STM at a core level is certainly a nice research topic, but I
wonder whether it’s the best way forward for Python.

STM works well in
Haskell because it has the type system to enforce several constraints. Also most
data is immutable in Haskell, so threading is mostly safe by

Most Python objects are mutable (by default), so users have to
be very careful when using multi-threading. STM gives you a nice, composable
primitive to protect your critical sections, but it does not tell where
your critical sections are.

The discussion was about Software Transaction Memory (STM for acro-friends) which is a key idea to avoid manual-implementing locks in a concurrent environment (for more information, read the full cited blog post and wikipedia explanation)

But STM works best if you have already a side effect free language.

Also Garbage collection is simplified in a language like Clojure, Erlang or Haskell. In Erlang for instance processes are isolated and can have different heaps. So it is simpler to make a fair garbage collection strategy.

So python is good for web prototyping and so on, but for functional programming it is a bit hard to get accustomed to. But perhaps I need only more study…

Scala is not always side effect free

I like Scala because it generate Java code. And Java code is fast and reliable. Skynet will be written in Java, belive me.

But Scala is far too complex. It is a mix of Erlang and Java. I did not understand why Scala has so much mutable data construct. Why did not Scala stick with the Side effect free Erlang pattern?

In my humble experience, if you give a programmer **more then one way** of doing things, they will mess it up their own code(Perl is a good example of this).Also Javascript, with its bad design, lead to different way of implement “complex objects”.[1]

So Scala is too complex in my humble opinion.


[1] Anyway Javscript seems to became the new “browser virtual machine”; One of the last trend is Clojure Script:

ClojureScript is a new compiler for Clojure that targets JavaScript. It is designed to emit JavaScript code which is compatible with the advanced compilation mode of the Google Closure optimizing compiler.

Series NavigationFunctional ProgrammingJavaScript War: Prologue

Leave a Reply