5 ms·

FYI https://github.com/droundy/gotgo https://github.com/droundy/gotgo

by ithkuil 13y ago

pjmlp 13y ago
Like generic macros bundled in C++ compilers around 1993.
- ithkuil 13y ago
  You mean a trick to use cpp preprocessor to implement template expansion when C++ (or common compilers) didn't have templates? Did this technique just expand the classes every time they were used (in the header file, just like C++ templates) or generated files for each concrete type parameter which was then just compiled once (like gotgo) ?
  - pjmlp 13y ago
    Yes. Borland C++ for MS-DOS had such a framework. Basically you had to #define the desired set of type definitions before each #include, if I remember correctly. That is why I find tools like gotgo a form of time travel back to the time when generic programming wasn't mainstream.
- twotwotwo 13y ago
  Sure. I'm happy if it makes it easy to build the stuff I want, even if it's not fundamentally that new or interesting.
  - pjmlp 13y ago
    The point is that by keeping generics out of the language, Go designers have forced the developers to look out for solutions of their own. Which funny enough, happen to be similar to the ones in use before generics were widely available in the mainstream.
    - twotwotwo 13y ago
      Fair enough--I'm just saying I actually wouldn't mind if the actual eventual solution in Go were a bit gotgo-like (though I'd like it to be standard, not require an extra build step, etc.). Making adaptable containers without extending the type system might even be the Go-y way to do it, though it probably wouldn't win many converts from other languages. (Or, from the other end entirely, I could see polymorphic functions happening--they'd complicate the Go compilers more than macro-like generics would, but using them would feel familiar for Go's many refugees from duck-typed dynamic langs.) Anyhow, I'm fairly aimlessly spec'latin' here, don't listen too much to me.
twotwotwo 13y ago
Yeah--it looks like it does it about as well as a third-party tool can. But it's the sort of thing it seems like could hugely benefit from being in the core--then hopefully folks would be more inclined to write libs for B-trees or whatever on top of it. Mostly irrelevant, but to put a finer point on the wish for something to show up in the core: I totally sympathize with the Gophers' decision to ship 1.0 without generics (or polymorphic functions or whatever); there are workarounds for not having 'em, and there's plenty else to keep the core team busy, like writing an awesome stdlib. Other languages that now have generics also lacked them at first. But it sort of grates to hear it waved off as simply unimportant that you can't deploy a set or B-tree or whatever of a new type without either cut-and-pasting (by hand or w/a third-party tool) or taking the runtime hit of dynamic typing. That's a solvable, useful-to-solve, and repeatedly solved problem, and seems eventually worth solving in the Go core, even if it's not the highest priority. Most of Go's omissions/quirks I either actively like or just shrug at, but that's one on my wishlist. End rant. :)

FYI https://github.com/droundy/gotgo https://github.com/droundy/gotgo

by ithkuil 13y ago

FYI https://github.com/droundy/gotgo https://github.com/droundy/gotgo

pjmlp 13y ago

Like generic macros bundled in C++ compilers around 1993.

ithkuil 13y ago
You mean a trick to use cpp preprocessor to implement template expansion when C++ (or common compilers) didn't have templates? Did this technique just expand the classes every time they were used (in the header file, just like C++ templates) or generated files for each concrete type parameter which was then just compiled once (like gotgo) ?
- pjmlp 13y ago
  Yes. Borland C++ for MS-DOS had such a framework. Basically you had to #define the desired set of type definitions before each #include, if I remember correctly. That is why I find tools like gotgo a form of time travel back to the time when generic programming wasn't mainstream.
twotwotwo 13y ago
Sure. I'm happy if it makes it easy to build the stuff I want, even if it's not fundamentally that new or interesting.
- pjmlp 13y ago
  The point is that by keeping generics out of the language, Go designers have forced the developers to look out for solutions of their own. Which funny enough, happen to be similar to the ones in use before generics were widely available in the mainstream.
  - twotwotwo 13y ago
    Fair enough--I'm just saying I actually wouldn't mind if the actual eventual solution in Go were a bit gotgo-like (though I'd like it to be standard, not require an extra build step, etc.). Making adaptable containers without extending the type system might even be the Go-y way to do it, though it probably wouldn't win many converts from other languages. (Or, from the other end entirely, I could see polymorphic functions happening--they'd complicate the Go compilers more than macro-like generics would, but using them would feel familiar for Go's many refugees from duck-typed dynamic langs.) Anyhow, I'm fairly aimlessly spec'latin' here, don't listen too much to me.

twotwotwo 13y ago

Yeah--it looks like it does it about as well as a third-party tool can. But it's the sort of thing it seems like could hugely benefit from being in the core--then hopefully folks would be more inclined to write libs for B-trees or whatever on top of it. Mostly irrelevant, but to put a finer point on the wish for something to show up in the core: I totally sympathize with the Gophers' decision to ship 1.0 without generics (or polymorphic functions or whatever); there are workarounds for not having 'em, and there's plenty else to keep the core team busy, like writing an awesome stdlib. Other languages that now have generics also lacked them at first. But it sort of grates to hear it waved off as simply unimportant that you can't deploy a set or B-tree or whatever of a new type without either cut-and-pasting (by hand or w/a third-party tool) or taking the runtime hit of dynamic typing. That's a solvable, useful-to-solve, and repeatedly solved problem, and seems eventually worth solving in the Go core, even if it's not the highest priority. Most of Go's omissions/quirks I either actively like or just shrug at, but that's one on my wishlist. End rant. :)