C / C++ skills

The layers of functionality on top of the core platform are often patented. For example, Windows Forms and ASP.NET are Microsoft proprietary class libraries. They can be used freely, but companies would have to get permission to re-implement them. That's why Mono has been in hot water occasionally - they went beyond the Common Language Infrastructure and the C# language and they have clearly stepped on proprietary areas that aren't open.

As long as someone sticks to the open pieces they can't possibly get into any trouble. The open parts are quite huge in and of themselves, and that's all anyone would even want in an Embedded MCU target environment.

Eric

But C# exists solely in one single environment - Windows. It is also used primarily in large enterprise solutions. Most embedded developers don't have lots of experience in that area, and therefore have little experience with the latest fashions. Unix developers also will have little experience with it also. Even developers of Windows based drivers and system utilities won't have C# on their radar. The people pushing C# run in completely different social circles, they read completely different trade magazines, they use different terminology, etc. C# is a niche market - though it's a large and well funded niche.

-- Darin Johnson

Reliable software can be written and has been written in various assembly languages.

So if C is better than assembly language, reliable software can be written also in C.

A large number of programs during the last decades have been written in C/C++, thus, the absolute number of bad programs should also be quite large.

Bad programs can be written in any language.

Paul

The analogy is incorrect. Experts have their own helmets that provide the right safety level for the job at hand (eg. special helmet for critical stuff). Of course there are people who don't wear helmets, not because they don't want to, but because they didn't know they had to supply their own. Safe languages simply provide standard helmets, but if they don't fit then you're stuck.

The equivalent analogy for safe languages is a car filled with lots of safety features. The car becomes heavier and slower and less efficient as a result. It's well known that drivers offset some (most?) of the extra safety by driving more dangerously...

Wilco

Ouch.

I think that's a little unfair. (I was a biker for a long time - and I wore a full-face helmet and leathers. While I might be a safe driver, the main danger came from other road users. I was in favour of helmets, and wore one even when US state laws said it was optional.)

But, as Wilco says, the analogy fails for software design. Yes, my code tends to be more robust than most. This isn't because of or even despite C; and it's not because I'm some kind of genius. It's because I've worked in environments where failure was not an option, and where I/we studied failure modes. I've re-invented my approach to coding/design many times. I've studied the subject; I've read the books, the treatises, the EWD docs, made it a speciality. The approach I'm espousing is not particularly C-specific; it's more an emphasis on good design than dependence on a particular language. This is not new. Wiser men than I have said the same thing over and over; yet much (probably most) extant code is written by hack-and-debug artists who have read the odd book and figure they know what they're doing. And then wonder why it all goes wrong, and blame the tools.

I'm interested in an approach where one can stare at the code, understand it, and *know* that it has to work, without bugs. This mainly means keeping things simple and readable, having a good hierarchical approach, and not setting traps for oneself. It also means discipline. No language can enforce correct analysis and good design.

Going back to your analogy: I never drove my motorcycle without wearing a helmet. I'd studied the figures, knew the odds, knew the dangers. It was nothing to do with culture; it had everything to do with having an informed view.

Steve

I understand your point, and yes, there's truth in there. But - one can write obscure/wrong/poor code in any language.

I use a net - but it's not the language. It's a set of Best Practices I've developed (and/or nicked) over the years, which tend to allow me to sleep nights knowing that my products are not going to result in me/my company being sued.

Steve

I'm much less concerned with whether a language (including C, assembler, Pascal, Forth, whatever) is a HLL, and way more concerned with readability - and how well it lets me express the design. And, being practical, how well it fits the hardware (resources needed etc).

I've dealt with both unreadable Pascal and crystal-clear C. Guess which I prefer ;).

Steve

Testing is an essential part of software development independent of the language. It's true that C provides a lot of pitfalls for a beginner, but the pitfalls of so called safe languages are not that different.

Stricter typing is definitely useful if it increases the amount of static checking. However there is always a need to be able to bypass those checks, and (ISO) Pascal provided too few features to be as efficient as C. I'm all for increased safety and robustness if it doesn't come at such a high cost. It is possible to do a lot with no or little runtime cost, however languages are typically not designed by compiler experts...

That's rubbish. Most of the problems are caused by bad software engineering practices, bad design, lazy or incompetent programmers, bad management, tight deadlines etc. The language is irrelevant, you can write really good or really bad software in any language. Although C doesn't have bounds-checking and such built into the language, many tools exist to provide such features (lint, Valgrind, etc). If you don't use the right tools and are not experienced enough to write robust code then you deserve what you get.

The reality is that array bounds checks, garbage collection etc don't actually provide safety. They are nice for finding trivial bugs during development, but they replace one kind of bug with another kind. Take array bounds checking: ignoring the overhead, if a check does trigger, did you write all of the necessary cleanup code to deal correctly with the exception? Did you test every single access that could raise an exception? Very unlikely. So the program is still going to crash just like the Ariadne...

Wilco

Agreed. But, as your namesake said: "Program testing can be used to show the presence of bugs, but never to show their absence".

The only way to be sure of the absence of bugs is to design software to have no bugs. Period.

Very well said. That's precisely my viewpoint too.

Steve

Absolutely. However people do make mistakes when implementing the design, no matter how good it is. Many bugs are simple typos, even in bad designs. Programmers typically don't notice their own simple mistakes. Testing and code inspections are the only ways to find these mistakes. If you've ever had a collegue looking over your shoulder for a minute and pointing out a bug in code you've stared at for an hour you know what I mean.

Much of this is independent of language, the main difference is that expressive languages like C/C++ have more opportunities for errors. Forgetting to parenthesise appropriately is a common issue due to the odd operator precedence of C, tripping up new programmers. Although well designed language can reduce such problems, a coding standard works just as well.

Wilco

Completely agree. I'm a big fan of non-confrontational code reviews. They can be fun, and challenging. It's an opportunity to display the elegance of what you're doing to the one group of people who will actually appreciate it. It's also an opportunity to realise "blimey, they're right. I've been missing something. Rewind/erase. Hey, these guys are *good*". Either way, there's a glow to be had.

Hmmm. I have no trouble reading/maintaining well-written C. OTOH, most of the C++ I've had to deal with has been disastrous.

Agreed. Defensive programming mantra: always parenthesize as you intend, whether you think you need to or not. It also makes it easier to read.

So long as it's a good one. I've come across many bad ones, where it's clear the writer/s has/ve missed the point. I mean, a rule like "Thou shalt always test a Boolean for equality with TRUE or FALSE", resulting in: if ( some_flag == TRUE ) if ( condition == FALSE )

which is just plain wrong. And belies a complete misapprehension so deep it's not even worth arguing with.

But yeah, a well-worded coding standard, and a culture that cares about it (that's the other problem - when no-one gives a flying one about the coding standards) can do wonders. The kind of culture where one argues the finer points of factoring and the good parts of extreme programming around the water cooler. Where one's high standards get challenged to improve even further. Those are the kinds of cultures where one learns to do good stuff.

Which is why I do it. I'm also a musician, but I need a level of passion to motivate me. I still get excited about elegant, clear, clean software.

And very depressed about most of what's out there.

Steve

False. We've trial-ported slabs of our Windows C# code to run on Mono and other companies have *large* systems deployed on it. You don't get all the COM components and the libraries of Windows of course, but the latter are catching up.