X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Virus-Scanned: amavisd-new at neurotica.com
X-NSA-prism-xkeyscore: I do not consent to surveillance, prick
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neurotica.com;
	s=default; t=1436378165;
	bh=VwnIOdvoQYxsP4Kp5c1KJSAY7ppNAbdwegTwAoykpIs=;
	h=Date:From:To:Subject:References:In-Reply-To;
	b=FKOiZQ1uGiqjlvJUbph+Iy9fYXcrUBkLkw8U14qmJabg6slNtxSjBDOtpuCAheDqp
	 on8IyHwoxGPC06FZodcJJCw56cqN0e7yuJWwJad+xAkwCBP4hZRKaw+Qs7IvP0irge
	 LQ8W7CQotlmThy57kdP2Kq9MQ9Cipu/dCKepfVP8=
Message-ID: <559D6434.9030409@neurotica.com>
Date: Wed, 08 Jul 2015 13:56:04 -0400
From: "Dave McGuire (mcguire AT neurotica DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] gEDA/gschem still alive?
References: <20150703030409 DOT 32398 DOT qmail AT stuge DOT se>	<CAFC5WMoa2-z6bNca_bQN+jmMR260UBmoJQybUzH=L2TrBpzNNA AT mail DOT gmail DOT com>	<1436006726 DOT 677 DOT 13 DOT camel AT ssalewski DOT de>	<20150706200609 DOT GD24178 AT localhost DOT localdomain>	<CAC4O8c9f0pLsLu_dyuO5ggh7RmHY1vAA=UUhk9AE0JYZb4mhBQ AT mail DOT gmail DOT com>	<CAM2RGhQfPO31-1Uyc3kC7w286r0VD7c41UZEZcyYquzknCxbsQ AT mail DOT gmail DOT com>	<20150707060409 DOT GB14357 AT localhost DOT localdomain>	<CAOP4iL2C_LU=RQy5FWYF-7RrHW6tqhqqyFJGjkwLQ2AD7FiYJA AT mail DOT gmail DOT com>	<1436287952 DOT 678 DOT 26 DOT camel AT ssalewski DOT de>	<559C0F7E DOT 7010009 AT neurotica DOT com>	<20150707183339 DOT GA1817 AT alpha2>	<559C3667 DOT 7030402 AT neurotica DOT com> <CAOuGh88fS2pRy4TqYfHHk9wmUORc8Ko7E_AufA42jjHi+tYoMQ AT mail DOT gmail DOT com>
In-Reply-To: <CAOuGh88fS2pRy4TqYfHHk9wmUORc8Ko7E_AufA42jjHi+tYoMQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id t68HuURS017664
Reply-To: geda-user AT delorie DOT com

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