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)?
http://www.cs.nott.ac.uk/~gmh/domains.html
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.
good coders think in code, not with models to understand the code, you should be able to look at a block of asm or c or c++ or vb and understand it as is. if you need to use conceptual models try a different carreer, maybee in the fast food industry..
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.
wow. this is the first time in my life ive ever seen bigotry in the IT world...i thought that the level of intellect required to work on computers would be high enough to pass that by, but i guess i was wrong....damn....keep in my not everyone who reads slashdot it white...
> UML seems biased towards the object model of a
> program
You can use sequence diagrams like a kind of flowchart...the things passing messages around don't have to be objects, they can be functions, or objects, or white elephants.
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.
Fortran 77 for Engineers and Scientists 3rd Edition by Nyhoff and Leestma is an introductory programming text that goes into high-level design for a couple of chapters, as well as the history of computing, programming tips, etc. A very good book, IMO.
Matt
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
it would be to stop needless overcommenting of code. Not trying to stray offtopic but if you're in an introductory CS class, I believe syntax should be taught first. OO/structured programming ideas should be brought up later after the student has a firm grasp on the language that he/she is going to be applying these constructs thru coding.
/* This is the variable which is used for a
...Is absolutely overkill. Commenting is good, but this kind of commenting is awful -- trivial elements of the program are magnified 100x. Just my $0.02.
But back to the overcommenting issue, something like this:
counter. It is incremented by one each time
the program goes through the loop. */
int i=0;
All koons must die because they smells like mal odorous feet.
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.
I am fairly experienced with some types of programming, mainly small perl utilities to manage servers, server deployment, website testing, etc. Also a fair amount of C++ for my computer science classes I am taking at a local community college (BCC). A problem I am running into right now is how to structure a fairly large program. I have had one-liners grow into month-long, mulit-perl-module scripts. Now, I know advance planning would have been better, but are there books/websites/tutorials that can guide you on how to stucture a scalable program? I know, experience has helped me, but some other medium would provide a good reference. What's out there?
~Stephen
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?
I may just have to crack open this book again after all these years!
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 cut and pasted all of it as funny/nigger.txt
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
Employ the Contractor Pattern to lengthen the schedule and line your wallet with extra moola.
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.
This book is great for learning how to program.
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
Take a trip to a university bookstore and read some books on Computer Science, instead.
Not a 2-year vocational program either, please!
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 most courses they start with "theory" (they draw lines on chalkboard and paper, sometimes using an unholy amount of Greek letters) in order to avoid letting the students "get stuck" with "bad practices"
That is partly the result of the way the TEACHING of programming evolved. Programming was first taught by mathematicians and engineers. Mathematicians LIKE drawing lines on paper, and using Greek letters, engineers are "stuck with the bad practice" :-) of separating things into "theory" and "practice".
The words "theory" and "practice" have a very real meaning in the fields of engineering: it is much easier to erase a line on paper, and draw it somewhere else, than it is to pull down a bridge and rebuild it again. When it comes to teaching engineers, it would be very unwise to let the young trainees litter the countryside with their little training bridges. Of course they should learn as much by scribbling on paper, as they can, before the start to do that :-)
Programming, on the other hand, has no such limitations. Deleting a line from a program is JUST as easy (or easier) than erasing a line from a piece of paper. For those who can still remember, THAT WAS THE ORIGINAL INTENT OF SOFTWARE. I hate yell like that, but nobody seems to listen...
Writing of software (programming) has no separate "practice" and "theory". Many other, more mature fields share this behavior. Mathematics for one: you don't write a flowchart before you try to prove something. Playing chess, writing books etc...
Teaching of programming should use paper and pencil, when appropriate, (they are great tools, cheap, effective, they contain their own power supply) but should also use the computer as a valuable teaching tool. They major advantage of writing a program in front of the computer, and testing it immediately, is that you get instant feedback. This is what makes programming so much fun. You should not exclude fun from your course.
I don't know how much time you have for that course, and how much the intended audience already knows, and where do you want to get them, but I would suggest that in the beginning you should skip things like UML, flow charts and block diagrams. These tools can do miracles in the hands of capable programmers, who use them to communicate with their co-workers, but they are a mere waste of time for people who do not yet even know what a program is all about. It is a bit like not permitting a year old child to speak before he learned to spell properly...
This way you gain some time. Use that time instead to give them an understanding of the place of software. Most programmers don't know, and don't care how their programs fit in. That is a major shortcoming. Much worse than not knowing all the UML thingies. Also, try to give them some solid ground to stand on. The equipment they program, should be something they can understand. A PIC controller with LED and switches attached is a nifty thing to start with. They should FIRST learn about assemblers, and later about high level languages. A programmers should always KNOW what he is doing. He should always stand on solid ground. When they have learned to walk slowly, you can teach them to run, and fly, relying on compilers and interpreters. You can also start to teach them about operating systems, because they will have some understanding of the problems that made them necessary, and the limitations and tradeoffs they introduce. When you are done with all this, and they have at least a limited understanding of the previous topics, (the child can now speak) you can teach them the "conceptual models" (how to read, write and communicate about it).
Peter
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
Use smaller words so guys don't get lost in technical bs. Use fewer acronyms, they're confusing when a guy doesn't know what they mean, or if they mean something different to him than to you.
Also, as far as OOP goes, it's NOT HARD. In fact, it's easier than traditional programming, IMAO. Of course, I also have a strong mechanical background, and the idea of interchangeable parts is simple, as well as NOTHING NEW.
Finally, "Hello World" doesn't teach anybody anything. It's just another useless chapter, or section, or subsection.
Prolog is a logic paradigm, not functional. An example of a functional language is lisp.
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.
if you have every studied a romance language, i think programming should come fairly easily for someone. had i not taken 4 years of latin, i probably wouldn't be as good as a programmer now.
... conjugating regular verbs = object.method() ... straight-forward and gets about 80% of the verbs out of the way. conjugating irregular verbs is somewhat similar to having to learn a new component (eg, swing).
... and having a 'structured' language background (latin) helped a lot, imo
every time i learn a new (computer) language, i look at it like a new (human) language
senior year in high school, i took a course in c
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!
These books mostly seem to be out of print, but Jean Warnier took a systematic approach to programming fundamentals with "Logical Construction of Programs" and "Program Modification". Old stuff, definitely not OO, but does teach the basics of programming using a rigorous approach.
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.
This book is way beyond the ability of most students to appreciate.
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!
Someone's business card may say "Software Engineer", but that doesn't make them a software engineer.
A programmer is someone who can translate someone's solution set into machine instructions.
A software engineer is someone who can solve problems using a computer as a tool.
A lot of programmers think they are software engineers; they arrive at solutions through trial and error. They let the compiler correct their mistakes, rather than knowing ahead of time what the compiler will do with their code.
Here's a good test: ask them "What is a trie, and where and why would use use it instead of another algorithm?". If they can't answer, then they are not a software engineer.
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.
For great justice! All your base are belong to Jon Barrett.
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."
try like anything can be an object...
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.
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
There is a way to avoid assembly: start with an interpreted language who basic structures are really easy to understand and examine. LISP or Scheme work great, because one doesn't have to go below the level of cons cells to understand what is going on with the data, it must be MIT's first language for that reason.
On a personal level, I am still angry with my teachers who did nothing to demistify the computer for me. Nothing in the systems programming world cannot be explained to a smart high school student. Period. I was a smart high school kid, and learned some assembly and hardware, but stopped short of really interesting things for lack of available info; after that they taught me "programming" for several years, and although I did write rather long and rather complicated programs then, it was a total waste of time. Only when I had a chance to go back to basics, read real OS code, and understand how a C compiler worked by writing parts of one, only then did my CS education actually pick up.
Understanding assembly and a few basic things about hardware make all the difference between those who can write drivers and OS level code, and those who cannot. Of course, before such a student can really do it, (s)he must see a lot of good examples and a few high level algorithms/data structures ideas which are really math. But if you start teaching them theory supported by APIs (to make any meaningful programs possible), they will have a hard time breaking this applications programmer conditioning, whereas all really good programmers are a bit of systems programmers -- they have to be in order for their stuff to scale right, react to exceptional conditions etc.
Finally, if you are thinking of starting with an OO language, please eschew C++ (I know some students who had the misfortune of being taught that as a first langauge!). That's a language one cannot learn to program in until one understands more or less fully what one's C++ compiler does, despite all the theory that might be heaped on.
My advice is, devise your own simulated architecture and have students write short assembly programs for it. This way when time comes for them to learn loops or recursion, they will understand exactly what's going on behind their shiny new high level language, rather than being left in the fogs and darkness of "theory".
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!
I learned design in High School (SIPS, now TASIS) back in 1994, when many OO theories were being developed.
Before I ever touch a computer (we coded Pascal), I knew the entire implementation for Bubble sorts, early-terminating bbs, linear-insertion, quicksort, and many more.
After each sort analysis (entirely pen-and-paper) and algorithm layout, as well as a thorough understnading of arrays, we actually coded some.
After finishing the semester studying algorithm design, we then studied basic object theory by piecing our sorts (which ran each individually) with a driver program.
So, I heavily favor design.
I think that the current method of coding, especially in OS, of repetitiously compiling, rewriting, and guinea-pig testing is inefficient and does not lead to quality code. This method is, however, more fun than design.
Design requires a fundamental understanding of problem-solving, so it is more important to emphasize algorithmic problem-solving than syntax.
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.
Well, I thought that the level of intellect required to work on computers (e.g. 'that of a retarded monkey') would be high enough to avoid replying to stupid trolls. Hmm...
I believe finite state automata is a pretty good point to start. You can model variables, calls, etc... and they are easy to understand ...) ...)
For a bit more power, use PetriNets and StateCharts.
For OO, UML is just perfect
There exist free tools to help you with all those models (xfig, dia, xpns,
A thing you need not to overlook is to teach recursion, but I don't know any good model for this (recursion trees aren't that useful) so I suggest using a naturally recursive language ala scheme/lisp or something similar with easy to understand examples (factorial, definite integrals,
Imagine writing a simple program without even writing 1 line of code. Your program would be a visual flow diagram with nodes and bits that do work. They would do simple things like take data out of a database and format it before sticking it on a webpage etc... Nothing like making a 3D game or anything.
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
Aspect-Oriented Programming
Subject-Oriented Programming
Hyperspaces
Conceptual Modules
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.
....Scheme
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!
have a look at this one:
Design Patterns,
Erich Gamma [et al.],
Addison Wesley 1995,
ISBN 0-201-63361-2
I guess its one level beneath conceptual patterns - its about OO-classes and their relationships - you might want to take it as a "lower boundary" of your issue.
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.
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.
Having been an unsociable Apple-II, TRS-80,
Z80, 6502 programmer from ages 11 to 17 and then
having run off to MIT and taken 6.001,
I will comment that:
SICP is phenomenal. It opened my eyes to notions
of progamming, computation, encapsulation, abstraction, and design, that made me feel silly
for having thought that I previously knew something about software.
I don't know if the material was precisely hard
to absorb. I got an A, so the other 75% of the class might disagree. I will say that as much as I was able to absorb it, there was even more to
think about afterward. That course has colored the rest of my programming life.
That coloration wasn't 100% good. Design
needs to be tied to functionality. SICP
purposely and wrongly ignores real world efficiency. SICP brings up register machines
only at the end and then from a wrong and unrealistic direction. The focus was how in
a Turing-machine sense the register machine could
be gotten to do everything we'd been doing so
far. There was almost no focus on how many
register machine steps it took to accomplish
even the simplest thing we'd been doing.
The advanced among us actually did compile and
run the register machine simulator using the Scheme compiler for the register machine simulator built in Scheme, but we mostly failed to let the resulting speed inform us
that there was more to programming than
the holy grail of the knights of the lambda calculus.
It took me many years to realize that the right
design wasn't just about the right abstractions and encapsulations, but was also about letting things lie close to the machine at the right points. One needs to abstract and control complexity, but one also needs to lay things
out in a way that the abstractions don't unnecessarily move things around to eat all CPU and make unneccesary copies to eat all memory.
There's a sense in which functional programming
and Scheme/Lisp encourage getting away from the machine, and in which C/Assembler encourage not getting away, and it's really hard to argue which paradigm have had more commercial success.
http://www-2.cs.cmu.edu/~dst/LispBook/
k .h tml
And
http://mitpress.mit.edu/sicp/full-text/book/boo
for starters.
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
Funny, when I took introductory CS *ahem* years ago, they taught with Pascal and had time to teach actual CS concepts: design, analysis, algorithms, time complexity, data structures, etc. Much more recent courses have Java as the language in the intro courses and leave more than an inadequate skimming of design, analysis, algorithms, time complexity and data structures to other courses which may or may not treat them as main topics. Oh, but you do learn a nice modern language like Java! You may be able to bang out code, but I don't put any stock in your ability to design and oversee the implementation of a major project. Save yourself 4 years, dear readers, go to DeVry, you'll get just as much (unless you can afford an Ivy).
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.
Interestingly, I can best visualise the unfolding cube when said cube is spinning. :P
I wonder if this means anything?
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.
Think back to the first programs you ever tried to write. Now think how easy those same programs would be for you now.
I remember looking at a (BASIC) program to create sprites on a TI99/4A when I was first starting out. The heart of the program was a routine that essentially converted a binary string into a hexadecimal string. I remember looking at that for awhile, and finally understanding how the damn thing worked. What I remember most however, was that although I could see how it worked, I could not imagine being able to have thought it up on my own.
Now, of course, such a thing would be a trivial matter of a few minutes work, (in C anyway, I've forgotten BASIC :-)
My point is that when you're first beginning to program, there are a thousand sort of "stock answers" to "stock questions" that you don't know anything about. Even the trivial things are not so easy, and the only way to learn these things is to practice them, in a way not so different from practicing a musical instrument, or being good at say, doing inverse La Place transforms manually. Learn to program by programming. Practice helps more than anything else.
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.
If you wish to create computer programmers, teach them object models of programs in imperative languages. If you wish to create computer scientists, teach them math and functional languages.
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.
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!