Comment by btilly | Hacker News Reader

Comment by btilly | Hacker News Reader

Parent Full thread

Different software communities have different opinions on what makes life better for programmers.

As far as I can see, programming language researchers are just a subset of those communities with their own sets of beliefs. On average researchers are much smarter and better educated than most programmers. However it is likely that the majority of the smartest and best educated people are NOT in academia. (Before doubting that, remember there is an eternal brain drain of top people from academia to industry for the simple reason that industry pays more.)

In the case of the developers of Go, we are talking about people who I believe to be smarter than the vast majority of programming language researchers, and who _definitely_ have more experience around large software systems. They have come to different opinions about what makes that kind of development work. People like Ken Thompson and Rob Pike might not be right, but it would be unwise to assume that they are necessarily wrong simply because they disagree with a bunch of programming language researchers.

> In the case of the developers of Go, we are talking about people who I believe to be smarter than the vast majority of programming language researchers

Why would you have such an opinion ? I can turn the problem in my head a thousand times, i still can't see why. Because it is from the makers of Unix ?

The only way i could make sense of your statement is by saying people who makes the most used technology are the most clever, intrinsically. But i think this is an incredibly naive point of view.

I can see a bunch of things that make Go susceptible to have success : Traction, from the name of it's inventors and main sponsor (Google). Simple philosophy that makes it easy to learn, and pragmatic orientation. It doesn't mean it's a better language in any way. Just that it's aiming for the path of least resistance.

It is a respectable goal. Now i don't see the logic in saying that PL researchers are not as smart because they have more idealistic goals.

That wasn't what he said, though.

Checking golang a bit, I didn't feel it was "aiming for the path of least resistance". For instance, blocking compilation if any imported module is unused or forbidding circular dependencies, is going against the "let's let the coders do what they want".

I am currently involved in refactoring a big Python code base and I oh-so regret Python (which I like very much) is so easy-going on these issues.

Flake8 detects unused imports and generally adds some rigor that Python otherwise lacks. Not perfect, but it has made Python more pleasant for me for larger code bases especially.

Unix isn't the most used software, but it is probably the best. I think the makers of unix bring with them a strong sense of pedigree, but also something of a expectation that it shares unix design principles. Not sure if it does this or not, but the baggage is there.

UNIX is the "least crappy so far". There are probably better ways to do things, but we don't know them yet.

I believe this is traditionally where the smug LISP weenies descend.

trap door creaks open, a Symbolics Genera machine running Zmacs is behind codewright

You raaaang?

Oh, we do, e.g. Plan 9, but that doesn't mean the better ways can overcome the popularity of the incumbent that's "good enough".

Why would you have such an opinion ? I can turn the problem in my head a thousand times, i still can't see why.

I'd guess that Ben is basing this on decades of exposure to papers published, work done, and books published by Pike and Thompson. He then compares this to the many other programming language researchers with whom he has personal and professional familiarity, and offers his opinion on their relative abilities. He's not arguing 'in principle', he's stating his personal assessment of these particular individuals.

Exactly. There is no shortage of material to decide on. From articles like http://cm.bell-labs.com/who/ken/trust.html, to books like The Practice of Programming, to software like Unix and UTF-8, the invention of UTF-8, with many books in between, their abilities and accomplishments are obvious. There is also no shortage of articles like http://www.cs.princeton.edu/courses/archive/spr09/cos333/bea... written by people whose opinions I respect, lauding their abilities.

By contrast I have no reason to believe that the average programming language researcher is smarter than the average CS prof. It would be astounding if this average was anywhere near Pike and Thompson.

It is pointless to even discuss averages in populations where only a handful of people at the top matter.

I, in turn, have no reason to believe that the average systems programmer is smarter than Robin Milner or Guy Steele. So what?

I agree that they are among the smartest people for the job and that is why I am so surprised (and annoyed) that they choose tabs over spaces.

If for no other reason than that I have to have a different .vimrc file for my go programs than literally everything else.

Perhaps they're right and you're wrong?

Tabs are used for tabulating stuff. Spaces are used for spacing stuff. Indentation is a form of tabulation, so use tabs. Similarly to when you use a word processor, do you hold space down for long enough to center your text or do you use the "center" alignment? Right tools for the right job.

Hell it's not exactly hard to fix in vim either - just load the provided vim extensions as per the instructions and it just works without screwing up the rest of your configuration.

The amount of time I've had to spend dredging through fucked up merges where someone has added 5 or 3 spaces to the start of the line instead of 4 gives credence to why you should use tabs as the tab means "indented one level" rather than "n spaces depending on how the user or editor fucked up the file".

Anyway, rant over - sorry.

Lucky for you, they wrote a ftplugin for you.

tabs mean you and i can vary in how our editor displays the text -- this is the simplest form of separation of style from content.

Reply on news.ycombinator.com