Programming Ugly

[Catfish]

Hey Cope, about this:
http://fulloo.info/t-files/C++Examples/Account1/Account.html

I don't like it. It doesn't compile with a standard C++ compiler. It's also huge. (Glad to see you fixed the cast macros, that was really classy.)

Could you please construct a real example: like three or four dummy classes and a main() in one file, just to highlight how the objects are supposed to exchange information under the DCI paradigm, please?

[Cope]

It compiles and runs here just fine with g++, with no fancy flags. However, I'm not in the compiler repair business. You might check with your vendor.

It's not my goal to give society a better "Hello World" program. This is about systems thinking and how to model complex systems. If I gave you a trivial example you'd entirely miss the point. Sorry. I really am. You're going to have to work. You'll have to think. I know it hurts. I had to go through it too. I don't know how to make it easier for you. That's the notion of paradigm shifts.

On the other hand, I'd expect a little more investment from you in doing the research, the reading, and gaining the understanding before coming back here asking for a fix of code after just a day or two. God help us if you started a cook in MacDonalds and thereafter decided to be a chef and come back here in a day asking for recipes. Or that you came back here asking for a quick example of post-modernist office building design so you can quickly understand it and start to use it. Maybe I can give you a rhyming dictionary and you can take up an avocation as a poet. Fingers can help you think, but in the case of a fundamental change of programming ideology it's good to get the brain solidly engaged for a few weeks first. That's what you're facing here.

I'll listen to what you have to say after making a few weeks of honest investment. It's the least you could do. I invested ten years in trying to understand this, and spent three more years working on a book for professionals to refer to. I can't afford to take every kid by the hand who comes along and wants to learn this.

It's very hard for me to get you to understand what you don't understand. You either have to wait for that (it will be a long time) or take a willfull dispension of disbelief. It isn't me who's trying to push this on you. You came asking how to learn. I'm telling you. And it doesn't relate to giving you the HelloWorld toy you seek.

I'm not trying to be mean, or Machiavellian, or pompous. I, too, had to go through a humbling decade of mastering these ideas. I first encountered them in a discussion with Trygve in France back in June of 1999. It has been an ongoing dialog since then, capped by three years of intensive joint research. I just know what it takes to learn ideas like this. I have a lot of formal training in learning theory, dozens of years of experience teaching exactly stuff like this, and a resulting insight that it's going to take someone like you a lot of hard work to let go of your current prejudices about OO and to understand DCI. Either trust me, or give it up. I wouldn't feel bad if you did; it's O.K. Every character I type here takes away from my time developing reference material for a broader audience — an audience that is working in community to understand further these ideas.

We know that the materials that are out there are enough. It doesn't help me to hand-feed individuals, and it hurts the broader effort We see more and more systems deployed using DCI. There are groups of people talking intelligently about it in network postings. I don't know if they are brighter than you or if you are brighter than them, but I do know that there is enough material out there to aid an adequately bright and motivated individual to master this. I can't do anything for you if you come up short in one or both of these categories, and experience shows that there is little more I need to if you have both.

[helios]

While I agree that Catfish's attitude isn't the best, I don't think you need to be so condescending.

[ne555]

There seems to be a problem with the html. They forgot to escape some characters so <> are interpreted as tags (like in includes or template parameters).
Please fix that, and if you could provide a download for the sources it will be great.

It's not my goal to give society a better "Hello World" program.

That's clear. Your style is awful.

[Cope]

That's clear. Your style is awful.

Then I'm not sure how the code will help. I wouldn't want to do any damage. You're on your own.

[Catfish]

Then I'm not sure how the code will help. I wouldn't want to do any damage. You're on your own.

Well, at least you tried your best.

Coming back from the Java world after a long exile, am I right?

#include SavingsAccoun.h;

You keep invoking experience when it comes to applying the new paradigm.
Maybe DCI is nothing more than the "old" OOP applied with more experience, giving the practitioner an eagle-eyed view or something?

Then you're absolutely right that there's no easy way for attain that level of proficiency.
But as a paradigm, doesn't DCI have a set of concepts or rules, that you can exemplify in a simple program?

[1vRz3TCk]

Cope,

Just so "I'm" clear, your are James O. Coplien, the writer or co-writer of:

~ Advanced C++ Programming Styles and Idioms.
~ Pattern Languages of Program Design.
~ Pattern Languages of Program Design 2 (v. 2).
~ Software Patterns.
~ Multi-Paradigm Design for C++.
~ Organizational Patterns of Agile Software Development.
~ Lean Software Architecture for Agile Software Development.

[Cope]

Maybe DCI is nothing more than the "old" OOP applied with more experience, giving the practitioner an eagle-eyed view or something?

Like Schroedinger's cat.

Then you're absolutely right that there's no easy way for attain that level of proficiency.

I don't think anyone would confuse what I said for meaning that it would be easy.

But as a paradigm, doesn't DCI have a set of concepts or rules, that you can exemplify in a simple program?

It's kind of like asking: Don't relational databases have a set of concepts or rules that you can exemplify in a simple program? Maybe, if you're already steeped in relational algebra. But it's very unlikely that C++ programmers would have had the exposure. It is in fact much easier with JavaScript programmers, and it's pretty clean in Ruby.

I tell people who want to learn "Restricted OO" to start in Smalltalk; it's too easy to develop bad habits when starting in C++. I would tell people who want to learn "Full OO," as Reenskaug calls it, to start either with Trygve's BabyUML environment or with Ruby. But, still, before that — do I have to say it again? — there is some booking-it to be done. Think of the analogy to relational databases.

I could show you an SQL program that illustrates how to use a database, but that doesn't mean you would understand databases. Similarly, I could show you the Context for a DCI program to do X, but that doesn't mean you'd understand DCI. My experience is that there is a lot of danger of trying to teach a new paradigm by incrementally building on an existing one. That's what leads people to say things like:

That fixes the role of each object ('he' turns into a subject -> the active part) and thus opens a new world. That is what I call object oriented.

Let's start with that as a touchstone. Let's say that I want to display a shape on a window. I have an inheritance hierarchy of window classes and an inheritance hierarchy of shapes. Where does the draw method go, and what are its arguments?

There is no clean way to do it in C++: each implementation has serious problems with coupling and cohesion. That's what led Cargill and I (pretty much simultaneously) to invent what today is called the Visitor pattern in C++. (It turns out that it was already there in the Smalltalk-80 image.) That and Singleton are the only patterns that Erich Gamma said he would pull from the book if they were to do it again — mainly because the only people who understand Visitor are consultants who are trying to impress their clients.

But enough of C++. Back to our story. What is the right way to write draw? In CLOS, one writes code that looks similar to a collection of overloaded C++ functions:

draw(Circle c, TiledWindow w) ....
draw(Rectangle r, TiledWindow w) ....
draw(Circle c, PixelatedWindow w) ....
draw(Triangle t, PixelatedWindow w) ....

The thing is that these method bindings take place at run time rather than following the C++ of compile-time overloading.

Is that object-oriented? To me, it is. It certainly doesn't fit the only definition for OO I've seen in this thread:

That fixes the role of each object ('he' turns into a subject -> the active part) and thus opens a new world. That is what I call object oriented.

DCI moves from C++ in the direction of multi-methods, through CLOS, and on. It is difficult to reason about these concepts in terms of what you know.

But all of this is written elsewhere. You'll find the pointers to it above. I'd encourage you to invest the time looking at it.

[Cope]

I apologize: there have been some updates to the Account.html file on fulloo.info since I last posted it there. I've made some quick patches until I can recover the sound version.

[Cope]

Cope,

Just so "I'm" clear, your are James O. Coplien, the writer or co-writer of:

~ Advanced C++ Programming Styles and Idioms.
~ Pattern Languages of Program Design.
~ Pattern Languages of Program Design 2 (v. 2).
~ Software Patterns.
~ Multi-Paradigm Design for C++.
~ Organizational Patterns of Agile Software Development.
~ Lean Software Architecture for Agile Software Development.

I'm not sure why it makes a difference. Your learning has to depend on your own judgment of the facts — not on who I am. Anyhow,

http://www.unc.edu/depts/jomc/academics/dri/idog.html

Or, more broadly and to the point:

http://www.computer.org/portal/web/buildyourcareer/Agile-Careers/-/blogs/dogs-on-the-internet

[firedraco]

This sounds a lot like string theory to me; you can't explain it until you know what it is...which in my opinion, makes it very useless if you can't explain it to a layman.

[Catfish]

DCI moves from C++ in the direction of multi-methods, through CLOS, and on. It is difficult to reason about these concepts in terms of what you know.

Object manager classes with overloaded member functions?

[Cope]

This sounds a lot like string theory to me; you can't explain it until you know what it is...which in my opinion, makes it very useless if you can't explain it to a layman.

Exactly right, in that you can't explain it until you know what it is.

The same was true for explaining your C++ style of OO to procedural folks. But the world moved on.

This is Part II — or, in the broader context of history, part N of many.

It takes work for those who learn it, to learn it. Just ask those who have already gone through it (there are about 250 on the mailing list).

A few of you have already probably been doing this (but almost certainly not in C++, and certainly not in Java).

Many of you have been doing something like this, and will argue that you have been doing it, but you've just fallen into the trap that is typical of any paradigm shift: of failing to see the leap to the new concept. Even Juroslav Tulach made that mistake and persists in that mistake. It's almost embarrassing (http://netbeans.dzone.com/videos/screencast-jaroslav-tulach-mvc?utm_campaign=Feed%3A+zones%2Fnetbeans+(NetBeans+Zone)&utm_medium=feed&utm_source=feedburner)

Some of you will be left behind.

Some of you will get it, but only several years from now.

There is little that I can tell you here that will make a difference one way or the other.

I do hold very little hope for those who persist on wanting to see the code right away without doing the literature reading that a good professional would do.

As someone who understands string theory (or at least I think I do) (and, by the way, also its likely demise) I can say that hard work pays off in understanding fundamentally new concepts. I can't say that explaining string theory makes it any more useful to a layperson, anyhow. But the fact is that dozens or hundreds of people have mastered DCI. There are some people so narrow-minded that they believe their inability to grasp a concept means that the concept cannot be grasped. Break out of that, and you'll find that you can apply it — as many others have already have found. Of course, many of them don't have the liability of a C++ background (I mean this seriously and not in a mean-spirited way — I'm a C++ guy, too). A potential good learning path for someone with the C++ liability is to learn the concept in a different language — that makes it more difficult for you to bring the old baggage along with you.

[Cope]

Object manager classes with overloaded member functions?

Good example. And the answer is: No, not really.

1. It's about objects, not classes.

2. It's not overloading, its multiplexed overriding.

3. They aren't member functions. They're syntactically reminiscent of C++ friend functions, but the semantics are those of Visitor: think of it as cascaded dispatch.

This kind of thinking is similar to one of the small building blocks of DCI.

[1vRz3TCk]

Cope wrote:

I'm not sure why it makes a difference. Your learning has to depend on your own judgment of the facts — not on who I am.

It really doesn't make a difference to me who anyone is (hell, I don't post anywhere under my own name as it doesn't matter) but I get the feeling that some here don't take 'extraordinary ' views without qualifications.

[Catfish]

From what I read so far, my impression is that DCI is a methodology promoting the importance of helper objects that link the working objects, and not so much a paradigm.

[Ben Bowen]

That Ben guy. What a failure, eh?

@Cope
Yup, that was a stupid remark. I was unusually upset and very frustrated when I made that comment... I didn't look too deep into the webpage, and once after I skimmed a paragraph which initially translated into "Register to read this." in my thoughts, I gave up and well...

It was a stupid comment; nevertheless. By the way, C++ isn't that bad really. It remains my favorite programming language, for now.

Embarassingly, I still haven't read your thesis. I'll start now.

Ben

[rapidcoder]

Saying:

SpellCheck sc("some long text to spellcheck", dictionary);


has two problems. First, it doesn't address the problem of the original use case — how do I alternate between checking the TextBuffer, a file, and some selected text? Second, I presume that dictionary is a pointer to some class. That couples the function to a class — that's static, compile-time coupling. That, again, is thinking in classes instead of in objects.

Wrong. The problems you list are artificial. Checking a File? Read the file before the call to spellcheck. Checking the selected text? Pass the selected text to the SpellCheck constructor. This is up to the caller, where he gets his string from. If you are afraid of performance, just replace a string with a character stream interface then it could be made to work incrementally, without reserving too much memory, and you could pass a whatever stream implementation you wish.

The second problem is also non-existent, because the dictionary can be just an interface (pure virtual class object) or a pointer to a function, so there is no compile time coupling.

[Cope]

These problems are artificial only to someone who views himself primarily as a rapid coder, rather than a thinker focused on the mental model of the end user and the team. To write code that extends the end-user mental model is the fundamental purpose of OO.

I want to see all of the sequencing code for the use case in one place so I can reason about correctness. Making the code readable makes it understandable.

Checking a File? Read the file before the call to spellcheck.

What piece of code reads the file? Can I reason about that code together with the rest of the use case? How do I instead spell check a text selection?

This is up to the caller, where he gets his string from.

The caller, dear programmer, is the end user. The end user isn't going to reason at the level of individual strings and the mechanics of passing them around. The end user will, at the most detailed level, think in terms of the use case I presented earlier. Object orientation is about getting that end-user mental model into the code. If you don't, you end up with dissonance in the interface — the kind of thing that happens when you try to insert a picture exactly where you want it in the middle of a Microsoft Word paragraph.

What you are proposing here does not implement the use case. It implements a programmer's vulgar understanding of what needs to be done, taking casual inspiration from the use case. That takes away my ability to reason about the correctness of the code.

I am not worried about the difference between streams and buffers — those are secondary concerns. Get the end user mental model right first, and then fit that to the programmer mental model.

The second problem is also non-existent, because the dictionary can be just an interface (pure virtual class object) or a pointer to a function, so there is no compile time coupling.

Again, I want to be able to reason about the algorithm. Outside the algorithm you don't know what the interface should be. Take a second and think about what the interface should be. Now, let's say that I told you that the algorithm has enough context to pass in the kind of word being looked for: verb, noun, adjective, and so on. That knowledge has to be part of the interface. Did you get that right? You could of course put that in the interface class (the ABC) but now, where does the code go? Are you going to extend the implementation of Dictionary to implement that new interface? Or can you use the existing interfaces of Dictionary to implement the API for spell checking? If so, where do you put the code that translates between the two? You could put it in your ABC, but then your ABC isn't A any more. That limits its utility. How do you contextualize that?

Again, your response is a caricature of someone stuck in a class paradigm, striving to understand the full object paradigm. And you are letting your heart talk, rather than your head. Many such people try to understand a new idea by pronouncing it wrong. I have found in life that it is better to first understand an idea before trying to improve or discount it. You aren't the first one in the string of DCI students who have gotten this backwards.

[Cope]

@Cope
Yup, that was a stupid remark. I was unusually upset and very frustrated when I made that comment... I didn't look too deep into the webpage, and once after I skimmed a paragraph which initially translated into "Register to read this." in my thoughts, I gave up and well...

You sure set the tone for the discussion.

I appreciate your reflection; you have earned my respect.