No one gives a shit what programming language you use

So there’s no room for language advocates? No one can discuss the pros and cons of a language because this author steeps themselves so deep in programming meta-talk, that it’s all they hear and have grown tired of it? What does the world gain from non-interest in programming languages?

> Pick the language and stack based on your team’s needs and comfort, based on your business’s need and risk tolerance, and based on how easy it will be to produce software for your target users in that language or framework. That’s your criteria. Not what I think, not what UBM thinks, and certainly not the language or framework de jour on Hacker News.

How do I determine the above if I’m not allowed to dictate which language I think is best? Especially if I’m given several options for languages that are similar?

They're all just tools. There's things to be discussed tool to tool (language to language) for sure, but I generally agree with the idea here.

>woodworkers take pride in the finished product, and seeing that finish product being used. They are not all hot on the tools they use

For a while another hobby of mine was photography, and oh man photography has so much tool talk online that I lost interest in any online discussions / forums. Comparing this lens to that and so on was so prevalent that it seemed entirely disconnected from the hobby of actually taking a photograph.

Decades ago I took some outstanding photographs with an early days digital camera that would be greatly outclassed by a random camera on a smartphone now, but does that matter?

I suspect it is because high level talk about tools is just easier than talking about the actual code / effort and hard work it is to make a thing.

This entire post is a bad, unfocused rant driven by author's opinion against the tweet's author but choosing the wrong one to write about. The tweet mentioned has no _elitism_. Recommending a product (a programming language in that case) is anything but elitism. Author makes the common claim about _using what others use_. Some products are new giving you a choice, and not every product is made by a team. More importantly indeed no client gives a shit about the language. The choice is about making YOUR work easier, enjoyable, better. Those are correlated by the way. If something makes you enjoy programming (some people DO enjoy programming for the sake of it), then this may lead to you producing a better product.

"Pick the language and stack based on your team’s needs and comfort, based on your business’s need and risk tolerance, and based on how easy it will be to produce software for your target users in that language or framework. That’s your criteria"

Yep especially the part about "how easy it will be to produce software for your target users". Case in point. My company uses PHP/Laravel framework for our SAAS and we didn't just choose it because it was cool but because Laravel comes with a great ecosystem, packages and community and most of my team was good in PHP for a while. I actually tried to go rogue by trying to force Golang on my team (long story) but almost dodged the bullet when my CTO told me to go pound sand just because I wanted to switch to Golang (I am the CEO). I am so glad I have people to tell me that I am wrong when I am.

We have not only created a great product but the time to market is 20 times of what could have been if we had switched to Golang just because it was cool (and don't get me wrong, I love Go as an amateur programmer and even wrote an internal tool in it to help our team). But for our core SAAS product, focus should be on time to market, customer needs and our team's strength and I am so glad we stuck to what works for us, PHP and Laravel in this case. I hardly have a customer asking about the Programming language we use (may be 2-3 have asked in last 7 years and those were technical folks from customer's team)

Let me phrase that so that it makes sense, "no customer gives a sh*t what programming language you use, but you should care to pick one that suits the task."

> and based on how easy it will be to produce software for your target users in that language or framework.

Sometimes this might be Clojure. Often times it might be a language that can do things in parallel, either async i/o or perhaps concurrent computation. In these cases choice of language matters. Also if your company/team(s) are a certain size and growing, staticly typed languages have been chosen by other companies going through that transition even when already successfully using a ducktyped dynamic language. Know your tools, learn your craft, take posts, including this comment, with a grain of salt.

Isn't this guy a little too angry? I mean he even calls a person a "plague", which seems a bit excessive.

Well, I think Bob Martin promoting Clojure is a bad thing for Clojure... The Clojure community is really awesome, and so is the language, there's no need to have a self-declared (and under-substantiated) guru promoting it. I don't particularly care which languages other people use, but I do care about the ones I use (and, in my case, Clojure is the first one I reach for unless I have very specific requirements that would prevent me from doing so).

I think a better question would be:

Should we listen to UBM just because he is UBM?

The question here in general is:

Should we listen to people that know nothing about our situation?

The question is not: Why we are not using Closure?

The question should be: When is Closure a good tool for use to use?

And the answer to that is not because its 2021.

A better question always will be: What is the right tool for solving this problem, building something or reparing something that is broken.

Yes you should look into other languages. Yes you should not use one tool for all problems. Also you should not use a new tool every time a new problem comes.

You need to balance this out.

In the beginning you will not know if this is the right tool but you should try and you should be ready to destroy what you build. So that you have learned from it to build something better.

No one gives a sh*t about what materials are used to construct the turbine of your airplane - until it crashes specifically because of this material. Then and only then will anyone care.

But does it mean the material otherwise doesn't matter? Obviously not, it still matters a lot.

Then again, asking others to use a language generally without context, that's annoying.

Nobody cares, until the choice of language has practical consequences for the end user. E.g. I'm not touching anything written in Ruby because of my bad experiences with the mess Gems leave in the system.

Nobody cares as long as your choice of language doesn't make the program into its own special thing that needs to be handled differently than all other programs. When it does, I will not only care about your choice of language, but also about your choice of toolkit (e.g. Gtk3 being out of place outside of Linux/Gnome).

On the server it's less of an issue, because it's mostly the developer that needs to deal with the consequences of their choices, not the end user.

I dunno, it's not that I give a shit, it's that I find it interesting what languages people are using, and why. I don't find it elitist or offensive, it's just people being... I dunno people on Twitter. If someone wants to brag about using Clojure (or whatever was the point of the highlighted tweet - I actually took it as a joke), so what? So now I know someone probably really likes a language I know nothing about.

I guess I just don't understand the strong reaction to this. You wanna be a programming language elitist? I don't give a shit, go right ahead and be an elitist.

The author of this post appears to do an excellent job of projecting negative emotions onto the tweet that broke the camel's back, so to speak.

He makes it appear as though the entire software development industry, and especially how developers carry themselves within it, is not to his liking. I think he is calling for more humility, but I'm not sure, because this appears to be more of an attack on a vaguely-defined group of people rather than a call to action or a proposal for how software developers could present themselves more to his liking.

"People don't want a quarter inch drill, they want a quarter inch hole."

Leo McGivena, 1947

I will disagree with the title in that it is important to consider your means of production, and a language is not just a language, it is the opportunity cost of that language versus another in terms of efficient and accurate delivery of what the people want, support provided by others, the expertise in the market, 3rd party tooling and integration, and so on.

So you should give a shit what language you use, to give the people what they want the best way possible.

I would say programming languages are like musical instruments. Python might be like a guitar, easy to pick up and easy to start playing songs with knowledge of a few popular chords. C might be like piano, requiring manual dexterity in both hands and deep knowledge of music theory. Maybe Clojure is cello or something. All really capable of playing beautiful music in the hands of a skilled musician. Don’t just stick to brass or woodwinds, explore what you resonate with and play the best music on.

Maybe part of the problem with what we see in software is caused by people not caring enough which programming language is used.

Being prideful of the tools you use is dumb. Being prideful of not being prideful of the tools you use is also dumb. When you have "sh*t" in your title, you might want to check if this is something you really want to say.

I don’t disagree with the general viewpoint, but I’m not sure why all the vitriol. The idea of software craftsmanship is just an over-correction on the earlier prevailing perception of programmers as nerdy assembly line workers. These days programming is a well-paid and well-respected job, and we can probably just ignore those with weird chips in their shoulders from either side.

Regardless of the technology used there is a lot of value in writing code that can be changed without incurring $5MM in surprise losses to a company on a random Monday morning.

The sushi craftsperson and the wood worker are creating something that does not have to be read and understood by some poor schlep a year or even two weeks from now. Software is in maintenance mode almost immediately. It is not functional art nor should one ascribe it to be.

I despise the word craftsman in relation to software for a few reasons. First off, the word invokes visions of a crusty old dude carving wood. Secondly, it's "craftsperson" which doesn't have a good ring to it and does not express the notion properly. Perhaps it does sound elitelist, gender aside.

The author should have thought a bit more before firing off this rant but I kind of agree.

I'm tired of people autistically obsessing over languages too. It would be nice if we could always select a domain specific language that naturally begets readability but we cannot.

Why did you write that in Java? Because the company made me.

So two issues with this.

> Pick the language and stack based on your team’s needs and comfort, based on your business’s need and risk tolerance, and based on how easy it will be to produce software for your target users in that language or framework.

Developers clearly do care what language they use so this is a factor to take into consideration. Plain and simple - Java 1.0 might tick all of these boxes but you'll struggle to find many interested and passionate developers.

> I believe we can build better software, faster. I believe adopting Test Driven Development can change how we build software. I believe it allows us to build better software, faster. I believe it allows our software projects to reflect the needs our businesses and stakeholders have: To get the features stakeholders want, and demonstrate how the system works as quickly as possible.

This is from George's homepage which reads exactly like the 'BS' he's targeting. Which I think nullifys his argument - he's just gone on to give a shit about programming techniques instead.

Nobody driving across a bridge gives a shit about what tools the people who designed and built it used.

But they sure do give a shit about whether it's gonna fall down when too many big rigs drive across it, or whether a wind at just the right speed is gonna turn it into Galloping Gertie, or any of the other things that professional engineering practice is designed to make sure has been checked for by multiple people along the way from "hey we should put a bridge here" to "here I am doing my boring daily commute and it crosses this bridge".

Does your programming language make it harder to fuck up? Is it one that other people can pick up when you've left the project and shit needs changing? Is it one that leaves everyone involved in writing this code more pleasant to deal with than [Shitty Language Goes Here] because they're spending a lot less of the day swearing at the code?

That shit, they give a shit about.

I spent the majority of my life programming. Commodore 64 back when I was a kid, then I left the computer for a couple of years and got back into it in my teens. After a couple of promotions, and some shift in focus, I found myself, at work, not programming at all. It wasn't a sudden change, it happened over a couple of years. That's when I found that I need programming in my life for the sake of programming. I want to write code for the experience of writing code.

Today, I do write some code for work, but most of the code that I write, I write for entertainment—and for myself. Advent of Code makes December the best month of the year for me.

So, I agree with the sentiment of the article in general, but programming can also be valuable in itself.

The author is partially right. Programming language selection is rarely the factor that will make or break the success of your project. This assumes you're making a reasonable choice of course - no writing databases in Python or web apps in C.

But I don't understand why the author is so upset about people talking about programming languages. If we stop discussing the pros and cons of the tools that we use, we will continue to use today in perpetuity. We suck the oxygen out of the new tool space because anyone who tries to create something will be told "No one gives a shit".

An aside, we're all adults here OP. If you're going to swear, go ahead and say "shit". No need for this coy asterisk.

Maybe no one should but the majority of people in the industry certainly do. I feel like I can program in any language and for most product use cases the choice is essentially arbitrary. Interviewers do not seem to agree.

I run a corporate data science department and I've been fortunate enough to have management's support to run things however I want as long as I'm getting the job done. I built an MVP for a report in R with an intention of replacing it with a production-level language. Boss loved the report exactly as written and I realized the R version was good enough. Choosing a tool can involve striking a tough balance between "good enough" and avoiding creating technical debt, but trusting the people running the project to make the right choice is key.

> Take Jiro from Jiro dreams of Sushi, an example of a master of the ‘craft’ of making Sushi. Jiro doesn’t tout that he’s the best at it; but everyone else does. That’s a major difference from UBM’s (and others) self-identifying as a craftsman, is that Jiro doesn’t do that. He humbly learns and tries to get better, and more importantly tries to serve others. He doesn’t parade around with a self-given label that says “Sushi Craftsman” even though he ostensibly is.

The self-labeling does exist though, they just use a different label: Artisan.

This is extremely to the point especially when developers are consultants who deal directly with business people. I haven't met a single decision maker in any company who'd know the difference between Rust/Golang/ Pascal,nor could they care to know. All they need to know is that you can solve their problem by writing code. Of course when you walk into an existing JAVA codebase that needs modifying, that's what you'll work with but outside of these situations nobody cares.

I don't know if we watched different versions of Jiro dreams of Sushi, but it seems we came away with very different pictures of Jiro if the author sees him as non-elitist, or believes he concentrates on things that matter overall rather than the details of his craft.

Anyway, I agree with the author's overall concept that the language isn't necessarily important and shouldn't be worn as a badge, but I think he goes off track a bit in the details.

It's always been programming as a craft to create something of beauty vs. programming as an engineering pursuit to produce something that solves a problem.

Sometimes they overlap, but folks like UCB, DRY, SOLID, TTD, whatever the oft repeated mantra / person, miss the forest for the tree. Define your goals in terms of how you'll solve an actual problem:

"Implementing this new abstraction to follow DRY reduces the time it'll take for a new feature to be added since it encapsulates X, Y in a higher level interface and reduces boilerplate code". Great, go for it. I refactored half the project to remove 3 lines of easy to find but copy and pasted code? Not so great.

It is the difference between a junior and a more experience programmer. How does this >thing< you're excited about reduce code entropy, increase confidence in correctness, make it faster to iterate on the code in the future by other developers? That's mostly what I care about. The >thing< can be a language, library, framework, design pattern, etc. that you read about. Of course in specific cases you'll have performance, strict correctness, security, etc. that you're also solving for that's factored in.

It all boils down to what is good software? Everyone understands good software has to fulfill its functional requirements; but what about the non-functional requirements, the operational requirements, or the "ilities"?

I've seen a lot of programmers simply assume flexibility and scalability are de facto requirements. Are they? For some systems they are, for others they're not. Embedded systems don't typically concern themselves with scalability and oftentimes don't even worry about flexibility. Simplicity and testability are their major criterion. You need to know your actual non-functional requirements and not make assumptions. This oftentimes requires of years of experience, especially if working in a corporate setting.

Then there's the question of brownfield and greenfield deployment. Companies prefer to evolve software, they're generally not in favor of throwing everything out and starting over. Are you more interested in solving people's needs or using the most popular languages and frameworks du jour?

Greenfield development is risky. Programmers love getting a shot "to do things right." The problem is too many of those programmers are too inexperienced to understand how things became the way they are. They just assume everyone before them was a "bad" programmer and they, of course, are the "good" programmers. All these people are going to do is re-create today's problems, and possibly add in brand-new problems, using the latest languages and frameworks. All at an exorbitant cost.

Software is all about people, processes & tools and tools are rarely, if ever, the problem. Unless you understand people and processes I'm confident you can fail with any software stack you choose. Of course the converse is true too - if you understand the people, their needs and expectations, and the processes then you're way ahead of the game and are likely to succeed regardless of the software stack you choose or are forced to use. That's why I don't care about what programming language you use.

BTW - I like Clojure, I've used it a lot on little side projects. I've never once seen it used for commercial work. Too few people know it for most businesses to risk investing in it. Yes it's a chicken-and-egg problem but remember what I said earlier about people and processes?

I really don't follow this well, the argument seems to be:

- programming is described as a craft, a kind of skill

- actual crafts involve humility, rather than performative skill-showing

- real craft cares about the result/product, than good tooling and use of tools

- no one cares too much about the tools themselves

- hence no one should care about prog-lang which is just a tool

There are a few leaps in this logic I wonder if I missed something:

1) the basis of the argument is the description of software as a craft; but rather than discover what is meant by this, the author instead injects their own definition of "craft" - then instead of stating "programming is not a craft", they instead title the post something different based on an inference one or two steps removed from the original premise.

2) the tangent about "performative" distracts, I think, from what the beef is.

3) a prog-lang isn't a craft, really, nor is it like woodworking, or pottery, or factory lines, or house building, or being a ninja, or whatever other things devs like to describe themselves as. There may be aspects similar to those things, but in all those metaphors you have to pay attention to the point the metaphor is making rather than riff of the comparison on you own; ultimately devs compare programming to X to make some point, not because programming is actually like X in general

4) a prog-lang is a tool in an abstract sense; in a less abstract sense it is a language, hence the name. It makes as much sense to compare Java to the convention of calling a certain type of tool a "gouge", as it does to compare Java to the physical gouge itself.

5) woodworkers do bicker about tooling. and especially about finishes.

Hrm ... I tend to suggest picking the appropriate tool for the job. In the case there are multiple tools that can do the job, my focus tends to be on the one that enables me to be productive fastest, with the fewest likely bugs. I write notes about what the future might entail for this code, but I don't over-obsess on how to design it for the future.

Put another way, something that works well now, is often better than something that is designed for work at scale, that will take 2-3 months to get there.

This is why I use languages that I do, and tend to try to avoid the fad du jour. My time is valuable, and I'll spend it on languages that have a reasonable chance of working well for the tasks at hand, without the core language changing every single digit N months.

> woodworkers take pride in the finished product, and seeing that finish product being used. They are not all hot on the tools they use, and nor do they value the art of planing for its own sake.

Woodworkers are hot on the materials that go into their finished product and, for better or for worse, our language choice brings along a runtime and library that becomes the foundation of our digital artifacts.

Our toolchain matters and mastering more than one is non-trivial. Material world metaphors don’t map well to the digital world. I’m not a fan of Uncle Bob Martin and the tweet about Clojure in 2021 made me giggle but a mediocre proposal doesn’t take away from the importance of the underlying problem; our language ecosystem mastery defines the problem spaces we inhabit.

When I was young I also had this issue, at that time I thought that C# and .Net is the best thing ever and we will never have memory issues, there will be an OS made in C# and there are some benchmarks where C# is better then C++ . If you pay attention you see is almost the same thing that is now repeated by Rust fans, though to be fair there was no rewrite it in C# crowd from what I remember.

I had a similar phase where I was trying to convince people to switch to Linux, I still believe Linux is better for many tasks but I don't care anymore if my brother or some friends is running Windows, it is Red Hat ,Canonical and other's job to promote Linux for Desktops.

"I’ve written about the plague of UBM on our industry previously" wow the guy really hates Bob Martin, maybe it's a good thing to keep in mind that Bob is just a guy, he's not a prophet or a god, he doesn't know everything about everything ... you don't have to do or believe everything that Bob does or says or anyone else for that matter. But also Bob is entitled to his opinion, and I think he can tweet his opinions without being called elitist or anything alike because otherwise if we started name calling people with opinions, we're in deep deep shit!

PS: you can substitute Bob with any other name

A programming language is a tool. What matters most is your relationship with the tool:

- How much do you currently understand and trust it?

- How curious are you about learning to use it better?

- How well can you converse with a teammate about how to use it?

If you solve the same problem as everyone the language doesn't matter.

Some problems are yet, better expressed with one language than another.

As a CTO I always use the same language for prototyping, but in production we don't.

It seems like there are basically two types of programmers: those that think that programming languages are "done," and those that disagree.

To the former type, any modern language is roughly as good as any other, by definition, unless you've got an unusual use-case that requires something really specific. Thus any attempt at language advocacy sounds like tribalism or elitism. The people in this camp love to make analogies to woodworking tools, since innovation there stopped a while ago (presumably).

The latter type is perpetually depressed.

There’s always a valid point to be made regarding end users not “giving a shit” about the tech stack used to build your product.

But this author’s writing does not sound like he’s currently on one of those teams of people who produce sloppy, unmaintainable code because they can’t be bothered to stop and think of the larger structure of what they’re trying to build.

Because when you’re in that sort of situation, bring on the craftsmanship talk, please!

I disagree with a lot of what was said here especially now as new languages are starting to stray away from the same C++/Java pattern of doing things. New tools can provide new and better ways of solving old problems. That being said I feel like this entire article was written for a co-worker of his who won't stfu about his favorite new language that changes every 6 months.

>> No one gives a shit what programming language you use Well I do for one.

In my experience programmers with exposure to multiple PLs/paradigms/platforms tend to perform better than programmers who worked only with one, unless they go very deep and know that single PL/platform really well, like inside out (this is more often the case with C/C++ programmers).

To me, programming languages feel like incantations that elicit magic. Of course, I'm only interested in the magic, but in as much as the incantations link to the magic in ways that I can turn around in my head to make more/better magic, the incantations themselves have value in my mind.

I enjoy it when ppl use "Beautiful" "Clean" and "Elegant" to describe code, software, etc or anything technical.

It's quite the compliment to one's self to know what is beautiful not only to yourself but also what will be for others.

Uncle Bob works for a consultancy. And I guess it’s easier for them to get funding to reimplement something (then it’s greenfield) than to maintain some existing piece of software.

I realize this is about Clojure, but the headline.. try saying openly you write in VBA/VB6. I assure you, someone will take the time to tell you how wrong you are.

I agree for every language besides JavaScript.

JavaScript is clearly superior.

Sorry, but if I'm maintaining your code, I care, very much, about which language you chose and how adequate it is for what the thing does.

Unfortunately egomaniacs like UBM are on hiring committees. It's worth sticking your fingers into whatever flavor of the week garbage is out there on a weekend so you can atleast talk about it during interviews.

Tell that to your coworkers who have to change your code.

gotta throw a shoutout to https://reddit.com/r/rustjerk

> In another example of this performative culture of software craftsmanship, and I’ll use wood-working as an example because I grew up in that culture, woodworkers take pride in the finished product, and seeing that finish product being used. They are not all hot on the tools they use, and nor do they value the art of planing for its own sake. No, it’s always in furtherance of the ultimate goal: to produce something another human will enjoy using.

Okay, well that's just false. Wood workers tools are incredibly expensive and if you ask a wood worker about them they'll proudly show you what they are and glow about their quality and machining. I only know that because I've recently been looking into furniture making. Anyway, same sort of pride that programmers have around laptops, keyboards, languages, build systems, package managers, workflows, patterns cough tools of their trade.

The only difference, if you accept that a language is a tool, is that there is a massive barrier to entry for learning multiple languages at first, which usually requires that you implicitly or explicitly understand language fundamentals to make grasping concepts easier. I've worked with a lot of non-polyglot folks and this is usually the challenge. They'll very well understand one language but can only understand the world in it's paradigms. The world takes all types though.

> In fact, I’d wager that the niceness of the language is probably the least important part of choosing a language. Just ask everyone who bet the farm on coffeescript.

Ok, no. I've been on a few polyglot teams by now and I can tell you that I've experienced a theme of a main language and then several needs-based-implementations. That main language is usually a language that feels "nice" to code in by a majority of the programmers at the time. "Developer ergonomics" is definitely a thing I would classify as "niceness".

I've never understood the rage over people who make snarky comments about languages. So what? When I wrote in PHP in the early to mid 2000's people had all sorts of snarky things to say, it didn't deter me in learning new languages or applying myself more to PHP. The point that I think the author misses is that languages are different and so are various frameworks. They're all better at one thing or another, and just like programmers, fall in and out of relevancy all the time. Let people have their snark, it'll be invalid in a few years when we're refactoring the code base to run in WASM anyway.

If I was raising a kid I'd probably tell little Timmy not to pick on the PHP dev because they might grow up to be your boss, but I probably wouldn't write a Sunday rage post about it.

Not true. Rust fanboys certainly do. They're always ready to tell me how and when I should immediately rewrite all my code into Rust.

Prospective employers often do...

Well what language does this guy use?

fair to say that uncle bob has achieved more success than most people discussing this, and pretty much all of the discussion here is beyond toxic

I had to create an account to ask: what is UBM?