Lambda the Ultimate

If I were to nitpick I'd say that it's interesting to see such an endorsement of the use of invariants from a designer of a PL that has so little intrinsic support for defining them. Oh, wait, I just did ;-)

Basically, he seems to be saying that he designed a perfectly good language but that everybody just uses it wrong, either too low-level or too high-level.

I subscribe to the school of design that says a good design is one which helps its users to find the intended way to use it. A door that is meant to be pushed, but has a big pull handle on it is a bad design.

A language that jumbles together low-level constructs and high-level abstractions together willy-nilly so that users can't tell which it is for is badly designed, and the designer should take his lumps with grace, not blame the victim.

I think that there is much sense in the way C++ is/was designed. I'd personally like to hear somewhat more constructive critique of C++ - critique that would take the rationale that Stroustrup presents in TDE into account.

Sure, C++ may not be what one would come up while designing a new language from scratch (I certainly would not design a language like C++ from scratch), but that is not the way C++ came around. Ignoring the context in which C++ was designed is rather ignorant, IMHO.

[Nodding in agreement]

Have you read Robert Cecil Martin's book Designing Object Oriented C++ Applications Using The Booch Method? IMHO, it is one of the best books on software design, along with Robert Martin's articles on design principles, that I have read. Anyway, one of the chapters in the book is titled "Paradigm Crossings". Among other things, the chapter compares the "Representational Paradigm" and the "Object-Oriented Paradigm". Honestly, I think a lot of people really don't understand the insights that go into the "Abstraction vs Instability" diagram and the "Main Sequence" that Robert Martin talks about.

[I'm purposely being a bit vague as I'd like other people to read the book and because I don't have the time to explain these issues in depth.]

I have a pretty good idea of the context of the evolution of C++, because a) I was programming with C/C++ during the period, and remember the developments of the time b) I've read numerous papers about it, including those in Waldo "The Evolution of C++".

I wasn't even intending to criticize C++ per se; I was critiquing his critique of the use of his own language.

My message to him is: PL designer heal thyself! ;-)

I know these days C++ is described as "multi-paradigm". I am not sure it began life that way. I think it began life as an OO extension to C. My criticisms on that basis include:

• It became a multi-paradigm language, and so grew significantly in complexity.
• Even early on the syntax had some troubling ambiguities, or nearly so, making tools difficult to develop.
• Compatibility with C was sacrificed, so it was not strictly an OO extension to C.

Finally a useful criticism (although much too late) could come from a comparison of Objective-C. Objective-C was more proprietary then, but considering just the technical issues, they seem to have had similar goals. But Objective-C avoided the three issues, above.

One might argue against Objective-C that it did not preserve "curly brace" syntax for the OO part. That could be seen as a positive or a negative, subjectively.

Yes. I still think this is in the top 5 at least of OO programming books. Probably top 3, but I'd have to spend time recalling more recent books.

Don't let the "C++" or the "Booch Method" throw you. This book is about OO software design with particular attention to C++, and it uses the old Booch notation.

Very pragmatic, especially given that it predates the patterns, XP, etc. movements that came later for the C++ community. None of the hooey commonly associated with OO programming.

I'd like to hear about the other books that you'd place in the top 5. What I would really like to see is some pragmatic or theoretical take on software design that would challenge or surpass the engineering wisdom displayed in the works of Robert Martin. For me, Robert Martin's book (DOOCAUTBM) and design principles were eye openers. The essense of software design is to manage dependencies. Pretty much everything I know about software design boils down to dependency inversion or management. Even abstraction is fundamentally about dependencies. (Abstraction is about eliminating dependency on irrelevant or varying details.)

Top 5 OO Programming Books, hmmm... OK. I won't try to order them, these are all "in the top 5"...

• Robert Martin's DOOCAUTBM
• Design Patterns
• Refactoring: Improving the Design of Existing Code
• Kent Beck's Guide to Better Smalltalk: A Sorted Collection
• Concurrency: State Models & Java Programs

But ask me some other day and there might be other titles in the list.

First, C++ has evolved, albeit slower than other PLs, over the last 20 years. Thus, the use of the language should also evolve. Yet many programmers use C++ in exactly the same way they had a decade ago. Stroustrup and co. could theoretically force their hand by removing features from the PL, but given philosophy regarding backward compatibility, this will never happen (even if it did, the compiler vendors will never implement it).

Second, not only has the PL evolved but the rationalization for its use has also evolved. Once it was because C++ provided the easiest path for C programmers to enrich their toolset and their existing apps. Today C compatibility is not so important. I would hazard a guess that most current C++ developers do not have a serious background in C.

And yet, for various reasons, these programmers are using techniques that are throwbacks to the C area, such as pointers and arrays, instead of modern C++ tools such as strings, iterators and containers.

Over the last couple of years I've seen Stroustrop make a lot of effort in educating C++ programmers. He doesn't really need to. He has already won his fame and fortune.

C++ was multi-paradigmatic from day one, if only for supporting both OOP and "procedural" C style.

Finally a useful criticism (although much too late) could come from a comparison of Objective-C.

Given your Smalltalk inclinations, I'm not surprised that you find Objective-C more appealing than C++ (note, I'm not saying this as criticism). In your opinion, were Object-C's proprietary aspects the main reason why it lost to C++ ?

Both these problems exist with other languages, so I don't really see them as "his fault."

But being a language designer he has an interesting perspective, both on the issues themselves and on the programming community.

Yes, ST-BPP is not a *design* book. It is a more rudimentary coding book, about style and design only in-the-very-small.

The book I listed, Guide to Better Smalltalk, is a collection of his papers primarily about bigger design topics.

I'm not sure that I would associate concurrent programming and OO[D]

I included it not because it is about OOD per se, but because an OO programmer today *has* to understand these concepts and techniques, and this particular book does specically address the mechanics of translating a model into a popular OO language.

Also it was late and I did not want to spend more time thinking of another book! (I was tempted to just list the whole PLOP series as one book. Pick any one as the fifth.)

I would guess so. I think if it were free and/or marketed by a large corporation it would at least have had a more level playing field.

Of course now it is free (via GCC) on multiple platforms and successful on the Mac OS X. But the C++ genie is well out of the bottle.

Yes. I looked at the contents at the Amazon site. It might be an interesting read.

I was tempted to just list the whole PLOP series as one book.

I own copies of the first three and I've read parts of the fourth. I've also read Pattern Hatching, parts of volumes 1 and 2 of Pattern Oriented Software Architecture, and probably some other texts that I just don't remember at the moment (ah.. Anti-Patterns at least).

I have to say that while patterns are interesting, the insights I've learned from patterns pale in comparison to the design principles I've learned from Uncle Bob's articles. Applying the design principles (analyzing dependencies that is) I can usually quite easily come up with solutions rivalling documented design patterns.

What I would really like to know is what I should learn next. Generative Programming (and Modern C++ Design) was interesting as was OnLisp. I've considered reading about things such as CLOS. Of course, what I'm talking about here is pragmatic software engineering / design texts (concerned about issues of scale) rather than formal theory (or design) of programming languages (also involved heavily on my reading list). [I have lately also been reading books on algorithms.]

One thing I'd like to see is a book on the design of large scale software systems in a functional or logic programming perspective. Most texts I've read on functional [and fewer on logic programming] have been rather introductory and haven't really touched issues of scale at all. [I really don't need to read yet another book that introduces the Y-combinator or talks about the usual primitive recursive iterator functions, etc... I've read quite a few "coding" books esp. C++ related, but also functional programming related.] The dependency structure of most of the code I've written in functional languages has been strictly weaker in comparison to the dependency structure of my OO code, but this may be because I haven't really tried to create highly reusable designs (in my functional programming).

There are very few good design texts. The reason is simply that almost no one has a clue. So pick up the software systems you admire, and reverse engineer them, using the source code which is usually easily available (think emacs, gcc etc. etc.)

when templates were first introduced in C++, some implementations produced really unwieldy code. that goes against the very nature of the C-style programmer, who thinks programs must be small and fast. some people still abhor templates in any form, fearing large code size.

there are a whole lot of programmers that get a high from programming close to the machine. you aren't going to get them to change much, especially not the way most C++ vendors have approached things. they like their pointers and arrays.

This seems to reduce objects to essences that can be used as though they were ADTs? (at least in my limited understanding of the distinction William Cook made).

ADTs are organized around the observations. Each observation is implemented as an operation upon a concrete representation derived from the constructors. The constructors are also implemented as operations that create values in the representation type. The representation is shared among the operations, but hidden from clients of the ADT.

PDA is organized around the constructors of the data abstraction. The observations become the attributes, or methods, of the procedural data values. Thus a procedural data value is simply defined by the combination of all possible observations upon it.
"Object-Oriented Programming Versus Abstract Data Types"

The C# Buffer class seems a good example, it has 4 static members like:

public static void SetByte(
   Array array,
   int index,
   byte value
); 

Is identity of any value to Buffer class?
Does Buffer class encapsulate a representation?
Would anyone ever create an instance of Buffer class?
Would anyone ever subclass Buffer class?

Seems to me that this is a reasonable way to organize code - it just doesn't have much to do with what I would understand to be objects rather than ADTs. In Java and C# this is just OO cant - everything is a class even when there will never be instances.

Wouldn't it be more reasonable to think of this as a Buffer ADT?

I would agree on the whole. The PLOP books are interesting for their ideas, not necessarily always the principles or exact details.

One thing I'd like to see is a book on the design of large scale software systems in a functional or logic programming perspective.

I'd like to see this too. Reading code is educational, but to have the kind of text around the code that Bob Martin adds in his books would be so valuable for promoting the understanding and utility of these other approaches.

A lot of information is there in bits and pieces of various papers, but it is challenging for someone with limited time to piece together a coherent picture of building large systems.

But as to ADTs vs. Objects, I must say that I still think ADTs make much more sense than objects. That's just the way I feel, not something I can prove. I think the ADT concept is clear, it is directly related to abstraction, which to me is the fundamental concept in SE. So yeah, I don't mind being accused of standing up for ADTs...

Annotated source code perhaps (think literate programming)?

Well, it's one more idea for the "books I should really write one day" list

I don't mind you standing up for ADTs.
My concern is the loss of clarity when a library of 4 functions is termed a class...

One of the most used patterns in my OO design is the Strategy pattern (see GoF). Roughly speaking (perhaps slightly mixing different levels of abstraction), the Strategy pattern is the OO equivalent of a lambda expression. Higher-order methods that take Strategy / Policy objects as parameters are not rare in my OO designs.

I think that one of the reasons why the connections between functional programming and OO programming may not have been so widely understood (as I would like) is that many OO languages have been designed on top of weak execution cores. Even very early "mainstream" functional languages had anonymous lambda expression, lexical binding and tail recursion. Many early OO languages just didn't offer that level of sophistication, but relied on the simple stack model of execution (like C), making it actually rather hard to build sophisticated behavioral abstractions.

[Of course, my language of choice would be Scheme, which would allow me to easily build a sophisticated OO layer on top of the core Scheme. I prefer to avoid the Abstraction Inversion antipattern.]

Many early OO languages just didn't offer that level of sophistication
afaik Smalltalk has lambda and lexical binding but not tail recursion.

What I tried to say is that both OO and FP are fundamentally about behaviour (rather than representation) and therefore not very different. [But I started with the conclusion, which probably made you miss the point.]

I said: "Many early OO languages just didn't ..."

But I probably should have said "Many OO languages just don't...". I'm sure there have been exceptions to the rule. Pretty much all the mainstream OO languages of today have (had) extremely weak core language features. Things are probably going to change in the future..

But I probably should have said...
Drat! Just when I was going to mention LOOPS

Do you have the GoF book at hand? Which of the patterns would you characterize as representational [focus on organization and structure of data] and which would you characterize as behavioral [focus on organization and structure of operations / behavioral responsibilities]? [Forget the existing classification and just analyze the short descriptions. For example, Decorator is all about adding behavioral (functional) responsibilities, IMO.]

...

What do you mean that OO encapsulates representations and FP does not? How is such OO encapsulation different from the hiding of representational details of ADTs in FP?

...

It seems to me, that the main difference, forgetting side-effects (and subtyping and inheritance), between OO and FP is one of granularity. In OO the smallest granule is an object that may have several named methods. In FP the smallest granule is a function. The granule that I'm talking about here is the granule of behavior that one uses to compose (mainly by parameterization and layering) more complex behaviors.

But it seems that I've made a mistake, since I know Patrick to be a man of fine taste. I can't find any Robert Martin books on the shelves around the office, so I wonder if someone could give pointers to really good online publications of his? I'd like to read them and set myself straight.

I'm not exactly sure what you mean by this. However, one of the first books I read on OOA/OOD was Object-Oriented Analysis and Design with Applications [2nd. ed.] by Grady Booch. I honestly can't say that I would have really learned how to do better OO design from that book. On the other hand, after reading Robert Martin's book DOOCAUTBM and his articles on design principles (see RCM's articles on design principles) I really felt (and still feel) that I finally understood what software design is really all about. Of course, perhaps I'm just too ignorant to know any better. ;)

The Booch/Rumbaugh school of thought says that complex problems should be decomposed into object-oriented class hierarchies. For many problems this is wrong. Trying to squeeze every problem into an intricate class hierarchy often leads to contorted and fragile designs (described well in [1]). People who promote that "OOA/D is The Way" to impressionable youngsters like myself are Bad Guys in the computing world -- they are to be avoided.

I don't want to snipe at Robert Martin too much, because I can believe that he's a smart guy and his advice is good in context. But I find that he, along with the rest of modern software engineering writers, tacitly promotes the Booch/Rumbaugh "OOA/D Is It" mindset by using it as the basis for all software design without question. His papers describe how to avoid pitfalls of awkward design that I remember very well from my Java programming days, but just don't encounter anymore when programming in Lisp, Erlang, and C. This may not be because those languages are superior, but because having learned more I use the right tool for the job instead of always building a class hierarchy. I wish the authors of the books I read during my teens told me to learn about these alternatives instead of indoctrinating me with the OOA/D mindset.

I want to read "the straight dope". I don't want authors to assume that I have some particular preconceptions and only offer me advice consistent with those, even when they know that better alternatives exist. That is a harmful degenerate case of "Only Say Things That Can Be Heard" [2] or "the Silence of the Lambdas" [3].This is how Robert Martin's writing comes across to me. I found it insulting that in the (fake) case study cited above they contrived things so carefully to make Java the appropriate implementation language and so on. It looks like they chose Java as the solution, to avoid shocking the reader, and then contrived the problem to apparently match it. That sounds exactly like the way "worst practices" industrial projects work in reality. Blech!!!

This contrasts very strongly with other writers who know their stuff and tell it straight. To name a few, Hoare, Dijkstra, Kernighan, Bentley, Wirth, Norvig, and Stallman. When I read their stuff, I feel like I'm being addressed as a peer and nothing is off limits. I cannot find anything in a bookstore with that flavour today.

(It sucks that so much excellent work on software development is languishing in relative obscurity and inaccessibility in the ACM's digital library, while so much trash is thrust in our faces in book stores. There are so many excellent ACM links I'd love to post here, but I don't because many readers won't be able to download them anyway).

[1]: http://www.catb.org/~esr/writings/taoup/html/unix_and_oo.html

[2]: http://c2.com/cgi/wiki?OnlySayThingsThatCanBeHeard

[3]: http://home.pipeline.com/~hbaker1/sigplannotices/gigo-1997-03.html

Once the mind has deteriorated to this condition, there is nothing more to be done.

I wonder if someone could give pointers to really good online publications of his?

I would start with his Principles and Patterns article. I have not read much of his recently, but almost anything from his publications list would be worth reading.

Object Oriented Analysis and Design with Applications

That was never a favorite of mine. It does not resemble a Robert Martin publication, so I would only guess it has more of Grady Booch's influence.

I agree that his writings address C++ and Java more than Smalltalk, not to mention Lisp, or especially Erlang.

Beyond the language-specific aspects of his DOOCAUTBM book, I particularly apreciate that this is the first book I know of to show a software design process in action. That is, he describes his thought processes and shows him rethinking problems, design, and code.

Most OO books show one solution without a lot of insight into how that solution was derived, and so they tend to communicate there is one solution and not tradeoffs among multiple solutions.

This observation may no longer be valid. I tend not to read OO programming books because in the past they had been so poor as a whole.

The patterns and refactoring books listed above also take the realistic approach of tradeoffs and change. There are other pattern books that are not nearly as good.

I still feel the annoyance, but will refrain from slanderously laying it all at Mr. Martin's door in the future. :-)

the main difference
If we're talking about FP with ADTs versus OOP aren't we just back to ADTs versus OOP, and the distinction William Cook made? (quoted previously)

The absence of hand-waving theories in Designing Object Systems 1994 was such a contrast to the other OOAD books that were around at the time. This would never be a book for Patrick - there's no code, it's all statecharts and models and Z like specifications ;-)

Maybe some of the authors attitude ("we are rather stubborn about precision") comes from their experience developing process control systems, and their experience with Smalltalk shows elsewhere:

"With cyclic development we set out to build a regular succession of working functional subsets of the system. This approach allows progress towards delivered functionality to be assessed, rather than progress against a theoretical plan. It allows the development team to respond rapidly to problems and opportunities that arise during the development process."

I actually like that book very much. I've had it for years. (See the last book on my list above. It's a good companion to this one, models *and* code!)

This is essentially it for me. A good, simple OO language (like Smalltalk, but Ruby or Python will do in a pinch) just adds a bit of syntax for organizing functions that "belong" together.

Who's Bentley?