2017 Make with Ada competition

[FabienC]

Hi all,

I remember that there was some interest for our competition on the forum last year. So I'm here to tell you that we've started the second edition.

Still 8000 euros in cash prizes but also a bonus student prize this year. And by popular request, it is _not_ limited to ARM Cortex-M

More info on the competition website : makewithada.org

Have fun!

[mubes]

Does GNAT still require GPL for anything linked with its libraries? I'm pretty sure that was the situation last I looked which made the whole Ada thing a bit of a non starter for me....dependable embedded systems in a Pascal-stylee would float my boat, but not if I don't sometimes have the option to keep my sources private.....

I'd love to be told I'm wrong though.

Dave

[Sal Ammoniac]

There seems to be GPL'd versions of their tools, which they specifically say are not for commercial use, and the Pro versions, which require a quote process to get pricing. In past experience, any tools that require a formal quote process tend to be expensive (e.g. in the USD$5000-10000 range).

Paying for tools for commercial use isn't really an issue. What's really the issue here is finding Ada developers. C/C++ developers are plentiful and easy to find, but that's definitely not the case with Ada unless you happen to be located near a lot of defense contractors.

[nctnico]

Paying for tools for commercial use isn't really an issue.

It is because it will take a long time for such tools to pay for themselves for many small companies. The time needed for learning (debugging) will also postpone return on investment. For me the choice between free GCC and $$k Ada is simple: GCC. I'd like to try Ada if it is free for commercial products. I understand the creators want to make money but with their current business model they won't make Ada widespread. There has to be some momentum first and then profit can be made from support and courses. Another option would be to team up with microcontroller manufacturers and get royalties through them. There are several software vendors making money that way while their software is 'free' for users.

[ElektroQuark]

Has Ada any advantage as programming language?

[nctnico]

It is supposed to be less prone to making stupid mistakes like buffer overruns. Think about a gun which won't fire when pointed at your foot.

[FrankBuss]

Nice contest, I always planned to take a look at Spark/Ada, this is a good opportunity for it. How many contest entries were submitted in 2016?

PS: maybe a mod should move this thread to https://www.eevblog.com/forum/contests/

[Mechatrommer]

It is supposed to be less prone to making stupid mistakes like buffer overruns. Think about a gun which won't fire when pointed at your foot.

oh why i keep listening to excuses like this? why cant we practice memory management class/object in other lower level language? you give a safe gun to a dumb he will manage a way to shoot his foot. no wonder applications run much more slower and slower in much more powerful today's processors.

[Sal Ammoniac]

It is supposed to be less prone to making stupid mistakes like buffer overruns. Think about a gun which won't fire when pointed at your foot.

The way I see it, if you have developers who are making these kinds of stupid mistakes, you either need to train them better or get rid of them and replace them with competent people. Only poor craftsmen blame their tools for their own incompetence.

[Vtile]

It is supposed to be less prone to making stupid mistakes like buffer overruns. Think about a gun which won't fire when pointed at your foot.

oh why i keep listening to excuses like this? why cant we practice memory management class/object in other lower level language? you give a safe gun to a dumb he will manage a way to shoot his foot. no wonder applications run much more slower and slower in much more powerful today's processors.

I wouldn't want to have something potentially deadly programmed a languages where a qWERTui and QWERTui  makes a difference in variable etc. names or something like IR2 and lR2 crash the system while hovering somewhere between moon and earth.  Everyone have own favourite language. Ada is just one.

It is just that the system as whole (tools, manpower, training, information etc. etc.) needs to be as error proof as possible, Ada is supposed to work in that idea.

[nctnico]

It is supposed to be less prone to making stupid mistakes like buffer overruns. Think about a gun which won't fire when pointed at your foot.

The way I see it, if you have developers who are making these kinds of stupid mistakes, you either need to train them better or get rid of them and replace them with competent people. Only poor craftsmen blame their tools for their own incompetence.

I disagree with this slightly elitist statement. Tools which are easier to operate get more work done. When programming in C (and to a lesser extend in C++) you have to spend time on avoiding buffer overflows, invalid pointers, etc. If a language doesn't require spending time on stuff like that you can get more done in the same amount of time.

[Sal Ammoniac]

I disagree with this slightly elitist statement. Tools which are easier to operate get more work done. When programming in C (and to a lesser extend in C++) you have to spend time on avoiding buffer overflows, invalid pointers, etc. If a language doesn't require spending time on stuff like that you can get more done in the same amount of time.

Sloppy programming is still sloppy programming no matter what language is used--that's not an elitist statement--it's a professional one. Anyone sloppy enough to introduce buffer overflows, etc., into their C code is likely to just make different kinds of mistakes when using a language that is "easier to operate".

[legacy]

Sloppy programming is still sloppy programming no matter what language is used--that's not an elitist statement--it's a professional one.

What *IF* you, who are not sloppy programmer, have to code/debug/ K of line with a deadline of a few days? (it's a typical scenario in automotive, e.g. FOM, formula one management)

It happens you are under pressure and mistakes happen. ADA helps you.

[legacy]

train them better

train them better with what? C?

ADA is a self good training tool which itself stays on rails.
C needs ... a course which teaches how to stay on rails.

[Sal Ammoniac]

ADA is a self good training tool which itself stays on rails.
C needs ... a course which teaches how to stay on rails.

Two things: 1) I can't parse that statement, and 2) it's Ada, not ADA. It's named after Lady Ada Lovelace and is not an acronym.

[Mechatrommer]

I wouldn't want to have something potentially deadly programmed a languages where a qWERTui and QWERTui  makes a difference in variable etc...

punctuality! if you dont care to look carefully or train yourself to be one at your code, all you think is the easiness of the work done, i believe you train yourself to be deadly.

train them better

train them better with what? C?
ADA is a self good training tool which itself stays on rails.
C needs ... a course which teaches how to stay on rails.

train what in ADA? if its not existence. (non accesible aka encapsulated).

What *IF* you, who are not sloppy programmer, have to code/debug/ K of line with a deadline of a few days? (it's a typical scenario in automotive, e.g. FOM, formula one management)

we make our own custom memory management library at the first sign in for the job and keep using that forever. if we are not capable of doing that, we will not sign in, we find another job. train ourself to constraint to use our own "safe" library because we appreciated what "buffer overrun" is. ADA (higher level programming) intention is good, but at a cost of generating new breed of less skillfull programmers. you may deny it, but just because you cant feel it, or havent experienced it programmers for the money.

here we go again...

[tggzzz]

It is supposed to be less prone to making stupid mistakes like buffer overruns. Think about a gun which won't fire when pointed at your foot.

The way I see it, if you have developers who are making these kinds of stupid mistakes, you either need to train them better or get rid of them and replace them with competent people. Only poor craftsmen blame their tools for their own incompetence.

I disagree with this slightly elitist statement. Tools which are easier to operate get more work done. When programming in C (and to a lesser extend in C++) you have to spend time on avoiding buffer overflows, invalid pointers, etc. If a language doesn't require spending time on stuff like that you can get more done in the same amount of time.

Just so.

I prefer to spend time and mental energy solving "the problem at hand", not solving "the problems with the tools".

The real world has so many fascinating and inherently difficult tasks that need to be solved. Adding unnecessary man-made problems is an unpleasant distraction.

[legacy]

Ada is more like a personal trainer. But typically C-people sees Ada like a 'schoolmistress'. They usually consider themselves *real men* because they can shoot on their own feet. You are not a "real man" if you can't do it. Ain't it? So they believe, so they don't like neither they need the 'schoolmarm Ada', used with reference to a computer language whose name comes from a woman regarded as prim, strict, and brisk in manner.

A personal trainer guides you, teaches you, how to manage your effort to achieve better results.

Personally I have a job in avionics, sometimes I do staff in automotive/FOM, And I found Ada more than useful, especially when I am under pressure, or when I am in rush.

Ada is a mervelous language, which inspires vhdl, so I also feel comfortable when I have to develop HDL on fpgas

train what in ADA? if it's not existence. (non accessible aka encapsulated).

Not existence? Dude, in avionics we have green hills Ada. So we have in automotive/FOM.
You probably mean GNAT is not well supported, especially for embedded stuff. Sadly the truth.

But! That happens because of the attitude of C-people who see the 'schoolmarm Ada' as a limit for their freedom (which consists on the chance of bullet-shooting on their own feet), instead of seeing the personal trainer who can motivate them to write better code.

On computer science the feeling is ..  we still have to talk about 'guns, and bullets', because real men MUST be 'cowboys on the console'. Ain't it? Being a wild with two guns on the belt is a bonus. So, use C and C++, two guns, you can double the chance to shoot on your own feet!

This kind of evolution, which is itself embedded in linux (mr Linus Torvalds hates the C++ language, but his code looks objects made in C .. full of bugs), and GNU (they don't know how to program in C, their code is ... full of "patch"). The common context which makes C-people to dislike(hate?) Ada.

This way we have grown up ... 

[FabienC]

On top of what has been said so far, I want to add that  Ada is not only good to prevent you from shooting your foot, It's also great to find out why you shoot yourself in the foot (it will happen, there's no miracles ).

One instance of that is the contract based programming in Ada. In a project I'm working on, we have a bunch of hardware to initialize before being able to use it, business as usual...
In Ada, the interface looks like this:

Code: [Select]

package Motor_Driver is

   procedure Initialize;
   --  Initializes the hardware

   function Initialized return Boolean;
   --  Return True is the hardware is intialized

   procedure  Turn_On_Motor
     with Pre => Initialized;
   --  Turn on the motor with a precondition that hardware should be initialized
end Motor_Driver;

The result is that I will get an error if I try to use my motor before the hardware is initialized. It's simple things like this that can save you several minutes of debugging, over the course of a project it will save you hours.

I don't know if I shared those links before, here are two articles where we discuss Ada features in the context of embedded software:

https://community.arm.com/iot/embedded/b/embedded-blog/posts/ada-driver-library-for-arm-cortex-m-r---part-1-2
https://community.arm.com/iot/embedded/b/embedded-blog/posts/ada-driver-library-for-arm-cortex-m-r---part-2-2

[Sal Ammoniac]

On top of what has been said so far, I want to add that  Ada is not only good to prevent you from shooting your foot, It's also great to find out why you shoot yourself in the foot (it will happen, there's no miracles

Ada may be the best and safest language in the universe, but its uptake is going to continue to be nonexistent unless something is done to get it into the mainstream.

What the company sponsoring this contest should do is partner with IAR and Keil to get their compiler into the IAR Embedded Workbench and Keil ?Vision products. Give it the same level of support in these tools as C has at no additional cost. These are the mainstream tools that professionals use to develop embedded software and if they supported development in Ada that would go a long way to making it relevant to the average embedded developer.

Keep it as a niche product, like it is now, and it'll never have more than a tiny audience in the non-defense world.

[Mechatrommer]

But typically C-people sees Ada like a 'schoolmistress'. They usually consider themselves *real men* because they can shoot on their own feet...
But! That happens because of the attitude of C-people who see the 'schoolmarm Ada' as a limit for their freedom (which consists on the chance of bullet-shooting on their own feet)

no. that happened only because higher level language (Ada is one of it) programmers consider themselves as real men because they cant shoot on their foot. by stating excuses such as...

making stupid mistakes like buffer overruns. Think about a gun which won't fire when pointed at your foot.

like buffer overrun cannot be circumvented in lower level languagge programming. there are many issues why a mistake happened, blaming on the tool alone is not a wise thing to do imho.. i can say, most reported buffer overrun issues are few minority cases only compared to many softwares developed, and i suspect its more to do with unhealthy programming style rather than the programming tool itself. you can come up with the excuse if you have statistics such as out of millions Ada softwares developed, 0% bug. there is no OSS or free Ada utilities for public out there afaik, so no wonder there is zero error report. as i said, you give a dumb an intelligent gun, he will manage to find a way to shoot his foot, just wait until too many people using it.

if we want to play idiomatic expression, think about when a crocodile bite your foot, you'll need a gun that can be pointed to the foot and shoot. in the situation, i dont want a gun that decides through its infinite wisdom. making one small hole in the foot is a lot better than losing the entire foot.

train what in ADA? if it's not existence. (non accessible aka encapsulated).

Not existence? Dude, in avionics we have green hills Ada. So we have in automotive/FOM.
You probably mean GNAT is not well supported, especially for embedded stuff. Sadly the truth.

i was refering to how do you train people to access memory directly with safety but at the same time make full use of the speed (least amount of fault checking). how do you train them if its not accesible? (direct memory access). higher level language boundary check comes at a price of degraded memory access speed by boundary check on every access call. if you argue the time difference is negligible, then you have not making a software that complex enough. ymmv.

[FrankBuss]

Ada may be the best and safest language in the universe

I'm not sure about this. I'm trying to learn it now and looks like it is the same mess as with C/C++ for some things. E.g. the integer type is implementation dependent. Can be 32 bit, but can have other sizes as well. This doesn't inspire confidence in the language and doesn't help to write portable and safe software. Compare this to Java or C#: no matter what compiler you use, a given program runs always exactly the same on any CPU and with any compiler.

[Mechatrommer]

https://community.arm.com/iot/embedded/b/embedded-blog/posts/ada-driver-library-for-arm-cortex-m-r---part-1-2
https://community.arm.com/iot/embedded/b/embedded-blog/posts/ada-driver-library-for-arm-cortex-m-r---part-2-2

[tggzzz]

Ada may be the best and safest language in the universe

I'm not sure about this. I'm trying to learn it now and looks like it is the same mess as with C/C++ for some things. E.g. the integer type is implementation dependent. Can be 32 bit, but can have other sizes as well. This doesn't inspire confidence in the language and doesn't help to write portable and safe software. Compare this to Java or C#: no matter what compiler you use, a given program runs always exactly the same on any CPU and with any compiler.

The most frequent and destructive problems rarely involve the number of bits in an integer - except in the all-too-common case where people assume it relates to the number of bits in pointers

The magnitude of numbers that need to be represented depends on the problem and hence can and should be part of the problem specification and/or top-level architectural design. That is true for whichever language is used to implement a solution - Ada, C, Forth, Java, xC, Pascal (OK probably not Smalltalk, since it silently flips to BigIntegers whenever overflow occurs )

[tggzzz]

... like buffer overrun cannot be circumvented in lower level languagge programming. there are many issues why a mistake happened, blaming on the tool alone is not a wise thing to do imho..

There's some validity to that, but only some.

Engineers should use the tools that will give the best results for the job at hand, not merely some that they are already familiar with.

If you want dubious analogies, then

• you can use a cycle to cross the Alps - but in most cases it would be better to use a car
• you can use a hammer to insert screws, but it is better to use a screwdriver
• you can use C when designing hardware, but usually it is better to use an HDL such as Verilog or VHDL

C is too often used for insufficient reasons, e.g. "I'm familiar with it" and "I'm a better than average programmer".

[FrankBuss]

The magnitude of numbers that need to be represented depends on the problem and hence can and should be part of the problem specification and/or top-level architectural design. That is true for whichever language is used to implement a solution - Ada, C, Forth, Java, xC, Pascal (OK probably not Smalltalk, since it silently flips to BigIntegers whenever overflow occurs )

Right, and this is the reason I use int32_t etc. in C, except for simple things like small loop index variables. But the fact that it is possible at all that a program behaviour can change if you use a different compiler, is not a good language design decision in my opinion. I know they did this for efficiency reasons, because if you have 32 bit registers, then it is faster to have 32 bit integers as well, but this doesn't matter anymore nowadays. Would be better the other way around: if the programmer writes a program for an architecture with a CPU with 16 bit registers, the programmer could use 16 bit types, but integer should still be 32 bit. I guess it is no problem with the new generics feature of Ada to use the type you want in libraries as well, depending on your target.

[tggzzz]

The magnitude of numbers that need to be represented depends on the problem and hence can and should be part of the problem specification and/or top-level architectural design. That is true for whichever language is used to implement a solution - Ada, C, Forth, Java, xC, Pascal (OK probably not Smalltalk, since it silently flips to BigIntegers whenever overflow occurs )

Right, and this is the reason I use int32_t etc. in C, except for simple things like small loop index variables. But the fact that it is possible at all that a program behaviour can change if you use a different compiler, is not a good language design decision in my opinion. ....

I can tolerate different behaviour with differing int lengths with differing compilers; if the length is relevant then, as you do, you need to specify the size. I like uint_fast_8 and similar, since it allows me to specify both minimum required behaviour plus preferred attributes.

I can't tolerate it where changing the optimisation level changes the behaviour (other than time/space); that indicates a serious problem with the tool.

I can't tolerate it where changing from one version of one compiler to another version of the same compiler changes the behaviour (other than time/space); that indicates a serious problem with the tool.

[Mechatrommer]

Engineers should use the tools that will give the best results for the job at hand, not merely some that they are already familiar with.

agree. but i guess it comes down to using the right tool for the job... and the one tool that an engineer already familiar with usually will give the best result for him, and other engineers have their own familiarity to different tools that give the best to them.

C is too often used for insufficient reasons, e.g. "I'm familiar with it" and "I'm a better than average programmer".

not necessarily. some reasons are better/faster access to memory, resource limited friendly, support for many time saving coding and operation logic, such as generic data type function/class (template), operator overloading etc.. the shortest language to type in, we dont want to be bothered with "package body MyProc is", alot of unnecessary ":" and ";" "begin" "end FuncName" etc that supposed to be human readable but not so. longer language, by my dictionary will make software development time even longer, i'm guessing refactoring job will be a nightmare in Ada. afaics, Ada, like pascal, java etc are fucked/mixed up language between readability and some technical linguistic syntaxes. as of the best readable language i know is Basic, and the most technical (short albeit some says cryptics) language is C/C++, the rest are mixed up between the 2. if i want to pick high level language, it will be the Basic but sadly its dying, and nobody want to further expand it esp in embedded system, granted it sucks when it comes to OOP, but the best human readable language.

[legacy]

I believe the best way to appreciate Ada is finding a job in avionics, so you see where and why Ada helps.

how do you train them if its not accesible? (direct memory access). higher level language boundary check comes at a price of degraded memory access speed by boundary check on every access call. .

Ada is not only a pure language, it's a process with a *mind approach*. We have sections called "unsafe". These sections require special handling when you manage them, and they propagate constraints to the whole project. If a constraints is not respected, Ada doesn't compile!

You can have low level sections in Ada, which directly access memory without any check, but you must define it as "unsafe", therefore the module propagate the information to the builder which is now aware of  it as well as everybody, including those who are in the testing team. Everybody are aware it's a weakness! You must define modules through interfaces! And it's a must! C doesn't care about it, it's so wild that you can just use cpp to includes headers file, and who cares? When you access a module define "unsafe" in Ada there are a lot of checks at compile time.

These tricks help to catch mistakes, especially during the "system integration" process, when sources from different teams are merged together!

You can also ask the compiler to inject testing modules into the "unsafe" module, this helps during the testing activity, as the module is "unsafe" it MUST be tested more carefully, and then approved, and since it's interface is also "unsafe" then there are restrictions in the usage.

Ada, in first place, teaches you how you have to organize your work! Ada is fab team working process because it teaches how people has to manage the "source life cycle", from the prototype, to the testing, to the production, when you can progressively remove construction constraints.

C is a wild language, full of #ifdef branches, you can put assembly inline in the middle of a C file, and nobody cares. C requires external tools like "Code Purify" (shitty tool) which injects a lot of shit in order to provide a limited "unit test" capability. C doesn't care on what you do when you pass information between two modules, and doesn't suggest neither helps you to design test-modules.

Ada cares on boundaries at compile time, or at run time if you can allow it. It helps to assure "you are not out by one" when you implement a loop which needs to use an index to point to an array.

And all of these are native features! You don't need any shitty external tool.

Ada requires *fifty times* the effort you need to learn a wild language like C, but once learned it shows how C requires *ten times* the effort you need with Ada to achieve the same purpose!

At the end, it's a gain 

[Mechatrommer]

I believe the best way to appreciate Ada is finding a job in avionics, so you see where and why Ada helps...  They help to catch mistakes, especially during the "system integration" process, when sources from different teams are merged together!...  C requires ten times the effort you need with Ada to do the achieve the same purpose!

then i guess in Avionics the place it deserves to be. Ada is not a new name to me, unlike java, i've heard it since the beginning its just i have no chance at experiencing it due to inaccessible IDE. but it failure to even listed in top 10 rank after many decades shows something is not right. if its really that good an effort should be made to make aware to the community esp universities and new learners. just to be fair, they must learn all the languages and free to pick what they like. survival of the fittest. as for java, the not so far syntax from C/C++, i believe its winning because of it "cross platform" feature in mind with its JRE engines for many platforms/machines provided by the language IDE developer (Sun Microsystems), hence productivity, demand and the poll of money is there, as speculations and prospects helped it to jump high. it seems the "programmers aided compiler" as you've described has not won much place in the heart of paid/unpaid programmers. now back to topic, i have no objection to the contest, i even hope we can come up with something positive out of it. its just that from time to time we heard people chiming in with inadequate excuses just as if this is the holy spirit and others should be rendered in obsoletion. but no, with the "lack of feature", "doesnt care" compiler of the unsafe C/C++, it still stands at #2 after java all this while. Ada group has a long way to go... wish them luck.

[tggzzz]

C is too often used for insufficient reasons, e.g. "I'm familiar with it" and "I'm a better than average programmer".

not necessarily. some reasons are better/faster access to memory, resource limited friendly, support for many time saving coding and operation logic, such as generic data type function/class (template), operator overloading etc.. the shortest language to type in, we dont want to be bothered with "package body MyProc is", alot of unnecessary ":" and ";" "begin" "end FuncName" etc that supposed to be human readable but not so. longer language, by my dictionary will make software development time even longer, i'm guessing refactoring job will be a nightmare in Ada. afaics, Ada, like pascal, java etc are fucked/mixed up language between readability and some technical linguistic syntaxes. as of the best readable language i know is Basic, and the most technical (short albeit some says cryptics) language is C/C++, the rest are mixed up between the 2. if i want to pick high level language, it will be the Basic but sadly its dying, and nobody want to further expand it esp in embedded system, granted it sucks when it comes to OOP, but the best human readable language.

And from that we can accurately assess your skillset and the types of development and programs you have written.

You can only have been working on very small and simple tasks, and/or have had the task explained to you in detail before you begin. Why? Because in larger, more complex and more challenging jobs typing occupies a miniscule proportion of design time. Much much more is spent on finding out and understanding what needs to be done, and then testing to see that you have done it.

You cannot have used a modern strongly typed language for anything more than toy examples. Why? Because if you had you would realise that C/C++ actively prevents complex fast and accurate refactoring. If you understood what's involved in C/C++ compilation, you would know why that has to be the case. You would also realise that you get the IDE to do most of the typing for you; "control-space" is a wonderful key!

Your prejudices opinions are based in ignorance.

If you had ever had to do a difficult task where it seriously mattered (i.e. lawyers, lawsuits, certifications) that you got correct results, you would be very concerned about using C.

[Sal Ammoniac]

Because if you had you would realise that C/C++ actively prevents complex fast and accurate refactoring.

How do you figure this? I do it all the time.

[Sal Ammoniac]

C is too often used for insufficient reasons, e.g. "I'm familiar with it" and "I'm a better than average programmer".

The primary reason we use C (and C++) is tools support. Most of these other languages (Ada, Rust, etc.) have minimal tools support. Typically just command-line tools. Debugging capabilities are usually limited too.

I'd be more likely to consider one of these languages for production work if they had first class support in IAR or Keil.

[GeorgeOfTheJungle]

C is too often used for insufficient reasons, e.g. "I'm familiar with it" and "I'm a better than average programmer"

Or "I have low level stuff to do and don't want to have deal with 20 unnecessary layers of abstraction, thank you very much"

[tggzzz]

C is too often used for insufficient reasons, e.g. "I'm familiar with it" and "I'm a better than average programmer".

The primary reason we use C (and C++) is tools support. Most of these other languages (Ada, Rust, etc.) have minimal tools support. Typically just command-line tools. Debugging capabilities are usually limited too.

I'd be more likely to consider one of these languages for production work if they had first class support in IAR or Keil.

Tool support and good libraries are very important - and lack of them is an entry barrier for new languages. However, for embedded programming and established languages, those are less of a barrier.

It does mean that a new language has to offer significant advantages over C, and most don't. I've used that as a reason to not bother to use many "fashionable" languages.

[tggzzz]

C is too often used for insufficient reasons, e.g. "I'm familiar with it" and "I'm a better than average programmer"

Or "I have low level stuff to do and don't want to have deal with 20 unnecessary layers of abstraction, thank you very much"

Abstraction can both obscure and enable; getting the right balance is vital. Many languages fail (e.g. C++), but not all languages.

In particular, for embedded languages like Ada and xC can be excellent.

(xC is effectively Occam with FPGA-like IO capabilities, e.g. specify a 32-bit serialised output starts on a specific clock cycle, or wait until either input arrives or a timeout happens, and then proceed with a 10ns latency also noting the clock cycle when the input occurred.)

[Mechatrommer]

You can only have been working on very small and simple tasks, and/or have had the task explained to you in detail before you begin. Why? Because in larger, more complex and more challenging jobs typing occupies a miniscule proportion of design time. Much much more is spent on finding out and understanding what needs to be done, and then testing to see that you have done it.

well... its very complex, not much typing to do, and you dont know what to do in advance.. and lawyer is ready to bust your arse, and its very complex.... well, its very fascinating and self explanatory...  more like management BS to me... i'm sorry for your bad experience on certain brand name inconsistent compiler/tool behaviour.

[tggzzz]

You can only have been working on very small and simple tasks, and/or have had the task explained to you in detail before you begin. Why? Because in larger, more complex and more challenging jobs typing occupies a miniscule proportion of design time. Much much more is spent on finding out and understanding what needs to be done, and then testing to see that you have done it.

well... its very complex, not much typing to do, and you dont know what to do in advance.. and lawyer is ready to bust your arse, and its very complex.... well, its very fascinating and self explanatory...  more like management BS to me... i'm sorry for your bad experience on certain brand name inconsistent compiler/tool behaviour.

I really don't know what you are talking about.

You have no idea of my experience and background, but to give you a taste...

It does concentrate your mind if your code can kill someone even if it behaves correctly according to specification.
Alternatively, how about developing products where, if you make a mistake, you only find out 3 months later and a re-spin costs 8 times your annual salary.
And finally, working in an environment where the first task is to find out what you want to do, and then find a way of doing it. After that, doing it is trivially easy!

[Mechatrommer]

It does concentrate your mind if your code can kill someone even if it behaves correctly according to specification.

take it easy mate, dont put too much pressure on yourself. you can get the safest car in the world and still can kill somebody.

Alternatively, how about developing products where, if you make a mistake, you only find out 3 months later and a re-spin costs 8 times your annual salary.

thats why you dont make sloppy code, lousy test set etc. if what you are trying to say is that a great tool will not make you kill somebody by just pressing a "integrity test" button and then laying about while it finish testing, then i'm still not buying it. if you can afford to pay the tool, then why not, but dont impose it on everybody else.

And finally, working in an environment where the first task is to find out what you want to do, and then find a way of doing it. After that, doing it is trivially easy!

thats call finding out customers/users need or interest or market/niche prospects, and then proceed with engineering processes decision. after that really doing it (on the decided methodology) because we are specialized in the field. its a normal workflow, but we are talking about the last part in this very thread, the first 2 parts is out of topic.

[tggzzz]

I will remind you, and anyone else, that your comments have omitted your context, in which you believe that having a more verbose language makes development much slower. It has been pointed out to you that typing time is a trivial part of development for interesting non-trivial purposes.

However, you still persist in thinking...

It does concentrate your mind if your code can kill someone even if it behaves correctly according to specification.

take it easy mate, dont put too much pressure on yourself. you can get the safest car in the world and still can kill somebody.

And your point is?

Alternatively, how about developing products where, if you make a mistake, you only find out 3 months later and a re-spin costs 8 times your annual salary.

thats why you dont make sloppy code, lousy test set etc. if what you are trying to say is that a great tool will not make you kill somebody by just pressing a "integrity test" button and then laying about while it finish testing, then i'm still not buying it. if you can afford to pay the tool, then why not, but dont impose it on everybody else.

No, it is about using the right tool for a job, and that a tiny amount of extra typing is trivial - and probably beneficial.

And finally, working in an environment where the first task is to find out what you want to do, and then find a way of doing it. After that, doing it is trivially easy!

thats call finding out customers/users need or interest or market/niche prospects, and then proceed with engineering processes decision. after that really doing it (on the decided methodology) because we are specialized in the field. its a normal workflow, but we are talking about the last part in this very thread, the first 2 parts is out of topic.

No. It is called research into concepts/products that do not yet exist, so there are no customers you can go and ask!

As I said, you comments are revealing about your background.

[Mechatrommer]

I will remind you, and anyone else, that your comments have omitted your context, in which you believe that having a more verbose language makes development much slower. It has been pointed out to you that typing time is a trivial part of development for interesting non-trivial purposes.

correct. and you wander off topic even further that has nothing to do with coding...

No. It is called research into concepts/products that do not yet exist, so there are no customers you can go and ask!

oh invention? i hope you are not doomed to failure on most projects you ventured.

As I said, you comments are revealing about your background.

and you assume what that is?

[legacy]

The primary reason we use C (and C++) is tools support. Most of these other languages (Ada, Rust, etc.) have minimal tools support.

Green hills Adamulti supports ADA and comes with a full debugger support.
It costs money, that's another reason why I said "find a job in avionics if you want experiment Ada".
They have money, they buy professional tools.

[legacy]

then i guess in Avionics the place it deserves to be.

eh, it's sad, but it's the sadly the Truth. I have never seen Ada in other job-areas. We introduced Ada in Automotive/FOM, but it's not at the same professional level. I believe due to the cost factor 

[legacy]

If you had ever had to do a difficult task where it seriously mattered (i.e. lawyers, lawsuits, certifications) that you got correct results, you would be very concerned about using C.

Exactly the point!

[tggzzz]

Because if you had you would realise that C/C++ actively prevents complex fast and accurate refactoring.

How do you figure this? I do it all the time.

Consider the effects of #defines
Consider the consequences of templates being a a Turing-complete language in their own right.
Consider why it takes so long to compile C++ from scratch.

[JPortici]

The primary reason we use C (and C++) is tools support. Most of these other languages (Ada, Rust, etc.) have minimal tools support.

Green hills Adamulti supports ADA and comes with a full debugger support.
It costs money, that's another reason why I said "find a job in avionics if you want experiment Ada".
They have money, they buy professional tools.

wouldn't you rephrase that as "they have a lot of money, they can buy pricey tools"?
after all, given a skilled programmer you could write secure C code, i think.

Imagine you are a smaller business, still in those segments (automotive-aftermarket for example). what would you rather do, spend the money on specialist tools and a programmer that will be asking a lot because it's kind of a niche language or pay a good C programmer that can achieve the same result... but costing way less because they are a dime a dozen and you have free (or at least cheap in comparison) developement tools?
 
(no, i'm not that experienced. no, i never had to work in situations where lawyers and others people's lives are at stake. i'm just using myexperience, albeit limited, and my common sense. please, tell me if i'm missing something)

[tggzzz]

The primary reason we use C (and C++) is tools support. Most of these other languages (Ada, Rust, etc.) have minimal tools support.

Green hills Adamulti supports ADA and comes with a full debugger support.
It costs money, that's another reason why I said "find a job in avionics if you want experiment Ada".
They have money, they buy professional tools.

wouldn't you rephrase that as "they have a lot of money, they can buy pricey tools"?
after all, given a skilled programmer you could write secure C code, i think.

Imagine you are a smaller business, still in those segments (automotive-aftermarket for example). what would you rather do, spend the money on specialist tools and a programmer that will be asking a lot because it's kind of a niche language or pay a good C programmer that can achieve the same result... but costing way less because they are a dime a dozen and you have free (or at least cheap in comparison) developement tools?
 
(no, i'm not that experienced. no, i never had to work in situations where lawyers and others people's lives are at stake. i'm just using myexperience, albeit limited, and my common sense. please, tell me if i'm missing something)

You are missing several things.

Demonstrably skilled programmers do continually make many mistakes with C/C++.
Those with significant experience of both C and Ada usually claim Ada gives better results where it is used.
You have to compare the cost of the tools with the employment costs of the engineers (typically 2*salary).
You have to compare the cost of the tools with the cost of making a mistake that would have been avoided if the tools had been used.
The cost to you is irrelevant
You have ignored the difficulty of proving (e.g. to a judge/jury) that you have taken all necessary steps. Common sense is irrelevant in that context.

[NorthGuy]

Common sense is irrelevant in that context.

Common sense is always relevant. Cogito ergo sum.

People are crazy about safety. They invented safe programming languages and used them to create the most overbloated and dysfunctional software that ever existed. You think looking at the results would give them a clue that something is wrong with the approach. Not in a slightest. They want yet better, that is yet safer languages.

What I value in the language is freedom - ability to do what I want with it. If, instead, it stands in my way, I will try to avoid it a all costs. Language safety is of no concern to me. If I do something stupid such as going over array boundaries, so be it. I know I'm going to make mistakes, and there's nothing wrong with this. I can test, and I can fix. Does such approach makes development slower? I don't think so. More freedom means simpler and less bloated programs. Simpler programs take less development time. Also, they are likely to have less bug.

I know what makes my development slower. It's reading Internet forums instead of working. But there's a difference between knowing the path and walking the path 

[JPortici]

You are missing several things.

I am aware i am, that's why i asked

Demonstrably skilled programmers do continually make many mistakes with C/C++.

after all, humans make mistakes

Those with significant experience of both C and Ada usually claim Ada gives better results where it is used.

You have to compare the cost of the tools with the employment costs of the engineers (typically 2*salary).

but i would expect that since that's a more niche language tool that costs a lot for a small business, the salary for somebody that know it well would be that higher as well. bottom line, can smaller businesses in less critical areas afford the price of both tools and man power?
I assume that the goal of this competition is to increase adoption or at least make developers curious about it. Okay, where is the free compiler and debugger for my platform of choice? I am fine with some limitations so i can at least check it out
 

You have to compare the cost of the tools with the cost of making a mistake that would have been avoided if the tools had been used.
The cost to you is irrelevant
You have ignored the difficulty of proving (e.g. to a judge/jury) that you have taken all necessary steps. Common sense is irrelevant in that context.

Very true, one buy insurance before the accident. about common sense, i think that the jury's/judge common sense is very relevant, more than actual proofs, sadly

This is only my opinion, of course

[tggzzz]

You are missing several things.

I am aware i am, that's why i asked

Demonstrably skilled programmers do continually make many mistakes with C/C++.

after all, humans make mistakes

Those with significant experience of both C and Ada usually claim Ada gives better results where it is used.

You have to compare the cost of the tools with the employment costs of the engineers (typically 2*salary).

but i would expect that since that's a more niche language tool that costs a lot for a small business, the salary for somebody that know it well would be that higher as well. bottom line, can smaller businesses in less critical areas afford the price of both tools and man power?
I assume that the goal of this competition is to increase adoption or at least make developers curious about it. Okay, where is the free compiler and debugger for my platform of choice? I am fine with some limitations so i can at least check it out
 

You have to compare the cost of the tools with the cost of making a mistake that would have been avoided if the tools had been used.
The cost to you is irrelevant
You have ignored the difficulty of proving (e.g. to a judge/jury) that you have taken all necessary steps. Common sense is irrelevant in that context.

Very true, one buy insurance before the accident. about common sense, i think that the jury's/judge common sense is very relevant, more than actual proofs, sadly

This is only my opinion, of course

I hope your placement of brackets in your programs is less error-prone than your placement of "quote" tags above! (One of the lines that you appear to write was in fact written by me).

Knowing that humans make mistakes is a reason for preferring languages that help detect and avoid some important classes of mistake.

Having free compilers/tools is very helpful, but is not sufficient. Industry inertia should never be underestimated.

General principle about insurance: on average you pay more for insurance than you get back from insurance. With that in mind...
I've never heard of any insurance for being late to market or developing poor quality products.
I suspect that buying insurance for a useful amount of product liability would be very expensive.

[tggzzz]

Common sense is irrelevant in that context.

Common sense is always relevant. Cogito ergo sum.

It is necessary, but not sufficient. Besides, common sense isn't common.

People are crazy about safety. They invented safe programming languages and used them to create the most overbloated and dysfunctional software that ever existed. You think looking at the results would give them a clue that something is wrong with the approach. Not in a slightest. They want yet better, that is yet safer languages.

I hope you can express your intent better in a programming language than you can in English.

What I value in the language is freedom - ability to do what I want with it. If, instead, it stands in my way, I will try to avoid it a all costs. Language safety is of no concern to me. If I do something stupid such as going over array boundaries, so be it. I know I'm going to make mistakes, and there's nothing wrong with this. I can test, and I can fix. Does such approach makes development slower? I don't think so.

Professionals know that "you can't test quality into a product". Developers are notoriously bad at finding bugs in their own code.

W.r.t. development speed, you really ought to think it makes the process slower overall. Start with reading any of the standard books such as Brooks' "The Mythical Man Month", or McConnell's "Rapid Development"

More freedom means simpler and less bloated programs. Simpler programs take less development time. Also, they are likely to have less bug.

The last two sentences are correct, if somewhat ungrammatical. The first sentence is gibberish.

[Mechatrommer]

maybe someone should persuade Dave to program this forum in Ada, to avoid stupid mistakes like misquotes and ungrammatical semantics. this is life threatening forum, brain doesnt count 

[nctnico]

People are crazy about safety. They invented safe programming languages and used them to create the most overbloated and dysfunctional software that ever existed. You think looking at the results would give them a clue that something is wrong with the approach. Not in a slightest. They want yet better, that is yet safer languages.

IMHO you have to distinguish between two use cases for a safe programming language:
1) Use by programmers who can't program so the program doesn't work but at least it doesn't crash all the time.
2) Use by programmers who can program and like to concentrate on the task at hand instead of babysitting a programming language.

[tggzzz]

People are crazy about safety. They invented safe programming languages and used them to create the most overbloated and dysfunctional software that ever existed. You think looking at the results would give them a clue that something is wrong with the approach. Not in a slightest. They want yet better, that is yet safer languages.

IMHO you have to distinguish between two use cases for a safe programming language:
1) Use by programmers who can't program so the program doesn't work but at least it doesn't crash all the time.
2) Use by programmers who can program and like to concentrate on the task at hand instead of babysitting a programming language.

Nicely put.

Alternatively, "if C++ is the answer, just what was the question?".

[Mechatrommer]

IMHO you have to distinguish between two use cases for a safe programming language:
1) Use by programmers who can't program so the program doesn't work but at least it doesn't crash all the time.
2) Use by programmers who can program and like to concentrate on the task at hand instead of babysitting a programming language.

you have to distinguish between a "language" and "features that come with the compiler". language is one thing, compiler is another thing. since this thread is more toward a "language" (Ada), we should be concentrating on that, not what feature a compiler can provide. features a compiler from Borland will be different from what a Microsoft's compiler can provide. external tools is another whole different story. i will agree with you and the clan if this thread is talking about..... "Competition using Robust Ada Compiler from AdaCore". i'm not sure how many Ada compiler out there, GNAT is one of it? but if Ada is like C/C++ with many compiler manufaturers/vendors, i bet there will a whole bunch of inconsistencies and level of securities among them.

[JPortici]

You are missing several things.

I am aware i am, that's why i asked

Demonstrably skilled programmers do continually make many mistakes with C/C++.

after all, humans make mistakes

Those with significant experience of both C and Ada usually claim Ada gives better results where it is used.

You have to compare the cost of the tools with the employment costs of the engineers (typically 2*salary).

but i would expect that since that's a more niche language tool that costs a lot for a small business, the salary for somebody that know it well would be that higher as well. bottom line, can smaller businesses in less critical areas afford the price of both tools and man power?
I assume that the goal of this competition is to increase adoption or at least make developers curious about it. Okay, where is the free compiler and debugger for my platform of choice? I am fine with some limitations so i can at least check it out
 

You have to compare the cost of the tools with the cost of making a mistake that would have been avoided if the tools had been used.
The cost to you is irrelevant
You have ignored the difficulty of proving (e.g. to a judge/jury) that you have taken all necessary steps. Common sense is irrelevant in that context.

Very true, one buy insurance before the accident. about common sense, i think that the jury's/judge common sense is very relevant, more than actual proofs, sadly

This is only my opinion, of course

I hope your placement of brackets in your programs is less error-prone than your placement of "quote" tags above! (One of the lines that you appear to write was in fact written by me).

Knowing that humans make mistakes is a reason for preferring languages that help detect and avoid some important classes of mistake.

Having free compilers/tools is very helpful, but is not sufficient. Industry inertia should never be underestimated.

General principle about insurance: on average you pay more for insurance than you get back from insurance. With that in mind...
I've never heard of any insurance for being late to market or developing poor quality products.
I suspect that buying insurance for a useful amount of product liability would be very expensive.

Yeeeeeah, i get your point. i guess i would have spotted that mistake in a forum with a WYSIWYG post editor, but i'd rather just make an error and then correct it. Nobody was harmed for this error, do you get mine?

I am not saying you all are wrong, not at all. What i'm trying to say is that i can't see how the benefits are more that the cost in my line of work. I like to learn from my mistakes and my mistakes shouldn't put people's life in danger, hopefully.
I am sure i will change my mind in the future, when i will be more eperienced... or when needed. But if i can use C, i'll use C.

Lack of experience? Probably. I won't deny it. After all, i have been earning money from programming microcontrollers for just a few years (i'm 25)
But the i-know-better attitude is not helping getting your message across

Lazyness? That plays a big role: if i can use C i will use C. I will be extra careful, no problem for me. I don't have tight development cycles nor have to work on safety critical applicatons, thank god.

But at the end of the day is lack of free and ready made tools that is stopping me or someone like me (i think) from adopting new languages.
Is there an ada compiler for dspic? AFAIK, no. And i use them extensively.
It is true that one shouldn't understimate industry inertia, but smaller players can also be more dynamic (less numbers on products and quantities, less people, less inertia from within the workplace itself) but for those places a multi thousand euro investment can't be taken lightly. That is my current situation. I can/am proposing new platforms in both software and hardware at where i work but the investment has to be justified. Having free tools for the platforms i have to use, at least for training, would have me learning these platforms.

I see your point. Do you see mine?

Again, it is all my opinion.

[legacy]

Professionals know that "you can't test quality into a product". Developers are notoriously bad at finding bugs in their own code.

Exactly!

[JPortici]

pay a good C programmer that can achieve the same result

No, that is the point: there job-area (like avionics) where C-programmers don't achieve the same result if you have to consider the task in the life-cycle window.

again: i thought that the point of all of this (2017 make with ada competition) was to increase adoption of ada from OUTSIDE those job-areas

i am NOT arguing about it's purposes and merits in those job areas, of which i know nothing about

[NorthGuy]

I hope you can express your intent better in a programming language than you can in English.

If you don't understand something, just ask. I'll explain. If you want to discuss grammatical errors, point specifically to them. I'll learn and hopefully my English will be better and more understandable next time.

Professionals know that "you can't test quality into a product". Developers are notoriously bad at finding bugs in their own code.

I didn't suggest testing quality into a product. I suggested that there's no reason to be afraid of mistakes. If you make a mistake, this is not the end of the world. You can fix it and move along. Happens all the time.

But what can you do if the language stands between you and your goal and doesn't let you do what you want to do?

[Kalvin]

But what can you do if the language stands between you and your goal and doesn't let you do what you want to do?

Do you have any particular case where the language has prevented you from doing something you would need to do? And what useful language constructions Ada does not have compared to the C/C++ languages, for example?

[Kalvin]

The magnitude of numbers that need to be represented depends on the problem and hence can and should be part of the problem specification and/or top-level architectural design. That is true for whichever language is used to implement a solution - Ada, C, Forth, Java, xC, Pascal (OK probably not Smalltalk, since it silently flips to BigIntegers whenever overflow occurs )

Right, and this is the reason I use int32_t etc. in C, except for simple things like small loop index variables. But the fact that it is possible at all that a program behaviour can change if you use a different compiler, is not a good language design decision in my opinion. I know they did this for efficiency reasons, because if you have 32 bit registers, then it is faster to have 32 bit integers as well, but this doesn't matter anymore nowadays. Would be better the other way around: if the programmer writes a program for an architecture with a CPU with 16 bit registers, the programmer could use 16 bit types, but integer should still be 32 bit. I guess it is no problem with the new generics feature of Ada to use the type you want in libraries as well, depending on your target.

Well, if you think about it, using integers or longs doesn't convey any information whether the variable contains a valid value or whether the value you are trying to assign to a variable is within the valid range. Thus, using integer and longs should not be allowed in first place. And the int32_t, uint32_t, uint8_t are just stating that you want to allocate N bytes for the variable, that's all.

Let's take an example here: You are printing the values of variables on the screen while your program is running. How can you be sure that the values of the variables are withing acceptable range? You do not, unless you check your source code or the documentation. So, you take a look at the source code and find out the the variable is of type integer:

Code: [Select]

int row;
int column;

Are you any wiser now in determining whether the variable holds a valid value?

The C programmers have a partial solution for this: they can use a typedef to define a new type:

Code: [Select]

typedef int RowIndex_t;
typedef int ColumnIndex_t;

RowIndex_t row;
ColumnIndex_t column;

Unfortunately this definition doesn't give any more information other than the variable row is now of type RowIndex_t but doesn't reveal what is the allowed range of values. Also, it doesn't allow the compiler check whether you are accessing the array with valid indexes: You can access the table as Table[row][column] or Table[column][row] and the compiler is happy with that, although the result may not be what you expect.

In Ada it is possible to define an integer type to contain the lower and upper limits of the type, so the programmer can find that information right from the type definition:

Code: [Select]

type Row_Index_Type is range ROW_INDEX_MIN .. ROW_INDEX_MAX;
type Column_Index_Type is range COLUMN_INDEX_MIN .. COLUMN_INDEX_MAX;

m : Row_Index_Type;
n : Column_Index_Type;

Now, also the compiler can check that the variable will always be assigned with the valid values, otherwise an exception will occur. With this more detailed and expressive type system, a compiler is able to perform compile-time analysis and find common errors, like trying to access the array with wrong indexes or assigning a variable with a value outside its allowed range etc.

[NorthGuy]

Do you have any particular case where the language has prevented you from doing something you would need to do? And what useful language constructions Ada does not have compared to the C/C++ languages, for example?

Last time I used "safe" languages was some 15 years age when I was forced to use VB and C#. So, I don't remember specific cases. Perhaps we start from C, and then you explain how Ada can help.

I propose the following small example. If you think it is bad, offer a different one and we'll go from there.

Imagine, you have a binary file (similar to ELF, ZIP etc.). Let's suppose the file contains a tree presented as a list of 32-bit aligned records:

Code: [Select]

typedef struct {
  uint32_t sibling; // offset of the sibling's record from the beginning of the file
  uint32_t child; // offset of the first child's record from the beginning of the file
  load_t payload; // variable length payload
} obj_t, *pobj_t;
You need to transverse the tree. You read your file into memory as a single piece, verify that the length is a multilple of 4, then you start going through the tree:

Code: [Select]

int process_object(char* file_base, uint32_t file_size, pobj_t object) {
   int offs;
 
  //TODO: here goes the code to process the payload

  // now deal with the tree

  // process the rest of the siblings (if any)
  if ((offs = object->sibling & 0xfffffffc) > file_size - 8) return 0;  // safety
  if (offs && !process_object(file_base, file_size, (pobj_t)(file_base + offs))) return 0;

  // process the children (if any)
  if ((offs = object->child & 0xfffffffc) > file_size - 8) return 0;  // safety;
  if (offs && !process_object(file_base, file_size, (pobj_t)(file_base + offs))) return 0;

  return 1;
}
In this case, C gave me everything - ability to access the data quickly, ability to process loads regardless of the payload. It is quick to write and works (I didn't test it though). Why would I need anything else? Extra tools cannot help, but they have an ability to impede what is already working.

How that would be done with Ada?

[tggzzz]

You are missing several things.

I am aware i am, that's why i asked

Demonstrably skilled programmers do continually make many mistakes with C/C++.

after all, humans make mistakes

Those with significant experience of both C and Ada usually claim Ada gives better results where it is used.

You have to compare the cost of the tools with the employment costs of the engineers (typically 2*salary).

but i would expect that since that's a more niche language tool that costs a lot for a small business, the salary for somebody that know it well would be that higher as well. bottom line, can smaller businesses in less critical areas afford the price of both tools and man power?
I assume that the goal of this competition is to increase adoption or at least make developers curious about it. Okay, where is the free compiler and debugger for my platform of choice? I am fine with some limitations so i can at least check it out
 

You have to compare the cost of the tools with the cost of making a mistake that would have been avoided if the tools had been used.
The cost to you is irrelevant
You have ignored the difficulty of proving (e.g. to a judge/jury) that you have taken all necessary steps. Common sense is irrelevant in that context.

Very true, one buy insurance before the accident. about common sense, i think that the jury's/judge common sense is very relevant, more than actual proofs, sadly

This is only my opinion, of course

I hope your placement of brackets in your programs is less error-prone than your placement of "quote" tags above! (One of the lines that you appear to write was in fact written by me).

Knowing that humans make mistakes is a reason for preferring languages that help detect and avoid some important classes of mistake.

Having free compilers/tools is very helpful, but is not sufficient. Industry inertia should never be underestimated.

General principle about insurance: on average you pay more for insurance than you get back from insurance. With that in mind...
I've never heard of any insurance for being late to market or developing poor quality products.
I suspect that buying insurance for a useful amount of product liability would be very expensive.

Yeeeeeah, i get your point. i guess i would have spotted that mistake in a forum with a WYSIWYG post editor, but i'd rather just make an error and then correct it. Nobody was harmed for this error, do you get mine?

Agreed. My point about the brackets was trivial, except that it is an illustration of how easy it is to miss a mistake. We all make mistakes; I know that only too well

I am not saying you all are wrong, not at all. What i'm trying to say is that i can't see how the benefits are more that the cost in my line of work. I like to learn from my mistakes and my mistakes shouldn't put people's life in danger, hopefully.
I am sure i will change my mind in the future, when i will be more eperienced... or when needed. But if i can use C, i'll use C.

Lack of experience? Probably. I won't deny it. After all, i have been earning money from programming microcontrollers for just a few years (i'm 25)
But the i-know-better attitude is not helping getting your message across

There is always a risk-reward tradeoff. In many cases the cost of mistakes is small.
You should use the best tool for the job; in some cases that will be C, in others it shouldn't be C.
What I object to is (other) people claiming that, one way or another, they catch all their mistakes.

Trying to work out what you will try to do better next time is a valuable attribute in an engineer. I've always asked job candidates that in interviews; if they don't have an answer they certainly won't get the job!

I was your age when I first used C in microcontrollers (in 1982). It worked, the customer was satisfied, but I was aware of C's limitations, I realised where I was "skating on thin ice" and started looking for tools without those limitations.

Lazyness? That plays a big role: if i can use C i will use C. I will be extra careful, no problem for me. I don't have tight development cycles nor have to work on safety critical applicatons, thank god.

But at the end of the day is lack of free and ready made tools that is stopping me or someone like me (i think) from adopting new languages.
Is there an ada compiler for dspic? AFAIK, no. And i use them extensively.
It is true that one shouldn't understimate industry inertia, but smaller players can also be more dynamic (less numbers on products and quantities, less people, less inertia from within the workplace itself) but for those places a multi thousand euro investment can't be taken lightly. That is my current situation. I can/am proposing new platforms in both software and hardware at where i work but the investment has to be justified. Having free tools for the platforms i have to use, at least for training, would have me learning these platforms.

Laziness is a poor reason
Mistakes can be very expensive even in non-safety critical applications.
Learning new languages is valuable, even if you never learn them in anger. Just knowing "different ways of thinking" is valuable, e.g. OOP, declarative, FSMs and event-driven architectures.

I see your point. Do you see mine?

Yes I do, with the caveats mentioned above.

[tggzzz]

IMHO you have to distinguish between two use cases for a safe programming language:
1) Use by programmers who can't program so the program doesn't work but at least it doesn't crash all the time.
2) Use by programmers who can program and like to concentrate on the task at hand instead of babysitting a programming language.

you have to distinguish between a "language" and "features that come with the compiler". language is one thing, compiler is another thing. since this thread is more toward a "language" (Ada), we should be concentrating on that, not what feature a compiler can provide. features a compiler from Borland will be different from what a Microsoft's compiler can provide. external tools is another whole different story.

I strongly suspect nctnico is more than aware of that.

However, language features can both enable and prevent compilers and toolchains from finding mistakes and reasoning about the code. And that is completely independent of specific compilers and other tools.

[NorthGuy]

What I object to is (other) people claiming that, one way or another, they catch all their mistakes.

I think you're tilting at windmills. I haven't seen anyone claiming that.

[Kalvin]

How that would be done with Ada?

Pretty much similar to your C implementation unless the binary file is abstracted by a simple container which will provide some information about the file itself, like the file size, so you do not have to pass that around explicitly.

Ada doesn't have restrictions which prevents from accessing the binary arrays like you are doing. But, if your file has been corrupted, the variable offs may get negative values, and you will access the data somewhere else in the stack:

Code: [Select]

if ((offs = object->sibling & 0xfffffffc) > file_size - 8) return 0;  // safety
if (offs && !process_object(file_base, file_size, (pobj_t)(file_base + offs))) return 0;

You are also assuming that int is 32-bits. Will this work correctly with 64 bit ints?

In Ada one could write pre-conditions and post-conditions which would check the that the contract is not violated. For example one pre-condition could be so that the object is within file_base and file_base + file_size and trying to access the file outsize its bound would produce an exception.

In Ada one would probably operate with unsigned integers to access the elements of the byte array, so the index cannot be negative and will be caught at runtime. Then one would assign an Access variable (similar to C pointer) to point to the struct, and access the data using that Access variable. Also, one would add a pre-condition that the index has to be divisible by 4. One can also specify that the Access is aligned to 4.

Using isolated example is a bit problematic because the benefits of the language seem to be very limited if none. But even in this small example one could write something more robust - even in C, but Ada has some built-in advantages, though.

[analogo]

Does GNAT still require GPL for anything linked with its libraries?

GNAT does not require other sources/programs to be compiled with GPL. As the rest of GCC, it is licensed under the GPLv3 + runtime library exception: https://www.gnu.org/licenses/gcc-exception.html: "When you use GCC to compile a program, GCC may combine portions of certain GCC header files and runtime libraries with the compiled program. The purpose of this Exception is to allow compilation of non-GPL (including proprietary) programs to use, in this way, the header files and runtime libraries covered by this Exception."

In other words, GNAT/GCC itself is GPL but you can use it without problems (and without paying) to produce any program, even proprietary programs.

[legacy]

GNAT does not require other sources/programs to be compiled with GPL. As the rest of GCC

GNAT requires a bootstrapper, which is architecture specific!

Code: [Select]

SRC_URI="ftp://gcc.gnu.org/pub/gcc/releases/gcc-${PV}/gcc-core-${PV}.tar.bz2
        ftp://gcc.gnu.org/pub/gcc/releases/gcc-${PV}/gcc-ada-${PV}.tar.bz2
        amd64? ( https://dev.gentoo.org/~george/src/gnatboot-${SLOT}-amd64.tar.bz2 )
        sparc? ( https://dev.gentoo.org/~george/src/gnatboot-${SLOT}-sparc.tar.bz2 )
        x86?   ( https://dev.gentoo.org/~george/src/gnatboot-${SLOT}-i686.tar.bz2 )"
#       ppc?   ( mirror://gentoo/gnatboot-${BOOT_SLOT}-ppc.tar.bz2 )

As you can see, forget { PPC32, PPC64, MIPS, HPPA1, HPPA2, SPARC }

Code: [Select]

2016-12-10--16-12-50---2016-12-10--19-32-20 - emerge  =dev-lang/gnat-gcc-4.9.3 - success - root
2016-12-10--20-15-36---2016-12-10--23-06-03 - emerge  =dev-lang/gnat-gcc-4.3.6 - failure - root
2016-12-13--01-42-28---2016-12-13--06-58-53 - emerge  =dev-lang/gnat-gcc-4.3.6-r1 - failure - root
2016-12-13--12-04-03---2016-12-13--12-05-42 - emerge  -K =dev-lang/gnat-gcc-4.3.5 - success - root

Also, there are some bugs, which still don't make the process to complete on some versions.

[legacy]

but Ada has some built-in advantages, though.

And not being obliged to use the C preprocessor ( #ifdev, #else ... #define ... ) is a bonus

[NorthGuy]

In Ada one would probably operate with unsigned integers to access the elements of the byte array, so the index cannot be negative and will be caught at runtime. Then one would assign an Access variable (similar to C pointer) to point to the struct, and access the data using that Access variable. Also, one would add a pre-condition that the index has to be divisible by 4. One can also specify that the Access is aligned to 4.

I should've declared Offs as uint32_t. It's a bug in my code. However, when you combine signed with unsigned, C uses unsigned operation, so the code still works correctly. I might've get a compiler warning on this, depending on the compiler.

So, in Ada you would declare the constraints when declaring the variables, and then the compiler would check every assignment. But if you had specified a wrong constraint in the declaration (same as I declared Offs int instead of uint32_t) then you would get all the wrong checks (same as I could get wrong comparisons if the C standard would be slightly different). Doesn't look very different so far.

What is different, is that Ada would check the conditions on all assignments, not only when it's needed. It you know the value in the variable is good, so you can skip the checks. The compiler cannot. I understand the compiler can optimise and skip some of the checks. But humans can do this better. Thus human code will produce less checks, often much less checks. Not a big deal for a small program, but this is one of mechanisms which add bloat to the code.

But even in this small example one could write something more robust - even in C, but Ada has some built-in advantages, though.

Exactly. The success depends on the one writing the code. If he uses int instead of uint32_t in C, or if he specifies a wrong constraint in Ada, the code will be buggy. Looks like switching languages won't make much difference, will it?

[westfw]

I would love to see someone use this contest as an excuse to re-write the Arduino environment for Due (Atmel SAM3X CM3.)  Just enough for all of the standard examples to run.   You can cheat if you want - I assume the Ada compilers in question have the ability to call functions in a lower-level language?  Then we can see exactly how much bigger/slower/etc the sketches are, how much of the code has to be "unsafe", how much ha to be written in some other language, look for advantages of the Ada version, and so on, for a whole set of pretty standard-ish embedded applications...

[Mechatrommer]

In Ada one would probably operate with unsigned integers to access the elements of the byte array, so the index cannot be negative and will be caught at runtime.

oh i would love to see this when it get caught in life threatening situation such as in Avionics... i would love.... but actually not, for the sake of the souls involved.

[Kalvin]

In Ada one would probably operate with unsigned integers to access the elements of the byte array, so the index cannot be negative and will be caught at runtime. Then one would assign an Access variable (similar to C pointer) to point to the struct, and access the data using that Access variable. Also, one would add a pre-condition that the index has to be divisible by 4. One can also specify that the Access is aligned to 4.

I should've declared Offs as uint32_t. It's a bug in my code. However, when you combine signed with unsigned, C uses unsigned operation, so the code still works correctly. I might've get a compiler warning on this, depending on the compiler.

So, in Ada you would declare the constraints when declaring the variables, and then the compiler would check every assignment. But if you had specified a wrong constraint in the declaration (same as I declared Offs int instead of uint32_t) then you would get all the wrong checks (same as I could get wrong comparisons if the C standard would be slightly different). Doesn't look very different so far.

What is different, is that Ada would check the conditions on all assignments, not only when it's needed. It you know the value in the variable is good, so you can skip the checks. The compiler cannot. I understand the compiler can optimise and skip some of the checks. But humans can do this better. Thus human code will produce less checks, often much less checks. Not a big deal for a small program, but this is one of mechanisms which add bloat to the code.

But even in this small example one could write something more robust - even in C, but Ada has some built-in advantages, though.

Exactly. The success depends on the one writing the code. If he uses int instead of uint32_t in C, or if he specifies a wrong constraint in Ada, the code will be buggy. Looks like switching languages won't make much difference, will it?

Yes, you are correct that changing a programming language wouldn't make a poorly designed and poorly written code any better. But in the hands of a good programmer it does make difference.

Btw, you are making an assignment in if statement, which is considered as illegal in many organizations. Yes, you are comparing signed to unsigned. Probably you will turn off also some other compiler warnings so they will not annoy you too much. You are also assuming that the endianess doesn't matter. It would be also a good thing to make the struct as packed just in case. Ada has a built-in capability to specify the endianess, so one doesn't have to decorate the code with the endianess conversion macros.

[Kalvin]

In Ada one would probably operate with unsigned integers to access the elements of the byte array, so the index cannot be negative and will be caught at runtime.

oh i would love to see this when it get caught in life threatening situation such as in Avionics... i would love.... but actually not, for the sake of the souls involved.

Yes, I know what you mean: It would be much better to keep on computing using invalid data, like the air speed, instead of letting the programmer to decide what to do if the exception should happen. Right?

[Mechatrommer]

In Ada one would probably operate with unsigned integers to access the elements of the byte array, so the index cannot be negative and will be caught at runtime.

oh i would love to see this when it get caught in life threatening situation such as in Avionics... i would love.... but actually not, for the sake of the souls involved.

Yes, I know what you mean: It would be much better to keep on computing using invalid data, like the air speed, instead of letting the programmer to decide what to do if the exception should happen. Right?

exception is certainly supported in C/C++. but we are not comfortable enough with any compiler's high level built in functions/features, so we make our own check in every loops, tuned specifically so there is no unecessary degradation in performance (aka bloatware). modular programming style is a must, so we can break down applications into smaller unit test, and we make sure every single one of it is bulletproof of any possible inputs, we test them to fail. please distinguish... we test our code/application, we are not testing the "language" or the "tool", we test the real deal. that is if... and only if... we are paid good money for it. you call that tedious? not much difference than exception handling in any languages, generic or specific.

[Kalvin]

In Ada one would probably operate with unsigned integers to access the elements of the byte array, so the index cannot be negative and will be caught at runtime.

oh i would love to see this when it get caught in life threatening situation such as in Avionics... i would love.... but actually not, for the sake of the souls involved.

Yes, I know what you mean: It would be much better to keep on computing using invalid data, like the air speed, instead of letting the programmer to decide what to do if the exception should happen. Right?

exception is certainly supported in C/C++. but we are not comfortable enough with any compiler's high level built in functions/features, so we make our own check in every loops, tuned specifically so there is no unecessary degradation in performance (aka bloatware). modular programming style is a must, so we can break down applications into smaller unit test, and we make sure every single one of it is bulletproof of any possible inputs, we test them to fail. please distinguish... we test our code/application, we are not testing the "language" or the "tool", we test the real deal. that is if... and only if... we are paid good money for it. you call that tedious? not much difference than exception handling in any languages, generic or specific.

In my opinion Ada has superior type system compared to C or C++ as it allows the system designer or programmer specify the limits of the data types very specifically and the compiler is able to perform compile-time checking - as well as run-time checking if enabled. Ada has also pre-conditions and post-conditions which help the compiler to validate the code and help unit testing, in addition to providing the person reading the code the intention of the original programmer very clearly. Ada has also a SPARK subset which makes it possible to mathematically prove the code correct against the specifications. Of course, if the specs are wrong or poorly written no language can improve poor design.

[Kalvin]

One thing came to my mind while thinking of "what can be done in C but not in Ada": Protothreads used in Contiki OS.

http://dunkels.com/adam/pt/

The protothreads implementation depends heavily on C preprocessor macros and it exploits heavily some C language constructs that may not available in Ada.

[westfw]

"what can be done in C but not in Ada": Protothreads used in Contiki OS.

Doesn't Ada have it's own multitasking?

This is the perfect time for one of the Ada experts to chime in and say something like "Contiki protothreads are a prefect example of C programmers doing things that are extremely dangerous, just because the language lacks important features like built-in multitasking."  :-)

On the third hand, Contiki uses protothreads to save space and overhead in systems that would have problems implementing real multitasking (say: "Posix threads"), and support of multitasking is one of the things that adds "bloat" to the Ada runtimes...  TANSTAAFL!

(Hmm.  Serious question:  relatively recently, there has been a fair amount of development of link-time optimization; so that unused functions from libraries (or from user code) are simply omitted from the final binary.  Do Ada compilers like GNAT for embedded ARM manage to take advantage of that for reducing the footprint of the runtime environment, or are they still in the "the runtime is the runtime; you get the whole thing."  (usually a DLL on "real" computers; I'm not sure how it's handled on embedded targets.)  (A big advantage of C is that is mostly doesn't have any runtime environment.  Just libraries.  This makes it terrifyingly easy to port to new targets; at least "partially.")

[nctnico]

On the third hand, Contiki uses protothreads to save space and overhead in systems that would have problems implementing real multitasking (say: "Posix threads"), and support of multitasking is one of the things that adds "bloat" to the Ada runtimes...  TANSTAAFL!

I've looked at protothreads but it is a mess. It is a typical solution which makes a piece of code unreadable and thus hard to transfer to a different programmer.

Do Ada compilers like GNAT for embedded ARM manage to take advantage of that for reducing the footprint of the runtime environment, or are they still in the "the runtime is the runtime; you get the whole thing."

IMHO you should always aim to get the whole thing. A half baked runtime just sucks because one or another you have to contort yourself into all kinds of limitations. I've seen that happen with Windows CE (half baked) versus Linux (whole package) on embedded systems.

[NorthGuy]

Yes, you are correct that changing a programming language wouldn't make a poorly designed and poorly written code any better. But in the hands of a good programmer it does make difference.

You keep saying this, but you don't really show where the difference is. I suggested a small example, and, by your words, it would be about the same in Ada as in C and Ada can mimic C. So what? I can re-write the example in Pascal which compiles with old Delphi (great compiler BTW, way better than most C compilers):

Code: [Select]

type
  PObj = ^TObj;
  TObj = record
    sibling: cardinal; // offset of the sibling's record from the beginning of the file
    child: cardinal; // offset of the first child's record from the beginning of the file
    payload: array[0..3] of char; // variable length payload
  end;
 
function process_object(file_base: PChar; file_size: cardinal; o: PObj): boolean;
var
  offs: cardinal;
begin
  process_object := FALSE;
  //TODO: here goes the code to process the payload

  // now deal with the tree

  // process the rest of the siblings (if any)
  offs := o^.sibling and $fffffffc;
  if offs > (file_size - sizeof(TObj)) then exit;
  if offs > 0 then begin
    if not process_object(file_base, file_size, PObj(file_base + offs)) then exit;
  end;

  // process the children (if any)
  offs := o^.sibling and $fffffffc;
  if offs > (file_size - sizeof(TObj)) then exit;
  if offs > 0 then begin
    if not process_object(file_base, file_size, PObj(file_base + offs)) then exit;
  end;

  process_object := TRUE;
end;
But this doesn't make Pascal better than C. It only demonstrates that it has enough low-level capabilities to replicate anything that can be done in C. From your explanations, it appears that Ada can do the same, so anyone who works in C could replicate his work in Ada. But this doesn't make Ada better than C.

May be the example was not good to show the advantages of Ada. Can you come up with a new example which would show the difference?

Btw, you are making an assignment in if statement, which is considered as illegal in many organizations.

Like companies who use MISRA? This is another way to sacrifice freedom for imaginary safety. I couldn't care less about this. I don't work for such organization, and I never will.

You are also assuming that the endianess doesn't matter. It would be also a good thing to make the struct as packed just in case. Ada has a built-in capability to specify the endianess, so one doesn't have to decorate the code with the endianess conversion macros.

I don't assume anything (try not to anyway). In the real life I would know the endianness of my target CPU(s). If I had to flip bytes (e.g. with TCP/IP) I would. If not, I wouldn't.

Of course, there is a theoretical possibility that I may target different platforms which have different endianness, but I don't envision this in the near future, and I'm not going to make any provisions in my code until this really happens. Until then, I wouldn't try to write a code which would work for either endianness. This would be extra work, extra clutter, and extra testing.

In general, I write my code for specific target(s) and I don't worry if it can be ported to somewhere else. In my experience, if I want to port something to a different target 10 years from now, I'll have to re-write anyway - life will be very different then. Why waste time ensuring portability of code which will never be ported? In my early years, I did waste lots of time "universalizing" my code. I tried to make it flexible, so that I could use it in different situations. I seriously believed that I would be reusing my code for the rest of my life. I had such a nice collection of punchcards. How silly that was. Since then, I figured out that I can gain a lot by making my code specific (as opposed to universal).

Language designers are in a different position. When you design a language, such as Ada, you would expect it to be used everywhere. And endianness was of a big importance back then. If they created language constructions to handle endianness, this is certainly a good thing. But I doubt it is substantially better than using htons(), ntohs() etc.

[legacy]

But this doesn't make Pascal better than C. It only demonstrates that

to talk is futile. We are again stopped at the same point.

People wants examples, so the better advice is: find a job in avionics, it will full of them, with all the details and the low level you need to see, and it doesn't cost time to repeat concept again and again and again, without a context.

[NorthGuy]

People wants examples, so the better advice is: find a job in avionics, it will full of them, with all the details and the low level you need to see, and it doesn't cost time to repeat concept again and again and again, without a context.

So, there's a concept, mindset. Specific examples cannot be given. Smells like snake oil.

[FrankBuss]

So, there's a concept, mindset. Specific examples cannot be given. Smells like snake oil.

There are many examples on the web. Some interesting ones are which you can't write in C or C++, see for example this article and contracts. Post-conditions are not easily possible with C++. Only recently they proposed it for C++17, see here, so it is obviously missing from the language and useful for bigger projects, and even Stroustrup recommends it.

You are right, you can do anything in C that you can do in Ada, regarding the pure computation of something, and the source code might be smaller, because of the more verbose syntax of Ada, and the executable might be smaller, because of less runtime checks. But Ada claims to help you to avoid bugs with the compile time and runtime checks. This is not important for a blinking LED program on a microcontroller, but there are interesting studies, like this, which compares C and Ada for the number of bugs per lines. For C it was 7 times more bugs compared to Ada. Even if you consider that an Ada program might have twice as much lines as a C program, it would be a good reason to use Ada, because the study shows also, that programming a feature in Ada was cheaper than programming it in C, and even many of the programmers hired for this company had to learn Ada first, because the were only C programmers. And the additional time and space required for the runtime checks doesn't matter for modern microcontrollers. But granted, you might not want to use it for a 4 bit CPU in a toy, where every opcode and cent counts. I guess there is no silver bullet and perfect language for all use cases.

So far looks like every C programmer who has tried Ada thinks it should be used more often. I'll report after I finished my competition entry, for which I have to learn Ada first, and which is bigger than a blinking LED. Maybe you should write some Ada programs, too, to see if it is just snake oil or if it helps you.

[Mechatrommer]

funnily enough i never have the need for assert function, or i believe with this same "contract" concept. i have a stereotype that assert, or "throw catch all" feature are only for lazy programmer. but well maybe thats just me. as i said i made my own checking and divert code execution to whenever it needs to be, when some condition (or contract? same meaning but different word labelling?) is violated. it does obscure program logic or semantics (readability) though (well i dont see much difference with bloated syntaxes just to handle pre/post conditions), but handling exception from unknown source is just as tedious imho. things like assert do help in debugging software, but in real/published/distributed application esp in life threatening application, thrown assert or exception is just not tolerable. hell who can afford to click ok button with "this line error to variable this...." in the middle of the sky where you are the pilot struggle to balance the pitch and aileron just because autopilot is stopped calculating. ymmv...

[NorthGuy]

Code: [Select]

[quote author=FrankBuss link=topic=88483.msg1214330#msg1214330 date=1495384769]
There are many examples on the web. Some interesting ones are which you can't write in C or C++, see for example this article and contracts.
This article starts from building a storage stack and checking for stack overflows. It may be useful in debugging. However, even in C, you can use macros which will insert checks during debugging. Then you can re-define the macros, so that all the checks are removed for production.

What is important to me, I don't perceive that doing checks is a problem worth addressing. Imagine, you have life critical application, your patient is dying and your stack overflows over and over again. Would it really matter if the patient died because of a reset by bloody unchecked exception in C code, or ... because Ada caught the condition and organizely reported it to a software handler which happily reset the chip.

<disclaimer>I never participated in life critical projects.

IMHO, the real problem is how to design the firmware so that the storage stack never overflows - analyze timing paths, execution flow, and make sure that the adverse conditions never happen. This, surely, is not related to any language. But since the stack never overflows, who cares if there's a check for the overflow or not.

However, to make sure everything goes as planned, I need a language which cooperates and does exactly what I say. If Ada inserts a bunch of checks on my timing critical path, upsets the timing and destroys my safety mechanisms, I don't want to be the one fixing the mess. Worse yet, what if Ada does such thing unpredictably, just because I made a small change which caused extra checks to appear. And this all a day before production deadline? I better go with full control and C (or similar), or even assembler if needed.

Post-conditions are not easily possible with C++.

"try" can do it in C++. In C, you can encapsulate your block into a function call.

... there are interesting studies, like this, which compares C and Ada for the number of bugs per lines.

It is a very interesting study. I'm not sure it was because of Ada safety features, or because of the overall verbosity of the language. C is somewhat cryptic and often perceived as unfriendly. I suspect, if they compared C to Pascal, the result would be similar, although there's no safety in Pascal. I do like Pascal better than C, but unfortunately it isn't used much.

Maybe you should write some Ada programs, too, to see if it is just snake oil or if it helps you.

My interests are more at lower levels. When I was young I had a book on Algol-68, which I found fascinating at a time, but then I moved from high abstractions to physical realities, for better or for worse ...

I wish you luck in the Ada contest.

[nctnico]

Code: [Select]

[quote author=FrankBuss link=topic=88483.msg1214330#msg1214330 date=1495384769]
There are many examples on the web. Some interesting ones are which you can't write in C or C++, see for example this article and contracts.
This article starts from building a storage stack and checking for stack overflows. It may be useful in debugging. However, even in C, you can use macros which will insert checks during debugging. Then you can re-define the macros, so that all the checks are removed for production.

Which is exactly what you don't want! Boundary checks in production software prevent a bug in module A to spread across your software and cause problems in module F. You'll never find the cause of 'quirky' behaviour especially if it occurs only a few times per year. Is it that really so hard to see the benefits of a language which does that for you so you don't have to deal with it yourself?

[tggzzz]

Btw, you are making an assignment in if statement, which is considered as illegal in many organizations.

Like companies who use MISRA? This is another way to sacrifice freedom for imaginary safety. I couldn't care less about this. I don't work for such organization, and I never will.

Good. That's a relief.

[tggzzz]

<disclaimer>I never participated in life critical projects.

Given your other questions and statements in your posting, that is quite evident.

Please try to imagine what you would do and what choices you would make if your code was responsible for, say, your mother's life.

Then move on to consider the same question if your code was responsible for you companies' continued existence (i.e. if you got it seriously wrong, your company would go bankrupt).

[tggzzz]

Code: [Select]

[quote author=FrankBuss link=topic=88483.msg1214330#msg1214330 date=1495384769]
There are many examples on the web. Some interesting ones are which you can't write in C or C++, see for example this article and contracts.
This article starts from building a storage stack and checking for stack overflows. It may be useful in debugging. However, even in C, you can use macros which will insert checks during debugging. Then you can re-define the macros, so that all the checks are removed for production.

Which is exactly what you don't want! Boundary checks in production software prevent a bug in module A to spread across your software and cause problems in module F. You'll never find the cause of 'quirky' behaviour especially if it occurs only a few times per year. Is it that really so hard to see the benefits of a language which does that for you so you don't have to deal with it yourself?

Precisely.

I have successfully used that mentality to avoid becoming involved in lawsuits by quickly and simply demonstrating that other company's code was at fault, not my company's code.

[tggzzz]

On the third hand, Contiki uses protothreads to save space and overhead in systems that would have problems implementing real multitasking (say: "Posix threads"), and support of multitasking is one of the things that adds "bloat" to the Ada runtimes...  TANSTAAFL!

I've looked at protothreads but it is a mess. It is a typical solution which makes a piece of code unreadable and thus hard to transfer to a different programmer.

When I looked at it I regarded it as a brittle solution to the wrong problem. You know, the "if all you have is a hammer, everything looks like a nail" syndrome.

Engineers (cf amateurs) choose the right tool for the job, and don't try to "MacGuyver" everything.

Do Ada compilers like GNAT for embedded ARM manage to take advantage of that for reducing the footprint of the runtime environment, or are they still in the "the runtime is the runtime; you get the whole thing."

IMHO you should always aim to get the whole thing. A half baked runtime just sucks because one or another you have to contort yourself into all kinds of limitations. I've seen that happen with Windows CE (half baked) versus Linux (whole package) on embedded systems.

A half-baked runtime is as dangerous as a half-baked garbage collector.

C programmers are infamous for thinking that they can knock up a quick special purpose GC on the fly. And when it turns out to have problems they don't blame themselves, but they do go on to damn all GCs as being useless! Doh!

[NorthGuy]

Is it that really so hard to see the benefits of a language which does that for you so you don't have to deal with it yourself?

I accustomed to dealing with my problems by myself. I don't feel it is hard, time consuming, or anything of the sort. So, I choose to give up whatever are the benefits of unknown checks, and do my own checks as I feel appropriate.

[tggzzz]

Is it that really so hard to see the benefits of a language which does that for you so you don't have to deal with it yourself?

I accustomed to dealing with my problems by myself. I don't feel it is hard, time consuming, or anything of the sort. So, I choose to give up whatever are the benefits of unknown checks, and do my own checks as I feel appropriate.

I taught my daughter to do her best to learn from other peoples' mistakes - because repeating known mistakes is a waste of at least on person's life. Let's make new mistakes!

Alternatively: it is better to stand on the shoulders of giants than to tread on the toes of giants

[NorthGuy]

<disclaimer>I never participated in life critical projects.

Given your other questions and statements in your posting, that is quite evident.

Please try to imagine what you would do and what choices you would make if your code was responsible for, say, your mother's life.

Then move on to consider the same question if your code was responsible for you companies' continued existence (i.e. if you got it seriously wrong, your company would go bankrupt).

  I have put this one in for you. I though zzz would byte on it. And you did! 

[tggzzz]

<disclaimer>I never participated in life critical projects.

Given your other questions and statements in your posting, that is quite evident.

Please try to imagine what you would do and what choices you would make if your code was responsible for, say, your mother's life.

Then move on to consider the same question if your code was responsible for you companies' continued existence (i.e. if you got it seriously wrong, your company would go bankrupt).

  I have put this one in for you. I though zzz would byte on it. And you did! 

So, you admit you are a troll.

[Mechatrommer]

so much so for the engineering workflow... and language's tool robustness...
http://www-users.math.umn.edu/~arnold/disasters/ariane.html
http://www-users.math.umn.edu/~arnold/disasters/ariane5rep.html
teach our daughter not to repeat people's mistake...
ie relying on "robust" language... and trusting advertisements.

[FrankBuss]

so much so for the engineering workflow... and language's tool robustness...
http://www-users.math.umn.edu/~arnold/disasters/ariane.html
http://www-users.math.umn.edu/~arnold/disasters/ariane5rep.html

This has nothing to do with Ada. I think the main reason for the failure was the missing requirement ("SRI specification (which is supposed to be a requirements document for the SRI) does not contain the Ariane 5 trajectory data as a functional requirement."). They used a system which was developed for the Ariane 4, and they knew the trajectory of the Ariane 5 was different, but they didn't bother to simulate the new trajectory. That's just careless. You can use the best and safest language, even mathematically prove that it works according to the specification, but this doesn't mean that the specification is right or that it will work in the real world. Both things are orthogonal: safe language and coding, and testing.

[tggzzz]

so much so for the engineering workflow... and language's tool robustness...
http://www-users.math.umn.edu/~arnold/disasters/ariane.html
http://www-users.math.umn.edu/~arnold/disasters/ariane5rep.html
teach our daughter not to repeat people's mistake...
ie relying on "robust" language... and trusting advertisements.

That interpretation is a failure of your critical thinking. A problem would have occurred with any programming language since the specification was faulty.

You need to understand the vital difference between "validation" and "verification". If you can't show such understanding, then it is completely reasonable for anyone reading your opinions to disregard them as worthless.

[Mechatrommer]

yeah but the point is Ada let stupid mistake like overflowed conversion from 64 bit float value to 16 bits integer value... and another point, as you put it, specification, and its decided by human, those human are given the safest gun on earth and they eventually did manage to shoot their foot . so much so on the Ada "on rail" bulletproof checking... if you cant see the basic point to the problem discussed here, arguing/wandering with inadequately solid proof, then your opinion may as well be disregarded as worthless.

[FrankBuss]

If you read the detailed documentation about the problem, the Ada system generated an exception when the overflow occurred, which caused the system to turn off. And the programmers even identified all possible overflow problems and decided to not protect this conversion (I guess with try/catch or something), which they have done for other conversions. But as I wrote, you can think it is all 100% correct, but if you don't test it in the real world or at least with simulated data for the real device, it is very likely that it will fail.

[legacy]

You need to understand the vital difference between "validation" and "verification"

so, in their mind ( "validation" isEqualTo "verification )

LOL 

That's the first difference they will learn in avionics.

( someone still thinks, he/she can have the same experience, mastering the difference between "validation" and "verification", by translating C sketches from Arduino into gNAT )

[legacy]

Like companies who use MISRA? This is another way to sacrifice freedom for imaginary safety.

Yeah, "imaginary safety" which only happens in your ignorance.
I am tired to read this kind of bullshit 

[Mechatrommer]

If you read the detailed documentation about the problem, the Ada system generated an exception when the overflow occurred, which caused the system to turn off. And the programmers even identified all possible overflow problems and decided to not protect this conversion

i know! whose fault then? i bet the answer is NOT the language/ide/tool/ada, right? its the human, whoever they are... but when it comes to C, when a programmer or management BS specified to not to boundary check in memory access, and buffer overrun occured, who got the blame? you are right! C's fault, not the stupid programmer or the management BS . you see the fairness/problem here? and then what happened when a buffer overrun occured will differ from machine/OS to another. this subject requires an entire lot of discussion on it own which i will not wander into.

[gameridian]

I'm staying out of this conversation, but I will at least point out that it is more about having a comprehensive specification than it is about the language used.  Despite working with avionics systems in the past that have used jovial, pascal, and ada, I would have no issue with choosing C again.  I've worked on various aircraft subsystems such as a flight management system for a fixed wing aircraft, and modernization of a mission computer for a rotary wing aircraft, both of which were safety critical, DO-178B compliant, and written in C.  A detailed spec dominates all aspects.

[Mechatrommer]

A detailed spec dominates all aspects.

this + tolerant boss that knows rush job |= safety... in any languages...

[westfw]

Quote

Quote

Do Ada compilers like GNAT for embedded ARM manage to take advantage of that for reducing the footprint of the runtime environment, or are they still in the "the runtime is the runtime; you get the whole thing."

IMHO you should always aim to get the whole thing. A half baked runtime just sucks because one or another you have to contort yourself into all kinds of limitations.Quote

No no.   I want the whole runtime to be "available", but I want only the parts that a particular application USES to be be included in the binary.  It's something that embedded C developers more-or-less take for granted ("if you don't use printf, you won't get printf code in your .hex file"), but it's not necessarily how languages that have a significant runtime component work ("You wrote a 4 line "hello world" program in visual basic.  Don't forget to make sure that anyone who wants to run this program also downloads the 300k Visual Basic Runtime library.")
Quote

>[Ariane] This has nothing to do with Ada.I'm pretty sure I read/heard one analysis that said it would have worked fine if the overflow had simply been ignored, the way it would have been in Fortran or C.  By trapping "errors", Ada succeeded in introducing a code path that was unexpected and unhandled, while ultimately unnecessary.  Sure, it should have just handled it correctly.   But you could say that about C too.  It's a common "doublethink" in embedded programming:  "we must handle all errors so the program doesn't crash" vs "you know, the program crashing is not so bad, if it restarts quickly enough that the SYSTEM spends most of it's time working."

[NorthGuy]

Is it possible that they were not vigilant enough because they were using safe language and expected that the language provide some level of protection?

[tggzzz]

You need to understand the vital difference between "validation" and "verification"

so, in their mind ( "validation" isEqualTo "verification )

LOL 

That's the first difference they will learn in avionics.

( someone still thinks, he/she can have the same experience, mastering the difference between "validation" and "verification", by translating C sketches from Arduino into gNAT )

...and then complaining that there are more keystrokes in the Ada version, therefore it is worse.

Some people should be kept away from keyboards.

[Kalvin]

I'm staying out of this conversation, but I will at least point out that it is more about having a comprehensive specification than it is about the language used.  Despite working with avionics systems in the past that have used jovial, pascal, and ada, I would have no issue with choosing C again.  I've worked on various aircraft subsystems such as a flight management system for a fixed wing aircraft, and modernization of a mission computer for a rotary wing aircraft, both of which were safety critical, DO-178B compliant, and written in C.  A detailed spec dominates all aspects.

After that it is only a matter of time the get the product right, and then maintain the product, probably port the software into a new device, while keeping in mind that time = money. Some languages are better in this than others, though.

[tggzzz]

If you read the detailed documentation about the problem, the Ada system generated an exception when the overflow occurred, which caused the system to turn off. And the programmers even identified all possible overflow problems and decided to not protect this conversion

i know! whose fault then? i bet the answer is NOT the language/ide/tool/ada, right? its the human, whoever they are... but when it comes to C, when a programmer or management BS specified to not to boundary check in memory access, and buffer overrun occured, who got the blame? you are right! C's fault, not the stupid programmer or the management BS . you see the fairness/problem here? and then what happened when a buffer overrun occured will differ from machine/OS to another. this subject requires an entire lot of discussion on it own which i will not wander into.

Don't be silly.

A programmer that chooses to ignore warnings is at fault.
A language that cannot, by design, issue warnings is also at fault, albeit a different fault.

[Mechatrommer]

A language that cannot, by design, issue warnings is also at fault, albeit a different fault.

and then again you, as many others, cannot distinguish between a "language" and the "compiler". i'm not sure about gcc and others, but microsoft vc++ compiler is certainly gives "possible loss of data" warning when you try to assign larger to lower bit variable, and many other violations possibility too. i'm not sure which compiler you all people are refering to maybe gcc? which you are all mistakenly refering to as the "language". well, its a matter of time for someone to come up with better and more polished C/C++ compiler. its not that easy to get it 100% right when it is a free tool.

with exception to fault that can only be determined at runtime such as buffer overrun. with a good habit and experience, a simple routine may solve the issue. if one is to say this is a mcguyver or tedious babysitting job, then he should learn more, or else find another job...

Is it possible that they were not vigilant enough because they were using safe language and expected that the language provide some level of protection?

from the report, the team has done extensive test on one particular/earlier specification. the unprotected decision was a well intended decision, acceptable for the earlier case. the problem was when they moved the software to latest revision rocket that didnt obey the earlier specification. the culprit is the person/team who decided to move it without retest to new spec and redo full simulation on the new system. yeah its alot of job, programming is just a small part of it, 7bils of wasted money is too much money if its only for Ada programming. but deciding which variables to be protected or not is the babysitting job in Ada language domain. if they mourn that Ada doesnt need babysitting, the report just proved they are plain wrong;

[NorthGuy]

from the report, the team has done extensive test on one particular/earlier specification. the unprotected decision was a well intended decision, acceptable for the earlier case. the problem was when they moved the software to latest revision rocket that didnt obey the earlier specification. the culprit is the person/team who decided to move it without retest to new spec and redo full simulation on the new system. yeah its alot of job, programming is just a small part of it, 7bils of wasted money is too much money if its only for Ada programming. but deciding which variables to be protected or not is the babysitting job in Ada language domain. if they mourn that Ada doesnt need babysitting, the report just proved they are plain wrong;

I think the cause of the failure came earlier, when they failed to unit test the calculations over the entire range of the possible values for A4. It worked on A4 by pure coincidence. By the time they used it on A5 they thought it was fully tested and operational.

If I understood the report correctly, the value being calculated was not needed for the flight on that stage, and if it produced a garbage value it wouldn't be critical. The real problem was the exception caused by the overflow. The exception caused the shut-down of the entire computer which eventually caused the explosion.

The computer shutdown was meant to be a safety feature, and as it often happens with safety features, it has gone completely untested - no one ever bothered to test the scenarios with computer shutdown. Worse yet, even the commission which investigated the case didn't pointed out to the necessity of such tests. They did discuss whether shutting down the computer was a good idea or not, but they never really envisioned the consequences, never did any tests.

The exception and computer shutdown, the very features that were put there solely for safety reasons, have caused the whole thing to blow up. How ironic.

[Mechatrommer]

well, i try not to blame eng. team there a lot of people involved. i dont believe all of them are a bunch of fool and lazy either. highly suspect will be people up there who has the power to "interview" and control people and select who he like or not. who are clueless about programming details, only care about the management, economic and legislative jargons. and who only trust the advertisement. do they have report on people who got fired, sued or jailed? i believe none. in the end this people in power in regret due to the loss thought he should listen to the engineer in the first place and concluded the report with Recommendation for future project. well thats just my speculation.

[Sal Ammoniac]

Demonstrably skilled programmers do continually make many mistakes with C/C++.

That's why we do code reviews. Compilers, even very sophisticated ones, cannot catch certain kinds of logic errors, so relying on only the compiler or language is foolish.

[tggzzz]

Demonstrably skilled programmers do continually make many mistakes with C/C++.

That's why we do code reviews. Compilers, even very sophisticated ones, cannot catch certain kinds of logic errors, so relying on only the compiler or language is foolish.

Only a fool would rely on compilers to catch all errors.
Only a different kind of fool would expect code reviews to catch all errors.
Only an arrogant <expletive deleted>[1] would believe they don't need all the help they can get, from whatever source.

Code reviews are necessary but not sufficient; there are many kinds of error they will not catch. A particular problem is they are not scalable, particularly where code is produced by multiple teams/companies.

Code reviews only examine a single snapshot of a subset of the codebase. Compilers and associated tools (if permitted by the language and tools) examine the whole codebase every time they are invoked.

EDITED to ADD [1], or someone completely inexperienced in professional development projects

[nctnico]

Automated unit tests which are part of a compilation process are one of the tools which can control quality of software. Code review is just a snapshot indeed.

[Sal Ammoniac]

Automated unit tests which are part of a compilation process are one of the tools which can control quality of software. Code review is just a snapshot indeed.

They're all part of the development process, along with using static analysis tools, etc.

Code reviews are a snapshot in a sense, but a useful one. We typically catch ~95% of the bugs that would otherwise make it into verification during code reviews. All commits to our source repository are reviewed individually, which keeps the review process fine grained and less of a burden. This process may not work for all development groups, but it's been very effective for us.

[tggzzz]

Automated unit tests which are part of a compilation process are one of the tools which can control quality of software. Code review is just a snapshot indeed.

They're all part of the development process, along with using static analysis tools, etc.

Code reviews are a snapshot in a sense, but a useful one. We typically catch ~95% of the bugs that would otherwise make it into verification during code reviews. All commits to our source repository are reviewed individually, which keeps the review process fine grained and less of a burden. This process may not work for all development groups, but it's been very effective for us.

Just so. We need all the help we can get, from whatever source.

Computers are rather good at automation of dull repetitive tasks, and should be used for such. Tools that unnecessarily introduce whole classes of problems are an unwelcome distraction and waste of the most valuable resource, brainpower; avoid such tools where there are alternatives.

[legacy]

Some people should be kept away from keyboards.

Sure. My job would be easier, and less stressful.

P.s. from the C world.
I am debugging SSH (secure shell from OpenSSH). A customer(1) needs to use it in his produces, and it crashes on a "musl" roortfs (it's not glibc, it's more like uclibc, experimental, but useful on PowerPC since glibc is too bloat, and uclibc has too many problems).

Sources are a mess 

Thanks god we have debugging symbols and GDB+DDD, but I still wonder *why* they don't conform to MISRA! Debugging would be easier by ten orders of magnitude at least.



(1) Naval Engineering field. They build cruise ships's equipment.

[legacy]

Code reviews only examine a single snapshot of a subset of the codebase.

We experimented a critical failure bug during system integration test from two different teams. One was European, the other was American.

ModuleA was integrated to ModuleB.
ModuleA (EU) used meters, ModuleB (USA) used inches.

The software went into "disable channels and halt", which means "unrecoverable critical failure, mission aborted"


Another problem we had: how can you really test abnormal high critical conditions?

We had this problem on a Mach2. This kind of firmware was DO178B level A, since the airplane speed was 2500 Km/h, with a lot of low level requirements classified "critical".

if the software does something wrong with CBIT (continuous built-in test, to assure the hardware is ok, and also the software is ok), it takes longer to resume (e.g. because of an overflow in the Cordic/BKM unit? it must NOT happen) , but a delay is critical when you are moving a 2500 Km/h because it makes the airplane to go out of its trajectory, which might be critical during a mission.

We have to care about safety, and mission. Both are a must, and they must not fail.

We did a full coverage, but we tested just a subset of the abnormal high critical conditions. In my report I wrote "test is not applicable for these sub cases" (e.g. what happens if the hardware on a module gets damaged during the attack ? how will it propagate its error to the main system ? Like we have planned and tested, or in a new un-predicted way ? Will it recoverable ?)

Which is a weakness, because there are conditions in the firmware which are not fully explored in their behavior after system integration. We just know how a module reacts on test-case's inputs.

[legacy]

Automated unit tests

What do you use? Cantata? CodePurify?

[tggzzz]

Which is a weakness, because there are conditions in the firmware which are not fully explored in their behavior after system integration. We just know how a module reacts on test-case's inputs.

As I am sure you are aware (but others appear not to be), emergent behaviour is an inherent and unavoidable problem, and "you can't (unit) test quality into a product".

(My favourite example of emergent behaviour is related to sand. Nowhere in the {specification,properties} of individual grains is it {defined,measured} that sand piles will form with a half-angle of ~35 degrees)

[legacy]

As I am sure you are aware (but others appear not to be), emergent behaviour is an inherent and unavoidable problem, and "you can't (unit) test quality into a product".

That's precisely *the* point!
You can't (unit) test quality into a product!
but you have to sign the report with your blood!

Good job, ain't it? 

[GeorgeOfTheJungle]

The button "unnotify" fro this thread is not working for me, I want to unsubscribe but I can't. Any ideas, please?

[tggzzz]

As I am sure you are aware (but others appear not to be), emergent behaviour is an inherent and unavoidable problem, and "you can't (unit) test quality into a product".

That's precisely *the* point!
You can't (unit) test quality into a product!
but you have to sign the report with your blood!

Good job, ain't it? 

I rather like the (possibly apocryphal) bridge acceptance test: the architect/engineer had to stand under it as all the supporting scaffolding was being removed.

I have seen something similar recently: a local glider inspector insists that after he has repaired/recertified a glider, he is the first one to fly it.

[legacy]

I have seen something similar recently: a local glider inspector insists that after he has repaired/recertified a glider, he is the first one to fly it.

LOOOOOL 

[Mechatrommer]

I rather like the (possibly apocryphal) bridge acceptance test: the architect/engineer had to stand under it as all the supporting scaffolding was being removed.
I have seen something similar recently: a local glider inspector insists that after he has repaired/recertified a glider, he is the first one to fly it.

are you saying that you will accept the test on yourself if its developed in Ada?

[tggzzz]

I rather like the (possibly apocryphal) bridge acceptance test: the architect/engineer had to stand under it as all the supporting scaffolding was being removed.
I have seen something similar recently: a local glider inspector insists that after he has repaired/recertified a glider, he is the first one to fly it.

are you saying that you will accept the test on yourself if its developed in Ada?

Now you are just being silly; stop trolling.

Read (and understand) what I have written elsewhere in this thread and you will find you already know the answer.

[NorthGuy]

are you saying that you will accept the test on yourself if its developed in Ada?

Now you are just being silly; stop trolling.

Read (and understand) what I have written elsewhere in this thread and you will find you already know the answer.

Here's what you said elsewhere in this thread:

Please try to imagine what you would do and what choices you would make if your code was responsible for, say, your mother's life.

Doesn't look too much dissimilar.

[tggzzz]

are you saying that you will accept the test on yourself if its developed in Ada?

Now you are just being silly; stop trolling.

Read (and understand) what I have written elsewhere in this thread and you will find you already know the answer.

Here's what you said elsewhere in this thread:

Please try to imagine what you would do and what choices you would make if your code was responsible for, say, your mother's life.

Doesn't look too much dissimilar.

That is indeed one thing I've said. But not the only one. Look again, and find more substantive points.

But perhaps your contribution should simply be seen in the light of your previous point in https://www.eevblog.com/forum/microcontrollers/2017-make-with-ada-competition/msg1214513/#msg1214513

[NorthGuy]

That is indeed one thing I've said. But not the only one. Look again, and find more substantive points.

Not by much.

[Mechatrommer]

so the conclusion is... you can still shoot your foot with Ada, class dismissed. thank you everybody for your participation in this contest.

[tggzzz]

That is indeed one thing I've said. But not the only one. Look again, and find more substantive points.

Not by much.

I can only echo this statement: https://www.eevblog.com/forum/microcontrollers/2017-make-with-ada-competition/msg1214885/#msg1214885

[Kalvin]

so the conclusion is... you can still shoot your foot with Ada, class dismissed. thank you everybody for your participation in this contest.

Of course, it would stupid to argument otherwise. However, not all languages are equal. C has much more opportunities to shoot yourself into foot compared to Ada, and C++ provides you with many opportunities to shoot yourself into back.

[nctnico]

so the conclusion is... you can still shoot your foot with Ada, class dismissed. thank you everybody for your participation in this contest.

Yes, you can most certainly cut yourself with a very dull knife. You just have to push much harder 

[FrankBuss]

Of course, it would stupid to argument otherwise. However, not all languages are equal. C has much more opportunities to shoot yourself into foot compared to Ada, and C++ provides you with many opportunities to shoot yourself into back.

It's not "shoot yourself in the back"

http://www.toodarkpark.org/computers/humor/shoot-self-in-foot.html

C:

You shoot yourself in the foot.
You shoot yourself in the foot and then nobody else can figure out what you did.


C++:

You accidentally create a dozen instances of yourself and shoot them all in the foot. Providing emergency medical assistance is impossible since you can't tell which are bitwise copies and which are just pointing at others and saying, "That's me, over there."


Ada:

If you are dumb enough to actually use this language, the United States Department of Defense will kidnap you, stand you up in front of a firing squad, and tell the soldiers, "Shoot at his feet."

After correctly packaging your foot, you attempt to concurrently load the gun, pull the trigger, scream, and shoot yourself in the foot. When you try, however, you discover that your foot is of the wrong type.

You scour all 156e54 pages of the manuals, looking for references to foot, leg, or toe; then you get hopelessly confused and give up. You sneak in when the boss isn't around and finally write the damn thing in C. You turn in 7,689 pages of source code to the review committee, knowing they'll never look at it, and when the program needs maintenance, you quit.

[tggzzz]

You scour all 156e54 pages of the manuals, looking for references to foot, leg, or toe; then you get hopelessly confused and give up.

Unfortunately that's also true for C++, where "manuals" are the combination of "this year's language definition" plus "compilerX manual" plus C++/compilerX forums plus "C++ FQA". You are left wondering if it is a compiler bug or your not understanding the interactions between all the C++ "features".

You decide to become a manager, and absolve yourself of responsibility by offshoring development to "highly experienced" development teams working for 1/10 of the salary. You leave that job after 2 years - in time to claim management success but before the "suboptimalities" become evident. Your successor has to deal with the "suboptimalities", and deflects blame onto the person that set up the arrangement.

[legacy]

Yup, we are all doomed with C++.
All of us 

( I am considering to move my core business into the field of ice cream sellers
At least it will be more "cool"  )

[Vtile]

It is funny to follow these "my dick is bigger than yours" arguments/fights at which programming language is the best for everything. 

Real Programmers use FORTRAN. Quiche Eaters use PASCAL.

[tggzzz]

It is funny to follow these "my dick is bigger than yours" arguments/fights at which programming language is the best for everything. 

It is sad when that happens.

I learned decades ago that engineers should know several different tools (in this case languages) so that they can choose the most appropriate one for their next task. However, too often people get wedded to the tools they know, and mutate "I could use X to do this" into "you should use X to do this".

[Vtile]

... and REAL ENGINEERS use relays.

[Mechatrommer]

I learned decades ago that engineers should know several different tools (in this case languages) so that they can choose the most appropriate one for their next task. However, too often people get wedded to the tools they know, and mutate "I could use X to do this" into "you should use X to do this".

yes for example this...

It is supposed to be less prone to making stupid mistakes like buffer overruns. Think about a gun which won't fire when pointed at your foot.

[tggzzz]

I learned decades ago that engineers should know several different tools (in this case languages) so that they can choose the most appropriate one for their next task. However, too often people get wedded to the tools they know, and mutate "I could use X to do this" into "you should use X to do this".

yes for example this...

It is supposed to be less prone to making stupid mistakes like buffer overruns. Think about a gun which won't fire when pointed at your foot.

It appears that something is being lost in the (two) translation(s).

[legacy]

... and REAL ENGINEERS use relays.

Well, it was hard to convince people in the railway business to adopt transistors instead of relays.

Why? Because of the behavior of the relay when it fails: it does it as an open circuit (1), so the train comes into a complete stop. People will be angry but neither dead nor hurt.

When a transistor fails, it does as a short circuit, so the train come across into the stop like a deranged dog, and it will end into an epic disaster.

You can imagine the effort we had to take at promoting the DigitalInfil (made by DSPs, MPUs, a lot of transistors and ... software) for a train which runs at 270-300 Km/h!

At the beginning it was NoGO! (well, they were afraid, because, as you know, E = m * v^2, it's a lot of kinetic energy that a body like a train + passengers possess by virtue of being in motion)

So, we tried to convince them talking about DSPs in redundant configuration, plus a "voter-unit" (special trusted hardware), and firmware written in C, applying MISRA and a similar certification to the DO178B I quoted for airplanes and helicopters.

We spent four years testing the unit in abnormal conditions, to prove it's safe! Also the voter contains relays, so it's intrinsically safe, but the software must be checked and verified to enforce the safety.

And, for your && their pleasure, at the top, in the application layer, we put a software written in Ada 


(1) thanks to the gravity!

when a relay decides it's the time to break itself, its coil is not able to contrast the gravity force which pushes the lower lib of the contact in the direction of the ground while the upper lib is fixed in its position. As result, it's open. An open circuit 

[tggzzz]

... and REAL ENGINEERS use relays.

Nah. Real engineers use fluidic logic gates. They work with gas at ~2000psi.

I once did a study into replacing fluidic logic with microprocessors, and concluded it would be a bad idea. There are significant advantages to fluidic logic in unmanned environments with flammable gasses.

[ealex]

personal experience (sorry for the long post ) :

bug 1:
3'rd party embedded os that used some values stored in memory to decide if it's a cold or warm boot:
if ( 0xDEAD == ram[0] && 0xBEEF == ram[1] ) => warm boot. ( they wanted to be "safe" )
in their case, for some reason " && " was actually " || " -> so the code would think that it was a warm boot when only half of the conditions where met so it skipped over some of it's initialization steps and fail some time after when it tried to run code from peripheral space

on some mcu's the RAM, after a cold boot, would tend to have 0xBEEF in it ... one in several thousands ...
a nice and frustrating bug ... i think i simulated 1000000 hours of run-time on all the dev boards we had until we got a production unit that failed in the factory - that board failed 5/10 cold boots and could finally find the problem.

in this case no tool would have been able to catch it ...


bug 2:
CAN frame that contained a size byte and some payload.
some application code got the can frame, extracted the size, done some math on it then memcpy from the frame buffer to an array.
well ... sometimes the CAN frame would have a size of 0 ( not documented behavior ) ... -> memcpy with size -1
the kernel killed the application, but only after if corrupted some shared memory that was mapped in the application space and used as a very fast ipc.
=> the code that handled the ipc(mine) was the one that started complaining that someone corrupted it's data => "it's your bug, not mine"

guess who had to spend a "lovely" evening replaying hour-long CAN traces to reproduce / figure out what CAN frame was generating the issue and then finding out where it's failing ...

in this case :
- basic defensive programming would have fixed it from the start, instead of "i'm a high level C++ linux application programmer, input data is always right so the bug is not in my team's code" ( you know the speech )
- Ada might have helped ... if the client actually gave a damn about tools and dev time lost to digging out stupid errors
- review - only if the reviewers have the proper mind set


bug 3:
a simple buffer - a byte array that stored data until all of the chips on the board where up and running.
in some very rare occasions - like 1 in 10000 cycles one of the chips took way longer than expected and the data rate on the input bus spiked -> the buffer overflowed by 1 byte.
just enough to overwrite some stuff from an 3'rd party eeprom emulation library -> the library happily trashed half of the attached flash memory.
on the next boot you had no more system settings or identification data ... no complete failure but you lost some important functionality

again, caught on field and reproduced after days of repetitive testing - it's a joy to work on systems that are not predictable

- review ... maybe, the buffer was already 2x the worst we could estimate
- testing ... you end up having to simulate the entire solar system if you need to be 100% sure
- defensive programming : yes, if your constantly enforce this.
- run-time range checks - certainly yes - the cost of lost time + updating all devices that are already on the field might be greater than a full Ada license + training + round the world 5 stars company payed cruise for the team that found the bug

=>
there are no magical solutions.
you can make horrible code with the best tools if you rush it and don't give a damn about the result.
or you can make an almost perfect system with assembler and a piece of string as a debugger, if you work on it your entire life.

also, there's the question of cost : how expensive is this failure ?
if your toyota decides to go full throttle for no apparent reason you get an ugly accident with several victims
if your rush-hour filled to the brim subway decides to go full throttle and "extend the tunnel" ... you'll need more than a mop and a bucket to clear up the mess.
i've been in a subway train that had a software crash - the doors where no longer responding, the mechanic manually opened some of them via the emergency release.
he had to power cycle the train to get it going again.


regarding rail-road relays:
 - the are "gravitational relays" - there is no spring to pull the armature in the off position - the weight of the armature does this, so they work only in a specific orientation
 - the contacts are made from materials that do not weld - graphite and silver for example, so they'll disconnect even if the contact points are white-hot

[tggzzz]

personal experience (sorry for the long post ) :

No need to apologise.

With your example #1, I wonder if using a stricter language (i.e. one that shows more bugs during compilation) would have encouraged or discouraged a mentality where people don't make presumptions that are justified by "it works" (a.k.a. I haven't seen it fail, yet).

Example #2: well, yes

Example #3: yes indeed. As you indicate, you can't test quality into a product. Also sometimes there are good system reasons for minimising buffer size.

And "cost effectiveness" is indeed a very important consideration. A particular problem is where the cost consequences are paid by someone else (i.e. an economist's "externality"). In that case the perpetrator has little incentive to avoid mistakes. We all know too many examples of that

[mubes]

Thanks for bringing this conversation back to more interesting material. It is indeed the case that where I live in the real world things go wrong on all sorts of interesting and unpredictable ways. I know plenty of Happy-Flow-Programmers who will give you a system that will work perfectly for 99 times out of a hundred and I know plenty of, frankly arrogant, programmers who think they produce bug free code. Neither of those is that useful and anyone who comes to interview with the attitude of "I'm a great programmer, my code is bug free" might as well have saved themselves the cost of the bus fare.

In the best scenario you have weather-worn programmers who know that it's the nasties that catch you out, and who are humble enough to know that they themselves will make mistakes. Unfortunately those greybeards tend to have seen so many programming fads come and go that they are pretty cynical about trying new stuff, despite the fact that modern languages and tools could undoubtedly help them (We had one guy who would _not_ move from Windows 3.11 until I physically disconnected him from the network as a security risk).  The best way to get these people to try new stuff is one bite at a time...which comes back to my original question about GPL; having to make a significant investment in unproven (to me personally, the only judge that counts) technology with unproven benefits is not going to happen, I'll just stick with my c compiler, thanks. There is no point in you wheeling out PowerPoint, statistics and papers showing me how good the alternatives are....the authors of those documents are not going to be the ones standing at a roadside, in a plane or down a mineshaft trying to figure out why 1+1 seems to become 4.

Defensive languages are just starting to hit the embedded space  properly (e.g. rust). As that community is finding, if you give us a way to reverse slowly and carefully into something new and you will find yourself with a set of powerful evangelists with significant influence over the spending decisions of their organisations....but if you demand 'faith' and upfront investment of anything  other than time then ain't gonna happen.

Dave

[tggzzz]

Thanks for bringing this conversation back to more interesting material. It is indeed the case that where I live in the real world things go wrong on all sorts of interesting and unpredictable ways. I know plenty of Happy-Flow-Programmers who will give you a system that will work perfectly for 99 times out of a hundred and I know plenty of, frankly arrogant, programmers who think they produce bug free code. Neither of those is that useful and anyone who comes to interview with the attitude of "I'm a great programmer, my code is bug free" might as well have saved themselves the cost of the bus fare.

Yes indeed. Fortunately such cowboys are relatively easy to weed out, provided a competent engineer is doing part of the interviewing.

In the best scenario you have weather-worn programmers who know that it's the nasties that catch you out, and who are humble enough to know that they themselves will make mistakes. Unfortunately those greybeards tend to have seen so many programming fads come and go that they are pretty cynical about trying new stuff, despite the fact that modern languages and tools could undoubtedly help them

I'm definitely in that category, but I have always been on the lookout for genuine improvements. I've occasionally found them and pounced on them: C in '81, OOP in '85 and '86, Java in '96, and recently xC. The latter is a triumphant "reinvention" of 70s advanced technology (CSP), by some of the people that were responsible back then

(We had one guy who would _not_ move from Windows 3.11 until I physically disconnected him from the network as a security risk). The best way to get these people to try new stuff is one bite at a time...which comes back to my original question about GPL; having to make a significant investment in unproven (to me personally, the only judge that counts) technology with unproven benefits is not going to happen, I'll just stick with my c compiler, thanks. There is no point in you wheeling out PowerPoint, statistics and papers showing me how good the alternatives are....the authors of those documents are not going to be the ones standing at a roadside, in a plane or down a mineshaft trying to figure out why 1+1 seems to become 4.

I well remember set of presentations of optical fibre measurements being made in lab conditions. My customer then showed a picture of where he would be making his measurements: in a hole in the ground, optionally with water sloshing around

Or, more recently, a company where one of their customers had a tendency to throw chairs around.

Defensive languages are just starting to hit the embedded space  properly (e.g. rust). As that community is finding, if you give us a way to reverse slowly and carefully into something new and you will find yourself with a set of powerful evangelists with significant influence over the spending decisions of their organisations....but if you demand 'faith' and upfront investment of anything  other than time then ain't gonna happen.

If you regard Ada and SPARK and similar as "defensive" and "embedded", they have been around for >30 years!

Rust is, in my opinion, not as good for parallel programming on multicore systems as CSP/Occam/xC. If you want hard realtime behaviour, then the XMOS multicore processors will guarantee that too.

[mubes]

I'm definitely in that category, but I have always been on the lookout for genuine improvements. I've occasionally found them and pounced on them: C in '81, OOP in '85 and '86, Java in '96, and recently xC. The latter is a triumphant "reinvention" of 70s advanced technology (CSP), by some of the people that were responsible back then

<SNIP>

If you regard Ada and SPARK and similar as "defensive" and "embedded", they have been around for >30 years!

Rust is, in my opinion, not as good for parallel programming on multicore systems as CSP/Occam/xC. If you want hard realtime behaviour, then the XMOS multicore processors will guarantee that too.

Ah, it seems my beard is of similar vintage...although I only go as far back as things like Transputer and VIPER etc. Way back I designed a whole comms system based around the T414 and the worm-routeing stuff that it could do. That chip was so innovative and the channel based comms infrastructure was _really_ clever to my young eye.  Until a little bit of Google I had no idea that the XMOS xC stuff was based on similar concepts (why I love fora like this!)....I can see I need to pull out a few old logbooks and do a bit of reading.  Rust is really dealing with a different set of problems to the CSP-abstractions; They addressed process isolation and message passing in a very elegant way, wheras Rust seems to be targetted much more at addressing the fallout you get from closely coupled processes interfering with each other....a problem you simply don't have if you follow a CSP (OCCAM/xC or Erlang-style) approach. The work that's being done over at http://blog.japaric.io/fearless-concurrency/ is interesting though...but does seem to have a 'safe-C' rather than fundamental new approach feel to it.

DAVE

[tggzzz]

I'm definitely in that category, but I have always been on the lookout for genuine improvements. I've occasionally found them and pounced on them: C in '81, OOP in '85 and '86, Java in '96, and recently xC. The latter is a triumphant "reinvention" of 70s advanced technology (CSP), by some of the people that were responsible back then

<SNIP>

If you regard Ada and SPARK and similar as "defensive" and "embedded", they have been around for >30 years!

Rust is, in my opinion, not as good for parallel programming on multicore systems as CSP/Occam/xC. If you want hard realtime behaviour, then the XMOS multicore processors will guarantee that too.

Ah, it seems my beard is of similar vintage...although I only go as far back as things like Transputer and VIPER etc. Way back I designed a whole comms system based around the T414 and the worm-routeing stuff that it could do. That chip was so innovative and the channel based comms infrastructure was _really_ clever to my young eye. 

I wouldn't get too uptight about the distinctions between CSP, Occam and Transputers: they were a synergistic whole. If you liked them, you'll feel very much at home with xC and xCore processors.

Until a little bit of Google I had no idea that the XMOS xC stuff was based on similar concepts (why I love fora like this!)....I can see I need to pull out a few old logbooks and do a bit of reading.  Rust is really dealing with a different set of problems to the CSP-abstractions; They addressed process isolation and message passing in a very elegant way, wheras Rust seems to be targetted much more at addressing the fallout you get from closely coupled processes interfering with each other....a problem you simply don't have if you follow a CSP (OCCAM/xC or Erlang-style) approach.

Always wanted to use Erlang, but never had the opportunity.

The work that's being done over at http://blog.japaric.io/fearless-concurrency/ is interesting though...but does seem to have a 'safe-C' rather than fundamental new approach feel to it.

I've had a quick skim of that URL, and RTFM doesn't feel all that different: bog-standard processors, cooperative multitasking, priorities, now while (1) {} task loops. Having said that, I would feel more comfortable if there were more many-cored processors out there. Bit of a chicken and egg.

[legacy]

OCCAM/xC or Erlang-style

yup, things I have in my todo-list. But the goddamned linux support for customers  is so time-consuming that it's already consuming all my energy. Since OS like VxWorks and linux are written in C,and so it is for most of the userland, then I am still blocked with C.

Thanks god I can use Ada when I am requested to provide consultancy to my customers, but it seems no chance to learn new languages

The only customer who uses Erlang is related to facebook's stuff, but I don't know what he does in details 

[tggzzz]

OCCAM/xC or Erlang-style

yup, things I have in my todo-list. But the goddamned linux support for customers  is so time-consuming that it's already consuming all my energy. Since OS like VxWorks and linux are written in C,and so it is for most of the userland, then I am still blocked with C.

Thanks god I can use Ada when I am requested to provide consultancy to my customers, but it seems no chance to learn new languages

The only customer who uses Erlang is related to facebook's stuff, but I don't know what he does in details 

It can, rightly, be difficult to suggest that a customer "swims against the stream"

With one exception I've learned new languages in my spare time, and later been in a good position to get interesting jobs with "early adopters"; hence professionally using C in 82, Smalltalk/ObjectiveC in 86/87, and Java in 97.

It is unsurprising that I also used Java in a very Erlang-like style - for telecoms infrastructure.

[orin]

All I wanted to do was an FFT...

So, I got an STM32F469 discovery board, downloaded the Windows drivers for the board, Ada_Drivers_Library, GNAT GPL2016, ran GPS with the demo project, told it to download to the board and... it sulked.

Somewhere it suggested running st-util first so I did that.  Download to the board... OK now that works but an st-util instance has crashed.

Several days later after getting the st-util code, making it run under Visual Studio 2017 (because VS2017 is free for open source development and I have it installed), it no longer sulks and I can download/run the examples.  See https://github.com/orinem/stlink if you want the fixed st-util; hopefully it will be merged back into https://github.com/texane/stlink soon.

Now I find an Ada FFT implementation... this looks good: https://rosettacode.org/wiki/Fast_Fourier_transform#Ada - should be really portable from a 'rosetta' named site.  Nope.  It manages to need Ada.Numerics.Complex_Arrays and Ada.Numerics.Real_Arrays which are not in any of the the Ada_Drivers_Library embedded run times that I can find.  Why not?  The generic versions are there.  Some digging and I found the relevant ADS files.  Copy the contents into my project and remove the Ada.Numerics decorations and we're off.  Not so fast.  Forget about Ada.Complex_Text_IO.  Not happening.  So remove it and format the strings by hand and finally, I have something that builds and runs and does an FFT.

Why would I want an FFT?  How about to do a waterfall display for one of these radios: http://www.wb5rvz.org/  The ARM processor should have plenty of power.

Now will someone explain what this actually does?  It looks as bad as a C++ template definition to me.

Code: [Select]

with Ada.Numerics.Generic_Complex_Arrays;
 
generic
   with package Complex_Arrays is
      new Ada.Numerics.Generic_Complex_Arrays (<>);
   use Complex_Arrays;
function Generic_FFT (X : Complex_Vector) return Complex_Vector;

[FrankBuss]

So this is my entry for this year:

http://www.makewithada.org/entry/midisynthesizer

Well, this didn't went so well. I don't know if I should continue to use Ada, especially when doing embedded programming.

[Sal Ammoniac]

I don't know if I should continue to use Ada, especially when doing embedded programming.

I evaluated their Ada toolset to see if it was something worth considering for my company's next project and concluded that the tools were too expensive and didn't really offer much of anything over C to consider switching to. Another big issue would be finding people familiar with it. Of the dozens of resumes/CVs I've received over the past few months for an embedded developer opening in my department, not one listed Ada experience.

[legacy]

GNAT

yup, no doubt GNAT sucks if compared to SGI-ADA, or GreenHills-ADA, for the typical hipster term "ecosystem", which is just an hipster term, but practically it makes the difference for the final user.

[FrankBuss]

Maybe they didn't list Ada in their CVs  because they didn't want to program in Ada

[legacy]

Maybe they didn't list Ada in their CVs  because they didn't want to program in Ada

LOL 

well, yes ... it's also the reason why it's on the third line on my CV

I mean ...
you should take an umbrella in case it rains
you should be prepared to throw yourself out of the window in case
you get GNAT as ADA-compiler on your desk
(because it's really depressing, but some companies can't buy commercial ADA)

so, you should be careful on what you are indirectly asking by presenting ADA on your CV 

[legacy]

(may be I am still in time to move "ADA" in the last page of my CV
reducing the font-size to super-super-small  )

[FrankBuss]

you should be prepared to throw yourself out of the window in case
you get GNAT as ADA-compiler on your desk

What's wrong with the GNAT compiler? I tried the latest version which was packaged in Debian and there were some features missing, because some code couldn't be compiled, but the package was not updated for some years now. Then I tried the free 2017 compiler from http://libre.adacore.com , both for Linux 64 bit and for ARM, and it works better. Only complain so far for the ARM version is that the binaries are getting much bigger than I'm used to for the same program in C, like 480 kB for my synthesizer test, which was like 40 kB when I tried this in C. But I didn't analyze it more, maybe it has just a big runtime footprint. The GPS IDE is not bad either. Of course, you can't compare this with something like Keil uVision, but I was able to work with it. It has the usual modern features like auto-completion, go to symbol declaration, pretty print formatting, integrated debugger etc.

[legacy]

What's wrong with the GNAT compiler?

it sucks when you try to compile it(1), and when you want to use it for serious stuff. It's not productive, it's seems a shitty compiler with a shitty library set, and when you try to port it to a new target (which means x86 only, arm, hppa, mips ... forget it) hurts a lot, in fact ... see how many people are describing success in that. Not so many? Yup, just a few. A lot of effort for poor results!


(1) recompiling gnat

Code: [Select]

2016-12-10--16-12-50---2016-12-10--19-32-20 - emerge  =dev-lang/gnat-gcc-4.9.3 - success - root
2016-12-13--12-04-03---2016-12-13--12-05-42 - emerge  =dev-lang/gnat-gcc-4.3.5 - failure - root
2017-08-24--10-43-15---2017-08-24--11-06-49 - emerge  =dev-lang/gnat-gcc-4.3.5 - failure - root

gnat v4.3.5 is still bugged in the stage2 (thus my Overlay still fails on modern environment), and unfortunately GHDL v0.29 needs gnat v4.3: it means I am obliged to do dirty job in order to fix it someway. Dirty job = workaround. Not so good!

This, when I wear the "system admin" hat, while as "user developer" ... well ... using gnat is not so suffering experience, but ... it's for sure by ten orders of magnitude more frustrating than every commercial ADA compilers (SGI and Green Hills) I have ever used! Especially for parallel programming, and this also because libraries are more coherent.

For sure GNAT is not a good choice for business neither for hobby (if you can't allocate time for that / or if you just want to relax) since it's very irritating!

[legacy]

can't compare this with something like Keil uVision

For business, I would compare with AdaMulti! And in fact The GNAT Programming Studio (aka GPS) sucks: it's less productive by 10 orders of magnitude, especially the debugger part.

Thus my reason to stay away from companies who don't have money to buy serious tools.

[orin]

you should be prepared to throw yourself out of the window in case
you get GNAT as ADA-compiler on your desk

What's wrong with the GNAT compiler? I tried the latest version which was packaged in Debian and there were some features missing, because some code couldn't be compiled, but the package was not updated for some years now. Then I tried the free 2017 compiler from http://libre.adacore.com , both for Linux 64 bit and for ARM, and it works better. Only complain so far for the ARM version is that the binaries are getting much bigger than I'm used to for the same program in C, like 480 kB for my synthesizer test, which was like 40 kB when I tried this in C. But I didn't analyze it more, maybe it has just a big runtime footprint. The GPS IDE is not bad either. Of course, you can't compare this with something like Keil uVision, but I was able to work with it. It has the usual modern features like auto-completion, go to symbol declaration, pretty print formatting, integrated debugger etc.

I couldn't make the 2017 GPL version debug on an STM32F469 discovery board.  I had to retreat to the 2016 version with my fixes to st-util and even then, it's started sulking if I don't start st-util separately.

The GPS IDE will hang completely on OSX Sierra with nothing more than pasting some code!  I ended up editing files outside of GPS and letting it pick them up when they changed.  That cut down the hangs.

BUT, FWIW, I did manage to link to some ARM CMSIS functions (32 bit float FFT and some related functions) and time/display a 1024 point FFT.  I also managed to encode/decode some PSK31 by porting the PSKCore DLL source to Ada.  I've yet to feed it real data from the ADC though - that's work in progress.

I found writing to the display on the discovery board to be painfully slow - it was looking like there was plenty of time to do the DSP but I'd only be able to update the display more than two or three times a second... most of which would be spent in the driver library waiting. 

The optimized code looked pretty good with the FIR filters turning into multiply-accumulate instructions, but _some_ library complex arithmetic doesn't inline (divide by real for example) and was better done 'by hand' by dividing the real and imaginary parts separately.

Edit: NOT 'more than'

[legacy]

I found writing to the display on the discovery board to be painfully slow

Yup, and! worse still (for me) it becomes painful freaky slow on multi processing, which *IS* the reason why I'd like to use GNAT on machines like Parallela. Of course I can't recompile GNAT, I have to trust ADA-core, thus .. tools-binary, no fix.

[Sal Ammoniac]

Just a reminder everyone, it's Ada, not ADA. It's named after a person (Ada Lovelace) and is not an acronym.

[FrankBuss]

So this is my entry for this year:

http://www.makewithada.org/entry/midisynthesizer

The extended deadline helped me to get a first version working



But I saw already other entries and they are very polished, with lots of useful functions, excellent documentation etc., I guess I won't win anything. Was still fun to start learning how to program in Ada.

[JPortici]

bumping, because.
I stumbled upon makeWithAda again.
I looked at the supported boards and to my surprise the STM32F4 discovery is supported.
I happen to have one of these.
What could i do besides the blinkies that helps me understand the language and its advantages better?
something simple, in the sense that i don't have to connect stuff to the board..

[newbrain]

Just a reminder everyone, it's Ada, not ADA. It's named after a person (Ada Lovelace) and is not an acronym.

Oh, I thought it stood for "Accidentally Destroyed Ariane"