111–120 of 164 posts
Honest question: How often do people upgrade their production language? Me: once in a decade, maybe. I'm still perfectly happy (and productive) with C# 3.5, Java 7 and Python 2. I'm grudgingly moving forward because the old toolchains are being deprecated now, but my codes aren't significantly improved because of a few fancy idioms available in a new language, and it barely affects the design decisions. Upgrading you…
Earlier quoted context omitted.
In the JavaScript world people use those holiday chocolate calendar things to count the days until a new version of their favorite compiler will come out and can't sleep the night before because they want to be sure they can update at the very instant the release is dropped (and then proceed to complain that their favorite framework didn't update for the quirks of the new compiler in a timely manner). I wish I was co…
Yep, and that's why JS is moving and everyone else is biting the dust lol. Progress needs to be made and those who can't follow don't have the right to complain really. Old tools are always available because language compatibility is preserved (which, imo should also be dropped, we would have much better language as a result). We also stick to LTS (in my case node LTS)
I think that Go and ECMAScript has shown that language compatibility is critical. The language changes that really improve quality of life change the way that you write code in that language, which mean you have to rewrite your existing code to opt-in to them. Small languages changes may not actually be worth the cost of adoption.
Honest question: How often do people upgrade their production language? Me: once in a decade, maybe. I'm still perfectly happy (and productive) with C# 3.5, Java 7 and Python 2. I'm grudgingly moving forward because the old toolchains are being deprecated now, but my codes aren't significantly improved because of a few fancy idioms available in a new language, and it barely affects the design decisions. Upgrading you…
Earlier quoted context omitted.
Because Java has had such a terrible support record. And it’s not like Oracle has any products they support. Microsoft has quite a history of creating and then abandoning different APIs and technologies. This is all pointless hyperbole. This isn’t that big change in the Java ecosystem. It’s not like it’s going to cost $20 to run Java at all. The price is for running Oracle’s Java... that’s older than six months... th…
Microsoft is known for s lot of things, but breaking backwards compatibility and short term support aren’t two of them.
Honest question: How often do people upgrade their production language? Me: once in a decade, maybe. I'm still perfectly happy (and productive) with C# 3.5, Java 7 and Python 2. I'm grudgingly moving forward because the old toolchains are being deprecated now, but my codes aren't significantly improved because of a few fancy idioms available in a new language, and it barely affects the design decisions. Upgrading you…
I'm sure if I had to deploy anywhere else than a server I ultimately control, I'd be a lot more conservative, but until then, this stuff makes things fun.
Honest question: How often do people upgrade their production language? Me: once in a decade, maybe. I'm still perfectly happy (and productive) with C# 3.5, Java 7 and Python 2. I'm grudgingly moving forward because the old toolchains are being deprecated now, but my codes aren't significantly improved because of a few fancy idioms available in a new language, and it barely affects the design decisions. Upgrading you…
It's insane, a complete waste of time, and a sign that the software is turning to garbage, releasing major api breaking changes just for their own goals, but to meet the goals of the user. Same goes for frameworks to a lesser extent. If one can't point out any real advantage of upgrading to a major version other than the developers want you to, that's the sign of broken software that's about to be insecure because th…
Earlier quoted context omitted.
That's a bit dangerous. There's good in both functional approach and type systems but I'd rather see them where they are - in TypeScript and lodash and have vanilla be as vanilla as possible. Time will tell, there's already been a case where things from framework were pulled into ES (coffeescript).
I’m curious what you mean by dangerous? I’m having trouble discerning what you mean. If you mean going into a functional paradigm I’d say it’s definitely a matter if taste. However my biggest gripe is that the ECMAScript board seems intent on being all things to all people. So they half implemented classes. And they added some neat data types. But god for bid you want to override their constructors yet if I make a cl…
The reason that's critically concerning for the language and its ecosystem is that since 'vanilla JS' has no opinion, all the libraries created for it tend to have to form their own opinion. This then means that when binding to many ES libraries, you're torn between a hundred flavors of functional, half-baked OO, procedural, or just bit buckets of inconsistency.
If the language can't make up its mind, you're guaranteed to see fragmentation by its users.
Earlier quoted context omitted.
Use openjdk instead. By default on linux, that's what will continue to happen. You won't really be impacted by this.
how's the performance compared to Oracle's (in Linux)?
Earlier quoted context omitted.
You're a long time out of date at this point. Google merged openjdk a long time ago for their base JVM. https://www.theregister.co.uk/2015/12/30/android_openjdk/
They didn't fully merged OpenJDK, just selected parts of it, across multiple Android versions. Compatibility is still kind of broken. It isn't possible to guarantee that any random Java library is usable on Android.