Rich Hickey's slides from jvm lang summit - worth a read?

language_fan foo at bar.com.invalid
Thu Sep 24 16:45:51 PDT 2009


Thu, 24 Sep 2009 18:00:56 -0400, bearophile thusly wrote:

> Walter Bright:
> 
>> Executive summary: pure functions and immutable data structures help
>> manage program complexity.
> 
> There's something missing in most of the articles I've read that praise
> pure functions and immutable data structures. When I write a 500-lines
> long Python program I often start using almost pure data structures and
> pure functions, they help me avoid bugs and keep things tidy. Then if
> the performance is good enough I may stop (I add more tests, docs, etc).
> 
> If the performance isn't good enough I often profile the code and
> (beside trying to improve algorithms and data structures, catching and
> pre-processing, etc), I also sometimes reduce the purity of some
> performance critical functions/methods and change the code in some spots
> so it modifies some big data structures in place, to avoid repeated
> allocations and reduce GC activity. This speeds up the code.

Well, there are type and effect systems that allow in-place modifications 
without breaking the type rules, but many common functional languages 
just do not use these systems. If you break free from the safe part of 
the language, it is like driving a car without seat belt and/or brakes. 
If you are a hardcore professional, you know how to avoid some of the 
dangers, but often it is not possible to avoid them all.

Static type checking has a crucial property: it can prove some properties 
(like the absence of some errors) without decreasing the runtime 
performance. Another alternative are the unit tests, but no matter how 
many tests you add to your test suite, you can never prove the absence of 
errors, only their presence. Switching to Python is in one way a step in 
the wrong direction - you lose something you already had for free - 
instead you need to emulate it with tons of additional unit tests to 
achieve acceptable levels of quality.

Type systems, like the pure data structures, have their roots in formal 
logic. I recommend taking a cursory look at the history of types. It all 
started in 1870s, and even though there were functional languages like 
Lisp already in 1970, it was only then that someone (Reynolds, Milner) 
came up with modern concepts like polymorphisms. E.g. the type system for 
stuff like

  int get_length_of_a_list(T)(List!(T) list);

was invented in the 70s. Lisp could not provide this kind of safety for 
lists, there was only the core stuff for lambda calculus ready back then. 
As another example I could mention typesafe printf that was invented in 
the 80s. The good thing is, some serious advancements have happened since 
then, but more is definitely yet to come. It would be foolish to think 
that functional languages have somehow remained stagnant since the 
introduction of Lisp. On the contrary, the mainstream C-like languages 
have refused to take advantage of type systems developed in the 90s or in 
the 21th century. Now that multi-cores are becoming the norm, a lot of 
research is happening also on that domain.



More information about the Digitalmars-d mailing list