Quote from Dave Voorhis on April 5, 2021, 11:18 am

Quote from dandl on April 5, 2021, 1:49 am

Quote from Dave Voorhis on April 4, 2021, 11:24 am

Quote from dandl on April 4, 2021, 12:16 am

So, my take on Java is that all they have ever tried to do was create a safer C++. The object model is much the same, the code looks similar, the libraries cover similar territory, the coding experience is similar (but safer). In doing that they left out templates (and therefore STL) and value types and have been scrambling to put them back in. They also left out pointers, preprocessor, macros, typedefs, native "C" APIs.

There has been some interchange of ideas: annotations/attributes, reflection/RTTI, auto/var(C#), foreach: the capabilities seem comparable. C# has pointers, interop and a limited preprocessor, but still no macros or typedefs. Reflection is probably better than RTTI. But overall Java/C# is just a safer C++ with some bits left out.

[As it happens I'm in the middle of a mixed C#/C++ project with a lot of API/compatibility problems to solve, and the C++ features I've been really using are macros and typedefs. I'm having to hand-edit or generate C# code because it lacks the features. It's an unusual case, but for this goal C# is safer but also limited in comparison to C++.]

[One of the reasons Python is popular is the excellent "C" API feature. C# is pretty good too.]

But C++/Java/C# are like brain surgeons: great at what they do, but don't ask one to do rocket science.

So in all seriousness, what would make you switch languages? Is slow and steady tweaking of tiny features in Java at a glacial pace enough, always more or less tracking equivalents in C++? Surely there must be something frustrating about Java that some Big New Thing would fix? And if so what?

Yes, Java and C# were meant to be a C++ with softer, less dangerous edges. That was the point.

But one imperative, has-a-few-functional-addons C/C++-derived (whether syntax, semantics, or both) language is pretty much like every other. In terms of overall developer productivity and essential problem-solving approach, C, C++, C#, Java, JavaScript, TypeScript, Ruby, Python, PHP, Swift, Rust (and for that matter, FORTRAN, Pascal, PL/I, COBOL, etc.) are equivalent. When we need to do fine-grained, build-it-out-of-toothpicks software construction, any of them are fine; simply choose the one most suited (or least un-suited) to the job at hand.

No, that won't do.

That won't do what?

ASM => Fortran/Cobol/Algol => C => C++ is a continuous upward path of expressive power. C => Pascal => Java/C# is an upward path of safety. They're not equivalent.

They are equivalent for business applications, which I took to be the implicit context here. If you need to write a device driver, Java/C# (or Pascal) would not be the right choice -- but only because of lack/presence of certain low-level facilities -- but if you need to write a Website backend, they are equivalent. If you're talking about overall language semantics and general abstract expressivity, they are equivalent.

For the next hot new coolness or cool new hotness, we should be looking more closely at functional, declarative, logical, and goal-directed languages for inspiration and influence.

Not yet. We haven't exhausted this path. Java/C# are not the end of the road. We left out too much in the pursuit of safety.

We've left out pointers, mainly. For the majority of fine-grained, low-level, 3GL requirements in the context of building typical business applications, they're perfectly adequate.

They're perfectly inadequate for making any significant leaps in developer power that would make a newcomer language compelling enough to switch from Java/C#.

Add their capabilities, safety, expressivity and power -- but don't take away what we can do now with Java/C#/Python/whatever, whether though clean integration or absorption -- and there may be a compelling reason to switch.

Bingo. What we all really want is a safer simpler C++.

We've got it, and it's called Rust.

What I really don't want is yet another safer, simpler C++. We've got enough of those already.

I want to step up in capability and absorb 3GL functionality, and definitely not stay at a maximum of 3GL level.

I think we do need to look closely at functional, declarative, logical, and goal-directed languages for inspiration and influence, and step up a level without losing 3GL capability. We've got enough languages that take a step over without stepping up, and adding yet another one is not going to make a compelling difference.

So let's take that as the goal: C++ has shown us it can be done, now do it with safety and simplicity.

Rust.

Goal: a new language S that can completely replace C++ (and Java/C#), but is both safe and "as simple as possible but no simpler".

Rust.

Which implies:

• No end-runs around the compiler. We tell the compiler what we're doing, it checks up on us, the runtime has no way to cheat. [Caveat: highly restricted access to 'unsafe' code?]
• Support for multiple memory models: stack, heap, ref-counted, GC, we don't care but it just works, safely. [Note: C# value types are not GC. People care.]
• No null references: compiler tracks all usage.
• No casts, all conversions checked at compile time eg: Maybe, conversions with defaults, pattern matching.
• No exception handling, except for recovery from catastrophic failure to a provable safe point.
• No reflection/RTTI: whatever would be done at runtime using reflection must be done at compile time so it can be made safe.
• No ifdefs/macros/annotations/code generation, but a  meta-programming extension to replace existing use cases with code the compiler can check.
• Provably thread safe (async, promises, whatever).
• Interop: compiler-checked access to Java, C# and extern "C" libraries. [Caveat: do we trust the libraries?]
• Compiles to executable/DLL/SO etc.

It's Rust. There's perhaps work to be done to better integrate with Java/JVM (though there's https://github.com/jni-rs/jni-rs) and C#/.NET (e.g., see https://medium.com/@chyyran/calling-c-natively-from-rust-1f92c506289d), but it's there.

Not sure I agree with this: "No exception handling, except for recovery from catastrophic failure to a provable safe point," particularly as "except for recovery from catastrophic failure to a provable safe point" is exception handling. Perhaps you mean "no use of exception handling as an unwieldy alternative to return values."

A friend of mine once said: I write it, I compile it. If it compiles, it works; then as long as I got the logic right, it's done. He was talking about Burroughs Algol, at a time when most operating systems were written in assembler. We're not there yet with Java/C# and not even close with C++. You can write an O/S in S, safely.

So tell me if you think any of the shopping list is beyond us. Would you use it? I know I would.

I don't know anyone actually using Rust. Plenty of folks are playing with it. I plan to do so at some point.

I haven't seen anything yet that would compel me to switch from C# and Java, because I find them perfectly adequate for most fine-grained, 3GL-style programming, with occasional forays into C++ when I need to do something explicitly with memory (mainly on Arduinos for personal projects) or consistently high performance and low latency (paid work.)

Quote from Dave Voorhis on April 5, 2021, 11:19 am

Quote from dandl on April 5, 2021, 4:00 am

Assume a language in which:

• the compiler takes care of lexing and parsing, making the AST accessible
• there are tools for manipulating the AST (safely) provided by the compiler or written as compiler extensions
• the AST can be saved, round-tripped into viewable source code and compiled into (safe) executable code.

Doesn't that address your concerns?

That's meta-programming as I see it.

That's AST macros, rather than text-replacement macros, which are good for avoiding the usual problems with text-replacement macros.

In case you're not yet sensing a theme here, I direct your attention to Rust macros: https://doc.rust-lang.org/book/ch19-06-macros.html

Quote from Darren Duncan on April 5, 2021, 6:59 pm

Quote from dandl on April 5, 2021, 4:00 am

Assume a language in which:

• the compiler takes care of lexing and parsing, making the AST accessible
• there are tools for manipulating the AST (safely) provided by the compiler or written as compiler extensions
• the AST can be saved, round-tripped into viewable source code and compiled into (safe) executable code.

Doesn't that address your concerns?

That's meta-programming as I see it.

For the purposes of the current discussion lets assume that what you describe does address my concerns.  I don't feel a need to get further into the weeds at this time.  Thank you.

Quote from dandl on April 5, 2021, 11:16 pm

Quote from Darren Duncan on April 4, 2021, 8:26 pm

Quote from tobega on April 4, 2021, 7:52 pm

There is always someone who finds it frustrating and there have been some bubbles of Scala and lately Kotlin usage (not sure where Clojure programmers came from). Scala is now mostly dead and I predict Kotlin will not be a huge success because it has no "great idea" other than to be a Java with more features (which is probably why C# doesn't take off either)

I have the impression that C# is seeing a resurgence now.  It is indeed the most comparable to Java but I have found it had a better standard library and some other better language design aspects. I think that part of what held C# back historically was that it was officially Windows-only.  But its new version with the open-source .NET Core lineage, seems to be rapidly gaining in popularity among developers and in features, and its also being touted that the current version also has great runtime performance, with only close-to-the-metal languages doing better.

It's an opportunity to get rid of the cruft from 2.0 and earlier. Java should do the same, before it's too late.

Quote from Darren Duncan on April 5, 2021, 11:30 pm

Quote from dandl on April 5, 2021, 11:16 pm

Quote from Darren Duncan on April 4, 2021, 8:26 pm

I have the impression that C# is seeing a resurgence now.  It is indeed the most comparable to Java but I have found it had a better standard library and some other better language design aspects. I think that part of what held C# back historically was that it was officially Windows-only.  But its new version with the open-source .NET Core lineage, seems to be rapidly gaining in popularity among developers and in features, and its also being touted that the current version also has great runtime performance, with only close-to-the-metal languages doing better.

It's an opportunity to get rid of the cruft from 2.0 and earlier. Java should do the same, before it's too late.

While I know that C# only really got good with .NET 4.0, or at least I consider that the minimum usable version for what I want, can you give a quick summary of what you mean by "cruft from 2.0 and earlier"?  I actually only started using .NET with 4.5 so that is my life experience, and anything I know about earlier versions is just from reading documentation.

Quote from dandl on April 5, 2021, 11:58 pm

So in all seriousness, what would make you switch languages? Is slow and steady tweaking of tiny features in Java at a glacial pace enough, always more or less tracking equivalents in C++? Surely there must be something frustrating about Java that some Big New Thing would fix? And if so what?

Yes, Java and C# were meant to be a C++ with softer, less dangerous edges. That was the point.

But one imperative, has-a-few-functional-addons C/C++-derived (whether syntax, semantics, or both) language is pretty much like every other. In terms of overall developer productivity and essential problem-solving approach, C, C++, C#, Java, JavaScript, TypeScript, Ruby, Python, PHP, Swift, Rust (and for that matter, FORTRAN, Pascal, PL/I, COBOL, etc.) are equivalent. When we need to do fine-grained, build-it-out-of-toothpicks software construction, any of them are fine; simply choose the one most suited (or least un-suited) to the job at hand.

No, that won't do.

That won't do what?

ASM => Fortran/Cobol/Algol => C => C++ is a continuous upward path of expressive power. C => Pascal => Java/C# is an upward path of safety. They're not equivalent.

They are equivalent for business applications, which I took to be the implicit context here. If you need to write a device driver, Java/C# (or Pascal) would not be the right choice -- but only because of lack/presence of certain low-level facilities -- but if you need to write a Website backend, they are equivalent. If you're talking about overall language semantics and general abstract expressivity, they are equivalent.

No, they really aren't, and in any case, business applications are a tiny subset of the interesting problems to be solved by programming.

Add their capabilities, safety, expressivity and power -- but don't take away what we can do now with Java/C#/Python/whatever, whether though clean integration or absorption -- and there may be a compelling reason to switch.

Bingo. What we all really want is a safer simpler C++.

We've got it, and it's called Rust.

I offered Rust as an example of meta-programming, and you rejected it. The 'hello world' program in Rust uses a macro.

What I really don't want is yet another safer, simpler C++. We've got enough of those already.

I want to step up in capability and absorb 3GL functionality, and definitely not stay at a maximum of 3GL level.

I think we do need to look closely at functional, declarative, logical, and goal-directed languages for inspiration and influence, and step up a level without losing 3GL capability. We've got enough languages that take a step over without stepping up, and adding yet another one is not going to make a compelling difference.

You can want but you're not going to get until 3GL is fixed.

Goal: a new language S that can completely replace C++ (and Java/C#), but is both safe and "as simple as possible but no simpler".

Rust.

Maybe. I haven't yet had the opportunity to do a project in Rust so I can't say, but I would make a small bet it scores no more than about 75% on my list.

Which implies:

• No end-runs around the compiler. We tell the compiler what we're doing, it checks up on us, the runtime has no way to cheat. [Caveat: highly restricted access to 'unsafe' code?]
• Support for multiple memory models: stack, heap, ref-counted, GC, we don't care but it just works, safely. [Note: C# value types are not GC. People care.]
• No null references: compiler tracks all usage.
• No casts, all conversions checked at compile time eg: Maybe, conversions with defaults, pattern matching.
• No exception handling, except for recovery from catastrophic failure to a provable safe point.
• No reflection/RTTI: whatever would be done at runtime using reflection must be done at compile time so it can be made safe.
• No ifdefs/macros/annotations/code generation, but a  meta-programming extension to replace existing use cases with code the compiler can check.
• Provably thread safe (async, promises, whatever).
• Interop: compiler-checked access to Java, C# and extern "C" libraries. [Caveat: do we trust the libraries?]
• Compiles to executable/DLL/SO etc.

It's Rust. There's perhaps work to be done to better integrate with Java/JVM (though there's https://github.com/jni-rs/jni-rs) and C#/.NET (e.g., see https://medium.com/@chyyran/calling-c-natively-from-rust-1f92c506289d), but it's there.

Not sure I agree with this: "No exception handling, except for recovery from catastrophic failure to a provable safe point," particularly as "except for recovery from catastrophic failure to a provable safe point" is exception handling. Perhaps you mean "no use of exception handling as an unwieldy alternative to return values."

That too, but no, it's the provable safety that is missing. Java exception handling is horribly intrusive, C# is not much better, C++ is just unsafe. The language should deal with all the small things (Rust has Option<T>) and just provide one means of disaster recovery. In Rust that's 'panic', which is a better name for what I mean.

A friend of mine once said: I write it, I compile it. If it compiles, it works; then as long as I got the logic right, it's done. He was talking about Burroughs Algol, at a time when most operating systems were written in assembler. We're not there yet with Java/C# and not even close with C++. You can write an O/S in S, safely.

So tell me if you think any of the shopping list is beyond us. Would you use it? I know I would.

I don't know anyone actually using Rust. Plenty of folks are playing with it. I plan to do so at some point.

I haven't seen anything yet that would compel me to switch from C# and Java, because I find them perfectly adequate for most fine-grained, 3GL-style programming, with occasional forays into C++ when I need to do something explicitly with memory (mainly on Arduinos for personal projects) or consistently high performance and low latency (paid work.)

There is nothing on this planet that would get you to switch for the kind of work you do and get paid for. I haven't done any paid programming for over 30 years, and when I did it wasn't what you call 'business programming', so my perspective is rather different. My customers do 'business programming' and I hang out with people who do 'non-business programming', and I write tools for them. I've written code in over 50 languages, and compilers for several of them. I'm seriously into language features. I would switch, but right now safety is not enough on its own. It is a guiding principle worth following.

Yes, Rust was the best I found on my quest for M and then S. I'm increasingly certain that until we solve the safety problem for all kinds of programming, we can't move to the next level.

So now I need a project to try it out, and perhaps implementing the Extended RA is one worth trying. One thing Andl taught me was: I really miss programming with relations!

Quote from tobega on April 6, 2021, 5:11 am

Are we really thinking along the right lines here, though? Do we really need more ways to produce increasingly complex code?

So far I haven't seen any features mentioned that help us prove the correctness of code, which might be more needed. Things like contracts and more restrictive types.

If ease of proving correctness is important, we should perhaps be looking at the Ada language. The very few people I know who have programmed in Ada really liked it and wish they could use it instead of Java. Ada is so far the best-proven language for safety-critical applications and I suspect it is quite nice in general, too, but it's still on my TODO-list so I don't know first-hand.

And if we insist on more powerful features, I think we need to at least consider how to prove correctness.

 

Quote from dandl on April 6, 2021, 6:00 am

Quote from tobega on April 6, 2021, 5:11 am

Are we really thinking along the right lines here, though? Do we really need more ways to produce increasingly complex code?

So far I haven't seen any features mentioned that help us prove the correctness of code, which might be more needed. Things like contracts and more restrictive types.

If ease of proving correctness is important, we should perhaps be looking at the Ada language. The very few people I know who have programmed in Ada really liked it and wish they could use it instead of Java. Ada is so far the best-proven language for safety-critical applications and I suspect it is quite nice in general, too, but it's still on my TODO-list so I don't know first-hand.

And if we insist on more powerful features, I think we need to at least consider how to prove correctness.

 

Goal: a new language S that can completely replace C++ (and Java/C#), but is both safe and "as simple as possible but no simpler". Not more powerful, just doing what we already do, but safer and simpler.

Ada was a valiant attempt. I watched the process and I studied the language. It has some great safety features, and modern languages can learn from it.

However, it missed the boat. The embedded system world focused on C and C++, and grew to love OO in Java. Ada is a vast language with many challenges to implement, and at least in the early stages was too big, too hard, too slow and not OO. It's very much still in use, but its use is not growing.

Proving correctness implies logical proofs, which is much harder than safety. Contracts per Eiffel are equivalent to runtime assertions: good to have, but not a replacement for safety. Strong typing is what it is, I don't know what restrictive types would be: scalar ranges? They weren't a big success in Pascal. But sure, whatever contributes to safety.

Quote from tobega on April 6, 2021, 7:26 am

Nvidia recently switched to Ada, I think it was because it is really hard to update software in devices so it better be correct.

Obviously there is the same inertia working against Ada as there will be against any language, as well as a (probably misguided) perception that it is old. I'm not sure OO is necessarily an obstacle since neither Rust nor Go seem to be very OO, and Ada does have features which seem to enable things similar to Java OO, https://learn.adacore.com/courses/intro-to-ada/chapters/object_oriented_programming.html (and of course true OO-believers would rather use Smalltalk).

Ada did suffer initially from the complexity, even compiling it was too hard a problem for the computers of the day. But after that I think the biggest problem against adoption was that neither Ada nor Smalltalk, nor Eiffel for that matter, were free as in beer. Why pay for a language when you can get C or C++ or Java for free? Now there are open-source versions , but I think you are probably correct that the ship has sailed. On the other hand, how many believed in 2000 that Apple would bounce back?

But if you're looking for a way to introduce new features that will be popular, I suspect that a JEP may be easiest.