Thanks for your reply, and sorry for not answering earlier — for some reason I only got a notification of it in my mail today.

Regarding waste you are correct, of course. All waste can never be eliminated completely, just reduced. The other way of looking at the words is that we can eliminate some part of the waste, while leaving the rest untouched. It is semantics — I think I and you mean the same thing.

I enjoyed the article you linked to. I think I have a somewhat different kind of a prototype in my mind from yours — in this article I am talking about validating the business case, while the prototypes in your article are about validating the technology choices. Both of them have their place. I don’t know if the difference matters in this conversation, but I wanted to point it out.

How much prototyping is enough? Depends on the case. You can never be entirely sure that the choices you make will work. Prototype can only reduce uncertainty, never eliminate it. On abstract level, there is a certain value to information, and you want to maximize the output you get from your attempts to uncover it. On practical level, you will mostly make these choices by intuition, but if you want to get technical, there are ways to do it too. One book that might be helpful here is http://www.amazon.com/How-Measure-Anything-Intangibles-Business/dp/0470110120 .

About the elimination of waste, I don’t think you really are “eliminating” waste, you’re just reducing it. The question is, how far would you go with a prototype before saying that it will or won’t work?

I did publish a post discussing the importance of prototyping (see top two factors that tank many IT projects), but I still think that a prototype is waste.

Me and Mr Lisp met briefly during my university times (and that was long time ago). FP was not a major topic, but still something to touch upon. I did an exam work dealing with data mining. The result was not elegant, but it worked. I received the credits, but still something did not feel right that day …..

Why? It occurred to me some weeks later that, if really applying FP paradigm as intended, the whole problem could have been solved with roughly 1/3 of the code. And I tell you, with Lisp that would mean significant number of opening and closing brackets that could have been made unnecessary (main pain point of Lisp).

Unfortunately, I never had reason to start any other project in Lisp (still did have an interesting professional career, needless to say). But I think/feel, there is point in the claims being made in this blog (and so are the facts regarding programming languages in enterprises)….

The reason for being wrong? maintainability. In itself, a solution written in a functional language is quite maintainable of course. The problem is that there are just too few capable developers in the market, which make large enterprises dependent on a scarce resource.

Case in point is the rise of ‘easy’ languages like Java and .net. These became very popular in the enterprise because they’re more idiot proof. You can simply afford to hire idiots and get away with it. Not so with a functional language.

The extra ‘cost’ incurred with these easy languages is offset by being able to hire less ‘leet’ coders at a lower rate. ‘Everyone is replacable’ is the mantra.

I don’t see a functional language become more than a niche thing in the enterprise world, most likely something like a neatly wrapped and isolated module in a larger OOP software system.

JVM compatible languages are much easier to sell to customers, employers, co-workers and other parties. Support for enterprisey JVM libraries by definition exists for these.

Out of JVM compatible languages I prefer Scala and there are signs it might actually take off. Groovy has some sort of fanclub in the enterprise software world but to me feels like a quick and dirty fp patch over standard Java. Yuck.

In any case I agree that people should start learning fp because it will come and Haskell certainly seems one of the best languages to learn with.