How do you grant a company access to your data but prevent them from storing it? And how does it apply to data a company generates about me? For example, if I listen to songs on Spotify, are they supposed to somehow not store it, but still give me recommendations?
If you plan to be a professional software engineer, then I recommend just paying for the best tools. The price of one hour of an engineer's salary (give or take) can pay for the entire IntelliJ suite for a year.
I started learning Java in 1996 and it was a real revelation back then. Coming from very platform-specific C, everything felt comparatively easy. And Javadocs were amazing.
Just a few months ago I dusted off an old project from 1997, loaded it up in IntelliJ IDEA, built it, and ran it. It worked! And that's Java's best feature, it's long-term language and library stability. I worry that it is at risk now with Oracle's new 6-month release cycle.
> A frozen language means that either those modifications are harder
I don't agree that it's harder. What is definitely harder is not being able to ship bug-fixes or modifications without ripping everything up because the language has moved on since your last release. And that is very common when developing for, as an example, iOS, since Swift is a fast-moving language that doesn't maintain backwards compatibility. The benefits of having some new language feature in Swift are far outweighed by the downside of existing codebases being invalidated. The various languages in the Javascript family suffer from this as well. The Python 2 -> Python 3 debacle was another example of this.
I have dusted off 20 year old Java code which compiled and ran just fine just fine. That is extraordinarily valuable to me, and requires a lot of discipline by the language maintainers. In fact, the new faster pace of Java iteration could be its downfall, time will tell.
A last note: how many language features from the past 20 years really matter? How many really speed up development, improve maintainability, etc. I would say that there are very few. In fact, perhaps the only one that passes that bar might be async/await type threading advancements.
While I submitted this, I would like to voice my opinion that I am against "var" in Java. People may ask, "Why should I have to enter in the type if the compiler can infer it for me?" My answer is twofold: 1) You or some other maintainer will need to know what that type is later when reading the code. Of course, "var" is meaningless, requiring you to dig back one or more steps to determine the actual type. 2) You don't actually need to enter in the type, any competent IDE can do it for you.
So I'm not sure what we are saving here. When has the time spent typing in code ever been a bottleneck in software development anyways?
This is my feeling from having worked extensively in Java as well as languages that support "var": C# and Swift. I feel like my productivity goes down when I have to support code that uses inferred types. There also seems to be a performance hit when compiling code with inferred typing, although that may be circumventable with better compiler tech, who knows.
I would argue that the opposite of a bloom filter doesn't really exist, at least not in a satisfying way. A bloom filter's size is dependent only on the desired false positive rate, whereas its opposite must be dependent on the size of the data. (And don't be fooled by data that can be represented by a primary key, that's not as general as a bloom filter.) I tried, with limited success, to explain my point of view in this answer on StackExchange: https://cstheory.stackexchange.com/questions/6596/a-probabil...
This may be an unpopular opinion, but I don't want Java to move forward faster. I don't really want it to move forward much at all unless there is a huge, tangible benefit from the new feature(s). I am of the belief that programming languages should be a solid, fixed foundation on which lasting software can be reliably built. Every time a feature is added to a programming language, it becomes larger, more complex and harder to learn. Rapid changes to languages can also result in regrets, and it is essentially impossible to take something back in language development.
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.)