8 ms·

When did our tools become our religion?

36 points by avadhoot 4y ago

h2odragon 4y ago
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.
macshome 4y ago
They become religion the moment that anyone else uses the “wrong” tool.
- justincredible 4y ago
jdeaton 4y ago
> It is rather simple: The tools don't matter. Its hard to read past nonsense like this.
- hef19898 4y ago
  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.
- exmadscientist 4y ago
  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.
  - chongli 4y ago
    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.
    - afarrell 4y ago
      The Romans were not as smart as us because they did not have the tools to understand the neurological effect of lead poisoning.
      - falcolas 4y ago
        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.
      - ablob 4y ago
        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.
    - falcolas 4y ago
      > 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.
- falcolas 4y ago
  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.
  - 082349872349872 4y ago
    In principle, if stuck on a desert island, we all could recreate our tools, right? (stuck, w/plenty of hardware and electricity, that is)
    - falcolas 4y ago
      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.
mgarfias 4y ago
9mm vs .45. Ford v chevy. John Deere vs kubota. It’s not just us geeks.
- molsongolden 4y ago
  10mm*
  - hef19898 4y ago
    .22, depending on the use case.
- mc32 4y ago
  No, I want Alice Chalmers ;)
  - mikestew 4y ago
    Minor nitpick: Ms. Chalmers did not make tractors. Two dudes named Allis and Chalmers did.
    - mc32 4y ago
      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.
- pugworthy 4y ago
  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.
the_third_wave 4y ago
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.
- CharlesW 4y ago
  Forgive me father, for I have used tabs to indent my code.
  - themadturk 4y ago
    In a Commodore 64 emulator, write a BASIC program to output 10 Hail Marys. Thy sin is forgiven.
    - the_third_wave 4y ago
      Here is a BASIC program that will output 10 Hail Marys in a Commodore 64 emulator: 10 FOR I = 1 TO 10 20 PRINT "Hail Mary" 30 NEXT I 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. 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 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. 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...
thdrtnl 4y ago
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.
CharlesW 4y ago
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.
bloblaw 4y ago
FTA: > 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.
- madrox 4y ago
  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.
  - csdvrx 4y ago
    > 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.
    - bloblaw 4y ago
      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/ 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.
  - marcosdumay 4y ago
deleted 4y ago
[deleted]
Canada 4y ago
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!
casey2 4y ago
At least since alt.religion.emacs.
- pugworthy 4y ago
  For sure. The Emacs vs VI divide has been with us for an eternity.
dasil003 4y ago
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.
RcouF1uZ4gsC 4y ago
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.
deltree7 4y ago
(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.
- akiselev 4y ago
  Where humanity goes, evil [1] follows. [1] https://github.com/emacs-evil/evil https://github.com/emacs-evil/evil
  - 082349872349872 4y ago
    Editors lead to fresh code Fresh code leads to bugs Bugs lead to suffering
    - akiselev 4y ago
      Suffering leads to the management side
randcraw 4y ago
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.
- eYrKEC2 4y ago
  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.
- sumtechguy 4y ago
  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.
- chinabot 4y ago
  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.
danbruc 4y ago
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.
- _a_a_a_ 4y ago
  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.
  - danbruc 4y ago
    [...] 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.
    - _a_a_a_ 4y ago
      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?
      - danbruc 4y ago
        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. [1] https://en.wikipedia.org/wiki/HATEOAS https://en.wikipedia.org/wiki/HATEOAS [2] https://en.wikipedia.org/wiki/Naked_objects https://en.wikipedia.org/wiki/Naked_objects
wayeq 4y ago
"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.
ghusto 4y ago
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.
metalliqaz 4y ago
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?
- patrick451 4y ago
  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.
thewebcount 4y ago
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.
poiuyt098 4y ago
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.
nextlevelwizard 4y ago
> 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.
- justsomehnguy 4y ago
  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.
w0de0 4y ago
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!
deterministic 4y ago
Of course tools matter. There is a reason why we are no longer programming in Assembler.

36 points by avadhoot 4y ago

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.

macshome 4y ago

They become religion the moment that anyone else uses the “wrong” tool.

justincredible 4y ago

jdeaton 4y ago

> It is rather simple: The tools don't matter. Its hard to read past nonsense like this.

hef19898 4y ago
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.
exmadscientist 4y ago
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.
- chongli 4y ago
  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.
  - afarrell 4y ago
    The Romans were not as smart as us because they did not have the tools to understand the neurological effect of lead poisoning.
    - falcolas 4y ago
      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.
    - ablob 4y ago
      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.
  - falcolas 4y ago
    > 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.
falcolas 4y ago
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.
- 082349872349872 4y ago
  In principle, if stuck on a desert island, we all could recreate our tools, right? (stuck, w/plenty of hardware and electricity, that is)
  - falcolas 4y ago
    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.

mgarfias 4y ago

9mm vs .45. Ford v chevy. John Deere vs kubota. It’s not just us geeks.

molsongolden 4y ago
10mm*
- hef19898 4y ago
  .22, depending on the use case.
mc32 4y ago
No, I want Alice Chalmers ;)
- mikestew 4y ago
  Minor nitpick: Ms. Chalmers did not make tractors. Two dudes named Allis and Chalmers did.
  - mc32 4y ago
    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.
pugworthy 4y ago
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.

the_third_wave 4y ago

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.

CharlesW 4y ago
Forgive me father, for I have used tabs to indent my code.
- themadturk 4y ago
  In a Commodore 64 emulator, write a BASIC program to output 10 Hail Marys. Thy sin is forgiven.
  - the_third_wave 4y ago
    Here is a BASIC program that will output 10 Hail Marys in a Commodore 64 emulator: 10 FOR I = 1 TO 10 20 PRINT "Hail Mary" 30 NEXT I 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. 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 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. 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...

thdrtnl 4y ago

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.

CharlesW 4y ago

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.

bloblaw 4y ago

FTA: > 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.

madrox 4y ago
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.
- csdvrx 4y ago
  > 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.
  - bloblaw 4y ago
    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/ 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.
- marcosdumay 4y ago

deleted 4y ago

[deleted]

Canada 4y ago

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!

casey2 4y ago

At least since alt.religion.emacs.

pugworthy 4y ago
For sure. The Emacs vs VI divide has been with us for an eternity.

dasil003 4y ago

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.

RcouF1uZ4gsC 4y ago

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.

deltree7 4y ago

(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.

akiselev 4y ago
Where humanity goes, evil [1] follows. [1] https://github.com/emacs-evil/evil https://github.com/emacs-evil/evil
- 082349872349872 4y ago
  Editors lead to fresh code Fresh code leads to bugs Bugs lead to suffering
  - akiselev 4y ago
    Suffering leads to the management side

randcraw 4y ago

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.

eYrKEC2 4y ago
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.
sumtechguy 4y ago
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.
chinabot 4y ago
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.

danbruc 4y ago

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.

_a_a_a_ 4y ago
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.
- danbruc 4y ago
  [...] 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.
  - _a_a_a_ 4y ago
    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?
    - danbruc 4y ago
      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. [1] https://en.wikipedia.org/wiki/HATEOAS https://en.wikipedia.org/wiki/HATEOAS [2] https://en.wikipedia.org/wiki/Naked_objects https://en.wikipedia.org/wiki/Naked_objects

wayeq 4y ago

"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.

ghusto 4y ago

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.

metalliqaz 4y ago

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?

patrick451 4y ago
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.

thewebcount 4y ago

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.

poiuyt098 4y ago

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.

nextlevelwizard 4y ago

> 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.

justsomehnguy 4y ago
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.

w0de0 4y ago

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!

deterministic 4y ago

Of course tools matter. There is a reason why we are no longer programming in Assembler.