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…
When did our tools become our religion?
41–50 of 70 posts
Re: When did our tools become our religion?
#42... thanks for the insight.
Re: When did our tools become our religion?
#43FTA: > 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…
(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?
#44Nobody 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…
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?
#45Earlier 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.
> 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?
#46If 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…
> 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?
#47At least since alt.religion.emacs.
Re: When did our tools become our religion?
#489mm vs .45. Ford v chevy. John Deere vs kubota. It’s not just us geeks.
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?
#49If 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.
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?
#50I'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.