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

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

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

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

Contents

  validity of ... reasons for preferring C over C++ Nobody <nobody@nowhere.invalid> - 2014-10-17 00:00 +0100
    Re: validity of ... reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-17 07:38 +0200
    Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-17 09:27 +0200
      Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 09:29 +0100
        Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-17 11:19 +0200
          Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-17 02:35 -0700
            Re: validity of ... reasons for preferring C over C++ Arlet Ottens <usenet+5@c-scape.nl> - 2014-10-17 11:43 +0200
              Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 12:12 +0100
                Re: validity of ... reasons for preferring C over C++ Arlet Ottens <usenet+5@c-scape.nl> - 2014-10-17 13:25 +0200
                  Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 12:40 +0100
              Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-17 20:12 +0300
                Re: validity of ... reasons for preferring C over C++ Rob Gaddi <rgaddi@technologyhighland.invalid> - 2014-10-17 10:18 -0700
                  Re: validity of ... reasons for preferring C over C++ upsidedown@downunder.com - 2014-10-17 21:53 +0300
                    Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-17 22:59 +0300
                      Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-17 13:23 -0700
                        Re: validity of ... reasons for preferring C over C++ Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2014-10-18 17:46 +0200
                          Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-18 11:45 -0700
                            Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-19 01:51 +0300
                              Re: validity of ... reasons for preferring C over C++ Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2014-10-19 12:43 +0200
                  Re: validity of ... reasons for preferring C over C++ Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2014-10-18 17:44 +0200
            Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-17 12:44 +0200
              Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 12:13 +0100
              Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-17 20:15 +0300
                Re: validity of ... reasons for preferring C over C++ Arlet Ottens <usenet+5@c-scape.nl> - 2014-10-17 19:18 +0200
                Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-17 23:03 +0200
                  Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-17 14:11 -0700
                    Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-18 20:14 +0200
                      Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-18 22:15 +0100
                        Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-18 23:07 +0000
                          Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-19 00:36 +0100
                            Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-19 10:55 +0300
                              Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-19 09:33 +0100
                          Re: validity of ... reasons for preferring C over C++ "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2014-10-20 15:04 +0200
                        Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-19 13:32 +0200
                  Re: validity of ... reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-17 23:44 +0200
                    Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-18 20:10 +0200
                      Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-18 23:38 +0300
                      Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-18 22:21 +0100
                  Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-19 10:43 +0300
                    Re: validity of ... reasons for preferring C over C++ Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2014-10-19 09:38 +0000
                    Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-19 14:07 +0200
                      Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-19 19:47 -0700
                        Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-20 06:55 +0300
                          Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-19 21:02 -0700
                            Re: validity of ... reasons for preferring C over C++ britt.snodgrass@gmail.com - 2014-10-20 04:02 -0700
                            Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-20 18:51 +0300
                              C and Ada, was: Re: validity of ... reasons for preferring C over C++ Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2014-10-21 00:30 +0000
                                Re: C and Ada, was: Re: validity of ... reasons for preferring C over C++ Les Cargill <lcargill99@comcast.com> - 2014-10-20 20:49 -0500
                                  Re: C and Ada, was: Re: validity of ... reasons for preferring C over C++ Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2014-10-21 09:11 +0200
                                    Re: C and Ada, was: Re: validity of ... reasons for preferring C over C++ Les Cargill <lcargill99@comcast.com> - 2014-10-21 08:34 -0500
                  Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-19 21:23 +0300
                  Re: validity of ... reasons for preferring C over C++ Nobody <nobody@nowhere.invalid> - 2014-10-20 03:39 +0100
            Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 12:07 +0100
          Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 12:06 +0100
            Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-17 14:12 +0200
              Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 13:16 +0100
            Re: validity of ... reasons for preferring C over C++ Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2014-10-17 14:13 +0200
              Re: validity of ... reasons for preferring C over C++ Arlet Ottens <usenet+5@c-scape.nl> - 2014-10-17 14:35 +0200
                Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 13:59 +0100
              Re: validity of ... reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-17 17:06 +0200
              Re: validity of ... reasons for preferring C over C++ upsidedown@downunder.com - 2014-10-17 19:41 +0300
        Re: validity of ... reasons for preferring C over C++ Clifford Heath <no.spam@please.net> - 2014-10-18 10:14 +1100
          Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-18 00:36 +0100
            Re: validity of ... reasons for preferring C over C++ Clifford Heath <no.spam@please.net> - 2014-10-20 09:45 +1100
          Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-18 08:52 +0300
            Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-18 09:41 +0100
    Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-20 09:46 -0700
      Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-20 16:26 -0700
        Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-20 16:42 -0700
          Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-20 17:24 -0700
            Re: validity of ... reasons for preferring C over C++ John Devereux <john@devereux.me.uk> - 2014-10-21 19:09 +0100
              Re: validity of ... reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-24 16:38 +0200
            Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-21 15:12 -0700
              Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-21 16:39 -0700
                Re: validity of ... reasons for preferring C over C++ Nobody <nobody@nowhere.invalid> - 2014-10-22 01:43 +0100
                Re: validity of ... reasons for preferring C over C++ Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2014-10-22 20:00 +0200
            Re: validity of ... reasons for preferring C over C++ Stefan Reuther <stefan.news@arcor.de> - 2014-10-22 18:49 +0200
        Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-21 15:15 -0700
        Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-22 04:45 -0700
          Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-22 09:30 -0700
            Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-23 12:25 -0700
              Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-23 15:17 -0700
                Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-23 22:59 +0000
                  Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-23 16:02 -0700
                Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-27 08:30 -0700
                  Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-27 09:00 -0700
                    Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-27 09:24 -0700
                      Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-27 09:30 -0700
                      Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-28 00:52 +0000
                Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-28 08:45 +0100
                  Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-28 02:00 -0700
                    Re: validity of ... reasons for preferring C over C++ George Neuner <gneuner2@comcast.net> - 2014-10-30 11:56 -0400
                  Re: validity of ... reasons for preferring C over C++ upsidedown@downunder.com - 2014-10-28 19:59 +0200
                    Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-28 23:46 +0100
                      Re: validity of ... reasons for preferring C over C++ upsidedown@downunder.com - 2014-10-29 07:27 +0200
                        Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-29 10:11 +0100
                    Re: validity of ... reasons for preferring C over C++ Robert Wessel <robertwessel2@yahoo.com> - 2014-10-29 10:21 -0500
                      Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-29 20:15 +0000
                        Re: validity of ... reasons for preferring C over C++ Robert Wessel <robertwessel2@yahoo.com> - 2014-10-30 11:33 -0500
                          Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-30 19:07 +0000
                            Re: validity of ... reasons for preferring C over C++ Robert Wessel <robertwessel2@yahoo.com> - 2014-10-30 16:19 -0500
                        Re: validity of ... reasons for preferring C over C++ Nobody <nobody@nowhere.invalid> - 2014-10-31 07:32 +0000
                          Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-31 08:45 +0000
                            Re: validity of ... reasons for preferring C over C++ Reinhardt Behm <rbehm@hushmail.com> - 2014-10-31 18:15 +0800
                              Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-31 22:03 +0000
                            Re: validity of ... reasons for preferring C over C++ Robert Wessel <robertwessel2@yahoo.com> - 2014-10-31 09:53 -0500
                              Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-31 22:17 +0000
                          Re: validity of ... reasons for preferring C over C++ Les Cargill <lcargill99@comcast.com> - 2014-10-31 17:50 -0500
              Re: validity of ... reasons for preferring C over C++ Nobody <nobody@nowhere.invalid> - 2014-10-28 04:37 +0000
      Re: validity of ... reasons for preferring C over C++ Stefan Reuther <stefan.news@arcor.de> - 2014-10-21 19:12 +0200
        Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-21 15:06 -0700
          Re: validity of ... reasons for preferring C over C++ Stefan Reuther <stefan.news@arcor.de> - 2014-10-22 19:06 +0200

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

#18704

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 - and the limited choice of
tools, and limited number of users, mean that it is only appropriate in
certain niches.  This applies even more so to other language choices,
such as Eiffel.

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

#18708

On 17/10/14 11: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 - and the limited choice of
> tools, and limited number of users, mean that it is only appropriate in
> certain niches.  This applies even more so to other language choices,
> such as Eiffel.

Yes :( The tyranny of the majority :(

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

#18733

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...

> - and the limited choice of tools, and limited number of users, mean
> that it is only appropriate in certain niches. 

Circular argument. If more people would use it, there would be more
users, more choice of tools, etc. On USENET, comp.lang.ada is a very
active group which gives lots of help to new users. And recently there
seems to be an influx of new users in that group.

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

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

#18734

On 10/17/2014 07:15 PM, Niklas Holsti wrote:

>> - and the limited choice of tools, and limited number of users, mean
>> that it is only appropriate in certain niches.
>
> Circular argument. If more people would use it, there would be more
> users, more choice of tools, etc. On USENET, comp.lang.ada is a very
> active group which gives lots of help to new users. And recently there
> seems to be an influx of new users in that group.

For any given developer, there's nothing circular about the argument.

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

#18751

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, and many of the 
constructs are more wordy than necessary.  Using words rather than 
symbols is not necessarily a bad thing, within limits - C++ arguably 
relies too much on symbols, as anyone trying to read a lambda function 
will know.  But sometimes Ada reads as though you are chatting to the 
computer rather than programming.

Ada programming encourages the use of user-defined types for all sorts 
of things.  You are not supposed to hold a "day" in an "int" or 
"uint8_t", you are supposed to define "type Day_type is range 1 .. 31;". 
  Sometimes this sort of thing can make code clearer, but it can also 
make it harder to see what is really going on in the program.  When you 
see a type like "uint8_t" or "int", you know exactly what it means - 
when the type is "Day_type", you have to think about it much more, and 
perhaps look up the definition.  And because type conversions have to be 
explicit in Ada, you need to add lots of them when using these types.  C 
and C++ do more of this automatically, giving clearer code.

The run-time overhead in Ada can be an issue - the larger run-time 
library, the run-time checks, exceptions (I don't like them in C++ either).


Of course, the biggest disadvantages of Ada compared to C or C++ are not 
because of the language itself, but because of the relative popularities 
- there are fewer Ada tools, fewer Ada developers, fewer libraries, 
RTOS's, network stacks, etc., less example code, and so on.


And there are things that Ada has that I would love to see in C and/or 
C++, such as the ' symbol that lets you write Day_type'Last.


>
>> - and the limited choice of tools, and limited number of users, mean
>> that it is only appropriate in certain niches.
>
> Circular argument. If more people would use it, there would be more
> users, more choice of tools, etc. On USENET, comp.lang.ada is a very
> active group which gives lots of help to new users. And recently there
> seems to be an influx of new users in that group.
>

Of course it is a circular argument.  Lots of things we use or do all 
the time are used primarily because they are popular, and they are 
popular primarily because people use them - despite there being 
technically superior alternatives.  We program 8051 microcontrollers, 
type with QWERTY keyboards, use Windows systems, eat at McDonalds, and 
listen to Britny Spears - even though they are all hopelessly bad 
compared to alternatives, they exist because they are popular.

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

#18752

David Brown <david.brown@hesbynett.no> writes:
> Ada programming encourages the use of user-defined types for all sorts
> of things.  You are not supposed to hold a "day" in an "int" or
> "uint8_t", you are supposed to define "type Day_type is range 1
> .. 31;". Sometimes this sort of thing can make code clearer, but it
> can also make it harder to see what is really going on in the program.

This is called "typeful programming" (search on the phrase) and the idea
is it helps the compiler catch errors in the code.

> And because type conversions have to be explicit in Ada, you need to
> add lots of them when using these types.  C and C++ do more of this
> automatically, giving clearer code.

After using Haskell for a while, I've gotten to hate automatic
conversions.  They make the code obscure and scary compared to explicit
conversions.  I never know if some unwanted conversion is going on in
the background.  If I passed the wrong type by accident and the compiler
goes and converts it automatically, what's the point of having types?

> The run-time overhead in Ada can be an issue - the larger run-time
> library, the run-time checks, exceptions (I don't like them in C++
> either).

I think this is a matter of what runtime profile you choose.  Ada has
lots of different profiles including some intended for small embedded
processors that don't support fancier features like tasking (not sure
about exceptions).  Runtime checks for stuff like integer range errors
are typically compile-time options.

> there are fewer Ada tools, fewer Ada developers, fewer libraries,
> RTOS's, network stacks, etc., less example code, and so on.

True.

> We program 8051 microcontrollers, type with QWERTY keyboards, use
> Windows systems, eat at McDonalds, and listen to Britny Spears - even
> though they are all hopelessly bad compared to alternatives, they
> exist because they are popular.

Saved to quote file :)

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

#18800

On 17/10/14 23:11, Paul Rubin wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> Ada programming encourages the use of user-defined types for all sorts
>> of things.  You are not supposed to hold a "day" in an "int" or
>> "uint8_t", you are supposed to define "type Day_type is range 1
>> .. 31;". Sometimes this sort of thing can make code clearer, but it
>> can also make it harder to see what is really going on in the program.
>
> 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.

>
>> And because type conversions have to be explicit in Ada, you need to
>> add lots of them when using these types.  C and C++ do more of this
>> automatically, giving clearer code.
>
> After using Haskell for a while, I've gotten to hate automatic
> conversions.  They make the code obscure and scary compared to explicit
> conversions.  I never know if some unwanted conversion is going on in
> the background.  If I passed the wrong type by accident and the compiler
> goes and converts it automatically, what's the point of having types?
>
>> The run-time overhead in Ada can be an issue - the larger run-time
>> library, the run-time checks, exceptions (I don't like them in C++
>> either).
>
> I think this is a matter of what runtime profile you choose.  Ada has
> lots of different profiles including some intended for small embedded
> processors that don't support fancier features like tasking (not sure
> about exceptions).  Runtime checks for stuff like integer range errors
> are typically compile-time options.

OK.  I haven't tried Ada on embedded systems, and haven't looked at this 
in detail.

>
>> there are fewer Ada tools, fewer Ada developers, fewer libraries,
>> RTOS's, network stacks, etc., less example code, and so on.
>
> True.
>
>> We program 8051 microcontrollers, type with QWERTY keyboards, use
>> Windows systems, eat at McDonalds, and listen to Britny Spears - even
>> though they are all hopelessly bad compared to alternatives, they
>> exist because they are popular.
>
> Saved to quote file :)
>

I hope you corrected the spelling of "Britney" before saving it!  But 
it's nice to know I've written something of interest to someone - it's a 
rare thing on Usenet.

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

#18806

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.

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".

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

#18812

Tom Gardner <spamjunk@blueyonder.co.uk> wrote:

(snip)

> 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.

Reminds me that Java requires the compiler to be able to determine
that a scalar variable is given a value before it is referenced.
They could have just zeroed all of them, but that is pretty much
your "automatic".  This way, you have a chance to think about it.
But then again, you can just put =0 on all your declarations.
 
> 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".

Yes, another chance to think about the problem, and possible mistakes.

-- glen

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

#18814

On 19/10/14 00:07, glen herrmannsfeldt wrote:
> Reminds me that Java requires the compiler to be able to determine
> that a scalar variable is given a value before it is referenced.
> They could have just zeroed all of them, but that is pretty much
> your "automatic".  This way, you have a chance to think about it.
> But then again, you can just put =0 on all your declarations.

No.

If a primitive (int, long, boolean etc) isn't explicitly
initialised then it is given a sensible default value (0,
false etc).

Unless explicitly initialised an object also has a sensible
default value, null. There's nothing in the compiler that
will prevent you trying to "use" the object, but at runtime
a NullPointerException is thrown and, if not caught, a stacktrace.

I've seen projects where NullPointerExceptions were regularly
thrown, caught, and ignored. I didn't like it one little bit,
but since it was a "contractual obligation" project and the
program continued to work, there was no point in my making a
great big fuss.

I'm not sure whether or not to be comforted that the program
continued to work :)

There's a story from the early Smalltalk days. Someone was
bringing up a VM and everything was working except that
scrollbars on windows worked in the opposite direction.
Eventually it was traced to a VM primitive bug in the
subtraction of negative numbers.

On even days I think that illustrates remarkable robustness.
On odd days I wonder how anyone could be sure that all VM
bugs had been found.

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

#18818

On 14-10-19 02:36 , Tom Gardner wrote:
> On 19/10/14 00:07, glen herrmannsfeldt wrote:
>> Reminds me that Java requires the compiler to be able to determine
>> that a scalar variable is given a value before it is referenced.
>> They could have just zeroed all of them, but that is pretty much
>> your "automatic".  This way, you have a chance to think about it.
>> But then again, you can just put =0 on all your declarations.
> 
> No.
> 
> If a primitive (int, long, boolean etc) isn't explicitly
> initialised then it is given a sensible default value (0,
> false etc).

Hmm... seems not to be the case.

The Java Specification I found says, in
http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.12.5:

"A local variable (§14.4, §14.14) must be explicitly given a value
before it is used, by either initialization (§14.4) or assignment
(§15.26), in a way that can be verified using the rules for definite
assignment (§16)."

The default initialisation rules, earlier on the same page, do not apply
to local variables.

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

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

#18820

On 19/10/14 08:55, Niklas Holsti wrote:
> On 14-10-19 02:36 , Tom Gardner wrote:
>> On 19/10/14 00:07, glen herrmannsfeldt wrote:
>>> Reminds me that Java requires the compiler to be able to determine
>>> that a scalar variable is given a value before it is referenced.
>>> They could have just zeroed all of them, but that is pretty much
>>> your "automatic".  This way, you have a chance to think about it.
>>> But then again, you can just put =0 on all your declarations.
>>
>> No.
>>
>> If a primitive (int, long, boolean etc) isn't explicitly
>> initialised then it is given a sensible default value (0,
>> false etc).
>
> Hmm... seems not to be the case.
>
> The Java Specification I found says, in
> http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.12.5:
>
> "A local variable (§14.4, §14.14) must be explicitly given a value
> before it is used, by either initialization (§14.4) or assignment
> (§15.26), in a way that can be verified using the rules for definite
> assignment (§16)."
>
> The default initialisation rules, earlier on the same page, do not apply
> to local variables.

Indeed. I wonder why it is required in that subset of cases.
Probably something to do with local classes, which were introduced
"relatively recently".

This isn't something that concerns me in that the environment
requires me to do something that I ought to be doing anyway:
it is the safe option without any penalties.

Having said that, I am becoming concerned that Java is becoming
unnecessarily complex merely in order to save a few keystrokes,
to give computer scientists something to do, and to enable
marketeers to brag about "improvements". Local classes were one
example, generics another, and the stuff in Java 8 another.

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

#18849

Op Sun, 19 Oct 2014 01:07:06 +0200 schreef glen herrmannsfeldt  
<gah@ugcs.caltech.edu>:
> Tom Gardner <spamjunk@blueyonder.co.uk> wrote:
>
> (snip)
>
>> 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.
>
> Reminds me that Java requires the compiler to be able to determine
> that a scalar variable is given a value before it is referenced.
> They could have just zeroed all of them, but that is pretty much
> your "automatic".  This way, you have a chance to think about it.
> But then again, you can just put =0 on all your declarations.

Unless they are "final"!  When poking in other folks' code, I find it  
helps to make things final/const when you think they should be, and see  
where things break.


-- 
(Remove the obvious prefix to reply privately.)
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/

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

#18828

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".

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

#18754

David Brown schreef op 17-Oct-14 11:03 PM:
> 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, and many of the
> constructs are more wordy than necessary.

But do you find it more difficult to *read* Ada because of this 
verbosity? (One of the basic rules of software engineering is that you 
must optimzie for the reader, not for the author.)

 > Using words rather than
> symbols is not necessarily a bad thing, within limits - C++ arguably
> relies too much on symbols, as anyone trying to read a lambda function
> will know.

Funny you mention lambdas in this context. I just finished giving a C++ 
course, which I revised to include C++ 0x11 features, including lambdas. 
I had never written any lambda untill 4 months ago. They still feel 
strange to me, and my college that assisted in the course still thinks 
they are something totally weird.

But for the students a lambda seems to be much easier to understand than 
exceptions or virtual methods. I think experienced programmers (myself 
included) are often much less eager to adopt a new feature than novices.

Wouter van Ooijen

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

#18799

On 17/10/14 23:44, Wouter van Ooijen wrote:
> David Brown schreef op 17-Oct-14 11:03 PM:
>> 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, and many of the
>> constructs are more wordy than necessary.
>
> But do you find it more difficult to *read* Ada because of this
> verbosity? (One of the basic rules of software engineering is that you
> must optimzie for the reader, not for the author.)

Yes, I find it harder to read (but again, I stress my limited experience 
- any language is easier to use after more practice).  When reading C, I 
find the syntax and the common identifiers contrast with function names, 
variables, and other identifiers, making it easier to see the structure 
of the code.  Ada just seems to have too many words for my liking - it 
reads like a school essay.

There is some evidence suggesting that the "errors per line of code" 
rates is fairly independent of the programming language - and with all 
other things being equal (which they seldom are), a more compact 
language will have a lower bug rate than a more verbose one.  I believe 
this is simply a matter of the amount of information that you can easily 
see and process at a time - this is why there is a common rule of 
keeping your functions shorter than one screenfull.


Of course I agree with you that making code easy to read and understand 
is important - languages (and identifiers in the language) should not be 
made short to save keystrokes.

>
>  > Using words rather than
>> symbols is not necessarily a bad thing, within limits - C++ arguably
>> relies too much on symbols, as anyone trying to read a lambda function
>> will know.
>
> Funny you mention lambdas in this context. I just finished giving a C++
> course, which I revised to include C++ 0x11 features, including lambdas.
> I had never written any lambda untill 4 months ago. They still feel
> strange to me, and my college that assisted in the course still thinks
> they are something totally weird.
>

I use lambdas regularly in Python - where they are defined using the 
keyword "lambda".  So I am quite happy with the concept of lambda 
functions - I just think that the C++ syntax for them is going to take 
quite a while to get used to.

> But for the students a lambda seems to be much easier to understand than
> exceptions or virtual methods. I think experienced programmers (myself
> included) are often much less eager to adopt a new feature than novices.
>
> Wouter van Ooijen
>

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

#18805

On 14-10-18 21:10 , David Brown wrote:

> There is some evidence suggesting that the "errors per line of code"
> rates is fairly independent of the programming language - and with all
> other things being equal (which they seldom are), a more compact
> language will have a lower bug rate than a more verbose one.

Stephen F. Zeigler reported in 1995 on an empirical study, done within
Rational Software Corporation, of a large set of C and Ada modules being
developed and maintained by the same team, with the same people working
on both C and Ada modules.

The rate of defects/KSLOC was 0.676 for the C modules, and 0.096 for the
Ada modules - about 7 times more defects per line in C than in Ada.

The study makes many other interesting comparisons:
http://archive.adaic.com/intro/ada-vs-c/cada_art.html.

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

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

#18807

On 18/10/14 19:10, David Brown wrote:
> On 17/10/14 23:44, Wouter van Ooijen wrote:
>> David Brown schreef op 17-Oct-14 11:03 PM:
>>> 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, and many of the
>>> constructs are more wordy than necessary.
>>
>> But do you find it more difficult to *read* Ada because of this
>> verbosity? (One of the basic rules of software engineering is that you
>> must optimzie for the reader, not for the author.)
>
> Yes, I find it harder to read (but again, I stress my limited experience - any language is easier to use after more practice).  When reading C, I find the syntax and the common identifiers contrast
> with function names, variables, and other identifiers, making it easier to see the structure of the code.  Ada just seems to have too many words for my liking - it reads like a school essay.

Without commenting on Ada specifically, my experience is that
the more information you can give the compiler via the source code,
the better the environmental tools can help you.

I started with C when the state of the art was multiple green screens,
emacs and grep.

The power of modern environments with modern languages to recursively
and accurately "show me everything that can call this method" and
"show me everything reachable from here", plus "what methods can
I call on variable x" is remarkable and helpful.

For me that's a good tradeoff.

> There is some evidence suggesting that the "errors per line of code" rates is fairly independent of the programming language - and with all other things being equal (which they seldom are), a more
> compact language will have a lower bug rate than a more verbose one.  I believe this is simply a matter of the amount of information that you can easily see and process at a time - this is why there
> is a common rule of keeping your functions shorter than one screenfull.
>
>
> Of course I agree with you that making code easy to read and understand is important - languages (and identifiers in the language) should not be made short to save keystrokes.

And, of course, that extends beyond mere names!

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

#18817

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!   :-)

However, I will focus all my fire on C. I don't know enough about C++ to
debate its merits.

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

You may be surprised by the comparisons later in this post.

> lots of things need repeated,

Really? If you mean the repetition of "if" in the construct "if" .. "end
if" and the similar repetitions of "loop", "case", and "record" in "end
loop", "end case", "end record", I believe many programmers find them
quite useful, compared to the multiply overloaded meanings of "}" in C.
They help an Ada compiler give sensible error messages when some "end"
is omitted by mistake.

The only places where you repeat things in Ada, and you do not need to
repeat in C, that I can think of now, happen when you want to define the
internal codes used for enumeration values or the bit-fields used for
structs ("records" in Ada). In C you can specify those without repeating
the name of the enumeration literal, or the name of the struct field; in
Ada those are repeated, because the "representation clause" is a
separate syntactic unit.

C:
   typedef enum {red = 4, blue = 6, green = 9} color_t;

Ada:

   type color_t is (red, blue, green);
   for color_t use (red => 4, blue => 6, green => 9);

To reduce repetition, the second Ada line can be written as

   for color_t use (4, 6, 9);

but that loses the close connection between the name and the
corresponding value, and is therefore seldom used.

> and many of the
> constructs are more wordy than necessary.  Using words rather than
> symbols is not necessarily a bad thing, within limits - C++ arguably
> relies too much on symbols, as anyone trying to read a lambda function
> will know.  But sometimes Ada reads as though you are chatting to the
> computer rather than programming.

The languages certainly have a different textual appearance. But I will
stick my neck out and argue that for all but small toy programs, Ada is
*less* verbose than C.

How should we measure verbosity? By the number of non-blank characters
in the source-code file, or by the number of syntactical tokens? I think
both measures are relevant.

If we measure by syntactical tokens, for comparable language constructs
there is usually little difference between Ada and C, and in some cases
the Ada form is shorter. Let's look at some common examples, assuming
that in each case the length of the user-chosen identifiers are the same
in Ada and in C (I will argue later below that Ada identifiers should in
general be *shorter* than C identifiers, assuming equivalent naming
conventions).

The C forms below follow the usual recommendations for always using {}
in control structures and "break" in switch cases. In both Ada and C I
insert more spaces than usual, around separators, to make it easier to
count tokens.

Preparing to use another module

   C:    # include "sorting.h"
   Ada:  with Sorting ;

   Same number of tokens. Ada is 7 characters shorter.

Typeless number definition

   C:    # define NUM_FROOS 55
   Ada:  Num_Froos : constant := 55 ;

   C is shorter by 2 tokens and 5 characters.

Typed constant definition

   C:    const float x = 33.4f ;
   Ada:  x : constant float := 33.4 ;

   C is shorter by 1 token and 5 characters.

Variable declaration

   C:      float x ;
   Ada:    x : float ;

   C is one character and token shorter.

Type declaration (type naming)

   C:          typedef float voltage_t ;
   Ada:        subtype voltage_t is float ;

   C is one token and 2 characters shorter.

Assignment statement

   C:      varname = expression  ;
   Ada:    varname := expression ;

   Same number of tokens; one character less in C.

Assignment to a variable through a pointer

   C:     * varname = expression ;
   Ada:   varname . all := expression ;

   C is one token and 4 characters shorter.

Assignment to a field of a structure through a pointer to the structure

   C:     varname -> field = expression ;
   Ada.   varname . field := expression ;

   Same number of tokens and characters in C and Ada.

Conditional statement

   C:
      if ( condition ) {
         statements1
      } else {
         statements2
      }

   Ada:
      if condition then
         statements1
      else
         statements2
      end if ;

   Ada is shorter by two tokens (if we consider "end if" as
   two tokens) but longer by 4 characters, mainly because
   of the full-length words in "then" and "end if".

Counted loop from 1 to N

   C:
      for ( int i = 1 ; i <= N ; i ++ ) {
         statements
      }

   Ada:
      for i in 1 .. N loop
         statements
      end loop ;

   Ada is shorter by 6 tokens, but has the same number of
   characters as C because of the full-length words in
   "loop" and "end loop".

   The Ada and C forms are not exactly equivalent. In Ada,
   the loop counter "i" automatically inherits the type of N;
   in C, that is the programmer's responsibility. In C, the
   incrementation of "i" might overflow or wrap around,
   causing undefined behaviour or making the loop never
   ending; in Ada, the loop is sure to end at i = N, even
   if i+1 would overflow or wrap around.

While loop

   C:
      while ( condition ) {
         statements
      }

   Ada:
      while condition loop
         statements
      end loop ;

   Same number of tokens in Ada and C, but Ada has 8
   more characters because of the full-length words in
   "loop" and "end loop".

Conditional exit from loop

   C:     if ( condition ) break ;
   Ada:   exit when condition ;

   Ada is shorter by 2 tokens and 1 character.

Switch-case with 2 cases and a default

   C:
      switch ( expr ) {
      case 0 : statements
               break ;
      case 1 : statements
               break ;
      default : statements
      }

   Ada:
      case expr is
      when 0 => statements
      when 1 => statements
      when others => statements
      end case ;

   Ada is shorter by 3 tokens and 2 characters.

Defining a structure/record type

   C:
      typedef struct {
         float x , y , z ;
      } triple_t ;

   Ada:
      type triple_t is record
         x , y , z : float ;
      end record ;

   C 2 tokens and 7 characters shorter, mainly
   because of the full words "record" and "end"
   in the Ada form.

Procedure (void function) declaration

   C:    void foo ( float x , float * y ) ;
   Ada:  procedure foo ( x : float ; y : out float ) ;

   C is 2 tokens (the two colons in the formal parameter
   list) and 9 characters shorter.

   The C and Ada forms are not exactly equivalent, because
   "float * y" in the C form means pass by address,
   while "y : out float" in Ada means no value is passed
   in, and a value is passed out by copy. To make the Ada
   form exactly the same as C, replace the "out" by
   "aliased in out", or define a pointer type float_ptr
   and write "y : in float_ptr".

For this last example, note that a reference to an output parameter,
within a function or procedure, is generally shorter in Ada than in C,
because in C the parameter is a pointer and therefore one must use the
"*" or "->" forms, while in Ada an "out" parameter is not seen as a
pointer and does not need the corresponding ".all" notation, even if the
compiler chooses to pass the parameter by reference.

I could go on, but I believe the conclusion so far is clear: measured by
number of tokens, sometimes the C form is shorter, sometimes the Ada
form is shorter. In this collection of examples, the difference was
largest for the counted loop, where Ada was shorter by 6 tokens.

Measured by number of non-blank characters, C is usually shorter, but
the difference comes from the English keywords in Ada, where C instead
uses special characters. For me, it is faster to type the English
keywords, partly because on my Finnish keyboard the brackets {} require
the Alt Graph key (and a careful glance at the topmost key row to avoid
typing the adjacent () or [] instead).

But, to conclude my argument, IMO the clincher in the verbosity
comparison is the name-space issue. Ignoring comments, most of the text
of a program consists of user-defined identifiers of constants, types,
variables, functions, procedures. Many of these identifiers must be
globally visible, for example the identifiers of the types,
enumerations, and functions/procedures which a client module needs to
see in other to call another module.

Because C lacks a module/namespace construct, in larger C programs one
must usually extend these identifiers with module-specific prefixes to
avoid accidental clashes of identifiers defined in different modules.
For example, the function "display" defined in module "channels" may be
called channels_display, or chan_display, or ch_display, depending on
the degree of abbreviation desired.

Unfortunately, these prefixes must then be used in every occurrence of
the identifier, even within the defining module itself.

In contrast, an identifier "display" defined within an Ada package
"channels" can be used as such within the package itself (and in all its
child packages). Only in other packages is it necessary to write
channels.display, or to open direct visibility to the channels package
by saying "use channels".

This effect should, on average, make identifiers shorter in an Ada
program than in the corresponding C program, assuming equivalent design
standards for naming (for example, abbreviation rules) and a program of
at least medium size.

Another factor that can shorten Ada identifiers is the possibility to
overload function and procedure names (including enumeration literals)
by type, while in C overloading is not possible (in C++ it is, but I am
incompetent to talk about C++).

(A long argument, perhaps, but *my* verbosity was not at issue :-))

> Ada programming encourages the use of user-defined types for all sorts
> of things.  You are not supposed to hold a "day" in an "int" or
> "uint8_t", you are supposed to define "type Day_type is range 1 .. 31;".

That is entirely a matter of convention. It can hardly called a problem
of the Ada language.

> Sometimes this sort of thing can make code clearer, but it can also
> make it harder to see what is really going on in the program.  When you
> see a type like "uint8_t" or "int", you know exactly what it means -
> when the type is "Day_type", you have to think about it much more, and
> perhaps look up the definition. 

This is a good example of the main difference in the concept of "type"
in Ada and in C, or at least an example of how the meaning of "type" is
different for typical programmers in the two languages.

For Ada, and for the typical Ada programmer, the type of an object
describes the meaning of the object in the application world, in the
problem statement.

For C, and for the typical C programmer, the type of an object describes
the internal machine representation of the object.

"uint8_t" describes the machine representation but says nothing of the
logical role or meaning of the value, in the problem and the
application. In C, that is typically the role of the object's
identifier, such as in the declaration

   uint8_t day_in_month;

"Day_type" describes the logical role, but (as such) does not say
anything about the machine representation. This means that the object
identifier can more easily be used to make the role of the particular
object more precise, as in:

   Day_type pay_day;

In fact I believe that C practice is moving towards the Ada use of
types. More and more, C programmers are advised to define type names such as

   typedef uint8_t day_t;

However, the rationale usually given for this advice is to help program
maintenance in case the type must be changed to something else, which is
true but trivial from the conceptual point of view.

Of course, the above does not mean that Ada programmers ignore internal
representation issues, just that the two concerns are separated. If the
Ada programmer wants to say that a Day_type uses 8 bits, she adds a Size
aspect to the type declaration:

   type Day_type is range 1 .. 31 with Size => 8;

> And because type conversions have to be explicit in Ada, you need
> to add lots of them when using these types.

Well, some programmers prefer to avoid automatic conversions.

In Ada, you can control whether conversions are automatic or must be
explicit, by using subtypes in the former case and types in the latter case.

If you declare Day_type not as a type, but as a subtype:

   subtype Day_type is Integer range 1 .. 31;

you are free to write computations that mix Integer and Day_type, you
can assign a Day_type variable to an Integer variable, and can assign an
Integer expression to a Day_type variable (with, in the last case, an
automatic check that the value is in the range 1 .. 31). However, you
can still use Day_type'First and Day_type'Last to ask about the range,
and you can loop over all days by

   for D in Day_type loop ... end loop;

>  C and C++ do more of this automatically, giving clearer code.

The code can be shorter, yes. Whether is is clearer is subjective, of
course.

> The run-time overhead in Ada can be an issue - the larger run-time
> library, the run-time checks, exceptions (I don't like them in C++ either).

Ada compilers these days give you a choice of run-times, from
zero-run-time to the full standard, with the corresponding restrictions
in the Ada code you can execute on that run-time. For the GNAT compiler,
the run-time is treated as a normal library at link-time, so any
run-time function that is not used can be eliminated from the executable.

And *of course* the run-time checks can be turned off globally or
locally, by compiler options or specific pragmas.

Benchmarks vary, but if one writes Ada code that is functionally
equivalent to C code (does not compute with dynamically sized objects,
does not use tasking, does not use exceptions, disables run-time checks,
etc.) one can expect to have close to the same machine code as for the C
code. Note that this does not mean "writing C in Ada", because one still
has all the compile-time goodies of Ada: module system, stronger typing,
object and type attributes, and so on. And the ability to test the
program with run-time checks *on*.

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

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

#18825

On 2014-10-19, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
>
> Counted loop from 1 to N
>
>    C:
>       for ( int i = 1 ; i <= N ; i ++ ) {
>          statements
>       }
>
>    Ada:
>       for i in 1 .. N loop
>          statements
>       end loop ;
>

And in addition, if the goal of the loop is to iterate over the whole
of (say) an array, Ada's 'Range attribute can be used so there's no
need to explicitly list the loop boundaries within the for statement.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

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

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

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

csiph-web