Lambda the Ultimate

I don't care what kind of fridge I use. If I go buy a fridge, I will probably look at a few features and pick something that I think is reasonably priced. Heck, I'll probably let myself be influenced by what the guy in the store says, and even worse, I am likely to let the looks of the thing weight heavily.

How I buy fridges is how 95% of people buy software. And what 95% of people do, becomes the rule for everyone's business model. It decides how software is produced. Much like I won't see how the fridge has faults that will fail in the next 3 years, noone cares how often exactly a piece of software crashes, how clumsy its UI is in practise, or how much it eats into your virtual memory.

The fact that the vast majority of people doesn't have time to invest into understanding things outside their primary scope isn't going to change, infact I predict it will get worse.

So the only way here to improve software quality is to produce tools that under the same economic pressure of writing code fast without much work into making it "lean", will produce higher quality product.

Programming languages can help here, but only in a very limited way. Yes you can improve stability by going from unsafe typing to safe typing, but that is only a small step. The problems Wirth is talking about will not change by switching languages, a word processor with 10 million features isn't going to be any less bloated in Haskell than it will be in C++ (infact, it will probably be more bloated in Haskell, because its implementation is less "lean").

Is there a language or system that will effectively counter the degradation normally associated with throwing millions of lines of unorganized code for new features at a code base? I don't think so. Most programming language features we are fond of only help counter degradation when coupled with design (or refactoring), which is something you can't expect given the reality of the world.

The paper makes good points about the realities of programming with real-world constraints. But I think the negativeness about languages is incorrect, and the author didn't really provide any support for it. He seems to be thinking of particular examples he's seen, and perhaps he's only thinking of general-purpose languages, but there are plenty of counterexamples where DSLs have succeeded in solving real problems very well.

The main real objection to language-based solutions is that designing in terms of languages isn't familiar to the average programmer, so solutions that take that approach may be thought "too advanced" and thus considered subject to maintenance risks.

I find that thinking in terms of language design can be a very successful strategy for attacking real-world problems. Even if the end result isn't actually implemented as a language, sketching out the design as though it were a language can make a big difference. That's partly because it's possible to define a language so clearly and formally, whereas many other design methodologies and their tools (e.g. OO & UML) don't lend themselves to this nearly as well.

Many of the ways in which XML is used today demonstrate how much real systems need DSLs. I know of various big companies that use real DSLs (not XML) internally to good effect. In short, I think that languages are a practicable solution, that can lead to jewels in practice, and it's only the lack of familiarity with the approach that inhibits this from being more widely recognized. They're often used in more advanced cases, as many previous articles here on LtU have shown.

The fridge analogy shows a problem with picking concrete, real world examples and then trying to apply them to how various computer realities work.

"Much like I won't see how the fridge has faults that will fail in the next 3 years, noone cares how often exactly a piece of software crashes, how clumsy its UI is in practise, or how much it eats into your virtual memory."

the fridge faults are not enumerated, the software faults are. The software faults are of a nature that while not apparent in the showroom will become apparent when it is taken home. These software faults are not faults that will cause the software to fail in three years, it is instead a fault that make the software irritating and difficult to use now. Software faults which make software fail in 3 years are, dependencies on things outside the software which are likely to be updated in 3 years (OS differences generally), new formats for which the software was not built to interact with becoming standard, and other similar occurences.

The software faults enumerated however would be more analogous to a fridge door popping open at inopportune times, the light going out more often than it should, or the freezer compartment of the fridge overheating while the rest of the fridge works fine. Faults which I submit would cause the 95% of people who buy fridges to do either of the following:
1. return the fridge for a refund
2. buy a new fridge before the three years are up, and not of the brand bought before
3. buy a new fridge when the old one finally kicks it, never buy that brand again though.

The only thing that I think might cause people to not shift brands of fridges would be if they had to totally relearn how to open the fridge doors and how to put food in the new fridge.

I'm convinced that the fridge analogy is a poor one because all analogies between a computer and non-computer devices will be poor ones.

XML can be used for DSL creation, and it need not be an ugly incoherent mess, the problem is that just as the skills required for the design of good DSLs there are skills needed for the design of good XML dialects, these are not necessarily the same.