Quote from Dave Voorhis on April 21, 2021, 11:36 am

Quote from dandl on April 21, 2021, 10:56 am

Quote from Dave Voorhis on April 21, 2021, 8:22 am

Quote from dandl on April 21, 2021, 12:44 am

It wasn't meant to be an analysis. Just pointing out that your bullet points are vague enough to mean anything from cutting-edge future advancements to crude legacy languages. E.g., "getting rid of ... type declarations" could mean type inference per modern languages, or literally no type declarations and "type inference" of a handful of primitive types per vintage BASIC.

I think you're trying to read them backwards, as a list of inclusions rather than a list of exclusions. Assume you start with the latest Java/C#/etc: this is what we try to take out. There is another list of things we might want to add, including getting things back from C++ (meta, unions, type aliases, value types) and elsewhere.

I just mean they're vague, and subject to very broad interpretation.

Please, please, please do not bring back C++-style "meta", unions (if you mean what I think you mean), and type aliases. Java not having these is one of its strengths.

C++lets you do things (unsafely) that you can't do in Java. I want to be able to do them, but safely.

The meta I want is to solve this problem. I have just spent a couple of hours writing code like this for a large number of named variables:

Console.Writeln($"version="{a.Version}");
b.version = a.Version
Console.Writeln($"version="{b.version}");

This is debugging code, not production, and I don't care if the macro that does this for me offends your sensibilities. Simple text substitution is enough to save a mountain of typing, and we now have the tech that will allow us to do this safely. I want it.

Why can't you do it with a function/method/procedure?

No need to answer specifically, because my point is that whatever prevents you from simply defining (and using) a function/method/procedure and compels use of a macro (as a workaround!) is the problem that needs fixing. Macros should be considered an undesirable workaround for a language limitation, not a solution.

C unions did two things: structural overlays (which is actually undefined behaviour) and simple algebraic types (along with struct). I want the algebraic types: don't  you?

C unions are untagged. If used to simulate type unions, you have to manually implement the type tag and handling the type is manual, leading to potential errors -- your ad-hoc union says it's type x but it's actually type y. Hilarity ensues.

Real algebraic types are good. C unions aren't algebraic types.

C typedefs allow you to type check usage of primitive types. We used them extensively in Powerflex to manage the various compiler differences (such as signed/unsigned, short/long) but they're also really useful to distinguish (say) between an integer used as a count, one used as an index and one used as a length. There is no downside.

There are only downsides. They're a workaround better handled by type hierarchies, type assignment, and/or true substitutability, with (ideally) the ability to identify distinct-but-equivalent types.

But I mention that not to get into a debate about what should/shouldn't be included, but to point out that it's almost inevitable that everyone you ask will have a different vision of what should/shouldn't be included in some C++/C#/Java successor. What I think should/shouldn't be there will differ from what you think should/shouldn't be there, and likewise for Ant, Erwin, Tobega, etc., etc.

I think the best you can do here is write something that scratches your own personal itches, and hope that enough other developers share the same itches to appreciate your, er, itch-scratcher.

I have very few specific itches: whatever gives me safer-shorter-higher, meta and fits in will be just fine. But it's totally wrong to think about what to add until you know for sure what you're prepared to give up to get it.

Again, I think your focus needs to be on what scratches your itches; what gives you safer-shorter-higher, meta, and fits in, because I find almost all of your suggestions to be undesirable.

But that's me, and the fact that we differ on this is the essence of my point. Likewise, Erwin, Ant, Tobega, Hugh, you-name-it will no doubt have their own ideas of what the next language should be.

You do you.

No, the whole point is leave it to the compiler and stop worrying about it, so we can think about other things.

My point is simply that we sometimes want to be able to specify type annotations, and sometimes use type inference.

Again, upside down. You start from the preconception that need to know everything and be in total control. If you were designing Java you would include pointers and unsigned because 'sometimes you want to specify this and sometimes that'. Someone with better insight said no, you can't have them. My question is not what you want to add, but what you can allow to be taken away. What do you use routinely, which can be totally removed from 'next J' (because there more important things to think about)?

If I was designing Java (or a post-Java language) I would not include pointers and unsigned but I would definitely include the ability to specify type annotations because they really do improve readability. I routinely use type annotations and routinely elide them and use type inference. My goal is always to make my code as readable as possible -- indeed I see that as a fundamental purpose of programming; it's a way of stating requirements for other humans in a way that just happens to be executable -- and optional annotations are a key ingredient in that. I think they're very useful when used appropriately.

But if you don't, that's fine. You do you. Build your new language as you see fit.

That compels the reader to look in the API, which turns what could be simple code-reading into a painful festival of API lookups. Speaking as someone who spends a significant amount of time reading/maintaining legacy code, judicious use of explicit type annotations in this context is really, really, really helpful.

I wouldn't want to lose the ability to provide such annotations, when I feel they're appropriate to enhance readability.

So what does the compiler have to do for you give up your insecurity and stop looking? Why do you need to know? What mistakes are happening which a smarter compiler could avoid?

The compiler doesn't do anything. This isn't about the compiler. This is about allowing me to understand the code better, so I can modify it. When I see Pair<int, int> location = document.getOffset() I know immediately that I can use location.getKey() and location.getValue(). With only var location = document.getOffset(), I've got to look up document's getOffset() or get the IDE to do it for me. Ugh.

In short, the former code has given me useful semantic information that is otherwise elided. When I'm writing code, if I feel it might be useful to a future developer (who may or may not be me), I'll include the type annotation. If not, I'll use var and elide it.

Of course, this is a trade-off between readability vs conciseness and ease of change. Like almost all things in programming, trade-offs are involved, and when trade-offs are involved, personal preferences, priorities, and inclinations are involved. My inclination is to favour readability, even if it makes the code more verbose. If your inclination (here, at least) is to favour conciseness and ease of change, then perhaps the post-C++/C#/Java language I create or choose to use might be different from the post-C++/C#/Java language that  you create or choose to use.

That, of course, is perfectly fine.

Or, maybe the post-C++/C#/Java language one or both of us creates or uses will allow both, so the developer can decide.

That's perfectly fine too. Indeed, that's what C# and Java do.

Quote from tobega on April 21, 2021, 3:27 pm

Quote from dandl on April 21, 2021, 10:56 am

Quote from Dave Voorhis on April 21, 2021, 8:22 am

Quote from dandl on April 21, 2021, 12:44 am

It wasn't meant to be an analysis. Just pointing out that your bullet points are vague enough to mean anything from cutting-edge future advancements to crude legacy languages. E.g., "getting rid of ... type declarations" could mean type inference per modern languages, or literally no type declarations and "type inference" of a handful of primitive types per vintage BASIC.

I think you're trying to read them backwards, as a list of inclusions rather than a list of exclusions. Assume you start with the latest Java/C#/etc: this is what we try to take out. There is another list of things we might want to add, including getting things back from C++ (meta, unions, type aliases, value types) and elsewhere.

I just mean they're vague, and subject to very broad interpretation.

Please, please, please do not bring back C++-style "meta", unions (if you mean what I think you mean), and type aliases. Java not having these is one of its strengths.

C++lets you do things (unsafely) that you can't do in Java. I want to be able to do them, but safely.

The meta I want is to solve this problem. I have just spent a couple of hours writing code like this for a large number of named variables:

Console.Writeln($"version="{a.Version}");
b.version = a.Version
Console.Writeln($"version="{b.version}");

This is debugging code, not production, and I don't care if the macro that does this for me offends your sensibilities. Simple text substitution is enough to save a mountain of typing, and we now have the tech that will allow us to do this safely. I want it.

C unions did two things: structural overlays (which is actually undefined behaviour) and simple algebraic types (along with struct). I want the algebraic types: don't  you?

C typedefs allow you to type check usage of primitive types. We used them extensively in Powerflex to manage the various compiler differences (such as signed/unsigned, short/long) but they're also really useful to distinguish (say) between an integer used as a count, one used as an index and one used as a length. There is no downside.

But I mention that not to get into a debate about what should/shouldn't be included, but to point out that it's almost inevitable that everyone you ask will have a different vision of what should/shouldn't be included in some C++/C#/Java successor. What I think should/shouldn't be there will differ from what you think should/shouldn't be there, and likewise for Ant, Erwin, Tobega, etc., etc.

I think the best you can do here is write something that scratches your own personal itches, and hope that enough other developers share the same itches to appreciate your, er, itch-scratcher.

I have very few specific itches: whatever gives me safer-shorter-higher, meta and fits in will be just fine. But it's totally wrong to think about what to add until you know for sure what you're prepared to give up to get it.

I keep waiting for the revolutionary vision of how we should program in a safer-shorter-higher way, but we're still at a laundry list of incremental changes which we can't all agree are improvements.

So far, based on your requirements, I think I would recommend you to take a look at Ada. I think a lot would be won if we all did, but it's not exactly a new revolutionary thing.

Quote from Erwin on April 21, 2021, 10:38 pm

Quote from tobega on April 21, 2021, 3:27 pm

I keep waiting for the revolutionary vision of how we should program in a safer-shorter-higher way ...

One thing that always comes to mind when I see such proposals, is that we might have a language that instead of forcing the developer into

am_price_net := int(am_price_gross * pct_reduc * 100 + 0.5) / 100;

allows one to write

COMPUTE AM-PRICE-NET ROUNDED = AM-PRICE-GROSS * PCT-REDUC;

But for some strange reason people always think I'm being facetious when I say that.

Quote from dandl on April 22, 2021, 5:35 am

Quote from Darren Duncan on April 21, 2021, 9:34 am

Quote from dandl on April 20, 2021, 2:22 pm

Did you look at the Raku language yet?  I recommend it.  May very well outdo some of the other newer and niche languages on your final list.

We wrote quite a bit of Perl back in the day, to analyse log files from our test suites. We were getting files of 50m lines, on Windows and several flavours of Unix, we outgrew awk and Perl handled them well. I wondered what had happened to Perl 6. Thanks for the pointer.

This is a language with a heritage going back over 30  years, seeking to evolve so as to 'fix Perl' and 'remove warts'. That would place it outside my survey.

There seems to be no particular intent to make the language safer at compile time, because dynamic typing is always a fallback. I'm not sure whether the classes and roles in Raku would equate to the TTM type system, or permit type inference. It still reads like a scripting language (Python-ish) rather than a novel general application development language of the kind I've been looking for. But that could be my lack of familiarity

While early on Raku was a modest evolution of Perl, they dropped that pretence long ago, and Raku is in fact a whole new programming language rewritten from the ground up with huge influences from multiple other languages as well as many novel things never done in other languages.

So you should be thinking of Raku as around 15 years old in practice, and as its own thing rather than as a continuation of anything else.  Calling Raku a continuation of Perl is like calling Java a continuation of C++.

Raku is a full featured novel general application development language that lacks no features in any other such language, and has all the more modern advanced features, it is not "just" a scripting language.

The fact that Raku, unlike Perl, supports declared types of variables/parameters/etc, means it is making the language safer at compile time.

This was not intended as a criticism or analsys of Raku in its own right. It just didn't come across as a source of novel ideas to ease pain in mainstream languages, particularly those that are already strongly typed.

 

Quote from Darren Duncan on April 22, 2021, 5:44 am

Quote from dandl on April 22, 2021, 5:35 am

Quote from Darren Duncan on April 21, 2021, 9:34 am

Quote from dandl on April 20, 2021, 2:22 pm

Did you look at the Raku language yet?  I recommend it.  May very well outdo some of the other newer and niche languages on your final list.

We wrote quite a bit of Perl back in the day, to analyse log files from our test suites. We were getting files of 50m lines, on Windows and several flavours of Unix, we outgrew awk and Perl handled them well. I wondered what had happened to Perl 6. Thanks for the pointer.

This is a language with a heritage going back over 30  years, seeking to evolve so as to 'fix Perl' and 'remove warts'. That would place it outside my survey.

There seems to be no particular intent to make the language safer at compile time, because dynamic typing is always a fallback. I'm not sure whether the classes and roles in Raku would equate to the TTM type system, or permit type inference. It still reads like a scripting language (Python-ish) rather than a novel general application development language of the kind I've been looking for. But that could be my lack of familiarity

While early on Raku was a modest evolution of Perl, they dropped that pretence long ago, and Raku is in fact a whole new programming language rewritten from the ground up with huge influences from multiple other languages as well as many novel things never done in other languages.

So you should be thinking of Raku as around 15 years old in practice, and as its own thing rather than as a continuation of anything else.  Calling Raku a continuation of Perl is like calling Java a continuation of C++.

Raku is a full featured novel general application development language that lacks no features in any other such language, and has all the more modern advanced features, it is not "just" a scripting language.

The fact that Raku, unlike Perl, supports declared types of variables/parameters/etc, means it is making the language safer at compile time.

This was not intended as a criticism or analsys of Raku in its own right. It just didn't come across as a source of novel ideas to ease pain in mainstream languages, particularly those that are already strongly typed.

 

Thank you for the clarity.  Its all good, thanks.

Quote from dandl on April 22, 2021, 6:28 am

Quote from Dave Voorhis on April 21, 2021, 11:36 am

Quote from dandl on April 21, 2021, 10:56 am

Quote from Dave Voorhis on April 21, 2021, 8:22 am

Quote from dandl on April 21, 2021, 12:44 am

It wasn't meant to be an analysis. Just pointing out that your bullet points are vague enough to mean anything from cutting-edge future advancements to crude legacy languages. E.g., "getting rid of ... type declarations" could mean type inference per modern languages, or literally no type declarations and "type inference" of a handful of primitive types per vintage BASIC.

I think you're trying to read them backwards, as a list of inclusions rather than a list of exclusions. Assume you start with the latest Java/C#/etc: this is what we try to take out. There is another list of things we might want to add, including getting things back from C++ (meta, unions, type aliases, value types) and elsewhere.

I just mean they're vague, and subject to very broad interpretation.

Please, please, please do not bring back C++-style "meta", unions (if you mean what I think you mean), and type aliases. Java not having these is one of its strengths.

C++lets you do things (unsafely) that you can't do in Java. I want to be able to do them, but safely.

The meta I want is to solve this problem. I have just spent a couple of hours writing code like this for a large number of named variables:

Console.Writeln($"version="{a.Version}");
b.version = a.Version
Console.Writeln($"version="{b.version}");

This is debugging code, not production, and I don't care if the macro that does this for me offends your sensibilities. Simple text substitution is enough to save a mountain of typing, and we now have the tech that will allow us to do this safely. I want it.

Why can't you do it with a function/method/procedure?

No need to answer specifically, because my point is that whatever prevents you from simply defining (and using) a function/method/procedure and compels use of a macro (as a workaround!) is the problem that needs fixing. Macros should be considered an undesirable workaround for a language limitation, not a solution.

Because (a) the input is notionally a list of symbols derived from a previously defined data structure and (b) the output is a mix of different kinds of token: new or mangled names of various types, and text strings. This is easy enough to do with reflection, so call this 'reflection at compile time'.

In any case, you don't get to change the problem. It exists for me and others in precisely that form, C/C++ can do it somewhat, and existing languages offer no solution (other than reflection and code generation).

C unions did two things: structural overlays (which is actually undefined behaviour) and simple algebraic types (along with struct). I want the algebraic types: don't  you?

C unions are untagged. If used to simulate type unions, you have to manually implement the type tag and handling the type is manual, leading to potential errors -- your ad-hoc union says it's type x but it's actually type y. Hilarity ensues.

Real algebraic types are good. C unions aren't algebraic types.

I never said they were. I want safe unions, not C unions.

C typedefs allow you to type check usage of primitive types. We used them extensively in Powerflex to manage the various compiler differences (such as signed/unsigned, short/long) but they're also really useful to distinguish (say) between an integer used as a count, one used as an index and one used as a length. There is no downside.

There are only downsides. They're a workaround better handled by type hierarchies, type assignment, and/or true substitutability, with (ideally) the ability to identify distinct-but-equivalent types.

It sounds like you said no, but then your explanation says yes. I don't want usafe C typedefs, I want safe type aliases/inheritance to replace them.

So to summarise: In Java we lost C macros, unions, typedefs; they were unsafe. I want things that do what they let me do, but now I want them do it safely. Do you have an argument against that specific proposition?

The compiler doesn't do anything. This isn't about the compiler. This is about allowing me to understand the code better, so I can modify it.

Or, maybe the post-C++/C#/Java language one or both of us creates or uses will allow both, so the developer can decide.

So:

• I would like to be able to write application code (both free-standing and code that consumes a variety of APIs) without any type annotations
• you would like to retain type annotations for readability
• and there is the issue of ambiguity/overloading which the compiler cannot resolve, unless the language prevents them.

There are languages out there which claim to not need annotations: that topic will have to wait until I can take a look.

Quote from dandl on April 22, 2021, 7:53 am

Quote from tobega on April 21, 2021, 3:27 pm

Quote from dandl on April 21, 2021, 10:56 am

Quote from Dave Voorhis on April 21, 2021, 8:22 am

Quote from dandl on April 21, 2021, 12:44 am

It wasn't meant to be an analysis. Just pointing out that your bullet points are vague enough to mean anything from cutting-edge future advancements to crude legacy languages. E.g., "getting rid of ... type declarations" could mean type inference per modern languages, or literally no type declarations and "type inference" of a handful of primitive types per vintage BASIC.

I think you're trying to read them backwards, as a list of inclusions rather than a list of exclusions. Assume you start with the latest Java/C#/etc: this is what we try to take out. There is another list of things we might want to add, including getting things back from C++ (meta, unions, type aliases, value types) and elsewhere.

I just mean they're vague, and subject to very broad interpretation.

Please, please, please do not bring back C++-style "meta", unions (if you mean what I think you mean), and type aliases. Java not having these is one of its strengths.

C++lets you do things (unsafely) that you can't do in Java. I want to be able to do them, but safely.

The meta I want is to solve this problem. I have just spent a couple of hours writing code like this for a large number of named variables:

Console.Writeln($"version="{a.Version}");
b.version = a.Version
Console.Writeln($"version="{b.version}");

This is debugging code, not production, and I don't care if the macro that does this for me offends your sensibilities. Simple text substitution is enough to save a mountain of typing, and we now have the tech that will allow us to do this safely. I want it.

C unions did two things: structural overlays (which is actually undefined behaviour) and simple algebraic types (along with struct). I want the algebraic types: don't  you?

C typedefs allow you to type check usage of primitive types. We used them extensively in Powerflex to manage the various compiler differences (such as signed/unsigned, short/long) but they're also really useful to distinguish (say) between an integer used as a count, one used as an index and one used as a length. There is no downside.

But I mention that not to get into a debate about what should/shouldn't be included, but to point out that it's almost inevitable that everyone you ask will have a different vision of what should/shouldn't be included in some C++/C#/Java successor. What I think should/shouldn't be there will differ from what you think should/shouldn't be there, and likewise for Ant, Erwin, Tobega, etc., etc.

I think the best you can do here is write something that scratches your own personal itches, and hope that enough other developers share the same itches to appreciate your, er, itch-scratcher.

I have very few specific itches: whatever gives me safer-shorter-higher, meta and fits in will be just fine. But it's totally wrong to think about what to add until you know for sure what you're prepared to give up to get it.

I keep waiting for the revolutionary vision of how we should program in a safer-shorter-higher way, but we're still at a laundry list of incremental changes which we can't all agree are improvements.

I'm still working on the laundry list. See post.

My presumption is that you need to write less code to leave room for getting more done. But I have a couple of targets:

• a data structure that embodies structure at a higher level than the types we know and love. I have a data model of 20 tables, with various key and other constraints, and I would like to check at compile time that the operations I code for it will not violate any constraints.
• Ditto for a graph structure, etc.
• A template that generates an HTML page from an SQL query (the query, not the result set).
• Templates to transform SQL <=> Json <=> XML <=> etc.

So far, based on your requirements, I think I would recommend you to take a look at Ada. I think a lot would be won if we all did, but it's not exactly a new revolutionary thing.

I don't think so.

Quote from tobega on April 22, 2021, 8:17 am

Quote from Erwin on April 21, 2021, 10:38 pm

Quote from tobega on April 21, 2021, 3:27 pm

I keep waiting for the revolutionary vision of how we should program in a safer-shorter-higher way ...

One thing that always comes to mind when I see such proposals, is that we might have a language that instead of forcing the developer into

am_price_net := int(am_price_gross * pct_reduc * 100 + 0.5) / 100;

allows one to write

COMPUTE AM-PRICE-NET ROUNDED = AM-PRICE-GROSS * PCT-REDUC;

But for some strange reason people always think I'm being facetious when I say that.

Except that it's not necessarily an equivalent statement since it seems default rounded mode is NEAREST-TOWARD-ZERO

And if someone sets default rounded mode to NEAREST-EVEN is that when the second example becomes really correct  or when it goes wrong? So is the feature a benefit or a bug-source?

Quote from Dave Voorhis on April 22, 2021, 8:29 am

Quote from dandl on April 22, 2021, 6:28 am

Quote from Dave Voorhis on April 21, 2021, 11:36 am

Quote from dandl on April 21, 2021, 10:56 am

Quote from Dave Voorhis on April 21, 2021, 8:22 am

Quote from dandl on April 21, 2021, 12:44 am

It wasn't meant to be an analysis. Just pointing out that your bullet points are vague enough to mean anything from cutting-edge future advancements to crude legacy languages. E.g., "getting rid of ... type declarations" could mean type inference per modern languages, or literally no type declarations and "type inference" of a handful of primitive types per vintage BASIC.

I think you're trying to read them backwards, as a list of inclusions rather than a list of exclusions. Assume you start with the latest Java/C#/etc: this is what we try to take out. There is another list of things we might want to add, including getting things back from C++ (meta, unions, type aliases, value types) and elsewhere.

I just mean they're vague, and subject to very broad interpretation.

Please, please, please do not bring back C++-style "meta", unions (if you mean what I think you mean), and type aliases. Java not having these is one of its strengths.

C++lets you do things (unsafely) that you can't do in Java. I want to be able to do them, but safely.

The meta I want is to solve this problem. I have just spent a couple of hours writing code like this for a large number of named variables:

Console.Writeln($"version="{a.Version}");
b.version = a.Version
Console.Writeln($"version="{b.version}");

This is debugging code, not production, and I don't care if the macro that does this for me offends your sensibilities. Simple text substitution is enough to save a mountain of typing, and we now have the tech that will allow us to do this safely. I want it.

Why can't you do it with a function/method/procedure?

No need to answer specifically, because my point is that whatever prevents you from simply defining (and using) a function/method/procedure and compels use of a macro (as a workaround!) is the problem that needs fixing. Macros should be considered an undesirable workaround for a language limitation, not a solution.

Because (a) the input is notionally a list of symbols derived from a previously defined data structure and (b) the output is a mix of different kinds of token: new or mangled names of various types, and text strings. This is easy enough to do with reflection, so call this 'reflection at compile time'.

In any case, you don't get to change the problem. It exists for me and others in precisely that form, C/C++ can do it somewhat, and existing languages offer no solution (other than reflection and code generation).

But that is precisely the problem. If conventional function/method/procedure definition is too weak to handle what you need, then that is the problem.

Text replacement macros (and their relatives -- token-based macros and templates) are notoriously problematic, and are additional complexity.

Surely the underlying problem is addressable?

C unions did two things: structural overlays (which is actually undefined behaviour) and simple algebraic types (along with struct). I want the algebraic types: don't  you?

C unions are untagged. If used to simulate type unions, you have to manually implement the type tag and handling the type is manual, leading to potential errors -- your ad-hoc union says it's type x but it's actually type y. Hilarity ensues.

Real algebraic types are good. C unions aren't algebraic types.

I never said they were. I want safe unions, not C unions.

C typedefs allow you to type check usage of primitive types. We used them extensively in Powerflex to manage the various compiler differences (such as signed/unsigned, short/long) but they're also really useful to distinguish (say) between an integer used as a count, one used as an index and one used as a length. There is no downside.

There are only downsides. They're a workaround better handled by type hierarchies, type assignment, and/or true substitutability, with (ideally) the ability to identify distinct-but-equivalent types.

It sounds like you said no, but then your explanation says yes. I don't want usafe C typedefs, I want safe type aliases/inheritance to replace them.

So to summarise: In Java we lost C macros, unions, typedefs; they were unsafe. I want things that do what they let me do, but now I want them do it safely. Do you have an argument against that specific proposition?

No, but sheesh, do we have to always follow the same pattern?

You: I want this bad idea from the past.

Me: That's a bad idea from the past. Here's a good idea from the present or future.

You: I didn't mean the bad idea. I meant the good idea.

E.g., above you appear to suggest C unions in "C unions did two things: structural overlays (which is actually undefined behaviour) and simple algebraic types (along with struct). I want the algebraic types: don't you?" and C typedefs in "C typedefs allow you to type check usage of primitive types. We used them extensively ... There is no downside."

Later, we get " I want safe unions, not C unions" and "I don't want usafe C typedefs, I want safe type aliases/inheritance to replace them."

Maybe make it clear to begin with what you have in mind. Does your latest "Life after D safe Java Mk III" risk following the same pattern?

Also, are you reinventing Kotlin and Scala?

We've already got Kotlin and Scala.

The compiler doesn't do anything. This isn't about the compiler. This is about allowing me to understand the code better, so I can modify it.

Or, maybe the post-C++/C#/Java language one or both of us creates or uses will allow both, so the developer can decide.

So:

• I would like to be able to write application code (both free-standing and code that consumes a variety of APIs) without any type annotations
• you would like to retain type annotations for readability
• and there is the issue of ambiguity/overloading which the compiler cannot resolve, unless the language prevents them.

There are languages out there which claim to not need annotations: that topic will have to wait until I can take a look.

There might well be, but are they statically typed?

The important thing is that I would like to retain type annotations for readability.

But again: You do you. Create what you would like to use.