Those "stupid journalists" appear to be in good company, starting with official press releases from both the European Commission and indeed the European Court of Justice itself about the 2010 Spanish newspaper case.

I would be the first to agree that moves towards a more powerful right to be forgotten such as you describe would be a good idea, but as of today, these are mostly just proposals. For example, while there is already a right under some limited circumstances to request deletion of personal data, the UK's data protection regulator has written guidance for data controllers that makes clear that the right is quite tightly constrained for the time being.

In this case, "filter" means select only those items that match the criteria, i.e., where the given predicate is true.

This usage is about as consistent as anything you'll find in the programming world: languages using it this way include Python, PHP, JavaScript, Java, D, and many well-known functional programming languages including Haskell, several of the ML family, Erlang, Scala and Clojure. Some other well-known languages have related algorithms under other name, but I know of no counter-examples that use "filter" in the opposite sense.

I think you're confusing two different things here. The "right to be forgotten", as much discussed recently with regard to Google and the like, is primarily about search engines digging up old information that would otherwise naturally fade into obscurity, and in particular the danger of finding old information that looks plausible but may in fact be misleading without context or now incorrect/outdated.

Sadly, most of us even in Europe still have rather limited rights to compel businesses not to store personal data about us or to delete that data on demand, if the data is correct, they register the fact that they are doing it with the appropriate national privacy regulator, and they can come up with some vaguely plausible argument for why they want to have the data.

I guess a few million people are about to find out the hard way why some of us have been arguing for a long time that we should have stronger privacy safeguards in the Internet/big data/data mining age. I wish they didn't have to find out this way, though.

Sure there are. The trouble is, every single one you listed has serious drawbacks compared to the current model.

Yes, they did. Plenty still do, though for most of them it's beer money rather than a career.

But before recordings you didn't need a sound engineer in a studio with a mixing desk and a lot of expensive equipment. Who pays the sound engineer in your world? Or the composer of the symphony? Or all those people whose names come after the actors when the film credits roll? Your model might work for the latest production of Hamlet. It isn't going to produce Fast and Furious 8.

That damages the experience for the majority of viewers, who no longer have the option to enjoy the movie in the comfort of their own home.

Because an ad-funded internet is so good that people invented ad-blockers, and blatant product placement doesn't in any way reduce the enjoyment of TV shows.

This is one of the more promising ideas on your list. However, right now, even the most successful projects on Kickstarter and the like are still coming in with an order of magnitude or two less funding than comparable projects generate through a copyright-based system. When GTA VI comes along, do you think it's going to be supported by a successful crowdfunding campaign?

People like stuff for free. I'd agree that some people rip content illegally just because of the convenience factor -- films out in theatres before you can buy physical media or stream a legal download, DRM, and so on. But the idea that the only reason people don't pay for stuff they can download illegally for free is because it's inconvenient is implausible.

Do you know what does work, very reliably, by your arguments about violating property rights? Locking down the Internet and limiting devices you can legally buy/sell/own in the first place to those that play nicely with your closed ecosystem.

The trouble is, the "information wants to be free" crowd think this is a joke and can never happen, and that cute sound-bites like "censorship is damage and the Internet routes around it" will overcome the will of the billion-dollar infrastructure companies that actually produce a lot of popular content and the governments with laws and police and jails. They will not, and all you're doing is pushing those powerful organisations towards systems where -- as, ironically, you suggested -- content providers will keep everything under their control. The only way to enjoy any content will be to rent it and access it via limited mechanisms.

Really? What are they, then?

Of course there is, but at no point have I (or anyone else I've seen in this discussion) suggested doing the latter just to make the code shorter. The point is that there are plenty of languages that can say in one clean, readable line of code what takes half an editor window in Java. I gave some typical examples in my reply to another post.

Right. The marginal cost of extra copies of information is very low. Unfortunately the initial cost of putting that information together may be extremely high, and if the information is never collected it won't be distributed either.

So we create an economic incentive to encourage that creation and distribution, effectively amortizing the initial development cost over all those who ultimately obtain a copy. This might not be the perfect economic model, but I'm still waiting for anyone to offer a plausible better alternative.

You can repeat these arguments as often as you like, but the not-a-lost-sale argument still contradicts basic economics, and the just-trying-it-out argument still contradicts overwhelming empirical data the industry has been collecting for years.

No, but I'm saying it appears to have relatively little impact on the bottom line of copyright holders. More importantly, so does vast amounts of empirical data.

Maybe you personally aren't familiar with higher order functions or comprehensions. However, millions of programmers are, and would read and understand those lines without a second thought.

Using filter in Haskell or a list comprehension in Python is as routine as using your for-loop is in Java, and the associated syntax is similarly familiar to anyone who's ever done a significant amount of programming in those languages.

Moreover, these tools are declarative, which means you can use them in languages that better control side effects for safety, and you can use them in languages that optimise based on that extra knowledge for faster performance, and you will be able to use them in the data parallel languages of tomorrow to make more efficient use of modern processing hardware. In other words, in languages designed to take advantage of them, these styles immediately convey more information than the imperative style required by your for-loop version.

Perhaps it was the filter function that confused you, if you aren't familiar with that particular terminology? If so, I would remind you that you just wrote a code example full of integers and an add function that has nothing to do with calculating the sum of those integers. (At least, I think you did. I notice that you missed out several lines of initialisation and type declarations for those variables, making your example code considerably shorter than it otherwise would have been if you'd actually written a like-for-like equivalent.)

I honestly don't understand how any programmer, whatever their preference of language, can claim that an expression that says filter (<10) items and means choose the items that are less than 10 isn't straightforward. I think you're just trolling here.

As for never being used, you're welcome to stick with yesterday's programming tools if you like. No doubt there will be plenty of need for programmers to maintain legacy systems for a long time to come. But tomorrow's programming tools will let us build bigger, more efficient, safer programs, and we'll be doing it faster and with fewer resources. If you're not familiar with these idioms yet, you might want to consider broadening your knowledge, because before long every 21-year-old kid who learned programming by messing around with JavaScript in their browser is going to be using them.

Good for you. The last time I saw a programmer do that was... also never in my entire career, actually. If your programmers have trouble meditating on a print-out of a language with syntactic whitespace, you might suggest they instead use any modern text editor and a macro/plug-in that makes mismatched whitespace show up in bright red. Then they can become enlightened, spend less time "meditating" like programmers who work with punch cards, and spend more time making useful software.

I doubt that there was any text editor available in 1927 that got tabs/spaces wrong when working with Python code. Take your pick.

The thing is, I think it is related to how easy something is to understand.

If I can express an algorithm as a single function of 10 lines then, other things being equal, that will be easier to understand than distributing the same algorithm across 5 functions each of 20 lines. You can see the whole thing at once, instead of jumping around within or between files. You don't have overheads of passing around and returning values.

Similarly, if I can express a simple bit of logic as a clean one-liner, while a verbose style requires 6 lines of manual loop/conditional logic and maybe a function wrapped around it, then I'm thinking about what that logic is doing and it how it fits in with the other logic around it while you're still worrying about loop counters.

Here's a version of finding all the items less than 10 in a list, written in Haskell, a relatively powerful language:

items = [1, 15, 27, 3, 54]
result = filter (<10) items

Here's a slightly more verbose version, written in Python, also a language known for being clean and expressive:

items = [1, 15, 27, 3, 54]
result = [item for item in items if item < 10]

And in contrast, here is the best Stack Overflow has to offer about implementing this sort of requirement in Java.

Spoiler: There are basically three kinds of replies. Some write out entire functions to implement the filter using a manual loop. Some use a third party library to do a more clumsy variation of the Python and Haskell examples above. And a few recent ones use Java 8 to do a slightly less clumsy variation of the Python and Haskell examples above. The clear trend is to try to get away from classical, verbose Java to something more powerful and expressive. Like Scala, according to the first comment on the original question...

By that argument, doesn't any powerful abstraction make code harder to understand? Similarly, doesn't any verbose style make code easier to understand, even if the boilerplate contributes no additional meaning? Sorry, but I can't agree with this sort of reasoning at all. If it was that simple, we'd still be writing large software systems in assembly language and no-one would use any sort of libraries or modular design.

I'd agree with the ecosystem being a huge factor in Java's success.

More than that, it is a relatively closed ecosystem. Tools like JNI are available, but in practice few projects seem to use them. Mostly, either you're working in JVM world or you're working somewhere else. That's a lot of momentum to overcome for any long-standing project or development team to move to another language, tool chain, standard library, and so on.

I also think the summary's claim that Java is easy for humans to understand at a glance because of its simplicity is a mischaracterisation. Java is a relatively verbose, inexpressive language, so actually it can take quite a long time to figure out how any given piece of code works. What Java does offer is that an average developer can reliably figure out how any given piece of code works, even if it takes a while. For long-running, large-scale projects that is a valuable attribute for a programming language.

I've been programming in Python professionally for something close to a decade now, and in all that time the number of tab/space bugs I've seen in production is: 0.

Get a good edit -- any good editor -- and worry about problems that actually matter. This one was solved in about 1927.