Slashdot Mirror
'Design Patterns' Receives ACM SIGPLAN Award
bth writes "ACM's Special Interest Group on Programming Languages (SIGPLAN) recently awarded the 2005 Programming Languages Achievement Award to Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (known as the 'Gang of Four') for their creation of 'Design Patterns' (the computer science book and the subfield at the intersection of programming languages and software engineering). The annual award recognizes an individual (or individuals) who has (have) made a significant and lasting contribution to the field of programming languages."
As mentioned by Paul Graham, in his essay "Revenge of the Nerds", Peter Norvig found that 16 of the 23 patterns in Design Patterns were "invisible or simpler" in Lisp.
http://www.thebricktestament.com/the_law/when_to_
I've worked with a couple of folks who swore by this book, but I never really heard much from them about why. Is it about good algorithms? Or larger design issues (such as)?
Or is it more about just giving programmers a common vocabulary with which to discuss the way they bulid software?
Is it good reading for an amatuer programmer, or more as an advanced topic?
Its good to see these people being recognized for contributing such a useful concept to object oriented programmers, and its wholly appropriate they should recieve such an award from a group focused on exploring "implementation and efficient use" of programming languages. Although they have their critics, Design patterns have surely helped many programmers greatly in this manner, especially in languages such as java.
Business Voyeur
Why are you giving the credit to Paul Graham?
He isn't.
The AACS key is NOT 0xF606EEFD628B1CA427BEA93A9CA9773F
In my software engineering studies, virtually all of my teachers swear by the design patterns of the Gang of Four book for all object-oriented programming projects.
Sorry, there are no silver bullets. Here's a "lifetime acheivement award, anyway".
This site is one of the best.
hilarious
Oh my
The quite possibly most useless book in the history of computer science gets an award. Somehow I am not that surprised, considering that everybody hails it as the end all of object oriented design and everything.
To be honest, modern computer science curriculum seems to be wasting a lot of bright young potential on buzzwords. Patterns, paradigms, bleh. People somehow manage to get masters degrees in CS from Berkeley without even knowing what "turing complete", "Karnaugh map", "Rice's theorem", "Goedel's completeness theorem", "planar graph", "functional language", "church-turing thesis" are. But you ask them about a singleton, model-view controller or Java's security model in reflection and they're the fucking expert.
Well that's barely computer science, that's just OO banging. Just because it uses paradigms and object oriented terms doesn't make it anything other than advanced code banging.
It surely deserves this award. However, after 15 years doing software development, I now consider two other books even more important even thought they are not quite as information-full as the design patterns book. They are: "Agile Software Development" by Alistair Cockburn and "Software Craftsmanship" by Pete McBreen. I have a full list of books, web sites and tools that I recommend at my Software Resources page.
Helping with organizational effectiveness is our job.
Congratulations to Erich, Richard, Ralph, and John. Great guys who made a contribution for the ages.
Common sense for the rest of us. It was a good idiot filter back in the day...
Congratulations to the GoF. Their observations of patterns of systems and behavior are well-described and well-cataloged in their book. I only wish the concepts and materials were conveyed better when taught.
Most of the time people start with the attitude "Let's start with the Visitor pattern" or something like that. The point of the patterns movement is there are common things that are done, wouldn't it be nice if we could talk about them with common terminology and use the full richness of our experience to ensure when we see the problem again that we don't make all the same mistakes we made last time.
I'd like to see it taught (and this can be in the programming shop, too) like this: "What are we trying to do? Where have we done something like this before? Doesn't this look like something we've done last month? Can you detect a pattern to all this?!"
Instead, what I often see if people spouting pattern names like one would name-drop at a party--the more you drop the more important you must be. Starting with the problem to be solved, the understanding of same, and then recognizing that we've seen this before, then naming the pattern is less flashy but is more the intent of the GoF IMHO.
The patterns themselves are not really that
... }
...
groundbreaking, IMO; the genius of the book
is the perspective on looking at software
as pattern definitions and then their use
in different ways and places in software.
The part that every OO developer should
ingrain in their brain is to
Prefer composition to inheritance.
Good Lord, people love their inheritance
when there are very, very rare situations
that call for it. (Composition, btw, is
where a data structure is used as a data
member of the class).
What it recommends is that instead of this:
class cElement : cParent {
use this:
class cElement {
cParent mParent;
}
Inheritance is so friggin abused by OO
developers, it is ridiculous.
So, my recommendation is to read the first
50 pages or so, which is their general
perspective on programming. After that,
it's just details about the patterns they
have encountered in their careers.
Peace & Blessings,
bmac
"Some is good, more is better, and too much is just about right."
- This mantra is good for money, horsepower, disk space, but not design patterns...
When somebody starts telling me that they used 5 different patterns in their program and they're proud of it - then I know the code is crap. Most of the pattern zealots I've seen write bloated, inefficient code. Sometimes I think they scour the literature looking for some extra patterns to put in.
That said, these patterns do exist and programmers keep reinventing them. The key is knowing when to call it a pattern and go to the trouble of formalizing it versus just writing code. Alternatively, find a language that makes most of these go away.
Ralph Johnson was my professor for two semester when I took UIUCs CS Senior Prject course the year before last. Pretty good guy! Very laid back.
Good book, too! Well earned, I'd say!
I, too, read the Gang of Four book. It is treated at my workplace like a Bible of sorts. And it's all a bunch of bullshit. If you want to make your code slow and bulky at the expense of maybe being 5% more maintainable, this is the book for you. However, in the real world, where customers want their software to run fast and use a minimum amount of system memory, these techniques, while instructive, are ultimately utterly worthless. The poster is absolutely right in saying that it's all just OO banging. Kids these days are taught the benefit of a signleton and a bridge pattern, but can't tell you the meaning of priority inversion or when you need to use a spinlock versus a regular sync object.
Karma: Excellent Birds (mostly as a result of listening to Laurie Anderson)
The classic Design Patterns book is great, and the GOF certainly deserves this award. Still, the book is hard to read. And in daily practice, it's not always clear when to apply which pattern (especially for the less experienced).
I'm reading Head First Design Patterns, published by O'Reilly, right now. It's an fun and easy to read Design Patterns course, which is difficult to put down once you started it. The authors have a great sense of humour, and use a very practice-oriented approach. They tackle day-to-day problems by starting with the obvious solution an inexperienced programmer would use. Then they point out the problems with this solution, and step by step they work to the appropriate design pattern. Patterns are examined from different viewpoints, and the authors try to answer all the questions you might have.
I really recommend this book. In fact, I recommend the whole "Head First" series (I also own Head First EJB). These books are not usable as reference works, but they are wonderful for learning and mastering a subject.
"If I could make a decent living coding in Lisp, I might actually give a shit."
If I could make a living fucking women, I might actually give a shit.
Those who can, do. Those who can't buy the videos.
Patterns themselves are good to have in code, but the idea that they must be reimplemented for each case (as opposed to being packaged up into a concrete, first-class language object) really shows the limitations of mainstream languages. Peter Norvig (formerly at Harlequin, and now at Google) did a good writeup of the issue. Paul Graham also has an interesting take on this subject.
A deep unwavering belief is a sure sign you're missing something...
The laws of software process: a new model for the production and managment of software by Phillip G. Armour
The Art of Interactive Design by Chris Crawford.
Designing and writing Online Documentation by William Horton.
Technical Editors Handbook by George Freeman and Deborah A Freedman.
Bugs in writing: A guide to debugging your prose by Lyn Dupre.
Thanks De Lemming, we appreciate it. We stood on the shoulders of gaints to write Head First Design Patterns. You're totally, right, our books are for learning, grab GoF for ref. ;)
Eric Freeman
I'm fairly confident the concept of design patterns truly originated with these two books. The concept from architecture was then applied to software.
The fundamental idea being that there are certain components of architecture that "just work" and "feel right". They may solve very complex problems in elegant and subtle ways. They are not usually designed, but instead are discovered.
Interestly enough, I believe that Alexander himself wasn't an architect, but a physicist with an interest in architecture.
I hope that Alexander was mentioned ;)
For another take on design patterns, I consider them to be nothing more than tricks to get around the braindead limitations of most mainstream object oriented languages. Its no accident that non object oriented languages like Lisp and ML don't have quite so many design patterns.
Seriously. I think some patterns are fine for some things, but as a previous poster has stated, more ugly-as-shit code has been written using design patterns than not.
I know that in the OO languages world, this book is hailed by many as the holy book, but to me, there really is only one... "Code Complete".
The one book teaches the fundamentals of good programming *in any language* better than any programming book ever written.
Case in point, I don't think any shit code has been written as a result of applying the techniques and best practices in "Code Complete". I certainly can't say the same about "Design Patterns".
Even Paul Graham, a Lisper critic of object oriented programming, creates his own set of object oriented systems in the final tutorial chapter of his book, "ANSI Common Lisp". (It's easy to build object systems in any language, such as Common LISP or Scheme, which have lambda and lexical scope.)
As for ML, the most popular ML language is OCAML. The "O" in OCAML stands for "objective", guess what that means. It's no wonder you posted as an AC, you obviously don't know anything about Lisp or ML other than what you've read in someones' blog.
Design patterns are largely cookbook workaround for poorly designed languages and libraries. It's pretty depressing that this is the best that software engineering and programming languages have to offer in 2005.
> I consider them to be nothing more than
> tricks to get around the braindead
> limitations of most mainstream object
> oriented languages
This is a perfectly right comment. For example, if your language supports closure, your need of the command pattern is greatly reduced. If you use a dynamic language like Perl or Python, you will find many patterns like bridges and abstract factories completely useless.
That said, each language has its own set of limitation. Before some genius creates a language that has everything we want (and still has the language comprehensible), we will continue to need some "band aid". If we need band aids, it is probably better to have a standard band aid for each purpose, rather than having a different one each time for no reason.
Hunger still exists.
War still exists.
Republicans and Democrats still exist.
Design patterns have not solved these and other problems, to my complete and utter surprise.
(Hitler doesn't exist any more, but I don't know how much design patterns had to do with that.)
Had I read your post earlier, my surprise might have been alleviated, or perhaps avoided altogether.
If your post can prevent one person from being surprised when design patterns don't solve all of the problems in the world, then I would say that it was worth all of the extensive effort that you obviously put into it.
You, sir (or madam), are a sage.
Or something.
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
These pattern things are all well and good. Yet they only seem to crop up in user interfaces. When it comes to doing proper programming, i.e. solving the customer problem, there are more important considerations, such as seeing if the customer's problem fits in the four steps of a church-turing thesis, or if a coin is tossed somewhere along the line.
threadeds blog
Where did the grandparent poster say that? He just said that Lisp is a "non object oriented" language. The only amendment I'd make to that is to say that Lisp is not fundamentally an OO language-- it's a functional language first, and OO only second. CLOS is a layer built on top of Lisp, and it's built with Lisp itself. The crucial ingredients of modern Lisp dialects are first-class lexical closures, dynamic typing and s-expression syntax (which is what makes the macro system feasible).
As for ML, well, OCAML is a language that adds an object-oriented system on top of the earlier CAML dialect. Look up CAML or Standard ML; there's no OO there. What you find is lexical closures and a Hindley-Milner static type system, together with a built-in preference for purely-functional code.
If we need band aids, it is probably better to have a standard band aid for each purpose, rather than having a different one each time for no reason.
But this is exactly the point. High-level abstractions are fantastic, but there will always be a need for, if nothing else, alternate implementations of those abstractions. As long as we still need a language sitting where C++ sits relative to the hardware, we'll need these elegant solutions to the "braindead limitations" of lower-level languages.
If other reasons we do lack, we swear no one will die when we attack
I LOVE python. But I think Lisp is one of the shittiest, most annoying languages on the market today. When I code in Python, I feel NOTHING like when I code in Lisp. Lisp needs to just die and blowtards like Paul Graham need to stop peddling their tired zealotry to people who know better.
The first 50 pages of generic design recommendations are not too bad but the patterns themselves are very boring to read.
There seems to be a strain of pedantry that is attracted to OO programming and it is in full flight in this book which is full of tedious repetition. As has been pointed out elsewhere, too many patterns can be a bad thing, a very bad thing. Also, patterns are in a way an admission that the language is flawed. You should not have an iterator pattern - you should have an iterator macro! Why are we still coding in low level 3GLs like Java 47 years after FORTRAN was invented?
I find the anti-patterns books more interesting. Why do people build spaghetti trash and what can you do about it? The answers are out there.
That book needed more examples.
Granted, I read it recovering from surgery with anesthesia in my system, but I found it to be prohibitively dense material for concepts that don't warrant that density.
The contribution to programming from those concepts will be fully realized when they are expressed in a form easily digestible by busy programmers who have to do a lot in the real world.
With all the hype over design patterns (usually by OO zealots who couldn't code in any other paradigm if their lives depended on it) you'd think no one had managed to write complex systems before they came along. In fact it seems to me that since the false prophet known as OO with all its attendant accolytes came along (design patterns being one of them) programming has actually got harder, less efficient and far more costly.
IMO its time to ditch all this high level buzzword trash coding methodology and go back to something a bit lower level whereby coders actually have to put some thought into what their writing and hopefully produce a fast , efficient end result. Not just use someone elses lego bricks to build some bloatware system thats has all the stability and robustness of a 1 legged stool. Far too many clueless idiots are coders these days. Its a bit like car maintenance - you have the people who can change the oil and air filter and plug in a new alternator out of a parts box and then call themselves mechanics , but the real mechanics know otherwise.
> Not just use someone elses lego bricks to build > some bloatware system thats has all the > stability and robustness of a 1 legged stool. So you say a system built of "your own sandcorns" is more stable than using "someone elses lego bricks"? Lego bricks being available as libraries are mostly better tested (more eyes) than the stuff you coded for your own. Just look at the security problems with C: Because most C coders have to play with char arrays for string handling instead of using a string class, we have all these buffer overflows all the time. Using a string class that abstracts from the nasty details makes the code less error-prone and more secure. A common string class gets more code review than your own privately used code will ever get. Also, abstractions make the code less complex and thus improve code quality. > Its a bit like car maintenance No, its more like building skyscrapers. Nobody would build them out of sandcorns at the building site. You use components.
Several people here have commented on how they have seen misuse of design patterns in code, or that a high usage correlates with bad code. This can happen, and I will discuss what I have noticed, but this does not reflect on the Gang of Four, or their book.
The book discusses the symptoms which would cause you to consider a particular pattern, and the disadvantages of using said pattern. In general, most of the patterns reduce coupling, and the flipside of that is it harder to follow the code - coupling means you can jump straight to where something is implemented. You use the pattern where you know without it e.g. the number of branches or classes has grown, or definetly will grow, to be unmanageable.
Design patterns became very fashionable, so everyone wanted to show they were using them. This meant that people who did not understand (or care about) the justification and negative consequences using them where the current and future requirements were simple, and the simple non-pattern solution was manageable.
For example, dozens of utility classes done as factory pattern. Therefore there is an interface and a factory, but there was only one implementation class needed and created. That class typically had a few extra methods, so client classes downcast to the concrete class. Pointless. It also made it harder to find what a framework method did, as you had to see what the factory was configured to create to find the implementation.
I have been in the situation where a poser at a design review insisted on using the strategy pattern because there was an if-else in my code (i.e. exactly two branches and the requirements were fixed). If someone like that gets their way, the code becomes very unreadable, inefficient and over-engineered.
People also cite that you can use the name of a design pattern, and other OO developers will understand this complicated design feature because it maps to the pattern. That is o.k. but the wannabes put the name of a pattern on their own solution which is quite different. Their solution might be valid, but they put a misleading name on it to get the pattern halo effect.
If some one reads the considerations mentioned in the book, and uses the pattern where there is a lot of complexity, or you can predict there will be a lot of complexity, they are an excellent solution to OO design problems that arise again and again.
${YEAR+1} is going to be the year of Linux on the desktop!
I would say that 'Design Patterns' is at least as much descriptive as prescriptive, in that they are describing what's been found in software 'in the wild' so to speak. Each pattern includes examples of where they've been found. In addition, each pattern includes a list of pros and cons.
I generally find that I prefer to let my code dictate my patterns, rather than the other way around. When building a system which calls for a centralized menu (or command line) to invoke various procedures, it's generally a good idea to see what the book has to say about the 'Command' pattern, and at least see what pitfalls one might encounter, and what kind of best practices have been discovered.
It was a joke! When you give me that look it was a joke.
Or better still, use an OO language that supports both dynamic variables and closures, e.g. Smalltalk or Ruby. As is the case with LISP, people working in this type of language will find that most design patterns are either reduntant or blindingly obvious.
Despite protestations from LISPers to the contrary therefore, design patterns do not address problems that are inherent in OO itself, but ones which result from languages that implement it using type systems and syntactic / semantic constructs that were either originally designed for structured programming (C++, Object Pascal), or are directly derived from an ancestor that was meant for structured programming (Java, C#).
Agreed. Trying to use a design pattern that is close, but not quite, what you need, is like trying to fit a square peg into a round hole: It may work if you use a big enough hammer, but it's never going to be as good as just using a round peg.
Everyone: Please ignore this book, and actually solve the problems you have; rather than attempting to look up the answer in this "solutions manual" for writing programs.
--Ender
Loose things are easy to lose. You're getting your hair cut. They're going there to see their aunt.
Actually, I find that each user interface (aside from simple dialog boxes) is unique enough that it would really be its own pattern, though as I move towards creating a suite of software tools, my general user interface style will emerge as a rather complex pattern. But before I can do that I have to have many hand-coded instances first so that I can factor out the pattern.
.y becomes .x. All I'm doing is getting the vertical bar correct (which is quite a bit of a pain, actually), then I'll apply the pattern to the hor bar. This is a very simplistic yet completely realistic example.
I find patterns most useful in three specific areas: container/list class design, database design and database to class mapping.
I wrote a tool to generate c# classes that wrap the ArrayList class with functions that return a properly-typed elements. It's basically a c++-style template creator (with lots more parameters), yet what it really is is a pattern definition and instantiation process. I define the instance parameters (like includeStackRoutines? and elemHasName) and then I generate a list container. It takes two minutes to generate the class, and this is all because of patterns.
The second use of patterns is in database design, or, rather, the definition of the tables within the db. Some tables have a unique id, some have versioned records, some have another table in a 1:n relation, etc... Even in a large (in my professional experience) db, the types of relations between tables is usually relatively small in number: maybe four or five. Each set of SQL statements that access a section of the db will be just like the SQL statements used for other sections that have the same type of relation, which is a pattern. (BTW, I don't use stored procedures because there are completely non-portable and have lousy error reporting, IME. I do, however, love the idea of having such a clean interface to my db.)
The third situation is in mapping the db structure to a class structure. Once again, similar design patterns for the tables lead to similar patterns of class implementation.
Remember that with patterns what someone else in this discussion said: if the code was exactly the same it would just become a single function. The point of patterns is to factor out the commonality of code and to then apply the pattern as a framework for the creation of similar pieces of code. The key here is that the other areas are
*similar*, not the same.
A very simple example that I'm dealing with now is that I'm rolling my own scroll bars within a generic canvas. The code for the vertical click-and-drag bar is the same pattern as the horizontal bar, except that
Peace & Blessings,
bmac
Perhaps all the negative comments about design patterns are due to a misunderstanding of the application of patterns. If you can identify a pattern, then you can exploit it for easier reproduction, maintenance, update, and so forth. But if you have a problem and trying to solve it by applying patterns, then you are wasting time. It may be better to focus on solving the problem first, and given enough time and resources, refactor using design pattern principles. Good coding that avoids repetitions is better than creating repetitions.
"With all the hype over design patterns (usually by OO zealots who couldn't code in any other paradigm if their lives depended on it) you'd think no one had managed to write complex systems before they came along."
OO emerged in 1967, so it would indeed be true to say that there wasn't a lot resembling our modern definition of a complex system "before it came along".
"In fact it seems to me that since the false prophet known as OO with all its attendant accolytes came along (design patterns being one of them) programming has actually got harder, less efficient and far more costly."
Exactly the same things were said about structured programming by adherents of monolithic programming, and high level languages by those who preferred ti work in assembly code. Each of these extra levels of abstraction has drawn endless criticism from those who resent or fear change. Doubtless the same resentful, doom-laden voices will sound from entrenched members of the OO community when something else starts to become popular.
"IMO its time to ditch all this high level buzzword trash coding methodology and go back to something a bit lower level whereby coders actually have to put some thought into what their writing and hopefully produce a fast , efficient end result."
The speed and efficiency of an end result has far more to do with the algorithms that are used than what language it was written in. A quick sort in Smalltalk will sort several million elements more rapidly than an assembly-code bubble sort.
"Not just use someone elses lego bricks to build some bloatware system thats has all the stability and robustness of a 1 legged stool."
OO does not have a monopoly on bloatware or poor stability. Windows-95 for example was mostly written in C and assembler.
"Far too many clueless idiots are coders these days."
Sturgeon's Law states that 90% of everything is crap, and programmers are no exception. It would be nice if we could prove that all the crap lived in the OO world, but the fact that so much plain old C code has been found to harbour critical security flaws proves that crap programmers and crap programming are everywhere.
"Its a bit like car maintenance - you have the people who can change the oil and air filter and plug in a new alternator out of a parts box and then call themselves mechanics , but the real mechanics know otherwise."
The flaw in this analogy lies in the fact that the "real mechanics" don't make their own parts unless there is no other option, because buying a ready-made part where one is available is cheaper and quicker (even if one has both the skills and equipment to cast and machine a differential, crank shaft, or cylinder head). This is actually far closer to what OO programmers do (and indeed structured programmers who use supplied library functions and OS services) than the sort of low-level stuff you propose, i.e.: use an existing part if there is one that fits, otherwise write your own.
Why would size be a changeable property in the first place? In geometry, objects certainly don't change size once they exist. If yours do, you're doing some kind of animation, and probably have no use for squares anyway.
Perhaps the pattern missing here is Complete Construction. If some property is unchangeable, it should be set at construction time, and never be changed. The class interface needs to reflect this, so in this case we would have a Square constructor taking one argument, a Rectangle constructor taking two arguments, and no setSize() method.
Inheritance is overused by people who don't know what they're doing, but the same can be said about the inheritance backlash. I meet many developers who avoid inheritance, but few who can explain why and when.
Design Patterns are not mean to be "ccokie-cutter" solutions. They will not make a bad programmer produce good code.
A Flyweight class used to represent individual characters in a document (as suggested in GoF book) will look very different from one used to represent individual frames in a video clip (as implemented by me after reading GoF book.)
Design Patterns provide a framework for thinking and communicating about the design space for a particular problem but they are no substitute for rigorous thought, problem-solving skills, and good design principles. These you must bring to the table yourself.
Well I have written a LISP compiler, and I have written thousand and thousands of lines of both ML and Lisp.
...
As someone else pointed out both Lisp and ML are fundamentally functional languages, with some object add-ons.
But all this is irrelevant. In the presence of higher order functions and decent type systems, most of these patterns are not necessary. But you totally failed to address this issue, and instead tried to attack the messenger
The problem with today's OO programmers is that they don't know this simple principle: inheritance should be on extending interfaces, not implementations.
An example of the above principle is a common mistake of GUI toolkits: there are widget classes that inherit from a 'Window' class, simply because the widget uses a native O/S window to display its output. If the toolkit is transferred to another O/S which does not have windows (for example, an OpenGL implementation that uses texture composition), then the toolkit falls flat on its face.
Some of the patterns don't seem to have good implementations. Take Singleton, please! It gets hard to implement the one-and-only one instance of an object and in a non GC language to enforce that it gets deleted correctly at the end. Are there any clean implementations of Singleton in any of the regular OO languages?
I am all for identifying the patterns and extending languages to simplify their implementation -- otherwise you are spinning your wheels trying to rewrite the same (potentially buggy) code all the time.
In Common LISP, they are one-dimensional arrays (character vectors).
As such, a cdr can't point into the middle of a string, since cdr can't point to a subsequence of an array.
In fact, the only thing that you can do with a substring as a whole in CL is make a copy of it and replace it.
(It's possible that some CL implementations allow other operations, and it's possible that other LISP dialects (e.g., Scheme) may allow other operations, but those are not Common LISP.)
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
For example, versions of C on machines that don't support floating-point (e.g., PDP-11) usually call support library routines to do floating-point operations.
I consider such routines to be part of the language implementation, and thus I consider floating point operations to be part of the C language, even when the underlying code calls library functions.
OTOH, to do I/O, a C program has to explicitly call functions such as printf, etc., so I/O is not part of the (ANSI) C language itself; i.e., C can't do I/O without calling (functions in) an external library (even if some compilers recognize functions like printf and can optimize it to a call to puts in some cases).
(This may have changed with C99; I haven't had a chance to look at the C99 spec yet.)
Similarly, it is irrelevant (except maybe in terms of performance, low-level debugging, etc.) whether a particular CL implementation uses a macro, function, or a single opcode in its built-in VM, to implement a particular operation that is part of the language (as long as it conforms to the spec).
I consider such lower-level macros/functions to be part of the implementation, built-in, internal.
OTOH, something like an interface to the sockets library I consider to be a reference to an external library, even though you use operations in such a libarary the same way you do the "built-in" operations, once the package as been loaded (and its symbols have been interned).
Re: FFI: With FFI, you can interface to just about anything.
It's just that if you want that "anything" to do the things that I mentioned earlier, then it will have to be written in a language other than (Common) LISP.
In addition, IIRC, FFI is an extension to CL, not part of the "standard" language, and may be implemented by different, uh, implementations in different ways.
Rereading the above, I can see that I am not expressing my position as clearly as I'd like to.
Still, I hope that you can get the jist of it.
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
You can drive screws with a hammer if you want to. Hell, you can even try to saw a board with it. That doesn't mean the hammer is a flawed tool.
Arguing on the internet, special olympics, blah blah blah. I just won't get into it, sorry. You obviously hold more of an emotional stake in this than I do.
Slashdot - where whining about luck is the new way to make the world you want.
It's good for them, they bring together in that book some good stuff ! But we often forget some old folks too, let remember good old days of Smalltalk-80 form Xerox ( and of course Smalltalk 72 ) the real first metaclasse based OO language where you can find alot of those (new) paterns. ( no Bill didn't invent OO ! ) http://www.archive.org/details/DanIngal1989 All of other languages have some interest patern too, let just think at CSP-Occam, Scheme(kindof lisp) ... :-)
Correct but language isn't unimportant either: an assembly quicksort will sort elements more rapidly than a smalltalk quicksort.
It's all about the level of optimalisation, you start with the algorithm and then concider reimplementation in assembly.