Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #30465 > unrolled thread

C++, Ada, ...

Back to article view | Back to comp.arch.embedded

Contents

  C++, Ada, ... pozz <pozzugno@gmail.com> - 2021-04-17 17:48 +0200
    Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-17 18:45 +0200
      Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-17 19:55 +0100
        Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-18 12:53 +0200
          Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-18 18:48 +0300
            Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-18 18:59 +0200
              Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-19 13:51 +0300
                Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-19 14:22 +0200
                  Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-19 19:16 +0300
                    Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-19 22:19 +0200
                      Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-20 01:03 +0300
                        Re: C++, Ada, ... Richard Damon <Richard@Damon-Family.org> - 2021-04-19 18:09 -0400
                        Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-20 06:58 +0200
                          Re: C++, Ada, ... Paul Rubin <no.email@nospam.invalid> - 2021-04-19 23:18 -0700
                            Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-20 09:36 +0200
                Re: C++, Ada, ... Paul Rubin <no.email@nospam.invalid> - 2021-04-19 12:20 -0700
                  Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-20 00:26 +0300
                    Re: C++, Ada, ... Paul Rubin <no.email@nospam.invalid> - 2021-04-19 16:01 -0700
                      Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-20 10:47 +0300
                  Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-19 23:30 +0100
      Re: C++, Ada, ... Clifford Heath <no.spam@please.net> - 2021-04-18 08:29 +1000
      Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-18 10:39 +0300
        Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-18 14:59 +0200
          Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-18 19:23 +0300
            Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-18 19:26 +0200
              Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-18 19:29 +0100
                Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-18 22:23 +0200
                  Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-18 23:09 +0100
                    Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-19 08:56 +0200
                  Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-19 14:04 +0300
                    Re: C++, Ada, ... Dimiter_Popoff <dp@tgi-sci.com> - 2021-04-19 15:16 +0300
                      Re: C++, Ada, ... Paul Rubin <no.email@nospam.invalid> - 2021-04-19 12:47 -0700
                        Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-20 00:37 +0300
                          Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-20 07:50 +0200
                    Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-19 14:26 +0200
              Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-18 19:30 +0100
                Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-18 22:17 +0200
                  Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-18 23:17 +0100
                    Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-19 08:52 +0200
                      Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-19 10:08 +0100
                        Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-19 12:15 +0200
                          Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-19 12:00 +0100
                      Re: C++, Ada, ... Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-04-19 16:15 +0300
                        Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-19 15:43 +0200
      Re: C++, Ada, ... pozz <pozzugno@gmail.com> - 2021-04-19 18:38 +0200
        Re: C++, Ada, ... Paul Rubin <no.email@nospam.invalid> - 2021-04-19 10:48 -0700
        Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-19 19:33 +0100
          Re: C++, Ada, ... Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-04-20 15:09 +0300
            Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-20 15:29 +0100
        Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-19 22:48 +0200
          Re: C++, Ada, ... pozz <pozzugno@gmail.com> - 2021-04-19 23:17 +0200
            Re: C++, Ada, ... Paul Rubin <no.email@nospam.invalid> - 2021-04-19 15:55 -0700
              Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-20 08:21 +0200
            Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-20 08:20 +0200
    Re: C++, Ada, ... Dave Nadler <drn@nadler.com> - 2021-04-17 21:07 -0400
      Re: C++, Ada, ... Don Y <blockedofcourse@foo.invalid> - 2021-04-17 18:53 -0700
      Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-18 09:42 +0100
    Re: C++, Ada, ... dalai lamah <antonio12358@hotmail.com> - 2021-04-18 14:39 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#30479

On 18/4/21 2:45 am, David Brown wrote:
> On 17/04/2021 17:48, pozz wrote:
>> What do you think about different languages than usual C for embedded
>> systems?
>>
>> I mean C++, Ada but also Python. Always more powerful embedded
>> processors are coming, so I expect new and modern languages will enter
>> in the embedded world.
>>
>> Hardware are cheaper and more powerful than ever, but software stays
>> expensive. New and modern languages could reduce the software cost,
>> because they are simpler than C and much more similar to desktop/server
>> programming paradigm.
>>
>> We embedded sw developers were lucky: electronics and technologies
>> change rapidly, but sw for embedded has changed slower than
>> desktop/mobile sw. Think of mobile app developers: maybe they already
>> changed IDEs, tools and languages ten times in a few years.
>> C language for embedded is today very similar than 10 years ago.
>>
>> However I think this situation for embedded developers will change in
>> the very next years. And we will be forced to learn modern technologies,
>> such as new languages and tools.
>> Is it ok for me to study and learn new things... but it will be more
>> difficult to acquire new skills for real jobs.
>>
>> What do you think?
> 
> You should probably add Rust to your list - I think its popularity will
> increase.

+1.

I've used C++ for over 30 years, but Rust is going to rule. It's not 
really any harder, but vastly safer, especially for parallel coding.

CH

[toc] | [prev] | [next] | [standalone]

#30482

On 2021-04-17 19:45, David Brown wrote:
> On 17/04/2021 17:48, pozz wrote:
>> What do you think about different languages than usual C for embedded
>> systems?
>>
>> I mean C++, Ada but also Python. Always more powerful embedded
>> processors are coming, so I expect new and modern languages will enter
>> in the embedded world.
>>
>> ...
>> Is it ok for me to study and learn new things... but it will be more
>> difficult to acquire new skills for real jobs.
>>
>> What do you think?
> 
>   ...
> Ada involves a fair amount of change to how you work, compared to C
> development.  (Disclaimer - I have only done a very small amount of Ada
> coding, and no serious projects.  But I have considered it as an
> option.)  I really don't see it becoming much more common, and outside
> of niche areas (defence, aerospace) it is very rare.  Programming in Ada
> often takes a lot more effort even for simple things, leading quickly to
> code that is so wordy that it is unclear what is going on.


That depends, I guess, on what one considers "simple", and also, of 
course, on how familiar one is with the languages.

Perhaps it is time to link once again to the experience of C versus Ada 
in an introductory embedded-programming class using a model rail-road 
example, where the students using Ada fared much better than those using C:

http://archive.adaic.com/projects/atwork/trains.html

I am (as you guessed) an Ada fan, and find it a pleasure to write, even 
if it takes more keystrokes than the equivalent in C.

For embedded systems in particular, I find portability to be a great 
advantage of Ada. With few exceptions, the embedded program can be 
exercised on the development host, and if the target supports the 
standard Ada tasking system (or a subset of it), this applies even to 
multi-threaded programs (without the need to emulate some embedded 
RTK/OS on the host).


> And most of the advantages of Ada (such as better typing) can be
> achieved in C++ with less effort,

According to the link above, the main Ada advantage was the ability to 
define one's own problem-oriented scalar types, such as integers with 
specific value ranges. AIUI, this is not easily done in C++.


> and at the same time C++ can give additional safety on
> resources that is harder to get on Ada.  (But Ada has some nice features
> introspective that C++ programmers currently only dream about.)


Can you be more specific on those points, please?


> It used to be the case that C++ compilers were expensive and poor
> quality, that the resulting code was very slow on common
> microcontrollers, and that the language didn't have much extra to offer
> small-systems embedded developers.  That, I think, has changed in all
> aspects.  I use gcc 10 with C++17 on Cortex-M devices, and features like
> templates, strong enumerations, std::array, and controlled automatic
> conversions make it easier to write good code.


AdaCore provides the gcc-based GNAT Ada compiler for several embedded 
targets, free to use for open-source projects: libre.adacore.com.

Commercial projects can use Ada on other targets by means of the 
(different) AdaCore compiler that generates C code as an intermediate 
representation.

[toc] | [prev] | [next] | [standalone]

#30487

On 18/04/2021 09:39, Niklas Holsti wrote:
> On 2021-04-17 19:45, David Brown wrote:
>> On 17/04/2021 17:48, pozz wrote:
>>> What do you think about different languages than usual C for embedded
>>> systems?
>>>
>>> I mean C++, Ada but also Python. Always more powerful embedded
>>> processors are coming, so I expect new and modern languages will enter
>>> in the embedded world.
>>>
>>> ...
>>> Is it ok for me to study and learn new things... but it will be more
>>> difficult to acquire new skills for real jobs.
>>>
>>> What do you think?
>>
>>   ...
>> Ada involves a fair amount of change to how you work, compared to C
>> development.  (Disclaimer - I have only done a very small amount of Ada
>> coding, and no serious projects.  But I have considered it as an
>> option.)  I really don't see it becoming much more common, and outside
>> of niche areas (defence, aerospace) it is very rare.  Programming in Ada
>> often takes a lot more effort even for simple things, leading quickly to
>> code that is so wordy that it is unclear what is going on.
> 
> 
> That depends, I guess, on what one considers "simple", and also, of
> course, on how familiar one is with the languages.
> 
> Perhaps it is time to link once again to the experience of C versus Ada
> in an introductory embedded-programming class using a model rail-road
> example, where the students using Ada fared much better than those using C:
> 
> http://archive.adaic.com/projects/atwork/trains.html

Are there no newer examples?  While this study was interesting, it is
some 30 years out of date and compares and old version of Ada with an
old version of C (perhaps not even C90).  I'd rather see the pros and
cons of Ada 2012 compared to C++17.

> 
> I am (as you guessed) an Ada fan, and find it a pleasure to write, even
> if it takes more keystrokes than the equivalent in C.

I had no need to guess - it's not the first time you have posted about
Ada here!  I'm glad that someone with your Ada qualifications can chime
in here, and can correct my if I'm wrong.

> 
> For embedded systems in particular, I find portability to be a great
> advantage of Ada. With few exceptions, the embedded program can be
> exercised on the development host, and if the target supports the
> standard Ada tasking system (or a subset of it), this applies even to
> multi-threaded programs (without the need to emulate some embedded
> RTK/OS on the host).
> 

For suitable targets, I can see that being useful.  C and C++ can be
used on a wider range of targets, and with a wider range of RTOS (if
any).  Of course, code for widely differing target systems is often very
different anyway, so portability is not always a concern.

> 
>> And most of the advantages of Ada (such as better typing) can be
>> achieved in C++ with less effort,
> 
> According to the link above, the main Ada advantage was the ability to
> define one's own problem-oriented scalar types, such as integers with
> specific value ranges. AIUI, this is not easily done in C++.
> 

Sure it can be done in C++.

<https://foonathan.net/2016/10/strong-typedefs/>

You can make types with specific ranges (with compile-time checks where
possible, optional run-time checks otherwise).  You can choose which
operations you allow on them, and how they combine (so that multiplying
a speed and a time give you a distance automatically, but adding them is
not allowed).  You can make integer types with different overflow
behaviour (wrapping, saturating, throwing errors, unspecified behaviour,
undefined behaviour) that can be used as easily as normal integers, and
mixed if and only if it is safe to do so or you make it explicit.  You
can make array types that are indexed by enumerated types.  It's all
possible - more so that in Ada, AFAIK.

Where you have a difference, however, is that many of the most
beneficial cases (such as strong subrange types) are simple to use in
Ada and built into the language, and therefore they are often used.  In
C++, you need to find a suitable template library or make things
yourself, giving a much higher barrier to use.

A very interesting distinction when looking at language features and
safe coding is how much people /could/ use safety features, and how much
they /do/ use them.  For example, with C programming you can get strong
type safety as long as you wrap all your new types in structs.  The
compiler will complain for type mistakes, just as it would in Ada - but
the /use/ of such types is often very inconvenient in C.

> 
>> and at the same time C++ can give additional safety on
>> resources that is harder to get on Ada.  (But Ada has some nice features
>> introspective that C++ programmers currently only dream about.)
> 
> 
> Can you be more specific on those points, please?
> 

For the first point - my understanding is that in Ada, when you have
classes you need to manually call constructor and destructor
(initializer and finalizer) functions.  RAII is thus harder, and it is
as easy to make mistakes as it is in C (with malloc and free).  Does Ada
have the equivalent of std::unique_ptr, std::shared_ptr and other smart
pointers, or container classes that handle allocation?

For the second point, I am thinking of things like type attributes.  I
would /really/ like C++ enumerations to have something matching the
"first" and "last" attributes!  AFAIK, C++ won't get this until
reflection is added, probably not until C++26.

> 
>> It used to be the case that C++ compilers were expensive and poor
>> quality, that the resulting code was very slow on common
>> microcontrollers, and that the language didn't have much extra to offer
>> small-systems embedded developers.  That, I think, has changed in all
>> aspects.  I use gcc 10 with C++17 on Cortex-M devices, and features like
>> templates, strong enumerations, std::array, and controlled automatic
>> conversions make it easier to write good code.
> 
> 
> AdaCore provides the gcc-based GNAT Ada compiler for several embedded
> targets, free to use for open-source projects: libre.adacore.com.
> 
> Commercial projects can use Ada on other targets by means of the
> (different) AdaCore compiler that generates C code as an intermediate
> representation.
> 

This means that Ada suffers from a similar barrier to adoption that C++
used to do.  Big companies will happily pay the cost for the tools that
they think will lead to better development efficiency or reliability.
Smaller ones will have a much harder time trying to justify the expense,
especially as they will often have few developers who can use the tools.
A move from C to Ada is compounded by needing a complete change of the
code - with C to C++, you can re-use old code, and you can also use a
few of the C++ features rather than moving wholescale (though of course
you also miss out on corresponding benefits).

[toc] | [prev] | [next] | [standalone]

#30495

On 2021-04-18 15:59, David Brown wrote:
> On 18/04/2021 09:39, Niklas Holsti wrote:
>> On 2021-04-17 19:45, David Brown wrote:
>>> On 17/04/2021 17:48, pozz wrote:
>>>> What do you think about different languages than usual C for embedded
>>>> systems?
>>>>
>>>> I mean C++, Ada but also Python. Always more powerful embedded
>>>> processors are coming, so I expect new and modern languages will enter
>>>> in the embedded world.
>>>>
>>>> ...
>>>> Is it ok for me to study and learn new things... but it will be more
>>>> difficult to acquire new skills for real jobs.
>>>>
>>>> What do you think?
>>>
>>>    ...
>>> Ada involves a fair amount of change to how you work, compared to C
>>> development.  (Disclaimer - I have only done a very small amount of Ada
>>> coding, and no serious projects.  But I have considered it as an
>>> option.)  I really don't see it becoming much more common, and outside
>>> of niche areas (defence, aerospace) it is very rare.  Programming in Ada
>>> often takes a lot more effort even for simple things, leading quickly to
>>> code that is so wordy that it is unclear what is going on.
>>
>>
>> That depends, I guess, on what one considers "simple", and also, of
>> course, on how familiar one is with the languages.
>>
>> Perhaps it is time to link once again to the experience of C versus Ada
>> in an introductory embedded-programming class using a model rail-road
>> example, where the students using Ada fared much better than those using C:
>>
>> http://archive.adaic.com/projects/atwork/trains.html
> 
> Are there no newer examples?


I have none to hand, at least.


> While this study was interesting, it is some 30 years out of date

I would call it "30 years old". Whether it is "out of date" can be 
debated -- I don't think the basic ideas of the two languages have 
changed very drastically even in that time.


> and compares and old version of Ada with an old version of C (perhaps
> not even C90).  I'd rather see the pros and cons of Ada 2012 compared
> to C++17.

So would I, but I haven't seen any such studies reported.

I can only point to the biased material at 
https://www.adaic.org/advantages/.

And a recent Ada-adoption story from NVIDIA:

https://www.adacore.com/webinars/securing-future-of-embedded-software

but that is more about the AdaCore tools and the SPARK form of Ada than 
about C-vs-Ada.

>>
>> I am (as you guessed) an Ada fan, and find it a pleasure to write, even
>> if it takes more keystrokes than the equivalent in C.
> 
> I had no need to guess - it's not the first time you have posted about
> Ada here!  I'm glad that someone with your Ada qualifications can chime
> in here, and can correct my if I'm wrong.
> 
>>
>> For embedded systems in particular, I find portability to be a great
>> advantage of Ada. With few exceptions, the embedded program can be
>> exercised on the development host, and if the target supports the
>> standard Ada tasking system (or a subset of it), this applies even to
>> multi-threaded programs (without the need to emulate some embedded
>> RTK/OS on the host).
>>
> 
> For suitable targets, I can see that being useful.  C and C++ can be
> used on a wider range of targets, and with a wider range of RTOS (if
> any).


Ada can be used with other RTOSses too, although one loses both some 
ease-of-use advantages and the portability advantage. Typical Ada 
compilers for embedded systems also let one write Ada programs that do 
not need an RTOS at all and run with a single thread.


> Of course, code for widely differing target systems is often very
> different anyway, so portability is not always a concern.
> 
>>
>>> And most of the advantages of Ada (such as better typing) can be
>>> achieved in C++ with less effort,
>>
>> According to the link above, the main Ada advantage was the ability to
>> define one's own problem-oriented scalar types, such as integers with
>> specific value ranges. AIUI, this is not easily done in C++.
>>
> 
> Sure it can be done in C++.
> 
> <https://foonathan.net/2016/10/strong-typedefs/>

I did not see any mention of range-checked types there. But yes, they 
can be constructed in C++, but not as easily as in Ada, as it seems we 
agree. I should have said "/as/ easily" in the quote above.


> You can make types with specific ranges (with compile-time checks where
> possible, optional run-time checks otherwise).  You can choose which
> operations you allow on them, and how they combine (so that multiplying
> a speed and a time give you a distance automatically, but adding them is
> not allowed).  You can make integer types with different overflow
> behaviour (wrapping, saturating, throwing errors, unspecified behaviour,
> undefined behaviour) that can be used as easily as normal integers, and
> mixed if and only if it is safe to do so or you make it explicit.  You
> can make array types that are indexed by enumerated types.  It's all
> possible - more so that in Ada, AFAIK.


I admit that C++ templates allow the programming of more compile-time 
activities than Ada allows.


> Where you have a difference, however, is that many of the most
> beneficial cases (such as strong subrange types) are simple to use in
> Ada and built into the language, and therefore they are often used.  In
> C++, you need to find a suitable template library or make things
> yourself, giving a much higher barrier to use.


Yup.


> A very interesting distinction when looking at language features and
> safe coding is how much people /could/ use safety features, and how much
> they /do/ use them.  For example, with C programming you can get strong
> type safety as long as you wrap all your new types in structs.  The
> compiler will complain for type mistakes, just as it would in Ada - but
> the /use/ of such types is often very inconvenient in C.


Indeed.


>>> and at the same time C++ can give additional safety on
>>> resources that is harder to get on Ada.  (But Ada has some nice features
>>> introspective that C++ programmers currently only dream about.)
>>
>>
>> Can you be more specific on those points, please?
>>
> 
> For the first point - my understanding is that in Ada, when you have
> classes you need to manually call constructor and destructor
> (initializer and finalizer) functions.  RAII is thus harder, and it is
> as easy to make mistakes as it is in C (with malloc and free).  Does Ada
> have the equivalent of std::unique_ptr, std::shared_ptr and other smart
> pointers, or container classes that handle allocation?


Answered in another message. The Ada "controlled" types have 
automatically called initializer and finalizer operations. They can be 
used to implement smart pointers, but no smart pointers are built into 
Ada (perhaps mainly because they would then have to be thread-safe, 
which would be a lot of overhead for a single-threaded program).


> For the second point, I am thinking of things like type attributes.  I
> would /really/ like C++ enumerations to have something matching the
> "first" and "last" attributes!  AFAIK, C++ won't get this until
> reflection is added, probably not until C++26.


Yes, good point in favour of Ada. I've seen some C++ programs that go to 
great metaprogramming lengths to define "trait" templates to get the 
equivalent of the "first", "last", "size" etc. attributes. So it is, 
again, possible in C++, but not as easy as when it is built-in, as in Ada.


>>> It used to be the case that C++ compilers were expensive and poor
>>> quality, that the resulting code was very slow on common
>>> microcontrollers, and that the language didn't have much extra to offer
>>> small-systems embedded developers.  That, I think, has changed in all
>>> aspects.  I use gcc 10 with C++17 on Cortex-M devices, and features like
>>> templates, strong enumerations, std::array, and controlled automatic
>>> conversions make it easier to write good code.
>>
>>
>> AdaCore provides the gcc-based GNAT Ada compiler for several embedded
>> targets, free to use for open-source projects: libre.adacore.com.
>>
>> Commercial projects can use Ada on other targets by means of the
>> (different) AdaCore compiler that generates C code as an intermediate
>> representation.
>>
> 
> This means that Ada suffers from a similar barrier to adoption that C++
> used to do.  Big companies will happily pay the cost for the tools that
> they think will lead to better development efficiency or reliability.
> Smaller ones will have a much harder time trying to justify the expense,
> especially as they will often have few developers who can use the tools.
> A move from C to Ada is compounded by needing a complete change of the
> code - with C to C++, you can re-use old code, and you can also use a
> few of the C++ features rather than moving wholescale (though of course
> you also miss out on corresponding benefits).


Of course you can move from C to Ada without a full re-write, because 
all Ada compilers provide inter-linking with C code, and most data 
structures can be mapped between the two languages. (For some Ada 
compilers like GNAT, this even holds for C++ and Ada)

In fact, there is another C-vs-Ada study,

http://archive.adaic.com/intro/ada-vs-c/cada_art.html

where an Ada compiler vendor incrementally moved their Ada compiler from 
being written in C to being written in Ada, and found a steady increase 
of quality and decrease of cost-to-repair as modules were moved from C 
to Ada. But it is from 1995, so perhaps "out of date" :-)

[toc] | [prev] | [next] | [standalone]

#30497

On 18/04/2021 18:23, Niklas Holsti wrote:
> On 2021-04-18 15:59, David Brown wrote:
>> On 18/04/2021 09:39, Niklas Holsti wrote:
>>> On 2021-04-17 19:45, David Brown wrote:
>>>> On 17/04/2021 17:48, pozz wrote:
>>>>> What do you think about different languages than usual C for embedded
>>>>> systems?
>>>>>
>>>>> I mean C++, Ada but also Python. Always more powerful embedded
>>>>> processors are coming, so I expect new and modern languages will enter
>>>>> in the embedded world.
>>>>>
>>>>> ...
>>>>> Is it ok for me to study and learn new things... but it will be more
>>>>> difficult to acquire new skills for real jobs.
>>>>>
>>>>> What do you think?
>>>>
>>>>    ...
>>>> Ada involves a fair amount of change to how you work, compared to C
>>>> development.  (Disclaimer - I have only done a very small amount of Ada
>>>> coding, and no serious projects.  But I have considered it as an
>>>> option.)  I really don't see it becoming much more common, and outside
>>>> of niche areas (defence, aerospace) it is very rare.  Programming in
>>>> Ada
>>>> often takes a lot more effort even for simple things, leading
>>>> quickly to
>>>> code that is so wordy that it is unclear what is going on.
>>>
>>>
>>> That depends, I guess, on what one considers "simple", and also, of
>>> course, on how familiar one is with the languages.
>>>
>>> Perhaps it is time to link once again to the experience of C versus Ada
>>> in an introductory embedded-programming class using a model rail-road
>>> example, where the students using Ada fared much better than those
>>> using C:
>>>
>>> http://archive.adaic.com/projects/atwork/trains.html
>>
>> Are there no newer examples?
> 
> 
> I have none to hand, at least.
> 
> 
>> While this study was interesting, it is some 30 years out of date
> 
> I would call it "30 years old". Whether it is "out of date" can be
> debated -- I don't think the basic ideas of the two languages have
> changed very drastically even in that time.
> 

C made a big leap, IMHO, with C99 - it became a significantly better
language, and it became easier to write safe, clear and efficient code
than with C90.  (C11 and C17 add little in comparison.)

C++ is a completely different language now than it was 30 years ago.

And the tools for both C and C++ have changed hugely in that time.

But some programmers have not changed, and the way they write C code has
not changed.  Again, it's a question of whether you are comparing how
languages /could/ be used at their best, or how some people use them at
their worst, or guessing something in between.

> 
>> and compares and old version of Ada with an old version of C (perhaps
>> not even C90).  I'd rather see the pros and cons of Ada 2012 compared
>> to C++17.
> 
> So would I, but I haven't seen any such studies reported.
> 
> I can only point to the biased material at
> https://www.adaic.org/advantages/.

As an example of the bias, I looked at the "What constructs exist in Ada
that do not have an equivalent construct in C/C++?" page.  First off,
anyone who talks about "C/C++" as though it were a single language is
either ignorant or biased.  Some of their points are outdated (C++ has
"proper" array types in the standard library), and support for very nice
syntaxes for literals).  Some are fair enough - strong type checking of
arithmetic types needs a good deal more effort (such as shown in the
"strong typedef" link from earlier).  Some are absolutely a point to
Ada, such as named parameters.  And the page is missing the "What
constructs exist in C++ that do not have an equivalent in Ada?" list :-)

> 
> And a recent Ada-adoption story from NVIDIA:
> 
> https://www.adacore.com/webinars/securing-future-of-embedded-software
> 
> but that is more about the AdaCore tools and the SPARK form of Ada than
> about C-vs-Ada.
> 
>>>
>>> I am (as you guessed) an Ada fan, and find it a pleasure to write, even
>>> if it takes more keystrokes than the equivalent in C.
>>
>> I had no need to guess - it's not the first time you have posted about
>> Ada here!  I'm glad that someone with your Ada qualifications can chime
>> in here, and can correct my if I'm wrong.
>>
>>>
>>> For embedded systems in particular, I find portability to be a great
>>> advantage of Ada. With few exceptions, the embedded program can be
>>> exercised on the development host, and if the target supports the
>>> standard Ada tasking system (or a subset of it), this applies even to
>>> multi-threaded programs (without the need to emulate some embedded
>>> RTK/OS on the host).
>>>
>>
>> For suitable targets, I can see that being useful.  C and C++ can be
>> used on a wider range of targets, and with a wider range of RTOS (if
>> any).
> 
> 
> Ada can be used with other RTOSses too, although one loses both some
> ease-of-use advantages and the portability advantage. Typical Ada
> compilers for embedded systems also let one write Ada programs that do
> not need an RTOS at all and run with a single thread.
> 
> 
>> Of course, code for widely differing target systems is often very
>> different anyway, so portability is not always a concern.
>>
>>>
>>>> And most of the advantages of Ada (such as better typing) can be
>>>> achieved in C++ with less effort,
>>>
>>> According to the link above, the main Ada advantage was the ability to
>>> define one's own problem-oriented scalar types, such as integers with
>>> specific value ranges. AIUI, this is not easily done in C++.
>>>
>>
>> Sure it can be done in C++.
>>
>> <https://foonathan.net/2016/10/strong-typedefs/>
> 
> I did not see any mention of range-checked types there. But yes, they
> can be constructed in C++, but not as easily as in Ada, as it seems we
> agree. I should have said "/as/ easily" in the quote above.

Once you have made appropriate templates, they can be used as easily as
in Ada.  But such templates are not in the C++ standard library.

> 
> 
>> You can make types with specific ranges (with compile-time checks where
>> possible, optional run-time checks otherwise).  You can choose which
>> operations you allow on them, and how they combine (so that multiplying
>> a speed and a time give you a distance automatically, but adding them is
>> not allowed).  You can make integer types with different overflow
>> behaviour (wrapping, saturating, throwing errors, unspecified behaviour,
>> undefined behaviour) that can be used as easily as normal integers, and
>> mixed if and only if it is safe to do so or you make it explicit.  You
>> can make array types that are indexed by enumerated types.  It's all
>> possible - more so that in Ada, AFAIK.
> 
> 
> I admit that C++ templates allow the programming of more compile-time
> activities than Ada allows.
> 

C++ has got a lot stronger at compile-time work in recent versions.  Not
only have templates got more powerful, but we've got "concepts" (named
sets of features or requirements for types), constexpr functions (that
can be evaluated at compile time or runtime), consteval functions (that
must be evaluated at compile time), constinit data (that must have
compile-time constant initialisers), etc.  And constants determined at
compile-time are not restricted to scaler or simple types.

> 
>> Where you have a difference, however, is that many of the most
>> beneficial cases (such as strong subrange types) are simple to use in
>> Ada and built into the language, and therefore they are often used.  In
>> C++, you need to find a suitable template library or make things
>> yourself, giving a much higher barrier to use.
> 
> 
> Yup.
> 
> 
>> A very interesting distinction when looking at language features and
>> safe coding is how much people /could/ use safety features, and how much
>> they /do/ use them.  For example, with C programming you can get strong
>> type safety as long as you wrap all your new types in structs.  The
>> compiler will complain for type mistakes, just as it would in Ada - but
>> the /use/ of such types is often very inconvenient in C.
> 
> 
> Indeed.
> 
> 
>>>> and at the same time C++ can give additional safety on
>>>> resources that is harder to get on Ada.  (But Ada has some nice
>>>> features
>>>> introspective that C++ programmers currently only dream about.)
>>>
>>>
>>> Can you be more specific on those points, please?
>>>
>>
>> For the first point - my understanding is that in Ada, when you have
>> classes you need to manually call constructor and destructor
>> (initializer and finalizer) functions.  RAII is thus harder, and it is
>> as easy to make mistakes as it is in C (with malloc and free).  Does Ada
>> have the equivalent of std::unique_ptr, std::shared_ptr and other smart
>> pointers, or container classes that handle allocation?
> 
> 
> Answered in another message. The Ada "controlled" types have
> automatically called initializer and finalizer operations. They can be
> used to implement smart pointers, but no smart pointers are built into
> Ada (perhaps mainly because they would then have to be thread-safe,
> which would be a lot of overhead for a single-threaded program).
> 
> 
>> For the second point, I am thinking of things like type attributes.  I
>> would /really/ like C++ enumerations to have something matching the
>> "first" and "last" attributes!  AFAIK, C++ won't get this until
>> reflection is added, probably not until C++26.
> 
> 
> Yes, good point in favour of Ada. I've seen some C++ programs that go to
> great metaprogramming lengths to define "trait" templates to get the
> equivalent of the "first", "last", "size" etc. attributes. So it is,
> again, possible in C++, but not as easy as when it is built-in, as in Ada.
> 

Agreed.

There is a proposal in the works for "metaclasses" in C++, which goes
beyond reflection and into code generation.  I'm looking forward to that
- it will put an end to a lot of "boilerplate" code.  But it's going to
take a good while to arrive.

> 
>>>> It used to be the case that C++ compilers were expensive and poor
>>>> quality, that the resulting code was very slow on common
>>>> microcontrollers, and that the language didn't have much extra to offer
>>>> small-systems embedded developers.  That, I think, has changed in all
>>>> aspects.  I use gcc 10 with C++17 on Cortex-M devices, and features
>>>> like
>>>> templates, strong enumerations, std::array, and controlled automatic
>>>> conversions make it easier to write good code.
>>>
>>>
>>> AdaCore provides the gcc-based GNAT Ada compiler for several embedded
>>> targets, free to use for open-source projects: libre.adacore.com.
>>>
>>> Commercial projects can use Ada on other targets by means of the
>>> (different) AdaCore compiler that generates C code as an intermediate
>>> representation.
>>>
>>
>> This means that Ada suffers from a similar barrier to adoption that C++
>> used to do.  Big companies will happily pay the cost for the tools that
>> they think will lead to better development efficiency or reliability.
>> Smaller ones will have a much harder time trying to justify the expense,
>> especially as they will often have few developers who can use the tools.
>> A move from C to Ada is compounded by needing a complete change of the
>> code - with C to C++, you can re-use old code, and you can also use a
>> few of the C++ features rather than moving wholescale (though of course
>> you also miss out on corresponding benefits).
> 
> 
> Of course you can move from C to Ada without a full re-write, because
> all Ada compilers provide inter-linking with C code, and most data
> structures can be mapped between the two languages. (For some Ada
> compilers like GNAT, this even holds for C++ and Ada)
> 
> In fact, there is another C-vs-Ada study,
> 
> http://archive.adaic.com/intro/ada-vs-c/cada_art.html
> 
> where an Ada compiler vendor incrementally moved their Ada compiler from
> being written in C to being written in Ada, and found a steady increase
> of quality and decrease of cost-to-repair as modules were moved from C
> to Ada. But it is from 1995, so perhaps "out of date" :-)
> 

You can move file by file from C to Ada, but you can move from C to C++
by adding the "-x c++" flag to your build or clicking the "compile C
code as C++" on the IDE.  Then you change as much or as little as you
want, when you want.

[toc] | [prev] | [next] | [standalone]

#30498

On 18/04/21 18:26, David Brown wrote:
> But some programmers have not changed, and the way they write C code has
> not changed.  Again, it's a question of whether you are comparing how
> languages/could/  be used at their best, or how some people use them at
> their worst, or guessing something in between.

That is indeed a useful first question.

A second question is "how easy is it to get intelligent
but inexperienced programmers to avoid the worst features
and use the languages well?" (We'll ignore all the programmers
that shouldn't be given a keyboard :) )

A third is "will that happen in company X's environment when
they are extending code written by people that left 5 years
ago?"

[toc] | [prev] | [next] | [standalone]

#30501

On 18/04/2021 20:29, Tom Gardner wrote:
> On 18/04/21 18:26, David Brown wrote:
>> But some programmers have not changed, and the way they write C code has
>> not changed.  Again, it's a question of whether you are comparing how
>> languages/could/  be used at their best, or how some people use them at
>> their worst, or guessing something in between.
> 
> That is indeed a useful first question.
> 
> A second question is "how easy is it to get intelligent
> but inexperienced programmers to avoid the worst features
> and use the languages well?" (We'll ignore all the programmers
> that shouldn't be given a keyboard :) )
> 
> A third is "will that happen in company X's environment when
> they are extending code written by people that left 5 years
> ago?"

All good questions.

Another is what will happen to the company when the one person that
understood the language at all, leaves?  With C++, you can hire another
qualified and experienced C++ programmer.  (Okay, so you might have to
beat them over the head with an 8051 emulator until they stop using
std::vector and realise you don't want UCS2 encoding for your 2x20
character display, but they'll learn that soon enough.)  With Ada, or
Forth, or any other minor language, you are scuppered.

These are important considerations.

[toc] | [prev] | [next] | [standalone]

#30502

On 18/04/21 21:23, David Brown wrote:
> On 18/04/2021 20:29, Tom Gardner wrote:
>> On 18/04/21 18:26, David Brown wrote:
>>> But some programmers have not changed, and the way they write C code has
>>> not changed.  Again, it's a question of whether you are comparing how
>>> languages/could/  be used at their best, or how some people use them at
>>> their worst, or guessing something in between.
>>
>> That is indeed a useful first question.
>>
>> A second question is "how easy is it to get intelligent
>> but inexperienced programmers to avoid the worst features
>> and use the languages well?" (We'll ignore all the programmers
>> that shouldn't be given a keyboard :) )
>>
>> A third is "will that happen in company X's environment when
>> they are extending code written by people that left 5 years
>> ago?"
> 
> All good questions.
> 
> Another is what will happen to the company when the one person that
> understood the language at all, leaves?  With C++, you can hire another
> qualified and experienced C++ programmer.  (Okay, so you might have to
> beat them over the head with an 8051 emulator until they stop using
> std::vector and realise you don't want UCS2 encoding for your 2x20
> character display, but they'll learn that soon enough.)  With Ada, or
> Forth, or any other minor language, you are scuppered.
> 
> These are important considerations.

They are important considerations, indeed.

I'm unconvinced that it is practical to rely on hiring
another C++ programmer that is /actually/ qualified
and experienced - and wants to work on someone else's
code.

The "uncanny valley" is a major problem for any new tech,
languages included.

We've all seen the next better mousetrap that turns
out to merely have exchanged swings and roundabouts.

[toc] | [prev] | [next] | [standalone]

#30505

On 19/04/2021 00:09, Tom Gardner wrote:
> On 18/04/21 21:23, David Brown wrote:
>> On 18/04/2021 20:29, Tom Gardner wrote:
>>> On 18/04/21 18:26, David Brown wrote:
>>>> But some programmers have not changed, and the way they write C code
>>>> has
>>>> not changed.  Again, it's a question of whether you are comparing how
>>>> languages/could/  be used at their best, or how some people use them at
>>>> their worst, or guessing something in between.
>>>
>>> That is indeed a useful first question.
>>>
>>> A second question is "how easy is it to get intelligent
>>> but inexperienced programmers to avoid the worst features
>>> and use the languages well?" (We'll ignore all the programmers
>>> that shouldn't be given a keyboard :) )
>>>
>>> A third is "will that happen in company X's environment when
>>> they are extending code written by people that left 5 years
>>> ago?"
>>
>> All good questions.
>>
>> Another is what will happen to the company when the one person that
>> understood the language at all, leaves?  With C++, you can hire another
>> qualified and experienced C++ programmer.  (Okay, so you might have to
>> beat them over the head with an 8051 emulator until they stop using
>> std::vector and realise you don't want UCS2 encoding for your 2x20
>> character display, but they'll learn that soon enough.)  With Ada, or
>> Forth, or any other minor language, you are scuppered.
>>
>> These are important considerations.
> 
> They are important considerations, indeed.
> 
> I'm unconvinced that it is practical to rely on hiring
> another C++ programmer that is /actually/ qualified
> and experienced - and wants to work on someone else's
> code.

You don't tell the new guy that he or she must maintain old code!  You
spring that as a surprise, once you've got them hooked on the quality of
your coffee machine.

> 
> The "uncanny valley" is a major problem for any new tech,
> languages included.
> 
> We've all seen the next better mousetrap that turns
> out to merely have exchanged swings and roundabouts.

Indeed.

But code written in the latest fad language is not the worst.  I've had
to deal with code (for a PC) written in ancient versions of a propriety
"RAD tool" where the vendor will no longer sell the outdated version and
the new tool version is not remotely compatible.  I'd pick Ada over that
any day of the week.

[toc] | [prev] | [next] | [standalone]

#30510

On 2021-04-18 23:23, David Brown wrote:
> On 18/04/2021 20:29, Tom Gardner wrote:
>> On 18/04/21 18:26, David Brown wrote:
>>> But some programmers have not changed, and the way they write C code has
>>> not changed.  Again, it's a question of whether you are comparing how
>>> languages/could/  be used at their best, or how some people use them at
>>> their worst, or guessing something in between.
>>
>> That is indeed a useful first question.
>>
>> A second question is "how easy is it to get intelligent
>> but inexperienced programmers to avoid the worst features
>> and use the languages well?" (We'll ignore all the programmers
>> that shouldn't be given a keyboard :) )
>>
>> A third is "will that happen in company X's environment when
>> they are extending code written by people that left 5 years
>> ago?"
> 
> All good questions.
> 
> Another is what will happen to the company when the one person that
> understood the language at all, leaves?


If the company trained only one person in the language, that was a 
stupid (risky) decision by the company, or they should not have started 
using that language at all.


> With C++, you can hire another
> qualified and experienced C++ programmer.  (Okay, so you might have to
> beat them over the head with an 8051 emulator until they stop using
> std::vector and realise you don't want UCS2 encoding for your 2x20
> character display, but they'll learn that soon enough.)  With Ada, or
> Forth, or any other minor language, you are scuppered.


During all my years (since about 1995) working on on-board SW for ESA 
spacecraft, the company hired one person with earlier experience in Ada, 
and that was I. All other hires working in Ada projects learned Ada on 
the job (and some became enthusiasts).

Sadly, some of the large aerospace "prime" companies in Europe are 
becoming unwilling to accept subcontracted SW products in Ada, for the 
reason discussed: because their HR departments say that they cannot find 
programmers trained in Ada. Bah, a competent programmer will pick up the 
core concepts quickly, says I.

Of course there are also training companies that offer Ada training courses.

[toc] | [prev] | [next] | [standalone]

#30511

On 4/19/2021 14:04, Niklas Holsti wrote:
> ....
> Sadly, some of the large aerospace "prime" companies in Europe are 
> becoming unwilling to accept subcontracted SW products in Ada, for the 
> reason discussed: because their HR departments say that they cannot find 
> programmers trained in Ada. Bah, a competent programmer will pick up the 
> core concepts quickly, says I.

This is valid not just for ADA. An experienced programmer will need days
to adjust to this or that language. I guess most if not all of us have
been through it.

Dimiter

======================================================
Dimiter Popoff, TGI             http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#30521

Dimiter_Popoff <dp@tgi-sci.com> writes:
> On 4/19/2021 14:04, Niklas Holsti wrote:
>> ...their HR departments say that they cannot find programmers trained
>> in Ada. Bah, a competent programmer will pick up the core concepts
>> quickly, says I.
>
> This is valid not just for ADA. An experienced programmer will need days
> to adjust to this or that language. I guess most if not all of us have
> been through it.

No it's much worse than that.  First of all some languages are really
different and take considerable conceptual adjustment: it took me quite
a while as a C and Python programmer to become anywhere near clueful
about Haskell.  But understanding Haskell then demystified parts of C++
that had made no sense to me at all.

Secondly, being competent in a language now means far more than the
language itself.  There is also a culture and a code corpus out there
which also have to be assimilated for each language.  E.g. Ruby is a
very simple language, but coming up to speed as a Ruby developer means
getting used to a decade of Rails hacks, ORM internals, 100's of "gems"
(packages) scattered over 100s of Github repositories, etc.  It's the
same way with Javascript and the NPM universe plus whatever
framework-of-the-week your project is using.  Python is not yet that
bad, because it traditionally had a "batteries included" ethic that
tried to standardize more useful functions than other languages did, but
it seems to have given up on that in the past few years.

Maybe things are better in the embedded world, but in the internet world
any significant application will have far too much internal
functionality (dealing with complex network protocols, file formats,
etc) for the developers to get anything done without bringing in a mass
of external dependencies.  A lot of dev work ISTM now is about
understanding and managing those dependencies, and also in connecting to
a wider dev community that you can exchange wisdom with.  "Computer
science", such as knowing how to balance binary trees, is now almost a
useless subject.  (On the other hand, math in general, particularly
probability, has become a lot more useful.  This is kind of satisfying
for me since I studied a lot of it in school and then for many years
never used it in programming.)

[toc] | [prev] | [next] | [standalone]

#30527

On 2021-04-19 22:47, Paul Rubin wrote:
> Dimiter_Popoff <dp@tgi-sci.com> writes:
>> On 4/19/2021 14:04, Niklas Holsti wrote:
>>> ...their HR departments say that they cannot find programmers trained
>>> in Ada. Bah, a competent programmer will pick up the core concepts
>>> quickly, says I.
>>
>> This is valid not just for ADA. An experienced programmer will need days
>> to adjust to this or that language. I guess most if not all of us have
>> been through it.
> 
> No it's much worse than that.  First of all some languages are really
> different and take considerable conceptual adjustment: it took me quite
> a while as a C and Python programmer to become anywhere near clueful
> about Haskell.  But understanding Haskell then demystified parts of C++
> that had made no sense to me at all.


I agree that it takes a mental leap to go from an imperative language to 
a functional languge, or to a logic-programming / declarative language.

To maintain a Haskell program, one would certainly prefer to hire a 
programmer experienced in functional programming, over one experienced 
only in C, C++ or Ada.


> Secondly, being competent in a language now means far more than the
> language itself.  There is also a culture and a code corpus out there
> which also have to be assimilated for each language.  E.g. Ruby is a
> very simple language, but coming up to speed as a Ruby developer means
> getting used to a decade of Rails hacks, ORM internals, 100's of "gems"
> (packages) scattered over 100s of Github repositories, etc.  It's the
> same way with Javascript and the NPM universe plus whatever
> framework-of-the-week your project is using.  Python is not yet that
> bad, because it traditionally had a "batteries included" ethic that
> tried to standardize more useful functions than other languages did, but
> it seems to have given up on that in the past few years.


Relying on libraries/packages from the Internet is also a huge 
vulnerability. Not long ago a large part of the world's programs in one 
of these languages (unfortunately I forget which -- it was reported on 
comp.risks) suddenly stopped working because they all depended on 
real-time download of a small library package from a certain repository, 
where the maintainer of that package had quarreled with the repository 
owner/provider and had removed the package. Boom... Fortunately it was a 
very small piece of SW and was easily replaced.

The next step is for a malicious actor to replace some such package with 
malware... the programs which use it will seem to go on working, but may 
not do what they are supposed to do.

[toc] | [prev] | [next] | [standalone]

#30534

On 19/04/2021 23:37, Niklas Holsti wrote:
> On 2021-04-19 22:47, Paul Rubin wrote:
>> Dimiter_Popoff <dp@tgi-sci.com> writes:
>>> On 4/19/2021 14:04, Niklas Holsti wrote:
>>>> ...their HR departments say that they cannot find programmers trained
>>>> in Ada. Bah, a competent programmer will pick up the core concepts
>>>> quickly, says I.
>>>
>>> This is valid not just for ADA. An experienced programmer will need days
>>> to adjust to this or that language. I guess most if not all of us have
>>> been through it.
>>
>> No it's much worse than that.  First of all some languages are really
>> different and take considerable conceptual adjustment: it took me quite
>> a while as a C and Python programmer to become anywhere near clueful
>> about Haskell.  But understanding Haskell then demystified parts of C++
>> that had made no sense to me at all.
> 
> 
> I agree that it takes a mental leap to go from an imperative language to
> a functional languge, or to a logic-programming / declarative language.
> 
> To maintain a Haskell program, one would certainly prefer to hire a
> programmer experienced in functional programming, over one experienced
> only in C, C++ or Ada.

Certainly.  The differences between C++ and Ada are much smaller than to
Haskell.

Some languages mix imperative and functional paradigms.  In C++, you can
do a certain amount of functional-style coding - you have lambdas, and
with templates and generic functions you can manipulate functions to
some extent.  Ranges and list comprehensions are new to the latest
standard, though being library features they are not as neat in syntax
as you get in languages that support these directly (like Python or,
more obviously, Haskell).  Pattern matching is on its way too.

You see at least some functional programming features on many
interpreted languages too, like Python and Javascript.

Going the other way, you get ocaml that is basically a functional
programming language with some imperative features added on.


But for someone unused to functional programming, Haskell does look
quite bizarre.  (Though it is not at the level of APL!).

> 
>> Secondly, being competent in a language now means far more than the
>> language itself.  There is also a culture and a code corpus out there
>> which also have to be assimilated for each language.  E.g. Ruby is a
>> very simple language, but coming up to speed as a Ruby developer means
>> getting used to a decade of Rails hacks, ORM internals, 100's of "gems"
>> (packages) scattered over 100s of Github repositories, etc.  It's the
>> same way with Javascript and the NPM universe plus whatever
>> framework-of-the-week your project is using.  Python is not yet that
>> bad, because it traditionally had a "batteries included" ethic that
>> tried to standardize more useful functions than other languages did, but
>> it seems to have given up on that in the past few years.
> 
> 
> Relying on libraries/packages from the Internet is also a huge
> vulnerability. Not long ago a large part of the world's programs in one
> of these languages (unfortunately I forget which -- it was reported on
> comp.risks) suddenly stopped working because they all depended on
> real-time download of a small library package from a certain repository,
> where the maintainer of that package had quarreled with the repository
> owner/provider and had removed the package. Boom... Fortunately it was a
> very small piece of SW and was easily replaced.
> 

Would that have been a Javascript library?  It is common (mad, but
common) to pull these from external servers (rather than your own
webserver), and it would happen every time a webpage with the code is
loaded.

> The next step is for a malicious actor to replace some such package with
> malware... the programs which use it will seem to go on working, but may
> not do what they are supposed to do.

[toc] | [prev] | [next] | [standalone]

#30513

On 19/04/2021 13:04, Niklas Holsti wrote:
> On 2021-04-18 23:23, David Brown wrote:
>> On 18/04/2021 20:29, Tom Gardner wrote:
>>> On 18/04/21 18:26, David Brown wrote:
>>>> But some programmers have not changed, and the way they write C code
>>>> has
>>>> not changed.  Again, it's a question of whether you are comparing how
>>>> languages/could/  be used at their best, or how some people use them at
>>>> their worst, or guessing something in between.
>>>
>>> That is indeed a useful first question.
>>>
>>> A second question is "how easy is it to get intelligent
>>> but inexperienced programmers to avoid the worst features
>>> and use the languages well?" (We'll ignore all the programmers
>>> that shouldn't be given a keyboard :) )
>>>
>>> A third is "will that happen in company X's environment when
>>> they are extending code written by people that left 5 years
>>> ago?"
>>
>> All good questions.
>>
>> Another is what will happen to the company when the one person that
>> understood the language at all, leaves?
> 
> 
> If the company trained only one person in the language, that was a
> stupid (risky) decision by the company, or they should not have started
> using that language at all.
> 
> 
>> With C++, you can hire another
>> qualified and experienced C++ programmer.  (Okay, so you might have to
>> beat them over the head with an 8051 emulator until they stop using
>> std::vector and realise you don't want UCS2 encoding for your 2x20
>> character display, but they'll learn that soon enough.)  With Ada, or
>> Forth, or any other minor language, you are scuppered.
> 
> 
> During all my years (since about 1995) working on on-board SW for ESA
> spacecraft, the company hired one person with earlier experience in Ada,
> and that was I. All other hires working in Ada projects learned Ada on
> the job (and some became enthusiasts).
> 
> Sadly, some of the large aerospace "prime" companies in Europe are
> becoming unwilling to accept subcontracted SW products in Ada, for the
> reason discussed: because their HR departments say that they cannot find
> programmers trained in Ada. Bah, a competent programmer will pick up the
> core concepts quickly, says I.
> 

I agree with you there.  But so many people learn "programming in C++"
or "programming in Java", rather than learning "programming".

> Of course there are also training companies that offer Ada training
> courses.

[toc] | [prev] | [next] | [standalone]

#30499

On 18/04/21 18:26, David Brown wrote:
> C++ has got a lot stronger at compile-time work in recent versions.  Not
> only have templates got more powerful, but we've got "concepts" (named
> sets of features or requirements for types), constexpr functions (that
> can be evaluated at compile time or runtime), consteval functions (that
> must be evaluated at compile time), constinit data (that must have
> compile-time constant initialisers), etc.  And constants determined at
> compile-time are not restricted to scaler or simple types.

Sounds wordy ;)

[toc] | [prev] | [next] | [standalone]

#30500

On 18/04/2021 20:30, Tom Gardner wrote:
> On 18/04/21 18:26, David Brown wrote:
>> C++ has got a lot stronger at compile-time work in recent versions.  Not
>> only have templates got more powerful, but we've got "concepts" (named
>> sets of features or requirements for types), constexpr functions (that
>> can be evaluated at compile time or runtime), consteval functions (that
>> must be evaluated at compile time), constinit data (that must have
>> compile-time constant initialisers), etc.  And constants determined at
>> compile-time are not restricted to scaler or simple types.
> 
> Sounds wordy ;)

Have you looked at the C++ standards documents?  There are more than a
few words there!

I'm not suggesting C++ is a perfect language - not by a long way.  It
has plenty of ugliness, and in this thread we've covered several points
where Ada can do something neater and clearer than you can do it in C++.

But it's a good thing that it has more ways for handling things at
compile time.  In many of my C projects, I have had Python code for
pre-processing, for computing tables, and that kind of thing.  With
modern C++, these are no longer needed.

An odd thing about the compile-time calculation features of C++ is that
they came about partly by accident, or unforeseen side-effects.  Someone
discovered that templates with integer parameters could be used to do
quite a lot of compile-time calculations.  The code was /really/ ugly,
slow to compile, limited in scope.  But people were finding use for it.
 So the motivation for "constexpr" was that programmers were already
doing compile-time calculations, and so it was best to let them do it in
a nicer way.

[toc] | [prev] | [next] | [standalone]

#30503

On 18/04/21 21:17, David Brown wrote:
> On 18/04/2021 20:30, Tom Gardner wrote:
>> On 18/04/21 18:26, David Brown wrote:
>>> C++ has got a lot stronger at compile-time work in recent versions.  Not
>>> only have templates got more powerful, but we've got "concepts" (named
>>> sets of features or requirements for types), constexpr functions (that
>>> can be evaluated at compile time or runtime), consteval functions (that
>>> must be evaluated at compile time), constinit data (that must have
>>> compile-time constant initialisers), etc.  And constants determined at
>>> compile-time are not restricted to scaler or simple types.
>>
>> Sounds wordy ;)
> 
> Have you looked at the C++ standards documents?  There are more than a
> few words there!

No. I value my sanity.


> I'm not suggesting C++ is a perfect language - not by a long way.  It
> has plenty of ugliness, and in this thread we've covered several points
> where Ada can do something neater and clearer than you can do it in C++.
> 
> But it's a good thing that it has more ways for handling things at
> compile time.  In many of my C projects, I have had Python code for
> pre-processing, for computing tables, and that kind of thing.  With
> modern C++, these are no longer needed.

The useful question is not whether something is good,
but whether there are better alternatives. "Better",
of course, can include /anything/ relevant!



> An odd thing about the compile-time calculation features of C++ is that
> they came about partly by accident, or unforeseen side-effects.  Someone
> discovered that templates with integer parameters could be used to do
> quite a lot of compile-time calculations.  The code was /really/ ugly,
> slow to compile, limited in scope.  But people were finding use for it.
>   So the motivation for "constexpr" was that programmers were already
> doing compile-time calculations, and so it was best to let them do it in
> a nicer way.

Infamously, getting a valid C++ program that cause the
compiler to generate the sequence of prime numbers during
compilation came as an unpleasant /surprise/ to the C++
standards committee.

The code is short; whether it is ugly is a matter of taste!
https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP

[toc] | [prev] | [next] | [standalone]

#30504

On 19/04/2021 00:17, Tom Gardner wrote:
> On 18/04/21 21:17, David Brown wrote:
>> On 18/04/2021 20:30, Tom Gardner wrote:
>>> On 18/04/21 18:26, David Brown wrote:
>>>> C++ has got a lot stronger at compile-time work in recent versions. 
>>>> Not
>>>> only have templates got more powerful, but we've got "concepts" (named
>>>> sets of features or requirements for types), constexpr functions (that
>>>> can be evaluated at compile time or runtime), consteval functions (that
>>>> must be evaluated at compile time), constinit data (that must have
>>>> compile-time constant initialisers), etc.  And constants determined at
>>>> compile-time are not restricted to scaler or simple types.
>>>
>>> Sounds wordy ;)
>>
>> Have you looked at the C++ standards documents?  There are more than a
>> few words there!
> 
> No. I value my sanity.

I have looked at it, and come back as sane as ever (apart from the
pencils up my nose and underpants on my head).  But I've worked up to it
through many versions of the C standards.

More seriously, if I need to look up any details of C or C++, I find
<https://en.cppreference.com/w/> vastly more user-friendly.

> 
> 
>> I'm not suggesting C++ is a perfect language - not by a long way.  It
>> has plenty of ugliness, and in this thread we've covered several points
>> where Ada can do something neater and clearer than you can do it in C++.
>>
>> But it's a good thing that it has more ways for handling things at
>> compile time.  In many of my C projects, I have had Python code for
>> pre-processing, for computing tables, and that kind of thing.  With
>> modern C++, these are no longer needed.
> 
> The useful question is not whether something is good,
> but whether there are better alternatives. "Better",
> of course, can include /anything/ relevant!
> 

Yes - and "better" is usually highly subjective.

In the case of compile-time calculations, modern C++ is certainly better
than older C++ versions or C (or, AFAIK, Ada).  It can't do everything
that I might do with external Python scripts - it can't do code
generation, or make tables that depend on multiple source files, or make
CRC checks for the final binary.  But it can do some things that
previously required external scripts, and that's nice.

> 
> 
>> An odd thing about the compile-time calculation features of C++ is that
>> they came about partly by accident, or unforeseen side-effects.  Someone
>> discovered that templates with integer parameters could be used to do
>> quite a lot of compile-time calculations.  The code was /really/ ugly,
>> slow to compile, limited in scope.  But people were finding use for it.
>>   So the motivation for "constexpr" was that programmers were already
>> doing compile-time calculations, and so it was best to let them do it in
>> a nicer way.
> 
> Infamously, getting a valid C++ program that cause the
> compiler to generate the sequence of prime numbers during
> compilation came as an unpleasant /surprise/ to the C++
> standards committee.

I don't believe that the surprise was "unpleasant" - it's just something
they hadn't considered.  (I'm not even sure of that either - my feeling
is that this is an urban myth, or at least a story exaggerated in the
regular retelling.)

> 
> The code is short; whether it is ugly is a matter of taste!
> https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP
> 

Template-based calculations were certainly very convoluted - they needed
a functional programming style structure but with much more awkward
syntax (and at the height of their "popularity", horrendous compiler
error messages when you made a mistake - that too has improved greatly).
 And that is why constexpr (especially in latest versions) is so much
better.

Template-based calculations are a bit like trying to do calculations and
data structures in LaTeX.  It is all possible, but it doesn't roll off
the tongue very easily.


(I wonder if anyone else understands the pencil and underpants
reference.  I am sure Tom does.)

[toc] | [prev] | [next] | [standalone]

#30506

On 19/04/21 07:52, David Brown wrote:
> On 19/04/2021 00:17, Tom Gardner wrote:
>> Infamously, getting a valid C++ program that cause the
>> compiler to generate the sequence of prime numbers during
>> compilation came as an unpleasant /surprise/ to the C++
>> standards committee.
> 
> I don't believe that the surprise was "unpleasant" - it's just something
> they hadn't considered.  (I'm not even sure of that either - my feeling
> is that this is an urban myth, or at least a story exaggerated in the
> regular retelling.)

I was thinking of "unpleasant" /because/ it was a surprise.
Bjarne dismissed the possibility before being stunned a
couple of days later.

Here's a google (mis)translation of the Erwin Unruh's account at
http://www.erwin-unruh.de/meta.html

Temple meta programming

  The template meta programming is a way to carry out calculations already in C 
++ during the translation.  This allows additional checks to be installed.  This 
is particularly used to build efficient algorithms.
  In 2000, a special workshop was held for this purpose.

  This started with the C ++ standardization meeting in 1994 in Sandiego.  Here 
is my personal memory:

  We discussed the possibilities of determining template arguments from a 
template.  The question came up as to whether the inverse of a function could be 
determined.  So if "i + 1 == 5" could be closed, that "i == 4".  This was 
denied, but the question inspired me to the idea to calculate primes during the 
translation.  The first version I crafted on Monday, but she was fundamentally 
wrong.  Bjarne Strouffup said so something would not work in principle.
  This stacked my zeal, and so I finished the scaffolding of the program 
Wednesday afternoon.  On Wednesday evening another work meeting was announced 
where I had some air.  There I met Tom Pennello, and we put together.  He had 
his notebook and we tapped my program briefly.  After some crafts, the program 
ran.  We made a run and printed program and error message.  Then Tom came to the 
idea of ​​taking a more complicated function.  We chose the Ackermann function. 
After a few hours, this also ran and calculated the value of the Ackermann 
function during the translation.
  On Thursday I showed the term Bjarne.  He was extremely stunned.  I then made 
copies for all participants and officially distributed this curious program.  I 
kept the whole thing for a joke.

  A few weeks later, I developed a proof that the template mechanism is 
turbine-complete.  However, since this proof was quite dry, I just put it to the 
files.  I still have the notes.  On the occasion, I will tempt this time and 
provide here.

  Later, Todd Veldhuizen picked up the idea and published an article in the C ++ 
Report.  This appeared in May 1995. He understood the possibilities behind the 
idea and put them in concrete metatograms that make something constructive.
  This article was the basis on which template meta programming was built. 
Although I gave the kick-off, but did not recognize the range of the idea.

  Erwin Unruh, 1. 1. 2002


> Template-based calculations are a bit like trying to do calculations and
> data structures in LaTeX.  It is all possible, but it doesn't roll off
> the tongue very easily.

Being perverse can be fun, /provided/ it doesn't happen
accidentally in everyday life.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web