Since when is not having a bug patentable?

. . . .

A pathetic attempt at humor, irrelevant, and argumentative. Grow up, fool.

I didn't mean to sound snarky - it just doesn't sound like you've had the pleasure of having to oversee a lot of software development. If you're not on the hook for end-user functionality, that makes for a ... less interesting living :)

I have had contact with people who claimed to replace software developers with tech doing LabView. I wished them luck.

Maybe it's grown; I dunno. I would be scared to use it for production work.

I keep hearing and seeing that, and then the tide rolls back out. The problem is, ironically, that the solutions tend to be closed-source and the vendor dies.

I have used Rational Rose, ObjecTime and one other such CASE tools in anger, for production work, and only the other one is still around ( whatever IBM calls the Bruce Powell Douglass solution these days - used to be Rhapsody).

i can't defend the economics of it much. it does enable a certain transparency.

One of my mentors put this as "why can't you buy software like you buy chips?" I think that's an economics problem, and I've never seen it attacked properly.

I will actually agree with you there. It requires significant discipline in establishing and enforcing "contracts" between modules, as well as the usual glories of 'C'. Or something - you have to have considerable rigor in making the behavior ... measurable.

This isn't *hard*, it's just apparently rare. I don't get it.

'C' has a very significant momentum. If I had to guess, Python might be next, although it's hard to find work writing Python.

I am as surprised as anybody at the longevity of 'C'. But I am fond of it. Maybe that's Stockholm Syndrome :)

Agreed. indeed, when you "do software" as if it were state machines, life gets better.

Indeed. I think, and this is just me, that is why you make state *explicit*. Very, very explicit.

i've had pushback from fellow software people on this, and I still don't get it. It was intuitively obvious to me from day one. Maybe it's "cheating".

Fully half my career looks exactly like that. Deterministic as all get out.

Sounds eminently familiar. In my formative years, I worked for hardware markers/FPGA writers, and while I was not an FPGA developer, I debugged a lot of them and shared the common philosophy.

I do see people who want engineers who do both, but they find it easy enough to find people who have *done* both, so they're not interested in helping me add that to the resume. The rubber meets the road there in knowing the toolchain, and you don't get that in your spare time.

And frankly, in the '90s, there were a lot of EEs who needed the FPGA work more than I did.

-- Les Cargill

Sounds interesting. Which realtime Linux? IIRC there is one which runs the Linux kernel itself in one task, and the hard realtime drivers in another task.

I have roughly 20,000 boxes in service all over the world. Most have embedded uPs, and I wrote maybe 75% of that code myself, and supervised the rest. If there is a bug in any of it, it's a big deal to fix in the field. A bug that makes one product malfunction for a single minute could cost one of our customers millions of dollars.

Very few of our products do demonstrate bugs in the field, because we are very careful. Being careful isn't brilliant, it's just tedious.

I'm here on Sunday, testing the code of a pulse generator. It's an ARM processor, coded in C, not by me. I've found about 5 bugs so far, and maybe 10 other things I want to change.

I have seen some very impressive stuff done with LabView, by "non-programmers." Real Programmers seem to hate LabView and ADA, things that let mere mortals get stuff done.

C is 40 years old. Software is the worst thing technology does. It won't be like this 40 years from now. So, what's next?

Some university or maybe company is going to figure out how to teach people to program, and to manage programming, in a safe and predictable manner.

That's what we do in our embedded programs. We whiteboard the main loop and all the state machines that it runs, document all the states and flags, take pictures and archive them. It just works.

I've known lots of programmers who didn't know about state machines.

No, it's engineering.

F1... isn't that the European copy of Nascar?

Whoops, Jan, you forgot to increment the loop counter. ;)

Cheers

Phil Hobbs

No, it is not that, he is incrementing the loop counter. It's a 3 bit platform (integer) for a 4 bit calculation, which isn't worth 2 bits.

Jamie

"Back to F1" sounds like a GOTO to me.

...and no label "F1". That's at least three bugs.

More like indycar except they don't use oval tracks,

grant@pooh:~/linux/linux-3.4.2a$ grep -r goto * |wc -l

Hmm?

Grant.

On a sunny day (Sun, 10 Jun 2012 16:41:28 -0500) it happened John S wrote in :

plonk: PLONK goto plonk;

On a sunny day (Sun, 10 Jun 2012 15:26:43 -0700) it happened John Larkin wrote in :

PLONK was actually the sound of: [x] You posting with left brain half deflated [x] You posting with right brain half deflated [x] You posting with both brain halfs deflated [x] Your airospace design hopping on the runway trying to take of.

Tick any or all to you ability. If you scored 4 crosses you qualify for participating in our tombola.

Larkin:

With nitro it makes no difference.

On a sunny day (Sun, 10 Jun 2012 23:46:14 -0400) it happened " snipped-for-privacy@att.bizzzzzzzzzzzz" wrote in :

Don't forget yourself, that makes 4 :-)

On a sunny day (11 Jun 2012 06:46:56 GMT) it happened Jasen Betts wrote in :

They don't use oval tyres either.

ISTR that parts of the 777 user interface were written in C/C++ as they could not meet the delivery targets due to a shortage of qualified Ada programmers. A glass cockpit with fly by wire is all very well but you really would not want to see a BSOD in that application...

There are 25 former senior anti-terrorist officers that would beg to differ with your interpretation of the Chinook engine FADECs reliability. MOD tried and failed to blame the pilots.

And the 777's GE FADECs are not without incident. A strongly typed robust language offers no protection at all from an incorrect algorithm:

They also generally use a minimalist controlled subset of Ada with a careful level of proof of correctness pioneered by John Barnes of Praxis as High Integrity Ada for extreme safety critical work.

You should probably try Ada or Modula2 they are about the closest to real software engineering of the present crop of languages.

C is usable with care now that modern compilers make some effort at detecting many common faults at compile time. But there is too much scope for wild pointers and buffer overruns for safety critical work.

You're the one who claims to be perfect. Blows that theory.

Am I unplonked? After being PLONKd so many times?

--

John Larkin Highland Technology Inc

Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators