Hacker News Reader

Comment by nrjdhsbsid | Hacker News Reader

For a language I find as reasonably designed as Java, this is stupid.

Add a new key"word", don't deprecate a whole fucking character in a language that's been around for twenty years.

It pains me to consider the horrific amount of code this will break. The lifetimes of hours spent deleting _ that would have been writing whimsical poetry in a moonlit garden or curing cancer.

I'm not surprised I guess given that Java is "owned" by Oracle now. Hopefully they kill it off quickly so we can get the migrations to openjdk overwith.

View on HN

Never seen single underscore as variable, field or method name and never seen any naming convention that allowed that (and I've read a lot of open source code too). Conclusion: it's a pain only for those who didn't care about readability of their code and it's definitely not the end of the world.

I've seen it popping up a lot lately. It's used as an identifier for lambda functions, indicating "i must use a variable identifier here, but I don't use it"

someObject.doSomething(_ -> isDerp());

Exactly the case when you get warning in Java 8. Bad code written by lazy devs and now it's time for them to pay.

No it's not, it's illegal to use _ as a lambda parameter.

"It pains me to consider the horrific amount of code this will break"

Almost none.

_ was never encouraged, promoted, it wouldn't really fit with any sort of Java coding practice at all.

So I don't think it will be a huge issue.

> Add a new key"word"

That's exactly what they're doing. And exactly why many languages are hesitant to add new keywords ever, since you could be using anything as a variable name. (Hence the practice of reserved words which might become keywords in the future.)

> I'm not surprised I guess given that Java is "owned" by Oracle now. Hopefully they kill it off quickly so we can get the migrations to openjdk overwith.

What makes you think that OpenJDK isn't owned by Oracle, or that OpenJDK won't add the _ keyword, given that it's part of the Java 9 spec?

I'll admit the last part was just using a good opportunity to diss Oracle. The longer the keyword the less name collisions there will be in general, using a single character is absolute worst case if you want to avoid breaking code

I highly doubt that, seems like you'd get a lot more name collisions if you make something commonly used as a variable (such as index or length) a keyword instead of the seldomly-used underscore.

It is the string '_' that turns into a keyword. Names like _buh or BUH_HUH will still be valid.

> The lifetimes of hours spent deleting _

that's... quite a lot of _

The sheer amount of Java code written is nearly unfathomable. Maybe 3 million developers each churning out 20000 lines a year. That's about 60 billion lines of Java code per year. There could easily be over a trillion lines of Java out there.

If that is true, it's stuff for nightmares.

Here is something I made to lighten the mood: https://i.imgur.com/qzOPn85.png

.. or maybe this is even scarier. I'm not sure.

edit: downvotes from java devs incoming :D

Hahahaha

Edit: I'm a Java guy too, don't get why some people get so butthurt over things :)

At least it's not JavaScript with infinity,null,undefined, and NaN. Oh and null!=null which is hilarious

LOL yeah.. don't get me started about JS :D.

I more of a C++ guy, but I like Java very much and have used it extensively in the past. I personally like a good C/C++ joke and can't understand why the Java devs are so serious. Apparently nobody is allowed to joke about Java, it's serious business :D

For what it's worth, you should _always_ be using triple-equals in Javascript unless you have an overwhelmingly good reason not to. Many of the weird Javascript-isms people like to complain about are due to surprising type coercions, which don't happen with triple-equals (which behaves as you would expect- value equality without type coercion for primitive types and reference equality otherwise.)

For someone who uses a more than one language on a regular basis, triple equals is an annoying break with convention. It shouldn't be that easy to make a mistake by simply missing an extra character. This is one of many reasons I've taken to using TypeScript for all of my web frontend projects.

However you still run into the same problems with > , < , <= , and =>. So you need to really really understand the corner cases (same as with C++).

You mean NaN != NaN. null == null is true, and null != null is false.

NaN != NaN is surprising, but is not unique to JavaScript. As far as I know, this is the case in every language, and is mandated by the IEEE 754 specification.

However, it does come up in JavaScript more often than other places, since NaN is really easy to get (+{} => NaN, 1 - '' => NaN, etc, etc).

In SQL, 'NULL <> NULL' is true as well, you have to use 'NULL IS NULL' instead, so the concept has a long and somewhat respectable pedigree...

Reply on news.ycombinator.com