3 ms·
The counter argument to this is that developers requiring more and more tooling surrounding what is arguably just a text file with some code in it can cause fri
by jaredcwhite 4y ago
The counter argument to this is that developers requiring more and more tooling surrounding what is arguably just a text file with some code in it can cause friction, yak shaving, and cognitive load over time.
Listen, there's nothing wrong with IDEs, linters, formatters, test frameworks, advanced dependency management across multiple projects & repos, yada yada yada. But there's also something to be said for being able to open up a blank file in a blank folder, writing some lines of code, and running a command to execute said code. That's it. That's the stack.
Programmers are constantly tempted throughout the ages to overcomplicate and overburden language ecosystems and stacks such that a newbie coming in has to learn an inordinate amount of knowledge about everything surrounding the language before they can even learn the language itself.
I guess what I'm trying to say is I'll always push back against this idea of "progress" == more complexity. Tools, frameworks, languages, and ecosystem evolve over time. Best practices change and adapt. That's to be expected. Is it progress though? Is it actually better?
I remain entirely skeptical.
- deleted 4y ago[deleted]
- jjoonathan 4y agoYeah, it's definitely possible to make tooling "investments" that never amortize, but I've also seen an awful lot of programmer-minutes become programmer-days when tooling degraded to the point of printf/run/printf/run/printf/run/bisect/repeat.
- pixelrevision 4y agoGo strikes a really good balance here.
- jamincan 4y agoMore opinionated solutions such as gofmt/rustfmt/black seem to be popular in part because they remove some of that cognitive load.
- returningfory2 4y agoI don't think this is a counter argument at all? If anything, it's reinforcing the argument in the article. > But there's also something to be said for being able to open up a blank file in a blank folder, writing some lines of code, and running a command to execute said code. E.g., in Go the tooling is so good that you can just create a file and run it using `go run .`. This is sort of the point the author is making? No need to worry about build systems, dependencies, etc.