You're thinking of the ZFS that goes through FUSE. There is also ZFS on Linux that runs as kernel modules like any other fs.

There's also btrfs.

Of course, neither of those needs the md driver at all, they have their own raid like systems.

Really? What are they, then?

Since the contact details are her work details posted to a public website and in regard to a work matter, it's not a problem. Private contact details would be over the line.

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.

Then learn to affect a cheesy eastern European accent and tell the interviewer you are after Moose and Perl.

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.

But certainly not on a regular road ridden by something other than 5 elephants.

The school owned the camera he used. Therefore all work from that camera belongs to the school.

No. It does not work like that. If you borrow my guitar and write a hit song, it's your song, the copyright is yours. If you borrow my camera and take a Pulitzer-winning photo, it's your photo, the copyright is yours. Copyright goes to the creator of a work, not to the owner of any tools incidental to the creation.

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.

Yet we DID have a patient zero not long ago and the spread was very limited and died out quickly in spite of your claim that there is no herd immunity at our current level of vaccination.