7 ms·

It is a bit astonishing what lengths the go community is willing to, er, go, in order to avoid compile-time code execution (the basis of lisp macros) or generic

It is a bit astonishing what lengths the go community is willing to, er, go, in order to avoid compile-time code execution (the basis of lisp macros) or generics. I understand that neither of these ideas were invented at Bell Labs during the 1970s, but at some point, can't we just put aside the not invented here syndrome? Could we all just agree to pretend that Bell Labs folks invented those ideas? Would that work?

zuzun 12y ago
So how many programming languages besides LISP are powerful enough to support turning Protocol Buffers into code during compilation? And is this the ultimate must have?
- logicchains 12y ago
  It could be done in OCaml or Haskell, considering they both have compile-time AST generation/manipulation, but I'm not sure if anyone's written an actual implementation of this. Nimrod too, as that has AST macros. As does Elixir.
- pjmlp 12y ago
  D, Rust, Nim(rod), Template Haskell, OCaml, C++...
  - mseepgood 12y ago
    I don't think these can open and read .proto files during compilation.
    - pcwalton 12y ago
      Rust can.
      - tuxychandru 12y ago
        Are you referring to compiler plugins like the one providing regex! macro or is it something else?
        wycats 12y ago
        Yes, compiler plugins. For a relevant example, check out the Rust docopt crate[1]. An identical technique could be used for yacc or protobufs. [1]: https://github.com/docopt/docopt.rs https://github.com/docopt/docopt.rs
    - pjmlp 12y ago
      D has meta-programming and compile-time evaluation, including reading files. I bet C++ can do it with some clear use of template metatprogramming, compile time evaluation and processor macros. Nim has meta-programming capabilities, including reading files. Not sure about Template Haskell, though.
      - thesz 12y ago
        Template Haskell code can runIO I/O actions, including reading files.
    - jeremyjh 12y ago
      Haskell can, but there is not an implementation that does this.
      - hawkice 12y ago
        To be clear for the Haskell newbies, he's talking about an implementation of the protobuf library, not Haskell. You can fairly easily lift from Template Haskell types into IO in GHC (not sure about TH in other compilers).
- ben0x539 12y ago
  F# type providers sound like they're for this sort of thing. I expect Scala has a similar macro facility. Nemerle can probably do it too.
- NateDad 12y ago
  I don't want my language to be that complicated. "Powerful" has nothing to do with it.
personZ 12y ago
The Go community are out building solutions productively and fruitfully, often finding the lack of generics an edge nuisance, but something that is by no means a showstopper. The people who have no knowledge or skill in Go, on the other hand, fill the message boards, railing rabidly about how absolutely critical generics are, and don't these people (who almost universally have extensive experience across a number of languages) know what they're missing?
- frowaway001 12y ago
  The point you are missing is that people who don't want to live in the 1970ies avoid Go in the first place, so the Go community by definition consists only of people who think Java-1.0 style programming is perfectly fine in 2014. Yes, there are reasons why the intended audience of Go just didn't care and Go is mostly used PHP, JavaScript, Python, Ruby etc, developers today.
  - vorg 12y ago
    > Go is mostly used PHP, JavaScript, Python, Ruby etc, developers today Could be dynamic typing has had its day, just like visual programming from the 1990's. Or maybe users of those languages wanted to use one with a large corp backing it, like Java and C# have. The most common glib response I get when I say I'm trying out Go to write something is "You're using Go? So you wanna work for Google, do you?" Perhaps that shows the real motivation of why a programmer learns Ruby or Python or Go.
  - shurcooL 12y ago
    There are people who want their language to be as complicated and feature-rich as possible. They have lots of choices available, including C++1*, Java, Ruby, etc. Those languages probably don't have anything that has only one idiomatic solution. Even writing a for loop will have multiple different but viable alternatives. Then there are people who want their language to be as simple as possible, yet still powerful enough to allow you to create all the things you can with Go. There are very few such languages. In fact, there are a few things/special rules I'd like to see simplified in Go because they have less benefit than cost. Having a simple language allows for some cool benefits, and if Go starts to compete with C++ for number of features, it will lose its main distinctive property.
blablabla123 12y ago
There have been many lengthy disucssions about generics on the Go mailing list. Haven't checked them in a while but the essence used to be that generics are difficult. C++ has really powerful generics but unfortunately C++ templates are in many respects a nightmare. Java templates on the other hand are not really powerful. The idea was to wait until someone would come up with a powerful generics concept that is nice for the developer.
- pjmlp 12y ago
  Generics exist in multiple forms since CLU (1974). To reduce them to what C++ and Java implementations offer, is just being ignorant from history of programming languages.
  - frowaway001 12y ago
    > being ignorant from history of programming languages Isn't that Go's design principle?
    - NateDad 12y ago
      People in the 70's knew a lot more about programming than you seem to think.
      - frowaway001 12y ago
        Yes, but they weren't so self absorbed to dismiss the 40 years of experience in front of them.
        NateDad 12y ago
        Not all languages need to have all the features of Haskell or Rust. Just as not All languages need to be dynamically typed. Just because a language is missing your favorite feature(s), doesn't mean it's a bad language. And maybe you have tried writing programs in go and didn't like it. That's fine. But there's no need to insult everyone who uses language. Every language has its niche, even perpetual punching bags like vb and php.

zuzun 12y ago

So how many programming languages besides LISP are powerful enough to support turning Protocol Buffers into code during compilation? And is this the ultimate must have?

logicchains 12y ago
It could be done in OCaml or Haskell, considering they both have compile-time AST generation/manipulation, but I'm not sure if anyone's written an actual implementation of this. Nimrod too, as that has AST macros. As does Elixir.
pjmlp 12y ago
D, Rust, Nim(rod), Template Haskell, OCaml, C++...
- mseepgood 12y ago
  I don't think these can open and read .proto files during compilation.
  - pcwalton 12y ago
    Rust can.
    - tuxychandru 12y ago
      Are you referring to compiler plugins like the one providing regex! macro or is it something else?
      - wycats 12y ago
        Yes, compiler plugins. For a relevant example, check out the Rust docopt crate[1]. An identical technique could be used for yacc or protobufs. [1]: https://github.com/docopt/docopt.rs https://github.com/docopt/docopt.rs
  - pjmlp 12y ago
    D has meta-programming and compile-time evaluation, including reading files. I bet C++ can do it with some clear use of template metatprogramming, compile time evaluation and processor macros. Nim has meta-programming capabilities, including reading files. Not sure about Template Haskell, though.
    - thesz 12y ago
      Template Haskell code can runIO I/O actions, including reading files.
  - jeremyjh 12y ago
    Haskell can, but there is not an implementation that does this.
    - hawkice 12y ago
      To be clear for the Haskell newbies, he's talking about an implementation of the protobuf library, not Haskell. You can fairly easily lift from Template Haskell types into IO in GHC (not sure about TH in other compilers).
ben0x539 12y ago
F# type providers sound like they're for this sort of thing. I expect Scala has a similar macro facility. Nemerle can probably do it too.
NateDad 12y ago
I don't want my language to be that complicated. "Powerful" has nothing to do with it.

personZ 12y ago

The Go community are out building solutions productively and fruitfully, often finding the lack of generics an edge nuisance, but something that is by no means a showstopper. The people who have no knowledge or skill in Go, on the other hand, fill the message boards, railing rabidly about how absolutely critical generics are, and don't these people (who almost universally have extensive experience across a number of languages) know what they're missing?

frowaway001 12y ago
The point you are missing is that people who don't want to live in the 1970ies avoid Go in the first place, so the Go community by definition consists only of people who think Java-1.0 style programming is perfectly fine in 2014. Yes, there are reasons why the intended audience of Go just didn't care and Go is mostly used PHP, JavaScript, Python, Ruby etc, developers today.
- vorg 12y ago
  > Go is mostly used PHP, JavaScript, Python, Ruby etc, developers today Could be dynamic typing has had its day, just like visual programming from the 1990's. Or maybe users of those languages wanted to use one with a large corp backing it, like Java and C# have. The most common glib response I get when I say I'm trying out Go to write something is "You're using Go? So you wanna work for Google, do you?" Perhaps that shows the real motivation of why a programmer learns Ruby or Python or Go.
- shurcooL 12y ago
  There are people who want their language to be as complicated and feature-rich as possible. They have lots of choices available, including C++1*, Java, Ruby, etc. Those languages probably don't have anything that has only one idiomatic solution. Even writing a for loop will have multiple different but viable alternatives. Then there are people who want their language to be as simple as possible, yet still powerful enough to allow you to create all the things you can with Go. There are very few such languages. In fact, there are a few things/special rules I'd like to see simplified in Go because they have less benefit than cost. Having a simple language allows for some cool benefits, and if Go starts to compete with C++ for number of features, it will lose its main distinctive property.

blablabla123 12y ago

There have been many lengthy disucssions about generics on the Go mailing list. Haven't checked them in a while but the essence used to be that generics are difficult. C++ has really powerful generics but unfortunately C++ templates are in many respects a nightmare. Java templates on the other hand are not really powerful. The idea was to wait until someone would come up with a powerful generics concept that is nice for the developer.

pjmlp 12y ago
Generics exist in multiple forms since CLU (1974). To reduce them to what C++ and Java implementations offer, is just being ignorant from history of programming languages.
- frowaway001 12y ago
  > being ignorant from history of programming languages Isn't that Go's design principle?
  - NateDad 12y ago
    People in the 70's knew a lot more about programming than you seem to think.
    - frowaway001 12y ago
      Yes, but they weren't so self absorbed to dismiss the 40 years of experience in front of them.
      - NateDad 12y ago
        Not all languages need to have all the features of Haskell or Rust. Just as not All languages need to be dynamically typed. Just because a language is missing your favorite feature(s), doesn't mean it's a bad language. And maybe you have tried writing programs in go and didn't like it. That's fine. But there's no need to insult everyone who uses language. Every language has its niche, even perpetual punching bags like vb and php.