Lambda the Ultimate

I included a link to a freely available draft within the text of the story. Here it is again. I wouldn't have posted the story at all if there wasn't some kind of free version available (hard to have a useful discussion when most of the participants can't read the article under discussion). I've edited the story to try to give the open access link a bit more prominence.

Thanks. Sorry for missing that link. I guess now I have evidence to support my hypothesis that I am too tired and should stop working...

It's hard to say, based on a single comment, just how serious the author was about the "rewrite it from scratch" approach to maintenance. However, if it really does cost less (using a scripting language) to rewrite from scratch instead of tweaking legacy code, then surely that would reduce the cost of "by far the most costly part of software lifecycle". This isn't exactly a brand new idea: Joe Armstrong has previously written about the benefits of (given a sufficiently powerful set of abstractions) writing from scratch even when there are existing solutions that are "almost right". Loui claims that one of the reasons that scripting languages are so useful is that "To script an environment is to be powerfully embedded in that environment." In that sense, I guess you could see Erlang as a "scripting language" for distributed systems.

It'd be nice to see some actual statistics on the cost of rewriting versus modifying for the kind of programs the Loui is talking about. It'd also be nice to see some statistics on the frequency of rewriting verses modification, instead of just an assertion by the author. Hmmm... I guess what I'm asking for is some kind of study of the pragmatics of the "rewrite from scratch" approach to maintenance :-)

Rewriting can be the time to remove accumulated cruft, and take advantage of new opportunities to simplify.

- Paddy.

Are you subtly suggesting that the author might be subject to exagerated enthusiasms ? Or did you have another point I'm not catching ?
Note that some of those benefits are clearly real even if I would take exception to the "flexibility of typelessness" and I'm not sure the increase in amount of casual programming is such a good thing.

Untrained grandmothers shouldn't be writing avionics software. Untrained CEOs shouldn't be implementing corporate information systems in VBA or similar.

But there are many top-of-the-software-stack, highly-application-specific things that might be more productively done by a domain expert with limited programming skills (but given appropriate tools), then by a professional programmer/computer scientist who knows nothing about the domain. Indeed, there are many problem domains that are user-specific; for which it would make no economic sense whatsoever to commission a professional to tackle, but which that user might be able to improve by some level of programming.

Assuming that mission-critical or infrastructure software is not being written by the incompetent (and unfortunately there are many degreed and well-paid programmers who are lousy at their jobs, so credentials and/or employment don't always indicate competence)--why do you think ghat "casual programming" is bad?

While I appreciate your arguments, as you say yourself, even now a lot of "important" programming is being done by persons that aren't really qualified for it. My definition of "important" being here that the program realized have consequences on the live/work of others without a choice given. While I surely hope that for example medical software is held to an higher standard, we know it's not always as good as it should be.
But the main problem today is that even "casual" programming can have bad consequences on others by the mean of the internet, and bad piece of work with vaunted features tend to spread very fast. We've seen that phenomenon already with PHP for instance.

Anyway, I think most "casual" programming while not bad in itself shoud be done in sandboxes or isolated devices. And I would prefer that this casual programming be done with languages that favor a secure style of programmation and enforce a minimum of rules, contrary to most script languages currently (PHP being one of the worse of its kind).

...that lots of sloppy code is written in PHP, or that PHP itself is a sloppy design? Or both?

I'm not sure that PHP in itself is a major problem. While PHP the language is fast and loose in many ways (lots of implicit type conversions, not terribly modular); it the places it is used, it's just "glue" between a webserver and a RDBMS; both of which have security models not easily subverted by poorly-written PHP programs. I've not heard reports of buggy PHP programs causing the runtime to exhibit undefined or exploitable behavior; the language doesn't appear to permit its abstractions from being violated anywhere near as easily as C/C++.

Not that I like PHP (I consider it the open source equivalent to Visual Basic--not a compliment)--but bad code written in PHP is not as risky as bad code written in C.

PHP is secure in the original sense of the word - semantics not impacted by hardware choice - not in the more modern sense. As most of what you care about in systems running PHP is accessible by the PHP process, this latter sense is critical. *Because* it is the VB of the open source community, it has encouraged non-traditional developers (eg., designers) into the server-page community: before PHP, it was all perl/cgi. I'd hope for even more hand-holding by the language and libraries because of this easy-to-use intent!

While no longer as true (but still to a great extent), PHP encourages sloppy code when gluing a web server to the RDMS in terms of security. This can and does break data integrity and confidentiality on the server (injection), and anything on the client (XSS). As a similar problem, there are/were also many cases of exploits to inject malicious files through the modularity mechanisms (dynamic includes, etc). Every year, the security community publishes new analyses to detect this stuff in PHP, and while fun to read, it's hard for me to believe addressing it at the language level wouldn't eliminate most instances of these problems, and without the effort many/most developers already traditionally forgo in running these analyses.

Indeed, we too were taught Pascal. This was a required course for both CS students, and non CS students. The first CS specific course (well known for being the weeder) was then Dylan (Mac campus), a Lisp variant. It strikes me as unfortunate that the emphasis in this debate sounds like the question what is the language we should teach our CS students. I would hope it would be, what are the languages we will teach them. It would seem best to have one of each major discipline represented, perhaps the first one taught could just be chosen chronologically... Lisp? ;)

Linguists recognize something above syntax and semantics, and they call it "pragmatics". Pragmatics has to do with more abstract social and cognitive functions of language: situations, speakers and hearers, discourse, plans and actions, and performance. We are entering an era of comparative programming language study when the issues are higher-level, social, and cognitive too.

I agree also that these types of questions have popped up here a lot. That was one of the reasons I thought that the LtU community might be interested in what Loui had to say.

I don't have any particularly good ideas for addressing the methodological issues myself. I assume that we could probably learn something from the linguists who carry out research in the pragmatics of natural languages, although I'm sure some of the issues arising in the context of programming will be quite different than anything a linguist has to deal with.

It is definitely interesting. By criticizing the approach I wasn't criticizing the LtU-worthiness of the story...

As for pragmatics: the syntax/semantics/pragmatics model, especially if understood hierarchically (see the use of "above" above) is rather problematic and antiquated in linguistics itself, and more so in the philosophy of language. When linguists talk about pragmatics these days they are much more precise than the vague description you quoted above. This is one reason I objected to this terminology. Second, by using this classification one is implicitly suggesting that the issues involved are linguistic (i.e., this is about linguistic pragmatics: the pragmatics of linguistic expressions etc.). But many other, non-linguistic, issues play an important role as well.

I have to admit that I'm fairly ignorant of linguistics, and had never heard of this particular use of the term pragmatics. Thanks for insight into the current status of pragmatics within modern linguistics.

A couple of previous discussions may be of interest #1 (from 2001, where I mention the lack of attention to pragmatics), #2, #3.

Thanks for helping maintain the continuity of the LtU archive!