31–40 of 84 posts
It'd be nice, but being an Android guy, I'd see zero benefit, as Google has no good way to push out updates to their VM.
Maybe Google should use openJDK instead of using their own proprietary version of Java. No one benefits of fragmentation.
Earlier quoted context omitted.
My point is that "smaller" features like pattern matching and data classes will land in Java well before big ticket items like value types; not that JVM enhancements will be strictly limited to LTS. Of course, you have the inside word: when are value types coming to the JVM? Hopefully by Java 10.
Minimal value types will arrive as an experimental feature at the VM level real soon now, language and library support will take a lot more work.
Earlier quoted context omitted.
Maybe Google should use openJDK instead of using their own proprietary version of Java. No one benefits of fragmentation.
As of Android 7 they do use the OpenJDK. If you're implying that they should replace the Android SDK/ART with OpenJDK/JVM then that would be foolish. The OpenJDK and JVM were never designed to work within the constraints of embedded mobile devices.
Slow releases weren't the only problem. Sometimes they even promised things that one year into development would be candidly postponed of other two years. I can't recall of any project being managed as poorly.
Earlier quoted context omitted.
As of Android 7 they do use the OpenJDK. If you're implying that they should replace the Android SDK/ART with OpenJDK/JVM then that would be foolish. The OpenJDK and JVM were never designed to work within the constraints of embedded mobile devices.
Why can't Google submit patches to make it work for embedded devices? I don't see the point of a separate version of Java. Imagine if you could develop Android apps against the latest version of Java.
Earlier quoted context omitted.
Only if the first number is constrained to two digits. The release from March of 2100 would be 100.3, which would work just fine.
It will mess up sorting. I agree with the suggestion. There really is no good reason why they wouldn't use yyyy.
https://blog.codinghorror.com/sorting-for-humans-natural-sor...
Earlier quoted context omitted.
FP and OOP are compatible styles. In fact, I would argue that FP is more object orientated than procedural code such as loops.
Not really; FP and OOP are dissimilar in their approach to mutable state and it's management, for instance. You can come up with a synthesis (or probably many different syntheses) of ideas from the two styles to make a style blending inspiration from each, but they aren't directly compatible, and most direct combinations mhave tension between the two styles, or directly subordinate one to the other, for that reason.
The venerable master Qc Na was walking with his student, Anton.
Hoping to prompt the master into a discussion, Anton said
"Master, I have heard that objects are a very good thing - is this true?"
Qc Na looked pityingly at his student and replied, "Foolish pupil -
objects are merely a poor man's closures."
Chastised, Anton took his leave from his master and returned to his
cell, intent on studying closures. He carefully read the entire
"Lambda: The Ultimate..." series of papers and its cousins, and
implemented a small Scheme interpreter with a closure-based object
system. He learned much, and looked forward to informing his master of
his progress.
On his next walk with Qc Na, Anton attempted to impress his master by
saying "Master, I have diligently studied the matter, and now understand
that objects are truly a poor man's closures." Qc Na responded by
hitting Anton with his stick, saying "When will you learn? Closures are a
poor man's object." At that moment, Anton became enlightened.
I'm fully in support of defined, rolling release trains. 6 months is a good start considering where they're coming from. I feel like that's still slightly too long though, and is one of the things I wish the Go team would change. The Go team's argument is that it takes time to fully test features before being able to release them, which I understand, but that's the whole point behind a multiple release train model. B…
> To make it clear that these are time-based releases, and to make it easy to figure out the release date of any particular release, the version strings of feature releases will be of the form $YEAR.$MONTH. Thus next year’s March release will be 18.3, and the September long-term support release will be 18.9. Shouldn't those version numbers be 2018.3 and 2018.9? Have we learned nothing from the Y2K bug?
Imagine the shock when our descendents wake up on Jan 1 2118 and all their systems are accidentially running on a 100 year old JVM :)
In general, I think too much stock is put into language features, perhaps because many developers are bored with the actual software they are writing/maintaining, and so new language features are relatively fun. As a mental experiment for those who know both Java and Kotlin, or both Java and Scala: Suppose you were asked to estimate the time required to implement a system in Java, and you arrived at an answer of 2 months. Now what would be your estimate for the same system, but written in Kotlin? How about Scala? Admit that it would be the same. (Well, probably a little longer for Scala, but just because it takes forever to compile, ha.)