←back to thread

392 points mfiguiere | 1 comments | | HN request time: 1.016s | source
Show context
phendrenad2 ◴[] No.35474996[source]
> Build systems stand between a programmer and running their code, so anything we can do to make the experience quicker or more productive directly impacts how effective a developer can be.

How about doing away with the build system entirely? Build systems seem like something that shouldn't exist. When I create a new C# .NET app in Visual Studio 2019, what "build system" does it use? You might have an academic answer, but that's beside the point. It doesn't matter. It just builds. Optimizing a build system feels like a lack of vision, and getting stuck in a local maxima where you think you're being more productive, but you're not seeing the bigger picture of what could be possible.

replies(14): >>35475210 #>>35475243 #>>35475249 #>>35475260 #>>35475271 #>>35475272 #>>35475320 #>>35475645 #>>35476535 #>>35476550 #>>35477035 #>>35480031 #>>35485001 #>>35487462 #
palata ◴[] No.35475210[source]
How do you think VS builds your code?
replies(1): >>35476164 #
phendrenad2 ◴[] No.35476164[source]
The point is it doesn't matter. What it's doing internally isn't interesting to me, a programmer. I'd rather not think about it. Unfortunately, people have decided that microoptimizations like writing declarative build definitions by hand is beneficial, so I've had to learn many build systems.
replies(2): >>35478187 #>>35479744 #
1. __float ◴[] No.35478187[source]
The way it builds your software is also a declarative build system: MSBuild. It happens to be configured in XML instead of a Python-like language, and the IDE integration is probably better than what you get from Buck or similar.

Building software can be complex sometimes, and _pretending_ it's a "microoptimization" to care about that is unnecessarily diminutive.