Why functional programming doesn't catch on

By Confusion on zaterdag 21 februari 2009 22:30 - Comments (61)
Categories: Java, Software engineering, Views: 87.538

Authorities in the field of software engineering have long lamented the fact that functional programming (FP) doesn't seem to catch on. Their sympathizers often blame that on shortcomings in the audience or their pointy-haired bosses, but that is the easy way out: to assume that someone that disagrees with you simply lacks the ability to understand you is a way of shielding yourself from the possiblity that you are the one with a shortcoming: the inability to provide a proper explanation.

I think that the actual reason for the limited adoption of FP languages is exactly that: the way the advantages are formulated and exemplified are completely obvious and compelling to their proponents, but those same explanations and examples utterly fail to convince most software engineers, because they simply do not appeal to the problems they are confronted with in their daily line of work.

I think this hypothesis is best exemplified by the seminal paper Why Functional Programming Matters. This paper sets out to
[..] demonstrate to the 'real world' that functional programming is vitally important,
[listing of advantages]
Such a catalogue of 'advantages' is all very well, but one must not be surprised if outsiders don't take it too seriously.
We must must find something to put in its place - something which not only explains the power of functional programming, but also gives a clear indication of what the functional programmer should strive towards.
and then goes on with explanations like
The definition of reduce can be derived just by parameterising the definition of sum, giving
(reduce f x) nil = x
(reduce f x) (cons a l) = f a ((reduce f x) l)
and applications to things like the Newton-Raphson approximation and tree pruning in artifical intelligence.

[I'm inserting an intentional dramatic silence here, in which you can see my facial expression turn to complete astonishment]

Now how in heavens name can one expect to convince the average software engineer of the tenets of functional programming with these kinds of examples? If it does one thing, it is scaring people away by seeming unnecessarily difficult and academic.

Every introduction to a programming language shows you the recursive method to calculate Fibonacci numbers. It's abstract, many people do not relate to it very well, but it's only a single example. However, the documentation for FP languages seem to consist solely of these kinds of highly mathematically inspired examples. No 'Address' class to be found there. Hasn't anyone written a functional equivalent of the Pet Store application to demonstrate the power of FP for the regular work that most of us do?

People that want to improve the world often overlook one fundamental problem: you cannot improve the world just by being right. You need to convince others of that fact if you want to exert influence. If you cannot convince them, find out why you cannot convince them. I think there is a bright future ahead for functional programming, as soon as someone stands up to convince the masses.

As not everyone reads the comments, I would like to highlight a few points made there:
  • The article I quote is 25 years old and was directed to people in academia. It would not be fair to conclude that all FP documentation is that hard to understand for someone without an academic background.
  • There are deliberate attempts at displaying the 'real life' value of FP, for instance in Real World Haskell and Practical Common Lisp.
  • Several people assert that FP is catching on, but it just isn't very visible (yet). This may be because those that use it consider it a competative advantage

Spring, Hibernate and leaky abstractions

By Confusion on vrijdag 20 februari 2009 22:33 - Comments (3)
Categories: Java, Software engineering, Views: 6.957

The advantage of using frameworks/libraries like Spring and Hibernate is supposed to be that they take care of the nasty details and that you only need to think about what you wish to do on a much higher level. However, abstractions are always leaky and when you run into a problem, you still need to understand about the nitty-gritty details.

This week, I ran into the following problem: my Spring/Hibernate based application locked up. It was reproducible and seemed to depend on the number of queries that had taken place. So I started Tomcat with

told Eclipse to connect to that socket (debug remote application) and suspended operation after the application frooze. The result was clear: no more connections in the connection pool and an infinite wait until one would be available.

Now this application is reasonably old and has worked succesfully for quite a while. Everything seemed to be in order, until, after looking at the Javadoc of the HibernateDaoSupport class for the umpteenth time, it suddenly hit me: the latest DAO used getSession() instead of getSessionFactory().getCurrentSession() to obtain a session. While the first could very well be a shorthand for the latter, it most certainly isn't. I noticed the difference when I reviewed the differences when updating from Subversion and read the appropriate Javadoc, but I wasn't paying enough attention to realise that the difference between these ways of obtaining a Hibernate session was a nitty-gritty detail that was very important.

Using grails on an existing database

By Confusion on donderdag 12 februari 2009 22:12 - Comments (3)
Categories: Java, Software engineering, Views: 19.383

I've encountered the following problem several times: I needed to inspect or alter data in a database, but there is no interface to this data. Todays problem was that I needed to edit some html in a SQL server database, but the so called 'Enterprise Manager' did not display these fields, complaining about the 'grid buffer size'. Of course it turned out to be impossible to find out how to increase that value and using the Query Manager to edit large text fields isn't very convenient either.

Now I could write some custom Java to perform the specific actions that were required, but I would be hard pressed to provide full CRUD capabilities within a reasonable period of time and I certainly wouldn't have a GUI. After searching a bit for frameworks to generate CRUD with editing controls for an existing database, I decided to give grails, a Ruby on Rails type framework based on the JVM language Groovy, a go.

Now firstly, it is important to realize that such frameworks are usually bent on specifying a domain model, which is then used to generate the database. When used with an existing database the generator code will often try to modify your database. In case of grails, by adding an 'id' and 'version' column. If you generate the skeleton for a grails application (see the quick start, there will be a database configuration file in grails-app/conf/DataSource.groovy. When you modify this file to add your configuration, be sure to comment the lines saying
dbCreate = "update" // or "create" or ...

The order of operation is as follows: create domain objects, generate default views and controllers and modify them appropriately. There is a tool called GRAG that can help you to reverse engineer your domain objects from your database and although it produced some odd results in my case, it will certainly help you on your way. A domain object may look like this:
class Email {
    static mapping = {
         table 'emails'
         id column:'email_id'
         version false
    String content

The 'mapping' element is required because I'm not following the defaults: if the table was called 'email', the id column was called 'id' and the table would have a 'version' column, it would not have been necessary.

After having created domain objects, you need to run
grails generate-all Email

to generate a controller and a view. Follow with
grails run-app

and you've got a CRUD application running for this table and its two fields.

Of course, you'll often need a bit more than this, but for instance changing the input element for the html field to a large enough textarea and adding some functionality to properly (un)escape html was easy.

Behulpzaam of bemoeizuchtig? nl

Door Confusion op maandag 9 februari 2009 20:09 - Reacties (14)
Categorie: Philosophy, Views: 4.066

Een jongen van een jaar of vijftien staat al een tijdje in de richting van een aankomende tram te turen en zegt tenslotte tegen zijn ouders "het is een 16". Het was inderdaad een 16, maar dat had ik, met dank aan Kepler, al een meter of vijftig eerder gezien. De gedachte om hem te adviseren een opticien te bezoeken kwam bij me op, maar meteen overviel me het gevoel dat me dat niet in dank zou worden afgenomen. Zouden jullie iets hebben gezegd?

Als je die laatste vraag voor jezelf hebt beantwoord, dan geef ik nu de volgende overweging: er is een kans dat deze jongen zijn leven lang last zal hebben van de gevolgen van een gebrekkig gezichtsvermogen. Niet alleen vanwege de beperking zelf: er is een verband tussen onopgemerkte beperkingen in het zicht en iemands schoolprestaties. Het effect van dat laatste rimpelt door iemands hele leven heen. Een simpele opmerking, maar wel een persoonlijke, zou levensveranderend kunnen zijn. Zou je een volgende keer iets zeggen?

Is there more bad PHP than bad Java?

By Confusion on zondag 8 februari 2009 11:34 - Comments (7)
Categories: Java, Software engineering, Views: 4.678

Bad code is code that invites future bugs due to being incomprehensible or fragile. Although this is mostly the result of a lack of forethought and design, I think that in some programming languages it is much easier to write such code than in others.

I think there are three main reasons why a language may be more bad-code-prone than others: lacking namespaces, using dynamic typing and providing functional programming possibilities. Now I am not argueing that it is an inherent feature of such languages that they result in bad code. Rather, I think that these languages provide more, and easier, ways to shoot oneself in the foot. Dynamic typing and functional programming provide easy ways to circumvent the restrictions imposed by a proper design, while the lack of proper namespaces does not allow you to implement a proper design at all.

As a result, I think it requires more skill and thought to write good code in languages like PHP and Javascript then it does in a statically typed, 'restricted', language like Java. However, these are precisely the languages that less skilled programmers use more often, because they seem simpler. Consequently, there is necessarily more bad PHP than there is bad Java.