You're conflating the monstrosity of J2EE (which admittedly was a mess, and completely unrelated to Java itself) with the "Java Language" by which I mean the syntax of the language itself.
Yes the younger/newer generation took a look at all the XML files in J2EE and said "Isn't there something simpler", and so now today we ended up with JavaScript running on the server side (NodeJS). TypeScript came to the rescue over the last 5 years, but now we have a world with TS and Java. The solution should have been to make Java run in the Browser, and not JavaScript, but I understand the history, and how, when, why that occurred. I've been coding 30ish years myself, like you.
> You're conflating the monstrosity of J2EE (which admittedly was a mess, and completely unrelated to Java itself) with the "Java Language" by which I mean the syntax of the language itself.
I'm not sure how well you can separate that: most people are going to hit those bumps when they get started, and they're going to see an ongoing frictional cost against their productivity. Yes, there are some neat things in the language — especially newer versions — but there are a lot of people who would benefit a lot from, say, a “Java: the good parts” distribution which makes it easy to start a new project and evolve it, and then SEO it as much as possible so people get that advice rather than the 10+ year old stuff many web searches will have highly ranked.
I do think there's an interesting alternate history where WebAssembly happened many years earlier in the form of Java byte-code. That would have lost a lot of the ability to read other people's code but it would have had better performance earlier and a good story for language competition which has brought many good features to Java from other languages. Unfortunately, after around 1997 or so that really came down to Microsoft so it would have been VB or C# in any case.
XML is interestingly similar where the core language community charged ahead building ever more standards on top of it but assumed that its inevitability meant someone else would fix their … not great … tools, specs, and examples for them — and then were surprised when almost everyone abandoned them for easier tools. I always liked the idea of XPath but it's effectively never moved past 1999 unless your world exclusively avoids libxml2, which wasted most of the hard work the standards group did.
One thing I think may be common about both of those is a big shift in how easy it is to build and ship development tools and programs: a 90s programmer had to live with what they got in a distribution to a much greater extent because you couldn't count on everyone having an internet connection, a fast one, package management hadn't happened much outside of the Linux/BSD world, and new things required waiting for someone to write a book you could order, finding a local user group, asking in Usenet, etc. Warts in your language still mattered but less so since for many people it was easier to keep using something than switch. After the 2000s, though, I think a lot of people realized that the cost of switching was so low that they had to care about developer ergonomics a lot more unless they had something like the massive platform pull Apple had with Objective-C and Microsoft had with C#.
I remember DCOM! I was a WIN32 MFC C++ Windows app developer from 1990 to 2000. I forget which person at MSFT finally ended up admitting "The Registry" was a mistake, but I think it was Gates?
It was right around the time when WAR/EAR/JAR files in Java were showing the power of having everything packaged and self contained. Meanwhile MSFT was stuck in DLL Hell for decades. ha.
As Java/.NET consultant I deal with both stacks since they exist, so it is always kind of funny see one side throwing balls to the other one, without realizing their own glass roof.
Regarding Java packing, isn't it funny how everyone is jumping into Docker hype just to get what Java containers have given us for the last 15 years?
I think I'm "doing it right", but like religions no one's is provably correct.
The younger kids are saying: "Meh, we'll just run NodeJS on the server, so we can ignore the J2EE mess the previous generation created since they're older and therefore dumber than us."
> I'm not sure how well you can separate that: most people are going to hit those bumps when they get started.
Your XML example is spot on and I agree. However I'd never say XML itself was flawed specifically because some of the tools, APIs, and specs built on top of it were flawed.
That would be like saying electricity itself is flawed because you don't like electric tooth brushes.
Likewise, Java was not flawed just because J2EE was a mess. The fact that J2EE drove people to NodeJS, has nothing whatsoever to do with Java itself.
I’ll say XML was flawed. It was a great initiative behind the wrong data model. The idea was to take what made sense for documents (strings with markup) and use that to represent everything else. But most data structures are really awkward expressed that way, and you run into weird decisions like: Should my map be a list of items or a set of attribute pairs in a single node? Is the key a node or an attribute? When does order matter? Etc.
If the XML standards group started with JSON or YAML or .. anything else, I think they would have made something really useful. But we didn’t think of that at the time, so instead we have XML. An impressive monolith built on a dead mountain.
Q: Why does TypeScript exist?
A: To fix JavaScript.
Q: Why was JavaScript invented?
A: To run code in the Browser.
Q: Why didn't they run Java in the Browser?
A: They did (applets). They tried. They failed. So they had to start over. They WANTED "Java" in the browser, but it wasn't practical for memory and CPU reasons, so they cobbled JavaScript together over a weekend.
You can write 100% perfectly type-safe code in TypeScript. You'd have to accidentally do a 'var' instead of a 'let' variable, or forget to add a type to a parameter, but if you try you can get pretty much 100% type-checking on every letter of every variable or object.
// 100% type-safe function :-)
function f(a: Date): number {
return a.getDate();
}
// Input to 100% type-safe function
const p = new Proxy(new Date(), {
get: function(target, prop, receiver) {
if (prop !== 'getDate') {
return Reflect.get(target, prop, receiver);
}
return function() {
console.log('Not typesafe :(');
};
}
});
f(p);
Output: "Not typesafe :("
What happened? all type-safety was circumvented. The f function that should return a number did not return a number. In fact, it didn't return anything.
The TypeScript compiler didn't return any errors either. This is perfectly valid TypeScript.
Why? because TypeScript is based on JavaScript. It is not 100% typesafe and it will never be.
Is TypeScript an improvement? yes. Does it help a lot of people? yes. Is it 100% typesafe? no.
Did TypeScript "fix" JavaScript? Mostly, but no. I hope the mods unflag my original comment.
I had already given two examples of how you can create non-type-safe code in TypeScript. I mentioned 1) the 'var/let' way and 2) The "Not including types on parameters" way.
That is not what is happening here. TypeScript correctly infers that type of the variable is a Proxy for a Date object. If you do not supply a Date object as first argument, the code won't compile.
The part that breaks things is that when f invokes a.getDate(), the Proxy get trap changes will return another function instead of Date#getDate at runtime, and that wasn't validated at compile time.
Proxy is part of JS. When did I ever say ANYTHING in JS is typesafe? Nothing in JS is typesafe.
However this is also simultaneously true: You can code in TypeScript and achieve 100% type safety by putting types on everything. If I claim all cubes can be painted red, you can't disprove that by proving green cubes exist.
You can go into my 250,000 loc project and randomly pick any variable name, method name, parameter name, etc., and put a typo in it or wrong type, and the compiler will catch it.
I have 100% type safety, and it's all done by TypeScript and my programming language IS TypeScript (not JS)
The the final output format generated by a compiler has absolutely nothing to do with whether the Language being compiled is typesafe or not. That would be like saying since Bytecode is not typesafe therefore Java is not a type safe language.
Google closure compiler and JetBrains IDEs can use JSdoc to validate types. I have used those to a reasonable level of accuracy to document entire JavaScript projects where I cannot migrate to TypeScript.
Excellent. Rock on man. I never thought I'd be a Microsoft fan again, but after they invented TypeScript/VSCode, I love them so much I might move to Redmond.
Just Java? That seems bizarre. There's so many more languages now days than just Java. I would love for Swift to take off. Don't get me wrong there is a lot in the Java ecosystem, but it's age is showing. And it's not lightweight. If I'm trying to spawn processes quickly it's not Java. If I want to run 100 instances of something, the RAM is going to cost me. JS and other fast to boot languages are also much more adaptable to serverless.
Now I'm not saying there's no room for Java any more, but "just Java" meeeeeeh.
Yes the younger/newer generation took a look at all the XML files in J2EE and said "Isn't there something simpler", and so now today we ended up with JavaScript running on the server side (NodeJS). TypeScript came to the rescue over the last 5 years, but now we have a world with TS and Java. The solution should have been to make Java run in the Browser, and not JavaScript, but I understand the history, and how, when, why that occurred. I've been coding 30ish years myself, like you.