Replying to
@epage Thanks for everything you did, Ed! Real impact delivered 💯
Remote
Ubiratan Soares
@ubiratansoares@hachyderm.io
mastodon 4.7.3Software Engineer. Continuous Learner.
0 Followers
0 Following
13 Posts
Joined January 16, 2023
Website:
RE: https://hachyderm.io/@ZacSweers/116101250172764107
I've been following this discussion popping over and over within the #androiddev community for more than 10 years. As a former member of this community, I also have something to say.
"[...] Then after a certain level of complexity I find myself annoyed with the wiring and adopt a DI framework."
Repeat after me : there is zero chance a DI framework may be simpler than manual wiring for any project, Android or not. By automating annoyance, one chooses compound more complexity (and build overhead) on top existing complexity (and existing build overhead). I'm all ears for a compelling counter argument framed on *simplicity* here, but I think I'll get none.
Since v1.0 Kotlin delivers already a good set of features that enable better ergonomics for manually wiring dep graphs (code) and production code. I once implemented something like
https://arturdryomov.dev/posts/a-dagger-to-remember/
in one large greenfield project, and I could see it by myself it works. The team was happy, the product scaled, the project too, and we could rev walk dep graphs of a module using IDE features. My gosh !
Kotlin enabled that almost a decade ago, but people refused to see, treating all boilerplate as equality bad. Nowadays, for large multi-year old Android code bases, the reality are several lines of custom annotations no one understands decorating a single constructor or function. I call this boilerplate too.
Over the years, I've compared the number of LoC before and after a clean build in all sort of Android projects I worked, just to learn that Dagger and friends was doubling, some times tripling the total LoC. And people never understood why a cold CI release build took one hour to complete during a hotfix deployment ..
I always argued that, with Kotlin features + manual wiring, having the same amount of LoC for dep graph code and prod code is pretty impossible. I invite someone to take a project like NIA and use some LLM to generate manually wired IoC, compare total number of LoC, and conclude by himself/herself. I don't have the time or interest to do that at this point.
ThePrimagen says on his videos : "code is liability". I agree with this statement. Android devs seems to forget that code under build/ folder is liable too, validated at compile time or not.
From the days I used to do #androiddev , .local folder was my default to store things I did not want to add at gitignore. Just made the most of defaults that project wizards set in place at some point.
Unsurprisingly, it turns outs there was a better/easier way
https://luisdalmolin.dev/blog/ignoring-files-in-git-without-gitignore/
RE: https://mastodon.social/@rustfoundation/116082286491862779
I'm humbled to share that I got oxidized 😄
Super happy for joining this amazing team 🦀
This is how we foster the community!!! Congrats @Rustnationuk@hachyderm.io it was a blast 👏👏👏
Replying to
Btw, all the ridiculous AI videos used in the presentation compound over the main message itself. #FOSDEM26
During my career, I went through this experience several times.
I started admiring someone professionally due to the impact of the work that person delivers.
Some time later, I no longer can follow that person. Although I try my best to judge art rather than the artist, one's statements become unbearable and I find myself disagreeing all the time with them, hence wasting my time. Today, that happened again.
Kill your heroes, they say. Unfortunately, AI speed up and amplifies that too.
RE: https://mas.to/@carnage4life/116140092273974349
Serious candidate for Tech meme of year 😂😂😂
RE: https://hachyderm.io/@tb/116611944803263309
Time to get rid of some regex managers out there 🎉🎉🎉
Replying to
@ZacSweers@hachyderm.io I disagree with everything you said.
Your counter example only works for naive setups and small projects. It elaborates around easiness rather than simplicity, and here I refer to Rich Hickey classic "Easy made Simple" talk on the subject.
Dagger does not enforce one way of doing DI, hence it is not simple. And regarding being easy, as soon one has a big multi module project with a non trivial brow DI setup in place, the reality shifts from "add one parameter to this constructor and done" to "let me troubleshoot Dagger output again", which defeats the original purpose every single time.
Btw, the annoying refactor you just described with manually wired code is now handled by LLMs at scale. Such systems are just amazing for this task. In addition, by refactoring glue code with LLMs one can finally think about who ows the glue in the first place, since one should own what one ships.
I brought the argument of LoC to frame how massive is the overhead of delegating code that is boring but not hard to write to a DI tool. It has nothing to do with build systems : only Platform Enginners have to engage with Gradle classpath pollution issues in large Android projects. Unfortunately, every single Engineer carries the weight of bloat generated by Dagger at compile time. That is the reality.
Glad that you mentioned productivity as a factor of iterations. Unfortunately the reality of most Android projects serving users in production US : we don't have the new fancy DI tool in the town in place. The reality is having a mixed setup of Dagger and something else, eventually a project like Anvil (which is now vaporware) making people frustrated with super slow build times, build caching that does not work as it should, and massive cognitive overhead for a problem that should be simple : create instances and pass them around.
I don't expect convince you to agree with me. But the arguments you provided did not convince me either.
Replying to
@kaush@hachyderm.io I assume that the next step is not reviewing AI agents generated code at all and just assume the behavior stands, correct?
I mean...with compilers, I don't need to review the output, unless I'm interested in ultra sensitive performance optimizations, which I did maybe a few times in my career, but most out of my own curiosity.
If one needs to review the output of a process, then one can't claim that AI agents are like compilers.
Replying to
@bascule@mas.to Maybe I missed something, but can RustSec (or some other project) infer whether a crate became abandonware, for instance by evaluating Github activity?