Bullets Flying My Way

Larry O'Brien has been questioning my critique of Fred Brook's essay, "No Silver Bullets" in my post Lego Programming. Actually, he turned my post into a strawman argument and tied my name to an argument that I didn’t really make—that IDEs are a silver bullet. IDEs certainly have introduced a number of tenfold improvements in area; in most cases, however, IDE improvements are not the bottlenecks in software development. The ability to build an interface in a few hours instead of a few days doesn’t significantly impact a six-month project. Support for third-party controls and object-oriented frameworks, on the otherhand, have eliminated bottlenecks and resulted in dramatic improvements in delivery times. Lotus was able to develop Improv in six months on the NeXT, because of its object-oriented capabilities.

I wrote some facetious comments, which he took up on a second post "Bullets Over Wrong Ways." I'll answer those posts with a more persuasive arguments in another month. My silence now does not indicate agreement or resignation.

I don't want to be drawn into a debate right now, while I am trying to bring a product into a beta. I'll just reprint an edited version of my comment to his last post:

To some extent, I was humoring you in my comments; but I don't think the functional paradigm has been fully fleshed out, but will most likely become the dominant approach decades from now. Much of the Brook's thoughts on silver bullets rests on artifacts of imperative programming like state and side effects. If we eliminate state, for example, our program becomes more like a specification, which I feel also impacts some of the other costs Brook's mentioned such as testing and communication.

I am going to make my point in an upcoming post.

I don't think object-oriented programming is entirely distinct from functional programming. To the extent that object-orientation supports compositional programming, to the extent that an object can be interpreted as an inert function whose arguments correspond to the object's members, an argument can be made that it is close to a functional style.

That's a subject of a future post.

Comments

[Wesner Moise]

I'll make a note that there are a number of things that need to be address with functional programming languages: performance, accessibility.

But I don't think they are very hard to overcome.

There are quite a number of things that functional programming enables: symbolic evaluation, pervasive parallelism and dynamic programming, tree transforms/pattern matching.

By dynamic programming, I am referring to pervasive memoization, which makes many types of exponential algorithms suddenly tractable.

It turns out to be crucially important for natural language support. It's also a major reason why my NStatic product is possible.

[Wesner Moise]

I have included this post here of someone who shares my view of functional programming as meeting the criteria of silver bullet as defined by Fred Brooks.

http://cogito.blogthing.com/2006/12/06/no-silver-bullet-and-functional-programming/

http://discuss.joelonsoftware.com/default.asp?joel.3.424533