notes-computer-programming-programmingLanguageDesign-programmingLanguageDesign

Excerpts from Larry Wall's talk

http://www.wall.org/~larry/pm.html

my comments on this:

i haven't read much else of what he's written, but I liked that talk a lot. I was interested to here his views on postmodernism, because I don't know much about it. Also, it definitely revealed a little bit of the spirit behind Perl. Parts of Larry Wall's thought pattern on Perl that I didn't know about before.

I do agree that the talk could cut many parts out and become more readable, though.

Below I've appended some parts of the talk that I think are real gems, although I'm not sure if they'll make as much sense out of context. But hopefully this will support my contention that the talk does contain "valuable insight" into the way that Larry Wall came up with/comes up with Perl.

  1. ``Well, of course not, I replied, ``all these things go together, but some disciplines change at different rates. The reason I'm giving this talk on Wednesday is because I think there's still a big streak of Modernism running through the middle of computer science, and a lot of people are out of touch with their culture. On the other hand, I'm not really out to fight Modernism, since postmodernism includes Modernism as just another valid source of ideas. In fact, Perl contains lots of modern ideas from computer science. Along with all the rest of the ideas in there.

Heidi said, ``You wanna know something really funny. In my IMP class, our class slogan is, 'There's more than one way to do it.

  1. More than that, I combined these cool features in a way that makes sense to me as a postmodern linguist, not in a way that makes sense to the typical Modernistic computer scientist. Recall that the essence of Modernism is to take one cool idea and drive it into the ground. It's not difficult to look at computer languages and see which ones are trying to be modern by driving something into the ground. Think about Lisp, and parentheses. Think about Forth, and stack code. Think about Prolog, and backtracking. Think about Smalltalk, and objects. (Or if you don't want to think about Smalltalk, think about Java, and objects.)

Think about Python, and whitespace. Hi, Guido.

Or think about shell programming, and reductionism. How many times have we heard the mantra that a program should do one thing and do it well?

Well...Perl does one thing, and does it well. What it does well is to integrate all its features into one language. More importantly, it does this without making them all look like each other. Ducts shouldn't look like girders, and girders shouldn't look like ducts. Neither of those should look like water pipes, and it's really important that water pipes not look like sewer pipes. Or smell like sewer pipes. Modernism says that we should make all these things look the same (and preferably invisible). Postmodernism says it's okay for them to stick out, and to look different, because a duct ought to look like a duct, and a sewer pipe ought to look like a sewer pipe, and hammer ought to look like a hammer, and a telephone ought to look like either a telephone, or a Star Trek communicator. Things that are different should look different.

  1. Modernism oversimplifies. Modernism puts the focus squarely on the hammer and the nail.

In contrast, postmodernism puts the focus back onto the carpenter.

  1. Fortunately, I am not Perl. Perl was my servant before it was anyone else's, so I taught Perl to be a better servant than I could ever teach myself to be. Perl is like the perfect butler. Whatever you ask Perl to do, it says ``Very good, sir, or ``Very good, madam. Only occasionally does Perl give you a stiff upper lip, or say ``Tsk, tsk. But if you ask Perl its opinion, it will advise you on matters of taste. ``I'm sorry sir, but bareword 'foo' is not allowed while 'strict subs' is in use.

Contrast that with the Modern idea of how a computer should behave. It's really rather patronizing: ``I'm sorry Dave. I can't allow you to do that.

The trouble with having a submissive servant is that it puts the burden back on you to make the decisions. Come to think of it, that's the problem with having a submissive wife too. My wife is very submissive. She's always saying, ``I submit this problem to you because I don't want to decide it.

  1. Many modern computer languages aspire to be minimalistic. They either succeed in being minimalistic, in which case they're relatively useless, or they don't succeed in being truly minimalistic, in which case you can actually solve real problems with them. A number of languages give lip service to the idea of minimalism, but merely sweep the complexity of the problem under the carpet of the programmer. C is a minimalistic language, but only if you don't count all the libraries that are necessary to use it usefully. C++ is obviously not trying to be minimalistic. Unix is considered by some to be a minimalistic operating system, but the fact of the matter is that if you think of Unix as a programming language, it's far richer than even Perl. Perl is, by and large, a digested and simplified version of Unix. Perl is the Cliff Notes of Unix.

---

"Python's goal is regularity and readability, not succinctness. " -- Paul Prescod

" I and just about every designer of Common Lisp and CLOS has had extreme exposure to the MIT/Stanford style of design. The essence of this style can be captured by the phrase ``the right thing. To such a designer it is important to get all of the following characteristics right:

    Simplicity-the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.
    Correctness-the design must be correct in all observable aspects. Incorrectness is simply not allowed.
    Consistency-the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness.
    Completeness-the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.

I believe most people would agree that these are good characteristics. I will call the use of this philosophy of design the ``MIT approach. Common Lisp (with CLOS) and Scheme represent the MIT approach to design and implementation.

The worse-is-better philosophy is only slightly different:

    Simplicity-the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.
    Correctness-the design must be correct in all observable aspects. It is slightly better to be simple than correct.
    Consistency-the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency.
    Completeness-the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.

Early Unix and C are examples of the use of this school of design, and I will call the use of this design strategy the ``New Jersey approach. I have intentionally caricatured the worse-is-better philosophy to convince you that it is obviously a bad philosophy and that the New Jersey approach is a bad approach. " -- http://www.jwz.org/doc/worse-is-better.html

toread http://dreamsongs.com/10ideas.html


Links and books

Books that are legitimately available (in full form or as a draft) for free online as of this writing as far as i can tell:

Books that are not available for free online as far as i can tell:

Other links:


see also Self:notes-computer-programming, Self:notes-computer-jasper.