It was a bit of a different time, when docbook was the way to publish, when Itanium was the 64-bit architecture, things like go and rust didn't exist and we used bitkeeper. But most of it is still relevant, and despite acquiring 2 kids since I started still have some ideas.
Yes yes, it's not Alan Turing-esque computer science. I have taught algorithms and data structures courses as well as operating systems courses to "computer science" students and this is more the second obviously. You gotta know both!
All I can say is that being a professional now for some time, anyone who knows this stuff is welcome in my team, no matter if we're bit banging hardware or writing JavaScript. When you have some concept of what's happing underneath, you write better code and, more importantly, are a better debugger.
I'm mostly cloud-y devops-y these days ... But when your CI triggers a kernel panic or a crash in some low level libray, it's nice to be able to go digging and send a patch upstream to fix it :)
Just as idle inquiry about the "CS" term, do you think the name "Computer science" would still apply (and did it always apply) to things such as CPU and OS architectures, the toolchain, etc - basically the subject of your e-book?
I am under the impression that there's a distinction between "Computer Science", which is algorithm and data structure design and analysis, and "Computer Engineering" which is basically everything else, from the hardware level up.
Or is this mostly a European distinction?
Because my friends who do "real CS" at various universities generally avoid anything which has to do with hardware and practical operating systems, and are basically mathematicians working on problems relatable to computers - their language of choice is TeX, not C. More like Turing instead of Torvalds.
I've been rattling this idea around in my head and, although it may sound crazy, I think C is a little high level to start an adult out on.
I know many people won't agree with this but all of the people I admire in the world of CS and everyone who is a true scottsman for all intents and purposes loves dipping down to a lower level once and a while. I think the best way to learn about computer science it to program for a machine so simple anyone can understand how every bit works. No magic.
One such example of this is old retro computers. Systems like old Z80 machines. If I wanted to teach everyone how to be an amazing programmer I'd start them out on an old broken computer, help them fix it and get it working, help them get programming and wet their feet copying in some hex values to get some binaries programs working, start them up with a notebook and give them "homework" of a few really useful routines to write for themselves in Assembly. They'd write the assembly and compile it with pen and paper so ther really understand what's going on. Then we'd write an assembler together, then from an assembler we'd write up a standard library, then from there we'd get to a compiler for a language they make up. After that the sky is the limit. Maybe help them start writing their own ROMs for the machines and see where they can take it. (Maybe 6 months to 1 year)
If someone was able to get through that they'd really, truely, understand everything in the computer. Funnily enough that's what most of my CS education feels like right now (except much less fun and I'm learning less then I would from this). Intersplice these sessions of training with lectures of computer architecture, basics of electronics, how each of the components in the computer works, different protocalls and why they are used. You'd be very well rounded and pretty much well suited for many programming jobs. Follow this up with a slow maybe 5 week transition period where you come back to a modern computer, learn some C and why C was made, learn some LISP was made, and then apply that to real world projects while only introducing new technologies and concepts only when they are of imediate use and then allow the student to learn directly from taking advantage of the benifits of these technologies.
I think a student would come out very well rounded from something like this. I wish I could pay for an education like this.
Computer science is not about computers; where does stuff like algorithms fit into this?
What is a "true scottsman" of CS? Low level programmers? What about people that have pioneered the theory of computer science? The likes of Karp, Valiant, Cook, Blum, Vazirani, Papdimitriou, Micali, Goldwasser, Goldreich, Shamir, Rivest and etc.?
I doubt these people know the inner workings of computers, but they have revolutionized our view of what it means to compute.
Increasingly today the underlying architecture, for most intents, is becoming irrelevant (to first order of magnitude). The biggest gains are not made from superoptimizing compilers, but from algorithmic efficiency. That doesn't figure anywhere in your curriculum.
I think your curriculum would be great as an intro to computer architecture, or even as a series covering the topic, but I don't think it's an adequate introduction to computer science.
I also advocate for starting with the low-level basics, although slightly lower - logic gates. Students should start off building circuits using 74-series ICs on a breadboard, while learning about Boolean logic. If the resources to work with actual hardware aren't available, a logic simulator should suffice. This is something that I think even young kids would be comfortable with doing: simple circuits to "compute" simple logic.
Then introduce binary maths and how that can also be computed using logic gates, and the concept of sequential circuits (flip-flops, latches, registers) --- allowing one to build a simple adding machine with memory. From there it's a short jump (no pun intended) to a basic CPU that interprets its data as instructions (critical concept!), and the rest follows naturally.
IMHO it's "interpretation of data" that is the key concept, regardless of whether you're working in high or low level, and that comes directly from understanding the basics.
That may be the ideal way to learn CS, but the problem IMO is that lots of people are going to lose interest immediately. When you start with a web app or a game they can immediately feel like they are developing a practical skill.
> I think the best way to learn about computer science it to program for a machine so simple anyone can understand how every bit works. No magic.
We do this in my school, sort of. The 2nd year courses teach you to know how to write assembly in a fictional subset of MIPS (https://www.student.cs.uwaterloo.ca/~cs241/mips/mipsref.pdf). There is a course where we write a compiler that emits this fictional MIPS, and a course where we learn how to implement a CPU that can execute (an even smaller subset of) these instructions (starting from CMOS gates).
If you have an audience that is even interested in C (they came specifically to learn about it) it is probably safe to assume that they are interested in lower levels of tech simply by the popular association between C and that.
People benefit from context. A "how stuff is made" tour might help. I would show the newbies all the steps: how we start with a piece of C source, and go to executable. Here is a simple program that adds two numbers. Okay, we pass it through this compiler and here it is in the processor-specific assembly language, which is quite different. The "plus" is being done by this ADD instruction here, which receives values from two internal data places in the processor called registers, which are a bit like the storage boxes in a pocket calculator. Then, assembly language is coded, nearly instruction by instruction, to machine code, which is these numbers here representing ones and zeros. This is a bit like sheet music for piano being translated to a punched paper piano roll, but even more direct.
But this isn't a comp sci book really since it doesn't actually cover any comp sci topics such as the analysis of computer programs, algorithms and data structures.
That's one portion of computer science. Computer science encompases, in my mind, the study, operation, maintnence, and information that is required to perform computing tasks of the modern era.
It's no use to know about algorithms and complexity if you only know how to sort punch cards as that isn't a modern day computing task.
A computer sceince background inherently implies software development background. This also includes an understanding of low level implementation and backing hardware that makes computation possible so you may understand the limitations of the hardware and how to engineer within those constraints.
An algorithm that takes infinite time for 1 instruction is O(1) and still constant time. An algorithm that takes infinite memory for every run is still a constant memory complexity. Knowing this tells you nothing about how implementable these algorithms are and thus a focus on only this algorithm and datastructure portion of computer science is useless without practical applications and an understand of how to go about implementing and discovering your own data structures and algorithms for real life tasks.
This is very Unix, C, and Intel specific, to the exclusion of practically everything else. It's quite a good introduction to some aspects of those, but the title should be changed to make this clear.
As someone who was trained on the hardware side of EE, but has a passion for general CS and is truly fascinated by it, I believe this book will be perfect for me. I have programmed on and off for years with varying levels of intensity, but have never truly understood and studied the lower level aspects of what I was doing. My programs range from robot control to web apps, but all have been on the uppermost levels of abstraction.
I will read this over the course of the next few days and edit this comment with my thoughts and notes.
If you want to try something out but get put off by some of the C frustrations like dealing with memory and working out how to deal with the standard library you should pick up a cheap copy (or download the free copy) of Structure and Interpretation of Computer Programs. It's a book that walks you through, program by program, all of the basic concepts of programming languages, computation, and programming in a clear and orderly mannor. You'll learn LISP, which to someone who works on lower level systems may not be of any use to you, but it is choosen because it is the simplest language to learn that will allow you to on your own pase explore different concepts dealing with computation.
The book is well worth the $10s you pay for it and it isn't written like a textbook and more like a tutorial/walk through the park of computer science.
Every CS degree I know teaches aspects of every level at once. I can't think of any course which, over time, goes from a high level downwards. It wouldn't make sense.
At my school (NCSU) Computer Engineering was taught from the bottom up - Assembly was 100 level, C was 200, Java was 300. Advanced topics covered CPU caches and memory hierarchies, CS never got those.
Computer Science was taught from the top down - Java in 100 level and C/Assembly were touched on in 300 level. Advanced concepts were data structures, operating systems, and algorithms, CE never got those.
Most of us are hacking on web apps these days anyways in which a baseline from either CS or CE is fine.
First impression was wow, I've forgotten how much I've learned over the years. You would learn a lot this way.
However it's hard to call it computer science without specific attention to data structures and algorithms. What about information theory, networking, database systems, and some kind of AI related course?
Is this more about the science vs the trade? I do wonder if a practical foundation helps people understand and go deeper into the science.
When I did a computer science degree from the University of Victoria, Canada, 1996+, it more started from the "bottom". Though if I remember assembler was being moved or removed from second second year. On the other hand before I finished for new students discrete mathematics, matrix algebra, and differential equation courses were also being dumbed down or eliminates. By the time I finished course catalog had a lot of "software engineering".
This reminds me of the computer engineering coursework I completed before switching to CS during my time at university. Interesting stuff sure, but a great way to overwhelm a beginner.
I so wish I could have learned CS this way in college. I ended up doing EE instead, which really came down to a preference for the order in which I learn things.
This is similar to the practical side of the CS education we got at The Evergreen State College, except fancy high-level stuff like Unix and C wasn't covered until long after we learned to write simple programs in assembly/machine code on virtual Von Neumann machines that we implemented ourselves.
Based on the comments I see here (about how they wished to learn CS, or CS vs EE), I wish this book had a different title with more of an indication that this is a operating systems book (though not 100%). Computer Science is more than what is presented here.
Big O Notation/Data Structures/Algorithms, ala Dr. Knuth
Proof and theorems
Computer architecture and design (NAND gates and the like)
Language design, interpretation, and implementation
...and much more.
Do not get me wrong, I believe this book is valuable (BIG 'THANK YOU' to Ian Wienand for it). I just wish the title could have been different.
I agree, the book isn't very "bottom-up" at all, perhaps with the exception of "Binary and Number Representation" being the second chapter; the rest of it looks like OS stuff.
I agree, and these are important CS topics. However, Big O made so much more sense to me after I've had a chance to understand basic machine execution and written a few non-trivial programs.
There's another aspect regarding when to introduce some of these topics - getting kids and new CS students interested and energized about what they are studying. I know the argument could be made that if these topics aren't of interest then don't do CS, but they must be introduced at the right time.
My first job after graduation (CS) was writing code in 6502 assembler for business phones (I know, I'm dating myself). What I learned there was the basis for code I write even today. There's nothing like understanding from the ground up.
[+] [-] delsarto|9 years ago|reply
It was a bit of a different time, when docbook was the way to publish, when Itanium was the 64-bit architecture, things like go and rust didn't exist and we used bitkeeper. But most of it is still relevant, and despite acquiring 2 kids since I started still have some ideas.
Yes yes, it's not Alan Turing-esque computer science. I have taught algorithms and data structures courses as well as operating systems courses to "computer science" students and this is more the second obviously. You gotta know both!
All I can say is that being a professional now for some time, anyone who knows this stuff is welcome in my team, no matter if we're bit banging hardware or writing JavaScript. When you have some concept of what's happing underneath, you write better code and, more importantly, are a better debugger.
I'm mostly cloud-y devops-y these days ... But when your CI triggers a kernel panic or a crash in some low level libray, it's nice to be able to go digging and send a patch upstream to fix it :)
[+] [-] ivoras|9 years ago|reply
I am under the impression that there's a distinction between "Computer Science", which is algorithm and data structure design and analysis, and "Computer Engineering" which is basically everything else, from the hardware level up.
Or is this mostly a European distinction?
Because my friends who do "real CS" at various universities generally avoid anything which has to do with hardware and practical operating systems, and are basically mathematicians working on problems relatable to computers - their language of choice is TeX, not C. More like Turing instead of Torvalds.
[+] [-] kj01a|9 years ago|reply
[+] [-] jdhendrickson|9 years ago|reply
[+] [-] gravypod|9 years ago|reply
I know many people won't agree with this but all of the people I admire in the world of CS and everyone who is a true scottsman for all intents and purposes loves dipping down to a lower level once and a while. I think the best way to learn about computer science it to program for a machine so simple anyone can understand how every bit works. No magic.
One such example of this is old retro computers. Systems like old Z80 machines. If I wanted to teach everyone how to be an amazing programmer I'd start them out on an old broken computer, help them fix it and get it working, help them get programming and wet their feet copying in some hex values to get some binaries programs working, start them up with a notebook and give them "homework" of a few really useful routines to write for themselves in Assembly. They'd write the assembly and compile it with pen and paper so ther really understand what's going on. Then we'd write an assembler together, then from an assembler we'd write up a standard library, then from there we'd get to a compiler for a language they make up. After that the sky is the limit. Maybe help them start writing their own ROMs for the machines and see where they can take it. (Maybe 6 months to 1 year)
If someone was able to get through that they'd really, truely, understand everything in the computer. Funnily enough that's what most of my CS education feels like right now (except much less fun and I'm learning less then I would from this). Intersplice these sessions of training with lectures of computer architecture, basics of electronics, how each of the components in the computer works, different protocalls and why they are used. You'd be very well rounded and pretty much well suited for many programming jobs. Follow this up with a slow maybe 5 week transition period where you come back to a modern computer, learn some C and why C was made, learn some LISP was made, and then apply that to real world projects while only introducing new technologies and concepts only when they are of imediate use and then allow the student to learn directly from taking advantage of the benifits of these technologies.
I think a student would come out very well rounded from something like this. I wish I could pay for an education like this.
[+] [-] Ar-Curunir|9 years ago|reply
What is a "true scottsman" of CS? Low level programmers? What about people that have pioneered the theory of computer science? The likes of Karp, Valiant, Cook, Blum, Vazirani, Papdimitriou, Micali, Goldwasser, Goldreich, Shamir, Rivest and etc.?
I doubt these people know the inner workings of computers, but they have revolutionized our view of what it means to compute.
Increasingly today the underlying architecture, for most intents, is becoming irrelevant (to first order of magnitude). The biggest gains are not made from superoptimizing compilers, but from algorithmic efficiency. That doesn't figure anywhere in your curriculum.
I think your curriculum would be great as an intro to computer architecture, or even as a series covering the topic, but I don't think it's an adequate introduction to computer science.
[+] [-] userbinator|9 years ago|reply
Then introduce binary maths and how that can also be computed using logic gates, and the concept of sequential circuits (flip-flops, latches, registers) --- allowing one to build a simple adding machine with memory. From there it's a short jump (no pun intended) to a basic CPU that interprets its data as instructions (critical concept!), and the rest follows naturally.
IMHO it's "interpretation of data" that is the key concept, regardless of whether you're working in high or low level, and that comes directly from understanding the basics.
[+] [-] junke|9 years ago|reply
[+] [-] vlunkr|9 years ago|reply
[+] [-] zodiac|9 years ago|reply
We do this in my school, sort of. The 2nd year courses teach you to know how to write assembly in a fictional subset of MIPS (https://www.student.cs.uwaterloo.ca/~cs241/mips/mipsref.pdf). There is a course where we write a compiler that emits this fictional MIPS, and a course where we learn how to implement a CPU that can execute (an even smaller subset of) these instructions (starting from CMOS gates).
[+] [-] kazinator|9 years ago|reply
People benefit from context. A "how stuff is made" tour might help. I would show the newbies all the steps: how we start with a piece of C source, and go to executable. Here is a simple program that adds two numbers. Okay, we pass it through this compiler and here it is in the processor-specific assembly language, which is quite different. The "plus" is being done by this ADD instruction here, which receives values from two internal data places in the processor called registers, which are a bit like the storage boxes in a pocket calculator. Then, assembly language is coded, nearly instruction by instruction, to machine code, which is these numbers here representing ones and zeros. This is a bit like sheet music for piano being translated to a punched paper piano roll, but even more direct.
[+] [-] joatmon-snoo|9 years ago|reply
It's a very distinct segment of the whole hardware/software spectrum that's very, very far off from the realm of, say, dev ops.
[+] [-] walshemj|9 years ago|reply
Bear in mind that this class was aged 14 and was the CSE (ie the vocational stream for those leaving at 16)
[+] [-] sAuronas|9 years ago|reply
[+] [-] witty_username|9 years ago|reply
[+] [-] ensiferum|9 years ago|reply
[+] [-] gravypod|9 years ago|reply
It's no use to know about algorithms and complexity if you only know how to sort punch cards as that isn't a modern day computing task.
A computer sceince background inherently implies software development background. This also includes an understanding of low level implementation and backing hardware that makes computation possible so you may understand the limitations of the hardware and how to engineer within those constraints.
An algorithm that takes infinite time for 1 instruction is O(1) and still constant time. An algorithm that takes infinite memory for every run is still a constant memory complexity. Knowing this tells you nothing about how implementable these algorithms are and thus a focus on only this algorithm and datastructure portion of computer science is useless without practical applications and an understand of how to go about implementing and discovering your own data structures and algorithms for real life tasks.
[+] [-] 33a|9 years ago|reply
[+] [-] DonaldFisk|9 years ago|reply
[+] [-] sepetoner|9 years ago|reply
I will read this over the course of the next few days and edit this comment with my thoughts and notes.
[+] [-] gravypod|9 years ago|reply
The book is well worth the $10s you pay for it and it isn't written like a textbook and more like a tutorial/walk through the park of computer science.
[+] [-] anjc|9 years ago|reply
[+] [-] munaf|9 years ago|reply
http://www.nand2tetris.org/
[+] [-] caleblloyd|9 years ago|reply
Computer Science was taught from the top down - Java in 100 level and C/Assembly were touched on in 300 level. Advanced concepts were data structures, operating systems, and algorithms, CE never got those.
Most of us are hacking on web apps these days anyways in which a baseline from either CS or CE is fine.
[+] [-] WhitneyLand|9 years ago|reply
However it's hard to call it computer science without specific attention to data structures and algorithms. What about information theory, networking, database systems, and some kind of AI related course?
[+] [-] lloydde|9 years ago|reply
When I did a computer science degree from the University of Victoria, Canada, 1996+, it more started from the "bottom". Though if I remember assembler was being moved or removed from second second year. On the other hand before I finished for new students discrete mathematics, matrix algebra, and differential equation courses were also being dumbed down or eliminates. By the time I finished course catalog had a lot of "software engineering".
[+] [-] arcaster|9 years ago|reply
[+] [-] spchampion2|9 years ago|reply
[+] [-] stephenboyd|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] c4n4rd|9 years ago|reply
Big O Notation/Data Structures/Algorithms, ala Dr. Knuth
Proof and theorems
Computer architecture and design (NAND gates and the like)
Language design, interpretation, and implementation
...and much more.
Do not get me wrong, I believe this book is valuable (BIG 'THANK YOU' to Ian Wienand for it). I just wish the title could have been different.
[+] [-] userbinator|9 years ago|reply
This is what I'd consider "bottom up":
https://www.amazon.com/Code-Language-Computer-Hardware-Softw...
[+] [-] blueatlas|9 years ago|reply
There's another aspect regarding when to introduce some of these topics - getting kids and new CS students interested and energized about what they are studying. I know the argument could be made that if these topics aren't of interest then don't do CS, but they must be introduced at the right time.
[+] [-] blueatlas|9 years ago|reply
[+] [-] thegabez|9 years ago|reply
[+] [-] jeisc|9 years ago|reply
http://link.springer.com/search?query=&search-within=Journal...
[+] [-] quantum_state|9 years ago|reply