And since "patterns" is such a hot buzzword, we might help make Lisp
more popular by combining such websites into one big "Lisp Patterns"
website, organized by type of pattern, such as algorithms, usage, etc.
It could even have a section on the GoF patterns with explanations
for most of them of why each is not needed in Lisp.
Antipatterns might be a very big subset of patterns, and might
therefore be a big section of the website.
Another kind of component of a programmer's knowledge is how to earn a
living from programming. How to get along with your boss, how to meet
deadlines, how to find a Lisp job, etc. Those might or might not have
a place in a collection of patterns. They might be considered an
additional kind of knowledge, in addition to patterns.
> Another kind of component of a programmer's knowledge is how to earn a
> living from programming. How to get along with your boss, how to meet
> deadlines, how to find a Lisp job, etc. Those might or might not have
> a place in a collection of patterns. They might be considered an
> additional kind of knowledge, in addition to patterns.
There's a whole body of literature about 'organisational patterns'
about. Things like ScapeGoat etc.
Lieven Marchand <m...@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
There are patterns and pattern languages about:
* organizations for developing software
* open-source communities including governance and standardization
* teaching computing and OO
* completing grad school
* how to be a consultant
* doing writers' workshops
* designing any sort of textual electronic communitications
* writing papers for conferences
And dozens more.
Anti-patterns, by the way, are ignored by the patterns community.
> In the recent thread about design patterns, RPG's definition of
> patterns seemed to be approximately that patterns are components of a
> programmer's knowledge, which differentiate between more and less
> experienced programmers. Such components seem to me to include
> algorithms and good usage of a programming language, along with other
> kinds of knowledge. In other words, books of algorithms, such as
> Knuth's, and books of good Lisp usage, such as PAIP, etc., could
> actually be considered patterns books. Or they could be combined into
> a bigger patterns book, and become individual chapters of it. And
> Cliki, ALU, CLOCC, etc., could be considered Lisp patterns websites.
> And since "patterns" is such a hot buzzword, we might help make Lisp
> more popular by combining such websites into one big "Lisp Patterns"
> website, organized by type of pattern, such as algorithms, usage, etc.
Hmm. I would think the reason people check out lisp is because they
are starting to have a clue about distinguishing between empty
marketing talk and useful technology.
Such folks are not likely to be impressed by cheap buzzwords like
"enterprise", "bullet proof", or even "patterns". It might even be a
> It could even have a section on the GoF patterns with explanations
> for most of them of why each is not needed in Lisp.
_That_ sounds very helpful, though: recognize the buzzword and show
how its most popularized form looks from the standpoint of someone who
has experience with lisp.
Note: If you want me to send you email, don't munge your address.
Alas, patterns are passe. I didn't think Lisp folks would let themselves get
into such a backwater. I recall trying to explain the concepts to some
Scheme guys on one of the Scheme mailing lists about 5 or 6 years ago, but
they also had the abstraction disease a lot of people have and could see
patterns only that way and therefore irrelevant to them. I think they forgot
they were people too.
If I have understood this patterns thing correctly, these would be some
of the patterns of design in Common Lisp:
1 Design algorithms to work with the highest meaningful class in the class
E.g., design them for sequence rather than specifically for strings or
lists, or vector rather than specifically for string.
2 Accept start and end arguments in sequence function to avoid unnecessary
Consequently, use them rather than inventing your own indexing and
3 When accepting an "end" position, it is exclusive. (The "start" position
is likewise inclusive.) A nil end argument means the natural end of the
sequence. Accept an explicit end argument, do not depend on defaulting.
I.e., when the start and end arguments are equal, the sequence is empty.
4 If your algorithm scans a sequence in one direction one element at a
time, accept a from-end argument.
Consequently, one does not need to call it with reversed arguments.
5 Use iteration rather than recursion to scan a sequence one element at a
time. (Reserve recursion for situations where you _require_ a stack.)
I.e., Common Lisp is not a dialect of Scheme.
6 When iterating over something to collect elements into a list, use loop
with collect, or push onto a list which you nreverse before returning
with the following template,
(... (nreverse list))
(push ... list)
or stuff new items onto the end of a list using the following template
(which is usually what loop uses)
(head (cons nil nil))
(... (cdr head))
(setf tail (setf (cdr tail) (cons ... nil)))
7 Design function interfaces so they can accept designators.
I.e., study and use the designators already designed-into Common Lisp.
When designing the functional interface for a new class hierarchy, that,
say, accept an "employee" instance, and you find employees using a string
or an integer, design and use an "employee designator" that turns strings
and integers into employee instances whenever only an employee instance
Except for item 6, I do not think these are issues of abstraction or
macrology. The patterns in 6 may be cast into macro form, but the degree
of variation may simply be too large to make general macros useful, which
is kind of what I expect from patterns: If they were general enough, they
_would_ be abstractions.
Now, RPG once told me that I sounded like I had not understood patterns,
so, Dick, if you read this and think it sounds like I have now, I would
appreciate a more positive hint this time. :)
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
> I think they forgot
> they were people too.
So, the whole design pattern and now the new XP wishy-washy thingy are ways
to encourage stupid people so that we can multiply those incompetent kiddies
and weenies in the software industry?
is society supposed to be moving forward, or is it backward? The pile of
mathematical knowledge and consequently all sort of unforeseen technologies
are impinging forthwith by the armies, but in the software industry are we
supposed to start a New Age dark age with the patterns and eXtreme
Programing soft and informal and hand-waving and poetic justice crap?
The mathematics in computer science along is sufficiently large now that a
single person perhaps cannot apprehend it in a life time. (look at Knuth's
ongoing work) Now you pattern kooks want to rob programers of already
wanting education to the patterns and XP voodoo?
why the computing world is filled with these patterns folks and OOP
go-getters and Larry Wall types of artists these days?
If a bridge falls, then the engineers who build it will be responsible. If a
software caused a disaster, guess what? These patterns and whatnot
wishy-washy monkey coders have licenses and software agreements to shuck
Is software building really that complex? So complex that errors are
unavoidable? So complex that it is more complex than bridge and
it is an irony that computer, by their nature, do not make mistakes. Yet,
they are littered with the most errors and crashes.
Software today are so fucked up precisely because it is tooo easy. Every
monkey can don on a "software engineer" hat after few years of keyboard
punching. Every donkey can speak grand patterns and propound and drool XP =
e"X"treme Programing methodology. How many of these arses can speak a single
dialect of modern mathematics? Can they contribute a single non-trivial
theorem? How many programers in the software industry even know what modern
mathematics is or consists of? What are the branches of modern logic? I can
pull from the top of my head discrete math subjects as easy as i can pull
the hairs on my head that even you -- a mathematician -- are not familiar
The problem isn't stupid people. The problem is a stupid attitude in
society, that software are too complex and errors are ok. The very fucking
damn lies by incompetent monkey coders that is unix and C and Perl et al.
What can we do, folks? First of all, stop lying to ourselves and the public
about how software is complex and unpredictable. Software building is ten
thousand times easier than bridge building or flying-machine building. If
the world's bridges and airplanes do not crash now and then, nor should
software. Software engineers must bear all responsibility to all software
faults. The public should demand that software licenses do not have the
"though we tried hard, but we are totally not responsible if the software
fucked up." clause.
This must start by building an awareness in the general public, that
irresponsible licenses are not acceptable. When software engineers bear
responsibility, then monkey coders will gradually fall by the way side, and
patterns and XP and UML and likewise shits will crawl back into the woodwork
they came from.
Given our already fucked up legacy, we can only start to build a system,
environment, and attitude, where every software is mathematically provably
correct. This is not only achievable, but not difficult when all the
programers are well educated.
Actually, i think programing patterns and e"X"treme Programing and OOP
mantras and UML are great, but only after every programer in this world have
mastered Knuth's books, and speaks lambda calculus fluently to begin with.
Then, perhaps we can start to suck each other's dicks and slobber pattern
with fellow XP chaps.
When we have a world where for each software bug the engineer will be
penalized for one month's salary, then we shall see if more math knowledge
prevails, or the patterns and XP type of thingy survives.
Dear Richard, you said that the patterns movement are waning? I'm glad to
hear that. As i have expressed here before, if the world is not filled with
100% morons, than stupid ideas will die off, and the world will move on, as
is the pattern in history. I think that OOP today isn't as hot as back in
say 1999. Also, please excuse my language. It is my style. A confrontational
style. If i do not speak up, who can? who would? who is willing?
I wonder how many bridges would stand up or aricraft would fly if they
could not rely on continuity and near-linearity of the physical
systems to ensure that small errors do not usually result in
Patterns are *old news*, like the Web or any of that 90s crap. Lisp
people need to understand that doing what everyone else did 5 years
ago is *not* the way to succeed. It might keep you in business but
you won't get rich writing a web server any more, or writing about
patterns. You need to find out what people will be doing *next*.
> environment, and attitude, where every software is mathematically provably
> correct. This is not only achievable, but not difficult when all the
What does it mean for software to be correct? Can it accidentally
kill a million people and still be considered mathematically correct?
Any hints? ;-)
frr at wanadoo dot es
I think that is part of what the purpose of patterns/pattern languages
is/was. To create what the next thing will be. The trick is not to find
out what is next but to create what is next. Partially by creating a
pattern language strong enough to influence a large enough group of people.
Of course this has to be your definition of success.
Patterns (deeply held beliefs) From the previous post:
There exists old news,
Successful things like the Web are crap,
Lisp people need to succeed,
Part of success is understanding,
There is a wrong way,
There is a right way, (If you could only figure it out)
The old things have been done, there is only room for success in new things.
I think so. While "provably correct" has its virtues, I think
"provably harmless" is better. "provably correct" does not imply
"provably harmless". All kinds of correctly functioning things can
cause harm. And one can sometimes prove harmlessness without having
to prove correctness.
Xah's discussion also presupposes that the only purpose of
software is engineering. Were art restricted to that which is
provably correct, there would be no Escher.
I don't mind people trying to refine and make more rigorous that part
of computer science which is intended to be engineering, but I regard
computer science to be much broader than that and would not like to
see this treatment uniformly applied to all it might be. And
certainly not all science. The name is an utter misnomer, IMO. But
then, it was pointed out to me by someone at some point that
"disciplines" that feel compelled to use the word "science" in their
name are rarely true sciences. In the case of CS, some of that may be
a failure to achieve some goals people wish it would achieve, but some
of it is just as well. I don't doubt that psychology will ultimately
yield to some fairly rigorous science, but I think it would be a
mistake, at least for the nearterm, to reclassify Philosophy as
"Thought Science" and then to berate it for entertaining fictions,
contradictions, random neuron firings, and whatever other oddities
make up the whole of human perception, conception, and so on.
Patterns were born from Smalltalk-inspired people, and ended up in the
hands of C++ and Java programmers. I don't think they persuaded many
people to learn Smalltalk. (Ditto XP, I think)
Web applications were probably originally pioneered by Perl programers
writing CGI. Then the Java guys muscled in with J2EE and all that
middleware stuff; I don't think many of them decided this would be a
good opportunity to learn Perl.
So I think Lisp programmers have to decide whether their goal is to
get rich, or to popularize Lisp. Even if you correctly identify the
Next Big Thing ahead of time[*] and win (= get rich) by implementing
it in Lisp, Lisp is not going to ride on its coattails to become the
Next Big Thing Implementation Language. Your competitors will just
reimplement it in whatever language they already know or has enough
marketing $ behind it to persuade J Random Programmer that he needs to
[*] A more reliable strategy would probably be to shape the next big
thing yourself instead of passively trying to spot it coming out
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
> Patterns (deeply held beliefs) From the previous post:
> There exists old news,
> Successful things like the Web are crap,
> Lisp people need to succeed,
> Part of success is understanding,
> There is a wrong way,
> There is a right way, (If you could only figure it out)
> The old things have been done, there is only room for success in new things.
I've always thought that I should learn more about the patterns
concept because it is so influential. But the more I read here, the
more it seems that it has become an ill-defined or often-misunderstood
concept, bound to confuse more than anything.
Are patterns simply heuristics favored by experts -- sort of "best
practices" in programming? That seems a lot more interesting than the
vague "deeply held beliefs" definition above.
I think patterns people are trying to prevent the next thing from being
just another variation of something somebody already did many years ago.
The "if we do it our _own_ way, we can call it innovation" crowd needs
serious corrective input to their "creative" processes. Preventing just
one stupid reinvention of the obvious from being marketed in glittering
new clothing would be worth every cost.
>I don't doubt that psychology will ultimately
>yield to some fairly rigorous science, but I think it would be a
>mistake, at least for the nearterm, to reclassify Philosophy as
>"Thought Science" and then to berate it for entertaining fictions,
>contradictions, random neuron firings, and whatever other oddities
>make up the whole of human perception, conception, and so on.
Philosophy is not a science, nor does it pretend to me. Philosophers
don't run experiments and evaluate their theories relative to empirical
data. This is not a knock on philosophy. Mathematics is not a science
by my definition either.
Linguistic is an interesting case (as you know). Linguists certainly
hatch strong theories. They also take the linguistic world seriously,
evaluating their theories relative to the (presumed) grammaticality
judgements of real speakers. And in the hands of Whorf, Chomsky, and
others, linguists have influenced the scientific activity of other
fields, e.g., psychology. But grammaticality judgements are a peculiar
sort of data that differ fundamentally from the data of other sciences.
It is thus unclear whether linguistics is properly scientific.
Experimental (cognitive, developmental) psychology definitely imitates
the physical sciences. It has theories and it runs experiments. But
its theories are often informal. It is difficult to know whether they
are just immature versions of what their natural science counterparts
have had more time to develop, or whether they are flawed in-pinciple.
And psychological experiments seem more inherently noisy and unreliable
than their analogs in the physical sciences. Experimental psychology
talks the talk and tries to walk the walk, but it is unclear whether it
will ever 'get there' -- psychological phenomena may prove to be the
sort of thing for which the scientific method is just ill-suited.
Given that what I've said is probably inflammatory enough, I'll remain
quiet on the scientific standing of other disciplines...
> Philosophy is not a science, nor does it pretend to me. Philosophers
> don't run experiments and evaluate their theories relative to empirical
> data. This is not a knock on philosophy. Mathematics is not a science
> by my definition either.
I didn't mean to suggest that Philosophy intended to be a science. I
meant to say that Xah's suggestion that, paraphrasing, "to understand
is to make mathematical" does not capture the ability of philosophers
to capture truths, even vague ones, in useful ways. They make no math
out of it, yet they do add to our understanding.
> Experimental (cognitive, developmental) psychology definitely imitates
> the physical sciences. It has theories and it runs experiments. But
> its theories are often informal. It is difficult to know whether they
> are just immature versions of what their natural science counterparts
> have had more time to develop, or whether they are flawed in-pinciple.
> And psychological experiments seem more inherently noisy and unreliable
> than their analogs in the physical sciences. Experimental psychology
> talks the talk and tries to walk the walk, but it is unclear whether it
> will ever 'get there' -- psychological phenomena may prove to be the
> sort of thing for which the scientific method is just ill-suited.
Practically speaking, we have every reason to assume that science
comes down to a mere handful of variables and formulas to explain the
physics of a very huge universe. Scientists are pushing for simpler
and simpler theories of unified field theory. That part of physics
seems to me to be about explaining either micro-effects or homogenous
aggregate effects involving relatively uniform physical quantities. A
sun might be assumed to be "mostly hydrogen", for example, so more
easily be dealt with in the aggregate. Solar science does not extent
to predicting individual solar winds at particular geographical points
on a particular sun for example, nor is a sun ever described as having
a particular behavior because "it had a troubling childhood". Where
we do see such things, whether in the study of the mind or in
meteorology (earthly or otherwise), we see research done in a very
different way because the reseearchers KNOW there are a lot of
variables to be addressed and they know the issue of combination, not
the issue of core nature, is the dominating factor. If we had to
psychoanalyze fires to understand how they started, I think our
present scientific method would break down.
So to each area of study its best tools. They should not have to all be
of a kind nor to a single standard.
> Are patterns simply heuristics favored by experts -- sort of "best
> practices" in programming? That seems a lot more interesting than the
> vague "deeply held beliefs" definition above.
Yes, exactly. Patterns are nothing more than a standardized, digestable
documentation approach for "best practices". By providing a single
description of an approach or architecture, patterns provide a good way
to quickly get up to speed on approaches/solutions you might not be
familiar with, while at the same time creating a shared terminology that
makes it much easier to communicate with others in your area.
Patterns are probably not the ONLY thing that would make Lisp more
popular in the rest of the programming world, but they probably wouldn't
hurt. Documenting common approaches to solving problems in a uniquely
Lisp fashion would be a great way of applying patterns in the Lisp
community. (You could easily position the entire _On Lisp_ text as a
collection of patterns, if it were written in a slightly different style).
The major thing keeping people from using languages like Lisp, Scheme,
and other functional languages is the learning curve. Patterns help
make that curve manageable for people that don't have a lifetime of
experience in the language.
It's a little disappointing that people often hold such a negative view
of patterns, given that they're just a way of communicating. I would
think the more information flow, the better, especially for a group that
wants desperately to communicate the advantages of its approach to the
rest of the world.
PS: Patterns were not invented by computer scientists, but by
architects. If you're interested in the original texts, check out
Christopher Alexander's "The Timeless Way of Building", and "A Pattern
Language: Towns, Buildings, Construction".
Curious Networks, Inc.
Erik> If I have understood this patterns thing correctly, these
Erik> would be some of the patterns of design in Common Lisp:
Erik> 1 Design algorithms to work with the highest meaningful class in
Erik> the class hierarchy.
Erik> E.g., design them for sequence rather than specifically for
Erik> strings or lists, or vector rather than specifically for string.
This seems like as good a place as any to start a tangent ...
I have recently had need for a way of holding sequences longer than
will fit in a particular implementation's array (i.e., the length is
(or might be) greater than the value of variable
array-dimension-limit). In response, I "invented" a buffer-list, a
list of buffers with the wrinkle that the list is actually a list of
lists, where the sublists are (buffer-length buffer), for example:
'((5 "01234") (5 "56789") ... ). Since the ordinary sequence
functions I need would not work on these buffer-lists, I wrote
(defun search-in-buffer-list (target buffer-list start)
"Searches for sequence TARGET in the buffers of BUFFER-LIST starting
at START, where START is a list consisting of (buffer-number
buffer-offset). If found, returns the buffer list address
(buffer-number buffer-offset). If not found, returns NIL. This is
implemented by successively looking in the buffer-list (with the
function POSITION) for the first object in the TARGET sequence, and
when found checking if the successive positions in BUFFER-LIST
match, using the function MATCH-IN-BUFFER-LIST described below."
(defun match-in-buffer-list (target buffer-list start)
"Checks if sequence TARGET matches the contents of BUFFER-LIST
starting at START, where START is a list consisting of
(buffer-number buffer-offset). This is used as a helper function to
SEARCH-IN-BUFFER-LIST, but is useful on its own as well. Returns T
if the sequences match at the specified position, otherwise NIL."
(defun buffer-list-offset (buffer-list start adjustment)
"Normalizes a buffer list address that has been adjusted forward or
backwards. Returns the normalized address in the form of the list
(defun extract-from-buffer-list (buffer-list start end)
"Essentially a SUBSEQ for buffer-lists. Concatenates, as necessary,
the contents of the buffers of BUFFER-LIST between the buffer-list
addresses START (inclusive) and END (exclusive). This function is
expected to fail if the concatenation exceeds the value of
variable array-dimension-limit.  by which I mean I know it will,
but I haven't done anything about it."
I've also got functions that read and write buffer-lists from/to
streams of element-type (unsigned-byte 8), which is what my immediate
need is for. The write function does not suffer from the problem of
the function EXTRACT-FROM-BUFFER-LIST, since (obviously) the
destination isn't subject to the array-dimension-limit.
Having developed these functions to a stage where they are useful to
me, it has entered my consciousness that this problem has certainly
presented itself to others before and I am curious how they might have
solved the problem. I did a little googling around but didn't find
anything relevant. Do my "buffer-lists" have another more typical
A couple thoughts I've had while writing this message are:
a) whether or not the buffer-lengths in the buffer-list are "good".
I kind of like the cached values so that I don't have to
recompute them whenever I need them.
b) whether I should eliminate the (buffer-number buffer-offset) from
the function call interface and just use a flat offset,
recomputing the buffer-number/-offsets as necessary.
At present, the remainder of Erik's suggestions for sequence functions
Russell Senior ``The two chiefs turned to each other.
sen...@aracnet.com Bellison uncorked a flood of horrible
profanity, which, translated meant, `This is
extremely unusual.' ''
> Xah's discussion also presupposes that the only purpose of
> software is engineering. Were art restricted to that which is
> provably correct, there would be no Escher.
Oh it's much worse than that. Quite apart from the idiot claim about
provable correctness being easy, he has completely unrealistic ideas
about the kind of things mechanical & civil engineers do. No one
building a bridge is `proving it correct' - probably no one building a
bridge knows what a formal proof *is*.(Here's something that should
strike cold fear into his bones: not only do almost none of the
engineers building things know what a formal proof is, almost none of
the physicists who build the foundations for engineering do either,
and those who do generally regard them as some stupid thing that
mathematicians do. And if you go to the maths dept you'll find that
about 90% of mathematicians aren't doing formal proofs either. It's
only the CS people who get so hung up about this, because they suffer
from *really bad* physics envy.) Instead they use informal 19th
century maths combined with late 20th century computer modelling
techniques. And sometimes they get it wrong and the bridge falls down
or has bad characteristics (still: look at the millenium bridge in
London). Planes drop out of the sky too, in case he hasn't noticed.
Engineering is *not* about rigour, its about getting an acceptably
good thing built in an acceptable time at an acceptable cost.
The difference that he's failed to notice is that engineering of
physical objects has some good characteristics whhich computing
systems don't have. In particular continuity and linearity which
combine to mean that small errors don't matter. In computing systems
this is absolutely not true: change a bit and the thing blows up, for
a significant proportion of bits. Imagine if physics was like that.
> Practically speaking, we have every reason to assume that science
> comes down to a mere handful of variables and formulas to explain the
> physics of a very huge universe. Scientists are pushing for simpler
> and simpler theories of unified field theory. That part of physics
> seems to me to be about explaining either micro-effects or homogenous
> aggregate effects involving relatively uniform physical quantities.
Well I think you have to take into account that things like unified
field theories are done by about 8 people. OK, it's more than 8, but
it's not everyone. It has high visibility because it's incredibly
glamorous, but there are an awful lot of people doing stuff that is
less glamorous but still very interesting.
A good example of this is superconductivity. All the *fundamental*
stuff to explain superconductivity was probably more-or-less sorted
out by the late 30s
(basically nonrelativistic QM), but it took an *awful* long time after
that for people to really have the faintest idea what was going on - I
think until the 70s - and there are still, I suspect, huge lacunae in
our knowledge of how things work.
And there are many other examples: lots and *lots* of people in
physics are doing things which are not trying to sort out the
fundamental laws of the universe, and I think there is an increasing
feeling that trying to understand the behavious of actual macroscopic
physical objects like stars and weather systems is important. One of
the reasons why this hasn't historically been done is that the best
you can probably do with such systems is to reduce the maths to the
point where actually doing predictions is merely a very
computationally demanding task rather than a completely intractible
one, so until reasonably fast computers became available there was
really no point in trying to attack such problems - who cared, in
1900, that you could reduce some problem from 10^20 multiplications to
10^9, you needed to get it down to 10^4 before you could even think
I have a document that I will probably never finish (it's at least 2
years since I did any work on it). Its title is `About six months'.
Its intent is that six months is about the difference between winning
and losing, and coincidentally the advantage Lisp gives you is also
about 6 months. If you can spot something at the same time everyone
else does, then you can get there *first* with Lisp. If you spot
something significantly before everyone else does it doesn't matter
very mugh how you do it, and if you spot if 5 years too late Lisp
won't help you win.
There are a few things to notice about this.
If you get there first you can set standards, if you are lucky. That
means everyone else has to talk to you, and if you get the standards
right that can further help your system because the standards are
designed to be easy for you.
Getting there first means not doing complicated things. This is a
really crucial point. If it needs XML or CORBA its going to take more
than 6 months - not just in Lisp but in any language because these
systems are just overcomplex. Things grow complexity as they mature
and die. If you think you need to implement a new lisp dialect or an
OS you are looking at the wrong things.
Getting there first does not solve everything. You can do pretty well
but reasonably soon (5 years) some huge monster will come along and
use monopoly power to smash you if they can. You want to have sold
out before this happens. Alternatively, like the dot.com boom, the
`next big thing' may turn out not to be so big, in which case you want
to sell before the bubble collapses to get maximum value...
The classic error made by Lisp people is that Lisp is *so good* that
you can not have any other ideas, and just do what everyone else does,
5 years later, but win because of secret Lisp magic. This is probably
enough to keep you afloat, because Lisp is pretty good, but you'll
spend your life fighting integration problems and so on, and needing
XML and CORBA and UML and all that other dross. The difference
between Lisp and anything else is that 5 years too late is only 4
years 6 months too late in Lisp.
So my theory is that Lisp is the difference between needing to see the
next big thing coming 6 months before anyone else, which means you are
lucky or a genius, and merely seeing it at the same time, which means
you just need to watch things like a hawk.
Of course there are other ways of making a living than spotting the
next big thing, and you can use Lisp for those too. That's what
almost everyone does, after all.
Finally someone mentioned that you have a choice between doing this
and popularising Lisp. This is not correct. Firstly you can get to
set Lisp-friendly standards. Secondly, Once you've done this you never
need to work again. *Then* you can popularise Lisp.
> I have recently had need for a way of holding sequences longer than
> will fit in a particular implementation's array (i.e., the length is
> (or might be) greater than the value of variable
> array-dimension-limit). In response, I "invented" a buffer-list, a
> list of buffers with the wrinkle that the list is actually a list of
> lists, where the sublists are (buffer-length buffer), for example:
> '((5 "01234") (5 "56789") ... ). Since the ordinary sequence
> functions I need would not work on these buffer-lists, I wrote
> Having developed these functions to a stage where they are useful to
> me, it has entered my consciousness that this problem has certainly
> presented itself to others before and I am curious how they might have
> solved the problem. I did a little googling around but didn't find
> anything relevant. Do my "buffer-lists" have another more typical
> name? Suggestions/comments?
> A couple thoughts I've had while writing this message are:
> a) whether or not the buffer-lengths in the buffer-list are "good".
> I kind of like the cached values so that I don't have to
> recompute them whenever I need them.
But "recomputation" is a very fast memory access for vectors, which is
likely nearly just as fast as a car operation, and will remove one
indirection to get at the vector, so it seems that not keeping this
duplicate value is a useful simplification.
> b) whether I should eliminate the (buffer-number buffer-offset) from
> the function call interface and just use a flat offset,
> recomputing the buffer-number/-offsets as necessary.
Since you need to retraverse your buffer list in any case,
recomputation seems inexpensive, so I'd go for it. This might be
different if you have lots of buffers, and either keep them in an
adjustable vector (so that direct indexing with the buffer-number
works), or you keep the buffer-cons instead of the buffer-number,
again giving you direct access.
Pierre R. Mai <pm...@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
I think the first two of these are not good examples. There aren't
really any interesting cases where if you have a star and you make
some *really small* change to it it will go nova. You could perhaps
construct such a thing (if you could construct stars...) but it would
be ludicrously weird. Similarly with atomic weapons - this is
something you've carefully constructed to be unstable, they don't
generally occur in nature, for instance (I think atomic piles do, or
The glass example is good though. Glass has this nice thing that if
its bent and you make even a tiny scratch on the stretched surface it
will suffer catastrophic failure because of crack propagation. So
generally its only used in contexts where you don't care about
catastrphic failure, or when you do you create special glass which has
its surfaces in compression and thus doesn't suffer from this kind of
catastrophic failure nearly so easily, and when it does the failure is
less bad (no shards).
But the point is that we have a really good understanding of what
causes this kind of thing and how to avoid it - people write books on
crack propagation and how to avoid it. Computing systems are all
crack propagation, all the time.
Kent Pitman wrote:
> I didn't mean to suggest that Philosophy intended to be a science. I
> meant to say that Xah's suggestion that, paraphrasing, "to understand
> is to make mathematical" does not capture the ability of philosophers
> to capture truths, even vague ones, in useful ways. They make no math
> out of it, yet they do add to our understanding.
It is apparent to me, that you don't know much philosophy, don't know much
about the evolution of philosophy from Greeks to modern. I don't claim to be
an expert at these, but i don't make clueless remarks about things i don't
When we discuss bout philosophy in our context, we can focus two things: its
subjects and its methodology.
In the Greek era, philosophy is the umbrella for all today's science
subjects plus mysticism plus religion. Its methods are observation and crude
reasoning. A good part of philosophy of that era would be under the general
headings of today's physics and psychology and religion.
In 300 years ago era, all "natural sciences" such as physics, astronomy,
linguistics, moved out of philosophy. Metaphysics and mysticism still
remain. The approach are crude science and refined reasoning.
Today, there is little to none philosophical studies as we know the word.
The subjects of classic philosophy either disappeared totally, such as
metaphysics and existence of God, or moved into vast number of disciplines
under the general headings of physics, chemistry, linguistics, social
sciences, mathematics. The diversity and branches are so fine such that one
accomplished mathematician do not understand the next mathematician.
It is very unfortunate that the online encyclopedia britanica.com is no
longer free. Otherwise, my readers can checkout the vast branches of
sciences that was once under the heading of philosophy, not to mention
getting a real treat on the history of philosophy. Though, you can still
purchase a britanica CD or DVD. Good investment! (too bad they don't make
Mac versions. Fuck!)
Today's intellectualism allow no room for scientifically baseless things,
philosophy or not. Get on track! Get a load of me!
(though a good online britanica is gone, but one can still learn a lot
immediately on the web about philosophy or history of. One can immediately
verify my claims. Here's few tips: "logical positivism", "philology,
linguistics", "rationalism", "mathematical philosophy", mind and body
problem, dualism, ... ah just peruse my English vocabulary page too:
there's enough *isms that if you nose each you'll get substantial
understanding of philosophy and history and English too ...
also keep in mind that online info are often low quality, even incorrect or
here's a good one:
Stanford Encyclopedia of Philosophy
A History of Western Philosophy by Bertrand Russell.
(if you buy the book through that link, i get a commission.)
I agree that ommiting those offsets may be a good idea.
On the other side the datastructure could be extended to support
"subsequences" of larger buffers.
'("hallo" *an-1024-char-array* (*buffer* 37 20) ...)
Storing a string or an array is done immediately but you could store a
subsequence of a larger buffer using a list (<buffer> <start> <end>).
This triplet is ready to directly apply SUBSEQ to it (or creating a
(let ((buffer-list '("hallo" *an-1024-char-array* (*buffer* 37 20) ...)))
(apply #'subseq (third buffer-list)))
I'm not sure if this is a particular good idea or if the same thing could
be done better by using displaced arrays.
Listen to Pitman applying his twisted polemics of prevarication and
That no-show class Tim Bradshaw is quick to follow up.
Sorry i started. I don't have time to carefully follow each post. Perhaps
till this weekend.
Goodbye my loves, cum all over your face.
> From: Kent M Pitman <pit...@world.std.com>
> Organization: My ISP can pay me if they want an ad here.
> Newsgroups: comp.lang.lisp
I agree that ommiting those offsets may be a good idea.
> I think the first two of these are not good examples...
I agree that the star example is stretching...
> You could perhaps construct such a thing (if you could construct
> stars...) but it would be ludicrously weird.
It would be cool tho' :)
> Similarly with atomic weapons - this is something you've
carefully > constructed to be unstable,
I would argue this a bit more -- it is possible to construct a crude
fission device if you have the materials to hand.
> they don't generally occur in nature, for instance...
Is this not more to do with the abundance of the source materials?
> (I think atomic piles do, or have done!).
Yes. There is some evidence that a natural fission reactor did occur
www.ans.org/pi/np/oklo. Maybe there were natural fission explosions?
Enough! as I could now be accused of arguing the toss.
[...elided cool points about glass...]
> But the point is that we have a really good understanding of what
> causes this kind of thing and how to avoid it - people write books on
> crack propagation and how to avoid it.
Absolutely. However, even with this knowlege, many people are
*still* blinded by glass each year.
> Computing systems are all crack propagation, all the time.
In three or more dimensions. Super smashing glass. I await the
computing equivalent of triplex.
It is apparent to me that Kent Pitman knows a great deal of philosophy as
such and indeed the philosophies of several disciplines. It is apparent
to me because of the questions he asks. This would not be apparent to
someone who thought that philosophy provided answers.
> Dear Richard Gabriel,
> > ...
> > I think they forgot
> > they were people too.
> So, the whole design pattern and now the new XP wishy-washy thingy are ways
> to encourage stupid people so that we can multiply those incompetent kiddies
> and weenies in the software industry?
> Software today are so fucked up precisely because it is tooo easy. ...
The big feature of internet is information.
> What can we do, folks?
go to public
> If i do not speak up, who can? who would? who is willing?
hmmm. Who knows, what is going on ?
> PS: Patterns were not invented by computer scientists, but by
> architects. If you're interested in the original texts, check out
> Christopher Alexander's "The Timeless Way of Building", and "A Pattern
> Language: Towns, Buildings, Construction".
I am interested, thanks much. You mean that the practice of thinking
of patterns of software development was inspired directly by these
> I am interested, thanks much. You mean that the practice of thinking
> of patterns of software development was inspired directly by these
Yes. Christoper Alexander's group began documenting common
architectural themes as patterns some time ago. Several individuals
(the Gang of Four, mostly) recognized the applicability of this approach
to computer science and Patterns (as we know them) were born.
The architecture patterns are interesting just to see how core concepts
in a different field can be effectively communicated.
> Yes, exactly. Patterns are nothing more than a standardized, digestable
> documentation approach for "best practices". By providing a single
> description of an approach or architecture, patterns provide a good way
> to quickly get up to speed on approaches/solutions you might not be
> familiar with, while at the same time creating a shared terminology that
> makes it much easier to communicate with others in your area.
This is about all patterns are usually considered to be, but
I think in some sense they "should" be something more. The
original inspiration for the patterns thing came from the
works of Christopher Alexander, and the interesting thing
there is that his patterns aren't meant to be used on their
own. They're supposed to fit together to form a "pattern
language", which is a bit like a generative grammar: it
contains "patterns" at many levels, and you're supposed to
be able to start at the top level and gradually follow the
productions down through lower levels until you have a
completely specified system. So the fundamental task in
pattern-making is *not* making patterns, but making pattern
*languages*. This is harder, in the same sort of way as
building a major software system is harder than writing a
single function. So of course it doesn't get done much.
The "pattern languages" that get published are almost all
"little languages"; they explain a way of making a decent
system that covers some rather small amount of ground.
By way of contrast, Alexander's book "A pattern language"
begins with a couple of patterns that are meant to apply at
the *global* scale and works down to the details of how to
construct an individual wall. There's not much in the
software patterns literature with that kind of breadth
That isn't to say that writing isolated patterns isn't a
useful activity. Encapsulating a not-entirely-trivial bit
of "best practice" in a pithy but fairly detailed form
is good, provided it's done well. But the really interesting
objects are -- perhaps I should say "might be" -- pattern languages,
not isolated patterns.
 Actually, he had several co-authors too.
Gareth McCaughan Gareth.M...@pobox.com
.sig under construc
Anderson, P. W. (1972). More is different: Broken symmetry and
the nature of hierarchical structure of science. Science, 177,
It's a wonderfully short read by one of the physicists who cracked
superconductivity, work for which he won the Nobel prize. He
examines the fallacy of throwing all of science's eggs in the
>A good example of this is superconductivity. All the *fundamental*
>stuff to explain superconductivity was probably more-or-less sorted
>out by the late 30s
>(basically nonrelativistic QM), but it took an *awful* long time after
>that for people to really have the faintest idea what was going on - I
>think until the 70s - and there are still, I suspect, huge lacunae in
>our knowledge of how things work.
"In the case of superconductivity, 30 years elapsed between the
time when physicists were in possession of every fundamental law
necessary for explaining it and the time when it was actually
done." (p. 395 of Anderson, 1972)
>And there are many other examples: lots and *lots* of people in
>physics are doing things which are not trying to sort out the
>fundamental laws of the universe, and I think there is an increasing
>feeling that trying to understand the behavious of actual macroscopic
>physical objects like stars and weather systems is important. One of
>the reasons why this hasn't historically been done is that the best
>you can probably do with such systems is to reduce the maths to the
>point where actually doing predictions is merely a very
>computationally demanding task rather than a completely intractible
>one, so until reasonably fast computers became available there was
>really no point in trying to attack such problems - who cared, in
>1900, that you could reduce some problem from 10^20 multiplications to
>10^9, you needed to get it down to 10^4 before you could even think
"The main fallacy in this kind of thinking is that the
reductionist hypothesis does not by any means imply a
Śconstructionistą one: the ability to reduce everything to simple
fundamental laws does not imply the ability to start from those
laws and reconstruct the universe. In fact, the more the elementary
particle physicists tell us about the nature of the fundamental
laws, the less relevance they seem to have to the very real
problems of the rest of science, much less to those of society.
"The constructionist hypothesis breaks down when confronted
with the twon difficulties of scale and complexity. The behaviors
or large and complex aggregates of elementary particles, it turns
out, is not to be understood in terms of a simple extrapolation
of the the properties of a few particles. Instead, at each level
of complexity enturely new properties appear, and the understanding
of the new behaviors requires research which I think is as
fundamental in its natura as any other. That is, it seems to me
that one may array the sciences roughly linearly in a hierarchy,
according to the idea: The elementary entities of science X obey
the laws of science Y. [Š]
"But this hierarchy does not imply that science X is Śjust
applied Y.ą At each stage entirely new laws, concepts, and
generalizations are necessary, requiring inspiration and creativity
to just as great a degree as in the previous one. Psychology is
not applied biology, nor is biology applied chemistry." (p. 393 of
> Jeffrey Palmer wrote:
> > Yes, exactly. Patterns are nothing more than a standardized, digestable
> > documentation approach for "best practices". By providing a single
> > description of an approach or architecture, patterns provide a good way
> > to quickly get up to speed on approaches/solutions you might not be
> > familiar with, while at the same time creating a shared terminology that
> > makes it much easier to communicate with others in your area.
> This is about all patterns are usually considered to be, but
> I think in some sense they "should" be something more.
Oh, one other thing that distinguishes a "pattern" from a
"standardized documentation of best practice": a pattern
is supposed to have a short, memorable name. This is more
important than it sounds; the idea is that knowing a bunch
of patterns provides some common language for a community
to talk about things at a higher level. Patterns thus
play a role a bit like that of abstractions like functions
and macros, but for humans rather than computers. That's
the theory, anyway.
Of course you can name interesting phenomena without
having patterns about them. "Ring buffer", "virtual
machine", "metaobject protocol", etc. So no one is
claiming that providing good names for things is some
new capability patterns have that nothing else had
before. Just that one of the things a pattern can do
is to provide a good name for a thing.
Again, this isn't something existing patterns do all
that well. (Some of them do, even when -- as with
"Singleton" and "Visitor" from the GoF book -- they're
good names for undeserving things. I think the names
"Observer" and "Composite", also from that book, are
useful contributions to the terminology of programming.)
 The "Observer pattern" is where you have a protocol
of callback functions to allow one entity to be
notified when another changes, without that other
entity needing to know anything about the thing
that's observing it. This is harder to think of
in languages without closures.
The "Composite pattern" is where a container contains
objects whose class is a superclass of the container's
class, so that you can do recursive descent uniformly.
This is harder to think of in statically typed languages.
Both of these "patterns" are, in some sense, too easy
in Lisp. Not in the sense that Lisp would be better if
it made them harder; but in languages where you have
to fight harder to do interesting things, it's easier
to notice when you've fought the same fight several
times. I think the *names* "observer" and "composite"
are useful even when you're programming in a language
that doesn't make it a non-trivial exercise to
> The architecture patterns are interesting just to see how core concepts
> in a different field can be effectively communicated.
As well as to show how even well-meaning people in another field can fuck
them over, with all respect due to the GoF.
The term I'm most familiar with for that general concept is "cords",
as described in the Boehm-Demers-Weiser conservative garbage collector
The garbage collector distribution includes a C string
(cord ) package that provides for fast concatenation and
substring operations on long strings. A simple curses- and
win32-based editor that represents the entire file as a cord
is included as a sample application.
is the header file for the cord package, which says (with C comment chars
Cords are immutable character strings. A number of operations
on long cords are much more efficient than their strings.h
counterpart. In particular, concatenation takes constant time
independent of the length of the arguments. (Cords are represented
as trees, with internal nodes representing concatenation and
leaves consisting of either C strings or a functional description of
Note particularly that bit about allowing functional representations
for leaves. In the cords package, "functional" leaves are actually
implemented in C as closures(!!) which are (virtual) accessors for
the strings they represent. Again from "cordh.txt":
/* Cords may be represented by functions defining the ith character */
typedef char (* CORD_fn)(size_t i, void * client_data);
In CL you could do that, too. Or depending on your needs, maybe make the
closures be just thunks that when called return the data they represent
as strings or as further cords of strings and/or thunks. I've seen
several server-side dynamic HTML systems (mostly in Scheme, as it happens)
that do something similar when generating web pages -- that is, there's
a generation phase that produces a cord-like tree of strings and/or
closures, and an output phase that walks the tree outputting the strings
and calling the closures [usually thunks], which return strings. (Or more
So you might want to consider adding these two features of "cords" --
trees [possibly (re)balanced] and closures -- to your "buffer-lists".
> This is about all patterns are usually considered to be, but
> I think in some sense they "should" be something more. The
> original inspiration for the patterns thing came from the
> works of Christopher Alexander, and the interesting thing
> there is that his patterns aren't meant to be used on their
> own. They're supposed to fit together to form a "pattern
> language", which is a bit like a generative grammar: it
> contains "patterns" at many levels, and you're supposed to
> be able to start at the top level and gradually follow the
> productions down through lower levels until you have a
> completely specified system. So the fundamental task in
> pattern-making is *not* making patterns, but making pattern
> *languages*. ...
I agree. Pattern languages are the glue that holds patterns together.
I find it difficult to write patterns without automatically placing them
into a pattern language; the context provided by the pattern language
allows for a more expressive presentation of the system complexity
(e.g., pattern languages cleanly support the documentation of alternate
solutions to a single problem, with a clear distinction based on
performance, or whatever is important to you).
I approach almost all documentation in this fashion now, regardless of
language, and I have found it to be very effective. Then again, I
probably take a more pragmatic approach to patterns, as opposed to some
in the industry (which is probably what prompted this thread in the
Now, that's weird.
What did you bring that book I didn't want to be read to out of about
Down Under up for?
> * tfb+g...@tfeb.org (Tim Bradshaw) wrote:
> | ([...] almost none of the physicists who build the foundations for
> | engineering do [know what a formal proof is]. [...] It's only the
> | CS people who get so hung up about this, because they suffer from
> | *really bad* physics envy.)
> Now, that's weird.
Why? People who envy something are often not very well informed about
the actual nature of that something.
Kent: Sorry my remarks tricked you into engaging Xah. He is endearing in his
way, and it is possible to get him to engage seriously, but rarely on a
stage like this one. He has an interesting talent for writing - I have no
evidence of his mathematical abilities. I rather like the guy, though he is
like a high-speed roller coaster with dynamically and randomly changing
turns and dips.
A few years ago I wrote an essay on tubes - Wired asked me to write it, but
the editor who did so left before they were ready to publish it. It's here:
Yes, exactly. I think the term comes from some criticism of
?sociology? which got enormously hung up on hugely complex but mostly
meaningless mathematice because it wanted to be a `proper science' and
saw that this was what physicists did. Of course what they missed was
both that the hairy maths has to mean something, and that, actually,
phycisists really are often doing something else, like trying to get
some kind of mental picture of what is happening, except it's all in 4
or more dimensions and so you can't really draw it on the whiteboard
too well. And most physics is extremely mathematically unrigorous,
too, the general attitude is `well, this obviously works, and the
mathematicians will sort out the boring details in 50 years or so' -
the Dirac delta function is a good example. Physicists are a cavaliar
lot, on the whole.
> And most physics is extremely mathematically unrigorous,
>too, the general attitude is `well, this obviously works, and the
>mathematicians will sort out the boring details in 50 years or so' -
>the Dirac delta function is a good example.
...and hey, this is the small part that we get to just accept so that we can
then go on and measure some stuff.
>Physicists are a cavaliar lot, on the whole.
I think they would like to own cavaliars (sic) but are more likely to ride an
aging sit-up-and-beg bike...
 the other 10% then don't understand what the other 90% are can do and then
go on to develop theories that has an increasing small chance of actually being
measured even with spending monies comesurate with the GDP of a medium sized
country in south east Asia.
> psychological phenomena may prove to be the
> sort of thing for which the scientific method is just ill-suited.
The above sentence is -- shall we be dramatic? -- oxymoron.
There are lots of the dogmatic dullards types, who like to make everything
as "scientific". Therefore, you see these dullish scientists and scholars
who would _define_ _scientific_ by some dogmatic criterions.
Like, they would say, science is such and such that meet such and such
criterions, such as being verifiable. Such and such, and such and such, that
such science can not and is not supposed to answer certain such and such
questions. Such and such, are the drools of these dullards.
Let me make an insight here:
There is absolutely no truth or facts in this world. Every supposed truth,
facts, or whatnot, are simply agreements of the majority. For example,
1+1==2, ain't that the truth? It depends on who you ask. There are artists
and poets, who will give you grandiloquent and surefire answers. Then
there's pundits, who will make smart asses of themselves. Even among the
greatest mathematicians and logicians and philosophers, it will come to
grave hair-pulling and eye-ball-gauging debates about foundations, little
details, paradoxes, schools of thoughts, and not to mention friend or foe.
(as we can see in history.) And if you bribe an Oxford fella or IBM fella,
then he will prove one plus one will equal to three, and retire with your
money. After all, we are humans beings of flesh and blood. Ain't truths a
product _our_ brain that changes depending on which philosopher is talking?
What science truly is or is not, is not for people to define and qualify as
by some dogmatic criterions. This goes for all questions in life; regardless
whether it is an answerable or technical question.
For all practical and theoretical purposes, scientific is: USE YOUR BRAIN.
When you use your brain on something, that's scientific.
What my insight illustrates is technically a philosophical view point that
truths are human creations. For those of your average intellects, the
practical moral being: do not fall for any dogma; simply use your brain, and
judge for yourself.
Question: What is not scientific?
Answer: not using your brain.
Q: For examples?
A: Mysticism, occultism, OOP fads.
Q: But aren't there things not scientifically understood but useful, like
A: Use your brain.
Q: So, i just use my brain, then whatever the conclusion will be my answer?
Q: That's why even the greatest mathematicians couldn't agree on
mathematical things. Is that right?
A: You got it!
Q: is Design Patterns good?
Q: But i used my brain, and i think it is worth a try. What's going on?
A: Use your brain.
Q: Oh, so i should use my brain and JUDGE FOR MYSELF?
Q: Do you have any final comment on Design Patterns?
A: When we have a world where for each software bug the engineer will be
penalized for one month's salary, then we shall see if more math knowledge
prevails, or the Design Patterns and XP type of utter crap survives.
Q: why should we be believe you? oh, i guess it's "use your brain"??
A: From now on it's $5 per question.
Q: Should we also doubt about the "use your brain" dogma?
> Dear intellects,
> > psychological phenomena may prove to be the
> > sort of thing for which the scientific method is just ill-suited.
> The above sentence is -- shall we be dramatic? -- oxymoron.
> There are lots of the dogmatic dullards types, who like to make everything
> as "scientific". Therefore, you see these dullish scientists and scholars
> who would _define_ _scientific_ by some dogmatic criterions.
> Like, they would say, science is such and such that meet such and such
> criterions, such as being verifiable. Such and such, and such and such, that
> such science can not and is not supposed to answer certain such and such
> questions. Such and such, are the drools of these dullards.
> Let me make an insight here:
> There is absolutely no truth or facts in this world. Every supposed truth,
> facts, or whatnot, are simply agreements of the majority. For example,
> 1+1==2, ain't that the truth? It depends on who you ask. There are artists
> and poets, who will give you grandiloquent and surefire answers. Then
> there's pundits, who will make smart asses of themselves.
As Dave Letterman once asked Rush Limbaugh: "don't you ever think that
maybe you are a bit of a hot-air ballon?" :)
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
In the oft-quote phrase from Alan Kay, "The best way to predict the
future is to invent it."
There is, of course, the lesser known phrase from Bill Gates(*), "The best
way to invent the future is to co-opt/buy/steal it."
* This attribution is completely spurious, made for the purposes of humor
and point making. The acutal phrase is, "Will no one rid me of this
troublesome antitrust lawsuit?" and it was probablly Balmer who said
I thought Bill Gates' take on it was "the best way to predict the future
is to reinvent it".
> So I think Lisp programmers have to decide whether their goal is to
> get rich, or to popularize Lisp. Even if you correctly identify the
If Lisp gains a reputation for making people rich, it will quickly
become popular. Paul Graham is just one person, not enough to give
Lisp such a reputation. We need hordes of Lisp millionaires.
Why don't we already have hordes of Lisp millionaires? What is the
invisible obstacle standing in the way of this logically-expectable
You can't use Lisp and work for Bill. You have to work for Bill to get
rich, he has all the money now.
Not so sure about that; you can target Bill's platform with Lisp.
Provided at least a majority of them are satisfied with the language that
made them rich and do not feel the urge to create their own pet languages.
| Why don't we already have hordes of Lisp millionaires?
Perhaps because they do not want to credit Lisp with it?
> If Lisp gains a reputation for making people rich, it will quickly
> become popular. Paul Graham is just one person, not enough to give
> Lisp such a reputation. We need hordes of Lisp millionaires.
> Why don't we already have hordes of Lisp millionaires? What is the
> invisible obstacle standing in the way of this logically-expectable
The really interesting metrics is the ratio (/ millionaires programmers) and
to compute it for Java, C++, Lisp, Python, etc.
> You can't use Lisp and work for Bill.
Are you sure? Surely you can use Haskell and work for Bill.
> You have to work for Bill to get rich, he has all the money now.
If he had all the money, it would be worthless.
Ah, but you forget that not all the people who got their money from
Bill applied for jobs with him. For a while in the 90's in Seattle,
one commonly-seen business plan was "make a company that does well
enough to make Bill want to buy it to either make it his or crush it".
If you did this with Lisp, you could get some of Bill's money as well
as with any other language. If he bought you to keep whatever you
made, he'd probably have his minions rewrite it in C++, but presumably
you already figured out the design, so this would even be a reasonable
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
"Thomas F. Burdick" wrote:
> Ah, but you forget that not all the people who got their money from
> Bill applied for jobs with him. For a while in the 90's in Seattle,
> one commonly-seen business plan was "make a company that does well
> enough to make Bill want to buy it to either make it his or crush it".
> If you did this with Lisp, you could get some of Bill's money as well
> as with any other language.
Quibble Alert: Hang on, what if Bill goes for the crush option on me?
Can you imagine if Bill decided to do a Visual Lisp? There'd go the
> Why don't we already have hordes of Lisp millionaires? What is the
> invisible obstacle standing in the way of this logically-expectable
I know a couple of people who have started successful companies using
Lisp as a technology, and are (I'm pretty sure) millionaires quite a
few times over.
In both cases, the main ingredients for success were:
- being pretty damn smart
- finding a complex domain that doesn't have good tools yet
- understanding that domain thoroughly
- building a solution in Lisp
- selling the solution into the market
Knowing Lisp is the least of it really, but Lisp does enable a smart
person to quickly build a solution to a complex problem, with one or
a few developers and maybe without external funding. That's a good way
to get rich.
> 5 Use iteration rather than recursion to scan a sequence one element at a
> time. (Reserve recursion for situations where you _require_ a stack.)
> I.e., Common Lisp is not a dialect of Scheme.
I think that higher-order functions are also useful, and for some
purposes recursion is more easily understood than iteration.
BPT <b...@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
i started to give my views on patterns and XP in this thread, then it
got ramified by someone into a hogwash discussion that revolves around
attacking the word "mathematics".
I like to make a coherent summary of my views on the Design Patterns
and eXtreme Programing stuff.
In my previous articles
> Message-ID: <B826DEE2.489D%x...@best.com>
> Date: Mon, 26 Nov 2001 01:46:13 GMT
> Subject: Re: Design patterns for Lisp
and other posts posted here recently, their contents are summarized
and expanded as follows:
(1) Patterns and XP are wishy-washy, unscientific, unproven, and
without any mathematical basis.
(2) there are enough applied mathematics in computer science for a
life-time of study.
(3) The programers in computing industry lacks sufficient training.
They lack sufficient computer science background, lack mastery of
their tools (languages, protocols etc.), and their knowledge of their
domain/field are often poor.
(4) It is extremely easy and common for non-qualified people to become
a software professional, who will gradually churn out significant
quantity of codes. (this is in contrast with other engineering
disciplines. A desk-top computer is sufficient to send a interested
laymen into software industry.)
(5) Software engineering is ten thousand times easier than physical
engineering such as bridge, airplane, tunnel, train, ship... building.
(6) computer do not make mistakes, people do, and sloppiness is a
common attitude in software industry.
(7) software licenses are irresponsible. The vast majority of software
license agreements contains clauses that don't guarantee it works.
The quality of software depends on primarily of two aspects:
* Programer's mastery of the tools. (programing language, protocols,
operating system ...)
* Programer's expertise/knowledge of his field/domain.
Programers should master their tools. Know every detail of their
language well. Then, programer should strive to accumulate knowledge
of their respective domain.
When a programer masters his tools and domain expertise, he obtains
the expertise any Design Pattern tries to describe. Design Patterns is
a snake oil. Icing on the cake. Fluff. Wishful thinking. Slouch's
drug. Idiot's placebo. And that's not all.
Design Patterns is the opium of computing industry. From an addicted
individual or company, it may have improved a code or helped a team.
But on the whole, it hinders the propagation of quality languages. It
stops advancements of language design. It reduces the awareness of
real education needs like mastering languages and domain expertise. It
is a fucking spoon-feeding formula designed to retard the mundane and
drug the smart. It curbs creation ability. It is a plague, a bad-ass
fashion phenomenon; a jargon-riding dimwit-pleasing epidemic.
For the record, the "Gang of Four" mentioned in this thread who wrote
the _Design Patterns_ book are:
Erich Gamma <-- fucking ass one
Richard Helm <-- fucking ass two
Ralph Johnson <-- fucking ass too
John Vlissides <-- fucking ass also
These people will be remembered as criminals in the computing history,
along with Larry Wall and those fucking jackasses who distributed
their home work now known as Unix. [criminals here is defined as those
who bring damages to society, including hampering progress in a
I have mentioned above that software engineering is significantly
easier then bridge engineering. Let's drill on this a bit.
When we say A is easier then B, we have to define what we mean by
"easier". Before we can say what we mean by "easier", we need to
understand the nature A and B comparably. We can consider Software
Writing vs Bridge Building. This would be on easy one. We can also
consider Software Engineering vs Bridge Engineering. This will be a
bit difficult. We'll need to further discuss what does "engineering"
really encompasses here. Coming up with a good definition can be quite
involved. Instead of drilling on a sensible definition, I'll simply
mention a few comparisons of things in software engineering and bride
engineering below. The following items will be somewhat hodgepodge.
* Material cost.
* Size of team.
* Cost of raising (educating/training) engineers.
* The nature involved.
In building bridges, there are lots of unknown factors. There's wind,
storm, flood, earthquake all of which we cannot fully control, and can
only predict in a limited way. It will involve many science
disciplines. geo-science, physics, aerodynamics. Software building
requires much lesser disciplines, and significantly much less people.
Build bridges is costly. It can only be done once, and the one time
must be right. It cannot go by trial-and-error. Software building on
the other hand, can trial-and-error all the way. It's essentially
The essence of computers can be likened to an abacus. You push the
beads and you readout the values. There are no chance events. No storm
or flood to worry about. The information are one hundred percent known
to you, and you control it one hundred percent one hundred percent of
Which one is ten thousand times easier do you think? Is it bridge
engineering, or software engineering?
In the above, i have touched on the problem of software licenses.
Namely, they outright disclaims the functionality of the software.
I propose that we raise an awareness of this situation, so that the
public (consumer) will start to demand more responsible software
... my time's up. Next time when i have some time, reminds me to write
on WHY software industry is the way it is, and why the solution is to
first raise the awareness of irresponsible licenses. This should be
the last message in this episode.
Goodbye my love, cum all over your face.
Feast your eyes. Note the ominous all-caps.
Excerpt of License agreement from Mac OS 9:
4. Disclaimer of Warranty on Apple Software. You expressly
acknowledge and agree that use of the Apple Software is at your sole
risk. The Apple Software is provided "AS IS" and without warranty of
any kind and Apple and Apple's licensor(s) (for the purposes of
provisions 4 and 5, Apple and Apple's licensor(s) shall be
collectively referred to as "Apple") EXPRESSLY DISCLAIM ALL WARRANTIES
AND/OR CONDITIONS, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES AND/OR CONDITIONS OF MERCHANTABILITY OR
SATISFACTORY QUALITY AND FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT OF THIRD PARTY RIGHTS. APPLE DOES NOT WARRANT THAT
THE FUNCTIONS CONTAINED IN THE APPLE SOFTWARE WILL MEET YOUR
REQUIREMENTS, OR THAT THE OPERATION OF THE APPLE SOFTWARE WILL BE
UNINTERRUPTED OR ERROR-FREE, OR THAT DEFECTS IN THE APPLE SOFTWARE
WILL BE CORRECTED. FURTHERMORE, APPLE DOES NOT WARRANT OR MAKE ANY
REPRESENTATIONS REGARDING THE USE OR THE RESULTS OF THE USE OF THE
APPLE SOFTWARE OR RELATED DOCUMENTATION IN TERMS OF THEIR CORRECTNESS,
ACCURACY, RELIABILITY, OR OTHERWISE. NO ORAL OR WRITTEN INFORMATION
OR ADVICE GIVEN BY APPLE OR AN APPLE AUTHORIZED REPRESENTATIVE SHALL
CREATE A WARRANTY OR IN ANY WAY INCREASE THE SCOPE OF THIS WARRANTY.
SHOULD THE APPLE SOFTWARE PROVE DEFECTIVE, YOU (AND NOT APPLE OR AN
APPLE AUTHORIZED REPRESENTATIVE) ASSUME THE ENTIRE COST OF ALL
NECESSARY SERVICING, REPAIR OR CORRECTION. SOME JURISDICTIONS DO NOT
ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION MAY
NOT APPLY TO YOU. THE TERMS OF THIS DISCLAIMER DO NOT AFFECT OR
PREJUDICE THE STATUTORY RIGHTS OF A CONSUMER ACQUIRING APPLE PRODUCTS
OTHERWISE THAN IN THE COURSE OF A BUSINESS, NEITHER DO THEY LIMIT OR
EXCLUDE ANY LIABILITY FOR DEATH OR PERSONAL INJURY CAUSED BY APPLE'S
5. Limitation of Liability. UNDER NO CIRCUMSTANCES, INCLUDING
NEGLIGENCE, SHALL APPLE BE LIABLE FOR ANY INCIDENTAL, SPECIAL,
INDIRECT OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO THIS
LICENSE. SOME JURISDICTIONS DO NOT ALLOW THE LIMITATION OF INCIDENTAL
OR CONSEQUENTIAL DAMAGES SO THIS LIMITATION MAY NOT APPLY TO YOU. In
no event shall Apple's total liability to you for all damages exceed
the amount of fifty dollars ($50.00).
GNU General License, excerpt:
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO
WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY
KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME
THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY
AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU
FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF
SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
END-USER LICENSE AGREEMENT FOR MICROSOFT WINDOWS 98, excerpt:
Microsoft warrants that (a) the SOFTWARE PRODUCT will perform
substantially in accordance with the accompanying written materials
for a period of ninety (90) days from the date of receipt, and (b) any
Support Services provided by Microsoft shall be substantially as
described in applicable written materials provided to you by
Microsoft, and Microsoft support engineers will make commercially
reasonable efforts to solve any problem. To the extent allowed by
applicable law, implied warranties on the SOFTWARE PRODUCT, if any,
are limited to ninety (90) days. Some states/jurisdictions do not
allow limitations on duration of an implied warranty, so the above
limitation may not apply to you.
Microsoft's and its suppliers' entire liability and your exclusive
remedy shall be, at Microsoft's option, either (a) return of the price
paid, if any, or (b) repair or replacement of the SOFTWARE PRODUCT
that does not meet Microsoft's Limited Warranty and that is returned
to Microsoft with a copy of your receipt. This Limited Warranty is
void if failure of the SOFTWARE PRODUCT has resulted from accident,
abuse, or misapplication. Any replacement SOFTWARE PRODUCT will be
warranted for the remainder of the original warranty period or thirty
(30) days, whichever is longer. Outside the United States, neither
these remedies nor any product support services offered by Microsoft
are available without proof of purchase from an authorized
NO OTHER WARRANTIES.
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, MICROSOFT AND ITS
SUPPLIERS DISCLAIM ALL OTHER WARRANTIES AND CONDITIONS, EITHER EXPRESS
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OR
CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE
AND NON-INFRINGEMENT, WITH REGARD TO THE SOFTWARE PRODUCT, AND THE
PROVISION OF OR FAILURE TO PROVIDE SUPPORT SERVICES. THIS LIMITED
WARRANTY GIVES YOU SPECIFIC LEGAL RIGHTS. YOU MAY HAVE OTHERS, WHICH
VARY FROM STATE/JURISDICTION TO STATE/JURISDICTION.
LIMITATION OF LIABILITY.
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL
MICROSOFT OR ITS SUPPLIERS BE LIABLE FOR ANY SPECIAL, INCIDENTAL,
INDIRECT, OR CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING, WITHOUT
LIMITATION, DAMAGES FOR LOSS OF BUSINESS PROFITS, BUSINESS
INTERRUPTION, LOSS OF BUSINESS INFORMATION, OR ANY OTHER PECUNIARY
LOSS) ARISING OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE
PRODUCT OR THE FAILURE TO PROVIDE SUPPORT SERVICES, EVEN IF MICROSOFT
HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. IN ANY CASE,
MICROSOFT'S ENTIRE LIABILITY UNDER ANY PROVISION OF THIS EULA SHALL BE
LIMITED TO THE GREATER OF THE AMOUNT ACTUALLY PAID BY YOU FOR THE
SOFTWARE PRODUCT OR U.S.$5.00; PROVIDED, HOWEVER, IF YOU HAVE ENTERED
INTO A MICROSOFT SUPPORT SERVICES AGREEMENT, MICROSOFT'S ENTIRE
LIABILITY REGARDING SUPPORT SERVICES SHALL BE GOVERNED BY THE TERMS OF
THAT AGREEMENT. BECAUSE SOME STATES/JURISDICTIONS DO NOT ALLOW THE
EXCLUSION OR LIMITATION OF LIABILITY, THE ABOVE LIMITATION MAY NOT
APPLY TO YOU.