Lisp and software architecture

92 views
Skip to first unread message

Peter Seibel

unread,
Mar 7, 2006, 11:32:35 PM3/7/06
to
Next month I'm goin to be giving a talk[1] about the effect of
programming language on software architecture. I'm thinking about what
the heck I'm going to say and how to turn it into an oppotunity to
brag on Lisp. So if you have any good war stories about how using Lisp
(or any other language for that matter) had an affect on the
architecture of the system you were working on, I'd love to hear
them.

-Peter

[1] April 26th at the Software Architecture and Modeling SIG of
SDForum in Palo Alto

--
Peter Seibel * pe...@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/

Sacha

unread,
Mar 8, 2006, 12:37:39 AM3/8/06
to

"Peter Seibel" <pe...@gigamonkeys.com> wrote in message
news:m2d5gxp...@gigamonkeys.com...

> Next month I'm goin to be giving a talk[1] about the effect of
> programming language on software architecture. <snip>

Shouldn't the language be considered as an implementation detail ?
It is my beleif that the architecture is on a different level.

Now this might not hold true for dynamic languages. Until now I only used
c++, c# and delphi for large projects, and these are all alike after all. So
I migh be completely wrong here.

On the other hand, it seems to me that my father was doing OO programming
using bare bone pointers back in the days.
That's a good example of a good concept crossing the language frontiers.

I'm a lisp newbie, freelance programmer working for telephone companies.
There is one thing i made and remade in about every language i worked with :
the telephony pricelist.
Though this looks like a simple task, the thing can be quite involved as my
customers need all the configuration options you could imagine and a lot
more too. It kind of became my benchmark implementation for language
testing.
They say lisp is different, so i'm building yet another pricelist using
lisp.
To say the truth, it looks like it'll eventually be quite the same thing as
my other implementations. Maybe am i too much of a newbie still, but hey
they say another thing : you need to build programs in order to learn =P

By the way I wanted to thank you for your book and even more so for
providing it on the web.
It is a great push toward learning lisp.

Sacha


Wade Humeniuk

unread,
Mar 8, 2006, 1:12:11 AM3/8/06
to
Peter Seibel wrote:
> Next month I'm goin to be giving a talk[1] about the effect of
> programming language on software architecture. I'm thinking about what
> the heck I'm going to say and how to turn it into an oppotunity to
> brag on Lisp. So if you have any good war stories about how using Lisp
> (or any other language for that matter) had an affect on the
> architecture of the system you were working on, I'd love to hear
> them.
>

Lists. Lists. Lists.

Lisp has them, now C++ has them, can't live without them.
A program is a list (tree). GUIs have drop-down lists.
Sorted, unsorted. Aircraft are put in queues (lists) for
takeoff. Forget fixed sized arrays, its lists lists
lists, any size, no limits. Variable argument lists make a
function extendable without breaking the callers.
Its the thought that rigidity could be expelled from
those Gothic architectures.

Wade

Christopher Browne

unread,
Mar 8, 2006, 1:03:06 AM3/8/06
to
Martha Stewart called it a Good Thing when "Sacha" <n...@address.spam> wrote:
> "Peter Seibel" <pe...@gigamonkeys.com> wrote in message
> news:m2d5gxp...@gigamonkeys.com...
>> Next month I'm goin to be giving a talk[1] about the effect of
>> programming language on software architecture. <snip>
>
> Shouldn't the language be considered as an implementation detail ?
> It is my beleif that the architecture is on a different level.

That's the big question.

The "Sapiran/Whorfian Hypothesis" essentially asserts that the
language that you use determines the shape of the thoughts that you
can form.

That would seem to imply that your language will determine what kind
of architectures you are capable of thinking about.

How true that hypothesis is represents an open question in
linguistics.

I think there can be considerable truth to this notion when it comes
to software architecture.

Someone with very primitive views of computer language will have very
different perspectives on what kinds of architecture are possible as
compared to someone with a "livelier view."

To someone who "thinks in COBOL," the world will have a pretty limited
shape.

Someone that speaks "pretty primitive C" probably sees a bit bigger
world.

Start throwing in extra abstractions, which often have language
implications, and there's more to perceive.

- Language parsing (ala Yacc) adds something
- Objects/data classification adds something
- Sequence manipulation "en masse," whether via reduce, mapcar,
or other languages' approaches (as with APL or SQL) adds something
- Associative arrays adds something

Common Lisp throws in some interesting constructs like places (e.g. -
things to which you can apply SETF), macros, closures.

I'm quite sure this has some impact on what kinds of architectures a
designer can imagine...
--
(format nil "~S@~S" "cbbrowne" "gmail.com")
http://linuxfinances.info/info/slony.html
Why isn't phonetic spelled the way it sounds?

nall...@gmail.com

unread,
Mar 8, 2006, 2:23:40 AM3/8/06
to
I think you should say:

the fact that Nick Allen has been able to coerce a computer into doing
anything more complex than turn off means that there is something
special about lisp that allows one to perform far beyond the normal
scope of their iq

jk

personally I think Emacs would be a great example of something that
probably couldn't have happened in any other language, though I'm not
sure if the topic's far removed enough to be appropriate.

SQL brings up a lot of issues (IE vs ODBMS or RDBMS written in a
non-declarative language)

I thought the Honda Car Crash System described by Kuroda Hisao in Three
Application Stories using Lisp at ILC05 was pretty awesome, but the
paper's probably unusable terse.

does html count as a language? it's screwed it's fair shair of
architectures up...

I guess you could always bring up the word of things successfully
programmed initially in lisp because the architecture was to big and
untried to be pulled off for the first time in any language...

good luck... er, break a leg... er, a neuron...

Nick

Pascal Costanza

unread,
Mar 8, 2006, 2:45:09 AM3/8/06
to
Peter Seibel wrote:
> Next month I'm goin to be giving a talk[1] about the effect of
> programming language on software architecture. I'm thinking about what
> the heck I'm going to say and how to turn it into an oppotunity to
> brag on Lisp. So if you have any good war stories about how using Lisp
> (or any other language for that matter) had an affect on the
> architecture of the system you were working on, I'd love to hear
> them.

Googling for "dynamic software architecture" might give you some ideas.
(The idea is that you can change the architecture at runtime. You could
mention examples where people update, for example, web applications
while they're running.)


Pascal

--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/

Rainer Joswig

unread,
Mar 8, 2006, 3:24:14 AM3/8/06
to
In article <m2d5gxp...@gigamonkeys.com>,
Peter Seibel <pe...@gigamonkeys.com> wrote:

> Next month I'm goin to be giving a talk[1] about the effect of
> programming language on software architecture. I'm thinking about what
> the heck I'm going to say and how to turn it into an oppotunity to
> brag on Lisp. So if you have any good war stories about how using Lisp
> (or any other language for that matter) had an affect on the
> architecture of the system you were working on, I'd love to hear
> them.
>
> -Peter
>
> [1] April 26th at the Software Architecture and Modeling SIG of
> SDForum in Palo Alto

I think there are lots of architecture- and Lisp-related topics:

- multiparadigm architectures (rules + objects + constraints + ...)
- very object-oriented architectures
- layered language architectures (objects on the bottom,
then functions, then macros)
- architectures which use exotic (non-mainstream) paradigms
- open architectures (-> Xerox, MIT Lispm)
- Meta-level architectures
- Architecture development (RAD, Prototypes, ...)
- Evolvable architectures
- 'Knowledge-based' systems and their architectures

and probably more...

For all of the above one should be able to find papers/examples.

--
http://lispm.dyndns.org/

Ken Tilton

unread,
Mar 8, 2006, 7:13:50 AM3/8/06
to
> Peter Seibel wrote:
>
>> Next month I'm goin to be giving a talk[1] about the effect of
>> programming language on software architecture. I'm thinking about what
>> the heck I'm going to say and how to turn it into an oppotunity to
>> brag on Lisp. So if you have any good war stories about how using Lisp
>> (or any other language for that matter) had an affect on the
>> architecture of the system you were working on, I'd love to hear
>> them.

Too bad you gave up on Cells at the first backtrace. Cells simply fell
out of an attack on an application problem, turned into a paradigm, took
over the whole application. Would never have happened without
first-class functions, closures, macros, CLOS, untyped variables...

kt

Wade Humeniuk

unread,
Mar 8, 2006, 8:21:47 AM3/8/06
to
Sacha wrote:

> I'm a lisp newbie, freelance programmer working for telephone companies.
> There is one thing i made and remade in about every language i worked with :
> the telephony pricelist.
> Though this looks like a simple task, the thing can be quite involved as my
> customers need all the configuration options you could imagine and a lot
> more too. It kind of became my benchmark implementation for language
> testing.
> They say lisp is different, so i'm building yet another pricelist using
> lisp.
> To say the truth, it looks like it'll eventually be quite the same thing as
> my other implementations. Maybe am i too much of a newbie still, but hey
> they say another thing : you need to build programs in order to learn =P
>

How about creating a Pricelist expert language instead? Then your
customers can specify/create/maintain their own "pricelists". Start
with one that has a Lisp syntax and then go from there.

Wade

Simon Brooke

unread,
Mar 8, 2006, 8:57:50 AM3/8/06
to
in message <m2d5gxp...@gigamonkeys.com>, Peter Seibel
('pe...@gigamonkeys.com') wrote:

> Next month I'm goin to be giving a talk[1] about the effect of
> programming language on software architecture. I'm thinking about what
> the heck I'm going to say and how to turn it into an oppotunity to
> brag on Lisp. So if you have any good war stories about how using Lisp
> (or any other language for that matter) had an affect on the
> architecture of the system you were working on, I'd love to hear
> them.

If you're using any Algol family language, up to and including
Java/C#/C++ etc, or FORTRAN and derivatives, then one of the issues is
data object size. Doing the equivalent of

(* pi (factorial 1000))

in most languages requires not only a lot of special libraries but also a
lot of special syntax. This leads you to think about your problem space
in two's complement 32 or 64 bit integers, and in 32 or 64 bit IEEE 754
encoded reals. That in turn leads you to accept rounding errors as
inevitable, even if they're not. You don't expect the equivalent of

(+ 22/7 1/7)

to return exactly 23/7. You expect rounding error. You say 'it's
inevitable'; you say 'it doesn't matter'.

If you use any statically typed language - Algol family, Fortran family,
any of them - you have to make early commitments to the type of an
object that you don't yet know much about. In Java (and its derivatives)
or C++, for example, you can't at all easily move an object about in the
class hierarchy; the class it was born in, it dies in. There's no social
mobility for objects.

All these things (and many others) limit the way you think about a
problem space. They limit what you can build because they limit what you
can think of.

If this post has been any use to you you might want to look at my
currently developing essay 'Post Scarcity Software', which is here
<URL:http://www.jasmine.org.uk:80/dogfood/story/article_42.html>

--
si...@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
"The result is a language that... not even its mother could
love. Like the camel, Common Lisp is a horse designed by
committee. Camels do have their uses."
;; Scott Fahlman, 7 March 1995


Ken Tilton

unread,
Mar 8, 2006, 9:15:37 AM3/8/06
to
Sacha wrote:
> "Peter Seibel" <pe...@gigamonkeys.com> wrote in message
> news:m2d5gxp...@gigamonkeys.com...
>
>>Next month I'm goin to be giving a talk[1] about the effect of
>>programming language on software architecture. <snip>
>
>
> Shouldn't the language be considered as an implementation detail ?
> It is my beleif that the architecture is on a different level.
>
> Now this might not hold true for dynamic languages. Until now I only used
> c++, c# and delphi for large projects, and these are all alike after all. So
> I migh be completely wrong here.
>
> On the other hand, it seems to me that my father was doing OO programming
> using bare bone pointers back in the days.
> That's a good example of a good concept crossing the language frontiers.
>
> I'm a lisp newbie, freelance programmer working for telephone companies.
> There is one thing i made and remade in about every language i worked with :
> the telephony pricelist.
> Though this looks like a simple task, the thing can be quite involved as my
> customers need all the configuration options you could imagine and a lot
> more too. It kind of became my benchmark implementation for language
> testing.
> They say lisp is different, so i'm building yet another pricelist using
> lisp.
> To say the truth, it looks like it'll eventually be quite the same thing as
> my other implementations.

Not after you post it to c.l.l. :)

> Maybe am i too much of a newbie still,...

No, that is not the problem. Many newbies (but not you, it seems) go too
far in straining to do things The Lisp Way. This is good, this is how
one learns something new, breaks the mold: throw oneself into it with
gusto, try to be functional, try to leverage CLOS and macros, yada yada.

> but hey
> they say another thing : you need to build programs in order to learn =P

Building programs will not help you; Lisp is a multi-paradigm language,
so you can write code as if it were C. Which it seems you are. Having
solved the problem several times already, you are just writing the same
code in Lisp. What do you think it is going to look like?

Most newbies in your situation are sharp enough to say, "Hey, my Lisp
code looks just like my C code, what am I doing wrong?" Your grand
conclusion is that Lisp is no different than C. Hmmmmm....

ken

bill...@gmail.com

unread,
Mar 8, 2006, 10:47:05 AM3/8/06
to
> Next month I'm goin to be giving a talk[1] about the effect of
> programming language on software architecture. <snip>

> [1] April 26th at the Software Architecture and Modeling SIG of
> SDForum in Palo Alto

You might want to consider using a Design Patterns based approach to
showing how the choice of a programming language can affect how you
look at a problem from an architectural and modeling standpoint. This
is something that the SIG will relate to easily. Peter Norvig did this
very effectively in his "Design Patterns in Dynamic Programming"
presentation (http://norvig.com/design-patterns/). Obviously, you won't
want to cover the same ground as Peter did; however, you can mold some
of those ideas into your talk. Richard Gabriel also has a lot of good
material for this type of approach in his _Patterns of Software_ book
(http://www.dreamsongs.com/NewFiles/PatternsOfSoftware.pdf). In fact,
you might want to look at some of his OOPSLA presentations as well.

This approach could also lead into a discussion about how the selection
of a programming language with a high level of abstraction capabilities
changes the requirements for the types of modeling tools that you might
need/want to use. For example, many Java programmers use UML modeling
tools but very few Lisp programmers do.

Another good souce of material for the presentation might be some DSL
examples (e.g. - Rainer Joswig's movie -
http://bc.tech.coop/blog/050711.html). This would reinforce the idea of
how the choice of programming language affects the types of patterns
that the programmer "sees" or uses. Also using DSL's, you might want to
weave in some psychological material about how the choice of a
programming language can subconsciously influence your architectural
design choices (e.g. - things that are "really hard" to do in one
programming language but easy to do in another programming language
result in different architectural approaches being taken in the design
of the solution).

--
Bill Clementson

Peter Seibel

unread,
Mar 8, 2006, 11:22:32 AM3/8/06
to
Ken Tilton <kent...@gmail.com> writes:

Hey, that's not fair. I didn't give up because I couldn't get it to
run--I gave up long before that, when I couldn't find anything that
explained what it was and why I should care. ;-)

-Peter

Sacha

unread,
Mar 8, 2006, 12:18:56 PM3/8/06
to

"Wade Humeniuk" <whumeniu+...@telus.net> wrote in message
news:LTAPf.22801$Ui.8488@edtnps84...

Would you mean something like : lay the data, throw lots of parenthesis
around it, back it up with some code to make it work, then refactor until i
get a usefull, higher level language ?

Or maybe lay the finaly language down then wrap the code around it ?

There was this very nice and quite enlightening DSL video :
http://bc.tech.coop/blog/050711.html

That sure sounds neat, i'll give it a try.

Sacha


Sacha

unread,
Mar 8, 2006, 12:35:05 PM3/8/06
to
>>
<snip>

>>, so i'm building yet another pricelist using lisp.
>> To say the truth, it looks like it'll eventually be quite the same thing
>> as my other implementations.
>
> Most newbies in your situation are sharp enough to say, "Hey, my Lisp code
> looks just like my C code, what am I doing wrong?" Your grand conclusion
> is that Lisp is no different than C. Hmmmmm....
>

I knew this post would be controversial..

> "Hey, my Lisp code looks just like my C code, what am I doing wrong?"

My post was sort of admiting a failure. Maybe should i tackle something
different, get out of the track, then go back to the price list problem when
i'll be able to make it more idiomatic.

Wade Humeniuk suggested going the DSL path , so i'll give it a try first.

Sacha

Ken Tilton

unread,
Mar 8, 2006, 12:36:03 PM3/8/06
to
Peter Seibel wrote:
> Ken Tilton <kent...@gmail.com> writes:
>
>
>>>Peter Seibel wrote:
>>>
>>>
>>>>Next month I'm goin to be giving a talk[1] about the effect of
>>>>programming language on software architecture. I'm thinking about what
>>>>the heck I'm going to say and how to turn it into an oppotunity to
>>>>brag on Lisp. So if you have any good war stories about how using Lisp
>>>>(or any other language for that matter) had an affect on the
>>>>architecture of the system you were working on, I'd love to hear
>>>>them.
>>
>>Too bad you gave up on Cells at the first backtrace. Cells simply fell
>>out of an attack on an application problem, turned into a paradigm,
>>took over the whole application. Would never have happened without
>>first-class functions, closures, macros, CLOS, untyped variables...
>
>
> Hey, that's not fair. I didn't give up because I couldn't get it to
> run--I gave up long before that, when I couldn't find anything that
> explained what it was and why I should care. ;-)

Oh, lord, that is easy. Go to the ActiveState site, they named the whole
frickin company after Cells functionality. Then look at what the Tk
crowd calls "actions"-- that is Tk with its little bit of hardcoded
"active state" trying to let the user hardcode some of what Cells does
automatically. You might also check the Adobe site, look for a white
paper on, I forget, Eve? Same thing, and they apparently are
standardizing on that for future software development.

I also find this tool to be a helpful, you might want to give it a try
for things like this:

http://www.google.com/

Try:

http://www.tilton-technology.com/cells-overview.pdf

Look for:

"1.2 The big picture

Cells support a declarative paradigm in which the motivating force
behind an application’s overall behavior is dataflow through a
dependency graph maintained automatically by the system. The benefits
are several.

• Eliminates the class of bug in which program state is internally
inconsistent.

• A corollary benefit: eliminates the housekeeping burden of keeping
consistent the state dependency graph implicit in any application.

• Makes manifest the state dependency graph implicit in any application.
Actual runtime dependencies can be graphed.

• Program semantics are fully encapsulated by the declarative model; the
rule for a cell defines it completely.

• Cells let us tailor instances with rules, not just literals, making
objects more reusable. For example, some GUI schemes allow widgets to
specify their dimensions with options such as :sticky-left or :fixed or
:elastic-right. With cells you can write any algorithm you like to
decide a widget’s geometry. Furthermore, by arranging instances in a
navigable namespace, those algorithms can draw on arbitrary application
state.

• Divides and conquers application complexity. No cell in even the most
complex spreadsheet touches more than a handful of cells, usually just
one or two. The complex solution emerges from multiple small but
high-quality solutions to small problems. Our experience has been the
same with Cells in application development."

Of course, if you have not done much application programming that will
not make any sense to you. Try reading Fred Brooks's "No Silver Bullet",
in which he explains why software can never be easier to develop than it
was in 1986. In part:

"Digital computers are themselves more complex than most things people
build, they have very large numbers of states....Software systems have
orders of magnitude more states than computers do....In most cases, the
elements interact with each other in some nonlinear fashion, and the
complexity of the whole increases much more than linearly."

You never looked at Cells, so i will tell you: Cells manage state.

Again, if you are just a code monkey and are never given responsibility
for anything more than a subroutine here and there, I understand why
that still makes no sense to you. Brooks continued:

"Many of the classical problems of developing software products derive
from this essential complexity."

This is why anyone can write a ten line program, why you have to learn
how to program to pull off a hundred line program, why most thousand
line programs are horrid, and why most 100kloc projects fail.

Cells fixes that.

Well, even with your father pitching it, it took you twenty years to
become a Lispnik:

http://wiki.alu.org/Peter_Seibel's_Road_to_Lisp

Should we look for a Road to Cells Switch Date of 2028?

:)

ken

ps. Thanks for the fat pitch. :)

Ken Tilton

unread,
Mar 8, 2006, 12:40:03 PM3/8/06
to
Sacha wrote:
> <snip>
>
>>>, so i'm building yet another pricelist using lisp.
>>>To say the truth, it looks like it'll eventually be quite the same thing
>>>as my other implementations.
>>
>>Most newbies in your situation are sharp enough to say, "Hey, my Lisp code
>>looks just like my C code, what am I doing wrong?" Your grand conclusion
>>is that Lisp is no different than C. Hmmmmm....
>>
>
>
> I knew this post would be controversial..
>
>
>>"Hey, my Lisp code looks just like my C code, what am I doing wrong?"
>
>
> My post was sort of admiting a failure.

Oh, I saw the "sort of". Too sorty for my taste. :)

> Maybe should i tackle something
> different, get out of the track, then go back to the price list problem when
> i'll be able to make it more idiomatic.
>
> Wade Humeniuk suggested going the DSL path , so i'll give it a try first.

Nah, nobody really writes DSLs. We do what Graham says: build up to the
problem domain with a macro here and a macro there, all swimming around
in straight CL.

You should have listened to my suggestion, if you noticed it. :)

ken

William Bland

unread,
Mar 8, 2006, 12:44:08 PM3/8/06
to
On Wed, 08 Mar 2006 07:47:05 -0800, billclem wrote:

>> Next month I'm goin to be giving a talk[1] about the effect of
>> programming language on software architecture. <snip>
>> [1] April 26th at the Software Architecture and Modeling SIG of
>> SDForum in Palo Alto

Excellent - I hope to be able to attend.

> You might want to consider using a Design Patterns based approach to
> showing how the choice of a programming language can affect how you
> look at a problem from an architectural and modeling standpoint.

Agreed. I have often surprised people at work by showing them how some of
the patterns that are needed in Java are actually "built in" to Lisp (or
at least much less hassle to implement there). This does seem to to get
people interested.

> ... the choice of a programming language can subconsciously influence


> your architectural design choices (e.g. - things that are "really hard"
> to do in one programming language but easy to do in another programming
> language result in different architectural approaches being taken in the
> design of the solution).

Absolutely agreed. The biggest difference between me doing Java
architecture and Lisp architecture is that when I'm doing Java, I
constantly discard potential architectures as being too much work to
implement and maintain. When I'm doing Lisp I don't find myself doing
that so much, and I can focus on the more important differences between
potential architectures.

Best wishes,
Bill.

Sacha

unread,
Mar 8, 2006, 12:50:43 PM3/8/06
to

> Nah, nobody really writes DSLs. We do what Graham says: build up to the
> problem domain with a macro here and a macro there, all swimming around in
> straight CL.

That was my first idea, and that's how i get something very close to a c++
solution.

> You should have listened to my suggestion, if you noticed it. :)
>

I'm not goind to post my code (too ugly i guess) and ask you guys to do my
home work.
What would be the educational value ?

Anyways, thanks for your time, there's no secret, i need to go back to the
drawing board and work out my RSIs.

Sacha


Tolstoy

unread,
Mar 8, 2006, 2:31:09 PM3/8/06
to
I took a class in Software Architecture (at a major corporation) and
the upshot was that SA had little to do with programming languages, or
even the design of software beyond the "we need a database component, a
web component" and so on. Choice of programming language is an
implementation detail.

The class seemed to argue that being a Software Architect was about
politics, persuasion, defining the problem, lining up sponsorship,
providing business justification and analysis, and so on. And, of
course, how to choose implementation technologies that line up well
with all these aspects. (I was shocked. Maybe the term has changed,
at least in corporations above a certain size?)

So, seems like the first thing you should do is define Software
Architecture. Are you talking about how to arrange your code to solve
the problem? Or are you talking about how to solve problems, one part
of which is the actual software? Neither? Both?

My own experience is that projects are very much in flux, design
changes with each phone conference, and time is short, you need to show
something NOW and you need to design that prototype so that it is
reasonably robust, and, above all, easy to change when someone on a
phone call says, "But that's not what I meant at all." My goal is to
create "executable specifications" and lisp kicks ass at that.

Could you figure out how technical choices can affect all the
non-technical aspects of a software project? For instance, getting a
prototype out the door in a few days to show sponsors is much better
than a set of beautifully rendered design documents, or, horrors, some
sort of UML representation.

--Keith

Ken Tilton

unread,
Mar 8, 2006, 2:46:45 PM3/8/06
to
Sacha wrote:
>>Nah, nobody really writes DSLs. We do what Graham says: build up to the
>>problem domain with a macro here and a macro there, all swimming around in
>>straight CL.
>
>
> That was my first idea, and that's how i get something very close to a c++
> solution.
>
>
>>You should have listened to my suggestion, if you noticed it. :)
>>
>
>
> I'm not goind to post my code (too ugly i guess)

OK, so now you are not "sort of" taking the blame for writing C in Lisp,
you are taking all the credit. I see growth!

> and ask you guys to do my
> home work.
> What would be the educational value ?

Learning? From experts? We won't do the hard work, just the fun redesign
ideas.

You failed once to break with the past on your own, why not get some
help? There are an awful lot of "thanks, everybody!" posts piling up in
the c.l.l archive.

>
> Anyways, thanks for your time, there's no secret, i need to go back to the
> drawing board and work out my RSIs.

Oh, well. Best of luck. I doubt you will succeed. I mentored an
incredibly good programmer during the Google Summer of Code, but he put
the configuration code in an external BLAH.def text file (with non-Lispy
syntax) which he then opened, read, and parsed in Lisp so his WOMP
engine could handle his BLAH project.

I asked him why he did not just write a defwomp macro? His response was
basically, Doh!

He probably would have gotten there a year later once The Lisp Way sunk in.

Did a whack from the Lisp stick diminish the quality of his
enlightenment? Nah, the suddenness of the realization makes the lesson
stick as well as having the same epiphany after months of living with
external config files.

ken

Matthew D Swank

unread,
Mar 8, 2006, 2:47:26 PM3/8/06
to
On Wed, 08 Mar 2006 12:36:03 -0500, Ken Tilton wrote:

> ps. Thanks for the fat pitch. :)

When is "Cells III, Cells in 3D" due to be committed?

Matt

--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.

Paolo Amoroso

unread,
Mar 8, 2006, 2:38:19 PM3/8/06
to
William Bland <doctorb...@gmail.com> writes:

> Agreed. I have often surprised people at work by showing them how some of
> the patterns that are needed in Java are actually "built in" to Lisp (or
> at least much less hassle to implement there). This does seem to to get
> people interested.

I read the GoF patterns book a while back, but I seem to remember that
they explicitly state something like this, and mention Lisp and
Smalltalk as examples of languages requiring less or no patterns.


Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net

Ken

unread,
Mar 8, 2006, 3:09:11 PM3/8/06
to

Matthew D Swank wrote:
> On Wed, 08 Mar 2006 12:36:03 -0500, Ken Tilton wrote:
>
>
>>ps. Thanks for the fat pitch. :)
>
>
> When is "Cells III, Cells in 3D" due to be committed?

Cells3 was done (enough to let me drive Tk froms Cells), but then I
decided it should go a little further, and am meditating on "further".
Unless someone reports a problem Cells3 would solve I will just let it
gestate. I do not want to have to jump to Cells4 in three weeks and put
tfb and Cells-Gtk thru another round of testing.

Cells in 3D is unknown to me, but could be Cello. I love OpenGL, but I
have a portable retail app to get out and Tk solves a /lot/ of
nitty-gritty stuff Cello has not even dreamed of, natively to boot, so I
am hoping I can get by with Celtk (+ Cells Tk).

ken

Patrick May

unread,
Mar 8, 2006, 4:10:01 PM3/8/06
to
"Tolstoy" <keith...@gmail.com> writes:
> So, seems like the first thing you should do is define Software
> Architecture. Are you talking about how to arrange your code to
> solve the problem? Or are you talking about how to solve problems,
> one part of which is the actual software? Neither? Both?

In addition to the points you've raised, one of the most
important distinctions between architecture and design is that a
software architecture must address non-functional requirements
(performance, resiliency, scalability, extensibility, and all the rest
of the "ilities").

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
p...@spe.com | (C++, Java, Jini, CORBA, UML)

Pascal Bourguignon

unread,
Mar 9, 2006, 1:05:56 AM3/9/06
to
Paolo Amoroso <amo...@mclink.it> writes:
> I read the GoF patterns book a while back, but I seem to remember that
> they explicitly state something like this, and mention Lisp and
> Smalltalk as examples of languages requiring less or no patterns.

It's not that Lisp requires less patterns, it's that every macro you
write in lisp IS a pattern!

(Well, but perhaps the simpliest purely syntactic sugar ones).


Also, UML case tools, particularly those that implement rules for
automatic model transformations and which generate automatically the
resulting C++ sources, are not needed either when you write lisp, once
again because you have macros to implement these model transformation
rules, and to generate the final Lisp code.

--
__Pascal Bourguignon__ http://www.informatimago.com/

COMPONENT EQUIVALENCY NOTICE: The subatomic particles (electrons,
protons, etc.) comprising this product are exactly the same in every
measurable respect as those used in the products of other
manufacturers, and no claim to the contrary may legitimately be
expressed or implied.

Holger Schauer

unread,
Mar 10, 2006, 8:28:49 AM3/10/06
to
On 4572 September 1993, Pascal Bourguignon wrote:
> Paolo Amoroso <amo...@mclink.it> writes:
>> I read the GoF patterns book a while back, but I seem to remember that
>> they explicitly state something like this, and mention Lisp and
>> Smalltalk as examples of languages requiring less or no patterns.

I'm reading it right now, and it's "less". They even say quite
concretely which patterns they included in the book which are somewhat
build-in in Lisp/Smalltalk.

> It's not that Lisp requires less patterns, it's that every macro you
> write in lisp IS a pattern!

I don't think that the pattern you have in mind is the kind of
patterns the GoF book talks about. Many aspects of what I've read so
far deal more with how to structure your data and functionality so
that the resulting code becomes quite flexible and maintainable
("encapsulate the concept that varies" seems to be the mantra of the
book). I take that to be quite independent of the language you
actually use.

Holger

--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"Ihre Kontinentalfestplatte ist fragmentiert. Möchten Sie
den Assistenten zur Driftbeschleunigung starten?"
-- Andreas Meier in de.alt.sysadmin.recovery

Tayssir John Gabbour

unread,
Mar 10, 2006, 9:44:27 AM3/10/06
to
Ken Tilton wrote:
> Cells support a declarative paradigm in which the motivating force
> behind an application's overall behavior is dataflow through a
> dependency graph maintained automatically by the system. The benefits
> are several.

Ironically enough, only this morning I looked at Cells. I suspect it
may be genuinely useful.

Seems the main use is to define constraints between things, and then
simply forget about them, knowing that the constraints will be
maintained without additional thought on your part.

A good exposition is in Jim Veitch's paper [1] where he described a
similar system for Boeing, for modelling planes.

* Showed eager updating of parts of a plane when some other part
affecting it changes.
* Then converted it to lazy updating, so recalculations only happen
when a) you look at the part and b) some other part which affects it
was updated.


[1] "A History and Description of CLOS". Took only few lines of code to
illustrate the concept, though the guy actually uses DO* (ugh). Hmm,
little surprise that the Cadence/Ltk guys seem to be poking around
Cells, I guess, as they work on CAD systems too.


> · Eliminates the class of bug in which program state is internally


> inconsistent.
>
> · A corollary benefit: eliminates the housekeeping burden of keeping
> consistent the state dependency graph implicit in any application.

Maybe a problem is that sounds too technojargony.


Tayssir

Ken Tilton

unread,
Mar 10, 2006, 11:05:39 AM3/10/06
to
Tayssir John Gabbour wrote:
> Ken Tilton wrote:
>
>>Cells support a declarative paradigm in which the motivating force
>>behind an application's overall behavior is dataflow through a
>>dependency graph maintained automatically by the system. The benefits
>>are several.
>
>
> Ironically enough, only this morning I looked at Cells. I suspect it
> may be genuinely useful.
>
> Seems the main use is to define constraints between things, and then
> simply forget about them, knowing that the constraints will be
> maintained without additional thought on your part.

Right. But the actual constraint languages included, inter alia, partial
and multi-way constraints. I have not needed those so I have not played
with those, tho Cells4 will likely support the non-deterministic thing
that results.

The problem is that the constraint languages proved nearly impossible to
program. I am looking for a productivity aid in conventional
programming, not to search large solution spaces ala the typical good
constraint application.

>
> A good exposition is in Jim Veitch's paper [1] where he described a
> similar system for Boeing, for modelling planes.

The prior (and concurrent) art of Cells is vast.

>
> * Showed eager updating of parts of a plane when some other part
> affecting it changes.
> * Then converted it to lazy updating, so recalculations only happen
> when a) you look at the part and b) some other part which affects it
> was updated.
>
>
> [1] "A History and Description of CLOS". Took only few lines of code to
> illustrate the concept, though the guy actually uses DO* (ugh). Hmm,
> little surprise that the Cadence/Ltk guys seem to be poking around
> Cells, I guess, as they work on CAD systems too.
>
>
>
>>· Eliminates the class of bug in which program state is internally
>>inconsistent.
>>
>>· A corollary benefit: eliminates the housekeeping burden of keeping
>>consistent the state dependency graph implicit in any application.
>
>
> Maybe a problem is that sounds too technojargony.

How about "best thing since sliced bread!"? People get upset if one
sounds like a carnival barker.

Me and the COSI guyhave tried the spreadsheet metaphor, but listeners
invariably respond "Oh, I use Excel, I do not need a spreadsheet."

So it is a lot like Lisp. A few of us know about Lisp/Cells, and use it
to program/managestate, and would not do it any other way given our
druthers, but the rest just slog on ignorantly with
Java/manualstatemanagement until the mindshare reaches a critical mass
and it becomes OK to explore.


kt

Pisin Bootvong

unread,
Mar 10, 2006, 12:58:54 PM3/10/06
to
Let me talk about how Ruby's (and Smalltalk's) open class enable better
object oriented design than that of Java/C++.

One concept of OO is to "tell object to do something" instead of to
"tell it how to do something".

So instead of saying.

cat.position.x = rat.position.x;
cat.position.y = rat.position.y;

You can do

cat.catch(rat);

But the problem with OO object like C++, Java and C# is that:

"You cannot teach existing object new trick."

In those close-object languages, If you don't have access to the
class's source code, you cannot add method to that class.
So if you want a person to be able to run you probably need to add
helper class.

class PersonTrick {
static void run(Person p){
// Code to manipulate person to make him run via his public
method.
}
}

And the method call becomes awkward as

PersonTrick.run(person);

(Or you can teach this trick in subclass of Person, but that will only
work if you control creation of the object).


But with Ruby/Smalltalk you can add the trcik directly to the class as.

class Person
def run
# code to make I run
end
end

And you call it as

person.run

So you can see how code looks nicer and the method is where it really
belongs.

Since Common Lisp 's generic function is not tied to a single class,
CLOS always support Open class design; you can always add generic
function specialized on third party's class (The only quirk is that
most standard function in CL is not generic function so you can not
specialize those function with your own class).

Message has been deleted

Ken Tilton

unread,
Mar 10, 2006, 5:30:39 PM3/10/06
to
goat_ro...@yahoo.com wrote:
> X-No-Archive:yes

> Ken Tilton wrote:
>
>>Peter Seibel wrote:
>>
>>>Ken Tilton <kent...@gmail.com> writes:
>>>
>>>>Too bad you gave up on Cells at the first backtrace. Cells simply fell
>>>>out of an attack on an application problem, turned into a paradigm,
>>>>took over the whole application. Would never have happened without
>>>>first-class functions, closures, macros, CLOS, untyped variables...
>>>
>>>Hey, that's not fair. I didn't give up because I couldn't get it to
>>>run--I gave up long before that, when I couldn't find anything that
>>>explained what it was and why I should care. ;-)
>
>
> I agree with Mr. Siebel. I visited your site and links over a period of
> 3 years. Semaphor/Cells was poorly documented;
> there seemed little
> reason to examine it further.

Hang on, I listed several reasons in that doc and quoted them in this
thread. You have not responded to those points, but simply say "bad
doc!". I admit the latter freely, what do you have to say to my points
about Cells being the long-sought Silver Bullet?

If someone brings you cold fusion in a mason jar, are you going to say
"No Pyrex beaker?"?

You and Mr. Seibel stand in curious contrast to Vasilis Margioulas (sp?)
who downloaded Cells, downloaded Celtic (pretty much same as Celtk), saw
how it all worked, decided to see if it would make development easier,
built Cells-Gtk and sent it to me in the middle of the night my time
without asking me one question or even letting me know he existed.

He decided, "Yes", btw.

What does Vasilis have that you lack? I better duck that pitch. :)

No seriously, youse guys are looking for a shrink-wrapped library, and I
freely acknowledge Cells (ne Semaphors until the Savages of c.l.l set
upon me) requires an enthusiastic explorer.

I am exactly the same way. If I /need/ X, I will bang on it and support
groups and even read documentation (sorry, Edi) until it works. If I do
not need it, it better come with an installer. :)

I need all the Silver Bullets I get, apparently you do not.

>
>
>>Oh, lord, that is easy. Go to the ActiveState site, they named the whole
>>frickin company after Cells functionality.
>
>

> http://www.google.com/search?hl=en&lr=&q=cells+SITE%3AActiveState.com&btnG=Search
> comes up empty, an extraordinary thing on Google!-) Please tell us
> what "Cells functionality" has to do with the ActiveState site.

I did. Here let me help. I will take your own reply and delete the span
of sentences across which your attention could not, well, span:

>>>Oh, lord, that is easy. Go to the ActiveState site, they named the whole
>>>frickin company after Cells functionality.

....snip...


>>>You never looked at Cells, so i will tell you: Cells manage state.

Of course if you have chimed in just to abuse me, you probably still do
not get it. Or maybe you do not know where is the "active state" in Tk?
Uhh, you get to tell a widget a "variable" to track. Then when you
change the variable (in any which way), the widget reacts sensibly to
the change. The alternative is for the programmer to carry that burden:
"Oh, gee, I just changed X. I happen to recall that widget Y reflects in
some way the value of X. I must tell widget Y to update itself. Oh, and
then there is this menu item M that is available only when Y...".

If you are yawning, you /are/ just here to abuse me. :)

>
>
>>I also find this tool to be a helpful, you might want to give it a try
>>for things like this:
>> http://www.google.com/
>
>

> cf., above.
>
>
>>Try:
>> http://www.tilton-technology.com/cells-overview.pdf
>
>
> This document is great...

Oh great, now I am hearing things. :)

>... but was apparently posted on July 2, 2003:
> http://web.archive.org/web/*/http://www.tilton-technology.com/cells-overview.pdf
> But you were already posting about Semaphor/Cells (in one form or
> another) prior to October, 2000, e.g.,

So the complaint is tardiness? That is why you have not tried a Silver
Bullet? Reminds me of why I lost interest in open source.

> http://groups.google.com/group/comp.lang.lisp/msg/0a1564e6719bbbce?dmode=source&hl=en
> There you called it "Semaphors". Later the name changed to "Cells":
> http://groups.google.com/group/comp.lang.lisp/msg/97297a72116fede6?dmode=source&hl=en
>
> So decent Cells documentation was slow to appear. Today your site links
> to a "Cells tutorial" at Bill Clementson's blog but the link is broken.
> It should probably be http://bc.tech.coop/blog/030911.html

OK, you found it and make absolutely no comment on the actual
functionality of Cells, merely rant on about tardiness. Which is my
point above, you are not /really/ interested in Cells. That is why the
doc seems so bad. You are blaming me for your own approach to the project.

>
>
>>You never looked at Cells, so i will tell you: Cells manage state.
>
>

> Hey, people looked! "Semaphor"/"Cells" documentation was poor to
> nonexistent. (BTW did you _pay_ someone else to write that PDF, above?
> The "author:" tag is blank!8-))


>
>
>>Well, even with your father pitching it, it took you twenty years to
>>become a Lispnik:
>> http://wiki.alu.org/Peter_Seibel's_Road_to_Lisp
>>Should we look for a Road to Cells Switch Date of 2028?
>>:)
>
>

> Unfair (along with "code monkey" comment).

You are unaware that Mr. Seibel jokingly refers to himself as Javamonkey.

btw, I am serious, not putting anyone down. If one does not have to
develop applications with a significant amount of long-lived,
interdependent state, usually something that arises when one must
process an unpredictable stream of related data and maintain therefrom a
coherent model of everything that has transpired (a common example being
a GUI application in which the user types this then clicks here and
wants a complex drawing or document to result), then one likely cannot
understand the advantage of managed state.

You know, the first person Bricklin and ??? showed VisiCalc to said "So
what?". That was another programmer, I think. The second was someone who
did finance and so did spreadsheets on paper. He wanted to buy their
company. Something like that.

> Mr. Siebel surely deserves
> at least another 2 years (the time to post decent Cells documentation).


>
>
>>ps. Thanks for the fat pitch. :)
>
>

> Looked like a strike (swing and a miss) from here.

The flamewar is of little interest compared with the possibility that
there might be a better way to program complex applications. Nothing you
have written shows that you have actually tried Cells in a toy
application to see if I am right, so I am afraid my friend that you are
not even in the ballpark. Which might explain your umpiring.

You know what is funny? You do not even realize that you are not arguing
with me, you are arguing with the history of programming. The prior art
goes back to 1963 and a draw program called Sketchpad that included what
might be the first implementation of constraints. It continues to today
(literally, at 1:43PM EST), when a friend wrote to ask about the broken
Clementson link, telling me a co-worker had just re-invented Cells. In
between we have the KR system in Garnet, and the non-open COSI project
presented at LUGM '99. I hesitate to mention the entire constraints
research programme (kicked off in the 80s by our own Guy Steele's
computer language cum PhD thesis "A Constraint Programming Language")
which continues to today, because they IMO went a bridge too far with
multiway and partial constraints and ended up with unprogrammable
systems. But the spirit is the same: the automatic management of complex
interdependent states given only declarative rules the system must
enforce. Translating for Tayssir, "It is the cat's meow." :)

Thanks for the intentional pass[1], but next time try to say something
/substantive/ about Cells or the more general concept of constraints,
don't just whine about tardy doc. Intentional passes are boring to watch.

:)

ken

ps. In Steele's early 80s paper he marvels that something as wonderful
as constraints did not catch on after Sketchpad/63. Twenty years they
still have not caught on. The only difference is that, after exchanges
like this, I am not at all surprised. :)

[1] In baseball, a fat pitch is a fastball out over the plate, very easy
to hit out of the park. Pitchers in winning situations have been known
to do this to baseball legends in their last at bat before retirement.
An intentional pass is everyone standing around while the pitcher throws
four balls deliberately out of the strike zone (allowing the batter to
take first base uncontested) because he does not want to give the batter
a chance to hit the ball. k

bradb

unread,
Mar 10, 2006, 11:24:20 PM3/10/06
to
Your energetic post got me interested in Cells, so I downloaded the tgz
from http://common-lisp.net/project/cells/ & tried to follow the cells
basic tutorial & Bill's tutorial.
I have a problem though, no where in the cells source directory can I
find a definition for the DEF-C-ECHO macro.
Am I missing something blindingly obvious? Or is Cells ment to be
installed someother way? ASDF-INSTALL failed (crashed) on a recentish
SBCL. Should I try to install from CVS?

Kenny, your post inspired me to look past the lack of documentation
(examples and docs within the package acutally do look pretty good),
but so far I've had no luck getting any traction well using cells.

Cheers
Brad

Ken Tilton

unread,
Mar 11, 2006, 12:17:45 AM3/11/06
to
bradb wrote:
> Your energetic post got me interested in Cells, so I downloaded the tgz
> from http://common-lisp.net/project/cells/ & tried to follow the cells
> basic tutorial & Bill's tutorial.
> I have a problem though, no where in the cells source directory can I
> find a definition for the DEF-C-ECHO macro.
> Am I missing something blindingly obvious?

No, I did a second version of Cells and changed def-c-echo to
def-c-output. That name is not working out either, look for it to become:

def-slot-change-handler

... or something similarly uninterpretive. But for now you will likely
find it at the end of propagate.lisp. The arguments and functionality
are unchanged, so you can just do a global replace on any examples you find.

> Or is Cells ment to be
> installed someother way? ASDF-INSTALL failed (crashed) on a recentish
> SBCL. Should I try to install from CVS?
>
> Kenny, your post inspired me to look past the lack of documentation
> (examples and docs within the package acutally do look pretty good),

yeah, I got pretty chatty in commenting some of the test code, and I
usually recommend that to people who bother to ask.

> but so far I've had no luck getting any traction well using cells.

If you have any GUI stuff to do I could send you Cells3 when it
stabilizes. It will include Celtk as a demo app. Still no doc, just a
test function that exercises every Tk widget and makes the state even
more active <g> using Cells.

ken

bill...@gmail.com

unread,
Mar 11, 2006, 12:35:23 AM3/11/06
to
> Am I missing something blindingly obvious? Or is Cells ment to be
> installed someother way? ASDF-INSTALL failed (crashed) on a recentish
> SBCL. Should I try to install from CVS?

I'm always surprised when I hear of people having trouble installing
cells. Every time I've tried it, it's worked first time. I just tried
it again with both OpenMCL and SBCL and it worked fine on both of those
implementations. Basically, all I did was:

1. (asdf-install:install :cells) ; take the '0' debugger option if you
need to bypass gpg key checking
2. create a symlink to the cells directory (for some reason
asdf-install didn't do this) or cd to the cells directory
3. (asdf:oos 'asdf:load-op :cells)
4. (asdf:oos 'asdf:load-op :cells-test)

This last statement loads & runs all the test programs in the cells
test directory, so you'll get a lot sample output as well. I did steps
1-4 with OpenMCL (v1.0) and steps 3-4 (since I already had cells
installed) with SBCL (v0.9.6). These steps don't differ from how I
would install any other lisp library, so I'm surprised that you're
encountering problems.

--
Bill Clementson

Message has been deleted

Paolo Amoroso

unread,
Mar 11, 2006, 6:20:32 AM3/11/06
to
Ken Tilton <kent...@gmail.com> writes:

> thread. You have not responded to those points, but simply say "bad
> doc!". I admit the latter freely, what do you have to say to my points

Incidentally, the best documentation for Cells may be that of
Garnet/KR. Reading this material is enough to understand what Cells
is about, and it can be picked up from the several examples in a
matter of hours.

Folks, especially novices: do check Lisp source code. You may be
surprised at how much you understand.

Thomas F. Burdick

unread,
Mar 11, 2006, 8:43:45 AM3/11/06
to
"bradb" <brad.be...@gmail.com> writes:

> Your energetic post got me interested in Cells, so I downloaded the tgz
> from http://common-lisp.net/project/cells/ & tried to follow the cells
> basic tutorial & Bill's tutorial.
> I have a problem though, no where in the cells source directory can I
> find a definition for the DEF-C-ECHO macro.
> Am I missing something blindingly obvious? Or is Cells ment to be
> installed someother way? ASDF-INSTALL failed (crashed) on a recentish
> SBCL. Should I try to install from CVS?

Cells definately works with recent SBCLs, as that's what I use. I
keep intending to make a new release, as CVS does contain some (rather
obscure) bug fixes, so CVS isn't a bad idea.

--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'

Ken Tilton

unread,
Mar 11, 2006, 10:53:22 AM3/11/06
to
goat_ro...@yahoo.com wrote:
> X-No-Archive:yes
> Ken Tilton wrote:
>
>>goat_ro...@yahoo.com wrote:
>>
>>>X-No-Archive:yes
>>>Ken Tilton wrote:
>>>
>>>
>>>>Peter Seibel wrote:
>>>>
>>>>
>>>>>Ken Tilton <kent...@gmail.com> writes:
>>>>>
>>>>>
>>>>>>Too bad you gave up on Cells at the first backtrace. Cells simply fell
>>>>>>out of an attack on an application problem, turned into a paradigm,
>>>>>>took over the whole application. Would never have happened without
>>>>>>first-class functions, closures, macros, CLOS, untyped variables...
>
>
> Here the dreaded ellipsis (...) appears after a non-sequitur,
> indicating Kenny-knows-what!

... unhygienic variable capture, special variables, non-standard method
combination....


> I admit the latter freely, what do you have to say to my points
>
>>about Cells being the long-sought Silver Bullet?
>
>

> Sorry, I can't speak to that: I haven't tried it.

Nonsense. I listed some of the prior art, some of which you knew. Tell
us the implications you see, if any, of automatic management of
long-lived, interdependent state. I will make it easy for you: how did
Visicalc improve on paper spreadsheets? And remember, this is why Brooks
said a Silver Bullet was impossible.

Or are you actually not interested at all in programming?

>
>
>>If someone brings you cold fusion in a mason jar, are you going to say
>>"No Pyrex beaker?"?
>
>

> No, I would run away yelling "No lead beaker?"

<g>

> And FWIW I have a well-worn copy of Sutherland's dissertation,
> "SKETCHPAD, A MAN-MACHINE GRAPHICAL COMMUNICATION SYSTEM" not 4 feet
> away to my left

Awesome. Just googled it. Thanks. Never saw that before.

> (I could pick it out of my bookshelves blindfolded).
> I've read it no less than 3 times over the years.

Three times?! There is the problem. You like to read doc. I like to
write code. We better call the whole thing off.

> It is very
> well-written and easy to understand. He wrote it _before_ he received
> his Ph.D.

As if! "This paper is based in part on a thesis submitted to the
Department of Electrical Engineering, M.I.T., in partial fulfillment of
the requirements for the Degree of Doctor of Philosophy."

> If you write documentation as clearly as Sutherland did and publish it
> with your code then people will more willingly accept your products.

Look, Sutherland /had/ to write his thesis. His whole frickin'
publish-or-perish career depended on the paper: "Reprinted from
proceedings of the AFIPS Spring Joint Computer Conference, Detroit,
Michigan, May 21-23, 1963, pp. 329-346."

Hope you did not send your shirts out.*

ken

* Adding insult to injury, when a baseball player learns they have been
sent down to the minor leagues for bad performance and must be on the
bus in a few hours to join the lowly new team, sometimes it so happens
they just sent their shirts to the cleaners (to be picked up in three
days--doh!).

bradb

unread,
Mar 11, 2006, 11:17:50 AM3/11/06
to
Thanks, I'll make those changes & see how I get on. If you're super
lucky, you might even get a patch against the documentation :)

Brad

bradb

unread,
Mar 11, 2006, 2:08:06 PM3/11/06
to
No luck with the demos, sorry. Now the function CV is undefined.

Cheers
Brad

Message has been deleted

Ken Tilton

unread,
Mar 11, 2006, 4:35:35 PM3/11/06
to
bradb wrote:
> No luck with the demos, sorry. Now the function CV is undefined.

Help us help you help us to help you. :)

I really really think you are running demo code developed under Cells I
using the Cells II package. CV became C-IN or C-INPUT for the
terseness-challenged.

Any code in any doc I recall would be Cells I code, since I have not
written any doc since Cells I.

(a) Post the code
(b) Tell us where you got it
(c) Tell us if (cells::test-cells) runs to completion
(d) Consider asking on the Cells list (tho I think we are close to
nailing this)

kt

Ken Tilton

unread,
Mar 11, 2006, 5:09:17 PM3/11/06
to
goat_ro...@yahoo.com wrote:
> X-No-Archive:yes
> Ken Tilton wrote:
>
>>... There is the problem. You like to read doc. I like to
>>write code.
>
>
> I read any documentation I believe is useful. I try to write
> documentation before writing code. As code changes I update the
> documentation. Writing, whether code or documentation, helps clarify my
> ideas.

I see. You are weak at solving problems over the keyboard. Documentation
and re-documentation is the only way you can build interesting software.
As a consequence, all your code is documented, however slowly it is
produced. Your feature turns out to be a bug.

I prefer the "code as design" school of thought.

http://www.developerdotstar.com/mag/articles/reeves_design_main.html

The Cells code /is/ my frickin documentation. (Just thought of that one.
<g>)

I imagine Messrs. Burdick and Margioulas got the stupid stuff to run
(meaning the regression test suite), then looked at the regression test
code and thought "WTF is C? and HTH does it work?". Then they did "find
definition" and... read the design.

That's my story and I am sticking to it.

kt

bradb

unread,
Mar 11, 2006, 6:06:43 PM3/11/06
to
a & b) The example code is from
http://www.tilton-technology.com/01-Cell-basics.lisp and
http://bc.tech.coop/blog/030911.html
c) (cells::test-cells) appears to run properly and returns NIL
d) Probably a good idea, I have stolen a bit of the thread here.

I really does look like I am using example code that doesn't map to the
library version :(
It would be really nice if the basic cells tutorial lived in CVS
somewhere & was part of the test suite. It would also be nice if you
could get the cells library from CVS without needing to get other bits
and pieces.

Cheers
Brad

Ken Tilton

unread,
Mar 11, 2006, 6:15:16 PM3/11/06
to
bradb wrote:
> a & b) The example code is from
> http://www.tilton-technology.com/01-Cell-basics.lisp and
> http://bc.tech.coop/blog/030911.html
> c) (cells::test-cells) appears to run properly and returns NIL
> d) Probably a good idea, I have stolen a bit of the thread here.
>
> I really does look like I am using example code that doesn't map to the
> library version :(
> It would be really nice if the basic cells tutorial lived in CVS

Too easy. :) OK, you mean "01-cells-basics.lisp" included on the site? I
will pull that into the next release. Thanks for a good idea.

> somewhere & was part of the test suite. It would also be nice if you
> could get the cells library from CVS without needing to get other bits
> and pieces.

Which were they? I made my own personal suite of CL utilities into a
subdirectory of Cells just to avoid this.

kt

Ken Tilton

unread,
Mar 11, 2006, 6:34:20 PM3/11/06
to
bradb wrote:
> a & b) The example code is from
> http://www.tilton-technology.com/01-Cell-basics.lisp and

Oh, sorry, you said that. OK, I will add this to the Cells source tree
and update.

> http://bc.tech.coop/blog/030911.html

I have also updated the web page link to point to Bill's write-up. Of
course that is still Cells I code.

I will write to Bill and ask if I can pull that into my source tree
along with his comments and then update it to fit cells, well, cells3.

thx for the report.

kt

bradb

unread,
Mar 11, 2006, 6:47:18 PM3/11/06
to
> Which were they? I made my own personal suite of CL utilities into a
> subdirectory of Cells just to avoid this.
>

Actually, you're right there is a link to CVS from here
http://common-lisp.net/project/cells/. I use CVS all the time, but
what I don't usually do is pull from repos. Most Sourceforge pages
have the exact command that you need in order to get the latest CVS, in
your case this is (I think) cvs -z3 -d
:pserver:anonymous:anon...@common-lisp.net:/project/cells/cvsroot co
cell-cultures/cells. It would be nice to have that somewhere on the
main page to ease CVS access.

Though that puts cells into cell-cultures/cells, which isn't _really_
what I want.

Cheers
Brad

Edi Weitz

unread,
Mar 11, 2006, 7:15:50 PM3/11/06
to
On 11 Mar 2006 15:47:18 -0800, "bradb" <brad.be...@gmail.com> wrote:

> It would be nice to have that somewhere on the main page to ease CVS
> access.

<http://common-lisp.net/faq.shtml>

--

European Common Lisp Meeting 2006: <http://weitz.de/eclm2006/>

Real email: (replace (subseq "spam...@agharta.de" 5) "edi")

Ken Tilton

unread,
Mar 11, 2006, 7:18:59 PM3/11/06
to
bradb wrote:
>>Which were they? I made my own personal suite of CL utilities into a
>>subdirectory of Cells just to avoid this.
>>
>
>
> Actually, you're right there is a link to CVS from here
> http://common-lisp.net/project/cells/. I use CVS all the time, but
> what I don't usually do is pull from repos. Most Sourceforge pages
> have the exact command that you need in order to get the latest CVS, in
> your case this is (I think) cvs -z3 -d
> :pserver:anonymous:anon...@common-lisp.net:/project/cells/cvsroot co
> cell-cultures/cells. It would be nice to have that somewhere on the
> main page to ease CVS access.

Actually, I think c-l.net has the advantage over SourceForge here with
nightly tarballs, so no one has to study the CVS /language/ just to get
a little source.

But you do have to know to scroll down to find the little "download
tarball" link.

Of course if you want to /track/ an active project one, well, I use
TortoiseCVS so I /still/ do not need to learn CVS.

ken

bradb

unread,
Mar 11, 2006, 7:35:06 PM3/11/06
to
Ah, I wasn't aware you could get a tarball like that. Which is funny
because I've used that view cvs interface a bit before, I guess you
very quickly filter stuff out :)

Brad

Tayssir John Gabbour

unread,
Mar 11, 2006, 9:21:24 PM3/11/06
to
bradb wrote:
> No luck with the demos, sorry. Now the function CV is undefined.

Does anyone else have problems with DEF-C-OUTPUT? Its OLD-VALUE always
reporting NIL to me... but that doesn't make sense; I expect it to hold
whatever the last slot value was.

Adapted from cells-test/hello-world.test (I tried both latest CVS Cells
and the tarball, with SBCL PPC Darwin 0.9.9):


(use-package :cells)
(use-package :utils-kt)

(defmodel computer ()
((happen :cell :ephemeral :initform (c-in nil) :accessor happen)
(location :cell t
:initform (c? (case (^happen)
(:leave :away)
(:arrive :at-home)
(t .cache))) ;; ie, unchanged
:accessor location)
(response :cell :ephemeral
:initform nil
:initarg :response
:accessor response)))

(macrolet ((fmt (name)
`(format t
"~%~A: ~15A (previously ~:[an unbound ~A~;~A~])"
,name new-value old-value-boundp old-value)))
(def-c-output response () (fmt "response"))
(def-c-output happen () (fmt "happen "))
(def-c-output location () (fmt "location")))

(defun hello-world ()
(let ((dell (make-be 'computer
:response (c? (bwhen (h (happen self))
(if (eql (^location) :at-home)
(case h
(:knock-knock "who's
there?")
(:world "hello, world."))
"<silence>"))))))
(dotimes (n 2)
(setf (happen dell) :knock-knock))
(setf (happen dell) :arrive)
(setf (happen dell) :knock-knock)
(setf (happen dell) :world)
(values)))

CL-USER> (hello-world)

happen : NIL (previously an unbound NIL)
location: NIL (previously NIL)
response: NIL (previously NIL)
happen : KNOCK-KNOCK (previously NIL)
response: <silence> (previously NIL)
happen : KNOCK-KNOCK (previously NIL)
response: <silence> (previously NIL)
happen : ARRIVE (previously NIL)
location: AT-HOME (previously NIL)
happen : KNOCK-KNOCK (previously NIL)
response: who's there? (previously NIL)
happen : WORLD (previously NIL)
response: hello, world. (previously NIL)
; No value

Ken Tilton

unread,
Mar 11, 2006, 10:33:41 PM3/11/06
to
Tayssir John Gabbour wrote:
> bradb wrote:
>
>>No luck with the demos, sorry. Now the function CV is undefined.
>
>
> Does anyone else have problems with DEF-C-OUTPUT? Its OLD-VALUE always
> reporting NIL to me...

That just happens to be the case, partly because it is a silly example,
mostly because most of the slots are ephemeral, which are actually not
the norm in real world programming.

The silly example has the location start out as neither :at-home nor
:away, but instead nil. Hell, I'll go so far as to call that a bug since
that is not a sensible location. I should probably have it be :at-home
if nothing has yet transpired, but the example wants the system to be
away for the first few knocks. And so it goes. :)

if you add (setf (happen dell) :leave) you should see the location
output go from :at-home to :away.

As for ephemerals, oddly enough, Cells being good at modelling
long-lived state created a problem: how does one model events, which
happen but then are no more?

Ask on the Cells list and I will expand further on why events must be
handled differently, but ephemerals are how I hacked events into the
paradigm: slots specified as ephemeral revert to nil immediately after
propagating any non-nil value they assume, but not as a state change
seen by the model.

> but that doesn't make sense; I expect it to hold
> whatever the last slot value was.

Yep. Ephemerals are the oddball in this regard.

ken

Frank Buss

unread,
Mar 11, 2006, 10:41:44 PM3/11/06
to
Ken Tilton wrote:

> Actually, I think c-l.net has the advantage over SourceForge here with
> nightly tarballs, so no one has to study the CVS /language/ just to get
> a little source.

SourceForge has nightly tarballs, too:

http://sourceforge.net/docs/E04/#nightly_tarballs

But it is different from c-l.net: It is a backup of the repository itself,
with all versions included. The same is possible with rsync read-only
access to the subversion repository.

But I don't see the advantage to download the head revision of all files in
CVS or SVN. If you are a developer and you want the latest source, use
checkout and then only bandwith saving updates. If you can't install a SVN
or CVS client, you are not a developer :-)
If you are a more normal user, then use official releases, only.

> Of course if you want to /track/ an active project one, well, I use
> TortoiseCVS so I /still/ do not need to learn CVS.

There is not much to learn for CVS or SVN, if you just want to track an
active project: an initial checkout (e.g. "svn co
https://svn.sourceforge.net/svnroot/lispbuilder lispbuilder" for the Common
Lisp Application Builder project at http://sf.net/projects/lispbuilder )
and a "svn up" (started in the project directory, no other options are
needed) everytime you want to be up-to-date is sufficient. Same with cvs,
only the path for the "co" command is different.

--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Ken Tilton

unread,
Mar 11, 2006, 11:32:33 PM3/11/06
to
Frank Buss wrote:
> Ken Tilton wrote:
>
>
>>Actually, I think c-l.net has the advantage over SourceForge here with
>>nightly tarballs, so no one has to study the CVS /language/ just to get
>>a little source.
>
>
> SourceForge has nightly tarballs, too:
>
> http://sourceforge.net/docs/E04/#nightly_tarballs
>
> But it is different from c-l.net: It is a backup of the repository itself,
> with all versions included. The same is possible with rsync read-only
> access to the subversion repository.
>
> But I don't see the advantage to download the head revision of all files in
> CVS or SVN. If you are a developer and you want the latest source, use
> checkout and then only bandwith saving updates. If you can't install a SVN
> or CVS client, you are not a developer :-)

You have been using that crap too long if you think software needs to be
that obtuse.

:)

ken

Frank Buss

unread,
Mar 11, 2006, 11:57:29 PM3/11/06
to
Ken Tilton wrote:

> You have been using that crap too long if you think software needs to be
> that obtuse.

Do you have an alternative? With SVN it is even easier to do version
management than with CVS, which I've used for many projects. And I have
used other version management systems, like Continuus and ClearCase and
compared to CVS they were constantly in the way of my workflow :-)

Ken Tilton

unread,
Mar 12, 2006, 12:47:48 AM3/12/06
to
Frank Buss wrote:
> Ken Tilton wrote:
>
>
>>You have been using that crap too long if you think software needs to be
>>that obtuse.
>
>
> Do you have an alternative? With SVN it is even easier to do version
> management than with CVS, which I've used for many projects. And I have
> used other version management systems, like Continuus and ClearCase and
> compared to CVS they were constantly in the way of my workflow :-)
>

(a) I can only tell you what I have heard, first that Subversion was
better, then something else even betterer which I forget.

(b) My larger point is that TortoiseCVS managed somehow to be
user-friendly while sitting atop CVS. I suppose that under extreme
circumstances everything in CVS can find a use, the design mistake was
not making simple things simple. Like TortoiseCVS did.

kt

Tayssir John Gabbour

unread,
Mar 12, 2006, 12:53:16 AM3/12/06
to
Ken Tilton wrote:

> Tayssir John Gabbour wrote:
> > Does anyone else have problems with DEF-C-OUTPUT? Its OLD-VALUE always
> > reporting NIL to me...
>
> That just happens to be the case, partly because it is a silly example,
> mostly because most of the slots are ephemeral, which are actually not
> the norm in real world programming.

Aaah, yes that makes sense. My understanding is that with discrete
processes, we basically have a choice between cells being T or
:ephemeral ("states" and "events").

And :delta seems to be absent from your sourcetree, which makes sense
too.

Do you think it would be an improvement to have :cell T by default, and
if you want to cause an event, you'd do something other than setting
the slot-value? Like:
(setf (happens obj) :new-state) ;stays :new-state until changed
(eventf (happens obj) :new-event) ;reverts to initform immediately


Incidentally, if anyone could clarify a couple quick questions I'd be
grateful:

* So, cells only update other cells in their own object instance (not
even cells allocated as :class)? Which means a cell in one object has
to explicitly set another object's c-in cell?

* What other notable vars are there, like .cache and the ^slotnames?


Thanks,
Tayssir

Message has been deleted

Ken Tilton

unread,
Mar 12, 2006, 1:54:31 AM3/12/06
to
Tayssir John Gabbour wrote:
> Ken Tilton wrote:
>
>>Tayssir John Gabbour wrote:
>>
>>>Does anyone else have problems with DEF-C-OUTPUT? Its OLD-VALUE always
>>>reporting NIL to me...
>>
>>That just happens to be the case, partly because it is a silly example,
>>mostly because most of the slots are ephemeral, which are actually not
>>the norm in real world programming.
>
>
> Aaah, yes that makes sense. My understanding is that with discrete
> processes, we basically have a choice between cells being T or
> :ephemeral ("states" and "events").
>
> And :delta seems to be absent from your sourcetree, which makes sense
> too.

That is either vestigial or will be resurrected if it ever comes up
again. I honestly forget if I found :delta slots were obsoleted by
synapses or closures or something, and it is too late to figure out now.

The idea was to have, say, consecutive (setf (foo bar) 42) forms
propagate each time, but then:

(setf (foo bar) 0)

..not propagate at all. Kind of a second-order thang. This came up in a
physics simulation, of a pendulum, IIRC.


>
> Do you think it would be an improvement to have :cell T by default,

? It is. Do you mean eliminate the :ephemeral alternative? I will guess
yes based on the next:

> and
> if you want to cause an event, you'd do something other than setting
> the slot-value? Like:
> (setf (happens obj) :new-state) ;stays :new-state until changed
> (eventf (happens obj) :new-event) ;reverts to initform immediately

No. Eventhood (if you will) is an attribute of the slot, so the slot
should always behave eventishly. :)

Likewise outputs (ne echos, defined by def-c-output) are GFs specialized
on the slot-name (and class and new and old values, but the point is
that, unlike the rules one associates with a slot, they cannot be varied
instance by instance.

>
>
> Incidentally, if anyone could clarify a couple quick questions I'd be
> grateful:
>
> * So, cells only update other cells in their own object instance (not
> even cells allocated as :class)?

No. And, not to quibble, I would say cells can depend on cells of any
instance (so, yes, propagation (updating, as you say) can flow between
cells of different instances).

> Which means a cell in one object has
> to explicitly set another object's c-in cell?

You have been looking at the Cells-Gtk code, haven't you? :) SETFs of
c-ins are rampant there. They are the equivalent of GOTOs, and largely
defeat the declarative quality Cells provides.

It is probably my fault. I used that trick to deal with circularities
when in a weak moment i decided it was simpler than having a mechanism
in Cells to deal with cycles. I do not think I will ever ban the trick
outright, but I will always be looking for an excuse to do so. :) Cells3
at least forces one to wrap such behavior in a "mother, may I?" macro.

>
> * What other notable vars are there, like .cache and the ^slotnames?

self, .cause (if that is still working <g>), and .parent, though the
last two are just symbol macros you can track down.

ken

Thomas F. Burdick

unread,
Mar 12, 2006, 2:33:02 AM3/12/06
to
"bradb" <brad.be...@gmail.com> writes:

> > Which were they? I made my own personal suite of CL utilities into a
> > subdirectory of Cells just to avoid this.
> >
>
> Actually, you're right there is a link to CVS from here
> http://common-lisp.net/project/cells/. I use CVS all the time, but
> what I don't usually do is pull from repos. Most Sourceforge pages
> have the exact command that you need in order to get the latest CVS, in
> your case this is (I think) cvs -z3 -d
> :pserver:anonymous:anon...@common-lisp.net:/project/cells/cvsroot co
> cell-cultures/cells. It would be nice to have that somewhere on the
> main page to ease CVS access.

Oops, I hear some maintenance work calling. Use this command instead:

cvs -z3 -d :pserver:anonymous:anon...@common-lisp.net:/project/cells/cvsroot co cells

The cells-cultures stuff isn't how things are organized anymore.

Ken Tilton

unread,
Mar 12, 2006, 3:05:42 AM3/12/06
to
goat_ro...@yahoo.com wrote:
> X-No-Archive:yes
> Ken Tilton wrote:
>
>>I see. You are weak at solving problems over the keyboard. Documentation
>>and re-documentation is the only way you can build interesting software.
>>As a consequence, all your code is documented, however slowly it is
>>produced. Your feature turns out to be a bug.
>
>
> I see.

How witty, mirroring my flame. <yawn> Get your own style.

> You are weak at solving problems by thinking. Hacking and
> re-hacking code randomly is the only way you can build software.

You don't like monkeys?

> As a
> consequence, none your code is documented, however slowly it is
> produced. Your bug turns out to be a feature.

I don't know, it sounds like we both go through the same exploratory
process since you confess to having to go back and re-document when you
realize the design arising from your original effort needed more work.
ie, the documentation you write and re-write does not actually produce
good design, it just lets you think slower. I understand, I need that,
too, on rare occasions.

What I do not understand is how your approach works in the best
applications of Lisp, when, as Graham says, we are not even sure what
kind of program we are writing. Do you just keep writing documentation
and (peeking ahead) doing math formulae and symbolic logic until you
know? Gosh.

>
> One such programmer was preparing a new system feature for a
> convention. While working late one evening he described his problem. I
> immediately recognized and explained the solution, a simple algebraic
> transformation requiring at most 20 LOC. But he was very poor at math
> and could not understand.

I can identify with him. We are not smart like you. I am just a simple
applications guy. Stalled a wing in Calc III.

> Instead he worked an 80-hour week "changing
> the code until it works" (his words).

Can you possibly be unaware of Tilton's Law? "That code works signifies
nothing."

> He was still hacking code at the
> convention. He claimed to have succeeded just before the doors opened.
>
> When first hired he appeared to be an extremely hardworking individual.
> We soon realized he was little more than a human random code generator.
>
> Documentation written by such programmers is useless since they do not
> understand their code.

Well, there are monkeys and then there are monkeys. My secret weapon is
my lack of intelligence. If I cannot understand my code (more likely if
it becomes painful to live with) I change it. That is trick number one.
Trick number two: every change must lead to more code being deleted than
new code is written. Bonus points for every clarifying comment that can
be deleted because the clarifyee gets deleted.

But you do remind me of the project when I worked with a bunch of brits
who thought they were better than everyone. Typical yobs. One of them
finally complimented me for always being able to solve problems, even
when everyone else was stumped. I responded that I just kept trying
different things until something worked, at which point one them
startled us all by shouting, "That's right!". Like you he was deeply
resentful that anything less than an anal-retentive, theoretically
founded, tediously documented, correctness proven, UML diagrammed,
change controlled approach could succeed.

The exercise left for the reader is exactly how not planning prevails
where planning fails. Compare and contrast Grant vs. McClellan, Patton
vs. Montgomery, and Reinhold Messner vs. seige mountaineering.

Happily, we have come full circle and are back on topic. How does Lisp
affect software architecture? Lisp is so expressive that we can design
over the keyboard. We are programming at a higher level, sometimes with
awesome tools such as DEFMACRO, sometimes just because we have this vast
library of utilities polished by almost fifty years of use, and always
because we do not have to fuss endlessly with static typing. That means
we can reach for the stars in our designs, and the resulting
applications reflect it. They themselves become meta-applications or,
with Foderaro, programmable applications.

All flamewar fun aside, thanks for looking so closely at Cells. I know
literate programming is not "heavy commenting", but I am pretending I
never heard that and the code is at least getting surrounded by a lot of
discussion. But only as sections get re-visited, so you still might
hate it.


kt

Tayssir John Gabbour

unread,
Mar 12, 2006, 3:50:13 AM3/12/06