10 ms·

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

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.

junke 10y ago
See also this presentation: Creating a language using only assembly language (https://speakerdeck.com/nineties/creating-a-language-using-only-assembly-language https://speakerdeck.com/nineties/creating-a-language-using-o...).
- bogomipz 10y ago
  Wow, this was really interesting. Do you know if there is any video of the presentation available? I wasn't able to find it in a quick search. Also I love to see people using speakerdeck.com to make their presentations available, it is so much nicer and and elegant that the abomination that is slideshare.net. Cheers.
  - junke 10y ago
    I couldn't find either. Only the github page https://github.com/nineties/amber https://github.com/nineties/amber
sAuronas 10y ago
Great explanation: you just described the perfect 9-12 year education for the future software developers or even a "STEM track" for those so inclined.
- gravypod 10y ago
  I'm worried that it may just be my love for microcomputers, old mainframes, and just computers in general that is clouding my judgement but I think this would really improve the understanding of computational systems for anyone who was so inclined to participate in the course(s) required to teach this material. Much like the steriotipical sex-ed course where students are made to carry a baby I think college CS students should be made to "carry"* their example computer that they have worked so hare to maintain and program. I feel that something like this would be rather easy to do, cost wise, as many fanatics (in an endering sense of the word) have constructed kits that replecate the functionality of these machiens. One such example is the PDP-8 kit. This would make it extremely affordable to build systems like these for may students to come. [0] I'm not saying that this exact system should be used, I'm just a fan of DIGITAL and wish I could play with more of their gear (anyone in NJ with a PDP or other microcomputers my email is in my profile), but the stands. - It's cheap to make - They understand the "GOOD OLD DAYS" to better understand design choices made on old software they will be maintaining - Due to the tough constraints of these machines they will likely cut corners. Corners we all have cut before. They will see the pain of doing that in a safe enviroment where millions of dollars or lives aren't on the line (like in the real world). - They will know every portion of the computer inside and out. - They'll get to friggen build things! Make things work! Really Program! (We all know the feeling of getting shit done and how addictive that is) * Not carry everywhere, just to class and home. [0] - http://www.sparetimegizmos.com/Hardware/SBC6120-2.htm http://www.sparetimegizmos.com/Hardware/SBC6120-2.htm
  - qwertyuiop924 10y ago
    I agree. You have to learn from both directions: go read SICP, PLAI, TAPL, PAIP, Dragon, Algorithms, and whatever else so you have an understanding of the concepts. Now build a Z80 or 6502-based computer (at the very least) and implement stuff on the bare metal so that you understand how the machine works, at least on a basic level. But if you can't be bothered to actually build a computer yourself (which is completely understandable), and still want to get a feel for hardware, write some games for an old game console. I recommend the Gameboy: it's dirt cheap (~$20 for a GBA), you can buy a flashcart + reader/writer and/or SD cart from BennVenn for ~$80-$100 (although you may have to wait a bit until he restocks), it's well documented (the PanDoc and numerous tutorials can help you out), and the toolchain is widely available (actually, several toolchains are widely available: various forks of the now-dead RGBDS, and WLA-DX, which seems to be more lively, so it's what I'd reccomend).
Ar-Curunir 10y ago
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.
- gravypod 10y ago
  Theory is useless without implementation and implementation is nothing without an understanding of theory. Implementation and theory are in lockstep but by learning theory you will not necessarily know how to implement, or even really understand, the topics you have memorized. On the other hand it is necessitated by the concept of implementation that you on one hand understand the tools you are using to solve this problem and on the other have reached a point where you see why the tool is used. You can sit a person in front of a whiteboard all you want. Brainwash them about arrays, maps, matricies, trees and graphs and they have a high likely hood of coming out knowing nothing but verbatum what you have told them. Conversly you cannot sit a person in front of a computer, guide them through the exercises that I described, and expect the same as the student who once sat in front of the whiteboard. Trees grow from seeds and the best way to plant these seeds are not with an expo marker but, in my opinion, by bringing the student to a crossroads where they need to discover a concept on their own. This is a common tactic in game design: allow the player to discover new rules after you've taught them the basic foundation. After they understand the basic foundation of how they will be interacting with the machine I think that, with the guidance of the correct assignements in the notebook codesegment phase of the program, the student will be able to create these different routines and ideas on their own. Some such examples I will provide below: - Make some way that will allow you to find a number between two possitions in memory - Make a wrapper for this routine that will operate from a starting possition and an offset of the size - Make a way to find the distance between two points on an X, Y plane - Find a way to apply the same transformation in every item between two points in memory - Find a way to implement a way of storing data about an X, Y plane. For instance where a dot is on a section of graph paper - Make a subroutine that will allow you to store potentially infinite items in a collection. There are many ways to approch this but the three main ones are to: use a section of memory that is preallocated and reallocated when it is filled, make some way to daisy chain items of the list together possibly by wrapping them in in more data that will serve to aid your program, do the same as the daisy chain but allow the chain to coninue in more then one direction. Hint: this will probably need an init_<structure>, add_<structure>, remove_<structure>, free_<structure> This would take a long time but under the correct stimulating guidance the student will be able to seek out why they need these tools. These tasks should be presented after they've completed a project that someone in our position knows that the optimal way of solving the problem was not choosen and a more abstract and simple solution exists. These situations will present themselves often. I've possitioned myself to make these suggestions to my peers at my university who are having a very difficult time passing the classes we are in together. The people who need to see why AND how. I'll look at their work and say "how about try using X method of solving the problem and show me what you come up with" and when they come up with a solution I say "now try and make it a library. Remove it from your current solution and allow yourself to use it for further work on other projects". This changes the way they think about programing.
kazinator 10y ago
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.
- gravypod 10y ago
  That is very top down. This is perfectly fine and the only reason why I think differently is because most of my peers are afraid of experimenting. They think everything they haven't seen is magic.... because well it seems that way. It's voodoo to them. When I see a compiler I just think "pfft, tokenizer, lexer, tree". When they see a compiler they think "I could never understand this in my life". It's like when I go to my mechanic. I pop the hood, he looks at it, spouts off some Geordi LaForge-sounding nonsense, I pay him and I walk away feeling like I've made out like a bandit! "That moron! That stuffs so complciated this work was worth double that! Hahahaha!" What's really happening is that my mechanic has touched under the hood and no matter the car he things "eh, I'll figure it out". Or "How hard could it be? I'f fixed thousands of cars and thousands of problems, I know what's wrong already!" He gained that experiance from actually messing around under the hood. Not from driving the car at a high level like I have but from sticking his hands in and getting into the nitty gritty. Going from the top down leaves people affraid to push further down into their machine. This is the fear of infinite complexity that they think is hiding under the surface. The truth is that all computer science material of of constant complexity when looked at on it's plane of theory. IF everything has been correctly abstracted and defined then nothing should be "complicated" but it should be "entierly understandable". Anyone who gets the basics should be able to go "eh, I'll figure it out" when referencing any part of the computer if it has been correctly implemented.
userbinator 10y ago
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.
- vvanders 10y ago
  I'd actually argue an FPGA/CPLD is a slightly better approach, simply because you have block memory that acts very much like "cache" and makes it abundant why system memory is so much slower. Since you have timing statistics it also makes it really easy to demonstrate pipelining and many other modern "quirks" of processors that have a large impact on performance.
  - gravypod 10y ago
    The barrier to entry in the FPGA world is tooling and expression. If that hurdle is solved then I'd be all for it. It will usher a new era of electrical engineering design that is as cheap as software desgin making it practical for students to try EVERYTHING on their own. To conduct similar experiments as I have with computer in electronics (as I'd like to do one day so I can get to the same place I am in electronics as I am in computer science) I'd need to spend thousands of dollars on chips and parts.
    - ZenoArrow 10y ago
      >"The barrier to entry in the FPGA world is tooling and expression" Regarding tooling, I'd say it's not quite the barrier it used to be, now that Project IceStorm exists. http://www.clifford.at/icestorm/ http://www.clifford.at/icestorm/
witty_username 10y ago
What is the point in copying hex values?
- gravypod 10y ago
  To the outside world of non-CS people the concept of a processor is magic. It is in a sense still magical to me but I can see that a processor is just a complex state machine that takes in numbers and spits out numbers. Saying that without really experiancing it means nothing and I cannot put into words the value of understanding this. It makes so many previously unaprochable tasks much less daunting. Copying in hex values will give the student many important skills. At first they will learn to recognize errors in the hex by identifying opcodes for the instruction set you are using. IIRC 0xEB amd 0xEA is a jmp. Secondly they will understand how the assebmly is turned into code executable by the CPU. It's not magic it's just a simple map operation taking the text from the assembly and 1:1 mapping it (in most cases) to opcodes. Knowing the opcodes by heart is nice for debugging and decompiling/reverse engineering code. It's fun to do and a really important skill, in my book, for anyone doing computer science in the real world (and if you're paying >10k/semester at college you should know how to do it!). Getting a feal for what is really happening under the hood, just numbers being read, run, and repeat will help you understand how to write a compiler. Again, I can tell you all this and give you a chart to memorize and say "THIS WILL HELP YOU" or I can let you natrually tackel your tasks and allow you, on your own time, to find out what helps you get the job done. The one thing that isn't negotiable is giving you tasks that incrementally will challange you but not scare you away. What is negotiable is how these are presented. I feel they should be unseen tasks hidden undernethe something that looks like something else to the student.
  - witty_username 10y ago
    > It's not magic it's just a simple map operation taking the text from the assembly and 1:1 mapping it (in most cases) to opcodes. Maybe in the Z80, but in modern x86 the instructions are broken down into micro ops and also pipelined (multiple pipelines, even). > Knowing the opcodes by heart is nice for debugging and decompiling/reverse engineering code. It's fun to do and a really important skill, in my book, for anyone doing computer science in the real world (and if you're paying >10k/semester at college you should know how to do it!). Why would you need to memorize hex opcodes for CS in the real world? I'll just use objdump or my favorite disassembler (even gdb can print instructions). > will help you understand how to write a compiler. Not sure how it will help one understand.
vlunkr 10y ago
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.
- Chathamization 10y ago
  It's not only that, but doing something like writing your own assembler probably isn't going to be terribly relevant to someone creating a web app or making a game in Unity - particularly so 5, 10, or 20 years later. Heck, I'm not even sure that working on an assembler is going to be terribly useful to most people who will be writing in assembly. Students who aren't interested in a particular requirement will complete it and then soon forget most of the things they learned. Heck, even students interested in it will probably forget most of it if they're not using it for a particular task. If they're not, you're probably better off with a quick survey course which gives them the basic understanding they need. From my experience, the biggest problem with "CS" education (which tends to be a catch all for most software related computer studies) is the lack of focus. Students get a little bit of experience making a toy in language A, then they get a little experience making a toy in language B, then they get a little dusting of algorithmic theory, etc. My suggestion would be to try to get them quickly up and running on projects they're interested, to the point where they feel self-sufficient. Then teach them what they need to make their project better. They're going to both retain a lot more and come out of it being able to do a lot more. Trying to make every CS student a jack of all trades ends up being a colossal waste of their time and money.
  - gravypod 10y ago
    All software is related in some degree. You will find that people who come from a background of compilers will do well in developing certian portions of games. In a sense most games are a compiler. You feed it in source (images, dialog, models, textures, etc) and it spits out an interactivly compiled narrative. Websites are also compilers. They just operate on a higher level of abstraction then the simple toy compiler we would right. The information to someone new is invaluable so long as they learn it themselves and aren't forced through it.
joatmon-snoo 10y ago
Except at some point you have to deal with x86 and ARM and wait a minute - this looks a lot like computer engineering. 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.
- gravypod 10y ago
  Dev ops is not computer science. Dev ops is the operations of computational devices and the upkeep of the programs that run on them. Computer Science is the creation of these programs by taking advantage of the hardware they are running on. Dev ops are the road builders to the shipping companies. They do absolutly nothing related to each other but they both need each other. Dev ops is more an information technology field and it's useless to make devops people take courses from CS other then a familarity with Unix and Windows sytems. In fact Dev Ops people should go far further into depth on Unix and Windows systems to the point at which they know every bit of information of every documentation concerning running applications, services, and jobs on these machines. Computer scientists should go into how these are implemented.
zodiac 10y ago
> 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 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).
- gravypod 10y ago
  Want to trade? You can come to NJIT: the land of physics, math, and more math. Oh and 4 "inter-disaplinary" corses (read wastes of time).
walshemj 10y ago
Interesting in the 70's at high school my first language was CECIL a cut down assembler designed for teaching. Bear in mind that this class was aged 14 and was the CSE (ie the vocational stream for those leaving at 16)
- gravypod 10y ago
  Assembly is very simple. That's it's saving grace.

junke 10y ago

See also this presentation: Creating a language using only assembly language (https://speakerdeck.com/nineties/creating-a-language-using-only-assembly-language https://speakerdeck.com/nineties/creating-a-language-using-o...).

bogomipz 10y ago
Wow, this was really interesting. Do you know if there is any video of the presentation available? I wasn't able to find it in a quick search. Also I love to see people using speakerdeck.com to make their presentations available, it is so much nicer and and elegant that the abomination that is slideshare.net. Cheers.
- junke 10y ago
  I couldn't find either. Only the github page https://github.com/nineties/amber https://github.com/nineties/amber

sAuronas 10y ago

Great explanation: you just described the perfect 9-12 year education for the future software developers or even a "STEM track" for those so inclined.

gravypod 10y ago
I'm worried that it may just be my love for microcomputers, old mainframes, and just computers in general that is clouding my judgement but I think this would really improve the understanding of computational systems for anyone who was so inclined to participate in the course(s) required to teach this material. Much like the steriotipical sex-ed course where students are made to carry a baby I think college CS students should be made to "carry"* their example computer that they have worked so hare to maintain and program. I feel that something like this would be rather easy to do, cost wise, as many fanatics (in an endering sense of the word) have constructed kits that replecate the functionality of these machiens. One such example is the PDP-8 kit. This would make it extremely affordable to build systems like these for may students to come. [0] I'm not saying that this exact system should be used, I'm just a fan of DIGITAL and wish I could play with more of their gear (anyone in NJ with a PDP or other microcomputers my email is in my profile), but the stands. - It's cheap to make - They understand the "GOOD OLD DAYS" to better understand design choices made on old software they will be maintaining - Due to the tough constraints of these machines they will likely cut corners. Corners we all have cut before. They will see the pain of doing that in a safe enviroment where millions of dollars or lives aren't on the line (like in the real world). - They will know every portion of the computer inside and out. - They'll get to friggen build things! Make things work! Really Program! (We all know the feeling of getting shit done and how addictive that is) * Not carry everywhere, just to class and home. [0] - http://www.sparetimegizmos.com/Hardware/SBC6120-2.htm http://www.sparetimegizmos.com/Hardware/SBC6120-2.htm
- qwertyuiop924 10y ago
  I agree. You have to learn from both directions: go read SICP, PLAI, TAPL, PAIP, Dragon, Algorithms, and whatever else so you have an understanding of the concepts. Now build a Z80 or 6502-based computer (at the very least) and implement stuff on the bare metal so that you understand how the machine works, at least on a basic level. But if you can't be bothered to actually build a computer yourself (which is completely understandable), and still want to get a feel for hardware, write some games for an old game console. I recommend the Gameboy: it's dirt cheap (~$20 for a GBA), you can buy a flashcart + reader/writer and/or SD cart from BennVenn for ~$80-$100 (although you may have to wait a bit until he restocks), it's well documented (the PanDoc and numerous tutorials can help you out), and the toolchain is widely available (actually, several toolchains are widely available: various forks of the now-dead RGBDS, and WLA-DX, which seems to be more lively, so it's what I'd reccomend).

Ar-Curunir 10y ago

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.

gravypod 10y ago
Theory is useless without implementation and implementation is nothing without an understanding of theory. Implementation and theory are in lockstep but by learning theory you will not necessarily know how to implement, or even really understand, the topics you have memorized. On the other hand it is necessitated by the concept of implementation that you on one hand understand the tools you are using to solve this problem and on the other have reached a point where you see why the tool is used. You can sit a person in front of a whiteboard all you want. Brainwash them about arrays, maps, matricies, trees and graphs and they have a high likely hood of coming out knowing nothing but verbatum what you have told them. Conversly you cannot sit a person in front of a computer, guide them through the exercises that I described, and expect the same as the student who once sat in front of the whiteboard. Trees grow from seeds and the best way to plant these seeds are not with an expo marker but, in my opinion, by bringing the student to a crossroads where they need to discover a concept on their own. This is a common tactic in game design: allow the player to discover new rules after you've taught them the basic foundation. After they understand the basic foundation of how they will be interacting with the machine I think that, with the guidance of the correct assignements in the notebook codesegment phase of the program, the student will be able to create these different routines and ideas on their own. Some such examples I will provide below: - Make some way that will allow you to find a number between two possitions in memory - Make a wrapper for this routine that will operate from a starting possition and an offset of the size - Make a way to find the distance between two points on an X, Y plane - Find a way to apply the same transformation in every item between two points in memory - Find a way to implement a way of storing data about an X, Y plane. For instance where a dot is on a section of graph paper - Make a subroutine that will allow you to store potentially infinite items in a collection. There are many ways to approch this but the three main ones are to: use a section of memory that is preallocated and reallocated when it is filled, make some way to daisy chain items of the list together possibly by wrapping them in in more data that will serve to aid your program, do the same as the daisy chain but allow the chain to coninue in more then one direction. Hint: this will probably need an init_<structure>, add_<structure>, remove_<structure>, free_<structure> This would take a long time but under the correct stimulating guidance the student will be able to seek out why they need these tools. These tasks should be presented after they've completed a project that someone in our position knows that the optimal way of solving the problem was not choosen and a more abstract and simple solution exists. These situations will present themselves often. I've possitioned myself to make these suggestions to my peers at my university who are having a very difficult time passing the classes we are in together. The people who need to see why AND how. I'll look at their work and say "how about try using X method of solving the problem and show me what you come up with" and when they come up with a solution I say "now try and make it a library. Remove it from your current solution and allow yourself to use it for further work on other projects". This changes the way they think about programing.

kazinator 10y ago

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.

gravypod 10y ago
That is very top down. This is perfectly fine and the only reason why I think differently is because most of my peers are afraid of experimenting. They think everything they haven't seen is magic.... because well it seems that way. It's voodoo to them. When I see a compiler I just think "pfft, tokenizer, lexer, tree". When they see a compiler they think "I could never understand this in my life". It's like when I go to my mechanic. I pop the hood, he looks at it, spouts off some Geordi LaForge-sounding nonsense, I pay him and I walk away feeling like I've made out like a bandit! "That moron! That stuffs so complciated this work was worth double that! Hahahaha!" What's really happening is that my mechanic has touched under the hood and no matter the car he things "eh, I'll figure it out". Or "How hard could it be? I'f fixed thousands of cars and thousands of problems, I know what's wrong already!" He gained that experiance from actually messing around under the hood. Not from driving the car at a high level like I have but from sticking his hands in and getting into the nitty gritty. Going from the top down leaves people affraid to push further down into their machine. This is the fear of infinite complexity that they think is hiding under the surface. The truth is that all computer science material of of constant complexity when looked at on it's plane of theory. IF everything has been correctly abstracted and defined then nothing should be "complicated" but it should be "entierly understandable". Anyone who gets the basics should be able to go "eh, I'll figure it out" when referencing any part of the computer if it has been correctly implemented.

userbinator 10y ago

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.

vvanders 10y ago
I'd actually argue an FPGA/CPLD is a slightly better approach, simply because you have block memory that acts very much like "cache" and makes it abundant why system memory is so much slower. Since you have timing statistics it also makes it really easy to demonstrate pipelining and many other modern "quirks" of processors that have a large impact on performance.
- gravypod 10y ago
  The barrier to entry in the FPGA world is tooling and expression. If that hurdle is solved then I'd be all for it. It will usher a new era of electrical engineering design that is as cheap as software desgin making it practical for students to try EVERYTHING on their own. To conduct similar experiments as I have with computer in electronics (as I'd like to do one day so I can get to the same place I am in electronics as I am in computer science) I'd need to spend thousands of dollars on chips and parts.
  - ZenoArrow 10y ago
    >"The barrier to entry in the FPGA world is tooling and expression" Regarding tooling, I'd say it's not quite the barrier it used to be, now that Project IceStorm exists. http://www.clifford.at/icestorm/ http://www.clifford.at/icestorm/

witty_username 10y ago

What is the point in copying hex values?

gravypod 10y ago
To the outside world of non-CS people the concept of a processor is magic. It is in a sense still magical to me but I can see that a processor is just a complex state machine that takes in numbers and spits out numbers. Saying that without really experiancing it means nothing and I cannot put into words the value of understanding this. It makes so many previously unaprochable tasks much less daunting. Copying in hex values will give the student many important skills. At first they will learn to recognize errors in the hex by identifying opcodes for the instruction set you are using. IIRC 0xEB amd 0xEA is a jmp. Secondly they will understand how the assebmly is turned into code executable by the CPU. It's not magic it's just a simple map operation taking the text from the assembly and 1:1 mapping it (in most cases) to opcodes. Knowing the opcodes by heart is nice for debugging and decompiling/reverse engineering code. It's fun to do and a really important skill, in my book, for anyone doing computer science in the real world (and if you're paying >10k/semester at college you should know how to do it!). Getting a feal for what is really happening under the hood, just numbers being read, run, and repeat will help you understand how to write a compiler. Again, I can tell you all this and give you a chart to memorize and say "THIS WILL HELP YOU" or I can let you natrually tackel your tasks and allow you, on your own time, to find out what helps you get the job done. The one thing that isn't negotiable is giving you tasks that incrementally will challange you but not scare you away. What is negotiable is how these are presented. I feel they should be unseen tasks hidden undernethe something that looks like something else to the student.
- witty_username 10y ago
  > It's not magic it's just a simple map operation taking the text from the assembly and 1:1 mapping it (in most cases) to opcodes. Maybe in the Z80, but in modern x86 the instructions are broken down into micro ops and also pipelined (multiple pipelines, even). > Knowing the opcodes by heart is nice for debugging and decompiling/reverse engineering code. It's fun to do and a really important skill, in my book, for anyone doing computer science in the real world (and if you're paying >10k/semester at college you should know how to do it!). Why would you need to memorize hex opcodes for CS in the real world? I'll just use objdump or my favorite disassembler (even gdb can print instructions). > will help you understand how to write a compiler. Not sure how it will help one understand.

vlunkr 10y ago

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.

Chathamization 10y ago
It's not only that, but doing something like writing your own assembler probably isn't going to be terribly relevant to someone creating a web app or making a game in Unity - particularly so 5, 10, or 20 years later. Heck, I'm not even sure that working on an assembler is going to be terribly useful to most people who will be writing in assembly. Students who aren't interested in a particular requirement will complete it and then soon forget most of the things they learned. Heck, even students interested in it will probably forget most of it if they're not using it for a particular task. If they're not, you're probably better off with a quick survey course which gives them the basic understanding they need. From my experience, the biggest problem with "CS" education (which tends to be a catch all for most software related computer studies) is the lack of focus. Students get a little bit of experience making a toy in language A, then they get a little experience making a toy in language B, then they get a little dusting of algorithmic theory, etc. My suggestion would be to try to get them quickly up and running on projects they're interested, to the point where they feel self-sufficient. Then teach them what they need to make their project better. They're going to both retain a lot more and come out of it being able to do a lot more. Trying to make every CS student a jack of all trades ends up being a colossal waste of their time and money.
- gravypod 10y ago
  All software is related in some degree. You will find that people who come from a background of compilers will do well in developing certian portions of games. In a sense most games are a compiler. You feed it in source (images, dialog, models, textures, etc) and it spits out an interactivly compiled narrative. Websites are also compilers. They just operate on a higher level of abstraction then the simple toy compiler we would right. The information to someone new is invaluable so long as they learn it themselves and aren't forced through it.

joatmon-snoo 10y ago

Except at some point you have to deal with x86 and ARM and wait a minute - this looks a lot like computer engineering. 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.

gravypod 10y ago
Dev ops is not computer science. Dev ops is the operations of computational devices and the upkeep of the programs that run on them. Computer Science is the creation of these programs by taking advantage of the hardware they are running on. Dev ops are the road builders to the shipping companies. They do absolutly nothing related to each other but they both need each other. Dev ops is more an information technology field and it's useless to make devops people take courses from CS other then a familarity with Unix and Windows sytems. In fact Dev Ops people should go far further into depth on Unix and Windows systems to the point at which they know every bit of information of every documentation concerning running applications, services, and jobs on these machines. Computer scientists should go into how these are implemented.

zodiac 10y ago

> 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 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).

gravypod 10y ago
Want to trade? You can come to NJIT: the land of physics, math, and more math. Oh and 4 "inter-disaplinary" corses (read wastes of time).

walshemj 10y ago

Interesting in the 70's at high school my first language was CECIL a cut down assembler designed for teaching. Bear in mind that this class was aged 14 and was the CSE (ie the vocational stream for those leaving at 16)

gravypod 10y ago
Assembly is very simple. That's it's saving grace.