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.

You are right, and we believe that what we are doing represents "fair use", as per _delirium above.

[I work at Docracy] There isn't, although you may be able to filter the main RSS feed. That's a good idea, though, we should add a feed to every document... something I will probably do... right now.

[I work at Docracy] We check once a day. We've seen some strange stuff going on with "Last updated:" though. For example, if you check out the history of Skype's ToS, they changed it in mid-January, but with a last-updated date of "February 2013"! Then, just a couple of days ago, they reverted it. Here's the first change: http://www.docracy.com/doc/diff?revisedId=0xgv5wfb72v&or..., then they changed it back: http://www.docracy.com/doc/diff?revisedId=0jxg6uxmx4d&or...

[I work at Docracy] We believe that if everybody who visits and uses the company's site is implicitly held to these terms, then they should be able to have a copy of the terms. We would be very surprised if a company asked us to stop tracking these policies, and nobody has yet.

[I work at Docracy, prepare for a plug!] Well note that we have a great negotiation and e-signing service that uses these same diff tools, try it out! http://www.docracy.com/supersigning

[I'm the co-creator of this project] I think that because this is a "human network", you wouldn't get those kinds of problems. People won't be synching with random strangers in the street, they will be synching with people they know and trust. Data will spread via "six degrees of separation". Think of it is just a more convenient form of USB thumb-drive sneakernets.

Started with C=64, but was in a small town and didn't really have access to any books or guidance. Moved on to PC and wrote some text-based games. It was enough to get me interested in CS for college. This was the mid-90s and I got really interested in Internet. I wrote a simple risk-style RTS game and ran the server directly on the CS department's web server! Incredible that this was allowed at that time.

For those interested in a far deeper analysis of music structure, as well as exploring the possibility of computer composition and creativity, see the work of David Cope: http://www.amazon.com/Computer-Models-Musical-Creativity-Dav...