pents90

It’s not. The inner loop operates only from i+1 to n in exchange sort and the resulting swaps are very different.

Ok, so it’s more of a legal framework than a technological one.

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.

It's long past time to retire Lena as the canonical test image in CG.

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

Not sure how everybody else feels about it, but I find that optional typing is the enemy of readable code.

As a long-time Java developer, I really hope they won't implement JEP 286. I think type inference by the compiler is a bad idea, as it results in less readable code, more bugs, and an unnecessary burden on the compiler. I think all the examples where type inference is convenient are trivial cases, but the downsides start to crop up in real-world, large code bases. So it's something that makes the easy things slightly easier and the hard the things harder.

Type inference already happens for you when you are using a good IDE, like IntelliJ IDEA. You can just use the "Introduce Variable" refactoring. And better yet, it self-documents your code with the variable's type.

A few years ago I wrote a Minesweeper clone in Google Spreadsheets: https://docs.google.com/spreadsheets/d/1367o4BYYNynmMan_1I5x...

Scala appeals to those who love programming languages. Java and a few other languages appeal to those who love making software, something that Scala is terrible at.

Some of the worst data presentation offenses are being committed in this talk, including graphs with misleading axes, trend lines derived from too few data points, and no acknowledgement of exponential trends, such as solar energy's adoption.

> (FWIW, I do know JS)

Assumption confirmed!

(Author here) The apps are just really thin native WebView/UIWebView layers, included in the source. No frameworks were used.

"Oliphant Immortal" from Gurk III: http://pix.pe?Q_____A4_YEAHDDYcDbYacDbA4_H_______wGuAA_H4__H...

Potential prior art here in a patent from the early 1990s: http://www.google.com/patents/US5337652

In our Play app, we isolate the real tricky stuff from our controllers and then write unit tests for it there. The controllers themselves end up being fairly lean and simple, so we test them (along with the front-end) with Selenium. We're not dogmatic about 100% coverage as we are a start-up trying to move fast, but this approach has worked well for us.

[I work at Docracy] C'mon, I wouldn't say "loads"! We are still working on a few lingering encoding problems, and we usually filter them out when we spot them. Other spurious changes are from the sites themselves. For example, every couple of days the IRS changes the date format in their privacy policy for some mysterious reason: https://www.docracy.com/doc/diff?originalId=1frr1ml4lt&r...

[I work at Docracy] What is unique is how we handle diffing within a hierarchical HTML structure and how our algorithm is tuned to display sensible diffs for written language text, which requires some more nuance than what is typically used to diff code lines. It's our own, homespun algorithm.