jvmboi

I am fully remote and have been for a long time but I don't trust productivity studies, especially if they just find what everyone wants to hear anyway.

If the market can do anything then it that has to be optimizing productivity. Every single company has a weighty incentive to work out what works best and so I fully expect that after a bit of churn the optimal remote/on-premise balance will be found on a job-by-job basis.

My sneaking suspicion is that the real reason that everything is so slow is that noticeable loading or processing times give the software a feeling of heft. It strokes our ego as programmers because if something takes a while to complete then it must be very complicated and important.

I prefer Gradle but I do agree with this assessment. Maven is really rock solid and dependable and once you have a POM that does what you want it will keep doing that for the next decade.

I think if you have a project in an enterprise setting where you want a dependable build on a codebase that has a lot of people with relatively low investment contributing then you either use Maven or you have to be very strict and disciplined with how you setup your Gradle build(s).

BUT. For myself I wouldn't trade Gradle for the world. I can setup my projects to develop in a live coding style even though I am working in a compiled language.

Right now I am hacking on a Kotlin Spring Boot project with JOOQ and HTMX and I have set it up so that I can use JOOQ code in buildSrc[1] to output SQL that is then used by JOOQ codegen[2] to generate Records, POJOS, DAOs and so on. I just run 'gradle build -t' and my and 'gradle run' in parallel and because of Spring Hotreload and using the LiveReload Chrome extension I can see my changes taking effect in almost real time. When I make a change that leads to a compile error then my build script will give the Star Trek computer error chirp. I don't think I can convey how happy and productive this setup makes me.

It would be extremely hard to do all of that in maven but it's so simple in gradle. And if you do it right, which is not hard if you follow the docs, then you automatically have dirty checking / lazy behavior. SQL is only generated when buildSrc changes. JOOQ artifacts are only generated when the SQL changes. Spring only reloads the application when code or resources change. Everything is quite fast too. For my project it's currently around 3 seconds from changing the code to seeing my changes reflected on the frontend. And everything from the DDL (schema definition) to DML (sql queries), backend and frontend is in my favorite language: Kotlin!

I hope that everyone's build tool makes them as happy as gradle does me.

[1] buildSrc let's you write custom Groovy/Kotlin/Java build tasks that you can then use in your project's build

[2] with the artifacts that JOOQ codegen generates it's possible to use SQL in a fully typesafe, database independent and refactorable way. Here is a good one page overview of how to set it up and what you can do with it: https://www.baeldung.com/kotlin/jooq

Gradle scripts are just programs so it's impossible to vouch for every single gradle script that exist. I mean you can just write

  if( Random.nextBoolean()) {
      project.delete(
          fileTree(project)
      )
  }

And delete your whole project on roughly every second build.

Yes, so maybe it's too easy to shoot yourself in the foot but the "non-deterministic" behavior isn't coming from anything gradle does inherently but from your build script.

In my experience most critique of gradle happens in a vacuum. Is it perfect? No. But on planet earth most people use gulp for builds and npm for dependencies that together have a superset of any issues that gradle has.

It's been a while since I used maven but if I recall correctly the reason for that is that javac (java compiler) actually doesn't do incremental compilation. It was such a problem that eclipse (the ide) had it's own java compiler that could do incremental compilation. This alternative compiler was so popular that you could even use it in Jetbrains IDE and I think you could configure maven to use it to get incremental compilation there to.

So easy to say, so hard to do.

With heroic effort I can maybe lock down my routers, my kids devices, all devices in my house and they can just go to a friends house and see or, maybe even purchase, every single thing that we[1] have deemed unsafe or inappropriate to children. I am not just talking about porn but drugs, every conceivable type of violence, every conceivable type of crime and criminal, every kind of advertisement, every kind of political propaganda. From the point of view of a parent, the internet is a pipe that potentially connects your child's innocence and naivety to every single bad influence and predator in the world.

Yes, I could keep my kids offline but then they'd pay the price of being complete outsiders.

I don't actually have a solution because I don't trust the government to regulate the internet but from a societal POV of a society that wants to keep existing it's probably best to make the easy path sane and safe per default. That's the way we tried to do it in the past, anyways.

[1] we, as in the majority of people in the majority of societies

Apple TV has a show called "WeCrashed" centered around this company. I enjoyed it immensely and wholeheartedly recommend it.

https://tv.apple.com/en/show/wecrashed

Is it really a new feature to have the most traveled path be comfortable? I wouldn't agree. I think whoever is in charge of Java should be conservative and careful but what I would just wish is for them to give the developer experience some priority.

Streams are fine and Java is clearly evolving in a good direction but what makes me tear out my hairs is that they needed 7 years to add a toList() method to streams. This is so typical for the way that the Java language evolved. Ergonomics always came last with Java and if it's not clunky and painful to use at first then the Java stewards don't want it. Maybe in another 7 years we will get filter() and map() directly on Collection.