4 ms·

Why do I have to learn a second programming language just to configure my build? /s Builds need Turing completeness surprisingly often. Build languages then ex

by jacobn 6y ago

Why do I have to learn a second programming language just to configure my build? /s Builds need Turing completeness surprisingly often. Build languages then expand to accommodate, with spaghetti disasters as the result. “But it has to be accessible to new users and can’t be tied to just one language” said SBT as it jumped the shark with its .sbt files. Sigh. Developers get crap tools because developers won’t pay for tooling - if it’s not open source and free we don’t touch it outside of an enterprise environment. And Lo and behold, most tooling is either cobbled together by Enthusiasts, or as user friendly as enterprise ware usually is. (There are, of course, shining exceptions to this, which is great)

ashtonkem 6y ago
What’s frustrating is seeing new communities and languages make unforced errors that a review of prior mistakes should easy uncover. The lack of a unified, coherent build tool in Java was a huge mistake. New languages would be well advised to focus on good tooling right out of the gate, rather than putting it off until later.
- ooobit2 6y ago
  At the very least, limit the scope of the language until a standardized toolset is cross-functional. I'm not not throwing shade at UWP right now.
- EdwardDiego 6y ago
  Maven has never really been displaced - Gradle only has traction in Android dev, for some reason it became the blessed-by-Google solution. Even when I'm writing Scala I prefer Maven to SBT, I just prefer declarative build tools to DSLs up in my grill.
  - ashtonkem 6y ago
    In my limited experience, Gradle is increasingly popular for Spring Boot applications.
pas 6y ago
The problem of tooling is that that's the place where ugly hacks most often go. Where the beautiful elegant abstractions meet the reality, where third party dependency cruft seeps in, where cross-version compilation gets orchestrated, where all the dev/test/prod compile time configuration, optimization, obfuscation, etc. happens. And sbt is just bad all around on top of all this, and it should feel bad.
- deleted 6y ago
  [deleted]
toyg 6y ago
> if it’s not open source and free we don’t touch it outside of an enterprise environment. To be fair, this is due also to the fact that opensource tools are mostly guaranteed to outlive their developers. Should Microsoft go bankrupt tomorrow (don't laugh, it basically happened to SUN), most of their traditional tooling would disappear. In contrast, Gcc might be old and crusty, but it will go on forever like a cockroach.
twelve40 6y ago
> crap tools because developers won’t pay for tooling I'm not sure i understand this argument crap Linux because developers won’t pay for Linux crap git because developers won’t pay for git ...that's clearly not the case, no? Every day we use a bunch of developer tools that are not just crap, but amazing and great to work with, and were built as open source. So I'm not sure about equating open source with crap experience.

by jacobn 6y ago

ashtonkem 6y ago

What’s frustrating is seeing new communities and languages make unforced errors that a review of prior mistakes should easy uncover. The lack of a unified, coherent build tool in Java was a huge mistake. New languages would be well advised to focus on good tooling right out of the gate, rather than putting it off until later.

ooobit2 6y ago
At the very least, limit the scope of the language until a standardized toolset is cross-functional. I'm not not throwing shade at UWP right now.
EdwardDiego 6y ago
Maven has never really been displaced - Gradle only has traction in Android dev, for some reason it became the blessed-by-Google solution. Even when I'm writing Scala I prefer Maven to SBT, I just prefer declarative build tools to DSLs up in my grill.
- ashtonkem 6y ago
  In my limited experience, Gradle is increasingly popular for Spring Boot applications.

pas 6y ago

The problem of tooling is that that's the place where ugly hacks most often go. Where the beautiful elegant abstractions meet the reality, where third party dependency cruft seeps in, where cross-version compilation gets orchestrated, where all the dev/test/prod compile time configuration, optimization, obfuscation, etc. happens. And sbt is just bad all around on top of all this, and it should feel bad.

deleted 6y ago
[deleted]

toyg 6y ago

> if it’s not open source and free we don’t touch it outside of an enterprise environment. To be fair, this is due also to the fact that opensource tools are mostly guaranteed to outlive their developers. Should Microsoft go bankrupt tomorrow (don't laugh, it basically happened to SUN), most of their traditional tooling would disappear. In contrast, Gcc might be old and crusty, but it will go on forever like a cockroach.

twelve40 6y ago

> crap tools because developers won’t pay for tooling I'm not sure i understand this argument crap Linux because developers won’t pay for Linux crap git because developers won’t pay for git ...that's clearly not the case, no? Every day we use a bunch of developer tools that are not just crap, but amazing and great to work with, and were built as open source. So I'm not sure about equating open source with crap experience.