cool article, interesting quote

formatting link

"The use of C is really criminal," said Ganssle. "C will compile a telephone directory, practically. I guess we use C because we think debugging is fun."

John

Reply to
John Larkin
Loading thread data ...

Interesting article indeed, but as usual, the real problem was not identified.

The real culprit for poor engineering in any field, let alone software engineering, is the engineer. Most software engineers simply write bad code. Even "good" software engineers write bad code. When I first started programming professionally, I burned through 11 $100+ flash EEPROMs before I got my write timing right. The C code had lots of fat in it that I didn't see until I checked the ASM outputs. I wasn't accustomed to eating through $1000 / day of company's money due to my carelessness/sloppiness. None of the software people in the group cared one bit (no pun intended). One them just patted me on the shoulder and said, "hey, good work, looks like you got that timing loop right."

It's no wonder that software engineering ranked so high on desirable occupations. Software engineers are probably the most spoiled professionals ever to exist:

  1. No heavy lifting, though fingers and wrists might hurt. Oh the pain.
  2. No asbestos.
  3. Free foosbal and ping pong and video games.
  4. Benefits that makes the even most socialist countries green with envy.
  5. No real show up time. Leave when you want. Two hour lunch more rule than exception.
  6. Free snacks. Free drinks.
  7. Free travel to conferences that are entirely unnecessary where loitering and messing with whatever looks like it needs messing with is actually encouraged.
  8. Automatic pay raises, irrespective of performance.
  9. Abitrary quality control.
  10. Profits in excess of 20,000%, in some cases, 100,000%.
  11. State of the art tools. ALWAYS. And then some.
  12. Ability to quit 4 times in 2 years, with huge gaps, and still be hired.
  13. License to kill anyone who even "thinks" of mentioning a Taylor expansion or other basic math that just so happens to be relevant to the problem at hand.
  14. Deadlines that are as about as hard as a eunuch on Viagra.

And after all this, if they don't feel like using the tool that is actually appropriate for the job, (assembly, C, or C++) they go to boss and say, "I think there would be increased productivity if we are allowed to keep our rubber duckies close by as we program." Then the boss, himself horrifically incompetent and earning $160,000US/year, and also highly disinclined to do anything that would inadvertently dislodge himself from his most fortuitous position, readily agrees, but adding, of course, a bit of bombastic babble so as to impress his superiors, who each earn $300,000US/year. "As we continue to focus on our core objectives, we must ensure that each team member has access to the most effective tools available, in particular, those yellow, polymer-based synthetic birds that make squeaky noises."

Software engineering as an engineering discipline boders on the comical.

Now where did I put that rubber duckie...

-Le Chaud Lapin-

Reply to
Le Chaud Lapin

The answer to the article is in the first paragraph:

"software glitches by a lone programmer whose code was never properly inspected and tested"

In a safety critical system this is criminal (literally, as in due diligence and best practice was not applied therefore people died due to your negligence). The programming language used is irrelevant if this is your engineering practice.

Regards, Richard.

formatting link

*Now for ARM CORTEX M3!*
Reply to
Richard

"It's a poor worker who blames his tool"

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
 Click to see the full signature
Reply to
Spehro Pefhany

Heh! I like that, being an assembler bigot myself. At the age of 46, after about 24 years of coding in high-level languages - BASIC; pascal, FORTRAN; COBOL

- and both S/370 assembler and machine language, I took a night school class in C. Not C+ or C++ or C-on-Steroids .... nothing like that. Just basic, vanilla C. Pointers to pointers to pointers ... whassup wi' dat?!! I was flummoxed, big time, until I finally got my head around the concept. I wrote one useful app. in C shortly after completing the class, then I abandoned C (as I had dropped pascal, FORTRAN, and COBOL before).

I have to say I did like some of C's syntax and its structural flexibility. I thought they aided debugging, which _every_ app., regardless of language used to build it, requires. Many of today's micros have scads of program memory, so micros are more and more able to swallow those C-generated telephone books. ;-)

I just smile whenever a youngster asks me if I have such-and-such a routine that I would give to him/her for their micro target ... OH! and it must be in C.

--
Michael
Reply to
Michael

I once had to make a fail safe device which was not allowed to have failure modes in which the safety was compromised. It was built around fail safe hardware that had three channels for each computing or input output item. It was of course extremely expensive and the code which was no more than 5000 lines was fully tested.

It would not make economic sense to have the same degree of intrinsic safety for ordinary devices where failure modes have no dramatic consequences.

Software engineering is not just about coding practices or even testing practices. The whole cycle must be made fault safe from specification down to deployment. Tools exist to make safe and proven specifications. Code can then be generated automatically by certified translating tools which produce safe code. These tools cost of course a lot of money and are restricted to certain types of problems, mainly avionics.

The organisation itself is also responsible for the safety of the code. Too often coding is seen as a minor activity that can be left to a team of lonely geeks. Hardware companies are organized to ensure that the hardware is designed and built according to good practices. This involves the personnel of all divisions. Software on the contrary is often made by a small team relatively shielded from the rest of the company.

Good practices for software can only be met if coding is seen as a core activity and if all are involved. An economic decision must be made based on the required level of safety for the choice of adequate tools and methods.

The process and the result of the coding activity must be controlled with the same degree of care as for the hardware. It is simply plain foolishness to rely upon an individual to deliver fault free software.

Reply to
Lanarcam

The answer is you can't leave software creation to humans. Huge bureaucracies have evolved ostensibly for the purpose of actualizing every conceivable best practice in software development, but when it gets down to the code, the product is still garbage, all of the development milestones have been falsified, the documentation is half-assed garbage, the personnel situation as usual is a sewer, the costs are astronomical, delays abound by the year, and the performance is dismal. Software engineering is in desperate need of a technological solution and NOT any goddammed management organization bullsh_t.

Reply to
Fred Bloggs

I don't think Ganssle is realistic. What is the alternative to C?

Nothing wrong with assembly, except that it is not very portable. Sometimes that doesn't matter.

Embedded java hasn't really come into its own, yet, although I wouldn't rule it out. Ganssle seems to suggest Ada and spark. I don't know any Ada programmers, and prior to reading the article, I had never heard of spark.

Furthermore, the article goes on about these C gotcha's. Well, I knew about these gothcha's, and I'm not even a real C programmer. Is it too much to ask that C coders read and understand the relevant ANSI/ISO standard? I don't think it is.

Maybe Ada is much better. I've never tried it. But I also don't think there are as many Ada development environments around as there are C environments, and that is a real issue.

Just my $0.02

--Mac

Reply to
Mac

Thanks; a truly superior rant. And mostly true.

John

Reply to
John Larkin

But sometimes the tool won't stand up to the task ;-)

...Jim Thompson

--
|  James E.Thompson, P.E.                           |    mens     |
|  Analog Innovations, Inc.                         |     et      |
 Click to see the full signature
Reply to
Jim Thompson

Troll.

Not a good one either.

--
Grant Edwards                   grante             Yow!  I HIJACKED a 747 to
                                  at               get here!! I hope those
 Click to see the full signature
Reply to
Grant Edwards

Yeah, I program my embedded stuff in 68K assembly. Some people sort of laugh at me and tell me how much faster they (or I) could do it in C or C++. Only thing is, I finish projects in about a fifth of the time it takes them, do very little debugging, and ship stuff that's thoroughly documented and bug-free. I think the difference is that I want to get it done (not just the coding, but the whole thing) as soon as possible, in as simple and reliable a way as possible, and they want to play with tools and toys and abstraction.

The language isn't as important as the psychology and the discipline. The way most C is taught and practised is the crime, and the ghastly bloated messes we live with (or in the extreme, die with) is the result.

I like PowerBasic for little engineering doodles that run on a PC, or to build things like thermocouple lookup tables (output as assembly source) but I'd never use an Intel part in an embedded system, or ever program an x86 in assembly.

John

Reply to
John Larkin

Pascal worked nicely for embedded systems development. I've never used Modula 2/3 for embedded work, but I think it would be a good candidate also.

Ada is really pretty decent also.

25-30 years ago the same could have been said of C. Everybody used Pascal for microprocessor work, and C was rare.
--
Grant Edwards                   grante             Yow!  I want another
                                  at               RE-WRITE on my CEASAR
 Click to see the full signature
Reply to
Grant Edwards

Pascal, Modula, Ada all come to mind. Ada is probably the most practical today.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 Click to see the full signature
Reply to
CBFalconer

Hi John,

I must ask why you prefer 68K assembly over x86? I am not arguing with you, IMHO the 68K was one of the better CISC architectures out there.

-Isaac

Reply to
Isaac Bosompem

In article , John Larkin wrote: [...]

I think the real problem is that they learn the C syntax and how to "code" but not how to "program". I've seen ones that couldn't figure out how to sort a disk file that wouldn't fit into RAM.

--
--
kensmith@rahul.net   forging knowledge
Reply to
Ken Smith

Some might say scientology with a does of XML.

I would. When you strip out the libraries of Java, you're left with something that looks like brain-dead C++ with pseudo-deterministic determinism.

There is strong disagreement as to what constitutes a programming language between C/C++ programmers and Java programmers. C/C++ programmers regard their language proper as those elements that can be compiled and executed on a not-yet-seen CPU, with nothing more than RAM in the architecture. Java programmers regard their language proper as this, plus the interpreter (JVM), plus the libraries, plus and architecture that rocks their myopic world (display, graphics, sound, database, etc.) I think Dennis Ritchie had the right idea when he originally developed C. When universality is sought, it is a lot easier to start from a basis of minimalism and add as necessary than to start from a basis of maximalism and try to explain to your boss why your 16-bit micro project needs 64MB RAM and a VGA display.

Sure isn't. But his rant has less to do with programming language than a social war that has been going on for hundreds, if not thousands of years. Experienced programmers who have an affinity for languages that do not require them to know where their ass is are often right-brained people trying to establish themselves in a left-brained world and complaining about it. I cannot count the number of times that I have recommended that a project be done using C or C++, but was ignored because there were too many of these types of people in the group, only to find them returning later asking how to fix a problem that never would have arisen had they used C/C++. Typical scenario:

Them: "Hey Chaud, the wooden fire helmets keep catching fire when our customers go to put out fires.....we were wondering if you could take some of that metal stuff you were talking about 7 months ago and plate our Version 3.0 helmets with it."

Me: "You're STILL using wooden helmets!!!!??????"

Them: "Yes, they work great except for this little problem."

Me: "Why don't you just make the whole helmet out of metal?"

Them: "We considered that, but the installed based of wooden helmets is too great. We've already sold 8,000. We have to protect our market position."

Me: "But the lawsuits alone will be more expensive if you don't get rid of that wood."

Them: "You're assuming, Chaud. No one knows that for sure. Let's just stay focused on the objective at hand, shall we?"

Boss: "Look, Le Chaud, hindsight is 20/20. Yes, there are some issues, but no one could have foreseen that wooden helmets would have been a problem. Just do your metal thing so we can get on with it."

Maybe. But I think C++ hits the sweet spot in ways that cannot be expressed. And that's with relatively poor libraries - (the C++ standard does not even have a class that supports the notion of a hierarchy). Think what will happen when these libraries are improved and refined to some level of persistence. Java and friends will begin to hemorrhage massively.

-Le Chaud Lapin-

Reply to
Le Chaud Lapin
[...]

I've heard Ada discribed as worse. One reported problem with it is that it is such a complex and feature ridden language that no-one really can test that the compiler for it works correctly.

--
--
kensmith@rahul.net   forging knowledge
Reply to
Ken Smith

Technically, it's for the large number of 32-bit registers, the symmetry of the instruction set, the high-endian thing, memory-mapped i/o, and the fact that I learned to program on the PDP-11. Business-wise, it's that the Moto/Freescale parts stay around forever, whereas Intel is known to announce, promote, and cancel embedded processors before they even hit production.

Could any post-1970 CPU architecture be much worse than the 8048/8051 horrors?

The 68332 has 8/16/32-bit arithmetic ops and nice 64:32 multiplies and divides, which take a lot of the tedium out of assembly programming; you seldom have to do fractured math. I write entire embedded apps without ever mentioning the carry bit.

John

Reply to
John Larkin

Things like the engine-control computers for jet engines are programmed in Ada. I believe there are several certified (possibly proven) correct Ada compilers around.

John

Reply to
John Larkin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.