When did our tools become our religion?
vanschneider.com
vanschneider.com
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.
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.
> 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.
Why do you care about bad developers? They won't do good things either way.
This is one of those things that are obvious in the specific, but we're talking in abstract terms.
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.
(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" 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.
This is a peculiarly programmer misconception of an aphorism that predates the entire industry of programming.
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.
Editors lead to fresh code
Fresh code leads to bugs
Bugs lead to suffering Suffering leads to the management sideI'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.
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.
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.
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.
Thy sin is forgiven.
10 FOR I = 1 TO 10
20 PRINT "Hail Mary"
30 NEXT I
Alternatively, you can also use the following single line of code to achieve the same result:
10 PRINT "Hail Mary";:FOR I = 1 TO 9:PRINT "Hail Mary";:NEXT I
I 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...
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.
It’s not just us geeks.
They were real simple -easy to maintain by a small farmer.
It sure brings in the, "It should be welded on as Donald Healey and god intended!" crowd with some online forums.
But of course, one is always working with a team, even if your other teammate is Future You.
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.
Some tools feel better in your hands.
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.
Its hard to read past nonsense like this.
Once tool quality passes a certain threshold, it the user that matters.
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.
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.
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.
(stuck, w/plenty of hardware and electricity, that is)
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.
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!
> and now half of the services are SOAP and half of them are REST
which seems to contradict in tone your first sentence.
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 a Monty Python Shoe vs. Gourd reference would illustrate...
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.
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.
> 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.
IT is changing fast and a stream of fresh converts is required to implement & update new libraries and features and protocols.