student project

C is a lot older than Ada.

John

Right. And she may have subsequently posted in sci.computer.theoretical:

I was a houseguest of the "dean" of a local electronics manufacturer who, after a few glasses of wine, cornered me and asserted that CS graduates are lousy industrial C programmers, despite spending $40K a year at university. "We don't program", seemed like a safe reply, and I was about to explain the difference between university and technical college when I noticed the wine was better than I expected.

-- Joe

Google for 'agile' or 'scrum' and start to shiver.

Interestingly Ada comes with gcc. When I type 'gnat' on the command line of my Windows PC I fire up an Ada compiler.

The syntax looks a lot like VHDL:

People who write hideous C code are the same sort who used to write hideous spaghetti Basic code. That isn't a language issue.

I like C pretty well, actually, probably because I've been using it for

For small projects the language doesn't matter much, so we can all use what we're comfortable with. I wouldn't like to think about what writing something like my clusterized EM simulator would have been like in C or Java or Basic or something like that.

(I've been updating the simulator for an aerospace client, and finally found and fixed a bug down in the dispersive metal (n < k) support that's been plaguing me for ages. It works beautifully now, and on my shiny new 200 Gflops 24-core Opteron box, it *flies*.)

Cheers

Phil Hobbs

I love REXX. I'm about 10x faster in REXX than in C++, so for things that won't need to run very long, it's a big win.

Cheers

Phil Hobbs

In all fairness to programmers, that can be the same with HW designers. I have seen some rather gross "solutions" during my career and then there is the habit of not doing the documentation right. When the boss finally insists on the module spec to be written some designers sit there totally frustrated in front of a motley collection of snippets, torn off envelope pieces and coffee-stained sheets of paper in all sorts of sizes.

If this would simulate mechanical stresses, dynamic loads and thrust my aerospace clients would probably be quite interested :-)

Do you have a description of it on the web somewhere?

Spec? What's that? I can't get management even interested in a usable requirements document. Of course when things don't turn out as they want...

Looking for that specification? ;-)

Yup, been there :-(

When I design something larger my clients always get a module spec, whether they requested it or not. I have always worked that way. Before doing a single pen stroke on paper or CAD I open a Word document and all the info I received goes in there. Then brief descriptions of the needed sub-scircuits are fleshed out. _Then_ and only then the CAD gets fired up. To me anything else is like driving through the darkness with the headlights turned off.

It's an optimizing finite-element time-domain electromagnetic code, which I've used extensively in designing infrared antennas, optical waveguide devices, and other such things. It's especially useful since it produces CAD files of the optimized geometry, suitable for importing into mask design programs etc. (It speaks DXF and CTXT dialects.)

It's highly extensible, so it could be modified to do some multiphysics things, but I haven't actually done it.

You probably wouldn't use it for microwave devices, (although you certainly could) because method-of-moments codes are much faster for ensembles of perfect conductors and dielectrics.

The manual is at

Cheers

Phil Hobbs

We usually write the manual before we design the hardware. You've got to do it sooner or later. Sooner makes it into the requirements document, and helps you think about what you're about to do.

John

If you need to step through your program in a debugger in order to figure out where it went wrong, you've written it and/or your tests wrongly.

If you do it afterwards, yes.

Testing, done beforehand, isn't *any* way to find bugs. It's a way of determining when the spec has been met, and making sure that in future it will continue to be met. In other words, it prevents bugs from being incorporated into the program.

Languages like Cucumber support tests that read like specifications, except that they're executable. There's no translation step from specs to tests; the specs *are* the tests. I don't know how to do that with hardware, but it works well for software.

BDD is just double-entry book-keeping, for software. It's impossible to envisage accounting without DEBK, and in future, it'll also be impossible to envisage software development without BDD. You should get someone to show you how it's done.

Contrary to what a lot of folk here claim, stricter compilers don't help you solve the same problem. Executable behaviour descriptions cross-correlated with executable implementations are a necessary safeguard whatever the language you use.

Clifford Heath.

I'm sure. I told my boss that I wasn't used to working on a blank canvas. It's easy, until what you build isn't what they wanted. Other simple modifications that may be saleable also don't get built. Of course the real issue is that they really don't know what they want until they see it.

I'm used to working from specs that have been *very* well thought out. It was rare to see anything significant that had to change after the spec was published. Completely different attitudes.

Maybe.

No there's an idea.

Was that at IBM, or some small places?

All the places I've worked at for any length of time have been small companies -- or small divisions of a larger company -- and usually the specs are fairly dynamic in nature. More often than not, though, the spec changes to *reduce* features rather than expand them... :-) (This experience has led me to conclude that many places don't start with a hard-and-fast spec because it can be rather embarassing to compare what ends up being marketed vs. what was initially spec'd!)

I'm told that some companies purposely underbid government contracts that are clearly ill-defined and then make their profit on charging huge change fees when it's pointed out to the government the widget can never work as spec'd.

---Joel

IBM. The system architects were quite good. Of course there is a big difference between 2 and 200 engineers working on a project.

Some things were fluid, like the operation of some specialty mode or perhaps the reset state but basic function was very well thought out. That's why the claim was 1LOC/day for programmers. All the work was done by the time what most would call "programmers" started.

Clearly. Been there. It was scary.

Yes. Don't get me wrong here - I was involved in a UK initiative to improve software quality at one time. The thing was ultimately canned because senior management did not like the inflexibility of having to specify what it was they wanted from the software! It also became clear that the consultants who were helping us could not actually deliver on their own bold promises to deliver better code more quickly.

What was done did help spread some best practice but it was nothing like enough. The problem ulitmately comes down to the weakness of software project managers and their general inability to stand up to hectoring bosses who want to see those damn engineers typing away *NOW*!

Comparatively little software has decent high level architecture diagrams in the same way that electronics does. And some of the ones that MS produce serve only to confuse rather than to illuminate. Parts of the MS "Help" system would happily define help as:

He : The masculine pronoun LP : Obsolete black vinyl music disk

The help is almost never at the right level.

Even fewer have detailed designs for the next tier.

By comparison it is much easier to resist management insistence that all electronics engineers should be hacking away at a rats nest with their soldering irons. And at least with a rats nest you can see all of it. Software developed at a console tends to have very nasty coherence length problems caused by the screen length (25 lines of old and somewhat longer now). The modern school almost *never* print out the source code. I still have a 132 column printer.

If you have ever tried it with a seriously talented team you would know that it is like herding cats. Egos get in the way. That doesn't mean it cannot be done but it requires a lot of skill to deliver a software project and get all three of budget, specification and timing. This is made a lot harder when there is no formal specification and features are being added faster than the developers can keep up.

The UK's identity card project looked to be in that mode and was saved from total failure by being cancelled after a change in government.

Actually in the scientific instrument business they still tend to be moderately small software teams in the range of 3-20 engineers on a particular product. But there is a very big difference between a relatively well specified signal generator and something that is capable of producing bulk data for days on end showing quick summary reports in realtime and is expected to look after the kit.

It isn't sensible to have one person on a single product since you are then absolutely stuffed if they fall under a bus or get poached by a competitor. Two is the minimum. This also helps with checking code since you tend to read what you intended to write whereas a fresh pair of eyes or just explaining the code verbally to an other person uses different parts of the brain and highlights any inconsistencies.

Regards, Martin Brown

On a sunny day (Sun, 21 Nov 2010 23:06:33 -0600) it happened " snipped-for-privacy@att.bizzzzzzzzzzzz" wrote in :

I did one hardware design of a very big system, sort of before we had programmable logic, and there was for a year a political meeting about every 2 weeks or so. New specs were then given, end every one of those required a board re-design. When it finally was all build and in use, one day some emergency happened, and somebody flipped the right switches, and it worked beautifully, and probably some lives were saved. After that the politics started fighting over who was allowed to flip what switches... Assigning that authority to people who would not be there when something happened. You cannot beat that sort of thinking.

Our engineering standards document says

STOP. THINK.

John