No?

My EE classes were about logic gates, flip-flops, and other abstractions. Logic gate chips are abstractions on some complex stuff that you do NOT have to worry about in CS (the real stuff -- resistance, etc).

EE, as served to CS folks, is another approach towards understanding &&, ||, ^, and so forth. You get a firmer grasp on the relationships between logical things. For example, it should be trivial for you to see that !(a && b) == (!a || !b), and you can transform your complex conditional statement to whatever is most readable.

For that matter, should you have to work with assembly, what you learn of these logical abstractions will help with optimization.

Another point... Especially in introductory CS courses and in most algorithms courses, we focus primarily on sequential approaches towards problem solving. In EE, things are, by default, parallel. They have to force sequence (where necessary) with such mechanisms as flip-flops. Exposure to thinking the EE way actually helps with abstract problem solving in parallel software development. For example, software "pipelines" are modeled much after the hardware circuit pipelines. OpenGL? Functional programming? Many similarities.

I remember very specifically coming up with a good heuristic towards solving the big P/NP problem that came from a realization I made from playing with the EE logic stuff.

What about synchronization? Locks? You have handy API for this stuff, but, as evidenced by a lot of bad programming and fear of parallel programming in the last 20 years, people do not actually know how to use these tools, much less how they work. And the EE guys work with this kind of thing regularly; they already have a number of answers that we can use to model our software.

Finally, if you ever have to develop software that helps in the operation of circuit boards, dealing with FPGAs or microprocessors, the EE knowledge helps you and them debug interaction problems (the most common problem being that of timing and how to synchronize all those parallel events). I know... been there... was thankful for the background and was able to help dig into FPGA code to find the subtle problems quicker.

Just to toss in the authority argument, isn't Sussman an EE guy?

So yes, a certain exposure to EE is valuable for students of CS, primarily for the exposure to other ways to approach everyday CS problems.

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.

I maintain that to work well at abstraction level N, you need a good conceptual understanding of abstraction level N - 1. All abstractions leak, and you need to be able to handle it.

To work really well, it also helps to understand level N+1 or N-2, respectively--either by implementing a higher level abstraction in a lower level environment, or by working on two levels at once (and thus needing to understand the level below the lower level).

For instance, you might be stuck with using C or Java and thus have to reinvent higher level abstractions through clever use of function pointers or design patterns or something--hence thinking at N+1, implementing at N, and being mindful of N-1 as you implement. Or you may be writing in Python but optimizing code bottlenecks in C, hence when writing Python (N) you have to understand the C (N-1), and when writing C (N-1) you have to understand the assembly (N-2).

So by induction, you need to learn N - 2, N - 3, ..., 2, ... 1? I wholeheartedly disagree. By that logic, why stop at transistors? Let's get down to the physics of how transistors work, or hey, atomic physics.

Ehhh... only partially. If you need to work well at level N-1, then yes, the inductive proof works. They only mentioned knowledge about a level lower than you're working at, though.

My bad, I read it wrong.

Actually in case of transistors, it is better to understand how they really work on physics level, because many abstract models of transistor do not make sense.

I said "a good conceptual understanding." Not a complete understanding.