Lambda the Ultimate

This guy pretty much explicitly says that it would be too dangerous to let Java users have anything so powerful.

Aside from my previously stated reservations about the meaning of "powerful" in this context, I think this might be a good place to discuss another "sociolinguistic" aspect of PLs: standardization vs. expressiveness.

Among human languages, there is the quite familiar distinction of "standard" and "colloquial" language, and I should point out that there is nothing inherently different about the two structurally.

I mean by this that if a linguist were given data from a previously unknown language, there would be no way to tell if it was a standard or colloquial variety from the structure alone.

"Standard" is therefore purely a matter of social intent.

It is not uncommon to hear people say that colloquial varieties of language are "more expressive". People can make up new words, make references to in-jokes, mix metaphors, use local slang, etc. and this gives them the greatest freedom of expression.

But if I want to write a book, or deliver a speech at an international conference, I want to use a standard so that everyone who hears me has the greatest chance of understanding me. In fact, we so take this for granted that we often switch unconsciously between the two modes of communication.

So my question is why do so many expect that a language intended as a standard (to be used by large groups of programmers possibly dispersed in time and space) should have the same features as a language intended for hacking among friends?

Do we say that slang is "too powerful" to be used by the "herd" who use standard language? No, we recognize that it is a bad idea to confuse people by using obscure local slang when we want to communicate over a wide area.

So why don't we see that your "powerful macro" might turn your code into a different PL that I don't understand?

Good question. Seems to me most programmers don't make this distinction between languages. You can argue that they are correct in not doing so: many languages that were aimed for large groups aren't the ones actually used by most large groups. Comapre Ada and C, for example.

But let's follow you analgoy to its conclusion. If, indeed, macros create dialects, but people can unconsciously move back to the standard language when writing for a large audience, then there shouldn't be a problem with having macros in the language. Programmers would use them were appropriate.

Having said that, I agree that heavy use of macros create dialects (we call them DSELs around here usually, and talk about stratified design). Some think this is a great software design approach ("First design a language, then write the system"), others are cautious thinking this may result in systems that are hard to maintain. Perhaps the answer is project specific, and related to other engineering factors? This sort of questions often are.

To answer this, I will have to answer my own rhetorical question ("why do we treat HLs and PLs differently?") and show why the analogy breaks down.

With HLs we take it for granted (we don't even think about it usually) that their primary purpose is social: to communicate and form social bonds. Our code-switching between standard and colloquial happens because we have a keen social "instinct" about the appropriate social uses of each form.

With PLs, we tend to focus on their purposes as command languages to "get the computer to do what we want" (hence, I believe the fixation on "power").

It is also much harder to tell when you are writing code who your audience will be. Today's hacked-together script may be tomorrow's next open-source sensation. That COBOL routine that was supposed to be "temporary" is still kicking around.

we call them DSELs around here usually E for embedded? Search didn't help me out too much there. ;-)

Perhaps the answer is project specific, and related to other engineering factors?

A good rule of thumb for almost anything. ;-)

However, as we all know around here, designing a good language is a non-trivial activity. What makes the macro fan think they can just whip one off and it will be in general better than using the host language directly?

(I just noticed I've been using lots of slang expressions in this thread, e.g. "whip one off"; I hope my "macro language" isn't obfuscating my meaning for anyone. ;-) )

I think you're right, at least in many PL communities. Perhaps the real debate is to figure out what exactly "readable code" means. ;-)

In programming languages the primary audience is rarely other programmers but the machine, at least in practice. Therefore "slang" can evolve unhindered and powerful language features become "dangerous" because the "slang" remains understandable only to the original programmer, effectively hindering team efforts and making maintenance a nightmare. The obvious solution is to ban the "dangerous" features to limit how the language can evolve. It would seem a better solution would be to let the team evolve their own domain specific dialect, but in a social context (maybe using code reviews?) so that the whole team understands the alterations. Then one should theoretically achieve both power and understanding.

That's not quite true. To take just one example, modern standard French "cheval" (horse) descends from the Latin slang "cavallus" rather than from the standard Latin "equus".

In programming languages the primary audience is rarely other programmers but the machine, at least in practice

I don't think I agree with that. (See elsewhere in this thread)

let the team evolve their own domain specific dialect

This happens in a more limited way anyway, but nonetheless it can make bringing new people onto the team quite difficult.

I should make clear that I'm not as concerned with the creation of an orthogonal sub-language. (This isn't that different from creating new objects or functions) I'm more worried about those changes to the language that alter the semantics of normal expressions in the language. And these are precisely the kinds of changes that you need macros to accomplish.

In such cases, someone who knows the standard is going to be in for a shock when something completely different happens than expected.

Dialect and slang are different things. (Ask A Linguist - what an idea!)

someone who knows the standard is going to be in for a shock
I've experienced something similar to this in Smalltalk a couple of times :-(
We ripped out all the clever stuff and returned to something more vanilla - for compatibility with version upgrades, 3rd party tools, new hires knowledge, ... but mostly, in these cases, because the changes were about implementation cleverness rather than utility.
(My head's starting to go pointy...)

As you can see from the responses, even linguists don't completely agree what the distinction is.

do these approaches make up various C++ slangs?

In linguistics, creating a deterministic, general procedure for deciding if some particular language system is a dialect or a language has the same formal status as a procedure for deciding the halting problem in computer science.

I think this question falls within the bounds of this theorem. ;-)

C++ slangs
Thanks for the help.

This happens with HLs as well, actually, doesn't it? Think about the enormous amount of research (and commercial effort) that goes into deciphering old "texts" (hand-writing, colloquialisms, dis-used languages) that no one expected to last or matter. IANAL (that's "linguist", not "lawyer"), but I believe that for anthropologists and linguists, these "private" or "personal" artifacts are often extremely important.

This is a good point. In this particular case, I tend to feel that anyone who believes that just keeping macros out of Java will make all code readable (and maintainable) by all programmers is really fooling himself.

As we've discussed here before, there's a very deep connection between API design and language design, and the development of a medium-to-large project in Java is nothing if not an exercise in API design. Therefore, a programmer new to a project really does have to learn one or more DSLs already, often at a very high level of conceptual sophistication.

With that in mind, I really feel that preventing the user from using macros to reduce straightforward code duplication and boilerplate really gains nothing at all... In fact, one could argue that it's worse, since while there is less project-specific language for the programmer to learn, it's made up for by forcing you to learn more project-specific idiom. I can give plenty of examples, if you'd like...

That's not quite true. To take just one example, modern standard French "cheval" (horse) descends from the Latin slang "cavallus" rather than from the standard Latin "equus".

As usual I should have been more specific. In this context with "core language" I meant the structural components of the language (syntax, morphology and phonology) that evolve significantly slower than the vocabulary (the only reference I could find for this now is unfortunately in Finnish but I believe "it's a well known fact"). Your example is one of alteration to the vocabulary. Similarily most programming languages allow you to define your own functions and data-types, but not to change the semantics of normal expressions in the language.

My idea was that if it would be possible to use similar mechanisms to regulate the use of macros as the one used to regulate alterations to natural languages. Anyone can add a word, but only under very, very special circumstances could someone add a new phoneme. Ergo for function and "core semantic". As you said it is more a question of what "readable code" is. What I tried to say was that it might be better to limit the use of certain language features on a project to project basis than by leaving the features out of the language. To keep the semantics altering features under control the social mechanisms could be useful, but it was merely a suggestion, one might employ rigid coding standards just as well (as in "thy shalt not use macros").

In programming languages the primary audience is rarely other programmers but the machine, at least in practice

I don't think I agree with that. (See elsewhere in this thread)

Sorry, meant to say "in programming the primary...". Everywhere I have worked the saying "If it ain't broke don't fix it" applied. As long as a program worked, nobody cared exactly how. I interpret this as "It's more important that the machine understands it than that a human does". In practice it cannot be the other way around because then we would be satisfied to produce a requirements document and ignore the actual program, since the requirements document is usually easier to understand to a person than the program code. I believe this is approximately what you meant by "command language". Of course a good program is understandable to people as well and therefore programming language design is primarily done with people in mind rather than machines.

Sorry if my joke misfired there Isaac.

What I meant was two things.

First, like a lot of words, "dialect" and "slang" have a lot of uses that that overlap, and there is no surefire way to disentangle them without making an ad hoc distinction.

Similarly, the question of when two dialects or languages diverge is equally impossible to disentangle without ad-hockery.

So in response to your question about C++ "slangs", you could argue it either way.

Or perhaps I misunderstood your intent?

I still see a distinction. It reasonable to assume that no one is supposed to see my private papers. Now, after I'm gone, I have no control over what people do with them, so they may use them for their own purposes, but they are on their own.

If I build a program for use by others, it is unreasonable to assume that no one will ever read my code.

I don't know that anyone would support the simple equation "no macros = readability".

it's made up for by forcing you to learn more project-specific idiom

I'm not sure how that is worse. Any new work environment will require some learning curve. Any programming project will have some "idiom" to learn (domain issues, libraries, coding standards, etc.)

So long as these have the property that in formal language you would call "monotonic with respect to the base language", this is only reasonable.

What that means in plainer language is that "what's added won't change what's already there".

If I make you learn a new library, it builds on what you know already. If I have a macro that changes what "new" does, I'm changing the rules of the game.

I can give plenty of examples, if you'd like...

Oh, I've seen 'em. ;-)

If you are saying this is a common attitude, I agree.

I meant the structural components of the language (syntax, morphology and phonology) that evolve significantly slower

Not to get too off topic, but suffice it to say that, you're right these things seem to change at different rate for different features. They all change though, and possibly because of "slang".

Well, certainly I'd object to some uses of macros, the same way I strenuously object to some uses of operator overloading... But that's what coding standards are for. I really support using macros to reduce code duplication, because in my experience there's a huge gain in maintainability... If, in my project, I have to write five methods with the exact same ugly nested for loop, with one line of code different in the inner loop (I have actually seen this, and it really was the right way to do it), I really believe that a macro would, in the long run, help a lot, and lower the learning curve for new programmers. It's a lot easier than saying "See how all of these methods look the same... Memorize that pattern, you'll be writing it again." Or worse, saying sometime down the road, "See how yours looked a bit differnt? That's why all of our users are pissed off..."

In situations like this, my teams have seriously considered using a third-party pre-processor or macro system. But that's much worse than a built-in macro system, because it's unsacntioned, non-standard, and new programmers not only have to learn the macros, they have to learn the whole system (which, since Java doesn't have one, may be a new idea to them).

Note that for many of these applications, macros are really just replacing missing (IMHO) higher-order features of Java. If Java had higher-order anonymous functions, it would be much easier to write my ugly for loop once and drop in the inner line of code as needed. Java's anonymous inner class implementation and syntax currently makes this far too cumbersome for frequent use, and again, it's one more project-specific idiom that new programmers will have to learn.

So I guess, really, I'm arguing for as many abstraction-building tools as possible. I don't believe that building more abstractions is ever the wrong move, and as I've said before, disallowing the use of macros to do it just moves the abstraction into the programmer's heads, where it's duplicated, distributed, and much more likely to decay... ;)

For the record, I cannot imagine myself ever being convinced to redefine the "new" operator in Java.

I, too, disagree with the "primacy" of the computer as audience for programming. I think the computer and other programmers are equally important audiences, and if either audience can't make sense of the program, is is broken, and should be fixed. In some circumstance, making the machine understand it may have higher priority, but if your project goes that way for long enough, you're going to be in trouble. Until the program is clean, well-designed and well-understood as well as executable and correct, the programmer's work is not finished. Down-time can be spent cleaning up, re-writing ugly bits, writing more tests, etc.

I think this is much more than just vanity, or make-work ("We've built this hot-rod, now let's tinker with it... Haven't gapped those plugs in about three hours..."). If the code is working but not well-understood, the team will be almost certainly be less responsive when someone wants that functionality to change. Maybe this is no big deal for projects that are written to a spec, used once and then thrown away (and where the programmer's have final say over the interpretation of the spec... that'll be the day), but frankly, I've never seen a project like that. Besides, that's why there's perl. :P

Hmmm. My experience with those things is that 99% of the time a bit (or a lot ;-) ) of refactoring gets rid of this kind of redundancy. If you are refactoring as you go, usually only a bit.

I guess I'm opposed to "swatting a fly with a baseball bat", which is what macros seem to be for some of these problems.

The design is pretty clear -- very flat, weak language where all the power comes from gluing together Sun APIs. I think the great indirection of Sun is making people think Java is a universal language, when it's really a glue language.

The alterations to the language comes from the speakers of it, not from some central steering committee. A committee might accept certain proficient changes and add them to the standard(ized) language but they can in no way control the colloquial varieties. If this method used in HLs is to be adapted to PLs, the PL must allow variation to occur, in this case macros in Java. Changing the meaning of the "new"-keyword is kind of similar to dramatic changes such as changing function of the determiner "the" to be a preposition meaning "on top of". These kinds of changes are naturally regulated, they are indeed possible but very rare. If the primary audience for PLs would indeed be people (in practice) there would be no need to limit the power of abstraction, all language features would be used only when they make the solution more readable to people.

A more general point: Even if we agree that macros can create dialects, I think it is reasonable to assume that one or two macros are not going to make the code that much harder to read, or cause the language community to split.

Languages cannot ensure code is readable, they should provide tools that support writing readable code. Paternalism in language design simply does not work.

The "re" in "refactoring" tends to mislead people into thinking it means making cosmetic changes to already working code, in order to satisfy some programmer's nebulous desire for elegance. More usually in practice (good practice, anyway) it means "factoring as you go along, based on feedback from the implementation process" as opposed to "factoring everything up front, before you start work on implementing anything at all".

Refactoring also needs to be scoped: since it's essentially a way of reaping the immediate benefits of experience, it only really makes sense to refactor code that you yourself (or you and your immediate peers) have written fairly recently or are working on right now. I don't think anybody really thinks that gratuitously modifying large swathes of an existing codebase long after the fact is a good idea...

I think there is an interesting difference between the macro-building approach to abstracting common idioms and the (re-)factoring approach. As I've mostly programmed in languages without substantial support for macros, I've always favoured the latter by default: if you find yourself typing something over and over again, factor it out. But I've never seen macros done well (MFC doesn't count), so I'm missing part of the picture.

It probably makes a difference whether your language supports the inlining of functions, too, since a "call" to an inlined function is, like a macro, an instruction to the compiler/interpreter to "insert some code here", rather than an instruction to the run-time system to make a full function call.

I imagine that the full power of macros comes from their ability to be used as highly parameterisable code templates. They're probably less useful in a language that lets you write highly parameterisable code.

That's part of it, for sure. That's why I always foud the Ada choice (i.e., no macros, support for generics/tempates) better than the Java choice (no macros, and no genericity). But I am hopeful about the future Java generics.

My sense of Ada is that it very much occupies the same PL "niche" as Java: standardized, large-scale development. (You'll be happy to know Ehud that your frequent mention of it has inspired me to learn more ;-) )

I think it is reasonable to assume that one or two macros are not going to make the code that much harder to read

Not necessarily of course. But if the difference is really so trivial, why would someone argue that a language needs macros? Java (and I'm sure Ada and others) has ample abstraction mechanisms to deal with most of these kinds of problems.

The discipline it takes to ensure that macros don't harm readability is the same that is required to find ways to use the language better to avoid the need for macros. If someone hasn't bothered with the latter, do you think they will with the former? ;-)

Paternalism in language design simply does not work.

Of course not. But populism doesn't necessarily work either. ;-) I don't think it is reasonable to expect language designers and implementers to run to add macros to their language just because people have decided it is the silver bullet for their problem.

And in a language whose mission involves providing a stable standard for large-scale development, it might even undermine the confidence of industry if they do so.

Not to mention the drain on the maintenance efforts for the language, since getting macros right is, I'm sure, harder than it looks.

I'm actually plugging test-driven development here. (sneaky I know ;-))

My experience is that using a few simple, easy-to-understand OO techniques, I can get around most redundancies of the kind we were talking about, if you use them as you build the code.

Obviously retrofitting a large body of code would be more difficult, but, assuming your were making localize improvements, you could probably make a localized abstraction to prevent having new redundancies in the code.

I certainly would want to at least try to deal with the problem this way before calling in the macros.

in Ada not all types belong to the same hierarchy
Looking back (without the pressure to evangalize OO) it seems that we should think of Ada and Oberon-2 as hybrid object-procedural languages.

If you are arguing for the "evolutionary design" of PLs, I have no problem with this. But evolution works by ruthlessly applying a fitness function to each iteration: the unfit must die so that the fit may prevail.

These kinds of changes are naturally regulated, they are indeed possible but very rare.

In the HL example, certain things may not happen frequently, and one can assume there is some "fitness function" that works to retard unnecessary changes, but without knowing what that mechanism is, we can't assume that PLs "naturally" have this property too.

Also, in spite of all human efforts to the contrary, in a few hundred years of very slow change, the language will become unintelligible to us. If you speed that process up by letting the "power" enthusiasts loose with macros, you probably only need 100 days. ;-)

Macros Make Me Mad

macros vs. blocks

choosing a language for your audience or macros vs syntax?

I agree, and what I meant was that there is no such function for PLs, at least not by default. Therefore that function needs to be provided somehow, for instance using peer reviews. The relevancy of my whole argument was that there exists mechanisms in HLs that tame dangerous alterations, and that these methods work to preserve understandability fairly well. HLs manage to harness mutation without becoming unintelligible. Therefore it would seem to be possible for PLs as well if the right mechanisms are in place. So if one would want a very productive team he/she might want to pick a language that has macros and strive to use them right. This path is obviously riskier than playing safe and picking a language without macros, but it should not be impossible.

Yes and no... The key word here is obviously "gratuitously"...

Suppose you have a team of programmers working on a project, and everybody knows module X was poorly designed and has had new features hacked in or bolted on in less-than-ideal (but expedient and maybe necessary) ways. No one has touched module X in quite some time. Suppose further that this team expects that within six months their users are going to want more new features in module X, and that there's currently a couple of programmers with nothing incredibly pressing to do.

At some point, taking the time to revisit the design and implementation of module X, at least to make sure it's well-understooed, and if possible to improve it, becomes higher priority than adding some low-priority feature or even in some cases fixing an obscure bug.

In this case, we're talking about code that no one is immediately working on, that may have nothing wrong with it functionally, but that has reached the end of its life in terms of extensibility or maintainability. If this code is well-tested and well-typed (sorry, cheap shot) then programmers can revisit it with confidence. If not, I'd say those are problems of their own...

There are other reasons, too, but I guess I'll get into hot water with many of you... Many programmers (myself included) are more productive and far more motivated when we feel good about our product, and particularly when we know that the way we feel about the code is taken seriously by management. I have left jobs before because I felt that the team could take no pride in its work, and was not encouraged to try.

It is, in some ways, like cleaning house. Many of us make the bed each morning and do our dishes not because our mothers (or partners) tell us to, but because we are happier, more productive people when our space is tidy.

Except that in Java classes are closed, so while all objects may be instances of Object, I can't use that to add common functionality to all my classes, nor can I (sadly) tell the type-checker that String should be considered an instance of my new interface Printable with such-and-such an implementation.

There are ways around these problems, of course, but they're not very satisfying.

I doubt it. For a language like Java, I'd say it looks almost impossible. ;)

The design is pretty clear -- very flat, weak language where all the power comes from gluing together Sun APIs. I think the great indirection of Sun is making people think Java is a universal language, when it's really a glue language.

I think this is overly harsh. Even if I grant the characterization of Java as a glue language, I object to the pejorative tone. If Java is a glue language, this is not to prevent programmers from managing complexity, it's the model that Java uses to help programmers manage complexity. Then the problem of designing your program becomes primarily about designing and specifying the different pieces that get glued together, and then writing the glue code on each side of each membrane. In a sense, one might say that this is what OO design patterns are all about.

Perhaps you just don't like that model for designing programs, but I really don't think that Java is "merely" a glue language in any sense stronger than that in which all languages are "merely" glue languages for their built-in primitives and standard libraries. Haskell's just glue for stringing together IO actions, after all...

Yes, but in fact these mechanisms do exist "by default" for Pls, and they're much the mechanisms that operate for HLs. In fact, this whole conversation is an example of one such mechanism. Here we have a group of people gathered to discuss exactly this issue: conservatism versus deviation as related to expressiveness, diversity and the opression of minority voices.

Colloquialisms and individual idiosyncracies prevail in personal or very-small group software projects, and various large social groups (in the normal, literal sense of "social") have dialects with their own norms and deviations (Microsoft, for example, is famous for its coding standards). There is, to some degree, a "lowest common denominator" of many programming languages, that every reader might understand, but just as not all writers of English agree on stylistic and grammatical points, not all writers of C++ agree on just what "standard" formatting and usage is. We have style guides for HLs and we have sylte guides for PLs; even there, good old-fashioned social authority rules (what the Chicago Manual of Style says matters more than what I say, what Scott Meyers says also matters more than what I say).

...At some point, taking the time to revisit the design and implementation of module X, at least to make sure it's well-understooed, and if possible to improve it, becomes higher priority than adding some low-priority feature or even in some cases fixing an obscure bug.

This may on the other hand be a good time to do a complete rewrite, factoring in what you know about current and future requirements that the original coders didn't (and couldn't have been expected to) know. Sometimes these things can be fixed by changing a little, pervasively; sometimes they can't.

I think that either way this is a different kind of operation to "refactoring" as I understand it, primarily because the kind of information you're trying to take into account is more of the order of a total knowledge of the system and its defects, rather than an immediate sense that what you've been coding for the past couple of hours has some funny-smelling bits that could do with a quick shuffle around.

The rescue of very large systems is possibly another matter altogether - I wouldn't know, but I'd guess that you'd need a lot more than Martin Fowler's Portable Refactoring Kit-Bag to tackle that kind of job...

Where is the pejorative tone? If we're calling Java a "language for the masses," then stating it's a glue language, which derives power not from its expressiveness but its great libraries, doesn't sound so bad.

I'm talking as a UI person would speak. You throttle power to gain usability. Programming languages are AFAIK a subset of UIs, and I think a lot can be transferred between languages and UIs.

If Java is a glue language, this is not to prevent programmers from managing complexity, it's the model that Java uses to help programmers manage complexity.

From Kernighan, I hear the Unix philosophy is about having small tools that perform their functions well. This can also mean that the tools do not let one easily make big monolithic programs of doom; this is an interesting engineering perspective.

Haskell's just glue for stringing together IO actions, after all...

I've only read some tutorials on Haskell. I haven't heard people call Haskell's IO library enormous, unlike Java's, though I could be wrong.

Maybe I just misunderstood... I guess I took the contrast between "glue languages" and "universal languages" as implying a value dichotomy with the latter on top. I guess I'd argue that Java is, if anything, a glue-oriented universal language, where its emphasis on API-based programming and design isn't an alternative to general-purposeness, but rather a form of it.

Perhaps the bias that I've discovered is my own... :) I guess in making my inference, I projected my own feeling that "more powerful must be better" onto you!

I'd like to add a small different angle to this [macro] discussion. IANAL (L=Linguist), but it seems to me the linguistic idea of "productivity" might be helpful in sorting out when macros make sense or not. In the rest of this message, I'll use "productive" only in the linguistic sense.

My feeble understanding: linguistic productivity is the ability to produce new language. We could divide "new language" into perhaps two piles, new syntax (forms) and new semantics (meanings). We all do the former, all the time; e.g. when you "verb" a noun (as I've just done), and we do the latter when we make up new nouns, or new meanings for old nouns.

What does it take for a language to be productive (in the linguistic sense)? Semantic extension (new nouns) comes from procedural definition. Semantic extension (new meanings for old nouns) comes from overloading. Syntactic extension (new forms) comes from ... macros.

I opine that there are *no* productive PLs that do not have both ungelded macros and higher-order functions.

A full macro facility in Java would defeat the purpose of the language, IMHO. Statically strongly-typed imperative languages are not *supposed* to be productive; the facilities for creating higher-order abstractions are intentionally limited, to make life for the code-writer and code-reader less complex.

Depending on circumstances, "less complex" may or may not equate to "easier."

Ehud: Your statement "Paternalistic design doesn't work" confuses me. I think I understand your intent, but doesn't this contradict the real benefits of Ada (a paternalistic design if there ever was one)?

Similarly, if "industrial languages" (e.g. Ada, Java) are non-productive, doesn't that imply that paternalistic design (you can't handle this power, so I won't give it to you) *does* work, at least for the intended users of these languages?

??

Normally, the concept of linguistic productivity refers to the ability to produce and understand a sentence that you have never heard before. For example, until now I have never said "My uncle is a rutabaga", but I had no problem making it, and you had no problem understanding what it means (though you may wonder if I need professional help. ;-))

As Oskar pointed out earlier in this thread, though lexical items ("words and fixed expressions") do and must change all the time to meet human needs, the fundamental structures change slowly (relatively speaking), tend not to change that much for a given individual, and generally change in spite of efforts to prevent them rather than out of need.

The only need that is served by those changes might be the need of new groups (generations, social classes, etc.) to differentiate themselves through speech. (Parallels in PLS?)

doesn't that imply that paternalistic design (you can't handle this power, so I won't give it to you) *does* work

I think there is a fundamental difference between "you can't handle this tool, so I won't give it to you" and "I'm going to add some safety features to this tool so that it is harder to hurt yourself with it".

All of us, no matter how proficient we are with a tool, sometimes make mistakes, and if I'm using a power saw, I'm going to appreciate it if they have added a guard to it to make it harder for me to saw my fingers off.

I'm also going to appreciate it when the tools of other people I'm working with make it harder for them to hurt me by accident. (If they want to hurt me on purpose, that is a different matter ;-) )

http://www.ai.mit.edu/~jrb/jse/