Slashdot Mirror
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)
- Who/Where/How are the different models of a program being taught?
- What conceptual models do you use when programming (and where would I go to find out about them)?
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?
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.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
... 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.
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
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.
Hexayurt - open source refugee shelter,
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.
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
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.
- 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.I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
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.
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.
echo 5050
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.