Live data from Hacker News

When did our tools become our religion?

vanschneider.com

41–50 of 70 posts

Re: When did our tools become our religion?

#41

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…

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.

Re: When did our tools become our religion?

#43
post #16

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 fr…

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.

Re: When did our tools become our religion?

#44

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…

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.

Re: When did our tools become our religion?

#45
post #32
post #22

Earlier quoted context omitted.

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

Re: When did our tools become our religion?

#46
post #37

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 replac…

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.

Re: When did our tools become our religion?

#48
post #5

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.

Re: When did our tools become our religion?

#49
post #46
post #37

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 replac…

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.

Re: When did our tools become our religion?

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

Post reply on HN