Diminishing returns of static typing

Re:Diminishing returns of static typing by DubiousPusher on Monday October 02, 2017 @12:39PM (#15385335)

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.

[ Parent | on HN ]

Re:Diminishing returns of static typing by underwater on Monday October 02, 2017 @07:00PM (#15388708)

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.

[ Parent | on HN ]

Re:Diminishing returns of static typing by subwayclub on Monday October 02, 2017 @09:44PM (#15389451)

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.

[ Parent | on HN ]

Re:Diminishing returns of static typing by yorwba on Monday October 02, 2017 @07:35PM (#15388858)

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.

[ Parent | on HN ]

Re:Diminishing returns of static typing by bjz_ on Tuesday October 03, 2017 @06:20AM (#15391366)

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.

[ Parent | on HN ]

Re:Diminishing returns of static typing by DubiousPusher on Tuesday October 03, 2017 @12:48AM (#15390249)

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.

[ Parent | on HN ]

Re:Diminishing returns of static typing by dragonwriter on Monday October 02, 2017 @07:03PM (#15388718)

In principle, this should be possible with static typing with a robust enough type system, too.

[ Parent | on HN ]

Re:Diminishing returns of static typing by throwawayjava on Monday October 02, 2017 @10:13PM (#15389593)

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.

[ Parent | on HN ]