Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Checking for Errors Before Run Time

394 views
Skip to first unread message

Chris Perkins

unread,
Nov 20, 2001, 3:12:28 PM11/20/01
to
As I've been learning LISP over the last 6 months or so, I've been
blown away by its power and grace. But there is one thing that has
been bothering me, but it may just be my C++/Java approach.

Programmers wanting to make their code solid often use Design By
Contract to assert input and output contracts on functions. I see
LISP has this, and that's great.

But, Java and C++, by their nature, can perform some basic contract
enforcement at compile time, rather than waiting for runtime.
Specifically, the compiler will bleat for violations of access
(public/private), argument count, and argument type.

LISP compilers seem to throw warnings for argument count, but that's
it.

I would venture that most C++/Java programmers *like* type safety and
see it as a real advantage - they are warned of stupid mistakes at
compile time, rather than having to vette them out at runtime. To my
mind, C++/Java programmers gain the side effect of a simple
preconditional contract on their arguments by using types. And, bonus
for them, that contract is verified at compile time, rather than at
runtime.

Does LISP have any way of doing this? I'm not proposing abusing type
specifications to achieve this, but is there anyway to have simple pre
and post conditional contracts verified outside of runtime?

I would love a system to be able to specify pre & post conditional
contracts, class invariants, etc. and have them all checked by simply
issuing a command at the prompt. While I'm fantasizing, in an ideal
system, contracts that are 100% verifiable would be taken out of the
code (why slow it down?), and the rest would be converted to assert
clauses to continue runtime monitoring.

Chris
Media Lab, Inc. / As Is Software, Inc.

Thom Goodsell

unread,
Nov 20, 2001, 3:53:47 PM11/20/01
to
The current thread with the subject "Using type declarations in safety
checks" is discussing exactly this topic. I'd post a reference, but I
can't figure out how to get message IDs out of Google Groups.

Thom

--
Thom Goodsell tgoo...@cra.com
Scientist (617) 491-3474 x574
Charles River Analytics http://www.cra.com/

cbbr...@acm.org

unread,
Nov 20, 2001, 3:57:05 PM11/20/01
to

Most implementations seem not to do _vast_ amounts of "contract
verification," with CMUCL being the notable exception.

Supposing you write a function that begins:

(defun db-put (db key datum
&key (start 0) end db-start db-end
(transaction *transaction*) (flags 0))
(declare (type db db) (string key datum)
(type (or transaction null) *transaction*))

CMUCL does some validation, when you run COMPILE-FILE, to see if
arguments db, key, datum, and *transaction* are used, internally, in a
manner conforming with those declarations.

Supposing I set up a _call_ that doesn't conform, as with:

(db-put "db" "key" "datum")

The compiler gripes back at me thusly:

In: DB-PUT "db"
(DB-PUT "db" "key" "datum")
Warning: This is not a (VALUES &OPTIONAL DB &REST T):
"db"

In many cases, further type inference is done by CMUCL. For instance,
it is very likely going to infer that the FLAGS parameter is a NUMBER,
based both on the default, and on the sorts of functions that get
applied to FLAGS within the function.

That's one direction whereby some validation takes place.

Another would be via CLOS. If you use DEFCLASS to define types, and
DEFMETHOD to declare methods to apply to those types, then type
checking gets done quite automatically any time code is written and
compiled. Invalid applications of methods often can be detected at
compile time, which should provide a fair bit of what you're after.

All that being said, it's often more useful to write code in a really
generic manner, not caring about types, and then tighten things down
later _if it proves necessary_.

That's probably as much as you're going to get. If you want
Eiffel-style DBC, then perhaps what you want to use is in fact Eiffel.
If you want ML-style static type checking, then you may want to use
ML. Expecting Lisp to conform to identical design criteria can't be
expected to be reasonable.
--
(reverse (concatenate 'string "moc.enworbbc@" "enworbbc"))
http://www.cbbrowne.com/info/linux.html
Rules of the Evil Overlord #231. "Mythical guardians will be
instructed to ask visitors name, purpose of visit, and whether they
have an appointment instead of ancient riddles.
<http://www.eviloverlord.com/>

Bradford W. Miller

unread,
Nov 20, 2001, 4:42:48 PM11/20/01
to
Not exactly on point, but see Mitsubishi Electric Research Labs TR 91-04
"Some Useful Lisp Algorithms: Part 1" by Richard C. Waters, where he gives
an implementation for automatic regression testing of programs (post
compile), and a way to determine how good your test coverage is by analyzing
your program source.

The most immediate problem with doing things exactly as you suggest is just
that other than CMU Common Lisp, nobody I'm aware of has implemented good
type checking for lisp programs. I think CMU's dates back to spice lisp, so
presumably you can get the code, and nothing prevents you from writing your
own version of defun to wire it in. (There are one or more PD code walkers).

An alternative is just to write your lisp functions to correctly handle
types that don't match their expected arguments. Robust code is better than
contracted code, for most purposes. Ah, the metaphor!


On 11/20/01 2:12 PM, in article ¿y´RTICLE], "Chris Perkins"

Erik Naggum

unread,
Nov 20, 2001, 5:49:59 PM11/20/01
to
* Chris Perkins

| But, Java and C++, by their nature, can perform some basic contract
| enforcement at compile time, rather than waiting for runtime.
| Specifically, the compiler will bleat for violations of access
| (public/private), argument count, and argument type.

They also have a prohibitively expensive compilation process compared to
Common Lisp. This is _why_ it is important in those languages to make
sure that runtime is a less expensive debugging environment. Comparisons
of language tend to forget their contexts and evolution completely, and
take one of these for granted while the other is treated like a stranger
in a strange land. This is why you should strive to forget where you
came from and try to figure out how your new language came to be and why
what it does is natural in its environment.

| I would venture that most C++/Java programmers *like* type safety and see
| it as a real advantage - they are warned of stupid mistakes at compile
| time, rather than having to vette them out at runtime.

That is because so many things are mistakes that no human being in his
right mind can be expected to figure out are mistakes. Languages that
are so hard only compilers (that are so hard to write that no human being
in his right mind can do it) can figure out whether a program is correct,
should simply not be used by human beings. I happen to think Java is
pretty good this way while C++ is absolutely insane.

| To my mind, C++/Java programmers gain the side effect of a simple
| preconditional contract on their arguments by using types. And, bonus
| for them, that contract is verified at compile time, rather than at
| runtime.

A less elaborate contract can actually be remembered and understood.

| Does LISP have any way of doing this? I'm not proposing abusing type
| specifications to achieve this, but is there anyway to have simple pre
| and post conditional contracts verified outside of runtime?

I think you should re-examine the reasons you are obsessing against
run-time. Run-time may hurt in C++ because debugging is so hard, but
learning from pain is not a very good way to learn the right thing.
(The only thing that appears to work is to make it painful _not_ to
think, because it is appears to be painful to many people to think.)
Because you break to the debugger in Common Lisp and you can debug much
more accurately when you do not compile your Common Lisp code, so the
compiler is actually even less important than it might appear to be.

| I would love a system to be able to specify pre & post conditional
| contracts, class invariants, etc. and have them all checked by simply
| issuing a command at the prompt. While I'm fantasizing, in an ideal
| system, contracts that are 100% verifiable would be taken out of the code
| (why slow it down?), and the rest would be converted to assert clauses to
| continue runtime monitoring.

One of the things you learn from writing serious Common Lisp programs is
that you never take out the "checks and balances" part, because it does
not slow the program down appreciably (use a profiler to find out where
your performance is less than optimal -- it is not where you think it is,
and certainly not in execution safety, which turns into crashes and long
debug cycles when you remove them, reduce the safety setting, and ask for
higher speed optimization, and all errors were not taken out of the code)
and because even if you test your own code, you make it harder for others
(including yourself) to use it, whether in that "reuse" fashion, or when
modifying the program sometime later on.

Coming from the C++ world, it can take a while to get used to programs
that do not crash and burn. Likewise, returning from Common Lisp to C++
is _amazingly_ painful.

///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.

Thomas F. Burdick

unread,
Nov 20, 2001, 8:29:31 PM11/20/01
to
Erik Naggum <er...@naggum.net> writes:

> One of the things you learn from writing serious Common Lisp programs is
> that you never take out the "checks and balances" part, because it does
> not slow the program down appreciably (use a profiler to find out where
> your performance is less than optimal -- it is not where you think it is,

This is a lesson that dates from the early 1970's, AFAICT. I'm
completely amazed at how many programmers need to be constantly
reminded of this.

> and certainly not in execution safety, which turns into crashes and long
> debug cycles when you remove them, reduce the safety setting, and ask for
> higher speed optimization, and all errors were not taken out of the code)

Well, unless it is in the execution safety. But then it would only be
in the inner loops. Which, if you find your code doing something
stupid, you carefully arrange for the code around the loop to ensure
the safety of the inner loop, comment this prominently, and locally
turn speed all the way up and safety all the way down. There's really
no need to do this anywhere else, though.

--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'

cp

unread,
Nov 20, 2001, 9:12:32 PM11/20/01
to
> They also have a prohibitively expensive compilation process compared to
> Common Lisp. This is _why_ it is important in those languages to make
> sure that runtime is a less expensive debugging environment.
Comparisons
> of language tend to forget their contexts and evolution completely, and
> take one of these for granted while the other is treated like a stranger
> in a strange land. This is why you should strive to forget where you
> came from and try to figure out how your new language came to be and why
> what it does is natural in its environment.

I'm not necessarily advocating type specifications in Lisp. I'm simply
trying to write better and more solid code, which is why I have come to Lisp
in the first place. I don't necessarily care to introduce type
specifications to Lisp, but I would be interested in upstream (not runtime)
verification of simple and complex contracts.

The sooner I can discover a typo or an error, the better. I believe this is
true for any language.

> Coming from the C++ world, it can take a while to get used to programs
> that do not crash and burn.

While it is true that I don't have to restart my machine when I miscode in
Lisp, I still "crash and burn" - I incorrectly use a form - I pass arguments
in the wrong order, etc. Little things that haunt every programmer - even
Lispers. And, I assert, little things that *could* be detected by my
language or tool, instead of me, my debugger, or my users.


But, as has been suggested to me, I will read up on CLOS, I will check
Richard Waters' article on regression testing, and I'll muck about a bit.


On an aside, I've always felt that Design Patterns, DBC, and UML are, at an
idealogical level, fundamentally tied together. They are, in a sense,
programmers struggling to find a "form" or "description" of both the shape
of their code and the code itself. Nowadays, when I think about that
struggle I think to myself "Hmmmmm...that sounds like the type of problem
Lisp would be well suited to solve"


Chris Perkins

unread,
Nov 20, 2001, 9:34:00 PM11/20/01
to
I sent that last message before I was done when I was trying to fix my ID.
cp is me, Chris Perkins.


> Nowadays, when I think about that
> struggle I think to myself "Hmmmmm...that sounds like the type of problem
> Lisp would be well suited to solve"

Let me clarify: Lisp seems like it could solve that problem by someone
actively pursuing it and writing a solution. Merely using Lisp does not
solve the problem (though it is a step in the right direction).

Chris Perkins

Kenny Tilton

unread,
Nov 20, 2001, 9:54:06 PM11/20/01
to

cp wrote:
> While it is true that I don't have to restart my machine when I miscode in
> Lisp, I still "crash and burn" -

No, you just crash, not necessarily burn. It's more like that simulator
in the TV ad where the guy driving the beer truck goes off a cliff
because he is eyeballing a simulated blonde bombshell. The instructor
gives you hell, rewinds the sim to before the babe comes into view, you
keep yer eyes on the road for the most part.

I have spent hours working on a new grid widget without ever closing the
main app window. I just hit the button that leads to the widgets
creation, back out and start again to see the effect of any changes. If
in a rare case I am just changing the paint function, all I need do is
cover uncover the widget.

Even if I crash (the subject at hand), I do not burn. I poke around
sometimes for a few minutes or even an hour, make all the changes I
want, recompile--then look back at the backtrace to see how far back to
restart to pick up the change.

Sometimes I cannot because I use Semaphors a lot and these are
structures that arrange for a slot to be efficiently envalued by a
formula--if I die in a formula, fixing the formula in the source does
not change the lambda function that died, so I just "burn" the window
and re-run. without linking.

I once ported Semaphors to C++ (and Java) and I indeed experienced the
advantages of having the compiler dopeslap me around, but smarter folks
than me say I cannot have it both ways--well, Dylan is a stab at that, I
guess. And if I have to choose, well...

as you say, we are all trying to figure out the best way to program
these things. i see a parallel between Lisp and the mountaineering
technique of Reinhold Messner, who subsituted speed for stuff (gear,
food, oxygen) to conquer big peaks. Instead of seige tactics in which
teams of climbers went up and down ferrying supplies between higher and
higher camps, and he is partner just went for it. This meant climbing
unroped on stuff that would have me pissing in my pants. Messner's
thinking was that usually it's the weather that kills climbers, and
seige tactics ineluctably put one on the mountain longer.

So basically Messner used skill and an insane degree of conditioning to
maximize speed and minimize exposure to the crucial hazard, weather. And
that approach is incompatible with seige climbing.

kenny
clinisys

Erik Naggum

unread,
Nov 20, 2001, 10:49:04 PM11/20/01
to
* Chris Perkins

| I'm not necessarily advocating type specifications in Lisp.

I do not follow you. Type specifications are already available to you in
Common Lisp. Why use an inferior Lisp without them?

Or do you mean that you want static type checking? That you cannot get
very easily.

Or do you mean that you do not want to add type declarations in the true
sense of a declaration -- you _declare_ its type? Why not? If you have
knowledge you withhold from the compiler, that can only be your loss.

| The sooner I can discover a typo or an error, the better. I believe this
| is true for any language.

I disagree, probably to your surprise. The earlier an error is detected,
the _firmer_ the determination that it is an error is, and the simpler
the world must be in which statements are made. For instance, we have
the option in Common Lisp of redefining a function between the definition
the compiler knew about at compile-time of a caller and the actual time
it was called. This would require a total re-compile in languages that
consider such things an error with no option to negotiate. In the long
history of programming languages, indeed human history, there are people
who insist that they know what is true and good, and who seek to limit
other people's opportunity to find out what other things are true and
good. These generally call anything they disagree with "errors" and make
people angry at their compilers or computers. Then there are people who
only think they know what is wrong, and while they have their own ideas
about what is true and good, they only seek to limit other people's
opportunity to do wrong and harmful things. These generally do not think
things are errors unless they are _clearly_ wrong and harmful. If not
clearly, they may issue a warning or a style-warning. (E.g., omitting
the value of the final branch of a cond or case expression when the value
returned is stored in a place that is declared not to accept nil as a
possible value, might be a style warning because the compiler cannot know
that you do not know better.)

| While it is true that I don't have to restart my machine when I miscode in
| Lisp, I still "crash and burn" - I incorrectly use a form - I pass arguments
| in the wrong order, etc.

Then you have a _really_ bad Common Lisp environment.

| Little things that haunt every programmer - even Lispers.

No, not really. You see, a Common Lisp programmer who is uncertain about
the arguments to a function he is about to call, asks the system for the
lambda list. If he changes the lambda list in any way, he calls upon the
system to let him edit all the calling points of that function. If he
uses a smart editor, like Emacs, many of these operations can be fully
automated, and this is again possible because (almost) all Common Lisp
expressions are easy to scan both forwards and backwards in the editor,
so you can move them around with simple editor commands.

| And, I assert, little things that *could* be detected by my language or
| tool, instead of me, my debugger, or my users.

I assert that writing better code to begin with, working with a language
that is actually small enough that it does not impose a cognitive load on
its users. Common Lisp programmers make fewer syntactic bloopers because
there is much less syntax, much better support for what syntax there is
in their editors (although the other languages are getting some of the
benefits of Lisp's superior syntax in Emacs). The tradeoff between how
much the programmer, the editor, and the compiler does is very different
between Java and Common Lisp.

If you think that whichever language you learned first has every implicit
or tacit assumption right, you are wrong. The language you learned first
was an accident. Learning a new langauge can be done two ways: Either
drop everything you have gotten used to and open your mind to the new
language, or study carefully how you react to things that differ and make
those assumptions explicit. Anything else will fail. (Mixing works. :)

Coby Beck

unread,
Nov 20, 2001, 11:01:35 PM11/20/01
to

"cp" <cper...@medialab.com> wrote in message
news:k5EK7.902$jt4.2...@news.uswest.net...

> The sooner I can discover a typo or an error, the better. I believe this is
> true for any language.
>

I think the reason this is not as big an issue as you may feel is due to the
interactive and incremental way development is best done in lisp. You do not
need to write 6 screens full of code before it is ready to hand to the compiler
to uncover all of your typos. I always test my functions as I write them and
definately individually test them when they are "finished". The great thing
about lisp development is that ability. You need to write method foo that will
take an object of one of your classes and do something magical, create an
object, bind it to something, even the same variable named in foo's lambda list
and step by step make sure every line does what you expect. By the time that
process is finished, the only errors left are the special cases you forgot and
logical nuances. These are not the kind of things compilers will tell you
about anyway.

In a certain sense this *is* discovering the typo and "d'oh" errors at runtime,
but the (big) difference is that runtime is anytime.

Coby
--
(remove #\space "coby . beck @ opentechgroup . com")


Craig Brozefsky

unread,
Nov 20, 2001, 11:29:46 PM11/20/01
to
"cp" <cper...@medialab.com> writes:

> I'm not necessarily advocating type specifications in Lisp.

They are already there in Common Lisp.

> The sooner I can discover a typo or an error, the better. I believe this is
> true for any language.

Might I suggest the following then:

1. Learn to control the verbosity of your compiler and it's
strictness. The compiler can tell you quite a bit of information
before you hit "runtime." In cmucl, (setf *compile-verbose* t) will
be helpful.

2. Use declaimations and/or declarations to set your compiler policy
appropriatly. This will get quite a few typos. I put:
(declaim (optimization (debug 3) (safety 3)))
in my init file. Under cmucl I also:
(setf *compile-print* nil)
(declaim (optimize (inhibit-warning 3)))
which reduced my console spam while compiling to the important
warnings and notices.

> Lisp, I still "crash and burn" - I incorrectly use a form - I pass
> arguments in the wrong order, etc. Little things that haunt every
> programmer - even Lispers. And, I assert, little things that
> *could* be detected by my language or tool, instead of me, my
> debugger, or my users.

See above. What usually slips thru at this point may have possibly
been caught by static type checking, but static type checking is not
worth the trouble in CL, as Erik explained in another post.

> But, as has been suggested to me, I will read up on CLOS, I will check
> Richard Waters' article on regression testing, and I'll muck about a bit.

CLOS will not help you much here, it's an object system, tho I still
encourage you to learn about it. What will help you here is the
Common Lisp Hyperspec and your CL implementations manual. Check out
the sections on compiler policy and the use of type declarations in
the CLHS, and your manuals section on the compiler and debugger.

> "Hmmmmm...that sounds like the type of problem Lisp would be well
> suited to solve"

Yah, the solution is called macros and readtable 8)


--
Craig Brozefsky <cr...@red-bean.com>
http://www.red-bean.com/~craig
All around the world hearts pound with the rythym. Fear not of
men because men must die. - Mos Def

Kaz Kylheku

unread,
Nov 20, 2001, 11:37:59 PM11/20/01
to
In article <k5EK7.902$jt4.2...@news.uswest.net>, cp wrote:
>> They also have a prohibitively expensive compilation process compared to
>> Common Lisp. This is _why_ it is important in those languages to make
>> sure that runtime is a less expensive debugging environment.
>Comparisons
>> of language tend to forget their contexts and evolution completely, and
>> take one of these for granted while the other is treated like a stranger
>> in a strange land. This is why you should strive to forget where you
>> came from and try to figure out how your new language came to be and why
>> what it does is natural in its environment.
>
>I'm not necessarily advocating type specifications in Lisp. I'm simply
>trying to write better and more solid code, which is why I have come to Lisp
>in the first place. I don't necessarily care to introduce type
>specifications to Lisp, but I would be interested in upstream (not runtime)
>verification of simple and complex contracts.
>
>The sooner I can discover a typo or an error, the better. I believe this is
>true for any language.

I think that any benefits must be weighed against disadvantages. Is it
wortwhile to save time finding a typo, if you have to pay for it in lost
productivity at every turn? Is it wortwhile if it means that there are
some programs you cannot write? Some programming languages force such
a tradeoff on their users by requiring them to make declarations which
allow checks to be easily implemented.

I think that static checking is perhaps a must only in safety critical
software. Such software should be kept small and uncomplicated, because
too much is at stake, so the lost productivity isn't an issue.

>> Coming from the C++ world, it can take a while to get used to programs
>> that do not crash and burn.
>
>While it is true that I don't have to restart my machine when I miscode in
>Lisp, I still "crash and burn" - I incorrectly use a form - I pass arguments
>in the wrong order, etc.

But note that these situations are identified at a high level. Mistakes
in a C++ program require a mapping from some machine language level back
to the source language. Frequently, the mapping is difficult or
impossible. A mistake that occured thousands of cycles earlier in the
execution in an unrelated part of the program manifests itself in a
mysterious failure elsewhere, perhaps in a subprogram that is itself
correct.

You can't compare that to a high level diagnosis which tells you
exactly what the problem is as it happens. (There can still be some
level separation; e.g. a problem occurs deep in some code generated by
a macro, without an easily apparent macro-level mapping back to the user
of the macro).

C++ also doesn't let you programmatically choose the recovery, and
certainly interactive recovery isn't part of a running C++ program;
only when that program is running in a debugger.

Things like division by zero or dereferencing a null pointer are simply
undefined behavior; they don't generate standard exceptions that can be
caught. Programmers rely on platform-specific, nonportable mechanisms,
like POSIX signals, or structured exception language extensions like
those of Win32 or Digital UNIX or what have you.

> Little things that haunt every programmer - even
>Lispers. And, I assert, little things that *could* be detected by my
>language or tool, instead of me, my debugger, or my users.

Software shops waste tens of thousands of dollars on tools like Purify,
yet crank out C++ that leaks and crashes. Money is wasted on the tools,
time and money on their application.

>But, as has been suggested to me, I will read up on CLOS, I will check
>Richard Waters' article on regression testing, and I'll muck about a bit.
>
>
>On an aside, I've always felt that Design Patterns, DBC, and UML are, at an
>idealogical level, fundamentally tied together.

Many of the the design patterns described in the Design Patterns book
are largely just C++ workaround patterns. It's shocking that the authors
don't appear to realize that; if they do, they sure don't acknowledge it;
their introduction claims that these are genuine patterns of object
oriented design.

For example, the Adapter and Visitor patterns are meaningless in the context
of an object system like CLOS, because you can create new generic
functions with methods that specialize to existing classes, and because
you have multiple dispatch. So from the perspetive of the CLOS user, these
are, respectively, a recipe for overcoming the idiosynchrasies of a
type system, and for clumsily simulating double dispatch.

Flyweights are just interning; happens all the time in Lisp when you
use (interned) symbols.

Here is a good one: the State pattern. Basically, you have an empty
object, which holds a pointer to another object. It redirects its calls
to that object. It switches to other objects to represent state changes.

This is nothing more than a simulation of an object's *type* changing at
run time! The ``context'' object appears to change type because its entire
implementation is in the state object which is swapped for another one
which has a different behavior.

In CLOS you can do that by directly by telling an object to change
class. So you don't need a surrogate object to hold a pointer; you just
have the state object and change it. Design Pattern, my ass! Say it
with me: Workaround Recipe!

The State recipe is basically just reimplementing a virtual dispatch
table in software, because the language doesn't give you the access
to the real virtual table that would let you allow you to switch the
virtual functions to make the object appear to change type.

For fun, I wrote a little C library in which a dynamic structure can,
at run time, change its type among AVL, red-black, splay and ordinary
binary trees as well as a sorted linear list. You can build a red-black
tree, and then say ``please become an AVL tree''. Classes would only
have gotten in the way of this, because I needed a way to switch the
virtual table of a live object to a new set of methods.

Lastly, UML is basically a whole lot of graphical crud thrown together to try
to capture every nuance of C++. It favors a narrow view of object
orientation in which methods are properties of classes, exemplified by
descendants of the Simula family. I think that the big names behind
UML have a vested interest in selling you their design process at big
bucks per seat. Just say no!

By the way, I pay my bills by developing in C++. Dirty, multithreaded,
C++ with dynamic real-world inputs: communication protocol middleware.
So I'm not some academic looking down on the trenches from an ivory
tower. I use those workaround recipes, and from time to time I even have
to produce or understand UM-Hell.

Hope you have as much fun reading this little rant as I had writing it. ;)

Kenny Tilton

unread,
Nov 21, 2001, 12:06:13 AM11/21/01
to

cp wrote:
> I would be interested in upstream (not runtime)
> verification of simple and complex contracts.

I just thought of another parallel, one going back twenty years.

It was a long, detailed, very serious argument I read in a tech journal
against writing code which did not compile on the first shot.

I am sure no one understands what I just wrote, because it is so
inconceivable. I repeat. The guy was saying that it was inexcusable to
submit code to the compiler which would not compile successfully. His
point was that it was lame to rely on the compiler to find stuff, one
should desk check one's code thoroughly enough that one is sure the code
will compile. Failures should leave one kicking oneself.

I do not recall why Mr CompileClean felt that way. Probably time wasted
was one. back then 2500 lines of COBOL could take 30min to compile on
PDP-11/70. But I recall also something more, that he thought programmers
should be looking at what they wrote in your spirit of "the sooner the
better".

I do not need to tell you that type checking upstream or down does not
guarantee correct code. So if one is not looking at code closely enough
to determine if the compiler will barf, clearly one is not looking
closely enough to detect bugs. And I think that was a part of what MrCC
was down on.

Which reminds me of another story from that same high visibility RSTS/E
COBOL project. My manager saw me hunched over a listing and asked if
there was some problem. I said no, I was just desk-checking the code.
Relieved, he laughed and said we do not do that here. I was new. I said
what do you do, just run it and see? He said, no, we move it into
production, and started laughing.

Now there's a Lisper for you.

kenny
clinisys

Chris Perkins

unread,
Nov 21, 2001, 12:44:10 AM11/21/01
to

>
> Hope you have as much fun reading this little rant as I had writing it. ;)

I liked your rant quite a bit. As a C++ programmer I "liked" the Design
Patterns meaning that I understood the need for them, but I always felt they
were at heart just a kludge. Really, just a kludge on top of a kludge.
This is part of the reason I am learning Lisp now.

Chris


Chris Perkins

unread,
Nov 21, 2001, 2:10:23 AM11/21/01
to

> I do not follow you. [...deleted...] Or do you mean that you want

static type checking? That you cannot get
> very easily.

Sorry about that, the message went out before I got to re-read and edit it.
Static type checking would have been most analagous. However, I am in no
means advocating static type checking. I would not cut even a single hair
off Lisps dynamic language head.

I don't want to limit what can or can't be done in the Lisp. I don't want
the compiler to throw errors. I only want something that will help me
identify errors without having to discover them at runtime. Maybe something
like (check-function-for-obvious-errors 'function) Think less about type
errors and more about the situations you use assert clauses for right now.


> I disagree, probably to your surprise. The earlier an error is
detected,
> the _firmer_ the determination that it is an error is, and the simpler
> the world must be in which statements are made.

True, but our code does make simple statements from time to time. And it
would be nice if the simpler bugs could be vetted out. And it would be even
nicer if not so simple bugs could be discovered.....


> I assert that writing better code to begin with, working with a language
> that is actually small enough that it does not impose a cognitive load
on
> its users.

Yes, this is the most salient point against adding artificial constructs
(like DBC) to shore up our code. The more code, the harder it is to keep
all the details in ones head, and coding is a detail oriented job. So, as
programmers we try to fight this with elegance and simplicity, and when
those aren't enough we modularize.


When working on some recent large Java/C++ projects I used DBC extensively
and to great effect. Postconditions, preconditions, invariants, etc. were
all keeping the code ship shape. It was especially useful when the
following year the product was developed into its 2.0 version. There were
a lot of conditional checks, and many were fairly trivial. But every now
and then we'd make a change to something and despite great care to handle
all the consequences we'd set off a DBC assertion in testing. And, hey,
that's great - without that DBC check that little error might have gone
undetected or propogated itself into other problems. But, often once the
problem was examined I would realize that it was one of the trivial
assertions that caught it, and I'd think to myself "That assertion clause
wasn't complicated - I could write something to vette that out
systematically". But, of course, in Java or (worse) C++ one really couldn't
easily write something like that. But, in Lisp, well that's a different
story...

Anyway, I know Java and C++ are terribly brittle, and maybe as I work more
in Lisp I'll just perceive DBC, assert clauses, and the like as artificial
kludges for addressing the shortcomings of static languages. Maybe.... or
maybe not. I still use assert clauses in my Lisp code (though, thankfully,
not nearly as many) and a few seem like they could be systematically
verified.

Chris Perkins

Alain Picard

unread,
Nov 21, 2001, 5:28:40 AM11/21/01
to
k...@ashi.footprints.net (Kaz Kylheku) writes:

>
> Many of the the design patterns described in the Design Patterns book
> are largely just C++ workaround patterns. It's shocking that the authors
> don't appear to realize that; if they do, they sure don't acknowledge it;
> their introduction claims that these are genuine patterns of object
> oriented design.

I can't agree with you more; heck, I've tried to convince my
co-workers of it for years, BUT, to be fair, at least _one_ of the
authors _does_ realize it (I think it's Ralph Johnson, he's actually
a smalltalker). One of the patterns at least says that it's not
useful in smalltalk. [Book's at the office, so I can't check up
on which right now]. But I figure the other 3 authors (and the publishers)
made sure this point didn't come across too clearly...

As you say, next thing you know, people would stop buying Rose and Purify
and actually use programming environments that work... shudder. :-)

The amazing thing is, back when I was a C++ programmer, I thought that
was SUCH a great book. And I guess it was, in a way: it made it possible
to use C++ and get something done. In the long run, of course, that may
have been a disservice...

--
It would be difficult to construe Larry Wall, in article
this as a feature. <1995May29....@netlabs.com>

Thomas F. Burdick

unread,
Nov 21, 2001, 6:04:57 AM11/21/01
to
jlo...@hushmail.com writes:

> On Wed, 21 Nov 2001 02:54:06 GMT, Kenny Tilton <kti...@nyc.rr.com> wrote:
>
>
> >Sometimes I cannot because I use Semaphors a lot and these are
> >structures that arrange for a slot to be efficiently envalued by a
> >formula--if I die in a formula, fixing the formula in the source does
> >not change the lambda function that died, so I just "burn" the window
> >and re-run. without linking.
>

> What are these Semaphors? I guess it's not the IPC thing you're talking about,
> no? :)

No, it's his wacky[*] terminology for "constrained slot" :-)

[*] I really don't see the logic in the name. "semaphore" litterally
means "sign bearer". Or it can be the railroad thing, or the flag
thing. Maybe it's a physical metaphor for the railroad semaphore? Or
maybe there's another meaning of semaphore I don't know about?
Actually, I called it wacky, hoping that Kenny will explain the name :-)

Kenny Tilton

unread,
Nov 21, 2001, 10:22:13 AM11/21/01
to

"Thomas F. Burdick" wrote:
>
> jlo...@hushmail.com writes:
>
> > On Wed, 21 Nov 2001 02:54:06 GMT, Kenny Tilton <kti...@nyc.rr.com> wrote:
> >
> >
> > >Sometimes I cannot because I use Semaphors a lot and these are
> > >structures that arrange for a slot to be efficiently envalued by a
> > >formula--
> >

> > What are these Semaphors? I guess it's not the IPC thing you're talking about,
> > no? :)

No, but see below.

>
> No, it's his wacky[*] terminology for "constrained slot" :-)
>
> [*] I really don't see the logic in the name. "semaphore" litterally
> means "sign bearer".

Right, the "bearer" part conveys the dataflow, and the "sema" says
"meaning" to me, so I get "meaning bearer", tho "sign bearer" is what
the dictionaries say.

While Semaphor may be wacky, "constrained" is wrong. A constraint to me
/partially/ specifies a value in terms of other values. So I might have
(< x y) as a constraint on the values x can assume. The constraint does
not determine the value of x, it keeps x from becoming GE y at runtime.

Semaphors are CLOS slots that act like cells in a spreadsheet. A
formula /fully/ determines the value for the slot. If that is a
constraint it is a constraint with extreme prejudice.

Our first implementation used a lambda whose sole argument was the
instance owning the slot, but this had two problems. One, it was slow.
Two, where a slot value effected the screen appearance, lazy evaluation
is no good; a change to the value requires a screen update. Garneters
must manually call update-window or somesuch. Similarly, if x depends on
y and y changes, maybe y does not effect the screen but maybe x does and
x would return a new value if recalculated. So we arranged for eager
evaluation, with lots of optimizations to make that efficient.

[on IPC: we used win32 COPYDATA to splice semaphoric dataflow between
processes.]

The eager evaluation then means that a change to a single semaphoric
slot causes a cascade of dependent slot changes and (via a GF callback
specialized on the instance, new value and old value) to any necessary
manifestation outside the semaphoric web, such as a screen redraw.

I felt the metaphor of "bearing" was apt for the process of propagating
state. And in my metaphysics the meaning of anything is the sum of its
causes. Eager evaluation is cause-and-effect. Semantics is about
meaning. meaning+propagation = semantics+bearer = Semaphor. Misspelled
because I dig the word "metaphor" and so I can trademark it. :)

kenny
clinisys

Erik Naggum

unread,
Nov 21, 2001, 1:38:23 PM11/21/01
to
* Erik Naggum

> I disagree, probably to your surprise. The earlier an error is detected,
> the _firmer_ the determination that it is an error is, and the simpler
> the world must be in which statements are made.

* Chris Perkins


| True, but our code does make simple statements from time to time.

I was referring to the statement "this is an error".

| And it would be nice if the simpler bugs could be vetted out.

As you grow more accustomed to programming in a better language, you will
notice that you make far fewer "simple bugs". I am serious about this.

| Anyway, I know Java and C++ are terribly brittle, and maybe as I work
| more in Lisp I'll just perceive DBC, assert clauses, and the like as
| artificial kludges for addressing the shortcomings of static languages.

The overspecificity of these languages produces the need for tools to
combat their cognitive load. Having to specify so much detail so early
it just plain wrong, so you need tools that can help you keep things
together when you have to make changes as you learn what you should have
known by the time you specified these things. The nature of the problem
you are solving becomes known to you only as you try to solve it.

I believe C++ instills fear in programmers, fear that the interaction of
some details causes unpredictable results. Its unmanageable complexity
has spawned more fear-preventing tools than any other language, but the
solution _should_ have been to create and use a language that does not
overload the whole goddamn human brain with irrelevant details. Striking
that balance between language complexity and the convenience of using it
is amazingly hard, but I think Common Lisp is closer to this lofty ideal
than any other I have used. That the syntax is so predictable and so
easy to navigate using the proper editor, causes many more benefits than
people realize early on. I think the best advice right now is that you
should relax all those "needs" you have because you come from a C++/Java
environment.

Kenny Tilton

unread,
Nov 21, 2001, 1:46:33 PM11/21/01
to

jlo...@hushmail.com wrote:
>
> Seems interesting, but I'm not sure if I follow you. Could you post a concrete
> example of its use and usefulness? O:)

Well, if you know Garnet you need read no further, Semaphors are like
the constraints/demons tho with important differences such as eager vs.
lazy evaluation.

If you do not know Garnet, here is a simple example (with important
details missing):

(defmodel CTSelectable (Control)
()
(:default-initargs
:selected (sm? (find self (^selection (selector self)))) ;;
explained below
:controlAction #'(lambda (self os-event) (setf (selection (selector
self)) (list self)))))

(defmodel CTButton (CTSelectable Image)())

(def-sm-echo (forecolor) (self newvalue oldvalue) <invalidate self to
force redraw>)

(make-instance 'CTButton :forecolor (sm? (if (^selected self) red
blue)))))

---------------------------------------------------------------

"self" I throw in out of nowhere ala Smalltalk and C++ this. It is the
instance that owns the slot.

(selector self) returns (trust me) some cooperating supervisory instance
which keeps track of the selection defined by several buttons.

the ^macros arrange for behind-the-scenes dependency maintenance in
support of eager re-evaluation. now that I grok specials the ^macros are
superfluous, but I am still implementing that in an experimental branch
of development.

when the controlAction gets invoked (by a mechanism not shown) the
selection semaphor of the selector gets a new value. the dataflow engine
(DF) then causes the selected state to go non-nil. then DF makes the
forecolor of the instance in question change from blue to red. the echo
function associated with forecolor then triggers the screen redraw.

---------------------------------

usefulness? the grail. the silver bullet. better programmer
productivity:

- eliminates an entire class bug, viz, internal inconsistency arising
from oversights in state propagation. and it eliminates all the coding
required to propagate state throughout the application model.

- more self-documenting since it gathers the semantics of any slot in
one rule

- allows OO to deliver on the promise of re-use, since instances can be
assigned their own rules (even closing over different lexically-bound
values), in turn allowing us to get more varied behavior out of fewer
classes than is possible when slot parameters cannot be functional or
can be functional but must have the same rule for each instance of a
slot.

- eliminates the exponential growth of complexity as applications
increase in functionality. example from another domain: if one models in
detail the cashflow of a small business with a spreadsheet one ends up
with a quite complex model in which no cell formula ever taps more than
a few values. the spreadsheet author only has to worry about one formula
at a time, not the whole system all at once. the complexity emerges from
so many simple formulas. same with semaphors.

- it's great fun (as I think Garnetites can confirm)


kenny
clinisys

Lieven Marchand

unread,
Nov 21, 2001, 1:53:14 PM11/21/01
to
Kenny Tilton <kti...@nyc.rr.com> writes:

> I do not recall why Mr CompileClean felt that way. Probably time wasted
> was one. back then 2500 lines of COBOL could take 30min to compile on
> PDP-11/70. But I recall also something more, that he thought programmers
> should be looking at what they wrote in your spirit of "the sooner the
> better".

At that time in mainframe shops, you handed in your punch cards, they
were run and your listing was returned to you and your next shot at
the machine could be in another four hours. Don't assume an
interactive environment that is continuously available. In that
context desk checking was very valuable.

--
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

Lieven Marchand

unread,
Nov 21, 2001, 2:00:39 PM11/21/01
to
Erik Naggum <er...@naggum.net> writes:

> I disagree, probably to your surprise. The earlier an error is detected,
> the _firmer_ the determination that it is an error is, and the simpler
> the world must be in which statements are made. For instance, we have
> the option in Common Lisp of redefining a function between the definition
> the compiler knew about at compile-time of a caller and the actual time
> it was called. This would require a total re-compile in languages that
> consider such things an error with no option to negotiate. In the long
> history of programming languages, indeed human history, there are people
> who insist that they know what is true and good, and who seek to limit
> other people's opportunity to find out what other things are true and
> good. These generally call anything they disagree with "errors" and make
> people angry at their compilers or computers. Then there are people who
> only think they know what is wrong, and while they have their own ideas
> about what is true and good, they only seek to limit other people's
> opportunity to do wrong and harmful things. These generally do not think
> things are errors unless they are _clearly_ wrong and harmful. If not
> clearly, they may issue a warning or a style-warning. (E.g., omitting
> the value of the final branch of a cond or case expression when the value
> returned is stored in a place that is declared not to accept nil as a
> possible value, might be a style warning because the compiler cannot know
> that you do not know better.)

I've always liked the Poplog terminology. They call errors mishaps and
have the same philosophy as CL about them. Off course, poplog is also
a highly dynamic language that grew up in AI research, so the
similarity is not surprising.

Thomas F. Burdick

unread,
Nov 21, 2001, 3:45:35 PM11/21/01
to
Kenny Tilton <kti...@nyc.rr.com> writes:

> While Semaphor may be wacky, "constrained" is wrong. A constraint to me
> /partially/ specifies a value in terms of other values. So I might have
> (< x y) as a constraint on the values x can assume. The constraint does
> not determine the value of x, it keeps x from becoming GE y at runtime.

(with-disclaiming
I really know jack about constraints, so I usually just refer to KR,
and KR slots. Which avoids any discussion about the nature of those
slots (so long as people know what KR is -- but if they don't, I
hand them the manual).)

[...]


> I felt the metaphor of "bearing" was apt for the process of propagating
> state. And in my metaphysics the meaning of anything is the sum of its
> causes. Eager evaluation is cause-and-effect. Semantics is about
> meaning. meaning+propagation = semantics+bearer = Semaphor. Misspelled
> because I dig the word "metaphor" and so I can trademark it. :)

Okay, this makes sense to me now. The "sema" in semaphore *really*
means sign to me because of, y'know, that whole thing where semaphores
are mechanical things that have actual signs. Oops, I didn't notice
you were dropping the -e -- that's a great excuse to redefine the
meaning of a word, you re-derived it from the greek (and according to
English conventions, even, not French).

Kenny Tilton

unread,
Nov 21, 2001, 4:11:12 PM11/21/01
to

"Thomas F. Burdick" wrote:
>
> Okay, this makes sense to me now. The "sema" in semaphore *really*
> means sign to me because of, y'know, that whole thing where semaphores
> are mechanical things that have actual signs.

right. when i was analyzing the name i was reminded also that that was
(is?) how ships communicated when near each other, with someone waving
about paddles (semaphores).

> Oops, I didn't notice
> you were dropping the -e -- that's a great excuse to redefine the
> meaning of a word,

<heh-heh> this is marketing, we don't need an excuse to redefine words.

constraints make me think of handcuffs, leg irons, strait jackets, duct
tape... kinky, but not my thing, and entirely the wrong connotation for
an empowering productivity hack.

kenny
clinisys

Pierre R. Mai

unread,
Nov 21, 2001, 3:47:48 PM11/21/01
to
Craig Brozefsky <cr...@red-bean.com> writes:

> 2. Use declaimations and/or declarations to set your compiler policy
> appropriatly. This will get quite a few typos. I put:
> (declaim (optimization (debug 3) (safety 3)))
> in my init file. Under cmucl I also:
> (setf *compile-print* nil)
> (declaim (optimize (inhibit-warning 3)))
> which reduced my console spam while compiling to the important
> warnings and notices.

Note that the next release of CMU CL will reduce spurious console spam
quite a bit on its own, too, thereby bringing it closer to the goal of
"every issued warning counts":

- Spurious warnings about undefined types/classes or functions for
classes/GFs defined in the same file as methods depending on those
have been eliminated.
- Code that is automatically generated by PCL (CMU CL's CLOS
implementation) will not emit compilation noise anymore. This was
especially annoying since this kind of code generation and
compilation often happens at run-time.

Regs, Pierre.

--
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

Kent M Pitman

unread,
Nov 21, 2001, 4:42:28 PM11/21/01
to
Lieven Marchand <m...@wyrd.be> writes:

> Erik Naggum <er...@naggum.net> writes:
>
> > I disagree, probably to your surprise. The earlier an error is detected,
> > the _firmer_ the determination that it is an error is, and the simpler
> > the world must be in which statements are made. For instance, we have
> > the option in Common Lisp of redefining a function between the definition
> > the compiler knew about at compile-time of a caller and the actual time
> > it was called. This would require a total re-compile in languages that
> > consider such things an error with no option to negotiate.

I agree. I would spin it this way: The earlier an error is detected,
the more opportunity there should be to fix it. We have a choice
between a world like Gattaca describes in which people's DNA is
determined and the rest of their life follows as a consequence, or the
world the human genome people idealistically think they are working
toward where early diagnosis of something gives you the opportunity to
work toward a fix. Static languages seem to take the gattaca posture,
in part because the whole notion of staticness is to disempower people
to make choices in more places than one. In a static language does
early detection imply "last chance" because not only do static
languages attempt to do early detection, but later on, the sitatuion
is going to remain unchanged. There is no opportunity for users or
code to intervene to head off the inevitable. Like the unlucky
protagonist at center stage of a Shakespearean tragedy, knowledge of
the statically detected tragic flaw yields no hope, and if code is not
stopped, it will merely proceed to one inevitable fate. Hardly any
wonder the compiler gives up and leaves at intermission. But in a
dynamic language, the direness of the warning and the certainness are
in many cases orthogonally varying, and the possible futures are quite
a bit more varied.

> > In the long
> > history of programming languages, indeed human history, there are people
> > who insist that they know what is true and good, and who seek to limit
> > other people's opportunity to find out what other things are true and
> > good. These generally call anything they disagree with "errors" and make
> > people angry at their compilers or computers. Then there are people who
> > only think they know what is wrong, and while they have their own ideas
> > about what is true and good, they only seek to limit other people's
> > opportunity to do wrong and harmful things. These generally do not think
> > things are errors unless they are _clearly_ wrong and harmful. If not
> > clearly, they may issue a warning or a style-warning. (E.g., omitting
> > the value of the final branch of a cond or case expression when the value
> > returned is stored in a place that is declared not to accept nil as a
> > possible value, might be a style warning because the compiler cannot know
> > that you do not know better.)
>
> I've always liked the Poplog terminology. They call errors mishaps and
> have the same philosophy as CL about them. Off course, poplog is also
> a highly dynamic language that grew up in AI research, so the
> similarity is not surprising.

I think the term mishap is a misnomer, or would be for us.

I don't know if there are othe terms you like there, but I'm prepared to
defend the CL terminology if there are others you think are better. :-)
I just went and double-checked the terms and am happy that they all very
closely parallel their conventional English meanings.

The fully elaborated terminology for CL acknowledges that condition
objects represent situations. Situations are actual real-world
phenomena. Error situations are situations situations where something
is amiss. mishap is defined as "an unforunate accident" or "bad luck"
(says Merriam-Webster at webster.com). This seems to me quite a
subset of the possible situations, failing to acknowledge issues that
happen by well-meaning or ill-meaning intent, for example. I also
personally think it connotes an event of actual specific consequences.

Bob Bane

unread,
Nov 21, 2001, 5:01:52 PM11/21/01
to
Kaz Kylheku wrote:
>
> Many of the the design patterns described in the Design Patterns book
> are largely just C++ workaround patterns. It's shocking that the authors
> don't appear to realize that; if they do, they sure don't acknowledge it;
> their introduction claims that these are genuine patterns of object
> oriented design.
>
Has anyone stomped through the Design Patterns book and classified the
patterns in detail, preferrably on the web somewhere? I've seen the
"patterns are C++ workarounds" claim in many places (I saw it first by
Norvig), but never in a form I could easily shove up the nose of a C++
bigot.
--
Remove obvious stuff to e-mail me.
Bob Bane

Matthieu Villeneuve

unread,
Nov 21, 2001, 7:18:27 PM11/21/01
to

Peter Norvig's slideshow "Design Patterns in Dynamic Programming" is
very interesting:
http://www.norvig.com/design-patterns/ppframe.htm

One of the slides summarizes the study:
"16 of 23 patterns are either invisible or simpler, due to:
- First-class types (6): Abstract-Factory, Flyweight, Factory-Method,
State, Proxy, Chain-Of-Responsibility
- First-class functions (4): Command, Strategy, Template-Method,
Visitor
- Macros (2): Interpreter, Iterator
- Method Combination (2): Mediator, Observer
- Multimethods (1): Builder
- Modules (1): Facade"


--Matthieu

Rahul Jain

unread,
Nov 21, 2001, 7:23:38 PM11/21/01
to
Bob Bane <ba...@removeme.gst.com> writes:

> Has anyone stomped through the Design Patterns book and classified the
> patterns in detail, preferrably on the web somewhere? I've seen the
> "patterns are C++ workarounds" claim in many places (I saw it first by
> Norvig), but never in a form I could easily shove up the nose of a C++
> bigot.

Norvig himself has analyzed the issue and has a presentation available
discussing design patters in languages like Lisp, Smalltalk, and
Dylan:

http://www.norvig.com/design-patterns/

--
-> -/- - Rahul Jain - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- mailto:rahul...@usa.net -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.220020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.

Richard P. Gabriel

unread,
Nov 21, 2001, 8:58:14 PM11/21/01
to
I've been working with the patterns community for a long time. The so-called
Gang of Four (Gamma et al) design patterns are notoriously misleading about
the ideas behind patterns. A better way to think of what a pattern is in
software is to think about the kinds of advice an experience usability or UI
person would give to people working on a project in order to make the
interface really nice and usable.

Patterns are not about abstraction.

-rpg-

Fernando Rodríguez

unread,
Nov 22, 2001, 6:00:11 AM11/22/01
to
On Wed, 21 Nov 2001 18:46:33 GMT, Kenny Tilton <kti...@nyc.rr.com> wrote:

>
>
>jlo...@hushmail.com wrote:
>>
>> Seems interesting, but I'm not sure if I follow you. Could you post a concrete
>> example of its use and usefulness? O:)
>
>Well, if you know Garnet you need read no further, Semaphors are like
>the constraints/demons tho with important differences such as eager vs.
>lazy evaluation.

I checked the Garnet[1] site and the project seems to be abandoned. Is there
any other Lisp GUI toolkit that includes this sort of thing? O:-)

[snip]

>usefulness? the grail. the silver bullet. better programmer
>productivity:
>
>- eliminates an entire class bug, viz, internal inconsistency arising
>from oversights in state propagation. and it eliminates all the coding
>required to propagate state throughout the application model.

OK, I'm interested. :-)

Yesterday I spent the whole day debugging this sort of thing (although not in
a Lisp app), and they are the most annoying bugs I've seen. The app's GUI has
many states that modify the state of a huge number of widgets, so enforcing
consistency is very time, patience, good mood and coffee consuming... ;-)

Where can I learn more about these techniques? O:-)

TIA

[1] They abandoned it to start a C++ toolkit called Amulet. That would be
fine, since the application I'm dealing with right now is in C++, but Amulet
has also been abandoned. What the heck?... ;-P

--
Fernando Rodríguez
frr at wanadoo dot es
--

Thomas F. Burdick

unread,
Nov 22, 2001, 6:30:13 AM11/22/01
to
Fernando Rodríguez <spa...@must.die> writes:

> [1] They abandoned it to start a C++ toolkit called Amulet. That would be
> fine, since the application I'm dealing with right now is in C++, but Amulet
> has also been abandoned. What the heck?... ;-P

Well, Garnet isn't completely abandoned -- it is public domain, so
just because CMU threw it to the wolves, doesn't mean that the wolves
aren't takeing care of it. But, we aren't exactly continuing
development, either. That's too bad about Amulet. I know they
struggled for a long time to port it to C++ (time that could have been
spent amaking Garnet quite amazing), but it really sucks that that
ended out killing the project. I liked it a lot more being able to
imagine that there was a mutant Garnet out there somewhere :-(

Tim Bradshaw

unread,
Nov 22, 2001, 7:04:19 AM11/22/01
to
Bob Bane <ba...@removeme.gst.com> wrote in message news:<3BFC2450...@removeme.gst.com>...

> Has anyone stomped through the Design Patterns book and classified the
> patterns in detail, preferrably on the web somewhere? I've seen the
> "patterns are C++ workarounds" claim in many places (I saw it first by
> Norvig), but never in a form I could easily shove up the nose of a C++
> bigot.

I did this but not on the web, and I gave up before the end, sorry!

But I came to the conclusion, after talking to various people for a
bit, that patterns are *not* just C++ workarounds, but that there is
actually something more there. However I think that it is the case
that the GoF book patterns almost all are C++ workarounds, but perhaps
that says more about the book than patterns as such. Unfortunately
the patterns community seems to be riddled with the sort of cultism
that is so common in computing (it seems to have happened to XP too,
which is sad), and I'm kind of averse to that (the robes and diet of
cardboard fish get to me after a while, as does the ending up buried
in a pit with all the other cult members when the world fails to end
on time) so I kind of lost interest. But I think there may be
something there if you look beyond the GoF book.

--tim

Kenny Tilton

unread,
Nov 22, 2001, 12:32:56 PM11/22/01
to

"Fernando Rodríguez" wrote:
>
> On Wed, 21 Nov 2001 18:46:33 GMT, Kenny Tilton <kti...@nyc.rr.com> wrote:
>
> >
> >
> >jlo...@hushmail.com wrote:
> >>
> >> Seems interesting, but I'm not sure if I follow you. Could you post a concrete
> >> example of its use and usefulness? O:)
> >
> >Well, if you know Garnet you need read no further, Semaphors are like
> >the constraints/demons tho with important differences such as eager vs.
> >lazy evaluation.
>
> I checked the Garnet[1] site and the project seems to be abandoned. Is there
> any other Lisp GUI toolkit that includes this sort of thing? O:-)

COSI is similar. On this page, check out Paper #6 under 1999 papers:

http://www-int.stsci.edu/apsb/doc/papers-and-meetings/papers.html

But under their system constraints are defined for a class. Semaphors
for the same slot can vary from instance to instance. Other diffs as
well. No demons/echos, but changes go thru (setf <slotName>). Semaphors
echo out of (setf slot-value-using-class) so it does not matter what the
writer method is called (which might vary from class to class onthe same
slot) and so it gets kicked off at make-instance time (initforms go thru
(setf SVUC)).


>
> Yesterday I spent the whole day debugging this sort of thing (although not in
> a Lisp app), and they are the most annoying bugs I've seen. The app's GUI has
> many states that modify the state of a huge number of widgets, so enforcing
> consistency is very time, patience, good mood and coffee consuming... ;-)

Semaphors are definitely great fun for complex or large problems like
that.

>
> Where can I learn more about these techniques? O:-)
>

I plan to share the existing ACL/win32 stuff RSN. The DF engine will be
proprietary FASL-only until/if I decide to OpenSource it and will come
with a license for non-commercial use. Commercial use will not be a
problem, I just haven't thought that far.

The GUI source will be, oh, I don't know, GPL to start? That could be
relaxed over time as things develop.

There is a small amount of doc. I will add to that in the context of an
open project to build a GPL optics workbench simulator. (A pet project.)
I will also help anyone with their code myself. That would include
newbie help and also advanced help for when things get hairy. Also
adding extensions to Semaphors where that seems the Right Thing to solve
a problem.

If ACL/Win32 is not your platform I will try to work something out,
either getting the same platform or having someone build FASLs under
NDA. MCL is a little harder because they do not support the MOP, but
that is where Semaphors started (ie, a MOP-less approach is possible). I
am not crazy about making that effort, tho. Maybe if a lot of interest
developed from that quarter.


> TIA
>
> [1] They abandoned it to start a C++ toolkit called Amulet. That would be
> fine, since the application I'm dealing with right now is in C++, but Amulet
> has also been abandoned. What the heck?... ;-P
>

Wow. I see they Open-sourced it, but that page does not show any news or
updates in a year. Dead also?

I have actually ported Semaphors to C++ and Java out of curiosity.
Without macros more plumbing shows, but they seemed to work. Python
looks very doable. If CL users don't dig Semaphors I'll see what the
Pythonites think, looks like they'll eat anything.

kenny
clinisys

Reini Urban

unread,
Nov 22, 2001, 9:34:48 PM11/22/01
to
Tim Bradshaw wrote:
>But I think there may be
>something there if you look beyond the GoF book.

I esp. like the AntiPatterns Book.
At my acadwiki http://xarch.tu-graz.ac.at/acadwiki/AntiPattern I try to
categorized some for the web.

Positive patterns in other languages than lisp are
mostly useless for lispers, even the smalltalk patterns,
but anti patterns are usually common.
--
Reini Urban
http://tv.mur.at/film/

Will Deakin

unread,
Nov 23, 2001, 5:27:12 AM11/23/01
to
Kenny Tilton wrote:

> I do not need to tell you that type checking upstream or down does not
> guarantee correct code. So if one is not looking at code closely enough
> to determine if the compiler will barf, clearly one is not looking
> closely enough to detect bugs. And I think that was a part of what MrCC
> was down on.


This is an excellent point.

In written english did a lot of this when writing a thesis and I
still see this every day in word documents and emails -- when stuff
is spell checked people assume that it is *right*. But all spell --
or type name -- checking tells you is that the spell checking
recognised all the words: a bit of a chocolate fireguard.

Aha, you might say, the next this is grammar checkers. And computer
languages are much more robust in this respect than natural
languages. However, again the guarantees give are also fraught with
danger because they give the unwary a fuzzy glow of success -- or
desparate anger in the case where valid syntax is marked as wrong[1].

:)w

[1] One of my biggest pains was writing about light propagation in
optical crystals where the nouns `field' and `feld'[2] are both valid.
[2] As in `Icelandic feld spar'.

Tim Bradshaw

unread,
Nov 23, 2001, 6:32:49 AM11/23/01
to
"Richard P. Gabriel" <r...@dreamsongs.com> wrote in message news:<B8219BB6.C3D%r...@dreamsongs.com>...

>
> Patterns are not about abstraction.

Yes. I think this is the key point that should be made about them and
which is completely missing in a lot of the literature (well, in the
GoF book).

When I read it, I found myself just getting annoyed and cynical (OK, I
was already cynical), because virtually everything they actually
describe is a stupid half-working workaround for something that is a
problem only because people program in some completely inadequate
language like C++. And this all seemed to be raised up into some
quasi-religions thing.

I think (as a non-patterns person) that it's somehow about rituals.
Rituals are ways of doing something which you just do, rather than
working out all the time from first principles why it's done like
this, and *good* rituals are ways of doing something that turn out to
work well and combine well with other good rituals.

Software development is a mass of rituals, and most of them are bad
ones. I find myself spending a lot of time trying to work out and
explain *why* things are being done, because most of the time you find
that there is just no reason at all - and if you repeatedly ask why
you can maybe stop this thing being done or work out how to do it
better (or, more likely, get sacked for being an inconvenient and
annoying person). These bad rituals are almost the same thing as what
I was calling cults in my other message in this thread.

A good example of this working is working out what backup strategies
should be: everyone has them, and something happens every day, and it
all feels comfortable. But you need to really look hard at what is
being done, and in particular you have to work out what the bad cases
are: if the disk goes on fire can you take a naked machine and recover
it in a hurry? Is anything useful actually getting written to tape
(do you need multiple drives / multipke controllers?). Is it for
disaster recovery or accidental file-deletion recovery, should you use
different processes (rituals) for these rather than the same for both?
What happens if the building burns down: do you need offsite backups
(in one case I dealt with I decided the answer was no: if we had an
event bad enough to take out the machine room and the tape store (4
floors up) then about our last problem was data recovery since the
organisation would not recover from such an event anyway). I bet that
*most* backup strategies have *serious* vulnerabilities to some
reasonably likely event, because no one has ever stopped to think
about what they are doing.

But you can't always do this - for instance you need to be able to
work out, once, what works, and not do it each time, and sometimes
it's really not clear why what works does work. So you describe the
rituals that work as rituals, and call them patterns. Of course,
without the analysis of why you can't distinguish patterns from cults,
and that's a big problem, since I think a lot of patterns turn out to
be cults.

I think that things like `how you go about developing code in Lisp'
are good candidates for patterns - there clearly are a bunch of
rituals that people use, and they are often very successful, but even
if you can work out why they work such a description would be so
enormous that it's better to say `do it this way, it works'.

--tim

Richard P. Gabriel

unread,
Nov 23, 2001, 1:07:12 PM11/23/01
to
in article fbc0f5d1.01112...@posting.google.com, Tim Bradshaw at
tfb+g...@tfeb.org wrote on 11/22/01 4:04:

> Unfortunately
> the patterns community seems to be riddled with the sort of cultism
> that is so common in computing (it seems to have happened to XP too,
> which is sad), and I'm kind of averse to that

There is a fine line to observers between cult and culture. I have been part
of the patterns community since it started, and it has a strong culture
derived from the community's interest in making developing software easier
and using software better for end users. There are a number of people in the
community who believe the works of Christopher Alexander are getting at
something important. I believe this as well - in many ways what the patterns
community is saying about the advantages of patterns and pattern languages
are what we were saying were the advantages of Lisp.

Patterns are about what to build, not how to build it.

People who believe in Alexander use his vocabulary, just as many of you use
the vocabulary of McCarthy, Moon, Steele, and - consider this - me. This
makes them seem a little cultish, as does your use of a culture-specific
language. Think about how some folks in the Lisp community feel denotational
semantics is important or #F is better than NIL. This is cultish. Or is it
cultural?

XP came out of the patterns community and by the same people who started the
patterns movement, so it's not odd that that community would be built based
on a strong cultural basis.

There is really a lot to patterns and the patterns community, though that
community is in decline. If you want to find out about it, try reading
Alexander's "The Oregon Experiment," which I think is the easiest, quickest
way to see the ideas. After that "The Timeless Way of Building." A long
time ago I wrote a bunch of essays explaining the ideas to the OO community
which were collected in a book. If you have a friend who has the book you
can take a look at those essays.

But don't dismiss patterns because of the GoF - much of the patterns
community derides that work as well. Think of the GoF as helping losers lose
less.

-rpg-

Paolo Amoroso

unread,
Nov 23, 2001, 2:20:40 PM11/23/01
to
On 23 Nov 2001 03:32:49 -0800, tfb+g...@tfeb.org (Tim Bradshaw) wrote:

[about the GoF patterns book]


> When I read it, I found myself just getting annoyed and cynical (OK, I
> was already cynical), because virtually everything they actually
> describe is a stupid half-working workaround for something that is a
> problem only because people program in some completely inadequate
> language like C++. And this all seemed to be raised up into some

I seem to remember that they candidly admit a few times that languages such
as Lisp, or maybe they explicitly mention CLOS, don't need patterns. I
don't have the book handy, so I can't check.


Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]

Paolo Amoroso

unread,
Nov 23, 2001, 2:20:42 PM11/23/01
to
On Wed, 21 Nov 2001 17:58:14 -0800, "Richard P. Gabriel"
<r...@dreamsongs.com> wrote:

> the ideas behind patterns. A better way to think of what a pattern is in
> software is to think about the kinds of advice an experience usability or UI
> person would give to people working on a project in order to make the
> interface really nice and usable.

Do you mention this as a general example, or because the kind of advice
from usability/UI persons, and not other kinds of advice, provides better
insight on software patterns?

Richard P. Gabriel

unread,
Nov 23, 2001, 3:25:56 PM11/23/01
to
in article 7nL+O5eiZiCvDZ...@4ax.com, Paolo Amoroso at
amo...@mclink.it wrote on 11/23/01 11:20:

> On Wed, 21 Nov 2001 17:58:14 -0800, "Richard P. Gabriel"
> <r...@dreamsongs.com> wrote:
>
>> the ideas behind patterns. A better way to think of what a pattern is in

>> software is to think about the kinds of advice an experienced usability or UI


>> person would give to people working on a project in order to make the
>> interface really nice and usable.
>
> Do you mention this as a general example, or because the kind of advice
> from usability/UI persons, and not other kinds of advice, provides better
> insight on software patterns?

Because that sort of advice is most like what the best patterns are like,
and so if you can appreciate that sort of advice, then you can appreciate a
good pattern in another area when you see it.

Here's another true statement about patterns: If there are no such things as
patterns in the Lisp world, then there are no statements a master programmer
can give as advice for junior programmers, and hence there is no difference
at all between an beginning programmer and a master programmer in the Lisp
world.

The GoF patterns are notorious in parts of the patterns world for
misrepresenting the patterns concept because they provide to C++ programming
constructs we have in Lisp. The authors of the book understand that - they
are as smart and knowledgeable as you all think you are - but maintain that
the poor C++ programmer needs these patterns, which is true.

But, patterns by themselves are neither interesting nor generally useful. A
pattern is part of a pattern language, which is a coordinated set of
patterns that tell you how to build a really nice artifact of a particular
category customized to your needs. If you are someone who thinks that a
pattern is just an abstraction or is something that a great abstraction
mechanism can provide for you, then put that thought firmly in your head
right now.

Here are some remarks about a pattern language for spreadsheets. By a
"spreadsheet" I mean any sort of constraint satisfaction system that relies
on geometry to provide intuitive assistance to its users who use and
sometimes program the spreadsheet using, perhaps, a user interface. The
design of the "macro language" is part of the problem of designing and
building the spreadsheet. A spreadsheet pattern language is aimed at doing
two things: It teaches how to create such a system, and it teaches what
makes a good spreadsheet for users and for programmers who have to build and
maintain spreadsheets.

It starts with a tour of what a general spreadsheet is in the form of a
skeleton of the steps you would take to write one. You would use this PL if
you needed to write a spreadsheet program for a particular application or
for a particular set of users with oddball needs. Its patterns would tell
you at every stage of the process what to build (code or design) next. If
you were an expert programmer but had never done a spreadsheet before you
would be able to build a nice one the first time, and at the end you would
understand how to build anything that was like a spreadsheet - perhaps with
the assistance of the pattern language.

The patterns and pattern language are a stylized way of presenting the
information you need, and each pattern includes the reasons why the thing
you build using the pattern makes it nicer for you as designer/coder and for
the person using the spreadsheet.

You *could* substitute for this some mondo set of abstractions and macros
and a framework for generalized spreadsheets along with some documentation
for it, but the pattern language is more general and in the end it teaches
you about the art of creating spreadsheets. And, in languages like C++,
Java, and SmallTalk, you could do the exact same thing, yet many people
prefer to write pattern languages, mostly because of the pedagogical angle.

Again, if you think patterns are only about abstractions, then you must
notice you never comment to yourself that one piece of code is better than
another nor that one design is better than another. Patterns are a literary
form for expressing those judgments along with the reasons why, and a
pattern language is a literary form for showing and teaching people how to
build a nicely designed and implemented system.

-rpg-

Wade Humeniuk

unread,
Nov 23, 2001, 4:20:54 PM11/23/01
to
> Again, if you think patterns are only about abstractions, then you must
> notice you never comment to yourself that one piece of code is better than
> another nor that one design is better than another. Patterns are a
literary
> form for expressing those judgments along with the reasons why, and a
> pattern language is a literary form for showing and teaching people how to
> build a nicely designed and implemented system.

Do you mean something like this simple case? (In Lisp of course)

(declare-pattern grocery-list
:number-of-items (probably < 200)
:functionality
(must (insert-item and (sort-by-location-in-store since easier-to-follow
and
store is sorted by food-catagory)))
:implementation-data-representation
((lisp-list since lisp-list is not to long and insertable and orderable)
(not hash-table since storage-requirements and complexity
exceed functionality)))

Wade


Kaz Kylheku

unread,
Nov 23, 2001, 5:04:21 PM11/23/01
to
In article <0W=+O1VxGoGH6Zng...@4ax.com>, Paolo Amoroso wrote:
>On 23 Nov 2001 03:32:49 -0800, tfb+g...@tfeb.org (Tim Bradshaw) wrote:
>
>[about the GoF patterns book]
>> When I read it, I found myself just getting annoyed and cynical (OK, I
>> was already cynical), because virtually everything they actually
>> describe is a stupid half-working workaround for something that is a
>> problem only because people program in some completely inadequate
>> language like C++. And this all seemed to be raised up into some
>
>I seem to remember that they candidly admit a few times that languages such
>as Lisp, or maybe they explicitly mention CLOS, don't need patterns. I
>don't have the book handy, so I can't check.

Yes they do, albeit weakly. They say in the introduction that in CLOS
there is a ``lesser need'' for design patterns like Visitor, instead
of saying out right that there is in fact no need. No need implies lesser
need, so at least they aren't lying.

But what is damning is that they admit that if the book's
focus was procedural languages like C, Pascal or Ada, then among the
design patterns, they would have to consider "Inheritance", "Polymorphism"
and so on.

That's a clear indication that the patterns are a manual workaround,
and the authors know it: that they are programs to be executed by the
programmer, where automation is lacking in the machine.

I would add that if the book was about assembly language, then "control
structures" and "data structures" would be listed as design patterns.

Richard P. Gabriel

unread,
Nov 23, 2001, 7:24:52 PM11/23/01
to
in article 9tmejt$gf5$1...@news3.cadvision.com, Wade Humeniuk at
hume...@cadvision.com wrote on 11/23/01 13:20:

Yes, this is an excellent example of completely misunderstanding the concept
of patterns. Is that what you meant?

-rpg-

Friedrich Dominicus

unread,
Nov 24, 2001, 1:50:18 AM11/24/01
to
"Richard P. Gabriel" <r...@dreamsongs.com> writes:
>
> Patterns are about what to build, not how to build it.
I dont't think that is fully the case. Having read your book (Patterns
of Software) and having it always within reach. I cite (page 47
(Pattern languages)
The way Alexander motivates pattern languages is with the example of
barns.
....
If each farmer were to desing and build abarn based on this functional
requirements, each barn would be different, probably radically
different.
...

But barns in Swiss valleys do not vary wildly, so each farmer must be
copying something.
...

That does imply for me that not just what to build is important but
even how you do it. Just an example. I would be damn bad idea to put
the hay in the cellar. So you will always try to put it above the
cattle. That is a how for me. It suggest how to build such things.

In fact pattern has a lot of meanings but the nearest hit IMHO is
template. That has another smell hasn't it ;-)

Well the template of the GOF book are introduced using C++. Therefor
one better know how to deal with C++ to understand those
patterns. In Common Lisp there are surely other templates. E.g a very
easy one is
- transform elements of a collection

Well this is so common that we have some patterns for that. We or the
inventors have even gave it a name. How is it done is still open, I
agree, but there are still suggestions on how to do it.
Take one element
Transform it
keep the result somewhere

>
> But don't dismiss patterns because of the GoF - much of the patterns
> community derides that work as well. Think of the GoF as helping losers lose
> less.

I think this is a bit unfair. It's the same as how the authors do not
state explicitly or clearly that this patterns are not of use
universal but for xy. I don't feel as if it's good idea to call the
users of the GoF book as loosers.

Regards
Friedrich

Fernando Rodríguez

unread,
Nov 24, 2001, 5:24:54 AM11/24/01
to
On Thu, 22 Nov 2001 17:32:56 GMT, Kenny Tilton <kti...@nyc.rr.com> wrote:

>> Where can I learn more about these techniques? O:-)
>>
>
>I plan to share the existing ACL/win32 stuff RSN. The DF engine will be

RSN? O:-)

>If ACL/Win32 is not your platform I will try to work something out,
>either getting the same platform or having someone build FASLs under

I'm using LWW. Is it very implementation dependant? Would it work with
Allegro 'free' version?

>> [1] They abandoned it to start a C++ toolkit called Amulet. That would be
>> fine, since the application I'm dealing with right now is in C++, but Amulet
>> has also been abandoned. What the heck?... ;-P
>>
>
>Wow. I see they Open-sourced it, but that page does not show any news or
>updates in a year. Dead also?

It doesn't look very alive, but I'll take a look at it.

>I have actually ported Semaphors to C++ and Java out of curiosity.
>Without macros more plumbing shows, but they seemed to work. Python
>looks very doable. If CL users don't dig Semaphors I'll see what the
>Pythonites think, looks like they'll eat anything.

I also use Python, so that's OK for me. ;-)

Software Scavenger

unread,
Nov 24, 2001, 5:26:51 AM11/24/01
to
"Richard P. Gabriel" <r...@dreamsongs.com> wrote in message news:<B82428D4.171B%r...@dreamsongs.com>...

> Yes, this is an excellent example of completely misunderstanding the concept
> of patterns. Is that what you meant?

How is it different than a program design document? You can implement
a pattern on different platforms and/or in different contexts, just
like you can port a program to different platforms and/or contexts.
It seems to me the pattern is just an abstraction of the program
design, including the reasons for making the design decisions. By
getting rid of the baggage of implementation, the design becomes more
easily portable. Is a pattern really just a program design document?

Kenny Tilton

unread,
Nov 24, 2001, 6:51:27 AM11/24/01
to

"Fernando Rodríguez" wrote:
>
> On Thu, 22 Nov 2001 17:32:56 GMT, Kenny Tilton <kti...@nyc.rr.com> wrote:
>
> >> Where can I learn more about these techniques? O:-)
> >>
> >
> >I plan to share the existing ACL/win32 stuff RSN. The DF engine will be
>
> RSN? O:-)

within a month?

> I'm using LWW. Is it very implementation dependant? Would it work with
> Allegro 'free' version?

version 1.0 will use ACL Common Graphics enough places to require ACL.
In the GUI stuff. The DF engine is CL+MOP. A quick apropos on the free
LWW suggests the MOP support there would suffice for that much.

version <next> would resurrect the bit I did where I wrapped CG widgets
(and could prob wrap also arbitrary win32 controls).

version <next> would elim ACL CG and just use win32 calls. Then I guess
a port to LWW would require only FFI access to that. Porting from MCL to
ACL took a solid, intense month, FWIW.

version <Mac>... without MOP support in MCL I either do a MOP-less
version or, well, can CMUCL be run under OSX or some Mac Linux or
something?

yes, it works with the ACL 'free' version.

I plan to follow the path of greatest interest (if any), so the above
rough plan might well be overtaken by events.

kenny
clinisys

Kenny Tilton

unread,
Nov 24, 2001, 7:35:34 AM11/24/01
to

Kenny Tilton wrote:
>
> "Fernando Rodríguez" wrote:
...


> > RSN? O:-)
>
> within a month?

btw, before going public I am taking a crack at fixing a long-standing
problem with the propagation, so this could delay things a week.

the flaw arises when:

1. B uses A in a calculation. Maybe B <= 2 * A

2. C uses A and B. Maybe C <= (+ A B)

First of all, we get an inefficiency because C recalculates twice.

Worse, depending onhow things unfolded at runtime, when A changes C
might get notified first and take on a bogus value until B gets notified
and in turn again notifies C to refresh itself.

So:

(setf A 1)

Evaluate B: 2

Evaluate C: 3

(setf A 2)

C changes to 4 (not good)

B changes to 4

C changes to 6 (correct)

The amazing thing to me is that this has not presented a problem in five
years of heavy use in many different kinds of application. But I think I
see a way to sort it out, so I thought I would fix that up before going
public.

Another issue I should address is rolling back dataflow via
unwind-protect, but I am not even sure that is feasible. Currently
changes to a semaphoric slot are manifested outside the flow via echo
functions as each slot takes on a new value, before propagating the
change to dependents. I could easily back out the slot changes, but the
echos of course would have done their thing. Echoing after the
propagation--well, that's an area for future research, but I do know
there are a number of places where it is a Good Thing the side-effects
of echos happen before propagation, so that might be dicey.

Again, this has not been a problem and Semaphors have been stress-tested
severely over the years, so maybe unwinding is not a concern. But if a
wider audience starts running into problems we can play with this.

kenny
clinisys

Wade Humeniuk

unread,
Nov 24, 2001, 10:07:43 AM11/24/01
to
>
> > Yes, this is an excellent example of completely misunderstanding the
concept
> > of patterns. Is that what you meant?
>
> How is it different than a program design document? You can implement
> a pattern on different platforms and/or in different contexts, just
> like you can port a program to different platforms and/or contexts.
> It seems to me the pattern is just an abstraction of the program
> design, including the reasons for making the design decisions. By
> getting rid of the baggage of implementation, the design becomes more
> easily portable. Is a pattern really just a program design document?

To really be effective the vocabulary used in a design document must be
commonly understood by the people sharing the design document. It always
was bit frustrating to write a design document because I always seemed to
take artistic liscense (so that the design would be attractive to other
developers and thus they would adopt the thinking) of thus how much was a
lie (lie by ommision and simplification). Though in the end with people
working on the software together this vocabulary allowed qiuck discussion of
large sections of the implementation. There seemed to be concepts like
finite state machines, device drivers, interprocess communication that were
developed based on conventions and experience that other people had. The
design document became less important as the work went along as people
realized it was of little use.

Wade


Wade Humeniuk

unread,
Nov 24, 2001, 10:27:43 AM11/24/01
to
> Yes, this is an excellent example of completely misunderstanding the
concept
> of patterns. Is that what you meant?

Mostly I was probing for more information (someone had to ask a question).
I see I should do some reading. Anyways...

Is the fault in the example the attempt to formalize? Or is it that a
grocery list not a pattern (though all grocery lists seem to pretty
similar)? Or something else?

Wade


Kaz Kylheku

unread,
Nov 24, 2001, 12:12:32 PM11/24/01
to
In article <a6789134.01112...@posting.google.com>, Software

Scavenger wrote:
>"Richard P. Gabriel" <r...@dreamsongs.com> wrote in message news:<B82428D4.171B%r...@dreamsongs.com>...
>
>> Yes, this is an excellent example of completely misunderstanding the concept
>> of patterns. Is that what you meant?
>
>How is it different than a program design document? You can implement
>a pattern on different platforms and/or in different contexts, just
>like you can port a program to different platforms and/or contexts.
>It seems to me the pattern is just an abstraction of the program
>design, including the reasons for making the design decisions.

A pattern is a step by step recipe which a programmer follows; so in
effect it is software that is executed by the programmer. In principle,
it could be executed by the machine.

In the Introduction, the authors of _Design Patterns_ admit that if their
target languages were C or Pascal, then ``Inheritance'' and ``Polymorphism''
would be included among the design patterns.

So, extending one step further, if they used even lower level languages,
then perhaps ``Control Structure'' and ``Data Structure'' would also
be patterns; the programmer would follow these patterns to crank out
code with certain properties, without the aid of the machine.

Kenny Tilton

unread,
Nov 24, 2001, 4:53:46 PM11/24/01
to

Kenny Tilton wrote:
>
> btw, before going public I am taking a crack at fixing a long-standing
> problem with the propagation, so this could delay things a week.
>
> the flaw arises when:
>
> 1. B uses A in a calculation. Maybe B <= 2 * A
>
> 2. C uses A and B. Maybe C <= (+ A B)
>

...


> The amazing thing to me is that this has not presented a problem in five
> years of heavy use in many different kinds of application.

Well, turned out to be hard to trigger this problem, partly because
recently I put in a partial quick fix:

before propagating a change in A to /any/ of its dependents, flag
/all/ dependents as requiring re-evaluation.

So even if C gets told to recalculate before B, when it samples B the
internals see it requires reevaluation and comes up with a freash value.

But I /did/ manage to set up double calculation (the first erroneous)
and I /have/ seen it in real-world code, so I'm going in. I had to set
up multiple layers of dependency and order the code just right. The
flag-all trick can only go one dependency deep because optimizations
stop propagation if a given node does not change. Thus I do not know if
dependents of a dependent require recalculation until that dependent
recalculates and is observed actually to change.

btw, lest that sound a little hairy to work with, my objective has
always been that the user should just be able to code rules without
worrying about this stuff, just as a spreadsheet author nowadays (not at
first) only needs to watch out for circularities.

kenny
clinisys

Fernando Rodríguez

unread,
Nov 25, 2001, 4:32:55 AM11/25/01
to
On Thu, 22 Nov 2001 17:32:56 GMT, Kenny Tilton <kti...@nyc.rr.com> wrote:

>> I checked the Garnet[1] site and the project seems to be abandoned. Is there
>> any other Lisp GUI toolkit that includes this sort of thing? O:-)
>
>COSI is similar. On this page, check out Paper #6 under 1999 papers:
>
> http://www-int.stsci.edu/apsb/doc/papers-and-meetings/papers.html
>

I also found this
http://cocasoft.cs.tamu.edu/~lidu/courses/db01f/papers/GUInDatabase-goyal98.pdf

It's about abstracting the GUI as a sort of prolog database (with the state of
widgets defined with facts and rules) and considering the event handlers as
queries that modify this DB.

The idea seems cool, thought I'm not sure if I like the pseudo-prolog / C++
implementation. I don't know how this compares to your Semaphores...

Kenny Tilton

unread,
Nov 25, 2001, 11:34:41 AM11/25/01
to

"Fernando Rodríguez" wrote:
>
>
> I also found this
> http://cocasoft.cs.tamu.edu/~lidu/courses/db01f/papers/GUInDatabase-goyal98.pdf
>

Nice find, thx. I'll add that to the bibliography.

> It's about abstracting the GUI as a sort of prolog database (with the state of
> widgets defined with facts and rules) and considering the event handlers as
> queries that modify this DB.
>
> The idea seems cool, thought I'm not sure if I like the pseudo-prolog / C++
> implementation. I don't know how this compares to your Semaphores...

Very similar in many ways. details probably differ, but the big picture
is the same. One quibble: upon discovering parallels between the GUI
problem and database management they concluded that GUI management /is/
a database management problem. I would have said that GUI and DBMS were
special cases of some higher-order state management problem.

As for the implementation language issue, yes, early on I saw that one
of the biggest wins about Semaphors is that they are Just Lisp. GarnetSo
that makes them more approachable. The constraints crowd tended to
create whole new languages built atop the constraint solver. With
Semaphors you have to get used to the paradigm shift, but that's fun.
And nothing stops anyone from having a slot rule invoke an embedded
prolog system or constraint-solver to calculate a new value. So you get
the best of both i think.

back on the ranch, unexpectedly easy progress fixing that dataflow
problem in which slots transiently take on illogical values, might roll
over for me today if a -- simple solution holds up and i get a few
hours in.

kenny
clinisys

Kenny Tilton

unread,
Nov 25, 2001, 1:50:28 PM11/25/01
to

Kenny Tilton wrote:
> back on the ranch, unexpectedly easy progress fixing that dataflow
> problem in which slots transiently take on illogical values, might roll
> over for me today if a -- simple solution holds up and i get a few
> hours in.

ok, that was easy. i'll get to work now on a distro for ACL/CG/Win32.

kenny
clinisys

Richard P. Gabriel

unread,
Nov 25, 2001, 2:37:11 PM11/25/01
to
in article a6789134.01112...@posting.google.com, Software
Scavenger at cubic...@mailandnews.com wrote on 11/24/01 2:26:

It is more like a design document for a class of programs. There is a
pattern language I'm working on for textual electronic communications, which
includes email, instant messaging, chatrooms, group meetings, and a lot
more. This is not a language for just an email client.

A pattern language is an abstraction of a class of program designs, but it
aims to teach, not merely to build.

-rpg-

Richard P. Gabriel

unread,
Nov 25, 2001, 5:05:30 PM11/25/01
to
in article 9toe9l$5fe$1...@news3.cadvision.com, Wade Humeniuk at
hume...@cadvision.com wrote on 11/24/01 7:27:

The example is too small - it's more like a description of an algorithm than
a deep, complex design decision. Moreover, patterns are not suitable for
formalization because the idea is to communicate with as many people as
possible. If a computer could execute a pattern or apply it automatically,
it isn't a pattern to begin with. That's why different disciplines have
different takes on what the most primitive patterns are. Here is a
non-Alexander-written pattern language:

http://www.conservationeconomy.net

-rpg-

Xah Lee

unread,
Nov 25, 2001, 9:38:19 PM11/25/01
to
> Here is a
> non-Alexander-written pattern language:
>
> http://www.conservationeconomy.net

Oh ho my gawd, i thought i'm going to see an eye-opener, but what have i
there? Same type of poetic syllogism that Kent Pitman likes to write on and
on.

Dear Richard Gabriel, recently i wrote a poem, i'll forthwith dedicate it to
all poets and artful folks for the first time, here:

when poets in this world,
savvy an integral or sum,
then belles-lettres and their utters,
might sum to some value.

i got an idea,
to kill off all poets,
so all the literature,
devoid of vacuity can be.

--

Do you believe in UFO? telekinesis? clairaudience? clairvoyance? telepathy?
feng shui? numerology? palmistry? astrology? geomancy? How about the classic
yin-yang and tai-chi and i-chi and the life wheel? Do you believe the youth
reclaiming secrets of yoga? or the modern non-contact healing? Do you have
phantasmagoric vision? Are you into the practices of seers and diviners and
wizardry and witchcraft? A prophet and foreteller? Ghostburster and
exorcist? Do you conglomerate séance and confer with the dead?

Have you ever heard the power of laughter?

I speak art, and art speaks for me; and when i say 1 + 1 = 3, then one plus
one is three. May the world see the beauty in me, and suck it up to me, and
when i describe a pattern, let it encompass computer science. Grand! I am
grand!

Xah
x...@xahlee.org
http://xahlee.org/PageTwo_dir/more.html


> From: "Richard P. Gabriel" <r...@dreamsongs.com>
> Organization: MindSpring Enterprises
> Newsgroups: comp.lang.lisp
> Date: Sun, 25 Nov 2001 14:05:30 -0800
> Subject: Re: Design Patterns vs. better languages

Richard P. Gabriel

unread,
Nov 26, 2001, 2:22:42 AM11/26/01
to
in article B826EB1B.48B2%x...@best.com, Xah Lee at x...@best.com wrote on
11/25/01 18:38:

> i got an idea,
> to kill off all poets,
> so all the literature,
> devoid of vacuity can be.

Given I'm a poet, I guess I should take this as a death threat. Or perhaps
you didn't mean it in a discursive way.

As usual, I love your nonlinear thinking.

There is much to criticize in the patterns, XP, and mathematical [sic]
computer science communities. Let's say we all agree with your argument
that all but the mathematical approaches have proven inept. Why would the
mathematical approach work better? Or are you simply suggesting we give them
a try too?

-rpg-

Will Deakin

unread,
Nov 26, 2001, 3:52:42 AM11/26/01
to
Richard P. Gabriel wrote:

> Why would the mathematical approach work better?

This may be because Xah Lee is a mathematician -- at least by
training -- and not a poet.

> ...Or are you simply suggesting we give them a try too?
I agree with this. Although, as a physicist I would humbly suggest
that you might want to try a physical approach first...

;)w


Tim Bradshaw

unread,
Nov 26, 2001, 5:57:08 AM11/26/01
to
"Richard P. Gabriel" <r...@dreamsongs.com> wrote in message news:<B823D050.124A%r...@dreamsongs.com>...

>
> People who believe in Alexander use his vocabulary, just as many of you use
> the vocabulary of McCarthy, Moon, Steele, and - consider this - me. This
> makes them seem a little cultish, as does your use of a culture-specific
> language. Think about how some folks in the Lisp community feel denotational
> semantics is important or #F is better than NIL. This is cultish. Or is it
> cultural?
>

It may be that I've given the wrong impression about what I meant by
`riddled with cults'. I definitely did not mean to imply that
patterns (or XP, which I find very attractive in many ways) are cults,
just that they tend to get surrounded with them, as does Lisp, and in
fact almost any other computing-related area I know.

This article is too small to define what I mean by `cult' too - in
fact I'm not really sure that I have a good definition other than `I
know one when I see one'. Use of domain-specific jargon does not
constitute a cult (at least not appropriate use: use of lisp jargon at
a party might indicate something bad), obsessing about NIL/#F or
denotational semantics definitely would in the context of Lisp. It's
something to do with a conviction that there is one true way to do
something and that people who do things some other way are heretics or
less than human.

I think computing is surrounded by cults because we don't really have
any good answers. All the answers we have are basically pretty shit
ones or just don't apply, so we just thrash around trying to make
something work. But people hate that - they really want certainty
and not having to think about the problem. So they latch on to some
idea and convince themselves that this, and only this, is the way to
solve all the problems they have. You see this a lot with various
formal `mathematical' approaches to programming which people get
completely wound up about (including some here). It helps a lot if
the topic of the cult is not realistically obtainable - `if only we
had a Lisp OS all our problems would go away' - because it makes the
cult harder to destroy. You see this really a lot.

In an environment where cults flourish, good ideas grow cults like
barnacles or something, so just because I think that patterns / XP are
surrounded by cults does not mean I think they are bad (Lisp is
*definitely* surrounded by cults, and I kind of like it even so). To
some extent patterns seem to me to be an anti-cult, in fact.

I just can't help but bring up a non-computing cult in this context:
valves (tubes). I don't read Hi Fi magazines but last time I looked
at one there was just mass obsession about the mystical virtues of
valve amplification. I'm as keen on valves as the next person (I've
built valve amplifiers and I have more valve equipment than is good
for me or entirely safe) but I still find the stuff in the Hi Fi press
really strange. One of the things that is (was) fashionable is what's
called `single-ended' designs. As far as I can see these are systems
with no feedback - you just rely on the valves being pretty linear.
Well, valves are pretty linear in fact, so they do OK - maybe you get
under 10% distortion! Of course the terrible truth is that people
*like* the distortion. At least musicians admit this: no one ever
claimed an AC30 has `low distortion', at least not when the gain is
all the way up.

--tim

Kenny Tilton

unread,
Nov 26, 2001, 8:47:58 AM11/26/01
to
> > "Richard P. Gabriel" <r...@dreamsongs.com> wrote in message
> > news:<B82428D4.171B%r...@dreamsongs.com>...
> >
> >> Yes, this is an excellent example of completely misunderstanding the concept
> >> of patterns.

ooh-ooh, I think I got it. I was converting from the ACL project manager
to defsystem and realized that although I had the /doc/ for defsystem I
did not know how it was used most effectively.

This reminded me of what i guess would be a pattern (CMIIW): setting up
parallel test, acceptance and production environments for a software
system. details would vary from DOS to UNIX to VMS, and would depend on
details such as what source management utilities were available. but
there would be certain core ideas, such as using some form of logical
name mechanism consistently to guard against inadvertently running
production code against test data.

i guess i am thinking "pattern" when i say to myself: I know how I did
this under VMS, how can I do this under NT?

hang on. that sounds like abstraction. oh well.

still, that sort of thing (how to manage software change with parallel
environments) that I have never seen documented but that every software
shop faces. maybe that is not a pattern, but it does sound like
something worthwhile to get written down so folks aren't forever
reinventing (or staggering along without) that wheel.

which reminds me of a craftsman's "bag of tricks"...

kenny
clinisys

Kenny Tilton

unread,
Nov 26, 2001, 8:59:29 AM11/26/01
to
"Richard P. Gabriel" wrote:
>
> in article B826EB1B.48B2%x...@best.com, Xah Lee at x...@best.com wrote on
> 11/25/01 18:38:
> > i got an idea,
> > to kill off all poets,
> > so all the literature,
> > devoid of vacuity can be.
>
> Let's say we all agree with your argument
> that all but the mathematical approaches have proven inept. Why would the
> mathematical approach work better?

uh-oh. is this how sociology journals ended up looking like calculus
texts?

XL also wondered aloud if programming was harder than building
construction, or something to that effect. I wager we won't know until
we have been building programs for a couple hundred years. How long had
people been building things before the Romans came up with the arch?
Then they got all excited and ran around building stuff with their new
toy.

Programming is young, we need an arch or two of our own.

kenny
clinisys

Xah Lee

unread,
Nov 26, 2001, 9:06:44 AM11/26/01
to
Dear Richard Gabriel and friends,

> There is much to criticize in the patterns, XP, and mathematical [sic]
> computer science communities. Let's say we all agree with your argument
> that all but the mathematical approaches have proven inept. Why would the
> mathematical approach work better? Or are you simply suggesting we give them
> a try too?

When subjects are well understood, it is called mathematics. In trying to
understand anything, mathematical is the only way. There are many aspects to
the question "what is mathematics". One practical view is that Mathematics
is a form of extreme scientific rationalism. It is with this stance, we
should approach to software engineering and everyday questions.

What people usually mean by math or mathematical, is things that are already
very well understood, having lots of theorems and various formal
foundations, especially in the form of symbols on paper. For example,
numbers and equations and geometric figures and measures; the average people
will take as mathematics. In general, unless you have had some familiarity
with abstract algebra or topology, it is hopeless for laity to understand in
any slight sense what modern mathematics is about, less to ponder about
"what is mathematics". From a more advanced point of view, mathematics are
simply _concepts_. Concepts so abstract (and advanced and difficult) that
one has to get years of training just to be able to imagine it. For example,
there are great many math concepts that i cannot grasp. (e.g. what's a
bundle? what's projective geometry in higher dimensions? what's a lattice?
what's a rational curve? ...) Same applies to any accomplished
mathematician. Much for lack of time to study them all, also for extreme
lack of material and people who know them. In contrast, software patterns
and OOP mantra and eXtreme Programing every idiot can love and embrace and
sing, just like solutions for weight-lost abound, except for the hard-core
less eating and more exercise.

300 years ago mathematicians have the faintest idea what numbers are. Today,
there are still a lot unanswered questions about the nature of numbers, but
the difference of today's understanding and 300 years ago is like the
difference of knowing English versus the English alphabets. As near as 300
years ago, there are quite a lot math practitioner who made significant
contributions to mathematics, yet who speaks of magic and God and voodoo as
explanation of many aspects of numbers that are not understood. (i'm not
going to turn this message into a math history write up... but just as a few
examples from top of my head... the nature of number 0, negative numbers,
irrational numbers, complex numbers, infinity, transcendental numbers
(that's non-algebraic numbers), transfinite numbers are all filled with
mysticism and crap as near as 300 years ago, by as famous mathematicians as
Euler, Pascal, Kepler, and others.... bogus fads are not limited to numbers,
but much other math objects or concepts such as geometry, calculus etc.)

So, when we ask "why should we rely on mathematical methods in computer
engineering?" It is like asking "why should we be sensible? Why don't we all
fortune-tell and crystal-gaze and prance and fuck around?".

--

I have known quite many mathematicians in my life. The majority of them had
their degrees in distant past. I have realized that they have absolutely no
interest in mathematics, nor remember what is mathematics, if ever. Note
that many of these have Ph Ds from Stanford and Berkeley. My formal indirect
boss, who is a lady of respectable age and have a math ph D in perhaps
topology, are so old-fashioned and un-scientific who even keep fortune
cookie tickets as good-luck charm. I'm so not impressed with people who have
math degrees. What i learned from my life experiences is that even
mathematics is of austere rigor and respectability, a person who had math
training can be just as a kook as the next utterly ignorant zombie in
everyday subjects.

Having been working in Silicon Valley (Mountain View, CA) since about 1998,
i'm so unimpressed with coders and programers and engineers too. I deem
myself to be not a mathematician, and also lack in many basic knowledge in
computer science. (never studied algorithms in any direct way, for example.)
But i witness these multitudes of lesser learned around me, one sloppier
than another, one confident than another, churning out crappy software one
faster than another, living their happy lives unassuming. (it may be just
that i haven't met many respectable engineers.)

There is one message i want to emphasize:
Spread the idea that irresponsible software license is not acceptable. When
the public demand responsible software and engineers responsible for their
fuckups, then all sorts of fads and crap in the computing industry will
disappear.

Xah
x...@xahlee.org
http://xahlee.org/PageTwo_dir/more.html


> From: "Richard P. Gabriel" <r...@dreamsongs.com>
> Organization: MindSpring Enterprises
> Newsgroups: comp.lang.lisp
> Date: Sun, 25 Nov 2001 23:22:42 -0800
> Subject: Re: Design Patterns vs. better languages
>

Wade Humeniuk

unread,
Nov 26, 2001, 11:39:53 AM11/26/01
to
> The example is too small - it's more like a description of an algorithm
than
> a deep, complex design decision. Moreover, patterns are not suitable for
> formalization because the idea is to communicate with as many people as
> possible. If a computer could execute a pattern or apply it automatically,
> it isn't a pattern to begin with. That's why different disciplines have
> different takes on what the most primitive patterns are. Here is a
> non-Alexander-written pattern language:
>
> http://www.conservationeconomy.net

My thoughts:

On first glance the network diagram at the site looks like a technique I saw
for writing. Start with a central core idea and list all thoughts that come
to mind and draw the connections between each. This seminar I was at
presented this technique to get a person's unordered thoughts out and
allowing them to be written in a linear and coherent form.

Patterns represent the knowledge of a person, interconnections, relationship
with other people and the deep structure of "the nature of the universe".

A description (the language used to describe) of a thing is not the thing.
Thus to communicate knowledge (teach) one has to use the actual things, or
embed the knowledge in the actual things. This knowledge must be
discoverable. A pattern language should lead you to a situation where you
can understand for yourself.

Thought is loosely ordered and given any two things a mind will attempt to
infer a relationship between those things. Some relationships are useful
(patterns) and some are not. Which are useful cannot be known ahead of
time. To learn you have to be put in new situations where your knowledge
is more chaotic (wrong, dead ends,...)

Patterns most likely have an aesthetic appeal. Maybe it is an appeal to
order or the need to understand and be secure in chaos.


Wade


Kent M Pitman

unread,
Nov 26, 2001, 11:43:30 AM11/26/01
to
Xah Lee <x...@best.com> writes:

> What people usually mean by math or mathematical, is things that are already
> very well understood, having lots of theorems and various formal
> foundations, especially in the form of symbols on paper.

Actually, as nearly as I can tell, most people on the street hate
mathematics, and not because it is "formal" but because it pretends to
be. I think most would describe it as "detached from reality" in that
it often idealizes a topic in a way that while it gives more
predictability and structure to the topic in some theoretical way, it
still doesn't give a sense of the random or statistically confusing
way the real world behaves, and the complex nature of interactions
that drive it.

> So, when we ask "why should we rely on mathematical methods in
> computer engineering?" It is like asking "why should we be sensible?
> Why don't we all fortune-tell and crystal-gaze and prance and fuck
> around?".

I don't really disagree with anything you say, except your conclusion.
The reason fortune telling and crystal gazing is so popular is that it
seeks to answer questions that mathematics leaves aside as uninteresting,
lacking in hard data, poorly specified, etc. That is, mathematics doesn't
really seek to address real world questions head-on.

For example, mathematics may tell you a certain size beam will suffice to
hold a specified weight, but knowledge of practicality can tell you that
the beam may be imperfect in nature, that it may get old, that the specs
may be exceeded, that things could be wrong. People use math to get them to
a certain point, but perceive that beyond that, mathematics will not get
them the rest of the way. You can, of course, model all the rest of these
things with formal statistics. I'm sure insurance companies do. But
I think most people don't.

> There is one message i want to emphasize:
> Spread the idea that irresponsible software license is not acceptable. When
> the public demand responsible software and engineers responsible for their
> fuckups, then all sorts of fads and crap in the computing industry will
> disappear.

And much good with it.

As long as "software" is all of one kind, and not distinguished as to whether
it's "suitable for engineering", etc., this disagreement will exist.
Programming is just communicating, and to say that communicating must be
rigorous is to say those with nothing rigorous to say must not speak.

Lieven Marchand

unread,
Nov 26, 2001, 12:01:41 PM11/26/01
to
Kenny Tilton <kti...@nyc.rr.com> writes:

> uh-oh. is this how sociology journals ended up looking like calculus
> texts?

Looking like it is the apex of their achievement. Sokal has
brilliantly exposed this idiocy with his hoax.

--
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

lars.r....@telia.com

unread,
Nov 27, 2001, 7:21:29 AM11/27/01
to
On 26 Nov 2001 02:57:08 -0800, tfb+g...@tfeb.org (Tim Bradshaw)
wrote:

>
>I just can't help but bring up a non-computing cult in this context:
>valves (tubes). I don't read Hi Fi magazines but last time I looked
>at one there was just mass obsession about the mystical virtues of
>valve amplification. I'm as keen on valves as the next person (I've
>built valve amplifiers and I have more valve equipment than is good
>for me or entirely safe) but I still find the stuff in the Hi Fi press
>really strange. One of the things that is (was) fashionable is what's
>called `single-ended' designs. As far as I can see these are systems
>with no feedback - you just rely on the valves being pretty linear.
>Well, valves are pretty linear in fact, so they do OK - maybe you get
>under 10% distortion! Of course the terrible truth is that people
>*like* the distortion. At least musicians admit this: no one ever
>claimed an AC30 has `low distortion', at least not when the gain is
>all the way up.

What a coincidence. The latest issue of "Allt om Elektronik" (a
Swedish DIY Electronics magazine) has a project where you can build
"the Tube Clipper" which is a device to be connected somewhere in the
signal chain of your HiFi.

It seems to introduce some kind of distorsion (clipping or something
else, I'm not an electronics guy). Anyway, this is supposed to
generate the "valve sound" so much revered by some of the HiFi freaks.
What will they think of next?

Lars

Will Deakin

unread,
Nov 27, 2001, 7:40:50 AM11/27/01
to
lars.r....@telia.com wrote:

> It seems to introduce some kind of distorsion (clipping or something
> else, I'm not an electronics guy). Anyway, this is supposed to
> generate the "valve sound" so much revered by some of the HiFi freaks.

If I try and rationalise my like of the valves sound is because they
have a continuous sort of browning distortion of sound -- rather
than a direct clipping of the noise on amplification.

> What will they think of next?

An artificial fish that sings christmas carols -- oops, they've
already done that,

:)w


lars_lundback

unread,
Nov 27, 2001, 7:50:35 AM11/27/01
to
On Tue, 27 Nov 2001 12:40:50 +0000, Will Deakin
<aniso...@hotmail.com> wrote:


>If I try and rationalise my like of the valves sound is because they
>have a continuous sort of browning distortion of sound -- rather
>than a direct clipping of the noise on amplification.

Hmm, maybe a brownish piece of cloth on top of the strings of my grand
piano would make it sound like a valve piano?

Lars

Xah Lee

unread,
Nov 27, 2001, 10:16:58 AM11/27/01
to
Dear morons and readers,

Lieven Marchand wrote:
> Kenny Tilton <kti...@nyc.rr.com> writes:
>
>> uh-oh. is this how sociology journals ended up looking like calculus
>> texts?
>
> Looking like it is the apex of their achievement. Sokal has
> brilliantly exposed this idiocy with his hoax.


What Kenny Tilton and Lieven Marchand are trying to say, is that sometimes
we see morons who are less than brainy, but nevertheless are good men, and
tried hard to keep their professional liveliness by publishing. Because
these are dullards, they fail to grasp meanings, fail to penetrate, fail to
represent, and often sticking to dogmatic methodologies and ends up with
papers or text books filled with inanities consisting lots of ineffectual
symbols and equations, which the Kenny Tilton and Lieven Marchand class of
moron wants to equate as "mathematics".

Nothing out of ordinary.

Now, the Kenny Tilton and Lieven Marchand class of morons also like to
impress and sound big when encountering the flamboyant Xah, but lacks the
ability. Therefore, their half-developed expressions and half-assed taunts
directed at Xah needs Xah Lee to help them conceive their meanings and
representation.

Now, who the fuck is Sokal? If you are not citing names that can be found in
standard dictionaries, would you please give some explanation? How much do
you know of Sokal? Is Sokal's ideas you support? How and why? You impressive
moron.

Xah
x...@xahlee.org
http://xahlee.org/PageTwo_dir/more.html

Xah Lee

unread,
Nov 27, 2001, 10:22:14 AM11/27/01
to
Dear readers,

Kent Pitman is a piss. Look at the following:

Pitman wrote:
> Xah Lee <x...@best.com> writes:
>> What people usually mean by math or mathematical, is things that are already
>> very well understood, having lots of theorems and various formal
>> foundations, especially in the form of symbols on paper.
>
> Actually, as nearly as I can tell, most people on the street hate
> mathematics, and not because it is "formal" but because it pretends to
> be.

There are several evils here. First, Pitman divert the context of the
conversation, from my discussion of meaning of mathematics to how street
people think of mathematics. He then lies. He says that the street folks
hates math not because math is difficult or very abstract or rigorous but
because they think mathematics pretends to be being about the world. Can he
really stand to what he said? Also, he is fucking insincere here. He use
calculated imprecise phrases that has lots of interpretations, giving him
certain freedom to expand later depending on the situation. That is why you
see the word "formal" as quoted, or the terse "it pretends to be"; what
exactly? I believe Kent Pitman have the ability to write clearly and
succinctly, but most of the time he crafts his writings so that it sounds
like he is expressing his opinions humbly, but there are lots of insinuation
and subtle twists that are masked as unintentional and aimed to deceive.

When one abuses writing skills to advance his views and denies the
hanky-panky part, that is malicious cheating.

> I think most would describe it as "detached from reality" in that
> it often idealizes a topic in a way that while it gives more
> predictability and structure to the topic in some theoretical way, it
> still doesn't give a sense of the random or statistically confusing
> way the real world behaves, and the complex nature of interactions
> that drive it.

What an insulting baloney.

Who does the "most" refer to? Is it still the average people on the street?
If so, do you really believe that the average people on the street have so
and so exquisite opinions about the nature of math? Or, does the "most" has
suddenly and subtly changed context to mean the average programer? Which one
exactly, you fuck?

And, look at the way Pitman bloats. He's on to predictability and structure
and theoretical and interaction all in one sentence. What does the fuck it
really mean?

In the process of expressing one's thoughts or ideas in a mathematical or
formal way, it almost always is the case that the idea will clarify, and
reveal many of it's flaws or absurdities even rendering it totally garbage.

If i try to summarize the paragraph Pitman wrote above, it may be this:

"Mathematics is just a model of reality. Reality is very complex, and math
makes sacrifices in order to gain understanding."

If that's all Pitman is saying, then it is nothing out of common knowledge.
However, Pitman is probably hinting: "_therefore_ math is not the only way
to look at things." He didn't say it and was ambiguous because he knew if he
did say it outright, then he would look so majorly stupid. His meanings must
hide beneath grand verbiage.

>> So, when we ask "why should we rely on mathematical methods in
>> computer engineering?" It is like asking "why should we be sensible?
>> Why don't we all fortune-tell and crystal-gaze and prance and fuck
>> around?".
>
> I don't really disagree with anything you say, except your conclusion.
> The reason fortune telling and crystal gazing is so popular is that it
> seeks to answer questions that mathematics leaves aside as uninteresting,
> lacking in hard data, poorly specified, etc. That is, mathematics doesn't
> really seek to address real world questions head-on.
>
> For example, mathematics may tell you a certain size beam will suffice to
> hold a specified weight, but knowledge of practicality can tell you that
> the beam may be imperfect in nature, that it may get old, that the specs
> may be exceeded, that things could be wrong. People use math to get them to
> a certain point, but perceive that beyond that, mathematics will not get
> them the rest of the way. You can, of course, model all the rest of these
> things with formal statistics. I'm sure insurance companies do. But
> I think most people don't.

Here, Pitman got very confused. On one hand, he tried to drive away the
aspect of math i mentioned that mathematics is the scientific approach of
understanding. He focused on the limitations of mathematics, and also
confuses either intentionally or unintentionally about people's ability to
do mathematics. Because his grand confusion and a bit of guilt, he mentions
reluctantly about the use of mathematics by insurance industry. This mention
is perhaps to indicate that he is a just man who thought of all aspects, or,
he really got confused and couldn't decide how he takes math.

>> There is one message i want to emphasize:
>> Spread the idea that irresponsible software license is not acceptable. When
>> the public demand responsible software and engineers responsible for their
>> fuckups, then all sorts of fads and crap in the computing industry will
>> disappear.
>
> And much good with it.

Much good with it???

Ambiguity is one of Pitman's weapon.
Does Kent Pitman here wanted to say "Xah, i think that is a great idea.". Or
is he saying "Xah, that's fine with me." And if the latter, what is the
significance? Why does he have to mention it? Why can't he outwardly say
"yeah, go fuck yourself with your insults, Xah".

> As long as "software" is all of one kind, and not distinguished as to whether
> it's "suitable for engineering", etc., this disagreement will exist.
> Programming is just communicating, and to say that communicating must be
> rigorous is to say those with nothing rigorous to say must not speak.

Here's another example of his grand confusion. A simple term "software" is
now ill-defined touching on the art of programer communication. Does my
comment about software license necessitate this philosophizing?

There is an classic art form called polemics. Polemics is basically the _art
of argument_. Even today we can still see some form of it in schools or TV
show, where two team of students takes opposite sides of some controversial
issue such as capital punishment. It does not matter which team believes in
which side, but that the person has the ability to advance his opinions,
even an outright incorrect fact. A skilled arguer can assert 1+1=3, dinosaur
doesn't exist, i'm god, or any absurd idea in some very convincing way if
there is a large gap of skill and knowledge between him and his audiences'.

Kent Pitman may not be evil, but old. I advise folks here: if Pitman makes
technical comments about lisp, than perhaps it is good. In any thread of
heated discussion, take his elaborate and protracted commentaries carefully.
Often you can just treat it as time-wasting crap, especially in threads he
is defensive.

Amid the world of information and chaos and polemic artists and all sort of
competing claims, what can you poor readers do? Open your mind, but JUDGE
FOR YOURSELF. Really.

Xah
x...@xahlee.org
http://xahlee.org/PageTwo_dir/more.html

Andreas Bogk

unread,
Nov 27, 2001, 10:32:21 AM11/27/01
to
Xah Lee <x...@best.com> writes:

> When subjects are well understood, it is called mathematics. In trying to
> understand anything, mathematical is the only way. There are many aspects to
> the question "what is mathematics". One practical view is that Mathematics
> is a form of extreme scientific rationalism. It is with this stance, we
> should approach to software engineering and everyday questions.

I would not speak badly about mathematics, since I enjoy exploring
it's world of thought a lot.

But I hope you are aware of the limits of mathematics, and rationalism
for that matter. I am sure you're familiar with the works of Cantor,
Hilbert, Russell, Gödel, Turing, Church and Chaitin[0], and their results
on incompleteness.

One of the big challenges of solving problems is that our brain has a
limited capacity for rational models of the world. The world just is
arbitrarily complex. However, we humans have a way to cope with
incompleteness, it's called "intuition" or "art".

Good engineering is the right mixture between mathematics and art.

I agree however that standards in software engineering are absolutely
lousy compared to other branches of engineering. I'd blame this on
schools who still think computer science is an obscure branch of
mathematics.

Andreas

[0] Chaitin is *the* current expert on computability and complexity
theory. His work at

http://www.cs.auckland.ac.nz/CDMTCS/chaitin/

is a must-read for anybody seriously interested in the foundations of
our craft. His book "The Unknowable" presents the classic proofs of
Gödel and Turing in Lisp. In contrast to the original papers, I could
actually understand the proof, and it made the light go on for me:

http://www.cs.auckland.ac.nz/CDMTCS/chaitin/unknowable/index.html

Andreas

--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)

Kenny Tilton

unread,
Nov 27, 2001, 10:45:13 AM11/27/01
to
Xah Lee wrote:
>
> Now, who the fuck is Sokal? If you are not citing names that can be found in
> standard dictionaries....

Dictionaries? Real Morons use Google and discover...

http://www.physics.nyu.edu/faculty/sokal/

kenny
clinisys

Kent M Pitman

unread,
Nov 27, 2001, 12:55:27 PM11/27/01
to
Xah Lee <x...@best.com> writes:

> Dear readers,
>
> Kent Pitman is a piss.

I doubt you can support this mathematically.

> ... He then lies. ...

I'm sure you can't support this.

I think

lie(x) implies tell_falsehood(x) and intends(x,tell_falsehood(x))

You're going to have a lot of trouble with intends.

I thought perhaps it was worth engaging you in discussion, since rpg
chose to indulge you.

I think I'll just stop here.

I don't really mind you being abrasive and calling me names.
I do, however, mind you telling falsehoods, regardless of your intent.
Especially in the name of furthering mathematics.

Fred Gilham

unread,
Nov 27, 2001, 2:17:38 PM11/27/01
to

lars.r....@telia.com writes:

I've been trying to play jazz guitar for a while now. I've been
playing guitar for a long time, never very good, always liked jazz,
decided that if I was never going to be good at it, I'd be no good at
something I really liked. As Chesterton said, anything worth doing is
worth doing poorly....

Anyway with electric guitars, the amplifier is actually part of the
instrument. If you listen to an unamplified solid body guitar you'll
notice that it's an essential part of the instrument. :-)

Different styles of guitar playing seem to be traditionally associated
with different distortion sounds. Jazz guitar is generally supposed
to be `clean', almost flute-like, with almost no pluck sound. Many
jazz guitarists use solid state because they aren't looking for
distortion. They also turn the treble down on the guitar and/or the
amplifier to get rid of high-frequency transient kinds of sounds.
They also use flat-wound strings that have no twang. Few sounds are
prettier than a properly amplified, flat-wound G string played in the
higher positions on a nice hollow-body f-hole style jazz box.

Other styles, on the other hand, such as blues or rock, use varying
amounts of distortion. And tube amplifiers are generally preferred
where distortion is used. Most people argue that this is because
tubes go into distortion (aka clipping) more softly. When an
amplifier is overdriven, it starts to square off the tops of the
waves. A tube amplifier does this more gradually and gives you
rounder distorted tops, while solid state amplifiers give you a more
square-wave-like distortion. The rounder distortion sounds more
pleasing to the ear because of its particular mix of harmonics. Again
there's some uncertainty about exactly which harmonics are giving
pleasure. The consensus seems to be that even harmonics are more
pleasant than odd harmonics.

This is relevant in hi-fi electronics because almost every amplifier
will clip to some extent when being played at a significant volume
level. This creates distortion, and again the tube-type distortion is
more pleasing to the ear.

The interesting thing, from what I can discover, is that even
harmonics are `symmetrical', that is, both halves of the wave are
distorted in the same way, while odd harmonics are asymmetrical, that
is, one half of the wave form looks different from the other half. At
least that's the impression I got from some stuff I read on the
Internet. We all know how reliable that is. But if this is the case,
one can argue that the ear responds to the symmetrical pattern of
sound better than to an asymmetrical pattern.

--
Fred Gilham gil...@csl.sri.com
"...If reason is no longer a faculty enabling us to discern some
cosmic design, then it is no longer clear what claim reason has upon
us, or upon our politics. On the contrary, the sorts of habits that we
associate with `reasoning' --- that is, reflecting and discussing and
trying to achieve some kind of coherence among our various opinions
--- can come to seem like nothing more than the mental preferences (or
prejudices) of a particular class of people --- the dogmatic
proceduralism of an educated elite." --- Steven D. Smith

Will Deakin

unread,
Nov 27, 2001, 3:34:01 PM11/27/01
to
> Hmm, maybe a brownish piece of cloth on top of the strings of my grand
> piano would make it sound like a valve piano?
Sure. This is is a beautiful thought. However, having never owned a grand[1]
I cannot say I have ever tried it and so could not say.

For me, I find small pieces of beige cardboard attached to a comb is sufficient...

;)w

[1] is it a full concert? or a baby? whatever -- cool!

lars_lundback

unread,
Nov 27, 2001, 3:52:14 PM11/27/01
to
On 27 Nov 2001 11:17:38 -0800, Fred Gilham
<gil...@snapdragon.csl.sri.com> wrote:


>The interesting thing, from what I can discover, is that even
>harmonics are `symmetrical', that is, both halves of the wave are
>distorted in the same way, while odd harmonics are asymmetrical, that
>is, one half of the wave form looks different from the other half. At
>least that's the impression I got from some stuff I read on the
>Internet. We all know how reliable that is. But if this is the case,
>one can argue that the ear responds to the symmetrical pattern of
>sound better than to an asymmetrical pattern.
>

I admire your elegant final swerve to get us into patterns again. The
actual interpretation of these patterns occur in the brain of course.
Certain kinds of patterns will be interpreted as language. We can now
glimpse a future better language: Symmetrical Common Lisp.

Lars


Xah Lee

unread,
Nov 27, 2001, 11:24:57 PM11/27/01
to
Kent Pitman is the world's number one mother fucking hypocrite. (in
comp.lang.lisp for sure.)

Let me prove it to ya.

i wrote:
>> Kent Pitman is a piss.

Pitman replied:

> I doubt you can support this mathematically.


Readers, the first thing to notice is that this is not the way a serious
letter would start. If Pitman seriously believed that i have stepped beyond
any reason, stepped beyond civilization, stepped beyond tolerance, he would
not and should not start a letter with such semi-funny pun, joking on an
outright name-calling. The semi-serious tone can be seen in other parts of
his message.

Then Pitman continued:

>> ... He then lies. ...
>
> I'm sure you can't support this.

Notice that he cut out my sentences before and after, so that the only part
is "He then lies".

He does this so that any reader reading his post will immediately get the
impression that I accused Kent Pitman of plainly lying. Only a reader who
have participated in this thread, and have paid attention to my posts will
have a better idea what the before and after sentences' significance, and in
what context.

Kent Pitman continues:

> I think
>
> lie(x) implies tell_falsehood(x) and intends(x,tell_falsehood(x))

One can see that Pitman indeed charge that _Xah Lee accused Kent Pitman of
plainly lying about something_.

One also should notice that instead using plain English, Pitman is a bit
playful and use a programing notation to indicate what he meant. (readers
should not doubt that Pitman is quite capable of saying the exact same thing
in a clear and absolute way using plain English.)


> You're going to have a lot of trouble with intends.

This is a clear case of Kent's ambiguity weapon. By that he may be saying
"Xah, how do you explain your behavior as i described?" with a stern face.
Or, it can carry the tone "Or dear Xah, you little playful devil. <grin>
Explain yourself!".

The sentence "You're going to have a lot of trouble with intends." can also
have other interpretations. It can mean "Xah, do you know exactly what you
wanted to say?" Or, it can be a joke as a teacher telling his student's
weakness in a particular function of a programing language. Notice that
these different interpretations are vastly different from each other.

A skillful writer write what he means. A master writer writes the intended
sentence.


> I thought perhaps it was worth engaging you in discussion, since rpg
> chose to indulge you.


This is where Kent Pitman drags in Richard Gabriel.

Pitman wanted to get reader's attention, that Richard Gabriel and me has
exchange some messages, because Richard Gabriel is a well-known and
well-respected figure in Lisp community. Pitman wanted to sound like as if
Mr. Gabriel tried to pity Xah and let Xah have something to say. Note that
Pitman said "I thought perhaps it was worth engaging you in discussion".
This is to give the impression, that Pitman argued with Xah because he is
pitying Xah, and wanted to let Xah have a chance to speak among those who
have recognized credentials.

> I think I'll just stop here.


This sentence is to give the impression that the very noble and loving and
well-known and well-respected Kent Pitman cannot really help the nameless
Xah Lee and have to let it go.


> I don't really mind you being abrasive and calling me names.


This is again to emphasize, the degree of tolerance Pitman has shown.


Pitman ended his message thus:


> I do, however, mind you telling falsehoods, regardless of your intent.
> Especially in the name of furthering mathematics.

This sentence further emphasized to the readers, how utterly important is
TRUTH and KNOWLEDGE and MATHEMATICS, but Xah Lee is truly a lost kid.


----------------------------

Dear Readers of comp.lang.lisp,


Notice that in my long message criticizing Kent Pitman, he did not even face
one point squarely. Instead, he equivocates and drag in Richard Gabriel and
bow out. This is not the first time Pitman behaved this way. Since the year
2000, i have criticized Kent Pitman in this newsgroup about around 4 times,
each separated by few months. Kent Pitman did respond to my messages or in
the thread mentioning my criticisms a few times, but never faced my
criticism head on. (once he did and got shot down by me.) He always dodge
and quibble and equivocate and ramify. For those inclined, you can go to
deja.com and search for the string "xahlee pitman" and you'll get a some
picture of our crossings.

I already gave up on Kent. Thus in message

> From: Xah Lee <x...@best.com>
> Newsgroups: comp.lang.lisp
> Message-ID: <B81BAF25.78A9%x...@best.com>
> Date: Sat, 17 Nov 2001 14:07:41 GMT
> Subject: Re: I'm outta here...

i simply attacked Kent in a personal way for the first time. Kent Pitman did
not respond.

Now, in this thread, i see that Kent Pitman replied my message on
emphasizing math, thus i decided to compose a detailed message in response.
In particular, i detailed Kent Pitman's sophistry. His reply as you have all
seen in my analysis above.

The reason Kent Pitman's letter is of serious content but semi-serious
style, is because Pitman is a coward. A coward is ambiguous, because he do
not stand by his words. In one hand he wants the world to know that Xah has
done wrong, but on the other hand he fears of saying such in a clear,
unambiguous manner. He do not wish to reason. He fear the truth.

Dear Pitman, your reputation in this group just went down a few serious
notches. Cheer up. I'll invite you to dinner if you deign to ring my bell
when you pass by.

Frank A. Adrian

unread,
Nov 27, 2001, 11:40:17 PM11/27/01
to
Xah Lee wrote:

> Now, who the fuck is Sokal? If you are not citing names that can be found
> in standard dictionaries, would you please give some explanation? How much
> do you know of Sokal? Is Sokal's ideas you support? How and why? You
> impressive moron.

Sokal was a guy who a few years ago performed a little sociology
experiment with one of the major sociology journals. He constructed a
completely bogus paper, filled with jargon and mathematical underpinnings,
much of it inconsistent, and was able to get the paper published with
little more than small grammatical changes. None of the supposed expert
referees were able to spot this exceptionally nonsensical paper for what it
was. He then published a second paper castigating the journal and
explaining point by point how his paper was incorrectly accepted. You can
find the story at http://www.keele.ac.uk/depts/stt/stt/sokal.htm.

Not that I think this says much about the state of sociological research
then or today. It has more to say about the time pressure that reviewers
are under, the fact that fields of knowledge have grown so broad that
almost no one is an expert in all parts of even a single discipline, and
the normal *human* tendency to give a credentialed stranger the benefit of
the doubt when confronted with information outside their specialty.

And not that Computer Science has done much better with some of the papers
I've seen :-).

faa

Christopher Stacy

unread,
Nov 27, 2001, 11:45:25 PM11/27/01
to
I think the tube people like the distortion properties that
occur at the top of the envelope (rather than the straight
clipping that solid state gives you).


Thomas F. Burdick

unread,
Nov 28, 2001, 1:31:23 AM11/28/01
to
"Frank A. Adrian" <fad...@qwest.net> writes:

> Not that I think this says much about the state of sociological research
> then or today. It has more to say about the time pressure that reviewers
> are under, the fact that fields of knowledge have grown so broad that
> almost no one is an expert in all parts of even a single discipline, and
> the normal *human* tendency to give a credentialed stranger the benefit of
> the doubt when confronted with information outside their specialty.
>
> And not that Computer Science has done much better with some of the papers
> I've seen :-).

Of course, most people don't claim CS to be a Real Science the way
physics and chemistry are. Some claim that computer scientists really
know what they're doing, but I think most (?) don't. Most aspire to
it, kind of like biology 150 years ago. I suspect that sociology is
in a similar situation. It only becomes problematic when people
pretend they know more than they do.

--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'

Tim Bradshaw

unread,
Nov 28, 2001, 8:20:54 AM11/28/01
to
Fred Gilham <gil...@snapdragon.csl.sri.com> wrote in message news:<u7vgfwd...@snapdragon.csl.sri.com>...

> Different styles of guitar playing seem to be traditionally associated
> with different distortion sounds. Jazz guitar is generally supposed
> to be `clean', almost flute-like, with almost no pluck sound. Many
> jazz guitarists use solid state because they aren't looking for
> distortion. They also turn the treble down on the guitar and/or the
> amplifier to get rid of high-frequency transient kinds of sounds.
> They also use flat-wound strings that have no twang. Few sounds are
> prettier than a properly amplified, flat-wound G string played in the
> higher positions on a nice hollow-body f-hole style jazz box.

I actually think that lots of jazz guitarists sound really bad - there
seems to be some big cleverness thing about how you don't need to rely
on nice tone but can just be wonderful because of how well you can
play. Of course many of them *can* play very well... You don't seem
to get this with, say, sax players, who typically have bags of
wonderful tone. People like John Scofield (maybe he's not really
jazz, I dunno) are a delightful exception to my ears. I think partly
there's a complex there because the electric guitar is really seen as
a populist instrument so jazz people stay as far from the conventional
tone as possible because it wouldn't do for jazz to be popular, oh no.

That being said one of the tricks is that jazz players typically use
hollow or semi-solid bodied guitars, which tend to have more intrinsic
tone than a solid-bodied instrument, or in any case rely less on the
amplifier to make it interesting. I have two guitars - a Gibson 175
which is a classic f-hole hollow-boodied semi-acoustic, and a Heritage
<something> which is made by the people who used to work for Gibson
before they closed the Kalamazoo factory, and is really a Les Paul
(but, I think, nicer than anything Gibson make now). Anyway its very
interesting how the two instruments behave differently - the heritage
actually has bags of tone for a solid-bodied instrument but the 175 is
much more interesting-sounding with no distortion at all.

Hmm, this has nothing to do with Lisp, I'll stop.

--tim

PS if anyone is in Denmark, they should go and see the exhibition at
the music history museum, loads of really interesting electric guitars
(but no amps, which I think is a major omission in this context),
including what claims to be a '58 Les Paul, I hate to think how much
its worth. And of course *lots* of other fantastic musical
instruments. Danish museums are amazing, almost make living in a
hotel room worth it (not quite).

Frank A. Adrian

unread,
Nov 28, 2001, 9:44:53 AM11/28/01
to
Tim Bradshaw wrote:
> That being said one of the tricks is that jazz players typically use
> hollow or semi-solid bodied guitars, which tend to have more intrinsic
> tone than a solid-bodied instrument, or in any case rely less on the
> amplifier to make it interesting. I have two guitars - a Gibson 175
> which is a classic f-hole hollow-boodied semi-acoustic, and a Heritage
> <something> which is made by the people who used to work for Gibson
> before they closed the Kalamazoo factory, and is really a Les Paul
> (but, I think, nicer than anything Gibson make now). Anyway its very
> interesting how the two instruments behave differently - the heritage
> actually has bags of tone for a solid-bodied instrument but the 175 is
> much more interesting-sounding with no distortion at all.

I always liked the Gibson L-6 for some reason. The best thing about it was
that it seemed to have very little personality that you might have to try
to play around. Good clean sound, too.

Of course, for rock, nothing beats a Paul (but I still have a fondness for
the old SG line, too).

>
> Hmm, this has nothing to do with Lisp, I'll stop.

Ditto...

lars_lundback

unread,
Nov 29, 2001, 5:20:14 AM11/29/01
to

(Well, I now see that an amplifier can be an essential part of a
musical instrument.)

You know, I have always been fascinated by the many facets displayed
by some posters to c.l.l and the wide range of background and
interests they have. c.l.scheme and other c.l newsgroups seem dull in
comparison.

Guys, do you realize the potential if we subgroup c.l.l? We could
cover all kinds of interests: cl.l.musicalinstruments, c.l.l.SF,
c.l.l.HiFi, c.l.l.RexStout, c.l.l-beautifulcars - there's no end to
it.


Lars

(At some stage in life, some people start pondering on the obvious.
Like patterns. I guess I am beyond that.)


Tim Bradshaw

unread,
Nov 29, 2001, 11:26:21 AM11/29/01
to
Lars Lundback wrote in message news:<3c05f349...@vulkan.euv-frankfurt-o.de>...

>
> Guys, do you realize the potential if we subgroup c.l.l? We could
> cover all kinds of interests: cl.l.musicalinstruments, c.l.l.SF,
> c.l.l.HiFi, c.l.l.RexStout, c.l.l-beautifulcars - there's no end to
> it.

This is really a mistake I think. Part of the fun is that because
there's only a single group you keep coming across all sorts of
people, whereas if you subgroup (too far) you end up with lots of
little sterile groups who all think the same.

--tim

lars_lundback

unread,
Nov 29, 2001, 3:45:00 PM11/29/01
to
On 27 Nov 2001 12:34:01 -0800, aniso...@hotmail.com (Will Deakin)
wrote:

>
>For me, I find small pieces of beige cardboard attached to a comb is sufficient...

That and stomping on the floor makes great fun :=)

>;)w
>
>[1] is it a full concert? or a baby? whatever -- cool!

Eh, I actually have two boudoir grands. One is a Grotrian-Steinweg
about 6'2" long, in perfect condition. The other is a Steinway of the
same size which I have dissembled to do some restoration work. I
learned the basics in shellack polishing from a friend of mine who was
one of the best piano restorers around. Great fun but alas, it takes
years of practice to be able to polish _all_ parts to perfection ...

Lars

Will Deakin

unread,
Dec 3, 2001, 6:47:16 AM12/3/01
to
Lars wrote:

> That and stomping on the floor makes great fun :=)
:)w

> Eh, I actually have two boudoir grands.

You must have a big house :)

> I learned the basics in shellack polishing... Great fun but alas,

> it takes years of practice to be able to polish _all_
> parts to perfection ...

Good luck! My only exposure to shellac was a terms workwork project
as a callow youth. The smell of methalated spirits still bring a
shellac related frisson to this day.

:)w


0 new messages