Re:What every programmer should know about memory
by Groxx on Tuesday July 13, 2010 @06:47PM
(#1513006)
paragraphs 2-3) absolutely. But that's dealing with logical operations, not logic gates. Physical logic gates are an implementation of those operations, not the other way around.
P5-7) I see this as an inherent flaw in CS education, but it's been a rational flaw: multi-core systems are relatively new. Sequential approaches made a lot of sense at a physical and logical level. At least it's improving, if slowly. And, again, EE is an implementation of the logic, not the other way around. EE itself may provide an application, perhaps one that's easier to grasp by most people (to which I must say: proof?), but so is programming. And for programmers, programming seems to me more applicable, and certainly a quicker-to-test method. How much learning a functional language would help the average programmer is another argument entirely.
P8) well yeah. There you're working directly with things resulting from the electronics at the lowest level. This is very very strictly a combined field, however. The same is true for many fields - they are nearly defined by their crossing of multiple borders. Programmers, for instance, have absolutely no requirement that they learn one bit of user interface design - they may only ever design low-level APIs. Top-level design is partly defined by that bit of art / UI theory crossover. Note also that very few CS majors cover UI at all, at least as far as I've seen, unless they're specifically for UI.
P9) If anything that supports the "I had to learn it, so you do too" mentality.
An analogy is perhaps in order: if I'm trying to make a better wood glue, the underlying operation is to connect two pieces of wood. Will studying nails help me make better glue, just because it also connects two pieces of wood? And since nails are (often enough) made of metal, how about some metal-smithing to go with so I can make my own nails to learn from?
------
edit: I am actually interested in continuing this, there's no malice here (and apologies if it's been interpreted as such), I'm just fairly strongly opinionated on this. I've had a small chunk of digital electronics, and have yet to see a return from it for programming, though I'll definitely dive into an Arduino some time soon. If you think there's something special about general EE education that's lacking in general CS that is best taught from an EE perspective, I'd love to know what it is, because I'll happily learn it. I just haven't found any in my admittedly-very-shallow experience.
Parallelism I'm divided on. There's indeed much more focus on it in EE, and much more needs to be in CS... but I'm not convinced the timing diagrams will help any programmer more than some of the basic algorithms in CS, and my own experience has essentially only served to waste my time.
P5-7) I see this as an inherent flaw in CS education, but it's been a rational flaw: multi-core systems are relatively new. Sequential approaches made a lot of sense at a physical and logical level. At least it's improving, if slowly. And, again, EE is an implementation of the logic, not the other way around. EE itself may provide an application, perhaps one that's easier to grasp by most people (to which I must say: proof?), but so is programming. And for programmers, programming seems to me more applicable, and certainly a quicker-to-test method. How much learning a functional language would help the average programmer is another argument entirely.
P8) well yeah. There you're working directly with things resulting from the electronics at the lowest level. This is very very strictly a combined field, however. The same is true for many fields - they are nearly defined by their crossing of multiple borders. Programmers, for instance, have absolutely no requirement that they learn one bit of user interface design - they may only ever design low-level APIs. Top-level design is partly defined by that bit of art / UI theory crossover. Note also that very few CS majors cover UI at all, at least as far as I've seen, unless they're specifically for UI.
P9) If anything that supports the "I had to learn it, so you do too" mentality.
An analogy is perhaps in order: if I'm trying to make a better wood glue, the underlying operation is to connect two pieces of wood. Will studying nails help me make better glue, just because it also connects two pieces of wood? And since nails are (often enough) made of metal, how about some metal-smithing to go with so I can make my own nails to learn from?
------
edit: I am actually interested in continuing this, there's no malice here (and apologies if it's been interpreted as such), I'm just fairly strongly opinionated on this. I've had a small chunk of digital electronics, and have yet to see a return from it for programming, though I'll definitely dive into an Arduino some time soon. If you think there's something special about general EE education that's lacking in general CS that is best taught from an EE perspective, I'd love to know what it is, because I'll happily learn it. I just haven't found any in my admittedly-very-shallow experience.
Parallelism I'm divided on. There's indeed much more focus on it in EE, and much more needs to be in CS... but I'm not convinced the timing diagrams will help any programmer more than some of the basic algorithms in CS, and my own experience has essentially only served to waste my time.