Life after J
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?
Quote from dandl on April 4, 2021, 12:16 amSo, 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.
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.
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.
Quote from dandl on April 4, 2021, 12:16 amSo, 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?
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)
Interestingly there is some movement in almost the opposite direction to what you seem to be asking for. A reasonable number of Java developers are moving to the Go language because it has significantly LESS features than Java (although the features it has are very well suited to most modern development). In Go there is deliberately only one way to do each thing and not many complications. It may seem clunky but the people I know that use it love it more and more and once they forget about their old complicated languages they tend to find elegant(ish) practical solutions in Go. On a side note, even though Go was intended as an alternative to C++, most movement to Go comes (thankfully) from Python (in the DevOps/SRE field) and to some extent from Java.
Rust is consistently the most loved new language among developers so it will at least find a solid niche. Julia has its niche and is bound to make inroads into Python territory at some point, at least for machine learning and scientific computing. Dart has a killer app for mobile development and may take over some web development as well (I hope).
I suppose the common theme for all the movements is that it makes developers' lives easier and code less complicated. I don't think the best new languages have more powerful features, in fact, they often seem to gain their power from being more restricted in some ways.
But most programmers will probably stick to Java for at least as long as Cobol has been around, simply because of the large legacy codebases that exist.
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.
Quote from Darren Duncan on April 4, 2021, 8:26 pmQuote from tobega on April 4, 2021, 7:52 pmThere 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.
If anything is holding C# back, it's the fact that so many of its available open source libraries seem to be written and maintained by amateurs and/or hobbyists. The language is nice, and .NET Core seems to work well (but steer clear of Entity Framework), but the quality of available code and documentation is -- with only a few exceptions -- appalling. Maybe good code is only in-house or commercially available?
Quote from tobega on April 4, 2021, 7:52 pmQuote from dandl on April 4, 2021, 12:16 amSo, 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?
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)
Interestingly there is some movement in almost the opposite direction to what you seem to be asking for. A reasonable number of Java developers are moving to the Go language because it has significantly LESS features than Java (although the features it has are very well suited to most modern development). In Go there is deliberately only one way to do each thing and not many complications. It may seem clunky but the people I know that use it love it more and more and once they forget about their old complicated languages they tend to find elegant(ish) practical solutions in Go. On a side note, even though Go was intended as an alternative to C++, most movement to Go comes (thankfully) from Python (in the DevOps/SRE field) and to some extent from Java. [...]
I wonder if any/many are moving back, or elsewhere. I've known developers to move to Go with great enthusiasm, only to bitterly complain later about its stripped-down-ness. I get the impression those using it to create Website back-end RESTful APIs are happiest; I guess it hits a sweet-spot there.
Though again, all of these languages are basically ways of arranging toothpicks to build skyscrapers.
We need better ways to turn toothpicks into reusable bricks, bricks into reusable walls, walls into reusable rooms, rooms into reusable buildings, buildings into- ...
Etc. (A brick should be a tiny room, too, or a building.)
Etc.
Quote from Dave Voorhis on April 4, 2021, 11:24 amQuote from dandl on April 4, 2021, 12:16 amSo, 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. 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.
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.
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++. So let's take that as the goal: C++ has shown us it can be done, now do it with safety and simplicity.
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". 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.
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.
Quote from Dave Voorhis on April 4, 2021, 8:58 pmQuote from Darren Duncan on April 4, 2021, 8:26 pmQuote from tobega on April 4, 2021, 7:52 pmThere 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.
If anything is holding C# back, it's the fact that so many of its available open source libraries seem to be written and maintained by amateurs and/or hobbyists. The language is nice, and .NET Core seems to work well (but steer clear of Entity Framework), but the quality of available code and documentation is -- with only a few exceptions -- appalling. Maybe good code is only in-house or commercially available?
C# gets me to Unity, so it's Mono that's actually the issue there.
I've just done a REST API in Core, and the code is lovely but opaque. It's using attributes and reflection to do clever things that I and the compiler can't see, and which fail at runtime, often by doing nothing at all. Nothing wrong with Core as such, but this what you get when you don't tell the compiler.
Quote from tobega on April 4, 2021, 7:52 pmQuote from dandl on April 4, 2021, 12:16 amSo, 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?
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)
Yup, wrong answer.
Interestingly there is some movement in almost the opposite direction to what you seem to be asking for. A reasonable number of Java developers are moving to the Go language because it has significantly LESS features than Java (although the features it has are very well suited to most modern development). In Go there is deliberately only one way to do each thing and not many complications. It may seem clunky but the people I know that use it love it more and more and once they forget about their old complicated languages they tend to find elegant(ish) practical solutions in Go. On a side note, even though Go was intended as an alternative to C++, most movement to Go comes (thankfully) from Python (in the DevOps/SRE field) and to some extent from Java.
Rust is consistently the most loved new language among developers so it will at least find a solid niche. Julia has its niche and is bound to make inroads into Python territory at some point, at least for machine learning and scientific computing. Dart has a killer app for mobile development and may take over some web development as well (I hope).
I think Go and Rust are both about safety: Go for concurrency and Rust for memory. There is a message here: devs care about safe.
I suppose the common theme for all the movements is that it makes developers' lives easier and code less complicated. I don't think the best new languages have more powerful features, in fact, they often seem to gain their power from being more restricted in some ways.
But most programmers will probably stick to Java for at least as long as Cobol has been around, simply because of the large legacy codebases that exist.
Then the obvious solution is to build on them, not discard them.
Quote from dandl on April 5, 2021, 1:49 amBingo. What we all really want is a safer simpler C++. So let's take that as the goal: C++ has shown us it can be done, now do it with safety and simplicity.
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". 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.
I disagree with the no-reflection and no-code-generation bullets, at least in the generalized sense that I interpret them.
I consider it essential to support homoiconic programming, where code is in the form of data that a program can read and generate.
Also this is required in order to have a D language, because what are system catalog relvars if not code-as-data?