So what is the difference between a software engineer and computer scientist?

Nice one!. I'm feeling analog(ue) may now be a lost cause but that 'assembler only' idea would seem key to rationalis(z)ing the whole CS paradigm. john

--
Posted via a free Usenet account from http://www.teranews.com

I'm thinking that programming should not be taught at all as a distinct major. Everybody should study something real, and learn to program on the side, in the way that engineers used to take a couple of drafting courses.

Goodness knows that programming majors really can't program.

John

I'm coming in on the tail end of this. Initially I was going to say I disagree, but I think I agree with you, John.

Some of the thread I saw is comparing CS and EE. I think there is a third option: SE. Software Engineering. The program needs to mix enough theory (e.g fundamental algorithms) with enough real work environments (e.g. how do you configure an apache web sever) with real work development (working on team projects, not all individual assignments). There should be some real hardware work in there too.

It all boils down to two things: Can you understand word problems?

-- the accountants and product development managers don't understand programming terminology, so you have to learn theirs. Marketing droids might speak of "real-time web pages" which you have to tramslate to real programming rewuirements

Can you find (nearly) optimal solutions for the implementation?

-- There's a quote I like to use in this context: "an engineer is someone that can do for $1 what any damn fool can do for $2. And there's another aspect I see neglected often: It is not how well it works when it works, but how well it works when it doesn't work that really matters. IOW how does the application behave in the worstcase?

It is an issue of teahing students how to THINK. Maybe that's why some of the better ones come from non-programming backgrounds. (I may be biased here. My undergraduate degree was in Physics. My Masters was in Electrical Engineering but it was a software concentration option.)

Ed Prochak

Well, something is sure broken. Big, gigabuck-scale software projects are almost always late and over budget, and some fraction, a third maybe, are absolute failures. Eveything more complex than a toaster oven is usually littered with bugs, sometimes thousands of bugs. Performance like that deserves to be called neither Science nor Engineering.

Imagine if a third of our bridges, buildings, and airplanes fell down.

What Computer Science should do is figure out how to get a group of people to produce good code in a predictable manner.

When the best programmers never studied programming, something is wrong with CS/CE education. Reminds me of the experiment where they found that graduates of the Cooks and Bakers school were better aerial gunners than graduates of the Aerial Gunnery school.

John

This way of teaching was practiced in my days in the university. The side effect is scanty knowledge and getting into the habit of reinventing the wheels.

I'd say only about 5% of all graduates are worthy regardless of their major.

This is impossible. What is possible is to teach the different approaches and demonstrate how and why the things are done.

Any kinds of big and small business and technology projects are often late, over budget and going to nowhere. Nothing is broken, this is a real life.

And everybody seems to be quite happy with it. The things do not have to be perfect; good enough is good enough.

Look at the news: almost every week a bridge, a building, a ship or an airplane is going down. The more or less reliable things are only the things which were designed 30 years ago and produced in the big quantities. So what?

The recipe is very simple: to get it for good, every project requires about 3 times more effort, time and money then it can be allocated for it.

The meaning of education is something like a probation. One has to prove his dedication to EE by spending so many of his best years in the college.

That only tells that the programming is getting more and more into the blue color profession.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

... snip ...

I think the answer is simple. The best programmers learned fundamentals, not the language du jour nor the current hot application suite. It also helps if their IQ exceeds that of a parrot.

--
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.

Programmers learn by writing programs. The bigger and more complex the more they learn.

But the best programs are small and simple. So most programmers are learning the wrong lessons; they are indulging themselves in the games of complexity and abstraction, and teaching themselves how to fail.

The more I program, the shorter my programs become, the faster they are finished, and the fewer bugs they have.

"Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan

John

No, the best are the correct size for the task. Robust, well designed, easily maintained.

I worked on a fairly large system written in C. I needed to modify a part of it and was shocked at how poorly the algorithms were understood by the programmers.

I also asked why they wrote it in C. I was told for speed. This is for a system which responds to user input from the keyboard and submits queries to an Oracle database. How fast do you have to be to keep up with typing?

But that's rare. Given the C-inspired style of building a large program out of a lot of small subroutines, it would seem that each sub can be small and fairly simple, thus easily documented, tested, and inspected for correctness. So correctness of the program as a whole is an interface management issue, which lead programmers and managers should learn how to be good at. They're usually not.

Most code these days is just a heap of characters, undocumented and uncommented and largely untested. No wonder people can't put together reliable systems from bunches of these.

John

"...followed by heavy hardware experience." That's the ticket. The best programmers I know are the ones who would not shy away probing a few signals with a scope, fix their truck, repair the oil burner of the central furnace when it broke etc. Including my father. He had to automate a cold-rolled steel line with 2K of RAM. To the younger readers: No, 2K is not a typo. And he taught me how to diagnose and fix an oil burner ;-)

--
Regards, Joerg

http://www.analogconsultants.com

I agree. Of course, I'm biased. ;)

I have a fairly complete workbench, with two oscilloscopes, one analog and one digital, a 16-channel logic analyzer, signal generator, counter, 7 1/2 digit bench multimeter from HP, two GPIB triple power supplies from Tek, another basic power supply, soldering iron, a variety of programmers and ICE tools, etc. Plenty of spare parts around, including a variety of lenses and so on, so I can cobble up things as I need them. I can read schematics and can even sometimes contribute an idea here and there or find a problem in them.

I also can do everything from changing liquids to pulling axles and replace bearings to milling new parts for my vehicles. I can cut and weld and I've made some really great gate hinges and various parts I can't buy elsewhere for the farm here. I know my way around an oil burner, too -- though that was learned more recently when I actually had to work on a problem with the firebox temperature sensor.

I can also tend and milk cows, know my way around a horse, slop the hogs, take care of the chickens, operate a JD backhoe and front loader, separate cream from milk with a hand-crank and make butter in a mason jar, and build a barn alone.

But I suppose that's why I enjoy embedded work so much. I get to ask questions, interfere with, and kibitz on everyone else's tasks and make their life a real pain. ;)

Jon

I did a multiplexed fire alarm/hvac control remote with a 6802 uP. It did software single-slope a/d conversion (4 channels at a time), remote contact supervision, relay drivers, stuff like that. Binary comm protocol with CRC. Software UART in the receive direction, software UART and FSK generation for transmit. Ran with 128 bytes of ram and 1024 bytes of eprom. There are still jillions of them running in buildings in Manhattan.

John

Then you must remember the D5 kit?... One of my first endeavours was to make its monitor run on a 6800 board I had built using an indicator/keyboard another guy in the neighbourhood had built. The published sources (Herve Tireford was the author of these again, IIRC) were something I was learning from back then... I somehow refuse to believe it has been well > 20 years ago. Did you use an Exorciser? Not so long ago I did an emulation of the MDOS09 under DPS, it can actually be accessed via telnet and runs about 20 times faster than the emulated original 2 MHz

6809 CPU ran, but does what it was intended to do :-).

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

[...] [...]

Excuse me for butting in, but I still have an Exorciser II (2 MHz

6800), a D1 Kit, and a D2 Kit, all in working condition. :-)

But where do you get your 8" floppies? :-) :-)

Back in the 80-s I had two Bulgarian 8" drives, clones of something, which did work in a way I had to become an expert of locating/repairing/replacing bad sectors to rescue an hours work... The good side was they taught me backup habits :-).

If I get around to a spare system here or have the one I constantly use free for a while I'll put that MDOS09 emulation online and post a note. Oh, the 8" drives (huge 512 kB each, up to 7) are nowadays DPS files, maintained in CPU memory while emulated :-).

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

Oh, I still have about 100 new 8" floppies in sealed boxes, and some

1000+ used ones. Very few of the latter have developed any "bad spots." Most of them are still as good as new, actually. [...]

Here is a very good 680x emulator. It emulates the SWTPc S/09 hardware and is capable of running the FLEX, UniFLEX and OS-9 operating systems.

Sometimes I also put online one of my "real" S/09 systems with 6809 UniFLEX, for "trusted" users. :-)

I wrote a little monitor/debug program that behaved like DEC's ODT debug routine, in a box with appropriate hardware. I'd unplug the 6802 CPU and plug this in so I could load code, patch, poke breakpoints, stuff like that. It could also single-step target code by doing an RTI into the code and asserting NMI at just the right time, 17 clocks later or some such.

We used a cross-assembler that ran on a PDP-11, under the RSTS or RT-11 operating systems. The 6802 assembler was entirely macro defininitions within Macro-11, the native PDP-11 assembler. It worked great (Macro-11 was a superb thing, more a language processor than a simple assembler) although it was rather slow, minutes to assemble typically.

Now we mostly use 68332's, with the jtag-like BDM pod running into a laptop pc. An entire application build (preprocess source, assemble, postprocess listing, build rom image with a couple of FPGA config files thrown in) takes a couple of seconds.

John