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)?
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!!!
-- OMFG = Oh My Floatse Goatse
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?
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.
Make then learn LOGO.
If a turtle walking around the screen can't teach the fundamentals of programming, nothing can.
There are plenty of books about things like structured programming (iirc there is even one with that exact title), Just about any book with the work "algorithms" in the title, or things like "The Tao of Objects". Those are all good resources that focus on methodology rather than language.
I am fairly new to UML, and I agree it is very tailored toward OOP. That's not a bad thing, but it seems like you would need a firm grasp on OOP before touching UML, thus reducing your desire to a moot point, or a vicious circle depending on your viewpoint.
I think one of the best things for students to understand (from a students perspective) is that simple code is the best code. Also, Data layout is god... IMHO if you get the data layout right, you can't help but write simple logical code.
"...I'll need guns" --Chow Yun-Fat in 'Replacement Killers'
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.
In my experience, it seems best to introduce some sort of usefull example first, and then show how it fits into an overal paradigm of computing.
ie. Introduce C/PASCAL/BASIC then talk about the von Neumann model (which seems to be the most popular model, but possible not the easiest to understand)
In fact, since the von Neumann model is so popular, perhaps you should start of with a functional or declarative language first, like prolog just to open their minds before they get stuck into one way of thinking.
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.
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..
Sortof like a modern, complex Karel in other words ;)
Karma: Could be worse (could be raining)
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.
Writers imply. Readers infer.
Durham VRG
HTH
Structure and Interpretation of Computer Programs
by Harold Abelson, Gerald Jay Sussman, Julie Sussman.
... 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.
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.)
Soccer Goal Plans
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.
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?
Make sure they're not those terribly thin, Kate Moss-like models. Give them at least a little bit of figure, please!
... 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.
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.
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,
These can and will never be tought in university.
This comment is printed on 100% recycled electrons.
Uh...I'd toss the flowcharts...we tossed those back when I started programming more than 20 years ago.
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.
.
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?
hey man im an english and Poli Sci Major...Programming has nothing on me! I just come here to check out whats going on in the world of IT....if your a wanabe, thats ure thing....
I've been over this so many times it makes me want to kick someone in the teeth...
It always seems like programmers say that you have to know data structures and algorithms first to write good programs. Unfortunatly, these people have forgotten they had to LEARN TO CODE first. I dissapprove of any program that teaches theory first and syntax second because once the theory is there, people have the bad habit of trying to do things word for word. If these people had thier way, the towers of hanoi problem would only be taught iteratively!
Ok, i'm going home. Today sucked.
Linux is dead.
LU
A program is a set of a commands, that perform operations under strings.
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! :)
-- Ken Kinder ken@_nospam_kenkinder.com http://kenkinder.com/
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
Pseudo-code and flowcharts were my enemies in AP Computer Science. Nobody should have to flowchart a program with one For loop. I found all of that theoretical stuff to be useless for me, and I'm sure your students will too. I was able to get a 5 on the AP Computer Science test without ever turning in a flowchart. Really, I think programming should theoretically be taught from a theoretical standpoint, but really, modelling something in a flowchart manner went out in the 70's. Your best bet is to keep on upping the complexeties of the programs until you get to something that 50% of the kids are floundering on, then you should introduce flowcharts... instead of making kids flowchart everything so that they get bored of it before it ever becomes useful.
adam
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)
I'm sure many people here are already familiar with it, but if you're not it's worth a look.
Move on. There's nothing to see here.
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.
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.)
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
Maybe this isn't exactly what you're asking for, but for me, the first book that comes to mind when you start talking about "programming" from a more conceptual standpoint, is "The Pragmatic Programmer" by Andrew Hunt and David Thomas (Addison-Wesley). Lots of good examples in that book of how to go about programming and how not to go about programming (not just writing code), and lots of great advice on how to improve your craft. Maybe not too much about "conceptial models" as in functional versus imperative or procedural versus object-oriented, but it certainly is worth a look.
Most people learn concrete first, then they can move to abstract. Without some programming language(s) to think in or weigh alternatives in, it gets difficult to consider abstract notions.
It sounds like you are trying to do what I tried, teaching black belt lessons to white belts. This does not work, even if the black belt lessons are on topics the white belts already have covered.
However, The problem with starting out with the conceptual, is that students may miss an understanding of what a computer can actually do. Truly understanding things conceptually (rather than just repeating concepts for a test) usually requires quite a bit of experience.
The best programming class I ever took was actually an electronics class, where the final project was to build a working computer (which would even record and play back sound) out of a Motorola 68000 chip. That taught me most of the assembly I ever need to use, but also gave me a deep understanding of how computers actually work which is useful for everything from writing algorithms to basic Systems administration.
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)
Remember that what's inside of you doesn't matter because nobody can see it.
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.
Find free books.
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
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
The programmer's bible for this is The Art of Computer Programming by Don Knuth. It isn't the easiest book in the world to read, however, and consists of three volumes and an additional one Knuth wrote recently.
An interesting example of this I found out about recently are coroutines. I struggled with writing part of a program for weeks on end trying to do something similar to this. Had I known about this kind of technique then, I would've done it in a day.
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".
Every programming textbook I used at university was strong on concepts and theory and considered syntax an irritation that got in the way.
For an introduction to programming from a conceptual viewpoint, try the books in the "Data Abstration and Problem Solving with [language]: Walls and Mirrors". That's what we used in first year, and it's a good introduction to programming from a conceptual point of view.
Jason
The best introductory computer science textbook is "Structure and Interpretation of Computer Programs", also known as the wizard book because of the wizard on the cover. I've also heard good things about "How to Design Programs." Both of these books avoid the pitfall of focusing on syntax by using Scheme, which has very little syntax. I haven't read HTDP, but SICP is the best introductory computer science textbook I've read, and many computer science educators agree.
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.
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.
-- Did you try Tao3D? http://tao3d.sourceforge.net
Before object oriented things, structures, etc, the fundamental thing a student needs to know about programming is that it's a list of instructions to the computer.
I know BASIC teaches bad habits, but hell...teach them some rudimentary BASIC if you have to for a few classes (Pascal might be still better since I've heard it gives less bad habits, but I have no experience w/ Pascal). Once they know what code does, then it's time to teach higher levels of abstraction, with structured programming (C), OOP (C++/Java), or even something outside the declarative type of language (Prolog, which most people who aren't pure, theoretical CS will hate).
At the risk of sounding old, I'd say that most colleges today don't teach that long enough before they jump to C++/Java. You get one "Hello world", using C++-style cin and cout, and then it's off to classes, overloading, etc...without even giving more than a passing mention of pointers or even arrays (these concepts are pretty tough for a first-time student).
Abstractions are a programmer's tool. They're OK, but one must remember that they're only a human interface to what is essentially a list of commands to the computer. Teaching abstractions in a language without teaching how to write a simple program in it is confusing and demoralizing...and the sad thing is that I suspect most universities probably just teach C++ or Java to first-years because it's the Next Big Thing (TM).
There's no sig like this sig anywhere near this sig, so this must be the sig.
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:
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.
OS/2 - because choice is a terrible thing to waste.
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.
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).
2 dashes and a space, or just 2 dashes?
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
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.
Remember that what's inside of you doesn't matter because nobody can see it.
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.
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.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
The best book i've ran across that teachs analysis, design, as well as UML syntax, and design patterns is:
Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design
Great book that teachs by going through an example of building a very simple Post/Cash register system.
Covers Requirements, use cases, functional specs, conceptual models, system sequence, collab, design class diagrams, and finally patterns and how to map your finished design to code.
Very easy to read and understand. highly recommended!
I would say that you actually could teach design without teaching syntax first.
First, I would teach what memory is, and how instructions are followed in memory and the concept of algorithms. The next thing would be variables, followed by pointers. Then subroutines and parameter passing. Finally, data structures and "meta" structures like linked lists, stacks, etc.
You can actually explain every bit of this without a programming language, and without actually writing a single program on a computer. Along the way, you can have students write out basic programs in pseudocode on paper. This allows them to learn some code structure without relying on the compiler to and run-time environment to test everything.
After this, you can start from the beginning and go over the pseudocode programs and teach them how to phrase the same things in a particular language like C or Perl.
One thing I've noticed about people with poor backgrounds in software design and problem solving is that they may be able to write basic code in one language, but if they have to switch languages, they're totally lost.
To other readers, please note: I'm not necessarily advocating this approach. I'm merely suggesting it as a possibility.
bytesmythe
Hypocrisy is the resin that holds the plywood of society together.
-- Scott Meyer
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.
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.
An Introduction to Programming, and Object Orientated Design
: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.
Nino & Hosch
That's the book I started with 7 months ago (had never programmed before, HTML doesn't count
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)
As a potential student of programming I think that it is more important to get the conceptual ideas of programming first. I think that to demonstrate logical programming is much more important than learning syntax. Many books that I have looked at try a 24 hour format. They also claim that little knowledge of programming is necassary. Even after completing a book I am left with little skills in implementation of even the most basic nature.
I think that a what your are attempting could be very useful.
Zed lets you fully specify your program regardless of how it's implemented. It is specifically designed to let you work out the conceptual nuts & bolts and make sure they're consistent before you implement.
The most grievous bugs are logic errors(imho).
// James
--- The reclining dragon deeply fears the blue pool's clarity.
You say that this is for an introductory course. Does this mean people with zero programming experience or little experience? Are you talking about high school, college, vocational, or corporate training type courses? I'm not very close to the teaching scene, and so I don't have any good pedagogical sources. Anyways, a few cautions along with my thoughts: our conceptual models probably vary widely, having mostly developed ad-hoc. Methodology, and the coincedant models, of any kind are not exactly common amoung professional programmers. Articulating the ad-hoc models that we do use, often unconsciously, is not easy. Interesting study? Very. Useful for an introductory course? I don't know your purposes, but I doubt it.
:) But then again, my peers were severely disappointed by Prolog.
So, now for my thoughts. I would couch the discussion in terms of problem solving, rather than "programming" per se. Hopefully your students are used to solving math, physics, and/or chemistry etc problems. In this context, "problem solving methodology" should hopefully be sufficiently tangible to get them thinking about it. Discuss using algebraic methods versus geometric arguments versus intuitive methods for problem solving. This is mostly just to get them thinking about the fact that there are entirely different conceptual approaches, all of them workable, but with different applicability. It should be less controversial in this context to say that there is no "best" approach, only ones that you are more or less comfortable with. Now it should be easier to present different programming paradigms as different approaches to the same problem.
Ok, now, how math inclined are these students? If you want to go after conceptual, well, you're going to hit a mathematical barrier eventually. If you can spend some time on basic set theory, and the idea of functions as mappings or projections, I would recommend it. Then, some basic algebra to get across the idea that we define the meaning of operators, but we try and do it in such a way that the emergent properties are interesting to us. And of course, I would (re)introduce them to Newton's method as a segway into algorithms. Finally, I would go over just enough logic and binary arithmetic that you can lay out a simple adding circuit in terms of AND, OR, XOR, etc. Now the stage is set without unduly biasing them towards one method. They may be severely disappointed by so much math, though
The easiest, quickest way I can think of to start is in a cooking class. The ingredients are your inputs, the receipie is your program, the oven is your computer, and the cookies are your output.
From there it's all all powdered sugar and souffles.
Karma: Food Fight (Mostly affected by Date Plate).
Having read SICP, I know that functional programming is for quiche eaters. If you are into this sort of thing, then you will love the Lambda the Ultimate blog.
cpeterso
- 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.
I'm not sure how all of this stacks up to SICP since I just found this one this morning. I can't say enough good things about SICP (It is how I really learned to think about software), but neither can a lot of other posters, so I figure I don't have to. This program is directed at a conceptual level and it looks like this course might be a worthwhile comparison.
The link is here
Apple ships the OS-X developer tools (free download) with a nice set of Tutorials that start with Conceptual presentation of: Object Oriented design, Frameworks, Sockets and Classes.
Apple Developer Tools
Alright Larmen, stop trolling!!!
I thought the book to be too simplistic and nothing to do with actual code (which is necessary in an introduction to programming course).
The author of this thread is trying to cover way too much material with novices that will be more than overwhelmed.
Unless he wants to teach Visual Basic using its Visual Modeler (but I wouldn't call that programming).
come on fhqwhgads
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.
Programming Logic...Many colleges have courses just like that where they do not get into any specific language but instead discuss the very topics you brought up.
Do not ever start out an introductory course with theories only. If you spend even the first two weeks or so discussing just the ideas of programming and never get to the actual syntax, everyone will be bored out of their minds, and you will definitely hurt any of the inspirable people. Mix and match. Sure, some courses may start out with too much syntax, and not focusing enough on the ideas behind writing certain routines, but they get the people into actually working with the code. Imagine if in an introductory physics class all the professor talked about was how a force could be used to accelerate a mass, and how the forces could act with or against each other, but never got down to F=ma and the vector additon of forces, or never showed pictures of force diagrams or anything. You would lose everyone in the class. Make sure you combine application and processes with theories. Get the right balance, and the theories can/will be interesting enough to be applied anyhow.
SICP is great, but it can be quite difficult for many beginning programmers. An excellent alternative that covers many of the same "big ideas" is The Schematics of Computation, by Manis and Little; I call it "SICP for mortals".
We're at the same stage in software where medicine was when the guy who cut your hair was the same guy who set your bones. Truth be told, we have no clue as how to write software and our kids will pity us and our grandkids will REALLY pity us.... As for the competing schools of development - 'Where there is science there is no argument' - da Vinci
Mumia Abu-Jamal is *laughably guilty*. Check the evidence.
In the words of a programmer noted for both correctness AND efficiency,
Premature optimization is the root of all evil
:-)
Remember that what's inside of you doesn't matter because nobody can see it.
I disagree.
I think that someone starting off with these mental tools straight out of college can avoid all the 'sweat & tears' that we had to go through.
I haven't personally derived each and every pattern described in Design Patterns (just 1 in fact)... but that doens't mean I don't find them useful. Quite the opposite.
Now I 'grok' the pattern I worked out for myself more than the others, but that doesn't mean I don't use them.
I still think this would be a bit much to through at someone early on, but perhaps after they've got a language under their belt, along with some basic concepts....
Fooz Meister
IMHO you learn to program just like you learn to talk. First you mumble after an adult (wizzard), without comprehension, than you find meaning in the words.
Only then you get your first glimps of semantics, as you combine the meaning of words (instructions) into the meaning of life^H^H^H^H it all (what the program does).
It doesn't pay to hammer in "42" if they don't know the question.
Just give them exampels, have them work with it, and then they see the light, and the can reverse the process; Going from meaning to syntax.If they want to know the answer to soon, they are not going to like it. And you need that motivation! Have them program 'life' than the 'universe' and after than you make them believe the can do 'everything.' Keep um coding! The semantics is the answer, the sintax the question.
-- (:> jms cs.vu.nl (_) --"---
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.
Remember that what's inside of you doesn't matter because nobody can see it.
Although I understand the merits of looking at everything from a top-level, big picture point of view, I don't know if this is the best way to teach new students.
I completely believe that the reason why I absorbed computer science in college, especially software engineering principles, is that I wrote a 30,000 line game in C when I was in high school. I learned *all* the wrong things to do by experience, and could apply all the material in college directly to my game.
I've always wanted to teach a programming class where you would keep building on an project through-out the semester, until it totally blows up in everyone's faces because of their bad programming practices. The next phase of the class (maybe the next semester?) would be analyzing the project and how SW design principles could have been applied and how they would have helped!
http://www.gel.ulaval.ca/~dumais01/genu/
"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"
Try getting the Data Structures book by Micheal Main from the University of Colorado he only has one so it should be easy to find it is very handy for conceputal computer science.
Not to be mean, BUT... Let me guess, the singleton pattern is the one pattern that you HAVE derived.
come on fhqwhgads
I do not have any tools per se, in teaching computing concepts. I usually start with diagrams of what computing hardware is, though.
After all, basic operation of a motor vehicle and how it is maintained for example begins with maintaining its parts, and why and what happens when you don't change the oil for example on a regular basis.
Same thing with computing machinery. What parts do what provide a thoughtful framework, a conceptual framework in how and what programming is and how to do it.
MMU's, Registers, Stack Frames (if you are on a CISC machine), and the hardware that makes these things go.
From there I move into the flow of information and instructions through the machine. I can then use that as a jump point to teaching programming concepts:
1) I begin with the 5 "holy" constructs of structured design. From these 5 constructs all computing algorithms can be encompassed.
command, if/then, while, do/while, case.
This provides a conceptual and I think easy way to build simple programs.
I usually ask people to design an algorithm that counts to 10 then quits, for example.
2) After people master these concepts of control and command, I can then usually introduce the more advanced concepts of what data means to execution and implementation on the structure of code. (i.e. Data Structures)
I try to keep the Math at a minimum unless I am talking with a bunch of PhD's who for example, want to figure out the finer points of whatever weather model they are building and its impact on the execution time on the target machine.
Math however, is very important in structured design. God has his hands everywhere in your code you know, and he writes hints on how to improve it and how to store that data and access it, in his own handwriting...
Mathematics.
4) After we cover those topics, we get into the world of specialized design. We cover some of the more highly specialized fields in command and data representation such as Object Oriented Design,
Conceptual models for OOD I use typically begin with the construction of a Structured Design template, and the I transform it into an equivalent OOD. OOD is very abstract, even more so than structured design in many ways.
Many structured design students of the past 30 years in computer science often have a VERY hard time making the jump into this new mode of thinking.
It takes more than just learning a new language to be a good OOD'er. Many of my students depending on the effort, usually are quite skilled in OOD about 2 years of writing code, and proper mentoring.
That is of course, as long as you don't use Microsoft tools.
Did you know VB of objekt oreinTA TED.
:-)
-hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
Ok... I am NOT a programmer. I would like to be, but most of the suggested approaches I have read here are really missing the point of the post, (Duhhhh... at least I think so...). It doesn't help me at all to continually parrot "BAWWWK! Learn code, learn code! BAWWWK!" I have read code til I was stooped over like a man thrice my age, and I still am unclear on the concept.
Additionally, it is just as useless to me to suggest that I just write programs until I get it right. Anyone ever heard the old adage about an infinite number of monkeys with typewriters eventually producing the works of Shakespeare? Well, as in that example, simply barfing code onto a page until it lurches to life as a marginally-functional program means a long time between initial keystroke and thrilling to the sight of "Hello, world!" on your monitor.
Personally (and bear in mind that I am a theatre major-turned-network administrator--i.e.: right-brain artsy-fartsy type learning to use his left lobe) I need something more in order to absorb the complexities associated with arcane code. What this post is getting at, I think, is more of a content-with-context approach.
As an initial approach, I am sure many people would benefit from simple representations of complex processes as a foundation for learning. This doesn't simply mean learning to flowchart, but some sort of symbolic representation which indicates both the flow of the program and the environment within which it must run.
For example, the first truly 'original' program I wrote, in order to self-teach myself shell scripting, was a simple script which started with a variable set to zero, and which would add one to that variable, display it onscreen as "This program has now run X times", then save the resulting variable to a separate file. On subsequent executions of the script, it would read the variable from the outside file, process it as decribed above, and spit out the result onscreen and as the new value of the outside file.
Now, this may sound like a moronic little program, but until I figured out how the STATIC CODE interacted with the VARIABLE OUTPUT (maintained in a file outside the script) I was as stumped as John Bobbit after Lorena wigged-out on him. For me, it was just as important to understand the system of input and output and file storage and retrieval as it was to learn how to script.
Most programming books I see take too dry an approach to lining up all the code, with very little in the way of analogy (in my moron script, it was important to learn how the script 'hands off' the output to a file where it is 'stored' until the script needs to 'pull it out' again. I know this makes me sound like an abject moron, but I have yet to find an instructional tool that brings the concept of programming as close to home as analogy.
Ok... Time to get back to work, trying to get Slashcode working here at work... Anyone have a spare magic wand I can wave over my computer??
Mmmmmm... Bold, yet refreshing!
Practical C Programming by Steve Oulliane at O'Reilly. Covers everything you're looking for.
This is like trying to teach a child about sentance structure before they know how to talk. Ie; it wouldn't make any sense to talk about predicates and subjects to a student who doesn't know any words. People need something concrete to grasp first. They need a real syntax, or things like objects, and pretty flow charts don't mean anything. Only once you have the rudiments down can you understand more complicated design issues.
You can't think about something unless you have someTHING to think ABOUT. I would think a student would be turned off really soon by philosophy without his being able to DO something. I've really enjoyed programming and now approach the abstract books with interest since I can relate to the problems that they discuss. And I DID learn programming by having an idea of a program, then looking up the code that would allow me to do it, but the two went hand-in-hand. If I could only think of what I wanted my program to do and couldn't ( for a long time ) do anything about it, I would have quit long ago. (I'm a self-taught programmer currently working in industry.)
You should look into information on John von Neumann - he is generally accredited with inventing flowcharts and designing some of the first conceptual flow for machine operation. I was rather happy to have his concepts introduced in my intro CS class, but I doubt that it was so common a happening.
.....he is also just a really cool figure to review =) good luck
-shpoffo
The single most important subject in the realm of software development is, sadly, often ignored entirely in computer science education. That subject is workflow. I've seen altogether too many well-implemented, relatively bug-free software packages that are nonetheless miserable failures because they fail to adequately consider what the end user really needs to do and how those users go about accomplishing their work.
I'd even go so far as to say that I believe that the first "Intro to Computer Science" course ideally should involve little or no programming at all. Rather, it should focus on requirements engineering. Students should learn how to work with real end users to understand their workflows. They should learn how to write good requirements documents in prose that adequately describe the workflows they have observed so that someone could conceivably build a satisfactory software system from the requirements documentation.
"User and Task Analysis for Interface Design" by Hackos & Redish is an excellent resource that focuses specifically on this topic. "Software Engineering" by Ian Sommerville addresses the issue to some extent while providing a broad overview of software development processes.
While actually coding may help you learn to program, it may not help if the programmer does not know about the tools available to solve the problems they encounter.
If a coder knows about conventions, concepts, and other fundamentals, when they encounter a situation coding where they need to apply them (for a simple example, planning before you actually code), then they can think "Hey, I remember something that's applicable to this", and go and lookup the details if necessary.
To go to your boots example: If someone gets blisters from walking, they may think it's the boots that need breaking in, but they might also think that the boots they have are not the right kind. When you say, "Look millions of people have gotten blisters, and breaking the boots in solves it with most boots", they might actualy do that, whreas without your guidance, they might not even consider that factor.
I like Matthias Felleisen & Daniel P Friedman's books: Little Schemer, Seasoned Schemer and A Little Java, a Few Patterns. They look like they're books for kids--and they are--but anyone can learn from them, and they cover programming, rather than syntax.
A lot of these responses describe such famous texts as Structure and Interpretation of Computer Programs, or Design Patterns, or some other famous book by Kernighan and someone else. Someday, I plan to read all of these books.
But if you're like me you graduated with a liberal arts degree because you had too much fun in college, now you are teaching yourself programming in hopes of getting a decent job, you've learned your way around Python and Perl and you've even gotten a job as a temp, building an internal content management site in PHP (without using code from PostNuke etc, in an attempt to force yourself to figure out the answers to your own problems [even though in hindsight it might not have been a bad idea])...
Having figured out that writing mammoth PHP scripts to handle every possible scenario is pretty unwieldy once you get the hang of that object-oriented thing, and realizing that you could have planned this thing a whole lot better than just jumping in and writing PHP code...
I'd heard that Java is a good next step and isn't that the language they teach beginning Computer Science students? And everyone on Monster.com seems to be hiring Java programmers...
Well in that case there's a book for you -- for me at least -- called Beginning Java Objects by Jaquie Barker. It's a Wrox book, so you can learn from it without having a CS degree or a mentor by your side (though I sure have come to appreciate the help I get on mailing lists), and it focuses on design rather than syntax. You really need to have programmed a little bit before getting into it, but it has already made me a better programmer.
Very easy to get into and get a lot of helpful information from.
"First you gotta do the truffle shuffle."
I can't answer the question in its full generality, but I can discuss another way to teach introductory C++.
Accelerated C++: Practical Programming By Example
by Koenig and Moo
ISBN 0-201-70353-X
I have to admit I've never actually read it, being a seasoned C++ programmer already, but it comes highly recommended from several well-respected authors. From what I gather, it introduces C++ programming by focusing on content and results rather than syntax. Using the STL and the Standard Library, you can accomplish complex tasks quickly and easily without bogging down in the details of how algorithms and data structures are implemented.
Why is this a good thing? Certainly if you're going to have a career in programming, you need to learn the details of building a linked list or a sort algorithm. But many majors in other sciences only take one or two introductory programming courses. It's better they should learn how to write something useful than the arcane intricacies of function pointers and storage duration qualifiers.
Even for CS majors, I would argue this approach is beneficial. It provides much greater feelings of accomplishment at the crucial introductory stage. Beginning programmers shouldn't even be messing with raw pointers or static arrays; they're highly unsafe and require a lot of attention to details which beginners don't comprehend.
At least that's my opinion, I could be wrong.
Democracy is two wolves and a sheep voting on lunch.
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.
OS/2 - because choice is a terrible thing to waste.
Personally I'm a poor programmer, for question you asked. I tend not to use flowcharts because I find it easier to express what I would write down in code anyways. If I use any conceptual model its typically just a class diagram for large projects, or maybe a memory map for smaller architectures. Rational Rose seems to be about the only real standard out there for conceptual stuff, unless you count hand waving Design Patterns.
But I feel sorry for any intiate who takes on such advanced topics like "programs are made of..." because not all programs can be seen as a knowledge base, or a system of sending messages. I would focus more on the math behind the scenes, because thats where things are heading. Things like assertions and domains are finally being promoted in Software Engineering and it takes a solid foundation to appreciate and understand it. Computers operate on a mathematical level. The smallest component of a program is an instruction. If you want to model that using parse trees thats an interesting approach but mostly useless. Reguardless of the content, for an entry level class the best thing you can do to get more of the class to understand things is lots of bite sized homework. Its a pain on the graders and the students might complain, but doing things several times using similar solutions helps you generalize concepts better.
I Browse at +4 Flamebait
Open Source Sysadmin
Are you some old time APLer? How did you stumble up on K. Between you, me, and my ex-roommate I think we are the only ones on Slashdot to have ever mentioned the language.
You might want to check out Paul Graham's site Especially his downloadable book 'On Lisp' The first chapter of that book has thoughts especially about why planning before implementation isn't really suited for building programs like it is for building dams. Instead he recommends planning as you write code. Of course having a language that is best suited for this style of programming is highly recommended :).
I have to admit that I'm a relative Lisp newbie but the more I study it the more I see why people love it so much...And I yearn to see a Lisp Machine for they were already dead before I knew the power of Lisp.(Wouldn't you like to know why people thought Lisp as OS was superior to Unix?) Paul Graham undoubtedly has a more scholarly explanation of this technique than I can give it credit to in the meager submission..
So when you are weighing all the suggestions on how to streamline those flowcharts give a good look to the one that says throw the flowcharts out the window and let 'code evolution' take place!
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
I prefer learning syntax first. The whole "Hello, World!" program being your first code is nice. You could go about learning all the conceptual stuff first; but, what can you do with it if you can't actually code yet?
Question
http://www.ironfroggy.com/
but even that is an (obvious) anthropomorphization of the modelling problem done by a human. it may be we never know how computers dream, which is a sad thing.
best of luck understanding things!
thi
These are all hacking manuals! Why is everyone mentioning hacking manuals!
The Art Of Computer Programming = hacking with elegant algorithms.
The Pragmatic Programmer = hacking with inelegant algorithms.
Design Patterns = hacking with no algorithms whatsoever but instead just some sort of vague metaphors.
A New Kind Of Science = hacking with algorithms that create pretty pictures and thus concluding that you've unified quantum mechanics and general relativity.
Knuth's book side, these have as much to do with developing a genuine understanding of computer programming as ISBN 0385194269!
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.
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.
Of course, The Art of Computer Programming by Don Knuth can not be beaten. But Design Patters by the fearsome four (Gamma et al.) is absolutely essential reading for the type of ideas that you refer to.
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.
Mentoring is the best bet, but personell is limited when it comes to this respect.
Learn by example.
* Full source code to a real problem.
* Don't leave out any code out or anything assumed.
* Make sure the project and source compile and work (unlike many books) so the learnee can play.
* Try to make the reader follow what the hell you are doing.
* Finally, present the learnee with the explanations why what was done where.
Giving explanations during the code takes away from the readers thought process. Letting a person play with the code also helps in the learning process. Watch a toddle play and learn and you'll see what I mean. We, as adults, don't (or at least shouldn't) lose that play/learn mechanism
A side effect, the person will become a better debugger.
UML 'seems' biased towards OOP?? Are you serious? UML exists solely for the OOP paradigm.
It sounds to me as though you're trying to fuse a Programming Languages course with a Software Engineering and SE Management course.
While looking at things from a new perspective may be interesting, the IEEE and ACM people will laugh at you for standing on your head for too long.
Functional and other non-imperative programming approaches are, for lack of a better term, academic. I'd suggest keeping them out of a mainstream curriculum course, offering them instead as an elective.
The design process and especially its resultant artifacts are more managerial than scientific in scope, and should also be taught separately.
The application of development processes and patterns form a relatively cohessive whole as it is. They're orthogonal to the language used and the documentation generated.
It looks as if you're trying to go vertically through subjects that are more easily addressed linearly. What you propose is fine fodder for consecutive courses, and could even be hit in one term, but these ideas do not belong in one course.
-- What you do today will cost you a day of your life.
Consider your basic procedural language. For a simple C program that interacts with the user through stdin/stdout, a programmer must consider at least three models or views of the program: the memory model, the textual model, and the user model. The user model is the simplest: the programmer must relate the printf/scanf's in the code with the actual output on the screen. Programmer's frequently employ the user model to observe the program execute through time (ahh, printf's... the poor man's debugger). The textual model is the code itself (e.g., what line are we on? how is this complicated nested expression executing? what does this macro expand to?). With the memory model, the programmer must consider how his/her code is altering the stack and heap.
Modern languages and processors do a great deal of magic providing us with this nice stack concept, but you generally have to start using it awhile before you understand the value and intent of it. One idea would be to force students to solve problems without using subroutines... just lots of gotos. This would automatically reduce the number of conceptual models from 3 to 2; once the student runs into the limitations of a goto-only program, they may welcome the idea of a stack and understand it intuitively.
Back to the point: in a single hour, you might go back and forth b/t high-level object models, quickly sketched flowcharts, cute little graphs and charts describing your problem domain, roughed-out pseudocode, a gdb window, a log file, and the code itself, all in attempt to expand, understand, and debug the program.
None of these views completely captures what the program is doing on all levels. I contend that the programmer shifts between them while exploring the problem and its possible solutions. Now... how to teach the student to do this... hmm. Good question.
-1, Too Many Layers Of Abstraction
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.
OS/2 - because choice is a terrible thing to waste.
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.
OS/2 - because choice is a terrible thing to waste.
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:
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.
OS/2 - because choice is a terrible thing to waste.
It was interesting, designing the program flowchart, and then writing the source code - and then going back and drawing the boxes around printout of the source code, re-creating the flowchart! The idea was that structure of the flowchart matched the structure of the program flow, and that the flowchart really could (with very little syntax tweaking) be the source code.
I do not understand why we aren't writing programs by dragging and dropping Nassi-Schneiderman blocks into an IDE that then prompts for the parameters of the piece. Put a 3-D visualizer/modeler on the thing and you should have a proveably correct code generator that would make the 20th century seem truly archaic.
Sigh - oh to be twenty again....
"The most sensible request of government we make is not, "Do something!" But "Quit it!"
There are two lines of approach:- 1. learn the language , for which you learn the syntax. 2. learn how to acheive some business function using a language, for which you do analysis, design, yada yada.. Now, if we are talking about 2, you do it in a way that suits your style and inclinations (OO, Procedural. what not). If we are talking about 1, then the best I can do is to shut up and listen to programmatically enlightened souls.
Science as a way of life.
My own personal experience working in various companies and settings, from large scale software house to small R&D group, has taught me that the best programmers are people who can think like the machine. Bar none, that is the best metric of success as a programmer.
So how does one learn to think like a machine? Experience is the only way.
I would suggest that you take your list of what you want to teach, and extend each by coming up with a real-world example that can best be represented by the technique you wish to illustrate. For instance, designing a boolean algebra reducer is a good illustration of functional programming - I forget the exact terms, but it has to do with more mathematical programming. A telephone address book is a good introduction to data structures and procedural and object-oriented programming.
I cannot add to your list, but I can suggest that carefully-chosen examples are the best way to get the point across and your students will identify with them better and remember them long after the semester ends. Remember the first time you implemented a stack? I could quote you code from mine :-)
Best wishes.
It's a tried and true methodology.
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?
Energy: time to change the picture.
The best book out there on what you'd call "patterns" is Bitter Java, cause it breaks down the hype around pattern based programming and shows how to use design patterns in the real world. Also there's Oreilly's "Java Patterns" and there's the original small talk based patterns book from '85. I like to program with php so I can forget about patterns, but as my own code got more and more complicated I found its still a useful resource to check out some concepts of design. Bitter Java is good because it takes patterns into the real world, and breaks down some of the myths around them that cause otherwise decent programmers to write slow, crappy code.
Check my site out for ogg vorbis music produced with linux.
I understand your desire to teach these conceptual models. I too think that there is too much emphasis on syntax and not enough on good CS theory.
But if this is an introductory course, you can't just start with teaching concepts like design patterns, OOA/D, and relational theory.
First you have to start with basic computing theory: the difference between primary and secondary storage and the difference between machine code, assembly code, byte code, and higher level language code. Then you have to teach the basic concepts of programming: iteration, conditionals, functions, objects, pointers, and references. And the best way to do that is by example, which requires you to teach the basic syntax of a language.
Only after students have a firm mastery of the basic tools can you start to introduce the concepts of good architecture. Without the knowledge of a language to practice their skills with, it would be hard to really grasp the meaning of the theoretical knowledge.
Frankly, if your introductory courses are like my introductory courses were, there are a lot of CS students that still need to be weeded out. There will be some students that can never really understand a pointer, and just want to survive one semester before they change majors. (There may also be some students there because intro to computers is required).
Bottom line: as much as I agree that we need to spend more time on fundamental CS theory, we can't expect to teach the kinds of topics you are talking about to first year undergrads.
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
Software engineering is a subset of sytems engineering. I think that one of the problems with software engineering culture is that there is not a neutral approach to modeling in general. Almost all the noise is about specific types of modeling, presented with an almost religious fervor, especially object. Most people use the term "object" without much understanding; I've had several senior chief engineers tell me there is only object or procedural.
If you want to address modeling in general you should probably lift up a domain and look into systems engineering and cybernetics. General graph theory is the place to start; basically you can "conceptually" model any way you can graph. From graph theory you can go one way into the "Structured Modeling" discipline, and the other way into standard SW treatments: structured analysis, dataflow, CRC, UML, to see how models are used. But the real question is, how are models mis-used? That is, has does a prejudice for a specific modeling method hamper the design?
The most important thing for an engineer is practicality. One has to blow through all of the convention and marketing to arrive at a solution with the greatest overall payback, on schedule and on budget. The only way a teacher can help develop this is by building an appreciation for essential principles over fads and heavily marketed conventions. Fads and marketing, however, are what has built careers in SW methodology. There has been no incentive to be a loud generalist, so you will not find any general materials yet.
I think you're going to have to put it together yourself...
You teach people spelling and grammar, _then_ you teach them to write stories.
You teach people calculus, _then_ you teach them physics.
You teach people algebra _then_ you teach them calculus.
Well, I'm running out of examples, here. My last year of college I had a younger student ask me "But, what's the point of a tree?" There's really no point to teaching the abstract stuff _first_. Programming a computer is an unnatural act, people generally simply have no conceptual framework to slot the abstractions into!
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.
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.
you should be able to look at a block of asm or c or c++ or vb and understand it
Yes you should be able to, but you shouldn't have to unless that is the block you're going to modify.
It seems obvious to me that you have never worked on something that is part of a bigger system. You try spending a few hours 'reverse engineering' a flowchart from the code to find the place to make your addition so that the impact (read: work) will be smaller. Then you can tell me how to do that without any form of conceptual model
try a different carreer, maybee in the fast food industry
Been there, done that, ain't going back. But whith your attitude that using conceptual models is wrong, just because you never needed it to write 'Hello World', maybe you should?
- We are the slashdot. Resistance is futile. Prepare to be moderated -
Look at the screen, you must not.
Shut your eyes, you must.
Guide your fingers, the Force will.
Great coder, you will be, yesss.
Hrm, seems to me that you're looking forward to a "mix" of programming and software engineering. Anyway, there are a couple of books you should take a look at :
"Software Engineering" 6th ed. - Ian Sommerville
Addison-Wesley, 2001
"Introduction to Automata Theory, Languages, and Computation" 2nd ed. - John Hopcroft, Rajeev Motwani and Jeffrey D. Ullman
Addison-Wesley, 2001
They're both really good.
The second one is used at Stanford for CS154 (Automata and Language Theory).
The first one even has a web page (http://www.software-engin.com/) with source code for most of the examples, additional material, and even slides (in pdf and ppt) for each chapter that you can use as a teaching aid.
Hope you find these interesting.
- Algorithms - Robert Sedgewick
- Code Complete - Microsoft
- Effective C++ - Scott Myers
- Game Programming Gems - Deloura
- Design Patterns - Gamma et al.
- Large Scale C++ Design - Lakos
Each of these books has served me well during my programming career. If I had to recommend two all-purpose programming must-have's from the list they would be 'Algorithms' by Sedgewick and 'Code Complete'. Algorithms shows you how to program, not how to learn APIs and syntax - it's a true gem. And Code Complete goes through a wealth of knowledge about how to get the job done effectuvely, quickly, and with few bugs - it's very good.'Those who will not reason, are bigots, those who cannot are fools, and those who dare not, are slaves.' - George Gordon
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).
or this:
Couldn't resist.
I guess at a higher level abstraction software architecture is what you refer to as 'structure' of programs. Software architecture can be worked out at different abstraction levels, from corporate wide architecture, to architecture bwteeen applications and within an application, where we sometimes call this design patterns. If you need info in this regard I canrecomment the book "design patterns" by Game, Helms, Johnson & Vlissides which is on a code level Also Martin Fowler has done some stuff on patterns in information systems check http://martinfowler.com
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."
"Alcohol, Tobacco, Firearms, and Explosives" should be a convenience store, not a government agency.
> my god that background is ugly
a script:void(document.bgColor='#AAAAAA')
Add bookmarklets like these to your bookmarks, and relax the next time someone forces a bad background on you.
javascript:void(document.body.background='')
jav
That book is not an introductory text. It is a second of third year text and even then it can be difficult for many to understand. Sipser can probably be taught in the second of third year with more effectiveness.
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
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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.
To learn about recursion you first have to learn about recursion.
My other account has a 3-digit UID.
Billshit. Analysis of the problem to be solved as well as designing the system to solve it are as important as writing the system's code. If you think systems like the X Window System, the Linux kernel, Mozilla or any other successful large system was created without paying attention to analysis and design, you are mistaken. A good design is as instrumental to a good program as good coding practice is -- unless you're just writing throw-away code for personal use, it really pays off to think through what you're going to create, and how you're going to go about it. This is where conceptual models can be very useful, especially if you remember that conceptual models do not HAVE to be flowcharts and rich pictures, but a vision of the basic concept you are going to implement in your program. Are you going to write your program as a traditional main program/subroutine architecture, an event-driven architecture, an object-oriented one, a pipes and filters network, or perhaps a repository style? Without knowing which architecture you're trying to implement, you are most likely to produce poor, inefficient and hard to maintain code -- if you can even get properly started. What constitutes a good program? Brian Kernighan and Rob Pike, in their book "The Practice of Programming", state that the three principles of simplicity, clarity and generality are fundamental to creating good programs. I agree with them, because a program which satisfies these three criteria is easy to reuse code from, easy to adapt to other circumstances, usually easy to optimize, easy to maintain, and easy to understand. If you are a coder, you certainly know the value of these properties. However, a poorly selected design style (architecture) or a flawed analysis of the problem will be just as great barriers towards achieving the goal of a good program as bad programming practice can be. Coding is just the implementation of the problem solution, design is figuring out HOW this implementation should work. Good coders may think in code, and good system designers may think in terms of models. The best coders, however, also happen to be good system designers, and the best system designers also happen to be good coders.
Six sick
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Exactly - when I read this "ask slashdot" question, I thought instantly, isn't that what I had when I took intro to programming in college? Yes, it was, hardly any textbook ever made the impression that "SICP" has made on me. Several folks have said it is hard going, maybe for some, for me it was like a light going on in my head - OH! I thought, Computer programming really is interesting and deep after all. Not something I'd thought after high school BASIC class.
;)
I was lucky though, in many ways. Hal Abelson came to my college (Brandeis) to teach it once a week (with our own computer science professors filling in on the other sessions of the week), so probably my experience was more on target than those who didn't have the good fortune to have one of the authors teaching the class. It was an exciting, fun, mind expanding class - the kind of thing I went to college for in the first place (cause I wasn't much of a drinker
It did cover prolog style programming, and object oriented programming, as well as lambda calculus, and stream-based programming. Admittedly, the only one it teaches deeply is the lambda calculus; the others are covered more cursorily and need their own courses to deepen them. (I "understood" object oriented programming after that course and the lunar lander program, but I didn't *understand* object oriented programming till I'd been programming in Smalltalk for several months)
Anyway - there may well be other books that achieve this goal, because it's been years & years, but that one sure did.
Writing is the only socially acceptable form of schizophrenia. (E. L. Doctorow)
An old book by David Gelernter and Suresh Jagannathan. I found this book is quite unique because Gelernter sees programs from a structural engineering perspective rather than mathematical view.
I've been teaching a class like this for several years, and haven't found a book I really like. (Well, I did once, used it for one semester, and then it went out of print. :-(
I agree with your comment that intro text books tend to deal too much with syntax, and not explain how to use the syntax they learned.
What I have found, however, is it takes a good balance between concepts and practice. Particularly when dealing with people with no programming background, too much theory is just as bad as too much practice.
Another interesting thing I have found is that the class is divided into two groups: those that can learn C easily and finds VB confusing, and those can learn Visual Basic, but can't get C. As a result, I let the students pick whatever language they want to learn with, and show examples in both languages.
What I usually do is discuss some structured programming concept and discuss it abstractly (e.g., if-then-else, while-do, etc.) I then give some generic examples using pseudo-code to show how such a construct would be used. I then show example programs in both C and VB.
Once they have learned that construct, we work on several programs to demonstrate how you can use this new concept to solve problems. I have a "getinfo" program (prompt the user for info, and then display it) that is written over the length of the semester. Each time we learn a new concept, we see how it can be used to improve the "getinfo" program. This helps them see how all these new ideas fit into the big picture.
Early in the semester, I give them time during class to try to write simple programs. If they don't get help with their first few programs, they probably won't be able to get very far. As the semester progresses, it is up to them to practice writing programs.
I encourage them to write one program with a group. By working together, they can usually avoid spinning their wheels because somebody in the group comes up with an answer.
In lieu of a text book, I have lots of sample programs that they can download from my web site.
I don't agree --- sequential, conditional and looping are the easy things. Teach them the hard stuff first, like recursion. The easy stuff can wait.
That's also the stuff that most of the foundation of computer science is built on, and which you need to know to be a good computer scientist.
I speak from hard experience, having tried to teach Theory of Computation to a class of college seniors who had never mastered recursion. Very ugly.
If you can get away with it, look at Abelson and Sussman's Structure and Interpretation of Computer Programs. Still the classic for concepts of programs and programming.
At Project Technology (http://www.projtech.com) they are working at conceptual modelling of software systems for over 12 years. The methodology has been developed by Sally Shlaer and Steve Mellor (of Ward/Mellor fame) and is very mature now.
They focus on building complete and executable models of software systems that can be run and tested on a simulator. In the final step the models are translated by a model-compiler into the target language of choice (C/C++, FORTRAN, whatever). No hand-coding required!
The latest version of their methodology uses a subset of UML hence it was renamed executable and translatable UML (XTUML). It is supported by a comprehensive set of tools
I think the software modelling concepts they developed are quite close to what you are looking for.
Several Scheme ones take this approach. Scheme and the Art of
r ammi ngGroundUp/
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/Prog
Engineering and the Ultimate
I do use 'i' a lot for very short loops. Knowing the rules and the impact of breaking them is perhaps the best knowledge of all.
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
Another old-timer viewpoint here. (I learned to program on a PDP 11/40 with VT-52 terminals. We were excited when we got VT-100s.) I had classes in programming that just went over what you mentioned, starting with syntax. But one of my classes was on computer systems analysis. We used a book by Shelly and Cashman. I think the book was Business Systems Analysis and Design but I am not certain of the title. That class taught me more about programming than the programming classes did. It focused on concepts. The first one being: "What do you want to get from this program? Why are you doing this? What are you trying to accomplish?" Then we looked at what our inputs needed to be to get the outcome we wanted. "Is all the necessary input available? Do we need to gather more data? Is there too much data and do we need to narrow our scope? Is the data in a form we can use or do we need to manipulate it?" After the output was determined and the inputs examined, then we could select the language and sometimes even the platform to write our program in. After each of us got a clear picture of output, input, and platform, we all used our individual preferences to plan our programs before starting to write them. I favored flowcharting, but we were free to use any planning method we wanted to, we just had to plan before we wrote. We were also reminded that there was no guarantee that we would be the person who would be maintaining this code in the future, so as we wrote our code, we had to keep it easy to read and put in copious comments. I hope this helps. It has helped me for many, many years.
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.
"Communism is like having one [local] phone company " - Lenny Bruce
I think the authors of SICP realized there were other models out there,
;-). See below.
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
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
Here's a concept i've been working on, (for about 4 years!)
it's sort of OOO programming.
The basic theroy goes somthing like this.
1:
Imagine what it would be like instelled libjpeg on you machine, and all applications that could save graphics could instantly use libjpeg.
2: Now that you managed that,
Imagine that your computer stores stats/hiristics on your usage, and if you never save from one application using libjpeg than it no longer presents it to you.
3: now extend the concept to any component and use the stats/hiristics to generate a nural net.
4: stringing it all together,
The input's and outputs of the components can be represented by 'data types' stored in a dictionary, each object presents this meta information to the system. So if you have a text document, a component that can convert text to Post sctipt,a compoenet that can rasterise the post script, you can then save the rasterised version using your just installed libjpeg.
5: Extensibility and configuration.
All systems components (including the nural net processors etc...) are 'components', so can be swaped out for differnt tasks or improved components.
The meta-data contains enough information that the system can find new version releases.
System stats are stored, and can be used to rate components, e.g. 'The machine on 10.191.1.51 says that it's users prefer this compoenet to do the job, and it's better quiality and faster, do you wan't to give it a go?'
This also provides a mechinism for the system to search for new components, process tasks on the network(load ballencing), thread tasks. etc...
Systems components can be as small as an number stored in memory and as large and an office suite.
Expect the first beta in about 5 years time... and enjoy.
thank God the internet isn't a human right.
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!
thank God the internet isn't a human right.
It seems to me that the language used to write a program should, in large part, determine the program model. For example, the programming model I used when writing mainframe programs in COBOL and IDEAL would be useless for the programs I now write in JAVA. Converse is also true.
While there are some aspects of a program that will be true regardless of the language, such as database reads, and user displays, how these things are implemented are langage dependant. Tell a COBOL programmer use a different class for all database access and you will get a dumb look. Tell a JAVA programer to use 1 class for each program and she give up programming.
Other posters have talked about how over-modeling can create confusion. But under-modeling can do the same. The amount of modeling needed by a program is language dependant.
I think this is why language syntax is taught before program models. A model for a specific program needs a context, the langage syntax provides that context.
Enjoy your life, it's the only one you've got!
There's more than one way to get a job done, however. Never lock yourself into a single way of doing things. Use the Unified Method as a guide for developing your own procedures (which it how it was intended anyway).
I recently read a weblog from a young yet experienced programmer. He clearly states that programs should be written with easy readable statements.
Because the code should be the documentation, and will become the facts, surviving any design tool, paper or specification that led to it.
I agree completely with him. Sometimes programming compares to the art of writing, or even philosphy.
Well documented and readable code also covers the DRY (Don't Repeat Yourself) principle. That does not mean that the concept shouldn't be created or documented. It means that the code digs in far greater detail to what are the exact businessrules. Therefor it is imperative that the syntax of the language helps to the readability.
Closing the gap between the problem space and the solution space as much as possible, is the real achievement. Writing readable code is a great way to do just that.
--------
* Sigh *
I disagree. I think structure should come before things like, say, pointers.
The article poster should do some research into the newish computational calculi, which were designed to express these very ideas. Object calculus and relational calculus would be good places to start to get a semantic foundation.
Google will show you the way.
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?
i find it easier to imagine a spinning and unfolding cube with me floating inside the cube. i wonder if THAT means anything... apart from the fact that i am stoned immaculate... :S
Forgive him, for he believes that the customs of his tribe are the laws of nature! -- G.B. Shaw
Huh? Pointers?
I didn't say anything about pointers. In fact, I'd favor leaving out that stuff for a while. Part of the reason I think that C-style languages are a poor choice for a first programming course.
In general, I'm a fan of introductory approaches that maintain abstraction (e.g., the SICP-style discussion in Scheme of how to do objects) and dislike things that introduce contingent facts about mapping onto hardware (e.g., procedural languages, where the first thing you have to learn is some rudimentary I/O, which is almost always a rat's nest of special cases, complexity and kludges).
For starters, I favor languages where you don't even see pointers!