Hacker News Reader

Comment by tikhonj | Hacker News Reader

What annoys me a little bit about Go (and other projects similarly adherent to "worse is better") is the implied dichotomy between "research" and making "programming lives better". Do they think the point of Haskell isn't to make programming easier? That's what most of the research into the language is exactly about! This isn't just about Haskell either: most other PL research is also about making programming lives easier. And Go ignores essentially all of it.

Now, there is even nothing strictly wrong about ignoring research like that. It's just annoying how they revel in ignoring all recent progress in the field.

View on HN

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.

Haskell is an elegant language but Haskell fans will be much more effective advocates of the language if they admit that it's conceptually very difficult for most programmers to grasp. Some of the most experienced and capable programmers I've ever known have struggled to get their head around Haskell, and I don't buy the argument that it's only because their minds have been poisoned by overexposure to other languages.

Haskell is important and I'm glad it exists but I think Go has a much better chance of become a plausible alternative to Java and C++ and perhaps Python in most programming shops.

> and I don't buy the argument that it's _only_ because their minds have been poisoned by overexposure to other languages.

I've not heard that argument. I think most Haskell people would acknowledge theirs is not an easy language to learn and program.

The argument is especially non-stick because in practicality every programmer will be "poisoned" by other languages. That means that even if Haskell wasn't a hard language to learn in theory (i.e. if a "virgin" brain could learn it just fine), in practice it will be.

It's easier to expand on the solid points of the language, not easiness of understanding. But like I said, I've not seen Haskell being thrown around in that fashion.

And to add to that, many Haskell people freely admit that they themselves barely understand all of Haskell, or still have much to learn.

I think Simon Peyton Jones says it best about Haskell :

http://www.youtube.com/watch?v=iSmkqocn0oQ

He says Haskell is useless. Without even debating that (it can certainly be useful for certain classes of programming problems), you can see his point : The goal of Haskell was to start from an ideal view (pure functional programming without side effects) and try and see how to make that eventually practical for everyday programming, without sacrificing the pure core of the language.

You have languages, like F# (or even C# !) that takes lessons from Haskell, with at the same time being practical for pretty much every programming task (their platform , .Net, makes them useless for a lot of use cases, but that is another problem)

And on the other side (in my opinion), you have languages like Go, being pretty dismissive about pretty much everything learned from languages like Haskell.

I respect the point of view of Go's creator, i just disagree with it, and don't see any project i could do in Go that i wouldn't prefer doing in Scala/OCaml/C#. But more power to people who want to do great things in Go !

Go fills a niche (AOT compiled without a VM) that only OCaml fills in the list of languages i have listed, and OCaml is probably much more complicated to learn, even if it is way simpler than Haskell, so even if i don't agree with the design choices, i can see why Go could gain traction (apart from the fact that it is Google powered)

Peyton-Jones said that Haskell was useless before they got a handle on how to do IO. Haskell is clearly not useless at present.

However it's far harder to make it not useless than other choices. To me at least, Haskell appears to be alphabet soup like badly written Perl. The syntax is so close to the metal it's unreal.

SPJ's comment had nothing to do with lexical syntax.

I'm not sure exactly what exactly you're referring to, but I'd say it's not so much "worse is better" (in the traditional sense that simplicity of implementation is better than simplicity of interface) but "simplicity is better" (than maximum functionality, whether in implementation or interface). Generics, for instance, are not exactly recent PL research, but Go doesn't have them (yet) because they tend to add complexity to both interface and implementation.

As for Haskell, well - whether or not it makes programming easier, it adds complexity, and it certainly doesn't have the 'free and light' feeling borrowed from dynamic languages that Go likes to revel in.

For what it's worth, Rust includes a lot of pragmatically useful research stuff that was passed over in Go. In particular, I think Rust's emphasis on immutability is a better decision that will result in faster, lock-free code. (Yes, it counts as locking when you have to pass the one-and-only pointer to a thing over a channel just to read it.) But Rust is a big complicated language. Go is syntactically tiny, and that's an advantage in an number of ways, from speed of compilation to ease of use.

Usually when people say "big and complicated", they mean C++, which Rust is much simpler than. We put a lot of effort into keeping Rust as minimalist as possible without sacrificing the language goals. It's certainly a bigger language than Go, of course.

"This isn't just about Haskell either: most other PL research is also about making programming lives easier. And Go ignores essentially all of it."

That's a bold statement, and I'm not sure that's what Rob Pike is asserting. I saw his presentation as saying "We knowingly made tradeoffs in the programming language to, in part, make managing large codebases tractable." He's right in saying that dependency management isn't intrinsic in most of programming language theory today, and it's a big productivity sink for development organizations with very large codebases.

Slides eight and nine, to me at least, suggest by the implicit contrast between research and helping programmers that the Go designers just weren't interested in the state of PL research.

That is because PL research isn't interested in helping programmers write programs under their real world constraints. Pike isn't interested in what geologists have to say about programming languages either.

I don't think making the lives of a maximum number of today's industrial software engineers simpler is the main concern of academic PL researchers, nor should it be. A PL researcher should be able to spend time working on formal aspects of some thought experiment without thinking about interoperability, compile times, social issues in large corporations, etc.

And then programming languages are user interfaces. Hence, researching them is a social science and a cognitive science as much as it is a formal science. I don't hear much about that aspect from PL researchers. Arguably, language designers with an industrial background know a lot more about that than academic PL researchers. It may not be very scientific, but they should have pretty good intuitive access to these things.

Why should PL researchers care only about languages and lot about language usage? Only about programs and not how to create them? That seems extremely ivory tower to no good.

I believe they do care about that, but it shouldn't limit their thinking too much. For instance, there could be a wonderful model of computing that no current machine can efficiently implement. Kind of like Lisp in the 1950s.

You aren't the first person I've seen that mention that goes ignores a lot of programming research. Would you mind expanding on that for someone who doesn't know much about PL research / theory? Are they missing things you think a modern language should have? What are they doing wrong according to research?

You might like to check out this blog post by Cristina Videira Lopes (though it's not about Go in particular): http://tagide.com/blog/2012/03/research-in-programming-langu...

Great link. Thanks!

The way I like to think of it is that a large component of PL design is making something pleasant for humans to use, which is more of an art than a science: inherently subjective (not everyone likes the same things), holistic (it's not any one feature of Python that makes it Pythonic, it's the whole philosophy), and hard to quantify. So it's no surprise that rigorous design is not the prime factor in popularity of programming languages.

I don't think, however, that really explains why research languages these days have very little in common with popular languages - why purity and strict types and all their baggage, despite their promise to make software less buggy, have not been widely adopted. There are a few reasons why this might be the case (not just "FP is hard and most programmers aren't very good at programming", although that is one factor), but their sum seems to be something fundamental about software design - perhaps changeable, but identifiable as a unit, not simply a consequence of the limitations of rigorous design.

I don't think the divide between research and industry languages is as deep as you imply. Take your examples: purity and strict typing. Purity has been adopted wholesale by Clojure and has influenced C++11 (constexpr implies purity in addition to many other things). Go, the subject of the post, is stricter about type conversions than the C family languages are. Java's type-safe implementation of generics was influenced by ML.

Clojure is far from pure.

Yeah, that was a bad choice of words; what I was getting at was the emphasis on immutability.

> why purity and strict types and all their baggage, despite their promise to make software less buggy, have not been widely adopted.

I am guessing is it mainly due to the inertia of the current popular languages (C, C++, Java, Python, etc.), and that none of them offer such guarantees. There are tons of libraries written in them, and so it is hard to move away from them. I am hoping that Scala and Rust will change things.

While I am not an expert at PLs, one thing they definitely missed for a language that claims to be "built for scale/multicore" is immutability. Not only is it not default for variables to be immutable (like many functional/hybrid programming languages), but there is no notion of immutability built in to the language in the first place.

The slides (and plenty other Go literature) describe the metrics used to decide Go features in quite a lot of detail. If these metrics are applicable in your context, then Go is more likely to "make your life better" than Haskell.

Can you point out to specific PL research results that Go has outright ignored, rather than decided against for X reasons?

this is a very interesting question, but can it be answered?

I mean, we can say that design by contract (or linq/multiple dispatch/type state/whatever) offers an interesting solution to common problems and was ignored.

But.. just because it's not listed in the FAQs?

Immutability.

It is strange the way negative comments float to the top of most HN stories, but I guess it sometimes makes for interesting debates.

Do they think the point of Haskell isn't to make programming easier?

This comment makes me genuinely curious, why do you feel Haskell has not taken off? Do you feel it is easier than Go to use or to pick up?

Do you spend most of your time "programming" learning how to program? Or using what you've learned? Haskell has a steep learning curve, for sure, and that's one reason it doesn't have widespread use. Once you've learned it, programming in it is arguably a lot more enjoyable (and thus easier) than other languages...

It seems a lot of people have trouble ever escaping the steep learning curve stage in Haskell, but it does look interesting and your post has inspired me to go take a look at the Haskell intro docs.

However I definitely wouldn't group Go with 'worse is better' languages like PHP, so that seems an inaccurate description to me. I suppose what I was interested to know from those advocating Haskell as intrinsically better than Go was whether the learning curve is the only issue with Haskell, or whether there are also times in daily use where it sacrifices ease of use/comprehension for power, as opposed to Go where there is a great emphasis on making the language itself as simple as possible, even at the cost of some convenience.

Ultimately it's not practical to use it, so even if it is easier to use after the great hump of the learning curve, it's still not good for real world applications, principally because of libraries, support and ubiquitousness . Certain languages reach terminal velocity, whereupon their real world usefulness goes up exponentially, and whether they are well designed or not the become practically necessary.

"Research" is about producing new knowledge about something, which in this case is programming computers.

The slide on the problems that the Go system solves points out things the solving of which is unlikely to yield significant new knowledge in the domain. Yet solving those problems does improve the lives of programmers and so is a valuable engineering contribution.

For some problems, they do reuse techniques that are at least two decades old. Putting import information in compilation units at the head to speed up compilation was already done in Turbo Pascal and is available in Free Pascal today. They also did take up CSP as a concurrency model.

    "Do they think the point of Haskell isn't to make programming easier?"

The point of Haskell was stated by the community much early on -- that they'd try to "avoid success at all costs". "Making programming easier" isn't even a clearly definable research goal I think. Easier for who? .. for which problems? .. on which kinds of machines and environments? Haskell, as I see it, is a platform for experimenting with new techniques and asking "what if?" questions. A sandbox to play in. If it happens to make certain kinds of programming tasks easy and elegant, that's a by product.

The focus on Haskell as an alternative is unfortunate. What about, say, Racket? There's a language that emerged out of PL research, by researchers that clearly care about getting programming concepts across to people (The Little Schemer, etc.), that's pragmatically oriented and has a lot of research-derived neat features.

Is the problem that there are too few Racket boosters? Racket seems pretty swell to me.

Good point. The focus on evaluating the success or failure of programming languages as a popularity contest is also unfortunate. There is also the matter of influence.

In the mid 80's I took Dan Friedman's (author of The Little Schemer) Programming Languages course and simply had a ton of fun learning all about Scheme & the implementation of languages. I had no idea at the time it would be by far the most important class that I took as either an undergraduate or graduate student.

Turns out, one of the most important things programming languages do is influence the way we learn and think about computation. I've learned crucial lessons from Scheme and all the languages I've worked in over the years. To this day, I am perplexed by people so vested in one programming language that they fear instead of savor the chance to work in another.

As a math major, a key lesson demonstrated so vividly by Prof Friedman & by the philosophy of Scheme resonated with me personally: the importance of clearly understanding "what depends on what?" and of learning which things can and/or should be made fundamental and which derivative.

The Golang Team has looked at their problem domain and, through the creation of Go, has built a striking and innovative statement on what they've judged as fundamental. I welcome their emphasis on selectivity over accumulation and believe there is much to be learned from their choices.

Racket's goals appear more pedagogical and the effort they put in (which is bloody awesome for a relatively small team, btw) on the pragmatic aspects is to the extent necessary for teaching.

If we, again, ask whether Racket (or any of the features in it such as delimited continuations) can help solve the problems that the Go team wants solved, I still need to scratch my head a bit. For example, V8 has overtaken mzscheme w.r.t. speed and you would (rightly) ask for a comparison with Node today for a class of server applications. (Being a PL buff, I'm pretty familiar with Racket/Haskell, having written and deployed a Scheme interpreter myself.)

I offer another categorization - Go is to design where Racket/Haskell is to research. A good part of design work involves intelligent trade offs. In PL research, you're interested in ideas, new ways of thinking, insights, optimization techniques, etc. You're not (usually) interested in taking a new idea and packaging it so it is digestible to a certain class of programmers. Constant factor speed improvements are also not usually interesting to PL research, but very welcome to the pragmatic programmer. Syntax design, for example, is seldom the highlight of a PL research project.

>Do they think the point of Haskell isn't to make programming easier? That's what most of the research into the language is exactly about!

After a decade of trying to "get" Haskell, I have to say that they are doing an awful job at it.

Gosling said similar about Java https://docs.google.com/viewer?url=dfjug.org/thefeelofjava.p...

I think it's about the long game. Go is for now. Haskell is for eventually. Mostly.

One of the original goals of Go was to be a practical systems PL; that isn't one of Haskell's goals which focus on higher-order programming.

I just think Haskell and Go solve different problems.

Haskell's designers believe in the goal of great pegramming, but they refuse to compromise today to help engineers. Haskell Ultimate will be better than Go. But it doesn't exist yet.

Reply on news.ycombinator.com