Re: Ada Successor Language

[Luke A. Guest <laguest@archeia.com>]

Shark8 <> wrote:

> 
> (1)	The Meta language
> (2)	The Generic Language
> (3)	The Concurrent/Parallelism language
> (4)	The Proving language [SPARK]
> (5)	The HW/Representation language
> 
> ----------
> Your thoughts?
> 

There’s a guy, eLucian, wanting to implement his own language because Ada
is too complex, his is level, where he has defined 5 compilers all written
in different languages with different capabilities. I don’t agree with
that, it’s way too complex! Plus, he wants others to do the work while he
makes the money on it, no thanks.

You could just use SML and implant those five things with that. But I
disagree there too.

Any successor needs to be much simpler in design but not scope. We should
retain multi-paradigm programming imperative and OOP, but increase that
with FP - I’m coming around to FP more, but it’s not the be all and end
all.

The grammar needs to be easier to implement so that tools can be developed
much more quickly. Simplify the grammar, maybe look at python and ruby for
hints on syntax structure.

Any successor needs to retain what Ada can do but also do things better
where Ada struggles and add features for modern programming. This new
language needs to retain the ability to develop anything from small
embedded to server, distributed and bigger applications.

One thing which makes Ada complicated from the compiler perspective is the
ability to take multiple compilation units at a time and the fact it’s
defined as being able to take them in one source file, I’d simplify that
and separate out the idea of a program, I do like not having to define a
“main” though.

I’ve said it before and it needs to be said again, a new language needs to
be Unicode from the start using UTF-8, text manipulation in Ada is painful
at this current stage. For embedded we can also define 8-bit character
sets. It needs real strings and a fully capable library.

We should adopt the common C shorthand operators, -=, +=, etc. Which means
picking a different /= operator, may as well use != here too.

Being able to override ‘image ‘value would be really useful, for custom
types, e.g. outputting a record in json format for example. Imagine a
custom image for an enumeration!

Parallel blocks, yes I know it’s coming, but it’s something that should
still exist in any new language. In fact as much tasking capabilities as
possible given how many cores we have now.

Keep the concept of restrictions and profiles/subsets.

Keep packages.

Support endian-ness from the start even on primitive types, I.e. not just
records.

The runtime needs to be permissively license to attract users.

My initial thoughts. I have other frustrations I can’t think of right now.