5 ms·

Oh ok, I understand. I don't really buy the idea that go is a simple language, I have to say. A lot of go's design choices read (to me) as needlessly complex, l

by oisdk 7y ago

Oh ok, I understand. I don't really buy the idea that go is a simple language, I have to say. A lot of go's design choices read (to me) as needlessly complex, like features were added to address corner cases one by one instead of implementing the fundamental feature in the first place. "Multiple return values" instead of tuples; several weird variations on the c-style for-loop; special-cased nil values instead of `Maybe` or `Optional`; `interface {}` and special in-built types instead of generics, etc. ADTs and pattern-matching would obviate "multiple return values", nils, and greatly simplify error handling.

reificator 7y ago
A very instructive exercise for anyone who is or intends to be a software developer is to write some sort of interpreter and/or compiler. (As well as a virtual machine and/or emulator) Depending on your approach this can take a weekend, a few months, or the rest of your life. For instance, and amusingly enough written in golang, one of the most respected recent books on this topic is `Writing an Interpreter in Go` and its sequel `Writing a Compiler in Go`. https://interpreterbook.com/ https://interpreterbook.com/ and https://compilerbook.com/ https://compilerbook.com/ Both of these books are reasonably short, and have the reader make meaningful progress within a weekend. Going through the motions of actually making your own programming language (or reimplementing an existing one) teaches you a lot of things you wouldn't otherwise expect about how to write general code, how to use existing languages effectively, and how things work under the hood. It's also one of the best ways to really get a practical feel for how to approach unit testing. It's an exercise I'd recommend if you haven't gone through it already. It might make it really click for you why some features that seem like a no brainer and should be in every language aren't, and why some undesirable "features" are so prevalent.
- Scarbutt 7y ago
  one of the most respected recent books on this topic is `Writing an Interpreter in Go` Is 'recent' the key word here? ;) cause that is a very bold claim to make.
  - reificator 7y ago
    https://news.ycombinator.com/item?id=21154309 https://news.ycombinator.com/item?id=21154309
- AdieuToLogic 7y ago
  > A very instructive exercise for anyone who is or intends to be a software developer is to write some sort of interpreter and/or compiler. Another exercise, perhaps less demanding in this regard, is to explore using Free Monads[0] to implement an EDSL[1] for a problem domain. Of course, the approachability of this varies based on the person involved. > For instance, and amusingly enough written in golang, one of the most respected recent books on this topic is `Writing an Interpreter in Go` and its sequel `Writing a Compiler in Go`. Queue obligatory reference to "the dragon book": Compilers: Principles, Techniques, and Tools[2] 0 - https://softwareengineering.stackexchange.com/questions/242795/what-is-the-free-monad-interpreter-pattern https://softwareengineering.stackexchange.com/questions/2427... 1 - https://www.quora.com/What-is-an-embedded-domain-specific-language https://www.quora.com/What-is-an-embedded-domain-specific-la... 2 - https://suif.stanford.edu/dragonbook/ https://suif.stanford.edu/dragonbook/
  - reificator 7y ago
    Yeah I'm definitely not saying anything bad about the Dragon book here. But I know there's a recency bias when people are evaluating tech books, so if there's a good book from the last five years I'll recommend that over a great book from the last 15, just so there's a higher chance of the recommendation actually being used.
    - AdieuToLogic 7y ago
      No worries mate. I mentioned the dragon book by obligation, not in comparison to the works you referenced.
      - andersyr 7y ago
        If anyone is curious about an updated resource, I've found Modern Compiler Design much more approachable than the Dragon Book: Published in 2012, it includes chapters on designing object-oriented, functional, and logical compilers. https://www.springer.com/gp/book/9781461446989 https://www.springer.com/gp/book/9781461446989
- tom_mellior 7y ago
  > It might make it really click for you why some features that seem like a no brainer and should be in every language aren't, and why some undesirable "features" are so prevalent. I hate this kind of "I have secret knowledge, why don't you spend T amount of your time on some big project to maybe come to the same secret insights I mean". If you have an opinion on why pattern matching is so complex and undesirable, just come out and say it please. Otherwise I'll just call you out as not really having an argument.
  - deleted 7y ago
    [deleted]
  - mdpopescu 7y ago
    Ah... in religion we call that "gnosticism". (Not really important, it just struck me as something weird to find in a HN thread.)
  - reificator 7y ago
    > I have secret knowledge, why don't you spend T amount of your time on some big project to maybe come to the same secret insights I mean Alternate interpretation, I learned something valuable from doing this thing, perhaps you'd be interested in doing so as well since the book that took months or years to write will do a better job teaching it than I will in a five minute break while typing on HN. It's always impressive when freely sharing knowledge and tips is somehow taken as being insular and exclusive. > If you have an opinion on why pattern matching is so complex and undesirable Where did I say pattern matching is undesirable? It sounds more like you just want a fight here. Remember the HN guidelines: > Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
    - tom_mellior 7y ago
      > It's always impressive when freely sharing knowledge and tips is somehow taken as being insular and exclusive. But you didn't share knowledge. You suggested that you had knowledge that was pertinent to the topic at hand. But you didn't share it. You did share tips for resources where one can learn more, and that's great. But you didn't add something like "... and that's where I learned that pattern matching is undesirable because <technical reason>". > Where did I say pattern matching is undesirable? This whole thread was about you saying that pattern matching was undesirable from the point of view of Go's designers or implementors due to their design goal of simplicity. Then you mentioned those compiler resources. The only reasonable interperetation for me is that you wanted to say that you did indeed know concrete technical reasons why pattern matching in Go would be complicated and therefore undesirable.
kunos 7y ago
You keep missing the point entirely. Go was created to solve a very specific Google scenario: offer a valid alternative to C++ and Java for whatever they do in Google. It's not a language created to make college students or language hippies happy..if you are looking for that look somewhere else. Go can be picked up by any dev with minimal experience in C/C++/Java in 1-2 weeks and that was one the main design targets. Another one was fast compile times, adding all those nice features you'd like would also make the language more complex to parse and compile. I think you can talk about how much you like Haskell all day long, but if you keep using Go as a comparison you simply show you have no clue of what you are talking about. It's literally apples to oranges.
- oisdk 7y ago
  Maybe I am missing the point! It certainly wouldn't be the first time in an argument about programming languages. I do understand, though, that the purpose of Go is not necessarily to push the boundaries of language design. I also understand that it's important the language is easy to pick up, compiles quickly, etc. I think that some of Go's design decisions are bad, even with those stated goals in mind. Again, I don't want to overstate my experience or knowledge of language design (although I do know a little about Google's attitude towards Go, since that's where I spent my internship learning it), but some features (like "multiple return values" instead of tuples) seem to me to be just bad. Tuples are more familiar to a broader range of programmers, aren't a strange special case, are extremely useful, and have a straightforward implementation. Also, I don't want a bunch of fancy features added to Go: ideally several features would be removed, in favour of simpler, more straightforward ones.
  - reificator 7y ago
    I do agree, I would prefer tuples to multiple return in go. Perhaps they find it easier to teach to users coming from languages with less or no type inference? Java and C++ programmers in my experience don't tend to be familiar with tuples, despite there being a tuple in the C++ stdlib. My purely uninformed guess is that it's because of how verbose declarations can get in Java, or in C++ without auto/decltype from C++11.
renox 7y ago
> Multiple return values instead of tuples I remember having some bugs in Python due to one element tuples, I don't think I would have had the same issue if Python had multiple return value instead..

by oisdk 7y ago

reificator 7y ago

A very instructive exercise for anyone who is or intends to be a software developer is to write some sort of interpreter and/or compiler. (As well as a virtual machine and/or emulator) Depending on your approach this can take a weekend, a few months, or the rest of your life. For instance, and amusingly enough written in golang, one of the most respected recent books on this topic is `Writing an Interpreter in Go` and its sequel `Writing a Compiler in Go`. https://interpreterbook.com/ https://interpreterbook.com/ and https://compilerbook.com/ https://compilerbook.com/ Both of these books are reasonably short, and have the reader make meaningful progress within a weekend. Going through the motions of actually making your own programming language (or reimplementing an existing one) teaches you a lot of things you wouldn't otherwise expect about how to write general code, how to use existing languages effectively, and how things work under the hood. It's also one of the best ways to really get a practical feel for how to approach unit testing. It's an exercise I'd recommend if you haven't gone through it already. It might make it really click for you why some features that seem like a no brainer and should be in every language aren't, and why some undesirable "features" are so prevalent.

Scarbutt 7y ago
one of the most respected recent books on this topic is `Writing an Interpreter in Go` Is 'recent' the key word here? ;) cause that is a very bold claim to make.
- reificator 7y ago
  https://news.ycombinator.com/item?id=21154309 https://news.ycombinator.com/item?id=21154309
AdieuToLogic 7y ago
> A very instructive exercise for anyone who is or intends to be a software developer is to write some sort of interpreter and/or compiler. Another exercise, perhaps less demanding in this regard, is to explore using Free Monads[0] to implement an EDSL[1] for a problem domain. Of course, the approachability of this varies based on the person involved. > For instance, and amusingly enough written in golang, one of the most respected recent books on this topic is `Writing an Interpreter in Go` and its sequel `Writing a Compiler in Go`. Queue obligatory reference to "the dragon book": Compilers: Principles, Techniques, and Tools[2] 0 - https://softwareengineering.stackexchange.com/questions/242795/what-is-the-free-monad-interpreter-pattern https://softwareengineering.stackexchange.com/questions/2427... 1 - https://www.quora.com/What-is-an-embedded-domain-specific-language https://www.quora.com/What-is-an-embedded-domain-specific-la... 2 - https://suif.stanford.edu/dragonbook/ https://suif.stanford.edu/dragonbook/
- reificator 7y ago
  Yeah I'm definitely not saying anything bad about the Dragon book here. But I know there's a recency bias when people are evaluating tech books, so if there's a good book from the last five years I'll recommend that over a great book from the last 15, just so there's a higher chance of the recommendation actually being used.
  - AdieuToLogic 7y ago
    No worries mate. I mentioned the dragon book by obligation, not in comparison to the works you referenced.
    - andersyr 7y ago
      If anyone is curious about an updated resource, I've found Modern Compiler Design much more approachable than the Dragon Book: Published in 2012, it includes chapters on designing object-oriented, functional, and logical compilers. https://www.springer.com/gp/book/9781461446989 https://www.springer.com/gp/book/9781461446989
tom_mellior 7y ago
> It might make it really click for you why some features that seem like a no brainer and should be in every language aren't, and why some undesirable "features" are so prevalent. I hate this kind of "I have secret knowledge, why don't you spend T amount of your time on some big project to maybe come to the same secret insights I mean". If you have an opinion on why pattern matching is so complex and undesirable, just come out and say it please. Otherwise I'll just call you out as not really having an argument.
- deleted 7y ago
  [deleted]
- mdpopescu 7y ago
  Ah... in religion we call that "gnosticism". (Not really important, it just struck me as something weird to find in a HN thread.)
- reificator 7y ago
  > I have secret knowledge, why don't you spend T amount of your time on some big project to maybe come to the same secret insights I mean Alternate interpretation, I learned something valuable from doing this thing, perhaps you'd be interested in doing so as well since the book that took months or years to write will do a better job teaching it than I will in a five minute break while typing on HN. It's always impressive when freely sharing knowledge and tips is somehow taken as being insular and exclusive. > If you have an opinion on why pattern matching is so complex and undesirable Where did I say pattern matching is undesirable? It sounds more like you just want a fight here. Remember the HN guidelines: > Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
  - tom_mellior 7y ago
    > It's always impressive when freely sharing knowledge and tips is somehow taken as being insular and exclusive. But you didn't share knowledge. You suggested that you had knowledge that was pertinent to the topic at hand. But you didn't share it. You did share tips for resources where one can learn more, and that's great. But you didn't add something like "... and that's where I learned that pattern matching is undesirable because <technical reason>". > Where did I say pattern matching is undesirable? This whole thread was about you saying that pattern matching was undesirable from the point of view of Go's designers or implementors due to their design goal of simplicity. Then you mentioned those compiler resources. The only reasonable interperetation for me is that you wanted to say that you did indeed know concrete technical reasons why pattern matching in Go would be complicated and therefore undesirable.

kunos 7y ago

You keep missing the point entirely. Go was created to solve a very specific Google scenario: offer a valid alternative to C++ and Java for whatever they do in Google. It's not a language created to make college students or language hippies happy..if you are looking for that look somewhere else. Go can be picked up by any dev with minimal experience in C/C++/Java in 1-2 weeks and that was one the main design targets. Another one was fast compile times, adding all those nice features you'd like would also make the language more complex to parse and compile. I think you can talk about how much you like Haskell all day long, but if you keep using Go as a comparison you simply show you have no clue of what you are talking about. It's literally apples to oranges.

oisdk 7y ago
Maybe I am missing the point! It certainly wouldn't be the first time in an argument about programming languages. I do understand, though, that the purpose of Go is not necessarily to push the boundaries of language design. I also understand that it's important the language is easy to pick up, compiles quickly, etc. I think that some of Go's design decisions are bad, even with those stated goals in mind. Again, I don't want to overstate my experience or knowledge of language design (although I do know a little about Google's attitude towards Go, since that's where I spent my internship learning it), but some features (like "multiple return values" instead of tuples) seem to me to be just bad. Tuples are more familiar to a broader range of programmers, aren't a strange special case, are extremely useful, and have a straightforward implementation. Also, I don't want a bunch of fancy features added to Go: ideally several features would be removed, in favour of simpler, more straightforward ones.
- reificator 7y ago
  I do agree, I would prefer tuples to multiple return in go. Perhaps they find it easier to teach to users coming from languages with less or no type inference? Java and C++ programmers in my experience don't tend to be familiar with tuples, despite there being a tuple in the C++ stdlib. My purely uninformed guess is that it's because of how verbose declarations can get in Java, or in C++ without auto/decltype from C++11.

renox 7y ago

> Multiple return values instead of tuples I remember having some bugs in Python due to one element tuples, I don't think I would have had the same issue if Python had multiple return value instead..