School talk:Computer Science/Wikibooks archive

The following discussion took place on Wikibooks before Wikiversity was made an independent project:

Seems to me that we need to organize this page differently, more along the lines of a university curriculum.
 * Agree. We have Wikipedia for unordered categories of topics. That said, even then there are multiple reasonable ways of organization. JRM 15:54, 27 Oct 2004 (UTC)

I don't have time right now to whip out an entire course of study, but I will do what I can right now and come back to this tonight. (Hopefully other WikiVersitians will have dropped by and fleshed it out by them! ;)
 * Sorry, I'm just here to criticize you and generally be very annoying. OK, just kidding. There are some ideas of mine in here, too. I've kept the good ones, though. :-)
 * Sorry for messing up the nesting/numbering. I really wanted to do inline comments. Be careful, readers. JRM 15:54, 27 Oct 2004 (UTC)


 * Prerequisites (topics required for computer science, such as logic, math, etc. which are covered in other "Schools").
 * Doesn't mean we shouldn't offer specialized versions where appropriate, of course. We should also take advantage of the wiki nature and offer easy linking and followups for people who want to know more about topic X even if X isn't relevant in full to CS. This sounds obvious, but it's easier to forget on Wikibooks than on Wikipedia. JRM 15:54, 27 Oct 2004 (UTC)


 * Introductory material ("Comp Sci 1")
 * History of computing
 * This part is forbidden to start with "In ancient China...blablabla abacus..." :-)
 * I'd also make it a point to focus on the nature of algorithms, instead of just simple calculation. Calculating is but a special form of algorithm. (This is true even if it's actually all that real computers do.) JRM 15:54, 27 Oct 2004 (UTC)


 * Personal Free Workstations
 * I would recommend making an effort in this intro class to point students at appropriate seminars, classes, mailing lists, whatever ... to help them get their own computing environment setup to support their computing efforts. As an example, we (the engineering department) are going to have talented, highly educated, engineers coming in who need to get a home environment setup but who are basically idiot savants.  They will have been working with mainframes and desktop supermini's for years doing sophisticated analysis on machines designed, built, and maintained by Information Technology people or outside consultants or firms.  Likely to have similar problems with specialists interested in open computational research @ home in physiology, biology, etc. as well as small startup entrepreneurs from the 3rd and 4th world as the internet arrives locally to win hearts and minds away from terrorism and other forms of grumpiness and envy of the industrialized democracies worldwide. I look foward to working with some hackers, software engineers, or computer science people in helping set up such a series of tailored introductory seminars on building and supporting personal (hopefully free but that reflects my own bias) work stations when there is sufficient activity or need to justify it rather than participation in various classes valuable to me personally. Lazyquasar 03:31, 26 November 2005 (UTC)


 * Boolean logic (vis a vis computing)
 * Base 2 arithmetic
 * I'd definitely save this until you get to hardware and demonstrate what it's good for. You don't want another generation of students thinking that computers are intrinsically binary, and that this is somehow very important to computing. They aren't, and it isn't. (Actually, the reason binary matters in computers is the same reason it's interesting for other purposes: it's the simplest positional numeral system. Most of this you don't need to know at that point in the curriculum, though.) JRM 15:54, 27 Oct 2004 (UTC)


 * Basics of computer systems (hardware, software, user)
 * Computer hardware: processor, memory, I/O system
 * A good reference for organization would be Tanenbaum's classic "Structured Computer Architecture". I do mean "reference", BTW -- I'm not proposing we copy the TOC wholesale. :-) JRM 15:54, 27 Oct 2004 (UTC)


 * Von Nuemann (spelling?) paradigm: sequence, loop, branch
 * Actually, the crucial innovation underlying the Von Neumann architecture is the realization that "code is data" -- or less hackish, that a program is but data to another program. This is one of computing's most powerful ideas; it's what compilers are based on, and ultimately establishes the computer as a truly universal machine. JRM 15:54, 27 Oct 2004 (UTC)


 * Instructional computer language -- Basic instruction in a particular programming language. This language can subsequently be used to demonstrate fundemental algorithms and concepts of computer science such as sorting, recursion, etc. The choice of language is likely to start a holy war, which I don't have time to participate in right now.
 * It really doesn't matter. People who can't ever move beyond that language shouldn't be studying computer science anyway. Pascal is still a good choice for newbies, even if it's little used in practice. People are using Java too, but this immediately gets you into OO, which is a bit much for studying algorithms.
 * If you want to be really out there, pick a non-compilable language with just the basics (binary choice, pretest loop, integer, string, array, perhaps records). This will prevent people from a) welding themselves to their computers and running everything wihout understanding what's happening and b) give them a good basis for seeing the similarities (and differences!) in "real" languages.
 * Whatever choice you make, I wouldn't go with C or C++. Whatever their merits, using them to study concepts of algorithms is asking for trouble. (And I say this as someone who's first language was C, and who still uses it happily, so don't take me for a quiche eater with an axe to grind). JRM 15:54, 27 Oct 2004 (UTC)


 * Perhaps a generic Intro to Programming is required for this - discusses the different types of control structures, and how they're used, but give examples in multiple languages or simply link to examples in other books. If multiple languages are used, a discussion would probably be required to get a reasonably sized list that satisfies most people. Such a book would be centered on the usage of commands/structures and not the actual syntax. With some exceptions in advanced concepts, most languages are fundamentally the same on usage but with different syntax, and it's that basic usage that needs to be taught in an introductory course. After understanding these basics the reader can then apply these to the language of their choice or to whichever is used in a specific advanced course. If implemented, this should be a pre- or co-requisite to all "Intro to X" courses. Xerol 19:46, 25 October 2005 (UTC)
 * The problem with something like that is that to really understand the concepts, you need to get your hands dirty. You can explain everything in pseudocode and talk about it until the ends of the earth-  until they write a program and see output on their computer screen, its too abstract for most people to understand.  Teach the ideas in their pure form, sure.  But you need to give them something to bite into as well.  Trying to teach it without actually programming is like trying to teach physics without labs-  an hour long nap between 1st period and lunch.  --Gabe Sechan 20:16, 25 October 2005 (UTC)
 * Well, the point would be to "skim over" the basic concepts before getting your hands dirty. If/Then/Else structures can easily be explained in real text, and the application of those to programming would be language-dependent. Such a course would neither be extensive nor in-depth; the purpose would merely be to prepare the readers for any language they may come across in their studies. An alternative to this could be to make a short WikiBook on it, and assign it as preparatory reading for "Intro to X" courses. Xerol 21:02, 25 October 2005 (UTC)


 * Assembly language (i.e. what computers actually understand)
 * I'd leave this to Tanenbaum (or equivalent material). Focus on the layered structure of computers, not on what's "actually" at the bottom. This is an ill-defined notion anyway -- for example, your shiny new Intel processor (or AMD, don't hit me :-) doesn't actually understand assembly, it's just converting that into RISC instructions (and is that really the end of it?) Of course, you don't need to bother with those unless you're actually designing such a chip -- and similarly, you don't need to bother with assembly unless you have a real need for assembly, and that's becoming rare these days. All you really need to know is that there's more than one level, and though the one you're working on almost always isn't at the bottom, you can be blissfully ignorant about it. JRM 15:54, 27 Oct 2004 (UTC)


 * Other computer languages (not always for everyday use, but in case somebody runs across code in one of these languages)
 * FORTRAN (history of programming; optimized mathematical execution)
 * Pascal (procedural programming)
 * Ada (attempts to prevent errors by design)
 * Ruby (lambdas, easy-to-read syntax, gets the heck out of the way for quicker data structures courses)
 * Lisp (teaches functional programming, a possible alternative to Turing machines for teaching theory, an early programming language)
 * Haskell (teaches functional programming and automatic lazy evaluation)
 * Assembly (teaches more-basic units of computation)
 * others (please help flesh this list out)
 * A long list of languages is not on most curricula. Try a general course like "aspects of programming languages", where you focus on language design and basic paradigms (functional, imperative, logic, OO). How do languages implement repetition/recursion? Why do they do it the way they do? Could it be better? What criteria do you use to decide that? Why does COBOL suck so much? (Sorry about that last one, really :-)
 * This, with a basic outline of syntax, should be enough to let people educate themselves in a language when they need it. This is really the only sensible way to go, given the plethora of languages. Don't try to learn them one by one, learn them "all at once". Of course, some languages should be taught, but the 'language du jour' has a tendency of shifting quite often. A general curriculum (and the people taught by it) easily adapt to this. JRM 15:54, 27 Oct 2004 (UTC)
 * I don't agree. The School of Informatics, which needs a lot of help (hint, hint, especially to those who want to focus on programming itself), is the school that emphasizes programming and lets people pick up languages when they need them for, say, job readiness.  I think we should stick to programming languages that either illustrate various ideas in theoretical computation or that get out of the student's way.  COBOL and BASIC do not fulfill these at all.  Bondage and discipline languages are right out unless they illustrate some concept particularly well. &mdash; 131.230.133.185 6 July 2005 04:11 (UTC)


 * Fundemental algorithms and data structures ("Comp Sci 101")
 * Sorting
 * This part should not be allowed to start with bubble sort. :-) JRM 15:54, 27 Oct 2004 (UTC)


 * Searching
 * Linked lists, trees, hashing, etc.
 * Recursion
 * This is a fundamental part of functional programming, and should probably be treated as such, even if you don't go all the way with functional programming. If you've seen it in FP, it's much easier to move to recursion in imperative languages. I've never seen a course on an imperative language (whatever one you like) that didn't treat recursion as something alien and difficult -- which of course it is, to imperative languages. No need for that. JRM 15:54, 27 Oct 2004 (UTC)


 * Object-oriented programming
 * I think the curriculum needs to be revised at least somewhat. The First Level could perhaps require two programming courses - one introductory course (in C or another non-OO language), and one OO course (in C++, Java, etc). This section is getting a bit long though, should we start a new discussion on the organisation of the curriculum below? Xerol Oplan 00:48, 26 October 2005 (UTC)


 * Software engineering
 * Parts of this should be spread out over the curriculum, to encourage people to do it right from the start (and to show them why we do it that way). Too many curricula I've seen first let students write godawful code for years, then suddenly throw software engineering at them in its full g(l)ory. There's no reason to let the curriculum match the history of software development. You can do it right from the beginning -- and I don't mean with boxes and arrows, I mean sound practical advice. (Centralize things so you only have to update once, automate decentralizing if you have to decentralize. Don't use assumptions you haven't been given, but if you can ask, don't go out of your way to be "fully general" either. Don't comment on how a program does things, and try making it simpler before even commenting what it does. Keep track of what you're doing, why you're doing it, and why you're not doing it differently. Etcetera, etcetera... I'm leaving out all the reasoning behind them now, of course. :-) JRM 15:54, 27 Oct 2004 (UTC)


 * I agree. IMO, we should start off the bat with CVS/monotone/whatever or maybe even RCS... something old but really good for beginners. (Only like, 2 commands you need to know?). I dunno about Windows or IDEs on Linux... --Dragontamer


 * File systems and data storage/retrievel (not databases!)
 * Sequential files
 * Relative files
 * Indexed files
 * other file structures
 * It'll be useful to correlate this with data structures. I would not go in-depth with this, though, because low-level storage structures are becoming less and less important in a general sense, and more and more part of the "things you use but don't see" section. (Point in case: databases. :-) Like assembly, you need to have a basic knowledge of this, but you're not expected to reconstruct the data from a hexdump, useful as this skill may be. (It is, really. :-) JRM 15:54, 27 Oct 2004 (UTC)


 * System programming
 * emulation/simulation (write a simple computer simulator)
 * assembling (write a 2-pass assembler)
 * linking & loading (write a linker loader using the above components)
 * This is good, but remember that not everyone needs to know about systems programming. I'd say that knowing something about compilers is more useful -- i.e., take it up a level. It may seem counterintuitive to first do a high-level compiler and then the low-level stuff, but it's actually much friendlier on the students (for one thing, you already know one half of the process, which is writing a program in an HLL). JRM 15:54, 27 Oct 2004 (UTC)


 * Computer architecture
 * Operating system fundementals, i.e. "What does an O/S do" vs "How does Linux work?"
 * I hate to repeat myself, really I do hate to repeat myself, but again, Tanenbaum. I presume this would be the vertical part, though (going into how operating systems work, as opposed to knowing where operating systems fit in in the grand scheme of things). JRM 15:54, 27 Oct 2004 (UTC)

There is a lot more to this, but I have to get going now... Jrv
 * Erm... Ditto. The sheer scale of it all is quite daunting. Oh, and also, we should keep in mind that there's more than one way to skin a cat; I'm a big fan of specialized curricula alongside the 'standard' one. This is a wiki, after all. How about curricula that offer topics for people with a certain background (functional programming for people who've only ever used imperative languages, that sort of thing) or curricula for crossovers with other disciplines (CS for linguists)? I'm saying this now because some people may be easier stirred for this sort of specialization than for the general curriculum, which will always be a battleground of consensus and will always do some things you don't like.
 * Niche topics like reverse engineering, that don't really fit in any curriculum (but prove me wrong!), despite using only fundamental knowledge, should probably not be on the 'versity (we have general Wikibooks for that). Specializations might include things like parallelism (beyond the basics that everybody should know), computer graphics, databases, and formal/mathematical construction of programs (I'm shamelessly stealing ideas from my university curriculum, here).
 * Erm... What Jrv said. We have a lot to do. JRM 15:54, 27 Oct 2004 (UTC)


 * To comment on the curriculum in general: It would be better organised to have a list of courses (possibly numbered) and then have a curriculum for Computer Science in general. This way not all courses have to be part of the curriculum (i.e. we can have Electives) and there's room to have alternate or different ones as well. For example, at the 100-level of the CS Curriculum, perhaps Intro C, Intro C++, and one other language(from a list of completed courses) would be required in addition to the other courses there. This probably isn't worded exactly how I intended it but you get the basic idea. Xerol Oplan 22:15, 25 October 2005 (UTC)