Leaning how to judge the right tool for the job?

I believe that there are times when OO fits just right and can even be somewhat transcendent (if done well) and other times when FP fits just right and can be really transcendent (if done well), etc. But I'm not well versed enough to claim to know the nuances. Are there recommended texts which do a good job of boiling down this kind of experience and wisdom? I did just get CTM and started in on it! Could it be done with something smaller than CTM? :-)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Or being able to switch perspectives

I guess a far-flung idea would be that it could be neat if a language side-steped the question by supporting viewing the system in various ways: if you are adding a new type then maybe you want to see it as OO; if you are adding a new function across types then maybe you want to see it as FP; if you are debugging something (although much of the problems there are due to C++ specifics rather than general OO-isms, perhaps) then maybe you want things inlined as much as possbile so you can sort of linearly step through the source code.

What models of the underlying structure of the language would let us re-view things? The relationship between a function and what types it can operate upon, for example, could be used to re-sort the distance between things in 2D ASCII files.

The first step

Master tools that ease the pain of doing things you hate to do, but are forced to do frequently. Most programmers hate writing documentation, and should therefore master a literate programming tool like javadoc. If the job doesn't engage you, then make the job as painless as possible.

See also: No Silver Bullet: Essence and Accidents of Software Engineering by Frederick P. Brooks, Jr. Your comments about looking at things from different perspectives is covered by the section titled Invisibility. With regard to "inlining", I think people should read George Boolos's famous essay Don't Eliminate Cut, because it provides a mathematical discussion of what essentially amounts to inlining.

Could it be done with something smaller than CTM? :-)

I'm not sure it is the page count that makes something smaller. Some mathematicians claim that the Royal Road to Geometry was discovered by combining algebra and geometry, forming analytic geometry and thus creating the road the Greeks thought did not exist. The Greeks did not invent an algebraic language used for geometry.

Thanks for the thoughts

Regarding different perspectives, I was wondering this morning how much we've let the file system dictate what we do. It seems that some portion of e.g. the expression problem come down to "where is the code that I have to read and modify?" If we didn't have to search around in the FS then maybe this problem would be a little bit deflated - assuming we had good alternative ways to really look at things.

I think what I had in mind w.r.t. "something smaller" was perhaps to have something less theoretical and more a set of case studies. Like, "Chapter 1: A Grrreat Use of OO!" which shows why it works in a grounded manner, and how stupendously smooth and clean and easy it is to extends or rejigger or understand it all. And "Chapter 2: A Perfect Example of Leveraging FP" which explains how well it fits, and how you can do really transcendent things in that case. And "Chapter 3: No, Really, Prolog Rulez". And "Chapter 4: Oh No, Nothing Works Well in This Case".

Sort of an attempt to do some dharma transmission about how and when a given paradigm just *flows* (if: you know what you are doing, the chosen language doesn't suck, and the task is appropriate).

Smaller books than CTM you might be interested in:

* Of course, SICP. It doesn't present the programming paradigms per se, but it still remains one of the great works on the subject.

* How To Design Programs, by Felleisen et al--this book is SICP for the liberal arts major. :) An under-appreciated book on the subject--that said, this book isn't small.

* Mills' Theoretical Introduction to Programming is another interesting book in the same vein--it combines a good basic discussion of many of the theoretical underpinnings (logic, lambda calculus, other computational models, computational theory) with discussion on particualr programming paradigms and techniques.

It would be nice

It would be nice to have such a book, particularly for professional programmers. AS more FP stuff creeps into mainstream OO languages, I can easily imagine that a book like "Effective Scala" or similar could serve this way. "Effective Multi-Paradigm Programming in [X]" would be a lovely Addison-Wesley title.

Incidentally, I love your casual use of "dharma transmission". That brings a touch of authenticity that goes beyond the usual "Zen of programming" stuff... ;)

or a creative commons e-book?

Anybody want to submit a story?

Javadoc != literate programming

[Edit: meant as a reply to this comment by Z-Bo.]

A minor nit: Javadoc (although an excellent documentation extraction tool), is technically not a tool for literate programming since it doesn't, as far as I am aware, support "tangling" - someone writing Java code with Javadoc is still bound by Java's syntactic constraints on things like declaration order. Full-blown literate programming allows the author of the program to break the code into arbitrary chunks arranged in an arbitrary order (the order usually being dictated by clarity of exposition rather than language constraints).

Beautiful Code may be close

Beautiful Code may be close to what you have in mind.

"Functional Pearls" (many were discussed here over the years) fill the niche, as far as FP is concerned. The Fun of Programming contains some nice examples. Also as regards FP, see the famous "Why Functional Programming Matters"

Apt's Prolog tutorial has some examples that show the power of logic programming and unification.

Now why can't I think of anything celebrating OO....

Now why can't I think of

Now why can't I think of anything celebrating OO....

Objects and Systems: Principled Design with Implementations in C++ and Java by Bernard P. Zeigler. This book was written in 1997, and yet some universities are still using it as a "required text". Zeigler is well known for his book Theory of Modeling and Simulation, and he seems to consider object-orientation useful for research purposes.

I don't understand how Beautiful Code answers the question. Pontus Johnson and Mathias Ekstedt have written a book titled The Grand Unified Theory of Software Engineering, and it is freely available through Google Books. I like some of the points they make, but it's not a complete treatment.

I was referring to this

I was referring to this formulation of the question: I think what I had in mind w.r.t. "something smaller" was perhaps to have something less theoretical and more a set of case studies.

just an amusing quote

From a(n) Habitat retrospective:

An object-oriented data representation is essential. Taken at its face value, this assertion is unlikely to be controversial, as object-oriented programming is currently the methodology of choice among the software engineering cognoscenti.

For reference

It is shameful to see how

It is shameful to see how many of the new pearls weren't discussed here. The editorial team should be prosecuted for dereliction of duty...

Mea culpa

And I was just reading "Applicative Programming With Effects" today, and thinking, wow, this is a really fun paper, and then thinking, hmm, I don't think we ever had it on LtU, and then suddenly we had the whole list of Pearls, and now look at me: publicly shamed.

Hey, don't be too

Hey, don't be too dispirited, there's still room for posting stories about pearls that you want to single out for discussion! Redemption is just around the corner...

Probably because of

Now why can't I think of anything celebrating OO....,

Selective memory. (See the title of chapter 26). :-)

Nah, not really. I mentioned

Nah, not really. I mentioned the book since it seems to fill the description, but I think I am already on record here for being underwhelmed by it.