5 ms·

As someone who writes both Lisp and Go (and enjoys both), I find it odd that this article uses Lisp and Haskell as points of comparison. > programming in Go i

As someone who writes both Lisp and Go (and enjoys both), I find it odd that this article uses Lisp and Haskell as points of comparison. > programming in Go isn’t “fun” in the same way that Python, Haskell, or Lisp is. Yes, writing Lisp is much more "fun" than writing Go for me. But writing Go is much more productive and maintainable (both for solo projects and for larger groups). In fact, this is almost an intentional "feature" of Go: http://aerokode.com/blog/go-is-boring http://aerokode.com/blog/go-is-boring > The idea is that there’s simply no way that any group of designers could imagine how people will want to use their language so making it easy to extend solves the problem wonderfully. On the other hand, there's no way of making a language so easily extensible while also maintaining relatively uniform idiomatic, design, and style conventions across a language community. Go very heavily favors the latter. > In Lisp, CLOS (Common Lisp Object System) was originally a library. It was a user defined abstraction that was so popular it was ported into the standard. CLOS is actually very similar in some ways to Go's structs. Both emphasize encapsulating data inside an "entity" (object/struct), and separating the notion of behavior from that entity. To quote one of the language authors from GopherCon[0]: "Interfaces separate data from behavior. Classes conflate them." Lisp was "designed" (if you can call it that) around the principle that extending a language should be as easy as writing a program in that language. Go was designed around the principle that there should be only one dialect of the programming language, for the sake of cohesiveness. It's a stronger assertion of the Pythonic motto, "There should be one, and preferably only one, obvious way to do it". [0] https://twitter.com/chimeracoder/status/459827405386162176 https://twitter.com/chimeracoder/status/459827405386162176

masklinn 12y ago
> CLOS is actually very similar in some ways to Go's structs. You've completely missed the article's point: users were able to create CLOS before it got integrated in the language.
- chimeracoder 12y ago
  Yes, my point is that Go intentionally makes it hard for users to extend the language, while simultaneously learning from the successes and failures of other languages, and Yes, my point is that Go intentionally makes it hard for users to extend the language, while simultaneously learning from the successes and failures of other languages, and incorporating the results of that into Go. The fact that users are able to create core language features has its drawbacks when it comes to cohesion in the language community. Lisp itself is a perfect example of this - codebases are immensely fragmented in terms of which libraries they end up using (Quicklisp is, in part, an effort to solve this). Lisp was "designed" (if you can call it that) around the principle that extending a language should be as easy as writing a program in that language. Go was designed around the principle that there should be only one dialect of the programming language, for the sake of cohesiveness. Both are legitimate philosophies for different use cases, but that's why it's kind of silly (IMHO) to compare Go to Lisp - the goals are not only different, but diametrically opposed in most ways.
  - Pxtl 12y ago
    I think the problem with Lisp is that it grew organically from a large community across multiple languages and 50 years of life. Not that the language was excessively expressive. Go, on the other hand, was designed and implemented from a single vendor in a handful of years. That makes it far easier to provide a single, coherent platform. Once you provide a coherent, complete platform you don't need your users to solve every edge-case by implementing their own language features. Any language that doesn't provide some kind of code-that-writes-code workflow will eventually leave its developers dealing with frustrating boilerplate.
DAddYE 12y ago
> Yes, writing Lisp is much more "fun" than writing Go for me. But writing Go is much more productive and maintainable (both for solo projects and for larger groups). Not sure about this statement. As the OP said in order to trick the anti-features of go you need to come up with super verbose syntax. Which is easy that's true but when the project tends to be quite big the mission becomes hard. Also the "go get" thing is neat for small projects but for larger project IMHO is just broken. Godeps or few sh scripts can alleviate this but definitely is something needed to be addressed.
Pxtl 12y ago
> Yes, writing Lisp is much more "fun" than writing Go for me. But writing Go is much more productive and maintainable (both for solo projects and for larger groups). I heard ASP.Net WebForms get this defense, that no other platform could handle the "enterprise" needs for maintainability and every other platform was just building a pile of cowboy spaghetti code. Turns out it just sucked.
- egeozcan 12y ago
  > Turns out it just sucked. Well, an anecdotal counter-evidence is that we have some WebForms apps maintained by another team in our company and the developers from that team seem very happy and are productive enough to meet reasonable deadlines. I despise WebForms but that doesn't mean anything from a product managers perspective.
slantedview 12y ago
Yes, Go is boring, but it's interesting that the people who hate on Go for being boring are not the same people who hate on Java for being boring (though Java 8 is much improved).
- chc 12y ago
  People don't hate Java for being boring, per se. They hate it for being inflexible, verbose and having a bureaucratic culture.
  - twic 12y ago
    People hate Java because it's unremarkable but successful. There's nothing particularly innovative or wild about it, but equally, nothing particularly awful (plenty of mediocre, of course). Whether despite or because of that, it somehow became the most widely-used language in places you get paid to sit and write code. It always feels cool to hate popular things, and it always feels cool to hate boring things. Hence, Java became the Nickelback of programming languages.
    - spoiler 12y ago
      I like some Nickelback songs. Also, I don't hate on Java, I've even gotten seriously into it for about two years (for a university project and later got a job based on that), and it just made me unhappy (which is a big deal for me, for unrelated reasons). However, I never felt unhappy coding in Ruby (love it!), C (even though it was/is frustrating sometimes), C++ (ok, I am relatively new to it), Python, JavaScript... I tried other languages like Haskell, Erlang and similar, that didn't stick (Erlang syntax will plague me with confusion forever, probably), but nine of them made me unhappy when I worked in them.
  - krick 12y ago
    I don't really get what all you guys mean by "boring". I'd appreciate some clarification (especially about Go). What does it mean for language to be "fun"? I have some intuition of "fun", but it doesn't play well with what are you saying. I'd say being "fun" means ability to solve your problems easily, concentrating on problems themselves, not on language pitfalls. Isn't it? That's pretty much synonymous (maybe a little broader though) to "productive". So I can't comprehend how language can be "less fun, but more productive and maintainable".

masklinn 12y ago

> CLOS is actually very similar in some ways to Go's structs. You've completely missed the article's point: users were able to create CLOS before it got integrated in the language.

chimeracoder 12y ago
Yes, my point is that Go intentionally makes it hard for users to extend the language, while simultaneously learning from the successes and failures of other languages, and Yes, my point is that Go intentionally makes it hard for users to extend the language, while simultaneously learning from the successes and failures of other languages, and incorporating the results of that into Go. The fact that users are able to create core language features has its drawbacks when it comes to cohesion in the language community. Lisp itself is a perfect example of this - codebases are immensely fragmented in terms of which libraries they end up using (Quicklisp is, in part, an effort to solve this). Lisp was "designed" (if you can call it that) around the principle that extending a language should be as easy as writing a program in that language. Go was designed around the principle that there should be only one dialect of the programming language, for the sake of cohesiveness. Both are legitimate philosophies for different use cases, but that's why it's kind of silly (IMHO) to compare Go to Lisp - the goals are not only different, but diametrically opposed in most ways.
- Pxtl 12y ago
  I think the problem with Lisp is that it grew organically from a large community across multiple languages and 50 years of life. Not that the language was excessively expressive. Go, on the other hand, was designed and implemented from a single vendor in a handful of years. That makes it far easier to provide a single, coherent platform. Once you provide a coherent, complete platform you don't need your users to solve every edge-case by implementing their own language features. Any language that doesn't provide some kind of code-that-writes-code workflow will eventually leave its developers dealing with frustrating boilerplate.

DAddYE 12y ago

> Yes, writing Lisp is much more "fun" than writing Go for me. But writing Go is much more productive and maintainable (both for solo projects and for larger groups). Not sure about this statement. As the OP said in order to trick the anti-features of go you need to come up with super verbose syntax. Which is easy that's true but when the project tends to be quite big the mission becomes hard. Also the "go get" thing is neat for small projects but for larger project IMHO is just broken. Godeps or few sh scripts can alleviate this but definitely is something needed to be addressed.

Pxtl 12y ago

> Yes, writing Lisp is much more "fun" than writing Go for me. But writing Go is much more productive and maintainable (both for solo projects and for larger groups). I heard ASP.Net WebForms get this defense, that no other platform could handle the "enterprise" needs for maintainability and every other platform was just building a pile of cowboy spaghetti code. Turns out it just sucked.

egeozcan 12y ago
> Turns out it just sucked. Well, an anecdotal counter-evidence is that we have some WebForms apps maintained by another team in our company and the developers from that team seem very happy and are productive enough to meet reasonable deadlines. I despise WebForms but that doesn't mean anything from a product managers perspective.

slantedview 12y ago

Yes, Go is boring, but it's interesting that the people who hate on Go for being boring are not the same people who hate on Java for being boring (though Java 8 is much improved).

chc 12y ago
People don't hate Java for being boring, per se. They hate it for being inflexible, verbose and having a bureaucratic culture.
- twic 12y ago
  People hate Java because it's unremarkable but successful. There's nothing particularly innovative or wild about it, but equally, nothing particularly awful (plenty of mediocre, of course). Whether despite or because of that, it somehow became the most widely-used language in places you get paid to sit and write code. It always feels cool to hate popular things, and it always feels cool to hate boring things. Hence, Java became the Nickelback of programming languages.
  - spoiler 12y ago
    I like some Nickelback songs. Also, I don't hate on Java, I've even gotten seriously into it for about two years (for a university project and later got a job based on that), and it just made me unhappy (which is a big deal for me, for unrelated reasons). However, I never felt unhappy coding in Ruby (love it!), C (even though it was/is frustrating sometimes), C++ (ok, I am relatively new to it), Python, JavaScript... I tried other languages like Haskell, Erlang and similar, that didn't stick (Erlang syntax will plague me with confusion forever, probably), but nine of them made me unhappy when I worked in them.
- krick 12y ago
  I don't really get what all you guys mean by "boring". I'd appreciate some clarification (especially about Go). What does it mean for language to be "fun"? I have some intuition of "fun", but it doesn't play well with what are you saying. I'd say being "fun" means ability to solve your problems easily, concentrating on problems themselves, not on language pitfalls. Isn't it? That's pretty much synonymous (maybe a little broader though) to "productive". So I can't comprehend how language can be "less fun, but more productive and maintainable".