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)?
It's nothing new, a friend of mine took a class using textbook : "Tools for structured design , In introduction to programming logic"
by Marilyn Bohl and Maria Rynn
lots of flowcharts and pesudo codes..
... 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.
... well, most Microsoft products, for example.
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
Just US$0.02 from The Watchful Babbler.
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.
.
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
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).
Uh...I'd toss the flowcharts...we tossed those back when I started programming more than 20 years ago.
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.
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.
Remember that what's inside of you doesn't matter because nobody can see it.
you could start by teaching them about Babbage's Difference Engine, the Universal Turing Machine, etc.
(but it would take a long time and probably be a digression into anecdotal history more than a useful starting point)
if you want to arm people with a useful conceptual and visual toolkit, UML would get my vote. I wish someone would have started me out that way instead of letting me stumble my way into it.
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 is Genu?
Genu is an interface to C++. It brings to the user:
-Intuitive approach to programmation with the analogy of C++ and tree.
-Interface for managing complex projects and instant recognition of important part of the program
http://www.gel.ulaval.ca/~dumais01/genu/
the 1.00 version is due for June 15th.
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.
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.
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.
Bitter and proud of it.
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.
Nothing for 6-digit uids?