6 ms·

Compile-Time DI vs. Run-Time DI

47 points by dimes 7y ago

mcnichol 7y ago
Your point of breaking things as early in the process really is the winner. Catching things early and often. Tooling that shifts things further left in the pipeline is my go-to default.
- chris_wot 7y ago
  Do you think it is rust that popularized this?
  - maxxxxx 7y ago
    Why Rust? Strongly typed languages had this capability for a long time.
    - oldgun 7y ago
      I believe what he means is that Rust takes this a step further by ensuring memory safety at compile time.
      - jerf 7y ago
        Rust is merely the latest in a long line of efforts in that direction. It may have located a particularly nice point in the cost/benefits space, and the borrow semantics I believe are novel, but it's well inline with many efforts to make compile time errors out of as many things as possible, from a lot of C++ stuff, Ada, Eiffel, Haskell, a variety of proof methods, the list goes on, and even the things I list are themselves exemplars of entire streams of thought on the idea rather than a complete list, of course. (This is not a criticism of Rust. It is not a criticism of a work to place it correctly in its historical context. Very few things consist entirely of novel ideas, and very few of those are any good, if any.)
        maxxxxx 7y ago
        Agreed. Rust is another step in the right direction but I don't think it invented a new paradigm.
  - chriswarbo 7y ago
    It's been standard programming dogma for decades, e.g. https://developers.slashdot.org/story/03/10/21/0141215/software-defects---do-late-bugs-really-cost-more https://developers.slashdot.org/story/03/10/21/0141215/softw...
kangnkodos 7y ago
DI is Dependency Injection.
stabbles 7y ago
What this blog post does not address is the joy of configuring DI with XML files /s Isn't it bizarre how software developers have taken runtime DI to such extremes that it was considered a good idea to configure services in XML or YAML -- basically another language, that has to be parsed, can be malformed, etc?
- duality 7y ago
  The creators of Guice mention how configuring the dependency graph in Java was a big advantage it offers over older XML-based frameworks like Spring.
  - douglasisshiny 7y ago
    Spring has allowed for java configuration for some time.
  - vips7L 7y ago
    I've never configured Spring DI via XML and I've been a Spring dev for at least 2 years. It's always been via Java annotations and config classes.
- lmm 7y ago
  Early Java took a stupid decision to deliberately restrict expressiveness in the name of being "blue collar" (ironically enough Go largely retreads the same mistake). The result was a language so cumbersome that people would do anything to avoid having to write actual Java. Stupid policies at large companies that subject "configuration" changes to much less scrutiny than "code" changes compounded the problem. The decision to use XML was actually quite reasonable for many developers given the constraints at the time. Thankfully Java has mostly seen the light these days, adding generics, first-class functions, and good-enough multiple inheritance (though it still has very restricted and cumbersome metaprogramming - classes are not first-class, and the lack of HKT makes it very difficult to work with functions generically since you can't abstract over arity), and people are gradually realizing that this different environment warrants different choices. (Companies still have terrible policies about code versus "config" though).
Emily2636 7y ago
World's biggest cake See the video how they made and how it looks https://howto105.blogspot.com/2019/04/worlds-biggest-ice-cream-cake.html https://howto105.blogspot.com/2019/04/worlds-biggest-ice-cre... Very funny video of 2019 Just watch and try to control your laugh http://bit.ly/2IVEv1j http://bit.ly/2IVEv1j Cute dog walking like humans http://bit.ly/2VpFTQB http://bit.ly/2VpFTQB See the video of Cute dog skateboarding even humans can't do this easily http://bit.ly/2IXS2Wj http://bit.ly/2IXS2Wj World's most highest truck jump Even you can't believe this That's not a movie scene it's real http://bit.ly/2VuUme7 http://bit.ly/2VuUme7 See the video of Cute dog walking at rope Even humans can't do this http://bit.ly/2VupwSQ http://bit.ly/2VupwSQ
kazagistar 7y ago
Java has a fairly nice compile time DI framework in Dagger. However, it feels like it is missing a compile time version of the rest of the web stack: compile time routing and compile time template compilation, for example. Does anyone have any suggestions to fill out this stack?
- snuxoll 7y ago
  It’s not perfect by any means, but there is Ktor as an example. Use kotlinx.html for your templates and everything is defined at compile time.
benbjohnson 7y ago
I don't understand why you need a framework for dependency injection in Go. I've written Go for years and I just use the `main` package to instantiate and wire up everything. It's really straightforward, easy to debug, and there's nothing to generate. It's all type checked at compile time. I'm not trying to rain on the author's parade. I genuinely don't understand the benefit—especially in relation to the complexity of adding an extra dependency and layer to my application.
- strulovich 7y ago
  How many active contributors and lines of code does your projects have? I’ve found that the advantages for DI frameworks (besides encouraging more unit tests and enabling them) to be more valuable for bigger and messier projects.
  - sagichmal 7y ago
    I find precisely the opposite, that as a project gains (and loses, and gains again) maintainers, the indirection and mental overhead that DI frameworks necessarily bring to the table vastly outweigh whatever perceived benefit there was in introducing them. Conversely, a declarative, step-wise func main, with components manually constructed and passed to each other as dependencies where necessary, is sometimes tedious, but never confusing, and always refreshingly easy to maintain, no matter how much time you've spent with the project.
    - tempguy9999 7y ago
      I've literally no idea what the second paragraph means but I suspect it's quite important. Could you point to an example of this being done? Thanks.
      - twic 7y ago
        This sounds like the main methods i write (in Java, also not using a DI framework). Like this: var database = new DatabaseFacade(config.get("db.host"), config.get("db.port", Integer::parseInt)); var users = new UserRepository(database); var catalogue = new ProductRepository(database); var cart = new ShoppingCartController(users, catalogue); It's imperative code, of course, but it's sort of declarative in that all the code is doing is wiring things up. It's step-wise in that it does one simple thing after another; it might be quite long, as there are a lot of components to create, but it can be understood locally. Components are manually constructed, by calling constructors, rather than via reflection done by the framework. Components are passed to each other as parameters to establish dependencies, rather than there being some sort of rule-driven lookup, as a framework would do. It is indeed pretty tedious to read, as it's just lots of constructor calls, with no thrilling action. But it's so simple it's never confusing (and you get to use the full power of the IDE to navigate it, jumping to definitions and uses etc). And, as such, easy to maintain. Definitely refreshingly so if you've come from Spring or Guice.

47 points by dimes 7y ago

Your point of breaking things as early in the process really is the winner. Catching things early and often. Tooling that shifts things further left in the pipeline is my go-to default.

chris_wot 7y ago
Do you think it is rust that popularized this?
- maxxxxx 7y ago
  Why Rust? Strongly typed languages had this capability for a long time.
  - oldgun 7y ago
    I believe what he means is that Rust takes this a step further by ensuring memory safety at compile time.
    - jerf 7y ago
      Rust is merely the latest in a long line of efforts in that direction. It may have located a particularly nice point in the cost/benefits space, and the borrow semantics I believe are novel, but it's well inline with many efforts to make compile time errors out of as many things as possible, from a lot of C++ stuff, Ada, Eiffel, Haskell, a variety of proof methods, the list goes on, and even the things I list are themselves exemplars of entire streams of thought on the idea rather than a complete list, of course. (This is not a criticism of Rust. It is not a criticism of a work to place it correctly in its historical context. Very few things consist entirely of novel ideas, and very few of those are any good, if any.)
      - maxxxxx 7y ago
        Agreed. Rust is another step in the right direction but I don't think it invented a new paradigm.
- chriswarbo 7y ago
  It's been standard programming dogma for decades, e.g. https://developers.slashdot.org/story/03/10/21/0141215/software-defects---do-late-bugs-really-cost-more https://developers.slashdot.org/story/03/10/21/0141215/softw...

kangnkodos 7y ago

DI is Dependency Injection.

stabbles 7y ago

What this blog post does not address is the joy of configuring DI with XML files /s Isn't it bizarre how software developers have taken runtime DI to such extremes that it was considered a good idea to configure services in XML or YAML -- basically another language, that has to be parsed, can be malformed, etc?

duality 7y ago
The creators of Guice mention how configuring the dependency graph in Java was a big advantage it offers over older XML-based frameworks like Spring.
- douglasisshiny 7y ago
  Spring has allowed for java configuration for some time.
- vips7L 7y ago
  I've never configured Spring DI via XML and I've been a Spring dev for at least 2 years. It's always been via Java annotations and config classes.
lmm 7y ago
Early Java took a stupid decision to deliberately restrict expressiveness in the name of being "blue collar" (ironically enough Go largely retreads the same mistake). The result was a language so cumbersome that people would do anything to avoid having to write actual Java. Stupid policies at large companies that subject "configuration" changes to much less scrutiny than "code" changes compounded the problem. The decision to use XML was actually quite reasonable for many developers given the constraints at the time. Thankfully Java has mostly seen the light these days, adding generics, first-class functions, and good-enough multiple inheritance (though it still has very restricted and cumbersome metaprogramming - classes are not first-class, and the lack of HKT makes it very difficult to work with functions generically since you can't abstract over arity), and people are gradually realizing that this different environment warrants different choices. (Companies still have terrible policies about code versus "config" though).

Emily2636 7y ago

World's biggest cake See the video how they made and how it looks https://howto105.blogspot.com/2019/04/worlds-biggest-ice-cream-cake.html https://howto105.blogspot.com/2019/04/worlds-biggest-ice-cre... Very funny video of 2019 Just watch and try to control your laugh http://bit.ly/2IVEv1j http://bit.ly/2IVEv1j Cute dog walking like humans http://bit.ly/2VpFTQB http://bit.ly/2VpFTQB See the video of Cute dog skateboarding even humans can't do this easily http://bit.ly/2IXS2Wj http://bit.ly/2IXS2Wj World's most highest truck jump Even you can't believe this That's not a movie scene it's real http://bit.ly/2VuUme7 http://bit.ly/2VuUme7 See the video of Cute dog walking at rope Even humans can't do this http://bit.ly/2VupwSQ http://bit.ly/2VupwSQ

kazagistar 7y ago

Java has a fairly nice compile time DI framework in Dagger. However, it feels like it is missing a compile time version of the rest of the web stack: compile time routing and compile time template compilation, for example. Does anyone have any suggestions to fill out this stack?

snuxoll 7y ago
It’s not perfect by any means, but there is Ktor as an example. Use kotlinx.html for your templates and everything is defined at compile time.

benbjohnson 7y ago

I don't understand why you need a framework for dependency injection in Go. I've written Go for years and I just use the `main` package to instantiate and wire up everything. It's really straightforward, easy to debug, and there's nothing to generate. It's all type checked at compile time. I'm not trying to rain on the author's parade. I genuinely don't understand the benefit—especially in relation to the complexity of adding an extra dependency and layer to my application.

strulovich 7y ago
How many active contributors and lines of code does your projects have? I’ve found that the advantages for DI frameworks (besides encouraging more unit tests and enabling them) to be more valuable for bigger and messier projects.
- sagichmal 7y ago
  I find precisely the opposite, that as a project gains (and loses, and gains again) maintainers, the indirection and mental overhead that DI frameworks necessarily bring to the table vastly outweigh whatever perceived benefit there was in introducing them. Conversely, a declarative, step-wise func main, with components manually constructed and passed to each other as dependencies where necessary, is sometimes tedious, but never confusing, and always refreshingly easy to maintain, no matter how much time you've spent with the project.
  - tempguy9999 7y ago
    I've literally no idea what the second paragraph means but I suspect it's quite important. Could you point to an example of this being done? Thanks.
    - twic 7y ago
      This sounds like the main methods i write (in Java, also not using a DI framework). Like this: var database = new DatabaseFacade(config.get("db.host"), config.get("db.port", Integer::parseInt)); var users = new UserRepository(database); var catalogue = new ProductRepository(database); var cart = new ShoppingCartController(users, catalogue); It's imperative code, of course, but it's sort of declarative in that all the code is doing is wiring things up. It's step-wise in that it does one simple thing after another; it might be quite long, as there are a lot of components to create, but it can be understood locally. Components are manually constructed, by calling constructors, rather than via reflection done by the framework. Components are passed to each other as parameters to establish dependencies, rather than there being some sort of rule-driven lookup, as a framework would do. It is indeed pretty tedious to read, as it's just lots of constructor calls, with no thrilling action. But it's so simple it's never confusing (and you get to use the full power of the IDE to navigate it, jumping to definitions and uses etc). And, as such, easy to maintain. Definitely refreshingly so if you've come from Spring or Guice.