Where do people feel Lisp is going? How will popularity change? Is
Lisp threatened by upstarts like Python? Will Lisp become more
acceptable for general application development? Etc...
········@myrealbox.com (Nepheles) writes:
> Where do people feel Lisp is going? How will popularity change? Is
> Lisp threatened by upstarts like Python? Will Lisp become more
> acceptable for general application development? Etc...
My feeling is that in 50 years, there will still be Lisp programmers
and developments using Lisp. But by contrast, perl and python will
not be remembered. (Do you remember autocoder?)
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Pascal Bourguignon wrote:
> ········@myrealbox.com (Nepheles) writes:
>
>> Where do people feel Lisp is going? How will popularity change? Is
>> Lisp threatened by upstarts like Python? Will Lisp become more
>> acceptable for general application development? Etc...
>
> My feeling is that in 50 years, there will still be Lisp programmers
> and developments using Lisp. But by contrast, perl and python will
> not be remembered. (Do you remember autocoder?)
>
I certainly agree with you about Lisp being well-used in the future. I'm
still a Lisp newbie, but I recognize a timeless beauty in Lisp. Lisp's
fundamental notions about what it means to compute something are not going
to change. The syntax is so minimal, there isn't anything TO change there.
Okay, maybe some of the dialect changes, with people playing around with
CL, Scheme, Arc, etc., but the basics are all pretty similar.
Dave Roberts <·····@re-move.droberts.com> writes:
> I certainly agree with you about Lisp being well-used in the future. I'm
> still a Lisp newbie, but I recognize a timeless beauty in Lisp. Lisp's
> fundamental notions about what it means to compute something are not going
> to change. The syntax is so minimal, there isn't anything TO change there.
> Okay, maybe some of the dialect changes, with people playing around with
> CL, Scheme, Arc, etc., but the basics are all pretty similar.
http://www.songworm.com/lyrics/songworm-parody/EternalFlame.html
Dave Roberts wrote:
>
> Pascal Bourguignon wrote:
>
> > ········@myrealbox.com (Nepheles) writes:
> >
> >> Where do people feel Lisp is going? How will popularity change? Is
> >> Lisp threatened by upstarts like Python? Will Lisp become more
> >> acceptable for general application development? Etc...
> >
> > My feeling is that in 50 years, there will still be Lisp programmers
> > and developments using Lisp. But by contrast, perl and python will
> > not be remembered. (Do you remember autocoder?)
> >
>
> I certainly agree with you about Lisp being well-used in the future. I'm
> still a Lisp newbie, but I recognize a timeless beauty in Lisp. Lisp's
> fundamental notions about what it means to compute something are not going
> to change. The syntax is so minimal, there isn't anything TO change there.
<pounce>
get ye to http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
I can see you are headed for the Aesthetes subcategory on the highlight
film:
http://alu.cliki.net/RtL%20Highlight%20Film
<g>
</pounce>
btw, gang, I just checked the recent changes page and it is empty. Is
this another bit of bit rot?
kenny
--
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Kenny Tilton wrote:
> <pounce>
> get ye to http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Already been there, read it. ;-) Just haven't put in my own story as I
haven't yet decided whether I have finally "made the switch" yet.
> I can see you are headed for the Aesthetes subcategory on the highlight
> film:
>
> http://alu.cliki.net/RtL%20Highlight%20Film
>
> <g>
Yup. That's probably where I'll end up.
-- Dave
On 2004-01-25 12:49:42, Nepheles wrote:
> Where do people feel Lisp is going? How will popularity change?
(Common) Lisp has a healthy and living community. Take a look at
<http://www.cliki.net/index> and visit #lisp on FreeNode (IRC).
Popularity will rise. The free Lisps will gain more and more "market
share".
People will realize what Paul Graham is saying for quite some time:
You control the server. You can choose whatever language fits best
for your task.
> Is Lisp threatened by upstarts like Python?
I'd rather program in Ruby. But I use Python tools every day, due to
Gentoo Linux.
Languages can coexist. We live in the exciting time of open
interfaces, protocols, and multi platform development. The PHP page
calls a Common Lisp server process via XML-RPC, which gathers some
data with SQL and triggers a batch job in Perl. Think of any
combination you want.
········@myrealbox.com (Nepheles) writes:
> Where do people feel Lisp is going?
I think it is waiting for everyone else to catch up.
I'm guessing, however, that the most likely extensions to Lisp would
come in the form of some sort of unobtrusive static analysis.
> How will popularity change?
> Is Lisp threatened by upstarts like Python?
Hah.
> Will Lisp become more acceptable for general application
> development? Etc...
Once the demand for crappy software goes down a bit.
--
~jrm
Nepheles wrote:
>
> Where do people feel Lisp is going? How will popularity change? Is
> Lisp threatened by upstarts like Python? Will Lisp become more
> acceptable for general application development? Etc...
Lisp isn't going anywhere. If any of these other languages becomes
able to "threaten" Lisp's place, it will be because that other language
has become a lisp.
Common Lisp will pass away in time; Scheme too, will disappear. Elisp
is changing now, I hear, into something else. But there will always
be languages with a syntax based on balanced delimiters and an
isomorphism between code and data that allows macros, which are garbage
collected, capable of handling its program code as data, and have
runtime expression evaluation, anonymous functions, and recursion.
And by whatever name or whatever derivation, those languages will be
Lisps.
Lisp is a kind of "local optimum" of expressiveness in programming
languages. No matter where you start, if you keep making your
language more expressive, you eventually wind up with Lisp.
There are other axes for optimization, of course; Python sacrifices
some expressiveness (not very much, but some) for assurances of type
correctness. A Python programmer will loudly say he doesn't want
the ability to express things that aren't type safe, but there will
always be people who want maximum expressiveness, and so there will
always be Lisp.
Bear
On Sun, 25 Jan 2004 18:44:32 +0000, Ray Dillinger wrote:
> Elisp
> is changing now, I hear, into something else.
Can I read about this somewhere? Or can you give us some hints as to how
Elisp is changing?
TIA,
--
jb
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
jblazi wrote:
>
> On Sun, 25 Jan 2004 18:44:32 +0000, Ray Dillinger wrote:
>
> > Elisp
> > is changing now, I hear, into something else.
>
> Can I read about this somewhere? Or can you give us some hints as to how
> Elisp is changing?
>
Uh, this was mentioned in passing in a F2F conversation which I only
remember vaguely, but the noise I heard was about rewriting elisp to
use lexical rather than dynamic scope as its default binding discipline,
and corresponding changes in emacs' underlying codebase of course.
Bear
Ray Dillinger <····@sonic.net> writes:
> jblazi wrote:
>>
>> On Sun, 25 Jan 2004 18:44:32 +0000, Ray Dillinger wrote:
>>
>> > Elisp
>> > is changing now, I hear, into something else.
>>
>> Can I read about this somewhere? Or can you give us some hints as to how
>> Elisp is changing?
>>
>
> Uh, this was mentioned in passing in a F2F conversation which I only
> remember vaguely, but the noise I heard was about rewriting elisp to
> use lexical rather than dynamic scope as its default binding discipline,
> and corresponding changes in emacs' underlying codebase of course.
[...]
Miles Bader is working on this branch. It is called ‘lexbind’ in the
Emacs CVS. AFAIK dynamic scope will stay the default, unless a
buffer-local variable (buffer-local to the to-be-compiled source code)
is set to t.
Oliver
--
11 Pluviôse an 212 de la Révolution
Liberté, Egalité, Fraternité!
Nepheles wrote:
>
> Where do people feel Lisp is going?
Lisp is going to take over the world.
> How will popularity change?
By what mechanism? Word of mouth. Paul Graham jumpstarted the process.
> Is Lisp threatened by upstarts like Python?
Python and other upstarts help by fomenting rebellion against C++ and
Java; by introducing Lisp concepts to their users and showing what
development can be like; and by falling short of Lisp, so eventually
they will change to Lisp.
> Will Lisp become more acceptable for general application development? Etc...
Yep. See "take over the world".
kenny
--
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
>>>>> "Kenny" == Kenny Tilton <·······@nyc.rr.com> writes:
>> Is Lisp threatened by upstarts like Python?
Kenny> Python and other upstarts help by fomenting rebellion
Kenny> against C++ and Java; by introducing Lisp concepts to their
Kenny> users and showing what development can be like; and by
Kenny> falling short of Lisp, so eventually they will change to
Kenny> Lisp.
As a Pythonista, I felt like chipping in here.
It's true that languages like Python introduce Lisp concepts like
dynamic typing and first class functions, and people learn to
appreciate them.
However, they also reduce the astonishment people get when they check
out Lisp. Lisp is not all *that* special. I've been reading On Lisp,
trying to get excited about the language. However, while the book may
impress a C++ programmer, I have to say I'm not particularly
impressed. Most of the stuff I like about Lisp is available in Python,
in a more accessible fashion (I know that standard response for the
newsgroup might be "that's because you suck/are stupid", so if that's
your reaction, you can as well save your breath).
Also, Lisp mostly impressed me initially because it was simple and
orthogonal. Reading On Lisp kinda crushed that illusion for me -
Common Lisp is not simple. Lisp might become more attractive for
newbies if there was something better on the table. CL might be
tried-and-true, but it's not really all that exciting. It's too
verbose (esp. CLOS) and complicated. I imagine an energetic Open
Source group could do lots of good things for Lisp, including a
partial redesign (Arc is still vaporware).
It wouldn't hurt to get cmucl (or other CL implementation) into
Fedora, either. Write some interesting libraries, demonstrate people
how easy they are to use (I checked out Python after seeing how easy
CORBA was there), make scripting tasks easy, lose the "FP is the way
to go" attitude, it mostly serves to turn people away from the
language. Make easy things easy. Implement a simpler, less powerful
standard object system (as opposed to telling people to implement
their own or use CLOS).
As it stands, I can easily advocate Python to my colleagues, confident
that they will love it if they just take a few hours to epxlore
it. However, I can't realistically expect them to take a brief look at
Lisp and love it. Some of them (including yours truly) learned Scheme
at school, and forgot the language immediately after the course. It
wasn't used in the "real world", and wasn't fun enough to use in own
projects. Blame it on pedagogics, but if the course taught Python, it
would have required an extraordinarily crappy teacher to make me not
want to use the language after the course.
Please don't take this as a contribution to a language flamewar - I
wish Lisp all the best, and will probably continue using it in a form
of elisp, perhaps even start a toy project in CL (once I get a good CL
for Fedora). Just wanted to point out that the superiority of Lisp is
not so clear as to make Pythonistas drop Python and start doing Lisp
instead. Many Pythonistas are flirting with Lisp, but so far I haven't
seen any significant migration taking place.
--
Ville Vainio http://tinyurl.com/2prnb
Ville Vainio wrote:
>
> >>>>> "Kenny" == Kenny Tilton <·······@nyc.rr.com> writes:
>
> >> Is Lisp threatened by upstarts like Python?
>
> Kenny> Python and other upstarts help by fomenting rebellion
> Kenny> against C++ and Java; by introducing Lisp concepts to their
> Kenny> users and showing what development can be like; and by
> Kenny> falling short of Lisp, so eventually they will change to
> Kenny> Lisp.
>
> As a Pythonista, I felt like chipping in here.
Thx for a detailed, thoughtful chip-in.
I would be interested in your impressions afterwards should you in fact
undertake a toy project, hopefully not too toy.
I know what you mean about verbose, but then I was one of the folks
delighted to see languages start allowing 30-character variable names.
You know, typing speed is certainly not a constraint on software
development.
As for CLOS, whoa, what's not to like? Possibly you don't care much for
OO? I think I use every feature CLOS offers, so it seems perfect to me.
> Many Pythonistas are flirting with Lisp, ...
cool.
> ...but so far I haven't
> seen any significant migration taking place.
Well, Pythonistas in my experience are pretty happy with their language,
and one thing they seem high on is all the libraries available to make
quick results possible. To a degree then its charm is as a scripting
language on steroids. The one thing CL lacks is libs off the shelf. So
altogether I would expect the migration to be quite slow. Hopefully
certain Pythonistas will turn out to be language junkies and go looking
for the mother lode (CL) and decide they would rather help build FFI
bridges to C libs than go back to a lesser language.
Me, I just added FTGL /and/ ImageMagick to Cello over the past two
weeks, so obviously it is not that big a deal. (But Cello is starting to
be. <g>)
kenny
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Kenny Tilton wrote:
>
> Me, I just added FTGL /and/ ImageMagick to Cello over the past two
> weeks, so obviously it is not that big a deal. (But Cello is starting
> to be. <g>)
>
By the way how can we go about trying Cello? Just curious as I loved cells
(and no I haven't used cells for anything yet but as soon as I start a new
project I will - I just don't have the time to reimplement my current
stuff).
rmagere wrote:
>
> Kenny Tilton wrote:
> >
> > Me, I just added FTGL /and/ ImageMagick to Cello over the past two
> > weeks, so obviously it is not that big a deal. (But Cello is starting
> > to be. <g>)
> >
>
> By the way how can we go about trying Cello? Just curious as I loved cells
> (and no I haven't used cells for anything yet but as soon as I start a new
> project I will - I just don't have the time to reimplement my current
> stuff).
Any day now (two weeks?). Watch this space. I want to wait for an X11
version, and Mr. Burdick is handling the port, with emphasis on
CMUCL/SBCL. I have another X11 porter in the wings who wants to give it
a go under ACL trial. Thomas is keen on an OS X version as am I, so
something or other over there should happen in short order.
The holdup has been callbacks into Lisp from C, which commercial Lisps
handle OK on Linux/OS X, so if all else fails I'll get Cello working on
X11/OS X under commercial apps and forget the free guys exist. But
things sound very good on the free CL callbacks, so that should not
happen.
I am prepping a Cello tutorial on the win32 platform for Feb 9 in
Boulder, so I'll be polishing the interfaces to FTGL and ImageMagick
(they both are still at the level of elegance known as "just jam it in
to see if it works"). I also have to start tossing off/fixing the
standard widget set (sliders, scroll bars, list/tree views, tab
controls, etc etc), though I have enough now for a tutorial.
One holdup could be that Cello, with FTGL and ImageMagick, now has an
insanely higher level of graphical power, meaning the GUI has to be
extended to provide hooks for all that power. A simple example is that
widgets need Z positions as well as near and far bounds now that we are
in a 3D GUI. Another is that I/M means a whole new wrapper with options
for everything you can do in Photshop (blur, noise, crop, colorize, etc
etc etc). But I will try not to let that upgrade delay Cello.
Hey, I am still looking for a starter app. With ImageMagick I am tempted
to do cl-photoshop. But what's all this I here about the CLIM listener?
What's the feature set with that? I gather the REPL does not just Print,
it provides a graphical display of the output? And?
Of course I could always try to replicate the CLIM address book....
:)
kenny
In article <················@nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> Any day now (two weeks?). Watch this space. I want to wait for an X11
> version, and Mr. Burdick is handling the port, with emphasis on
> CMUCL/SBCL. I have another X11 porter in the wings who wants to give it
> a go under ACL trial. Thomas is keen on an OS X version as am I, so
> something or other over there should happen in short order.
>
> The holdup has been callbacks into Lisp from C, which commercial Lisps
> handle OK on Linux/OS X, so if all else fails I'll get Cello working on
> X11/OS X under commercial apps and forget the free guys exist. But
> things sound very good on the free CL callbacks, so that should not
> happen.
Hey hey! OpenMCL does have working callbacks. Please don't leave this
out.
> Hey, I am still looking for a starter app. With ImageMagick I am tempted
> to do cl-photoshop. But what's all this I here about the CLIM listener?
> What's the feature set with that? I gather the REPL does not just Print,
> it provides a graphical display of the output? And?
CLIM being a presentation-based display system, you can define
presentations for any different class in the output. You also get a
free graphical inspector which you can use to inspect slot values.
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
Brian Mastenbrook <··············@cs.indiana.edu> writes:
> In article <················@nyc.rr.com>, Kenny Tilton
> <·······@nyc.rr.com> wrote:
>
> > Any day now (two weeks?). Watch this space. I want to wait for an X11
> > version, and Mr. Burdick is handling the port, with emphasis on
> > CMUCL/SBCL. I have another X11 porter in the wings who wants to give it
> > a go under ACL trial. Thomas is keen on an OS X version as am I, so
> > something or other over there should happen in short order.
> >
> > The holdup has been callbacks into Lisp from C, which commercial Lisps
> > handle OK on Linux/OS X, so if all else fails I'll get Cello working on
> > X11/OS X under commercial apps and forget the free guys exist. But
> > things sound very good on the free CL callbacks, so that should not
> > happen.
>
> Hey hey! OpenMCL does have working callbacks. Please don't leave this
> out.
Being as I'm The Guy With The Mac who's porting to SBCL, I intend to
get it up on OpenMCL, too, which shouldn't be hard. But my home is
SBCL/Darwin and CMUCL/Solaris, so those are my priority. That and
merging with Kenny's tree with all the hella features he's added
recently.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Brian Mastenbrook wrote:
> CLIM being a presentation-based display system, you can define
> presentations for any different class in the output.
Sounds like a GF specialized on the class and <something else> such as
the container or a stream or even just a key value such as :clim-repl as
long the lisp supports eql specializers. What's all the shouting about
in re presentation types? I gotta be missing something (nothing new
about that).
> You also get a
> free graphical inspector which you can use to inspect slot values.
Done. Code-name ClouCell. And any cell-mediated slot changes as you
watch if the value changes (no explicit "reload" necessary). In fact I
am now working on a cyclic dependency: if instance being viewed is the
window and the display of the window's mouse-image slot is the
mouse-image (image under the mouse), the function which wants to know if
the image is under the mouse asks the dimensions of the image, and that
depends on the text being displayed, and that depends on what image is
under the mouse, since the text is a description of that.
I love it. I think I'll just give the text widget a fixed size and get
on with my life. The funny thing is I was crafty enough not to make the
mouse-image dependent on the geometry of every widget on the screen
(meaning it would /not/ notice if some image moved under the mouse, as
it should, but that would take a deeper fix), but the calculation itself
still loops back.
I love this game!* :)
kenny
* Advertising slogan for NBA basketball
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
In article <·················@nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> Brian Mastenbrook wrote:
> > CLIM being a presentation-based display system, you can define
> > presentations for any different class in the output.
>
> Sounds like a GF specialized on the class and <something else> such as
> the container or a stream or even just a key value such as :clim-repl as
> long the lisp supports eql specializers. What's all the shouting about
> in re presentation types? I gotta be missing something (nothing new
> about that).
Pretty close, except usually the presentation describes the object in
such a fashion as it can easily be made into HTML or PostScript too.
Not a big deal, just a certain degree of independence from the concept
of "interactive GUI". With a bit of work you could probably do the same
thing to Cello... if it exists. I haven't seen any evidence of that yet
:-)
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
Brian Mastenbrook wrote:
>
> In article <·················@nyc.rr.com>, Kenny Tilton
> <·······@nyc.rr.com> wrote:
>
> > Brian Mastenbrook wrote:
> > > CLIM being a presentation-based display system, you can define
> > > presentations for any different class in the output.
> >
> > Sounds like a GF specialized on the class and <something else> such as
> > the container or a stream or even just a key value such as :clim-repl as
> > long the lisp supports eql specializers. What's all the shouting about
> > in re presentation types? I gotta be missing something (nothing new
> > about that).
>
> Pretty close, except usually the presentation describes the object in
> such a fashion as it can easily be made into HTML or PostScript too.
Oh, OK, that does sound interesting ie more substantial than I thought.
If you mean they came up with an abstract presentation protocol which
can without further contribution from the class in question be
translated to HTML and PostScript.
> Not a big deal, just a certain degree of independence from the concept
> of "interactive GUI". With a bit of work you could probably do the same
> thing to Cello... if it exists. I haven't seen any evidence of that yet
> :-)
Oh ye of little faith! Well, ok, it's still vaporware. I mean, /I/ use
it, but only on win32, and Cello's definition is "a portable Common Lisp
Gui", so no X11 and OS X => no Cello.
And hey, even the win32 reference standard is chaos now because I just
bolted in FTGL and ImageMagick and I have to rethink everything... well,
FTGL is painless, god bless it. But with i/m, well, it's painless, too,
but now I am thinking OpenGL now moves to the background and i/m (or the
open fork (GraphicsMagick?)) becomes the normal graphics toolkit, with
everythng dropping into an OpenGl texture for final rendering. raw
opengl widgets still possible, for those brave enough to go there.
Here's a samplr setback caused by the huge win of I/M (look at this API:
http://www.imagemagick.org/www/api.html -- check out esp. DrawingWand):
I now should resurrect my invalidation scheme, by which widgets get
selectively redrawn. Currently any graphical attribute changing anywhere
posts a GLUT redisplay event and the whole kebash gets re-rendered.
Yikes! With i/m every widget can have it's own pixmap (or I suppose draw
directly to a container's pixmap--these are the things now on the table)
and at redraw time most graphic components just whap their cached pixmap
out to the GPU and only the "invalid" ones re-render thru i/m to regen
the pixels.
But if you have checked the Cello pre-cursors on the t-t site reffed in
my sig, all those use an invalidation scheme, so I just need to dust one
of them off... nah. NIH applies to my own code, too. Rewrite! :)
kenny
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Kenny Tilton <·······@nyc.rr.com> writes:
> If you mean they came up with an abstract presentation protocol which
> can without further contribution from the class in question be
> translated to HTML and PostScript.
You may check the CLIM substrate of CL-HTTP, and another similar use
of CLIM in another project (I don't have a reference handy, but try
googling for "clim html"; I seem to remember it was a chemistry
application, or something related to molecule visualization).
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Paolo Amoroso <·······@mclink.it> writes:
> You may check the CLIM substrate of CL-HTTP, and another similar use
> of CLIM in another project (I don't have a reference handy, but try
> googling for "clim html"; I seem to remember it was a chemistry
> application, or something related to molecule visualization).
Here it is:
CWEST: SRI CLIM to WWW Converter
http://www.ai.sri.com/~pkarp/clim-www/tool.html
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Paolo Amoroso wrote:
>
> Paolo Amoroso <·······@mclink.it> writes:
>
> > You may check the CLIM substrate of CL-HTTP, and another similar use
> > of CLIM in another project (I don't have a reference handy, but try
> > googling for "clim html"; I seem to remember it was a chemistry
> > application, or something related to molecule visualization).
>
> Here it is:
>
> CWEST: SRI CLIM to WWW Converter
> http://www.ai.sri.com/~pkarp/clim-www/tool.html
Thx for this and the other link. CLIM looks kinda complicated, as I had
gathered.
kt
--
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Kenny Tilton <·······@nyc.rr.com> writes:
> CLIM looks kinda complicated, as I had gathered.
As I have said before, CLIM most certainly _is_ complicated. But I do
not agree with the implications that one should therefore not use it,
or even try to learn what it is about.
At the risk of repeating myself, let me point out that such arguments
are similar to the ones we often hear from practitioners of other
programming languages as an excuse for not trying to learn what Lisp
is about. In those situations, we instantly recognize the flaw in the
argument, because we know that Lisp is complicated, but also that
learning Lisp can be a great pleasure and a great time saver in future
programming projects.
--
Robert Strandh
Robert STRANDH wrote:
>
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > CLIM looks kinda complicated, as I had gathered.
>
> As I have said before, CLIM most certainly _is_ complicated. But I do
> not agree with the implications that one should therefore not use it,
> or even try to learn what it is about.
>
> At the risk of repeating myself, let me point out that such arguments
> are similar to the ones we often hear from practitioners of other
> programming languages as an excuse for not trying to learn what Lisp
> is about. In those situations, we instantly recognize the flaw in the
> argument, because we know that Lisp is complicated, but also that
> learning Lisp can be a great pleasure and a great time saver in future
> programming projects.
The last time I said this you did not respond. I'll try again. No, we do
not often hear this, and I should know, I have been spamming c.l.l. for
a while now. We do not hear that Lisp is complicated from anti-lispniks
(we hear Python and Java have scads of libraries), and Lisp does not
have a difficult learning curve. Newbies who actually try Lisp (there
are no anti-Lispniks who have done so) are turning back-flips of joy
within a couple of days. Yes, these back-flips continue for ten years
because they keep on learning new things, albeit at a slower and slower
pace, but this is not at all what I am hearing about the CLIM curve,
which seems to require one to get to the top of K2 before the fun
starts.
Hey, who am I? Let's see the traffic on c.l.l. about CLIM, aside from
when i am trashing it. MCL ships a CLIM, LW ships a CLIM, ACL ships a
CLIM, McCLIM ships a CLIM... traffic zero. What am I missing about this
universal, portable CL GUI? Methinks not much.
Hint: "complicated" is /not/ a compliment.
kt
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Kenny Tilton <·······@nyc.rr.com> writes:
> No, we do not often hear this,
I am not going to do any statistical analysis on this, but I persist
in thinking that whatever the outcome of such an analysis, I would not
use it as a basis of judging the intrinsic value of Common Lisp.
Would you?
> but this is not at all what I am hearing about the CLIM curve,
> which seems to require one to get to the top of K2 before the fun
> starts.
Then do not use it.
> Hey, who am I? Let's see the traffic on c.l.l. about CLIM, aside from
> when i am trashing it. MCL ships a CLIM, LW ships a CLIM, ACL ships a
> CLIM, McCLIM ships a CLIM... traffic zero. What am I missing about this
> universal, portable CL GUI? Methinks not much.
I already pointed out the flaw of this reasoning. Does the fact that
we do not see much traffic about Common Lisp on comp.programming
constitute any credible argument against it? Methinks not. Do you
think it does?
> Hint: "complicated" is /not/ a compliment.
Thanks for pointing this out to me. It is also not an argument
_against_ anything.
--
Robert Strandh
---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------
Kenny Tilton <·······@nyc.rr.com> writes:
> Hey, who am I? Let's see the traffic on c.l.l. about CLIM, aside from
> when i am trashing it. MCL ships a CLIM, LW ships a CLIM, ACL ships a
> CLIM, McCLIM ships a CLIM... traffic zero. What am I missing about this
A possible explanation is suggested by a message posted to the CLIM
mailing list on 13 Feb 1997:
Well, we still use CLIM pretty extensively here at SRI. It's hard
to say why mailing-list traffic has died down. From our point of
view the answer is that we have sufficient in-house expertise and
the product is sufficiently stable that we don't need as much help
as we used to. In addition, Franz gives us such good support that
we tend to go directly to them with questions rather than to the
mailing list...
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
On 2004-01-29 09:39:49, Kenny Tilton wrote:
> Newbies who actually try Lisp (there
> are no anti-Lispniks who have done so) are turning back-flips of joy
> within a couple of days.
Nope. The first time I tried Common Lisp (or read "ANSI Common
Lisp") I was really disappointed. My expectations where high. All
the Lisp fans said it was an easy language which less punctation and
"swear words" than other languages.
Then I had to learn '`#,@ ...
And my favorite editor is VIM.
Stefan Scholl wrote:
> On 2004-01-29 09:39:49, Kenny Tilton wrote:
>
>
>>Newbies who actually try Lisp (there
>>are no anti-Lispniks who have done so) are turning back-flips of joy
>>within a couple of days.
>
>
> Nope.
Cool! My survey has pretty well covered how newbies are happily
discovering Lisp, so the next area to explore is folks who try Lisp
today and do not like it. Lessee...
The first time I tried Common Lisp (or read "ANSI Common
> Lisp") I was really disappointed. My expectations where high. All
> the Lisp fans said it was an easy language which less punctation and
> "swear words" than other languages.
>
> Then I had to learn '`#,@ ...
>
> And my favorite editor is VIM.
OK. You know about the Lisp-friendly VIM thingy, yes? (Pardon the
technical jargon, but I don't know anything except a faint recall of
some traffic here to that effect.) Now for the survey, overlapping the
other:
> What other languages do you like? Dislike?
> What led you to try Lisp?
> How did you learn Lisp? Any specific books and/or on-line references?
How far did you get with those?
> Which implementation(s) did you use?
> How much original Lisp code did you write?
> What don't you like about Lisp?
> Have you now abandoned Lisp entirely, or are continuing but with
reservations, or ____________?
> Are you planning on exploring other languages? if so, which. If not,
which language will you be using most?
6. Anything else?
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Stefan Scholl <······@no-spoon.de> wrote:
>On 2004-01-29 09:39:49, Kenny Tilton wrote:
>
>> Newbies who actually try Lisp (there
>> are no anti-Lispniks who have done so) are turning back-flips of joy
>> within a couple of days.
>
>Nope. The first time I tried Common Lisp (or read "ANSI Common
>Lisp") I was really disappointed. My expectations where high. All
>the Lisp fans said it was an easy language which less punctation and
>"swear words" than other languages.
>
>Then I had to learn '`#,@ ...
Which is still a lot less than in Perl ;-)
>And my favorite editor is VIM.
And mine still is, but I switched to Emacs for Lisp programming, because
it IMHO _is_ the better environment for this language. But for
everything else (text, LaTeX, Perl, Shell, YouNameIt) it's still vim for
me.
Regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
>Then I had to learn '`#,@ ...
Just an aside --- most of the above occur as abbreviations. For
example, instead of
#'foo
you can write
(function foo)
and instead of
'bar
you can write
(quote bar)
and instead of
`(a ,b ,@c)
you can write
(append (list (quote a) b) c)
This is different from other "line-noise-friendly" languages, where
the line noise is not optional.
--
Fred Gilham ······@csl.sri.com
The opponents of income taxation in 1912 said that we would see the
day when taxes would extract 25% of people's income. Such Cassandras
were ridiculed. -- Gary North
Fred Gilham <······@snapdragon.csl.sri.com> wrote:
+---------------
| and instead of
| `(a ,b ,@c)
| you can write
| (append (list (quote a) b) c)
+---------------
Or (list* (quote a) b c) or even (cons (quote a) (cons b c)).
See? Perl isn't the only one with "more than one way to do it"... ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In article <··················@parsec.no-spoon.de>,
Stefan Scholl <······@no-spoon.de> writes:
> On 2004-01-29 09:39:49, Kenny Tilton wrote:
>
>> Newbies who actually try Lisp (there
>> are no anti-Lispniks who have done so) are turning back-flips of joy
>> within a couple of days.
>
> Nope. The first time I tried Common Lisp (or read "ANSI Common
> Lisp") I was really disappointed. My expectations where high. All
> the Lisp fans said it was an easy language which less punctation and
> "swear words" than other languages.
>
> Then I had to learn '`#,@ ...
>
> And my favorite editor is VIM.
maybe you should try a few times more. a friend of mine ran into the
same problem as you (he didn't like emacs), and gave up a few times,
tried other languages. i could finally convince him one more time,
this time with an emacs style environment. he now often doesn't show
up in the pub, because he forgets to go over the joy of learning lisp
and exploring it.
hs
--
Not everything that counts can be counted,
not everything that can be counted counts.
A. Einstein
On 2004-01-31 23:17:48, Hartmann Schaffer wrote:
> Stefan Scholl <······@no-spoon.de> writes:
>> On 2004-01-29 09:39:49, Kenny Tilton wrote:
>>> Newbies who actually try Lisp (there
>>> are no anti-Lispniks who have done so) are turning back-flips of joy
>>> within a couple of days.
>>
>> Nope. The first time I tried Common Lisp (or read "ANSI Common Lisp
>
> maybe you should try a few times more.
I have. I use sbcl, emacs, and slime. The "first time" was 2001.
I've checked Amazon.DE: versandt am 8. Mai 2001
Kenny Tilton <·······@nyc.rr.com> writes:
> Brian Mastenbrook wrote:
> > CLIM being a presentation-based display system, you can define
> > presentations for any different class in the output.
>
> Sounds like a GF specialized on the class and <something else> such as
> the container or a stream or even just a key value such as :clim-repl as
> long the lisp supports eql specializers. What's all the shouting about
> in re presentation types? I gotta be missing something (nothing new
> about that).
It's a bit more than that. The presentation type is an additional type
that can be orthogonal to the type of the object being output. The
main effect of this parallel type universe is that you can give useful
presentation types to built-in Lisp types if you like. This was
probably more useful in 1984 than it is in the present world of CLOS,
but it means you can do fun tricks like subclass your presentation
type from SEQUENCE and then use the built-in CLIM methods for inputing
sequences.
The CLIM methods that deal with input and output are called
presentation methods. These are basically CLOS methods wrapped with
some magic make method combination work on presentation types. The
method for output, called PRESENT, can in fact dispatch on 4 different
values:
the object being output
the presentation type argument
the stream
the "view", which is an additional parameter describing type kind of
view being drawn, for example "text-view" vs. "schematic-view."
Now, the reason we get excited about this isn't that presentation
types can drive different kinds of output -- that's probably better
left to dispatching on the stream type. We like presentation types
because CLIM records the presentation type that was output to the
screen, input is also specified with presentation types (with the
method ACCEPT), CLIM knows if a thing on the screen has a compatible
presentation type with the current call to ACCEPT, will highlight it
for you to tell you it is valid input, will print a little message in
the pointer documentation area telling you what the effect of various
mouse clicks will be, and satisfies the call to ACCEPT when the thing
is clicked.
CLIM also supports translators from one presentation type to another,
so an object can satisfy more things than originally planned. One
common translator is from a presentation type to a command so that
mouse clicks on some objects can invoke commands.
>
> > You also get a
> > free graphical inspector which you can use to inspect slot values.
>
> Done. Code-name ClouCell. And any cell-mediated slot changes as you
> watch if the value changes (no explicit "reload" necessary). In fact I
One of the features I like about the McCLIM Listener is that
everything output by the REPL gets a presentation type of FORM, but
the REPL accepts forms... so you can click on otherwise unreadable
objects and use them as arguments in functions.
I meant to write something about this a month ago (the last
time you dissed McCLIM :) : Cells and CLIM have very different
objectives. You seem to think that the layout and rendering of an
interface is the heart of the matter. In the CLIM world the graphical
details of the interface tend to take a back seat to the mechanics of
invoking commands and interacting with the rendered view on the
screen. As a result CLIM interfaces often look butt-ugly, but that's
kind of missing the point.
Tim
Timothy Moore wrote:
>
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Brian Mastenbrook wrote:
> > > CLIM being a presentation-based display system, you can define
> > > presentations for any different class in the output.
> >
> > Sounds like a GF specialized on the class and <something else> such as
> > the container or a stream or even just a key value such as :clim-repl as
> > long the lisp supports eql specializers. What's all the shouting about
> > in re presentation types? I gotta be missing something (nothing new
> > about that).
>
> It's a bit more than that. The presentation type is an additional type
> that can be orthogonal to the type of the object being output. The
> main effect of this parallel type universe is that you can give useful
> presentation types to built-in Lisp types if you like. This was
> probably more useful in 1984 than it is in the present world of CLOS,
> but it means you can do fun tricks like subclass your presentation
> type from SEQUENCE and then use the built-in CLIM methods for inputing
> sequences.
>
> The CLIM methods that deal with input and output are called
> presentation methods. These are basically CLOS methods wrapped with
> some magic make method combination work on presentation types. The
> method for output, called PRESENT, can in fact dispatch on 4 different
> values:
> the object being output
> the presentation type argument
> the stream
> the "view", which is an additional parameter describing type kind of
> view being drawn, for example "text-view" vs. "schematic-view."
Jeez, got enough parameters? Answer: yes! <g>
>
> Now, the reason we get excited about this isn't that presentation
> types can drive different kinds of output -- that's probably better
> left to dispatching on the stream type. We like presentation types
> because CLIM records the presentation type that was output to the
> screen, input is also specified with presentation types (with the
> method ACCEPT), CLIM knows if a thing on the screen has a compatible
> presentation type with the current call to ACCEPT, will highlight it
> for you to tell you it is valid input, will print a little message in
> the pointer documentation area telling you what the effect of various
> mouse clicks will be, and satisfies the call to ACCEPT when the thing
> is clicked.
OK, so once you establish a couple of methods for a given object all
sorts of things fall into place.
>
> CLIM also supports translators from one presentation type to another,
> so an object can satisfy more things than originally planned. One
> common translator is from a presentation type to a command so that
> mouse clicks on some objects can invoke commands.
OK, but this is just starting to sound like an over-complicated way to
get a relatively small amount of something-for-nothin. As in, yeah, it
gives you some freebees, but without CLIm it takes two seconds to cover
the stuff CLIM does automatically, meanwhile I just spent a year
learning CLIM. I hate productivity (ha!) tools like that.
> >
> > > You also get a
> > > free graphical inspector which you can use to inspect slot values.
> >
> > Done. Code-name ClouCell. And any cell-mediated slot changes as you
> > watch if the value changes (no explicit "reload" necessary). In fact I
>
> One of the features I like about the McCLIM Listener is that
> everything output by the REPL gets a presentation type of FORM, but
> the REPL accepts forms... so you can click on otherwise unreadable
> objects and use them as arguments in functions.
Cloucell calls the presntations for those "labels", and they can be
selected and handed to other functions for inspection or other.
>
> I meant to write something about this a month ago (the last
> time you dissed McCLIM :) : Cells and CLIM have very different
> objectives. You seem to think that the layout and rendering of an
> interface is the heart of the matter.
No. The RoboCells application was wholly Cells-driven and its only i/o
was socket reads/write (outside the Cell graph--socket messages got fed
into the graph, and graph output was (in part) socket writes). Cells
started out to solve a GUI problem, but they rapidly (and ineluctably if
you think about it) took over the whole app. Cell applications truly are
dataflow applications in which all interesting computation arises from
state changes triggering other state changes. RoboCells aside, there is
usually an interactive user using my apps, usually looking at a screen,
so state change often involves changes to the screen, but that is all.
> In the CLIM world the graphical
> details of the interface tend to take a back seat to the mechanics of
> invoking commands and interacting with the rendered view on the
> screen.
Yes, Cello has a Control class. :)
> As a result CLIM interfaces often look butt-ugly, but that's
> kind of missing the point.
True, but what is the excuse for the ugly presentation? Are you saying
that CLIM tries to present things without knowing what it is presenting,
so it somehow has to default to ugly? That is very hard to understand.
Sh*t, throw in some color and 3d-effects fer chrissakes!!
:) Hey, thx for a closer view of CLIM.
kenny
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Kenny Tilton <·······@nyc.rr.com> writes:
> Timothy Moore wrote:
> >
> > The CLIM methods that deal with input and output are called
> > presentation methods. These are basically CLOS methods wrapped with
> > some magic make method combination work on presentation types. The
> > method for output, called PRESENT, can in fact dispatch on 4 different
> > values:
> > the object being output
> > the presentation type argument
> > the stream
> > the "view", which is an additional parameter describing type kind of
> > view being drawn, for example "text-view" vs. "schematic-view."
>
> Jeez, got enough parameters? Answer: yes! <g>
Maybe it's enough, maybe not. In practice most presentation methods
are specialized only on the presentation type and, perhaps, the
view. Nevertheless you'd be happy enough to have those extra
parameters if you retargeted your output for something radically
different.
> > CLIM also supports translators from one presentation type to another,
> > so an object can satisfy more things than originally planned. One
> > common translator is from a presentation type to a command so that
> > mouse clicks on some objects can invoke commands.
>
> OK, but this is just starting to sound like an over-complicated way to
> get a relatively small amount of something-for-nothin. As in, yeah, it
> gives you some freebees, but without CLIm it takes two seconds to cover
> the stuff CLIM does automatically, meanwhile I just spent a year
> learning CLIM. I hate productivity (ha!) tools like that.
This stuff is just not that complicated for the end user in most
cases. An extra option to an argument in a definition that resembles
DEFUN quite a bit is not over-complicated.
What, exactly, takes 2 seconds? I think we're talking past each other.
> > >
> > > > You also get a
> > > > free graphical inspector which you can use to inspect slot values.
> > >
> > > Done. Code-name ClouCell. And any cell-mediated slot changes as you
> > > watch if the value changes (no explicit "reload" necessary). In fact I
> >
> > One of the features I like about the McCLIM Listener is that
> > everything output by the REPL gets a presentation type of FORM, but
> > the REPL accepts forms... so you can click on otherwise unreadable
> > objects and use them as arguments in functions.
>
> Cloucell calls the presntations for those "labels", and they can be
> selected and handed to other functions for inspection or other.
Selected from where? Do you have a Cello REPL where I can see this in
action?
> > I meant to write something about this a month ago (the last
> > time you dissed McCLIM :) : Cells and CLIM have very different
> > objectives. You seem to think that the layout and rendering of an
> > interface is the heart of the matter.
>
> No. The RoboCells application was wholly Cells-driven and its only i/o
...
> state changes triggering other state changes. RoboCells aside, there is
> usually an interactive user using my apps, usually looking at a screen,
> so state change often involves changes to the screen, but that is all.
>
It's possible I've confused "Cells" and "Cello".
> > In the CLIM world the graphical
> > details of the interface tend to take a back seat to the mechanics of
> > invoking commands and interacting with the rendered view on the
> > screen.
>
> Yes, Cello has a Control class. :)
Do you have a pointer to some documentation on that? I don't want to
argue from ignorance, but I suspect CLIM has a bit more going on
there.
> > As a result CLIM interfaces often look butt-ugly, but that's
> > kind of missing the point.
>
> True, but what is the excuse for the ugly presentation? Are you saying
> that CLIM tries to present things without knowing what it is presenting,
> so it somehow has to default to ugly? That is very hard to understand.
> Sh*t, throw in some color and 3d-effects fer chrissakes!!
I don't think CLIM exactly defaults to ugly -- at least, that's not in
the Spec :) -- apart for an unfortunate default font choice. There are
a couple of factors that contribute to the plainness of some CLIM
applications:
Some applications are straight-forward ports from Genera, whose
interface looks a bit quaint by today's standards.
Most CLIM applications are not shrink wrap. The developers cared a lot
more about, for example, getting the shuttle loaded or the telescope
scheduled than color and 3d-effects in the interface.
It's possible to create a powerful inteface in CLIM with little more
than format statements, some presentation types and some presentation
methods, so that's all that people do.
In McCLIM we've added some window dressing that gives you some
prettier results than the default. I don't know if anyone uses it.
Also, some McCLIM applications are truely exquisite, though not in a
conventional way. Robert Strandh's GSharp music score editor comes to
mind.
> :) Hey, thx for a closer view of CLIM.
It's hard to tell if I'm wasting my time or not.
Tim
Timothy Moore wrote:
>
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Timothy Moore wrote:
> > >
> > > The CLIM methods that deal with input and output are called
> > > presentation methods. These are basically CLOS methods wrapped with
> > > some magic make method combination work on presentation types. The
> > > method for output, called PRESENT, can in fact dispatch on 4 different
> > > values:
> > > the object being output
> > > the presentation type argument
> > > the stream
> > > the "view", which is an additional parameter describing type kind of
> > > view being drawn, for example "text-view" vs. "schematic-view."
> >
> > Jeez, got enough parameters? Answer: yes! <g>
>
> Maybe it's enough, maybe not. In practice most presentation methods
> are specialized only on the presentation type and, perhaps, the
> view. Nevertheless you'd be happy enough to have those extra
> parameters if you retargeted your output for something radically
> different.
Sorry, i did not mean that as a slam. As you say, eventually all those
parameters come in handy for some role or another.
>
> Selected from where? Do you have a Cello REPL where I can see this in
> action?
I have an object inspector that will be one of the example apps when
Cello ships. I still have not heard much about the CLIM repl. I gather
it Ls, Rs, Es, and then Ps a (scrolling?) graphical display of the
result. I am guessing there is the default form which is a label showing
princ output and that this label is also a control you can double-click
to inspect, option-click to somehow drop in the next form to be read...
I was asking to see if I wanted to do a Cello REPL as an example app.
Right now I am leaning towards PhotoshopLite.
> It's possible I've confused "Cells" and "Cello".
Cello is a GUI/app framework built using Cells, the linear dataflow
dependency access-oriented (thx, Pascal) constraints etc etc engine.
> Do you have a pointer to some documentation on that? I don't want to
> argue from ignorance, but I suspect CLIM has a bit more going on
> there.
Lot's going on now, but I hope to roll "Cello for Case-hardened Bleeding
Edge Devotees" in short order. Currently it is being ported to Linux and
learning to use its new bionic implants: OpenGL, FTGL and ImageMagick.
> It's possible to create a powerful inteface in CLIM with little more
> than format statements, some presentation types and some presentation
> methods, so that's all that people do.
Understood. Makes sense.
Me, I am working on commercial software so it should look nice, too. And
on win32 it was falling off a log to use the 3D effects offered by the
GDI (?) to make nice buttons, edges, sunken panes, etc. And with win32
or FTGL gorgeous type is automatic, so why not.
kenny
--
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Kenny Tilton <·······@nyc.rr.com> writes:
> Timothy Moore wrote:
> >
> > Selected from where? Do you have a Cello REPL where I can see this in
> > action?
>
> I have an object inspector that will be one of the example apps when
> Cello ships. I still have not heard much about the CLIM repl. I gather
> it Ls, Rs, Es, and then Ps a (scrolling?) graphical display of the
> result. I am guessing there is the default form which is a label showing
> princ output and that this label is also a control you can double-click
> to inspect, option-click to somehow drop in the next form to be read...
> I was asking to see if I wanted to do a Cello REPL as an example app.
http://www.bricoworks.com/moore/mcclim.html has an example of the Listener in
action.
Tim
Timothy Moore wrote:
>
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Timothy Moore wrote:
> > >
> > > Selected from where? Do you have a Cello REPL where I can see this in
> > > action?
> >
> > I have an object inspector that will be one of the example apps when
> > Cello ships. I still have not heard much about the CLIM repl. I gather
> > it Ls, Rs, Es, and then Ps a (scrolling?) graphical display of the
> > result. I am guessing there is the default form which is a label showing
> > princ output and that this label is also a control you can double-click
> > to inspect, option-click to somehow drop in the next form to be read...
> > I was asking to see if I wanted to do a Cello REPL as an example app.
>
> http://www.bricoworks.com/moore/mcclim.html has an example of the Listener in
> action.
>
Thanks. Someone else sent me links to Rainer's (?) movies. Y'all need to
learn about marketing. Still butt ugly. And if CLIM is such a powerful
GUI, it should take 10 minutes to jazz it up. Statements like this from
the link above make me wonder if Lispniks have lost the ability to
communicate with non-Lispniks:
"It has many features, but here's one that's especially exciting for
Lisp programmers: anything that is printed can be used as input when
typing a form, even if its printed representation isn't readable."
This is what all the CLIM repl excitement is about? puh-leez! If this is
what we try to impress the world with (even the CL world), it shows we
need to get out more.
kenny
--
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
In article <·················@nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> Thanks. Someone else sent me links to Rainer's (?) movies. Y'all need to
> learn about marketing. Still butt ugly. And if CLIM is such a powerful
> GUI, it should take 10 minutes to jazz it up. Statements like this from
> the link above make me wonder if Lispniks have lost the ability to
> communicate with non-Lispniks:
I hate to break it to you, but the power of CLIM is not related to how
"pretty" it looks. Right now the people working on it are focusing on
making it usable; making it look pretty comes later.
> "It has many features, but here's one that's especially exciting for
> Lisp programmers: anything that is printed can be used as input when
> typing a form, even if its printed representation isn't readable."
>
> This is what all the CLIM repl excitement is about? puh-leez! If this is
> what we try to impress the world with (even the CL world), it shows we
> need to get out more.
For those people who actually /understand/ what lisp is all about,
being able to point to and manipulate objects (and not just their
printed representations) is a very very big thing. I don't see why we
can't maintain what makes us lispers when dealing with the outside
world.
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
Brian Mastenbrook wrote:
> In article <·················@nyc.rr.com>, Kenny Tilton
> <·······@nyc.rr.com> wrote:
>
>
>>Thanks. Someone else sent me links to Rainer's (?) movies. Y'all need to
>>learn about marketing. Still butt ugly. And if CLIM is such a powerful
>>GUI, it should take 10 minutes to jazz it up. Statements like this from
>>the link above make me wonder if Lispniks have lost the ability to
>>communicate with non-Lispniks:
>
>
> I hate to break it to you, but the power of CLIM is not related to how
> "pretty" it looks. Right now the people working on it are focusing on
> making it usable; making it look pretty comes later.
Two things. First, like I said, what is so wrong with CLIM that "pretty"
is so hard that it was not in the bag years ago. Someone apologized
for an unfortunate "default font". Excuse me, no :textFace '(ArialN
:size 14 :style '(bold italic)), where the face is any True/FreeType
font on the system? If not, CLIM ain't no GUI.
Second, I am laughing at myself because I forgot I had a CLIM REPL in
CliniSys for a while. The application had it's own mail mechanism to
keep all communications in sight. One could drop references to documents
or patients into the body of a message. Anyone reading that could
right-click on the nice textual reference and open that entity in a
view. That took me a day.
I doubt CLIM's power justifies its learning curve, or forgives its
apparent visual feebleness.
> For those people who actually /understand/ what lisp is all about,
> being able to point to and manipulate objects (and not just their
> printed representations) is a very very big thing. I don't see why we
> can't maintain what makes us lispers when dealing with the outside
> world.
If and only if the subject is marketing, we need to forget we are
Lispniks and do a Vulcan mind meld with a Java monkey. The George
Foreman grill is a great grill. It was a great grill before they hired
George Foreman*. But they could not sell them to save their lives. Now
they are ubiquitous. Quality and substance are irrelevant. To marketing.
Kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Someone apologized for an unfortunate "default font". Excuse me, no
> :textFace '(ArialN :size 14 :style '(bold italic)), where the face
> is any True/FreeType font on the system? If not, CLIM ain't no GUI.
What is your understanding of the word "default"? Apart from "to lose
by not fulfilling an obligation", which if talking sense were a
requirement for argument you'd be in danger of falling foul of.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Someone apologized for an unfortunate "default font". Excuse me, no
>>:textFace '(ArialN :size 14 :style '(bold italic)), where the face
>>is any True/FreeType font on the system? If not, CLIM ain't no GUI.
>
>
> What is your understanding of the word "default"?
I was too terse. Omitted was this inference I took from some ugly screen
being defended in part as the consequence of an ugly default font:
default n. "Something easily overridden in any decent GUI, so you will
never see it used as an excuse for a crappy display."
Make, um, sense? You may not like that I am making inferences based on
what users of CLIM say, but (a) that is the nature of intelligence and
(b) the alternative is to go out and learn CLIM, and apparently that
would take months.
> Apart from "to lose
> by not fulfilling an obligation", which if talking sense were a
> requirement for argument you'd be in danger of falling foul of.
Never a sentence with a preposition end. I would not be so picky, but I
see you aspire to a reputation for verbal felicity.
:)
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
In article <·························@twister.nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> I was too terse. Omitted was this inference I took from some ugly screen
> being defended in part as the consequence of an ugly default font:
>
> default n. "Something easily overridden in any decent GUI, so you will
> never see it used as an excuse for a crappy display."
From a user of Arial comes a complaint about the CLIM default font?
That can hardly be. But since you brought it up, what about
/presentation/-based user interfaces has anything to do with font? It
seems to me that the best way to do a presentation-based UI is to allow
the maximum flexibility on what exact font is chosen for the output
medium.
> Make, um, sense? You may not like that I am making inferences based on
> what users of CLIM say, but (a) that is the nature of intelligence and
> (b) the alternative is to go out and learn CLIM, and apparently that
> would take months.
CLIM does not take months to learn the basics of. A few hours with the
McCLIM Examples directory will do that. The advanced bits of CLIM take
time, just like the advanced bits of CL. I would think it would be
obvious that there is a difference between learning the mindset and
learning the whole API.
> Never a sentence with a preposition end. I would not be so picky, but I
> see you aspire to a reputation for verbal felicity.
And I see you aspire to a reputation for trolling. Is there any reason
you can't be polite to people? Perhaps you just need to take a break
from your computer. Your time on usenet seems to have worsened your
personality.
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
Brian Mastenbrook wrote:
> In article <·························@twister.nyc.rr.com>, Kenny Tilton
> <·······@nyc.rr.com> wrote:
>
>
>>I was too terse. Omitted was this inference I took from some ugly screen
>>being defended in part as the consequence of an ugly default font:
>>
>>default n. "Something easily overridden in any decent GUI, so you will
>>never see it used as an excuse for a crappy display."
>
>
> From a user of Arial comes a complaint about the CLIM default font?
ArialN (it was) came up because I was looking for the font which looked
most like the font I see used in tiny little labels in Netscape, ACL,
etc. For a serif face I use Sylfaen in testing because it is so short to
type.
You prefer one of the other 148 fonts on my system? That was the point,
btw, but thank you for twisting it into an attack on my taste in fonts.
Now put down that rope, this isn't funny any more!
:)
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Christophe Rhodes wrote:
> > Apart from "to lose
> > by not fulfilling an obligation", which if talking sense were a
> > requirement for argument you'd be in danger of falling foul of.
>
> Never a sentence with a preposition end. I would not be so picky, but
> I see you aspire to a reputation for verbal felicity.
Rejecting such sentences is not about being picky, but about begin a
so called "prescriptive linguist", which has been out of fashion for
decades. Google for: "sentence ending with preposition" for several
articles summarizing current thinking.
--
Robert Strandh
---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------
Robert STRANDH wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Christophe Rhodes wrote:
>>
>>>Apart from "to lose
>>>by not fulfilling an obligation", which if talking sense were a
>>>requirement for argument you'd be in danger of falling foul of.
>>
>>Never a sentence with a preposition end. I would not be so picky, but
>>I see you aspire to a reputation for verbal felicity.
>
>
> Rejecting such sentences is not about being picky, but about begin a
> so called "prescriptive linguist", which has been out of fashion for
> decades.
That was not about being a prescriptive, that was about responding with
an equally assinine remark.
Google for: "sentence ending with preposition" for several
> articles summarizing current thinking.
I have only in the past couple of years taken certain rules seriously,
by which I mean actually rewriting sentences when I realize I have split
an infinitive or ended a sentence with a preposition. The writing always
gets stronger when I make those corrections. I also like avoiding the
passive voice, but that is just too much damn work
XXXXXXXXXXXXXXXXXXXXXX wearies me.
It's not about prescriptions, it's about stronger writing (and making
fun of a too-florid sentence.)
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> I have only in the past couple of years taken certain rules seriously,
> by which I mean actually rewriting sentences when I realize I have
> split an infinitive or ended a sentence with a preposition. The
> writing always gets stronger when I make those corrections. I also
> like avoiding the passive voice, but that is just too much damn work
> XXXXXXXXXXXXXXXXXXXXXX wearies me.
``This is the sort of English up with which I will not put.''
-- Winston Churchill
``When I split an infinitive, God damn it, I split it so it will stay
split.'' -- Raymond Chandler
``Remember to never split an infinitive.'' -- William Safire
``Some infinitives seem to improve on being split, just as a stick of
round stovewood does.'' -- Strunk and White
--
~jrm
Joe Marshall wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>I have only in the past couple of years taken certain rules seriously,
>>by which I mean actually rewriting sentences when I realize I have
>>split an infinitive or ended a sentence with a preposition. The
>>writing always gets stronger when I make those corrections. I also
>>like avoiding the passive voice, but that is just too much damn work
>>XXXXXXXXXXXXXXXXXXXXXX wearies me.
>
>
>
> ``This is the sort of English up with which I will not put.''
> -- Winston Churchill
>
> ``When I split an infinitive, God damn it, I split it so it will stay
> split.'' -- Raymond Chandler
>
> ``Remember to never split an infinitive.'' -- William Safire
>
> ``Some infinitives seem to improve on being split, just as a stick of
> round stovewood does.'' -- Strunk and White
Oy, S&W, I'm in trouble now. lessee...
"To go boldly where no man has gone before." James T Kirk, Captain
"To be or to not be?" Hamlet
:)
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
* Kenny Tilton
| [...] that was about responding with an equally assinine remark.
This seems to be the favorite childish way to respond these days, but
nobody appears to worry that they may be mistaken in their assessment
of what they set out to equal and that they compare very different
things for equality.
It is well-known that people regard their own actions and the effect
they have on others very differently than they regard other people's
actions and their effect on themselves. Only under highly specialized
conditions are we able to respond exactly in kind. Most of the time,
however, we make mistakes on a scale that explains the escalation of
the hostilities on the Net. The injustice we suffer is not just worse
than the injustice we inflict on others, the same injustice feels more
than twice as unjust when suffered as when inflicted. When people who
do not reflect on their revengeful feelings set out to do onto other
what others have done onto third parties, they are not just insane to
begin with, as everyone quietly realizes, they inflict much more harm
on purpose than even the harm they thought they saw and want to exact
retribution for.
The reason this �respond in kind� thing can never actually work except
in the mind of the person doing it, is that there can never actually
/be/ a response in kind. Every response is the responsibility of the
person who produces it. You may have noticed that one of the most
bizarrely disturbed people here thinks that he did not write what he
in fact wrote, someone else wrote it. This is symptomatic of the kind
of problems that people who believe they respond in kind suffer from,
since they are no longer responsible for their own actions, someone
else did something that they merely repeat, and therefore they believe
they are not responsible for the choice and act of repetition. This
is remarkably invalid reasoning and remarkably immature.
�I'm only doing what you did. What's your problem?� illustrates that
the person who performs the mimicking does not understand that he is
usually, probably always, mistaken about what other people did, but
since he has absolved himself of responsibility for his actions like
the immature child he is, he will not be able to accept criticism of
any kind for this incredibly immature mirror game, because everything
anybody says about his stupid stunt is automatically deflected back to
the person they have mimicked, and the kind of people who engage in
this kind of behavior always rejoice in the criticism that they get,
because in their mind, the only guilty person is the person they have
copied and the mirror games effectively prevents them from thinking
about what they are doing at all.
The solution is deceptively simple: Always do your best. There can
never be anyone to blame for your own behavior, so don't insult the
intelligence of your audience by attempting to pull such a thing off.
If you think someone made an asinine remark, DO NOT ACT LIKE THEM.
And I'm only saying this because I believe you can think about it,
quite unlike the other immature runt we have running around here
mimicking people and failing to accept responsibility for himself.
--
Erik Naggum | Oslo, Norway 2004-031
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
"Robert STRANDH" <·······@labri.fr> wrote in message
···················@serveur5.labri.fr...
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Christophe Rhodes wrote:
> > > Apart from "to lose
> > > by not fulfilling an obligation", which if talking sense were a
> > > requirement for argument you'd be in danger of falling foul of.
> >
> > Never a sentence with a preposition end. I would not be so picky, but
> > I see you aspire to a reputation for verbal felicity.
>
> Rejecting such sentences is not about being picky, but about begin a
> so called "prescriptive linguist", which has been out of fashion for
> decades. Google for: "sentence ending with preposition" for several
> articles summarizing current thinking.
>
> --
> Robert Strandh
A friend's aunt, who believed it unlucky to discuss bad weather, once said:
"Why bring weather a body needs to get in out of up for?"
ralph231 <········@hotmail.com> wrote:
> "Robert STRANDH" <·······@labri.fr> wrote in message
> ···················@serveur5.labri.fr...
>> Kenny Tilton <·······@nyc.rr.com> writes:
>> > Never a sentence with a preposition end. I would not be so picky, but
>> > I see you aspire to a reputation for verbal felicity.
>>
>> Rejecting such sentences is not about being picky, but about begin a
>> so called "prescriptive linguist", which has been out of fashion for
>> decades. Google for: "sentence ending with preposition" for several
>> articles summarizing current thinking.
>
> A friend's aunt, who believed it unlucky to discuss bad weather, once said:
>
> "Why bring weather a body needs to get in out of up for?"
As the young child said, who was bored with bedtime stories about
Australia:
"What did you bring that book I didn't want to be read to out of about
Down Under up for?"
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
Kenny Tilton wrote:
> If and only if the subject is marketing, we need to forget we are
> Lispniks and do a Vulcan mind meld with a Java monkey.
Java has a bad reputation for GUI development because the abstract
layers (Awt or Swing) that make it portable hinder responsiveness. A lot
of Java monkeys move away for the standardized GUI toolkit to platform
native bindings (SWT, Apple's cocoa bindings) that give the performance
they require. Looking to Java as a sucessful example of a cross platform
GUI toolkit may be flawed- it's mainly used as a server language, not a
desktop one.
Though at least Java looks like aqua on OS X, unlike X11. But (AFAIK)
that's Apple's doing, not Sun's.
Maybe you need to convince someone in Apple that it's worth them
supplying a binding of aqua to CLIM, rather than using the X binding.
Except CLIM isn't a binary standard, so you're stuck persuading one
impementor of CL that it's worth making a binary standard for CLIM.
(yes, this is where the options trail off).
Alternatively, build a lisp on top of the JVM. Since 1.4 you can reload
class definitions on the fly, but you're still stuck with single
dispatch and having to implement lambda with interfaces. Given about
half the questions on Java bbs' are "how do I write an expression
evaluator" or "why does 1/2 = 0" and other non-questions in lisp, that
might be doing the java world a favour.
Pete
pete kirkham wrote:
> Kenny Tilton wrote:
>
>> If and only if the subject is marketing, we need to forget we are
>> Lispniks and do a Vulcan mind meld with a Java monkey.
>
>
> Java has a bad reputation for GUI development because the abstract
> layers (Awt or Swing) that make it portable hinder responsiveness. A lot
> of Java monkeys move away for the standardized GUI toolkit to platform
> native bindings (SWT, Apple's cocoa bindings) that give the performance
> they require.
Yeah, maybe that was a bad example. :) I am hoping OpenGL + FTGL +
ImageMagick will be perty fast and let me milk the GPU. fwiw, I like
what I see so far in re performance, and i wager the slowest thing by
far is Cells and my kill-them-with-containers approach in Cello.
Everything is a widget, often two, an outer-inner pair ... well, a
simple checkbox is actually a row container of a little box and a
separate text label. I could collapse those three into one if I ever saw
a performance problem, mind you, but this way I could assemble the
checkbox widget out of pre-existing widgets.
Hey, let's start up that "re-use" thread again!
btw, once I release Cello everyone can grab it and just throw it away,
keep the OpenGL + FTGL + ImageMagick bindings and knock themselves out.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
pete kirkham <·················@cafemosaic.co.uk> writes:
> Java has a bad reputation for GUI development because the abstract
> layers (Awt or Swing) that make it portable hinder responsiveness.
Swing is getting unfair press, in my opinion. I have done full-blown syntax
editors, as well as interactive drawing diagrams, all in swing, and the
performance is quite snappy.
The trick is avoiding "brute force" methods, and avoiding the built-in
documents with their structured views.
With smart data structures and lazy evaluation, things perform just fine.
> A lot of Java monkeys move away for the standardized GUI toolkit to platform
> native bindings (SWT, Apple's cocoa bindings) that give the performance they
> require.
And immediately run into interoperability problems. Ever try to port some
swing app to Eclipse?
Swing actually has a decent design. Parts of it suck, especially the
structured document support, but the overall philosphy is sound.
> Looking to Java as a sucessful example of a cross platform GUI toolkit may
> be flawed- it's mainly used as a server language, not a desktop one.
Unfair press again, in my opinion. From my point of view, developing desktop
apps in straight Java with swing gives me mostly instant portability,
especially compared to the grief I used to suffer writing the same kinds of
apps in "portable" C++, with "portable" OS calls.
"Portable GUI" is now mostly a non-issue for me. Sure there are some problems,
but far far less then I used to deal with.
> Though at least Java looks like aqua on OS X, unlike X11. But (AFAIK)
> that's Apple's doing, not Sun's.
But at least swing can handle this sort of thing quite easily. Changing the
look and feel tends to have little impact to the rest of the application.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
Ray Blaak <········@STRIPCAPStelus.net> wrote in message news:<················@STRIPCAPStelus.net>...
> Swing is getting unfair press, in my opinion. I have done full-blown syntax
> editors, as well as interactive drawing diagrams, all in swing, and the
> performance is quite snappy.
>
> The trick is avoiding "brute force" methods, and avoiding the built-in
> documents with their structured views.
>
> With smart data structures and lazy evaluation, things perform just fine.
Sounds like you're describing JGoodies. Their demos were very quick.
A problem with Swing I've observed on mswin is when you've got a
number of apps running, Swing apps tend to need a while to redraw. I
think this is independent of the app's quality, since iirc this could
be reproduced with a very barebones demo.
> Swing actually has a decent design. Parts of it suck, especially the
> structured document support, but the overall philosphy is sound.
Are there commonly-used gui toolkits with a better design? Just
curious what you think.
> > Looking to Java as a sucessful example of a cross platform GUI toolkit may
> > be flawed- it's mainly used as a server language, not a desktop one.
>
> Unfair press again, in my opinion. From my point of view, developing desktop
> apps in straight Java with swing gives me mostly instant portability,
> especially compared to the grief I used to suffer writing the same kinds of
> apps in "portable" C++, with "portable" OS calls.
I don't think Sun had a coherent message for desktop developers. For
example, lots of people complain about being forced to use or replace
the user's runtime env. However, there are solutions, at least if
you're willing to part with using the systemwide runtime env. So
despite the enormous amount of documentation, some messages were
fuzzy. Perhaps the marketing story could have been split between the
different fronts (desktop/server/etc). Plus that 100% pure java thing
was probably taken way too far as an overarching philosophy.
> > Though at least Java looks like aqua on OS X, unlike X11. But (AFAIK)
> > that's Apple's doing, not Sun's.
[This response is to Pete Kirkham]
Sun loaned an engineer to Apple for the port.
This was not going to happen with MSFT, since there was no way in hell
they were going to help the guys who desired to turn mswin into a
poorly debugged set of device drivers.
Ray Blaak wrote:
>>Though at least Java looks like aqua on OS X, unlike X11. But (AFAIK)
>>that's Apple's doing, not Sun's.
Could be. IIUC, they have similarly produced a GLUT (OpenGL Window
Manager Lite) for OS X built on Aqua, so GLUT windows play nicely with
other native OS X windows.
My Cello project is built on Freeglut, but those developers are taking
extroardinary pains to remain binary compatible with the original GLUT,
so Cello apps should link happily with apple's GLUT for distribution.
Well, hang on, Apple's GLUT also incorporates a couple of enhancements
that make it friendly to iterative development in the Lisp style, so we
we might just go for Apple's GLUT straight away. But I digress.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
In article <·························@twister.nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> Ray Blaak wrote:
>
> >>Though at least Java looks like aqua on OS X, unlike X11. But (AFAIK)
> >>that's Apple's doing, not Sun's.
>
> Could be. IIUC, they have similarly produced a GLUT (OpenGL Window
> Manager Lite) for OS X built on Aqua, so GLUT windows play nicely with
> other native OS X windows.
That's not a silver bullet that suddenly makes your apps feel like
Aqua. It must means they aren't running in the X server. You'll need to
examine HIView if you really want to actually look like Aqua.
> My Cello project is built on Freeglut, but those developers are taking
> extroardinary pains to remain binary compatible with the original GLUT,
> so Cello apps should link happily with apple's GLUT for distribution.
> Well, hang on, Apple's GLUT also incorporates a couple of enhancements
> that make it friendly to iterative development in the Lisp style, so we
> we might just go for Apple's GLUT straight away. But I digress.
Why does it seem that you tout the libraries your project is based on
so much? What does that do for the actual mechanics of using Cello? You
still need to write the code that turns ImageMagick, OpenGL, and GLUT
into an actual cohesive library with a good API.
I have in fact noticed a trend among many vaporware projects that they
tend to tout the libraries they are based on more than the project
itself. This is often because (a) they have no working code, and (b)
because we are supposed to judge the quality of the project based on
our impression of the reputation of its dependent libraries. The latter
of these seems to be the case here - why else would it matter to us
which particular implementation of GLUT you are using? For that matter,
why does it matter what graphics file reader you are using?
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
Brian Mastenbrook wrote:
> In article <·························@twister.nyc.rr.com>, Kenny Tilton
> <·······@nyc.rr.com> wrote:
>
>
>>Ray Blaak wrote:
>>
>>
>>>>Though at least Java looks like aqua on OS X, unlike X11. But (AFAIK)
>>>>that's Apple's doing, not Sun's.
>>
>>Could be. IIUC, they have similarly produced a GLUT (OpenGL Window
>>Manager Lite) for OS X built on Aqua, so GLUT windows play nicely with
>>other native OS X windows.
>
>
> That's not a silver bullet that suddenly makes your apps feel like
> Aqua. It must means they aren't running in the X server. You'll need to
> examine HIView if you really want to actually look like Aqua.
Well, it's all greek to me. OS X is next month. I looked at some of the
Aqua GLUT code and saw code that looked native, so I guessed the GLUT
windows would simply be native windows. But I do not know enough yet
even to understand what you wrote.
> Why does it seem that you tout the libraries your project is based on
> so much? What does that do for the actual mechanics of using Cello? You
> still need to write the code that turns ImageMagick, OpenGL, and GLUT
> into an actual cohesive library with a good API.
>
> I have in fact noticed a trend among many vaporware projects that they
> tend to tout the libraries they are based on more than the project
> itself.
I'm sorry, the libraries are mostly fixes to problems I created by
targeting portability, so the celebration you hear in me is over having
solved what I thought were show-stopping problems. The one definite
exception was ImageMagick, but Tim says that sucks so mebbe not. All the
things I am getting from these libraries are available if I hardcode for
CAPI or Common Graphics and for win32 or x11, and I lost them all when I
opted for portability via OpenGL. I was actually quite discouraged about
the whole thing until I opened my eyes and saw FTGL. So, again, I am
talking about the libraries for the problems they solve, not for their
added value.
That said, there /are/ some pluses other than portability (the only
thing I cared about):
-- OpenGL: wicked functionality, hardware accelerated
-- Freeglut: none.
-- FTGL: Extruded, scalable, lotsa kinds
-- ImageMagick: Photoshop and Illustrator In A Drum
-- Supercollider: the Lisp of programmable sound
-- Cells: <g>
btw, am I to understand now that the latest defense of CLIM is that
Cello is built atop quality, portable, free libraries? This acrimonious
thread bears a surprising amount of technical agreement.
:)
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
In article <·························@twister.nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> Well, it's all greek to me. OS X is next month. I looked at some of the
> Aqua GLUT code and saw code that looked native, so I guessed the GLUT
> windows would simply be native windows. But I do not know enough yet
> even to understand what you wrote.
Allow me to translate for you then: GLUT windows have a native-looking
titlebar. What's inside may look like crap for all the OS cares. X11
windows have a native-looking titlebar too, so that's no
differentiator.
> I'm sorry, the libraries are mostly fixes to problems I created by
> targeting portability, so the celebration you hear in me is over having
> solved what I thought were show-stopping problems.
You're talking to people who neither know nor care about your
portability problems, since we haven't seen the code.
> The one definite
> exception was ImageMagick, but Tim says that sucks so mebbe not. All the
> things I am getting from these libraries are available if I hardcode for
> CAPI or Common Graphics and for win32 or x11, and I lost them all when I
> opted for portability via OpenGL. I was actually quite discouraged about
> the whole thing until I opened my eyes and saw FTGL. So, again, I am
> talking about the libraries for the problems they solve, not for their
> added value.
That would mean something to me if I knew anything about those problems.
> That said, there /are/ some pluses other than portability (the only
> thing I cared about):
>
> -- OpenGL: wicked functionality, hardware accelerated
Doesn't mean anything if the project doesn't exist. Apple touts OpenGL
because their windowing system exists and is shipping.
> btw, am I to understand now that the latest defense of CLIM is that
> Cello is built atop quality, portable, free libraries?
I wasn't defending CLIM. I was explaining that Cello is classic
vaporware of the type that never gets released, and that one tactic
taken by people who engage in such vaporware is to tout their libraries
highly so other people can imagine how cool it might be - if it ever
exists. As of right now I'm convinced that you're making Cello up.
> This acrimonious
> thread bears a surprising amount of technical agreement.
It is not a technical issue, merely a question of why you feel the need
to constantly remind everyone of what cool libraries you are using,
instead of talking about what Cello actually is (or might be, if it
actually existed).
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
Brian Mastenbrook wrote:
> Allow me to translate for you then: GLUT windows have a native-looking
> titlebar. What's inside may look like crap for all the OS cares. X11
> windows have a native-looking titlebar too, so that's no
> differentiator.
I am sorry, I just surfed Apple but I cannot find the bit where they
whooped about all the extra goodies covered by their native GLUT. But it
seems they ship two GLUTs, one sitting atop X11 and one native, so I
wager the latter is there for a reason (not just title bars).
Performance? Stuff like drag and drop? Wish I had more details for you.
>>I'm sorry, the libraries are mostly fixes to problems I created by
>>targeting portability, so the celebration you hear in me is over having
>>solved what I thought were show-stopping problems.
>
>
> You're talking to people who neither know nor care about your
> portability problems, since we haven't seen the code.
You missed my point. You think I am bragging about my libraries. I am
simply celebrating that some libraries bailed me out of a jam. ie, No, I
am not bragging about my libraries. I did list some nice benefits of
them, but they do not rise to the level of gee whiz (pending
re-evaluation of Imagemagick).
Btw, I was too hard on Freeglut. Two things about that: hey, maybe there
is a small free lunch if a vendor adds some value to the Glut. More
specifically, f/g allows me to put a window instance inside a pane of
itself (or any other f/g window, but it was fun putting the window
inside itself. That (I think) can be a performance boost, because the
outer window (at least in the win32 freeglut) does not get a redisplay
callback just because the inner window needs a redraw.
I do not know how easy that was, but I appreciate getting that out of
the box.
> That would mean something to me if I knew anything about those problems.
Have you ever seen un-anti-aliased type? eeyeeuwww.
> Doesn't mean anything if the project doesn't exist. Apple touts OpenGL
> because their windowing system exists and is shipping.
>
>
>>btw, am I to understand now that the latest defense of CLIM is that
>>Cello is built atop quality, portable, free libraries?
>
>
> I wasn't defending CLIM. I was explaining that Cello is classic
> vaporware of the type that never gets released, and that one tactic
> taken by people who engage in such vaporware is to tout their libraries
> highly so other people can imagine how cool it might be - if it ever
> exists. As of right now I'm convinced that you're making Cello up.
Ok, that's two "liar!", one "what did I do to you to deserve this
unjustified attack", and one weather forecast for Hell.
:)
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
In article <·························@twister.nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> I am sorry, I just surfed Apple but I cannot find the bit where they
> whooped about all the extra goodies covered by their native GLUT. But it
> seems they ship two GLUTs, one sitting atop X11 and one native, so I
> wager the latter is there for a reason (not just title bars).
> Performance? Stuff like drag and drop? Wish I had more details for you.
Not everyone has X11 installed. In addition the main GLUT will provide
native menus. But GLUT has no conception of any other widget. You do
know what GLUT does, right?
> You missed my point. You think I am bragging about my libraries. I am
> simply celebrating that some libraries bailed me out of a jam. ie, No, I
> am not bragging about my libraries. I did list some nice benefits of
> them, but they do not rise to the level of gee whiz (pending
> re-evaluation of Imagemagick).
Why don't you brag about the new things that you are bringing to the
field of lisp GUI design then, or the new GUI model that Cells can
provide, or something /new/? You're simply riding on the coattails of
these other projects right now.
> Btw, I was too hard on Freeglut. Two things about that: hey, maybe there
> is a small free lunch if a vendor adds some value to the Glut. More
> specifically, f/g allows me to put a window instance inside a pane of
> itself (or any other f/g window, but it was fun putting the window
> inside itself. That (I think) can be a performance boost, because the
> outer window (at least in the win32 freeglut) does not get a redisplay
> callback just because the inner window needs a redraw.
Why do I care? You haven't told us anything at all about what Cello
actually is, how it is constructed, what GUI model it uses, or anything
else that would lead an intelligent observer to conclude that this
person truly does have the code that he claims he has. Until such time
all of your prattling about FreeGLUT and ImageMagick is simply
meaningless.
> I do not know how easy that was, but I appreciate getting that out of
> the box.
I'd appreciate a forthright statement of what you actually have running
and built. Do you have a working version of Cello on any platform? If
so, is it an older version that you are planning on throwing away for a
rewrite? Code that you won't release doesn't count.
> Have you ever seen un-anti-aliased type? eeyeeuwww.
Yes, I have, and I dislike it as much as the next person. But whether
or not you have antialiased type does not help me or anyone else
determine whether you're trying to bullshit us on the bigger picture.
> Ok, that's two "liar!", one "what did I do to you to deserve this
> unjustified attack", and one weather forecast for Hell.
To this date I have not seen any evidence that the Cello code you are
talking about in the present tense actually exists. I am not trying to
accuse you of lying because I dislike you, but my conclusion based on
the evidence currently at hand is not very favorable. Based on my
experience with other promulgators of vaporware, Cello falls into the
classic pattern:
* Hype either the libraries you have written or the libraries others
have written, as it generates an impression of false progress and
potentially causes others to associate their good impression of those
libraries with your project. I couldn't care less if you wrote all the
code to draw the bits by hand so long as it did what you said it did.
* Speak ill of the (shipping) competition without providing any
/specific/ examples of the ways that your product is better than
theirs. You'd think that if you were just working on technical issues
in the implementation that you'd already have a fair idea of what the
API would look like and could provide some highly specific contrast to
the CLIM code people have been showing you.
* Misdirect by bringing up straw-man issues instead of providing
specific indication that you actually have a project in development. I
did not mention antialiased type myself; I merely said that the
libraries you were using did not convince me that you had written
working or workable code for Cello.
* And finally, get really really defensive.
I think it's fairly obvious what you need to do to convince me
otherwise. The best response to an accusation of not telling the truth
is to prove that you have been. You have not done so and have given no
indication that you will.
Brian
> :)
:( to see an advocate of CL fall into the same pattern as so many other
sleazy developers.
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
Brian Mastenbrook wrote:
> Not everyone has X11 installed. In addition the main GLUT will provide
> native menus. But GLUT has no conception of any other widget. You do
> know what GLUT does, right?
That controls the sound card, right?
> Why don't you brag about the new things that you are bringing to the
> field of lisp GUI design then...
Portability? Lisp "further the way down" than adopting an entire C/C++
framework? Object-reuse? Cells?
, or the new GUI model that Cells can
> provide...
Cells transcend GUI.
, or something /new/?
The goal is to give CL a standard GUI. That means portability across
OSes and implementations. So (aside from Cells, which transcend GUIs),
there is nothing new other than CL not having this now.
You're simply riding on the coattails of
> these other projects right now.
And lovin' it. I was just playing with FTGL again. Hellasweet.
> I'd appreciate a forthright statement of what you actually have running
> and built.
If you do not believe me now, why will you believe me then?
Do you have a working version of Cello on any platform?
Missed a couple of articles, didn't you?
> To this date I have not seen any evidence that the Cello code you are
> talking about in the present tense actually exists.
My reputation here on c.l.l?
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Ray Blaak wrote:
> Swing is getting unfair press, in my opinion. I have done full-blown syntax
> editors, as well as interactive drawing diagrams, all in swing, and the
> performance is quite snappy.
>
> The trick is avoiding "brute force" methods, and avoiding the built-in
> documents with their structured views.
>
> With smart data structures and lazy evaluation, things perform just fine.
Yes, me too. The problem is that the way to get good performance in
Swing is not to use it. If a Java monkey working in a GUI building IDE
follows the swing tutorials, then they end up with lots of tiny listener
classes that take forever to load, and document editors that run slowly.
If a coding shop manager wants to work with commodity programmers, then
the output of the tutorial level + 1 coder matters.
> Swing actually has a decent design. Parts of it suck, especially the
> structured document support, but the overall philosphy is sound.
Good design and sellability aren't that strongly correlated. I run OS X
at home but work on windows and irix, I use swing on all, and like it.
But the impression people get if they follow the book, and use the
recommended constructs and tools, is of slowness. Though that's more a
fault of the idea of commodity programmer and substituting tools and
frameworks for experience and invention, than it is of the technical
merit of Java.
Pete
pete kirkham <·················@cafemosaic.co.uk> writes:
> Maybe you need to convince someone in Apple that it's worth them
> supplying a binding of aqua to CLIM, rather than using the X
> binding. Except CLIM isn't a binary standard, so you're stuck
There is experimental code in McCLIM for that.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
In article <··············@plato.moon.paoloamoroso.it>,
Paolo Amoroso <·······@mclink.it> wrote:
> pete kirkham <·················@cafemosaic.co.uk> writes:
>
> > Maybe you need to convince someone in Apple that it's worth them
> > supplying a binding of aqua to CLIM, rather than using the X
> > binding. Except CLIM isn't a binary standard, so you're stuck
>
> There is experimental code in McCLIM for that.
>
>
> Paolo
I find the original remark you are responding to very confused.
Why should one need to convince someone in Apple to
provide an Aqua binding? Aqua is no secret.
Aqua is Mac OS X's user interface and accessible
through libraries, etc. These libraries are documented,
have an APIs, etc. Every interested developer can use
them.
LispWorks for example has an Aqua user interface
via the Cocoa libraries and MCL via the Carbon
libraries.
Several people have mentioned interest in an Aqua
based backend for McCLIM.
Usually CLIM is a layered architecture and it provides
some ideas to support native window systems even
when writing portable code. Much of CLIM itself
is written in a portable way. And then this code
needs a backend that maps it to the native
window system. This backend is some Lisp code that
provides windows, events, gadgets, etc. of the native
window system.
So, the same CLIM user code may look on on platform (say, X11)
ugly and on the next platform (say, Mac OS X) it may look much
better.
CLIM itself for the User is more like an abstract
(object-oriented) User Interface Management System (UIMS)
that provides common service that can be found
on many window systems. If some window system lacks some
capability, CLIM may need to provide the functionality
itself.
Much of the UIMS that CLIM provides is derived from
the Symbolics UIMS and Window System called
Dynamic Windows. Influences were also X11, Windows, Mac OS
and the Postscript imaging model. Lower levels
of the original CLIM implementation (the Silica layer)
have been provided by Xerox.
For all the stuff it provides, it lacks quite a lot
of things that are provided by modern user
interfaces. No wonder, not much has been done to
advance CLIM in the last ten years. Some of
the missing things are really *hard* to define
portably (fonts, etc.). Additionaly some
of its design is a bit CLOS heavy. Unfortunately
the original portable CLIM implementation has not
been Open Source - stagnation was the result.
Currently the McCLIM project develops an Open Source
reimplementation that will provide a new base
for experimentation and application development.
(Though for some larger amount of money the
CLIM source for MCL is available, and Open Genera
also comes with CLIM source).
For those, who are interested in a common, high-level
UIMS in Lisp (CLOS-based), McCLIM is a worthwile
effort. McCLIM is currently under active development.
Links:
McCLIM http://clim.mikemac.com/
McCLIM Wiki http://mcclim.cliki.net/index
McCLIM 2 Spec http://www.stud.uni-karlsruhe.de/~unk6/clim-spec/
CLIM Tutorial, Draft http://www.kantz.com/jason/clim-primer/index.htm
Rainer Joswig wrote:
>>pete kirkham <·················@cafemosaic.co.uk> writes:
>>
>>
>>>Maybe you need to convince someone in Apple that it's worth them
>>>supplying a binding of aqua to CLIM, rather than using the X
>>>binding. Except CLIM isn't a binary standard, so you're stuck
>>
>>There is experimental code in McCLIM for that.
>>
>>
>>Paolo
>
>
> I find the original remark you are responding to very confused.
> Why should one need to convince someone in Apple to
> provide an Aqua binding? Aqua is no secret.
> Aqua is Mac OS X's user interface and accessible
> through libraries, etc. These libraries are documented,
> have an APIs, etc. Every interested developer can use
> them.
So every CLIM ends up looking different, rather than behaving
predictably. If there was one Apple approved CLIM binding for OS X,
rather than Carbon, Cocoa and X11 bindings from various vendors, then
there wouldn't be a problem with different lisps looking different. Yes,
any developer could write it, which is why it needs to be Apple- if any
programmer can do something, then twenty programmers will do it, but
between each version will be slight incompatibilities and
inconsistancies. It's one thing having an interface manager looking
different on different OSes, but there's no reason why it has to look
different on the same OS.
Pete
In article <·························@news.dial.pipex.com>,
pete kirkham <·················@cafemosaic.co.uk> wrote:
> Rainer Joswig wrote:
>
> >>pete kirkham <·················@cafemosaic.co.uk> writes:
> >>
> >>
> >>>Maybe you need to convince someone in Apple that it's worth them
> >>>supplying a binding of aqua to CLIM, rather than using the X
> >>>binding. Except CLIM isn't a binary standard, so you're stuck
> >>
> >>There is experimental code in McCLIM for that.
> >>
> >>
> >>Paolo
> >
> >
> > I find the original remark you are responding to very confused.
> > Why should one need to convince someone in Apple to
> > provide an Aqua binding? Aqua is no secret.
> > Aqua is Mac OS X's user interface and accessible
> > through libraries, etc. These libraries are documented,
> > have an APIs, etc. Every interested developer can use
> > them.
>
> So every CLIM ends up looking different, rather than behaving
> predictably. If there was one Apple approved CLIM binding for OS X,
> rather than Carbon, Cocoa and X11 bindings from various vendors, then
> there wouldn't be a problem with different lisps looking different. Yes,
> any developer could write it, which is why it needs to be Apple- if any
> programmer can do something, then twenty programmers will do it, but
> between each version will be slight incompatibilities and
> inconsistancies. It's one thing having an interface manager looking
> different on different OSes, but there's no reason why it has to look
> different on the same OS.
Right, this sounds confused to me.
pete kirkham <·················@cafemosaic.co.uk> wrote in message news:<·························@news.dial.pipex.com>...
> Rainer Joswig wrote:
>
> >>pete kirkham <·················@cafemosaic.co.uk> writes:
> >>
> >>
> >>>Maybe you need to convince someone in Apple that it's worth them
> >>>supplying a binding of aqua to CLIM, rather than using the X
> >>>binding. Except CLIM isn't a binary standard, so you're stuck
> >>
> >>There is experimental code in McCLIM for that.
> >>
> >>
> >>Paolo
> >
> >
> > I find the original remark you are responding to very confused.
> > Why should one need to convince someone in Apple to
> > provide an Aqua binding? Aqua is no secret.
> > Aqua is Mac OS X's user interface and accessible
> > through libraries, etc. These libraries are documented,
> > have an APIs, etc. Every interested developer can use
> > them.
>
> So every CLIM ends up looking different, rather than behaving
> predictably.
As somebody who's attempting to write a Cocoa back end at the
moment, I'll put my perspective forward.
Firstly, on the above; if I do my job properly the behavior of
a CLIM app when running against McCLIM utilising my back end
will indeed be "predictable" for a given definition of predictable.
For example, would you expect a CLIM application running on Cocoa
to behave identically to the same CLIM application running on say
X11 on an IA32 platform in order to be predictable? Or would you
expect it to behave predictably for somebody who is used to using
the Cocoa UI?
I'm looking to create multiple look & feel realizers to cover
this off - the default CLIM realizer, which should "behave
predictably" from the pure CLIM perspective (complete with "looking
butt ugly" as some might have it - though this will get anti-aliasing
out of the box running through the Cocoa API, at least), and a Cocoa
realizer which will look and act more like a "native" Cocoa
application (i.e. "behave predictably" from the perspective of the
native environment).
> If there was one Apple approved CLIM binding for OS X,
> rather than Carbon, Cocoa and X11 bindings from various vendors, then
> there wouldn't be a problem with different lisps looking different. Yes,
> any developer could write it, which is why it needs to be Apple- if any
> programmer can do something, then twenty programmers will do it, but
> between each version will be slight incompatibilities and
There should be no incompatabilities, only eye-candy differences. If
there are twenty different back ends that all look different, and
possibly all behave slightly differently in some areas (for example -
I might write a back end that circumvents the "standard" menuing in
Cocoa, and another that does not. These may "behave" differently, by
your definition of unpredictability. They would certainly look different).
Does this matter? You then get the choice to pick what you want as
an application developer (including not to make a specific choice and
leave it up to the user instead).
Unless you decide to make use of implementation-specific functions in
my code (i.e. any functions I introduce to do my thing that aren't
mandated by the spec) then there should be no incompatabilities. If you
want to be compatible, stick to what's in the spec, and by changing the
back end you can get some look and feel differentiation without changing
your code at all (you can configure the back end you want to use at run
time). You may not even have to change the back end, depending on how
many realizers are implemented in a single back end. Just change the
realizer using (with-look-and-feel-realization). If you want to find
functions that break compatability (for whatever reason - efficiency
probably, stupidity maybe 8-) then tough. But this is a decision you
make during your implementation - it's not one that is encouraged.
> inconsistancies. It's one thing having an interface manager looking
> different on different OSes, but there's no reason why it has to look
> different on the same OS.
>
Is there any reason it shouldn't? Maybe you specifically *want* to look
different, and behave differently, to everything else available. How
else will you experiment with your new UI that's going to look space-age
and provide untold usability improvements? Different people have different
needs, and I for one value diversity.
-Duncan
>
> Pete
pete kirkham <·················@cafemosaic.co.uk> writes:
> So every CLIM ends up looking different, rather than behaving
> predictably.
I'm not exactly sure how this statement is supposed to make sense. The
whole point of CLIM is that no matter how it looks, it'll behave
similarly. Also, the native gadgets are only used for cases where
they're asked for. You don't ask for a "Windows scrollbar" or a "MacOS X
menu" in CLIM. You ask for a scrollbar or a menu. The backend takes care
of making that look like it's supposed to look like on your host system.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<·················@nyc.rr.com>...
> Timothy Moore wrote:
> >
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> > > Timothy Moore wrote:
> > > >
> > > > Selected from where? Do you have a Cello REPL where I can see this in
> > > > action?
> > >
> > > I have an object inspector that will be one of the example apps when
> > > Cello ships. I still have not heard much about the CLIM repl. I gather
> > > it Ls, Rs, Es, and then Ps a (scrolling?) graphical display of the
> > > result. I am guessing there is the default form which is a label showing
> > > princ output and that this label is also a control you can double-click
> > > to inspect, option-click to somehow drop in the next form to be read...
> > > I was asking to see if I wanted to do a Cello REPL as an example app.
> >
> > http://www.bricoworks.com/moore/mcclim.html has an example of the Listener in
> > action.
> >
>
> Thanks. Someone else sent me links to Rainer's (?) movies. Y'all need to
> learn about marketing. Still butt ugly. And if CLIM is such a powerful
> GUI, it should take 10 minutes to jazz it up. Statements like this from
> the link above make me wonder if Lispniks have lost the ability to
> communicate with non-Lispniks:
>
> "It has many features, but here's one that's especially exciting for
> Lisp programmers: anything that is printed can be used as input when
> typing a form, even if its printed representation isn't readable."
>
> This is what all the CLIM repl excitement is about? puh-leez! If this is
> what we try to impress the world with (even the CL world), it shows we
> need to get out more.
When somebody at work asked me what the CLIM listener was I described
it to them as a graphical xterm that allows you to inline wigits and display
graphical elements as well as text, and where all those things displayed
can be used as inputs to commands entered in the "terminal" on a
contextual basis just by clicking on them.
Ok, it's an oversimplification, and without mentioning the REPL, but this
was for a collegue who knew UN*X but not Lisp - so throwing the REPL on
top should just make it even nicer for Lisp-aware folks.
(with-own-trumpet-blowing
"I think with a little work (and possibly some examples) this description
might give some people (i.e. non-Lisp, UN*X aware people) a bit of a clue.")
-Duncan
>
> kenny
Kenny Tilton <·······@nyc.rr.com> writes:
> Y'all need to
> learn about marketing. Still butt ugly.
We have been through this before, it seems. I personally do not care
if I am the only one using CLIM. Spending energy on marketing would
take away energy from more urgent needs. I have complete confidence
in members of the Lisp community to realize this, and to see that
perceived ugliness is easy to fix by most people with elementary
knowledge of Common Lisp, whereas the hard architecture questions are
best handled by the people who have been involved in development for a
while.
> And if CLIM is such a powerful
> GUI, it should take 10 minutes to jazz it up. Statements like this from
> the link above make me wonder if Lispniks have lost the ability to
> communicate with non-Lispniks:
>
> "It has many features, but here's one that's especially exciting for
> Lisp programmers: anything that is printed can be used as input when
> typing a form, even if its printed representation isn't readable."
>
> This is what all the CLIM repl excitement is about? puh-leez! If this is
> what we try to impress the world with (even the CL world), it shows we
> need to get out more.
I really do not understand why you care. If you are so convinced that
CLIM is inferior to what you suggest as a replacement, why is it so
important to you to criticize it? You should be able to count on the
intelligence of members of the Common Lisp community to come to the
same conclusion.
And we are not trying to impress the world, not even the entire CL
world. We are (at least I am) perfectly happy to impress people who
appreciate the beauty of CLIM. And even if _they_ are not impressed,
_we_ are, and that is enough for me. You are not part of the set of
people we try to impress, so whether you are impressed or not is of no
importance. Attacking us for not being impressive enough is attacking
a straw man created by your imagination.
I really cannot understand the purpose of these attacks. Have we done
anything to offend you? If I have said anything that could be
interpreted as an attack on you or your software, I sincerely
apologize. Are you saying we are not allowed to work on what we want?
Implementing (part of) McCLIM has been a fantastic experience to me.
I have learned a lot about object-oriented programming in Common Lisp,
about how expert Common Lisp programmers think about software design,
and more generally about software architecture. By making the result
of this exercise available to others I somehow deserve these attacks?
--
Robert Strandh
Robert STRANDH wrote:
> I really do not understand why you care.
Care? This is a Usenet bull session. I said something nasty about people
wasting their time on CLIM, and here we are, hopefully discussing the
merits of the package. Folks working on it have defended it for its
power, saying it is worth the (sometimes) admitted learning curve. This
has led to a side exchange of whether hard-to-learn is always bad (my
position, quantum mechanics aside).
> If you are so convinced that
> CLIM is inferior to what you suggest as a replacement, why is it so
> important to you to criticize it?
I am asking, not telling. I have looked at the CLIM doc, and was pumped
by some of the power I saw there, but others here said not to bother
(with reasons I had started to suspect), so that's as far as I got. Now
McCLIM developers are defending it while unhappy users are sending me
emails saying CLIM sucks.
When I dissed Lispworks recently I got dope-slapped by a number of users
(digression: and in fact I will possibly use it if Cello cannot be made
to hunt on Mac OS X). As this thread drags on, I keep expecting
testimonials to CLIM to appear. Or I expect a CLIM developer to whip up
a snazzy screen in ten minutes, post the GIF, and tell me to shut the
fuck up.
Aint happenin.
> I really cannot understand the purpose of these attacks. Have we done
> anything to offend you?
Just this bit, where you try to cast a discussion of CLIM as a
psychological problem of mine. :)
We software developers work very hard on our products, and so of course
end up with a strong emotional connect with them. I have not enjoyed
this CLIM-bashing, because I know you have put a lot of good work into
it and are a bit of a "proud papa" and I know my /objective/ assessments
are offensive to you on a personal level. And you are a good guy, IIRC
from a recent ILC, so it is doubly distasteful having CLIM as my chew
toy du semaine.
But McCLIM (I guess) wants to be taken seriously as a portable CL gui,
and you have stepped up to defend it, so I elect to continue despite my
discomfort with dissing you implicitly.
You are making points in good faith, as am I. I am sorry they do not go
the way you like, but as far as I can make out from private
communications, I am not missing the mark by much.
There is no vendetta. I am totally open to evidence of McCLIM's
brilliance. I was honestly delighted to hear it had a new poster child
to replace the address book, only to discover the CLIM repl is just as
ugly as ever, and no more powerful than something I once tossed off in a
day.
The defenses I am hearing are "yes! it is hard to learn! so what!" and
"yes! it is ugly! so what!". I guess the good news we can end this
thread in near perfect agreement.
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Robert STRANDH wrote:
>
> > If you are so convinced that
> > CLIM is inferior to what you suggest as a replacement, why is it so
> > important to you to criticize it?
>
> I am asking, not telling. I have looked at the CLIM doc, and was
> pumped by some of the power I saw there, but others here said not to
> bother (with reasons I had started to suspect), so that's as far as I
> got. Now McCLIM developers are defending it while unhappy users are
> sending me emails saying CLIM sucks.
You're stepping awfully close to the territory of professional Usenet
trolls. Private mail supporting your position? Check...
...
> be made to hunt on Mac OS X). As this thread drags on, I keep
> expecting testimonials to CLIM to appear. Or I expect a CLIM developer
> to whip up a snazzy screen in ten minutes, post the GIF, and tell me
> to shut the fuck up.
>
> Aint happenin.
Part of that is about to :)
...
> There is no vendetta. I am totally open to evidence of McCLIM's
> brilliance. I was honestly delighted to hear it had a new poster child
> to replace the address book, only to discover the CLIM repl is just as
> ugly as ever, and no more powerful than something I once tossed off in
> a day.
Hah. I whipped up my stupid web page as an illustration
because I suspected that we were talking past each other. We
apparently still are, but it's hard to tell what exactly we are
talking about because our code is out there and yours is not. I'm not
in a position to try your stuff; you can, but instead you choose to
focus on screenshots and tell war stories. Your one day toss-off
seems to have implemented the P part of a REPL, and I'm sure was
beautiful, but who knows?
I find your suggestions (not just in this thread) that we've been
wasting our time on McCLIM fairly uh, incongruous. You've carried on a
breathless soliloquy with this group about Cello for a year as you
wander off to ever more impractical targets. I mean, ImageMagick? WTF?
I want to be at that meeting. Get your head out of the aether, shut the fuck
up, and write some code :)
> The defenses I am hearing are "yes! it is hard to learn! so what!" and
> "yes! it is ugly! so what!". I guess the good news we can end this
> thread in near perfect agreement.
I'm sure.
Tim
Timothy Moore wrote:
> You're stepping awfully close to the territory of professional Usenet
> trolls. Private mail supporting your position? Check...
<heh-heh> You got me on that one. But can you blame them? Now you are
calling me a liar, right? Who wants to deal with that kind of abuse just
to share their feelings about CLIM? (When I dissed CLIM I thought I
might take some heat, but I never expected the Spanish Inquisition.)
And I do not think any of them is any happier than I am breaking the
news to you soccer moms about your little project. jeez, no wonder they
do not let parents attend practices!
> Hah. I whipped up my stupid web page as an illustration
> because I suspected that we were talking past each other. We
> apparently still are, but it's hard to tell what exactly we are
> talking about because our code is out there and yours is not.
? We are talking about CLIM being hard to program and ugly, what has
that got to do with Cello shipping?
> I find your suggestions (not just in this thread) that we've been
> wasting our time on McCLIM fairly uh, incongruous. You've carried on a
> breathless soliloquy with this group about Cello for a year as you
> wander off to ever more impractical targets.
RoboCup was fun! But it did kill a few months, as did training for a
sporting event, which was a lot friendlier than c.l.l. now that I think
about it.
> I mean, ImageMagick? WTF?
Bad choice? What is wrong with it? The list looks insanely active, and a
lot of it works for me. One or two functions did not, but I have not
been to the list to ask about those. What about GraphicsMagick? Better,
worse?
Besides, no one says you have to use i/m, you can just do native OpenGL
if you like.
Well, thanks for calling me a liar. My record here on c.l.l. totally
justifies that. You CLIMers have really hit bottom. I hope!
Wouldn't it be easier just to join the Cello project? I need help with
graphic design.
:)
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> ? We are talking about CLIM being hard to program and ugly, what has
> that got to do with Cello shipping?
Simply that if you can "toss off" all the hard bits of clim in a
one-day hack, and you've abdicated the graphic design bit anyway, you
should have something we can see by now. So, where is the code?
> Wouldn't it be easier just to join the Cello project? I need help with
> graphic design.
I hear that the weather in NY has been a bit chilly lately, but that
on its own is not sufficient to satisfy the "hell freezes over"
criterion
-dan
Daniel Barlow <···@telent.net> writes:
> I hear that the weather in NY has been a bit chilly lately, but that
> on its own is not sufficient to satisfy the "hell freezes over"
> criterion
FWIW, I can testify that Hell's Kitchen was definitely frozen over. The
wind was also horrendous.
In any case, I'm sorry for speaking about CLIM in Kenny's presence at
the first LispNYC meeting I attended.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
* Kenny Tilton -> Timothy Moore
| Now you are calling me a liar, right?
No, he pointed out that only people who have no regard for the ability
of others to examine the truth of a statement, refer to private mail
in support of their public position.
| Who wants to deal with that kind of abuse just to share their feelings
| about CLIM?
The only abuse you see is of your own invention. As always, in fact.
A written text has no power to abuse you. It is a dead string of bits
that needs an interpreter before it has any meaning. That interpreter
is you, and you have to accept responsibility for your interpretation.
If you fail to do this, you will believe that other people said what
you interpreted it to mean, and it becomes impossible for anyone to
show you that you interpreted it wrongly. This is just like those UFO
sighting programs on Discovery Channel, where people claim that they
saw something and when somebody else points out that it was not what
they thought they saw, these interminabely retarded people claim that
scientists and skeptics deny what they saw. I mean, sensory evidence,
man! What are you going to trust? Your own eyes or some scientist
who wasn't even there?
| But it did kill a few months, as did training for a sporting event,
| which was a lot friendlier than c.l.l. now that I think about it.
Dude, comp.lang.lisp is a collection of texts. It has no capacity to
be friendly or hostile. There is simply not enough information here
to give rise to any such things. If you think you see it, it can only
be because you are willing to fill in all the blanks and flesh out an
impression with all sorts of extrapolations. This is not like people
who communicate in real life, with faces and voices and body language.
This is nothing more than sterile, dead words that come to life only
because you breathe life into them. If you look for friendliness, you
will breathe friendly life into them. If you look for hostility, you
will breathe hostile life into them. If you look for abusiveness, you
will breathe abusive life into them. If you look for humorous content
and are prepared to regard incongruities as funny, you will find a lot
of warm, intelligent humor here. If you are dead serious and lack a
sense of humor on your own, incongruities are insulting, harmful, and
in need of revengeful responses.
We had a lot of people here in the past who came to comp.lang.lisp
with their minds firmly set in their hostile expectations, who saw
every single utterance as evidence of hostility. In real life, people
who have this kind of mental disorder face a large number of strong
correctives via their non-verbal senses, but something is missing in
people who are unable to produce the same correctives on their own
from the texts that they read. Some people are /inept/ at producing
their own correctives and need other people who actually hold their
hands or shoulders and deliver the correctives through body heat.
Look at the word �corrective�, which some people respond to as if it
can only mean punishment through infliction of pain. A smile is a
corrective action when some person misreads a joke. A body hug is a
corrective action when some person misreads group acceptance rituals.
People who believe that correctives are painful were most probably
damaged by extremely harsh conditions during their formative years,
during which they never learned that correctives are never a statement
of personal like or dislike, but an expression of a desire for them to
improve. Those who deliver correctives through words on the Net, have
a right to expect that the recipient is able to process correctives in
an intelligent way. All kinds of information that contradicts beliefs
or previous statements have a core purpose of improving the state of
the public information, and this must always be regarded as good.
However, some people are broken. They probably never experienced that
accepting correctives led to better relations with other people, and
so they have come to believe that doing something harmful and stupid
on purpose is a good way of showing someone else that it is a harmful
and stupid thing to do, but this kind of �corrective� has never worked
in all of human history. It is the kind of retarded coping strategy
that people who never understood that if you do not care enough about
the improvement of someone you give a corrective to want to see it
through, you should refrain from delivering the corrective altogether.
In all likelihood, these people were damaged during their formative
years because they received correctives with no follow-up concern and
the only thing they ever learned was that they had done something bad
and wrong, which they could not process. Almost all the people who
have gone ballistic here and elsewhere on Usenet when they are told
that they are mistaken in one way or another, exhibit serious problems
in this regard, and they lack the focus on their self-improvement and
probably any other purpose that would mean they would appreciate the
correctives. Many of these people walk out into the great wide open
and speak only for a single person: They want others to like them, and
they say things that they believe will cause others to accept them as
members of their tribe. A corrective to such insufficient people will
be interpreted as rejection from the tribe, and if they think they had
deserved to be members of the tribe, they attack the tribe member that
has unfairely rejected them, while in reality, and as self-sufficient
people immediately observe, the corrective is a welcoming message to
the tribe. If, however, you have an emotional deficit and demand that
other people provide you with what you lack, you will necessarily find
that people who refuse to give you anything of what you so desperately
need, are hostile. If you have an emotional surplus, you do not need
other people to provide you with what you do not lack, and so you have
no need to engage in this practice with others, either.
The more we learn about the psychology of team-building, the more we
realize that people with a similar lack or similar surplus of self-
sufficiency are able to team up and work together, while teams where
people have wildy disparate self-sufficiency turn into cat fights and
exhibits of the constant need of those with a relative deficit of
self-sufficiency to prove their position relative to the other team
members, while those with a relative surplus of self-sufficiency want
nothing to do with those with a deficit because they get nothing back
from being around them. The best team-building methodology has been
found to be to help every team member increase his self-sufficiency to
the point where dependence on constant infusion of �respect� and the
like to cover the running deficit, vanishes completely. This is in
sharp contrast to the traditional belief that the best teams exhibit a
strong interdependency between team members, and it does not take much
thinking to realize that in such a system, if anyone starts to feel
that they have been more �giving� and others more �receiving�, they
will stop giving and start to be demanding, instead. In a team where
nobody is /needy/, however, the universal surplus means that nobody is
in a position to demand that others take care of them, and they can
focus on their stated purpose, as well as play and joke and take care
of anyone who should suffer a temporary loss. It is therefore vitally
important for a group of people who wish to cooperate over the long
haul to ensure that no one is allowed to exhibit an emotional deficit
that others are somehow obliged to make up for. Especially for such a
loosely coupled group as a newsgroup, where people communicate for but
a few hours a day, at best (or perhaps worst :), everybody needs to
make sure their emotional needs are satisfied before they venture out
into an environment that cannot have any duty to fulfill their needs.
In other words, Kenny, newsgroups are only as friendly as you decide
to make them with your own contributions. If you start to exhibit a
need for others to be friendly towards you, you will necessarily start
to believe that absence of friendliness is equivalent to presence of
hostility, just like a bunch of neurotics have done here in the past.
| Well, thanks for calling me a liar. My record here on c.l.l. totally
| justifies that. You CLIMers have really hit bottom. I hope!
Notice how I completely fail to care about your faux guilt trip.
--
Erik Naggum | Oslo, Norway 2004-031
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Kenny Tilton <·······@nyc.rr.com> writes:
> Timothy Moore wrote:
>
> > You're stepping awfully close to the territory of professional Usenet
> > trolls. Private mail supporting your position? Check...
>
> <heh-heh> You got me on that one. But can you blame them? Now you are
> calling me a liar, right? Who wants to deal with that kind of abuse
> just to share their feelings about CLIM? (When I dissed CLIM I thought
> I might take some heat, but I never expected the Spanish Inquisition.)
No, I'm not calling you a liar. People have been griping for years
about CLIM (check out the archives of the CLIM mailing list sometime),
but only you get heaped with abuse, because you deserve it :) I
believe that you get emails critical of CLIM, but why bring them up?
It makes for an extremely unpleasant, unproductive "conversation."
"I've got 50 names in my book, right here...."
> > Hah. I whipped up my stupid web page as an illustration
> > because I suspected that we were talking past each other. We
> > apparently still are, but it's hard to tell what exactly we are
> > talking about because our code is out there and yours is not.
>
> ? We are talking about CLIM being hard to program and ugly, what has
> that got to do with Cello shipping?
The conversation so far has gone something like this. You say that
you find the CLIM spec baroque, the examples ugly, and you don't see
what the fuss is all about (and apologies in advance if I'm
mischaracterizing your statements). I, and others, have tried to
provide examples of the things we like in CLIM, but your response has
been trash talk: it's still butt ugly, I whipped that up in an
afternoon, and besides Cello is much better. OK, why should I believe you?
After all, you've just asserted that something I like sucks, and I
don't get it. How can I tell that Cello is much better? Where do I see
it in action, its APIs, or even a sample application? Aren't you
interested in the opinion of experienced Lispers on Cello? How might I
be persuaded that CLIM sucks compared to Cello? It's like talking to a
fog bank.
To return to civility for a minute, if you care to answer: why is a
constraint / slot daemon driven interface system better than a
presentation based interface system?
> > I mean, ImageMagick? WTF?
>
> Bad choice? What is wrong with it? The list looks insanely active, and
> a lot of it works for me. One or two functions did not, but I have not
> been to the list to ask about those. What about GraphicsMagick?
> Better, worse?
I can't imagine why you're using it. In my experience ImageMagick is
slow, its treatment of transparency is bizzare, and the interface is
unpleasant. I don't know anything about GraphicsMagick, though at
first glance it looks like more of the same (two can play this game :)
OpenGL? good choice, I think that makes a fine target for a GUI. FTGL?
Sure, why not, though it seems like a distraction. But I don't get how one
can put "OpenGL, FTGL, and ImageMagick" in the same sentence.
> Besides, no one says you have to use i/m, you can just do native
> OpenGL if you like.
I don't have to use anything. I thought you were the one using these
libraries.
> Well, thanks for calling me a liar. My record here on c.l.l. totally
> justifies that. You CLIMers have really hit bottom. I hope!
Yup, I'm sprawled in the gutter drinking a cheap Pessac Leognan as I
write this. Good thing Bordeaux has excellent wireless coverage.
>
> Wouldn't it be easier just to join the Cello project? I need help with
> graphic design.
>
> :)
How? Where?
Tim
Timothy Moore wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Timothy Moore wrote:
>>
>>
>>>You're stepping awfully close to the territory of professional Usenet
>>>trolls. Private mail supporting your position? Check...
>>
>><heh-heh> You got me on that one. But can you blame them? Now you are
>>calling me a liar, right? Who wants to deal with that kind of abuse
>>just to share their feelings about CLIM? (When I dissed CLIM I thought
>>I might take some heat, but I never expected the Spanish Inquisition.)
>
>
> No, I'm not calling you a liar. People have been griping for years
> about CLIM (check out the archives of the CLIM mailing list sometime),
> but only you get heaped with abuse, because you deserve it :)
The Savages of C.L.L!
I
> believe that you get emails critical of CLIM, but why bring them up?
Robert (not me) stopped talking about CLIM to suggest I might be trying
to settle a score <groan>, and that opens the door to evidence that it
ain't just me. I would be delighted to be discussing CLIM on its merits
(tho methinks that horse dead) instead of counting chads.
> afternoon, and besides Cello is much better. OK, why should I believe you?
> After all, you've just asserted that something I like sucks, and I
> don't get it. How can I tell that Cello is much better? Where do I see
> it in action, its APIs, or even a sample application? Aren't you
> interested in the opinion of experienced Lispers on Cello? How might I
> be persuaded that CLIM sucks compared to Cello?
While I offer Cello as a contrast, in the end the question of interest
is why CLIM has failed. ie, If I did not have Cello, I would not use
CLIM, nor apparently would many others. What went wrong?
> To return to civility for a minute, if you care to answer: why is a
> constraint / slot daemon driven interface system better than a
> presentation based interface system?
Unfortunately not enough information on CLIM has made it into this
thread for me to understand why, as Robert concedes, CLIM is so hard to
master or why cosmetics are so hard they have to be deferred, so how can
I compare?
My musings on why Cells are so effective are in one of the half-baked
PDFs on my site. In brief, (1) the instance-orientation of slot-specific
rules is very empowering (object reuse becomes a reality) (2) think
about all the ways Visicalc is better than a paper spreadsheet (the
biggy being the way spreadsheets decompose complexity--even in th emost
complex model, no rule samples more than a few other cells).
>>>I mean, ImageMagick? WTF?
>>
>>Bad choice? What is wrong with it? The list looks insanely active, and
>>a lot of it works for me. One or two functions did not, but I have not
>>been to the list to ask about those. What about GraphicsMagick?
>>Better, worse?
>
>
> I can't imagine why you're using it.
Originally to load and display JPEGs, GIFs, et al. Then it looked as if
it would be a much easier way to do graphics than OpenGL.
> In my experience ImageMagick is
> slow, its treatment of transparency is bizzare, and the interface is
> unpleasant.
Thx for the head's up. I'll watch out for "slow". Transparency? I don't
need that. I know Apple has popularized it. But don't they just give
textures to OpenGL and let it do the transparency? (I made all that up,
this OpenGL stuff is all new to me.)
As for the interface, have you seen the new "wand" API? I have never
seen anything so simple, tho I have only played so far with a dozen diff
effects.
I don't know anything about GraphicsMagick, though at
> first glance it looks like more of the same (two can play this game :)
> OpenGL? good choice, I think that makes a fine target for a GUI. FTGL?
> Sure, why not, though it seems like a distraction.
Hunh? Nice-looking, portable, fast, antialiased type in a few lines of
user code is a distraction? For a GUI? Bitmap, pixmap, texture, outline,
polygon, and extruded polygon for free? Don't tell me you like the GLUT
font mechanism. :)
Of course I got into this bind by making OpenGL my low-level graphics
engine, but that is looking like a much better move thx to FTGL.
> But I don't get how one
> can put "OpenGL, FTGL, and ImageMagick" in the same sentence.
Well how do /you/ do anti-aliased type in OpenGL. wgl/agl/xgl? I had
wglFonts at first, but FTGL is faster, more portable yada yada. As for
I/M, how do you load JPEGs etc and skew/crop/scale/skew/blur/despeckle
etc etc? I'd be happy to look at new approaches for Cello.
> How? Where?
Currently we are waiting for the first sighting of Cello running with
Freeglut under X11 from CMUCL/SBCL. Until then, it's not Cello. When
that happens I will open a Cello project on common-lisp.net and make an
announcement here.
As for that X11 effort, Thomas is hard at it these days. I am heading
out for ten days, inluding a win32-only ~Cello presentation in Boulder.
when I get back I will look at LW+OSX+Cello if nothing has happened on
the Linux front.
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
> While I offer Cello as a contrast, in the end the question of interest
> is why CLIM has failed. ie, If I did not have Cello, I would not use
> CLIM, nor apparently would many others. What went wrong?
No; the first question of interest is *whether* CLIM has
failed.
--
Gareth McCaughan
.sig under construc
>>>>> "KT" == Kenny Tilton <·······@nyc.rr.com> writes:
[on imagemagick]
KT> Originally to load and display JPEGs, GIFs, et al. Then it
KT> looked as if it would be a much easier way to do graphics than
KT> OpenGL.
Imagemagick is a far different beast than opengl. I'd have ffi'ed out to
libjpeg and libpng for image loading, but it seems you want extra image
processing stuff there too. As for doing 'graphics' with it, I don't
know what you mean. Do you mean using it as a graphics substrate to
build your widgets on? If so, that'll probably be incomparably slow and
complicated comprated to opengl for anything 3D-ish.
[..]
KT> Thx for the head's up. I'll watch out for
KT> "slow". Transparency? I don't need that. [...]
You pretty much have it for free if you integrate opengl.
[...]
KT> Well how do /you/ do anti-aliased type in OpenGL. wgl/agl/xgl? [...]
I had a need like that a couple of weeks ago. I ended up using the
Hershey fonts with OpenGL's built-in line anti-aliasing. It isn't
ugly, but my needs were minimal. On the plus side you get reasonable
looking fonts completely from within lisp (Hersey fonts are available
as ASCII 'lists of lines' files that you can just include in your dumped
image). On the minus side you get a limited set of fonts and only in
unfilled line form.
KT> ... I am
KT> heading out for ten days, inluding a win32-only ~Cello
KT> presentation in Boulder. ...
Can you get that taped and put up an mpeg somewhere?
cheers,
BM
Bulent Murtezaoglu wrote:
>>>>>>"KT" == Kenny Tilton <·······@nyc.rr.com> writes:
>
> [on imagemagick]
> KT> Originally to load and display JPEGs, GIFs, et al. Then it
> KT> looked as if it would be a much easier way to do graphics than
> KT> OpenGL.
>
> Imagemagick is a far different beast than opengl. I'd have ffi'ed out to
> libjpeg and libpng for image loading, but it seems you want extra image
> processing stuff there too. As for doing 'graphics' with it, I don't
> know what you mean. Do you mean using it as a graphics substrate to
> build your widgets on? If so, that'll probably be incomparably slow and
> complicated comprated to opengl for anything 3D-ish.
Ok, so to do 3D buttons I should stick with what I do now, viz., build
them with polygons and turn on lighting? I do get a kick out of doing it
that way, but I need to disclose a hidden agenda:
It /would/ be nice to deliver a portable GUI/app framework of choice for
CL. Right now, printing aside, we have the technology. Cello can do it.
(I'll have to do a PS or PDF backend for printing.) Anyway, there is
still one problem (my hidden agenda): ease of learning/use.
I think the doc for glDrawPixels says it all for me. Not sure I
understand a word of it. So I have been concerned that Cello would be
portable and powerful but too hard to use. I was thinking I would have
to build an entire friendly layer, well, that does what I/M does.
Hey, what if I do this (which I plan to do anyway).
(1) Use an I/M function to do a simulated 3d effect in pixels.
(2) Convert that to a gl texture (forgive any glaring technical gaffes,
I am just swiping code and monkey-typing till it works with little
understanding of the deets) private to the widget.
(3) re-do the above only if the appearance of the widget changes.
(4) when redisplaying, just sweep the gui hierarchy using glDrawPixels
to dump the textures into opengl. or have an invalidation scheme in
which the window keeps a texture and info as to which sections of that
texture need to be refreshed, so only those widgets overlapping the
invalid region get re-rendered into the window texture, which then gets
written to opengl.
I just think I/M (or GraphicsMagick, its clone) will be an order of
magnitude easier to work with.
>
> [..]
> KT> Thx for the head's up. I'll watch out for
> KT> "slow". Transparency? I don't need that. [...]
>
> You pretty much have it for free if you integrate opengl.
yep.
> image). On the minus side you get a limited set of fonts and only in
> unfilled line form.
if your needs change I really recommend FTGL. It is C++, but the glue (I
can send you mine) was trivial. And I have another confession:
I also want Cello to be as good compared to other GUIs as Lisp is to
other languages. I think then it has to offer push-button access to any
installed font (well, TrueType/FreeType anyway).
>
> KT> ... I am
> KT> heading out for ten days, inluding a win32-only ~Cello
> KT> presentation in Boulder. ...
>
> Can you get that taped and put up an mpeg somewhere?
Saturday will be me ranting away, beer in hand, possibly with a laptop
with some funny screens propped up on a bowl of peanuts to stay dry,
mostly about Cells. Don't know if Boulder is CLIM turf, but if you see a
lot of motorcycles pull up, head for the back door. :)
Monday will be more filmable, but it will be a hands-on lesson in
(mostly) Cells and the Cello coordinate system. And it will be my first.
Probably I should polish that a little before making a movie? I will at
least upload a win32 Cello for Boulderites to play with and mention that
here. Then... is web-based video instruction hard?
And where are you located? The Cello World Tour is just gearing up.
Thx for the input on opengl et al.
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
>>>>> "KT" == Kenny Tilton <·······@nyc.rr.com> writes:
[...]
KT> Ok, so to do 3D buttons I should stick with what I do now,
KT> viz., build them with polygons and turn on lighting?
Yeah (that's what I'd do given that I had to do it in opengl). What
you lose by doing standard widgets with opengl is that it will look
odd in all platforms. Doubly so is the platform is themable. I do
like it that you are doing it in opengl though as I suspect you will
come up with neat abstractions that encapsulate lispy tricks to do
real 3D stuff. (that's my hidden agenda)
[...]
KT> It /would/ be nice to deliver a portable GUI/app framework of
KT> choice for CL. Right now, printing aside, we have the
KT> technology. Cello can do it. (I'll have to do a PS or PDF
KT> backend for printing.) Anyway, there is still one problem (my
KT> hidden agenda): ease of learning/use.
I think that can be taken care of by proving reasonable defaults, and
by exposing a limited but adequate subset with some boilerplate code
for conventional stuff (as in providing short code with the comment
'here's how you can do a canvas surrounded by a toolbar and a standard
menu bar') Please do not cripple it, though, while trying to make
newbies feel comfortable.
KT> I think the doc for glDrawPixels says it all for me. Not sure
KT> I understand a word of it.
Aw c'mon (just looked it up). If you skimmed the standard opengl book
(I don't have it handy I think it has a lego earth on it) it should be
familiar. (hints for the non-obvious parameters: usually you use
RGBA, you need to know how your pixel/color data is laid out in
memory, and obviously you need to know the width, height and _where_
your pixel data is!). If you will expose this to your user and are
worried about the number of parameters, standardize on RGBA and some
memory layout for pixels in other functions; expose width, height and
the pixel data array as arguments and make the rest defaulted
keywords. You _can_ simplify things like that in Lisp much easier
than you can in C.
[...]
KT> (1) Use an I/M function to do a simulated 3d effect in pixels.
KT> (2) Convert that to a gl texture (forgive any glaring
KT> technical gaffes, I am just swiping code and monkey-typing
KT> till it works with little understanding of the deets) private
KT> to the widget.
If these are standard buttons and such I'd just do the textures once
and ship them with the library. No need to generate them at runtime.
KT> (3) re-do the above only if the appearance of
KT> the widget changes.
I don't see how the texture can change unless you provide the users
with texture-generating functions. If the color or the text changes
or another predefined texture is selected this can all be done without
using imagemagick at runtime. Now I suspect you are thinking about
taking a shortcut and just generating the geometric object in Opengl
and using textures to give it visual attributes. You need to tell us
why, before we can help you (I am no OpenGL guru, others might have
better ideas. also try the opengl newsgroup).
KT> (4) when redisplaying, just sweep the gui
KT> hierarchy using glDrawPixels to dump the textures into
KT> opengl.
No. Don't do it that way. You'll lose any acceleration the hardware
gives you. Make display lists for the objects when you crate them and
call those as you sweep your hierarchy. If you want to use textures
wrapped on OpenGL polygons, you still do that.
KT> or have an invalidation scheme in which the window
KT> keeps a texture and info as to which sections of that texture
KT> need to be refreshed, so only those widgets overlapping the
KT> invalid region get re-rendered into the window texture, which
KT> then gets written to opengl.
I'd start by not worrying about invalidating rectangles in windows.
Just redraw the entire thing until you are comfortable with your code
(and coding under opengl). Again, you are thinking in terms of
maintaining your own frame buffer. That's not a good way to think.
Textures or not, let OpenGL work on the framebuffer.
KT> I just think I/M (or GraphicsMagick, its clone) will be an
KT> order of magnitude easier to work with.
I think you are solving the wrong problem with this. But I may be
misunderstanding.
[...]
KT> if your needs change I really recommend FTGL. It is C++, but
KT> the glue (I can send you mine) was trivial.
I'll get in touch off the NG when it comes to that.
[...]
KT> I also want Cello to be as good compared to other GUIs as Lisp
KT> is to other languages. I think then it has to offer
KT> push-button access to any installed font (well,
KT> TrueType/FreeType anyway).
One complication: your need to watch out for is missing fonts. You need
a way to get people similar fonts and a way for the programmer to specify
fonts with wild-cards (remember you are cross-platform)
[...]
KT> Monday will be more filmable, but it will be a hands-on lesson
KT> in (mostly) Cells and the Cello coordinate system. And it will
KT> be my first. Probably I should polish that a little before
KT> making a movie? I will at least upload a win32 Cello for
KT> Boulderites to play with and mention that here. Then... is
KT> web-based video instruction hard?
I haven't seen any great systems but I haven't looked very hard. I'd
look into something like SMIL and have the thing be non-streaming (ie
just make it downloadable and useable w/o being connected). I don't
know anything widely available other than the real player that can do
SMIL though.
KT> And where are you located? The Cello World Tour is just
KT> gearing up.
I don't think you can easily make it here. I am presently in
Istanbul, Turkey. I'll be back in the US (Western NY prolly), at some
point within the next 18 mo. I'll come watch it in NYC when I do. Or
we can do a Lisp conference here (I suggested this in CLL, within
days Al Queda blew people up here, so if we don't do it the terrorists
will have won!).
cheers,
BM
Bulent Murtezaoglu wrote:
>>>>>>"KT" == Kenny Tilton <·······@nyc.rr.com> writes:
>
> [...]
> KT> Ok, so to do 3D buttons I should stick with what I do now,
> KT> viz., build them with polygons and turn on lighting?
>
> Yeah (that's what I'd do given that I had to do it in opengl). What
> you lose by doing standard widgets with opengl is that it will look
> odd in all platforms. Doubly so is the platform is themable. I do
> like it that you are doing it in opengl though as I suspect you will
> come up with neat abstractions that encapsulate lispy tricks to do
> real 3D stuff. (that's my hidden agenda)
Yes, my first reaction on seeing OpenGL up close and personal was that
it could be a killer app for CL, because there were so many
opportunities to simplify that very tricky but powerful library.
> KT> backend for printing.) Anyway, there is still one problem (my
> KT> hidden agenda): ease of learning/use.
>
> I think that can be taken care of by proving reasonable defaults, and
> by exposing a limited but adequate subset with some boilerplate code
> for conventional stuff (as in providing short code with the comment
> 'here's how you can do a canvas surrounded by a toolbar and a standard
> menu bar') Please do not cripple it, though, while trying to make
> newbies feel comfortable.
Have no fear. Cells/Cello does not get its productivity from the 4gl
approach of dumbing things down in a way that prevents extensibility.
The simple demo will use the same classes as a killer demo, just
parameterized more extensively and with more creative Cell rules.
Anyway, I have started to think along the lines of teaching people to
fish instead of giving them fish. Put a lot of core capabilities in a
portable GUI lib with some basic widgets and let people realize, as I
have, that with core Cello geometry and Cells it is trivial to toss off
their own GUI. Then tell them to go away, because...
My current focus is on shipping commercial educational software, so the
Cello project will be more like "here is what I am using. bye now." But
that will mean enough widgets to do my app, so that ain't exactly
chopped liver as we say hear in the States.
>
> KT> I think the doc for glDrawPixels says it all for me. Not sure
> KT> I understand a word of it.
>
> Aw c'mon (just looked it up). If you skimmed the standard opengl book...
That's the thing that scared me. :)
> [...]
> KT> (1) Use an I/M function to do a simulated 3d effect in pixels.
> KT> (2) Convert that to a gl texture (forgive any glaring
> KT> technical gaffes, I am just swiping code and monkey-typing
> KT> till it works with little understanding of the deets) private
> KT> to the widget.
>
> If these are standard buttons and such I'd just do the textures once
> and ship them with the library. No need to generate them at runtime.
But can't I just memoize on the first go and get the same performance,
without the hassle of packaging them up? And of course I am talking
about Cello as a raw GUI development tool, so I am not deciding what
people's buttons should look like.
>
> KT> (3) re-do the above only if the appearance of
> KT> the widget changes.
>
> I don't see how the texture can change unless you provide the users
> with texture-generating functions. If the color or the text changes
> or another predefined texture is selected this can all be done without
> using imagemagick at runtime.
I am thinking about the program deciding at run-time to generate
arbitrary new visual output and not being limited to components shipped
with the app. And avoiding OpenGL (I know, you think OpenGL is not that
hard. Maybe it's just the doc that scares me. I'll try to Just Steal Code.)
Well, let's get a little further and get some Cello code into your hands
so we know what we're talking about. What's your platform?
> No. Don't do it that way. You'll lose any acceleration the hardware
> gives you. Make display lists for the objects when you crate them and
> call those as you sweep your hierarchy.
OK. Display lists I had heard about.
> I'd start by not worrying about invalidating rectangles in windows.
I'm down with that. That was an awful lot of pretty hairy code and it
kinda understood only rectangles. I imagine at this point it is slower
deciding what not to draw than it would be to just draw it.
>
> KT> I just think I/M (or GraphicsMagick, its clone) will be an
> KT> order of magnitude easier to work with.
>
> I think you are solving the wrong problem with this. But I may be
> misunderstanding.
We'll see. I am just getting started on all this and have no problem
yanking a library if it is going to be a problem.
> One complication: your need to watch out for is missing fonts.
Right, for my commercial app I have to go find some nice fonts to ship
with my app. But that is a delivery concern, methinks.
You need
> a way to get people similar fonts and a way for the programmer to specify
> fonts with wild-cards (remember you are cross-platform)
Win32 has a fonts directory, and I already have a font preview pane
which shows all their names each in their own font by wildcarding that
directory. Of course anyone developing an app can allow /their/ users to
go anywhere they like via some "open" dialog to find arbitrary
installed fonts. (If that is what you meant.)
Thx for the input on OpenGL. This project could use some help with that.
(Hint.)
:)
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
>>>>> "KT" == Kenny Tilton <·······@nyc.rr.com> writes:
[...]
BM> just do the textures once and ship them with the library. No
BM> need to generate them at runtime.
KT> But can't I just memoize on the first go and get the same
KT> performance, without the hassle of packaging them up?
Hmm. When I think of 'textures' in context of OpenGL I think of
things like brushed metal, fuzzy cloth and maybe some complicated but
small picture (a face maybe?). Things that get put on polygons mostly
to make them pretty, it other words. Of course you can memoize them
(in a manner of speaking, OpenGL should handle this for you). How do
you generate them though? Have a texture-generating mini language?
[...]
KT> I am thinking about the program deciding at run-time to
KT> generate arbitrary new visual output and not being limited to
KT> components shipped with the app.
That's fine (and as it should be). I think you were using texture to
mean arbitrary arrays of pixels to be shoved down the bus directly to
the frame-buffer (such as the pixels for a labelled button, for example).
If that is so, then I understand where we misunderstood each other.
Sure they are all arbirary array of pixels, but when I think of specific
textures to be shipped by the application/lib I think of patterns that
cannot easily be generated by the program on the fly (think brushed
metal and such). For things that can be generated on the fly (polygons
colors etc.) you don't need textures as other OpenGL primitives handle
those well and efficiently.
KT> And avoiding OpenGL (I know,
KT> you think OpenGL is not that hard. Maybe it's just the doc
KT> that scares me. I'll try to Just Steal Code.)
I think OpenGL is manageable and adequately documented, but it wasn't
the easiest thing I've used (CLIM was far easier!). I'm a slowish
learner though (but books don't scare me, sample code w/o documentation
does). The opengl newsgroup is also an OK place to lurk. They seem to
expect C code fragments for specific questions, but I seem to remember
that you're OK with C. What I did when I was trying to pick up
rudimentary OpenGL was to just skim the book here and there and make
myself a tiny testing jig (in LW where CAPI allows OpenGL panes and is
happy to give you buttons and sliders and such so you can change things).
KT> Well, let's get a little further and get some Cello code into
KT> your hands so we know what we're talking about. What's your
KT> platform?
I got LWPro in both Win and Linux but I'd need to be paid to run the one
under Windows. I run Debian, so CMUCL or SBCL is no problem.
[...]
KT> Thx for the input on OpenGL. This project could use some help
KT> with that. (Hint.)
All my coding energy is tied up with work at the moment so no promises
there. I do seem to have plenty of BSing energy for CLL though. Give
us a holler here if you get stuck (or send me e-mail, but I am no
expert).
cheers,
BM
Bulent Murtezaoglu wrote:
>>>>>>"KT" == Kenny Tilton <·······@nyc.rr.com> writes:
> .... I think you were using texture to
> mean arbitrary arrays of pixels to be shoved down the bus directly to
> the frame-buffer (such as the pixels for a labelled button, for example).
> If that is so, then I understand where we misunderstood each other.
yes. and yes, I do have some groovy metallic textures I DLed for
possible use as the basis of a window skin, and indeed that would have
to ship with the app.
> Sure they are all arbirary array of pixels, but when I think of specific
> textures to be shipped by the application/lib I think of patterns that
> cannot easily be generated by the program on the fly (think brushed
> metal and such). For things that can be generated on the fly (polygons
> colors etc.) you don't need textures as other OpenGL primitives handle
> those well and efficiently.
Picture one of those thousand monkeys typing and you have some idea of
my level of understanding. I found a little C app which pulled a JPEG in
via i/m and displayed it via opengl. That used a texture, so I do, too.
Monkey see, monkey do. Eeep!
>
> KT> And avoiding OpenGL (I know,
> KT> you think OpenGL is not that hard. Maybe it's just the doc
> KT> that scares me. I'll try to Just Steal Code.)
>
> I think OpenGL is manageable and adequately documented, but it wasn't
> the easiest thing I've used (CLIM was far easier!). I'm a slowish
> learner though (but books don't scare me, sample code w/o documentation
> does).
uh-oh.
The opengl newsgroup is also an OK place to lurk.
Yeah, that looks good. So far one or the other thousand monkeys over
here has muddled thru any problems I have had, but when I am righteously
stuck and can ask an intelligent Q, that's where I plan to turn.
> I got LWPro in both Win and Linux but I'd need to be paid to run the one
> under Windows. I run Debian, so CMUCL or SBCL is no problem.
OK. Someone else is waiting for me to stabilize Cello enough to try it
under Linux plus (I think) AllegroCL. Cello runs (or did the last time I
looked) under LW as well as acl on win32.
kt
Kenny Tilton <·······@nyc.rr.com> writes:
> While I offer Cello as a contrast, in the end the question of interest
> is why CLIM has failed. ie, If I did not have Cello, I would not use
Tough question. If you are really interested, I suggest that you at
least check the archives of the CLIM mailing list. You will find
plenty of food for thought. For example, it looks like vendors pulled
the plug from the standardization work around or after CLIM 2.0 was
released, i.e. in the early 1990s.
> CLIM, nor apparently would many others. What went wrong?
But apparently there are others who still use it. All major Lisp
vendors also ship a CLIM implementation, and Franz has recently made
available its own for Mac OS X.
If CLIM is a complete dead end for Lisp vendors, why do they continue
providing it? Wouldn't they save money by dropping the product and
concentrating on what customers really want? Can all of this use of
CLIM be explained by legacy applications? Feedback from vendors would
be greatly appreciated.
> Unfortunately not enough information on CLIM has made it into this
> thread for me to understand why, as Robert concedes, CLIM is so hard
> to master or why cosmetics are so hard they have to be deferred, so
Part of the reason why CLIM is hard to learn may be due to the lack of
tutorial-style documentation.
As for cosmetics, Rainer has explained that it is possible to make
CLIM applications look prettier.
The reason why cosmetics are being deferred in McCLIM is just that
resources are limited, and the developers are currently concentrating
on functionality. Despite this, there is some experimentation on
cosmetics, e.g. the pointer documentation pane with prettier button
icons.
For the record, getting with McCLIM a font prettier than the default
monospaced one is as simple as adding, say:
:text-style (make-text-style :sans-serif :roman :normal)
to the options supplied to a pane. At times I also add this to give a
gray-ish GTK look:
:background (make-gray-color 0.9)
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
[Just responding hear at random...]
Thanks everyone for all the detailed info. And I mean "all", that is a
tremendous stream of info to which I awoke.
I think I get it now. Rainer's UIMS distinction jived with what I was
starting to realize, viz., that CLIM is distinguished most by a
sophisticated mechanism to connect types to input and output schemes,
without much interest in looking good. It /has/ interesting low-level
graphics capabilities, and there /is/ an OpenGL backend, but... well,
for some reason there just any perty screenshots to be had, perhaps
because folks have other things to do.
When I woke up this morning I realized that, if I am right that the
sophisticated UIMS is CLIM's claim to fame, then Cello and CLIM are
different creatures in that they address different needs. Cello is first
about portability (hence all the libraries Brian is so jealous of
XXXXXXXXX of which Brian is so jealous XXXXXXXXXX Brian envies so), and
then it is about hand-wiring interfaces in the MVC way using Cells for
the power they bring to any programming.
So there is no conflict, and McCLIM should simply leverage work being
done by Thomas and myself to get a quick win in portability* (and a
fricking makeover) by tapping into low-level Cello as its back-end. That
also lets them drop the other backends. And then of course Cello
benefits by the efforts of the fine CLIM developers. Everyone does what
they do best, and everyone wins, including CL.
Don't worry, we'll find other topics over which to abuse each other here
on c.l.l.
kenny
* They should lose that MOP dependence as well for better portability.
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> I think I get it now. Rainer's UIMS distinction jived with what I was
> starting to realize, viz., that CLIM is distinguished most by a
> sophisticated mechanism to connect types to input and output schemes,
> without much interest in looking good. It /has/ interesting low-level
> graphics capabilities, and there /is/ an OpenGL backend, but... well,
> for some reason there just any perty screenshots to be had, perhaps
> because folks have other things to do.
I'll agree that you get it :)
> * They should lose that MOP dependence as well for better portability.
I made a pragmatic decision to use the MOP because the presentation
type system is similar to the CLOS class hierarchy and I use CLOS to
do the presentation method dispatch on presentation types. This is
just the sort of application for which the MOP is ideal. Presentation
types had already been vexing free CLIM development for years, so I just
wanted to get something working. It works pretty well in most Lisp
implementations. If someone wants to build a completely portable
presentation type and method system, go for it. It's not going to be
me.
Tim
Timothy Moore <·····@trousse.labri.fr> writes:
> To return to civility for a minute, if you care to answer: why is a
> constraint / slot daemon driven interface system better than a
> presentation based interface system?
And more importantly, how are they in any way incompatible?
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Kenny Tilton <·······@nyc.rr.com> writes:
> learning curve. This has led to a side exchange of whether
> hard-to-learn is always bad (my position, quantum mechanics aside).
Some thoughts by Dan Bricklin, of VisiCalc fame:
The "Computer as Assistant Fallacy"
Learning to use things that are hard is part of being human
http://www.danbricklin.com/assistantfallacy.htm
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Paolo Amoroso <·······@mclink.it> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > learning curve. This has led to a side exchange of whether
> > hard-to-learn is always bad (my position, quantum mechanics aside).
>
> Some thoughts by Dan Bricklin, of VisiCalc fame:
>
> The "Computer as Assistant Fallacy"
> Learning to use things that are hard is part of being human
> http://www.danbricklin.com/assistantfallacy.htm
First, whatever your reasoning, if you start comparing computers with
anything else, you're bound to conclude the utmost silly things.
The reason why the "computing industry" pushes for the "natural and
intelligent" "user friendly" "digital assistant" computers, is because
it's a good marketing trick to be able to sell computers to hundred of
million of people, who, basically, DON'T need anything from the
computers.
He compares computers with housing, cooking, driving.
- when you stop housing yourself, you're at the mercy of the
elements, and in most part of the world, that means that you
won't pass the winter.
- when you stop cooking, you're dead in 40 days.
- when you stop driving, it's about the same: people drive to
gather food (go to work to be able to buy it).
- when you stop using a computer, you still live a perfectly
healthy and fullfilling live. More healthly even, because you'd
be doing more exercise.
"People" just don't want to "use" a computer (remember what people
want is bread and games (and sex and power)). (Those who do want to
use a computer are geeks). So, it was really a smart move on the part
of Steve Jobs to promote this "fallacy": he just created this
industry, from a 100 thousand unit market into a billion unit market,
and this allows all geeks of the world to be able to buy cheap
computers. It's a scam. (By the way, another scam is in the
workings, that of pushing people to want to go to the star, only to
allow us geek to buy cheap space ships. Remember, people are not
interested in the stars or Mars either, they just want to fill their
estomac and have sex).
http://oldcomputers.net/appleii.html
2.5 years after the introduction of the Apple II, 50,000 units have
been sold.
Apple Computer announces that 70,000 Macintosh computers have been
shipped in the first 100 days since its announcement.
[3.2 years after the introdction of the Macintosh] Apple Computer
makes its 1 millionth Macintosh personal computer.
(And you could find similar statistics about MS-DOS vs. MS-Windows)
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
On Fri, 30 Jan 2004 18:36:28 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
> Thanks. Someone else sent me links to Rainer's (?) movies. Y'all
> need to learn about marketing. Still butt ugly. And if CLIM is such
> a powerful GUI, it should take 10 minutes to jazz it up.
You mean we need something as spiffy and flashy as, say,
<http://www.tilton-technology.com/>?
:)
FWIW, I have to admit that a "default" CLIM window looks kinda boring
if OS X is around but that's mostly because "modern" operating systems
like OS X or Wintendo XP are full of useless eye candy. If, in
contrast, you look at Rainer's movies you see that it all fits rather
nicely. If I had the option to have such an unostentatious but
consistent user interface on my laptop I'd use it immediately.
> Statements like this from the link above make me wonder if Lispniks
> have lost the ability to communicate with non-Lispniks:
>
> "It has many features, but here's one that's especially exciting for
> Lisp programmers: anything that is printed can be used as input when
> typing a form, even if its printed representation isn't readable."
>
> This is what all the CLIM repl excitement is about? puh-leez! If
> this is what we try to impress the world with (even the CL world),
> it shows we need to get out more.
I'm still very impressed by this feature and I've seen nothing
comparable in other GUIs. I've shown this to other programmers
(non-Lispers) and all of them were very impressed, too. Could it be
that you didn't really get it because you were too busy changing the
skin of your MP3 player or choosing your XP theme of the day? Just
curious... :)
Cheers,
Edi.
Edi Weitz wrote:
> On Fri, 30 Jan 2004 18:36:28 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
>
>
>>Thanks. Someone else sent me links to Rainer's (?) movies. Y'all
>>need to learn about marketing. Still butt ugly. And if CLIM is such
>>a powerful GUI, it should take 10 minutes to jazz it up.
>
>
> You mean we need something as spiffy and flashy as, say,
>
> <http://www.tilton-technology.com/>?
>
> :)
You don't like that? :) You'll find my confession to having zero GUI
design talent elsewhere in this thread. But, hey, give me points for
being smart enough to keep it minimalist, to minimize the horror. :)
> I'm still very impressed by this feature and I've seen nothing
> comparable in other GUIs. I've shown this to other programmers
> (non-Lispers) and all of them were very impressed, too. Could it be
> that you didn't really get it because...
It was so boring I did not even remember tossing off the same thing (see
elsewhere this thread) in a day for the CliniSys app. I mean, those are
URLs, right? <yawn>
you were too busy changing the
> skin of your MP3 player or choosing your XP theme of the day? Just
> curious... :)
Just the Crested Butte backcountry desktop, where I will be as of Monday
so you guys only have two more days to kick around Kenny.
:)
kenny
On Fri, 30 Jan 2004 22:44:08 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
> Edi Weitz wrote:
>
>> I'm still very impressed by this feature and I've seen nothing
>> comparable in other GUIs. I've shown this to other programmers
>> (non-Lispers) and all of them were very impressed, too. Could it be
>> that you didn't really get it because...
>
> It was so boring I did not even remember tossing off the same thing
> (see elsewhere this thread) in a day for the CliniSys app. I mean,
> those are URLs, right? <yawn>
OK, could you try to follow me for thirty seconds, please? If you have
a copy of LispWorks Pro around you can type in as you read after doing
something like
(require "clim")
(require "clim-demo")
(clim-demo:start-demo)
and then choosing the "Lisp Listener." Same for any other CLIM out
there I guess. If you don't have access to a CLIM implementation right
now just look at the screenshot (butt ugly, isn't it? but that's not
the point)
<http://agharta.de/clim.png>
and believe what I write:
1. Type
(defclass foo ()
((a :initarg :a :accessor :a)))
(defclass bar ()
((a :initarg :a :accessor :a)))
(make-instance 'foo :a 42)
(make-instance 'bar :a *)
into the REPL. The last two forms will print unreadable
representations like #<FOO 211EBBDC> and #<BAR 211ED2FC>. OK, fine,
you know that.
2. Now define a little function
(defun frob (type)
(let ((result (clim:accept type :prompt "Go Kenny")))
(clim:present (list result
(a result))))
(values))
3. Now evaluate
(frob 'bar)
and move the mouse across the listener window. You will see that
ONLY the #<BAR 211ED2FC> part from a couple of lines earlier is
mouse-sensitive and NOTHING ELSE. You can click on it and FROB will
use it and show a list like
(#<BAR 211ED2FC> #<FOO 211EBBDC>)
4. Finally, evaluate
(frob 'foo)
and again move the mouse. Now BOTH occurences of #<FOO 211EBBDC>
(the one from MAKE-INSTANCE above as well as the one printed by
FROB) are mouse-sensitive and again NOTHING ELSE. Click on one of
them to get
(#<FOO 211EBBDC> 42)
5. Play around, try (CLIM:ACCEPT 'NUMBER) and see how the "42" from
the last invocation is active. Evaluate (DIRECTORY "*"), then
(CLIM:ACCEPT 'PATHNAME), and see how the elements of the directory
list just returned are now available for you to click on.
Your CliniSys listener could do all that? With Microsoft Verdana? In
color? And you hacked it together in one day? While watching the
Superbowl and reading comp.lang.lisp?
I'm impressed. If that's true I might want to hire you for my next
project. If not I'm looking forward for more of your embarassing
yourself in public... :)
Those are URLs? Nope, sorry.
Cheers,
Edi.
Edi Weitz wrote:
> On Fri, 30 Jan 2004 22:44:08 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
>
>
>>Edi Weitz wrote:
>>
>>
>>>I'm still very impressed by this feature and I've seen nothing
>>>comparable in other GUIs. I've shown this to other programmers
>>>(non-Lispers) and all of them were very impressed, too. Could it be
>>>that you didn't really get it because...
>>
>>It was so boring I did not even remember tossing off the same thing
>>(see elsewhere this thread) in a day for the CliniSys app. I mean,
>>those are URLs, right? <yawn>
>
>
> OK, could you try to follow me for thirty seconds, please? If you have
> a copy of LispWorks Pro around you can type in as you read after doing
> something like
>
> (require "clim")
> (require "clim-demo")
> (clim-demo:start-demo)
>
> and then choosing the "Lisp Listener." Same for any other CLIM out
> there I guess. If you don't have access to a CLIM implementation right
> now just look at the screenshot (butt ugly, isn't it? but that's not
> the point)
>
> <http://agharta.de/clim.png>
>
> and believe what I write:
>
> 1. Type
>
> (defclass foo ()
> ((a :initarg :a :accessor :a)))
> (defclass bar ()
> ((a :initarg :a :accessor :a)))
> (make-instance 'foo :a 42)
> (make-instance 'bar :a *)
>
> into the REPL. The last two forms will print unreadable
> representations like #<FOO 211EBBDC> and #<BAR 211ED2FC>. OK, fine,
> you know that.
>
> 2. Now define a little function
>
> (defun frob (type)
> (let ((result (clim:accept type :prompt "Go Kenny")))
> (clim:present (list result
> (a result))))
> (values))
>
> 3. Now evaluate
>
> (frob 'bar)
>
> and move the mouse across the listener window. You will see that
> ONLY the #<BAR 211ED2FC> part from a couple of lines earlier is
> mouse-sensitive and NOTHING ELSE. You can click on it and FROB will
> use it and show a list like
>
> (#<BAR 211ED2FC> #<FOO 211EBBDC>)
>
> 4. Finally, evaluate
>
> (frob 'foo)
>
> and again move the mouse. Now BOTH occurences of #<FOO 211EBBDC>
> (the one from MAKE-INSTANCE above as well as the one printed by
> FROB) are mouse-sensitive and again NOTHING ELSE. Click on one of
> them to get
>
> (#<FOO 211EBBDC> 42)
>
> 5. Play around, try (CLIM:ACCEPT 'NUMBER) and see how the "42" from
> the last invocation is active. Evaluate (DIRECTORY "*"), then
> (CLIM:ACCEPT 'PATHNAME), and see how the elements of the directory
> list just returned are now available for you to click on.
>
<yawn>
> Your CliniSys listener could do all that?
[Yeah, I saw where I typed "Cliniys REPL" or "listener", but that was
either too fast typing or shorthand for "CliniSys equivalent", which I
believe I described in detail, and do some more below]
What do you mean by "all that"? Oh, wow, generic functions! But yes, I
had an embedded mail facility in which things like "Thanks for your
response on Data Query P102-23" and the mail recipient could click on
the section of text "Data Query..." and bounce to a Form View showing
the DQ in one pane and the patient form to which the DQ related in
another pane, positioned on the field (and page <duh>) referenced by the
DQ.
It turned out the users were turning back flips before they ever got to
the mail facility, and the scripted demo did not get as far as the
embedded mail mechanism, but the next task was to work out how the user
would insert the references into the text. I was going to implement drag
and drop, and/or copy/paste any arbitrary item in the clinical trial
browser. "paste" probably would not make sense for anything other than
such mail messages, but who knows.
Likewise when I said URL, that was shorthand for "big deal, HTML has had
text qua objects for a while, aka URLs".
When are guys going to learn to read my mind?
> With Microsoft Verdana?
Yep. Dingbats, if you like.
In
> color?
yep. No blinking, but only because that is so irritating.
And you hacked it together in one day? While watching the
> Superbowl ...
The only thing I can have on while programming is New Age music, which I
do not think bodes well for New Age music. I program serenaded by
honking cabbies and the siren sound of New York's Bravest and Finest.
and reading comp.lang.lisp?
Some people watch Dr. Phil, I cll.
>
> I'm impressed. If that's true I might want to hire you for my next
> project.
You probably think you are a good programmer, don't jeopardize that by
working with me. (How's that for trash talking?)
Well, I think part of the problem is that Lispniks have the bar set so
low on graphic design and I (as a commercial software developer) have
had it set so high and done things like the CLIM repl in my sleep, so
you all think you are in heaven because you got out of the flames into
the River Styx. I have really bad news for you.
If not I'm looking forward for more of your embarassing
> yourself in public... :)
You call this public? You need to take a walk! :)
besides, unlike the rest of you participating in this thread, I am just
trying to learn more about CLIM, I am not trying to score points.
The good news is that as The Defenders of CLIM fall back on trashing me
as their last resort, I continue to get info about CLIM (mostly in the
form of a vacuum of positive info), which is all I wanted in the first
place.
Hey, guys, your lynch mob is defending the honor of a lousy programming
GUI, get a grip, will you? Put down those torches!
Peace, kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
On Sat, 31 Jan 2004 04:44:27 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
> <yawn>
>
> What do you mean by "all that"? Oh, wow, generic functions!
<sigh>
> I had an embedded mail facility in which things like "Thanks for
> your response on Data Query P102-23" and the mail recipient could
> click on the section of text "Data Query..." and bounce to a Form
> View showing the DQ in one pane and the patient form to which the DQ
> related in another pane, positioned on the field (and page <duh>)
> referenced by the DQ.
>
> [...]
>
> Likewise when I said URL, that was shorthand for "big deal, HTML has
> had text qua objects for a while, aka URLs".
Yep. As I expected - you didn't get it. I give up. But at least I
tried.
> You probably think you are a good programmer, don't jeopardize that
> by working with me. (How's that for trash talking?)
I think I can deal with that.
> You call this public? You need to take a walk! :)
No worries - just returned from building a snowman with my daughter.
> besides, unlike the rest of you participating in this thread, I am
> just trying to learn more about CLIM, I am not trying to score
> points.
Me neither. In fact, the example in my last message was my first
attempt at CLIM ever (it wasn't /that/ hard) so I'm not a CLIM
user/developer trying to defend CLIM. I think Cello/Cells sounds
interesting and I'd like to look at it[1] - I'm just wondering why you
seem to think that you need to trash something that you obviously
don't understand in order to promote it. But, hey, why do I care?
'Nuff said in this thread,
Edi.
[1] I didn't write any real CLIM code yesterday but it only took me a
couple of minutes to see an impressive demo and play with it. I'll
use this as a benchmark for how easy to use Cello is... :)
Edi Weitz wrote:
> On Sat, 31 Jan 2004 04:44:27 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
>
>
>><yawn>
>>
>>What do you mean by "all that"? Oh, wow, generic functions!
>
>
> <sigh>
<groan> OK, I'll read your whole thing again more closely to come up
with specific questions. (And I should have thanked you for teh most
detailed play-by-play to date on the repl.) I mean, i thought I followed
it but you say I don't so I'll try again. I also tried DLing mcCLIM onto
win XP. PicoZip is being weird about opening the .tar, but I should be
able to crack it open one way or another.
I'll be able to load into AllegroCL on win32, right?
kt
Kenny Tilton <·······@nyc.rr.com> writes:
> Edi Weitz wrote:
>
> > On Sat, 31 Jan 2004 04:44:27 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
> >
> >><yawn>
> >>
> >>What do you mean by "all that"? Oh, wow, generic functions!
> > <sigh>
>
> <groan> OK, I'll read your whole thing again more closely to come up
> with specific questions. (And I should have thanked you for teh most
> detailed play-by-play to date on the repl.) I mean, i thought I
> followed it but you say I don't so I'll try again. I also tried DLing
> mcCLIM onto win XP. PicoZip is being weird about opening the .tar, but
> I should be able to crack it open one way or another.
>
> I'll be able to load into AllegroCL on win32, right?
I don't know that it's been tried there. The supported backend is X11,
so you'd need an X server somewhere.
I thought you were a Mac person :) McCLIM works nicely with OpenMCL.
Tim
Timothy Moore wrote:
> I don't know that it's been tried there. The supported backend is X11,
> so you'd need an X server somewhere.
I guess that would mean Cygwin + XFree86?
> I thought you were a Mac person :) McCLIM works nicely with OpenMCL.
Now I'm a Lisp person, so the most productive IDE is what matters to me.
For now that is AllegroCL on win32, but I might shift to MCL and a nice
big Powerbook laptop now that I am comfy developing on a (Dell) laptop.
I plopped for the Apple developer thing so I could grab one at the
developer discount (and get Panther with the developer sign-up), so
within a few months I should have a 17" PB like the rest of you (based
on ILC2003).
re McCLIM, in my experience I do not have a problem saying "make a view
for this model" by hand, so an automatic matching scheme holds no appeal
for me. There are places such as my object inspector that have a GF
'make-inspector-pane-for-object (kinda like that), but that is called by
the object-inspector-container when forming its content. which is what I
mean by "doing it by hand".
cheers and out for a week of snowboarding,
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
On Sat, 31 Jan 2004 21:25:00 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
> <groan> OK, I'll read your whole thing again more closely to come up
> with specific questions.
Good... :)
> (And I should have thanked you for teh most detailed play-by-play to
> date on the repl.)
You're welcome.
> I mean, i thought I followed it but you say I don't so I'll try
> again. I also tried DLing mcCLIM onto win XP. PicoZip is being
> weird about opening the .tar, but I should be able to crack it open
> one way or another.
Try FilZip. It's free.
> I'll be able to load into AllegroCL on win32, right?
I fear you won't but you have to ask the McCLIM developers (if they're
still talking to you ...:). From a quick glance it looks to me as if
there currently are only three backends - CLX, OpenGL, and Postscript
- and OpenGL is a beta which only works with CMUCL. Someone correct me
if I'm wrong.
Looks like your best chance is to either grab a Mac with OpenGL or a
Linux x86 box with CMUCL or SBCL. (Maybe they expected a certain kind
of ignorance from the Wintendo camp and thus didn't hasten too much to
support Win32 - cough, cough.)
FWIW, I just installed and ran McCLIM for the first time in my
life. It was so easy that even I was able to do it - go figure. Here's
what I did (with CMUCL 18e and Linux):
1. Get the "nightly snapshot" from <http://mcclim.cliki.net/Download>.
2. Unpack the tarball and cd into the newly created directory.
3. Start CMUCL (which has CLX, Gray streams, ASDF loaded), then
(mp::startup-idle-and-top-level-loops) ; CMUCL-specific
(load "system.lisp")
(asdf:oos 'asdf:compile-op :clim-clx-user)
(asdf:oos 'asdf:load-op :clim-clx-user)
(load "Apps/Listener/clim-listener.asd")
(asdf:operate 'asdf:load-op :clim-listener)
(clim-listener:run-listener-process)
4. Now you have a listener and can play with it. It behaves a bit
differently from my LW example. (I suppose this is a bug and I'll
report it.) So I had to modify my example - it's now here:
<http://agharta.de/mcclim.png>
5. Remember: The important point is to move your mouse across the
window once the "Go Kenny" prompt appears. These ain't you mother's
hyperlinks - unless she's a Javascript wizard.
Kudos to the McCLIM developers!
HTH,
Edi.
Edi Weitz <···@agharta.de> writes:
> Looks like your best chance is to either grab a Mac with OpenGL or a
> Linux x86 box with CMUCL or SBCL. (Maybe they expected a certain kind
> of ignorance from the Wintendo camp and thus didn't hasten too much to
> support Win32 - cough, cough.)
The OpenGL backend is quite broken at the moment because I'm working
on it. The X11 backend works well on OS X with Apple's X11 (and
others, I'm sure.)
> 4. Now you have a listener and can play with it. It behaves a bit
> differently from my LW example. (I suppose this is a bug and I'll
> report it.) So I had to modify my example - it's now here:
I wouldn't call it a bug, just undefined behavior :) Classic CLIM
appears to have a list presentation type and present method that
presents all of the list's elements. That's not in the Spec and is a
pain in the ass to do in the general case without tight integration
with the host system's print functions. We do ship a version of the
CMUCL pretty printer with hooks for presenting each subelement but I'm
not sure of its status.
On 01 Feb 2004 00:18:04 +0100, Timothy Moore <·····@trousse.labri.fr> wrote:
> Edi Weitz <···@agharta.de> writes:
>
>> 4. Now you have a listener and can play with it. It behaves a bit
>> differently from my LW example. (I suppose this is a bug and I'll
>> report it.) So I had to modify my example - it's now here:
>
> I wouldn't call it a bug, just undefined behavior :) Classic CLIM
> appears to have a list presentation type and present method that
> presents all of the list's elements. That's not in the Spec and is a
> pain in the ass to do in the general case without tight integration
> with the host system's print functions. We do ship a version of the
> CMUCL pretty printer with hooks for presenting each subelement but
> I'm not sure of its status.
Ah, OK, thanks for the info. So forget about my "bug report"... :)
Of course, things like this would be nice to have in the long run. But
at the moment I can only utter wishes.
Thanks,
Edi.
Edi Weitz <···@agharta.de> writes:
> Looks like your best chance is to either grab a Mac with OpenGL or a
> Linux x86 box with CMUCL or SBCL. (Maybe they expected a certain kind
> of ignorance from the Wintendo camp and thus didn't hasten too much to
> support Win32 - cough, cough.)
AFAIK, no one who develops McCLIM uses Windows for any development. See
also: CStacy's rant about hating debian users for not using redhat and
windows.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
>>>>> "RJ" == Rahul Jain <·····@nyct.net> writes:
[...]
RJ> ... See also: CStacy's rant about hating debian users
RJ> for not using redhat and windows. [...]
He neither said nor implied any such thing.
cheers,
BM
Bulent Murtezaoglu <··@acm.org> writes:
>>>>>> "RJ" == Rahul Jain <·····@nyct.net> writes:
> [...]
> RJ> ... See also: CStacy's rant about hating debian users
> RJ> for not using redhat and windows. [...]
>
> He neither said nor implied any such thing.
He made veiled aspersions at "those people" who use debian and won't
"let" anyone else use their software. Something along the lines of "is
there any easy way to install lisp libraries that doesn't involve
debian?" and then ranting about us not doing all the things that we did
_for_ _debian_ that need to be solved by users _of_ _the_ _other_
_platforms_ for them to be able to piggyback on the same distribution
system.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
>>>>> On Wed, 04 Feb 2004 23:44:22 -0500, Rahul Jain ("Rahul") writes:
Rahul> Bulent Murtezaoglu <··@acm.org> writes:
>>>>>>> "RJ" == Rahul Jain <·····@nyct.net> writes:
>> [...]
RJ> ... See also: CStacy's rant about hating debian users
RJ> for not using redhat and windows. [...]
>>
>> He neither said nor implied any such thing.
Rahul> He made veiled aspersions at "those people" who use debian and won't
Rahul> "let" anyone else use their software. Something along the lines of "is
Rahul> there any easy way to install lisp libraries that doesn't involve
Rahul> debian?" and then ranting about us not doing all the things that we did
Rahul> _for_ _debian_ that need to be solved by users _of_ _the_ _other_
Rahul> _platforms_ for them to be able to piggyback on the same distribution
Rahul> system.
Rahul Jain, I believe that you are actionably libeling me.
If not, would you please cite the Google references where
I wrote the things that you claim above?
······@news.dtpq.com (Christopher C. Stacy) writes:
>>>>>> On Wed, 04 Feb 2004 23:44:22 -0500, Rahul Jain ("Rahul") writes:
> Rahul> He made veiled aspersions at "those people" who use debian and
> Rahul> won't "let" anyone else use their software. Something along
> Rahul> the lines of "is there any easy way to install lisp libraries
> Rahul> that doesn't involve debian?" and then ranting about us not
> Rahul> doing all the things that we did _for_ _debian_ that need to
> Rahul> be solved by users _of_ _the_ _other_ _platforms_ for them to
> Rahul> be able to piggyback on the same distribution system.
>
> Rahul Jain, I believe that you are actionably libeling me.
>
> If not, would you please cite the Google references where
> I wrote the things that you claim above?
······@news.dtpq.com (Christopher C. Stacy) writes:
[Griping about not being able to install lisp libaries using a single
command elided.]
> * We DON'T understand SourceForge, we don't have or want CVS,
> and, sorry, mostly we don't run Debian. We may or may not
> have bzip, and we probably don't know even about it, if we do.
Sorry, we DO run Debian, and the solution for this problem was easy to
implement on Debian. You might as well ask us to implement Maxima in
C++. It's up to those who use other platforms to work on solutions for
their platforms. Some effort was made, but there wasn't a critical
enough mass for the degree of effort needed, or so it seemed to me.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
>>>>> On Sun, 08 Feb 2004 22:48:52 -0500, Rahul Jain ("Rahul") writes:
Rahul> ······@news.dtpq.com (Christopher C. Stacy) writes:
Rahul> [Griping about not being able to install lisp libaries using a single
Rahul> command elided.]
>> * We DON'T understand SourceForge, we don't have or want CVS,
>> and, sorry, mostly we don't run Debian. We may or may not
>> have bzip, and we probably don't know even about it, if we do.
Rahul> Sorry, we DO run Debian, and the solution for this problem was easy to
Rahul> implement on Debian. You might as well ask us to implement Maxima in
Rahul> C++. It's up to those who use other platforms to work on solutions for
Rahul> their platforms. Some effort was made, but there wasn't a critical
Rahul> enough mass for the degree of effort needed, or so it seemed to me.
On Mon, 02 Feb 2004 23 you claimed this:
See also: CStacy's rant about hating debian users for
not using redhat and windows.
On Wed, 04 Feb 2004 you claimed this:
He made veiled aspersions at "those people" who use
debian and won't "let" anyone else use their software.
Your defense consists of taking some of my statements out of context,
but even then, what you have reproduced above clearly does not show
where I made the statements that you accuse me of. Do you plan on
apologizing in public here, or would you prefer to take it to court?
······@news.dtpq.com (Christopher C. Stacy) writes:
>>>>>> On Sun, 08 Feb 2004 22:48:52 -0500, Rahul Jain ("Rahul") writes:
>
> Rahul> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
> >> * We DON'T understand SourceForge, we don't have or want CVS,
> >> and, sorry, mostly we don't run Debian. We may or may not
> >> have bzip, and we probably don't know even about it, if we do.
>
> Rahul> Sorry, we DO run Debian, and the solution for this problem was easy to
> Rahul> implement on Debian. You might as well ask us to implement Maxima in
> Rahul> C++. It's up to those who use other platforms to work on solutions for
> Rahul> their platforms. Some effort was made, but there wasn't a critical
> Rahul> enough mass for the degree of effort needed, or so it seemed to me.
>
> On Mon, 02 Feb 2004 23 you claimed this:
>
> See also: CStacy's rant about hating debian users for
> not using redhat and windows.
>
> On Wed, 04 Feb 2004 you claimed this:
>
> He made veiled aspersions at "those people" who use
> debian and won't "let" anyone else use their software.
>
> Your defense consists of taking some of my statements out of context,
> but even then, what you have reproduced above clearly does not show
> where I made the statements that you accuse me of. Do you plan on
> apologizing in public here, or would you prefer to take it to court?
The context was that you thought free library providers were not working
hard enough to deliver their applications. Every gripe you had, from the
difficulty installing a lisp implementation to the difficulty figuring
out how exactly to build the lisp library after struggling to download
it, has been addressed for debian's packaging system, even for ACL and
LW.
That is why so many people recommend Debian for using lisp on linux, and
even unix in general. That is the only reason I could fathom for you
lashing out at debian in the statement I quoted above, while you were
complaining at the difficulty you were having trying to use free lisp
libraries on redhat and windows.
What makes this so frustrating is that we predicted this kind of attack
long ago and make some effort to provide RPMs via CCLAN. Too bad no
users of RedHat cared enough to figure out the details. We even came up
with some ideas of how to accomplish this on Windows. Oh well. At least
we (definitely not I) never expected any thanks from the greater Lisp
community. It's just particularly frustrating to see this crap come from
you, a person whose opinions I had respected and valued and whose
contributions in this forum I had looked forward to (and I suppose to
some degree I still do).
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Kenny Tilton <·······@nyc.rr.com> writes:
> followed it but you say I don't so I'll try again. I also tried DLing
> mcCLIM onto win XP. PicoZip is being weird about opening the .tar, but
> I should be able to crack it open one way or another.
>
> I'll be able to load into AllegroCL on win32, right?
No. McCLIM has not been ported to Windows.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton <·······@nyc.rr.com> writes:
> besides, unlike the rest of you participating in this thread, I am
> just trying to learn more about CLIM, I am not trying to score points.
The "CLIM 2 User Guide", available online at Franz's site, is a good
start. The main caveat about this manual, and similar ones, is that it
does not necessarily present--no pun intended--the information you
need to start building a useful GUI in the order you need it. But it
gave me a few valuable "aha!" moments.
The thesis about presentation-based user interfaces I mentioned
somewhere else in this thread is also a good reading. But it is
probably more useful if you are going to implement a presentation
system yourself.
If you need more info, feel free to ask here or to the CLIM mailing
list, depending on your level of interest in CLIM.
> Hey, guys, your lynch mob is defending the honor of a lousy
> programming GUI, get a grip, will you? Put down those torches!
The CLIM savages?
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Edi Weitz wrote:
> On Fri, 30 Jan 2004 22:44:08 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
>
>
>>Edi Weitz wrote:
>>
>>
>>>I'm still very impressed by this feature and I've seen nothing
>>>comparable in other GUIs. I've shown this to other programmers
>>>(non-Lispers) and all of them were very impressed, too. Could it be
>>>that you didn't really get it because...
>>
>>It was so boring I did not even remember tossing off the same thing
>>(see elsewhere this thread) in a day for the CliniSys app. I mean,
>>those are URLs, right? <yawn>
>
>
> OK, could you try to follow me for thirty seconds, please? If you have
> a copy of LispWorks Pro around you can type in as you read after doing
> something like
>
> (require "clim")
> (require "clim-demo")
> (clim-demo:start-demo)
>
> and then choosing the "Lisp Listener." Same for any other CLIM out
> there I guess. If you don't have access to a CLIM implementation right
> now just look at the screenshot (butt ugly, isn't it? but that's not
> the point)
>
> <http://agharta.de/clim.png>
OK, first Q. That "lisp listener" window is all CLIM, right? ie, It is
not the Lispworks Listener? I see the little LW logo, but my LW trial
has blue/red christmas tree ornaments up there and calls its listener
"Listener 1", so I am guessing this is Andy's REPL built atop CLIM.
Second Q: I see in Robert & Tim's paper, on p3:
"The user can also enter arguments by clicking on graphic objects on the
screen. This is supported by a fundamental feature of CLIM,
presentations[4].....In the CLIM command loop one or more input
contexts, which expect input of a certain type, are active. Any
presentation whose type is a subtype of the input context type can then
be clicked on to provide input."
Now this sounds as if everything your PNG demos is just vanilla CLIM. So
I am guessing that that 8/17/2002 Strandh&Moore is describing Andy's repl?
I better get that clarified before guessing further. maybe a couple of
factual queries:
ACCEPT and PRESENT sound to me as if they are just part of CLIM, so I am
confused again as to where CLIM leaves off and the REPL begins. If
ACCEPT is however part of the REPL, or eventually pulls the front window
in as an argument to some GF (ie, if ACCEPT is pure CLIM which
internally invokes (apply #'window-accept *front-window" accept-args)
then I can see how the connection can be made.
REPL output be edited qua text? Can object descriptions wrap lines? I
gather (accept t) lets you select anything on the screen? Can accept
take a list of types?
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<·························@twister.nyc.rr.com>...
> Edi Weitz wrote:
>
> > On Fri, 30 Jan 2004 22:44:08 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
> >
> >
> >>Edi Weitz wrote:
> >>
> >>
> >>>I'm still very impressed by this feature and I've seen nothing
> >>>comparable in other GUIs. I've shown this to other programmers
> >>>(non-Lispers) and all of them were very impressed, too. Could it be
> >>>that you didn't really get it because...
> >>
> >>It was so boring I did not even remember tossing off the same thing
> >>(see elsewhere this thread) in a day for the CliniSys app. I mean,
> >>those are URLs, right? <yawn>
> >
> >
> > OK, could you try to follow me for thirty seconds, please? If you have
> > a copy of LispWorks Pro around you can type in as you read after doing
> > something like
> >
> > (require "clim")
> > (require "clim-demo")
> > (clim-demo:start-demo)
> >
> > and then choosing the "Lisp Listener." Same for any other CLIM out
> > there I guess. If you don't have access to a CLIM implementation right
> > now just look at the screenshot (butt ugly, isn't it? but that's not
> > the point)
> >
> > <http://agharta.de/clim.png>
>
> OK, first Q. That "lisp listener" window is all CLIM, right? ie, It is
> not the Lispworks Listener? I see the little LW logo, but my LW trial
> has blue/red christmas tree ornaments up there and calls its listener
> "Listener 1", so I am guessing this is Andy's REPL built atop CLIM.
Yes, the window is a CLIM window.
It is a Lisp Listener written with CLIM. So it is not the usual one
of the LispWorks IDE.
> Second Q: I see in Robert & Tim's paper, on p3:
>
> "The user can also enter arguments by clicking on graphic objects on the
> screen. This is supported by a fundamental feature of CLIM,
> presentations[4].....In the CLIM command loop one or more input
> contexts, which expect input of a certain type, are active. Any
> presentation whose type is a subtype of the input context type can then
> be clicked on to provide input."
>
> Now this sounds as if everything your PNG demos is just vanilla CLIM. So
> I am guessing that that 8/17/2002 Strandh&Moore is describing Andy's repl?
>
> I better get that clarified before guessing further. maybe a couple of
> factual queries:
>
> ACCEPT and PRESENT sound to me as if they are just part of CLIM, so I am
> confused again as to where CLIM leaves off and the REPL begins.
ACCEPT and PRESENT are CLIM functions.
See here for the documentation:
http://www.stud.uni-karlsruhe.de/~unk6/clim-spec/23-4.html#_1193
and
http://www.stud.uni-karlsruhe.de/~unk6/clim-spec/23-5.html#_1202
> If
> ACCEPT is however part of the REPL, or eventually pulls the front window
> in as an argument to some GF (ie, if ACCEPT is pure CLIM which
> internally invokes (apply #'window-accept *front-window" accept-args)
> then I can see how the connection can be made.
>
> REPL output be edited qua text? Can object descriptions wrap lines? I
> gather (accept t) lets you select anything on the screen? Can accept
> take a list of types?
Typed output can be anything. It can be text over multiple lines.
It can be graphics. It can be a mixture of both.
(clim:accept t) lets select you anything that has been presented to the
screen.
There are predefined Presentation Types.
http://www.stud.uni-karlsruhe.de/~unk6/clim-spec/23-8.html#_1251
If you want a list of types, you use the presentation type sequence-enumerated.
http://www.stud.uni-karlsruhe.de/~unk6/clim-spec/23-8.html#_1283
On Sun, 01 Feb 2004 03:13:35 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
> OK, first Q. That "lisp listener" window is all CLIM, right? ie, It
> is not the Lispworks Listener? I see the little LW logo, but my LW
> trial has blue/red christmas tree ornaments up there and calls its
> listener "Listener 1", so I am guessing this is Andy's REPL built
> atop CLIM.
Rainer has answered most of the questions. Just to clarify a bit more:
This
<http://agharta.de/clim.png>
is the listener demo included with LWW pro - source is available.
This
<http://agharta.de/mcclim.png>
(see my post from some hours ago) is Andy's listener distributed with
McCLIM and running in CMUCL.
You can see that both are not the original REPL by evaluating
something like (/ 1 0) - you won't end up in the usual debugger.
Note that both are only small examples. See Rainer's movies for what
DW does: You can, e.g. DESCRIBE an object and then edit the slot's
printed representation in DESCRIBE's output to actually change this
object. Also, other than in the LW listener demo above, DESCRIBE's
output is also available as input for ACCEPT.
I think most if not all of this can also be done with CLIM. I'd
certainly be happy if LW would provide me with an IDE like this -
Arial or not. (But maybe McCLIM will be there earlier.)
Cheers,
Edi.
Kenny Tilton <·······@nyc.rr.com> writes:
> OK, first Q. That "lisp listener" window is all CLIM, right? ie, It is
> not the Lispworks Listener? I see the little LW logo, but my LW trial
I am not a LispWorks user, but that window is probably the CLIM
listener included in the LispWorks implementation of CLIM.
> has blue/red christmas tree ornaments up there and calls its listener
> "Listener 1", so I am guessing this is Andy's REPL built atop CLIM.
Do you mean Andy Hefner's CLIM listener? If so, it is McCLIM's
specific and I don't think it can run on other CLIMs.
> Second Q: I see in Robert & Tim's paper, on p3:
>
> "The user can also enter arguments by clicking on graphic objects on the
> screen. This is supported by a fundamental feature of CLIM,
> presentations[4].....In the CLIM command loop one or more input
> contexts, which expect input of a certain type, are active. Any
> presentation whose type is a subtype of the input context type can
> then be clicked on to provide input."
>
> Now this sounds as if everything your PNG demos is just vanilla
> CLIM. So I am guessing that that 8/17/2002 Strandh&Moore is describing
> Andy's repl?
The above mentioned text quoted from the paper by Strandh and Moore
describes standard functionality available to all CLIM
applications. The CLIM listener is just a CLIM application. Indeed, if
I understand the documentation correctly, the Franz CLIM listener is
considered a demo.
> ACCEPT and PRESENT sound to me as if they are just part of CLIM, so I
> am confused again as to where CLIM leaves off and the REPL begins. If
ACCEPT and PRESENT are standard CLIM features not specific to the CLIM
listener. If you often hear about ACCEPT and PRESENT in the context of
a CLIM listener, it's because such a listener is a convenient
"scratch pad" for quick demonstration and experimentation, which is
shipped by most if not all CLIM implementations.
ACCEPT and PRESENT may be used in various ways, including but not
limited to command processors such as a CLIM listener. For example,
you can also use ACCEPT in a dialog to get input via widgets such as
check boxes, text fields, options menus, etc.
> REPL output be edited qua text? Can object descriptions wrap lines? I
> gather (accept t) lets you select anything on the screen? Can accept
> take a list of types?
1) REPL output be edited qua text?
I'm not sure I understand your question. Are you asking whether some
text that has been output as a presentation can later be edited? If
so, I don't know.
2) Can object descriptions wrap lines?
If by object description you mean something that has been output as a
presentation, then the answer is yes.
3) I gather (accept t) lets you select anything on the screen?
There are ways of accepting anything, but I don't remember the syntax
off the top of my head.
4) Can accept take a list of types?
Can you elaborate on why you may want a list of types? What do you
expect the system to do with a list of types? I ask because there may
be ways of syntactically getting what you ask for, but I'm not sure
they provide the functionality you expect.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Others have answered ably already, so I'll just fill in a few details.
Kenny Tilton <·······@nyc.rr.com> writes:
>
> Second Q: I see in Robert & Tim's paper, on p3:
>
> "The user can also enter arguments by clicking on graphic objects on the
> screen. This is supported by a fundamental feature of CLIM,
> presentations[4].....In the CLIM command loop one or more input
> contexts, which expect input of a certain type, are active. Any
> presentation whose type is a subtype of the input context type can
> then be clicked on to provide input."
>
> Now this sounds as if everything your PNG demos is just vanilla
> CLIM. So I am guessing that that 8/17/2002 Strandh&Moore is describing
> Andy's repl?
Things may be a bit confused here because there are a several "CLIM
REPLs" in play in this discussion. Classic CLIM ships with a "Lisp
Listener" demo; I think that's what's demonstrated by the folks
running LispWorks. Andy Hefner's program is similar but contains
additional commands such as "Show Class Superclasses" in a nifty
graph.
However, many if not most CLIM applications have a "command line,"
that is a window in which one can type complex commands and perhaps
see some results there. This is a REPL of a sort, but not a
necessarily a Lisp REPL (i.e. with support for evaluation, a debugger,
etc.) In the paper we described the general way in which commands, and
then the arguments of commands, get entered into an
application. Commands are either named commands typed at the command
line (plus their arguments), commands invoked via menu action, or
perhaps the result of clicking on a previous command or an object with
a translator to a command.
>
> I better get that clarified before guessing further. maybe a couple of
> factual queries:
>
> ACCEPT and PRESENT sound to me as if they are just part of CLIM, so I
> am confused again as to where CLIM leaves off and the REPL begins. If
> ACCEPT is however part of the REPL, or eventually pulls the front
> window in as an argument to some GF (ie, if ACCEPT is pure CLIM which
> internally invokes (apply #'window-accept *front-window" accept-args)
> then I can see how the connection can be made.
This is a good question because CLIM provides a rich set of operators
for dealing with Lisp objects and text. The "form" is a presentation
type provided by CLIM. It's actually one of the hairier ones because
the support for accepting Lisp objects at interior levels of a list
requires some unportable messing with implementation internals. The
Lisp Listener part of the Lisp Listener demo is pretty simple (I've
elided a lot...):
(defmethod read-frame-command ((frame listener)
&key (stream *standard-input*))
"Specialized for the listener, read a lisp form to eval, or a
command."
(multiple-value-bind (object type)
(accept 'command-or-form :stream stream :prompt nil)
(if (presentation-subtypep type 'command)
object
`(com-eval ,object))))
com-eval is a command that evaluates the form, presents all the values
according to their type, juggles all the Lisp top level variables like
*, **, ***, etc. If the user doesn't type a lisp form but instead
types a command (there are two different ways to do this in the
listener: the CLIM way, in which you type a : first, or the Genera
way, implemented by Andy, in which anything that doesn't look like a
Lisp form is interpreted as a command), that will be executed.
> REPL output be edited qua text?
Sort of. If the output is readable, it can be edited when sucked into
a form. If the printed representation is not readable, then the output
can not be edited as the actual Lisp object is embedded in the input
line. That's the ideal, anyway; the McCLIM reality is a little muddled
at the moment :)
>Can object descriptions wrap lines?
Yes.
> I
> gather (accept t) lets you select anything on the screen?
Yes.
>Can accept
> take a list of types?
There's an "or" presentation type, so you can say (accept '(or integer
widget ...))
Tim
In article <···············@trousse.labri.fr>,
Timothy Moore <·····@trousse.labri.fr> wrote:
> com-eval is a command that evaluates the form, presents all the values
> according to their type, juggles all the Lisp top level variables like
> *, **, ***, etc. If the user doesn't type a lisp form but instead
> types a command (there are two different ways to do this in the
> listener: the CLIM way, in which you type a : first, or the Genera
> way, implemented by Andy, in which anything that doesn't look like a
> Lisp form is interpreted as a command), that will be executed.
Genera has a switch for that. Either you prefer commands
(then you need to write ,show to evaluate the variable show)
or you prefer forms (then you need to write :Show ... to
reach the command).
>
> > REPL output be edited qua text?
>
> Sort of. If the output is readable, it can be edited when sucked into
> a form. If the printed representation is not readable, then the output
> can not be edited as the actual Lisp object is embedded in the input
> line. That's the ideal, anyway; the McCLIM reality is a little muddled
> at the moment :)
DW can copy the text of stuff on the screen. Which lets
you paste the stuff textually into the REPL - not only by objects.
Just as a side note, DW also lets you mark objects with the
mouse (like you would select icons on a Mac desktop with
the mouse, displaying a rectangle).
Rainer Joswig <······@lispmachine.de> writes:
> Just as a side note, DW also lets you mark objects with the
> mouse (like you would select icons on a Mac desktop with
> the mouse, displaying a rectangle).
In one of my applications, I'd like to be able to have such a "region"
available as a way to pass a parameter to commands. I'd like that region
to be contiguous as far as the application is concerned. That is, I'd
basically like to define exactly how that region grows as it is
extended. I don't want it to be the result of computing the intersection
of a rectangle with the presentations on the screen. Is there some easy
way to do this in portable CLIM?
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Kenny Tilton <·······@nyc.rr.com> writes:
> REPL output be edited qua text?
No, it can be manipulated qua object, using whatever commands are
defined to operate on that presentation. Of course, this is Lisp, so you
can define new commands at the REPL whenever you want. But you will be
able to get an inspector-like view of the slots and click on them to
manipulate and set their values as well.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Edi Weitz wrote:
> On Fri, 30 Jan 2004 22:44:08 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
>
>
>>Edi Weitz wrote:
>>
>>
>>>I'm still very impressed by this feature and I've seen nothing
>>>comparable in other GUIs. I've shown this to other programmers
>>>(non-Lispers) and all of them were very impressed, too. Could it be
>>>that you didn't really get it because...
>>
>>It was so boring I did not even remember tossing off the same thing
>>(see elsewhere this thread) in a day for the CliniSys app. I mean,
>>those are URLs, right? <yawn>
>
>
> OK, could you try to follow me for thirty seconds, please? If you have
> a copy of LispWorks Pro around you can type in as you read after doing
> something like
>
> (require "clim")
> (require "clim-demo")
> (clim-demo:start-demo)
>
Not on LWM without X11.
Cheers
--
Marco
On Sun, 01 Feb 2004 13:33:15 -0500, Marco Antoniotti <·······@cs.nyu.edu> wrote:
> Not on LWM without X11.
Really? Bummer! It worked for me on LWW pro - obviously also without
X11.
Edi.
In article <·················@nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
> Timothy Moore wrote:
> >
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> > > Timothy Moore wrote:
> > > >
> > > > Selected from where? Do you have a Cello REPL where I can see this in
> > > > action?
> > >
> > > I have an object inspector that will be one of the example apps when
> > > Cello ships. I still have not heard much about the CLIM repl. I gather
> > > it Ls, Rs, Es, and then Ps a (scrolling?) graphical display of the
> > > result. I am guessing there is the default form which is a label showing
> > > princ output and that this label is also a control you can double-click
> > > to inspect, option-click to somehow drop in the next form to be read...
> > > I was asking to see if I wanted to do a Cello REPL as an example app.
> >
> > http://www.bricoworks.com/moore/mcclim.html has an example of the Listener in
> > action.
> >
>
> Thanks. Someone else sent me links to Rainer's (?) movies. Y'all need to
> learn about marketing. Still butt ugly.
Look Kenny, the Symbolics movies are about Dynamic Windows. Not CLIM.
Dynamic Windows is from the 80s. The demos were not intended to
impress people by showing fancy grophics stuff (which can be done),
but more to show how to use the machine for Lisp development.
It may look ugly to you, but it is way cool. And as a power user
interface, it is still among the best.
> And if CLIM is such a powerful
> GUI, it should take 10 minutes to jazz it up. Statements like this from
> the link above make me wonder if Lispniks have lost the ability to
> communicate with non-Lispniks:
>
> "It has many features, but here's one that's especially exciting for
> Lisp programmers: anything that is printed can be used as input when
> typing a form, even if its printed representation isn't readable."
>
> This is what all the CLIM repl excitement is about? puh-leez! If this is
> what we try to impress the world with (even the CL world), it shows we
> need to get out more.
The CLIM listener can do some interesting stuff:
http://lispm.dyndns.org:8000/lisp/pics/toy-story.jpg ;-)
From looking at your home page, I'm not sure your stuff is
looking better. Actually it looks ugly and also quite a bit
non-standard to me. If I compare it to some of the very
nice Mac OS X applications... no comparison. Sorry.
Stuff that looks *much* better to me
is LispWorks' CAPI on Mac OS X
http://lispm.dyndns.org:8000/osx-lisp-env/lwm-panther-1.jpg
or Mirai's (proprietary) window toolkit running in ACL
http://lispm.dyndns.org:8000/lisp/pics/Mirai-P5-Paint-Front.jpg
http://lispm.dyndns.org:8000/lisp/pics/gunhead.jpg.
>>Thanks. Someone else sent me links to Rainer's (?) movies. Y'all need to
>>learn about marketing. Still butt ugly.
>
>
> Look Kenny, the Symbolics movies are about Dynamic Windows. Not CLIM.
Right, i kinda figured that out after a few minutes.
> It may look ugly to you, but it is way cool. And as a power user
> interface, it is still among the best.
No doubt.
> The CLIM listener can do some interesting stuff:
> http://lispm.dyndns.org:8000/lisp/pics/toy-story.jpg ;-)
Now we're marketing! That's the ticket. Take credit for Aqua Windows and
the entire Pixar company. I plan something along the same lines. :)
>
> From looking at your home page, I'm not sure your stuff is
> looking better. Actually it looks ugly ...
<sniff> Agreed. I /told/ them to hire a graphic designer, but would they
listen? Nooooo...
> and also quite a bit
> non-standard to me.
Yeah, yeah, I know. Standard is nice. I think the Web kinda destroyed
that requirement.
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
In article <·························@twister.nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> Yeah, yeah, I know. Standard is nice. I think the Web kinda destroyed
> that requirement.
No, the web destroyed usability. I can't count how many times I go to a
web site and can't figure out how to use it, get frustrated, and leave.
Do you really want to recreate that experience?
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
Brian Mastenbrook wrote:
> In article <·························@twister.nyc.rr.com>, Kenny Tilton
> <·······@nyc.rr.com> wrote:
>
>
>>Yeah, yeah, I know. Standard is nice. I think the Web kinda destroyed
>>that requirement.
>
>
> No, the web destroyed usability. I can't count how many times I go to a
> web site and can't figure out how to use it, get frustrated, and leave.
> Do you really want to recreate that experience?
I think Web designers have it tough because of the thin client. A
"non-standard" GUI can still have scroll bars, buttons, check boxes,
radio groups, menus, pop-up menus, text-edit widgets and be incredibly
recognizable useability wise. Matching the skin (translucent blue
widgets on OS X) would take a lot of work and eliminiate a visual
disparity (which matters) but the "non-standard" I am thinking about
should not affect usability.
kt
Kenny Tilton <·······@nyc.rr.com> writes:
> to do cl-photoshop. But what's all this I here about the CLIM listener?
> What's the feature set with that? I gather the REPL does not just Print,
> it provides a graphical display of the output? And?
You can get the main ideas behind CLIM's presentations from:
Presentation Based User Interfaces
ftp://publications.ai.mit.edu/ai-publications/pdf/AITR-794.pdf
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
On 25 Jan 2004 22:26:05 +0200, Ville Vainio <····························@thisisspamprotectiontut.finland> wrote:
> I've been reading On Lisp, trying to get excited about the
> language. However, while the book may impress a C++ programmer, I
> have to say I'm not particularly impressed.
Looks like you've missed the essence of "On Lisp" - it's about the
power of macros. You don't have them in Python-the-language.
> Common Lisp is not simple.
Yep. The world's not simple either. So what?
> lose the "FP is the way to go" attitude, it mostly serves to turn
> people away from the language.
You must be confusing Lisp with Scheme.
> once I get a good CL for Fedora
Isn't Fedora the successor to Red Hat? If you're on Intel hardware get
the CMUCL binary release tarball, cd to /usr/local and unpack it -
presto. Not very hard. For tons of libraries see CLiki[1], for an easy
way to install many of them see ASDF-INSTALL[2].
Edi.
[1] <http://www.cliki.net/>
[2] <http://weitz.de/asdf-install/>
Edi Weitz wrote:
>>once I get a good CL for Fedora
>
>
> Isn't Fedora the successor to Red Hat? If you're on Intel hardware get
> the CMUCL binary release tarball, cd to /usr/local and unpack it -
> presto. Not very hard. For tons of libraries see CLiki[1], for an easy
> way to install many of them see ASDF-INSTALL[2].
Hasn't Fedora put in some randomized mmap security hack that screws
up many lisps?
Paul
<·····@dls.net> wrote:
>> Isn't Fedora the successor to Red Hat? If you're on Intel hardware get
>> the CMUCL binary release tarball, cd to /usr/local and unpack it -
>> presto. Not very hard. For tons of libraries see CLiki[1], for an easy
>> way to install many of them see ASDF-INSTALL[2].
>
>Hasn't Fedora put in some randomized mmap security hack that screws
>up many lisps?
"Screws up" is putting it pretty strongly. The map randomization and
noexec-stack changes don't have any effect on programs that have been
built on a non-bleeding-edge binutils/gcc. So there should be no
problems with running an old binary release of a Lisp on Fedora.
Also, a freshly compiled SBCL seems to work well enough. It runs my
clx-using app, and it "apparently succeeds" in running the SBCL
regression tests. This was however done using some extra flags for
gcc/ld, which are supposed to prevent the exec-shield stuff from
kicking in.
--
Juho Snellman
······@iki.fi (Juho Snellman) writes:
> >Hasn't Fedora put in some randomized mmap security hack that screws
> >up many lisps?
>
> "Screws up" is putting it pretty strongly. The map randomization and
> noexec-stack changes don't have any effect on programs that have been
> built on a non-bleeding-edge binutils/gcc. So there should be no
> problems with running an old binary release of a Lisp on Fedora.
I haven't heard about this mmap randomization. I've found some
mentions of it through google but it's not obvious how it works or
what it's supposed to do. Is there a canonical place to read about
it? tnx.
<·············@NOSPAM.invalid> wrote:
>I haven't heard about this mmap randomization. I've found some
>mentions of it through google but it's not obvious how it works or
>what it's supposed to do. Is there a canonical place to read about
>it? tnx.
Try these links on how it works:
http://people.redhat.com/mingo/exec-shield/ANNOUNCE-exec-shield
http://marc.theaimsgroup.com/?l=linux-kernel&m=106457962917828&w=2
--
Juho Snellman
Hi Paul Rubin,
> ······@iki.fi (Juho Snellman) writes:
>> >Hasn't Fedora put in some randomized mmap security hack that screws
>> >up many lisps?
>>
>> "Screws up" is putting it pretty strongly. The map randomization and
>> noexec-stack changes don't have any effect on programs that have been
>> built on a non-bleeding-edge binutils/gcc. So there should be no
>> problems with running an old binary release of a Lisp on Fedora.
>
> I haven't heard about this mmap randomization. I've found some
> mentions of it through google but it's not obvious how it works or
> what it's supposed to do. Is there a canonical place to read about
> it? tnx.
Not canonical, but here are links to some of the Lisp implementation
issues:
<http://mail.gnu.org/archive/html/axiom-developer/2003-11/msg00163.html>
<http://mail.gnu.org/archive/html/axiom-developer/2003-12/msg00005.html>
<http://mail.gnu.org/archive/html/axiom-developer/2003-12/msg00008.html>
<http://mail.gnu.org/archive/html/axiom-developer/2003-12/msg00011.html>
Regards,
Adam
In article <··············@bird.agharta.de>, Edi Weitz <···@agharta.de>
wrote:
> > lose the "FP is the way to go" attitude, it mostly serves to turn
> > people away from the language.
>
> You must be confusing Lisp with Scheme.
Actually a repsonsible Schemer will tell you that Scheme is not really
a Functional Programming language, it's a Continual programming
language. The basic currency of Scheme is the implicit continuation,
not the function.
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
>>>>> "Edi" == Edi Weitz <···@agharta.de> writes:
Edi> Isn't Fedora the successor to Red Hat? If you're on Intel
Edi> hardware get the CMUCL binary release tarball, cd to
Edi> /usr/local and unpack it - presto. Not very hard. For tons of
Edi> libraries see CLiki[1], for an easy way to install many of
Edi> them see ASDF-INSTALL[2].
I tried the tarball. It worked, kinda, but trying to start the editor
failed - and I assumed there would be other problems. It has to do w/
Fedora's exec-shield or something, and the fact that lisps expect the
stack to be executable. I'm waiting for a more "verified-to-work"
version, preferably in fedora repos.
--
Ville Vainio http://tinyurl.com/2prnb
Ville Vainio <····························@thisisspamprotectiontut.finland> writes:
> I tried the tarball. It worked, kinda, but trying to start the
> editor failed - and I assumed there would be other problems. It has
> to do w/ Fedora's exec-shield or something, and the fact that lisps
> expect the stack to be executable. I'm waiting for a more
> "verified-to-work" version, preferably in fedora repos.
um. perhaps you could help me understand this strange phenomenon: you
run a bleeding-edge Linux distribution, and yet you appear to value
having ready-to-run packaged software very (I'd even say
"suspiciously") highly. something doesn't add up here.
get Clisp and perform the usual configure-make-install on it. should
be easy enough for you, and should even provide just the kind of
repetitive challenge that typical Linux users seem to love so much.
--
The whole idea of modules is so separatist, anyway. Can't we all just
get along? -- Jim Blandy
Michael Livshin wrote:
> Ville Vainio
> <····························@thisisspamprotectiontut.finland>
> writes:
>
>> I tried the tarball. It worked, kinda, but trying to start the
>> editor failed - and I assumed there would be other problems. It has
>> to do w/ Fedora's exec-shield or something, and the fact that lisps
>> expect the stack to be executable. I'm waiting for a more
>> "verified-to-work" version, preferably in fedora repos.
>
> um. perhaps you could help me understand this strange phenomenon: you
> run a bleeding-edge Linux distribution, and yet you appear to value
> having ready-to-run packaged software very (I'd even say
> "suspiciously") highly. something doesn't add up here.
>
> get Clisp and perform the usual configure-make-install on it. should
> be easy enough for you, and should even provide just the kind of
> repetitive challenge that typical Linux users seem to love so much.
I have never used Linux,
[Digression: well I turned on once RedHat 8, found the games directory
played them, got annoyed with printing command, i.e. it wasn't enough to
click print but I was also required to add a few parameters to the command
line, turned pc off and went back to using windows.]
and I wanted to give it a try however I must be able to use easily lisp on
it so I was wondering which Linux release would you suggest I try?
"news.ox.ac.uk" <·······@*the-mail-that-burns*.com> writes:
> I have never used Linux, [Digression: well I turned on once RedHat
> 8, found the games directory played them, got annoyed with printing
> command, i.e. it wasn't enough to click print but I was also
> required to add a few parameters to the command line, turned pc off
> and went back to using windows.] and I wanted to give it a try
> however I must be able to use easily lisp on it so I was wondering
> which Linux release would you suggest I try?
if you want to try Lisp, stay with Windows and get an evaluation
version of either Xanalys' (<URL:http://www.lispworks.com/>) or
(<URL:http://www.franz.com/>) Franz's CL environments. they are
limited but good enough for learning on, and come with nice IDE's.
--
All ITS machines now have hardware for a new machine instruction --
BAH
Branch And Hang.
Please update your programs.
Michael Livshin wrote:
> "news.ox.ac.uk" <·······@*the-mail-that-burns*.com> writes:
>
>> I have never used Linux, [Digression: well I turned on once RedHat
>> 8, found the games directory played them, got annoyed with printing
>> command, i.e. it wasn't enough to click print but I was also
>> required to add a few parameters to the command line, turned pc off
>> and went back to using windows.] and I wanted to give it a try
>> however I must be able to use easily lisp on it so I was wondering
>> which Linux release would you suggest I try?
>
> if you want to try Lisp, stay with Windows and get an evaluation
> version of either Xanalys' (<URL:http://www.lispworks.com/>) or
> (<URL:http://www.franz.com/>) Franz's CL environments. they are
> limited but good enough for learning on, and come with nice IDE's.
Thanks for the reply but I have already been using lisp for the past couple
of years,
it's more of a windows-->linux question and what people felt was the best
linux version
for lisp users; I suspect Debian is the answer but maybe being a total newby
(to linux)
RedHat might be better or Xandros or some and such. I post the question here
rather than
to a linux newsgroup as I would like to know the opinion of lisp users on
the topic.
"Rmagere" <·······@*the*mail*that*burns*.com> writes:
> Thanks for the reply but I have already been using lisp for the past couple
> of years,
> it's more of a windows-->linux question and what people felt was the best
> linux version
> for lisp users; I suspect Debian is the answer but maybe being a total newby
> (to linux)
> RedHat might be better or Xandros or some and such. I post the question here
> rather than
> to a linux newsgroup as I would like to know the opinion of lisp users on
> the topic.
In my experience, RedHat and SuSE are both easier to install than
Debian. On the other hand, Debian is much easier to update. I used to
use RedHat and SuSE, was quite happy with them for a while but got
tired of hunting down software packages and keeping my system
consistent over updates. Then I moved to Debian, found the
installation process annoying (there's excellent documentation on the
web, but you have to do _everything_ manually), but felt rewarded with
Debian's centrally-managed packages. Now I see the tiresome
installation process as an investment which pays after a while.
The Lisp support of Debian is better than for RedHat and SuSE and
adequate for my needs (I hear that Gentoo's is quite ok, too). I
particularly like that I can get a number of useful CL packages
automatically installed and removed from my system. After previous
experiences this feels like magic. ;-)
Your needs and/or experiences may differ. (Note that to some people
discussing Linux-Distros is a matter of religion, similar to peoples'
preferences for programming languages or text editors.)
Matthias wrote:
> In my experience, RedHat and SuSE are both easier to install than
> Debian. On the other hand, Debian is much easier to update. I used to
> use RedHat and SuSE, was quite happy with them for a while but got
> tired of hunting down software packages and keeping my system
> consistent over updates. Then I moved to Debian, found the
> installation process annoying (there's excellent documentation on the
> web, but you have to do _everything_ manually), but felt rewarded with
> Debian's centrally-managed packages. Now I see the tiresome
> installation process as an investment which pays after a while.
>
> The Lisp support of Debian is better than for RedHat and SuSE and
> adequate for my needs (I hear that Gentoo's is quite ok, too). I
> particularly like that I can get a number of useful CL packages
> automatically installed and removed from my system. After previous
> experiences this feels like magic. ;-)
>
> Your needs and/or experiences may differ. (Note that to some people
> discussing Linux-Distros is a matter of religion, similar to peoples'
> preferences for programming languages or text editors.)
Thanks for your reply, I think that I'll probably try out RedHat and if I
manage to cope
for a while I'll then give Debian a shot.
rmagere wrote:
>
> Matthias wrote:
> > In my experience, RedHat and SuSE are both easier to install than
> > Debian. On the other hand, Debian is much easier to update. I used to
> > use RedHat and SuSE, was quite happy with them for a while but got
> > tired of hunting down software packages and keeping my system
> > consistent over updates. Then I moved to Debian, found the
> > installation process annoying (there's excellent documentation on the
> > web, but you have to do _everything_ manually), but felt rewarded with
> > Debian's centrally-managed packages. Now I see the tiresome
> > installation process as an investment which pays after a while.
> >
> > The Lisp support of Debian is better than for RedHat and SuSE and
> > adequate for my needs (I hear that Gentoo's is quite ok, too). I
> > particularly like that I can get a number of useful CL packages
> > automatically installed and removed from my system. After previous
> > experiences this feels like magic. ;-)
> >
> > Your needs and/or experiences may differ. (Note that to some people
> > discussing Linux-Distros is a matter of religion, similar to peoples'
> > preferences for programming languages or text editors.)
>
> Thanks for your reply, I think that I'll probably try out RedHat and if I
> manage to cope
> for a while I'll then give Debian a shot.
And the correct answer is.....Knoppix!
http://www.knoppix.net/
Jay Sulzberger said it was the only way to go. True that.
It's not just Linux bootable from a CD, it is also the easiest install.
The only evil bit is partitioning the drive, other than that this utter
Linux ignoramus (me) was astonished to see a gorgeous KDE desktop pop-up
after an otherwise hands-off install.
btw, there are at least two sets of directions on the HD install on the
web. I could not follow the offical one. This one is the way to go:
http://search.netscape.com/ns/boomframe.jsp?query=knoppix+hd+install+minutes&page=1&offset=0&result_url=redir%3Fsrc%3Dwebsearch%26amp%3BrequestId%3D2439263d48574c3a%26amp%3BclickedItemRank%3D7%26amp%3BuserQuery%3Dknoppix%2Bhd%2Binstall%2Bminutes%26amp%3BclickedItemURN%3Dhttp%253A%252F%252Fwww.freenet.org.nz%252Fmisc%252Fknoppix-install.html%26amp%3BinvocationType%3D-%26amp%3BfromPage%3DNSCPResults&remove_url=http%3A%2F%2Fwww.freenet.org.nz%2Fmisc%2Fknoppix-install.html
Ha-ha-ha. That just shows what kind of assholes work at Netscape, they
don't let you out of their site. Try:
http://www.freenet.org.nz/misc/knoppix-install.html
btw, The Lisp-NYC Music SIG inaugural open meeting was favored with the
attendance of none other than Knoppix author and composer Klaus Knopper,
thx to Jay having dragged him to the meeting. Klaus explained that
Knoppix was easy because he himself hated hassling with computers.
kenny
--
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Andr� Thieme wrote:
>
> Kenny Tilton wrote:
>
> > And the correct answer is.....Knoppix!
> >
> > http://www.knoppix.net/
> >
>
> What about Gnoppix?
>
> http://www.gnoppix.org/
Never heard of it till now. All I know is that my version of Netscape
cannot display their HTML properly. :)
kt
--
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Thanks for all the replies. At the end I think that I will now burn a copy
of Knoppix as I like the option of running it from the cd without having to
mess up with any of my current settings. Once I get more into linux I'll
look on the other suggestions (Debian, Gnoppix, FreeBSD).
On Tue, 27 Jan 2004 09:54:01 -0000, "rmagere" <·······@*the-mail-that-burns*.com> wrote:
> Once I get more into linux I'll look on the other suggestions
> (Debian, Gnoppix, FreeBSD).
Just to avoid misconceptions:
1. FreeBSD is not a Linux distribution but a completely different
operating system. Both FreeBSD and Linux are "free" and Unix-like,
though.
2. Knoppix basically is Debian but with the option (as you said) to
run it from CD (which'll make it slow, of course) and an easy way
(compared to plain Debian) to install it. Once you have it
installed on your HD you basically have a Debian system which is a
mix of stable, testing, and unstable. (Look up the Debian docs to
see what these terms mean.)
3. AFAIK, Gnoppix is very similar to Knoppix but the GUI is
different. Knoppix uses KDE, Gnoppix uses Gnome. Gnoppix is rather
new compared to Knoppix.
Edi.
Edi Weitz <···@agharta.de> writes:
> On Tue, 27 Jan 2004 09:54:01 -0000, "rmagere" <·······@*the-mail-that-burns*.com> wrote:
>
> > Once I get more into linux I'll look on the other suggestions
> > (Debian, Gnoppix, FreeBSD).
>
> Just to avoid misconceptions:
>
> 1. FreeBSD is not a Linux distribution but a completely different
> operating system. Both FreeBSD and Linux are "free" and Unix-like,
> though.
And to avoid another misconception:
- A Linux system is not a Linux system but a GNU/Linux system
(mostly a GNU system with a Linux kernel).
- A FreeBSD system may also have im-ported some GNU software, even
if it is originally as BSD code a fullfleshed system, it becomes
really usable only with a minimum of GNU tools.
So he could have said: "Once I get more into GNU systems, I'll look on the
other suggestions of packaging and kernel (Debian, Gnoppix, FreeBSD)."
> 2. Knoppix basically is Debian but with the option (as you said) to
> run it from CD (which'll make it slow, of course) and an easy way
> (compared to plain Debian) to install it. Once you have it
> installed on your HD you basically have a Debian system which is a
> mix of stable, testing, and unstable. (Look up the Debian docs to
> see what these terms mean.)
>
> 3. AFAIK, Gnoppix is very similar to Knoppix but the GUI is
> different. Knoppix uses KDE, Gnoppix uses Gnome. Gnoppix is rather
> new compared to Knoppix.
>
> Edi.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Pascal Bourguignon wrote:
> And to avoid another misconception:
>
> - A Linux system is not a Linux system but a GNU/Linux system
> (mostly a GNU system with a Linux kernel).
>
> - A FreeBSD system may also have im-ported some GNU software, even
> if it is originally as BSD code a fullfleshed system, it becomes
> really usable only with a minimum of GNU tools.
>
> So he could have said: "Once I get more into GNU systems, I'll look on the
> other suggestions of packaging and kernel (Debian, Gnoppix, FreeBSD)."
The fact that a FreeBSD system contains "a minimum of GNU tools"
is not sufficient reason to call it a "GNU system". Not even Richard
Stallman claims that. GNU's excellent reputation is not helped by
making excessively strong claims about everything in the world
being really "a GNU system".
--
Gareth McCaughan
.sig under construc
In article <············@news.ox.ac.uk>,
"rmagere" <·······@*the-mail-that-burns*.com> writes:
> Matthias wrote:
>> In my experience, RedHat and SuSE are both easier to install than
>> Debian. On the other hand, Debian is much easier to update. I used to
>> use RedHat and SuSE, was quite happy with them for a while but got
>> tired of hunting down software packages and keeping my system
>> consistent over updates. Then I moved to Debian, found the
>> installation process annoying (there's excellent documentation on the
>> web, but you have to do _everything_ manually), but felt rewarded with
>> Debian's centrally-managed packages. Now I see the tiresome
>> installation process as an investment which pays after a while.
>>
>> The Lisp support of Debian is better than for RedHat and SuSE and
>> adequate for my needs (I hear that Gentoo's is quite ok, too). I
>> particularly like that I can get a number of useful CL packages
>> automatically installed and removed from my system. After previous
>> experiences this feels like magic. ;-)
>>
>> Your needs and/or experiences may differ. (Note that to some people
>> discussing Linux-Distros is a matter of religion, similar to peoples'
>> preferences for programming languages or text editors.)
>
> Thanks for your reply, I think that I'll probably try out RedHat and if I
> manage to cope
> for a while I'll then give Debian a shot.
there are a couple of debian derived distributions (iirc, libranet and
xandros among them) that seem to be as easy to install as redhat or
mandrake. even if they don't include the lisp packages in the
distribution, it should be no problem to install the the debian
packages on them. check out distrowatch.org
hs
--
Not everything that counts can be counted,
not everything that can be counted counts.
A. Einstein
"Rmagere" <·······@*the*mail*that*burns*.com> writes:
[...]
> for lisp users; I suspect Debian is the answer but maybe being a
> total newby (to linux) RedHat might be better or Xandros or some
> and such. I post the question here rather than to a linux newsgroup
> as I would like to know the opinion of lisp users on the topic.
I'll stir the pot a little and throw in FreeBSD. Installation of '3rd
party' software is fairly easy. To install clisp:
$ cd /usr/ports/lang/clisp
$ make install clean
Done.
There's also:
. /usr/ports/lang/cmucl
. /usr/ports/lang/sbcl
The above works for about 10,000 different applications that are in
the Ports tree. Very handy.
--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
David Magda wrote:
> I'll stir the pot a little and throw in FreeBSD. Installation of '3rd
> party' software is fairly easy. To install clisp:
>
> $ cd /usr/ports/lang/clisp
> $ make install clean
>
> Done.
Better, you only need to do that for one port and thereafter
it's
$ portinstall clisp
and you're done. And
$ portupgrade clisp
from time to time, assuming you're keeping your ports tree
up to date somehow.
--
Gareth McCaughan
.sig under construc
Michael Livshin <······@cmm.kakpryg.net> writes:
> um. perhaps you could help me understand this strange phenomenon: you
> run a bleeding-edge Linux distribution, and yet you appear to value
> having ready-to-run packaged software very (I'd even say
> "suspiciously") highly. something doesn't add up here.
Sorry. I use debian. It seems like a perfectly normal desire to me.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
>>>>> "Michael" == Michael Livshin <······@cmm.kakpryg.net> writes:
Michael> um. perhaps you could help me understand this strange
Michael> phenomenon: you run a bleeding-edge Linux distribution,
Michael> and yet you appear to value having ready-to-run packaged
Michael> software very (I'd even say "suspiciously") highly.
Michael> something doesn't add up here.
This is widely off topic, but I don't see how being on bleeding edge
and appreciating packaged software don't mix.
Michael> get Clisp and perform the usual configure-make-install on
Michael> it. should be easy enough for you, and should even
Michael> provide just the kind of repetitive challenge that
Michael> typical Linux users seem to love so much.
ISTR I tried compiling clisp and it bombed in some way (probably
Fedora happened). I thought going for cmucl might be a better idea in
the first place, according to the stuff I've read.
--
Ville Vainio http://tinyurl.com/2prnb
Edi Weitz wrote:
>
> On 25 Jan 2004 22:26:05 +0200, Ville Vainio <····························@thisisspamprotectiontut.finland> wrote:
>
> > I've been reading On Lisp, trying to get excited about the
> > language. However, while the book may impress a C++ programmer, I
> > have to say I'm not particularly impressed.
>
> Looks like you've missed the essence of "On Lisp" - it's about the
> power of macros. You don't have them in Python-the-language.
Good point!
kt
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
>>>>> "VV" == Ville Vainio <····························@thisisspamprotectiontut.finland> writes:
[...]
VV> Also, Lisp mostly impressed me initially because it was simple
VV> and orthogonal. Reading On Lisp kinda crushed that illusion
VV> for me - Common Lisp is not simple.
What part did you find complicated? On Lisp is not intended for people
who are new to the language (IMHO, dunno what Graham intended but he did
author another, more accessible book, ANSI Common Lisp).
VV> ... It wouldn't hurt to get cmucl (or other CL implementation)
VV> into Fedora, either.
Unfortunately not many of the developers run Red Hat and derivatives.
Debian seems to be the preferred distribution.
VV> Write some interesting libraries,
VV> demonstrate people how easy they are to use (I checked out
VV> Python after seeing how easy CORBA was there), make scripting
VV> tasks easy, lose the "FP is the way to go" attitude, [...]
We don't have a "FP is the way to go" attitude. I agree making
scripting tasks easy would entice people into the language, but
outside of ease of marketing I don't see the value. We don't use lisp
for scripting, and we are not really system administrators. Other
than vendors and OS CL developers who hang out here, most others with
a professional interest in lisp use it to solve problems they did not
know how to solve xx weeks ago. Sometimes they use it to solve
problems nobody knew how to solve xx weeks ago. Scripting does not
seem to be one of those problems. It doesn't need to stay this way,
of course. I agree that several languages got designed purely for
scripting and then became general purpose when the initial user base
found out they were good enough. The converse doesn't seem to be
the case (eg C doesn't grow 'scripting' features, neither did Smalltalk
or any of the Wirth languages etc.)
VV> ... Make easy things
VV> easy.
What easy thing, in your opinion, is hard in CL? Is it that libraries
are not available for what you take for granted in Python or is it some
language feature you find hard?
VV> Implement a simpler, less powerful standard object
VV> system (as opposed to telling people to implement their own or
VV> use CLOS).
Again what feature of CLOS would you remove?
VV> As it stands, I can easily advocate Python to my colleagues,
VV> confident that they will love it if they just take a few hours
VV> to epxlore it. However, I can't realistically expect them to
VV> take a brief look at Lisp and love it.
What's the rush? Have them take a longer look maybe?
VV> [... On SICP...] Blame it
VV> on pedagogics, but if the course taught Python, it would have
VV> required an extraordinarily crappy teacher to make me not want
VV> to use the language after the course. [...]
I am not familiar enough with Python to tell if the entire SICP can be
easily done with it without the syntax or other language deficiencies
getting in the way. I came to common lisp by way of SICP too (tho I
had attempted 'Anatomy of Lisp' on my own before that) but I suspect
times have changed (this was late 80's and student jobs involving
Lisp Machines could be had back then, so knowing something lispy or
better yet being OK at something lispy did have practical rewards).
cheers,
BM
Bulent Murtezaoglu <··@acm.org> writes:
> We don't use lisp for scripting, and we are not really system
> administrators.
Speak for yourself. :)
At my internship at Lucent, I used OpenMCL to script some benchmarks and
collect and analyze the results. I started doing it using bash, and then
realized that it was going to be so much easier to do in OpenMCL.
Lisp isn't really that hard to use for scripting. Without a CLIM
listener, it can be tedious (that is, only slightly more tedious than a
unix shell) for interactive use, but with a CLIM listener, it's far
easier. Being able to click on a file in a listing in order to use it as
a parameter is far easier than trying to copy the current dir from the
prompt and then the filename and then trying to quote it properly.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
I guess answering to this one covers most of the points in other
posts, so here goes.
>>>>> "Bulent" == Bulent Murtezaoglu <··@acm.org> writes:
VV> Also, Lisp mostly impressed me initially because it was simple
VV> and orthogonal. Reading On Lisp kinda crushed that illusion
VV> for me - Common Lisp is not simple.
Bulent> What part did you find complicated? On Lisp is not
Well, all of the sharp-quoting for starters. Seperate namespace for
functions seems to cause nothing but harm. This is more of an issue
for CL, not On Lisp.
Recently I implemented a toy Lisp system in python where I could do:
(setq myfunc (lambda (x) (+ x 1)))
(setq res (myfunc 6))
All the #' in CL seemed like an unnecessary hassle.
Bulent> intended for people who are new to the language (IMHO,
Bulent> dunno what Graham intended but he did author another, more
Bulent> accessible book, ANSI Common Lisp).
ACL didn't appear to be available for download, so that was not an
option. Python experience has conditioned me to expect free
documentation, so I kinda expected the same from Lisp. I guess that
shouldn't be too much to ask for a 50 year old language that is still
very much alive ;-).
Bulent> We don't have a "FP is the way to go" attitude. I agree
Well, Paul Graham has. I, perhaps too hastily, extrapolated that to
apply for rest of the Lisp community, probably because mr. Graham
seems to be an "opinion leader" of a sort here.
Bulent> making scripting tasks easy would entice people into the
Bulent> language, but outside of ease of marketing I don't see the
Bulent> value. We don't use lisp for scripting, and we are not
Bulent> really system administrators. Other than vendors and OS
Scripting is not just for system administrators. Implementing test
environments, prototypes, build systems etc. is a part of programming
these days.
As for marketing, I consider the user base of a language hugely
important, and I don't see why Lisp ppl wouldn't care whether anyone
else is using their language. Scripting is a good way to sneak in a
language through a back door. It's also the one niche where a
programmer has the best opportunity to introduce new languages. The
main implementation language is often determined by the company, and
finding a job where Lisp is the main language is not very likely, at
least at this time.
Bulent> CL developers who hang out here, most others with a
Bulent> professional interest in lisp use it to solve problems
Bulent> they did not know how to solve xx weeks ago. Sometimes
Perhaps my problem is that I don't really have problems that I don't
know how to solve. I'm mostly checking out Lisp for recreational
value. I dunno, I guess I'm just looking for the same rush I got when
first learning Python, and expected On Lisp to provide it. Apparently
Lisp just takes more time to grow on you.
VV> ... Make easy things easy.
Bulent> What easy thing, in your opinion, is hard in CL? Is it
Bulent> that libraries are not available for what you take for
Bulent> granted in Python or is it some language feature you find
Bulent> hard?
Pretty much. I would like to see an Open Source Lisp implementation
with a big standard library, providing sockets, normal posix stuff,
and generally most of the stuff in the Python standard library. And in
equally easy to use form.
VV> Implement a simpler, less powerful standard object system (as
VV> opposed to telling people to implement their own or use CLOS).
Bulent> Again what feature of CLOS would you remove?
CLOS just seemed to be rather arcane and verbose as a whole. I admit I
haven't really put much energy into getting to know it, because I
didn't have a good implementation (as elisp implementation is a bit
lacking). "Common Lisp: the language, 2nd edition" didn't really help,
to say the least.
To me a following object system (requiring tweaking the Lisp reader to
grok '.', I assume) might have had a more immediate appeal:
(defclass MyClass (Base1 Base2)
(def init (x y) (
(setq self.x x)
(setq self.y y)))
(def say () (
(print self.x self.y))))
(setq instance (MyClass 4 5))
(instance.say)
I know that the model has zillions of problems, and shredding it to
pieces is not really worth it. Just showing what kind of aesthetic I
like.
But I guess this is just a matter of prejudice - I might change my
mind immediately when I actually try CLOS on real CL. I'm certainly
going to.
VV> to epxlore it. However, I can't realistically expect them to
VV> take a brief look at Lisp and love it.
Bulent> What's the rush? Have them take a longer look maybe?
We really only have room for a scripting langauge - our main
implementation language is not going to change (it's C++, because of
the target platform). I don't feel that a significant investment of
time for learning Lisp would be worth it for them, at least in direct
professional sense. I'm also afraid that the initial disgust at
parentheses would turn them away quickly - I'm past that point myself,
but I certainly couldn't blame them.
VV> [... On SICP...] Blame it on pedagogics, but if the course
VV> taught Python, it would have required an extraordinarily
VV> crappy teacher to make me not want to use the language after
VV> the course. [...]
Bulent> I am not familiar enough with Python to tell if the entire
Bulent> SICP can be easily done with it without the syntax or
Bulent> other language deficiencies getting in the way. I came to
Our course wasn't SICP; it was "Programming I", the first programming
course at school. It could certainly have been Python. We didn't even
touch macros - it was basically an FP course.
--
Ville Vainio http://tinyurl.com/2prnb
Ville Vainio <·····@spammers.com> writes:
> snip
> Perhaps my problem is that I don't really have problems that I don't
> know how to solve. I'm mostly checking out Lisp for recreational
> value. I dunno, I guess I'm just looking for the same rush I got when
> first learning Python, and expected On Lisp to provide it. Apparently
> Lisp just takes more time to grow on you.
>
Could it be that you are checking out Lisp just to 'make sure' that it's
not better than Python? To sort of confirm your hope that Python is the
right language to be using. After all, switching languages can be a pain.
On Lisp is absolutely the wrong book to start with. It's definitely not
for beginners. Oh, and speaking of free documentation, have you heard of
the CLHS?
--
Jock Cooper
http://www.fractal-recursions.com
On Mon, Jan 26, 2004 at 09:25:35PM +0200, Ville Vainio wrote:
>
> I guess answering to this one covers most of the points in other
> posts, so here goes.
>
> >>>>> "Bulent" == Bulent Murtezaoglu <··@acm.org> writes:
>
> VV> Also, Lisp mostly impressed me initially because it was simple
> VV> and orthogonal. Reading On Lisp kinda crushed that illusion
> VV> for me - Common Lisp is not simple.
>
> Bulent> What part did you find complicated? On Lisp is not
>
> Well, all of the sharp-quoting for starters. Seperate namespace for
> functions seems to cause nothing but harm. This is more of an issue
> for CL, not On Lisp.
>
> Recently I implemented a toy Lisp system in python where I could do:
>
> (setq myfunc (lambda (x) (+ x 1)))
> (setq res (myfunc 6))
>
> All the #' in CL seemed like an unnecessary hassle.
Sure, until you realize that it means you can name your variables sanely
(ie. list). And that it saves you the hassle of having to understand a
hygenic macro system. On a slightly related note, being able to pass
around function names and funcalling them gives you the layer of
indirection necessary to be able to redefine functions on the fly. This
is very much a concern to CLers, though not so much to Schemers or other
people who fancy FP, I imagine.
I find #' to be no hassle at all, and I even choose to use it where it
is not required (with LAMBDA).
> Bulent> intended for people who are new to the language (IMHO,
> Bulent> dunno what Graham intended but he did author another, more
> Bulent> accessible book, ANSI Common Lisp).
>
> ACL didn't appear to be available for download, so that was not an
> option. Python experience has conditioned me to expect free
> documentation, so I kinda expected the same from Lisp. I guess that
> shouldn't be too much to ask for a 50 year old language that is still
> very much alive ;-).
Free documentation is one thing. Free books are another. ANSI Common
Lisp is a published book, and without the publisher's consent or
reassignment of rights, it is not free to copy. I suggest you go to
CLiki and check out the online documentation that is free.
> VV> ... Make easy things easy.
>
> Bulent> What easy thing, in your opinion, is hard in CL? Is it
> Bulent> that libraries are not available for what you take for
> Bulent> granted in Python or is it some language feature you find
> Bulent> hard?
>
> Pretty much. I would like to see an Open Source Lisp implementation
> with a big standard library, providing sockets, normal posix stuff,
> and generally most of the stuff in the Python standard library. And in
> equally easy to use form.
I believe that this already exists to a large extent. At least, I don't
have much trouble doing what I need to do (which involves sockets, some
posix stuff, some libraries). I would hardly use the word "standard" in
connection with this though. I don't think you realize that the word
"standard" in this newsgroup carries a much more serious connotation
than in the Python newsgroup, apparently. Common Lisp has an actual
standard, with ANSI, and part of that is an actual "standard library".
Python has no such thing. It is ridiculous, in this context, to assert
that Python has any sort of "standard library" such as CL has. However,
there are many non-"standard libraries" which provide desired
functionality, and are even ported to the many CL platforms that exist.
> VV> Implement a simpler, less powerful standard object system (as
> VV> opposed to telling people to implement their own or use CLOS).
>
> Bulent> Again what feature of CLOS would you remove?
>
> CLOS just seemed to be rather arcane and verbose as a whole. I admit I
> haven't really put much energy into getting to know it, because I
> didn't have a good implementation (as elisp implementation is a bit
> lacking). "Common Lisp: the language, 2nd edition" didn't really help,
> to say the least.
>
> To me a following object system (requiring tweaking the Lisp reader to
> grok '.', I assume) might have had a more immediate appeal:
>
> (defclass MyClass (Base1 Base2)
> (def init (x y) (
> (setq self.x x)
> (setq self.y y)))
> (def say () (
> (print self.x self.y))))
>
>
> (setq instance (MyClass 4 5))
>
> (instance.say)
>
> I know that the model has zillions of problems, and shredding it to
> pieces is not really worth it. Just showing what kind of aesthetic I
> like.
>
> But I guess this is just a matter of prejudice - I might change my
> mind immediately when I actually try CLOS on real CL. I'm certainly
> going to.
I can tell you right now that it is a matter of prejudice since I went
through the same stages. The key to understanding CLOS is to realize
that object systems don't have to follow the Java/C++ model (which is a
relative newcomer anyway).
> professional sense. I'm also afraid that the initial disgust at
> parentheses would turn them away quickly - I'm past that point myself,
> but I certainly couldn't blame them.
I would. That's juvenile.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish <·······@andrew.cmu.edu> wrote in message news:<·····················@mapcar.org>...
> On Mon, Jan 26, 2004 at 09:25:35PM +0200, Ville Vainio wrote:
>
>
> > All the #' in CL seemed like an unnecessary hassle.
>
> Sure, until you realize that it means you can name your variables sanely
> (ie. list). And that it saves you the hassle of having to understand a
> hygenic macro system. On a slightly related note, being able to pass
> around function names and funcalling them gives you the layer of
> indirection necessary to be able to redefine functions on the fly. This
> is very much a concern to CLers, though not so much to Schemers or other
> people who fancy FP, I imagine.
>
Would someone be willing to describe these advantages in a bit more
detail? As a newbie to both Scheme and CL, I too find CL's #' a hassle
compared to the Scheme way of treating an expression that evaluates to
a function just the same as a function name, and not having to think
about the rules for when to quote or sharp-quote or
funcall-sharp-quote....
Of course having to think about the rules for a while until you
internalise them is standard in programming, and I don't care as long
as any additional comnplexity buys me proportional (or more)
advantage. But I haven't heard any advantages of this design beyond
being able to use the same identifier for two different things.
The books all say that you have to use funcall and sharp-quotes in CL,
but they don't say why it was designed this way.
Now Matthew is referring to some interesting-sounding advantages of
this approach that I haven't read about in the books. I've already
gone from tolerating the parentheses to preferring them, after
learning the advantages, and I'd be very pleased if the same could
happen for funcall and sharp-quotes --especially since there's nothing
I can do about them. Then I could move it from the "costs of CL" to
the "benefits of CL" category in my mind. ;-)
On Thu, Jan 29, 2004 at 01:01:34AM -0800, Tuang wrote:
> Matthew Danish <·······@andrew.cmu.edu> wrote in message news:<·····················@mapcar.org>...
> > On Mon, Jan 26, 2004 at 09:25:35PM +0200, Ville Vainio wrote:
> >
> >
> > > All the #' in CL seemed like an unnecessary hassle.
> >
> > Sure, until you realize that it means you can name your variables sanely
> > (ie. list). And that it saves you the hassle of having to understand a
> > hygenic macro system. On a slightly related note, being able to pass
> > around function names and funcalling them gives you the layer of
> > indirection necessary to be able to redefine functions on the fly. This
> > is very much a concern to CLers, though not so much to Schemers or other
> > people who fancy FP, I imagine.
> >
>
> Would someone be willing to describe these advantages in a bit more
> detail? As a newbie to both Scheme and CL, I too find CL's #' a hassle
> compared to the Scheme way of treating an expression that evaluates to
> a function just the same as a function name, and not having to think
> about the rules for when to quote or sharp-quote or
> funcall-sharp-quote....
>
> Of course having to think about the rules for a while until you
> internalise them is standard in programming, and I don't care as long
> as any additional comnplexity buys me proportional (or more)
> advantage. But I haven't heard any advantages of this design beyond
> being able to use the same identifier for two different things.
>
> The books all say that you have to use funcall and sharp-quotes in CL,
> but they don't say why it was designed this way.
>
> Now Matthew is referring to some interesting-sounding advantages of
> this approach that I haven't read about in the books. I've already
> gone from tolerating the parentheses to preferring them, after
> learning the advantages, and I'd be very pleased if the same could
> happen for funcall and sharp-quotes --especially since there's nothing
> I can do about them. Then I could move it from the "costs of CL" to
> the "benefits of CL" category in my mind. ;-)
You can always tell a Schemer because he uses variable names such as
`LIS'.
In CL, you can use the same name for a variable and a function, and have
them distinguished by context. Hence,
(let ((list '(1 2 3))) (list list 4 5)) => ((1 2 3) 4 5)
In addition, the ability to assume that the first element of an
expression is a special-op, macro, or function name confers a potential
efficiency advantage (particularly if it is from the CL package). The
function binding of a name should always be bound to a function, if
bound at all, or else the consequences are left to the implementation.
CL's system also helps to give a working macro system in practice. One
issue you don't have to worry about is accidental name capture of
functions by variables:
(defmacro foo (x)
`(count ... ,x ...))
(defun bar ()
...
(let ((count (length ...)))
...
(foo x)
...)
...)
The use of the COUNT function which the macro expansion contains will
not conflict with the use of the COUNT variable in the BAR function. In
a single namespace system, you would have to worry about this.
The separate namespace system is quite simple to use. You can consider
all function calls to be of the form:
(FUNCALL (FUNCTION name) ...)
with a short-cut that looks like:
(name ...)
Where name is permitted to be either a symbol, or a (LAMBDA ...) form. [1]
Since FUNCALL is an ordinary function itself, naturally you can supply
its arguments in any way permitted for an ordinary function.
ie. (let ((var (FUNCTION name))) (funcall var ...))
In addition, FUNCALL lets you give it a symbol instead of a function,
and it will look up the fbinding of that symbol before calling it. This
means that where you might store a function, you can store its name
instead, and be able to change the definition of the function at will
and have the latest definition be used always.
ie. (defparameter *foo* #'bar) vs (defparameter *foo* 'bar), and the
subsequent FUNCALL of *FOO*. The former will bind whatever definition
of BAR that is in effect to *FOO*, and the latter only names BAR so that
it may be looked-up at function-call time.
The system is simple, confers several advantages, and its only
disadvantage is that it makes convoluted functional programming less
compact in syntax.
[1] FUNCTION also accepts names of the form (SETF symbol) which the
`short-cut' does not accept.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish <·······@andrew.cmu.edu> wrote:
[lots of useful info about the advantages of FUNCALL and the
sharp-quoting approach...]
Thanks! I'm going to print this out and add it as an "appendix" to the
back of one of my CL tutorials.
Apparently these benefits are not enough to justify the extra clutter
and complexity, even for some experts, or else Scheme would be
different. And apparently it is definitely worth it for other experts,
otherwise CL would be like Scheme.
Since the apparent focus of CL (real production apps) is more like
what I need than the apparent focus of Scheme (education and algorithm
description), there seems a good chance now that I'll eventually grow
to prefer the 2-namespace/FUNCALL approach.
On 8638 day of my life Matthew Danish wrote:
> [1] FUNCTION also accepts names of the form (SETF symbol) which the
> `short-cut' does not accept.
^^^^^^^^^^^^^^^
Where is it described?
I can't found it in a CLHS. And #'(setf test) works in CMUCL and
CLisp (though it proves nothing).
Moreover,
,----[ CLHS 2.4.8.2 Sharpsign Single-Quote ]
| Any expression preceded by #' (sharpsign followed by single-quote), as
| in #'expression, is treated by the Lisp reader as an abbreviation for
| and parsed identically to the expression (function expression).
`----
So, #'(setf symbol) should be valid expression...
--
Ivan Boldyrev
XML -- new language of ML family.
On Fri, Jan 30, 2004 at 11:39:25AM +0600, Ivan Boldyrev wrote:
> On 8638 day of my life Matthew Danish wrote:
> > [1] FUNCTION also accepts names of the form (SETF symbol) which the
> > `short-cut' does not accept.
> ^^^^^^^^^^^^^^^
> Where is it described?
function name n. 1. (in an environment) A symbol or a list (setf symbol)
that is the name of a function in that environment. 2. A symbol or a
list (setf symbol).
function designator n. a designator for a function; that is, an object
that denotes a function and that is one of: a symbol (denoting the
function named by that symbol in the global environment), or a function
(denoting itself). [...] See also extended function designator.
extended function designator n. a designator for a function; that is, an
object that denotes a function and that is one of: a /function name/
(denoting the function it names in the global environment), or a
function (denoting itself).
operator n. 1. a function, macro, or special operator. [...] 4. (of a
/compound form/) the car of the compound form, which might be either an
operator[2] or a lambda expression, and which is never (setf symbol).
compound form n. a non-empty list which is a form: a special form, a
lambda form, a macro form, or a function form.
Special Operator FUNCTION
FUNCTION name => function
name -- a /function name/ or lambda expression
function -- a function object
The value of FUNCTION is the functional value of name in the current
lexical environment.
3.1.2.1.2.3 Function Forms
If the /operator/ is a symbol naming a function, the form represents a
function form, [...]
FUNCTION accepts function names, which are either symbols or the list
(SETF symbol), or lambda expressions. So (FUNCTION (SETF FOO)) is
acceptable, given (SETF FOO).
However, the /operator/ of a compound (ie. function) form is explicitly
not allowed to be (SETF symbol). So ((SETF FOO) ...) is not acceptable.
Why is this the case? I don't know for certain, but probably to
ensure that uses of SETF functions were done through the SETF macro.
(SETF (FOO x) v) rather than ((SETF FOO) v x).
> I can't found it in a CLHS. And #'(setf test) works in CMUCL and
> CLisp (though it proves nothing).
Keep in mind that SETF expansions do not have to be defined by
functions, and #'(setf name) will only have valid evaluation semantics
when (setf name) is a function. For example, in CLISP, #'(SETF CAR)
does not work.
>
> Moreover,
>
> ,----[ CLHS 2.4.8.2 Sharpsign Single-Quote ]
> | Any expression preceded by #' (sharpsign followed by single-quote), as
> | in #'expression, is treated by the Lisp reader as an abbreviation for
> | and parsed identically to the expression (function expression).
> `----
>
> So, #'(setf symbol) should be valid expression...
It is, if (SETF SYMBOL) is a defined function. Every statement I issue
about the semantics of (FUNCTION X) is equally applicable to #'X,
because #'X is transformed by the Lisp reader into (FUNCTION X).
> XML -- new language of ML family.
=)
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
On 8640 day of my life Matthew Danish wrote:
> On Fri, Jan 30, 2004 at 11:39:25AM +0600, Ivan Boldyrev wrote:
>> On 8638 day of my life Matthew Danish wrote:
>> > [1] FUNCTION also accepts names of the form (SETF symbol) which the
>> > `short-cut' does not accept.
>> ^^^^^^^^^^^^^^^
>> Where is it described?
:skipped
> However, the /operator/ of a compound (ie. function) form is explicitly
> not allowed to be (SETF symbol). So ((SETF FOO) ...) is not acceptable.
Ups, I had read your message too quickly and misunderstood it. I
thought 'short-cut' was #'... form. My bad.
--
Ivan Boldyrev
Sorry my terrible English, my native language is Lisp!
Matthew Danish wrote:
> The separate namespace system is quite simple to use. You can consider
> all function calls to be of the form:
>
> (FUNCALL (FUNCTION name) ...)
>
> with a short-cut that looks like:
>
> (name ...)
>
> Where name is permitted to be either a symbol, or a (LAMBDA ...) form. [1]
Ivan Boldyrev <···············@cgitftp.uiggm.nsc.ru> writes:
> On 8638 day of my life Matthew Danish wrote:
> > [1] FUNCTION also accepts names of the form (SETF symbol) which the
> > `short-cut' does not accept.
> ^^^^^^^^^^^^^^^
> Where is it described?
>
> I can't found it in a CLHS. And #'(setf test) works in CMUCL and
> CLisp (though it proves nothing).
Matthew probably meant that ((SETF FOO) ...) is not a proper form.
--
Regards,
Alexey Dejneka
"Alas, the spheres of truth are less transparent than those of
illusion." -- L.E.J. Brouwer
On Thu, 29 Jan 2004 05:35:18 -0500, Matthew Danish wrote:
> CL's system also helps to give a working macro system in practice. One
> issue you don't have to worry about is accidental name capture of
> functions by variables:
This relies on an accident that most functions are global and most
variables are local. It doesn't eliminate the problem, it only lowers
its probability. It doesn't help when the code using the macro defines
some functions locally, nor when the macro wants to refer to global
objects which are not functions.
I've heard from some Lisp advocates that they prefer a solution which
works always to a solution which works most of the time :-)
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
On Sat, Jan 31, 2004 at 04:11:40PM +0100, Marcin 'Qrczak' Kowalczyk wrote:
> On Thu, 29 Jan 2004 05:35:18 -0500, Matthew Danish wrote:
>
> > CL's system also helps to give a working macro system in practice. One
> > issue you don't have to worry about is accidental name capture of
> > functions by variables:
>
> This relies on an accident that most functions are global and most
> variables are local. It doesn't eliminate the problem, it only lowers
> its probability. It doesn't help when the code using the macro defines
> some functions locally, nor when the macro wants to refer to global
> objects which are not functions.
Hence ``in practice.'' Note that it is also not permissible to
lexically shadow CL functions, and that the functions used by macros
otherwise tend to be internal to the package they came from. People
working in other packages do not need to worry about accidentally
shadowing a function named by an internal symbol in another package,
generally. The overall design of CL reflects the need to avoid
accidental shadowing of functions and variables used by macros, in fact.
> I've heard from some Lisp advocates that they prefer a solution which
> works always to a solution which works most of the time :-)
When both solutions are possible, perhaps. I don't think there has been
a hygenic macro system that meets the abilities of CL's procedural macro
system, and certainly not back before 1994 either. There are lots of
ways in CL to shoot yourself in the foot, the macro system is hardly
alone.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish <·······@andrew.cmu.edu> writes:
> On Sat, Jan 31, 2004 at 04:11:40PM +0100, Marcin 'Qrczak' Kowalczyk wrote:
> > On Thu, 29 Jan 2004 05:35:18 -0500, Matthew Danish wrote:
> >
> > > CL's system also helps to give a working macro system in practice. One
> > > issue you don't have to worry about is accidental name capture of
> > > functions by variables:
> >
> > This relies on an accident that most functions are global and most
> > variables are local. It doesn't eliminate the problem, it only lowers
> > its probability. It doesn't help when the code using the macro defines
> > some functions locally, nor when the macro wants to refer to global
> > objects which are not functions.
>
> Hence ``in practice.'' Note that it is also not permissible to
> lexically shadow CL functions, and that the functions used by macros
> otherwise tend to be internal to the package they came from.
This is the big thing. You're allowed to shadow the meanings of
variables from the shared vocabulary, but not functions.
> > I've heard from some Lisp advocates that they prefer a solution which
> > works always to a solution which works most of the time :-)
>
> When both solutions are possible, perhaps. I don't think there has been
> a hygenic macro system that meets the abilities of CL's procedural macro
> system, and certainly not back before 1994 either. There are lots of
> ways in CL to shoot yourself in the foot, the macro system is hardly
> alone.
AFAICT syntactic closures have all the power of CL's macro system.
They're a little harder to use, but if I were going to use a hygenic
macro system (that's a big if), it'd be that one. I think part of the
reason no one uses them in CL is because they solve something that,
for us, is a non-problem.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
On Sat, 31 Jan 2004 11:03:47 -0800, Thomas F. Burdick wrote:
>> Hence ``in practice.'' Note that it is also not permissible to
>> lexically shadow CL functions, and that the functions used by macros
>> otherwise tend to be internal to the package they came from.
>
> This is the big thing. You're allowed to shadow the meanings of
> variables from the shared vocabulary, but not functions.
Hmm, so name conflicts are not a problem because they have undefined
consequences? Interesting way of dealing with the problem. The programmer
must know the names of all standard functions, even ones he doesn't care
about. Can't say I like this.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
On Sat, Jan 31, 2004 at 08:47:55PM +0100, Marcin 'Qrczak' Kowalczyk wrote:
> On Sat, 31 Jan 2004 11:03:47 -0800, Thomas F. Burdick wrote:
>
> >> Hence ``in practice.'' Note that it is also not permissible to
> >> lexically shadow CL functions, and that the functions used by macros
> >> otherwise tend to be internal to the package they came from.
> >
> > This is the big thing. You're allowed to shadow the meanings of
> > variables from the shared vocabulary, but not functions.
>
> Hmm, so name conflicts are not a problem because they have undefined
> consequences? Interesting way of dealing with the problem. The programmer
> must know the names of all standard functions, even ones he doesn't care
> about. Can't say I like this.
When the standard says `undefined consequences' it is left to the
implementation to decide what to do. Then the question becomes one of
the quality of the implementation; a particular behavior is not required
because that might constrain useful behavior. For example, the typical
solution of this is the use of package locks.
If you choose to use an implementation where `undefined consequences'
means something unpleasant, then it might be time to reconsider your
choice. Or you can create a package which selectively imports only the
symbols from the CL package which you know.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Marcin 'Qrczak' Kowalczyk wrote:
> On Sat, 31 Jan 2004 11:03:47 -0800, Thomas F. Burdick wrote:
>
>>>Hence ``in practice.'' Note that it is also not permissible to
>>>lexically shadow CL functions, and that the functions used by macros
>>>otherwise tend to be internal to the package they came from.
>>
>>This is the big thing. You're allowed to shadow the meanings of
>>variables from the shared vocabulary, but not functions.
>
> Hmm, so name conflicts are not a problem because they have undefined
> consequences? Interesting way of dealing with the problem. The programmer
> must know the names of all standard functions, even ones he doesn't care
> about. Can't say I like this.
Welcome to Macintosh Common Lisp Version 5.0!
? (defun car (list)
(print list))
> Error: The function CAR is already defined in the MCL kernel.
> While executing: CCL::REDEFINE-KERNEL-FUNCTION
> Type Command-/ to continue, Command-. to abort.
> If continued: Replace the definition of CAR.
See the Restarts... menu item for further choices.
1 >
Aborted
? (defun test ()
(flet ((car (list)
(print list)))
(car '(a b c))))
;Compiler warnings :
; Attempt to bind compiler special name: CAR. Result undefined, in TEST.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> Hmm, so name conflicts are not a problem because they have undefined
> consequences? Interesting way of dealing with the problem. The programmer
> must know the names of all standard functions, even ones he doesn't care
> about. Can't say I like this.
The programmer has the right to be slightly smarter, and to know how
to ask Common-Lisp about the standard functions:
[15]> (defun standard-function-p (symbol)
(and (fboundp symbol)
(block :extern
(do-external-symbols (cl-sym "COMMON-LISP")
(when (eq symbol cl-sym) (return-from :extern t))) nil)))
STANDARD-FUNCTION-P
[16]> (standard-function-p 'car)
T
[17]> (standard-function-p 'defun)
T
[18]> (standard-function-p 'define)
NIL
[19]> (standard-function-p 'show)
NIL
[20]>
He could even use this predicate in a defmacro implementation that
would check automatically for any "undefined" clobbering.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> Hmm, so name conflicts are not a problem because they have undefined
> consequences? Interesting way of dealing with the problem. The programmer
> must know the names of all standard functions, even ones he doesn't care
> about. Can't say I like this.
He's the one who imported them into his namespace. If he doesn't want to
be bothered with learning most of the language, he should only bother to
import the part he wants to know about.
To be more clear, conflicts aren't a problem because they don't
happen. If you're using a symbol that you imported from another package,
you obviously meant to use the symbol from the other package, no?
Otherwise you would have used a symbol that's private to your package.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Marcin 'Qrczak' Kowalczyk wrote:
> On Thu, 29 Jan 2004 05:35:18 -0500, Matthew Danish wrote:
>
>
>>CL's system also helps to give a working macro system in practice. One
>>issue you don't have to worry about is accidental name capture of
>>functions by variables:
>
> This relies on an accident that most functions are global and most
> variables are local. It doesn't eliminate the problem, it only lowers
> its probability. It doesn't help when the code using the macro defines
> some functions locally, nor when the macro wants to refer to global
> objects which are not functions.
That's only one half of the story. The other half is that function names
and variable names are usually chosen very differently (or rather should
be chosen differently).
Functions usually have long distinctive names. This is even the case for
local functions. If you happen to use the same name for different
functions, you risk that your program becomes harder to understand.
Since in Lisp, functions are the essential ingredient in creating an
ontology for a specific program, every experienced Lisp programmer
naturally tries to find descriptive and unambiguous names for them.
Ambiguous function names are not very helpful, and programming languages
generally do not provide enough means to help disambiguating them from
context, unlike natural languages.
Your remark with regard to global objects is too general. In Common
Lisp, almost all global objects live in their own namespace. For
example, it's not possible to get hold of a class metaobject directly,
you always have to go through FIND-CLASS to get it, and so forth. The
only exception are global variables, and here Common Lisp programmers
follow the convention to use asterisks to wrap the names, which
effectively builds another namespace for global variables. (Kent Pitman
noted in some post in the past that the ANSI committee has put some
thought into adding strict checks to the language that this convention
is actually followed, but these ideas were dropped. AFAIR, the main
reason was not to gratuitously break compatibility with legacy Lisp code.)
Taken together, this means that there exist no name collisions between
functions, global variables and local variables in practice.
> I've heard from some Lisp advocates that they prefer a solution which
> works always to a solution which works most of the time :-)
A Lisp-1 creates name collision problems that don't exist in Lisp-2.
Some of them occur in conjunction with macros, but some of them occur
independently from macros. How do you deal with the latter?
I really think that the situation for a Lisp-1 is worse than for a
Lisp-2. In a Lisp-2 you only need to follow a few conventions and use
GENSYM and the like for the corner cases, and then you're done with it.
Lisp-1 creates problems that you can't fully solve.
On the other hand, I hear that Schemers use naming conventions to get
around of those other problems, by using names like lst and pair instead
of list and cons, and so on. It seems to me that both approaches are
more or less on the same level. The only difference is that the places
in which people rely on conventions are different.
The term "macro hygiene" just narrows the view in an unfortunate way,
while "general hygiene" might be the more appropriate term.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> This relies on an accident that most functions are global and most
> variables are local. It doesn't eliminate the problem, it only lowers
> its probability. It doesn't help when the code using the macro defines
> some functions locally, nor when the macro wants to refer to global
> objects which are not functions.
The package system is also involved. Usually users of your code are
in a different package from your code, and your local functions will
be named by symbol in your package, so there is no conflict.
-russ
········@hotmail.com (Tuang) writes:
> Would someone be willing to describe these advantages in a bit more
> detail? As a newbie to both Scheme and CL, I too find CL's #' a hassle
> compared to the Scheme way of treating an expression that evaluates to
> a function just the same as a function name, and not having to think
> about the rules for when to quote or sharp-quote or
> funcall-sharp-quote....
Whether to have two namespaces or one namespace is largely a matter of
taste. The difference that makes the *most* difference, so to speak,
is how the namespace decision affects the use of macros.
In Common Lisp, binding a function name is far less common than
binding a variable name. Because of this, it is infrequent to have
accidental capture of functions introduced by macros. In Scheme,
however, since variables and functions share the same namespace, the
issue of macro `hygiene' becomes much more important. The end result
is that macros in Scheme require substantially more work than macros
in Common Lisp.
> I've already gone from tolerating the parentheses to preferring
> them,
Another convert!
> after learning the advantages, and I'd be very pleased if the
> same could happen for funcall and sharp-quotes --especially since
> there's nothing I can do about them. Then I could move it from the
> "costs of CL" to the "benefits of CL" category in my mind. ;-)
I find both the `cost' and `benefit' of funcall and sharp-quote to be
well below my threshold of caring. (Which must be why they are such
good fodder for usenet flames.)
--
~jrm
* Tuang
| Would someone be willing to describe these advantages in a bit more
| detail? As a newbie to both Scheme and CL, I too find CL's #' a
| hassle compared to the Scheme way of treating an expression that
| evaluates to a function just the same as a function name, and not
| having to think about the rules for when to quote or sharp-quote or
| funcall-sharp-quote....
|
| Of course having to think about the rules for a while until you
| internalise them is standard in programming, and I don't care as long
| as any additional comnplexity buys me proportional (or more)
| advantage.
This is an important point, frequently overlooked by experts. To
become an expert, you have to do something often enough that you no
longer know why you do it, you just know what do to, immediately, but
there are no /rules/. The novice often has to learn rules to follow,
because that is believed to be the best didactic presentation of the
expertise, but pedagogy is not exactly a science. The more we know
about how people become competent and then experts, we realize that
one must leave the rules stage as soon as possible, but no sooner, of
course :). Going from rules to expertise is not a well-understood
process that can be taught, however. It appears to defy explanation
to those who have not already understood it.
Common Lisp does not have �rules� that are easy to learn. Instead, it
is extremely expert-friendly, and those who want to become experts
find it easy to do so because they can reason their way around, while
those who only want to become competent, will be endlessly frustrated
by the lack of comprehensive tables of results of the reasoning that
they have no interest in doing on their own.
Some people have expressed the notion here that mathematics is also no
more than a bunch of rules, or maybe it was just one person. Anyway,
the difference between rules and reasoning is like the different view
of functions. One view is that a function is a mapping from one set
to another set, and you can enumerate both sets if you feel like it,
or consult a table or a computing device. This view very effectively
prevents people from learning the other view. The other view is that
a function is an expression of an abstract relationship and that one
can obtain a mapping through a series of intermediate steps on demand,
but it is the abstract relationship that is important. As long as you
obsess about the values and mappings, you will never grasp the purpose
of the function. I have watched kids who have been taught by teachers
to compute meaningless functional mappings believe that mathematics is
merely arithmetic and rote learning of tables of mappings, but who
have then been taught to /reason/ about the abstract relationships
that are expressed by the functions, and they light up like fireworks.
Common Lisp is just as much rules as mathematics is arithmetic.
If you set out to internalize rules, you /will/ miss the big picture.
| Then I could move it from the "costs of CL" to the "benefits of CL"
| category in my mind. ;-)
I think the error is in determining something to be a cost too early.
--
Erik Naggum | Oslo, Norway 2004-029
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
"Erik Naggum" <····@naggum.no> wrote in message
····························@naggum.no...
> Common Lisp does not have �rules� that are easy to learn. Instead, it
> is extremely expert-friendly, and those who want to become experts
> find it easy to do so because they can reason their way around, while
> those who only want to become competent, will be endlessly frustrated
> by the lack of comprehensive tables of results of the reasoning that
> they have no interest in doing on their own.
This is a very important point.
With UNIX based C programs, you typically have a Makefile, header files, and
C source code with a main() function. On top of that, the C programs
regularly use the standard library, referenced through /usr/include and
store in /usr/lib.
These are tenets that "everyone knows" by day 2 of "21 days to programming
in C", and with these basics, you can start to navigate most any medium
sized C program.
Modern Java has even more aspects that the developer can count on, things
like using the Ant build tool, rudimentary javadocs, package hierarchies,
standard logging idioms, etc. As more and more tools from the Java community
come out, conforming with and working within the "de facto" standards
imposed by the community makes it much easier to work in that world. These
de facto standards are "good enough" that fighting this current is simply
not worth the developers time, and keeping up isn't that painful.
This nature of Java makes it easier for "How to program in Java in 21 days"
books to lay out a complete methodology for working with Java, without, of
course, necessarily actually understanding it. Just a bunch of templates and
skeletons that let users fill in the blanks for there projects.
As a corallary, once you have C programs going beyong the standard library
and start relying on extended libraries, then you get the chaos of Linux
today with its gazillion different package frameworks, file system
structures, etc. One of the big issues between the BSD camps and Linux camps
isn't so much performance or kernel quality, it's the strict structure
imposed by BSD compared to the anarchy of Linux. Of course, that's not
completely fair, as each of the Linux distros may be draconian to their own
way, but the word "Linux" ends up sweeping all of them in one chaotic lump
compared to the BSDs.
The CL community, for assorted reasons, has never (that I can find) come
with a common way of "How To" program in CL. Lots of books on syntax, the
language, operators, CLOS, etc, but not a whole lot on process, and
structure. How to leverage EMACS, how to organize sources, how use
defsystem, etc.
Everyone seems to have their own way of doing things, and a common practice
hasn't seemed to have bubbled up to the top.
I think this is due to the more organic nature of CL, its users, and its
domains than anything else. Its culture, with all of it implementations, and
their subtle distinctions, makes for not just a dynamic language, but a
dynamic community compared to the rigid hierarchies of something like Java
today.
In that way, I think it is much easier for a new person to pick up Java and
get with the "flow", because it's all laid out on the ground, follow the
yellow lines, stand on the right, pass on the left. CL is basically heaps of
code scattered across the net and its users all doing something in their own
way, as they had to organize their environments to suit if for no other
reason they don't have a model to follow.
That dynamic is comfortable for expert users who know what they want, but
for beginners its one more thing they need to worry about on top of simply
the language itself.
Regards,
Will Hartung
(·····@msoft.com)
On 2004-01-29, Will Hartung <·····@msoft.com> wrote:
|
| The CL community, for assorted reasons, has never (that I can find) come
| with a common way of "How To" program in CL. Lots of books on syntax, the
| language, operators, CLOS, etc, but not a whole lot on process, and
| structure. How to leverage EMACS, how to organize sources, how use
| defsystem, etc.
|
| Everyone seems to have their own way of doing things, and a common practice
| hasn't seemed to have bubbled up to the top.
I had a lot of trouble with this when I first learned Lisp. Coming
from a C/Python background, I started out every project by writing a
bunch of code (in vi, and I didn't know about the % command, so I had
lots of fun counting parens myself ;), then I would leave the editor,
start up my Lisp system in an xterm, load the code, figure out what
works and what doesn't work, quit Lisp, go back to the editor, make a
bunch of changes, restart Lisp and load the new code, figure out what
doesn't work this time, and so on. I couldn't figure out what all the
fuss was about, because using Lisp didn't seem to be making me any
more productive than I would be in, say, C++. Once I learned about
Emacs+ILISP, I had an `aha' moment and realized that I don't have to
write half my application all at once before I could even start
testing it, but could build it up incrementally one function at a
time, and then all the hype started making a *lot* more sense. :)
(Then I had a second `aha' moment when I realized I could just export
my classes and functions from a package, and use the REPL as my UI,
instead of building specialized applications which run from the shell
and have to parse their own command lines, or which use a GUI.)
--
Cliff Crawford *** ·····@cornell.edu
"The perfection of art is to conceal art." -- Quintilian
········@hotmail.com (Tuang) writes:
> Matthew Danish <·······@andrew.cmu.edu> wrote:
> > On Mon, Jan 26, 2004 at 09:25:35PM +0200, Ville Vainio wrote:
> > > All the #' in CL seemed like an unnecessary hassle.
> > Sure, until you realize that it means you can name your variables sanely
> Would someone be willing to describe these advantages in a bit more
> detail?
This classical paper approaches the subject from the Common Lisp angle:
http://www.nhplace.com/kent/Papers/Technical-Issues.html
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
Tuang wrote:
> Would someone be willing to describe these advantages in a bit more
> detail? As a newbie to both Scheme and CL, I too find CL's #' a hassle
> compared to the Scheme way of treating an expression that evaluates to
> a function just the same as a function name, and not having to think
> about the rules for when to quote or sharp-quote or
> funcall-sharp-quote....
The technical terms to describe what you have just said are Lisp-1 -
values and functions are stored the same - and Lisp-2 - values and
functions are stored differently, and therefore you need funcall and
function/#' to distinguish them.
In Scheme, accidental capture of function definitions is more likely to
occur than in Common Lisp because Scheme is a Lisp-1. Therefore, there
is a higher need to solve the issue of name captures which has led to a
number of hygienic macro systems, and obviously no real agreement on a
single one. A good paper that describes possible name capture problems
is the following.
Alan Bawden and Jonathan Rees, Syntactic Closures,
http://citeseer.nj.nec.com/bawden88syntactic.html
It is a good exercise to try to understand why the examples given in
that paper are not really pressing in a Lisp-2, and therefore in Common
Lisp, and what the situations could be in which you might actually want
to capture names. See also http://www.dreamsongs.com/Separation.html
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Ville Vainio <·····@spammers.com> writes:
> CLOS just seemed to be rather arcane and verbose as a whole.
That's a misconception, it's really quite simple. You can ignore 99%
of CLOS 99% of the time and everything just works. One day when you
find yourself truly screwed over by a decision someone else made 2
years ago, though, a little bit of poking around through the more
complex parts will show that someone else *already* thought of a way
out.
> I admit I haven't really put much energy into getting to know it,
> because I didn't have a good implementation (as elisp implementation
> is a bit lacking). "Common Lisp: the language, 2nd edition" didn't
> really help, to say the least.
Well, it has all the details.
> To me a following object system (requiring tweaking the Lisp reader to
> grok '.', I assume) might have had a more immediate appeal:
>
> (defclass MyClass (Base1 Base2)
> (def init (x y) (
> (setq self.x x)
> (setq self.y y)))
> (def say () (
> (print self.x self.y))))
(defclass my-class (base1 base2)
((x :initarg :x :reader x)
(y :initarg :y :reader y)))
(defmethod say ((instance my-class))
(print (x instance) (y instance)))
(setq instance (make-instance 'my-class :x 4 :y 5))
> I know that the model has zillions of problems, and shredding it to
> pieces is not really worth it. Just showing what kind of aesthetic I
> like.
The version I just wrote is perhaps slightly more verbose, but not
much.
Joe Marshall <···@ccs.neu.edu> writes:
> Ville Vainio <·····@spammers.com> writes:
> snip
>
> > To me a following object system (requiring tweaking the Lisp reader to
> > grok '.', I assume) might have had a more immediate appeal:
> >
> > (defclass MyClass (Base1 Base2)
> > (def init (x y) (
> > (setq self.x x)
> > (setq self.y y)))
> > (def say () (
> > (print self.x self.y))))
>
>
> (defclass my-class (base1 base2)
> ((x :initarg :x :reader x)
> (y :initarg :y :reader y)))
>
> (defmethod say ((instance my-class))
> (print (x instance) (y instance)))
>
> (setq instance (make-instance 'my-class :x 4 :y 5))
>
>
> > I know that the model has zillions of problems, and shredding it to
> > pieces is not really worth it. Just showing what kind of aesthetic I
> > like.
>
> The version I just wrote is perhaps slightly more verbose, but not
> much.
It seems the OP is a little attached to the object.property type syntax.
I definitely felt the same way when I was first learning CLOS. I was
coming from C and Perl and was rather uncomfortable with the lisp way
of (ACCESSOR OBJECT) and (METHOD args) instead of something.something
and something->something.. It didn't take too long to get used to though.
You can pass around accessors and methods as objects, though, I don't
know if you can pass a property or method name for use in the
object.property syntax. To me that is extremely useful.
Jock
Jock Cooper <·····@mail.com> wrote in message news:<··············@jcooper02.sagepub.com>...
> It seems the OP is a little attached to the object.property type syntax.
> I definitely felt the same way when I was first learning CLOS. I was
> coming from C and Perl and was rather uncomfortable with the lisp way
> of (ACCESSOR OBJECT) and (METHOD args) instead of something.something
> and something->something.. It didn't take too long to get used to though.
Actually, I wrote a macro automatically converting the dot syntax:
obj.attr -> (slot-ref obj 'attr)
However, now I am no more convinced that the dot notation is superior;
actually it feels kind of ugly in Scheme code (maybe not enough
parentheses? ;)
Michele Simionato
·················@poste.it (Michele Simionato) writes:
> Jock Cooper <·····@mail.com> wrote in message news:<··············@jcooper02.sagepub.com>...
>> It seems the OP is a little attached to the object.property type syntax.
>> I definitely felt the same way when I was first learning CLOS. I was
>> coming from C and Perl and was rather uncomfortable with the lisp way
>> of (ACCESSOR OBJECT) and (METHOD args) instead of something.something
>> and something->something.. It didn't take too long to get used to though.
>
> Actually, I wrote a macro automatically converting the dot syntax:
>
> obj.attr -> (slot-ref obj 'attr)
>
> However, now I am no more convinced that the dot notation is superior;
It is a little inferior. As Jock Cooper noted, you can't do this with
dot notation:
(let ((field-of-interest (read)))
(format t "~&The ~a field has value ~s." object.field-of-interest))
Michele Simionato wrote:
> Jock Cooper <·····@mail.com> wrote in message news:<··············@jcooper02.sagepub.com>...
>
>>It seems the OP is a little attached to the object.property type syntax.
>>I definitely felt the same way when I was first learning CLOS. I was
>>coming from C and Perl and was rather uncomfortable with the lisp way
>>of (ACCESSOR OBJECT) and (METHOD args) instead of something.something
>>and something->something.. It didn't take too long to get used to though.
>
>
> Actually, I wrote a macro automatically converting the dot syntax:
>
> obj.attr -> (slot-ref obj 'attr)
>
> However, now I am no more convinced that the dot notation is superior;
> actually it feels kind of ugly in Scheme code (maybe not enough
> parentheses? ;)
It feels even uglier in Common Lisp.
(defclass foo () ((x :accessor the-x :initform 42)))
(defmethod the-x :before ((x foo))
(format t "Accessing slot X in a ~S.~%" x))
(defvar a-foo (make-instance 'foo))
cl-prompt> (the-x a-foo)
Accessing slot X in a #<FOO #x2A>
42
With your 'dot macro' above you will always have to add methods on
SLOT-VALUE. Not a pretty thing.
This is another reason why Common Lisp (not Scheme!) unified notion of
"accessor" yields nicer behavior in the long run.
Cheers
--
Marco
Joe Marshall wrote:
> That's a misconception, it's really quite simple. You can ignore 99%
> of CLOS 99% of the time and everything just works. One day when you
> find yourself truly screwed over by a decision someone else made 2
> years ago, though, a little bit of poking around through the more
> complex parts will show that someone else *already* thought of a way
> out.
Joe, can you suggest a book that concentrates on teaching/introducing
the important 1% of CLOS, so that as a CLOS beginner I could start with
these important parts of it?
(online tutorials would be also nice)
On Mon, 26 Jan 2004 23:47:45 +0100, Andr� Thieme <······································@justmail.de> wrote:
> Joe, can you suggest a book that concentrates on
> teaching/introducing the important 1% of CLOS, so that as a CLOS
> beginner I could start with these important parts of it? (online
> tutorials would be also nice)
"Fundamentals of CLOS" by Nick Levine - "an introduction to the 10% of
CLOS which you need to get you through 90% of use cases:"
<http://cl-cookbook.sourceforge.net/clos-tutorial/index.html>
(OK, so it's not /one/ percent - but it's close...)
Edi.
Andr� Thieme <······································@justmail.de> writes:
> Joe Marshall wrote:
>
>> That's a misconception, it's really quite simple. You can ignore 99%
>> of CLOS 99% of the time and everything just works. One day when you
>> find yourself truly screwed over by a decision someone else made 2
>> years ago, though, a little bit of poking around through the more
>> complex parts will show that someone else *already* thought of a way
>> out.
>
> Joe, can you suggest a book that concentrates on teaching/introducing
> the important 1% of CLOS, so that as a CLOS beginner I could start
> with these important parts of it?
> (online tutorials would be also nice)
I am told that Sonya Keene's book is good, but I don't know
first-hand. Of the online tutorials I have seen, none quite take the
approach that I'd use, but perhaps they would work for others. I'm
working on my own, but it is nowhere near complete and I'm getting
dissatisfied with it.
Andr� Thieme wrote:
> Joe Marshall wrote:
>
>> That's a misconception, it's really quite simple. You can ignore 99%
>> of CLOS 99% of the time and everything just works. One day when you
>> find yourself truly screwed over by a decision someone else made 2
>> years ago, though, a little bit of poking around through the more
>> complex parts will show that someone else *already* thought of a way
>> out.
>
>
> Joe, can you suggest a book that concentrates on teaching/introducing
> the important 1% of CLOS, so that as a CLOS beginner I could start with
> these important parts of it?
> (online tutorials would be also nice)
Sonya Keene's book is still the best.
Sonya Keene "Object Oriented Programming in Common Lisp", Addison Wesley
1988. See the Cliki (www.cliki.net) or the ALU site (www.alu.org) for
online tutorials (some good, some not-so-good)
Cheers
--
Marco
Andr� Thieme <······································@justmail.de> writes:
> Joe, can you suggest a book that concentrates on teaching/introducing
> the important 1% of CLOS, so that as a CLOS beginner I could start
> with these important parts of it?
I have just written a `Warp Speed' introduction to CLOS. It isn't a
tutorial, but it is intended to give a neophyte the basic flavor of
CLOS programming without overwhelming them. It intentionally glosses
over and omits huge amounts. On the other hand, it is only about two
pages long and ought to be enough to get the broad concepts across.
See:
http://home.comcast.net/~prunesquallor/guide.html
Comments and questions are welcome.
--
~jrm
Thanks for the intro, but I'd wager that the C or Java or INTERCAL
programmer will not be impressed. They'll just say:
"but this is overloading"
which, we know, is not.
Cheers
Marco
Joe Marshall wrote:
> Andr� Thieme <······································@justmail.de> writes:
>
>
>>Joe, can you suggest a book that concentrates on teaching/introducing
>>the important 1% of CLOS, so that as a CLOS beginner I could start
>>with these important parts of it?
>
>
> I have just written a `Warp Speed' introduction to CLOS. It isn't a
> tutorial, but it is intended to give a neophyte the basic flavor of
> CLOS programming without overwhelming them. It intentionally glosses
> over and omits huge amounts. On the other hand, it is only about two
> pages long and ought to be enough to get the broad concepts across.
>
> See:
>
> http://home.comcast.net/~prunesquallor/guide.html
>
> Comments and questions are welcome.
>
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Thanks for the intro, but I'd wager that the C or Java or INTERCAL
> programmer will not be impressed. They'll just say:
>
> "but this is overloading"
To which you reply "it's similar, but the method is selected based on
the runtime class of the object itself, not the compile-time type of the
variable it's assigned to".
My guess is that most c++ or java programmers have had to work to
overcome the problem where some function gives you an Animal and you
know it's really a Dog but the computer doesn't. CLOS gives you that
For Free.
-dan
--
http://web.metacircles.com/ - Open Source software development and support
In article <··············@noetbook.telent.net>, Daniel Barlow
<···@telent.net> wrote:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> > Thanks for the intro, but I'd wager that the C or Java or INTERCAL
> > programmer will not be impressed. They'll just say:
> >
> > "but this is overloading"
>
> To which you reply "it's similar, but the method is selected based on
> the runtime class of the object itself, not the compile-time type of the
> variable it's assigned to".
>
> My guess is that most c++ or java programmers have had to work to
> overcome the problem where some function gives you an Animal and you
> know it's really a Dog but the computer doesn't. CLOS gives you that
> For Free.
Animal foo();
Dog x = dynamic_cast<Dog>(foo());
Not quite free, but not a huge burden either.
E.
Erann Gat wrote:
> In article <··············@noetbook.telent.net>, Daniel Barlow
> <···@telent.net> wrote:
>
>>My guess is that most c++ or java programmers have had to work to
>>overcome the problem where some function gives you an Animal and you
>>know it's really a Dog but the computer doesn't. CLOS gives you that
>>For Free.
>
> Animal foo();
>
> Dog x = dynamic_cast<Dog>(foo());
>
> Not quite free, but not a huge burden either.
That's not the important fault. The important one is this:
class Foo {
public static void print(Object o) {
System.out.println("I've got an object.");
}
public static void print(String s) {
System.out.println("I've got a string.");
}
public static void tunnel(Object o) {
print(o);
}
public static void main(String[] args) {
tunnel("What have you got?");
}
}
You won't get the intuitively expected result here (unless you have a
twisted intuition ;).
This is a toy example, but the issue comes up in real programs. For
example, the Visitor pattern suffers from this. Of course, nothing an
IDE can't compensate for. ;)
This could be another example for "static typing sucks" paper. ;) (I'm
thinking about it...)
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
In article <············@newsreader2.netcologne.de>, Pascal Costanza
<········@web.de> wrote:
> Erann Gat wrote:
>
> > In article <··············@noetbook.telent.net>, Daniel Barlow
> > <···@telent.net> wrote:
> >
> >>My guess is that most c++ or java programmers have had to work to
> >>overcome the problem where some function gives you an Animal and you
> >>know it's really a Dog but the computer doesn't. CLOS gives you that
> >>For Free.
> >
> > Animal foo();
> >
> > Dog x = dynamic_cast<Dog>(foo());
> >
> > Not quite free, but not a huge burden either.
>
> That's not the important fault. The important one is this:
>
> class Foo {
>
> public static void print(Object o) {
> System.out.println("I've got an object.");
> }
>
> public static void print(String s) {
> System.out.println("I've got a string.");
> }
>
> public static void tunnel(Object o) {
> print(o);
> }
>
> public static void main(String[] args) {
> tunnel("What have you got?");
> }
> }
#include <stdio.h>
class object {
public:
virtual void print() { printf ("I'm an object\n"); }
};
class thingy : public object {
public:
virtual void print() { printf ("I'm a thingy\n"); }
};
void tunnel(object &o) {
o.print();
}
main() {
object o;
thingy t;
tunnel(o);
tunnel(t);
}
[···@alvin gat]$ ./a.out
I'm an object
I'm a thingy
Erann Gat wrote:
> In article <············@newsreader2.netcologne.de>, Pascal Costanza
> <········@web.de> wrote:
>
>
>>Erann Gat wrote:
>>
>>
>>>In article <··············@noetbook.telent.net>, Daniel Barlow
>>><···@telent.net> wrote:
>>>
>>>
>>>>My guess is that most c++ or java programmers have had to work to
>>>>overcome the problem where some function gives you an Animal and you
>>>>know it's really a Dog but the computer doesn't. CLOS gives you that
>>>>For Free.
>>>
>>>Animal foo();
>>>
>>>Dog x = dynamic_cast<Dog>(foo());
>>>
>>>Not quite free, but not a huge burden either.
>>
>>That's not the important fault. The important one is this:
>>
>>class Foo {
>>
>> public static void print(Object o) {
>> System.out.println("I've got an object.");
>> }
>>
>> public static void print(String s) {
>> System.out.println("I've got a string.");
>> }
>>
>> public static void tunnel(Object o) {
>> print(o);
>> }
>>
>> public static void main(String[] args) {
>> tunnel("What have you got?");
>> }
>>}
>
>
>
> #include <stdio.h>
>
> class object {
> public:
> virtual void print() { printf ("I'm an object\n"); }
> };
>
> class thingy : public object {
> public:
> virtual void print() { printf ("I'm a thingy\n"); }
> };
>
> void tunnel(object &o) {
> o.print();
> }
>
> main() {
> object o;
> thingy t;
> tunnel(o);
> tunnel(t);
> }
>
>
> [···@alvin gat]$ ./a.out
> I'm an object
> I'm a thingy
very bad design in fact forced by classical OO (not you !) vs generic functions approach.
1- perhaps "object" & "thingy" are in a library. And you can't add the "print" method. So you have to use derivation to do this...
2- you use the fact that tunnel has 1 argument and so you can use the C++ polymorphism. What if "tunnel" has to downcast from 2+ arguments ?
3- "thingy" and "object" actually do the work ( using their "print" method) but why ? they don't have all the informations after all. Perhaps your printf should sometimes print in french ;). It is the responsabilty of your application's "displayer" (or tunnel).
(defmethod tunnel ((o object) (a2 other-arg)) ...)
(defmethod tunnel ((o thingy) (a2 other-arg)) ...)
is definitely better !
- it's funny because 2 days ago, i have exactly this to code in C++. My solution was to hand-code the dynamic_downcast of method argument :
void print(thingy &)
{
printf ("I'm a thingy\n");
}
void print(object &o)
{
thingy * lp_thingy = dynamic_cast< thingy * >( & o ) ;
if ( lp_thingy )
{
print( * lp_thingy ) ;
}
else
{
printf ("I'm an object\n") ;
}
}
void tunnel(object &o) {
print( o );
}
ugly but not touching object & thingy codes.
ctu.
Erann Gat wrote:
> In article <············@newsreader2.netcologne.de>, Pascal Costanza
> <········@web.de> wrote:
>
>>Erann Gat wrote:
>>
>>>In article <··············@noetbook.telent.net>, Daniel Barlow
>>><···@telent.net> wrote:
>>>
>>>
>>>>My guess is that most c++ or java programmers have had to work to
>>>>overcome the problem where some function gives you an Animal and you
>>>>know it's really a Dog but the computer doesn't. CLOS gives you that
>>>>For Free.
>>>
>>>Animal foo();
>>>
>>>Dog x = dynamic_cast<Dog>(foo());
>>>
>>>Not quite free, but not a huge burden either.
>>
>>That's not the important fault. The important one is this:
>>
>>class Foo {
>>
>> public static void print(Object o) {
>> System.out.println("I've got an object.");
>> }
>>
>> public static void print(String s) {
>> System.out.println("I've got a string.");
>> }
>>
>> public static void tunnel(Object o) {
>> print(o);
>> }
>>
>> public static void main(String[] args) {
>> tunnel("What have you got?");
>> }
>>}
>
> #include <stdio.h>
>
> class object {
> public:
> virtual void print() { printf ("I'm an object\n"); }
> };
>
> class thingy : public object {
> public:
> virtual void print() { printf ("I'm a thingy\n"); }
> };
>
> void tunnel(object &o) {
> o.print();
> }
>
> main() {
> object o;
> thingy t;
> tunnel(o);
> tunnel(t);
> }
>
> [···@alvin gat]$ ./a.out
> I'm an object
> I'm a thingy
But in a certain sense, that's a different program.
The example I have given was there to illustrate the problem, not to
illustrate where it might actually hurt you.
Check out the Visitor pattern. There, you need to add "accept" methods
to the classes that you want to be able to visit, like this:
class TreeRoot {
public void accept(Visitor v) {
v.visit(this);
}
...
}
A visitor is a class that traverses a class hierarchy:
interface Visitor {
public void visit(TreeRoot);
public void visit(TreeClass1);
public void visit(TreeClass2);
...
}
Because overloading is resolved statically, we need to repeat the accept
in each and every tree class:
class TreeClass1 extends TreeRoot {
public void accept(Visitor v) {
v.visit(this);
}
...
}
Of course, we can use an introduction advice in AspectJ to automate
this. Oh dear...
To bring this back to Common Lisp: With generic functions, you don't
need the Visitor pattern at all.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
In article <············@newsreader2.netcologne.de>, Pascal Costanza
<········@web.de> wrote:
>
> But in a certain sense, that's a different program.
Of course it's a different program. If it were the same program it would
do the same thing.
>
> The example I have given was there to illustrate the problem, not to
> illustrate where it might actually hurt you.
I still don't see the problem. Your original description was, "You know
it's a Dog (or a thingy) but the computer doesn't." The reason the
computer doesn't know it's a Dog is because you've forced it to decide
what it is at compile time, when the determination that it's a Dog can
only be made at run time. If by changing the program you allow it to wait
until run time to figure out what it is then the computer too can know
that it's a Dog.
>
> Check out the Visitor pattern.
I note with pleasure that the #1 hit on Google for "visitor pattern"
features Common Lisp prominently.
> To bring this back to Common Lisp: With generic functions, you don't
> need the Visitor pattern at all.
Is it really generic functions per se, or is it multimethods? It seems to
me that the visitor issue is the same as the old draw(shape, device)
issue. If you restricted yourself to single-argument dispatch in Lisp
you'd have the same problem. Is that right, or am I still missing
something?
E.
·········@jpl.nasa.gov (Erann Gat) writes:
> I still don't see the problem. Your original description was, "You know
> it's a Dog (or a thingy) but the computer doesn't." The reason the
> computer doesn't know it's a Dog is because you've forced it to decide
> what it is at compile time, when the determination that it's a Dog can
> only be made at run time. If by changing the program you allow it to wait
> until run time to figure out what it is then the computer too can know
> that it's a Dog.
My original problem statement, not Pascal's. And yes, you're
illustrating my point. When someone says "that's just like
overloading", the response is "except that it dispatches on the
argument type at runtime instead of fixing it at compile time, making
it a whole bundle more useful".
Given that you rewrote the example to use method dispatch instead of
overloaded arguments, that suggests to me pretty strongly that you
recognise the difference.
> Is it really generic functions per se, or is it multimethods? It seems to
> me that the visitor issue is the same as the old draw(shape, device)
> issue. If you restricted yourself to single-argument dispatch in Lisp
> you'd have the same problem. Is that right, or am I still missing
> something?
As far as I'm following this thread, that's right. But the
method-belongs-to-object c++/java mentality promotes the view of a
specially favoured 'this' argument, whereas I think multimethods
follow more naturally in a methods-belong-to-gfs view where the first
argument to a method is just an argument like any other.
-dan
Erann Gat wrote:
>>The example I have given was there to illustrate the problem, not to
>>illustrate where it might actually hurt you.
>
> I still don't see the problem. Your original description was, "You know
> it's a Dog (or a thingy) but the computer doesn't." The reason the
> computer doesn't know it's a Dog is because you've forced it to decide
> what it is at compile time, when the determination that it's a Dog can
> only be made at run time. If by changing the program you allow it to wait
> until run time to figure out what it is then the computer too can know
> that it's a Dog.
Sure, but the problem is that in Java, situations arise in which you
cannot rearrange the program in such a way that the computer can decide
this at run time, at least not in a straightforward way. The reason is
then not that I force the computer to make the decision at compile time,
but that I don't have any other choice.
>>Check out the Visitor pattern.
>
> I note with pleasure that the #1 hit on Google for "visitor pattern"
> features Common Lisp prominently.
:)
>>To bring this back to Common Lisp: With generic functions, you don't
>>need the Visitor pattern at all.
>
> Is it really generic functions per se, or is it multimethods? It seems to
> me that the visitor issue is the same as the old draw(shape, device)
> issue. If you restricted yourself to single-argument dispatch in Lisp
> you'd have the same problem. Is that right, or am I still missing
> something?
Several people describe the fact that the Visitor pattern uses simulated
double dispatch and/or tree traversal as essential properties of that
pattern, but they aren't. The actual intent of the Visitor pattern is to
be able to group methods according to their functionality and not
according to the classes to which they belong. One of the examples given
in the GoF book is a compiler, in which you have an abstract syntax tree
and different phases in the compilation process, say the type checking
phase and the code generation phase. According to "traditional" OO, the
class hierarchy has to look like this:
class Expression extends Node {
public void typeCheck(...) {...}
public void genCode(...) {...}
...
}
class ArithmeticExpression extends Expression {
public void typeCheck(...) {...}
public void genCode(...) {...}
...
}
...and so forth. The Visitor pattern turns this into the following scheme:
class TypeCheckingVisitor {
public void typeCheck(Expression e) {...}
public void typeCheck(ArithmeticExpression e) {...}
...
}
class CodeGeneratingVisitor {
public void genCode(Expression e) {...}
public void genCode(ArithmeticExpression e) {...}
...
}
The effect is that now, all the code that performs type checks is
localized in one class and all the code that performs code generation is
localized in another.
In Common Lisp, the difference is really nothing more than whether you
write this:
(defmethod type-check ((e expression))
...)
(defmethod gen-code ((e expression))
...)
(defmethod type-check ((e arithmetic-expression))
...)
(defmethod gen-code ((e arithmetic-expression))
...)
...or that:
(defmethod type-check ((e expression))
...)
(defmethod type-check ((e arithmetic-expression))
...)
(defmethod gen-code ((e expression))
...)
(defmethod gen-code ((e arithmetic-expression))
...)
To put it like this: In Common Lisp, the Visitor pattern is implemented
by the ctrl-alt-t keystroke. ;)
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
In article <············@newsreader2.netcologne.de>, Pascal Costanza
<········@web.de> wrote:
> Erann Gat wrote:
>
> >>The example I have given was there to illustrate the problem, not to
> >>illustrate where it might actually hurt you.
> >
> > I still don't see the problem. Your original description was, "You know
> > it's a Dog (or a thingy) but the computer doesn't." The reason the
> > computer doesn't know it's a Dog is because you've forced it to decide
> > what it is at compile time, when the determination that it's a Dog can
> > only be made at run time. If by changing the program you allow it to wait
> > until run time to figure out what it is then the computer too can know
> > that it's a Dog.
>
> Sure, but the problem is that in Java, situations arise in which you
> cannot rearrange the program in such a way that the computer can decide
> this at run time, at least not in a straightforward way. The reason is
> then not that I force the computer to make the decision at compile time,
> but that I don't have any other choice.
It seems to me that exactly the same situation can arise in Lisp if, for
example, you receive some code that uses non-generic functions and you
want behavior that only generic functions can provide. I don't see why
it's any different if you receive some code that uses overloading and you
want behavior that only virtual functions can provide.
> (defmethod type-check ((e expression))
> ...)
>
> (defmethod gen-code ((e expression))
> ...)
>
> (defmethod type-check ((e arithmetic-expression))
> ...)
>
> (defmethod gen-code ((e arithmetic-expression))
> ...)
>
> ...or that:
>
> (defmethod type-check ((e expression))
> ...)
>
> (defmethod type-check ((e arithmetic-expression))
> ...)
>
> (defmethod gen-code ((e expression))
> ...)
>
> (defmethod gen-code ((e arithmetic-expression))
> ...)
How is this different from:
resultT expression::type-check() { ... }
resultT arithmetic-expression::type-check() { ... }
resultT expression::gen-code() { ... }
resultT arithmetic-expression::gen-code() { ... }
vs
resultT expression::type-check() { ... }
resultT expression::gen-code() { ... }
resultT arithmetic-expression::type-check() { ... }
resultT arithmetic-expression::gen-code() { ... }
?
Sorry if I'm being thick, but I really don't see the problem.
E.
Erann Gat wrote:
>>Sure, but the problem is that in Java, situations arise in which you
>>cannot rearrange the program in such a way that the computer can decide
>>this at run time, at least not in a straightforward way. The reason is
>>then not that I force the computer to make the decision at compile time,
>>but that I don't have any other choice.
>
> It seems to me that exactly the same situation can arise in Lisp if, for
> example, you receive some code that uses non-generic functions and you
> want behavior that only generic functions can provide. I don't see why
> it's any different if you receive some code that uses overloading and you
> want behavior that only virtual functions can provide.
In Common Lisp, you can dynamically redefine a non-generic function as a
generic function and add a call to the original function as its default
method. You really don't have the problem at all in Common Lisp.
The problem in Java appears not (only) when you are working with other
peoples' code but even in your own code. If you want to apply the
Visitor pattern, you are screwed because you have to use overloading.
There's no way around it. It's an either-or situation.
>>(defmethod type-check ((e expression))
>> ...)
>>
>>(defmethod gen-code ((e expression))
>> ...)
>>
>>(defmethod type-check ((e arithmetic-expression))
>> ...)
>>
>>(defmethod gen-code ((e arithmetic-expression))
>> ...)
>>
>>...or that:
>>
>>(defmethod type-check ((e expression))
>> ...)
>>
>>(defmethod type-check ((e arithmetic-expression))
>> ...)
>>
>>(defmethod gen-code ((e expression))
>> ...)
>>
>>(defmethod gen-code ((e arithmetic-expression))
>> ...)
>
>
> How is this different from:
>
> resultT expression::type-check() { ... }
> resultT arithmetic-expression::type-check() { ... }
> resultT expression::gen-code() { ... }
> resultT arithmetic-expression::gen-code() { ... }
>
> vs
>
> resultT expression::type-check() { ... }
> resultT expression::gen-code() { ... }
> resultT arithmetic-expression::type-check() { ... }
> resultT arithmetic-expression::gen-code() { ... }
>
> ?
I don't know enough about C++ to be able to comment on this. Are these
still methods? Can you add methods to a C++ class from the outside? If
that's the case, then you indeed don't have a problem. However, IIRC
that's not the case - at least, I think you have to mention the method
headers in a C++ class, and then you're screwed again. But I might be wrong.
I have used the term generic function to refer to the fact that you can
add methods to a class from the outside. I have probably been too vague
here. There are other ways to add methods to classes from the outside.
AspectJ introductions and C#'s partial types also do the job. So what's
the case in C++?
Anyway, the real focus of my remark wrt to the Visitor pattern was not
whether methods should be defined outside or inside of classes. The
foucs is that, given you want to use the Visitor pattern for whatever
reason, you need to write an accept method in each and every class that
you want to be able to visit because of static overloading. With dynamic
dispatch (-> binary or multi-methods in this case), it would be
sufficient to write it once in the root class. The only way out would be
not to use the Visitor pattern. (Hence, it's an either-or thing.)
For example in Smalltalk, you need to simulate static overloading
manually for the Visitor pattern by giving all the visit methods
different names and again, putting accept methods in all the classes
that you want to visit.
So to summarize: The intent to group methods according to their
functionality combined with a language that doesn't allow you to add
methods to a class from the outside forces you to use the Visitor
pattern. As a consequence, you need to be able to dynamically dispatch
on two arguments which you can only simulate in a single dispatch
language. Static overloading doesn't help you here because you don't get
what you expect. (This was the original point raised in this subthread.)
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
> Erann Gat wrote:
>
> > How is this different from:
> >
> > resultT expression::type-check() { ... }
> > resultT arithmetic-expression::type-check() { ... }
> > resultT expression::gen-code() { ... }
> > resultT arithmetic-expression::gen-code() { ... }
> >
> > vs
> >
> > resultT expression::type-check() { ... }
> > resultT expression::gen-code() { ... }
> > resultT arithmetic-expression::type-check() { ... }
> > resultT arithmetic-expression::gen-code() { ... }
> >
> > ?
>
> I don't know enough about C++ to be able to comment on this. Are these
> still methods? Can you add methods to a C++ class from the outside? If
> that's the case, then you indeed don't have a problem. However, IIRC
> that's not the case - at least, I think you have to mention the method
> headers in a C++ class, and then you're screwed again. But I might be wrong.
No, they're overloaded functions. In C++, you can have
multi-dispatch, *or* you can have dynamic dispatch (using virtual
methods).
Erann: it's different because in CL you can write one single
MAP-PROGRAM-GRAPH function that will call some function on all the
nodes of the graph -- as far as it knows, all the nodes are just
instances of class NODE. Then, you can write methods on your
TYPE-CHECK gf that do different things depending on the actual type of
the node. In C++, if you use function overloading, the dispatch will
be done on the static type, so you can't have your mapped function
specialize on the actual subclass of Node it recieves.
If C++ let you have virtual overloaded functions, then you could
eliminate the Visitor pattern. As it is, the only way to get dynamic
dispatch is to use virtual methods that exist in the Node class.
(You can always roll your own dynamic dispatch in C++, using tables,
but everyone has to follow the discipline when they define their
classes. It's kind of annoying, but better than the alternative.)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Erann Gat wrote:
> In article <············@newsreader2.netcologne.de>, Pascal Costanza
> <········@web.de> wrote:
>
>>But in a certain sense, that's a different program.
>
> Of course it's a different program. If it were the same program it would
> do the same thing.
It would even be a different program if it did the same thing.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Hi Joe Marshall,
> Andr� Thieme <······································@justmail.de> writes:
>
>> Joe, can you suggest a book that concentrates on teaching/introducing
>> the important 1% of CLOS, so that as a CLOS beginner I could start
>> with these important parts of it?
>
> I have just written a `Warp Speed' introduction to CLOS. It isn't a
> tutorial, but it is intended to give a neophyte the basic flavor of
> CLOS programming without overwhelming them. It intentionally glosses
> over and omits huge amounts. On the other hand, it is only about two
> pages long and ought to be enough to get the broad concepts across.
>
> See:
>
> http://home.comcast.net/~prunesquallor/guide.html
>
> Comments and questions are welcome.
"The prepend generic function will take two arguments, an item and some
sort of thing to extend. It will return a new thing with the time
prepended on the front."
s/time/item/
Very helpful intro thanks Joe. I finally got to see the power of CLOS
code with your CALL-NEXT-METHOD example.
Regards,
Adam
* Ville Vainio
| All the #' in CL seemed like an unnecessary hassle.
After several discussions with programmers in many languages over many
years, I have gradually concluded that it is the #' reader macro that
is harmful, not the functionality it provides.
Quite unlike the QUOTE operator which people understand intuitively,
perhaps even because of its name, sharp-quote is meaningless, and the
bridge to its actual meaning is evidently difficult to build.
My suggestion is that you write (function ...) instead of #'... while
you need to internalize the functionality.
| Well, Paul Graham has. I, perhaps too hastily, extrapolated that to
| apply for rest of the Lisp community, probably because mr. Graham
| seems to be an "opinion leader" of a sort here.
He is not. There are no opinion leaders in the Lisp camp. Part of
what makes us (qua community) difficult to understand is precisely the
lack of any �leaders�. For some reason, �committee product� is a bad
thing in the eyes of many software people, who flock to the products
of single-minded single minds, instead. For some reason, following a
single leader and adopting a uniform set of ideas and ideals from one
person is preferable to adopting multifarious ideas and ideals from a
group of people who cannot seem to agree on anything, but who actually
agree on so much that the things they disagree about are /important/.
| As for marketing, I consider the user base of a language hugely
| important, and I don't see why Lisp ppl wouldn't care whether anyone
| else is using their language.
Please understand that markeing is not indicative of substance, but
rather of the lack thereof. People come to Common Lisp and Scheme in
the presence of a significantly /negativ/ marketing from those who are
unable to grasp the languages' benefits, or even their nature. The
only thing that can make people come to like something with a negative
impression in the general population is substance. So Lisp people
care very much about the substance, and so it is up to those who want
to learn to appreciate it. We know that lots of people will come
around, but also that it might take some time.
| The main implementation language is often determined by the company,
| and finding a job where Lisp is the main language is not very likely,
| at least at this time.
You are making this up, and that kind of negative marketing is very,
very annoying here. Please do not pretend that your fantasy world is
the reality others live in.
| I'm mostly checking out Lisp for recreational value.
All the people who have complained about Common Lisp and/or Scheme
features they do not understand in the past have also only come to
look at the language for their recreational value. However, the kind
of recreational value that you can get out of these languages is akin
to that of learning a foreign language, or Latin or Greek: The value
you get out of it depends entirely on whether you have put in enough
effort to acquire basic comprehension.
| I dunno, I guess I'm just looking for the same rush I got when first
| learning Python, and expected On Lisp to provide it. Apparently Lisp
| just takes more time to grow on you.
Yup. It is much more different, and the worst problem is that if you
have an �it looks the same, so it is the same� attitude towards life
in general, you will be satisfied that you have seen something you
already know, before you have any idea what you are looking at. In a
way, (Common) Lisp sorts people into those who maintain curiosity in
the presence of similarity and those who need external stimuli to keep
their curiosity up and running.
| CLOS just seemed to be rather arcane and verbose as a whole. [...]
| "Common Lisp: the language, 2nd edition" didn't really help, to say
| the least.
Try Sonya Keene.
| I'm also afraid that the initial disgust at parentheses would turn
| them away quickly - I'm past that point myself, but I certainly
| couldn't blame them.
I have written in the past on the reason for this aversion, so I have
no particular urge to repeat myself, but the central issue is that in
the C family of languages, parentheses are associated with pain and
suffering. Intelligent as most programmers are, they are still the
kinds of animals that associate intense, unrelenting discomfort, not
to say outright pain, with the nearest available culprit. Considering
the tremendously complex function that parentheses have in C, and even
more so in C++, it is not hard to understand that another language,
which sports parentheses all over the place, triggers associated pain
reactions in people who do not introspect sufficiently to understand
what, precisely, they are reacting to. I think the first thing you
have to do with people who exhibit parenthophobia is to desensitize
them and show them that the pain comes from the braindamaged abuse of
two harmless characters in the design of C and C++ and that the right
association is from C and C++ to pain, not from parentheses to pain.
--
Erik Naggum | Oslo, Norway 2004-026
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum <····@naggum.no> writes:
> He is not. There are no opinion leaders in the Lisp camp. Part of
> what makes us (qua community) difficult to understand is precisely the
> lack of any �leaders�.
this anarchist (*) attitude is also reflected in the language, e.g. in
that it supports a multitude of programming styles.
At the time I started to learn Common Lisp, I had just discovered the
minimalist beauty of Prolog, and was disgusted by the overwhelming
amount of choices in CL. It's a bit funny to consider that programmers
coming to CL today, may have fought their way out of a swamp of
thousands of half-useful java libraries or a horror jungle full of
useless xml, uml and whatever-ml, and thus may like lisp because they
think it looks minimalist! No wonder some of them overreact and turn
to scheme...
(*) you're free to read it as 'individualist' if your only
interpretation of 'anarchist' is 'bomb-throwing nihilist' ;-)
--
(espen)
Erik Naggum <····@naggum.no> writes:
> My suggestion is that you write (function ...) instead of #'... while
> you need to internalize the functionality.
I second this idea. It doesn't take much time at all to figure out
where you need it, and then it will seem obvious.
> There are no opinion leaders in the Lisp camp.
Unless you count all of us.
> Ville Vainio writes:
>
> As for marketing, I consider the user base of a language hugely
> important, and I don't see why Lisp ppl wouldn't care whether anyone
> else is using their language.
Part of being a comp.lang.lisp savage (TM) is a complete lack of
interest in how other people abuse themselves (although the more
misanthropic of us take a certain glee in hearing about it). If
someone else really wants to write code in, say, visual basic, they
pretty much get what they deserve.
> The main implementation language is often determined by the company,
> and finding a job where Lisp is the main language is not very likely,
> at least at this time.
Times are rough all over, but there are several people in this group
who have made a career based almost solely upon Lisp. It is by no
means a `dead-end'.
> | I dunno, I guess I'm just looking for the same rush I got when first
> | learning Python, and expected On Lisp to provide it. Apparently Lisp
> | just takes more time to grow on you.
Definitely. It is an acquired taste, like stinky cheese, or extremely
peaty single malt scotch.
Joe Marshall wrote:
> Erik Naggum <····@naggum.no> writes:
>>| I dunno, I guess I'm just looking for the same rush I got when first
>>| learning Python, and expected On Lisp to provide it. Apparently Lisp
>>| just takes more time to grow on you.
>
>
> Definitely. It is an acquired taste, like stinky cheese, or extremely
> peaty single malt scotch.
>
I must be some sort of mutant, because I took to Lisp at once and,
although it was not my first programming language, it at once seemed
that it was my native programming language. I like programming languges
in general, and periodically learn new ones for fun, but once I began to
learn Lisp it because my language of choice and no other language has
ever dislodged it.
I've fooled around idly for years with ideas for Lisp operating systems
for no better reason than that I worked on a Lisp-based OS at Apple in
1992-1994, and no day job has ever been as much fun since.
mikel evins <·····@evins.net> writes:
> Joe Marshall wrote:
> > Erik Naggum <····@naggum.no> writes:
>
> >>| I dunno, I guess I'm just looking for the same rush I got when
> >>| first learning Python, and expected On Lisp to provide
> >>| it. Apparently Lisp just takes more time to grow on you.
> >
> > Definitely. It is an acquired taste, like stinky cheese, or
> > extremely peaty single malt scotch.
>
> I must be some sort of mutant, because I took to Lisp at once [...]
I first encountered Lisp in college and the introduction was as
described in Successful Lisp description of the typical student
experience <http://www.psg.com/~dlamkins/sl/chapter02.html#student>:
"if you've learned Lisp in a typical classroom setting, you may have
come to believe that the language is nothing but lists and recursion."
I must really be a mutant because I actually feel in love with the
parenthesis for quasi-aesthetic reasons from the very beginning. I
already had a tendency to use nested parenthetical digressions when
writing English. I think I probably was influenced by the likes of
Monty Python ("welcome to the middle of the film"), Kurt Vonnegut (the
bit from _Breakfast of Champions_, if I'm remembering things
correctly, in which the author is explaining in the story how he has
only limited control over his characters, as if he was a puppeteer
controlling marionettes with old rubber bands), etc., using non-linear
naratives and mixing meta-story in with the story (not like I would
pretend to be able to write at their level (freqently these
digressions of mine (like this one) would have probably be better
restructured with a more conventional structure) nor do I mean any
offense to their reputations by claiming them as influences). This
combined with the idea that Lisp uses lists, with all these
"beautiful" parenthesis, for code *and* data, blurring the distinct
between the two, is what attracted me to Lisp in the first place. But
I might be the only person to use this kind of bad writing caused by a
type of punctuational attention deficit disorder, getting distracted
mid-sentence and feeling the need to record this as a parenthetical
landmark, as a reason to find a programming language appealing.
Erik Naggum <····@naggum.no> writes:
> | I dunno, I guess I'm just looking for the same rush I got when first
> | learning Python, and expected On Lisp to provide it. Apparently Lisp
> | just takes more time to grow on you.
>
> Yup. It is much more different, and the worst problem is that if you
> have an �it looks the same, so it is the same� attitude towards life
> in general, you will be satisfied that you have seen something you
> already know, before you have any idea what you are looking at. In a
> way, (Common) Lisp sorts people into those who maintain curiosity in
> the presence of similarity and those who need external stimuli to keep
> their curiosity up and running.
Reading this reminds of the following chapter of Robert Strandh's
excellent introductory text:
http://dept-info.labri.u-bordeaux.fr/~strandh/Teaching/MTP/Common/Strandh-Tutorial/psychology.html
It discusses perfection-oriented versus performance-oriented
learners. I think Common Lisp is a good match for the
perfection-oriented.
Bj�rn
Ville Vainio wrote:
> I guess answering to this one covers most of the points in other
> posts, so here goes.
>
>
>>>>>>"Bulent" == Bulent Murtezaoglu <··@acm.org> writes:
>
>
> VV> Also, Lisp mostly impressed me initially because it was simple
> VV> and orthogonal. Reading On Lisp kinda crushed that illusion
> VV> for me - Common Lisp is not simple.
>
> Bulent> What part did you find complicated? On Lisp is not
>
> Well, all of the sharp-quoting for starters. Seperate namespace for
> functions seems to cause nothing but harm. This is more of an issue
> for CL, not On Lisp.
Seperate namespaces for functions only cause the mild inconvience of
having to understand and know about funcall and function/#'. A unified
namespace for values and functions causes potentially severe macro
hygiene problems and, in the Scheme community, has led to numerous
proposals for hygienic macro facilities, apparently no actual agreement
on a single one, a standardization of only a very weak one, and an
ignorance of the fact that name capture can be extremely useful if done
right. And all this only to save a few keystrokes.
> Bulent> intended for people who are new to the language (IMHO,
> Bulent> dunno what Graham intended but he did author another, more
> Bulent> accessible book, ANSI Common Lisp).
>
> ACL didn't appear to be available for download, so that was not an
> option. Python experience has conditioned me to expect free
> documentation, so I kinda expected the same from Lisp. I guess that
> shouldn't be too much to ask for a 50 year old language that is still
> very much alive ;-).
ACL has a free version. Just look closer. There are numerous tutorials
and a few browsable specifications for free on the net. Again, just look
closer. http://alu.cliki.net is a good starting point.
> Bulent> We don't have a "FP is the way to go" attitude. I agree
>
> Well, Paul Graham has. I, perhaps too hastily, extrapolated that to
> apply for rest of the Lisp community, probably because mr. Graham
> seems to be an "opinion leader" of a sort here.
The Lisp community doesn't have an opinion leader. Common Lisp is a
truly multi-paradigm language, which means that it attracts people on
very different levels. What's wrong for some is exactly right for
others, and vice versa.
> Perhaps my problem is that I don't really have problems that I don't
> know how to solve. I'm mostly checking out Lisp for recreational
> value. I dunno, I guess I'm just looking for the same rush I got when
> first learning Python, and expected On Lisp to provide it. Apparently
> Lisp just takes more time to grow on you.
Yep.
> Bulent> Again what feature of CLOS would you remove?
>
> CLOS just seemed to be rather arcane and verbose as a whole. I admit I
> haven't really put much energy into getting to know it, because I
> didn't have a good implementation (as elisp implementation is a bit
> lacking). "Common Lisp: the language, 2nd edition" didn't really help,
> to say the least.
Again, there are number of good resourse out there on the net. I mention
a few in my guide at http://www.pascalcostanza.de/lisp/guide.html
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Ville Vainio wrote:
> I guess answering to this one covers most of the points in other
> posts, so here goes.
>
>
>>>>>>"Bulent" == Bulent Murtezaoglu <··@acm.org> writes:
>
>
> VV> Also, Lisp mostly impressed me initially because it was simple
> VV> and orthogonal. Reading On Lisp kinda crushed that illusion
> VV> for me - Common Lisp is not simple.
>
> Bulent> What part did you find complicated? On Lisp is not
>
> Well, all of the sharp-quoting for starters. Seperate namespace for
> functions seems to cause nothing but harm. This is more of an issue
> for CL, not On Lisp.
Never hurt me.
>
> Recently I implemented a toy Lisp system in python where I could do:
^^^
Let's underline "toy"
>
> (setq myfunc (lambda (x) (+ x 1)))
> (setq res (myfunc 6))
>
> All the #' in CL seemed like an unnecessary hassle.
Seems like you suffer from having read the infamous
http://www.strout.net/python/pythonvslisp.html
:)
> Bulent> intended for people who are new to the language (IMHO,
> Bulent> dunno what Graham intended but he did author another, more
> Bulent> accessible book, ANSI Common Lisp).
>
> ACL didn't appear to be available for download, so that was not an
> option. Python experience has conditioned me to expect free
> documentation, so I kinda expected the same from Lisp. I guess that
> shouldn't be too much to ask for a 50 year old language that is still
> very much alive ;-).
There is plenty of free documentation for Common Lisp. The fact that
there isn't a centralized site where all of this is listed (actually
there is www.cliki.net :) ) is simply a reflection that there are more
than 1.8 implementations of Common Lisp around, 5 of which with
extremely good compilers.
...
> Perhaps my problem is that I don't really have problems that I don't
> know how to solve. I'm mostly checking out Lisp for recreational
> value. I dunno, I guess I'm just looking for the same rush I got when
> first learning Python, and expected On Lisp to provide it. Apparently
> Lisp just takes more time to grow on you.
Yes. It does take a little more time. Patience has its own rewards.
>
> VV> ... Make easy things easy.
>
> Bulent> What easy thing, in your opinion, is hard in CL? Is it
> Bulent> that libraries are not available for what you take for
> Bulent> granted in Python or is it some language feature you find
> Bulent> hard?
>
> Pretty much. I would like to see an Open Source Lisp implementation
> with a big standard library, providing sockets, normal posix stuff,
> and generally most of the stuff in the Python standard library. And in
> equally easy to use form.
Could you name a Common Lisp implementation that does not provide you
with all of that? (I'll challenge you even on the GUI side).
>
> VV> Implement a simpler, less powerful standard object system (as
> VV> opposed to telling people to implement their own or use CLOS).
>
> Bulent> Again what feature of CLOS would you remove?
>
> CLOS just seemed to be rather arcane and verbose as a whole. I admit I
> haven't really put much energy into getting to know it, because I
> didn't have a good implementation (as elisp implementation is a bit
> lacking). "Common Lisp: the language, 2nd edition" didn't really help,
> to say the least.
>
> To me a following object system (requiring tweaking the Lisp reader to
> grok '.', I assume) might have had a more immediate appeal:
>
> (defclass MyClass (Base1 Base2)
> (def init (x y) (
> (setq self.x x)
> (setq self.y y)))
> (def say () (
> (print self.x self.y))))
>
>
> (setq instance (MyClass 4 5))
>
> (instance.say)
That is beacuse you are not getting the CLOS Karma. Why should
(+ 2 3)
be different from calling a method? The CLOS answer is that it
shouldn't. So you say
(say instance)
On top of that, why should accessing a member variable be different from
(/ 3 pi)
The Common Lisp way tells you that there is no difference, therefore you say
(x instance)
Common Lisp is so flexible that it allows you also to rename the
"accessor" so that you can say
(x-of instance)
As per your example, actually you *can* write it in Common Lisp (with
some effort). You *cannot* extend Python to accept instead
def foo (base1 base2)
x initarg foox
y initarg fooy initform 42
instance = foo(foox = 22)
def say (foo x)
print x.x x.y
def say (bar x)
print 'I am a bar'
print x.somevar
instance = bar()
say(instance)
(You can have multimethods in Python, but in a clumsier way and never
compiled)
To achieve the above you have to hack in the C/YACC/Whatever parser for
Python.
>
> I know that the model has zillions of problems, and shredding it to
> pieces is not really worth it. Just showing what kind of aesthetic I
> like.
It is not just a matter of aesthetic. Common Lisp correctly separates
the notion of encapsulation (packages - with all, but not many,
limitations) form that of OOP. Generic functions *are* a better way to
do OOP.
>
> But I guess this is just a matter of prejudice - I might change my
> mind immediately when I actually try CLOS on real CL. I'm certainly
> going to.
That is good. Download CMUCL and have fun with it. You will see why we
pine so much about it.
Cheers
--
Marco
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Ville Vainio wrote:
>
>> I guess answering to this one covers most of the points in other
>> posts, so here goes.
>>
>>>>>>>"Bulent" == Bulent Murtezaoglu <··@acm.org> writes:
>> VV> Also, Lisp mostly impressed me initially because it was simple
>> VV> and orthogonal. Reading On Lisp kinda crushed that illusion
>> VV> for me - Common Lisp is not simple.
>> Bulent> What part did you find complicated? On Lisp is not
>> Well, all of the sharp-quoting for starters. Seperate namespace for
>> functions seems to cause nothing but harm. This is more of an issue
>> for CL, not On Lisp.
>
> Never hurt me.
But you don't run with quotes. (Sorry, bad pun.)
>> Pretty much. I would like to see an Open Source Lisp implementation
>> with a big standard library, providing sockets, normal posix stuff,
>> and generally most of the stuff in the Python standard library. And in
>> equally easy to use form.
>
> Could you name a Common Lisp implementation that does not provide you
> with all of that? (I'll challenge you even on the GUI side).
He explicitly said that he wanted all that to be _in_ the CL
implementation itself. The ability to choose third-party libraries for
unexplored or non-standardizable code has been revoked. :)
>> I know that the model has zillions of problems, and shredding it to
>> pieces is not really worth it. Just showing what kind of aesthetic I
>> like.
>
> It is not just a matter of aesthetic. Common Lisp correctly separates
> the notion of encapsulation (packages - with all, but not many,
> limitations) form that of OOP. Generic functions *are* a better way to
> do OOP.
Actually, the problem is even worse with these C++/Java/Python/Ruby
languages. They conflate 3 things: types, scopes, and
namespaces. (Granted, C++ has namespaces, so it is a bit better about
this than the others.)
>> But I guess this is just a matter of prejudice - I might change my
>> mind immediately when I actually try CLOS on real CL. I'm certainly
>> going to.
>
> That is good. Download CMUCL and have fun with it. You will see why we
> pine so much about it.
And CMUCL's compiler is named Python, to boot. I'm sure he'll have a
blast. :)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain <·····@nyct.net> writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> > Ville Vainio wrote:
> >
> >> Well, all of the sharp-quoting for starters. Seperate namespace for
> >> functions seems to cause nothing but harm. This is more of an issue
> >> for CL, not On Lisp.
> >
> > Never hurt me.
>
> But you don't run with quotes.
Thinking that sharp = dangerous is a common but potentially hazardous
misconception. As all professional cooks know, dull knifes are the
hazard, not sharp ones. They're tools that should be handled with
care, but in a trained hand, they're not dangerous. Dull knifes will
lop your finger off, tho.
Perhaps our profession should be more like cooking in this regard, and
warn our newbies. After all, we've all been harmed by badly used
quotes, but how many of us have been hurt by sharp-quotes?
Half-seriously,
Thomas
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Rahul Jain wrote:
>
>
> But you don't run with quotes. (Sorry, bad pun.)
Well, parentheses () looks like safety brakes :)
>
>
>>>Pretty much. I would like to see an Open Source Lisp implementation
>>>with a big standard library, providing sockets, normal posix stuff,
>>>and generally most of the stuff in the Python standard library. And in
>>>equally easy to use form.
>>
>>Could you name a Common Lisp implementation that does not provide you
>>with all of that? (I'll challenge you even on the GUI side).
>
>
> He explicitly said that he wanted all that to be _in_ the CL
> implementation itself. The ability to choose third-party libraries for
> unexplored or non-standardizable code has been revoked. :)
>
Ok.
>>
>>It is not just a matter of aesthetic. Common Lisp correctly separates
>>the notion of encapsulation (packages - with all, but not many,
>>limitations) form that of OOP. Generic functions *are* a better way to
>>do OOP.
>
>
> Actually, the problem is even worse with these C++/Java/Python/Ruby
> languages. They conflate 3 things: types, scopes, and
> namespaces. (Granted, C++ has namespaces, so it is a bit better about
> this than the others.)
Yes. It is interesting that C++ had to introduce namespaces and Ada had
to introduce OO concepts. Common Lisp got this right (well, close
enough) pretty much from the beginning
>>>But I guess this is just a matter of prejudice - I might change my
>>>mind immediately when I actually try CLOS on real CL. I'm certainly
>>>going to.
>>
>>That is good. Download CMUCL and have fun with it. You will see why we
>>pine so much about it.
>
>
> And CMUCL's compiler is named Python, to boot. I'm sure he'll have a
> blast. :)
>
Yep. I forgot to mention that :)
Cheers
--
marco
Ville Vainio wrote:
> Well, all of the sharp-quoting for starters. Seperate namespace for
> functions seems to cause nothing but harm. This is more of an issue
> for CL, not On Lisp.
I disagree completely on this. It forces you to write (funcall fn ...)
instead (fn ...), but this is almost always a trivial cost. In return,
you get considerable simplification of the programmer's cognitive load.
It also becomes easier to compile the common case to safe, efficient code --
compiling (FOO x y z) doesn't require an analysis to determine if FOO
is bound to a function (if FOO isn't FBOUND, the implementation can
put a standard error-signalling function in the symbol's function slot.)
Paul
* Bulent Murtezaoglu wrote:
> We don't use lisp
> for scripting, and we are not really system administrators.
We are. We may not use it for scripting but we've used it for
implementing SW build systems and we're considering using it for a
cluster deployment tool (but we'll probably end up using perl).
--tim
Ville Vainio <····························@thisisspamprotectiontut.finland> wrote:
> As a Pythonista, I felt like chipping in here.
You might be interested in this:
http://alu.cliki.net/Comparing%20Lisp%20and%20Python
The big thing Lisp has that Python doesn't is macros.
There are a lot of little things Python has that Lisp doesn't.
Type/class unification is probably the biggest -- in Lisp, you can't
subclass a built-in type such as numbers or hash tables. On the other
hand, since you can specialize a Lisp method on a built-in type, there
is a lot less -reason- to want to subclass one.
Python is not without its own non-obvious, ad-hoc, and confusing bits,
either. I'd say that many of the uses of the __foo__ members on objects
and classes could count as such.
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
"Karl A. Krueger" <········@example.edu> writes:
> There are a lot of little things Python has that Lisp doesn't.
> Type/class unification is probably the biggest -- in Lisp, you can't
> subclass a built-in type such as numbers or hash tables.
I wasn't aware that Python allowed you create your own number
subclasses. Is this what you meant to convey?
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain <·····@nyct.net> wrote:
> "Karl A. Krueger" <········@example.edu> writes:
>> There are a lot of little things Python has that Lisp doesn't.
>> Type/class unification is probably the biggest -- in Lisp, you can't
>> subclass a built-in type such as numbers or hash tables.
>
> I wasn't aware that Python allowed you create your own number
> subclasses. Is this what you meant to convey?
Why yes, I did. In Python, you can indeed subclass numeric types such
as 'int' and 'float':
Python 2.3.2 (#1, Nov 30 2003, 16:48:05)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class SillyInt(int):
... def __init__(self, num):
... print "I'm silly, but you can call me %d" % num
...
>>> moo = SillyInt(5)
I'm silly, but you can call me 5
>>> boo = SillyInt(5.5)
I'm silly, but you can call me 5
>>> moo + boo
10
>>> class SillyFloat(float):
... def __init__(self, num):
... intpart = int(num)
... fracpart = num - intpart
... print "I'm %d plus %f." % (intpart, fracpart)
...
>>> whee = SillyFloat(3.1415)
I'm 3 plus 0.141500.
>>> whee + moo
8.1415000000000006
(Hooray for precision.)
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
"Karl A. Krueger" <········@example.edu> writes:
> The big thing Lisp has that Python doesn't is macros.
I disagree. Not with the lack of macros being a "big thing", but with
it being "the" big thing.
The other unique thing in CL that you don't have in Python, and other
languages, is CLOS - things like multiple dispatch, eql specializers,
fancy method combinations, user-defined generic function classes (and
generic functions that don't "belong" to a class in general), class
redefinition with controllable instance updating etc. are all very
cool to have, and while some of these things are possible in Python,
IMHO they are a lot nicer in CL.
(And the not-so-big things matter as well. It is cool that Python
functions can take &rest- and &key-like arguments, but it would be
even cooler if it were possible to see whether an actual value was
provided or whether it was defaulted. There are more things like this
where the Python constructs are nearly, but not quite, as useful as
their CL counterparts. I guess if you believe in the 80/20 rule, this
is the right thing to do, but there are (albeit rare) cases where
things get needlessly messy.)
> There are a lot of little things Python has that Lisp doesn't.
> Type/class unification is probably the biggest -- in Lisp, you can't
> subclass a built-in type such as numbers or hash tables.
Indeed, in that regard, Python wins. Another example is the __call__
"magic" method, which feels more natural than using
funcallable-standard-classes.
> On the other hand, since you can specialize a Lisp method on a
> built-in type, there is a lot less -reason- to want to subclass one.
It would however be nice if a lot more CL functions were generic.
Henrik Motakef <············@henrik-motakef.de> writes:
> "Karl A. Krueger" <········@example.edu> writes:
>
>> The big thing Lisp has that Python doesn't is macros.
>
> I disagree. Not with the lack of macros being a "big thing", but with
> it being "the" big thing.
>
> The other unique thing in CL that you don't have in Python, and other
> languages, is CLOS
You forgot the condition system.
And you forgot that the reason why we have both of those is because of
macros. :)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Ville Vainio <····························@thisisspamprotectiontut.finland> wrote in message news:<···············@mozart.cc.tut.fi>...
> It's true that languages like Python introduce Lisp concepts like
> dynamic typing and first class functions, and people learn to
> appreciate them.
>
> However, they also reduce the astonishment people get when they check
> out Lisp. Lisp is not all *that* special. I've been reading On Lisp,
> trying to get excited about the language. However, while the book may
> impress a C++ programmer, I have to say I'm not particularly
> impressed. Most of the stuff I like about Lisp is available in Python,
> in a more accessible fashion (I know that standard response for the
> newsgroup might be "that's because you suck/are stupid", so if that's
> your reaction, you can as well save your breath).
Speaking as a Pythonista flirting with Scheme I understand how do you feel.
I had exactly the same impression when I started using Scheme.
More or less, my first impression was something like "where is all the fuss?
anybody is talking about how wonderful is Lisp/Scheme, still I don't see
any real advantage with respect to Python".
After a month or so of Scheme programming, I changed my mind.
I was writing a code walker in Scheme then, and suddenly I got the
code=data/s-expressions/macros thing. Notice that I had already
(superficially) got macros, s-expressions and the code=data
concept separately, but I failed to consider the three things together
(maybe because I was distracted by the hygiene thing, at the end I
decided to go back to define-macro + gensym, I feel it is somewhat better).
But finally I got the connection and then I was impressed, *really* impressed.
This is the real difference with Python, and it is a HUGE difference.
Yes, of course Python has "eval" and therefore macros in nuce (I still
remember that "eval" was the thing of Python that impressed me the most)
but without s-expressions and the code=data idea, "eval" is essentially a
mutilated construct (also, it only works at run time, whereas macros
work at compile time). So, when you get the three things and their connection,
you will realize that Scheme/Lisp is a complete shift of paradigm with
respect to Python. I don't claim I understand the full extent of macro
programming, but I do understand enough to find it awesome. Essentially,
you have the power to implement your own programming language, but also
all the risk of it.
(BTW, I do think that for 99% of tasks the danger is bigger than the benefit
and I do NOT want to add macros in Python).
> Also, Lisp mostly impressed me initially because it was simple and
> orthogonal. Reading On Lisp kinda crushed that illusion for me -
> Common Lisp is not simple. Lisp might become more attractive for
> newbies if there was something better on the table. CL might be
> tried-and-true, but it's not really all that exciting. It's too
> verbose (esp. CLOS) and complicated. I imagine an energetic Open
> Source group could do lots of good things for Lisp, including a
> partial redesign (Arc is still vaporware).
As others said, you are confusing Scheme with Lisp. One of the reasons
why I have chosen Scheme over Lisp is that there are lots of free
implementations which are trivial to install (and probably you have at least
Guile already installed in your GNU/Linux system). So, maybe you
should try Scheme instead. It is said that learning Scheme before
Lisp can cause brain damage, but I decided to take the risk ;)
> It wouldn't hurt to get cmucl (or other CL implementation) into
> Fedora, either. Write some interesting libraries, demonstrate people
> how easy they are to use (I checked out Python after seeing how easy
> CORBA was there), make scripting tasks easy, lose the "FP is the way
> to go" attitude, it mostly serves to turn people away from the
> language.
Both Scheme and Lisp are not functional languages, they are multi-paradigm
languages where you can do functional programming, just as in Python.
> Make easy things easy.
Yeah, this was my major concerns with Scheme, too. It is not a "programmable
language", it is a "to be programmed language". I mean, you are *forced* to
program it, since by default it is cumbersome and rather unusable. OTOH,
in Python Guido has already done the job for you and the language provides
sensible defaults. On the other hand, in Scheme you are supposed to do
a fairly large amount of customization and programming of the language
before you start writing any application with it. This takes time and effort,
and it is an entirely new programming habit you have to get. In the
long run, it may be worth it, but certainly not in the short run, when
you want to develop very fast and a minimal amount of thinking (for instance
when you want to do some rather trivial scripting). So, for most of jobs,
Lisp is overkill.
> Implement a simpler, less powerful
> standard object system (as opposed to telling people to implement
> their own or use CLOS).
As before: you are supposed to do the job of customizing the object system
yourself. I don't know specifically about CLOS, but I quite like TinyCLOS:
it does not seem very different from Python object model, apart
for the multimethods.
> As it stands, I can easily advocate Python to my colleagues, confident
> that they will love it if they just take a few hours to epxlore
> it. However, I can't realistically expect them to take a brief look at
> Lisp and love it. Some of them (including yours truly) learned Scheme
> at school, and forgot the language immediately after the course. It
> wasn't used in the "real world", and wasn't fun enough to use in own
> projects. Blame it on pedagogics, but if the course taught Python, it
> would have required an extraordinarily crappy teacher to make me not
> want to use the language after the course.
Agreed.
> Please don't take this as a contribution to a language flamewar - I
> wish Lisp all the best, and will probably continue using it in a form
> of elisp, perhaps even start a toy project in CL (once I get a good CL
> for Fedora). Just wanted to point out that the superiority of Lisp is
> not so clear as to make Pythonistas drop Python and start doing Lisp
> instead. Many Pythonistas are flirting with Lisp, but so far I haven't
> seen any significant migration taking place.
As a matter of fact, I don't think I will migrate to Scheme/Lisp for
most of my programming tasks, since Python is simply more convenient
to use for most of things (especially for the libraries). Still, if I
wanted to implement a specialized mini-language or a symbolic calculation
package, I would rather implement it in Scheme/Lisp than in Python.
Just my 0.02c,
Michele Simionato
>>>>> "Michele" == Michele Simionato <·················@poste.it> writes:
Michele> installed in your GNU/Linux system). So, maybe you should
Michele> try Scheme instead. It is said that learning Scheme
Michele> before Lisp can cause brain damage, but I decided to take
Michele> the risk ;)
But isn't the library situation even worse for Scheme?
--
Ville Vainio http://tinyurl.com/2prnb
Ville Vainio wrote:
>
> >>>>> "Michele" == Michele Simionato <·················@poste.it> writes:
>
> Michele> installed in your GNU/Linux system). So, maybe you should
> Michele> try Scheme instead. It is said that learning Scheme
> Michele> before Lisp can cause brain damage, but I decided to take
> Michele> the risk ;)
>
> But isn't the library situation even worse for Scheme?
>
It's more fractious and fragmented. Some schemes (like MITscheme, now
MIT/Gnu Scheme) provide pretty much everything that the Common Lisp
standard requires in terms of library functions. TinyCLOS is available
as a portable library for Schemes, which, I think, is just about
equivalent to CLOS except that all the parts which are necessary in
CL because of its separate function namespace and different macrology
are omitted, and some other stuff having to do with scheme macrology
is added.
The "worse" part happens when you take your MITscheme application and try
to run it on any other scheme. Even another heavyweight scheme that
provides all the stuff, is likely to provide it with different function
names and argument signatures, and/or slightly different semantics for
doing similar tasks. What raises an exception in one system is assigned
a nonstandard semantics in another as an extension, returns a value of
type "error" in a third, invokes an error continuation in a fourth, and
crashes in a fifth.
Basically, the scheme standard originated as the *Intersection* of about
a dozen strong implementations, whereas the Common Lisp standard originated
as the *Union* of five or six strong implementations. And the differences
which prevented things from getting into the standard persist, and designers
of new scheme systems use the standard's silence on such matters to
introduce compatible extensions (that is to say, compatible with the
standard - and only occasionally with other scheme systems as well)
that allow them to experiment with or specialize their implementations.
F'r example I've got a scheme of my own cooking that is specialized for
natural-language work, where "strings" generally range from about 10K
to 2M characters long and may include non-ascii characters. It uses a
completely different string representation. Inserts, deletes, lookups,
etc, are all order(log N), substrings can be shared between different
string values, and the character set is infinite. A character in this
system is any valid combining sequence of unicode. I think it's a
design win for its intended domain - working with huge strings where you
copy, insert, and delete a lot, think of characters as linguistic entities
rather than representational units, and don't necessarily know (or care)
how big (how many unicode codepoints) any particular character is. The
scheme standard allows this kind of experimentation/specialization,
because it is silent on the internal representation of strings and
nearly silent on matters of character encodings, reflecting several
different character encodings; the Common Lisp standard specifies a
class relationship between strings and vectors that rules it out.
So, in different places you see different things. All CL's, to a first
approximation, are very similar and provide a huge set of things to work
with that are quite standardized. Schemes range from minimal systems
suitable for embedding, to huge systems bigger than the CL standard
requires, but in terms of the underlying machinery, or to the extent
that they exceed the minimal standard, they are often dissimilar and/or
actively experimental in surprising ways.
Bear
Ville Vainio <····························@thisisspamprotectiontut.finland> writes:
> orthogonal. Reading On Lisp kinda crushed that illusion for me -
> Common Lisp is not simple. Lisp might become more attractive for
> newbies if there was something better on the table. CL might be
Common Lisp is probably not intended for newbies, by design. It is
intended for those who are willing to spend the time for learning it.
> language. Make easy things easy. Implement a simpler, less powerful
> standard object system (as opposed to telling people to implement
> their own or use CLOS).
This seems to imply that ignoring the complicated and powerful
features of CLOS may not be an option for you. If so, can you
elaborate on that?
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton <·······@nyc.rr.com> writes:
> Python and other upstarts help by fomenting rebellion against C++ and
> Java; by introducing Lisp concepts to their users and showing what
> development can be like; and by falling short of Lisp, so eventually
> they will change to Lisp.
A couple of years ago, I talked to some guys from a company that built
server applications in python, they mentioned something like "we may
need to recode some of the stuff in C++ for efficiency reasons". It
would be great if it would be possible to convince those that grow out
of python that their obvious upgrade path is Common Lisp...
--
(espen)
Espen Vestre wrote:
> A couple of years ago, I talked to some guys from a company that built
> server applications in python, they mentioned something like "we may
> need to recode some of the stuff in C++ for efficiency reasons". It
> would be great if it would be possible to convince those that grow out
> of python that their obvious upgrade path is Common Lisp...
How about a Python implementation on top of Common Lisp?
Paul
* ········@myrealbox.com (Nepheles)
| Where do people feel Lisp is going? How will popularity change? Is
| Lisp threatened by upstarts like Python? Will Lisp become more
| acceptable for general application development?
Common Lisp will always be there for programmers who need to work out
the solution while coding and watching the computer work on the data.
Common Lisp is already not for the kind of people who obsess about the
details of implementation and the machine resources used, so as the
machine resources continue to be less important to the development of
software solutions, Common Lisp should become more and more suitable
for solution-oriented programmers and projects.
What keeps Common Lisp from becoming BEOL/ENDOL� is that it represents
data in memory very differently from other languages, particularly
those designed by people of the static type analysis persuasion who
mistakenly believe that the recipient of a bag of bits is satisfied
that it was what he advertised that he wanted and therefore does not
require any work to ascertain its validity on the receiving end. When
static type people understand that interaction with computers that are
not under the spell of the omniscient compiler is fraught with danger,
they resort to things like XML instead of waking up from their denial
of the real world.
What has to go before Common Lisp will conquer the world is the belief
that passing unadorned machine words around is safe just because some
external force has �approved� the exchange of those machine words.
-------
� BEOL/ENDOL -- the mythical ultimate programming language
--
Erik Naggum | Oslo, Norway 2004-026
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
In article <·······················@naggum.no>, Erik Naggum
<····@naggum.no> wrote:
> Common Lisp will always be there for programmers who need to work out
> the solution while coding and watching the computer work on the data.
Joel Spolsky says this is (unconditionally) a bad idea. See
http://www.joelonsoftware.com/articles/fog0000000036.html.
E.
·········@jpl.nasa.gov (Erann Gat) wrote in message news:<··························@192.168.1.51>...
> In article <·······················@naggum.no>, Erik Naggum
> <····@naggum.no> wrote:
>
> > Common Lisp will always be there for programmers who need to work out
> > the solution while coding and watching the computer work on the data.
>
> Joel Spolsky says this is (unconditionally) a bad idea. See
> http://www.joelonsoftware.com/articles/fog0000000036.html.
>
Spolsky advocates specification prior to the project, and it is hard
to disagree that a specification, where it can be rendered, is
desirable. Unfortunately, in unusual situations one often doesn't know
in advance how to approach the problem, or if the problem can be
solved at all. This takes quite some tinkering with data sets, problem
domain representations and algorithms to fiugre out, and Lisp is a
very fine tool at that.
Or take for instance reverse engineering. What good is Joel's advice
when you don't have a protocol or file format specification?
Various projects have different proportion of specified and
underspecified, but the latter is present in virtually all of them:
otherwise there'd be no need for human programmer.
--
Eugene
P.S. It just occurred to me that you could be pointing at the article
ironically. Still, my reply is written already :)
In article <····························@posting.google.com>,
······@funcall.org (Eugene Zaikonnikov) wrote:
> ·········@jpl.nasa.gov (Erann Gat) wrote in message
news:<··························@192.168.1.51>...
> > In article <·······················@naggum.no>, Erik Naggum
> > <····@naggum.no> wrote:
> >
> > > Common Lisp will always be there for programmers who need to work out
> > > the solution while coding and watching the computer work on the data.
> >
> > Joel Spolsky says this is (unconditionally) a bad idea. See
> > http://www.joelonsoftware.com/articles/fog0000000036.html.
> >
> Spolsky advocates specification prior to the project, and it is hard
> to disagree that a specification, where it can be rendered, is
> desirable. Unfortunately, in unusual situations one often doesn't know
> in advance how to approach the problem, or if the problem can be
> solved at all. This takes quite some tinkering with data sets, problem
> domain representations and algorithms to fiugre out, and Lisp is a
> very fine tool at that.
Yes, but should I conclude then that you believe that Lisp is only
suitable in "unusual situations"?
> P.S. It just occurred to me that you could be pointing at the article
> ironically. Still, my reply is written already :)
No, I pointed it out in all seriousness. I was hoping the response would
be something like, "Oh, Spolsky's argument was demolished by Arglebargle
back in 1993. Go see http://..."
E.
·········@jpl.nasa.gov (Erann Gat) writes:
> In article <····························@posting.google.com>,
> ······@funcall.org (Eugene Zaikonnikov) wrote:
>
> > P.S. It just occurred to me that you could be pointing at the article
> > ironically. Still, my reply is written already :)
>
> No, I pointed it out in all seriousness. I was hoping the response would
> be something like, "Oh, Spolsky's argument was demolished by Arglebargle
> back in 1993. Go see http://..."
I'm pretty sure some of the eXtreeeeeeeeeme programming people (and
their less caffeinated pair-programming neighbors) have good
rebuttals, that are essentially the Lisp line here: that's fine when
it works, but the problem with the spec everything first approach, is
that you often can't. Maybe you can spec large parts of the problem,
but rarely the whole thing. What you end out with is specs that are
wrong -- so you either have an incorrect program, or a program that's
at variance with the spec, or you spend 10 years going through a
hellish spec-debug-compile-link-debug-revise-spec cycle.
I am a fan of writing specs for the known, solved parts of a problem.
In fact, I'll even translate the spec into an s-expression notation,
and voila, I have my program in declarative form. Of course, there's
a bunch of work left to get it running, but now I know it implements
the spec.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@famine.OCF.Berkeley.EDU>,
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> ·········@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <····························@posting.google.com>,
> > ······@funcall.org (Eugene Zaikonnikov) wrote:
> >
> > > P.S. It just occurred to me that you could be pointing at the article
> > > ironically. Still, my reply is written already :)
> >
> > No, I pointed it out in all seriousness. I was hoping the response would
> > be something like, "Oh, Spolsky's argument was demolished by Arglebargle
> > back in 1993. Go see http://..."
>
> I'm pretty sure some of the eXtreeeeeeeeeme programming people (and
> their less caffeinated pair-programming neighbors) have good
> rebuttals,
Can you cite an actual reference?
E.
·········@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@famine.OCF.Berkeley.EDU>,
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>
> > ·········@jpl.nasa.gov (Erann Gat) writes:
> >
> > > In article <····························@posting.google.com>,
> > > ······@funcall.org (Eugene Zaikonnikov) wrote:
> > >
> > > > P.S. It just occurred to me that you could be pointing at the article
> > > > ironically. Still, my reply is written already :)
> > >
> > > No, I pointed it out in all seriousness. I was hoping the response would
> > > be something like, "Oh, Spolsky's argument was demolished by Arglebargle
> > > back in 1993. Go see http://..."
> >
> > I'm pretty sure some of the eXtreeeeeeeeeme programming people (and
> > their less caffeinated pair-programming neighbors) have good
> > rebuttals,
>
> Can you cite an actual reference?
Take a look at Kent Beck's book _Test Driven Development_. He makes a
plausable case for developing in very tight incremental loops.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
In article <··············@javamonkey.com>, Peter Seibel
<·····@javamonkey.com> wrote:
> Take a look at Kent Beck's book _Test Driven Development_. He makes a
> plausable case for developing in very tight incremental loops.
and Pascal Costanza adds:
> The following books are excellent IMHO:
>
> + Kent Beck, Extreme Programming Explained
> + Alistair Cockburn, Agile Software Methodologies
> + Kent Beck and Martin Fowler, Planning Extreme Programming
Thanks! These sound like good leads.
E.
Erann Gat wrote:
>>I'm pretty sure some of the eXtreeeeeeeeeme programming people (and
>>their less caffeinated pair-programming neighbors) have good
>>rebuttals,
>
> Can you cite an actual reference?
The following books are excellent IMHO:
+ Kent Beck, Extreme Programming Explained
+ Alistair Cockburn, Agile Software Methodologies
+ Kent Beck and Martin Fowler, Planning Extreme Programming
An important element of XP is test-first development. They actually do
not suggest to just wildly code ahead, but they have a very strict
process to follow, much stricter than, say, RUP.
It essentially goes like this: You first write user stories, then break
them up into manageable tasks, then you write test cases, and then you
write the code that makes the test cases succeed.
So the test cases actually take over the role of specifications - they
exactly tell you what is needed.
Another important element is to do the most simple thing that actually
works.
A toy example is this: Imagine you have a small set of test cases.
(assert (= (f 2) 4))
(assert (= (f 5) 10))
(assert (= (f 7) 14))
It's reasonable to write the following code to make these tests succeed:
(defun f (x)
(ecase x
(2 4)
(5 10)
(7 14)))
In later iterations, several more test cases are added:
(assert (= (f 1) 2))
(assert (= (f 3) 6))
(assert (= (f 4) 8))
The rule of doing the simplest thing actually makes you think about a
simpler implementation which leads you to come up with this:
(defun f (x)
(* 2 x))
Again, this is a toy example. For more complex scenarios, it makes a lot
more sense. But it still illustrates the point that the resulting code
does not necessarily only cover the instances given in a test suite, but
rather will be as systematic as other code. However, in the end you will
have a rather large test suite which gives you much more confidence that
the code really works.
There are several more rules in XP that are to be followed. This is only
a sketch how XP works.
I have only shown the elements that argue against the widely held belief
that you need a detailed specification before you can program. The
counter argument is not to say that you don't need specifications, the
counter argument is that the specifications don't need to be static.
Test cases are "dynamic specifications".
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
> Another important element is to do the most simple thing that
> actually works.
This seems to resonage strongly with the Forth philosophy. Says
Charles Moore:
Do not put code in your program that might be used. Do not leave
hooks on which you can hang extensions. The things you might want
to do are infinite; that means that each has 0 probability of
realization. If you need an extension later, you can code it later
-- and probably do a better job than if you did it now. And if
someone else adds the extension, will he notice the hooks you left?
Will you document this aspect of your program?
There's probably more of this in "Thinking FORTH" if you can get your
hands on a copy.
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
* Erann Gat
| Can you cite an actual reference?
A quote from my all-time favorite TV series, [scrubs]:
Why don't you head down to the library and look it up in the New
England Journal of Who Gives a Rat's Ass?
--
Erik Naggum | Oslo, Norway 2004-028
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
In article <·······················@naggum.no>, Erik Naggum
<····@naggum.no> wrote:
> * Erann Gat
> | Can you cite an actual reference?
>
> A quote from my all-time favorite TV series, [scrubs]:
>
> Why don't you head down to the library and look it up in the New
> England Journal of Who Gives a Rat's Ass?
Because the burden of proof lies with the person making the claim.
E.
·········@jpl.nasa.gov (Erann Gat) writes:
> In article <·······················@naggum.no>, Erik Naggum
> <····@naggum.no> wrote:
>
> > * Erann Gat
> > | Can you cite an actual reference?
> >
> > A quote from my all-time favorite TV series, [scrubs]:
> >
> > Why don't you head down to the library and look it up in the New
> > England Journal of Who Gives a Rat's Ass?
>
> Because the burden of proof lies with the person making the claim.
Uh, the claim was, "I'm sure these people probably have some good
arguments you can cite." I was trying to helpfully point you in the
right direction; the quote Erik cited kind of sums up how I felt about
your response.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@famine.OCF.Berkeley.EDU>,
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> ·········@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <·······················@naggum.no>, Erik Naggum
> > <····@naggum.no> wrote:
> >
> > > * Erann Gat
> > > | Can you cite an actual reference?
> > >
> > > A quote from my all-time favorite TV series, [scrubs]:
> > >
> > > Why don't you head down to the library and look it up in the New
> > > England Journal of Who Gives a Rat's Ass?
> >
> > Because the burden of proof lies with the person making the claim.
>
> Uh, the claim was, "I'm sure these people probably have some good
> arguments you can cite." I was trying to helpfully point you in the
> right direction; the quote Erik cited kind of sums up how I felt about
> your response.
In that case I'll respond by saying that I'm pretty sure that there are no
XP papers in the publication that Erik mentions.
I am likewise fairly certain that there is an awful lot of XP literature,
and that much of it is not really on point. I could go slogging through
it (and maybe I will) but I thought you might know a good reference off
the top of your head and might be willing to take a minute to share it
with me. I thought you might care whether Lisp gets used in the Aerospace
industry, and that desire might motivate you (or someone around here) to
help me out. But you are certainly not obligated to.
I also would have hoped that you would have found a more polite way to
communicate your unwillingness to help further, but you are not obligated
to do that either.
But thanks for the suggestion.
E.
·········@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@famine.OCF.Berkeley.EDU>,
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>
> > ·········@jpl.nasa.gov (Erann Gat) writes:
> >
> > > In article <·······················@naggum.no>, Erik Naggum
> > > <····@naggum.no> wrote:
> > >
> > > > * Erann Gat
> > > > | Can you cite an actual reference?
> > > >
> > > > A quote from my all-time favorite TV series, [scrubs]:
> > > >
> > > > Why don't you head down to the library and look it up in the New
> > > > England Journal of Who Gives a Rat's Ass?
> > >
> > > Because the burden of proof lies with the person making the claim.
> >
> > Uh, the claim was, "I'm sure these people probably have some good
> > arguments you can cite." I was trying to helpfully point you in the
> > right direction; the quote Erik cited kind of sums up how I felt about
> > your response.
>
> In that case I'll respond by saying that I'm pretty sure that there are no
> XP papers in the publication that Erik mentions.
(Do TV shows count as publications?)
> I am likewise fairly certain that there is an awful lot of XP literature,
> and that much of it is not really on point. I could go slogging through
> it (and maybe I will) but I thought you might know a good reference off
> the top of your head and might be willing to take a minute to share it
> with me. I thought you might care whether Lisp gets used in the Aerospace
> industry, and that desire might motivate you (or someone around here) to
> help me out. But you are certainly not obligated to.
>
> I also would have hoped that you would have found a more polite way to
> communicate your unwillingness to help further
Well, no, I'm not willing to slog through the XP/Agile stuff for the
references you want. I merely brought it up as a starting point, and
it was followed up on by others more familiar with the area, which is
what I was hoping for. I meant to, and probably would, have left your
comment alone, but Erik's post tickled my funny bone; that's the thing
about usenet, it's a semi-professional forum, but it's *only* a
semi-professional one.
> But thanks for the suggestion.
You're welcome (I did mean it helpfully), and good luck with your Lisp
advocacy endeavors. Personally, I could give 1/2 a rat's ass about
space (goddamn if we spent 1/2 what we do on aerospace on biotech!),
but your overfunded profession is highly regarded :-/
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@famine.OCF.Berkeley.EDU>,
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> (Do TV shows count as publications?)
They can. 60 Minutes, or Frontline for example. But not Scrubs.
> Well, no, I'm not willing to slog through the XP/Agile stuff for the
> references you want.
And I wouldn't expect you to. I thought that since you suggested it you
might know some off the top of your head. A perfectly acceptable answer
to my question would have been, "Not off the top of my head, sorry." Or
simply to not respond would have been OK too.
> I merely brought it up as a starting point, and
> it was followed up on by others more familiar with the area, which is
> what I was hoping for. I meant to, and probably would, have left your
> comment alone, but Erik's post tickled my funny bone; that's the thing
> about usenet, it's a semi-professional forum, but it's *only* a
> semi-professional one.
No worries.
> > But thanks for the suggestion.
>
> You're welcome (I did mean it helpfully)
I know.
> and good luck with your Lisp advocacy endeavors.
Thanks.
> Personally, I could give 1/2 a rat's ass about
> space (goddamn if we spent 1/2 what we do on aerospace on biotech!),
> but your overfunded profession is highly regarded :-/
I appreciate your candor. If you're not already reading it I recommend
Rand Simberg's blog. You'll probably enjoy it.
E.
·········@jpl.nasa.gov (Erann Gat) wrote in message news:<··························@192.168.1.51>...
> I am likewise fairly certain that there is an awful lot of XP literature,
> and that much of it is not really on point. I could go slogging through
> it (and maybe I will)
There isn't as much as you'd think. Ever read that much-reviled
_Decline and Fall of the American Programmer_? In it he explains how
someone with a new methodology must "play the game" in order for it to
gain acceptance. Saturate the market with books 'n lectures, etc...
In fact, the XP books often contain illustrations of people's faces,
which is important for many managers.
The main point is that tools have lowered the cost of change, so you
don't need to get requirements and architecture 100% right the first
time. If you look at something like the Waterfall, it assumes that
making errors in requirements or architecture are so prohibitively
expensive, it affects the entire shape of the methodology. Once you
relax this assumption, you'll want a completely different approach.
XP, one of the Agile methodologies, advocates a bunch of practices
that individually may be flawed, but taken together bolster each
other. Really for small or medium-sized projects; XP is not the Agile
approach you want for more than 20 people. [
http://www.martinfowler.com/articles/newMethodology.html#N4003C0 ]
If you're presenting these methodologies to your org, there are many
resources out there for doing this, with rebuttals to common
critcisms. The principal people like Kent Beck haunt various
forums...
> I am likewise fairly certain that there is an awful lot of XP literature,
> and that much of it is not really on point. I could go slogging through
> it (and maybe I will) but I thought you might know a good reference off
> the top of your head and might be willing to take a minute to share it
> with me. I thought you might care whether Lisp gets used in the Aerospace
> industry, and that desire might motivate you (or someone around here) to
> help me out. But you are certainly not obligated to.
Look at what you're writing. Why are you laying on a guilt trip? You
are acting in a manner that suggests you have various pressures, not
all of which concern this subject.
·········@jpl.nasa.gov (Erann Gat) writes:
> In article <·······················@naggum.no>, Erik Naggum
> <····@naggum.no> wrote:
>
> > * Erann Gat
> > | Can you cite an actual reference?
> >
> > A quote from my all-time favorite TV series, [scrubs]:
> >
> > Why don't you head down to the library and look it up in the New
> > England Journal of Who Gives a Rat's Ass?
>
> Because the burden of proof lies with the person making the claim.
Not always. This might be so in a theoretical world where everybody
is talking in formal proofs. In the real world, however, there is
also some responsibility on the side of the reader to try to make
sense of and prove himself what other people are saying. Just
demanding formal proofs from others while never delivering any
yourself is what's generally called �passive aggressiveness�, at best.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID #xEEFBA4AF
In article <··············@darkstar.cartan.de>, ···@cartan.de
(=?iso-8859-1?q?Nils_G=F6sche?=) wrote:
> ·········@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <·······················@naggum.no>, Erik Naggum
> > <····@naggum.no> wrote:
> >
> > > * Erann Gat
> > > | Can you cite an actual reference?
> > >
> > > A quote from my all-time favorite TV series, [scrubs]:
> > >
> > > Why don't you head down to the library and look it up in the New
> > > England Journal of Who Gives a Rat's Ass?
> >
> > Because the burden of proof lies with the person making the claim.
>
> Not always. This might be so in a theoretical world where everybody
> is talking in formal proofs. In the real world, however, there is
> also some responsibility on the side of the reader to try to make
> sense of and prove himself what other people are saying. Just
> demanding formal proofs from others while never delivering any
> yourself is what's generally called �passive aggressiveness�, at best.
That's true, but it's a non-sequitur, since I never demanded anything from
anyone, let alone a formal proof. All I did was ask a question.
Furthermore, I have often responded to questions similar to the one I
asked, so I think your armchair psychoanalysis is more than a little
unfair.
E.
·········@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@famine.OCF.Berkeley.EDU>,
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>
>> ·········@jpl.nasa.gov (Erann Gat) writes:
>>
>> > No, I pointed it out in all seriousness. I was hoping the response would
>> > be something like, "Oh, Spolsky's argument was demolished by Arglebargle
>> > back in 1993. Go see http://..."
>>
>> I'm pretty sure some of the eXtreeeeeeeeeme programming people (and
>> their less caffeinated pair-programming neighbors) have good
>> rebuttals,
>
> Can you cite an actual reference?
Well, as a self-professed eXtreeeeeeeeeme programming person
(i.e. who did a real project with that methodology), and one
who also did a project with BDUF, I can tell you I'm never
doing BDUF again.
As for Spolsky's article, I read it, and I think it's either:
* hopelessly misguided (harsh reading), or
* trite (i.e. if his definition of "Functional Spec" just
means "a user story"). In that case, it didn't take 3
pages to say it's a good idea to write down what you'd
like the system to do before you do it.
I can't even _imagine_ how Lisp being flexible and good at
exploratory programming is supposed to be an impediment here.
I've found the nature of lisp a great help in refactoring
and changing (often quite radically) the underlying design/metaphor
of our software, when it proved necessary. In many other languages,
at that point, we would have needed a rewrite.
I hope an actualy _data point_ by a practitioner is at
least as good as an academic reference?
In article <··············@memetrics.com>, Alain Picard
<············@memetrics.com> wrote:
> I can't even _imagine_ how Lisp being flexible and good at
> exploratory programming is supposed to be an impediment here.
Neither can I. But the fact of the matter is that many people think it
does, and so in certain arenas (notably the one I'm playing in) that view
cannot simply be dismissed even if it is wrong.
> I hope an actualy _data point_ by a practitioner is at
> least as good as an academic reference?
It would be, but you haven't provided one. What you have provided is, at
best, an anecdote. Anecdotes can help too, but real data points are
better (but much harder to come by).
E.
·········@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@memetrics.com>, Alain Picard
> <············@memetrics.com> wrote:
>
>> I hope an actualy _data point_ by a practitioner is at
>> least as good as an academic reference?
>
> It would be, but you haven't provided one. What you have provided is, at
> best, an anecdote. Anecdotes can help too, but real data points are
> better (but much harder to come by).
>
Does it make it a data point if I say that in 12 man years we
developed a significantly more complex system in Lisp/XP than we did
in 45 man years in C++/BDUP?
Or is that still just anectodal? What exactly would I have to do
to make this a data point? Sign an affidavid that it happened?
Provide a list of witnesses? Now I'm curious. :-)
In article <··············@memetrics.com>, Alain Picard
<············@memetrics.com> wrote:
> ·········@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <··············@memetrics.com>, Alain Picard
> > <············@memetrics.com> wrote:
> >
> >> I hope an actualy _data point_ by a practitioner is at
> >> least as good as an academic reference?
> >
> > It would be, but you haven't provided one. What you have provided is, at
> > best, an anecdote. Anecdotes can help too, but real data points are
> > better (but much harder to come by).
> >
>
> Does it make it a data point if I say that in 12 man years we
> developed a significantly more complex system in Lisp/XP than we did
> in 45 man years in C++/BDUP?
That helps.
The line between an anecdote and a data point is fuzzy, but the general
rule is that if it's published (and usenet doesn't count) it's considered
a data point. In certain circles it's not a data point unless it can be
shown to be a statistically significant result. I personally subscribe to
this latter view, but fortunately most of the people I need to convince
don't.
E.
·········@jpl.nasa.gov (Erann Gat) writes:
> The line between an anecdote and a data point is fuzzy, but the general
> rule is that if it's published (and usenet doesn't count) it's considered
> a data point. In certain circles it's not a data point unless it can be
> shown to be a statistically significant result. I personally subscribe to
> this latter view, but fortunately most of the people I need to convince
> don't.
At http://www.idiom.com/~zilla/Work/Softestim/softestim.html
J.P.Lewis writes:
Evidently the prize for software disasters goes to the FAA's Advanced
Automation System (AAS), an attempt at an improved air traffic control
system that ran into trouble in the early 90s after an estimated 6.5
billion was spent. The AAS has been described as as "one of the
largest and most spectacular computing failures in the history of the
field."
R.Britcher, one of the software engineers involved in the AAS project,
describes it in the book The Limits of Software (Addison
Wesley). Britcher himself characterizes the AAS as
"The greatest debacle in the history of organized work... we
learned nothing from it"
The book is thoughtful and is a good read.
Importantly, the AAS project did make use of software engineering best
practices, such as code inspections, schedule estimates, etc. The
software was estimated to be on schedule each and every month... until
one month before it was to be delivered. Only at this point did it
become evident that the project was hopelessly late.
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
> ·········@jpl.nasa.gov (Erann Gat) writes:
>
> > The line between an anecdote and a data point is fuzzy, but the general
> > rule is that if it's published (and usenet doesn't count) it's considered
> > a data point. In certain circles it's not a data point unless it can be
> > shown to be a statistically significant result. I personally subscribe to
> > this latter view, but fortunately most of the people I need to convince
> > don't.
>
> At http://www.idiom.com/~zilla/Work/Softestim/softestim.html
> J.P.Lewis writes:
>
> Evidently the prize for software disasters goes to the FAA's Advanced
> Automation System (AAS), an attempt at an improved air traffic control
> system that ran into trouble in the early 90s after an estimated 6.5
> billion was spent. The AAS has been described as as "one of the
> largest and most spectacular computing failures in the history of the
> field."
>
> R.Britcher, one of the software engineers involved in the AAS project,
> describes it in the book The Limits of Software (Addison
> Wesley). Britcher himself characterizes the AAS as
>
> "The greatest debacle in the history of organized work... we
> learned nothing from it"
>
> The book is thoughtful and is a good read.
>
> Importantly, the AAS project did make use of software engineering best
> practices, such as code inspections, schedule estimates, etc. The
> software was estimated to be on schedule each and every month... until
> one month before it was to be delivered. Only at this point did it
> become evident that the project was hopelessly late.
Perfect! Just what I needed! Thank you!
E.
Alain Picard wrote:
>
> ·········@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <··············@memetrics.com>, Alain Picard
> > <············@memetrics.com> wrote:
> >
> >> I hope an actualy _data point_ by a practitioner is at
> >> least as good as an academic reference?
> >
> > It would be, but you haven't provided one. What you have provided is, at
> > best, an anecdote. Anecdotes can help too, but real data points are
> > better (but much harder to come by).
> >
>
> Does it make it a data point if I say that in 12 man years we
> developed a significantly more complex system in Lisp/XP than we did
> in 45 man years in C++/BDUP?
>
> Or is that still just anectodal? What exactly would I have to do
> to make this a data point?
Change 12 to 11.87, 45 to 45.26, and make up a number for "significantly
more complex". I always like to use "5" for that.
kenny
--
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Kenny Tilton <·······@nyc.rr.com> writes:
> > Or is that still just anectodal? What exactly would I have to do
> > to make this a data point?
>
> Change 12 to 11.87, 45 to 45.26, and make up a number for "significantly
> more complex". I always like to use "5" for that.
Shhh! If you give away the secrets, people like my brother will have
a harder time picking the scientifically useful points apart from the
garbage ones! (Oh wait, they're pretty good with the junky ones, too,
nevermind, carry on. Especially keep using "5" and ".5". :-)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
"Thomas F. Burdick" <···@famine.OCF.Berkeley.EDU> wrote
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > > Or is that still just anectodal? What exactly would I have to do
> > > to make this a data point?
> >
> > Change 12 to 11.87, 45 to 45.26, and make up a number for "significantly
> > more complex". I always like to use "5" for that.
>
> Shhh! If you give away the secrets, people like my brother will have
> a harder time picking the scientifically useful points apart from the
> garbage ones! (Oh wait, they're pretty good with the junky ones, too,
> nevermind, carry on. Especially keep using "5" and ".5". :-)
IIRC There are statistics from the IRS that show that when people generate
fake numbers in their declarations they have a huge bias toward ending them
with a 5.
Kenny should use #'random instead... ;-)
Marc
"Marc Battyani" <·············@fractalconcept.com> wrote in message
···············@library2.airnews.net...
>
> "Thomas F. Burdick" <···@famine.OCF.Berkeley.EDU> wrote
> > Kenny Tilton <·······@nyc.rr.com> writes:
...
> > (Oh wait, they're pretty good with the junky ones, too,
> > nevermind, carry on. Especially keep using "5" and ".5". :-)
>
> IIRC There are statistics from the IRS that show that when people generate
> fake numbers in their declarations they have a huge bias toward ending
them
> with a 5.
>
> Kenny should use #'random instead... ;-)
>
> Marc
Not according to Benford:
http://mathworld.wolfram.com/BenfordsLaw.html
Note especially the reference at the bottom to:
Nigrini, M. "A Taxpayer Compliance Application of Benford's Law." J. Amer.
Tax. Assoc. 18, 72-91, 1996.
and:
http://www.nigrini.com/
in which he discusses his work in forensic accounting. Kenny should use
#'benford instead of #'random.
"Marc Battyani" <·············@fractalconcept.com> writes:
> "Thomas F. Burdick" <···@famine.OCF.Berkeley.EDU> wrote
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> > > > Or is that still just anectodal? What exactly would I have to do
> > > > to make this a data point?
> > >
> > > Change 12 to 11.87, 45 to 45.26, and make up a number for "significantly
> > > more complex". I always like to use "5" for that.
> >
> > Shhh! If you give away the secrets, people like my brother will have
> > a harder time picking the scientifically useful points apart from the
> > garbage ones! (Oh wait, they're pretty good with the junky ones, too,
> > nevermind, carry on. Especially keep using "5" and ".5". :-)
>
> IIRC There are statistics from the IRS that show that when people generate
> fake numbers in their declarations they have a huge bias toward ending them
> with a 5.
>
> Kenny should use #'random instead... ;-)
No random would be wrong too. You'd have to choose a number that
would keep the natural proportions (where there are much more 1 than
2, and more 2 than 3, etc).
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
·········@jpl.nasa.gov (Erann Gat) writes:
> No, I pointed it out in all seriousness. I was hoping the response would
> be something like, "Oh, Spolsky's argument was demolished by Arglebargle
> back in 1993. Go see http://..."
I'm afraid my immediate reaction was ``Who the hell is Spolsky, and
who elected him God?''
There are huge and obvious holes in his argument, and I can see no
reason why anyone should have made the effort to point them out. His
argument is fine for `commodity software', such as
yet-another-database-query-form, but they are clearly bogus when
you're not sure what direction you are going in the first place.
This is usually the situation in research.
Making a `specification' for solving problems when you haven't the
slightest idea if it is going to work is simply mental masturbation.
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
> ·········@jpl.nasa.gov (Erann Gat) writes:
>
> > No, I pointed it out in all seriousness. I was hoping the response would
> > be something like, "Oh, Spolsky's argument was demolished by Arglebargle
> > back in 1993. Go see http://..."
>
> I'm afraid my immediate reaction was ``Who the hell is Spolsky, and
> who elected him God?''
No one elected him God. But a lot of people read his blog, and he is
cited regularly on slashdot. So his views are influential.
> There are huge and obvious holes in his argument
Can you cite a reference that describes these huge and obvious holes?
> and I can see no
> reason why anyone should have made the effort to point them out.
If one cared about Lisp's economic viability one might wish to provide a
counterpoint to Spolsky in order to answer the objection that (one of)
Lisp's primary advantage(s), the ability to write software that is easy to
change, is (or at least invites) "the single biggest unnecessary risk you
take in a software project."
> His
> argument is fine for `commodity software', such as
> yet-another-database-query-form, but they are clearly bogus when
> you're not sure what direction you are going in the first place.
> This is usually the situation in research.
Actually, one can make the argument that it's a Bad Idea in research as
well. In science at least most progress comes about as the result of
testing well formulated hypotheses by carefully designed experiments, not
through random exploration. In fact, one might argue that the failure of
the original AI program (in the sense of research program, not computer
program) was due precisely to the fact that it was conducted in a
freewheeling exploratory style, without the discipline or rigor of the
normal process of science.
> Making a `specification' for solving problems when you haven't the
> slightest idea if it is going to work is simply mental masturbation.
And writing code under those same circumstances isn't?
E.
·········@jpl.nasa.gov (Erann Gat) writes:
> In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
>
>> ·········@jpl.nasa.gov (Erann Gat) writes:
>>
>> > No, I pointed it out in all seriousness. I was hoping the response would
>> > be something like, "Oh, Spolsky's argument was demolished by Arglebargle
>> > back in 1993. Go see http://..."
>>
>> I'm afraid my immediate reaction was ``Who the hell is Spolsky, and
>> who elected him God?''
>
> No one elected him God. But a lot of people read his blog, and he is
> cited regularly on slashdot. So his views are influential.
>
>
>> There are huge and obvious holes in his argument
>
> Can you cite a reference that describes these huge and obvious holes?
Not off the top of my head. I'll give it some thought.
> If one cared about Lisp's economic viability one might wish to provide a
> counterpoint to Spolsky in order to answer the objection that (one of)
> Lisp's primary advantage(s), the ability to write software that is easy to
> change, is (or at least invites) "the single biggest unnecessary risk you
> take in a software project."
Let me get this straight.
One of Lisp's strongest points is that it makes it very easy to
change software.
Spolsky argues that this ability is or invites the lions share of
unnecessary risk.
I'll give this some thought, too.
> Actually, one can make the argument that it's a Bad Idea in research as
> well. In science at least most progress comes about as the result of
> testing well formulated hypotheses by carefully designed experiments, not
> through random exploration.
There are *many* people that would argue against you on this!
You must be familiar with Isaac Asimov's quote:
The most exciting phrase to hear in science, the one that heralds
the most new discoveries, is not "Eureka!" but "That's funny..."
>> Making a `specification' for solving problems when you haven't the
>> slightest idea if it is going to work is simply mental masturbation.
>
> And writing code under those same circumstances isn't?
I don't think so. It is easy to write a specification that is
unrealizable. How do you prove the specification solves the problem?
A piece of code that works is proof that the problem is solvable.
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
> Let me get this straight.
>
> One of Lisp's strongest points is that it makes it very easy to
> change software.
>
> Spolsky argues that this ability is or invites the lions share of
> unnecessary risk.
Yes, exactly.
>
> I'll give this some thought, too.
Good.
>
> > Actually, one can make the argument that it's a Bad Idea in research as
> > well. In science at least most progress comes about as the result of
> > testing well formulated hypotheses by carefully designed experiments, not
> > through random exploration.
>
> There are *many* people that would argue against you on this!
>
> You must be familiar with Isaac Asimov's quote:
>
> The most exciting phrase to hear in science, the one that heralds
> the most new discoveries, is not "Eureka!" but "That's funny..."
Yes, but you can only know that something is "funny" if you have some
expectations to compare it against. Penzias and Wilson's discovery of the
cosmic background radiation was a "that's funny" sort of discovery, but
they weren't playing around randomly, they were trying to accomplish
something very specific according to a definite plan. Granted, what they
ended up accomplishing had nothing to do with their initial plan, but that
doesn't change the fact that they had a plan. Moreover, they would not
have accomplished what they did without the plan because it was only that
plan that lead them to recognize that the noise they were hearing was
"funny".
> >> Making a `specification' for solving problems when you haven't the
> >> slightest idea if it is going to work is simply mental masturbation.
> >
> > And writing code under those same circumstances isn't?
>
> I don't think so. It is easy to write a specification that is
> unrealizable.
Just as it is easy to write code that doesn't work.
> How do you prove the specification solves the problem?
How do you prove the code solves the problem? (And if your answer to this
is, "test it" then my response is: testing only proves that it solves an
instance of the problem. It does not prove it solves the problem.)
> A piece of code that works is proof that the problem is solvable.
That's not generally true because it depends on what you mean by "the
problem" and "works", but it doesn't matter because the topic at hand is
not whether one can produce working code without a spec. Clearly one
can. The issue is whether it's a good idea, whether it is more or less
effort to do it this way, or the end results are of higher or lower
quality.
(This is actually a pet peeve of mine regarding discussions about
software. People will often ask, "Can you do X using
method/technique/tool Y?" That is never the right question to ask because
the answer is always yes. The right question to ask is, "How much easier
is it to do X using Y than without using Y (or by using Z instead)?"
E.
·········@jpl.nasa.gov (Erann Gat) writes:
> In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
>> I'll give this some thought, too.
Here are my thoughts that address the particular question you first
raised: are there good, coherent, on-line rebuttals to Spolsky.
Joel Spolsky writes these comments:
``Failing to write a spec is the single biggest unnecessary risk you
take in a software project.''
Certainly there is a place for writing specifications, and although it
is a risk to write a large software project without a spec, it is not
the biggest risk.
Lorin May (in http://www.stsc.hill.af.mil/crosstalk/1998/07/causes.pdf)
identifies the main causes of software project failure as these:
Poor user input
Stakeholder conflicts
Vague requirements
Poor cost and schedule estimation
Skills that do not match the job
Hidden costs of going lean and mean
Failure to plan
Communications breakdowns
Poor architecture
Late failure warning signals
Some of these would be mitigated by having a proper spec, but many of
them occur whether you have a spec or not.
In http://www.cioupdate.com/reports/article.php/1563701
Carmine Mangione identifies an economic cause:
Organizations must consider the cost of adding features to a
product.
Under most software processes, the cost of changing software is not
linear, but exponential.
Software processes are designed to manage the cost of change.
Unless the product is shipped before the cost of change becomes
exponential, it will very likely fail.
He identifies these pitfalls:
Prototype Trap - Most developers intend to throw away a prototype
once it is completed and the resulting code quickly becomes
expensive to change.
4GL trap - The problem with 4GLs is that the code is very hard to
modify after it has been created. Choosing the wrong language will
ensure that the product will never ship.
Scripting trap - Most scripts are not maintainable or even readable
by those people who created them.
IDE trap - Companies do not design these tools to help developers,
but lock developers who use their IDE's into their platforms. In
the real world of changing requirements, platform restrictions are
often deadly.
Reengineering trap - Reengineering almost always fails because the
existing code cannot be easily changed because the cost of change
is exponential. If the cost of change was not exponential, there
would be no reason to reengineer.
Clearly, Mangione believes that making change easier and less
expensive is the key to profit.
The Standish Group notes these facts:
http://www.standishgroup.com/sample_research/chaos_1994_1.php
In the larger companies ... only 9% of their projects come in
on-time and on-budget. And, even when these projects are
completed, many are no more than a mere shadow of their original
specification requirements. Projects completed by the largest
American companies have only approximately 42% of the
originally-proposed features and functions.
http://www.pmboulevard.com/expert_column/archives/reg/project_failures_roetzheim.pdf
William Roetzheim writes ``Project Planning as the Root of All Evil''
``A key assumption here is that the corporation has any idea of
what its norm is for the project parameters.''
The plan is a complete work of fantasy.
Spolsky contradicts himself in these two paragraphs:
A functional specification describes how a product will work entirely
from the user's perspective. It doesn't care how the thing is
implemented. It talks about features. It specifies screens, menus,
dialogs, and so on.
The most important function of a spec is to design the program. The
act of writing the spec -- describing how the program works in minute
detail -- will force you to actually design the program.
As do these:
Giant reason number two is to save time communicating. When you write
a spec, you only have to communicate how the program is supposed to
work once.
My specs are updated frequently. The updating continues as the product
is developed and new decisions are made. The spec always reflects our
best collective understanding of how the product is going to work.
Spolsky states: ``Number three giant important reason to have a spec
is that without a detailed spec, it's impossible to make a schedule.''
Well, you cannot make a schedule without a calendar, either, but we
shouldn't elevate the calendar to the level of `make or break' status.
--
~jrm
In article <············@comcast.net>, Joe Marshall
<·············@comcast.net> wrote:
[A lot of good stuff]
Thanks for that response, Joe. That was very helpful.
E.
<non-sequitur>
P.S. Why prunesquallor, if I may ask?
</non-sequitur>
·········@jpl.nasa.gov (Erann Gat) writes:
> <non-sequitur>
> P.S. Why prunesquallor, if I may ask?
> </non-sequitur>
Albert (or Bernard?) Prunesquallor is one of the main characters in
``Gormenghast'', a novel by Mervyn Peak. He comes across as a bit of
a silly ass, but he's one of the few characters in the novel
perceptive enough to realize the presence of evil.
``Gormenghast'' is a very strange, but well-written story. ``It's
Dickens on crack.'' (observation by John Sessions) There are three
books in the series; Peak planned five, but did not finish them before
his death. Unfortunately, the third book in the series does not hold
up against the first two.
When I needed a new email address for home, rather than choose a
boring old gensym like `marshall226' I wanted something unique and
memorable. I figured that prunesquallor was uncommon enough a name
that I might just get it.
--
~jrm
Erann Gat wrote:
>>A piece of code that works is proof that the problem is solvable.
>
> That's not generally true because it depends on what you mean by "the
> problem" and "works", but it doesn't matter because the topic at hand is
> not whether one can produce working code without a spec. Clearly one
> can. The issue is whether it's a good idea, whether it is more or less
> effort to do it this way, or the end results are of higher or lower
> quality.
What about putting it like this: It's a waste of resources not to use a
computer to check assumptions / proposed ideas for solutions as early as
possible.
Then you could ask people what an ideal system for automatically
checking ideas should look like.
In fact, I think this could be a good survey to be carried out without
pushing for Lisp upfront.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
In article <···········@newsreader2.netcologne.de>, Pascal Costanza
<········@web.de> wrote:
> Erann Gat wrote:
>
> >>A piece of code that works is proof that the problem is solvable.
> >
> > That's not generally true because it depends on what you mean by "the
> > problem" and "works", but it doesn't matter because the topic at hand is
> > not whether one can produce working code without a spec. Clearly one
> > can. The issue is whether it's a good idea, whether it is more or less
> > effort to do it this way, or the end results are of higher or lower
> > quality.
>
> What about putting it like this: It's a waste of resources not to use a
> computer to check assumptions / proposed ideas for solutions as early as
> possible.
Much better. I will add that to my rhetorical arsenal. Thanks!
(BTW, I really liked your earlier exmaple about working on one method of a
multiple-method interface in Java. I wish you'd turn that into a paper.
I'd be happy to help if you don't have time to do it.)
> Then you could ask people what an ideal system for automatically
> checking ideas should look like.
OK, I'll bite: what should an ideal system for automatically checking
ideas look like?
> In fact, I think this could be a good survey to be carried out without
> pushing for Lisp upfront.
The contemporary answer around here (since we hired Gerard Holzmann) is:
proof checkers (which nowadays are all written in C++, and take C/C++ code
as input).
E.
·········@jpl.nasa.gov (Erann Gat) writes:
> Yes, but you can only know that something is "funny" if you have some
> expectations to compare it against.
The expectation is that the program will help the user get their job
done faster, more consistently, and/or more easily.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
"Joe Marshall" <···@ccs.neu.edu> wrote in message
·················@ccs.neu.edu...
> I don't think so. It is easy to write a specification that is
> unrealizable. How do you prove the specification solves the problem?
> A piece of code that works is proof that the problem is solvable.
Putting notes on a page does not music make.
Regards,
Will Hartung
(·····@msoft.com)
In article <··························@k-137-79-50-101.jpl.nasa.gov>,
Erann Gat <·········@jpl.nasa.gov> wrote:
>In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
>
>> ·········@jpl.nasa.gov (Erann Gat) writes:
>>
>> > No, I pointed it out in all seriousness. I was hoping the response would
>> > be something like, "Oh, Spolsky's argument was demolished by Arglebargle
>> > back in 1993. Go see http://..."
>>
>> I'm afraid my immediate reaction was ``Who the hell is Spolsky, and
>> who elected him God?''
>
>No one elected him God. But a lot of people read his blog, and he is
>cited regularly on slashdot. So his views are influential.
To quote the immortal 'Jesse Garon;'
"Many people have webpages."
>> There are huge and obvious holes in his argument
>
>Can you cite a reference that describes these huge and obvious holes?
Spolsky seems to be confounding writing a spec with top-down design in
his article. Writing down what you want your code to do in detail doesn't
seem like a horrible idea in most cases (though I can think of cases in
which it IS a bad idea). But "how it is supposed to do it" is another
story.
If your shop does OO or imperative design, and has between 10 and 500
coders working on something for Yoyodyne or MegaSoft, 'top down' might be
a good idea. It might be the only conceivable way of getting anything
done, despite the fact that you'll be sitting in specifications meetings
for weeks before doing any code writing.
If you're one to four guys working in the same boiler-room, this probably
isn't such a good idea. It's also a bad idea if you're doing something
truely new, and don't necessarily know how to get from point a to point b.
But in the latter case, deadlines are stupid anyway. I'm willing to bet "I
don't really know how to do this, though I think I can" is the source of
most deadline failures.
>> His
>> argument is fine for `commodity software', such as
>> yet-another-database-query-form, but they are clearly bogus when
>> you're not sure what direction you are going in the first place.
>> This is usually the situation in research.
>
>Actually, one can make the argument that it's a Bad Idea in research as
>well. In science at least most progress comes about as the result of
>testing well formulated hypotheses by carefully designed experiments, not
>through random exploration. In fact, one might argue that the failure of
>the original AI program (in the sense of research program, not computer
>program) was due precisely to the fact that it was conducted in a
>freewheeling exploratory style, without the discipline or rigor of the
>normal process of science.
AI isn't a science. Neither is computer science in general. Both are
vaguely like mathematics, with theorems, but without proofs (in general).
Despite the fact that the thing we call "a computer" pretty much sprung
fully formed from Von Neumann's brow after a few months of gestation in
1944 and 1945, everything else has been in fits and spurts, because we're
all a lot dumber than he was.
Things like relational databases, journaling file systems, the Macsyma
version of the Risch algorithm, multitasking OS and lisp itself seem to
have been invented in fits and starts and via a lot of noodling around.
Now that such things are standard, they should be easy for anyone to do
all over again (and, most software development *is* re-inventing the
wheel). But, practically speaking, a code-monkey may often be given a task
which he doesn't know how to do. And so he goes through similar (though
hopefully lesser) mental contortions, fits and spurts as the original
implementors of such ideas.
-Lupo
"A certain choleric vein gives zest and force to all acts....The best
work of the world is done in the tension between anger and control."
-G. Stanley Hall <··@io.com>
Erann Gat wrote:
>
> In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
>
> > Making a `specification' for solving problems when you haven't the
> > slightest idea if it is going to work is simply mental masturbation.
>
> And writing code under those same circumstances isn't?
Not quite. While both are descriptions of approaches to the problem,
with code, you can tell if it works. And every time it doesn't work,
you learn something about the problem from the exact way in which it
doesn't work.
Writing a specification won't direct your attention to the point in
the specification where you've made a wrong assumption about the problem.
Writing code is only a tiny bit more work than writing a spec, and
executing it certainly will direct your attention to the point in
the code where you made a wrong assumption. Code will force you to
discover things, while a spec will only force you to discover the
things you notice or anticipate.
"code" is just a name for a spec sufficiently detailed to let us
know if we're wrong in our assumptions. And if that's what we have
to find out, that's what we have to write.
Bear
Ray Dillinger <····@sonic.net> writes:
> Writing code is only a tiny bit more work than writing a spec, and
> executing it certainly will direct your attention to the point in
> the code where you made a wrong assumption. Code will force you to
> discover things, while a spec will only force you to discover the
> things you notice or anticipate.
I've noticed that it takes about as long to "draw" a screen by hand as
it does to mockup the screen using real code. I've also noticed that the
spec that contained these screen paintings often ignores many apsects
about how the app in question should behave and instead focuses on what
some specific case of some specific text field will look like. Also,
it's hard to distinguish between numbers on the screen whose
relationship is as shown and numbers that were just thrown up on the
screen. No one seems to care about the information, just about how it
looks. Then when they see that the information is wrong, they are
completely amazed at the fact that you didn't understand how they wanted
the screen to look. This seems to be the attitude in financial software
programming, at least, where the numbers are *extremely* important.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
·········@jpl.nasa.gov (Erann Gat) wrote in message news:<··························@k-137-79-50-101.jpl.nasa.gov>...
> In science at least most progress comes about as the result of
> testing well formulated hypotheses by carefully designed experiments, not
> through random exploration. <snip>
> the discipline or rigor of the normal process of science.
It looks like you don't have a background in scientific research.
Michele (who knows the difference between the plan he presented to
get funding and the research actually done)
Erann Gat wrote:
> If one cared about Lisp's economic viability one might wish to provide a
> counterpoint to Spolsky in order to answer the objection that (one of)
> Lisp's primary advantage(s), the ability to write software that is easy to
> change, is (or at least invites) "the single biggest unnecessary risk you
> take in a software project."
Sleeping is very dangerous: lots of people die in their sleep.
> > His
> > argument is fine for `commodity software', such as
> > yet-another-database-query-form, but they are clearly bogus when
> > you're not sure what direction you are going in the first place.
> > This is usually the situation in research.
>
> Actually, one can make the argument that it's a Bad Idea in research as
> well. In science at least most progress comes about as the result of
> testing well formulated hypotheses by carefully designed experiments, not
> through random exploration.
I don't think that's true at all. It doesn't seem to me to be
an accurate description of the origins of any of
- Newtonian mechanics
- Maxwell's equations
- special relativity
- general relativity
for instance. Maybe you can squeeze the birth of QM into that
framework, but I think it *is* a squeeze. The discovery that
atoms have nuclei fits in nicely, but (e.g.) the discovery of
X-rays certainly doesn't.
I've been concentrating on physics, because that's what
everyone thinks of when philosophizing about science :-).
But, e.g., the theory of evolution didn't arise from
"testing well formulated hypotheses by carefully designed
experiments", so it's not just physics to which your
description doesn't apply universally.
>> Making a `specification' for solving problems when you haven't the
>> slightest idea if it is going to work is simply mental masturbation.
>
> And writing code under those same circumstances isn't?
When dealing with an ill-understood problem, all you can do
is explore. Writing down a spec for one possible approach
may be a valuable form of exploration. Writing some code
may be, too. So many lots of other things. So I don't
accept Joe's claim that writing specs is necessarily
"mental masturbation" when you don't have a clue what
you're doing; it's one way of clarifying your ideas,
just like writing code is.
What writing code gives you that writing specs doesn't
is the ability to feed real data in and see what happens.
Perhaps infinitely intelligent people wouldn't need that;
they could just contemplate an algorithm and see in their
heads what it would do in practice. Those of us who are
cursed with finite minds have to try things out. Sometimes
we can predict things using (say) mathematics, but in
these days of scarily fast computers it can be much
quicker to try a few algorithms than to analyse them.
(The analysis may still need to be done -- but maybe
only on one algorithm, after trying many.)
--
Gareth McCaughan
.sig under construc
In article <··············@g.mccaughan.ntlworld.com>, Gareth McCaughan
<················@pobox.com> wrote:
> Erann Gat wrote:
>
> > If one cared about Lisp's economic viability one might wish to provide a
> > counterpoint to Spolsky in order to answer the objection that (one of)
> > Lisp's primary advantage(s), the ability to write software that is easy to
> > change, is (or at least invites) "the single biggest unnecessary risk you
> > take in a software project."
>
> Sleeping is very dangerous: lots of people die in their sleep.
Thanks. I'm sure that argument will carry a lot of weight at the next
software design meeting I go to.
> > > His
> > > argument is fine for `commodity software', such as
> > > yet-another-database-query-form, but they are clearly bogus when
> > > you're not sure what direction you are going in the first place.
> > > This is usually the situation in research.
> >
> > Actually, one can make the argument that it's a Bad Idea in research as
> > well. In science at least most progress comes about as the result of
> > testing well formulated hypotheses by carefully designed experiments, not
> > through random exploration.
>
> I don't think that's true at all. It doesn't seem to me to be
> an accurate description of the origins of any of
> - Newtonian mechanics
> - Maxwell's equations
> - special relativity
> - general relativity
> for instance.
> the theory of evolution
I think you could make a case that special relativity was the direct
result of the Michaelson-Morley experiment, which was designed to test a
well formulated hypothesis, to wit, the existence of the aether. But be
that as it may, how many examples can you come up with that are less than
90 years old? And how does that number compare to the total number of
scientific advances during that same period?
E.
·········@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@g.mccaughan.ntlworld.com>, Gareth McCaughan
> <················@pobox.com> wrote:
>>
>> Sleeping is very dangerous: lots of people die in their sleep.
>
> Thanks. I'm sure that argument will carry a lot of weight at the next
> software design meeting I go to.
It may not sway people towards your ideas, but it ought to keep them awake.
--
~jrm
In article <··························@192.168.1.51>,
Erann Gat <·········@jpl.nasa.gov> wrote:
>> > > His
>> > > argument is fine for `commodity software', such as
>> > > yet-another-database-query-form, but they are clearly bogus when
>> > > you're not sure what direction you are going in the first place.
>> > > This is usually the situation in research.
>> >
>> > Actually, one can make the argument that it's a Bad Idea in research as
>> > well. In science at least most progress comes about as the result of
>> > testing well formulated hypotheses by carefully designed experiments, not
>> > through random exploration.
>>
>> I don't think that's true at all. It doesn't seem to me to be
>> an accurate description of the origins of any of
>> - Newtonian mechanics
>> - Maxwell's equations
>> - special relativity
>> - general relativity
>> for instance.
>
>> the theory of evolution
>
>I think you could make a case that special relativity was the direct
>result of the Michaelson-Morley experiment, which was designed to test a
>well formulated hypothesis, to wit, the existence of the aether.
Einstein truely yanked Special Relativity from the aether himself. Lorentz
and Poincare had a lot of the math right, but it was up to Uncle Al to get
the *concept* right. Without him, we might still be thinking about
tensor theories of deformable ethers and such.
>But be
>that as it may, how many examples can you come up with that are less than
>90 years old? And how does that number compare to the total number of
>scientific advances during that same period?
My main complaint about science is that it that the sociology is such that
it prevents your doing anything but what your thesis advisor does. Of
course, this isn't always true, or humanity would never have had any of
the following interesting ideas:
1) Quantum computing
2) Loop quantum gravity
3) Quantum Chaology
4) The Gutzwiller Trace Formula
5) BCS theory
6) Atom trapping
7) Electroweak unification
8) Laughlin's theory of fractionally charged quasiparticles
blah blah blah
None of this stuff was particularly obvious, nor did they necessarily come
about via a theorem-hypothesis-experiment loop, excepting maybee the atom
trapping part. Most of it was discovered by accident.
It doesn't matter. Computer science isn't the same kind of science as
physics is.
-Lupo
"With three parameters, I can fit an elephant." -Lord Kelvin <··@io.com>
In article <······················@io.com>, ··@io.com (Lupo LeBoucher) wrote:
> Most of it was discovered by accident.
Yes, but not as a result of a blind search. Having a plan and having a
fortuitous accident are not mutually exclusive.
> It doesn't matter. Computer science isn't the same kind of science as
> physics is.
Yes, CS is (or perhaps it's better to say IMO ought to be considered) a
branch of psychology, or perhaps sociology. It's puzzling to me that this
is not more widely recognized: the human brain plays a significant role in
the creation of software, and yet the study of the creation of software
seems to completely ignore this obvious fact and focuses almost
exclusively on the behavior of machines. To quote Erik: puzzling this is.
E.
Erann Gat wrote:
>
> In article <······················@io.com>, ··@io.com (Lupo LeBoucher) wrote:
>
> > Most of it was discovered by accident.
>
> Yes, but not as a result of a blind search. Having a plan and having a
> fortuitous accident are not mutually exclusive.
>
> > It doesn't matter. Computer science isn't the same kind of science as
> > physics is.
>
> Yes, CS is (or perhaps it's better to say IMO ought to be considered) a
> branch of psychology, or perhaps sociology. It's puzzling to me that this
> is not more widely recognized: the human brain plays a significant role in
> the creation of software, and yet the study of the creation of software
> seems to completely ignore this obvious fact and focuses almost
> exclusively on the behavior of machines. To quote Erik: puzzling this is.
>
I actually see stronger parallels between computer programming and art
than computer programming and science. We often don't think of it, because
unlike "pure" arts, many programs have pragmatic value. But in coming up
with a good design, we are guided as much by aesthetics as by market analysis.
And coders who don't get paying work tend to implement things "because it
wasn't there", in a sort of reasoning similar to why mountain climers climb
mountains or why martial artists do katas.
Bear
Ray Dillinger <····@sonic.net> writes:
> I actually see stronger parallels between computer programming and art
ObLisp: Richard Gabriel has advocated awarding Master of Fine Arts
degrees in Software.
http://www.dreamsongs.com/MFASoftware.html
··@io.com (Lupo LeBoucher) writes:
> Einstein truely yanked Special Relativity from the aether himself. Lorentz
> and Poincare had a lot of the math right, but it was up to Uncle Al to get
> the *concept* right. Without him, we might still be thinking about
> tensor theories of deformable ethers and such.
Interestingly enough, it seems that Lorentz WAS right. He just didn't
have the right idea for what the ether is. If SR is right, then the GPS
is a monstrously complex system that relies on all kinds of correction
terms in the equations to work right. If LR is right, then the GPS is
rather simple and works right because of the laws of physics.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
"Joe Marshall" <···@ccs.neu.edu> wrote in message
·················@ccs.neu.edu...
> ·········@jpl.nasa.gov (Erann Gat) writes:
> There are huge and obvious holes in his argument, and I can see no
> reason why anyone should have made the effort to point them out. His
> argument is fine for `commodity software', such as
> yet-another-database-query-form, but they are clearly bogus when
> you're not sure what direction you are going in the first place.
> This is usually the situation in research.
Of course the detail is that a vast majority of modern software IS
"commodity software". Which is why the "glue objects together" paradigm is
so popular compared to the "start with blob of code, add other amorphous
blobs utill it looks like Application, bake". Legos vs sclupting.
Because of their market dynamics, the Lisp Vendors have never found the need
to come out with a set of Lisp Legos for Commodity Software. We basically
have at most a GUI builder.
Most commodity applications are 80-90% boiler plate, with a couple of parts
that are "hard", but rarely hard enough to warrant tossing out all of the
benefit the modern environments give to work the boiler plate problem. So,
you end up with some system beaten and contorted into submission to meet the
application demand, one or two chunks of ugly, difficult to maintain code,
with the knowledge etched into the head of the poor soul that made the
enivironment jump through its flaming hoops to get the job done.
So, Lisp has never really caught on in the Commodity Software arena, even
though at a base level it's more than qualified to do the work.
Then, since it never had its foot in the door in ye olde Client Server days,
it never made the leap into the modern realm of Application Servers and
Frameworks, as there was no demand from Commodity Software Client Server
Lisp clients to move their apps to the 3 tier model.
And, so, here we are.
Regards,
Will Hartung
(·····@msoft.com)
"Joe Marshall" <···@ccs.neu.edu> wrote in message
·················@ccs.neu.edu...
> ·········@jpl.nasa.gov (Erann Gat) writes:
>
> Making a `specification' for solving problems when you haven't the
> slightest idea if it is going to work is simply mental masturbation.
>
Or DARPA proposal writing ;-). They are big on metrics of evaluation and
conceptual frameworks that show your ideas will scale to larger/harder/more
real-time problems before they commit funding for you to go off and actually
develop them.
More to the point, has anyone put together an Eiffel-like way to incorporate
specifications and tests into the language itself? That would allow one to
simply point to the code as the spec in yet another sense (and if not
directly execute the spec (temporal modal logic interpreters
notwithstanding) at least provide appropriate unit-level testing and
guards).
"Gorbag" <·············@nospam.mac.com> writes:
> More to the point, has anyone put together an Eiffel-like way to incorporate
> specifications and tests into the language itself? That would allow one to
> simply point to the code as the spec in yet another sense (and if not
> directly execute the spec (temporal modal logic interpreters
> notwithstanding) at least provide appropriate unit-level testing and
> guards).
Something like <URL: http://www.gauss.muc.de/tools/dbc/dbc-intro.html >?
Regards,
'mr
--
[Emacs] is written in Lisp, which is the only computer language that is
beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_
·········@jpl.nasa.gov (Erann Gat) wrote in message news:<··························@k-137-79-50-101.jpl.nasa.gov>...
> In article <····························@posting.google.com>,
> ······@funcall.org (Eugene Zaikonnikov) wrote:
>
> > Spolsky advocates specification prior to the project, and it is hard
> > to disagree that a specification, where it can be rendered, is
> > desirable. Unfortunately, in unusual situations one often doesn't know
> > in advance how to approach the problem, or if the problem can be
> > solved at all. This takes quite some tinkering with data sets, problem
> > domain representations and algorithms to fiugre out, and Lisp is a
> > very fine tool at that.
>
> Yes, but should I conclude then that you believe that Lisp is only
> suitable in "unusual situations"?
>
No, you shouldn't. Lisp is as good at coding from spec as any
mainstream language, but notably better in unanticipated situations,
be it underspecification, misspecification, change of requirements or
code refactoring. I maintain that such situations are more frequent in
practice than in the Spolsky's toy example.
> > P.S. It just occurred to me that you could be pointing at the article
> > ironically. Still, my reply is written already :)
>
> No, I pointed it out in all seriousness. I was hoping the response would
> be something like, "Oh, Spolsky's argument was demolished by Arglebargle
> back in 1993. Go see http://..."
>
I think it all boils down to the old waterfall vs. iterative
development process debate, with plenty of good publications floating
around; see e.g. http://www.cdc-technologies.com/method/it_vs_wat.htm
Iterative approach assumes that changes into initial version of
specification at later stages of development are inevitable, which
means that the cost of change should be accounted for. Some of us find
that using Lisp makes that cost lower.
--
Eugene
Eugene Zaikonnikov <······@funcall.org> wrote:
> I think it all boils down to the old waterfall vs. iterative
> development process debate, with plenty of good publications floating
> around; see e.g. http://www.cdc-technologies.com/method/it_vs_wat.htm
*sigh* There are waterfalls and waterfalls. I find Royce's 1970 waterfall
quite nice, modern perhaps...
Royce, W.W., Managing the Development of Large-Scale Software:
Concepts and Techniques
Proceedings, Wescon, August 1970
(also reprinted in Proceedings, ICSE9)
It does include prototyping, involved customers, planned testing, etc.
It is sad it was forgotten, or then the early adopters didn't read past
figure one or two...
It's definitely a paper worth to find and read.
Jonne
Erann replied
> No, I pointed it out in all seriousness. I was hoping the
> response would be something like, "Oh, Spolsky's argument
> was demolished by Arglebargle back in 1993. Go see
> http://..."
Spolsky does not address the issue of where specifications
come from originally. He doesn't have to. His examples show
the context in which his advice lives. He is talking about
this dilemma:
You have a pretty clear idea in your head about what the
program should do. Should you set it down in prose, or
should you set it down in code?
His claim is that you should set it down in prose. He argues
that code is too rigid and expensive. You inevitably
discover that your idea was not as cleverly worked out in
your head as you had imagined. If you articulate your idea
in prose you can re-read your prose from a critical
distance, and rewrite it. If you articulate your idea in
code, the short comings will be more apparent than if you
had merely used prose, but alas, you find them too late,
your budget is already spent.
He is addressing the situation in which one is tempted to
plunge into coding the product, without writing a
specification, because one feels that one already knows what
the program is to do. His example is version 2 of an
existing program. If he was talking about version 1 he would
be talking about it being a particular company's first
version, not the first version in the world. Company A sells
software to frobnicate dongles. Company B notices that with
company A's software, it takes a user 3 weeks to frobnicate
a single dongle. Company B pounces on the business
opportunity of writing software to frobicate dongles in
pairs, in four weeks, ie two weeks a dongle.
Should the programmers in Company B plunge straight in to
coding their improved version, or should they "waste time"
writing a specification?
What happens if you face the opposite problem, that your
main obstacle is that you lack a clear idea of what your
program is to do? Currently you frobnicate dongles by
printing out the results of (analyse dongle), (explore
dongle), and (interpret dongle). Then you study the print
outs, and do something ad hoc. It is all very labour
intensive and expensive, and you feel that even partial
automation would save a lot of money. Should you attempt to
build an expert system to automate what you do when you
study the results? Should you build visualisation tools to
help you see what is going on more quickly? What is realistic?
You certainly need a plan. How many approaches are you going
to try. How many dongles are you going to try them on? How
wide a variety of dongles will your software deal with.
That last question "How wide a variety of dongles will your
software deal with?" is going to be the meat of a
specification in Spolsky's sense. You don't know the answer
to that question yet. Presumably you will chose to deal with
the range of variation coped with by the approach that deals
with the widest range of variation. Or maybe that approach
will prove to be over general and too slow for many
commercially important dongles. You will not know until you
have some actual timings.
A specification in Spolsky's sense is a reactive
document. You see the short comings of an existing piece of
software and react against that by specifying what it ought
to do instead.
Be alert to the limitations of language. If you have a truly
novel idea for a piece of software, you will find it
extremely difficult to explain your vision to other
persons. If you had prototype you could show them. Then they
would understand. Then you could write a specification:
Of course, it would report an error here instead of
crashing.
I'll just type this in. Obviously it will go in the
initialization file in the final version.
Let's have a coffee while we wait for this. Once I get the
caching sorted it will only take 2 or 3 seconds and be
quite suitable for interactive use.
Of course you need a specification. The usual causal
chain runs something like this
1)Think you don't need a specification.
2)Get into a quarrel with your boss, and end up being
ordered to write a specification.
3)Find that actually you are not ready to write a
specification, but you've lost that argument already so
write a bad one.
4)Do some exploratory coding
5)Lose the bad, and now obsolete, specification down the
back of the filing cabinet.
6)Segue into writing the final version, without reference
to the specification
7)Disaster.
The alternative:
1)Choose Lisp
2)Do some exploratory programming
3)Get something working early
4)Get ordered to write a specification, or else
5)Find that you can actually write a useful one, because
you have some running code to react against
6)Code to the specification, throwing away exploratory
code that doesn't fit. It wasn't too painful to write,
so its not too painful to throw it away.
7)Triumph
One could take the "cycle" in "product life cycle" seriously
n) type in some code to see what enhancements are feasible
n+1) type in some code to see what enhancements work well
n+2) type in some more code for user testing
n+3) write up a specification for the next version based
on the results of user testing with prototype code
n+4) code up the final version to meet the specification.
n+5) type in some code to see what problems with the old
version can be fixed
n+6) type in some code to see what fixes to problems in
the old version actually work well
n+7) type in some proposed fixes for user testing
You could say that the cycle runs n, n+1, n+2, n+3, n+4,
then back to n.
You could say that the cycle runs n+3, n+4, n+5, n+6, n+7,
then starts again at n+3. The cycle begins with the
specification if that is how you chose to draw the diagram.
Alan Crowe
Edinburgh
Scotland
······@funcall.org (Eugene Zaikonnikov) writes:
> ·········@jpl.nasa.gov (Erann Gat) wrote in message news:<··························@192.168.1.51>...
> > In article <·······················@naggum.no>, Erik Naggum
> > <····@naggum.no> wrote:
> >
> > > Common Lisp will always be there for programmers who need to work out
> > > the solution while coding and watching the computer work on the data.
> >
> > Joel Spolsky says this is (unconditionally) a bad idea. See
> > http://www.joelonsoftware.com/articles/fog0000000036.html.
> >
> Spolsky advocates specification prior to the project, and it is hard
> to disagree that a specification, where it can be rendered, is
> desirable. Unfortunately, in unusual situations one often doesn't know
> in advance how to approach the problem, or if the problem can be
> solved at all. This takes quite some tinkering with data sets, problem
> domain representations and algorithms to fiugre out, and Lisp is a
> very fine tool at that.
Also it seems to me that Spolsky is talking about _functional_ specs.
I'm certainly not going to discuss how I'm going to organize a
program's internal structure with the customer. What exactly the
program will do, yes, but not internals. The 'REPL exploration mode'
is more about the exploring the _design_ of the program.
> Or take for instance reverse engineering. What good is Joel's advice
> when you don't have a protocol or file format specification?
>
Great point.
Jock Cooper
--
http://www.fractal-recursions.com
"Eugene Zaikonnikov" <······@funcall.org> wrote in message
·································@posting.google.com...
> ·········@jpl.nasa.gov (Erann Gat) wrote in message
news:<··························@192.168.1.51>...
> > In article <·······················@naggum.no>, Erik Naggum
> > <····@naggum.no> wrote:
> >
> > > Common Lisp will always be there for programmers who need to work
out
> > > the solution while coding and watching the computer work on the
data.
> >
> > Joel Spolsky says this is (unconditionally) a bad idea. See
> > http://www.joelonsoftware.com/articles/fog0000000036.html.
> >
> Eugene
>
> P.S. It just occurred to me that you could be pointing at the article
> ironically. Still, my reply is written already :)
I tend to use Lisp more like one would use MAXIMA. I have a problem space I
wish
to explore to which there is no known solution. The problem may have a
specification,
but it is not possible to specify a solution until one is found.
I use lisp as a reasoning/solution tool in the search for a solution.
Static typing in this pursuit is of no interest to me. I already know that
the program is
wrong. Its probably using the completely wrong approach and algorithms (and
data structures).
Static typing is not going to help me find the correct ones.
Rene.
·········@jpl.nasa.gov (Erann Gat) wrote in message news:<··························@192.168.1.51>...
> In article <·······················@naggum.no>, Erik Naggum
> <····@naggum.no> wrote:
>
> > Common Lisp will always be there for programmers who need to work out
> > the solution while coding and watching the computer work on the data.
>
> Joel Spolsky says this is (unconditionally) a bad idea. See
> http://www.joelonsoftware.com/articles/fog0000000036.html.
Careful with making unconditional rules from Spolsky's analysis; he
likely cringes when people do that. He wrote:
"The moral of the story is that when you design your product in a
human language, it only takes a few minutes to try thinking about
several possibilities, revising, and improving your design. Nobody
feels bad when they delete a paragraph in a word processor. But when
you design your product in a programming language, it takes weeks to
do iterative designs."
Spec writing is a great device to stimulate thought. But it is not
the only such device.
He was probably focussing on the code-and-run mentality of some
coders. Also read his Five Worlds article:
http://www.joelonsoftware.com/articles/FiveWorlds.html
He explains that all gurus assume some context in their
pronouncements. Joel works in a team environment targetting primarily
Microsoft environments with highly restrictive static languages. No
wonder he doesn't want to lose that hard-won code; if you notice the
more Agile methodologies, they have a clear preference for dynamic
languages.
In article <····························@posting.google.com>,
···········@yahoo.com (Tayssir John Gabbour) wrote:
> ·········@jpl.nasa.gov (Erann Gat) wrote in message
news:<··························@192.168.1.51>...
> > In article <·······················@naggum.no>, Erik Naggum
> > <····@naggum.no> wrote:
> >
> > > Common Lisp will always be there for programmers who need to work out
> > > the solution while coding and watching the computer work on the data.
> >
> > Joel Spolsky says this is (unconditionally) a bad idea. See
> > http://www.joelonsoftware.com/articles/fog0000000036.html.
>
> Careful with making unconditional rules from Spolsky's analysis;
I don't. Spolsky does it himself. He writes:
"...failing to write a spec is the single biggest unnecessary risk you
take in a software project. It's as stupid as setting off to cross the
Mojave desert with just the clothes on your back, hoping to 'wing it.' "
Sounds pretty unequivocal to me.
So there are two possibilities:
1. He really meant it, or
2. There's a tacit disclaimer along the lines of, "Unless of course you
are properly equipped to do iterative development, e.g. if you're using
Lisp."
But in case 2 that just begs the question of why he didn't just come right
out and say so.
> Joel works in a team environment targetting primarily
> Microsoft environments with highly restrictive static languages.
Yes, but no one is holding a gun to their heads, and Allegro Common Lisp
runs on Windows. So the question of which way the causality runs is open:
does he advocate writing specs because he's using C++, or does he use C++
because he advocates writing specs?
E.
·········@jpl.nasa.gov (Erann Gat) writes:
> I don't. Spolsky does it himself. He writes:
>
> "...failing to write a spec is the single biggest unnecessary risk you
> take in a software project. It's as stupid as setting off to cross the
> Mojave desert with just the clothes on your back, hoping to 'wing it.' "
>
> Sounds pretty unequivocal to me.
Yep. How did he know that it was the Mojave desert, though?
It's all nice and well to say `plan ahead of time', and it is a great
idea *if you can do it*, but if you do not know the obstacles, how do
you plan for them?
Incidentally, it isn't feasible to just `assume that the desert is
bigger than what you currently see'. So we've prepared for the
desert, and we've crossed it without too much difficulty, and now
we're standing on the shores of Lake Powell. I assume someone thought
to bring a boat?
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
> ·········@jpl.nasa.gov (Erann Gat) writes:
>
> > I don't. Spolsky does it himself. He writes:
> >
> > "...failing to write a spec is the single biggest unnecessary risk you
> > take in a software project. It's as stupid as setting off to cross the
> > Mojave desert with just the clothes on your back, hoping to 'wing it.' "
> >
> > Sounds pretty unequivocal to me.
>
> Yep. How did he know that it was the Mojave desert, though?
Well, it's his metaphor.
> It's all nice and well to say `plan ahead of time', and it is a great
> idea *if you can do it*, but if you do not know the obstacles, how do
> you plan for them?
You can make some reasonable assumptions about the obstacles one is likely
to encounter. Columbus, for example, has precious little clue what he
would find, but he still didn't just jump into the ocean and start to
swim. Lewis and Clark didn't just walk out their front door with nothing
but a walking stick. This "zero knowledge" hypothesis is a straw man.
You always know *something* about where you're going, even if you're just
going walkabout.
> Incidentally, it isn't feasible to just `assume that the desert is
> bigger than what you currently see'. So we've prepared for the
> desert, and we've crossed it without too much difficulty, and now
> we're standing on the shores of Lake Powell. I assume someone thought
> to bring a boat?
If your goal was to cross the dessert then you don't need a boat. By
arriving at Lake Powell you have achieved your goal.
On the other hand, if your goal was to reach the East Coast, and crossing
the Mojave is just a subgoal in service of that larger goal, then a boat
could be very handy. But it's best to think about that *before* you
strike out across the desert. It seems to me that this analogy supports
Spolsky's position.
E.
·········@jpl.nasa.gov (Erann Gat) writes:
> If your goal was to cross the dessert then you don't need a boat. By
> arriving at Lake Powell you have achieved your goal.
>
> On the other hand, if your goal was to reach the East Coast, and crossing
> the Mojave is just a subgoal in service of that larger goal, then a boat
> could be very handy. But it's best to think about that *before* you
> strike out across the desert. It seems to me that this analogy supports
> Spolsky's position.
Only with the assumption that both you and Spolksy are making: that
you have prior knowledge that there is a lake in the way.
I'm not saying `go out unprepared and wing it', I'm saying "The best
laid schemes o' Mice an' Men, Gang aft agley," (Burns).
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
> ·········@jpl.nasa.gov (Erann Gat) writes:
>
> > If your goal was to cross the dessert then you don't need a boat. By
> > arriving at Lake Powell you have achieved your goal.
> >
> > On the other hand, if your goal was to reach the East Coast, and crossing
> > the Mojave is just a subgoal in service of that larger goal, then a boat
> > could be very handy. But it's best to think about that *before* you
> > strike out across the desert. It seems to me that this analogy supports
> > Spolsky's position.
>
> Only with the assumption that both you and Spolksy are making: that
> you have prior knowledge that there is a lake in the way.
No, you're missing the point.
What Spolsky is saying is not that you should take a boat. He is saying
that you should *think* about whether or not to take a boat *before* you
strike out across the desert (i.e. begin to code), and that in fact you
should *write down* your decision and the rationale for it, e.g.:
"We're going to take a boat because our goal is to reach the East Coast
and we believe it is likely that we will encounter at least one unfordable
body of water along the way without enough resources nearby to be able to
fabricate a boat in situ."
or
"We're not going to take a boat because our goal is merely to cross the
desert, and the probability of encountering a long-lived and unfordable
body of water in the desert is low (since if we encounter such a body of
water we are ipso facto no longer in the desert)."
As opposed to, "Let's just start walking and if we hit a lake we'll figure
out what to do about it then."
> I'm not saying `go out unprepared and wing it', I'm saying "The best
> laid schemes o' Mice an' Men, Gang aft agley," (Burns).
"Plans are useless, but planning is indispensible." -- Dwight Eisenhower.
So: does Lisp help when plans gang agly? How? Is that help worth the
tradeoff of the additional risk that Spolsky warns about (assuming you
accept Spolsky's argument)? These are serious questions and I think we
(since I still count myself as a Lisp fan) would do well to come up with
cogent responses rather than just cavalierly dismiss them if we want to
see Lisp be a serious player in the software game and not just a toy for
noodling around.
E.
"Joe Marshall" <···@ccs.neu.edu> wrote in message
·················@ccs.neu.edu...
> ·········@jpl.nasa.gov (Erann Gat) writes:
> > On the other hand, if your goal was to reach the East Coast, and
crossing
> > the Mojave is just a subgoal in service of that larger goal, then a boat
> > could be very handy. But it's best to think about that *before* you
> > strike out across the desert. It seems to me that this analogy supports
> > Spolsky's position.
>
> Only with the assumption that both you and Spolksy are making: that
> you have prior knowledge that there is a lake in the way.
>
> I'm not saying `go out unprepared and wing it', I'm saying "The best
> laid schemes o' Mice an' Men, Gang aft agley," (Burns).
Seems to me that Spolksy's idea of a spec is pretty darn informal, at the
level of "let's design a portable PC on a napkin in a coffee shop" kind of
way.
"Crossing the desert" and "getting to the east coast" are two different,
though perhaps complementary, goals.
And, when trapped in the middle of the desert, you may be caught up in the
details of getting water from a cactus and need some reference to the "real"
goal, which can help you refocus your efforts appropriately.
While Lisp is particularly good for doing things when you're not sure HOW to
do it, it seems that Joels view is you should always have some semi-concrete
vision of WHAT you want to do.
Regards,
Will Hartung
(·····@msoft.com)
Will Hartung <·····@msoft.com> wrote:
+---------------
| "Crossing the desert" and "getting to the east coast" are two different,
| though perhaps complementary, goals.
|
| And, when trapped in the middle of the desert, you may be caught up in the
| details of getting water from a cactus and need some reference to the "real"
| goal, which can help you refocus your efforts appropriately.
+---------------
Ah, yezz... Which brings to mind the old aphorism:
When you're up to your ass in alligators, it's hard to remember
that your original intention was to drain the swamp.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Personally I use schemes for serialization in my apps that include the
type information as well as the data- sometimes S-expr, sometimes XML,
sometimes ASN.1 (depending on what else might want to use the data and
efficiency), so haven't got into a file conversion problem in the last
ten years.
Everything can be forward and backward compatible out the box once you
realize that it's the value that should have the type, not the slot.
Maybe that's why he doesn't mention lisp.
Pete
Erann Gat wrote:
> If your goal was to cross the dessert then you don't need a boat.
No indeed; a spoon will probably suffice.
--
Gareth McCaughan
.sig under construc
In article <··············@g.mccaughan.ntlworld.com>, Gareth McCaughan
<················@pobox.com> wrote:
> Erann Gat wrote:
>
> > If your goal was to cross the dessert then you don't need a boat.
>
> No indeed; a spoon will probably suffice.
You haven't seen my desserts. :-)
E.
·········@jpl.nasa.gov (Erann Gat) wrote in message news:<··························@k-137-79-50-101.jpl.nasa.gov>...
> So there are two possibilities:
http://www.joelonsoftware.com/news/20020320.html
"It's true. I get email from people on development teams who appear to
be in some kind of big fight over something, and they are hitting each
other over the head with various quotes from me, instead of thinking
for themselves, and now they want me to adjudicate, as if I know the
first thing about their problems or their world. I haven't yet written
the article that says that if you can't think for yourself, no amount
of "methodology" is going to save you."
Maybe we shouldn't pore over his writing as if it were the Talmud. I
get the impression you want a deep engineering debate, but this is a
guy who lets people peek into his company. Reality TV, not Oxford
debates. Sometimes reality TV is more enlightening, depends on what
you want to get out of it.
> Yes, but no one is holding a gun to their heads, and Allegro Common Lisp
> runs on Windows. So the question of which way the causality runs is open:
> does he advocate writing specs because he's using C++, or does he use C++
> because he advocates writing specs?
Why would he use Franz's lisp? That's an added dependency and
requires serious justification. I would be happy to bind my knowledge
to macros so it doesn't stay in my head, but he apparently has a good
deal of Microsoft expertise in long-term memory. So from his
perspective, he's just adding risk for questionable reward. He has
noted many times that environments like Delphi may be technically
better, but he doesn't know them as intimately as Microsoft's
environments and therefore doesn't bet his people on them.
Erann Gat wrote:
[initially quoting Joel Spolsky:]
> "...failing to write a spec is the single biggest unnecessary risk you
> take in a software project. It's as stupid as setting off to cross the
> Mojave desert with just the clothes on your back, hoping to 'wing it.' "
>
> Sounds pretty unequivocal to me.
>
> So there are two possibilities:
>
> 1. He really meant it, or
> 2. There's a tacit disclaimer along the lines of, "Unless of course you
> are properly equipped to do iterative development, e.g. if you're using
> Lisp."
>
> But in case 2 that just begs the question of why he didn't just come right
> out and say so.
One possible reason is that he doesn't have any experience of
using Lisp, or at least that he doesn't have enough to know
what it can do for you. So far as I can tell, his own programming
has all been in VB, C, and C++; the teams he's run have all been
using languages like those.
Another possible reason is that the actual tacit disclaimer
is more like "Provided you're writing the sort of stuff for
which writing specs is possible".
> > Joel works in a team environment targetting primarily
> > Microsoft environments with highly restrictive static languages.
>
> Yes, but no one is holding a gun to their heads, and Allegro Common Lisp
> runs on Windows. So the question of which way the causality runs is open:
> does he advocate writing specs because he's using C++, or does he use C++
> because he advocates writing specs?
Actually he mostly uses Visual Basic. Whether this raises or
lowers your respect for his opinions about good programming
practice is up to you :-).
*
This all seems a bit surreal to me, anyway. There's no inconsistency
between using Lisp and writing specs. For certain (unusual, for most
programmers) kinds of problem, writing specs may be much less helpful
than it generally is, and Lisp may be very effective in attacking some
such problems. That doesn't mean that you can't use it for other
things.
Programs written in Lisp are generally easier to change than
programs written in C++. That doesn't mean you *have* to go
changing them all the time. (It does mean that some of the costs
of change are lower, which means that some of the reasons for
writing specs in advance are weaker, which may or may not be
enough to make a suck-it-and-see approach better than a
first-write-your-spec approach in some cases.) It doesn't
mean you *can't* write a spec at the start. All it means
is that when you need to make changes (which you do, even
if there's a detailed spec from the outset and the requirements
never change and the spec was done *really* well) you can
make them more easily. How can that be bad?
--
Gareth McCaughan
.sig under construc
* Erik Naggum
> Common Lisp will always be there for programmers who need to work out
> the solution while coding and watching the computer work on the data.
* Erann Gat
> Joel Spolsky says this is (unconditionally) a bad idea.
In fact, he said no such thing, so I never fell for the obvious bait.
* Gareth McCaughan
| This all seems a bit surreal to me, anyway. There's no inconsistency
| between using Lisp and writing specs.
Precisely. Erann Gat equated what I said with �aimless hacking�, and
his bait only applies to such a surreal reading of what I wrote. Some
things have not changed in a year...
| Programs written in Lisp are generally easier to change than programs
| written in C++. That doesn't mean you *have* to go changing them all
| the time. (It does mean that some of the costs of change are lower,
| which means that some of the reasons for writing specs in advance are
| weaker, which may or may not be enough to make a suck-it-and-see
| approach better than a first-write-your-spec approach in some cases.)
| It doesn't mean you *can't* write a spec at the start. All it means
| is that when you need to make changes (which you do, even if there's a
| detailed spec from the outset and the requirements never change and
| the spec was done *really* well) you can make them more easily. How
| can that be bad?
Very well said. You relieved me completely of commenting on this.
--
Erik Naggum | Oslo, Norway 2004-028
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
In article <·······················@naggum.no>, Erik Naggum
<····@naggum.no> wrote:
>
> * Erann Gat
> > Joel Spolsky says this is (unconditionally) a bad idea.
>
> In fact, he said no such thing
To see that he did requires a level of linguistic sophistication that I
take for granted. Hence my disappointment when I encounter people who
lack it. I keep wondering how they manage to live in our modern world,
but they just do, and never wonder about it. Puzzling this is.
> Erann Gat equated what I said with �aimless hacking�,
In fact I said no such thing.
Repeatedly jumping to conclusions is really not a good way to stay in
mental shape.
There is a difference between "aimless hacking" and "work[ing] out the
solution while coding and watching the computer work on the data." I do
not understand how this is possible, but it appears that you have somehow
managed to believe that I only subscribe to extreme views: either you plan
everything out in advance, or you engage in "aimless hacking"; there is no
middle ground. This is rather incredulous to me in light of the fact that
1) I am well known for having coined "Gat's First Law: all extreme
positions are wrong" and 2) I actually expressed *no view whatsoever* on
what you said, let alone equating what you said with anything, let alone
"aimless hacking", an expression that you have pulled out of your hat.
All I did was make a statement about what Spolsky said. So let me at
least try to explain this so that perhaps those who understand both you
and me can explain it to you.
(Note to those of you who think the tone of my response to this point is
inappropriate: please refer to
http://groups.google.com/groups?selm=3284289178877169KL2065E%40naggum.no
before you draw any conclusions.)
Let us begin by reviewing what Spolsky actually said in his own words:
"... failing to write a spec is the single biggest unnecessary risk you
take in a software project. It's ... stupid ..."
He then goes on to define exactly what he means by "writing a spec":
"... the act of writing the spec -- describing how the program works in minute
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
detail -- will force you to actually design the program.
^^^^^^
Now one might be tempted to respond by saying, "Sure, Spolsky wants you to
write a spec, but he doesn't say you have to do it *before* you start to
code." But in fact he does say this also:
"Programmers and software engineers who dive into code without writing a
spec [first] tend to think they're cool gunslingers, shooting from the
hip. They're not."
I added the word "first", but that clearly doesn't change Spolsky's intention.
It is clear to anyone with even a basic command of English and the rules
of discourse that Spolsky did in fact say exactly what I said he said.
But (and this is the important part so please pay attention) all of this
is irrelevant. It doesn't matter what I think Spolsky says. It doesn't
matter if he actually said all this or not. What matters is that this
represents a prevalent point of view out in the world, that the right way
to write software is to write a spec first, and code to the spec
afterwards. If one accepts this premise then the case for Lisp becomes
much weaker because there is no need for dynamism. Indeed, on this widely
accepted premise (at least in my industry), dynamism invites poor
programming practice.
The most fruitful response to this is not to try to discredit me by
setting up a caricature of my views as a straw man, but rather to attack
the issue at its root and explain *why* it is *not* in fact a good idea to
write a complete spec "describing how the program works in minute detail"
before starting to write code. Possible responses include things like,
"Because it is not possible to do so in general" (to which I will respond:
can you cite an example of such a case?) or "Because a spec can only be
written in response to a complete set of requirements, which is generally
unavailable" or something like that.
* Gareth McCaughan
| Programs written in Lisp are generally easier to change than programs
| written in C++. That doesn't mean you *have* to go changing them all
| the time. (It does mean that some of the costs of change are lower,
| which means that some of the reasons for writing specs in advance are
| weaker, which may or may not be enough to make a suck-it-and-see
| approach better than a first-write-your-spec approach in some cases.)
| It doesn't mean you *can't* write a spec at the start. All it means
| is that when you need to make changes (which you do, even if there's a
| detailed spec from the outset and the requirements never change and
| the spec was done *really* well) you can make them more easily. How
| can that be bad?
This is a fine response, but it is very different from what you first said:
> * Erik Naggum
> > Common Lisp will always be there for programmers who need to work out
> > the solution while coding and watching the computer work on the data.
"Working out the solution while coding" is very different from "when you
need to make changes ... you can make them more easily."
One last point. I would like to address Gareth's rhetorical (I presume)
question:
> How can that be bad?
Please note that what I am about to say is not my personal view, but
rather a view that is prevalent among my peers (and, more to the point,
among my superiors). It can be bad because 1) it facilitates "working out
the solution while programming" which is considered poor practice (indeed
"stupid" -- Spolsky's word, not mine) and 2) being able to make changes
easily is a good thing all else being equal, but all else is not equal.
You pay a price for the ability to make changes easily in terms of runtime
efficiency, availability of programmers, compatibility with existing
infrastructure, and having to deal with lots of irritating silly
parentheses (to say nothing of obnoxious Lisp programmers like Erann Gat
who think they know more than everyone else).
E.
* Erann Gat
| To see that he did requires a level of linguistic sophistication that
| I take for granted. Hence my disappointment when I encounter people
| who lack it. I keep wondering how they manage to live in our modern
| world, but they just do, and never wonder about it. Puzzling this is.
*sigh* At least I spent 2003 getting better.
I now have the evidence I need that you are still baiting for flames.
Could you /please/ try to get some help? Or at least grow up?
--
Erik Naggum | Oslo, Norway 2004-028
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
In article <·······················@naggum.no>, Erik Naggum
<····@naggum.no> wrote:
> * Erann Gat
> | To see that he did requires a level of linguistic sophistication that
> | I take for granted. Hence my disappointment when I encounter people
> | who lack it. I keep wondering how they manage to live in our modern
> | world, but they just do, and never wonder about it. Puzzling this is.
>
> *sigh* At least I spent 2003 getting better.
>
> I now have the evidence I need that you are still baiting for flames.
Really? What is it about the above passage that makes you think so?
That's a serious question. Surely you cannot fail to have noticed that I
didn't write that passage -- you did. I merely quoted it and edited it
lightly (I changed one word: "mathematical" to "linguistic"). Was it
flame bait when you wrote it? If not, why does it become flame bait when
I quote it?
E.
Erann Gat wrote:
>
> In article <·······················@naggum.no>, Erik Naggum
> <····@naggum.no> wrote:
>
> > * Erann Gat
> > | To see that he did requires a level of linguistic sophistication that
> > | I take for granted. Hence my disappointment when I encounter people
> > | who lack it. I keep wondering how they manage to live in our modern
> > | world, but they just do, and never wonder about it. Puzzling this is.
> >
> > *sigh* At least I spent 2003 getting better.
> >
> > I now have the evidence I need that you are still baiting for flames.
>
> Really? What is it about the above passage that makes you think so?
Mimicking someone is a deliberate provocation, and it's just /so/
argument-provoking and worst of all irritating. On top of that you then
strike this "who? me?" pose of utter innocence, when you know full well
you meant to embarrass the OP with their own words.
One thing for certain is that the conversation will no longer be about
specs vs. winging it, and that makes it flame bait.
Of course, you knew all that. :)
kenny
--
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Erann Gat wrote:
>
> In article <·······················@naggum.no>, Erik Naggum
> <····@naggum.no> wrote:
>
> > I now have the evidence I need that you are still baiting for flames.
>
> Really? What is it about the above passage that makes you think so?
>
> That's a serious question. Surely you cannot fail to have noticed that I
> didn't write that passage -- you did. I merely quoted it and edited it
> lightly (I changed one word: "mathematical" to "linguistic"). Was it
> flame bait when you wrote it? If not, why does it become flame bait when
> I quote it?
You are mocking a mathematician with linguistic games. Erik was
being mildly unpleasant, but he was not selfconscously mocking
anyone as far as I could tell.
Bear
In article <·················@sonic.net>, Ray Dillinger <····@sonic.net> wrote:
> Erann Gat wrote:
> >
> > In article <·······················@naggum.no>, Erik Naggum
> > <····@naggum.no> wrote:
> >
> > > I now have the evidence I need that you are still baiting for flames.
> >
> > Really? What is it about the above passage that makes you think so?
> >
> > That's a serious question. Surely you cannot fail to have noticed that I
> > didn't write that passage -- you did. I merely quoted it and edited it
> > lightly (I changed one word: "mathematical" to "linguistic"). Was it
> > flame bait when you wrote it? If not, why does it become flame bait when
> > I quote it?
>
>
> You are mocking a mathematician with linguistic games. Erik was
> being mildly unpleasant, but he was not selfconscously mocking
> anyone as far as I could tell.
What you call "mildly unpleasant" I call "insufferably condescending", but
that is neither here nor there. The fact is I was not mocking him.
"Mock" means "To treat with ridicule or contempt; deride." I was doing no
such thing. I was using Erik's words to express a sentiment that I
genuinely felt. (I decided to do that because Erik's words have so much
more, er, panache than I felt I could muster on my own.)
* Kenny Tilton:
> Mimicking someone is a deliberate provocation
So is condescension. But that is likewise neither here nor there. What
you call "mimicking" I call "quoting", and what I call "condescension" you
call, well, I don't know what you call it, but what difference does it
make? What's the rule here? That it's OK to be obnoxious as long as you
do it first?
> you know full well you meant to embarrass the OP with their own words.
I know nothing of the sort, and if the OP (actually he wasn't the OP but
we'll let that slide) was embarrassed by having his words quoted to him
perhaps next time he will give more careful consideration to what he
writes.
Now I would be very pleased to let the matter drop.
E.
Erann Gat wrote:
>
> In article <·················@sonic.net>, Ray Dillinger <····@sonic.net> wrote:
>
> > Erann Gat wrote:
> > >
> > > In article <·······················@naggum.no>, Erik Naggum
> > > <····@naggum.no> wrote:
> > >
> > > > I now have the evidence I need that you are still baiting for flames.
> > >
> > > Really? What is it about the above passage that makes you think so?
> > >
> > > That's a serious question. ...
> > You are mocking a mathematician with linguistic games.
.....
>
> * Kenny Tilton:
>
> > Mimicking someone is a deliberate provocation
>
...
>
> Now I would be very pleased to let the matter drop.
So it was /not/ a serious question? You got two very serious answers
that could have helped you understand why your style of exchange is so
insanely counterproductive, and your response is to clamp your hand over
your ears and wail "woo woo woo!".
Jeez, NASA would porbably be all-lisp-all-the-time if you weren't Lisp's
champion.
kenny
--
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
In article <·················@nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> Erann Gat wrote:
> > Now I would be very pleased to let the matter drop.
>
> So it was /not/ a serious question?
No, it was, and you're right, I should have thanked you for your response.
So thank you for your response.
> your style of exchange is so insanely counterproductive
But it isn't. I'm getting lots of useful and constructive responses in
other branches of this thread.
> Jeez, NASA would porbably be all-lisp-all-the-time if you weren't Lisp's
> champion.
Could be. So when are you coming out here to help?
E.
Erann Gat wrote:
>
>
> Could be. So when are you coming out here to help?
I did not hear back from you so I figured the room was a no-go. I was
also thinking, gee, don't you all kinda have your hands full at the
moment? I have visions of an empty room, and I wouldn't blame them. Must
be heady days out there.
I did check and it's a $130 penalty for altering the itinerary. I'd take
the hit but then there is the matter of competing with not one but two
Martian golf carts.
You know, it would also be nice if there was a Cello and a demo and some
doc for them to download if I got their interest. I think the $130
penalty means I can round-trip it from new york in may for the same net
outlay, and then the presentation will be sharper, Cello will be
released, and everyone will be tired of Mars or someone will have
figured out that the machine would be easier to debug from Earth if they
had a frickin REPL.
(length (directory "flash:\")) => oh, jeez.
kenny
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
In article <·················@nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> Erann Gat wrote:
> >
> >
> > Could be. So when are you coming out here to help?
>
> I did not hear back from you so I figured the room was a no-go.
I was waiting to hear from you that you had managed to change your
itinerary. Until you tell me when you are going to be here I don't know
when to schedule the room.
> I was
> also thinking, gee, don't you all kinda have your hands full at the
> moment? I have visions of an empty room, and I wouldn't blame them.
That is a risk, but 6000 people work at JPL and only a few dozen are
directly involed in MER ops.
> I did check and it's a $130 penalty for altering the itinerary. I'd take
> the hit but then there is the matter of competing with not one but two
> Martian golf carts.
Your call.
>
> You know, it would also be nice if there was a Cello and a demo and some
> doc for them to download if I got their interest. I think the $130
> penalty means I can round-trip it from new york in may for the same net
> outlay, and then the presentation will be sharper, Cello will be
> released, and everyone will be tired of Mars or someone will have
> figured out that the machine would be easier to debug from Earth if they
> had a frickin REPL.
OK.
E.
Erann Gat wrote:
> The most fruitful response to this is not to try to discredit me by
> setting up a caricature of my views as a straw man, but rather to attack
> the issue at its root and explain *why* it is *not* in fact a good idea to
> write a complete spec "describing how the program works in minute detail"
> before starting to write code. Possible responses include things like,
> "Because it is not possible to do so in general" (to which I will respond:
> can you cite an example of such a case?) or "Because a spec can only be
> written in response to a complete set of requirements, which is generally
> unavailable" or something like that.
I know that was addressed to Erik, but here are some slightly
more detailed possible responses.
- Some problems are so easy that there is scarcely any
chance that either the spec or the code you'd write
would need changing. For such problems, Joel Spolsky's
argument for spec writing doesn't apply. (There might
be other reasons to write a spec, such as being
required to by your employer or wanting to use it
as documentation for later users of the program.)
- Solving some problems involves making decisions for
which crucial information (e.g., how fast does this
approach run in typical cases?) is much more easily
obtained by writing the code and running it than in
any other way. These decisions can't be taken more
easily and quickly by looking at a spec than by
writing the code.
There are several different ways in which this can
happen. Here are some:
- There may be tricky algorithms involved that
are difficult to analyse; no better way of
estimating time and space requirements than
actually writing and running the code may be
available.
- The problem (or a subproblem) may have the form
"Make the customer happy"; the customer may be
unable to tell you reliably what will make him
happy. (Good user interfaces, like pornography,
are more easily recognized than defined. I make
no claim that good user interfaces should be
like pornography in any other respect.) Sometimes
the customer thinks he knows, or claims he knows,
but that turns out not to be so.
- The data to be fed to one part of the system
may be generated by another part, and there
may be no available way to predict what that
data will be until that other part of the system
is in place. It may not be possible to make a
sensible choice of how to design the later part
of the system until much is known about the
data it will be receiving.
- Some problems are desperately underspecified or
unclear. ("Write a program that creates beautiful
music." "Write a game that will sell 10 million
copies.") When faced with such a problem, unless
you choose to give up you need to generate some
clever ideas. Playing around can be an effective
source of ideas, and for programmers one valuable
for of "playing around" is playing around with the
code. What happens if I try generating notes
randomly like so? Hmm, not very interesting;
maybe I want to make each depend on what's gone
before, so let's try putting in such-and-such a
constraint. Now it's rather boring, so let's let
the constraint be violated every now and then.
And so on. (Producing genuinely beautiful music
will of course need enormously more sophistication
than that sort of interior monologue suggests.)
> * Gareth McCaughan
> | Programs written in Lisp are generally easier to change than programs
> | written in C++. That doesn't mean you *have* to go changing them all
> | the time. (It does mean that some of the costs of change are lower,
> | which means that some of the reasons for writing specs in advance are
> | weaker, which may or may not be enough to make a suck-it-and-see
> | approach better than a first-write-your-spec approach in some cases.)
> | It doesn't mean you *can't* write a spec at the start. All it means
> | is that when you need to make changes (which you do, even if there's a
> | detailed spec from the outset and the requirements never change and
> | the spec was done *really* well) you can make them more easily. How
> | can that be bad?
>
> This is a fine response, but it is very different from what you first said:
>
>
> > * Erik Naggum
> > > Common Lisp will always be there for programmers who need to work out
> > > the solution while coding and watching the computer work on the data.
>
> "Working out the solution while coding" is very different from "when you
> need to make changes ... you can make them more easily."
Indeed it is. CL is a great language for "working out the solution
while coding", and I happen to agree with Erik that that isn't
always a bad thing. But it's also worth pointing out that even
if it were, unconditionally, a bad thing, that wouldn't be any
argument against CL; it would just mean that one often-repeated
argument *for* CL would be invalid.
> One last point. I would like to address Gareth's rhetorical (I presume)
> question:
>
> > How can that be bad?
For the record, it wasn't wholly rhetorical.
> Please note that what I am about to say is not my personal view, but
> rather a view that is prevalent among my peers (and, more to the point,
> among my superiors). It can be bad because 1) it facilitates "working out
> the solution while programming" which is considered poor practice (indeed
> "stupid" -- Spolsky's word, not mine) and 2) being able to make changes
> easily is a good thing all else being equal, but all else is not equal.
> You pay a price for the ability to make changes easily in terms of runtime
> efficiency, availability of programmers, compatibility with existing
> infrastructure, and having to deal with lots of irritating silly
> parentheses (to say nothing of obnoxious Lisp programmers like Erann Gat
> who think they know more than everyone else).
#1 is a silly objection because facilitating a poor practice
is only bad if it's facilitated at the expense of good
practices. #2 may be a sensible objection to Lisp (at least
for some people or groups), but it isn't a reason why making
it easier to change your code is bad, and it therefore isn't
an answer to my question.
--
Gareth McCaughan
.sig under construc
In article <··············@g.mccaughan.ntlworld.com>, Gareth McCaughan
<················@pobox.com> wrote:
[A lot of good stuff]
Thanks for that response. That was very helpful.
> > > * Erik Naggum
> > > > Common Lisp will always be there for programmers who need to work out
> > > > the solution while coding and watching the computer work on the data.
> >
> > "Working out the solution while coding" is very different from "when you
> > need to make changes ... you can make them more easily."
>
> Indeed it is. CL is a great language for "working out the solution
> while coding", and I happen to agree with Erik that that isn't
> always a bad thing.
So do I. The problem is not how to convince *me*, the problem is how to
convince people who believe Spolsky.
> But it's also worth pointing out that even
> if it were, unconditionally, a bad thing, that wouldn't be any
> argument against CL; it would just mean that one often-repeated
> argument *for* CL would be invalid.
True. But it's already a hard enough sell around here without losing that
argument, so I don't want to give it up if I don't have to.
> > Please note that what I am about to say is not my personal view, but
> > rather a view that is prevalent among my peers (and, more to the point,
> > among my superiors). It can be bad because 1) it facilitates "working out
> > the solution while programming" which is considered poor practice (indeed
> > "stupid" -- Spolsky's word, not mine) and 2) being able to make changes
> > easily is a good thing all else being equal, but all else is not equal.
> > You pay a price for the ability to make changes easily in terms of runtime
> > efficiency, availability of programmers, compatibility with existing
> > infrastructure, and having to deal with lots of irritating silly
> > parentheses (to say nothing of obnoxious Lisp programmers like Erann Gat
> > who think they know more than everyone else).
>
> #1 is a silly objection because facilitating a poor practice
> is only bad if it's facilitated at the expense of good
> practices.
Huh? It seems to me that facilitating a bad practice is bad, period, end
of story. That might be more than offset by concomitant advantages, but
that would not change the fact that facilitating bad practice is (or can
reasonably be considered to be) unconditionally bad.
> #2 may be a sensible objection to Lisp (at least
> for some people or groups), but it isn't a reason why making
> it easier to change your code is bad, and it therefore isn't
> an answer to my question.
Good point.
E.
On Wed, 28 Jan 2004 22:07:13 -0800, Erann Gat wrote:
> Huh? It seems to me that facilitating a bad practice is bad, period, end
> of story. That might be more than offset by concomitant advantages, but
> that would not change the fact that facilitating bad practice is (or can
> reasonably be considered to be) unconditionally bad.
Most practices that are promulgated are bad (or good) based on their
context. The "unconditionally bad" (read almost never good)
practices are usually weeded out of the food chain early or properly
contextualized to their narrow solution space when described. Only
practices that are "good enough" in many contexts get promulgated
with unspecified contextualization broadly enough that they become used in
places where they turn out to be bad practices. And it's these "good
enough" practices that cause the most trouble precisely because they work
so well in the proper contexts. People get attached to them, promoting
a non-existant universality of goodness that causes no end of trouble to
people who just want to get work done.
faa
Frank A. Adrian wrote:
> On Wed, 28 Jan 2004 22:07:13 -0800, Erann Gat wrote:
>
>
>>Huh? It seems to me that facilitating a bad practice is bad, period, end
>>of story. That might be more than offset by concomitant advantages, but
>>that would not change the fact that facilitating bad practice is (or can
>>reasonably be considered to be) unconditionally bad.
>
>
> Most practices that are promulgated are bad (or good) based on their
> context. The "unconditionally bad" (read almost never good)
> practices are usually weeded out of the food chain early or properly
> contextualized to their narrow solution space when described. Only
> practices that are "good enough" in many contexts get promulgated
> with unspecified contextualization broadly enough that they become used in
> places where they turn out to be bad practices. And it's these "good
> enough" practices that cause the most trouble precisely because they work
> so well in the proper contexts. People get attached to them, promoting
> a non-existant universality of goodness that causes no end of trouble to
> people who just want to get work done.
Given the extraordinarily high failure rate of software projects (and
the tendency to redefine both failure and success along the way), I'd
think that the weeding-out process isn't as easy as all that. Even
processes that are unambiguously linked with failure could persist for
quite a while if they have other attractive traits.
paul
"Frank A. Adrian" <·······@ancar.org> writes:
> Most practices that are promulgated are bad (or good) based on their
> context. The "unconditionally bad" (read almost never good)
> practices are usually weeded out of the food chain early or properly
> contextualized to their narrow solution space when described.
`Unsafe' languages that do not check array bounds, validate arguments,
check for error codes, etc. for example.
On Thu, 29 Jan 2004 17:27:10 -0500, Joe Marshall wrote:
> `Unsafe' languages that do not check array bounds, validate arguments,
> check for error codes, etc. for example.
And these are fine practices to follow when (a) processor time is
precious, (b) code size is critical, and (c) the programmer is willing to
trade off the first two items for debugging and test time. This was
somewhat the case where and when C was first put into use. It most
certainly has not been this way in most places where C (or C++) has
been used for the past couple decades. I believe it is a case where a
hammer worked relatively well for a period of time and then was
decontextualized to try to use it to install drywall screws. Now people
ask why there are so many holes that need to be patched...
faa
* Erann Gat
| The problem is not how to convince *me*, the problem is how to
| convince people who believe Spolsky.
This is only your personal daemon, not a real problem.
Just because you are such an unoriginal thinker that you plagiarize
other people and then do not even have the moral integrity to accept
responsibility for your own actions and reactions, and therefore have
zero chance of convincing anyone with a healthy psychology, does not
mean that the problems you face are forever someone else's fault.
There will never be a shortage of people who believe stupid things.
If you make it your modus operandi to excuse your personal failures by
looking for one of them and claiming that people believe them instead
of you, not a single person, regardless of psychological health, will
believe anything you say at all.
I don't know if it is possible to teach people personal responsibility
and to accept responsibility for how they feel, how they react, and
how they act, if they have managed to reach adulthood without ever
learning it on their own, so I will have no advice to give to Erann
Gat at this or any later date. But it would be good if he could find
some other way to absolve himself of responsibility for his actions
than to plagiarize something I write. That's just so 2002.
--
Erik Naggum | Oslo, Norway 2004-029
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
In article <·······················@naggum.no>, Erik Naggum
<····@naggum.no> wrote:
> you plagiarize
I did no such thing. I never claimed that your words were my original
work. In fact, I even provided a citation.
> I don't know if it is possible to teach people personal responsibility
> and to accept responsibility for ... how they act,
I don't know, let's find out: You have leveled a very serious charge at
me. That charge is false. Will you accept responsibility for your
actions, withdraw the charge and apologise?
E.
·········@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@g.mccaughan.ntlworld.com>, Gareth McCaughan
> <················@pobox.com> wrote:
>
> [A lot of good stuff]
>
> Thanks for that response. That was very helpful.
>
> > > > * Erik Naggum
> > > > > Common Lisp will always be there for programmers who need to work out
> > > > > the solution while coding and watching the computer work on the data.
> > >
> > > "Working out the solution while coding" is very different from "when you
> > > need to make changes ... you can make them more easily."
> >
> > Indeed it is. CL is a great language for "working out the solution
> > while coding", and I happen to agree with Erik that that isn't
> > always a bad thing.
>
> So do I. The problem is not how to convince *me*, the problem is how to
> convince people who believe Spolsky.
That's an easy one: Spolsky himself says that what he's saying applies
only to his situation. Not everyone is in the same situation, having
to develop the same kind of software for the same kind of "customers".
> Huh? It seems to me that facilitating a bad practice is bad, period, end
> of story. That might be more than offset by concomitant advantages, but
> that would not change the fact that facilitating bad practice is (or can
> reasonably be considered to be) unconditionally bad.
Not because what you consider a bad practice in one situation may be a
good or even the best or the only practice in another situation.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Erann Gat wrote:
> > > Please note that what I am about to say is not my personal view, but
> > > rather a view that is prevalent among my peers (and, more to the point,
> > > among my superiors). It can be bad because 1) it facilitates "working out
> > > the solution while programming" which is considered poor practice (indeed
> > > "stupid" -- Spolsky's word, not mine) and 2)
...
> > #1 is a silly objection because facilitating a poor practice
> > is only bad if it's facilitated at the expense of good
> > practices.
>
> Huh? It seems to me that facilitating a bad practice is bad, period, end
> of story. That might be more than offset by concomitant advantages, but
> that would not change the fact that facilitating bad practice is (or can
> reasonably be considered to be) unconditionally bad.
OK, let's be a little more precise. Making it easier to do something
bad, and not making anything easier that isn't bad, is (I admit) a
bad thing. How bad it is depends on how able the relevant people are
to resist the temptation to do whatever it is that's been made
easier. Making something bad easier almost always means, in practice,
making some good things easier too; it's hard to separate them
because they're usually made easier in the same way, by the same
mechanism.
I think this is the case for Lisp's alleged facilitation of
bad programming practice. Writing in Lisp makes it easier to
change your code when requirements change, when your carefully
written spec turns out to have a bad decision embedded in it,
when you're struck by a sudden inspiration during coding that
you missed when writing the spec, or (yes) when you just don't
have a clear idea what you're doing. One aspect of that is
that it makes "cowboy coding" easier and therefore more
tempting, which is admittedly a bad thing -- but I think
it's clearly outweighed by the advantages of flexibility.
Furthermore:
I make the following claims. The way Lisp makes changing your code
more tempting is by making it easier and quicker. The reason why
development methods that involve changing your code a lot are
(allegedly, for some people, working on some tasks, blah blah blah)
stupid is that changing your code is difficult and slow. (Recall
Joel Spolsky's argument: you should plan everything in advance
because changing the code hurts so much compared to changing the
spec.) In other words, Lisp makes that sort of development method
more attractive *by making it less harmful*.
Now, how could that be bad? I see only one way. If someone's
perception of the risk and effort attendant on changing code
were seriously overoptimistic, then it could be the case that
the perceived badness of having to change code in Lisp falls
below their threshold for "just diving in and coding", while
(1) the *actual* badness is above the threshold and (2) even
the perceived badness is above the threshold for "stiffer"
languages like C++. So using Lisp might allow them to get
seduced into taking an unwise approach.
I think that scenario genuinely could happen, and that would
be a bad thing. But is it really fair to call that a problem
with Lisp? There are similar failure modes whenever something
makes something else easier to do. (Type inference, as in
languages like Haskell, makes it easier to write programs
without specifying types explicitly. Sometimes you should
specify some of the types explicitly even though you don't
have to, for the sake of clarity. Having type inference
will make some people, who misjudge the tradeoffs, write
worse programs. Support for floating point arithmetic
makes it easier to write programs that manipulate numbers
without a great scaffolding of explicit precision bookkeeping.
Sometimes you should do the bookkeeping explicitly, to be
sure that your program is robust against certain kinds of
data. Having support for floating-point numbers will make
some people, who misjudge the tradeoffs, write nasty sloppy
programs that work -- when they do -- only by coincidence.
And so on.)
--
Gareth McCaughan
.sig under construc
In article <··············@g.mccaughan.ntlworld.com>, Gareth McCaughan
<················@pobox.com> wrote:
> The way Lisp makes changing your code
> more tempting is by making it easier and quicker. The reason why
> development methods that involve changing your code a lot are
> (allegedly, for some people, working on some tasks, blah blah blah)
> stupid is that changing your code is difficult and slow. (Recall
> Joel Spolsky's argument: you should plan everything in advance
> because changing the code hurts so much compared to changing the
> spec.) In other words, Lisp makes that sort of development method
> more attractive *by making it less harmful*.
I used to think that was true, but I've been thinking about it all day and
I've come to the conclusion that the ease of making changes to code is a
red herring WRT Spolsky's argument.
What this debate is really about, it seems to me, is no different from the
old deliberative vs. reactive debate that took place in AI robotics during
the 80s. There were the traditionalists who said that robots should
generate a complete plan before starting to act, and there was Rod Brooks
who said that you should couple the sensors directly to the actuators and
not plan at all. Replace "act" with "code" and you have the current
discussion. Spolsky is the traditional sense-plan-act guy. XP is the
software-engineering version of the subsumption architecture.
Viewed in this light, Spolsky's argument becomes: if you code (act) before
you finish planning (writing a spec) you will be doing a series of local
optimizations that is not likely to lead you to a global optimum. And
this argument is in fact correct, except in those situations where
deliberation breaks down: if you have incomplete knowledge, or if your
environment is dynamic, i.e. your requirements are changing.
All this is completely independent of the cost of your operators (coding,
making changes).
Comments?
E.
·········@jpl.nasa.gov (Erann Gat) writes:
> What this debate is really about, it seems to me, is no different from the
> old deliberative vs. reactive debate that took place in AI robotics during
> the 80s. There were the traditionalists who said that robots should
> generate a complete plan before starting to act, and there was Rod Brooks
> who said that you should couple the sensors directly to the actuators and
> not plan at all.
And whether you believe in evolution or a Designer, you have to admit
that the most successful machines on the planet (i.e. the higher-order
vertibrates) come equipped with _both_ mechanisms. It's interesting,
however, that although there are animals with pre-planning computation
as well as reactive computaton abilities, and there are also animals
with reactive computation but not much in the way of planning abilities,
we don't see too many animals survive that have planning but not reaction
abilities.
> Replace "act" with "code" and you have the current
> discussion. Spolsky is the traditional sense-plan-act guy. XP is the
> software-engineering version of the subsumption architecture.
So it seems that for a language to survive long-term, it must have at
least reactive capabilities, and plan-then-code abilities then might
ensure dominance to some extent.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> vertibrates) come equipped with _both_ mechanisms. It's interesting,
> however, that although there are animals with pre-planning computation
> as well as reactive computaton abilities, and there are also animals
> with reactive computation but not much in the way of planning abilities,
> we don't see too many animals survive that have planning but not reaction
> abilities.
No operation plan extends with any certainty beyond the first
encounter with the main body of the enemy. It is only the layman
who, as a campaign develops, thinks he sees the original plan being
systematically fulfilled in every detail to its preconceived
conclusion." - von Moltke The Elder
Usually summarised as "No plan survives contact with the enemy" (and
attributed to Napoleon)
-dan
·········@jpl.nasa.gov (Erann Gat) writes:
> Viewed in this light, Spolsky's argument becomes: if you code (act)
> before you finish planning (writing a spec) you will be doing a
> series of local optimizations that is not likely to lead you to a
> global optimum. And this argument is in fact correct, except in
> those situations where deliberation breaks down: if you have
> incomplete knowledge, or if your environment is dynamic, i.e. your
> requirements are changing.
>
> All this is completely independent of the cost of your operators
> (coding, making changes).
>
> Comments?
I'm not sure how you figure it's completely independent of the cost of
the various operations. At the very least the cost of various
operations influences the cost of various strategies you could use to
mitigate the drawbacks of one approach or another.
For instance, the XP guys recognize that its easy to fall into the
trap of what you describe as "local optimizations" if you just start
coding. So they respond by doing "the simplest thing that could
possibly work" and counting on their ability to refactor later as they
gain knowledge. It's probably no surprise that that approach grew up
in the Smalltalk world which is similar to Lisp in its support for
making changes late in the game. That is, because the cost of making
changes is low, the cost of making provisional decisions while
actually coding is thus lower. If you were working in a language where
the cost of refactoring is high, then the strategy of doing simple
things knowing that you're going to have to change n percent of them
later is not so good because those changes will be more costly than the
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
In article <··············@javamonkey.com>, Peter Seibel
<·····@javamonkey.com> wrote:
> I'm not sure how you figure it's completely independent of the cost of
> the various operations.
The argument is the same, and therefore the conclusion is the same,
regardless of the cost of the operations. Of course, the cost of the
operations is not irrelevant, it's just irrelevant *for this argument*,
which is to say, to the argument over whether Spolsky is correct in his
position that one should always write a complete spec before writing any
code. What determines the desirability of writing a spec is not the cost
of coding and making changes, but rather the extent of one's knowledge and
the dynamism of the environment.
E.
·········@jpl.nasa.gov (Erann Gat) writes:
> Viewed in this light, Spolsky's argument becomes: if you code (act) before
> you finish planning (writing a spec) you will be doing a series of local
> optimizations that is not likely to lead you to a global optimum. And
> this argument is in fact correct, except in those situations where
> deliberation breaks down: if you have incomplete knowledge, or if your
> environment is dynamic, i.e. your requirements are changing.
Seems reasonable. Of course, you almost *never* have complete
knowledge whether you think you do or not, and the environment is
*always* dynamic. How often does it happen that code that passes the
tests is considered `complete' and never revisited?
--
~jrm
On Thu, 29 Jan 2004, Erann Gat wrote:
[snip]
> What this debate is really about, it seems to me, is no different from the
> old deliberative vs. reactive debate that took place in AI robotics during
> the 80s. There were the traditionalists who said that robots should
> generate a complete plan before starting to act, and there was Rod Brooks
> who said that you should couple the sensors directly to the actuators and
> not plan at all. Replace "act" with "code" and you have the current
> discussion. Spolsky is the traditional sense-plan-act guy. XP is the
> software-engineering version of the subsumption architecture.
Interesting. A major point of disanalogy, of course, is that the program
is more like the plan rather than the action, and we're talking about
different ways of plan generation. Hmm. I wavered on whether its a
disanalogy, perhaps its just an analogy weakness to me. Deployment of the
software seems much more like the action, above.
Hmm. And XP asks for early and often deployment :) But, the methodology
there is: 1) Identify a concrete goal, 2) develop an initial solution/plan
(a spike), 3) use that to test you and your customer's understanding of
the goal, 4) develop a refined solution/plan (an "iteration"), 5) deploy,
6) gather information about the success of that, 7) repeat.
Once you have an artefact, as you are adding functionality to achieve
additional goals, you are supposed to be aware of refactoring
opportunities, and take them aggressively. So it's a bit like a dynamic
profiling and optimization VM (like HotSpot).
> Viewed in this light, Spolsky's argument becomes: if you code (act) before
> you finish planning (writing a spec) you will be doing a series of local
> optimizations that is not likely to lead you to a global optimum.
But that's not clear, because you always have the whole program available,
or, at least, the whole programming task. If refactoring is difficult,
then early decisions tend to *commit* you to those decisions because the
cost of change is very high. If the cost of change is very low (or sunk),
then why would you do a series of local optimization *only*?
> And
> this argument is in fact correct, except in those situations where
> deliberation breaks down: if you have incomplete knowledge, or if your
> environment is dynamic, i.e. your requirements are changing.
Some of this depends on the level of detail of the requriements, as well.
Hmm. Maybe that's incomplete knowledge. E.g., if you are indifferent to
the particular api, but just *want* a stable API, that might be because
you *really* don't care, or because you would be satisified with any
number of concrete apis but you might also dislike some once you work with
them.
I think one could argue that with a software project of any reasonable
size, there is no such thing as unchanging requirements. Such arguments
might not be rhetorically useful. Hmm. Perhaps the extreme case is the
reqirement to backward engineer a program. But there, details of the
requirement (or rather what it takes to fulfill the requirement) typically
are determined over (a long) time.
> All this is completely independent of the cost of your operators (coding,
> making changes).
Yeah. In the structure of your analogy, this seems compelling. Hmm. What
are we optimizing for? Efficiency of the programming process? One counter
might be that planning up front doesn't constrain the search space any, so
it might be way more expensive than committing yourself to something and
pruning the search space (by those committments). You may have to
backtrack (and thus, you could run into thrashing), but you may up your
chances of achieving a correct result given the constraints.
> Comments?
See above.
Cheers,
Bijan Parsia.
Erann Gat wrote:
> What this debate is really about, it seems to me, is no different from the
> old deliberative vs. reactive debate that took place in AI robotics during
> the 80s. There were the traditionalists who said that robots should
> generate a complete plan before starting to act, and there was Rod Brooks
> who said that you should couple the sensors directly to the actuators and
> not plan at all. Replace "act" with "code" and you have the current
> discussion. Spolsky is the traditional sense-plan-act guy. XP is the
> software-engineering version of the subsumption architecture.
>
> Viewed in this light, Spolsky's argument becomes: if you code (act) before
> you finish planning (writing a spec) you will be doing a series of local
> optimizations that is not likely to lead you to a global optimum. And
> this argument is in fact correct, except in those situations where
> deliberation breaks down: if you have incomplete knowledge, or if your
> environment is dynamic, i.e. your requirements are changing.
>
> All this is completely independent of the cost of your operators (coding,
> making changes).
My intuition is that this is a bad analogy because it encourages
confusion of levels. Reactive architectures are (in some significant
part) about "compiling" planning knowledge into a form where its
original symbolic content is invisible. "IF you hit an obstruction THEN
stop and go around it" can be "compiled" down to a wire from the forward
bump sensor to the drive motors plus maybe a sequence relay or two, for
example. (When I say "compile" of course course at this point I mean "a
very smart human can figure out which minimal primitives can encode the
effects of the planning knowledge for a given class of problems, design
a hardware moral-equivalent-of-an-ISA to implement those primitives, and
then hand-code the necessary moral-equivalent-of-a-program.")
My point is that there's an enormous amount of pre-planning done before
a reactive architecture gets built (well, sometimes after it gets built
and breaks and needs to be rebuilt, lather, rinse, repeat, but
nevertheless). As a result, a working reactive gizmo (which subsumption,
however fuzzily defined, is only one of many ways to build) has encoded
in it the results of planning and of empirical trials that effectively
tell it how to handle whatever challenges in its class it comes up against.
The equivalent of this would be a coder who already knows how to write
whatever code is needed, and only has to recognize the nature of the
problem before spitting out the right solution, like a subject reacting
to any one of however many posthypnotic triggers.
The question of whether a gizmo (or a programmer) is limited to local
knowledge and hence likely to choose a suboptimal solution is, I think,
orthogonal to this. Various reactive folks did a bunch of work on
(effectively) encoding global knowledge in extra behaviors and a few
bits of state that acted to bias existing behaviors.
If you still want to use the analogy, I'd say that the cool thing about
languages like lisp is not just that they make changes easy but that
they do so by (very metaphorically speaking) giving reactive systems
access to the original symbolic content of the behaviors programmed into
them, and the ability to change that content and "recompile".
paul
>>>>> On Fri, 30 Jan 2004 12:52:04 -0500, Paul Wallich ("Paul") writes:
Paul> The equivalent of this would be a coder who already knows how to write
Paul> whatever code is needed, and only has to recognize the nature of the
Paul> problem before spitting out the right solution, like a subject
Paul> reacting to any one of however many posthypnotic triggers.
Which describes how most people seem to program today: recognize the
pattern, download and align the pre-packaged components, add the
boilerplate glue, and insert the customization strings.
Which is the same thing that experts generally do, except that
true experts have a deeper knowledge of the pieces involved rather
than explicitly learning to work by rote pattern matching; and in
days gone by, most programmers were capable of devising the patterns
and designing and implementing the components themselves.
Erann Gat wrote:
> What this debate is really about, it seems to me, is no different from the
> old deliberative vs. reactive debate that took place in AI robotics during
> the 80s. There were the traditionalists who said that robots should
> generate a complete plan before starting to act, and there was Rod Brooks
> who said that you should couple the sensors directly to the actuators and
> not plan at all. Replace "act" with "code" and you have the current
> discussion. Spolsky is the traditional sense-plan-act guy. XP is the
> software-engineering version of the subsumption architecture.
I think that none of those two extremes would actually work in practice,
and I believe that they don't happen.
The short, and probably wrongly represented, version of extreme planning
would be to have a plan worked out in so much detail that it only
requires blind coding according to that plan in order to finish the
program. It should be immediately clear that such a detailed plan would
be equivalent to the final program. Planning only makes sense insofar a
certain amount of details are left out.
The short, and definitely wrongly represented, version of extreme
programming would be to code ahead without spending any amount of
thinking upfront. Again, it should be immediately clear that this cannot
lead anywhere because you have to have a minimal knowledge what the goal
of the program is.
I have put up these two straw men in order to argue that _any_ kind of
software development process has to lie anywhere between these two
extremes. It's a continuum, not a dichotomy. And if you look at the
actual development processes, they all include certain amounts of both
of them. RUP has the notion of iterations, XP has the notion of planning
games.
The real contribution of XP is not how the process looks like - of
course, this is also a contribution, because it is really an excellent
development process AFAICT - but the more important point is that it is
the first that prominently integrated the notion of human factors into
the process. For example, an important element in the planning game is
that it's the programmers' job to determine how long a task needs to be
implemented, and they are encouraged to trust their intuition. XP makes
it very clear that noone else has a say in this respect. Managers and
customers are not allowed to object to their estimates. This is balanced
by the fact that only customers have the right to give priorities to the
tasks that are to be implemented. In turn, programmers don't have the
right to object to their priorities. And so forth.
(Extreme Programming can actually be understood as a pattern language in
an Alexandrinian sense. Things like test-first development, no code
ownership, do the simplest thing that could possibly work, and so no,
are patterns that, taken together, result in synergistic effects. So
it's not a fair representation that extreme programming means to blindly
code ahead. (I am not saying that anyone said so.))
In Alistair Cockburn's book, he gives a lot more information about why
it is actually important to count on human factors. An example he gives
in presentations is that in all the successful projects he consulted in,
there were people who had just done things that came up during a
project. This obviously helped to keep unexpected events under control,
but it only worked because people had enough freedom to act like this.
It seems to me that it actually doesn't matter too much what software
development process you choose. The important point is that you have
experienced people on board who control the process. Blindly following a
process won't lead you anywhere. Processes are followed blindly only by
people who are not willing to take over responsibility for decisions
they make. (One of XP's premise is that all people involved in a project
actually want to make that project successful. This is an example of
taking advantage of peoples' self-motivation.)
Viewed in this light, a lot of planning ahead, and maybe even a static,
strongly type-checked programming language, might be the right choice if
this suits the persons' thinking process better who are involved in
developing a piece of software. Again, the important point is that they
should be in control and be able to take corrective action in case
something doesn't work out as planned. (And it is important to note that
static languages tend to have certain limitations in that regard.)
BTW, I guess this is one of the important reasons why the belief in
programming languages (and other tools) for the so-called "average"
programmers is so wide-spread - it's because apparently many people
believe that human factors should be kept out of a process. This is
meant to reduce the possible sources of human errors, but this also
reduces the amount of responsibility people can take over.
Just a few random thoughts...
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Erann Gat wrote:
> Viewed in this light, Spolsky's argument becomes: if you code (act) before
> you finish planning (writing a spec) you will be doing a series of local
> optimizations that is not likely to lead you to a global optimum. And
> this argument is in fact correct, except in those situations where
> deliberation breaks down: if you have incomplete knowledge, or if your
> environment is dynamic, i.e. your requirements are changing.
>
> All this is completely independent of the cost of your operators (coding,
> making changes).
It isn't independent of the cost of the operators, because planning
isn't free and needs to be considered an "operator" in its own right.
And planning is a local optimization too, no more guaranteed to lead
to a global optimum than iterative coding is even if the environment
is stable. Oh, and knowledge is *always* incomplete.
Apart from that, I agree :-).
--
Gareth McCaughan
.sig under construc
* Erann Gat
| What this debate is really about, it seems to me, is no different
| from the old deliberative vs. reactive debate that took place in AI
| robotics during the 80s.
This debate is really about whether the act of programming produces or
consumes information. Of course it does both.
This odd discussion is similar to the age-old discussion about how to
write an essay. Some people believe that you should think carefully
about everything, construct a skeleton and a plan and proceed to flesh
it out, in the belief that you should have all the information you
need to write the essay up front and that the writing itself should
not produce more information, indeed that thinking of something you
had not thought of to begin with is some sort of failure condition,
like lack of planning or lack of concentration on the task at hand.
Other people believe that formulating an idea in words /creates/ the
idea and that you should only define a purpose, a goal condition, and
then proceed to write your ideas down while monitoring that you are on
the right course. (Monitoring is how consciousness works to begin
with and with some training becomes automatic and emotional: you feel
good when you go in the right direction and bad when you go in the
wrong direction. People who plan compulsively are usually the kind
who think that emotions have no business in directing attention or
focusing effort.) Creative people also argue that premature planning
solidifies unformed ideas that should be expressed fully if they are
allowed to form at all, because almost all ideas appear good until put
to the test, and the best test is not to think about what you would
do, but to actually do it. (The word �essay� itself is curious -- it
originally meant an attempt at expressing something, but the written
attempt has become such a standard model that the word has come to
mean a particular style of exposition and the history of the word is
all but forgotten.)
Most of the arguments in favor of one or the other of these positions
(when both are clearly necessary and correct) are made for the sole
purpose of pushing a pendulum that has swung too far in one direction
back in the other direction, so the context of each argument is that
the antithetical position has become too strong, for whatever reason
and by whatever measure. We have not arrived at the stable position
that is satisfactory to all parties, so we keep pushing the pendulum
too much in our direction when we perceive that it has been pushed too
much in the other direction by others. In all likelihood, the stable
position is one where different people exhibit different capacities
and tendencies and where the belief in one answer has been replaced by
a more pluralistic view. In my view, the planners are not only wrong,
but so averse to feeling bad that they prevent themselves from feeling
good about what they do and therefore have no direct experience of the
pleasure of thinking properly and so resort to their plans to avoid
the pain of realizing that they do not think well. Herbert Dreyfus
has argued that it is extremely important to be emotionally attached
to the success of one's work if one is to progress beyond advanced
beginner to competent or even proficient, and point out that students
who work very hard to avoid feeling the pain of failure never become
competent enough to feel the joy of competence and success. It is no
accident that those who recoil from the pain of failure are those who
are most likely to ask for �rules� or reach for the �answer book�.
Some people are very good at predicting what will happen and plan for
both the likely and the unlikely, but then become nervous wrecks when
their planning turns out to be faulty and they have to re-plan, which
they resist until it is already too late. Others are not so good at
prediction and planning, but are very good at setting goals, and they
try things out, compare it with their desired results, learn from each
failure, accept that neither other people nor the world in general are
obliged to do their bidding, and they never become nervous wrecks in
the face of hardship, even disasters, but frequently set new goals as
they find that some goals were unreachable at a reasonable cost.
In the real world, it takes all kinds to make a good society, and the
only track record we know from people who believe that only one kind
of person should exist is incredibly murderous tyrannies. A lot of
(dysfunctional) people believe that all those who do not obey every
rule should be punished or killed, and they spend their time blocking
other views, with such phraseology as �unconditionally bad� about them
while they misrepresent them in order to destroy the ability of others
to present them in a rational discussion. Typical behavioral patterns
with these people include hostility towards any violation of their
plans and rules, and when they see some person doing something they do
not like, they believe that the proper course of action is to do what
they do not like on purpose and in some demented idea of retaliation
and retribution, even though they are never directly affected, instead
of working to rectify or improve the global situation. Breaking rules
and upsetting plans cannot be mistakes to these people, only willful
acts of destruction, which only severe punishment can cure, and they
are never sufficiently humble to even consider the possibility that
they are the first to break any rules on purpose. People who plan too
much are also unable to enjoy or cope intelligently with surprises,
for any surprise is evidence of their insufficient planning.
The important distinction between planners and creators is whether an
action taken for a given purpose does or does not provide feedback to
the decision machinery that determines the next action. Listening to
feedback is not an option if you want to retain your mental health,
but listening to feedback will frequently mean that any plans you had
must be discarded. The more energy you have poured into planning, the
less likely you are to listen to feedback that it is junk. If you
make up your mind that the world is different than it is, that it
�ought� to be different, you will run into psychological problems, the
larger the more you insist. A lot of people believe that standing
fast in their beliefs is the hallmark of integrity and that it is the
duty of all people of true belief to force other people to obey their
beliefs. These days, we call them fundamentalists and terrorists, but
in the world of software development, we have no such useful labels
for those of deranged psychology and highly irrational beliefs, but
they are nonetheless present in the industry. The most effective test
they can be put to is whether /all/ actions taken by programmers are
able to provide feedback to the planning and scheduling of the whole
project, or only /some/ actions (of the selection of which they demand
to be the final arbiter).
If /all/ actions taken by programmers are used for feedback, the best
way to view the act of programming is that of producing information
about the problem to be solved. Some of it may be wrong, some of it
may be of no use, some of it may be unexpectedly true and need work to
be proven, but all of it is used as feedback. This is obviously not
the dichotomous relationship with planning that some people think it
is -- if you are both intelligent and of sound mental health, you do
not plan your actions, you plan your results and the acceptable costs,
and you trust both your own competence and that of others in actually
accomplishing those goals without detailed instructions. Some of the
time, however, an action may produce information that will affect the
results and the costs, and it is at this point that a rational manager
listens and an irrational manager ignores the available corrective
feedback. When all actions are used for feedback, the consequence of
making mistakes will be a corrective and appropriate response, because
everything everybody does /matters/.
If only /some/ actions taken by a programmer are used for feedback,
the result will necessarily be that programmers will perform actions
that are not used for feedback with reckless abandon. In this regime,
the already tyrannical manager will write ever more detailed plans to
enforce his model of reality, the stronger the more wrong it is, just
like people who have to be taken care of by society in general because
they have stopped accepting input from the real world. In business,
however, those who keep pushing for something they believe in tend to
be remembered when they have had a string of successes, but there is
now a growing literature on the stupidity of the highly intelligent in
both managing their lives and their money. (E.g., Why Smart People
Can Be So Stupid, edited by Robert J. Sternberg, ISBN 0-300-09033-1.)
It is quite possible for people who watch others who have succeeded by
pushing for something they believed in to believe that it was pushing
for something they believed in that produced the success, but in logic
this is known as the post hoc ergo propter hoc fallacy. In the real
world, pushing for something you believe in generally causes massive
and lasting failure, but if you accidentally get it right, pushing may
magnify the success. This is like performing an objectively insane
action which by sheer accident happens to associate itself in the mind
of the deranged with some random success condition that has nothing
whatsoever to do with the action. You could have worn the same tie
the last three times you won a contract or did a good presentation,
and then suddenly it becomes your �lucky tie�. Lots of people do
this, and such things as astrology and numerology or the importance of
winning New Hampshire because past presidents did, find a receptive
audience in the highly unscientific population. The more /selective/
you are in the feedback you accept, the more insane your reasoning
will become as you will necessarily reject corrective feedback that
would have led to better reasoning.
The point at which it becomes rational and productive to impose one's
will on reality or other people is perhaps the most interesting aspect
of the philosophy of ethics. It is not understood to any significant
degree how to determine this point in advance, so ethical thinking is
best thought of as a systematic approach to respond to objections, but
this imposes a requirement to object, and to do so rationally and only
constructively, which is not as well-defined as it ought to be. The
history of modern societies provide us with the evidence that we have
swerved aimlessly in this regard and are both unsystematic and highly
irrational in our objections and the expression thereof, especially in
cases where the severely misguided notions of �good� and �evil� are
involved, and people conjure up feelings of suffering �injustice�
instead of coping intelligently with the situation at hand. There are
people so devoid of rational ethical thinking that when they observe
something they object to, they do exactly the same thing on purpose in
order to express their objections, and then fail to understand that
they have done something objectionable. Human rights, for instance,
is an expression of a fuzzy line of demarcation around an area where
people are not allowed to impose their will on any other person for
any reason whatsoever. The U.S. Constitution was also thought to have
protected certain rights even under serious threats, but turned out to
be completely irrelevant to the American people. Social security is
an attempt to draw up an area where every citizen must accept the cost
of sustaining other citizens who are unwilling or unable to sustain
themselves, and those who object to this system tend to ignore the
fact that the absence creates slavery and people so desperate that no
law can bind them. The political debates are mostly about which areas
of public and personal life must yield to the imposition of the will
of others. This is far from the obvious and well-known that the mark
of the highly irrational and tyrannical pretends it is: /Nothing/ is
�unconditionally bad�; the will of some people who have made up their
mind about both reality and people /must not/ be imposed or accepted
to be imposed on others to the detriment of the ability to object both
rationally and constructively.
Being intelligent and reasonable human beings with the particular kind
of brain that we possess, we are still not only fallible, but very far
from omniscient. We are also naturally inclined to commit a fallacy
known as conformance bias, which makes us want to prove that what we
already believed was true and to believe faint affirmations even in
the presence of rejection. Another dangerous problem with puny human
brains is that counter-information tends to be rejected because opening
every decision up for re-evaluation would consume infinite resources,
and it also takes too much time and energy to re-evaluate enough to be
able to know whether some counter-information is important or not. For
these reasons, we have set up the extremely inhuman methodology known
as �science�: Figuring out that a particular causal relationship is
for real independent of our desire for it to be is really hard work.
Most people much prefer to believe that what they would like to be
true is also actually true than to do all the hard work to determine
what is and what is not actually true, not the least because most of
what people believe is actually dramatically false. Given what we
know about human fallibility and society-wide myths and beliefs, it
should be obvious that we simply cannot afford to be selective in what
feedback we are willing to accept. Every single relevant, corrective
feedback we refuse to consider will come back to harm us. So, too,
with every rational, constructive objection to what we have done, but
those who are least able to accept corrections are unsurprisingly also
those who are least able to express corrections and objections in a
way that other people can make use of, and they are the first to jump
to conclusions about other people's motives and rush to accusations
and all sorts of counterproductive idiocy. Instead of thinking when
they meet corrective feedback, they defend themselves and stick to
their plans precisely /because/ those plans are in danger of proving
insufficient or wrong, and this is much more likely to happen if the
plans have been very costly to produce.
To strike a balance between planning and creativity, we need to zoom
out and look at the available measurements of the success we have with
our various approaches. To do this, we need to be aware of the goals
we have for our work at a sufficiently abstract level. The more we
plan, the more concrete our goals become, however, and the danger of
planning to avoid costly mistakes in achieving our goals is that we no
longer remember what we were originally heading out to accomplish.
The most productive plan, then, must be the plan that is not concrete,
but abstract, yet has definite test criteria. The distinction between
a plan and a vision is therefore only in the availability of the tests
we can employ to know if we have gotten where we wanted to get. This
is the kind of plan that is incommunicable to computers at present, so
we are in no danger of confusing a program with its intention, just as
we are never in danger of confusing a test harness with the objective
of the whole endeavor.
The notion that planning at the detail level is a necessary product of
good planning at the abstract goal level is itself a product of the
kind of personality disorder that prevent creative people and experts
from producing the desirable results. This kind of planning is only a
good thing if you plan to hire monkeys who respond well to electric
shocks when they deviate from their instructions. Human beings are
not computers or physical devices and planning for intelligent people
is different from planning for morons. Most planners also believe
that they are vastly more intelligent than the people who are going to
implement the plan in practice. More often than not, however, they
are not noticeably more intelligent and the belief that one person can
plan what another person should do is a very good way of making the
person who plans unable to accept negative feedback from the stupider
person who implements it and the person who performs the planned steps
is unlikely to invoke their intelligence when the plans are bad, so
excessive planning is a very good way of destroying productivity and
/avoiding/ the abstract goals of an enterprise entirely.
However, we must take the planners' word for it -- they could never
employ their creativity and intelligence in the face of unexpected
situations and their fear of failure is probably well-founded, so if a
person demands detailed plans, we should feel a profound pity for
their damaged psychology and inferior brainpower and help them write
their plans and ensure that they measure only irrelevant properties of
the system being developed so they are kept busy without messing up
for anyone who have do to deal work. In this regard, we should go
talk to the social science people, because they educate a lot of the
bureaucrats who prevent politicians from doing more damage than they
absolutely have to with their misguided micro-controlled plans.
--
Erik Naggum | Oslo, Norway 2004-031
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Gareth McCaughan <················@pobox.com> writes:
> - Some problems are so easy that there is scarcely any
> chance that either the spec or the code you'd write
> would need changing. For such problems, Joel Spolsky's
> argument for spec writing doesn't apply. (There might
> be other reasons to write a spec, such as being
> required to by your employer or wanting to use it
> as documentation for later users of the program.)
For example, (some chapters of) the ANSI CL spec. Sure, specifying
exactly what REMOVE is supposed to do seems trivial, but it's important
when you want to make sure that it'll work the same way and with the
same interface on another implementation.
> - The problem (or a subproblem) may have the form
> "Make the customer happy"; the customer may be
> unable to tell you reliably what will make him
> happy. (Good user interfaces, like pornography,
> are more easily recognized than defined. I make
> no claim that good user interfaces should be
> like pornography in any other respect.) Sometimes
> the customer thinks he knows, or claims he knows,
> but that turns out not to be so.
Don't I know it. (Pun intended.) But then again, isn't the whole point
of writing software to make the customer happy? I mean, if code is
written to a disk but no one runs it, was it really written?
> - The data to be fed to one part of the system
> may be generated by another part, and there
> may be no available way to predict what that
> data will be until that other part of the system
> is in place. It may not be possible to make a
> sensible choice of how to design the later part
> of the system until much is known about the
> data it will be receiving.
Don't I know this one, too.
> Indeed it is. CL is a great language for "working out the solution
> while coding", and I happen to agree with Erik that that isn't
> always a bad thing. But it's also worth pointing out that even
> if it were, unconditionally, a bad thing, that wouldn't be any
> argument against CL; it would just mean that one often-repeated
> argument *for* CL would be invalid.
Well, if your original CL code is the spec and you're working out the
solution for how to translate that spec into CL using macros, then it's
surely not invalid. :)
From what I read about this Spolsky fellow, he doesn't seem to know
about the concept of an application written in a language that was
designed specifically for that application.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Erann Gat wrote:
> The most fruitful response to this is not to try to discredit me by
> setting up a caricature of my views as a straw man, but rather to attack
> the issue at its root and explain *why* it is *not* in fact a good idea to
> write a complete spec "describing how the program works in minute detail"
> before starting to write code. Possible responses include things like,
> "Because it is not possible to do so in general" (to which I will respond:
> can you cite an example of such a case?) or "Because a spec can only be
> written in response to a complete set of requirements, which is generally
> unavailable" or something like that.
To me, this immediately brings up the question: "What *exactly* do you mean
by a 'complete spec.'"
I see a couple of main reasons to produce a spec of some sort:
1. The original top-level spec is typically produced by the "marketing" guys
(and I use that word losely, as I'm technically one of those guys during
the work-day). This spec is the one you show to the customers to get
initial feedback. It's pretty high level, dropping down to lower levels
when required because a particular feature or facet of the system is very
important and if you don't spec it, the coder is likely to miss it and get
the detail wrong. That said, this is not at nearly the level of most design
docs.
2. Developing some level of design doc helps the programmer to work through
the large-scale architecture issues before he starts laying down code. I do
this myself, even when programming my own projects. This doesn't have to be
a fully detailed spec. It can take the form of notes, design ideas, etc.,
banged out in emacs. It just helps to frame your thinking. In particular,
it can be very useful to work through user workflows to see how the system
will really work in the end and streamline things (think usecases here).
3. Finally, depending on the team size, some level of spec is very useful
for keeping the team on track. It is true that test engineers have to have
something to which to compare the functioning program and determine if the
behavior is correct or incorrect. It's also true that you can't get the
docs people to read the code. Given this, if your team is large (> 10
people total), distributed (even just in different buildings on the same
campus), or even just overworked and busy, it helps to have some level of
document that gets everybody on the same page.
Now, Joel seems to claim that these are all the same "detailed" document,
written by the programmer. I don't support that. I think it's probably two
documents (1 and 2/3). The first is written by the product managers. The
second (2/3) is written by engineering, and may have a couple of sections
corresponding to 2 and 3. The level of those sections may be different,
however.
The requirement for level of detail in all this is highly dependent on team
size, distribution, and dynamics. If you have a total team size of five,
all sitting within earshot of each other, that allows you to get away with
a lot less. If you have a cast of thousands, with sub-contractors, etc.,
then you'll need a more detailed document or things won't come together in
the end, and no amount of dynamic Lisp will make up for that issue.
So, is Joel right? In spirit, most certainly. In practice? Depends heavily
on your particular situation.
Nepheles wrote:
> Where do people feel Lisp is going? How will popularity change? Is
> Lisp threatened by upstarts like Python? Will Lisp become more
> acceptable for general application development? Etc...
Lisp is a bit like nuclear energy: It's not en vogue, but it's going
to power human civilization for a long time.
I expect Lisp to rise from AI winter ashes when mainstream computing
reaches a complexity comparable to the most advanced systems built
on Lisp Machines in the 80's. In fact it's happening already.
Mark Giuliano provided some entertaining insights into large scale
systems during his "Advanced CLOS Meta Object Protocol" tutorial at
ILC03. The necessity to maintain and improve on large scale systems
at runtime will increase and Common Lisp provides by far the best
environment to deal with code complexity.
I don't think Common Lisp is threatened at all. Lisp is not
dead, it just smells funny.
-fix
--
------- Markus Fix http://www.bookfix.com/ --------
--------Creating the Programmer's Library----------
Nepheles wrote:
> Where do people feel Lisp is going? How will popularity change? Is
> Lisp threatened by upstarts like Python? Will Lisp become more
> acceptable for general application development? Etc...
I don't think that direct answers to these questions help. The choice
for a programming language shouldn't be a popularity contest.
Here is a good answer, IMHO: http://www.paulgraham.com/icad.html
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."