Using the pronoun "their" rather than "his" is the politically correct but grammatically incorrect approach that seems to be favored these days. Here's the non-politically-correct version of that sentence:

"Frenk wasn't particularly happy with his job, but was one of the "rockstar programmers" ... "

Naturally this is highly frowned upon because it imposes the male gender on a person whose gender we don't know (and whose gender may, in fact, not matter at all). And I'm not even going to approach the territory of gender identification.

I suspect Remy used "were" instead of "was" to match the plural nature of "their". So, to make the sentence internally consistent we need to change "one" to "some".

If you want to be politically correct AND grammatically correct, it's much simpler to write this:

"Frenk wasn't particularly happy with its job, but was one of the "rockstar programmers" ... "

"Frenk wasn't particularly happy with his job, but was one of the "rockstar programmers" ... "
Naturally this is highly frowned upon because it imposes the male gender on a person whose gender we don't know (and whose gender may, in fact, not matter at all). And I'm not even going to approach the territory of gender identification.

No, it doesn't impose the male sex on Frenk. There are two pronoun sets spelled he/him/his: "person of male sex" and "person of unspecified sex". This use is self-evidently the second, except that a great many people today are (inadequately educated / miseducated / just plain ignorant)(1) and think that only the first pronoun set exists.

But that just makes them *wrong*.

(1) Choose from this list as you see fit, or create your own version. However you choose to express it, these people have not had the distinction between the two sets adequately explained. I absolutely refuse to accuse anyone of a feminist conspiracy to suppress knowledge of the second so as to make people who use it seem like sexist pigs.

Am I the only one bothered with the lack of braces in the refactored code? One level without braces, okay although I'd include them anyway. Two levels is like an invitation for future misunderstanding.

Singular "they" goes back farther than the 19th century. For citations back to 1526, check out http://englishbibles.blogspot.ca/2006/09/singular-they-in-english-bibles.html; the Wikipedia page (https://en.wikipedia.org/wiki/Singular_they) has citations back to 1382.

I also like Ursula K. LeGuin's take: https://twitter.com/davemakes/status/955932631350181888

Those are not singular 'they'. They're uncertain of number 'they'. "Some", "none", "all", "any", "each", "eachother"; you can find 'they' used for all of those. What you won't find is 'they' used for "this specific single person whose gender I do not know". That would be singular they; and that does not occur before at best 1950.

The Dickinson quote mentioned in the M-W article, for example, is "anyone", therefore, "uncertain of number", not "singular but I'm not willing to divulge gender". "Frenk", by contrast, very much is a singular person, presumably (going by the name) male but possibly female. The distinction is obvious to anyone without a 1970s axe to grind.

Did Antonio also refactor the rest of the method or the calling code all the way up the stack, so it can handle the expected exceptions? "Resource" doesn't seem to be a class in the standard Java or JEE library, so we don't know what checked and unchecked exceptions it might throw, but presumably it can throw exceptions (maybe IO exceptions?) If the calling code was intentionally catching IllegalStateException, and now that code will throw the original exceptions, you could have changed your program for the worse. For example, the new code might crash the entire app on a bad file path, when perhaps it used to handle IllegalStateExceptions gracefully.

I see we're all distracting ourselves by arguing about pronouns, for some "deity-but-you-can-refer-to-him/her/it/them-as-Nature-if-it-makes-you-feel-better" awful reason.

Suck it up, all of you. Common usage will eventually decide one way or the other, and common usage is all that matters, and in the mean time Remy's intent is perfectly clear.

Now, about the "rocks-in-the-head" star programmer:

As the refactoring makes clear, the original problem is a million miles away from being so near-impossible that it demands any such contortion in the code. I yearn for the good old days, when Java programmers were simple stupid straightforward people writing simple stupid straightforward code in a language that offered only simple stupid straightforward constructs.

Breath-taking. Not only have I never seen a try-catch inside a lambda expression (in any language), I'd never even considered the idea. Now that I've considered it, I'm going to scrub out the relevant brain-cells with a wire brush.

Yes, that's an important consideration. It's generally considered good form to write a Java program that deals with file input/output, but doesn't deal specifically with IO exceptions. There are probably thousands of Java applications that work this way and are basically 100% sound.

The exception stuff added by Frenk in the original is there because a lambda function passed to Collectors.toMap() (or any of the builtin stream stuff) is not allowed to throw any checked exceptions. If you ignore that the code becomes:

But since getFile() and getInputStream() understandably throw IOException, you cannot write it this way. I could see where someone would start with the above, get the compilation errors and end up where Frenk did. That doesn't excuse the poor indentation or potential NullPointerException however. Never mind explaining WHY you would want a map of files to input streams in the first place.

That's all very well, but we're not speaking bloody French, and we don't need some steenking Academy to tell us what's right and what's wrong. English is a mutable language, created by usage. Correct English is that which conveys the meaning intended to be conveyed.

It's quite clear that given modern usage your old-fashioned prescriptivism is just plain wrong - not that it ever had any real validity, but at at least those rules were once the general usage.

The fact that "he" can be either masculine or neutral does a disservice to both feminine and masculine people and I for one support attempts to make language work better for everyone. Particularly when the argument against is prescriptive apologism "but this is how language WORKS." Language changes to suit the needs of its speakers. We're all hardwired to comprehend language, but not any particular language.

When RLB writes you can find 'they' used for all of those. What you won't find and such, that's a descriptivist argument.

More on topic, though:

On its surface, it’s not an objectively wrong approach- this is the kind of things streams are theoretically good at.

I think a major reason the streams API didn't try to accommodate checked exceptions is that many checked exceptions (especially IOException and SQLException) are predominantly in code that has side-effects. And, theoretically, streams aren't good at handling side-effects.

I wouldn’t mind this “dynamic English language” mantra if the language was being changed by lingvists because it was really lacking. Instead, it is being changed by a bunch of morons who never learned enough vocabulary to properly express themselves so they go on a crusade to redefine wrong words to express what was already possible with other words they never bothered to learn.

By the way whoever developed this website sucks Krogan quads. Mobile layout is terrible to the point of being unusable. You ever heard of responsive design? That a bunch of developers cannot fix that is the WTF that is overshadowing every WTF story ever published. Hire someone who knows modern CSS for fuck sake.

The main reason the streams API doesn't handle checked exceptions is simply that it can't. A Java closure is just sugar for providing an implementation of some callback interface, so it can't throw checked exceptions unless the callback method declares them. So to be usable, all the standard functional interfaces would need to have their methods declared as "throw Exception", and all code implementing the streams API would likewise have to either be "throws Exception" (forcing the caller to deal with every possible exception type), or would have to catch checked exceptions and wrap and re-throw them as runtime exceptions. Irritating as the problems causes by checked exceptions and closures are, neither of these options would be an improvement.

Language is always defined by morons. Morons in this case meaning the greatest group of language users. It's the attempts by linguists to force order or grammar on the language that historically fails. This is why e.g. 'to meme' is now a verb. You can rant and rail against it all you want, but it doesn't change a thing, bro.

I wouldn’t mind this “dynamic English language” mantra if the language was being changed by lingvists because it was really lacking.

Ah, but English is defined to be the language spoken by the English speakers (yes, that's circular). Therefore it is always the prescriptivist linguists that are wrong. This annoys prescriptivist linguists no end. This means that dictionaries of English must track actual usage, no matter how much it irritates the lexicographers concerned, though they usually seem to be types who find it interesting watching the evolution of the language in real time.

I don't understand people who fear the loop and other programmatic basics.

It could be worse though. There's a horrible pattern to this I've been observing. In programming I keep bumping into of just everything is bad.

Gotos are bad, elses are bad, ifs are bad, nulls are bad, loops are bad, variables are bad, more than 50 lines of code a file is bad, more than one level of logical nesting is bad, switch statements are bad, structs are bad (pure data that gets operated on), static anything is bad, pointers are bad, arrays are bad, public constructors are bad, etc.

I might not be a fan of all of these in all circumstances but it gets ridiculous when people insist that this is bad, that is bad, it's forbidden. In terms of prohibitions I think even the Taliban would have a hard time matching what seems to be hip today in programming.

It starts out as someone does a talk. Sometimes it reasonable sometimes it's just dictating their personal preferences. Often a group of people will listen to preachers and teachers but never understand.

Sure if you have:

if data.somesuch: do a with data
else: do b

In a tonne of disparate places really heavily then you might want to think, hey, perhaps that wants to be a class. It's the kind of lesson if you have to teach someone then they're probably not going to get it if they're been coding already and still haven't figured it out.

Simple rules also while not necessarily that effective or practical are very easy to enforce.

The result is that code reviews become if/else pogroms, mobs form with pitchforks and torches to exterminate sacrilegious keywords and flow control structures.

Anyone who argues that natural language is dynamic is basically too careless and lazy to use it properly. They just want to twist it and break it beyond recognition to accomplish their goal. Unfortunately, the same kind of people does the same thing with computer languages hence the need for this website.

Languages have rules. They are there to prevent mistakes. Those who break the rules are bound to repeat mistakes made by others.

The main reason the streams API doesn't handle checked exceptions is simply that it can't.

No, the main reason is what I wrote. Quoth the docs: Stream pipeline results may be nondeterministic or incorrect if the behavioral parameters to the stream operations are stateful. ... Side-effects in behavioral parameters to stream operations are, in general, discouraged, as they can often lead to unwitting violations of the statelessness requirement, as well as other thread-safety hazards.

So to be usable, all the standard functional interfaces would need to have their methods declared as "throw Exception" ... or would have to catch checked exceptions

No, you can set an exception class as a parameter to a generic interface, as in interface Thing<T extends Exception> { void call() throws T; }. You can then write void foo(Thing<RuntimeException> thing) { thing.call(); } and it won't require a try-catch block.

Natural language is exactly that. There are no "rules", only those rules agreed on by the people who are using the language. Those rules are subject to change, and have indeed changed over time even for the english language. There is a commonly held fiction, that a word's definition is exactly that found in a dictionary for a word. Nothing could be further from the truth. A word means exactly what a speaker intends for it to mean, nothing more.