Mail Archives: geda-user/2015/07/08/13:56:47
On 07/08/2015 09:15 AM, Bob Paddock (graceindustries AT gmail DOT com) [via
geda-user AT delorie DOT com] wrote:
>> When one raises the conceptual level of programming, one (usually)
>> sacrifices flexibility and control, and invariably people explain it
>> away with a hand-wave by saying "oh we really didn't want all of that
>> flexibility and control anyway, because it made us make mistakes!"
>> Everybody makes mistakes, creates buffer overruns and bad pointer
>> dereferences etc...but competent developers make fewer mistakes and
>> introduce fewer bugs. Lowering the barriers of entry creates more
>> programmers...not better ones.
>
> In the embedded spaces that I've worked in and still do, if I make a
> mistake in my code people die (Resume anyone? Really would like less
> stress in my life since my wife's suicide due to spending to much time
> at work. :-( http://www.kpaddock.org then
> http://www.kpaddock.com/book ).
>
> Hence I'm always looking for better tools/languages that can help
> prevent mistakes.
> At the moment I like the looks of Pony because of its mathematical
> bases and design for correctness philosophy.
> Don't know if is even works in the embedded space yet but will spend
> sometime to find out.
>
> That C lets us do damage so easily is not a great reason to support
> the language no mater how fast it might run, that it is a standard or
> that many people know it.
> I'd rather have a program that runs slower and runs correctly *every
> time*, that a fast one that crashes even once.
I certainly understand that point of view, it's a very good one.
There are other schools of thought here, though.
I feel there are far too many incompetent people writing code these
days. All of these languages for which saving programmers from their
own mistakes is their primary selling point are treating the symptom,
not the problem. Sure, everyone makes mistakes, and in some industries
(like yours) a firmware bug can have much bigger consequences than in
most other industries. But even in those types of situations,
exhaustive testing, and hiring programmers who know what they're doing
in the first place, addresses the problem...and you have faster, more
efficient code in the end. Paying a runtime penalty a zillion times
over for a code-writing-time shortcoming that happened once seems like a
really bad trade to me.
But then I'm overly anal-retentive about code efficiency, and any bugs
in the firmware I'm writing today (for example) might result in a very
slightly miscalculated bill...not deaths. (well, for the suits in
management, that's worse than deaths!)
C definitely allows people to shoot themselves in the foot, nobody
would argue about that. Just don't aim the gun at your foot. ;) I
wrote buffer overflow bugs when I was a new C programmer ~30 years ago.
I don't anymore.
The more dangerous (meaning physically dangerous) a potential firmware
bug is, the more testing should be done, and the more test coverage
verification should be done. For everything else...to err is human, to
have good test coverage and a watchdog timer, divine!
> Someone one recently said that "C is to C++ as Lung is to Lung Cancer"...
;)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
- Raw text -