Lambda the Ultimate

I really hate this terminology because it is devious and misleading. It uses the language of political correctness to beg the question of whether there are any genuine differences between programming languages. It implies that if you prefer a language, your preference is really only an expression of prejudice and hence groundless, because the presumption is that all languages were created equal.

Indeed, it can be read as an abnegation of the value of programming language theory itself. The perception that all programming languages are the same is one of the big stumbling blocks, I think, in the adoption of more modern and better-designed programming languages, and, it seems to me, espoused most vehemently by those people whose programming experience really has been with languages that are largely syntactic variants of each other, e.g., all C-like languages, all C++-like languages.

So if Booch is saying what matters most are the people on your project, then I agree.

What do you think he might be saying?

I agree, and undoubtedly there are lots of things which affect the quality of a software product more than choice of programming language. What I take exception with is the terminology `language bigot' which makes a tacit assumption which I feel is very wrong.

There are other phrases like this, mostly from politics, where it does not do to be honest: for example, `axis of evil' (`axis' implies an alliance).

People start using these phrases without thinking too deeply about what underlying assumptions they imply, assumptions which perhaps they do not agree with. After they've developed a habit of using such a phrase, though, if you challenge them on that underlying assumption, they will be forced to defend it to avoid feeling like a hypocrite. It's a sort of covert virus which bypasses your natural defenses.

I think Ehud really hit the nail on the head here. I believe that if Booch had his way, there would only be one programming language - and that language would be UML. UML compilers would translate directly to machine-code. The problem with this is that UML is like all other languages - best suited to solve a particular problem.

"It is possible to design a single language which is best for solving all problems" - I wonder what kind of language myth that is.

I used to be a language bigot

The problem here is that that statement could have been taken two ways. The first, to mean that you were arbitrarily opposed to using different languages than those with which you were familiar. I.E. I won't try Haskell, because it surely can't be as good as Java. The second to mean that all languages are equivalent. Unfortunately, it is this second meaning which I believe Booch was trying to espouse.

UML is UNCOL! ;-) See Model Driven Architecture http://www.omg.org/mda/ for more elaboration along this line of thinking, which I find quite, uh, audacious and touching.

And in a more balanced way than the quotes suggest ;-)
The quoted remarks were made in response to: "VB.NET is nearly identical to C# or Java... are VB developers ready to master the power of real object orientation?"

"by and large interesting software systems tend to involve many different languages. And the difficult decisions are the ones made above the choice of the language itself"

I'm not sure I believe this is a myth.

You can argue that a `programming language' is something that solves exactly one problem: how to describe a computation. That problem doesn't change whether you're programming business applications, compilers, web servers or embedded components. The particular problems, suitably abstracted, which show up in one domain are the same as show up in another. A binary search is a binary search no matter whether you are searching a list of business records, a symbol table, HTML table or array of interrupt vectors.

Even if you disagree with that, you must still concede that it is possible that one language could be better for all tasks than all other languages existing at some point in time. I don't think that is the case now, at this point in time, but I think it is possible to create such a language.

OTOH, I seriously doubt there is such a thing as a "best programming language", which is to say that there is no bound on how `good' a language can be.

If UML isn't rich enough to model my solution, do I change my solution? If Smalltalk offers me design flexibility greater than C++, shouldn't this influence the design?

My design for, say, a Jabber server will probably look significantly different depending on whether I intend to build it using Java or Erlang.

+1

My design for, say, a Jabber server will probably look significantly different depending on whether I intend to build it using Java or Erlang.

I agree to some extent, but your design as an exceptional programmer, in either language, would be superior to some poor slob's design, in either language. And I speculate your two designs in these languages would be more similar to each other than either one would be similar to the slob's in that same language.

Speculation.

Yes, language choice doesn't matter when you look at languages with nearly-identical semantics (C#, VB, Java, C++). But what it really means is that the *syntax* doesn't matter. What Booch assumes is that we all do things in exactly the same way (perhaps even that there *is* only one right way to do things), and from this perspective he's probably right. Using VB rather than C# for coding yout UMLed best-practice design doesn't matter at all.

But if you allow yourself to question the fundementals of the architecture as part of the design, and maybe not always choose the ISO/IEEE way of doing things, language is very important, because it will allow you to do some things much more efficiently, and in a cleaner way.

I use Java now for building web systems. The lack of first-class functions, dynamic typing and closures influences the way I do things significantly. It may be the right thing for some projects, but I'm absolutely sure that it's not the right thing for other tasks.

Maybe Booch (and others advocating this way of doing things) are just afraid to admit that they actually have very little knowledge about the fundementals of software design. That, in fact, we are all a little in the dark. Booch wants us to be like architects, who know, after centuries of practive, quite a lot about how to go about doing their job in a responsible way. But *pretending* that we are like that (by gaining MS/JAVA/UML certification, for instance) isn't going to get us there, and quite likely, it will prevent us from maturing as software developers.

Ah, Tom, you are a man after my own heart. :)

Maybe Booch (and others advocating this way of doing things) are just afraid to admit that they actually have very little knowledge about the fundementals of software design. That, in fact, we are all a little in the dark. Booch wants us to be like architects, who know, after centuries of practive, quite a lot about how to go about doing their job in a responsible way. But *pretending* that we are like that (by gaining MS/JAVA/UML certification, for instance) isn't going to get us there, and quite likely, it will prevent us from maturing as software developers.

I think there is some truth to this, but on the other hand I think it's not a completely fair criticism of Booch. He does seem to acknowledge that software development as an engineering discipline is immature:

But what the industry lacks—and I think this is what Alan is seeing—is that we just don't know what the right architectures are for many classes of systems. So, to standardize upon some of these now is woefully premature.

There he's talking about `The IEEE Recommended Practice for Architectural Description for Software-Intensive Systems' (whatever that is) rather than SE licensing, but earlier he says also:

I'm encouraged to see the growth of our industry as it moves towards being an engineering discipline.

He uses the words `moves towards' so it sounds like an acknowledgement that we are not there yet.

But, I also feel that people like Booch really equate software engineering with object-oriented design; for them, good software = OO software and there is nothing else. And I think this is a terribly parochial perspective.

Elsewhere he writes:

I have a huge book from the American Institute of Architects called the Architect's Handbook of Professional Practices. It deals with the licensing of civil architects, and in it you'll find things in the technology you need to know about, including certain stresses and physical materials and their properties. That's the foundation of the profession, and most of the software vendor certificates deal with that part of it. But we've missed a lot in terms of the science of engineering that says "How do you truly engineer systems?" "How do you architect these?"

I think it's really just the opposite. We have tons of methodologies and whatnot which deal with project management and workflow and so on, which is the human side of SE and undoubtedly a necessary component. What we really lack is insight into how to construct and analyze programs in mathematically and scientifically rigorous manners, which is in my mind equivalent to the `stresses and physical materials and their properties'. That side of software has been much more successfully and thoroughly studied in the context of FP rather than OOP.

If Booch knows so much about programming, how come I can find a reproducible way to crash any version of Rational Rose in 5 minutes or less?

To a large extent, I put blame on the journalist conducting the interview. A lot of Booch's answers are lightweight, which may be a fair first answer for a general audience. But to be really useful to an assumed highly skilled dotNET magazine reader, the journalist as edited and printed anyway, leaves it at that. Maybe the full interview was more detailed, but then they sure left off the interesting bits.

See http://patricklogan.blogspot.com where I address this issue with some specific quotes that I felt needed more detail to be useful.

I've been experimenting with Enterprise Architect (a UML-based CASE tool that's fairly cheap) and this has been my biggest problem so far - if I have an iterative development process, what keeps the code and the pretty pictures synchronized?

While I can read code into the system, generating diagrams, I don't believe that changes to those diagrams are reflected in changes to the code - presumably because it's hard (because of the impedance mismatch between my source code language (Java) and UML). But what could be implemented (but doesn't appear to be, as far as I can see so far), is the possibility to check source against diagrams. So I change the diagrams, refactor the code and then run some kind of cross-correlation.

Does that exist? Have people anything good to say about any of the UML toosl out there (I'm quite impressed by EA compared to other free tools I've tried - at least it feels "solid" (hasn't crashed on me yet), although it only runs on Windows (so I installed Samba a few days ago!)).