5 ms·

I used to be of the same mindset until I tried it. I still miss generics, but ...not as much. From a "non-starter" it became "I don't love it but I can learn to

I used to be of the same mindset until I tried it. I still miss generics, but ...not as much. From a "non-starter" it became "I don't love it but I can learn to live with it" to "let's look at creative solutions, perhaps using code generation, to try to solve this". I think generics will come, honestly, but not in an easily-recognizable form. The "go generate" is a small step into the direction this will take, IMO

copsarebastards 12y ago
> I still miss generics, but ...not as much. From a "non-starter" it became "I don't love it but I can learn to live with it" to "let's look at creative solutions, perhaps using code generation, to try to solve this". If you're trying to solve problems caused by your language, maybe the solution is to switch languages. > I think generics will come, honestly, but not in an easily-recognizable form. The "go generate" is a small step into the direction this will take, IMO Static code generation is what people tried before templates, which were then improved upon by generics, and that's only looking at mainstream languages--if you're willing to look outside that, there's Hindley-Milner type inference and typeclasses. The rest of the language design world went down this path decades ago and already made the mistakes Go is making and learned from them. `go generate` is a fucking terrible idea. People aren't saying this because they're afraid of change, they're saying it because they've seen it before. We know how the story ends and it's not a happy ending. The fact that Go's designers can't be bothered to read the book only goes to show that they shouldn't be designing a language, and Go's popularity is only due to a combination of ignorance and hype.
- danieldk 12y ago
  `go generate` is a fucking terrible idea. No. `go generate` is great for what it was invented for: Programs that write programs are therefore important elements in software engineering, but programs like Yacc that produce source code need to be integrated into the build process so their output can be compiled. When an external build tool like Make is being used, this is usually easy to do. But in Go, whose go tool gets all necessary build information from the Go source, there is a problem. There is simply no mechanism to run Yacc from the go tool alone. Source: https://blog.golang.org/generate https://blog.golang.org/generate It's not meant as a substitute for generics, it's for running tools such as yacc.
  - copsarebastards 12y ago
    I was responding to `go generate` as a subsitute for generics because that's what PopsiclePete was proposing. But while we're at it, `go generate` as a substitute for lexer/parser generators is another example of Go being decades behind programming language research. C# and clang have both innovated a lot in this space by writing sophisticated functional parsers by hand using libraries which in C#s case is then exposed in the language. You could go even farther and look into combinator parsers. Yet again Go ignores decades of programming language research.
    - ngrilly 12y ago
      > `go generate` as a substitute for lexer/parser generators is another example of Go being decades behind programming language research. Nobody wrote that `go generate` is a substitue for lexer/parser generators. `go generate` is just a mechanism to automate the execution of the generator, as explained by the comment you replied to. Repeating ad nauseum that Go is "decades behind programming language research" is not enough to make your point :-) > C# and clang have both innovated a lot in this space by writing sophisticated functional parsers by hand using libraries which in C#s case is then exposed in the language. Sounds interesting. Any link to share with us?
      - copsarebastards 12y ago
        It's exposed through Roslyn (I was technically wrong in that it's not included in the language, but in Visual Studio). It's not very well-documented (to give you some idea of how not well-documented it is, some of the most useful documentation is in a Word file[1]). The code is Open Source[2]. I found out about Roslyn through hearing Erik Meijer speak at a conference. A quick search shows that the content of his talk at the conference I went to is probably covered in his C9 lectures[3], probably in Chapter 8[4]. But I'm pretty sure that will only cover the parser combinators, which is the algorithm, but not the specifics, of how C# is parsed. When I was doing C# parsing I was working with the CodeDom[5]. If you just need the AST I think ExpressionTrees[6] are now the idiomatic way to generate it, but I'm not sure how that relates to Roslyn. Disclaimer: My day-to-day development switched over to primarily C/Python/JS about a year and a half ago, so it's been a while since I fired up Visual Studio. My knowledge is probably out of date, and might be flat wrong--nobody's memory is great after a year and a half. [1] http://msdn.microsoft.com/en-us/hh543916 http://msdn.microsoft.com/en-us/hh543916 [2] https://github.com/dotnet/roslyn https://github.com/dotnet/roslyn [3] https://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer-Functional-Programming-Fundamentals https://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer-Fun... [4] https://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer-Functional-Programming-Fundamentals/C9-Lectures-Dr-Erik-Meijer-Functional-Programming-Fundamentals-Chapter-8-of-13 https://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer-Fun... [5] https://msdn.microsoft.com/en-us/library/y2k85ax6.aspx https://msdn.microsoft.com/en-us/library/y2k85ax6.aspx [6] https://msdn.microsoft.com/en-us/library/bb397951.aspx https://msdn.microsoft.com/en-us/library/bb397951.aspx
danieldk 12y ago
The "go generate" is a small step into the direction this will take, IMO It's not. The problem is the number of possible types you want to instantiate a generic type or function over is potentially infinite. If I write say a binary search tree package, I can only use 'go generate' to generate instantiations for a finite number of types. If a user of my package need a binary search tree of another type, touch luck. The best they can do is use interface{} or start 'go generating' in their own projects. 'go generate' is great for generating code using yacc or Ragel, but it's not a solution to the lack of generics.
- PopsiclePete 12y ago
  Like I said, it's a "small step". It's in the quote you quoted in fact. A small step, that's all. There's go generate now, maybe somebody will write "go super-duper-generate" later. All I'm saying is, if "generics" come to Go, it will be through a tool like "go super-duper-generate-v2.0-apples", not syntax. That's all.
  - Jweb_Guru 12y ago
    I mean, we did this. It was called CFront. Now we have C++ templates that are probably Turing-complete and we use them to create things like Boost. Regardless of howyou feel about compile-time metaprogramming like Boost, Go exists as a direct reaction to its complexity, and that's exactly where go generate will take it.

copsarebastards 12y ago

> I still miss generics, but ...not as much. From a "non-starter" it became "I don't love it but I can learn to live with it" to "let's look at creative solutions, perhaps using code generation, to try to solve this". If you're trying to solve problems caused by your language, maybe the solution is to switch languages. > I think generics will come, honestly, but not in an easily-recognizable form. The "go generate" is a small step into the direction this will take, IMO Static code generation is what people tried before templates, which were then improved upon by generics, and that's only looking at mainstream languages--if you're willing to look outside that, there's Hindley-Milner type inference and typeclasses. The rest of the language design world went down this path decades ago and already made the mistakes Go is making and learned from them. `go generate` is a fucking terrible idea. People aren't saying this because they're afraid of change, they're saying it because they've seen it before. We know how the story ends and it's not a happy ending. The fact that Go's designers can't be bothered to read the book only goes to show that they shouldn't be designing a language, and Go's popularity is only due to a combination of ignorance and hype.

danieldk 12y ago
`go generate` is a fucking terrible idea. No. `go generate` is great for what it was invented for: Programs that write programs are therefore important elements in software engineering, but programs like Yacc that produce source code need to be integrated into the build process so their output can be compiled. When an external build tool like Make is being used, this is usually easy to do. But in Go, whose go tool gets all necessary build information from the Go source, there is a problem. There is simply no mechanism to run Yacc from the go tool alone. Source: https://blog.golang.org/generate https://blog.golang.org/generate It's not meant as a substitute for generics, it's for running tools such as yacc.
- copsarebastards 12y ago
  I was responding to `go generate` as a subsitute for generics because that's what PopsiclePete was proposing. But while we're at it, `go generate` as a substitute for lexer/parser generators is another example of Go being decades behind programming language research. C# and clang have both innovated a lot in this space by writing sophisticated functional parsers by hand using libraries which in C#s case is then exposed in the language. You could go even farther and look into combinator parsers. Yet again Go ignores decades of programming language research.
  - ngrilly 12y ago
    > `go generate` as a substitute for lexer/parser generators is another example of Go being decades behind programming language research. Nobody wrote that `go generate` is a substitue for lexer/parser generators. `go generate` is just a mechanism to automate the execution of the generator, as explained by the comment you replied to. Repeating ad nauseum that Go is "decades behind programming language research" is not enough to make your point :-) > C# and clang have both innovated a lot in this space by writing sophisticated functional parsers by hand using libraries which in C#s case is then exposed in the language. Sounds interesting. Any link to share with us?
    - copsarebastards 12y ago
      It's exposed through Roslyn (I was technically wrong in that it's not included in the language, but in Visual Studio). It's not very well-documented (to give you some idea of how not well-documented it is, some of the most useful documentation is in a Word file[1]). The code is Open Source[2]. I found out about Roslyn through hearing Erik Meijer speak at a conference. A quick search shows that the content of his talk at the conference I went to is probably covered in his C9 lectures[3], probably in Chapter 8[4]. But I'm pretty sure that will only cover the parser combinators, which is the algorithm, but not the specifics, of how C# is parsed. When I was doing C# parsing I was working with the CodeDom[5]. If you just need the AST I think ExpressionTrees[6] are now the idiomatic way to generate it, but I'm not sure how that relates to Roslyn. Disclaimer: My day-to-day development switched over to primarily C/Python/JS about a year and a half ago, so it's been a while since I fired up Visual Studio. My knowledge is probably out of date, and might be flat wrong--nobody's memory is great after a year and a half. [1] http://msdn.microsoft.com/en-us/hh543916 http://msdn.microsoft.com/en-us/hh543916 [2] https://github.com/dotnet/roslyn https://github.com/dotnet/roslyn [3] https://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer-Functional-Programming-Fundamentals https://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer-Fun... [4] https://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer-Functional-Programming-Fundamentals/C9-Lectures-Dr-Erik-Meijer-Functional-Programming-Fundamentals-Chapter-8-of-13 https://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer-Fun... [5] https://msdn.microsoft.com/en-us/library/y2k85ax6.aspx https://msdn.microsoft.com/en-us/library/y2k85ax6.aspx [6] https://msdn.microsoft.com/en-us/library/bb397951.aspx https://msdn.microsoft.com/en-us/library/bb397951.aspx

danieldk 12y ago

The "go generate" is a small step into the direction this will take, IMO It's not. The problem is the number of possible types you want to instantiate a generic type or function over is potentially infinite. If I write say a binary search tree package, I can only use 'go generate' to generate instantiations for a finite number of types. If a user of my package need a binary search tree of another type, touch luck. The best they can do is use interface{} or start 'go generating' in their own projects. 'go generate' is great for generating code using yacc or Ragel, but it's not a solution to the lack of generics.

PopsiclePete 12y ago
Like I said, it's a "small step". It's in the quote you quoted in fact. A small step, that's all. There's go generate now, maybe somebody will write "go super-duper-generate" later. All I'm saying is, if "generics" come to Go, it will be through a tool like "go super-duper-generate-v2.0-apples", not syntax. That's all.
- Jweb_Guru 12y ago
  I mean, we did this. It was called CFront. Now we have C++ templates that are probably Turing-complete and we use them to create things like Boost. Regardless of howyou feel about compile-time metaprogramming like Boost, Go exists as a direct reaction to its complexity, and that's exactly where go generate will take it.