From: Peter Seibel
Subject: The Amazon PCL tide may be heading back out to sea
Date:
Message-ID: <m3u0mez3lu.fsf@gigamonkeys.com>
After hitting a high-water mark of Sales Rank #543 last night, the
tide of PCL sales on Amazon seems to be subsiding somewhat. Which is
not to say it's doing too badly--it's still at #1317 and a few days
ago I was thrilled when it broke <5,000.
I imagine by now all Lispers tuned into the normal Lisp channels
(c.l.l., #lisp, the Lisp blogs) have heard about the book and--based
on the past few days excitement--many of them have bought it. My next
challenge is to see if I can get the word out to the merely
Lisp-curious. If you want to help out, think about whether there's
anything you can do now so that come Monday morning, when Joe and
Josephine Nonlisper roll into work and fire up their browsers and/or
email clients, there'll be something that makes them say, "Holy cow!
There's a new Lisp book out. And people seem excited about it. Maybe
Lisp isn't as dead as I thought. I should check it out." Maybe that's
just sending an email to the folks you know who've expressed some
interest in Lisp or maybe you participate in someother online forum
where a mention would be appropriate. Or maybe you know someone who
writes a blog that's *not* part of Planet Lisp but who might be
interested. Or something else entirely.
Anyway, the main book url is, as always:
<http://www.gigamonkeys.com/book/>
and the Amazon link is:
<http://www.amazon.com/exec/obidos/ASIN/1590592395>
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> After hitting a high-water mark of Sales Rank #543 last night, the
> tide of PCL sales on Amazon seems to be subsiding somewhat. Which is
> not to say it's doing too badly--it's still at #1317 and a few days
> ago I was thrilled when it broke <5,000.
>
> I imagine by now all Lispers tuned into the normal Lisp channels
> (c.l.l., #lisp, the Lisp blogs) have heard about the book and--based
> on the past few days excitement--many of them have bought it. My next
> challenge is to see if I can get the word out to the merely
> Lisp-curious. If you want to help out, think about whether there's
Here's my situation...
After dismissing Lisp as arcane and/or irrelevant a year ago because I
found Python, I decided to give Lisp another shot recently. I'd love
to learn it well and start using it, but I'm not sure what the best
book is to start with. I'm not even sure it's what I need for my
programming problems. I really like PCL and I plan to buy it, but
probably after the PG book. I don't know how to get around this. I
can't seem to jump from most Lisp books into working code. I feel like
I'll be writing C or C++ in Lisp. And that's not what I want to do.
Does anyone have any ideas on how to avoid this trap?
De-lurking to answer jonathon's question.
It's hard to see how to apply lisp when you're so accustomed to other
paradigms. I started with the PG:ANSI-CL book, but got totally spaced out a
few chapters in where he started discussing trees and raytracers. My specific
problem was I didn't see where all the memory for the tree nodes was coming
from, and I'd just written a C++ raytracer which looked *nothing* like the lisp
one; and I completely lost the ability to follow along soon after. In fact, in
PCL too I only read the latter part of 'other uses for conses'.
>Does anyone have any ideas on how to avoid this trap?
So FWIW, I'd suggest staying away from code that you've written before in iter
langs, because C background is hard to get rid of. Anyway, with PCL, Chap. 3
really gets you 'thinking in lisp' and following along with the iterative devpt
style. The DB example was sufficiently novel, as was the unit testing later.
I've never before jumped into working real life code either. Toy code, consing,
making amusing assoc lists that track monkey fever rampage through the cast of
Friends, sure, but real code, no.
This time I've committed to Lisp with a project, with PCL and MOP to help. But
I read most of PCL to decide it was doable before committing.
Decide how well you jell with the style, I found it's highly readable, very
well explained (almost every question you have is explained by the next para, a
very difficult thing to find in most books) and has a great sequencing.
So if you like the book I'd recommend PCL before ANSI-CL, which is a good
reference though.
It's humbling in a way that I can read Stoustrup or Scott Meyers but get
totally bogged down when it comes to even middling-advance lisp stuff. OTOH On
Lisp is going well so far.
This is getting OT, so I'll stop here. Good luck.
--
Nandan Bagchee
Some kinds of waste really are disgusting. SUVs, for example, would arguably
be gross even if they ran on a fuel which would never run out and generated
no pollution. SUVs are gross because they're the solution to a gross problem.
(How to make minivans look more masculine.)
-- Paul Graham
Nandan wrote:
> De-lurking to answer jonathon's question.
I appreciate it. :-)
> This time I've committed to Lisp with a project, with PCL and MOP to
help.
I can't figure out what book 'MOP' is.
> So if you like the book I'd recommend PCL before ANSI-CL, which is a
good
> reference though.
I think that will be next on my list. Or perhaps the Keene book. You
said ANSI-CL was a good reference, but I thought it was a regular intro
to Lisp?
From: Zach Beane
Subject: Re: The Amazon PCL tide may be heading back out to sea
Date:
Message-ID: <m3ekdhktrc.fsf@unnamed.xach.com>
"jonathon" <···········@bigfoot.com> writes:
>> So if you like the book I'd recommend PCL before ANSI-CL, which is a
> good
>> reference though.
>
> I think that will be next on my list. Or perhaps the Keene book. You
> said ANSI-CL was a good reference, but I thought it was a regular intro
> to Lisp?
I don't think it's either; it neither fully introduces Common Lisp nor
provides a useful reference. With the HyperSpec keystrokes away in any
reasonable CL environment, there's no reason to use any other source
as a pure reference.
It's the book I started with, but I haven't opened it more than a few
times after I first read it. On the other hand, I still find Paradigms
of AI Programming by Norvig very useful, and I think Practical Common
Lisp is an excellent exposition of /all/ features of Common Lisp.
Zach
>I can't figure out what book 'MOP' is.
Art of the meta-object protocol, by Gregor Kiczales (same guy behind J..
AspectJ). Sounds intimidating, but I've been told it isn't. I expect it to be
an elucidation of the generic functions that Seibel introduces. I still in some
sense think of lists of objects a la C++, so I'll start by mixing paradigms a
bit. This is in some sense a head-first project, failure isn't an option; so I
guess I'm over-fortifying. Keene is probably a better introduction, though PCL
lays it out very well for my C++ background.
>I think that will be next on my list. Or perhaps the Keene book. You
>said ANSI-CL was a good reference, but I thought it was a regular intro
>to Lisp?
Well in our Lisp class we were told it had a little ref in the appendix, without
the overhead of the hyperspec. Also PG spends quite some time discussing the possibilities
in each construct while PCL gives you the three most useful ways. This (I found) makes
PCL a better newbie book, since it explains the 'how to' while ANSI-CL explains several
details, which (comparitively) makes it more reference-like.
HTH, n
--
Nandan Bagchee
So I think people who are mature and experienced, with a business background,
may be overrated. We used to call these guys 'newscasters', because they had
neat hair and spoke in deep, confident voices, and generally didn't know much
more than they read on the teleprompter.
-- Paul Graham
From: Pascal Costanza
Subject: Re: The Amazon PCL tide may be heading back out to sea
Date:
Message-ID: <3c07u3F6feo11U1@individual.net>
Nandan wrote:
>>I can't figure out what book 'MOP' is.
>
> Art of the meta-object protocol, by Gregor Kiczales (same guy behind J..
> AspectJ). Sounds intimidating, but I've been told it isn't. I expect it to be
> an elucidation of the generic functions that Seibel introduces.
In a certain sense you're right, but that's also somewhat besides the point.
By default, CLOS internally implements classes as arrays, and each slot
name is mapped to an index into such arrays. Furthermore, generic
functions are objects that have a list of methods associated with them,
and whenever a generic function is called, it selects the right methods
from that list, combines them and then executes the combined methods.
What the CLOS Metaobject Protocol does is that it specifies how this all
is implemented in terms of CLOS itself. So the mapping of slots to
indices is achieved via a set of generic functions that determine the
set of actual slots for a class and then associates the indices to those
slots. The method dispatch of a generic function is also achieved via a
set of generic functions that perform the steps described above.
What this buys you is that you can define your own methods on those
generic functions and thus implement your own object model. This is used
in practice for example for mapping slots to columns in databases
instead of indices in RAM, or to call foreign methods as if they were
regular CLOS methods. You can achieve these things by, more or less,
straightforward object-oriented programming in CLOS. [1]
Some may find the fact that CLOS is implemented in terms of itself, and
especially that the method dispatch inside generic functions is
implemented with generic functions, somewhat puzzling, but that's "just"
the kind of metacircularity that you already have for the "kernel" Lisp
itself.
For an excellent introduction read the freely downloadable paper
"User-Level Language Crafting" by Andreas Paepcke. If you want a deeper
discussion afterwards, there's no way around the AMOP book by Kiczales
et al.
Pascal
[1] It's not so straightforward due to incompatibilities across MOP
implementations - that's because the MOP is not actuallly part of ANSI
Common Lisp.
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
"jonathon" <···········@bigfoot.com> writes:
> I think that will be next on my list. Or perhaps the Keene book. You
> said ANSI-CL was a good reference, but I thought it was a regular intro
> to Lisp?
Speaking of Common Lisp references, I preordered this other book by
Apress (scheduled for publication around next July):
The ANSI Common Lisp Reference Book
http://www.apress.com/book/bookDisplay.html?bID=263
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
> Some kinds of waste really are disgusting. SUVs, for example,
> would arguably be gross even if they ran on a fuel which would
> never run out and generated no pollution. SUVs are gross because
> they're the solution to a gross problem. (How to make minivans
> look more masculine.)
>
> -- Paul Graham
Perhaps the next step will be familiar vehicules made by Caterpilar...
http://toughquip.com/images/sce/769D_220.gif
or even:
http://toughquip.com/images/sce/D1OR_220.gif
--
__Pascal Bourguignon__ http://www.informatimago.com/
In a World without Walls and Fences,
who needs Windows and Gates?
From: Peter Seibel
Subject: Re: The Amazon PCL tide may be heading back out to sea
Date:
Message-ID: <m3zmw6xf78.fsf@gigamonkeys.com>
"jonathon" <···········@bigfoot.com> writes:
> Peter Seibel wrote:
>> After hitting a high-water mark of Sales Rank #543 last night, the
>> tide of PCL sales on Amazon seems to be subsiding somewhat. Which is
>> not to say it's doing too badly--it's still at #1317 and a few days
>> ago I was thrilled when it broke <5,000.
>>
>> I imagine by now all Lispers tuned into the normal Lisp channels
>> (c.l.l., #lisp, the Lisp blogs) have heard about the book and--based
>> on the past few days excitement--many of them have bought it. My next
>> challenge is to see if I can get the word out to the merely
>> Lisp-curious. If you want to help out, think about whether there's
>
> Here's my situation...
>
> After dismissing Lisp as arcane and/or irrelevant a year ago because I
> found Python, I decided to give Lisp another shot recently. I'd love
> to learn it well and start using it, but I'm not sure what the best
> book is to start with. I'm not even sure it's what I need for my
> programming problems. I really like PCL and I plan to buy it, but
> probably after the PG book. I don't know how to get around this. I
> can't seem to jump from most Lisp books into working code. I feel like
> I'll be writing C or C++ in Lisp. And that's not what I want to do.
>
> Does anyone have any ideas on how to avoid this trap?
So I'm obviously biased but I'd say: buy _Practical Common Lisp_
before Graham's book. The whole goal of PCL is to show folks who know
how to program in other languages how to make the jump to writing real
code in Common Lisp. Perhaps someone less biased than me can comment
on whether my suggestion has any actual merit.
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> "jonathon" <···········@bigfoot.com> writes:
>
>
>>can't seem to jump from most Lisp books into working code. I feel like
>>I'll be writing C or C++ in Lisp. And that's not what I want to do.
>>
>>Does anyone have any ideas on how to avoid this trap?
>
>
> So I'm obviously biased but I'd say: buy _Practical Common Lisp_
> before Graham's book. The whole goal of PCL is to show folks who know
> how to program in other languages how to make the jump to writing real
> code in Common Lisp. Perhaps someone less biased than me can comment
> on whether my suggestion has any actual merit.
My copy has not yet arrived. Does PCL, with its emphasis on pragmatism,
address the question of Lispy vs. non-Lispy style?
I remember a short, simple bit in On Lisp where Graham talks about the
visual flow of truly Lispy code. viz:
xxxxx
xxxx xxxx xxxxx
xxxx xxxx xx
xxx xxx xxx xxxx xxx
xxxx xxxx xxx
xxxx xxx
Strange as it seems, a simple guide like that can go a long way towards
achieving a functional style.
As for the fading Amazon spike, it will be nothing compared to the
steady surge as PCL feeds the surge in Lisp interest which began a
couple of years ago. But the time scale will be a year, so get
comfortable and enjoy the ride. :)
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
On Mon, 11 Apr 2005 02:02:12 +0000, Kenny Tilton wrote:
> As for the fading Amazon spike, it will be nothing compared to the
> steady surge as PCL feeds the surge in Lisp interest which began a
> couple of years ago.
What surge?
BR wrote:
> On Mon, 11 Apr 2005 02:02:12 +0000, Kenny Tilton wrote:
>
>
>>As for the fading Amazon spike, it will be nothing compared to the
>>steady surge as PCL feeds the surge in Lisp interest which began a
>>couple of years ago.
>
>
> What surge?
Surge is a second-order quality, so before answering (other than refer
you to my sig)...how long have you been watching? esp. c.l.l.
kenny
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Oops! BR <··········@comcast.net> was seen spray-painting on a wall:
> On Mon, 11 Apr 2005 02:02:12 +0000, Kenny Tilton wrote:
>
>> As for the fading Amazon spike, it will be nothing compared to the
>> steady surge as PCL feeds the surge in Lisp interest which began a
>> couple of years ago.
>
> What surge?
Oh, there has certainly been a surge of interest, at least if the
nature of traffic in this newsgroup is any indication.
--
(reverse (concatenate 'string "moc.liamg" ·@" "enworbbc"))
http://cbbrowne.com/info/
Rules of the Evil Overlord #35. "I will not grow a goatee. In the old
days they made you look diabolic. Now they just make you look like a
disaffected member of Generation X." <http://www.eviloverlord.com/>
From: Peter Seibel
Subject: Re: The Amazon PCL tide may be heading back out to sea
Date:
Message-ID: <m3vf6uxcxh.fsf@gigamonkeys.com>
Kenny Tilton <·······@nyc.rr.com> writes:
> Peter Seibel wrote:
>> "jonathon" <···········@bigfoot.com> writes:
>>
>>>can't seem to jump from most Lisp books into working code. I feel like
>>>I'll be writing C or C++ in Lisp. And that's not what I want to do.
>>>
>>>Does anyone have any ideas on how to avoid this trap?
>> So I'm obviously biased but I'd say: buy _Practical Common Lisp_
>> before Graham's book. The whole goal of PCL is to show folks who know
>> how to program in other languages how to make the jump to writing real
>> code in Common Lisp. Perhaps someone less biased than me can comment
>> on whether my suggestion has any actual merit.
>
> My copy has not yet arrived. Does PCL, with its emphasis on
> pragmatism, address the question of Lispy vs. non-Lispy style?
If it does, it's mostly by way of example. You can grab the source
code:
<http://www.gigamonkeys.com/book/practicals-1.0.2.tar.gz>
or:
<http://www.gigamonkeys.com/book/practicals-1.0.2.zip>
and decide if it's sufficiently Lispy for your taste.
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Your suggestion has merit.
I had an earlier post about my disillusionment with C++
and my eventual journey to the strange new land of Lisp.
I'm in the process of reading the preliminary draft of PCL and
am quite impressed by the readablility of it.
There is a secret hiding out there amongst thousands of developers,
a dream of tools and a software development environment
to rival the simulation and design tools that architects and engineers
have now.
For me, ultimate expression of that dream is to elucidate some sort
of correspondence between geometrical shapes and abstract
algorithm design and then have an environment which embodies
it. The only people I found who were doing research in this
general direction were Gerard Langlet (the famous APL researcher
and physicist, regretfully deceased before he could begin a comphrehensive
presentation of his ideas in book form) and Aoki Atsushi, creator of the
"Jun" graphics subsystem in Smalltalk.
That innocent old Lisp, lying in plain view all this time, might
have the capability to send me more in the
direction of the above mentioned dream as well as provide me
with the coherence that I found so lacking in C++
is just part of the promise that I believe it holds.
I will be buying the book. Soon.
Thanks
Tak
"Peter Seibel" <·····@gigamonkeys.com> wrote in message
···················@gigamonkeys.com...
> "jonathon" <···········@bigfoot.com> writes:
>
>> Peter Seibel wrote:
>>> After hitting a high-water mark of Sales Rank #543 last night, the
>>> tide of PCL sales on Amazon seems to be subsiding somewhat. Which is
>>> not to say it's doing too badly--it's still at #1317 and a few days
>>> ago I was thrilled when it broke <5,000.
>>>
>>> I imagine by now all Lispers tuned into the normal Lisp channels
>>> (c.l.l., #lisp, the Lisp blogs) have heard about the book and--based
>>> on the past few days excitement--many of them have bought it. My next
>>> challenge is to see if I can get the word out to the merely
>>> Lisp-curious. If you want to help out, think about whether there's
>>
>> Here's my situation...
>>
>> After dismissing Lisp as arcane and/or irrelevant a year ago because I
>> found Python, I decided to give Lisp another shot recently. I'd love
>> to learn it well and start using it, but I'm not sure what the best
>> book is to start with. I'm not even sure it's what I need for my
>> programming problems. I really like PCL and I plan to buy it, but
>> probably after the PG book. I don't know how to get around this. I
>> can't seem to jump from most Lisp books into working code. I feel like
>> I'll be writing C or C++ in Lisp. And that's not what I want to do.
>>
>> Does anyone have any ideas on how to avoid this trap?
>
> So I'm obviously biased but I'd say: buy _Practical Common Lisp_
> before Graham's book. The whole goal of PCL is to show folks who know
> how to program in other languages how to make the jump to writing real
> code in Common Lisp. Perhaps someone less biased than me can comment
> on whether my suggestion has any actual merit.
>
> -Peter
>
> --
> Peter Seibel ·····@gigamonkeys.com
>
> Lisp is the red pill. -- John Fraser, comp.lang.lisp
Takuon Soho <···@somwhere.net> schrieb:
> There is a secret hiding out there amongst thousands of developers, a
> dream of tools and a software development environment to rival the
> simulation and design tools that architects and engineers have now.
>
> For me, ultimate expression of that dream is to elucidate some sort of
> correspondence between geometrical shapes and abstract algorithm
> design and then have an environment which embodies it.
I think this is a pipe dream because the very things that make algorithm
design different from physical design are what make it more useful. For
example, it would be nice to have something like physical "tolerances"
where a small difference here or there didn't break an algorithm, but at
the same time the fact that small local code changes can completely
change the global behaviour of a program are what make programs
maintainable and extensible. Not to mention that physical machines (or
geometric approximations thereof) have little capability for
abstraction. Babbage invented the Difference Engine precisely because
programming it was better than building special-purpose machines for
everything it could do. Your notion of physicalizing algorithms is going
the wrong direction. Can you explain why you disagree, or have I
completely misunderstood you?
Adrian Kubala wrote:
> Takuon Soho <···@somwhere.net> schrieb:
>> For me, ultimate expression of that dream is to elucidate some sort of
>> correspondence between geometrical shapes and abstract algorithm
>> design and then have an environment which embodies it.
>
> I think this is a pipe dream because the very things that make algorithm
I'll be glad to disagree :-).
I and my colleagues have been doing this very thing for over a decade now.
We build embedded systems software by drawing "schematics" of the software
and compiling the schematics to machine code (or VM code).
If you have a hardware background, you can understand that algorithms can be
implemented in hardware, hence, it should be entirely possible to use
CAD/CAM principles to architect algorithms and systems.
I'm in the comp.lang.lisp newsgroup because I use the most powerful
non-graphical language - Common Lisp - to implement the compilers for our
graphical tools. On top of which, using Lisp is a very mind-opening
exercise.
> the same time the fact that small local code changes can completely
> change the global behaviour of a program are what make programs
> maintainable and extensible.
That's only because current coding languages are based on the wrong
fundamental principles. Get rid of CALL / RETURN (and RPC's and other
variants) and a whole lot of hidden, breakable dependencies disappear.
> Not to mention that physical machines (or
> geometric approximations thereof) have little capability for
> abstraction.
And that's a good thing!
Have you ever seen an architect hand off a sheaf of abstractions to a
bridge-building contractor? No, the architect gives them very precise
instructions, tuned to the exact problem at hand. The next time the
architect is faced with a similar problem, he reuses his previous work by
simply looking at his old drawings - simple, effective reuse.
We (the software community) took the wrong turn at Albuquerque.
We need blueprints for software. We need to be able to draw software.
pt
> That's only because current coding languages are based on the wrong
> fundamental principles. Get rid of CALL / RETURN (and RPC's and other
> variants) and a whole lot of hidden, breakable dependencies disappear.
>
I have often wondered if there were not another abstraction that got
rid of call/return similarly to how functional languages rid the need
of 'set'. Do you happen to have any liturature on such languages?
Formal papers perhaps?
--
-Dave Watson
········@docwatson.org
Dave Watson wrote:
> I have often wondered if there were not another abstraction that got
> rid of call/return similarly to how functional languages rid the need
> of 'set'. Do you happen to have any liturature on such languages?
> Formal papers perhaps?
We haven't written anything for public dissemination, yet. We've been
OEM'ing the technology and generally too busy trying to make a living.
Our inspiration came from a variety of sources:
- The concept of deferred monitors in the Turing language (something which
we might have inspired).
- Harel's Statecharts work. He did at least two things that we strongly
disagreed with, though. He tangled concurrency into the notation. He
described synchronous micro-semantics that could not possibly be used for
any of the real-time work we were doing.
- CSP, Occam
- Writing RTOS (real-time operating system) after RTOS, and thinking that
"this is just too clumsy and inefficient".
- Examining the reasons why hardware engineers could design systems that
were testable and ultimately more predictable and reliable (at least until
they started to use C-inspired design languages :-).
- Design and engineering of protocols.
pt
Paul Tarvydas <········@attcanada.ca> schrieb:
> embedded systems [...] hardware [...] blueprints
I can understand how these kinds of systems can benefit from a graphical
approach because, like traditional architecture, they deal with clear
requirements, little to no maintainance, and conceptually-simple
problems. But this kind of software engineering is in the minority, and
if it weren't, you'd be using your graphical tools to develop your
graphical-tool-compiler instead of Lisp.
Or I'd put it in evolutionary terms: new kinds of single-celled
organisms are fine and dandy, but brains are where the real revolution
is at. (Not to insult embedded systems, but to suggest that there's
whole levels of complexity we haven't even begun to explore, and
graphical languages can't take us there.)
Adrian Kubala wrote:
> I can understand how these kinds of systems can benefit from a graphical
> approach because, like traditional architecture, they deal with clear
> requirements, little to no maintainance, and conceptually-simple
> problems. But this kind of software engineering is in the minority, and
You've clearly never been involved in embedded systems work. Everything
you've said is exactly the opposite of the reality.
Stop and think about a famous case: the Mars Rovers. They are very typical
embedded systems problems (except for the fact that they had "reasonable"
budgets and probably had written requirements). Enormous amounts of
functionality squeezed into the smallest computer and smallest memory
possible, no choice of CPU (there's only a few mil-spec cpu's around, and
even fewer that can survive the extreme temperature differences required,
so you are forced to use whatever the hardware guys choose for you and hold
your nose), drop-dead shipping dates (the code had to be shipped on the
launch date, even though it had not completed testing) and in-field
failures that required serious maintenance.
Here's another problem to ponder: my customer designed some hardware and
expected to ship 20 million units. Obviously, the customer would not be
happy if the code had any bugs, or could not be updated in the field when a
bug fix or improvement was required. The business case suggested that
improvements and radical additions would be required every 3 months. Our
experience suggested that the code would take 10 man-years to develop and
would require 250K-500K of code space. Do the math on the download time
over phone lines (these devices would reside in people's homes - no
ethernet).
Really.
Go do the math.
(hint: 1200 Baud = approx. 120 bytes per second).
See how many servers you'd need and how long they'd be running to download
every quareterly update to 20 million units. How would you solve this
"conceptually-simple" problem? Oh, another small detail - the hardware had
a couple of megs of data space, but provided only 64K (k, not m) of code
space (i.e. not even close to the size of a Java interpreter).
My automobile has 13 cpu's in it. Use any present software technique you
want, but you have to sign a legal document that says that you were the
lead Engineer on the software project and that you will be held legally
responsible if any of the 13 cpu's has a bug in it - in any of the millions
of automobiles that use your code.
Especially if loss of life is involved.
That's what Engineers do when they affix their stamp and signature to a
design - they take personal, legal responsibility.
So, which language / technique do you plan to use for this conceptually
simple problem? Your career rests on your decision.
> if it weren't, you'd be using your graphical tools to develop your
> graphical-tool-compiler instead of Lisp.
The technique I'm using is called "bootstrapping" and is instantly
recognizable to anyone involved in new language design.
> Or I'd put it in evolutionary terms: new kinds of single-celled
> organisms are fine and dandy, but brains are where the real revolution
> is at. (Not to insult embedded systems, but to suggest that there's
> whole levels of complexity we haven't even begun to explore, and
> graphical languages can't take us there.)
Ok, that's your opinion. My opinion, based on 30 years of experience, is
that our technologies are at the breaking point and that we won't proceed
to new levels of complexity without a radical re-thinking of how we do
things. I find it personally insulting that the richest software company
on the planet cannot create a piece of software that doesn't break in the
field, after 20 years of continuous, intensive effort.
For fun, read the book "The Sleepwalkers" by Arthur Koestler and see how
time and time again, very smart people (e.g Copernicus, Keppler, et al)
refuse to see the warning signs that their theories and beliefs are
fundamentally broken.
(And, yes, that's not a typo - Copernicus, Keppler, et al - the guys who
destroyed the Ptolmaic System and the concept of Epicycles, didn't "get"
their own theories - the book is a fun read in that it exposes these
brilliant people to be only-human-after-all).
pt
ps. Oh, OK, here's the answer. 250*1024 / 120 = 2133 sec = 35 minutes to
download one cpu's worth of code. 700,000,000 minutes to download all 20
million units. That's 11,666,666 hours or 486,111 days. Since there's
about 90 days in a quarter, you'd need 5,401 servers running 24/7 (well,
enough servers to run 5,401 phone lines full blast - you'd probably have to
go to the telco with a special request for upgrading their switches, if you
were planning to occupy 5,000 lines continuously, forever). If one of
those servers goes down, your customer gets PO'ed and loses big $'s due to
missed marketing opportunities. What are you going to do if the line burps
in the middle of a download and the embedded device becomes a paper-weight?
Send a repair person to the house? With an installed base of 20M units,
how big is your maintenance staff? How important ($'s) is it to get the
software right?
> Have you ever seen an architect hand off a sheaf of abstractions to a
> bridge-building contractor? No, the architect gives them very precise
> instructions, tuned to the exact problem at hand. The next time the
> architect is faced with a similar problem, he reuses his previous work by
> simply looking at his old drawings - simple, effective reuse.
>
> We (the software community) took the wrong turn at Albuquerque.
>
> We need blueprints for software. We need to be able to draw software.
>
> pt
Intriguing and well spoken.
I could not agree more.
> That's only because current coding languages are based on the wrong
> fundamental principles. Get rid of CALL / RETURN (and RPC's and other
> variants) and a whole lot of hidden, breakable dependencies disappear.
It took dunderhead me almost 10 years to realize the veracity of this.
I shall be awed by the C++ "experts" no more.
Thanks
Tak (J Pannozzi)
"Paul Tarvydas" <········@attcanada.ca> wrote in message
···························@rogers.com...
> Adrian Kubala wrote:
>
>> Takuon Soho <···@somwhere.net> schrieb:
>>> For me, ultimate expression of that dream is to elucidate some sort of
>>> correspondence between geometrical shapes and abstract algorithm
>>> design and then have an environment which embodies it.
>>
>> I think this is a pipe dream because the very things that make algorithm
>
> I'll be glad to disagree :-).
>
> I and my colleagues have been doing this very thing for over a decade now.
> We build embedded systems software by drawing "schematics" of the software
> and compiling the schematics to machine code (or VM code).
>
> If you have a hardware background, you can understand that algorithms can
> be
> implemented in hardware, hence, it should be entirely possible to use
> CAD/CAM principles to architect algorithms and systems.
>
> I'm in the comp.lang.lisp newsgroup because I use the most powerful
> non-graphical language - Common Lisp - to implement the compilers for our
> graphical tools. On top of which, using Lisp is a very mind-opening
> exercise.
>
>> the same time the fact that small local code changes can completely
>> change the global behaviour of a program are what make programs
>> maintainable and extensible.
>
> That's only because current coding languages are based on the wrong
> fundamental principles. Get rid of CALL / RETURN (and RPC's and other
> variants) and a whole lot of hidden, breakable dependencies disappear.
>
>> Not to mention that physical machines (or
>> geometric approximations thereof) have little capability for
>> abstraction.
>
> And that's a good thing!
>
> Have you ever seen an architect hand off a sheaf of abstractions to a
> bridge-building contractor? No, the architect gives them very precise
> instructions, tuned to the exact problem at hand. The next time the
> architect is faced with a similar problem, he reuses his previous work by
> simply looking at his old drawings - simple, effective reuse.
>
> We (the software community) took the wrong turn at Albuquerque.
>
> We need blueprints for software. We need to be able to draw software.
>
> pt
>
Paul Tarvydas <········@allstream.net> wrote:
+---------------
| Adrian Kubala wrote:
| > Takuon Soho <···@somwhere.net> schrieb:
| >> For me, ultimate expression of that dream is to elucidate some sort of
| >> correspondence between geometrical shapes and abstract algorithm
| >> design and then have an environment which embodies it.
| >
| > I think this is a pipe dream because the very things that make algorithm
|
| I'll be glad to disagree :-).
|
| I and my colleagues have been doing this very thing for over a decade now.
| We build embedded systems software by drawing "schematics" of the software
| and compiling the schematics to machine code (or VM code).
...
| We (the software community) took the wrong turn at Albuquerque.
| We need blueprints for software. We need to be able to draw software.
+---------------
Indeed. Google for the programming language "Prograph", developed
in the early 1980's at McGill University, IIRC, and continued at
Dalhousie University by Tomasz Pietrzykowski, Michael Levin, and
others. [Hmmm.... <http://users.cs.dal.ca/~smedley/Research.html>
indicates that work in that field is still going on at Dalhousie.]
It was an almost fully functional, graphical, dataflow language
which one programmed by "wiring" sources, sinks, databases, and
processing boxes together, very much like drawing a schematic.
Pictorius, Inc. of Halifax, Nova Scotia <www.pictorius.com> sold
a commercial version for the Mac. [The <http://www.pictorius.com/>
domain seems to be dead, but see <http://www.tritera.com/prograph.html>.]
Tha abstract at <http://portal.acm.org/citation.cfm?id=317169> has
additional description, wherein it is compared to Lisp & Prolog:
...[but] which overcomes some of the shortcomings of Lisp by
replacing the usual textual representation of programs by
pictures called "prographs".
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Indeed. Google for the programming language "Prograph", developed
There's been a bunch, e.g. LabView, Visual Smalltalk with Parts, Sun's Java
Visual Workbench (? IIRC), UML, etc, etc.
Many of them fail to achieve their goals because they only look like
schematics, but don't act like schematics (i.e. they allow CALL / RETURN to
leak into the notations).
To work like a schematic, every part on a schematic must be asynchronous -
just like they are on an electronics schematic. An easy (but inefficient)
way to understand this is to think that every part on a schematic is
running in its own thread / process. Only then, do you get the "benefits"
of electronics-like schematics - fully decoupled components, plugable
components, drawable designs, etc.
pt
Paul Tarvydas wrote:
>Rob Warnock wrote:
>
>
>
>>Indeed. Google for the programming language "Prograph", developed
>>
>>
>
>There's been a bunch, e.g. LabView, Visual Smalltalk with Parts, Sun's Java
>Visual Workbench (? IIRC), UML, etc, etc.
>
>Many of them fail to achieve their goals because they only look like
>schematics, but don't act like schematics (i.e. they allow CALL / RETURN to
>leak into the notations).
>
>To work like a schematic, every part on a schematic must be asynchronous -
>just like they are on an electronics schematic. An easy (but inefficient)
>way to understand this is to think that every part on a schematic is
>running in its own thread / process. Only then, do you get the "benefits"
>of electronics-like schematics - fully decoupled components, plugable
>components, drawable designs, etc.
>
>pt
>
>
This is a good insight. What about recursion? That's also a CALL /
RETURN in a way. That would suggest that attempts to make a visual (as
in schematic) LISP will have a serious problem to deal with in terms of
decoupled components.
--
Barry
Barry Jones wrote:
> This is a good insight. What about recursion? That's also a CALL /
> RETURN in a way. That would suggest that attempts to make a visual (as
> in schematic) LISP will have a serious problem to deal with in terms of
> decoupled components.
There's a point below which drawings cease to be useful - i.e. where we
already have perfectly usable notations. For example, math and equations.
[We, in fact learned this the hard way - at first we super-atomized all of
our visual code and used things like "+" parts. The resulting diagrams
were a mess and much less expressive than "a = b + c;" code snipppets].
You use diagrams (composed of decoupled components) to express high-level
architecture.
What is "inside" a component can be, roughly, two things - (a) more
diagrams, or, (b) code.
When you get to the code-level, you use whatever makes sense, including
recursion, just as long as what you do doesn't leak out across the
boundaries of the component.
Note that, you can achieve decoupling (worthy of diagrams) by doing exactly
the opposite of what I'm talking about, i.e. using pure functional
languages. A blob of purely functional code is completely self-contained
and can be replaced by another "pin compatible" blob of code (algebraic
substitution, alpha/beta-reductions).
I know that what I'm talking about works "in the field", even on crappy
8-bit processors (8051's to be exact, and ARM's). We've shipped real
product with this technique and we've updated systems incrementally by
downloading a part at a time (typical part size = 100 bytes). I don't know
if a purely functional approach could attain this level of practicality (at
a minimum, after downloading a new function, you'd have to run the code
through a linker and the linker would have to check the parameter lists).
Common Lisp, too, does some neat things towards this problem - you can load
code on-the-fly (which is one of the reasons a lisp environment is so
convenient to use).
No No No No NO!!!!!!!!!
This is not what I meant.
These examples are diagrammatic and 2D.
The conceptual breakthrough that I seek and which I was probably
not clear enough about when I started this thread, is fundamentally
3D in nature. It involves the geometric manipulation of 3D shapes (not
2d!)
in a 3D perspective projection space. It additionally involves things which
have not yet been invented - most particulary, a correspondence between
software development algorithmic constructs and some sort of geometrical
or fractal shapes. I eventually decided that fractals were probably going
to
be the most likely attempt at realizing this.
That is not to detract from or take away from the dataflow concepts
or other 2d visualization attempts - they are just are different idea
and not at all what I was suggesting.
Thanks
Tak (James Pannozzi)
"Paul Tarvydas" <········@attcanada.ca> wrote in message
···························@rogers.com...
> Rob Warnock wrote:
>
>> Indeed. Google for the programming language "Prograph", developed
>
> There's been a bunch, e.g. LabView, Visual Smalltalk with Parts, Sun's
> Java
> Visual Workbench (? IIRC), UML, etc, etc.
>
> Many of them fail to achieve their goals because they only look like
> schematics, but don't act like schematics (i.e. they allow CALL / RETURN
> to
> leak into the notations).
>
> To work like a schematic, every part on a schematic must be asynchronous -
> just like they are on an electronics schematic. An easy (but inefficient)
> way to understand this is to think that every part on a schematic is
> running in its own thread / process. Only then, do you get the "benefits"
> of electronics-like schematics - fully decoupled components, plugable
> components, drawable designs, etc.
>
> pt
>
Rob Warnock <····@rpw3.org> schrieb:
> "Prograph" [...] Tha abstract at
> <http://portal.acm.org/citation.cfm?id=317169> has additional
> description, wherein it is compared to Lisp & Prolog:
>
> ...[but] which overcomes some of the shortcomings of Lisp by
> replacing the usual textual representation of programs by
> pictures called "prographs".
Here is their description of Lisps shortcomings: "[...] the strict
functional nature of Lisp allows only one return value from each
function evaluation, and requires an evaluation to be repeated if its
result is required in more than one place." Honestly I don't know what
they're talking about -- did Lisp not have "let" back then? Anyways it's
far from obvious, as they claim, that these problems are inherent in any
textual representation.
Plus, I think that these days nobody really uses a one-dimensional
textual representation for code, so it's a straw man. We have folding,
tags, searching, auto-indent, syntax highlighting, and the REPL, all
based on the idea that the program *is* an abstract multi-dimensional
entity which you can explore and manipulate in dialog with the computer.
Oh, one more reason that prographs and the like aren't the future:
alphabets outlasted ideograms.
Adrian Kubala wrote:
> Oh, one more reason that prographs and the like aren't the future:
> alphabets outlasted ideograms.
I see it exactly the other way around. What the software community is
trying to achieve is ratcheting the act programming up to the level of an
engineering discipline.
The fact that most other Engineering disciplines use diagrams - blueprints,
schematics, plans - and hire trained draftspeople, should give us a clue
about what's missing from our discipline!
Corollary: the fact that what we're doing cannot be expressed in clear,
exact diagrammatic form should set off alarm bells - we're making a mess
out of things (and the result is: buggy code, high in-the-field failure
rates, reactions of complete shock when asked to act like Engineers and to
sign our work, to put guarantees on our work and to take legal
responsibility for our work).
pt
Paul Tarvydas <········@attcanada.ca> schrieb:
> The fact that most other Engineering disciplines use diagrams -
> blueprints, schematics, plans - and hire trained draftspeople, should
> give us a clue about what's missing from our discipline!
Blueprints (and physical engineering for that matter) are completely
different from software, so I wish you wouldn't make unfounded analogies
to them:
1. They have a precise, obvious correspondence to their final physical
manifestation. It makes sense to draw pictures of *things*. Software
is not "things".
2. They are intended for human consumption, and therefore can rely on
conventions and shortcuts which are easily understood but not easily
formalized. When you try to make them unambiguous, they become
cumbersome.
Drawing diagrams just means specifying extra information (like layout)
irrelevant to the important concepts at hand. I think that's why
hardware designers prefer HDLs to circuit diagrams (and that's one of
the few domains where I agree that picto-languages might be useful).
What's your theory?
Adrian Kubala wrote:
...
>What's your theory?
My theory is that we (you and I) are miscommunicating and that we're coming
from completely different backgrounds with different fundamental belief
systems, that make it hard to understand one another.
I graduated from hard-core physics plus a smattering of comp. sci. in '77,
then, again, I graduated from Electrical Engineering in '81. I was
certified as a Professional Engineer in Ontario in '83. My wife happens to
be a certified Civil Engineer. I do have a clue what it means to call
something "Engineering" and what blueprints and schematics are.
I built my first compiler (lisp, on a Z80 with about 24K of memory) around
'78 (by stealing the code from John R. Allen's "The Anatomy of Lisp"). And
I've been building compilers/interpreters/RTOS'es about once a year or so
since then. I've been deeply interested in language design for the past
few decades, and I've even affected a language you might have heard about
(check the acknowledgements section of "Eiffel: The Language").
I've been consulting in software for 20 years and have worked on a wide
variety of systems - 22 Mloc banking systems, online forex, restaurant
automation, machine control, POS (point of sale) devices, smart electricity
meters, 3D graphics engines, etc.
>Blueprints (and physical engineering for that matter) are completely
>different from software, so I wish you wouldn't make unfounded analogies
>to them:
You are welcome to disagree with me, but, my analogies to Engineering are
not unfounded.
>1. They have a precise, obvious correspondence to their final physical
>���manifestation.�It�makes�sense�to�draw�pictures�of�things.�Software
>���is�not�"things".
This is an insightful point! And, respectfully, I totally disagree with
you.
I, most certainly, treat lumps of code - lines, functions, whole subsystems
- as "things".
I want to take these lumps - "parts", "components" - and arrange them in
meaningful ways to solve very specific problems.
I want my solution to be well-documented and to be easily reused.
I firmly believe that when my solutions can be represented in a formalized
pictorial form, they will be better documented and more easily reused, than
if they were presented in textual form only.
I've formed this opinion after some 30 years of beating my head against the
wall.
To belabour the point - how is an electrical schematic related to a physical
manifestation? Schematics are logical diagrams. They don't represent
physical layout whatsoever. Yet, schematics work very well.
>2. They are intended for human consumption, and therefore can rely on
>���conventions�and�shortcuts�which�are�easily�understood�but�not�easily
>���formalized.�When�you�try�to�make�them�unambiguous,�they�become
>���cumbersome.
Engineering is the art/science of being very, very specific and of thinking
through all of the minutia of a project.
The drawings that real Engineers use are not in any way ambiguous. There
may exist shorthand conventions, but these conventions are well-documented
and taught in schools - so that everyone understands the drawings and the
shorthand notations.
I believe that we don't have this sort of thing in software design. Despite
a number of attempts to crack this nut.
>Drawing diagrams just means specifying extra information (like layout)
>irrelevant to the important concepts at hand.
Again, I stronly disagree.
Layout of a project is supremely important. More important than the actual
code itself.
Code is cheap.
Design is expensive.
If you want to create code faster, learn to touch-type.
If you want to create designs faster, learn to think better and steal
designs from someone who's already solved some of your problems.
Layout shows how you - the designer - have decided to solve a specific
problem.
Code is just what the brick-layers decided to use to implement your design.
The layout IS the design. It's the most valuable, costly part of the
project. Someone - an engineer, an architect, a high-paid designer -
thought long and hard about the problem and the layout shows how they
decided to solve the problem. More than one solution is possible, but a
diagram of the chosen actual solution tells everyone what's going on and
what the designer orignally intended.
My opinion is that our biggest challenge is that we cannot capture the
expensive stuff - design of software - in meaningful, accurate, reusable
ways.
My opinion is that the best way to get out of this quandry is to reuse ideas
from more well-established disciplines.
pt
Paul Tarvydas <········@attcanada.ca> writes:
> The fact that most other Engineering disciplines use diagrams - blueprints,
> schematics, plans - and hire trained draftspeople, should give us a clue
> about what's missing from our discipline!
It's not clear to me that text is not the best way to express a program.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
No excuses. No apologies. Just do it.
--- Erik Naggum
Adrian Kubala <···········@sixfingeredman.net> wrote:
> Oh, one more reason that prographs and the like aren't the future:
> alphabets outlasted ideograms.
... well, except for among the 1.5 billion people who read and write
Chinese and Japanese. Some languages (Perl, for one) now allow you to
use Unicode in program code, meaning that you can name your variables
with Chinese characters if you care to do such a thing.
--
Karl A. Krueger <········@example.edu> { s/example/whoi/ }
Karl A. Krueger <········@example.edu> schrieb:
> Adrian Kubala <···········@sixfingeredman.net> wrote:
>> Oh, one more reason that prographs and the like aren't the future:
>> alphabets outlasted ideograms.
>
> ... well, except for among the 1.5 billion people who read and write
> Chinese and Japanese.
Neither of these languages is ideographic. See:
http://www.pinyin.info/readings/texts/ideographic_myth.html
From: Christopher C. Stacy
Subject: Re: OT: geometrical algorithm design
Date:
Message-ID: <uvf6nzx43.fsf@news.dtpq.com>
Adrian Kubala <···········@sixfingeredman.net> writes:
> Rob Warnock <····@rpw3.org> schrieb:
> > "Prograph" [...] Tha abstract at
> > <http://portal.acm.org/citation.cfm?id=317169> has additional
> > description, wherein it is compared to Lisp & Prolog:
> >
> > ...[but] which overcomes some of the shortcomings of Lisp by
> > replacing the usual textual representation of programs by
> > pictures called "prographs".
>
> Here is their description of Lisps shortcomings: "[...] the strict
> functional nature of Lisp allows only one return value from each
> function evaluation, and requires an evaluation to be repeated if its
> result is required in more than one place." Honestly I don't know what
> they're talking about -- did Lisp not have "let" back then? Anyways it's
> far from obvious, as they claim, that these problems are inherent in any
> textual representation.
>
> Plus, I think that these days nobody really uses a one-dimensional
> textual representation for code, so it's a straw man. We have folding,
> tags, searching, auto-indent, syntax highlighting, and the REPL, all
> based on the idea that the program *is* an abstract multi-dimensional
> entity which you can explore and manipulate in dialog with the computer.
That's all the stuff we had for Lisp in the late 1970s (at least).
(Except, if by "syntax coloring" you're referring to color displays,
we didn't have those. But the editor was certainly aware of the syntax.)
Prograph is described as "a visual, dataflow, object-oriented
programming language". On their commercial Prograph web site
the authors also claim, "Visual Programming as a research topic
is still very young, having been aggressively pursued for less
than 15 years". That claim is amusing, since the same web site
links to the 11th annual IEEE symposium on the subject, held 1995
(suggesting at least 21 years).
I remember that there was lots of work (for example, by Lieberman at MIT)
on visual programming and debugging (writing programs by drawing diagrams
of control and data flow, entity relationships, and object-oriented
programming, on the screen with a mouse) back around 1980. He even did
a visual "program by example" system in 1983. And I am pretty sure
there was even earlier research (eg. at PARC).
Looking at this Prograph language more closely, it appears to have
in fact been started by Pietrzykowski and Cox in 1983, and evolved
recentyly to embrace object oriented programming. I was looking at
this paper, <http://students.cs.byu.edu/~dheise/cs330/Prograph_final_report.pdf>
which talks about Prograph "being dead" and the above mentioned
company having gone bankrupt in 1996.
Visual programming has caught on in some domains, though.
There have been lots of process-control and workflow systems for
writing programs (for example, visually writing the code that
defines telephone switch services). And lots of database stuff.
Microsoft Access would be a good example of a popular system today.
I'm not sure why visual programming never seems to catch on in general.
Programmers they often like to draw some pictures while they
are working, and the like to see pictures of what they have
programmed, and naybe use those for navigation. But I think
there's something word-oriented in their brains that complements,
but cannot be replaced by the pictures. I don't think it's the
quality of the GUIs or the visual langage's concepts or expressive power.
Rather, there's something word-oriented about the programmer's
conceptual formulation of the program. And as a result, programmers
are more expressive in words (even though pictures are helpful).
> Oh, one more reason that prographs and the like aren't the future:
> alphabets outlasted ideograms.
I don't think you can say that, since there are at least 1.3E9 people
today who use idiographic languages (eg. Chinese).
But Prograph wasn't about ideograms, anyway; it's about diagrams.
Christopher C. Stacy <······@news.dtpq.com> wrote:
+---------------
| But Prograph wasn't about ideograms, anyway; it's about diagrams.
+---------------
And dataflow & databases. One of the people working on it once
explained it to me as (at least partly) an attempt to create
a functional, dataflow version of relational algebra. That is
[if I'm remembering correctly], you could take a "Select" object
and plumb it into a database relation object and then plumb the
output of that into another database relation object and get a
wire coming out that had the query results of the "join" of the
relations (or something along those lines). The idea was to use
high-enough level models for the dataflow that you could get
significant parallelism going, just as another poster was asking for.
[I don't know if they ever got that far...]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
> Visual programming has caught on in some domains, though.
> There have been lots of process-control and workflow systems for
> writing programs ...
The "(.*flow)" systems were not at all what I meant
by the idea of "geometrical algorithm design".
I was referring to a 3D space.
Again, let us go back to the architectural analogy,
however rough. The builder and architect do indeed
work with 2D schematics or blueprints.
Imagine for a moment that architects do not have the
ability to visualize 3d (preposterous, yes but bear with me
for a moment). So they use 2D blueprints to do all their
designs and then later the builders, following the 2d
blueprints as best they can, build the buildings.
What happens? Well, the buildings and bridges get
built but there are all kinds of anomalies. Bridges
warp and sometimes collapse. Buildings may have
all kinds of design shortcomings that were not
apparent at the onset(sort of like
the software of today, eh?)
We are like those limited dimensionality minded architects.
We have the software symbol languages down pat
and we may have some useful dataflow 2d design languages
and aids. But what we seem to missing is the 3D analogues
of all this - the representation of the algorithm in algorithm
space and I am suggesting that a mapping from algorithm
space to 3D space just might... might be possible
and wondered if anyone had made an attempt.
Because if no one has, then its open season for anyone,
including me, who wants to try.
Those who consider this impossible are welcome
to not try.
That is the missing link of software development,
not object oriented code or extreme programming
or any of the other gimmicks.
And it seems to me, that if any language were
perfect for a starting place to make this
exploration, it has got to be Lisp.
Thanks
Tak
(Jim Pannozzi)
> I'm not sure why visual programming never seems to catch on in general.
> Programmers they often like to draw some pictures while they
> are working, and the like to see pictures of what they have
> programmed, and naybe use those for navigation. But I think
> there's something word-oriented in their brains that complements,
> but cannot be replaced by the pictures. I don't think it's the
Strongly agree about there being something word-oriented in our
brians that complements pictures - the 3D "Shapeorithms"
that I am suggesting would indeed be an adjunct to design
with code and not at all to be considered a replacement... but
then again... (!)
(Takuon)
(Jim Pannozzi)
"Christopher C. Stacy" <······@news.dtpq.com> wrote in message
··················@news.dtpq.com...
> Adrian Kubala <···········@sixfingeredman.net> writes:
>
>> Rob Warnock <····@rpw3.org> schrieb:
>> > "Prograph" [...] Tha abstract at
>> > <http://portal.acm.org/citation.cfm?id=317169> has additional
>> > description, wherein it is compared to Lisp & Prolog:
>> >
>> > ...[but] which overcomes some of the shortcomings of Lisp by
>> > replacing the usual textual representation of programs by
>> > pictures called "prographs".
>>
>> Here is their description of Lisps shortcomings: "[...] the strict
>> functional nature of Lisp allows only one return value from each
>> function evaluation, and requires an evaluation to be repeated if its
>> result is required in more than one place." Honestly I don't know what
>> they're talking about -- did Lisp not have "let" back then? Anyways it's
>> far from obvious, as they claim, that these problems are inherent in any
>> textual representation.
>>
>> Plus, I think that these days nobody really uses a one-dimensional
>> textual representation for code, so it's a straw man. We have folding,
>> tags, searching, auto-indent, syntax highlighting, and the REPL, all
>> based on the idea that the program *is* an abstract multi-dimensional
>> entity which you can explore and manipulate in dialog with the computer.
>
> That's all the stuff we had for Lisp in the late 1970s (at least).
> (Except, if by "syntax coloring" you're referring to color displays,
> we didn't have those. But the editor was certainly aware of the syntax.)
>
> Prograph is described as "a visual, dataflow, object-oriented
> programming language". On their commercial Prograph web site
> the authors also claim, "Visual Programming as a research topic
> is still very young, having been aggressively pursued for less
> than 15 years". That claim is amusing, since the same web site
> links to the 11th annual IEEE symposium on the subject, held 1995
> (suggesting at least 21 years).
>
> I remember that there was lots of work (for example, by Lieberman at MIT)
> on visual programming and debugging (writing programs by drawing diagrams
> of control and data flow, entity relationships, and object-oriented
> programming, on the screen with a mouse) back around 1980. He even did
> a visual "program by example" system in 1983. And I am pretty sure
> there was even earlier research (eg. at PARC).
>
> Looking at this Prograph language more closely, it appears to have
> in fact been started by Pietrzykowski and Cox in 1983, and evolved
> recentyly to embrace object oriented programming. I was looking at
> this paper,
> <http://students.cs.byu.edu/~dheise/cs330/Prograph_final_report.pdf>
> which talks about Prograph "being dead" and the above mentioned
> company having gone bankrupt in 1996.
>
> Visual programming has caught on in some domains, though.
> There have been lots of process-control and workflow systems for
> writing programs (for example, visually writing the code that
> defines telephone switch services). And lots of database stuff.
> Microsoft Access would be a good example of a popular system today.
>
> I'm not sure why visual programming never seems to catch on in general.
> Programmers they often like to draw some pictures while they
> are working, and the like to see pictures of what they have
> programmed, and naybe use those for navigation. But I think
> there's something word-oriented in their brains that complements,
> but cannot be replaced by the pictures. I don't think it's the
> quality of the GUIs or the visual langage's concepts or expressive power.
> Rather, there's something word-oriented about the programmer's
> conceptual formulation of the program. And as a result, programmers
> are more expressive in words (even though pictures are helpful).
>
>> Oh, one more reason that prographs and the like aren't the future:
>> alphabets outlasted ideograms.
>
> I don't think you can say that, since there are at least 1.3E9 people
> today who use idiographic languages (eg. Chinese).
>
> But Prograph wasn't about ideograms, anyway; it's about diagrams.
"Takuon Soho" <···@somwhere.net> wrote in message
························@newsread2.news.pas.earthlink.net...
>> Visual programming has caught on in some domains, though.
>> There have been lots of process-control and workflow systems for
>> writing programs ...
>
> The "(.*flow)" systems were not at all what I meant
> by the idea of "geometrical algorithm design".
> I was referring to a 3D space.
>
> Again, let us go back to the architectural analogy,
> however rough. The builder and architect do indeed
> work with 2D schematics or blueprints.
>
> Imagine for a moment that architects do not have the
> ability to visualize 3d (preposterous, yes but bear with me
> for a moment). So they use 2D blueprints to do all their
> designs and then later the builders, following the 2d
> blueprints as best they can, build the buildings.
> What happens? Well, the buildings and bridges get
> built but there are all kinds of anomalies. Bridges
> warp and sometimes collapse. Buildings may have
> all kinds of design shortcomings that were not
> apparent at the onset(sort of like
> the software of today, eh?)
>
> We are like those limited dimensionality minded architects.
> We have the software symbol languages down pat
> and we may have some useful dataflow 2d design languages
> and aids. But what we seem to missing is the 3D analogues
> of all this - the representation of the algorithm in algorithm
> space and I am suggesting that a mapping from algorithm
> space to 3D space just might... might be possible
> and wondered if anyone had made an attempt.
> Because if no one has, then its open season for anyone,
> including me, who wants to try.
> Those who consider this impossible are welcome
> to not try.
>
Of course it's not impossible, we already do it. The problem
is that going 3D doesn't actually get you anything. The 2D
stuff is already 3D, think about the old 3 houses, 3 utilities
problem, but even flowcharts allow for paths to cross. The spaces
are isomorphic.
--
Geoff
"Geoffrey Summerhayes" <·············@hotmail.com> wrote in message
·························@news20.bellglobal.com...
> Of course it's not impossible, we already do it. The problem
> is that going 3D doesn't actually get you anything. ...
OK, good.
But nobody has attempted to formalize this?
Tak
>
> "Takuon Soho" <···@somwhere.net> wrote in message
> ························@newsread2.news.pas.earthlink.net...
>>> Visual programming has caught on in some domains, though.
>>> There have been lots of process-control and workflow systems for
>>> writing programs ...
>>
>> The "(.*flow)" systems were not at all what I meant
>> by the idea of "geometrical algorithm design".
>> I was referring to a 3D space.
>>
>> Again, let us go back to the architectural analogy,
>> however rough. The builder and architect do indeed
>> work with 2D schematics or blueprints.
>>
>> Imagine for a moment that architects do not have the
>> ability to visualize 3d (preposterous, yes but bear with me
>> for a moment). So they use 2D blueprints to do all their
>> designs and then later the builders, following the 2d
>> blueprints as best they can, build the buildings.
>> What happens? Well, the buildings and bridges get
>> built but there are all kinds of anomalies. Bridges
>> warp and sometimes collapse. Buildings may have
>> all kinds of design shortcomings that were not
>> apparent at the onset(sort of like
>> the software of today, eh?)
>>
>> We are like those limited dimensionality minded architects.
>> We have the software symbol languages down pat
>> and we may have some useful dataflow 2d design languages
>> and aids. But what we seem to missing is the 3D analogues
>> of all this - the representation of the algorithm in algorithm
>> space and I am suggesting that a mapping from algorithm
>> space to 3D space just might... might be possible
>> and wondered if anyone had made an attempt.
>> Because if no one has, then its open season for anyone,
>> including me, who wants to try.
>> Those who consider this impossible are welcome
>> to not try.
>>
>
> Of course it's not impossible, we already do it. The problem
> is that going 3D doesn't actually get you anything. The 2D
> stuff is already 3D, think about the old 3 houses, 3 utilities
> problem, but even flowcharts allow for paths to cross. The spaces
> are isomorphic.
>
> --
> Geoff
>
Thanks for an interesting objection
and yes I disagree and I suspect it is I who
have not been entirely clear in elucidating this idea.
Let us take, for an obvious example, the Simplex algorithm - a known
method of optimizing situations involving thousands of variables.
It is known that there are geometrical interpretations of this algorithm
(and I am not referring to Karamkar's breakthrough, this was done
long before that) and that in the geometrical interpretation, the
optimizations can be seen as paths accross some surface.
It so happens, because this is the realm of mathematics,
that this kind of correspondence occurs. No big deal then.
Now, imagine a mechanical engineer/bridge designer
designing a bridge, he could call up perhaps a finite element program
or a program that simulated wind loading and other stresses and would
probably have already drawn the bridge in some sort of CAD/CAM
program which would might interact with the other softwares.
A plethora of visual tools are at his disposal.
But, the poor software engineer does not have a tool that would
allow him to express his desired algorithm in anything other than
symbols. He might be a sophisticated designer and use the method of least
preconditions
of the renowned E. Dykstra in a modified Boolean logic is used to develop
some algorithm
but it would still be entirely operations on abstract symbologies.
And all he would have is stuff like the pathetically named "Visual
Development IDE Environments"
of the present whoose only "visual" aspect is that you can drag and drop
some stupid icons and forms and windows and when you type in some
class name it will do some rudimentary class or variable completion for you.
In some cases, when you create a window or button by dragging and dropping
icons, it will create some preliminary outline code for you - well that is
a step in the right direction anyway.
The question I have wondered about for some time is - could this process
be improved by some sort of real geometrical visualization??
At first I naively thought perhaps something like modified Platonic solids
might do the trick
but they are far too limiting.
Eventually I came to suspect (without any theory and not at all being a
researcher)
that the answer might lie in fractals and, sure enough, Gerard Langlet seems
to have
been going in this direction at the time of his untimely death.
So, the software engineer of the future, if he had such a tool as I am
envisioning,
and indeed if it is even possible, might switch from a fractalic to a
symbolic
view of the same algorithm or code. And, if one were to load the shape
into a 3d kind of paint program and operate on in some fashion, perhaps
replicating
some portion of the curves, and then return to the symbolic view, the code
would have
addtitional functions automatically generated by the shape interpreter.
Likewise, if the code were altered by the addition or deletion of functions
or lines, the symbolic shape representing the algorithm would be changed
by the symbol interpreter.
A pipe dream then? Perhaps.
But I am sure of one thing even from what little Lisp I know already.
C++ would fall over and die trying to do such a thing
but Lisp - that is the language which might do it.
Thanks.
Tak (Jim Pannozzi)
P.S. Re: Algorithm tolerance adjustment idea you mentioned -
It's already been done and is called Fuzzy Logic.
"Adrian Kubala" <···········@sixfingeredman.net> wrote in message
·······························@sixfingeredman.net...
> Takuon Soho <···@somwhere.net> schrieb:
>> There is a secret hiding out there amongst thousands of developers, a
>> dream of tools and a software development environment to rival the
>> simulation and design tools that architects and engineers have now.
>>
>> For me, ultimate expression of that dream is to elucidate some sort of
>> correspondence between geometrical shapes and abstract algorithm
>> design and then have an environment which embodies it.
>
> I think this is a pipe dream because the very things that make algorithm
> design different from physical design are what make it more useful. For
> example, it would be nice to have something like physical "tolerances"
> where a small difference here or there didn't break an algorithm, but at
> the same time the fact that small local code changes can completely
> change the global behaviour of a program are what make programs
> maintainable and extensible. Not to mention that physical machines (or
> geometric approximations thereof) have little capability for
> abstraction. Babbage invented the Difference Engine precisely because
> programming it was better than building special-purpose machines for
> everything it could do. Your notion of physicalizing algorithms is going
> the wrong direction. Can you explain why you disagree, or have I
> completely misunderstood you?
Takuon Soho <···@somwhere.net> schrieb:
> So, the software engineer of the future, if he had such a tool as I am
> envisioning, and indeed if it is even possible, might switch from a
> fractalic to a symbolic view of the same algorithm or code.
This is fascinating and I bet you are right that some software
engineering problems could be illuminated by visualization. However I
don't think it's obvious that, in general, images are any more intuitive
to humans than symbols. I know a good book can move me just as much as a
movie, and it doesn't seem like Eschers vastly outnumber Paul Grahams.
(Aesthetics are subtle in any medium -- maybe they're slightly easier to
recognize in a visual medium but not easier to produce.)
Plus, I don't see any reason that a mapping between elegant images and
elegant algorithms should be any less complex than a complete human
brain.
"Takuon Soho" <···@somwhere.net> wrote:
> So, the software engineer of the future, if he had such a tool as I am
> envisioning,
> and indeed if it is even possible, might switch from a fractalic to a
> symbolic
> view of the same algorithm or code. And, if one were to load the
> shape into a 3d kind of paint program and operate on in some fashion,
> perhaps replicating
> some portion of the curves, and then return to the symbolic view, the
> code would have
> addtitional functions automatically generated by the shape
> interpreter. Likewise, if the code were altered by the addition or
> deletion of functions or lines, the symbolic shape representing the
> algorithm would be changed by the symbol interpreter.
do you or Paul have an example how this could work? I think it is a very
interesting idea to write programs by drawing diagrams, like electronic
schematics. There are already tools, with which you can do this, like
LabView. But a diagram is 2D, so it would be difficult to represent it as
a readable piece of text. And why should one want to do it? When drawing
a construction diagram for a bridge, there is no need for the engineer to
view it as a textual list of lines and points (only for production,
perhaps).
And of course, once you have implemented the base system in Lisp, you can
draw the system with the system itself and you don't need Lisp anymore.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss <··@frank-buss.de> writes:
> "Takuon Soho" <···@somwhere.net> wrote:
>
> > So, the software engineer of the future, if he had such a tool as I am
> > envisioning,
> > and indeed if it is even possible, might switch from a fractalic to a
> > symbolic
> > view of the same algorithm or code. And, if one were to load the
> > shape into a 3d kind of paint program and operate on in some fashion,
> > perhaps replicating
> > some portion of the curves, and then return to the symbolic view, the
> > code would have
> > addtitional functions automatically generated by the shape
> > interpreter. Likewise, if the code were altered by the addition or
> > deletion of functions or lines, the symbolic shape representing the
> > algorithm would be changed by the symbol interpreter.
>
> do you or Paul have an example how this could work? I think it is a very
> interesting idea to write programs by drawing diagrams, like electronic
> schematics. There are already tools, with which you can do this, like
> LabView.
Yes, interresting and funny. Unfortunately, it's very *teddious*!
By the way, OUAT I had fun for days drawing diagrams of a CPU with
basic blocs such as registers, demultiplexers and gates in a program
that could simulate it, and I reached the point where it could decode
a few instructions. Very funny. But I'd never do it twice, and I'd
rather *write* the design for a CPU than draw it anytime!
> But a diagram is 2D, so it would be difficult to represent it as
> a readable piece of text. And why should one want to do it? When drawing
> a construction diagram for a bridge, there is no need for the engineer to
> view it as a textual list of lines and points (only for production,
> perhaps).
>
> And of course, once you have implemented the base system in Lisp, you can
> draw the system with the system itself and you don't need Lisp anymore.
Perhaps it's time to stop and read:
http://www.idlewords.com/2005/04/dabblers_and_blowhards.htm
--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.
"Takuon Soho" <···@somwhere.net> writes:
> A pipe dream then? Perhaps.
Most probably IMO. But keep thinking about it, you might find a way.
Since the very beginnings of programming, people have tried to
"visualize" programs (starting with flow charts and on with various
kind of graphical programming languages, up to UML). This never
resulted. I think the reason why, is that programming is not like
building a model of a bridge with matches and glue (what is
essentially done with CAD).
It's like designing the ADN for a complex organism. God is Verb, not
Picture! There are several layers between the source code (ADN) and
the target result (phenotype), and not all are embedded totally in the
source code (or ADN) either: input data (environment) influences too.
Now, perhaps if we had multidimensional visual capability, we could
draw a hyper picture in N dimensions (with N _big_), in which we could
represent the whole complexity of a non trivial program, in a useful
way. But we only have 2D visual or at most 3D conceptual, so any
projection will be overwhelming complex and inintelligible.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The mighty hunter
Returns with gifts of plump birds,
Your foot just squashed one.
Pascal Bourguignon <····@mouse-potato.com> wrote:
> It's like designing the ADN for a complex organism. God is Verb, not
> Picture! There are several layers between the source code (ADN) and
> the target result (phenotype), and not all are embedded totally in the
> source code (or ADN) either: input data (environment) influences too.
with ADN you mean DNA? For me the DNA is like the assembler language
level. If you have too much time, it is possible to write program at this
level, like the evolution does with DNA, but I think it is possible to
design a useful 2D graphical "language", which then maybe is compiled to
assembler or even to a gate configuration for a FPGA. But currently I
don't know, how the basic building blocks would look like and Lisp is the
best language for me.
> Now, perhaps if we had multidimensional visual capability, we could
> draw a hyper picture in N dimensions (with N _big_), in which we could
> represent the whole complexity of a non trivial program, in a useful
> way. But we only have 2D visual or at most 3D conceptual, so any
> projection will be overwhelming complex and inintelligible.
In Lisp functions are small, if well written. And in a 2D representation
you would design like in modern electronic schematic programs: You build
blocks with a well defined interface and build larger blocks with these
blocks, but every block is small and you should see immediatly how it
works. And perhaps there might be something like defmacro in Lisp: For
example if you need something like a data bus (for reading some data
stream), you could build some special symbols, which can be used in the
diagrams like macros in Lisp code.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss <··@frank-buss.de> writes:
> Pascal Bourguignon <····@mouse-potato.com> wrote:
>
> > It's like designing the ADN for a complex organism.
>
> with ADN you mean DNA?
Yes, sorry. ADN is French for DNA.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Cats meow out of angst
"Thumbs! If only we had thumbs!
We could break so much!"
Complex, yes.
But I am not talking about mere flowcharts or UML's,
it is something much more.
Our minds evolved in the open and the power of
3d visualization must not be discounted as opposed
to the artifciality of symbols. Othewise, as was mentioned,
architects would just routinely give a set of abstract specifications
to the builder with no blueprints.
The breakthrough would have to come in some grey area of
research on the borderline between discrete mathematics and,
perhaps, topology or fractal research.
And yes, the big weakness is that algorithms are not naturally 3d - they
can be considered to be, if such a representation were possible, of
multiple dimensions which we cannot grok geometrically.
Meanwhile, in my spare time, back to Langlet!
His "pariton" data structures and their representation by Serpinski
fractals opens a door and if nobody else wants to walk in
the dark and stumbole about, I will.
OK, this is not about Lisp and anyway,
I have to put up or shut up and until someday I have
time to pursue this it is the latter.
Thanks
Tak (Jim)
"Pascal Bourguignon" <····@mouse-potato.com> wrote in message
···················@thalassa.informatimago.com...
> "Takuon Soho" <···@somwhere.net> writes:
>> A pipe dream then? Perhaps.
>
> Most probably IMO. But keep thinking about it, you might find a way.
>
> Since the very beginnings of programming, people have tried to
> "visualize" programs (starting with flow charts and on with various
> kind of graphical programming languages, up to UML). This never
> resulted. I think the reason why, is that programming is not like
> building a model of a bridge with matches and glue (what is
> essentially done with CAD).
>
> It's like designing the ADN for a complex organism. God is Verb, not
> Picture! There are several layers between the source code (ADN) and
> the target result (phenotype), and not all are embedded totally in the
> source code (or ADN) either: input data (environment) influences too.
>
> Now, perhaps if we had multidimensional visual capability, we could
> draw a hyper picture in N dimensions (with N _big_), in which we could
> represent the whole complexity of a non trivial program, in a useful
> way. But we only have 2D visual or at most 3D conceptual, so any
> projection will be overwhelming complex and inintelligible.
>
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
> The mighty hunter
> Returns with gifts of plump birds,
> Your foot just squashed one.
"Takuon Soho" <···@somwhere.net> writes:
> Complex, yes.
>
> But I am not talking about mere flowcharts or UML's,
> it is something much more.
>
> Our minds evolved in the open and the power of
> 3d visualization must not be discounted as opposed
> to the artifciality of symbols. Othewise, as was mentioned,
> architects would just routinely give a set of abstract specifications
> to the builder with no blueprints.
Really, you should beware of such analogies. The job of an architect
is to design something that will be *seen*. How do you see a program?
What need do you have to *see* a program? You're forced to see a
bridge or a building, by essence of the objet. But programs are
spiritual in nature. Much harder to see. Anyway, their symbolic
properties are what import, not their look.
> The breakthrough would have to come in some grey area of
> research on the borderline between discrete mathematics and,
> perhaps, topology or fractal research.
Yes, topology might be useful. But a forest is a simple environment
compared to the kind of topology you'd need to represent a non-trivial
program. So the question is whether our brains designed for forests
will be able to manage more complex topologies?
Just watch people playing asteroids (or better, Void.app, eg a 3D
asteroid). Very few people _use_ the tore properties of their
environment...
> And yes, the big weakness is that algorithms are not naturally 3d - they
> can be considered to be, if such a representation were possible, of
> multiple dimensions which we cannot grok geometrically.
>
> Meanwhile, in my spare time, back to Langlet!
> His "pariton" data structures and their representation by Serpinski
> fractals opens a door and if nobody else wants to walk in
> the dark and stumbole about, I will.
>
> OK, this is not about Lisp and anyway,
> I have to put up or shut up and until someday I have
> time to pursue this it is the latter.
I can only encourage you to progress in this direction. My bet is
that it won't really be useful for programming, but it'll give nice
games. Have a look at experiments in "GUI", for example, applications
where the directory hierarchy is represented as galaxies and solar
systems, or other "games" with various 3D or "dunjon" representations
of the data. (And you'll see why we don't use them for day to day
operations ;-) And of course: http://www.opencroquet.org
Another question you might explore is that of the input. You can
display complex 3D environments, but without virtual reality input
devices, it's hard to navigate in them. And the problem with current
VR input devices is that you need to be a body builder to work in them
8 hours a day (Watch Johnny Mnemonic). So it's put off until we have
OTS Matrix like interfaces.
--
__Pascal Bourguignon__ http://www.informatimago.com/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d? s++:++ a+ C+++ UL++++ P--- L+++ E+++ W++ N+++ o-- K- w---
O- M++ V PS PE++ Y++ PGP t+ 5+ X++ R !tv b+++ DI++++ D++
G e+++ h+ r-- z?
------END GEEK CODE BLOCK------
On 13 Apr 2005 00:53:22 +0200, <····@mouse-potato.com> wrote:
> Yes, topology might be useful. But a forest is a simple environment
> compared to the kind of topology you'd need to represent a non-trivial
> program. So the question is whether our brains designed for forests
> will be able to manage more complex topologies?
>
> Just watch people playing asteroids (or better, Void.app, eg a 3D
> asteroid). Very few people _use_ the tore properties of their
> environment...
OT: the real wizards do, and the usual distribution statistics
guarantee that there are very few wizards. Brains are extensible too,
so a more complex topology requires a bit more training to manage.
--
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.
On Wed, 13 Apr 2005 00:53:22 +0200, Pascal Bourguignon wrote:
> Just watch people playing asteroids (or better, Void.app, eg a 3D
> asteroid). Very few people _use_ the tore properties of their
> environment...
Descent 3
BR <··········@comcast.net> writes:
> On Wed, 13 Apr 2005 00:53:22 +0200, Pascal Bourguignon wrote:
>
>
> > Just watch people playing asteroids (or better, Void.app, eg a 3D
> > asteroid). Very few people _use_ the tore properties of their
> > environment...
>
> Descent 3
Yes, if we could kill bugs as we kill enemies in Decent... :-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
Litter box not here.
You must have moved it again.
I'll poop in the sink.
"jonathon" <···········@bigfoot.com> schrieb im Newsbeitrag
·····························@f14g2000cwb.googlegroups.com...
...
> Does anyone have any ideas on how to avoid this trap?
Especially in your situation I'd recommend starting with Peter's book.
Andreas
"jonathon" <···········@bigfoot.com> writes:
> Here's my situation...
>
> After dismissing Lisp as arcane and/or irrelevant a year ago because I
> found Python, I decided to give Lisp another shot recently. I'd love
> to learn it well and start using it, but I'm not sure what the best
> book is to start with. I'm not even sure it's what I need for my
> programming problems. I really like PCL and I plan to buy it, but
> probably after the PG book. I don't know how to get around this. I
> can't seem to jump from most Lisp books into working code. I feel like
> I'll be writing C or C++ in Lisp. And that's not what I want to do.
>
> Does anyone have any ideas on how to avoid this trap?
As another 'newbie', I know exactly what you mean. My first lisp stuff
often looked like what it was - a programmer who had learnt C -> C++
-> Java -> perl. I often did things like
(defun foo ()
(if (some-test)
(progn
(......)
(.....)
.....))
(progn
(....)
(....)
....))))
I remember having similar difficulties moving to a new paradigm when I
learnt prolog.
Anyway, I realised one of my problems was the way I was approaching
the whole design and coding process. I'd gotten very use to designing
in a top down manner and then building from the bottom up. I was also
writing 'procedures' rather than functions and relying on side-effects
when it wasn't necessary.
For me (and everyone's mileage will differ) I had to break this habit
and combine the design and building together and adopt what I'd call a
code and refine approach. I actually start by trying to code the
problem as I'm thinking about it - I don't have these two distinct
design and coding stages, but instead do it all together. I keep my
functions small and restrict them to doing just one 'main' thing. When
I see lots of code reptition, I either create some functions or
possibly a macro.
I'm now beginning to feel that my code is more Lisp like and I've
noticed I'm beginning to change the way I code in other languages -
especially perl (I don't do much C or Java and hope I NEVER EVER have
to do C++ again!). I think my non-Lisp code may be improving as it
seems to be easier to read and see what is going on.
One thing I do beleive is that you just have to get in and give it a
go - don't expect anything other than your first efforts to be C or
C++ in Lisp - I think its like that for everyone who has come to Lisp
after first learning other languages. However, I think after a while,
the penny sort of drops and you start doing things a bit diffeently
and when you look at your code, you notice its beginning to look more
like what other people write.
Of course, being a newbie, I may just have it all wrong. I recently
sent some of my code to a friend who is an experienced Lisp programmer
who loves CL. I'm waiting for his feedback and expect he will have
some pretty critical comments to make - I tink this is important as
few of us can learn in a vacum.
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
Peter Seibel <·····@gigamonkeys.com> writes:
[...]
> If you want to help out, think about whether there's anything you
> can do now so that come Monday morning, when Joe and Josephine
> Nonlisper roll into work and fire up their browsers and/or email
> clients, there'll be something that makes them say, "Holy cow!
> There's a new Lisp book out. And people seem excited about it. Maybe
> Lisp isn't as dead as I thought. I should check it out."
An obvious thing would be a story in slashdot. The story might just
be to point to the relatively good sales, and O'Reilly's policy of not
wanting to do any books on lisp (so you'd want URL's for both).
That's not a very strong story, but it's not uninteresting. Anyway,
<http://humorix.org/articles/2005/04/slashdot-editors/>.
[...]
From: Hrvoje Blazevic
Subject: Re: The Amazon PCL tide may be heading back out to sea
Date:
Message-ID: <d3carc$1h5$1@ss405.t-com.hr>
Peter Seibel wrote:
> After hitting a high-water mark of Sales Rank #543 last night, the
> tide of PCL sales on Amazon seems to be subsiding somewhat. Which is
> not to say it's doing too badly--it's still at #1317 and a few days
> ago I was thrilled when it broke <5,000.
>
Well, I completed the purchase an hour ago, and it showed #1099.
-- Hrvoje
Peter Seibel wrote:
> After hitting a high-water mark of Sales Rank #543 last night, the
> tide of PCL sales on Amazon seems to be subsiding somewhat. Which is
> not to say it's doing too badly--it's still at #1317 and a few days
> ago I was thrilled when it broke <5,000.
Barnes & Noble updated my estimated ship date to May 11. I cancelled
it and tried Amazon. They're saying April 18 -- but only because I
chose the "no shipping fees" option. When I tried "next day" they said
tomorrow (April 13).
> I imagine by now all Lispers tuned into the normal Lisp channels
> (c.l.l., #lisp, the Lisp blogs) have heard about the book and--based
> on the past few days excitement--many of them have bought it. My next
> challenge is to see if I can get the word out to the merely
> Lisp-curious.
I emailed a few co-workers. One of them playfully suggested I get my
head examined; one said "I juth with that I had more time to thpend on
fun thubjecths inthead of thtupid uther requeths." :) I told him he
"jutht needth thmarter utherth".
I'm currently evangelizing Test Driven Development and Automated Unit
Testing to a large C++ project. Maybe later I can do a Lisp
presentation. (This group's product is (in)famous for late-night
outage conference calls. I think they'd like the "debug and patch a
running executable".)
-- Larry
Larry Clapp wrote:
> Peter Seibel wrote:
>
>>After hitting a high-water mark of Sales Rank #543 last night, the
>>tide of PCL sales on Amazon seems to be subsiding somewhat. Which is
>>not to say it's doing too badly--it's still at #1317 and a few days
>>ago I was thrilled when it broke <5,000.
>
>
> Barnes & Noble updated my estimated ship date to May 11. I cancelled
> it and tried Amazon. They're saying April 18 -- but only because I
> chose the "no shipping fees" option. When I tried "next day" they said
> tomorrow (April 13).
I ordered it from Amazon over the weekend using the lowest cost shipping
option (US Postal Service). They shipped it monday anyway, and it's
being shipped from a fulfillment center in my state (Illinois), so
it should arrive quickly.
Paul
In article <························@l41g2000cwc.googlegroups.com>, I wrote:
> I emailed a few co-workers. One of them playfully suggested I get
> my head examined; one said "I juth with that I had more time to
> thpend on fun thubjecths inthead of thtupid uther requeths." :) I
> told him he "jutht needth thmarter utherth".
... And one of the others, I found out later, looked over a few
chapters, decided to order it, and came over and talked to me about
doing a proof-of-concept for the large C++ project I mentioned, and
wondered if clisp can talk to Informix[1]?
Hey, Peter, I may've made you a sale! :)
> I'm currently evangelizing Test Driven Development and Automated
> Unit Testing to a large C++ project. Maybe later I can do a Lisp
> presentation. (This group's product is (in)famous for late-night
> outage conference calls. I think they'd like the "debug and patch a
> running executable".)
-- Larry
[1] The project in question runs on AIX. I havn't seen any $free$
implementations (even for trial use) that run on AIX other than clisp.
If my friend actually makes a go of it, maybe we can approach Franz or
LispWorks for a trial version with odbc support, or something.
Larry Clapp <·····@theclapp.org> writes:
> [1] The project in question runs on AIX. I havn't seen any $free$
> implementations (even for trial use) that run on AIX other than clisp.
> If my friend actually makes a go of it, maybe we can approach Franz or
> LispWorks for a trial version with odbc support, or something.
Just a wild guess: isn't AIX running on a PowerPC processor? Then
wouldn't OpenMCL be able to work (to be ported easily) on AIX too?
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
From: David Steuber
Subject: Re: The Amazon PCL tide may be heading back out to sea
Date:
Message-ID: <873btv1cuk.fsf@david-steuber.com>
Pascal Bourguignon <····@mouse-potato.com> writes:
> Just a wild guess: isn't AIX running on a PowerPC processor? Then
> wouldn't OpenMCL be able to work (to be ported easily) on AIX too?
If you are correct about AIX running on a PPC compatible processor
(I'm pretty sure the RS-6000 line did), then that would be an
interesting question to bring up on the OpenMCL-Devel list. My guess
is that porting wouldn't be super trivial even though OpenMCL runs
both Darwin and Linux. I could be wrong of course. But I recently
had a question about building OpenMCL from the CVS source because
0.14.3-50328 required bootstrapping. I had to download an image from
clozure's ftp server. There was no way to build the CVS sources with
0.14.3.
It may be easier to port SBCL but you won't get native threads. If I
understand the threading situation for PPC propertly, the generational
gc needs to be ported.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
In article <··············@thalassa.informatimago.com>, Pascal
Bourguignon wrote:
>
> Larry Clapp <·····@theclapp.org> writes:
>> [1] The project in question runs on AIX. I havn't seen any $free$
>> implementations (even for trial use) that run on AIX other than
>> clisp. If my friend actually makes a go of it, maybe we can
>> approach Franz or LispWorks for a trial version with odbc support,
>> or something.
>
> Just a wild guess: isn't AIX running on a PowerPC processor? Then
> wouldn't OpenMCL be able to work (to be ported easily) on AIX too?
Dunno. If we get that far, I'll keep OpenMCL in mind. Thanks for the
pointer, er, reference.
-- Larry
From: Peter Seibel
Subject: Re: The Amazon PCL tide may be heading back out to sea
Date:
Message-ID: <m3mzs0udbv.fsf@gigamonkeys.com>
Larry Clapp <·····@theclapp.org> writes:
> In article <························@l41g2000cwc.googlegroups.com>, I wrote:
>> I emailed a few co-workers. One of them playfully suggested I get
>> my head examined; one said "I juth with that I had more time to
>> thpend on fun thubjecths inthead of thtupid uther requeths." :) I
>> told him he "jutht needth thmarter utherth".
>
> ... And one of the others, I found out later, looked over a few
> chapters, decided to order it, and came over and talked to me about
> doing a proof-of-concept for the large C++ project I mentioned, and
> wondered if clisp can talk to Informix[1]?
>
> Hey, Peter, I may've made you a sale! :)
Excellent. Thanks!
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp