Conceptual Models of a Program?

retsofaj queries: "Almost all of the introductory programming books I've looked at focus on syntax, with possible digressions into a bit of semantics. What I haven't found are any great discussions that go beyond syntax and semantics and make it all the way to conceptual models. My goal is to develop a set of resources that can be used in an introductory course that teaches students programming starting with conceptual models, as opposed to starting with syntax."

"What I mean by conceptual models are how you think about what a program is (if a program can be anything!). Examples would be (all prefaced by "a program is made up of..."):

• flowcharts (structured programming)
• arrangements of opaque things sending messages to each other (OO)
• transformations of data structures (Wirth's view)
• state machines
• a knowledgebase (Prolog, etc.)
• algebraic operations on sets (Functional languages)

Of course this is just the list I've come up with off the top of me head. My questions for the community are therefore:

1. Who/Where/How are the different models of a program being taught?
2. What conceptual models do you use when programming (and where would I go to find out about them)?

I acknowledge that some of these are covered by UML, but UML seems biased towards the object model of a program, which seems to exclude things like knowledgebases and functional approaches."

Comments

Analysis/Design?

[Xtifr]

Perhaps you're looking in the wrong places? Introductory books on analysis and design would seem to me a better place to find an introduction to analysis and design than books on programming.

Programming (coding) is how you implement a design. By the time you get around to coding, I would hope that you already have the design worked out.

Or am I missing something here?

Re:Analysis/Design?

[Xtifr]

Heh, well, yes, far too many real-world projects are started without enough analysis or design. No arguments there. :)

But it sounds like this question was posed by someone who has recently discovered that analysis and design are important, and doesn't understand why programming books don't cover analysis and design in greater detail. Which is, to some extent, a bit like asking why books on carpentry don't teach architectural design.

Design Patterns

[abroadst]

I think a good text for a course on conceptual models for software is Design Patterns by Gamma, Helm, Johnson, and Vlissides. When I first came upon this book it really opened my eyes. Now I can hardly imagine trying to be a software developer without the perspective offered in these pages.

Re:Design Patterns

[MillionthMonkey]

Of course those GoF patterns can make life hell for the maintenance developer or app framework user, when people turn it into a contest to see how many design patterns they can fit into a single project. The overall "Design Patterns" philosophy is really "how can I defer as many decisions as possible from compile time to run time?" This makes the code very flexible, but the flexibility is wasted when a consultant writes code using lots of patterns to puff up his ego and then leaves without leaving adequate comments or documentation. Without insight into how the system works, the configurability and flexibility that these patterns offer is lost. The system hardens into an opaque black box.
Deferring decisions to runtime makes code hard to read. Inheritance trees can get fairly deep, work is delegated off in clever but unintuitive ways to weird generic objects, and finding the code you're looking for is impossible, because when you're looking for the place where stuff actually happens, you eventually come across a polymorphic wonder like

object.work();

and the trail ends there. Simply reading the code doesn't tell you what it does; the subtype of object isn't determined until runtime. You basically need a debugger.

You can take a really simple program and screw it up with aggressive elegance like this. Here is Hello World in Java:

public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, world!");
}
}


But this isn't elegant enough. What if we want to print some other string? Or what if we want to do something else with the string, like draw "Hello World" on a canvas in Times Roman? We'd have to recompile. By fanatically applying patterns, we can defer to runtime all the decisions that we don't want to make at runtime, and impress later consultants with all the patterns we managed to cram into our code:


public interface MessageStrategy {
public void sendMessage();
}

public abstract class AbstractStrategyFactory {
public abstract MessageStrategy createStrategy(MessageBody mb);
}

public class MessageBody {
Object payload;
public Object getPayload() {
return payload;
}
public void configure(Object obj) {
payload = obj;
}
public void send(MessageStrategy ms) {
ms.sendMessage();
}
}

public class DefaultFactory extends AbstractStrategyFactory {
private DefaultFactory() {;}
static DefaultFactory instance;
public static AbstractStrategyFactory getInstance() {
if (instance==null) instance = new DefaultFactory();
return instance;
}

public MessageStrategy createStrategy(final MessageBody mb) {
return new MessageStrategy() {
MessageBody body = mb;
public void sendMessage() {
Object obj = body.getPayload();
System.out.println((String)obj);
}
};
}
}

public class HelloWorld {
public static void main(String[] args) {
MessageBody mb = new MessageBody();
mb.configure("Hello World!");
AbstractStrategyFactory asf = DefaultFactory.getInstance();
MessageStrategy strategy = asf.createStrategy(mb);
mb.send(strategy);
}
}


Look at the clean separation of data and logic. By overapplying patterns, I can build my reputation as a fiendishly clever coder, and force clients to hire me back since nobody else knows what all this elegant crap does. Of course, if the specifications were to change, the HelloWorld class itself would require recompilation. But not if we are even more clever and use XML to get our data and to encode the actual implementation of what is to be done with it. XML may not always be a good idea for every project, but everyone agrees that it's definitely cool and and should be used wherever possible to create elegant configuration nightmares.

Re:Design Patterns

[JamieF]

Bravo! Fad coding is a very real problem, and in the OO world, over-abstracting and over-design-pattern-ing is a real problem, even though those aren't real words. :)

There are requirements that can make abstracted designs a good idea - things like i18n, which suggests that all the text in your UI should be ripped out of constants and put in config files. So in that case Hello World would need a way to read the config file in order to easily morph into Bonjour Monde or Hola Mundo or whatever.

I can't tell you how many times I've seen an object model in a project that starts with EVERYTHING being based on some GenericItem object that all the others inherit from, and GenericItem has no real value. The designer just wanted to use inheritance a lot. Oy.

I like OO and all, I just don't like OO developers who read 10 books on OO and try and apply 100% of what they've read in their first project... and spend all their time building more and more goofy infrastructure instead of actually implementing any functionality.

Re:Design Patterns

[spongman]

yeah, you have a point - don't try to write a class library when all you mean to do is write a program.

but on the other hand most tasks aren't as simple or well defined as 'Hello World'. remember the last time your boss/client said "hey can we change it to do [this]" and you groaned because [this] wasn't anywhere near the original spec and you knew how much work it would need to hack it in? at that point you're wishing you'd abstracted just a little bit more at the outset.

My corollary: the boss is always going to ask for something that you didn't expect. twice.

A Famous One Is...

[the eric conspiracy]

Structure and Interpretation of Computer Programs
by Harold Abelson, Gerald Jay Sussman, Julie Sussman.

Re:A Famous One Is...

[CMonk]

I'll second this one. Stop looking at programming books, if you want to learn Computer Science read Computer Science books. SICP is where I learned it all (in school).

Re:A Famous One Is...

[William Tanksley]

Agreed. This one's _essential_. In fact, I would go so far as to say I've seen no other choice; if you want to learn both how to program and how to think about programming, this is the only book which combines both.

The only problem, as I point out in another message, is that they almost totally ignore other conceptual models of programming; lambda calculus is thoroughly explored, but combinatorial logic and similar models, as demonstrated impurely by APL/J/K and purely by Forth/Postscript/Joy, are almost ignored. A good teacher would, IMO, base a class on SICP, but augment with two of the above languages and a discussion of their paradigms.

-Billy

How To Design Programs

[jrstewart]

You may be looking for the book How To Design Programs. I haven't read (all) of this book but I've learned a lot from the guys who wrote it. The complete text is online so take a look.

To Code Well - Write Code

[stoolpigeon]

The best way to learn programming is to do it. The more the better. And see what works and what doesn't.

You have to know syntax and semantics to practice.

To take the high road right off the bat is good conceptually but the problem is implementation is often where it gets difficult. I know a lot of people will disagree but I can tell you that the concepts behind something do not have a lot of value until the user has a level of experience that brings out that value.

I believe this is true across a wide range of disciplines - not just programming. If you tell someone that breaking in boots is important to hiking (w/out getting into a lot of messy details) they may listen they may not. If they sit at the end of a trail w/blisters all over their feet (or see a companion in that shape) they will value the information much, much more.

I've never found a conceptual approach to be nearly as useful before I've tried something compared to after those attempts.

.

Models

[Guitarzan]

Make sure they're not those terribly thin, Kate Moss-like models. Give them at least a little bit of figure, please!

Re:Experience!!!

[DrSkwid]

sorry but experience alone will not teach one the breadth of the subject. How, for instance, will one deduce that the re-written program would be better suited to a different programming paradigm if one has not studied the known paradigms?

Without reading about say, Functional Programming, how will one make the intuitive leap mearly by exercising the iterative.

Like *all* disciplines it is the combination of study and practice that will lead the way.

You have to learn arithmetic ...

[Daniel Dvorkin]

... before you can tackle algebra.

Students need to learn syntax before they learn (much) in the way of structure. It doesn't matter what language they first learn in, though I think something in the C family (i.e., C, C++, Java, etc.) is a good place to start, since a) most real-worl programming is done in one of these languages and b) if you can really, truly learn C, you can learn anything. ;)

But hell, teach 'em in Perl or LISP or Pascal if it makes you happy. The point is that programming courses have traditionally started out with "Hello World" or some such thing for a reason: beginning computer scientists need to learn that they can type in, compile, and run a program before they start worrying about higher-level structures. Any attempt to teach theory before practice will fail as surely as the "New Math" -- which basically did try to teach algebra before arithmetic -- did a couple of decades ago.

Hrm... can you teach people to think?

[vkg]

Although there are a lot of useful models like the ones you outlined, I'm not sure that there is any way to teach problem solving, and it's most important step, problem conceptualization.

I think you could take people through graded series of exercises soluble in different approaches, but there's no "one size fits all" way to develop intuition.

One approach used widely in architecture, a sibling profession if we ever had one, is "masterworks" - taking students through the works of other great architects, examining each decision made in some detail with reference to notebooks and discussions.

I think that this approach may make a lot more sense than teaching theory because it gives some access to an experienced mind, rather than just a methodology created by such a mind.

I know that I learned more from working with great programmers and absorbing their tricks than from any book I ever read or course I took.

Design Patterns, The Book

[Bouncings]

What you are talking about is software design patterns. I suggest Eddison Wesley's book on the topic of object orientation. There's less information on structured programming out there becuase structured programming isn't very trendy right now. New materials on cutting edge (yes, cutting edge) structured programming methodology is really only available on usenet and in people's code. For that, you are on your own.

I also would advocate you not to follow the dogma that object orientation is the holy grail of software. Be open minded to structured programming too! :)

Re:Design Patterns, The Book

[alext]

Nonsense. This book has nothing to do with IT fundamentals, OO or otherwise. As many people have pointed out, at best it can be regarded as a roll-your-own appendage to cover the flaws of current mainstream languages. This situation does not apply in academia - they can use any language they like.

Structure And Interpretation of Computer Languages

[William Tanksley]

The granddaddy of this type has to be MIT Press' SICP. It's a programming intro, but it teaches you lambda calculus as well as the problems with lambda calculus.

Lambda isn't everything, and a good teacher should also cover some languages which use it lightly (J and K) as well as a language which doesn't use it at all (Forth, Postscript, Joy) -- but it's good to have as a starter. SICP doesn't teach 'conceptual models', though; I don't think that the authors even realised there were other conceptual models out there. Most people don't, since most people don't even know that lambda calculus has almost nothing to do with how computers work, but is rather just the way most programming languages have been designed, in imitation of Fortran.

But I can't slam SICP. It may not cover other conceptual models, but it does a BANG-up job of covering the one it acknowledges, and even points out the weaknesses.

-Billy

Structure and Interpretation of Computer Programs

[alacqua]

Its been quite a while and a new edition since I read this book for a computer science class, but as I reacall the main thrust of Structure and Interpretation of Computer Programs was to focus on computer science concepts in a somewhat introductory class with a minimum of syntax. It uses the Scheme dialect of Lisp which, although it was quite alien to most of the students, does not force the programmer to get bogged down in lots of syntax rules and is quite powerful. I think the author(s) explicitly stated as a goal to get right into concepts and let the student absorb the syntax along the way. And you can read it online in addition to purchasing it at the bookstore.

I'm sure many people here are already familiar with it, but if you're not it's worth a look.

Best advice: Keep It Simple

[rufusdufus]

Getting too caught up in programming models early in as students training will almost certainly inspire them to build complex systems with huge over-generalized models. Programming models should come later, after basic syntactical and functional issues are addressed. The only model fledgling students should learn is to keep it simple. Teach them to solve problems with the least lines of codes possible, and the simplest data structures.

Structure and Interpretation of Computer Programs

[The Pim]

It's a beautiful book, and takes basically the approach you outline. I don't have it in front of me, but I believe it treats most of the models you mention, and always focuses on the insights they give you into programs.

It's the standard MIT intro text. Philip Greenspun called it the "one great book on the subject of computer programming". It's even online!

The only caveat is that students reportedly find it hard to absorb on the first pass--even at MIT. (This is second hand information--I didn't read SICP in a class, nor did I go to MIT. I read it after programming professionally for a few years, and loved it.)

How to Think Like a Computer Scientist

[bcrowell]

Check out How to Think Like a Computer Scientist. It's an excellent introductory book, and the digital version is also free. It does at least some of the kind of stuff you're talking about.

However, I think it would be a mistake not to teach any syntax at the beginning. Students need concrete examples, and the only thing that makes it fun to learn how to program is that you get to build actual programs that really do things.

That's a really clear book

[jabbo]

kind of like 'SICP for nonprogrammers' (\me ducks).

I liked the chapter differentiating generative recursion from structural recursion. That's a really insightful distinction in terms of the mechanics of grasping a problem and a good solution for the problem.

Definitely worth a read, although I think SICP is the cleverest (most intellectually satisfying) exposition of these little gems ever written.

I am reading (and doing) Paul Graham's 'ANSI Common Lisp' book for amusement and it's really sharpened my thinking. Macros are a great example of meta-generative-recursion, if you can call it that. Whatever you call it, it's raw power.

Another option

[jabbo]

I feel like Paul Graham's "ANSI Common Lisp" is more fun to work through (and makes my brain hurt somewhat less) than SICP. SICP is a really stiff book -- using that text for a class is a sure way to weed most people out. Graham's book, while very very intelligent and deep, is also a lot easier to grasp in many respects. Not a bad choice for 'SICP Lite' although that doesn't give it enough credit for what it teaches you about programming in the real world (vs. the computer-linguistics and mental gymnastics that SICP teaches you).

(Read the articles on Graham's site. They're friggin' amazing distillations of experience. If you've been programming (successfully) for long enough, you'll not only be pleasantly surprised, but will find yourself nodding in agreement whilst learning about new topics. Anyways, the book is an implementation of much of what he writes about, into his 'Mother Tongue' of Common Lisp. Hell, this is one of the few good writers who can correctly answer the question:

"If you're so damn smart, why aren't you rich?"

The answer, for anyone whose opinions you'd want to trust, is "I am", and it's BECAUSE of his opinions. :-))

...and read code!

[AT]

I agree, but also read code. There are lots of large projects with source available out there; grab it and find out how their authors did it, and note whether the approach is understandable, consistent, scaled well, etc. You can only write so much code for the sake of learning; also some designs lend themselves to larger projects, beyond the scope of a learning exercise.

Case studies are widely used in other disciplines like engineering, and they can be useful in programming too.

Old timer comment...

[johnlcallaway]

I've written code (as many others have) for 25 years, starting with Fortran and assembler on punchcards, working with TRS-80 Basic, spending several years with COBOL, using perl, Java, C/C++, and such over the last 10 years, and other languages to unique or propriatary to remember. The concepts that have lasted through all the languages and methodologies, from spaghetti assembler, top-down and structured COBOL programming and now object-oriented C++ and Java, are very simple.

• Break down what is being developed into very small components, and make them as independant of everything else as possible.
• Develop so that relationships between components can be easily understand to lessen the impacts of any change. (One hint to a student, can he envision a cube in his head and rotate it or unfold it?? If not, maybe programming isn't for him.)
• Write reasonably good, self documenting, maintainable code that is consistent. Teach that it might be easier to use 'i' as a variable in a short loop, but loop-idx or object_idx make more sense.
• Which leads into the next one, LEARN TO TYPE DAMMIT. Programmers spend their career at a keyboard, they should learn to use it efficiently. That means both hands and all the fingers. Throw in the feet if you can.
• Write self checking code that handles errors in a concise, yet informative node. I hate 'segment fault' type messages. Trap the damn things and let someone have a general idea where it occured and what dataset was being worked on if possible.

There are probably a thousand some concepts that should be taught, but these are a few off the top of my bald head that shine through.

Re:Old timer comment...

[w3woody]

While I agree with most of your comments, just one point from another ol' timer. (Though only 15 years...):

Teach that it might be easier to use 'i' as a variable in a short loop, but loop-idx or object_idx make more sense.

Research suggests that, for complex equations and/or complex operations, shorter variable names are more easily recognized than longer variable names. That's because most people who learned algaebra recognize patterns in the equations, and using longer variable names makes the equations harder to recognize.

Thus, "force = gravitational_constant * object_1_mass * object_2_mass / (distance * distance)" takes a little more time for the brain to parse than "f = G*m1*m2/(r*r)", even though they represent the same thing.

With this in mind, I would suggest that if the iterator of a loop was being used as part of a mathematical operation (such as an array index), perhaps using 'i' will make the code more readable. However, if your iterator is not being used as part of a complex equation or represents an object (such as a pointer in a linked list), perhaps using a descriptive name makes more sense.

Personally I tend to write:

for (i = 0; i < 10; ++i) a[i] = 0;

yet:

for (windowPtr = GWindowList; windowPtr != NULL; windowPtr = windowPtr->next) {
windowPtr->Update();
}

You get the idea.

Just my two cents worth.

Re:Old timer comment...

[vrmlguy]

I've said this before, but one of the best ideas that I ever encountered was that the length of variable names should be proportional to the size of their scope. So, one the one hand, this is OK:
for (int i=0; i<size; ++i) { ... }
(assuming that the "..." doesn't contain any braces), but function/method arguments should be longer, like this:
int createWidget(string name, billOfMaterials parts) {...}
and globally-visible items (like the class and function/method names above) get the longest names.

Re:Structure And Interpretation of Computer Langua

[bentini]

I think the authors of SICP realized there were other models out there, and I think they might disagree with the statement that lambda calculus have almost nothing to do with how computers work.

Sussman was a co-author on several papers, the titles of which approximated: "Lambda: The ultimate goto instruction." I think Sussman and Abelson know a lot more about cs than you give them credit for.

mod parent up (link to full text of SICP online)!

[jabbo]

Or use this one, if you must

SICP online (my god that background is ugly)

Not to be confused with the Society for Invasive Cardiovascular Professionals, mind you.

Everyone is different

[f00zbll]

Perhaps the most important thing about teaching isn't having a well thought out study plan. It's relating to the students and figuring out how they learn. This is where many instructors get it all wrong. Teaching isn't about theory or code, it's about taking a subject and making it approachable.

Some people prefer to read code. I definitely prefer reading code, because I think backwards and use non traditional techniques to learn programming principles. I prefer to deconstruct a piece of good code and work back to the theory that way. Some people prefer to understand the theory first and think about different approaches to apply it.

A good teacher is one who is able to adapt the study plan to the strengths and weaknesses of the students. People should stop thinking of teaching as a mechanical process. Teaching is a creative, organic process that changes both the teacher and student. There are many smart and talented people working as teachers, who can't teach worth a dime. There are great teachers who are terrible programmers. Finding some one who is great at both is difficult.

Perhaps you should be asking, "How do become a good teacher?" As Lao Tzsu taught, if a person wants to be a good teacher, first be a good student. The teacher has to be a student of the student to understand how and why a particular student fails, so that he can adapt the explanation/technique for that individual.

Ensure they know why...

[BMazurek]

Your suggestion is clearly different than what most students will be expecting their course to be. (I think it is very interesting and holds promise.) You should be up front about what you are going to do, and why. I think many students will be very frustrated otherwise.

Show them a couple of very simple constructs (like an if statement and a while loop), then show them the corresponding code in as many languages as you can. Build up in their mind that a computer language is just a tool to solve the problem .

The language you use to solve problems isn't irrelevent (some languages are better at certain tasks than others), but at this point in their programming career, it largely is.

Re:One problem is that...

[JamieF]

echo 5050

Amen to that ...

[Evil Pete]

He he he. Yeah I've been guilty of that too after I first came across patterns. But not for long having once had to wade through layers of inheritance. I still love patterns but Pattern Paralysis is a real danger for new projects these days. It can be a real liability if a System Architect decides to go down the path of aggressive application of patterns. Trouble is , so much of the abstraction is totally unnecessary , programmers being so smart that they practically obfuscate the code with "good" design.

Who needs to look?

[alienmole]

LEARN TO TYPE DAMMIT

Who needs to look at the screen? :-)

Look at the keyboard, you must not, hmmm?
Look at the screen, you must not.
Shut your eyes, you must.
Guide your fingers, the Force will.
Great coder, you will be, yesss.