3 ms·

Yup, love that about statically typed languages. This happens all the time for me in C#. I have several libraries I like that do a lot of code generation. When

Yup, love that about statically typed languages. This happens all the time for me in C#. I have several libraries I like that do a lot of code generation. When the project is young, directly handling the generated classes works well but as the project grows, I inevitably want to wrap the handling of the generated classes. It's awesome to be like, welp... it's time to handle this one type differently. Change the return type of an interface or the type of a container and just have the compiler tell you everything you broke.

underwater 9y ago
I’d argue that code generation is an anti—pattern that is only necessary because of static typing. A dynamic language would let you change the implementation of all generated objects simultaneously.
- dragonwriter 9y ago
  In principle, this should be possible with static typing with a robust enough type system, too.
- yorwba 9y ago
  Code generation by macros is an important feature of Lisps, which tend to be dynamically typed. Maybe it feels less like code generation when you don't also have to produce the correct type annotations, but a good inference engine can eliminate most of those from statically typed languages as well.
- subwayclub 9y ago
  Code generation is, in essence, the ultimate static construct since it allows you to compile any feature you would achieve through late binding and reflection, but with a static code path. Which in turn lets you leverage the compiler toolchain more and bring more errors towards compile time(where they're cheap to resolve). Dynamic languages can always lean on runtime features, but that's also their peril. Late binding deprives you of leveraging the tools in favor of "trust me". In both cases you can get a maintenance nightmare, of course. The point as I see it is to move things toward the runtime when the error case is not troublesome, and towards the compiler when automating in more safeguards would help.
- throwawayjava 9y ago
  A lot of generated code could be done with reflection or meta-object protocols. There's a good reason people generate code instead (in statically and dynamically typed languages!): performance.
- DubiousPusher 9y ago
  That may be entirely true and everything you can achieve with Roslyn and T4 templates may be achievable through some more elegant construct in another language. But I've never had the luxury of choosing a tech stack for it's purity of design. So the feature is wonderful in my day to day regardless. I'd love to build 3D experiences in a language like lisp or scheme. It'd be great fun to learn but I don't currently have the luxury of the time it would take to ramp. And I certainly don't have the political capital to convince my entire dev team to change.
- bjz_ 9y ago
  You can actually do a huge amount of metaprogramming in dependent type systems and still have the the power of static checking. We're still figuring out how to improve the ergonomics to the level that it matches macros and other code-gen methods, but it's super exciting stuff.

underwater 9y ago

I’d argue that code generation is an anti—pattern that is only necessary because of static typing. A dynamic language would let you change the implementation of all generated objects simultaneously.

dragonwriter 9y ago
In principle, this should be possible with static typing with a robust enough type system, too.
yorwba 9y ago
Code generation by macros is an important feature of Lisps, which tend to be dynamically typed. Maybe it feels less like code generation when you don't also have to produce the correct type annotations, but a good inference engine can eliminate most of those from statically typed languages as well.
subwayclub 9y ago
Code generation is, in essence, the ultimate static construct since it allows you to compile any feature you would achieve through late binding and reflection, but with a static code path. Which in turn lets you leverage the compiler toolchain more and bring more errors towards compile time(where they're cheap to resolve). Dynamic languages can always lean on runtime features, but that's also their peril. Late binding deprives you of leveraging the tools in favor of "trust me". In both cases you can get a maintenance nightmare, of course. The point as I see it is to move things toward the runtime when the error case is not troublesome, and towards the compiler when automating in more safeguards would help.
throwawayjava 9y ago
A lot of generated code could be done with reflection or meta-object protocols. There's a good reason people generate code instead (in statically and dynamically typed languages!): performance.
DubiousPusher 9y ago
That may be entirely true and everything you can achieve with Roslyn and T4 templates may be achievable through some more elegant construct in another language. But I've never had the luxury of choosing a tech stack for it's purity of design. So the feature is wonderful in my day to day regardless. I'd love to build 3D experiences in a language like lisp or scheme. It'd be great fun to learn but I don't currently have the luxury of the time it would take to ramp. And I certainly don't have the political capital to convince my entire dev team to change.
bjz_ 9y ago
You can actually do a huge amount of metaprogramming in dependent type systems and still have the the power of static checking. We're still figuring out how to improve the ergonomics to the level that it matches macros and other code-gen methods, but it's super exciting stuff.