Hacker News Reader

Comment by rvense | Hacker News Reader

Maybe compare to second year students of a very foreign language...

(Though I have to say, I'm a self-taught programmer with an academic background in theoretical linguistics as well as university-level experience of several languages quite different to my first language, and this result doesn't not surprise me. There are some obviously analogies to be made at some levels, I think the similarity between human languages and computer code is frequently overstated and a remnant from a more primitive linguistics that was quite narrowly focused on grammar.)

View on HN

> I think the similarity between human languages and computer code is frequently overstated

It wouldn't even occur to me to think of them as belonging to the same category.

Occasionally you come across languages that do and, at least to me, those languages feel extremely difficult to deal with. For instance, I found AppleScript and HyperTalk to be awful to work with.

I also notice that some junior programmers I've worked with tend to argue for coding styles in mainstream languages that read almost like sentences. Not sure if this is a generational thing or an experience thing.

I’ve seen the same thing, it might be generational. Someone arguing that we need an isNotEqual(a, b) helper in addition to isEqual(a, b), because that’s supposedly “cleaner” and more readable than !isEqual(a, b). They were very vehement about it, but I don’t get that at any level. It’s more lines of code to write and maintain, more unit tests, more characters to type at the usage site and to me, reads exactly the same way.

My personal opinion is that 'not' (Python-style) should be the operator instead, simply because it's easier to miss a ! than a 'not'. With that said, I'm with you in the 'not isEqual(a, b)' camp.

The exception, imo, is functions that take boolean arguments. Languages should make it easy to show what they mean, and devs should take care to explain them.

sort(reverse=true, numeric=false) is much easier to read than sort(true, false).

(Silly example, it's meant to illustrate the general point, not to say anything about the signature of a sort() function.)

For me, reading isNotEqual() introduces an extra mental variable. I have to spend extra effort to keep track of the bar over the statement that doesn't exist in the text.

But that said, I see no reason that someone couldn't learn to parse notX as fluently as I parse !X. I suppose it's one of those fashions that change with the times. Probably a big reason that I stick to good old C a lot of the time.

One problem is that when refactoring it's easy to make a monster like "if (!notX()) ..."

What's old is new again - see SQL and COBOL. They certainly are easy to get the gist of from the words even if you don't know the language. (The business logic may be spaghetti in a COBOL program, but what's happening is clear.) I like it, and I remember SQL easier after disuse than the syntax of something else I've used equally sparsely like bash scripting.

Then on the opposite end of the spectrum wrt new things, we have Rust, which comes off to me as pathologically terse and inscrutable - certainly much more difficult for a newbie to parse than SQL.

Why?

Unwrap a loaf of bread

Pull out two pieces

Put them side by side

Spread peanut butter on the left one

Spread jam on the right one

Etc.

Reply on news.ycombinator.com