91–100 of 164 posts
If Java is open and free, then why did Android decide to rewrite Java? I notice a lot of companies seem to avoid Java so there must be some sort of a catch.
Here is what Gosling has to say on it.
https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be...
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…
The problem is that if you stay on old language versions, you're doomed soon or later (see the world moving to Python 3.7, Java 11, C#7, Go 2,..).
If you consider then JavaScript, things are moving at speed of light. Today's framework might be ancient in a couple of months (React version??)
If Java is open and free, then why did Android decide to rewrite Java? I notice a lot of companies seem to avoid Java so there must be some sort of a catch.
Android is quickly moving away from Java to make Kotlin the default language nowadays, it's probably in part due to the Java lawsuit (and in part to add language features quicker without changing the VM).
Kotlin just gets an additional library to make some SDK usage a bit easier.
If Java is open and free, then why did Android decide to rewrite Java? I notice a lot of companies seem to avoid Java so there must be some sort of a catch.
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/
Compatibility is still kind of broken.
It isn't possible to guarantee that any random Java library is usable on Android.
One could argue that LTS software is just a trap (and a particularly lucrative one). I know that this is likely a couple factors that allow me to say this namely 1. I can rule over our dependency and technology choices with an iron fist if need be 2. I live in on post 3.6+ Python as our main language and for anyone with good CD/CI you can always run your tests against the master branch and latest dev builds at least…
Not upgrading your dependencies in-line with upstream is a form of perverse technical debt -- perverse because most technical debt is incurred to get new features/releases quicker, whereas the technical debt from not upgrading is incurred to simply stay where you are.
Things that business people can't understand is that nobody supports the language version any more and you can't build it with modern tools. You can't run the old OS any more, which has the old tools to build your code because the OS doesn't run on new hardware. I've been in the situation where I've had a server that was practically unique. It was so old that the only hardware that could run it, was the machine that was already running it. If that died, it was game over. (I should probably mention that I tend to specialise in difficult legacy situations in my career ;-) ).
The idea that you need to do maintenance work on your software, even without fixing bugs and without adding features, is incredibly difficult for business people to swallow. So they naively allow the situation to get very, very bad (and then they have to hire someone like me).
Earlier quoted context omitted.
Not upgrading your dependencies in-line with upstream is a form of perverse technical debt -- perverse because most technical debt is incurred to get new features/releases quicker, whereas the technical debt from not upgrading is incurred to simply stay where you are.
People really don't understand the cost of bit rot -- especially business people. If it worked 10 years ago, and it hasn't changed, why can't we use it now? I happen to have an old Rails project that my team has to maintain. Rails 2, Ruby 1.8.7. When we stopped being able to even compile Ruby 1.8.7 with the latest versions of GCC, I finally got approval to upgrade. Things that business people can't understand is that…
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)
Honestly I wish the ECMAScript board would have just went he other way and doubled down in making JS a function language instead of trying to push more OOP approaches would have been a lot better. It’s always been a little wonky as a Prototype based OO language anyway.