When did our tools become our religion?
vanschneider.comFTA: > Otherwise, the only thing that matters is that the tool works. Every tool comes with its own upsides and downsides, but most of them are increasingly the same. They mostly differ in workflow. But I can promise you: they all draw rectangles equally as well. If you can accomplish your work with the tool, then it serves its purpose.
Eevee dismissed with that argument succinctly when they wrote in their "PHP: a fractal of bad design" article:
> Do not tell me that “good developers can write good code in any language”, or bad developers blah blah. That doesn’t mean anything. A good carpenter can drive in a nail with either a rock or a hammer, but how many carpenters do you see bashing stuff with rocks? Part of what makes a good developer is the ability to choose the tools that work best.
That last sentence drives the point home.
As the saying goes, it is a poor craftworker who blames their tools... but the popular understanding in our community that it means a craftworker should be able to do anything with crappy tools is wrong. The real meaning is that it's a poor craftworker who has crappy tools, but just keeps using them. They should either fix them or get better tools. It is a poor craftworker who blames their tools because it is a poor craftworker who continually uses blameworthy tools!
(Or, in other words, I 100% disagree with the original post. Tools do matter, and it is folly to think otherwise in the face of overwhelming evidence.)
Since our tools are Turing complete, we are in the unusual position of sometimes being able to use our crappy tools to carve out better tools within the tools themselves, but in general, you should be using the best tools you can. And, yes, it is completely fair to judge a tool as being either bad for a job, or just a bad tool in general. Craftworkers who refuse to make such judgments are not exhibiting wisdom, but lack of discernment.
That is not to say that you must always use the best tool to the exclusion of all else. Much as we may not like to hear it, we aren't really craftworkers here for the most part, we are engineers. If I got moved to a big PHP 3.0 project, I would not make it my first order of business to insist that we drop everything and rewrite it in $BETTER_TOOL. That's not a good engineering move. The quality of our tools is only one part of a very complicated melange of relevant issues. But we're still allowed to have judgments, and the fact that tool quality is not 100% exclusively determinative doesn't mean the only other alternative is that they must be 0.0000...% relevant.
> The real meaning is that it's a poor craftworker who has crappy tools, but just keeps using them
The "real meaning" of a common aphorism is the one that's obvious to everyone. That's the point of aphorisms.
If common aphorisms needed special "truth knowers" to explain them, then the words themselves might qualify as religion.
I don't live in Silicon Valley. I live in a place where trades are a much bigger portion of the economy, and much of my social circle is in them. This is the common meaning that everyone else around me knows. I've explained the programmer meaning of "it's OK to stick with bad tools and you should just expect the user's skills to make up the difference" to the people who actually work with physicals tools in the trades, and it is met with either befuddlement or open laughter. No one who actually works with physical tools for a living could possibly think what programmers think about tools. You only need to experience once in your life the night-and-day transition from a blunt saw to a sharp one to get it. A skilled user of saws does not sit there bashing away at wood with a blunt saw and expecting their "skill" to cut the wood. No job foreman will sit there watching you bash away with a dull saw and smile approvingly because he knows you're making it up with "skill".
This is a peculiarly programmer misconception of an aphorism that predates the entire industry of programming.
I've heard it differently, but is a corollary: bad tools make it easy for bad developers to do bad things. Good tools make it easy for bad developers to do good things.
Bad tools make it hard for good developers to do good things, and good tools make it easy for good developers to to good things.
Why do you care about bad developers? They won't do good things either way.
We should all care about bad developers because if they make bad products sooner or later you or I will use one! Bad developers are the ones who store your password credentials and personal information in plain text. We should all care about making it easier to do things the right way because then the right way happens more often.
This is one of those things that are obvious in the specific, but we're talking in abstract terms.
Because I am very often (temporarily at least) a bad developer. I am tired, or sloppy, or unmotivated by a particular project, and I make mistakes. I want my tools to help me.
Most people, in my experience, are both good and bad developers in different measures. Tools that help the bad developer therefore help all developers in those moments when we make mistakes.
> bad tools make it easy for bad developers to do bad things
Who get to say if it's good or bad?
We need more "software things".
Users can decide what's good.
A few billion people have decided FB (done in php) is good.
Eevee also dismissed with this argument as well in the same article: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
> Do not tell me that Facebook and Wikipedia are built in PHP. I’m aware! They could also be written in Brainfuck, but as long as there are smart enough people wrangling the things, they can overcome problems with the platform. For all we know, development time could be halved or doubled if these products were written in some other language; this data point alone means nothing.
(Forming of a ) Religion is always a 4 step process.
i) Use a Framework/Tool/Process/Guideline rules to better your life.
ii) Feeling of elation/enlightenment when it provides that dopamine hit because it does provide benefits compared to before.
iii) The innate human nature to share the Framework/Tool/Process/Guidelines with others (and forming an opinion of them being idiots for not seeing the obvious benefits)
iv) The innate human nature to bond together on this shared experience and also seek social validation.
It applies from Christianity to Emacs.
Where humanity goes, evil [1] follows.
Editors lead to fresh code Fresh code leads to bugs Bugs lead to sufferingSuffering leads to the management side
They are treated religiously because people on one side know better, and the people on the other side take it personally / feel threatened.
I'm not going to use names in this example, lest I start a religious war right here — though I'm sure you can figure them out — but think of how much damage a poor but easy to learn programming language can do to the software industry as a whole.
The most obvious issue is that the poor language makes it easy to do things the wrong way (costing time, money, patience, and other scarcities, later on, for the sake of a quick-win now — a false economy, in other words). This argument is mostly agreed on already.
The less popular argument though, is that lowering the barrier to entry isn't necessarily a good thing. It brings in both less experienced, and just lesser programmers. The former has a place in the industry, just not the place they're being given. Everyone has to learn somewhere, but it shouldn't be in a place that gives equal weight to them as the more experienced developers. The latter need baptism by fire.
I'm currently learning difficult-as-all-hell programming language X. I'm sure it's not difficult at all for the majority of the programmers that know it, but for me, it's a struggle. I see it as a trial by fire though: The more I make it through, the more I'm changing in the ways I think about some areas of programming. If the barrier was low, there would be no struggle, and without struggle there is no learning.
Meh. This is a lot of words to express a mentality that may be more pithily summed up by the idiom "it's a poor craftsman that blames his tools". I happen to agree, but I don't see any value in convincing the world it's true.
There's a certain irony in arguing that designers spend too much energy in religious wars about tools. Is it a better use of time to argue about such meta questions?
My respect for a designer is 100% based on their output. Whether they are deeply about tools or they just use whatever is in front of them is utterly irrelevant. Who am I to judge someone else's process? Creativity comes from individual agency and can never come from the thought police or people who are primarily driven by a need for consensus.
Well said!
When you want to argue with someone for they joy of arguing; because vigorous discourse is enjoyable for itself, then trivial things like "vi vs. emacs" are great subjects for debate.
It seems that some never appreciated the "joy of argument" motivations and assumed that holy wars were a valid means of personal expression and useful for community building.
They're not a religion in any sense of the word. A culture, maybe. A religion? Nay, never.
OK, I'll make an exception for Emacs users. And Lisp users, them as well seeing how as both sort of fit in the same pews. Apple also has attracted a pious crowd so they also get an exception, especially given the sacrifices which its followers make, the regular pilgrimages to the Holy Store where the latest sacrament is purchased.
For every fervent user of X, I can find you 5 zealous irrational haters who are 100% convinced that X is just a religious fluff and that there is no way it's actually better than Y (what they are using). I have in fact, been guilty of that kind of thinking myself.
The Apple religion seems to have devolved down to simple classism. Back in the 80s, Apple really pushed the "us vs them" othering angle but now Apple is for everyone, as long as you can afford it.
Forgive me father, for I have used tabs to indent my code.
In a Commodore 64 emulator, write a BASIC program to output 10 Hail Marys.
Thy sin is forgiven.
Here is a BASIC program that will output 10 Hail Marys in a Commodore 64 emulator:
To run this program in a Commodore 64 emulator, type in the lines of code and then press "ENTER" after each line. Then, type "RUN" and press "ENTER" to execute the program. The program will loop through 10 iterations, printing "Hail Mary" on each iteration.10 FOR I = 1 TO 10 20 PRINT "Hail Mary" 30 NEXT IAlternatively, you can also use the following single line of code to achieve the same result:
This line of code uses a semicolon (;) to separate multiple commands on the same line, and the colon (:) to separate multiple lines of code that are treated as a single line. The program will loop through 9 iterations, printing "Hail Mary" on each iteration, and then print "Hail Mary" once more after the loop.10 PRINT "Hail Mary";:FOR I = 1 TO 9:PRINT "Hail Mary";:NEXT II don't think this bot understands the term "Hail Mary". I told it to spit out the whole thing and it did, followed by a one-line program which could never be entered on a real C64 (hardware or emulated) given that the maximum line length in the BASIC screen editor is 255 characters. Also, what's up with that silly extra "Hail Mary" in the single-line version and why are those colons there? I'm afraid salvation is far away...
I understand what this post is trying to say, but I believe tools matter.
Since I started using Jetbrains software I am able to work more agile because refactoring just works (most of the time).
But when another brand comes with a better IDE I will just as easily abandon Jetbrains.
Imho you should use the best tool for the job. But both the jobs and tools change.
9mm vs .45. Ford v chevy. John Deere vs kubota.
It’s not just us geeks.
I'm doing a rotisserie rebuild of my MG Midget right now, and am gluing new floor pans in using 3M (auto industry) panel bonding adhesive.
It sure brings in the, "It should be welded on as Donald Healey and god intended!" crowd with some online forums.
No, I want Alice Chalmers ;)
Minor nitpick: Ms. Chalmers did not make tractors. Two dudes named Allis and Chalmers did.
Aww, dangnit, you're right. I think you could run them old models on Kerosene or Gasoline.
They were real simple -easy to maintain by a small farmer.
10mm*
.22, depending on the use case.
The author specifies, "The only exception is when working with a team".
But of course, one is always working with a team, even if your other teammate is Future You.
Nobody looks at a house and asks, "What kind of hammer and nails did they use?"
The OP is right: the interesting stuff in computing has always been what a new app/tool/library can DO, how it's being USED, but never HOW it was made.
This revelation first came home for me when the team of contractors I was on proposed to our customer that our mission for the next year should be to convert our prototype R&D air traffic control simulation from Pascal into C++. We were (stupidly) surprised when the customer declined, observing that the product's capabilities wouldn't advance at all but merely become a little more modern under the hood, where nobody but us contractors would ever look.
A craftsman in building construction values his tools as well. You will see contempt on a journeyman's face if you hand him a Harbor Freight circular saw, but he will ogle your Fesstool circular saw.
Some tools feel better in your hands.
Funnily I am in the same situation but from the other side being the aging (60+) Pascal contractor who came in to a small company when there was no IT staff and wrote a complete MRP/ERP/Everything system. This small company over 15 years became a billion dollar one and I am now the only contractor in a large IT department with teams of programmers.
Ironically it is me pushing the change as there are not really many Pascal guys left and the current guys wouldn't dream of supporting such an "archaic language". I wish they would get a move on before I expire completely.
Ah rewrites. Sometimes you have to do them. Not because you will get new features. But just so you can hire someone at a reasonable price in the near future and it will actually run on a somewhat newish computer on a tech stack that was EOL 2 decades ago. Then you also get someone who rocks in and says 'you are just using the wrong language at my previous job we used xyz and it is the best we should just switch everything over to that'. Somewhere in the middle of those two points is where you decide to rewrite it.
> It is rather simple: The tools don't matter.
Its hard to read past nonsense like this.
People can - do, and always have done - work around tool deficiencies.
Once you're familiar with a tool, the simple act of moving to another tool will be what slows you down, but you'll get back up to speed soon enough.
The only place tool choice really matters is when you're part of a team who has to pass their work around. If you're not using the same tool - whichever tool it may be - it adds needless friction.
In principle, if stuck on a desert island, we all could recreate our tools, right?
(stuck, w/plenty of hardware and electricity, that is)
Whole rant... responding to the wrong comment.
Anyways. Could we re-create our programming tools? Eventually. So long as we have a computer and a whole lot of time. Bootstrapping a programming language to create an operating system's going to be a real bear though.
Now then, making those tools efficient (namely optimizing compilers) and safe is going to take a whole lot of time and brainpower.
It's entirely true, though. If you can deliver good work, on time, integrating well with your team (as applicable), then no one cares what tools you used or generally how you did it. It might be very important to you, and you can absolutely spend time on getting your setup right for you, but you should not make the mistake of thinking that anyone else cares.
No it isn't. The Romans were every bit as smart as we are today. The biggest difference between us and them is our tools.
Similarly, compare the computers of the 60's (or even the 80's) to the computers of today. The difference in outcomes reflects the difference in capabilities.
> The biggest difference between us and them is our tools.
Technology (gained throughout history) moreso than tools. For example, the Romans had concrete, (and it's a kind we still use occasionally), but we have about 1,000 different types of concrete, all with different mechanical properties and capabilities.
We have concrete water can flow freely through. We have concrete (well, more accurately techniques of building concrete forms) which has strength in tension. We have concrete which can bend, we have concrete which is astoundingly light. We have concrete we can can pump, and we have concrete which we can mechanically compact.
But when it comes to tools - aside from transporting concrete - we still use forms, screeding boards, and trowels in a dozen different shapes. Even the best concrete surfacing tools are trowels spun with a motor.
The Romans were not as smart as us because they did not have the tools to understand the neurological effect of lead poisoning.
They realized they were being poisoned, but they had the cause confused - they blamed it on acidic foods, since non-acidic foods wouldn't leech much lead out of their utensils.
The Romans would be less smart than us, if they had the tools to understand the neurological effect of lead poisoning but couldn't do it anyway.
They do, and then they don't. The best tool, and remember that definition is highly subjective and situation dependant, doesn't help you if you a) have no idea how to use it properly and b) don't have a framework to use it in.
Once tool quality passes a certain threshold, it the user that matters.
With Prometheus. Or: our cult of Hephaestus.
And why shouldn’t they be - What other proof is there of our wisdom’s worth? Tools are the most of our humanity; the all of it, for what is not a tool? A shirt, a city: all not animal is the animus of tools. All we are which we are not is holy tooling; it is then the wisest worship!
I can't speak for others, but I'm currently going through a very painful time tools-wise. We've switched to a new workflow with all new tools and there are several objective ways in which they make my life harder. There was, of course, the learning curve that any new tool has in the first few weeks/months. It's been 2 years, and I'm still getting slowed down every damn day by these horrible tools. It's not that I haven't learned them, it's that they are objectively worse than what we had before. (And what we had before had a number of issues, too.) I will fervently let others know of the potential pitfalls of the tools I'm forced to use by my employer. It may make me sound like I'm being religious, but really, I'm just trying to warn others what they're getting themselves into.
If it was only arguing about equally good tools, but sometimes actively choosing the worse tools is beyond me. XML and SOAP were perfectly fine and mature solutions with a lot of optional bells and whistles, but no, we have to invent and religiously use JSON and REST which are inferior in almost any way. And then we reinvent everything we already had - we invent JSON schema to replace XSD, we invent Swagger to replace WSDL and SOAP, and whatever does the job of XPath, XSLT, ... And we of course also make this change in a software that has been developed for more than a decade - because this is how it is done nowadays - and now half of the services are SOAP and half of them are REST.
I feel you're trolling. SOAP was a horror and REST is nothing to do with data formats. And while XML was fine, XML schemas were hellish and I've awful memory of them.
> and now half of the services are SOAP and half of them are REST
which seems to contradict in tone your first sentence.
[...] and REST is nothing to do with data formats.
In theory yes, but in practice almost no one builds anything that comes close to the initial vision of REST, in practice, i.e. the way the term is commonly used, REST means little more than we push around JSON via HTTP and maybe the HTTP method indicates what operation I want to do. And REST I mentioned with Swagger in comparison to SOAP and WSDL, not to JSON or XML.
Perhaps you could explain what that means, given REST is defined fairly well in Fielding's dissertation, and fits in quite well with pushing data around with the HTTP method indicating the operation. Wat else?
HATEOAS [1], i.e. you discover the available operations dynamically. In my opinion totally impractical unless the service is directly consumed by humans or you are building some kind of naked objects application [2] with all its implications. But this is what really distinguished REST from other remote procedure call implementations and this is also what essentially nobody does.
And the other two halves are gRPC and GraphQL...
Perhaps a Monty Python Shoe vs. Gourd reference would illustrate...
Actually maybe it would be a better world with tools as our religion.
So far the Emacs vs vim and tabs vs spaces “holy wars” have not generated any real-life injuries or deaths unlike a lot of other “holy wars” both past and present.
> It is rather simple: The tools don't matter.
This is biggest lie. Tools matter a lot.
You can do everything with just ’ed’, but you can nor argue that you wouldn’t be more productive with pretty much anything else.
I think you missed the gist of the message.
> If you work on your own, pick the tool that works best for you. If you work in a team, pick the tool that works best for the team.
"If you work on your own, pick the tool that works best for you. If you work in a team, pick the tool that works best for the team."
... thanks for the insight.
At least since alt.religion.emacs.
For sure. The Emacs vs VI divide has been with us for an eternity.
They become religion the moment that anyone else uses the “wrong” tool.
Yet another website where the text is 3x the size of all the rest of the text on my screen. Did everyone forget that desktop browsers exist?
It's too big on mobile too. Somewhere along the way, people got the idea that giant fonts and gratuitous line-spacing is tantamount to good design.
Of course tools matter. There is a reason why we are no longer programming in Assembler.
It's not our tools. It's our argument over our tools that is our religion. It's what keeps us moving forward to discover the one true way... that One True Way that of course we will never reach or agree on. Naturally we clan up and try to get everyone else on board with what we love at the moment. It's all good, preach on!
Because it does matter: to a large extent it's a zero-sum game. Our tools evolve, and without popularity they and your skills will stagnate and you'll be less productive over time.
IT is changing fast and a stream of fresh converts is required to implement & update new libraries and features and protocols.