4 ms·

>I don't know why this happens. I think programmers are so used to imperative (ant/Grunt/etc/etc) programming/building that it becomes confusing for them when t

>I don't know why this happens. I think programmers are so used to imperative (ant/Grunt/etc/etc) programming/building that it becomes confusing for them when they encounter a declarative system. Because, after all is said and done, programming is about having your computer "do" something - whether it be to write some bytes to the disk or to send some bytes to the network. It's just that sometimes there's an advantage to use an abstraction - such as say "SELECT * FROM TABLE WHERE ROW_ID =14" is an abstraction over something like "for (int i =0;i<table.size();i++) if(table.row[i].elem[1] == 14) ... ", but often you don't need such a complicated abstraction, you just "need something done" before (or after) building. Whether it be that you want to download an HTML file to package, or to move the resulting file to a certain directory, or to clean a certain directory, your build language shouldn't be that arcane that you have to create a "build.sh" to get things done.

wellpast 9y ago
— “SELECT...” is not an abstraction for “for...”, by the way. Abstractions are not for specific implementations. “SELECT...” is an abstraction for specifying Sets etc. — Maven is simple, not arcane. I’ve produced countless “custom” builds with wild variations of need and never has Maven let me down. In some sense this is easy to prove (see maven-antrun-plugin); however, Maven’s core plugin/idioms supports 90+% of use cases I’ve seen over many many “weird” build requirements. To your example, “copying files” is fundamental; however you have to learn the idiomatic way to do it if you want to reap the benefits. Otherwise, just call out to maven-antrun- or similar. But then you’re chasing your tail.
- greenhouse_gas 9y ago
  I've never used Maven, only gradle. The issue with convention over configuration is that you don't see how things should happen, because they're hidden behind the convention. For example, what are the steps behind your Android build? Can you tell me exactly what steps gradle takes when you run gradlew assembleDebug? So if for whatever reason you need to modify something, you're completely on your own.
  - frant-hartm 9y ago
    Sure.. $ gradlew -m assembleDebug Learn the tools you use..
lmm 9y ago
> after all is said and done, programming is about having your computer "do" something - whether it be to write some bytes to the disk or to send some bytes to the network. Not always. Often, particularly in scientific computing, you just want to ... compute ... a result. I mean sure, the computer needs to display the result to you, but the computation isn't about displaying it, it's about computing it. Just like adding up a bunch of numbers on a calculator isn't about getting the calculator to "do" anything. > often you don't need such a complicated abstraction, you just "need something done" before (or after) building. Abstractions should be simpler than the thing they abstract over, that's their whole point. Treating my computer's memory as a flat array of numbers is simpler than thinking about how much current is flowing through each RAM wire. "Compile all source files" is simpler than "execute javac Foo.java, then execute javac Bar.java, then..." > Whether it be that you want to download an HTML file to package, or to move the resulting file to a certain directory, or to clean a certain directory, your build language shouldn't be that arcane that you have to create a "build.sh" to get things done. You shouldn't need a build.sh, agreed, but nor should you need particular things to happen to particular directories. Maven has great support for things like "package my documentation in the standard way". It's only when people try to fight it about the low-level details that they really shouldn't be caring about that they run into trouble.

wellpast 9y ago

— “SELECT...” is not an abstraction for “for...”, by the way. Abstractions are not for specific implementations. “SELECT...” is an abstraction for specifying Sets etc. — Maven is simple, not arcane. I’ve produced countless “custom” builds with wild variations of need and never has Maven let me down. In some sense this is easy to prove (see maven-antrun-plugin); however, Maven’s core plugin/idioms supports 90+% of use cases I’ve seen over many many “weird” build requirements. To your example, “copying files” is fundamental; however you have to learn the idiomatic way to do it if you want to reap the benefits. Otherwise, just call out to maven-antrun- or similar. But then you’re chasing your tail.

greenhouse_gas 9y ago
I've never used Maven, only gradle. The issue with convention over configuration is that you don't see how things should happen, because they're hidden behind the convention. For example, what are the steps behind your Android build? Can you tell me exactly what steps gradle takes when you run gradlew assembleDebug? So if for whatever reason you need to modify something, you're completely on your own.
- frant-hartm 9y ago
  Sure.. $ gradlew -m assembleDebug Learn the tools you use..

lmm 9y ago

> after all is said and done, programming is about having your computer "do" something - whether it be to write some bytes to the disk or to send some bytes to the network. Not always. Often, particularly in scientific computing, you just want to ... compute ... a result. I mean sure, the computer needs to display the result to you, but the computation isn't about displaying it, it's about computing it. Just like adding up a bunch of numbers on a calculator isn't about getting the calculator to "do" anything. > often you don't need such a complicated abstraction, you just "need something done" before (or after) building. Abstractions should be simpler than the thing they abstract over, that's their whole point. Treating my computer's memory as a flat array of numbers is simpler than thinking about how much current is flowing through each RAM wire. "Compile all source files" is simpler than "execute javac Foo.java, then execute javac Bar.java, then..." > Whether it be that you want to download an HTML file to package, or to move the resulting file to a certain directory, or to clean a certain directory, your build language shouldn't be that arcane that you have to create a "build.sh" to get things done. You shouldn't need a build.sh, agreed, but nor should you need particular things to happen to particular directories. Maven has great support for things like "package my documentation in the standard way". It's only when people try to fight it about the low-level details that they really shouldn't be caring about that they run into trouble.