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

[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...

[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.

.

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

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.

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. :-))

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.

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.