Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Lucretia <laguest9000@googlemail.com>]

On Thursday, 10 August 2017 06:41:56 UTC+1, G.B.  wrote:
> On 09.08.17 23:08, Luke A. Guest wrote:
> 
> > 1) endian aspects.
> > 2) full Unicode support including sorting, character db, regexps, bounded
> > and unbounded need, iterators for code points, graphème clusters, word
> > boundaries, bidi, etc.
> 
> Unicode support can be a joint effort without major investments of time
> and money:
> practically adressing Randy Brukardt's remark that this is going to
> require politics, there is libiconv, the Unicode related designs done
> for the Swift language, java.text.*, and so forth.
> 
> > 3) cross platform GUI.
> 
> Care to elaborate why? Having seen cross platform GUIs fail in all but

I already explained in a previous post, the post does not just relate to 8 but to all my points.

> corporate surroundings, and possibly games, even then, new proprietary

In games, companies either use a third party UI or write their own, I know, because I used to work in games.

> libraries like Metal seem to entail non-portable program designs again.

See the Vulkan portability initiative https://www.khronos.org/blog/khronos-announces-the-vulkan-portability-initiative

> A portable abstract design of UIs could be economically more promising.
> It fits the OS's ways and customers like that. Also removes one layer
> of politics, support, and software, at least in parts.

This would be for desktop / mobile domains, not embedded. Remember that Ada was designed to replace all the languages the DoD were using for all application domains, not just embedded[1].

> > 4) multiple return types:
> >
> >   function Blah return Integer, Float;
> 
> Should other parameters in the subprogram's profile be non-variant,
> co-variant, or contra-variant, or just what the programmer specifies?

This is for the language designers to determine.
 
> > As an example.
> >
> > 5) Lambdas for the people looking for new (i.e. Old) trendy features.
> 
> Would you want lambdas that can be returned, or assigned? Or just
> lambdas that are unnamed expression_function-s of Ada 2012?

This is for the language designers to determine.

I know people want this, because I've seen this in this newsgroup.
 
> > 6) support for offloading to gpu's.
> > 7) memory mapped streams.
> > 8) networking support packages.
> 
> It seems as if C, the language and library, has very few of
> these additions and yet C is a good choice for embedded needs
> if judging by market share. How do C programmers port their
> networking code from Unix to Windows? Could Ada support packages
> provide convincing advantages (politics...) because of the language?

You can't really compare C and Ada, C is low-level, Ada is very high-level. C already has everything I've already noted, yes as third party libs, but other high-level languages have them in their standard library, this is what I'm talking about.

Again, you seem to be very myopic in that C and Ada are only used in embedded. I refer you back to [1] above. You seem to have forgotten this.

Windows has sockets, it also has other networking libs available, people just tend to create platform specific ports on top of those libs, Ada could do the same.

Don't you people want Ada to grow into more areas? I've seen people look at the language because it seemed interesting to them, then ask, "Does Ada have a GUI lib?" or "Does Ada have OpenGL?" or "Does Ada have DirectX?" etc. When they are told no, they leave never to return, because this is what they want in a language's runtime.

Seems to me you people only want Ada to stay hobbled in the embedded corner. If that's the case, I think it's time to start considering a new language, but there aren't any that have the features I want.