7 ms·

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 "progra

by tikhonj 14y ago

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.

cgag 14y ago
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?
- dill_day 14y ago
  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-languages http://tagide.com/blog/2012/03/research-in-programming-langu...
  - twelvechairs 14y ago
    Great link. Thanks!
  - comex 14y ago
    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.
    - pcwalton 14y ago
      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.
      - tel 14y ago
        Clojure is far from pure.
        pcwalton 14y ago
        Yeah, that was a bad choice of words; what I was getting at was the emphasis on immutability.
    - azth 14y ago
      > 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.
- azth 14y ago
  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.
leothekim 14y ago
"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.
- kenko 14y ago
  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.
  - Evbn 14y ago
    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.
cageface 14y ago
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.
- dlisboa 14y ago
  > 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.
  - dbaupp 14y ago
    And to add to that, many Haskell people freely admit that they themselves barely understand all of Haskell, or still have much to learn.
- Raphael_Amiard 14y ago
  I think Simon Peyton Jones says it best about Haskell : http://www.youtube.com/watch?v=iSmkqocn0oQ 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)
philwelch 14y ago
I just think Haskell and Go solve different problems.
6ren 14y ago
Gosling said similar about Java https://docs.google.com/viewer?url=dfjug.org/thefeelofjava.pdf https://docs.google.com/viewer?url=dfjug.org/thefeelofjava.p...
comex 14y ago
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.
btilly 14y ago
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.
- Raphael_Amiard 14y ago
  > 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.
  - xyproto 14y ago
    That wasn't what he said, though.
  - gbog 14y ago
brianobush 14y ago
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.
Evbn 14y ago
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.
Jare 14y ago
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?
- riffraff 14y ago
  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?
- azth 14y ago
  Immutability.
grey-area 14y ago
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?
- peteretep 14y ago
  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...
  - grey-area 14y ago
    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.
  - _feda_ 14y ago
    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.
emmelaich 14y ago
I think it's about the long game. Go is for now. Haskell is for eventually. Mostly.
dscrd 14y ago
>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.
fauigerzigerk 14y ago
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.
- Evbn 14y ago
  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.
  - fauigerzigerk 14y ago
    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.
JulianMorrison 14y ago
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.
- pcwalton 14y ago
  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.
  - deleted 14y ago
    [deleted]
aufreak3 14y ago
"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.
- kenko 14y ago
  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.
  - krutulis 14y ago
    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.

by tikhonj 14y ago

cgag 14y ago

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?

dill_day 14y ago
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-languages http://tagide.com/blog/2012/03/research-in-programming-langu...
- twelvechairs 14y ago
  Great link. Thanks!
- comex 14y ago
  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.
  - pcwalton 14y ago
    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.
    - tel 14y ago
      Clojure is far from pure.
      - pcwalton 14y ago
        Yeah, that was a bad choice of words; what I was getting at was the emphasis on immutability.
  - azth 14y ago
    > 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.
azth 14y ago
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.

leothekim 14y ago

"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.

kenko 14y ago
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.
- Evbn 14y ago
  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.

cageface 14y ago

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.

dlisboa 14y ago
> 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.
- dbaupp 14y ago
  And to add to that, many Haskell people freely admit that they themselves barely understand all of Haskell, or still have much to learn.
Raphael_Amiard 14y ago
I think Simon Peyton Jones says it best about Haskell : http://www.youtube.com/watch?v=iSmkqocn0oQ 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)

philwelch 14y ago

I just think Haskell and Go solve different problems.

6ren 14y ago

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

comex 14y ago

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.

btilly 14y ago

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.

Raphael_Amiard 14y ago
> 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.
- xyproto 14y ago
  That wasn't what he said, though.
- gbog 14y ago

brianobush 14y ago

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.

Evbn 14y ago

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.

Jare 14y ago

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?

riffraff 14y ago
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?
azth 14y ago
Immutability.

grey-area 14y ago

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?

peteretep 14y ago
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...
- grey-area 14y ago
  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.
- _feda_ 14y ago
  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.

emmelaich 14y ago

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

dscrd 14y ago

>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.

fauigerzigerk 14y ago

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.

Evbn 14y ago
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.
- fauigerzigerk 14y ago
  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.

JulianMorrison 14y ago

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.

pcwalton 14y ago
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.
- deleted 14y ago
  [deleted]

aufreak3 14y ago

"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.

kenko 14y ago
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.
- krutulis 14y ago
  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.