Wednesday, July 25, 2007

Blub Paradox

Ich habe da einen interessanten Artikel ueber das Blub Paradoxon gefunden.
Jenes besagt, das fast alle Programmierer der These zustimmen,
dass Programmiersprachen sich in ihrer "Macht" und Generalitaet unterscheiden, aber trotzdem
nicht bereit sind einzusehen, das andere Programmierespachen besser sind als die, die sie
habituell verwenden.
Verdeutlicht wird das am Beispieln eines eingefleischten "Blub" Programmierers.
"Blub" ist eine P.Sprache die im mittleren Bereich des Generalitaetskontinuums
liegt, das sich zwischen Maschinencode an einem Ende - und Lisp am anderen Ende
erstreckt.
Der Blub Programmierer kennt alle Sprachen, die schwaecher als Blub sind, und fragt sich,
wie man bloss ohne eine Feature "x" vernuenftig programmieren kann(- natuerlich verfuegt Blub ueber x).
Ausserdem findet er, dass Blub alle Features hat die er braucht, und ihm erscheinen features in
"hoeheren" Sprachen als verwirrend und unnoetig. Er denkt in Blub, und Blub ist sein Horizont -
und alle Probleme die er fuer loesungswuerdig befindet, sind in Blub loesbar!

http://www.paulgraham.com/avg.html

Sunday, July 15, 2007

functional vs oo

well it's been a while and I have come to trivial but usefull conclusions lately.
Once I thought functional programming was fundamentaly diffrent then
oo style programming, but I actually realized how well many aspects
of fp match to elements of oop;

Functions are simply Objects,
Closures are anonymous class,
certain design patterns ressemble
monads(decorator, chain of reponsibility,...)

oo style programming can be seen as a restricted variation of functional programming.

That matters because the key aspects of oop is encapsulation and
information hiding. This can easyly be achieved in fp through the
use of closures and the fact that functions can be treated like
any other data.

In oop very explicit notations usually exists, wich couple
certain functions to certain data through the notion of objects. Both, to increase readability of complex programms, and to lighten the restrictions that come with encapsulation, an explicit notion of inheritance is used.

While all this seems pretty obvious to most, frankly, I did not
appreciate oop after doing a a bit of fp, until I found myself reading through some javascript code that I wanted to optimize.
The code was using a many closures like this, which I removed
by placing the variables that the closures contained in
properties of objects, that also contained the functions
corresponding to the closures' code.

When I was finished I had not only increased speed by 40-60%
but was also surprised by the fact that my code looked a lot
like good oo-style code.

So in my opinion every programmer should learn to think functional
in order to get a hold of what the importance of encapsulation and code reuse.

That said, most javascript interpreters(javascript by itself not a purely functional language like haskell anyway) could do this manual optimization of closures automatically.

It is rumored that modern lisp systems and erlang(using HiPE) interpreters/compilers are very close to compiled "C" code performance:
See i.e. http://www.sics.se/~joe/apachevsyaws.html
or http://bob.pythonmac.org/archives/2006/09/21/erlang-binary-performance/

But to emphasis my point of oop vs fp regard this page:
http://openmap.bbn.com/~kanderso/performance/java/index.html

That's it for today.