Comment by jfoutz | Hacker News Reader

Comment by jfoutz | Hacker News Reader

Parent Full thread

Buffalo buffalo buffalo Buffalo buffalo, is hard to parse because English is very expressive. And you kinda have to know words have different meaning in different context. If I explain buffalo is another word for bison, and also buffalo means coerce, I can rephrase this

Bison from Buffalo coerce other Bison from Buffalo.

Generally, making a language more expressive makes it harder to parse. You have to know a lot more stuff. Computer languages often have a formal spec. I think java does, but I don't think perl does. Regardless, you just have to remember that footnote on page 26 of the manual that the construct X is an option.

I haven't touched java in a while, but I do remember some difficulty with parent class constructors calling methods implemented in the children, that relied on member variables that hadn't been initialized yet. I wish I could point at a concrete example, but I think it was something deep in the heart of swing (part of the jre so not changeable).

I can't imagine a way this makes it easier to parse in my head as I'm reading through code, or communicate failure. but there probably are libraries that become more usable with this new syntax.

It sucks because you're guaranteed super is called, the parent class can implement stuff that _has_ to happen. there's no way for me to force a subclass to call, something like pleaseInitializeAfterSuper(). and there's no way for me to do anything before super, right now.

Regardless, there's no easy way out. Making the language more expressive is a damn big hammer to use though. you'd think you could use a builder to guarantee initialization, But sometimes you can't.

To answer your question, no. I don't think this makes it easy to communicate why a program was rejected. it makes more programs possible though. At the cost of having to remember that footnote on page 26.

> Buffalo buffalo buffalo Buffalo buffalo, is hard to parse because English is very expressive. And you kinda have to know words have different meaning in different context. If I explain buffalo is another word for bison, and also buffalo means coerce, I can rephrase this

> Bison from Buffalo coerce other Bison from Buffalo.

The words don't have different meanings, though, at least in idiomatic English. No-one uses the word "buffalo" to mean "coerce". I'd be surprised if you could find even a handful of examples of it being used that way.

File the "many buffalos" thing under the same heading as the "code golf / obfuscated C" type things where you've got a chain of half a dozen ternary operators wrapped in a loop to make a state machine, where a switch() statement would suffice.

I've heard this example before, but you have a great point - I've never heard anyone use "buffalo" as a verb before. I wonder what possible better versions we could collectively come up with. "Badger" is much more commonly used as a verb, but I'm unaware of a well-known location called Badger.

I support that proposal ... but I can't immediately think of anything.

Vaguely related: www.marchmarchmarch.org.uk

Badger badgers badger badger badgers

(a badger being someone who makes badges, and thus badger badger being someone who makes badger badges)

Also, if you can have a badge depicting a badger badger, then badger badger badgers badger badger badger badgers.

PS. Mushroom! MUSHROOM! Panic, a snake!

The "intimidate" meaning of buffalo is in a bunch of dictionaries, I just checked. Regional slang, I guess?

But is it in active use? I've never found anything. I feel like I'd find it in some 19th-century American literature, maybe some Ambrose Bierce or Mark Twain.

Your example isn't about expressiveness, it's about ambiguity. I don't get the relevance, to be honest.

What’s the other way to parse? I totally don’t see it.

It's not ambiguous because there are multiple ways to parse it. It's ambiguous because all tokens are identical save capitalization and represent different POS elements based on position and context.

I am not sure what your definition of "expressive" is. To me, effectiveness to convey thought or ideas in this context. And I don't have the faintest idea of what that sentence means.

The proposed new rules for calling this() and super() aren't so foreign. It seems to be almost the same rules as for assigning final instance variables (e.g. class Foo { final int bar; } }), where you must definitely assign every final field exactly once in the constructor, not more, not less.

Still, after I experienced the constructor-less paradigm in Rust, where you only can only construct structs entirely all at once, and every "constructor" is just a static factory function, it's harder to justify the traditional OOP paradigm in Java, C++, etc.

As explicitly stated in the proposal the new rules about super/this calls are exactly the same as for a blank final field initialization. So the change simplifies some aspects of the language as it removes number of rules.

Moreover, given that Java calls overridden methods when super() calls a non-final method, the existing rules prevent some reasonable code patterns (again, see the proposal for the example) and the new ones allows to address those in reasonable and readable ways.

Reply on news.ycombinator.com