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

Experience!!!

[LinuxCumShot]

Experience is the only way to learn... write a program and its shitty, rewrite it and its less shitty... rewrite it again. Learn from your mistakes. You can't learn to program without practice. bling bling!!!

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.

Re:Experience!!!

[spongman]

The grand-parent has a point, experience is the most valuable asset in any project. Regardless of choice of language, understading of the problem domain, or design paradigm, the knowlegde that certain approaches just wont work well is invaliable. Of course, finding the one that works the best, is a different question, but there again, experience will often lead to the more correct answer.

Re:Experience!!!

[colvin_t]

Experience helps a great deal. One should not have to "rewrite" the program each time it doesnt work. Remember, preparation is everything. If you truly understand the problem and are familiar with programming concepts, you will be able to build a program that will do some, if not all of what you need. Granted, experience does play a part, but being a good programmer is, in my view, being able to understand concepts and use previous experience to write a good, solid, robust program.

Re:Experience!!!

[michael_cain]

I agree with the basic sentiment-- like any other language, you learn to write code by writing. The missing piece in your loop, particularly for beginners, is the editor who marks up their attempts, who tells them "this part is good" and "that part sucks". I was a self-taught programmer over 30 years ago and in that first six unsupervised months, I picked up bad habits that took me years to break. If you're just starting, get someone (hopefully someone who knows what they're doing) to edit some of your code.

Once you reach a certain level of proficiency, you can also progress by reading other people's code. Almost every language has some standard "idioms" for expressing common ideas well, and you can learn a lot of that from other people's code.

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?

[burnitall]

you're not missing anything, it's just that by and large design is done very quickly, usually on a white board, and almost always fails in some substantial way to fulfill the requirements.

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.

Re:Analysis/Design?

[angel'o'sphere]

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?


you're not missing anything, it's just that by and large design is done very quickly, usually on a white board, and almost always fails in some substantial way to fulfill the requirements.

What do you want to say by that?
That the designs you where somehow involved with where made like this? If so, its sad.
Or do you even like to argue: design is easy as you do it quick on the whiteboard? That would be realy depressing if that was your opinion.
Or do you even like to say that design allways fails? Then I dissagree!

Anyway, I did not whant to mock you!
When I started programming I learned to use flow charts and such to "design" my software. When I felt that I was a good programmer I started to omit flow charts and I never regreted it.
I asume "easy designing" is something everybody learned sometimes, likely found it even interesting but the more experiance one had he dropped it.
The false conclusion I made was: design is not worth it. It consumes time and does not give something back to the final product. I see this false conclusion repeated regulary, especially here on /. when "artists" claim UML and OOAD are useless. (Because the market leader in CASE tools has an overprised solution with questionable user interface and features :-) )

However since about 13 years I'm programming in OO. About 10 years I work with so called object oriented analysis and design. Since 5 years I teach it.
My overall programming skills are far better now, of course, as they were at the time when "I dropped designing". A typical one month one person project I indeed can do without design and without the risk of failure.
However, using a CASE tool and using the minimum A70% implementation. So at the moment where the new taught oo programmer likes to give up as he has spend 3 weeks mainly with A&D and only one week in coding and nearly nothing is visible of the end result the false conclusion "it does not pay off" comes up. If he sticks to the "right way" the last third of programming cycles will bumb out new features every day!

The bottom line is: 2/3 of software development activities should be THINKING! At first WHAT to implement - analysing - and then THINKING HOW to implement it - designing -. Only one third should actually be the implementing. If you use a CASE system, the implementation can indeed be that fast as you can generate the skelleton of the application out of the CASE system. If the CASE system is: paper and pencil ... well, then you are not THAT fast in implementing but you still should save a lot of time!

My picture above omits the key question: what about architecture? You need to have a reference architecture in mind or as experiance or as exiting framework. Without an existing reference architecture the crafting of a new software is 3 or 4 tmes more expensive then with it.

What is a reference architecture? Well, a LAMP(Linux, Apache, MYSQL, PHP) software is a typical architecture. A kernel is/has a typical architecture. A MVC based oo framework is a typical architecture. A knowledge base backed expert system like architecture is a typical sample. A scanner/parser/anylyser/generator/optimizer .... yeah, a compiler, is a typical reference architecture(more general: pipes and filters). A Tomcat/JSP/Servlet - JBoss/EJB - PostgreSQL solution is a typical architecture. (read Buschmann et al. Architecture Patterns, Addison Wesley). And so on. Well, the Tomcat/JBoss example is close to only resemble the technical infrastructure or technical architecture. You can and should distinguish between technical architecture and domain architecture. A&D should be constraint by the technical architecture and guided by a reference architecture and elaborate mainly the domain architecture ... hu?

Of course you can make a high level conceptual design before going deeper into the domain analysis. You need to do that if you have no reference architecture or experiance at hand.

Sorry :-) for the buzzwords, but I'm not an artist so far. After only 20 years programming experiance I consider my self to have just done the leap from craftmansship to engineering.

Regards,
angel'o'sphere

P.S.: you can book me in europe as mentor for oo technologies ... I speak better than I write :-) especialy german, LOL

It's simple, really

[cscx]

Teach them flowcharting and logic structures, i.e., sequential, conditional, looping, etc... They will be able to program in any language then... it's really easy to transition.

Re:It's simple, really

[crucini]

I haven't found flowcharts to be useful recently - they take a lot of space to cover simple things, and they implicitly describe "spaghetti" code - code which uses jumps or gotos for flow control. For small programs, I generally write the main() function first, keeping it short and clear and invoking a bunch of unwritten functions. At this point I effectively have the interface to those lower functions defined. If the program has to parse a source or config file, I may fill in dummy functions for some of the lower level and test the parser.

Then I flesh in the lower level functions, creating even lower ones where needed. I try to keep each function fairly short - going over 40 lines, let's say, could indicate that an unexpressed function is "swallowed" in your function. Longer functions are sometimes OK, and sometimes it's possible to factor out very short functions that have a clearcut, reusable purpose.

When I code in C, I often start by defining the data structures, but in Perl I haven't felt a need to do this since Perl's data structures are dynamic.

I hope this helps.

Re:It's simple, really

[ahde]

simple flowchart design:
steps are squares. decisions are diamonds. Use arrows for flow.

write objects as two lists:
methods/interfaces/functions/etc.
variables

start general and move to specifics.

Re:It's simple, really

[Tablizer]

(* We can write good or bad programs with any tool. Unless we teach people how to design, the languages matter very little. *)

The problem is that "good design" is rather subjective. 20 different experts will give you 20 different designs, especially in the OO world.

The procedural/relational world appears a bit more consistent IMO:

http://www.geocities.com/tablizer/bizmod.htm

I cannot find a similar way to describe OO biz app design philosophy that OO fans will generally agree with. If you can find one, let me know and I will recant.

(Note that I am not (yet) claiming this p/r approach is *better*, just that it appears more consistent from "expert" to expert. Then again, consistency is perhaps a part of "better".)

Simple, LOGO

[Anonymous Coward]

Make then learn LOGO.

If a turtle walking around the screen can't teach the fundamentals of programming, nothing can.

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

[Shamanin]

This is way beyond what an introductory course should takle. Design Patterns must first be recognized through sweat & tears before they can be truly understood and appreciated. Design Patterns offer the experienced software designer a common language to communicate their ideas to their peers.

Re:Design Patterns

[shoppa]

assuming that you have already conceived of your program as objects

While Gamma et al talk about these patterns from an object-oriented point of view, most of them predate the "OO language". We've been doing publish-subscribe, decorator, etc. for a long time, we just didn't use a OO language to talk about them.

Re:Design Patterns

[Tablizer]

(* While there could conceivably be design patterns for other conceptual models, I have yet to see such patterns collected into a similar work. *)

I have started documenting procedural/relational versions of GOF-influenced patterns at:

http://www.geocities.com/tablizer/prpats.htm

Personally, I find p/r versions of them simpler, and more flexible. In table-oriented thinking, a "pattern" is often merely a relational formula adapted to solve a need for a particular task. GOF tends to view them as global.

In GOF OO thinking, one tends to make the *code* resemble the pattern. However, in p/r one tries to factor potential relationships into formulas on tables instead of code shape. Changes are then less disruptive, because it is easier to change a formula than a physical code structure. And, you can have as many different such view-providing formulas as you need without trampling on one another.

Perhaps it is subjective. Developers tend to model their own mind more than anything external I have come to conclude after many heated debates. I just like p/r modeling better. I find it cleaner, more flexible, and less intrusive.

Relational modeling is as close as anything I have seen to reducing GOF-like patterns into a compact, virtual "pattern language". IOW, "pattern math".

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

[quantaman]

The second HelloWorld program looks like a tracing question off of one of my CompSci exams :)

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.

Re:Design Patterns

[angel'o'sphere]

Exactly what you find to be an advantage in your proposals is generaly found a disadvantage by OO programmers.

Your patterns are wrong applied, your strategy is exactly NOT a strategy, because you can't add a new variant of a step without modifying the original program code.

Design patters ín OO are mainly about: "NOT TO APPLY MANUAL CHANGES ON OLD CODE"
But by ADDING new code and making the new code able to interact with the old code.

Your other papers about comparision between OO and procedural are wrong as well.

You bring up a shape example and argue that the procedural approaches would be easyer to maintaine. Thats wrong.

If you invent a new shape you have not to modify one single point(in fact you create a complete new file and modify nothing in C++/Java etc.) but you have to change every single procedure to cover the new shape. The more "methods" or procedures a class/table(why don't you call it what it is? a record! its only a table in the DB and not in the programming language, there it is a record) have the more you have to change when a new shape gets added.

angel'o'sphere

Re:Design Patterns

[p3d0]

I disagree. Most of those design patterns are useful structures that can be employed in a variety of programs to solve recurring problems. Some are workarounds for C++ warts. But none of them are conceptual models for software.

Re:Design Patterns

[Arrgh]

Too much of a good thing might not end up also being a good thing?! Huh, I've never thought of it that way before. +1, Insightful!

Cute reductio ad absurdum anyway.

Re:Design Patterns

[angel'o'sphere]

Well Done!

But may I point out ... hu hom, you missed to use a Composite somewhere, or was it a Decorator? Yes, the decorator for the message in case you need a CR/LF or similar ending is missing.

You should have anticipated that, shouldn'd you?

He he, why did you get rated funny, I do not know, INSIGHTFULL would have been the right thing. And indeed it is, and it is funny, sarcastic and ironic as well.

I would bet you even compiled it, as I can not see a single syntax error :-)

angel'o'sphere

Re:Design Patterns

[Pseudonym]

Design patterns are nothing more and nothing less than a certain kind of engineering experience. If you're only writing trivial or small programs, you don't need them. If you're developing flexible medium- to large-sized applications or systems, the rules are different.

There are a number of differences between programming and software engineering. This has been one of them.

Re:Design Patterns

[Tablizer]

(* Your patterns are wrong applied, your strategy is exactly NOT a strategy, because you can't add a new variant of a step without modifying the original program code *)

What is an example? It is easier to add a table record than to add a class.

(* If you invent a new shape you have not to modify one single point *)

You did not read it very carefully. For one, most real-world things don't fit the shape change pattern. The rules of geometry don't change very often. However, in custom biz apps, PHB's don't care about math nor hierarchies. They will break a tree if they want to.

Second, the reverse is true if you add a *new operation* to each shape. You would have to visit and alter each sub-class in OOP. That is very intrusive. (And don't bring up inheritence, I covered that.)

I have been in many "change scenario" battles. OOP does not win unless you are delusional about forcing the world into mutually exclusive subtypes in a very artificial way.

OOP is a solution still looking for a problem that fits it.

Re:Design Patterns

[angel'o'sphere]

(* Your patterns are wrong applied, your strategy is exactly NOT a strategy, because you can't add a new variant of a step without modifying the original program code *)

What is an example? It is easier to add a table record than to add a class.


Example for what? If you add a nother case, (is that a table record for you?) you change the original program code. PERIOD. Design patters are about "how to avoid to need to change old code".

I have nothing against the point that you like Procedural approaches and prefere them over OOP.

But your samples regarding patterns, ALL OF THEM, are simply wrong.

You can program procedural for the rest of the universe time span and I do not care about that, nor does anybopdy else, its just your business to do so.


(* If you invent a new shape you have not to modify one single point *)

Its FAR more often that a further shape is added to your sample of shapes than that a new method is added. I unfortunatly once wrote a CAD system and later I wrote a CASE system. The number of shapes are not known offhand as the silly customer allways wants one more. The number of methods did not change often and if so it was easy to iterate over the files, as each class is in one file, and add the new method.

Adding a new method is absolutely no problem as you ADD something compleete new, its NOT intrusive as you do not affect your old test cases. Intrusion means by definition that all changed points need to be retested with ALL old test cases AND with new test cases for the change.
You do not add a new case label in a switch. You add a complete new method/procedure. If I use inheritance and have an abstract base class my compiler tells me if I ommit it at a single point to include the method or even the IDE does.
If I add a new method, I only write new test cases for that method I do not even need to retest the rest of the class. If I write a new class I only write tests for the new class I have no need to retest any old code.

If you forget in one of ten procedures to add a case statement, only your test will find it. A missing method is a compiler error, no test needed.

Your designs are so invasive to change that you can not even plan offhand how big a change will be and how big the impact might be and how many new tests you might need.

OOP is a solution still looking for a problem that fits it.

This is a silly statement. You where not even able to transfer the design patterns on your web site correctly from an oo language to a procedural language(which is possible, easy even!). How can you judge about OOP then?

I have been in many "change scenario" battles
If it was a battle for you, you better had used OOP and made a walk in the sunshine while refactoring your code.

I programmed nearly 10 years in procedural languages and I now do in OO languages since over 13 years. I have no problem that other people prefere other styles. But in their arguments they should stick to the trueth. You try to tell me that black is in fact white. But I can see, so I see you are either mad or a liar, white IS white and balck IS black. I do not care if you prefere white over black but be honest in talking about your preferences. The topic is indeed to interesting to bull around with it.

There are only 3 or 4 examples I found so far where a pure procedural solution was indeed favourable over a pure oo soluition. To bad that you did not even find those and cover them on your web site.

angel'o'sphere

Re:Design Patterns

[Tablizer]

(* Its FAR more often that a further shape is added to your sample of shapes than that a new method is added. *)

I wouldn't know, I don't program shapes for a living. In my domain, dividing things into "subtypes" is a disaster anyhow because it is a one-dimensional, mutually-exclusive division. Maybe "natural laws" can rely on such, but NOT man-made rules.

BTW, there are a lot of different ways to represent and classify shapes in practice. Sub-typing is only one of many. I showed how an oval can be a rectangle with 100% smoothing on it. IOW, manipulate an attribute to have all kinds of interesting in-between shapes. IS-A kills that.

(* You do not add a new case label in a switch. You add a complete new method/procedure. *)

Blocks is blocks. This is a name-game here. Methods are blocks nested within larger blocks (classes), and case statements are smaller blocks (case instance) nested within a subroutine.

You have a double standard going here.

Plus, you have more work if the options grow to no longer be mutually exclusive, which often happens in real applications.

(* This is a silly statement. You where not even able to transfer the design patterns on your web site correctly from an oo language to a procedural language *)

The pattern definitions are either vague or written with OO bias. If you can produce clearer definitions and show a concensus, I will reconsider.

(* There are only 3 or 4 examples I found so far where a pure procedural solution was indeed favourable over a pure oo soluition. To bad that you did not even find those and cover them on your web site. *)

How do you know that OO could not do them better? Did you run them by peers? If your OO is as bad as your procecural designs probably are, then you may be comparing bad OO to bad p/r.

(* If I use inheritance and have an abstract base class my compiler tells me if I ommit it at a single point to include the method or even the IDE does. *)

I addressed this already in the webpage. It is very language-dependent and potentially harms inheritance since the compiler does not know whether you meant to inherit or not.

Re:Design Patterns

[angel'o'sphere]

Blocks is blocks. This is a name-game here. Methods are blocks nested within larger blocks (classes), and case statements are smaller blocks (case instance) nested within a subroutine.

You have a double standard going here.


So: how do you call a specific case label inside a specific procedure?

How do you guarantee that all other old case labels do not get broken by a change?

Its hard to discuss if you use your own invented terminology :-)

I have no double standards. Each language provides some kind of "first class citizen". In procedural languages this are procedures and IMHO you can add records. In OO languages this are classes and IMHO methods.

From both you can take adresses, from the objects and the variables declared from a record type, as well as from procedures and methods.

Everything wich is smaller is on a different level. So your argument: "everything is a block" is rather weak. How to put the statement behind a case label into a variable and call/execute it stand alone?


How do you know that OO could not do them better? Did you run them by peers? If your OO is as bad as your procecural designs probably are, then you may be comparing bad OO to bad p/r.
Hey! you should appologize now. This is a personal assault. Why did you do that? Went out of arguments? *I* did not *make* the procedural desigs. I *found* them, they where made by others. I'm a known expert for OO design ... so its silly to asume I make *bad* OO designs.

As far as I can follow your argumentations you are not even an procedural programmer but a data base centric programmer, probably a relational programmer? Probably that is the cause for your dislike of OO?

At least it would be an explanation why you mix/switch terminology.


The pattern definitions are either vague or written with OO bias. If you can produce clearer definitions and show a concensus, I will reconsider.
Sure, if 'C' is a suitable language and you pay me, no problem.

Anyway, your main thesis is: OO is bad and procedural is better. This is not prooven on your site because for nearly every sample weak points spring in mind as they generaly are samples where a oo purist would say: no no, exactly what you bring up as good is BAD. The goal in oo is to craft a program which knows nothing about the data it manipulates.
No if "field of record" == xyz, no switch(var.field) case a: ....
In a perfect program you had no such if and no such case.
Another prime goal of OO is to write libraries which become OLD code and are able to call the NEW code of an application program. Not as in procedural code where NEW code is calling OLD code. In OO the goal is OLD code calls NEW code.
This is not doable with procedural programming (well, you can use a procedural language to implement an oo design, but then you are programming oo in a procedural language and no longer procedural)
As far as I understood you, not the language but the paradigme is what you dislike, right?

BTW: oo also fits business applications :-) So far no problem domain is known which is not suiteable or which would not benefit from oo approaches.

angel'o'sphere

Re:Design Patterns

[Tablizer]

(* So: how do you call a specific case label inside a specific procedure? *)

routineWithCase(theCaseArgument)

Besides, you are comparing apples to oranges here. You are asking how to make one paradigm resemble another, which is not the goal. Does OO do OO better? Well of course!

(* How do you guarantee that all other old case labels do not get broken by a change? *)

How do you guarentee that you won't break *nearby* methods? How are nearby methods less fragile than nearby case blocks? I don't know what kind of finger movements you are envisioning, but I see no difference. Blocks surrounded by blocks in both cases.

(* Hey! you should appologize now. This is a personal assault. *)

Okay, you are right. It was uncalled for. I apologize.

But, the point I am trying to make is that I don't know that quality of what you are comparing. You may have seen bad procedural all your life. Perhaps one of the few benefits of OO is that it made some people *care* about software engineering. However, just because it raised awarness does not mean it solved it. OO hype has distracted attention away from procedural engineering study and training. IOW, a self-fullfilling prophecy.

(* As far as I can follow your argumentations you are not even an procedural programmer but a data base centric programmer, probably a relational programmer? *)

IMO, procedural and relational fit well together. OO and databases tend to fight over territory and get tangled up in paradigm translation, the seperation of data and algorithm issues, and/or sharing issues. (I agree that there are flaws with some existing relational standards, vendors, and habits, but that is what we have to live with right now. Most these flaws are not paradigm-intrinsic.)

(* your main thesis is: OO is bad and procedural is better. *)

Wrongo! I believe it is *subjective*. OO better maps to the way *some* people think IMO. Just not my head. More on this below.

The point is that the industry *assumes* that OO is "better" and tosses procedural without first providing evidence. The lemming/bandwagon/hype factor.

(* This is not prooven on your site because for nearly every sample weak points spring in mind as they generaly are samples where a oo purist would say: no no, exactly what you bring up as good is BAD. *)

Perhaps, but the OO proposed by such "high level" gurus is often a tangled, overengineered mess. (Engineered for the wrong or unrealistic change patterns, IMO.)

IOW, it is the cliche simplicity of OOP which sells it, but to actually make it work in practice, you have to make pretzel code that is worse than what came before it. OO-Visitor has been called the "whipping boy of patterns" and rightly deserves it.

(* The goal in oo is to craft a program which knows nothing about the data it manipulates. No if "field of record" == xyz, no switch(var.field) case a: .... *)

Then assign it to a local variable first. Binding to a class can also be change-unfriendly (a mini Demeter sin). My technique of programming tends to "translate to indepedence" at the task level instead of at the entity level (OO's approach). I often talk about the "liaison layer". This provides "local translation" instead of the *global translation* of OOP. A one-size-fits-all hiding is not good. Make it local, and you have simpler interfaces and more flexible interfaces to deal with.

This allows information to "jump entities" with little or no impact on the application code. In OOP, if you move a peice of info from one class to another, it has a bigger rippling affect. (I called this the "noun shuffle" on my webpage.) See Also:

geocities.com/tablizer/bizmod.htm

(* Another prime goal of OO is to write libraries which become OLD code and are able to call the NEW code of an application program. Not as in procedural code where NEW code is calling OLD code. In OO the goal is OLD code calls NEW code. This is not doable with procedural programming *)

Could you privide something more specific? A routine call does not care if the routine is old or new.

(* BTW: oo also fits business applications :-) So far no problem domain is known which is not suiteable or which would not benefit from oo approaches. *)

Ed Yourdon did surveys and it was reported that OO offered no detectable advantages. (Actually it started out with advantages, but this faded, possibly because as OO went mainstream, the programmers were less likely to have an OO-mind-fit. IOW, it backs my subjective claim. It also suggests that if you want better designs, then let or find programmers use tools or techniques that best fit their head as long as they can justify the change-impact dicisions/tradeoffs they are making.)

Re:Design Patterns

[Tablizer]

(* For example, can anyone *not* tell from reading the 'main' function in the compelx example what it is supposed to do? *)

Only because the class name gave it away. If the class was named poorly, then one would be hosed.

BTW, it's sometimes best to save the translation for other output devices as a later step IMO. IOW, don't try to integrate it into the thing that generates it. Put it first in some cononical or meta form, such as in a table record. If you later need to send it to a different device, then read it from the table.

The mechanism that writes it to the table then does not have to care about how to send it.

In some ways this is similar to UNIX piping philosophy.

One problem is that...

[Steveftoth]

most people who can program already, did it the hard way by just simply diving in and doing it until it works. So it's very hard for people like that to go back and say what would to have worked better since they had to figure it out by themselves.

Programming is a process and modern US school don't teach processes at all. They teach you what 2+2 is, not how to add numbers. If someone figures out how to add on their own it's not cause they were taught it in school. How many people can add up all the numbers from 1 to a hundred quickly?

but not to make this a pessimistic post, I would say that teaching others how to program is probably best started with a flowchart type modeling, since that is easy to understand and can be represented graphically and then easily turned into code.
State diagrams are harder to understand at first, but once you get them they are very good tools for writing programs.

Re:One problem is that...

[jabbo]

> How many people can add up all the numbers from 1 to a hundred quickly?

I can...

$ perl -e 'foreach $i (1..100) { $sum += $i; }; print $sum . "\n";'
5050

Probably should have done this recursively for brain calisthenics, though ;-)

Re:One problem is that...

[jabbo]

$ perl -e 'foreach $i (1..100) { $sum += $i; }; print $sum . "\n";'


Why waste all the CPU cycles:

$ perl -e 'print (100+101)/2;'


mmm,

$ perl -e 'print (100+101)/2;'
201$

Probably not the result you wanted, definitely not a useful result, and points out why you need to understand syntax (operator precedence) as well as structure...

Re:One problem is that...

[JamieF]

echo 5050

Re:One problem is that...

[spongman]

shows my perl is fucked up, basically.

Re:One problem is that...

[maxume]

or come up with a superior algorithm...

0...100 is comprised of 50.5 sets of numbers that add up to 100, so do 50.5 * 100 = 5050.

That seems a little simpler, I guess, but who cares...

Karel The Robot

[critter_hunter]

Sortof like a modern, complex Karel in other words ;)

Worm's eye view

[Inthewire]

I started programming because I had a problem to solve. I focused on what I wanted to accomplish, not syntax or method or anything else. That isn't to say I didn't think about things like modularity, clarity, documentation, testing, etc - I did. I read a lot of the common texts - Brooks' _Mythical Man Month_, McConnell's _Code Complete_, Raskin's _The Humane Interface_, Spolsky's website, and a host of articles. I didn't start out with a language in mind. I started out with a result in mind. All of those things helped me to understand that my program existed to solve a problem. It wasn't there to keep me busy. I wasn't writing it because I wanted to use every neat trick I'd ever heard of. I was trying to make my life, and the lives of those around me, easier. I don't know how well I accomplished that, but I did build a program that did what it was supposed to do.

Re:Worm's eye view

[einer]

I did build a program that did what it was supposed to do.

Well, you're one up on Redmond.

Andrew

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

Re:A Famous One Is...

[hatter3bdev]

I found this book online here if anyone is looking for it.

Re:A Famous One Is...

[William Tanksley]

Well, I'm impressed! That is indeed almost exactly what I was hoping for.

I'm going to be spending some time reading the draft. The intro slideshow lacked something I was hoping for, though: it's based almost entirely on the lambda (variable passing) model. Are all your concepts built around that, or do you have some dataflow programming (as in APL/J/K) or concatenative programming (as in Forth/Postscript/Joy)? If so, your book would be of immense use to me, since I'm attempting to research the properties of concatenative languages (a shamefully neglected area of computer science).

Thanks for the book! I hope I can afford the hardcopy when it comes out... That looks like it'll be an INCREDIBLY massive tome. I'm not even going to be able to print it out, it's so massive.

-Billy

Re:A Famous One Is...

[William Tanksley]

I never heard of the term "concatenative languages", can you give a good reference?

Sure thing. Check out the main Joy page. The mailing list linked to from that page is also a very good resource.

I have programmed in both Forth and PostScript; they are incrementally compiled languages with a postfix syntax and no static typing.

Non-incremental Forth compilers are not uncommon; most people never use Postscript incrementally. A strongly statically typed variant of Forth exists (strongForth). And finally, although both do use RPN, they do not have a true postfix syntax; they lack syntax of any kind. Postfix syntax _requires_ that operators appear after their operands; RPN doesn't require operators and operands to have any static relationship.

The important distinction that the two languages share is that

1. any concatenation of valid programs produces another valid program
and
2. any dissection of a valid program produces two valid programs.

(Condition #2 is the equivalent of "referential transparancy" in lambda-based languages: it's nice to have for reasoning, but there are some handy things to have which make it impossible sometimes.)

Concatenativity implies a whole different set of rewriting rules, some of which are quite powerful compared to the applicative/lambda rewriting rules. It turns out to be a whole different way of thinking.

And as a bonus, the implementation is very simple, fast, and highly optimizable. Because data is managed by the programmer on a stack, the compiler doesn't have to guess what datum is more important than which other one; the stack provides a total ordering, and if the compiler can simply provide faster access to the top of the stack things speed up a lot.

-Billy

Re:A Famous One Is...

[William Tanksley]

Joy is just another language; I'm not convinced it's done right any more than Forth is. The interesting thing on that page isn't Joy itself; it's the conceptual background which the author builds up to describe a set of languages which lack application of functions to parameters.

But, other than being implementable in just a few kilobytes, what's the advantage of the Joy approach? It seems to be a rather tortuous way to write functional programs.

An excellent question. I could answer it by giving a list of advantages, but I think that would be beside the point.

I do not wish to imply that there are no disadvantages, nor that concatenative language are 'better' than (traditional) applicative ones. I simply wish to demonstrate that the differences between the two camps are real and useful, not mere obfuscation for its own sake. Concatenative languages should be an object of study, and more languages should at least include a concatenative subset, just as many languages now include a purely applicative subset.

Note your own saying -- Forth is fun. Why shouldn't we use languages which are fun? Why is Forth fun, and would it be possible to separate its fun from some of the admittedly inconvenient features?

My goal has been to try to answer those questions.

I'm not going to try to do that in this short space; but I will note a few convenient features of concatenative languages.

All of their typographical rewriting rules apply regardless of the semantics of the words making up the program(s). It doesn't matter whether the words modify state, do I/O, or anything else. So, concatenative languages can ALWAYS be typographically analysed. This is a HUGE improvement versus applicative languages, which contain a number of rewriting rules that only apply in special semantic cases (for example, the famous "referential transparency", which only applies in a very narrow context). This reduces many refactorings to a simple case of cut'n'paste. It also helps explain why Forth engages the mind in a way other low-level languages cannot: in spite of its native low level, it's easy to reason about its programs.

The textual nature of the rewriting rules makes metaprogramming in concatenative languages very easy (as I mentioned elsewhere, it's no accident that reliable Postscript can be generated easily by even C programs; imagine how much more powerful programs can be generated by a language aware of its own rewriting rules.

The data structure required to represent code is very simple. In Lisp it's a tree; the forks represent parameters of a function call. In concatenative languages it's merely a list: one action, then another, then another.

The only known means to make a language concatenative is to use a stack. This happens to not only make implementing the language trivial; it also makes a number of very useful results trivial.

Compiling requires no parsing, only lexing.

Strong polymorphic static typechecking can be done in the compiling pass, with no lookahead or behind.

Dataflow analysis is already done by the programmer, so the compiler can use the intelligence of the programmer to help it do its job of resource allocation. Urgently needed items are at the top of the stack; less urgently needed ones are at the bottom. Cache the top of stack in registers; page the bottom out; put the items between in varying speeds of memory, depending on depth in the stack. The only task for the compiler is to know the resources of the computer it'll be running on, so it can allocate the caches properly.

If you'd like a better answer, please ask the question on the concatenative language mailing list. It's a very good question, and will get an answer from many, including myself.

Slashdot just isn't really appropriate :-).

-Billy

Well ...

[Anonymous Coward]

... maybe I'm just a bitter old bastard (ah, you kids, with your IDEs and source-code control! You don't *know* how good you have it!), but it seems that too many comp-sci programs, to say nothing of the autodiadacts who start out on the "24 hours to a six-figure-salary developing Unix device drivers" books, ignore the fundamental abstractions that underlie all computing.

That having been said, it's not too hard to find good texts that cover these issues. Knuth's opus is only one example; there are several good books on algorithm design and analysis that are recent enough not to suffer from the "provably correct" disease of the '70s and '80s, and there's probably dozens of books by now that are part of the Booch series on OO design. Plus the hundreds of excellent texts on linear algebra and other basics.

Is it necessary to *start* with these? Well, I'm a fan of a two-track system where students are given both theory and praxis, allowing them to apply the former by way of the latter. You can learn theory without application, but chances are you'll end up with something like Python (/me ducks and covers); you can also learn application without theory, but then you get ... well, most Microsoft products, for example.

Just US$0.02 from The Watchful Babbler.

Java Design Patterns

[peterdaly]

In the Java "community", design patters are very popular as building blocks to build functional programs. There are many books available the the subject. One good one is EJB Design Patterns: Advanced Patterns,..., written by one of the guys who runs The ServerSide.com which also has a less formal discussion forum centering around design patterns.

While many design patterns are specific to good J2EE design, and may not be relevant for all types of application, many are general enough to be used in any object oriented language. May be part of what you are looking for.

-Pete
(yes, the book link has my amazon id in it...click and buy the book. It's worth having.)

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.

.

Re:To Code Well - Write Code

[Blackjax]

I find it frustrating to see people like the original submitter trying to do something like this. It is a fine example of someone with lofty ideals and noble intentions who is determined to not let reality get in the way of how things *should* be. Because if we can just teach them the wisdom *first* we can save them the time and effort of having to achieve it themselves! As the parent of this post points out, it doesn't really work like that. It would be really nice if you could teach most people the abstract theory and concept behind good design and development practices, but the truth is that you really appreciate why something is right by having done, or seen it done, wrong yourself.

If you have never developed before, the conceptual underpinnings will be largely meaningless. Sure, students can and will learn what you're teaching by wrote, but the information is not *real* to them yet because they can't make the connection to anything within their experience. Further, they won't retain it long enough for it to be of value later when their development skills catch up enough to appreciate it. So it is all well and good to say 'teach the abstract stuff first' but you're just going to frustrate them and yourself. It's like trying to give the benefit of your life experience to a teen by lecturing them. It's just words to them until they come into that wisdom on their own someday and finally 'get' what you were trying to tell them.

Re:To Code Well - Write Code

[Twylite]

You are discussing the difference between maths, engineering and social science. Programming can unfortunately only be described as a social science subject.

In maths you are presented with the result (the theory), and then with the proof. You don't need to satisfy yourself that it is correct emperically or "in the real world" or that its better to do it that way. Its proven.

In engineering you are presented with the result. You don't care about the proof, because you know that there is research and proof underlying the result, and you use the result in the recommended way to achieve those ends.

In social science everyone has their own theory. Some people rise to the top of the pile, and get continually picked on. Occasionally someone provides sufficient emperical evidence to justify the result being called a fact within the subject's domain.

This is the case with subjects like psychology and computer science. There is always more than one way to do or interpret something, and ego dictates that you must contest "accepted facts", and either derive or disprove the result for yourself.

Programming SHOULD be taught as an engineering subject. There is a body of knowledge for programming according to the conceptual model in use, and it is based on hard evidence from decades of development.

Unfortunately, software engineers prefer to make their own cement rather than ask the expert cement maker for the properties of the cement that is readily available.

Re:To Code Well - Write Code

[Twylite]

I'm hardly surprised. How can you understand functions and procedures without understanding the conceptual model of a functional program? How can you understand pointers, references and pass-by-value without understanding the execution model behind the program?

To teach, you have to start at the beginning. Programming is the means, which comes in just before the end. The approach of teaching students how to hack their way along in a visual language is a primary cause of the number of inept developers, and gives our profession a bad name. Bookkeeping is a well-established profession: if you get a useless bookkeeper, you blame the person or the institution. A useless developer is assumed to be par for the course.

Programming courses need to start with the most basic topic: what IS a program. Then the theory of how programs run (jumping around to repeat bits of processing, and varying the processing with parameters). Followed by how we achieve that using source code and a compiler.

Only then can a student appreciate and understand what they are going to be doing when they "program".

Re:To Code Well - Write Code

[p3d0]

5, Interesting?? This is off-topic. The question was not how best to teach programming.

Everyone knows you can only get good at programming (or anything, for that matter) through practice. That is not insightful, nor interesting. It's patently obvious.

Re:To Code Well - Write Code

[p3d0]

I find it frustrating to see people like the original submitter trying to do something like this. It is a fine example of someone with lofty ideals and noble intentions who is determined to not let reality get in the way of how things *should* be.

I would say the exact same thing regarding your attitude. Don't let the fact that students might not even know what a program is get in the way of your lofty notion that all you need to learn to program is to practice.

Would you tell a potential pianist not to study music theory?

I think a programmer's competence is a product of three factors:

• How much code you have written
• How much code you have read
• How much theory you know

Set any of these factors to zero, and your competence will also be zero.

Re:To Code Well - Write Code

[p3d0]

Teach the students how to use a tool (language syntax), then once they are comfortable enough with it that it is not a source of confusion for them, teach them how to apply that tool wisely. As for pianos, it is the same. There is a time for basics and a time for higher level abstract theory. Basics first, theory later (when it can be usefully applied).

Ok, I think we're pretty close to agreement here. We just differ on what we think of as "abstract theory". I bet people learn what a "note" is on their first piano lesson. (Mine was too long ago--I don't remember. :-) Likewise, people should know what the heck it is that they are building with all this syntax.

What is the point of saying "a function body is enclosed in curly braces" if they don't know what a function is, or why they would want one to have a body?

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:Practicum first, then theory

[cscx]

Introducing C as your first example is probably a bad idea.

For i = 1 to 10
Print i
Next

is a whole lot easier to understand than

for(i=0;i<=10;i++)
{
printf("%d", i);
}


for newcomers to programming.

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.

Re:You have to learn arithmetic ...

[happyclam]

While that's true, a lot can be done with beginners in a pseudocode type of "language" that does not actually get run. I recall my first "programming" exposure was BASIC in 7th grade math. We had no computers, and this was shortly before the Apple ][ came out. We wrote very short programs on paper which were then essentially traced by hand by the teacher.

Still, as a beginner with zero exposure to programming at the time, I learned a lot: linear processing of commands, simple loops, printing, and yes, even some syntax such as line numbers and labels.

(back to my point) Pseudocode can help teach the logic and flow and structure aspects of programming without the burden of having to follow syntactical rules at the same time. So, the first step should be to write out the "program" in a lightly structured pseudocode; the second step would be to "compile" that by hand into actual code when syntax had been covered. At that point, the fundamentals of the logic are out of the way and the students can focus on getting the syntax right.

When I think about how my projects have been completed in the real world recently, this is essentially the same process I go through: map out the general logic (either in prose or with a type of pseudocode shorthand) and then program the thing after I've got that worked out.

Re:You have to learn arithmetic ...

[GigsVT]

Learning C is very easy, it's a simple language. Learning to do something useful in C is the difficult part. :)

Re:You have to learn arithmetic ...

[binaryDigit]

To me it's kinda like woodworking/carpentry. You could either teach the students all about the tools, how to use them, etc, etc and then start teaching them about "concepts" such as joints, styles, etc. Or you could show them various pieces of furniture and how/why they were built that way, and the various features, then you could get into how to build it. Both ways have the pluses and minuses. What I like, is a mixture, just like woodworking class. Show me how to use the tools, but show me how with "concepts" in mind. e.g. show me how to use the table saw by letting me cut pieces/create rabbits and making a simple drawer. In this way, you show them the syntax (which for similar reasons to those who have already mentioned this), but also start to slowly feed them concepts and algorithms. What I _don't_ like are things that start off with syntax, but use lame/non useful examples to practice the syntax on. Have them create "real" stuff right off the bat (like the drawer, don't just have'em cut wood).

What I've seen of the "current crop of programmers" is that they are not very good with fundamental concepts and they are especially bad a breaking problems down and then applying the tool (whatever language/programming "style" that happens to be). So I know guys who know Java like the back of their hand, but when it comes to solving problems, they don't know _how_ to think about solving it. I also know some masters grads who can talk algorithms and concepts till their blue in the face, but they couldn't actually implement it if you wrote half the code for them.

Re:You have to learn arithmetic ...

[Eil]

Mwahaha, couldn't agree more. I'm still a rather inexperienced programmer and while I've dabbled in various languages, C is definitely the one that makes me shudder. They present it to you easily enough... at first. Ya know: These are variables, this is an array, these are for loops. And then all of the sudden its "Oh my god, how do I use pointers! How to define a structure?! HOLY SHIT, IF THIS 5-LINE FUNCTION SEGFAULTS ONE MORE TIME I'M GOING TO MURDER THE ENTIRE PLANET!!"

I'm sure we've all been there.

Re:You have to learn arithmetic ...

[pnatural]

Your comments about pseudo code are spot-on.

However, that pseudo code can actually be run if it's done in Python. Python is often described as "executable pseudo code". The syntax is very clear and very simple, but it is also amazingly powerful. Check it.

start lower than you'd think

[Pauly]

If this is a truly introductory class, please do what my first programming teacher didn't do: take a few classes to explain what the hell "programming" is. I went through a lot of confusion making the connection between words written into a file and behavior later when executing that file. Granted, this was a long time ago, and I had never sat behind a computer until my first lab in that class, but I imagine this is still a problem for most first timers.

In my case, I was able to fall back on my considerable experience with logic concepts and advanced mathematics. Fortunately for me, Fortran behaved(s) itself in this regard and allowed me to apply these concepts. I learned that this text needed to be processed before running it, but I had no idea until I started studying C what the hell those steps really meant.

Students today already have a bunch of assumptions of what computers are/do, so I imagine you'll have to help them unlearn some of that limited perspective. They also probably haven't learned a great deal of formal logic, so they might need some instruction there as well.

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.

Re:Hrm... can you teach people to think?

[vkg]

Let me suggest an example: RMS's config utility for Fetchmail. It's in Python, is relatively simple, and he's well on top of his game.

Plenty of changelogs available, and he'd probably talk you through a big chunk of the design process if asked nicely.

I do think that people can change the way you think about things, but I think 90% of the time it's done by "call-and-response" - you ask a question which reflects your current state, then they emit a response which changes your current state into some new state, and you fall on your ass wondering how you could have lived not knowing the world could be seen like that: code gurus.

Our models of education, alas, assume this is to happen by chance during lectures based on rough ideas of the makeup of a class.

I think the best programming education of all is apprenticeship and the open source community provides an excellent pool of masters from which to learn.

Email somebody: I bet within the first couple of dozen, you'll find somebody who's willing to mail you their source code to comment or standardize.

Re:Hrm... can you teach people to think?

[vkg]

Yeah, sorry, I'm a moron!

flowcharts

[deanj]

Uh...I'd toss the flowcharts...we tossed those back when I started programming more than 20 years ago.

You are VERY correct

[stoolpigeon]

I said the same but not as well.

I would add that this approach of theory w/out specifics of implemenatation is not as workable on a practical level.

People learning to code want to get in their and 'do' something. They want to see some results and I don't think there is anything wrong w/that. You need to give them that opportunity to keep enthusiasm.

The 2 track idea is excellent.

.

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.

Re:Design Patterns, The Book

[psaltes]

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

I just went and looked at both of those sites and I don't think that either are portraying design patterns nearly as harshly as you say they are.

Here is a quote from the second link: "Some of the patterns disappear -- that is, they are supported directly by language features, some patterns are simpler or have a different focus, and some are essentially unchanged."

From the first, "16 out of 23 patterns have qualitatively simpler implementations in lisp or Dylan than C++ for at least some uses of these patterns".

Both of these are quite balanced evenhanded statements, neither condemning design patterns or equating them with language flaws. Both links are oriented towards only one difference between language kinds, dynamic rather than static. There are quite satisfactory reasons to choose static languages over dynamic ones regardless of whether the design patterns are more complex, and it is somewhat closeminded to call either approach flawed.

Re:Design Patterns, The Book

[alext]

The quotes were just accessible examples of why this book is inappropriate as an introduction to conceptual computing fundamentals. There are other papers highlighting problems with the GoF book in its own terms, if that's what you're interested in. LISP and Dylan aren't perfect models either, and I certainly wouldn't base a course entirely on them.

I'm sure you are aware of established books on computing fundamentals, such as How to Design Programs, so it must be fairly obvious that the GoF is not remotely comparable to these.

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

You might like Design Patterns

[brad.hill]

It's not really a conceptual model of software, such as you seem to be seeking (pehaps barking up the wrong tree) but the Design Patterns book and community around these ideas are excellent.

Perhaps more similar to ideas from systems theory than from ontology, design patterns are sets of abstractions and ideas that are repeatedly useful in many different contexts for solving complex problems in an elegant manner.

As a developer, patterns are the most powerful part of my design repertoire. Conceptual models are invariably domain specific, but uses for patterns come up again and again.

Try Design Patterns, by Gamma, Helm, Johnson and Vlissides. There are many other books in that genere, though. Analysis Patterns by Martin Fowler may be more of what you want if you're looking for domain-specific analytical abstractions.

The book Cognitive Patterns by Karen Gardner describes a different kind of conceptual model for programming. An interesting read, but I've rarely used anything from it.

If you really want to get into a detailed ontological perspective on programming and the world, read On the Origin of Objects by Brian Cantwell Smith. Absolutely fascinating philosophical study. Absolutely useless to a working programmer. (unless you work at PARC or Watson labs) :)

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

50 pairs + one lone number

[jabbo]

You conveniently omitted the one outlier that the pattern converges upon. Anyone who understands quicksort could tell you that ;-)

1 + 99 = 100
2 + 98 = 100
...
50 + 0 = 50

sum (1..100, step=1) { x } = 5050 because of that.

Come to think of it, patterns like this (eg. all the multiples of 9 x a single digit N have the first digit as N-1 and the second as the difference 9-(N-1)) are probably why I hated calculus and used Taylor series in place of integrals every chance I got in college.

Integration still seems like voodoo to me. Sequences, now there's something *REAL*.

(even in job choices -- computational chemistry, database work, etc. -- I ended up with discrete rather than continuous bases for solving most problems... odd)

Re:50 pairs + one lone number

[spongman]

apparently Gauss' teacher gave his class this puzzle (add up all the numbers from 1-100) to keep them occupied while he marked papers thinking it would take them a while. Gauss, of course, worked out the above solution within minutes. he was 8.

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.

I always start with the concept of transformation

[IBitOBear]

It seems obvious when you say it aloud, but the purpose of any program is to "do something". That is where I start. With what exactly it "can mean to do something".

The fact that this is vauge is, frankly, exactly the point. I also take the student through the real-world words excersize. Particularly "what is a file? Now try again but completely forget that htere has ever been a thing called a computer; what is a file?" wearing them down to "An arbitrary collection of arbitrary things."

Once you have done this decomposition of practical thought (typically about ten minutes of easy banter and cheap jokes) you can "really start" with the idea that there is a thing called "a state", that that thing is "only as defined as it needs to be for the task" and that any task is a transformation on that state.

The whole lecture really involves working a crowd (of students) like you were the warm-up act for a TV sit-com live-taping audience. But done correctly you are seeding your students with the tiniest grains of everything you will be requireing them to think from there on out. Most importantly you are doing it in a non-threatening way AND showing them that what they already know is vitally important. (That's the heart of the all important act of validating your students.)

Then you start bouncing back and forth between the practical and the theoretical.

Basically, what you should *REALLY* do is spend a few weeks with an "english as a second language" teacher or just a plain english teacher and learn how to *TEACH* before you even think about teaching a particular subject like "programming".

The fundimental problem with computer science is that the students are learning from the people who learned from the people who made it up in the first place, and not one of those people ever learned to "teach" any subject to anybody. -- me

They used to call it "Systems Analysis"

[mangu]

About 40 years ago, IBM found that they could charge more from their customers if they called their programmers "Systems Analysts". The catch was that they had to find some way to differentiate the systems analysts work from that of mere "programmers". It was from that context that the basic idea of what you are asking came from.

OK, I'm being cynical, but my point is that, in the last 40 years or so, everybody in the industry has agreed that one should have *something* that precedes programming, but there has never been a really good agreement on what should that be. Methods go in and out of fashion, just like names, Yourdon, Chris Gaine, etc.

My tiny piece of advice, based solely on my decades of working with computers is: hire really _good_ programmers (they may be expensive, but they are worth every cent) and let them do what they like. Nothing hampers a good programmer as much as imposing a "methodology".

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.

Concept Programming

[descubes]

Take a look at the Mozart web page for a discussion of what this is. The basic idea: Your code should use the very same concepts that you have in your mind when you think about the application. A concept programming language can be extended to incorporate arbitrary forms of abstraction, not just the built-in ones (i.e. "integer", "addition", "objects" are all library things, not built-in)

I'm currently hard at work on the first concept-programming language, called XL.

"Cardboarding" and Literate Programing.

[os2fan]

Computer languages, like real languages, give you the power to say things. Learning a foreign language or C++ isn't going to get you to say intelligent things.

Because computers are so literal, you need to think out the fine details of the process as well. This is where the cardboard comes in. In essence, you assume the program works, and manually work through the data.

You need to be conversant with your target enough to deal with all of the possibilities. To get an idea of this, read some of the bug-lists and history files of shareware.

The other thing to do is to design the thing so that the user knows what to expect. Spreadsheets were there before computers [Stationers carry books of x or y columns].

Once you do this, sit down with your material, and start with this program:

/* rexx */
call startup
call looping
call closure
exit

You break the program down into parts, and then address each part. Each part should do a clearly defined activity. This may not be just "one thing". Each routine must leave the global variables in a clearly defined state,

More importantly, each of the controls (be they buttons or command switches) must do logical things. You can draw on your user's expectations. Putting a function at menu|F|X will draw the ire of people who use this sequence to shut the program down.

There are of course excellent books out there. The one by Hackel [I forget the name .... will post it tonigth :)] is good, as is Knuth's "Literate Programming". Jon Bentley's comment in there is worth considering as well.

Re:"Cardboarding" and Literate Programing.

[os2fan]

The book by Heckel is "The elements of friendly software design".

IT is about information, not technology

[alext]

Lucky you. Some poor recommendations so far IMHO, with the honourable exception of SICP.

The key thing is to keep a sense of proportion - anyone referring to UML or the GoF design patterns book has failed to understand what the fundamentals of IT are, and is certainly overestimating the relevance of their own preferred language or paradigm.

Scheme/LISP, logic and some database theory is a good way to approach the fundamentals, as it was 15 years ago when I went through it. They won't thank you to begin with, but its what college is for! I'm not totally sold on SICP, students might think it's a bit pedantic, you might like to look at How to Design Programs as an alternative. I don't have a good reference for database and logic texts - I use Joe Celko's Data and Databases book, but this isn't suitable as an introduction.

Re:Structure And Interpretation of Computer Langua

[ariels]

SICP is it. It's more than just "a book about Scheme"! It talks about:

• Scheme
• Programming:
  • Recursion and iteration
  • Continuation
  • Debugging!
  • Types and type hierarchies
  • Infinite data types!
  • ...
• Time complexity
• Abstract models of computing
• Functional programming
• Object-oriented programming
• Logic programming
• Memoization
• Interpreters
• Compilers
• Language design
• ...

Just the "Table of Contents" should be enough to set any red-blooded programmer on "DROOL".

Scheme has trivial syntax. This lets the authors explore semantics in amazing detail. Scheme's semantics are explained using progressively finer (and more accurate) "models". Eventually these models are implemented, in the form of interpreters and compilers for interesting subsets of Scheme. Meanwhile, various data types are presented. Unlike the vast majority of programming textbooks, arrays and array-based types are given little space. Meanwhile, lists, trees and various (potentially) "infinite" data structures are examined.

Models are also given for other types of programming, including a machine code, a logic programming language, and the pure functional style. Functional programming is used extensively (assignments are deliberately rare) but not fanatically.

An amazing introduction to the subject (even if you already know it).

Brain and Box

[LowneWulf]

Our professor would always (almost compulsively) draw a picture of a brain, and a picture of a box.

The box was your state machine, and the brain was the operator/programmer/user whatever looking at some aspect of it.

The whole concept of programming languages was explained using a sequence of grunts and sidetracks, and lots of pictures of the brain and the box with different relevant sizes :)

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.

Re:I always start with the concept of transformati

[IBitOBear]

Not to reply to my own post but...

The most important "conceptual model" is "you already know how to solve problems, you do it every day."

This is generally followed by:

"This is not hard, just new/strange to you"
and/or
"Everything anybody can do in here, at the atomic level, is exactly analogous to something you have already done in the real world."

The first and hardest thing to do is demystify the experience. Computer mystics program by rote formula, always recreating the same program with nearly identical structures in a cookbook-like format. Computer scientists take knowledge and use it to manufacture a good solution for each unique problem.

Most of the freshly-minted graduates in Computer Science are Computer Mystics. If you can break down this formula approach to the subject you will get much further much faster and produce a better graduate.

Best book I've read.... and the one I started with

[achiel]

An Introduction to Programming, and Object Orientated Design
Nino & Hosch

That's the book I started with 7 months ago (had never programmed before, HTML doesn't count :P), and I'm very happy I did. It's a fairly theoretical book, emphasizing greatly on the fundamentals of Object Orientated design, placing Java syntax a definite second. Chapters don't teach you how to program, they teach you the development of Object Orientated design, beginning with simple classes, building test classes for those, GUIs etc.

While this approach to programming is _very_ frustrating (I was very itchy, wanting to get ahead and start coding real programs which could actually 'do' something), it gives you a very good base from which to go on and learn more about programming. GUI's, for instance, are discussed in chapter 20 (one of the last chapters), and only AFTER completely digesting the whole Model-View-Controller pattern.

Enough of the propaganda for this book, I'm simply a student who is very happy to have been able get such a good introduction to programming from this book. I've tried other java books in the past, only to have been irritated with the lengthy examples which they START OFF with, even before teaching you exactly what a class is.

Problem with this book is that it doesn't really stand alone. You'll be able to grasp the concepts of OOP completely, but you'll have almost no hands-on experience, unless you pay _very_ close attention. I recommend using a second book as reference (we used a book by Kalin which I do NOT recommend, maybe an O'Reilly in a Nutshell book would be good)

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

[Tablizer]

(* 'i' makes a great loop variable. Yes, I know that it hearkens back to the days of Fortran, but it's become a cross-language idiom, so you'll confuse more people than you'll enlighten if you use something else for short loops. *)

I generally have to agree. As a rule of thumb, the more often something is referenced, the shorter its name should be. Long-winded code is harder to read IMO.

If you have a long variable name, then shorten it with an abbreviation, and then comment the abreviation. Example:

var fbtb; // foo bar transfer buffer

or perhaps:

var fooXfr; // foo bar transfer buffer

IOW, factor the "documentation" into one spot.

As a compromise, perhaps try "idx" instead of "i".

Re:Old timer comment...

[sconeu]

Shit, i is one of the most used letters in English or any other Roman Script based language for that matter. For that reason, all my loops are indexed by ii, jj, kk

I tend to use "j", for that reason but in vim, there's always \<i\> to look for the solo letter "i".

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

[p3d0]

I agree. Pick the notation that is most likely to help potential readers understand what the code is doing. If you honestly think that means using "i" as the induction variable of a loop (which it occasionally does), then do it.

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.

the guy needs a little Knuth (who doesn't?)

[jabbo]

In the words of a programmer noted for both correctness AND efficiency,

Premature optimization is the root of all evil

:-)

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.

Re:There is no such thing as "theory" in software

[os2fan]

No, honey, there is theory in software.

For example, consider the sorting algorithms. There are several different methods of sorting a series. Some of them, like quicksort, are generally better than others, like bubblesort. But in Knuth, we find a system where bubble sort is the most efficient method.

The idea that different methods "cost" different amounts, and doing these calculations can speed up programs greatly, is also not to be missed.

There is also "design philosopy", which is about how the parts fit together, and are built. The shift from the hard-coded jumps and gotos of assembler and basic to the structured programs of c, rexx &c is the application of a theoretical discovery. The unix pipe is built around the idea of task segments.

Like bridge design, program design is a case of learnt skills. And if you don't periodically look objectively with some theory at the design process, the design of both the bridge and the program may be sadly lacking and unnecessarily expensive.

And yes, you CAN learn bad habits. Programs like basic teach you bad habits in the sense that all values can be called from anywhere, and the use of "GOTO"'s.

Flow charts are generally a bad idea, since they force you into excessive codes. Better to let things wait and ride.

You Should Start with Some Syntax

[DrStrange]

I may be in the minority here but I believe you should start with some syntax before you teach design. Implementing a quality design will require syntax that most courses take weeks to get to, speaking from a C++ standpoint specifically but I believe it holds true for other languages as well. What's the point in showing someone how structures should interact if they don't have the slighest idea on how to transform that into code.

Basic rule of software: do the right things before you worry about doing the right things well. Learning the syntax is doing the right things, proper design is doing the right things well.

/me getting off soapbox

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.

Re:Everyone is different

[Tablizer]

(* 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. *)

I agree!

People tend to assume that either:

1. Others *do* think like themselves

and/or

2. People *should* think like themselves

People simply process and digest and "model" information in very different ways. What works for you may not work for others. For example, social people may learn or process information better if they envision processes as a bunch of friendly little elves interacting and cooperating with each other to get a job done.

Although I tend to be visual, I find that some people just don't relate to diagrams and prefer some sort of written description or dialog of some sorts.

One size does *not* fit all.

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:There is no such thing as "theory" in software

[os2fan]

I never said you should not make mistakes, or that you can't learn from mistakes.

None the same, theory is valuable, not all the time, but as often as it is in engineering. Debugging is fairly theoretical task. The more you move up the front, the less you have to debug and rewrite.

Yes, the average programming does benefit from a fair bit of design. In essence, if you can plan for things aforehand, then you can avoid these pitfalls. A big program in an area wher you can't lock away variables, or needs a tight squeeze of space, does well with a bit of foreplanning.

And, besides, what's the difference between "SORT" "ORDER BY", and cutting and pasting a standard sort routine. :) I may not know how to do quicksort, but the program runs faster with it than, say, bubblesort. Most of the time I use the "sort" command, and structure output to make its life easier. It's only when I need an inline sort that I dig out the code.

I mean, I wanted some code for matrix determinate and inverses, so I took some stock code, and made my programs use the right variables. It's not that much different to doing the same in an spreadsheet.

There's nothing wrong with a spot of idealism, and I assure you, it's not a new thing with computers.

As far as programming goes, the first thing I show people is things like how to write filters in rexx, and shell programming. Both of these are dirt-easy, and immediately appliable.

Re:There is no such thing as "theory" in software

[os2fan]

To say the same thing, there is no theory in 99% of designing and building bridges as well. In both case it's pretty much applying stock formulae to each case.

I mean, what's the difference in cut-and-paste and kit-assembled homes. The bulk of the work is done elsewhere.

Sorting routines are pretty much thrown at people. I do not deny this. So is bridge design. But this is not the point.

On the other hand, a careful study of where things go in a program, and considering alternate options for the program, resulted in massive speed increases (here hundred or thousand-fold type), in some of the programs I wrote and rewrote. Yet the first program I wrote was recycled to do an entirely different task, where it was much more effective.

There's no "magic wall" between theory and practice. It's more a matter of how far you stand back and see the scheme of things.

Re:Think in Parts

[Tablizer]

(* Break a bigger problem into a bunch of small pieces. Stay focused on what the program should be doing - don't lose sight of the bigger picture. *)

Good general advice. However, the problem is that there are often competing, orthogonal ways to divide something up. For example, traditional procedural programming tends to divide by tasks or verbs (at least the code part), while OOP tends to divide up by nouns. (I see no evidence that noun-centric code division is superior to task-centric, BTW.)

Every experienced programmer will probably agree that "parts is good", but the hard part (pun) is how to partition things to reflect the multi-faceted world we live in. Dealing with multiple, interweaving facets is the hardest part of designing complex systems IMO. (And please don't say that AOP has "solved" this. It is only a lab toy at this point.)

Re:Pseudocode

[os2fan]

Pseudocode is OK. Especially if it can be made into real code.

In fact, the concepts of bubble-programming and literate programming are based on pseudocode. All it means, is that you write the calls to the subroutines before the subroutine appears...

So a program like:

/*rexx */
call begin
call loops
call endme
exit

is a perfect pseudocode, that becomes a valid rexx script when the bits are filled in. It's also a neat block-breaker.

Often the pseudocode for something becomes with a little debugging, the alpha-code.

Re:Design

[lo_fye]

I teach web design, and one thing i find is that a LOT of my students are not programmers. They just want to make pretty web pages. They might not even know that it requires programming. Some don't even know how to use computers very well.

So, I have to start very basic. I get them to look at the source of a webpage (like google or soemthing). Then I point out that it's all just text. Then I get them to open up Notepad.exe, where we'll stay for the first 8 weeks before graduating to Homesite.

Then I describe what H,T,M, and L in HTML stand for, and what (exactly) mark-up is. I compare it to an english essay that you hand in, and when you get it back, the teacher has "marked it up" saying "new paragraph here" or "italic" or "bold" here.... she's not telling you to change the content, just how it appears.

Then I teach them 1 tag at a time and the well-formedness rules. After they type it in, they look at it in the browser. They understand it that way.

After completing all of the basic xHTML tags we move on to CSS and start emphasizing the separation of data and presentation.

Then we do css layers/positioning and @media types, even further separating data & presentation.

Finally we do javascript and dHTML. This is full-on scripting. Data and presentation layers are separated (for the most part), and I can now introduct the idea of variables (which I relate back to grade 10 algebra x=1, y=2, therefore x+y=3), looping, conditional structures, and functions.

For 16 3 hour classes, this gets them from point zero to understanding the basics of scripting, as well as all of the details required to make a site with css-p that will validate under the strict xhtml dtd. For beginners I have no doubt that "doing" is much more powerful than "talking/thinking about".

The Modern Prometheus

[apsmith]

The correct model for software development is obvious:

Frankenstein, or the Modern Prometheus by Mary Wollstonecraft Shelley (first published 1818).

Developing software means creating something new, that has never existed before. Something that is often cobbled together out of parts from both the living and the carcases of the recently or not-so-recently deceased. Something that, when we first try to bring it to life, often fails, badly at times. Something that we, acting as gods, mold and shape into an active entity worthy of respect from our peers and customers. The range to which software can be applied is vast, encompassing the entire spectrum of human endeavor. The consequences when we make mistakes can be devastating. Be careful out there, ok?

Re:UML tailored for OOP...

[JamieF]

>Any mission critical application (OS kernel, NASA spacecraft software
> etc etc) is done in Z type languages.

Really? Can you back that up? Specifically, can you prove that any of Windows NT / VMS / Solaris / FreeBSD / Linux / MacOS X have a kernel that was written in a "Z type language" as opposed to just coded directly in C/C++/whatever and tested the hard way?

Two good books

[magic]

How to Design Programs (Rice) and Structure and Interpretation of Computer Programs (MIT) are two classic texts that ignore syntax and dive straight for concepts.

-m

Thinking like a Unix Programmer

[marhar]

You can't beat "The Unix Programming Environment" by Kernighan and Pike. It was a great book when it was released in 1984 and it's great now. Same for Software Tools by Kernighan and Plaugher, from 1976.

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.

Re:Amen to that ...

[ahde]

Open source mostly obsoletes these methodologies. The idea behind them is to hide your code, which is fine for APIs, but especially in scripting languages (except perl) -- it's quicker and more concise to do your configuration in the code. Even with a C program, with the source (and a good makefile), its eaiser to grep (or sed!) for a string you want to replace, and then recompile, than to figure out how to set the right config to the right abstract interface.

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.

How To Design Programs (HTDP)

[alienmole]

SICP is fantastic, but tough going for many. Here's one that's being used even at the high school level, with some success: How To Design Programs (HTDP).

Perl Version

[crucini]

This:

print "$_\n" for 0..10;
print "Done\n";

or this:

print join "\n", 0..10, "Done", '';

Couldn't resist.

Re:Practicum first, then theory

[spongman]

yeah? try writing that in VDM.

ugh.

In my CS curriculum

[Kymermosst]

at Lane Community College, we started off Computer Science doing UML modelling and use-case diagrams, among other things.

When I am really programming, I write code, not use-case diagrams or class models.
The book we base most of our OO design on is Satzinger and Orvik's "The Object Oriented Approach."

Re:In my CS curriculum

[mikera]

On the contrary, it sometimes makes sense to code before you design.

I rather like the XP approach of designing only when you need to, and refactoring when you come across something you need to change. In my experience this is far more productive than lengthy design processes.

The knowledge that you will have to refactor tends to push you towards writing very clean and modular code from the outset, so design changes are usually very simple to implement.

Often the thorniest design decisions you will have to make only become apparent when you have a functioning prototype system and really start to understand the key implementation issues. There's nothing like a bunch of automated tests (another key XP practice) to help you here.

Yeah, sometimes you might have to tear up a whole subsystem and start again, but even then you will have learned more than you ever could have through a paper exercise. You've also probably spent less time doing this than you would have done on a single upfront design phase.

UML?

[angel'o'sphere]

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."
The UML covers about 9 different diagrams and approaches to model with them. "Object" or "Class" diagrams are ony *1* of those *9*.
Probably you should dig a bit into them before judging :-)

BTW: all but the class diagrams are well known digrams used in older methods of software design/specification, like e.g. state charts, flowcharts and message interactions(sequence charts).

The choice about using a "knowledge base" and/or "functional approaches" are beyond the conceptional phase. They have to be adressed before you start object or procedural modelling. Its an architectural descission (see e.g. Architecture Patterns, Buchmann et al., Addision Wessley) wether to use a knowledge base or a functional approach. The complete model looks absolutely different if you choose this or that architecture. And the modelling thechnices are also quite different.

Regards,
angel'o'sphere

Top-Down or Design wanted

[SEWilco]

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

It sounds like you want to start with Top-Down Programming or Analysis or Design. The other things you describe are used in a programming language class. A programming class would indeed start with the abstract methods and move to more detailed methods. A programming language might be learned for the examples and homework, but the language is taught as being just one of many tools to implement the design.

Old but good one

[Per Wigren]

To learn about recursion you first have to learn about recursion.

Black and white

[Anonymous Brave Guy]

Here's a good test: ask them "What is a trie, and where and why would use use it instead of another algorithm?". If they can't answer, then they are not a software engineer.

I've been a professional software developer for several years, and I have a formal background in CS at university level including several DS&A courses. Over the past couple of years, I've designed and implemented some fundamental modules on a big development project, and several people who've worked with them since have commented on how well the designs have worked out and how easy it is to adjust them later. I keep my knowledge current, reading several well-reviewed books on both CS theory and code hacking every year. Oh, yes, my business card does indeed say "Software Engineer" on it, and I think I've earned that title.

But I've never heard of an algorithm called a "trie".

These things are never black and white, and no single test like that can ever be fair.

Re:Black and white

[Xpilot]

A "trie" is not an algorithm, it's a data structure. It is a form of radix search tree that stores search keys in the external nodes of a tree. It was called "trie" because it's useful for re-trie-val :)

Re:Black and white

[Anonymous Brave Guy]

A "trie" is not an algorithm, it's a data structure.

Thanks for the reply. I've come across the term "trie" in that context, but the post to which I replied seemed to imply that there was an algorithm by that name. If that was a mistake, then my point about being wary of such simple tests is well made, I think. :-)

My Response

[johnnyb]

Several Scheme ones take this approach. Scheme and the Art of
Programming
is excellent, and for more advanced students, Structure and
Interpretation
of Computer Programs.

If you want your students to learn more about how the computer
works, you
might try reading the book I'm in the middle of writing,
Programming from
the Ground Up. The current draft is available online at
http://www.eskimo.com/~johnnyb/computers/Progr ammi ngGroundUp/

What a Conceptual Model Isn't...

[JohnDenver]

First and foremost, you're confusing a Conceptual Model with advanced abstract theories and design methodologies. Secondly, A Conceptual Model doesn't aim to substitute practice and prerequisite knowledge; a Conceptual Model aims to make concepts more familiar.

What we're talking are notations and analogies to explain basic algorithm design and assembly by capitalizing on what people already know about algorithms. Many people already know how to solve some pretty advanced problems with multiple steps using tools they're familiar with. A good Conceptual Model tries to apply a person's existing problem solving skills to a new paradigm where the tools are unfamiliar and the vernacular is cryptic.

While I can understand the benefit of learning lessons the hard way (you boot and blister analogy), some lessons are learned the hard way needlessly. Let's pick our lessons wisely, especially if a conceptual model could save someone 2 semesters of needless deciphering.

Re:Structure And Interpretation of Computer Langua

[William Tanksley]

I think the authors of SICP realized there were other models out there,

I agree -- they did a brilliant job. There's no way they could have noticed and documented so clearly so many of the problems with lambda notation if they hadn't known the other ways of looking at things. Nonetheless, they didn't choose to document those other models, and a wise teacher doing what he's asking for will want to document.

and I think they might disagree with the statement that lambda calculus have almost nothing to do with how computers work.

Then they'd be utterly ignorant. They probably never read the part of SICP which discusses the problems with various models of lambda computation ;-). See below.

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.

What you say here tends to discredit them, if it were true. I happen to know that they're smarter than that -- they DO know that lambda isn't a good model for computation, and they spend quite a bit of space in SICP teaching that.

Lambda isn't anything close to the ultimate goto. Continuations are. Shudder. But no matter.

Why isn't lambda a good computational model? Quite simply, because computers don't work merely by applying parameters to functions. They work by assigning values to locations. The reality of computing is almost entirely non-functional (in the sense that it's impossible to write a truly "pure" function, one with no variable modifications). Lambda notation has led inevitably to the false idea that the only way to write analysable programs is to avoid state modification; thus, a false dichotomy between OO and functional programming.

Calling a function isn't _really_ the same thing as passing it parameters, although C and Lisp make it look that way. Calling a function is actually pushing the current continuation on the return stack and jumping to the address of the new function. Passing a parameter is an entirely separate action.

The only languages I know which actually model that correctly are Forth, Postscript, and Joy. Thus, a Forth program can be both functional _and_ OO; it can be both functional and imperative. The only thing it can't be is both declarative and imperative (except in the silly sense of declaring a sequence of actions, naturally).

There's much more on this at the Joy page, whose URL I can't remember but which is linked from the Summary at the Concatenative Languages eGroup.

-Billy

Re:Mod up parent (it mentions K)!

[William Tanksley]

Grin. Thanks!

I'm not an old APLer; I was kind of a language collector, who tried and failed to learn APL because of its keyboard. J was much easier :-). K I still don't know, mainly because of its proprietariness; I'm not willing to put that much effort into any language, no matter how cool (and K is really, really cool) unless I can use it when and where I want to.

But as you can tell, I recognise and salute useful uniqueness; K has that, in spades. It may be a derivative of APL, but it's the most creative derivative of any language I've seen. (J is a close second.)

It makes me wish I needed kdb, to give me an excuse to learn the language even though it's proprietary. kdb is an insanely cool killer app. KILLER!!!!!! Astounding. Amazing. And utterly simple, thanks to K.

But K also has another advantage, which would make it useful in the context of this question: it's capable of being used in a manner like Scheme and other Algol-like languages. This makes teaching it take a LOT less time than J or APL would take, but you can still get to the real useful differences and make them fun.

-Billy

Where's sys.helloworld?

[oliverthered]

Your point seems to be that, every one writes a hello world, so why the hell isn't there a class library for it in java!

Re:And have someone to mentor you

[angel'o'sphere]

It's a tried and true methodology
NO, it is not!
It is a tried and true METHOD.

Methodology is the science of comparing methods.

And if you do an SA/SD analysis and design you follow the SA/SAD method.

If you do an RUP or XP process you are following the RUP method and XP method, respectively, and not any methodology.

angel'o'sphere

Re:It's not so simple, after all

[cscx]

I disagree. I think structure should come before things like, say, pointers.

Re:There is no such thing as "theory" in software

[crucini]

That was interesting, and I hope it gets modded up. I think you touched on something that makes me uneasy about "software design" - design seems to imply redundancy. It's easier to design a bridge than to make one. The drawing package for a bridge is a more compact representation of the underlying structure than the bridge itself.

Repetitive work may be needed in the physical world, but should be automated in the computer world. If a piece of software can be "designed", isn't the design document itself a program? And shouldn't it be run through a preprocessor/compiler/whatever to generate the next stage?

Of course a real engineered artifact might have higher-level design documents which do not contain sufficient detail to build the artifact, but containt sufficient detail that a qualified engineer could use them to develop the detailed design. Maybe within that context it is acceptable to speak of software design or engineering.

By the way, why don't you create an account?