The Difference Between Electrical Engineers and Computer Scientists | Hacker News Reader

The Difference Between Electrical Engineers and Computer Scientists

philip.greenspun.com

40 pointssmanek30 comments

Ugh. As someone with an EE degree, this is a nice allegory explaining why anyone with a CS degree coming in an job interview at my company has to demonstrate that they've overcome their deficiencies introduced by the CS program.

Usually a few questions involving pointers does the trick quite nicely.

In fact, I'm almost at the point where I'm rejecting applicants with CS degrees out of hand. I've had too many problems with architecture astronauts and the Java-solves-all-problems crowd.

I think that is an unfair characterization. People from reputable CS programs don't think this way. The problem is watered down schools giving CS a bad name.

Right, any program that leaves its students thinking any one language solves all problems has failed to do its job.

Isn't the real bug here that your hiring process is using the degree program as input in the first place? If a few questions about pointers are all it takes, then isn't that a better, cheaper indicator to use?

I feel so sad, because I got a physics degree with EE as minor and an M.Sc. in computer science. I can work in x86 Asm, C, Java, PHP/Python/Perl/Ruby,Scheme and circuits depends on problems at hand. I guess I will be kicked out immediately by your filter.

At the other hand. I feel so sad for you because the method that you are using is complete hindsight driven and you are correlating wrong causes and effects and misusing statistics. So please be careful of the happening of black swans.

Of course, he asked the wrong question - if he asked the engineer to design the whole toaster, and without constraints, it would be made of carbon-fiber, generate heat equivalent to an arc-welder, and fold up into a wallet-sized package. And cost $9000.

My interpretation:

Either make a great oven, or make a specialty cake-baking device. Don't straddle the middle ground of generality, the place filled with myriad edge cases and awkward attempts at abstraction.

The supposed EE's design is too complex by half. Indexing into an array of precomputed timer values? No. That's digital "CS thinking" :)

All you need is a photodetector. The heating coils illuminate the toast, and the photodetector shuts the toaster off once it's dark enough. The darkness knob adjusts the photodetector's cutoff threshold.

This system is even adaptive -- if it's cold that day, or your bread is frozen, it'll still get toasted to the same color.

some bread (such as dark rye) has the same colour as toast.

Good point. You'd have to make the darkness control an offset from the initial darkness, rather than an absolute darkness level. Not hard, but you'd need an extra bit of analog circuitry to store the initial value of the toast's reflectance.

You could also not waste time figuring out how to store the darkness using "analog circuitry" and just put a micro on the thing. Then you could have multiple sensors that would figure out what kind of bread was put in and then toast accordingly. It would a pretty fun problem to work on once the basic toaster was finished. You could play around with different kinds of sensors - heat, infrared LEDs+detectors, normal LEDs+detector, just light detector from ambient of the coils.

And the best part would be that you get to eat piles of yummy toast.

considering the parent's post about breads such as dark rye (pumpernickel): These breads are dark enough to start that there is

1) less gradation between untoasted and burnt than say, white or wheat bread, so the same "delta dark" would results in burnt toast.

2) the toast can (if the original bread is dry and/or dense enough) become unpalatably hard during the toasting process even before turning dark enough to be considered burnt.

Another strategy I considered was using an infrared photodiode instead of a visible light photodiode. That way, the diode effectively reads the toast temperature rather than color, which would address the issues you mention. But I was a bit worried that the infrared emission of the heating coils would swamp that of the toast.

For my original design, you'd definitely have to set the control to only slightly darker than your rye bread, or you'd get burned rye toast.

Well, I reckon that charred toast is around about the same colour regardless of the original bread - charcoal is charcoal. So, what you need to do is take the initial colour, subtract that from 'burnt toast', and then divide the result into the 16 desired intervals...

For those of us that have discovered the joy of slightly burnt toast with Vegemite for breakfast, accompagnied by a strong coffee, the value 15 will be seeing heavy use :-)

Of course, I'm interested to hear how you're going to go about solving the non-uniformity of toasting problem - sometimes part of my toast is still white when other parts are black!

The only elegant way I can think of to solve the toasting non-uniformity problem requires a breakthrough in materials science.

If you could make the toaster's heating coils out of a substance that increases its resistance with increased light influx, then the bright areas of the toast would increase the coil resistance nearby, thereby producing more heat locally and tending to even out the toast.

Of course, this is probably a lot of work just to make a toaster.

I was thinking instead of light sensor how about a smoke detector?

Why even a photodetector? Just have something that is the same distance from the heating coils as the toast. I think many toasters just use a bimetal strip that trips a release mechanically. You could probably get a big increase in accuracy by putting some kind of measuring mechanism on that.

Maybe a thermocouple to charge a capacitor for a timing element. But the mechanical solution is better.

As the old joke goes, you cannot spell 'geek' without double-E.

I've worked with them. Much respect for electrical engineers.

This is not a story about a computer scientist. It's a story about an enterprise IT consultant.

A mashup between "Architecture Astronauts" and "Execution in the Kingdom of Nouns", two good reads.

Another funny one in a similar vein, taken from a real story (supposedly), is "the complicator's gloves".

EE, bottom-up problem solving; CS, top-down problem solving?

EE's that I have worked with seem to understand system function deeply first, and build around it.

CS's usually mock-up simple versions, get it right, then optimize later.

Broad generalization I know, but do others observe this? Possible reasons: 1) high cost of iteration in most hardware systems vs software. 2) University educational strategy in CS vs EE. 3) Availability of easy-to-use, quality, low-cost tools for software vs hardware.

Moral of the Story : Don't Complicate simple things.

Pity the other lesson - don't simplify inherently complicated things - isn't as popular.

"Users won't buy the product unless it has a user-friendly, graphical interface. When the breakfast cooker is plugged in, users should see a cowboy boot on the screen"

http://arstechnica.com/reviews/os/open-moko-software.media/a...

"... The second advisor, a computer scientist, immediately recognized the danger of such short-sighted thinking. He said, "Toasters don't just turn bread into toast, they are also used to warm frozen waffles. What you see before you is really a breakfast food cooker. ..."

Code sharp, not pretty?

Given enough time the two disciplines will probably become closer, some university departments have aready combined them both (Southampton I believe does this).

I dread to think what sort of toasters we'll get when this happens!

At MIT (where Greenspun's been for a long time) they're together in a major. Which might explain why he's writing about how different they are.

Studying robotics, one learns an effective combination of engineering and computer science theory. So I'd have given the same answer as the computer scientist, but in ASM, low level C and Verilog.

Reply on news.ycombinator.com