*
programming and human factors
by Jeff Atwood
*
Paul Graham's essay Revenge of the Nerds is a nearly pornographic love letter to Lisp. If you can manage to read all the way to the end, there's an interesting footnote buried at the bottom:
Peter Norvig found that 16 of the 23 patterns in Design Patterns were "invisible or simpler" in Lisp.
He should have opened the essay with that evidence, because it strengthens his conclusion considerably:
In the OO world you hear a good deal about "patterns". When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write.
There's a Wiki entry called Are Design Patterns Missing Language Features? which expands and elaborates on Paul Graham's hypothesis. It even has a handy chart of the classic Gang of Four patterns and the corresponding language features that implement each one. It then degrades into a weird little Wiki-fight, but the saner comments look like this:
Has anyone ever considered that design patterns are the way that programming languages evolve? In the same way as communicative language, commonly used abbreviations ( or patterns ) may become standard. In english words like "won't" and "isn't" are abbreviations, but are more or less considered standard words today. In the same way, 'if-then-else' or 'do-while' could be considered design patterns that have now become standard features in many languages. Perhaps later languages will include many design patterns as standard features.
According to Graham, Lisp is so malleable that design patterns immediately become part of the base language; they are indistinguishable from the original core language constructs. Lisp doesn't need to evolve-- it just instantly becomes. One wonders, then, why Lisp hasn't become sentient and taken over the world by now. As Paul helpfully points out, it could be because we're so stupid:
I also disagree that it is not believable that the vast majority of programmers have been boneheads for 40 years. It seems to me entirely possible.
All kidding aside, I tend to agree on two points:
Using which encapsulate common patterns, and even more (such as Nullable and Generics) on the way.
If anything, Lisp is strong evidence that computer language evolution is quite slow; it's one of the oldest languages on the chart, and we're still adapting features from it.
Posted by Jeff Atwood View blog reactions
« Recursive Page.FindControl Alternative Keyboarding »
To me design patterns are to object-oriented code as algorithms are to functional code. A good pattern tells me how to create a object or a set of objects to accomplish a given task.
Could a Langauge be extended to support patterns better? Sure. A langauge can be also be extended to make certain algorithms easier to use. Perl, python, ruby, etc make certain types of algorithm very easy to use that would require a fair amount of coding in basic, c++, or pascal.
Robert Conley on June 3, 2005 07:45 AMNitpick: it's "Perl", not "PERL". See perldoc -q '"perl" and "Perl"'. :)
Ilmari Vacklin on July 9, 2007 10:16 PMI tend to agree with Paul Graham and Jeff Atwood, in that design patterns are implementations of functionality that should be in the language (implemented in the compiler / interpreter) but that are instead implemented over and over in the programs themselves. The reason these things don't change very quickly is because only certain people have access to make these kinds of changes in most languages. PG argues that in Lisp you have the option to make those changes yourself, and thus the patterns vanish into the language.
The barriers are that (1) most programmers don't see the patterns or know how to implement them better in their chosen language and (2) that they don't even have the option to change them. Now, standardizing a language does have its benefits, like being able to read someone's code without having to know how they've changed their dialect, though I think that is mitigated with good design of the dialect. Again, it requires good design on the part of the programmer and some people don't trust other programmers to be able to do that. So, "closed" languages don't evolve nearly as quickly as they could if we had more community involvement. Basically, whoever put out the language is responsible for integrating the additions to the language. This is one place where English actually has an advantage over most programming languages, you can just make your change in English and as long as everybody understands you (maybe people you talk with often help you develop your own internal dialect) that becomes part of the language.
The question then becomes how can you make a language that is easy to extend. Lots of discussion has been put forth on this topic, but the consensus involves more powerful programming constructs (closures, first class functions, anonymous methods, etc.) along with some mechanism for extension (macros or meta programming). Giving the programmer these tools at least gives them the option of extending the language, though not all programmers are capable (or want to deal with) the challenges of extending their own language.
One idea to overcome this challenge is to create a senior position that is in charge of extending the language for your project, and everybody else uses the dialect of the language that is produced. At least then the programmers can concentrate on getting the program done using the abstractions that someone else is making for them, and they don't have to know how the underline mechanisms of language extension work. Imagine if there was someone on your team that you could go to in order to request changes to your language that would make things easier, or that would design domain specific languages specific to your problem space so that you can more easily create the program. Doesn't that sound more productive?
Maybe this is an educational problem in that we need to train programmers better so that they understand the concepts involved in producing their own language, allowing them to extend the language of their choosing easily.
Joshua Volz on January 1, 2008 11:13 PMThis is a simplification.
It is not only about _design_ patterns, but also about _thinking_ patterns. And with thinking patterns, being humans, we tend to strive for simplicity, or beauty (however you denote it) - but also for "powerful" constructs. It will ultimately be why perl will fall away slowly (slow because languages never die quickly)
This thinking pattern reason is why OOP was such a huge success (and I refer to OOP more in the sense of smalltalk or even Obj-C, than in the C++ tradition, although even there it had big benefits despite how many people may hate the complexity of C++)
The reason Lisp never dominated the world was because Lisp never admits that it actually has warts. Lisp may win people when most people use C (like, 100 years ago), but now that we have ruby and python, which evolve seemingly a LOT faster than Lisp does (nevermind that splitted communities are bad for a language too), continuing past strategies in the lisp community seems like a loss-loss situation.
I dont think lisp will gain many new followers since the level of competition has raised a lot the last 10 years.
she on January 2, 2008 01:00 AMMy original take on Design Patterns, when I read the first GoF book, was that they solved problems created by the programming language (C++), not the customer. The list of Design Patterns is a list of things that are awkward to do in C++ and many Object Oriented programming languages.
That this was not obvious to everybody and is just now being discovered by many people is very depressing.
JFred on January 2, 2008 01:01 AMHi she!
I don't think that Python and Ruby are really able to evolve that fast to catch up with Lisp. It seems to me, that they will tend towards Lisp but will never have the power and flexibility of Lisp.
There is some other problem with Lisp why it failed, but not that you say.
Victor on January 2, 2008 05:29 AM| Content (c) 2008 Jeff Atwood. Logo image used with permission of the author. (c) 1993 Steven C. McConnell. All Rights Reserved. |
Subscribe in a reader
Subscribe via email