On Fri, 17 Oct 2014 14:13:55 +0200, Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:>On 2014-10-17 Tom Gardner wrote in comp.arch.embedded: >> >> I've forgotten the name for the generic phenomenon that the ignorant >> think they are better than they actually are. If anyone >> can come up with a decent way of allowing people to realise what >> they don't know, then they have probably found a way of making >> themselves very famous, rich, and winning all sorts of prizes. > >Ignorance is Bliss?What is wrong with BLISS ? It was a nice intermediate level language, in which much of VAX/VMS was written.
validity of ... reasons for preferring C over C++
Started by ●October 16, 2014
Reply by ●October 17, 20142014-10-17
Reply by ●October 17, 20142014-10-17
On 14-10-17 12:43 , Arlet Ottens wrote:> On 10/17/2014 11:35 AM, 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.Ada toolchains remain a problem, but things are changing. AdaCore now provides a free (both free-beer and free-speech) ARM Cortex version of the GNU Ada compiler, GNAT. There is also a version for the AVR 8-bitters. The TI MSP430 is also being worked on. No Ada compiler yet (as far as I know) for the 8051 series.> I don't know. I think Ada only helps protect against some superficial > mistakes. It does nothing to prevent someone from using a poor overall > design or conceptual errors that may be much harder to catch.I disagree. The set of problem-modelling tools in Ada is much stronger and more expressive than in C. It is much easier to think and design in problem-domain terms. A real module / package system, integer types defined by what you need and not by the implementation, private and abstract types, classes and inheritance, ... Ada is of course more comparable to C++ than to C, but Ada has none of the inherited "C baggage" that distorts and weakens C++. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .
Reply by ●October 17, 20142014-10-17
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 problemsCare 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 . @ .
Reply by ●October 17, 20142014-10-17
On Fri, 17 Oct 2014 20:12:03 +0300 Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:> On 14-10-17 12:43 , Arlet Ottens wrote: > > On 10/17/2014 11:35 AM, 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. > > Ada toolchains remain a problem, but things are changing. AdaCore now > provides a free (both free-beer and free-speech) ARM Cortex version of > the GNU Ada compiler, GNAT. There is also a version for the AVR > 8-bitters. The TI MSP430 is also being worked on. No Ada compiler yet > (as far as I know) for the 8051 series. > > > I don't know. I think Ada only helps protect against some superficial > > mistakes. It does nothing to prevent someone from using a poor overall > > design or conceptual errors that may be much harder to catch. > > I disagree. The set of problem-modelling tools in Ada is much stronger > and more expressive than in C. It is much easier to think and design in > problem-domain terms. A real module / package system, integer types > defined by what you need and not by the implementation, private and > abstract types, classes and inheritance, ... > > Ada is of course more comparable to C++ than to C, but Ada has none of > the inherited "C baggage" that distorts and weakens C++. > > -- > Niklas Holsti > Tidorum Ltd > niklas holsti tidorum fi > . @ .The last time I even thought about using Ada, I got scared off by the size of the runtime you needed to go with it (tens of KB). Anyone know if that's still the case? -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
Reply by ●October 17, 20142014-10-17
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.
Reply by ●October 17, 20142014-10-17
On Fri, 17 Oct 2014 10:18:21 -0700, Rob Gaddi <rgaddi@technologyhighland.invalid> wrote:>On Fri, 17 Oct 2014 20:12:03 +0300 >Niklas Holsti <niklas.holsti@tidorum.invalid> wrote: > >> On 14-10-17 12:43 , Arlet Ottens wrote: >> > On 10/17/2014 11:35 AM, 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. >> >> Ada toolchains remain a problem, but things are changing. AdaCore now >> provides a free (both free-beer and free-speech) ARM Cortex version of >> the GNU Ada compiler, GNAT. There is also a version for the AVR >> 8-bitters. The TI MSP430 is also being worked on. No Ada compiler yet >> (as far as I know) for the 8051 series. >> >> > I don't know. I think Ada only helps protect against some superficial >> > mistakes. It does nothing to prevent someone from using a poor overall >> > design or conceptual errors that may be much harder to catch. >> >> I disagree. The set of problem-modelling tools in Ada is much stronger >> and more expressive than in C. It is much easier to think and design in >> problem-domain terms. A real module / package system, integer types >> defined by what you need and not by the implementation, private and >> abstract types, classes and inheritance, ... >> >> Ada is of course more comparable to C++ than to C, but Ada has none of >> the inherited "C baggage" that distorts and weakens C++. >> >> -- >> Niklas Holsti >> Tidorum Ltd >> niklas holsti tidorum fi >> . @ . > >The last time I even thought about using Ada, I got scared off by the >size of the runtime you needed to go with it (tens of KB). Anyone know >if that's still the case?How much non-military application has actually been written in any dialect of ADA ? The only one I know of, were some Nokia MPS-10 systems intended for banking in the early 1980's. Some countries, in the addition to the USA, required ADA for their military applications in the same era.
Reply by ●October 17, 20142014-10-17
On 14-10-17 21:53 , upsidedown@downunder.com wrote:> On Fri, 17 Oct 2014 10:18:21 -0700, Rob Gaddi > <rgaddi@technologyhighland.invalid> wrote: > >> On Fri, 17 Oct 2014 20:12:03 +0300 >> Niklas Holsti <niklas.holsti@tidorum.invalid> wrote: >> >>> On 14-10-17 12:43 , Arlet Ottens wrote: >>>> On 10/17/2014 11:35 AM, 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. >>> >>> Ada toolchains remain a problem, but things are changing. AdaCore now >>> provides a free (both free-beer and free-speech) ARM Cortex version of >>> the GNU Ada compiler, GNAT. There is also a version for the AVR >>> 8-bitters. The TI MSP430 is also being worked on. No Ada compiler yet >>> (as far as I know) for the 8051 series. >>> >>>> I don't know. I think Ada only helps protect against some superficial >>>> mistakes. It does nothing to prevent someone from using a poor overall >>>> design or conceptual errors that may be much harder to catch. >>> >>> I disagree. The set of problem-modelling tools in Ada is much stronger >>> and more expressive than in C. It is much easier to think and design in >>> problem-domain terms. A real module / package system, integer types >>> defined by what you need and not by the implementation, private and >>> abstract types, classes and inheritance, ... >>> >>> Ada is of course more comparable to C++ than to C, but Ada has none of >>> the inherited "C baggage" that distorts and weakens C++. >>> >>> -- >>> Niklas Holsti >>> Tidorum Ltd >>> niklas holsti tidorum fi >>> . @ . >> >> The last time I even thought about using Ada, I got scared off by the >> size of the runtime you needed to go with it (tens of KB). Anyone know >> if that's still the case?You can choose to include the parts of the run-time libraries that you want to use. The GNAT compiler has a "zero foot-print" mode where the run-time is empty; of course this means that the application must manage without some Ada features (tasking, mainly). GNAT provides a range of run-times of various sizes and capabilities, and you can configure your own selection too. Same thing applies to C/C++: if you want to use threads/tasks, you must include a kernel of some sort. Is "tens of KB" a lot these days? That said, the main problem with Ada on microcontrollers today is still the limited range of compilers/targets. I haven't tried it, but the common opinion is that porting the gcc-based GNAT, and its run-time system, to new targets is not an easy task, even if gcc already supports the new target. Some people have succeeded to target ARM Cortex, Atmel AVR, and TI MSP430. The run-time systems in these "amateur" ports are still rudimentary, without tasking support, I believe. The AdaCore GPL GNAT for ARM Cortex has a very usable tasking subset (the "Ravenscar" profile).> How much non-military application has actually been written in any > dialect of ADA ?(Pro forma nit-pick: the name of the language is spelled Ada, after Ada Lovelace, http://en.wikipedia.org/wiki/Ada_Lovelace.) Typical uses are airplane control systems (civilian and military), air traffic control systems (mainly civilian), railroad control systems, space applications (civilian and military). I'm told that banking/finance applications exist. More listed at www.adaic.org. Some other resources: Reference manuals at http://www.ada-auth.org/standards/. Free compilers at http://libre.adacore.com/, also available in many Linux distributions (best support in Debian). Also available in the MinGW gcc environment for Windows, http://www.mingw.org/. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .
Reply by ●October 17, 20142014-10-17
Niklas Holsti <niklas.holsti@tidorum.invalid> writes:> That said, the main problem with Ada on microcontrollers today is still > the limited range of compilers/targets. I haven't tried it, but the > common opinion is that porting the gcc-based GNAT, and its run-time > system, to new targets is not an easy task, even if gcc already supports > the new target.I've heard of an Ada to C translator and I've been meaning to look into it. I guess it would be like the early implementations of C++ that translated C++ to C. You'd translate your Ada code and then run it through a C compiler, using C as a portable assembler.
Reply by ●October 17, 20142014-10-17
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.
Reply by ●October 17, 20142014-10-17
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 :)
