3 ms·

Then someone in your team failed learning the bare minimum to write a sane gradle file, and are putting imperative stuff into the configuration phase. For big

by kaba0 3y ago

Then someone in your team failed learning the bare minimum to write a sane gradle file, and are putting imperative stuff into the configuration phase. For big projects, compiling only what’s necessary is a huge time win.

troupo 3y ago
> Then someone in your team failed learning the bare minimum to write a sane gradle file Then someone in over 15 years and 8 versions gradle failed to make a system that doesn't require "learning to write sane gradle files" to make sure that it's only two orders of magnitude and not five orders of magnitude slower than it can be. > and are putting imperative stuff into the configuration phase Has nothing to do with the slowness that is gradle. > For big projects, compiling only what’s necessary is a huge time win. It is, and no one is arguing with that
- kaba0 3y ago
  It is your own failure if you beat the tool over yourself, for not having learnt it.
  - troupo 3y ago
    A tool that: - in 15 years is still slow by default - in 15 years could not acquire any sensible defaults that shouldn't need extra work to configure - is written in an esoteric language with next to zero tools to debug and introspect - randomly changes and moves thing around every couple of years for no discernible reason and making zero impact on reducing its slowness - has no configuration specification to speak of because the config is written in that same esoteric programming language And its zealots blame its failures on its users
    - kaba0 3y ago
      Build systems are a complex problem. Like, you can compare it to cargo/go’s build system etc, but these forget about 90% of the problem, and come up with a hard-coded for the happy-path rust/go project, with zero non-native dependency, all downloaded from the repository. This is not a bad thing, don’t get me wrong. But it is not enough to compile, say, a browser. Meanwhile, there are only a couple, truly general build systems, all of them quite complex — as you can’t get away with less. Gradle and bazel are pretty much the only truly generic build systems (I’m sure there are a couple more, but not many). You can actually compile a mixed java, c++, whatever project with gradle, for example, just fine, with proper parallelism, caching, etc. As for your points: > in 15 years is still slow by default Absolutely false. A 3-4 lines gradle build file for java will be fast, and correctly parallelize and maximally utilize previously built artifacts. > in 15 years could not acquire any sensible defaults that shouldn't need extra work to configure It’s literally 4 lines for a minimal project, maybe even less. I’m getting the feeling that you have zero idea about what you talk about. > is written in an esoteric language with next to zero tools to debug and introspect I somewhat agree, though nowadays kotlin is also an alternative with strong typing, proper auto-complete, the only trade off is a tiny bit slower first compile of the config file. Also, both could/can be debugged by a normal java debugger. > randomly changes and moves thing around every couple of years for no discernible reason There is some truth to this. But the speed has definitely improved. > has no configuration specification Kotlin is statically typed. Also, the API has okayish documentation, people just like to copy-paste everything and wonder why it fails. You wouldn’t be able to fly a plane either from watching 3 sitcoms showing a cockpit, would you?
      - troupo 3y ago
        > Absolutely false. A 3-4 lines gradle build file for java will be fast, and correctly parallelize and maximally utilize previously built artifacts. I've never seen this on any project that utilizes gradle. Every time, without fail, it's a multi-second startup of gradle that eventually invokes something that is actually fast: javac. > I’m getting the feeling that you have zero idea about what you talk about. Only 7 years dealing with java projects, both simple and complex >> has no configuration specification > Kotlin is statically typed. Kotlin being statically typed has literally nothing to do with a specification. Becuase Gradle doesn't have a configuration. It has a Groovy/Kotlin module that grew organically, haphazardly and without any long term plans. So writing gradle configuration is akin to reverse-engineering what the authors intended to do with a particular piece of code or API. > Also, the API has okayish documentation "okayish" is a synonim for bad. You'd think that a 15-year project in its 8th major version would have excellent API documentation > people just like to copy-paste everything and wonder why it fails. You wouldn’t be able to fly a plane either from watching 3 sitcoms So, a project with no specification to speak of, with "okayish" API that is slow as molasses by default out of the gate [1] keeps blaming its users for its own failure because somehow it's a plane, and not a glorified overengineered Makefile. [1] A reminder, if you will, that gradle managed to come up with caching configs to speed up its startup time only in version 8, after 15 years of development.
        krzyk 3y ago
        They are trying to make gradle better, by implementing a "maven over it" - declarative build configuration. But for time being maven is way easier to configure and understand.
        kaba0 3y ago
        It has always been “an imperative code that outputs the declarative configuration that can be used for the build”. Which is a very reasonable thing to do, but unfortunately most people fail to understand that a println in the config file’s global scope is different than inside a closure for a task description.
  - geodel 3y ago
    It could be if tool is work of good design and engineering. But not when tool's claim to fame is that it does not use XML to describe build config like Maven/Ant.
    - kaba0 3y ago
      There are not many alternatives that are truly general build tools (not limited to single language/repository, etc), and properly parallelize and cache. So, besides gradle and bazel, what else is there?

by kaba0 3y ago

troupo 3y ago

> Then someone in your team failed learning the bare minimum to write a sane gradle file Then someone in over 15 years and 8 versions gradle failed to make a system that doesn't require "learning to write sane gradle files" to make sure that it's only two orders of magnitude and not five orders of magnitude slower than it can be. > and are putting imperative stuff into the configuration phase Has nothing to do with the slowness that is gradle. > For big projects, compiling only what’s necessary is a huge time win. It is, and no one is arguing with that

kaba0 3y ago
It is your own failure if you beat the tool over yourself, for not having learnt it.
- troupo 3y ago
  A tool that: - in 15 years is still slow by default - in 15 years could not acquire any sensible defaults that shouldn't need extra work to configure - is written in an esoteric language with next to zero tools to debug and introspect - randomly changes and moves thing around every couple of years for no discernible reason and making zero impact on reducing its slowness - has no configuration specification to speak of because the config is written in that same esoteric programming language And its zealots blame its failures on its users
  - kaba0 3y ago
    Build systems are a complex problem. Like, you can compare it to cargo/go’s build system etc, but these forget about 90% of the problem, and come up with a hard-coded for the happy-path rust/go project, with zero non-native dependency, all downloaded from the repository. This is not a bad thing, don’t get me wrong. But it is not enough to compile, say, a browser. Meanwhile, there are only a couple, truly general build systems, all of them quite complex — as you can’t get away with less. Gradle and bazel are pretty much the only truly generic build systems (I’m sure there are a couple more, but not many). You can actually compile a mixed java, c++, whatever project with gradle, for example, just fine, with proper parallelism, caching, etc. As for your points: > in 15 years is still slow by default Absolutely false. A 3-4 lines gradle build file for java will be fast, and correctly parallelize and maximally utilize previously built artifacts. > in 15 years could not acquire any sensible defaults that shouldn't need extra work to configure It’s literally 4 lines for a minimal project, maybe even less. I’m getting the feeling that you have zero idea about what you talk about. > is written in an esoteric language with next to zero tools to debug and introspect I somewhat agree, though nowadays kotlin is also an alternative with strong typing, proper auto-complete, the only trade off is a tiny bit slower first compile of the config file. Also, both could/can be debugged by a normal java debugger. > randomly changes and moves thing around every couple of years for no discernible reason There is some truth to this. But the speed has definitely improved. > has no configuration specification Kotlin is statically typed. Also, the API has okayish documentation, people just like to copy-paste everything and wonder why it fails. You wouldn’t be able to fly a plane either from watching 3 sitcoms showing a cockpit, would you?
    - troupo 3y ago
      > Absolutely false. A 3-4 lines gradle build file for java will be fast, and correctly parallelize and maximally utilize previously built artifacts. I've never seen this on any project that utilizes gradle. Every time, without fail, it's a multi-second startup of gradle that eventually invokes something that is actually fast: javac. > I’m getting the feeling that you have zero idea about what you talk about. Only 7 years dealing with java projects, both simple and complex >> has no configuration specification > Kotlin is statically typed. Kotlin being statically typed has literally nothing to do with a specification. Becuase Gradle doesn't have a configuration. It has a Groovy/Kotlin module that grew organically, haphazardly and without any long term plans. So writing gradle configuration is akin to reverse-engineering what the authors intended to do with a particular piece of code or API. > Also, the API has okayish documentation "okayish" is a synonim for bad. You'd think that a 15-year project in its 8th major version would have excellent API documentation > people just like to copy-paste everything and wonder why it fails. You wouldn’t be able to fly a plane either from watching 3 sitcoms So, a project with no specification to speak of, with "okayish" API that is slow as molasses by default out of the gate [1] keeps blaming its users for its own failure because somehow it's a plane, and not a glorified overengineered Makefile. [1] A reminder, if you will, that gradle managed to come up with caching configs to speed up its startup time only in version 8, after 15 years of development.
      - krzyk 3y ago
        They are trying to make gradle better, by implementing a "maven over it" - declarative build configuration. But for time being maven is way easier to configure and understand.
        kaba0 3y ago
        It has always been “an imperative code that outputs the declarative configuration that can be used for the build”. Which is a very reasonable thing to do, but unfortunately most people fail to understand that a println in the config file’s global scope is different than inside a closure for a task description.
- geodel 3y ago
  It could be if tool is work of good design and engineering. But not when tool's claim to fame is that it does not use XML to describe build config like Maven/Ant.
  - kaba0 3y ago
    There are not many alternatives that are truly general build tools (not limited to single language/repository, etc), and properly parallelize and cache. So, besides gradle and bazel, what else is there?