| « You Can Still Get Five Tips For Developing Awesome Software! | Exception Handling: A Pilot’s Perspective » |
Two craftsmen make chess sets. Beautiful chess sets. One craftsman uses old style tools: chisels, files, hammers of all sizes. His preferred material is stone; he carefully carves the pawns, the queen, the rooks and the knights with exquisite detail, like his father, and like his father’s father. Another craftsman uses more modern technology to melt and mold metals. He uses fire, molds, and tools that can withstand tremendous heat and pressure. His boards are different colored metals. His pieces are just as exquisite, just as delicate, just as beautiful as the other craftsman.
Whose method is better?
Both craftsmen produce a thing of value, a thing of beauty. Both craftsmen worked hard to create. Ultimately, your purchase decision will be driven by factors beyond their control: individual taste, for example. You may prefer an old-style soapstone chess board. You might like cold, heavy metal in your hand. Your choice has nothing to do with the methods used by the craftsmen and everything to do with what they produced. You only care about the finished product.
Despite the opinions of the long comment at the end of this post, at the end of the day, most people never see or care about programming languages.
The fight over programming languages is similar to one craftsman berating another for his particular chosen medium. And even though the craftsman who uses stone may think it to be a superior medium than using metal, arguing about it is a truly pointless task: both methods create value, both methods ultimately lead to a similar outcome, and both methods are useful.
My problem with debating languages is that it takes time away from doing what’s truly important: creating things of value. Instead of spending time innovating and inventing, we spend time having petty discussions about “this language is better because…” or “PHP sucks; Rails is awesome!” These discussions do little to change anyone’s mind, but they do prevent us from doing productive things like creating new products and inventing new solutions.
For years, the Socorro code included a Python backend and a PHP front end. Even though many of my coworkers detest PHP, these solutions worked together for years, until we moved to a new Python-based web framework last year. That decision wasn’t made because PHP is evil; it was made out of other considerations like developer skill set, the aging out of the PHP framework in use (which would have required a rewrite) and preference. Even with the move to Python for the web framework, Socorro still contains bits of other code from other languages.
Software languages are meant to be used for innovating. They’re meant to be a tool. I’m glad that I have learned multiple languages and several different ways to accomplish the same thing. Every developer should. But the day a developer starts thinking that their chosen language is superior over another is the day they should remember the story of the craftsmen.
Languages don’t matter. What you do with them does.
Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP
Posted on 1/10/2013 at 5:00 am
Jonathan Protzenko (@mozjonathan) wrote at 1/10/2013 7:45 am:
While the little story with the metaphor seems very enlightening and all, I doesn’t actually counter the arguments expressed in the comment on your previous blog post.
There’s a reason people still try to design new programming languages: for a certain class of problems, the language you’re using does make a difference. Try to perform symbolic manipulations on ASTs in C++, and see how easier it becomes in a functional programming languages. Conversely, I wouldn’t write a low-level graphics library in OCaml.
Good languages allow you to express yourself more easily: by bolting high-level concepts in the language, you make the programmer’s life easier, you enhance the safety and the maintainability of your programs. What if the only control structure you could use was goto?
You’re not going to tell your customer “I’ll be using assembly for this project because in the end only the final result matters to you”. And the customer would be foolish to let you do that.
There’s a reason people work on languages: a better language makes a difference. People arguing about PHP vs Rails are not doing anything useful. But that’s called trolling, and we both know it’s not particularly interesting.
Languages *do* matter. And that’s the reason why here at Mozilla we have a project called Rust: because C++ has shown its limits. I don’t think the people in the Rust project think “languages don’t matter”…
Brandon Savage (@brandonsavage) wrote at 1/10/2013 8:58 am:
The people in the Rust project certainly think that languages matter a great deal. At the same time, I see few well utilized languages that were created for the purpose of creating a language itself. Rails, for example, was created for a purpose (and even though Rails is a framework, that’s a debate for another day). Without the products of 37signals, Rails would not be as popular as it is today.
Languages are tools. Developers have to select the right one for the task at hand. The analogy I used falls apart in terms of the fact that the finished product of a chess set varies tremendously based on the medium used to build it, while the 37signals products can be replicated in almost every web language on earth. My analogy was designed to point out that things of value can be created regardless of the language employed; even if we reach the limits of a particular medium we can still create things of value.
It is my hope that people who develop languages can stop fighting about what languages are better and instead focus on why they’re creating a language at all: to make something that will create value and enrich the lives of their users. That’s why we’re software developers, isn’t it?
p3 wrote at 1/10/2013 9:20 am:
I think what the commenter missed in the linked post is, that usually requirements for
… Submit buttons are hard in small screens …
Requirements for programs are not usually expressed as “you need to use this algorithm for search or that language because it can be formally verified”. Usually they are expressed as “I’ll pay you if it doesn’t take longer than X to make this, search takes maximum Y amount of time and you can formally verify this program.” If you can satisfy those requirements, the hardly ever your language choise matters.
Seva Lapsha (@seva_lapsha) wrote at 1/12/2013 1:53 am:
The metaphor with chess is very far from reality.
Consumers care first about cost. Then about speed (of development / maintenance). Then quality (unfortunately). And just in the end aesthetics.
You reverse the vector of priorities. This is why language (tool) might seem less relevant to you.
Let me demonstrate you another analogy. Bow and Arrows vs. AK-47.
Bow will be used just for fun. AK-47 will be used to do the actual work.
Period.
Luke Plant (@spookylukey) wrote at 1/12/2013 6:24 am:
The problem with the analogy is that when you deliver a software project, the deliverable is usually the source code itself, not the “thing” you made with that source code.
Further, the thing you delivered *will* need changing. It will have bugs that need fixing, and the customer will want to make *many* changes. And it will get passed on through many hands for that work to get done.
Your choice of language and “tool” will determine what every future maintainer must use.
So it’s more like you delivered a car, not a chess set, and with the car you included a set of tools that *must* be used to maintain that car. If the customer wants to change the tools for some better ones, they have to re-make the entire car. Under this analogy, the tools that you decide to use matter very much to the customer – or they ought to.
In short, I think your illustration misleads far more than it helps. A delivered software project is not a static asset, like a chess board, it is dynamic, and it is primarily a liability – every line of code is another potential bug, something that will need fixing or maintaining.
I have spent many years maintaining other people’s code, and this is the normal fate of a software engineer, because software spends 90% of its life in maintenance, and often not by the original developer. Software lasts *much* longer than you expect. All coding should be done for the maintainer, which means you should choose tools very carefully indeed.
I have to disagree that price is a primary motivator. For some customers perhaps this is true. For most customers though, especially business customers, value is their primary motivator. There’s a crucial difference between price and value decision-making.
Value-based decisions make a determination based on perceived or actual value. It’s why people will pay more for a Lexus than a Kia, even though both cars are capable of reaching the same highway speed. They perceive the Lexus to be more valuable – far more valuable than the extra features the Lexus includes – and so they pay a premium price.
As for bows vs guns: many people continue to hunt with bows for sport, though I wouldn’t say that taking down a deer with a bow and arrow qualifies as “fake work”. On the other hand, using an AK-47 to take down a deer won’t turn out very well. Different tools for different jobs and different purposes.
In the metaphor of the car that must be repaired with specific tools, when you bought your last car did you ask how the car would be maintained, what tools would be required, or what the cost would be for the computers necessary to diagnose the problems?
I didn’t think so.
The customer cares not HOW an item will be maintained, but they do care what it will cost to maintain. In that you have an argument: choice of tool will affect cost of maintainability.
Still, when bidding most jobs, maintenance cost is not factored in. Rarely do I hear anyone describe maintenance cost as a crucial component in their sales pitch for a new project. Customers care primarily about functionality, and less about those issues until after the fact. Even when I replaced the avionics in my aircraft, the only time maintenance costs came up is when I asked the shop why they were more expensive than other comparable shops. “Because you won’t come back for warranty work” was the answer.
I used the more expensive shop. And I haven’t had warranty work since.
First, my point about the car is that the analogy between normal goods and source code just doesn’t work at all. The same goes for the analogy to aircraft.
When you write software, you are creating a document in a language, and the primary audience of the document is other human beings. To claim that the language of the document doesn’t matter is madness – you can only conclude that if you believe the primary audience is the computer that executes the code, and that even you are unlikely to want to modify it, which is a terrible way to write software.
Second, the fact that customers don’t care about software maintenance costs is to their very great disadvantage, because maintenance costs are massive, and much greater than most customers realise. The biggest questions a customer should be asking are “*who* will be maintaining this”, “what kind of job will they do”, and “how much will it cost”.
Also, the costs of certain types of bugs can be massive, even if the software seems to work most of the time. Not all software with the same list of features is equal.
Basing any decision about tools on the ignorance of customers is an extremely weak argument at best, and completely immoral at worst. It is your job as a software developer to care about the things that you customers cannot care about because they cannot understand them, but will certainly be affected by them in the long term.
Assuming that my tool choice is based on ignorance is an ad hominem. I will not engage with trolls.
Sorry, Brandon, you must have misunderstood. I wasn’t claiming any ignorance on your part – I talked about the “ignorance of customers”. You seemed to be implying that because customers don’t care much about maintenance issues, then it is OK for us to ignore them.
If that isn’t what you were arguing, I am totally lost as to what you were saying. I’m arguing that because maintenance issues are paramount in reality, they should be for developers, and that every “tool” you choose to use is deciding which tools future developers use. So you can’t say choice of language is not an issue – it is *the* issue.
Dean Schulze wrote at 1/13/2013 10:02 pm:
You’ve made a generalization based on your experience with one project.
Read why Rob Pike and colleagues decided that a new language was needed and then think again about whether languages matter. Pike, et. al. disagree with you.
“Go at Google: Language Design in the Service of Software Engineering”
Boro (@KBstream) wrote at 1/14/2013 6:06 am:
Thanks Brandon for the article.
It was a nice read, I enjoyed it very much including the discussion in comments.I agree languages are a tool. I agree that selection of one matters in a sense that it should fit the purpose.
As per argument that a language matters to the customer I must say I disagree, partially of course as it matters on the type of product you do. The clients might actually want you to develop something in language X as then they can use it with other parts written in this language etc. But if we think about the end user they do not care about the language at all and the analogy fits perfect.
It is simple to observe e.g. in the gaming industry that if the users (gamers) were to care about the language they would ‘impose’ the development to be done in something less error prone and in my experience less painful to use than C++.
Otherwise how can you criticize a game written in C++ for crushing. I am not saying that it means that the C++ games have to crush I am just saying that all of them do crush, at least in my experience over the 5 recent years.This is just one example that tools doesn’t matter to the end users, the other could be for example cars, can you find someone who would car this days that a car is made by hand or a machine, or what type of metal was used?
And foremost I wouldn’t call customers ignorant for know knowing anything about languages. First of all they shouldn’t have to know a thing about them and the application they buy should work no matter the language used. And as I mentioned above the sad truth is that even this simple thing is often not being delivered by the developers these days. Finally, I must explain that in my opinion the legacy code, old language and generally businesses mentality (of not caring for improvement of quality until it is a necessity) are to blame and not the developers as there is only that much that you can do with certain tools.
All the best and again thanks for the article.
| « You Can Still Get Five Tips For Developing Awesome Software! | Exception Handling: A Pilot’s Perspective » |