validity of ... reasons for preferring C over C++

Niklas Holsti wrote:
> On 14-10-18 21:45 , Paul Rubin wrote:

>> Do you know what Ada-to-C translation tools they used?
>
> I believe they used the AdaMagic compiler from SofCheck
> (www.sofcheck.com). However, SofCheck has merged with AdaCore, and it
> seems the Ada-to-C translator is no longer available -- darn. Perhaps
> is AdaCore gets many requests...

It is still available, even if they don't advertise it.

>> What do the tools do about the Ada runtime?

AdaMagic has a (supposedly) full Ada runtime written in C.  How much of
it is included depends on how much is used and how good the C compiler
for the target is at eliminating unused code.

> If the VTC cubesat was done in SPARK, they probably did not use
> tasking.

I've never seen the VTC team mention RavenSPARK (i.e. SPARK with
tasking), so that is probably true.  And as they have proved the absence
of exceptions, there isn't much runtime use left (if any).

Greetings,

Jacob
-- 
The backhoe is the natural predator of the fiber optic cable.

On 18/10/14 23:15, Tom Gardner wrote:
> On 18/10/14 19:14, David Brown wrote:
>> On 17/10/14 23:11, Paul Rubin wrote:
>>> This is called "typeful programming" (search on the phrase) and the idea
>>> is it helps the compiler catch errors in the code.
>>
>> Yes, and it can sometimes be helpful in that way - but it can also
>> mean that you need extra code to deal with the conversions, and that
>> means extra scope for errors.  It works both ways.
>
> In my experience (not with Ada) is that requiring extra
> information (that aids mechanical checking) is a net benefit.
>
> The major disadvantage of "extra verbiage" is that the advantages
> are lost in cases in which it is automatically inserted or
> the programmer does "whatever is necessary to shut the compiler up".
> Nothing can help in that latter case.

That's the main problem - and that's why I say such extra types work 
both ways.

I would like C and C++ to have a way to specify a ranged subtype, and do 
compile-type checking on them when possible.  But overuse of them - as 
is encouraged (but by no means required) by Ada and Ada tutorials - 
leads to extra code to "shut the compiler up".  I have had the same 
problem in Pascal when trying to "do the right thing" regarding types, 
using explicitly ranged types when possible.  The result of the extra 
code for all the necessary conversions is not just that it makes the 
code more verbose, with extra places to make mistakes.  If you later 
change something in the types or other parts of the code, the explicit 
conversions hinder the compiler in spotting possible errors, because you 
have told it firmly that you know what you are doing.


>
> The extra information enables the toolset to be much more helpful
> when exploring/understanding the code, when refactoring the code,
> and when writing the code. "Autocomplete" operations largely remove
> the disadvantage of "extra verbiage".

On 19/10/14 09:43, Niklas Holsti wrote:
> On 14-10-18 00:03 , David Brown wrote:
>> On 17/10/14 19:15, Niklas Holsti wrote:
>>> On 14-10-17 13:44 , David Brown wrote:
>>>> On 17/10/14 11:35, Paul Rubin wrote:
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>> I disagree, in the embedded world.  In PC programming, I agree - very
>>>>>> often you are better with a language like Python than with C or C++.
>>>>>
>>>>> I have to think that even in MCU programming there have to be better
>>>>> alternatives to C or C++.  Ada seems like a possibility except that the
>>>>> toolchains are either obscure or very expensive.  There have been
>>>>> some C
>>>>> dialects like Cyclone that were clever but never got traction.  And I
>>>>> guess there are some specialty EDSL's like Atom that aren't so good for
>>>>> general purpose development.  Forth is interesting but it's from a
>>>>> different world, and still unsafe though with fewer traps than C.
>>>>>
>>>>
>>>> In theory, one could do much better than C or C++ - but not in practice.
>>>>    For some systems, Ada is a possible choice.  But while Ada is "safer"
>>>> than C in some ways, it has its own problems
>>>
>>> Care to list a few of those? Just to have a good debate? Been a while...
>>
>> My experience with Ada is rather limited, so you might end up teaching
>> me rather than getting a good debate.  But of course others will no
>> doubt join in.
>
> Let the flames roar!   :-)
>

I'm snipping the rest of your post, because I am going to need to read 
up about Ada again before I can reply properly - the little Ada I 
learned was too long ago for me to give you a proper argument.  But so 
far I can see that it looks like Ada is not as verbose as I believed, 
and is certainly worth considering more closely.

On 14-10-18 00:03 , David Brown wrote:
> On 17/10/14 19:15, Niklas Holsti wrote:
>> On 14-10-17 13:44 , David Brown wrote:
>>> On 17/10/14 11:35, Paul Rubin wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>> I disagree, in the embedded world.  In PC programming, I agree - very
>>>>> often you are better with a language like Python than with C or C++.
>>>>
>>>> I have to think that even in MCU programming there have to be better
>>>> alternatives to C or C++.  Ada seems like a possibility except that the
>>>> toolchains are either obscure or very expensive.  There have been
>>>> some C
>>>> dialects like Cyclone that were clever but never got traction.  And I
>>>> guess there are some specialty EDSL's like Atom that aren't so good for
>>>> general purpose development.  Forth is interesting but it's from a
>>>> different world, and still unsafe though with fewer traps than C.
>>>>
>>>
>>> In theory, one could do much better than C or C++ - but not in practice.
>>>   For some systems, Ada is a possible choice.  But while Ada is "safer"
>>> than C in some ways, it has its own problems
>>
>> Care to list a few of those? Just to have a good debate? Been a while...
> 
> My experience with Ada is rather limited, so you might end up teaching
> me rather than getting a good debate.  But of course others will no
> doubt join in.
> 
> An obvious (but highly subjective) irritation with Ada is the verbosity
> of the language - lots of things need repeated,

Oh yes, I now remember one common place where Ada needs repetition: Ada
does not have the combinations of assignment and operation, such as +=,
that C provides. So where one can increment a C variable by x += 1, or
x++, or ++x, in Ada one must write x := x + 1, or define one's own
increment procedure and write inc(x). Same for decrement and other
arithmetic operations.

Moreover, Ada does not have the "<<" and ">>" operators for left and
right shifts; they are functions in the library package Interfaces,
called Shift_Left and other verbose names.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

On 18/10/14 10:36, Tom Gardner wrote:
> On 18/10/14 00:14, Clifford Heath wrote:
>> On 17/10/14 19:29, Tom Gardner wrote:
>>> On 17/10/14 08:27, David Brown wrote:
>>>> If you don't know what your C++ code is doing, that's /your/ problem,
>>>> not the language's problem.
>>> Well yes. But some languages do have more obscured traps that
>>> that require higher levels of skill and more continual alertness.
>> Sharp tools cut. What's your point?
> Read the rest of my posting, i.e. the bit you snipped.

I did. Here, I'll even respond to some of it:

> K&R C had 228 pages. C Traps and Pitfalls had 228 pages. They
were all you needed in the 80. How long are the modern equivalents?

K&R C massively under-specified the language, even with the extension of 
Traps and Pitfalls. The modern specifications fill out the missing bits, 
and specify the changes that were needed to the language to handle the 
extensive problems that were exposed.

I never said that C or C++ were "nice" or "friendly" languages - in fact 
I agree with Niklas' response entirely. C is important because it's 
"sharp", and some of C++'s features are arguably unnecessary because 
they don't refine that core concept.

You have to learn how to use it. Much of C++ is entirely suitable for 
writing effective programs that do their job succinctly, precisely and 
with a minimum of bloat. The libraries are definitely not designed for 
the embedded environment, so if you skip them (or use them only with 
careful circumspection) you'll do better, but the libraries are not the 
language.

On Fri, 17 Oct 2014 23:03:24 +0200, David Brown wrote:

> An obvious (but highly subjective) irritation with Ada is the verbosity 
> of the language

One argument in favour of verbosity is that it increases the "distance"
between distinct, valid programs, thus reducing the probability that a
typo will go unnoticed.

A good example of this is to consider two fragments of C code:

A:
	if (condition)
	{
		...
	}

B:
	if (condition);
	{
		...
	}

The syntactic difference is a semicolon; the semantic difference is vast.

In C, a statement is a statement: anywhere a statement can appear,
*any* statement can appear.

A similar issue arises for expressions. In particular, assignment (=) and
equality comparison (==) are both expressions, and can appear almost
anywhere that any expression can appear. The fact that there's no distinct
boolean type doesn't help here (nor if you confuse & with && or | with ||).

David Brown <david.brown@hesbynett.no> writes:
> I'm snipping the rest of your post, because I am going to need to read
> up about Ada again before I can reply properly - the little Ada I
> learned was too long ago for me to give you a proper argument.  But so
> far I can see that it looks like Ada is not as verbose as I believed,
> and is certainly worth considering more closely.

Here's an old article comparing development costs between C vs Ada:

  http://archive.adaic.com/intro/ada-vs-c/cada_art.html
  
And here's a guide to Ada for C and C++ programmers:

   http://adahome.com/Ammo/cpp2ada.html

Both are somewhat out of date (they are way before Ada 2012) and
both are from a pro-Ada perspective, but I found them interesting.

On 14-10-20 05:47 , Paul Rubin wrote:

> Here's an old article comparing development costs between C vs Ada:
> 
>   http://archive.adaic.com/intro/ada-vs-c/cada_art.html
   ...
> Both are somewhat out of date (they are way before Ada 2012) and
> both are from a pro-Ada perspective, but I found them interesting.

I'm curious to know why you feel that the Zeigler article is from a
"pro-Ada perspective". To me it seems that the article tries hard to
understand what reasons, other than the language, could explain the
differences it reports, such as different competence of programmers,
different complexity of modules, etc.

The study was indeed done within a company that developed and sold Ada
compilers, but it also sold C and C++ compilers, I believe, so I
wouldn't automatically assume a bias.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> I'm curious to know why you feel that the Zeigler article is from a
> "pro-Ada perspective". 

Well, ok, I got both links from a pro-Ada site (adahome.com).  It's been
a while since I read the Ziegler article but its conclusion was
favorable to Ada.

On Monday, October 20, 2014 12:02:43 AM UTC-4, Paul Rubin wrote:
 
> 
> Well, ok, I got both links from a pro-Ada site (adahome.com).  It's been
> 

"AdaHome is (sadly) a zombie site. Its accessible by not updated in well over a decade. It is sometimes useful as an archive of old stuff. A better place to start today is http://www.adaic.org.