5 ms·

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 sy

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.

rhacker 6y ago
Ha, not even. I see more shops doing TS/TS (backend TS/FE TS). Even me, 20 year Java vet. Basically been doing full time TS for about 5 years now.
- j4ah4n 6y ago
  This. Time flies by and before long it happened.
- WClayFerguson 6y ago
  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.
  - 29athrowaway 6y ago
    JavaScript cannot be fixed.
    - WClayFerguson 6y ago
      TS is what everyone is coding nowadays, and yes it definitely "fixed" the problems with JS. However the world would be a better place if there was just Java, and neither of it's two offspring were ever born (JS and TS).
      - 29athrowaway 6y ago
        Yet, it compiles to JavaScript and it allows many of the things that make JavaScript unsafe. JavaScript is highly mutable and under the right circumstances you can trick JavaScript applications to modify themselves. i.e.: Prototype pollution.
        WClayFerguson 6y ago
        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.
        29athrowaway 6y ago
        Run this, please. // 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.
acdha 6y ago
> 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#.
- WClayFerguson 6y ago
  > 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.

rhacker 6y ago

Ha, not even. I see more shops doing TS/TS (backend TS/FE TS). Even me, 20 year Java vet. Basically been doing full time TS for about 5 years now.

j4ah4n 6y ago
This. Time flies by and before long it happened.
WClayFerguson 6y ago
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.
- 29athrowaway 6y ago
  JavaScript cannot be fixed.
  - WClayFerguson 6y ago
    TS is what everyone is coding nowadays, and yes it definitely "fixed" the problems with JS. However the world would be a better place if there was just Java, and neither of it's two offspring were ever born (JS and TS).
    - 29athrowaway 6y ago
      Yet, it compiles to JavaScript and it allows many of the things that make JavaScript unsafe. JavaScript is highly mutable and under the right circumstances you can trick JavaScript applications to modify themselves. i.e.: Prototype pollution.
      - WClayFerguson 6y ago
        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.
        29athrowaway 6y ago
        Run this, please. // 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.

acdha 6y ago

> 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#.

WClayFerguson 6y ago
> 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.