This one has absolutely nothing to do with Lisp!
http://smuglispweeny.blogspot.com/2008/03/we-can-live-with-way-you-handled-that.html
It does, however, cover God, Plato, and the Tao.
hth, kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Sat, 22 Mar 2008 20:08:33 -0400, Ken Tilton wrote:
> This one has absolutely nothing to do with Lisp!
>
>
> http://smuglispweeny.blogspot.com/2008/03/we-can-live-with-way-you-
handled-that.html
>
>
> It does, however, cover God, Plato, and the Tao.
>
> hth, kenny
Keep them coming dude.
--
Sohail Somani
http://uint32t.blogspot.com
Sohail Somani wrote:
> On Sat, 22 Mar 2008 20:08:33 -0400, Ken Tilton wrote:
>
>
>>This one has absolutely nothing to do with Lisp!
>>
>>
>>http://smuglispweeny.blogspot.com/2008/03/we-can-live-with-way-you-
>
> handled-that.html
>
>>
>>It does, however, cover God, Plato, and the Tao.
>>
>>hth, kenny
>
>
> Keep them coming dude.
>
Thanks, next one will almost be about Lisp: it will be about agile over
unagile.
btw, isn't it amusing that our big ball of mud wthe Scheme-crushing
index is a "lightweight" language?
Hmmmmm....
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Sat, 22 Mar 2008 21:05:09 -0400, Ken Tilton wrote:
> Sohail Somani wrote:
>> Keep them coming dude.
>>
>>
> Thanks, next one will almost be about Lisp: it will be about agile over
> unagile.
>
> btw, isn't it amusing that our big ball of mud wthe Scheme-crushing
> index is a "lightweight" language?
How many Schemers does it take to change a light bulb?
Eventually a Common Lisp programmer changes it because the Schemers were
all worried about the side-effects!
Ok, I made that up.
Looking forward to your next entertaining post...
--
Sohail Somani
http://uint32t.blogspot.com
Sohail Somani <······@taggedtype.net> writes:
> On Sat, 22 Mar 2008 21:05:09 -0400, Ken Tilton wrote:
>
> > Sohail Somani wrote:
>
> >> Keep them coming dude.
> >>
> >>
> > Thanks, next one will almost be about Lisp: it will be about agile over
> > unagile.
> >
> > btw, isn't it amusing that our big ball of mud wthe Scheme-crushing
> > index is a "lightweight" language?
>
> How many Schemers does it take to change a light bulb?
>
> Eventually a Common Lisp programmer changes it because the Schemers were
> all worried about the side-effects!
>
> Ok, I made that up.
>
> Looking forward to your next entertaining post...
Lest they think we're mean-spirited about them, I sort of imagine the
Schemers probably have the reverse sentiment...
How many CL programmers does it take to change a light bulb?
None. They don't want to be enlightened.
On Mar 22, 11:33 pm, Kent M Pitman <······@nhplace.com> wrote:
> Sohail Somani <······@taggedtype.net> writes:
> > On Sat, 22 Mar 2008 21:05:09 -0400, Ken Tilton wrote:
>
> > > Sohail Somani wrote:
>
> > >> Keep them coming dude.
>
> > > Thanks, next one will almost be about Lisp: it will be about agile over
> > > unagile.
>
> > > btw, isn't it amusing that our big ball of mud wthe Scheme-crushing
> > > index is a "lightweight" language?
>
> > How many Schemers does it take to change a light bulb?
>
> > Eventually a Common Lisp programmer changes it because the Schemers were
> > all worried about the side-effects!
>
> > Ok, I made that up.
>
> > Looking forward to your next entertaining post...
>
> Lest they think we're mean-spirited about them, I sort of imagine the
> Schemers probably have the reverse sentiment...
>
> How many CL programmers does it take to change a light bulb?
>
> None. They don't want to be enlightened.
Indeed, I've spent the last few days porting to PLT Scheme
a web app that we wrote in CL. Quite enlightening. I'm
starting to wonder if the only CL feature *really* missing
from Scheme is Kenny Tilton ;-)
-Mike
Michael J. Forster <····@sharedlogic.ca> wrote:
+---------------
| I've spent the last few days porting to PLT Scheme
| a web app that we wrote in CL. Quite enlightening.
+---------------
Please do share some of your experience. A long time ago
(circa 2001) I ported some web apps I'd written in PLT
Scheme (raw MzScheme, actually) to CMUCL, which was
basically no trouble at all. But then, I wasn't using
anything really obscure from MzScheme other than what
was in the "cgi.ss" library at the time. [I just whipped
up a small CGI package in CL, plus I used HTOUT for the HTML
generation rather than duplicating the "generate-html-output"
stuff in MzScheme.] I'd be interested in hearing what
surprises/difficulties you encountered going the other way...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Kent M Pitman <······@nhplace.com> writes:
> How many CL programmers does it take to change a light bulb?
>
They don't, they write a handler for the burnt-out-bulb
exception:
CL-USER> (handler-bind ((burnt-out-bulb (lambda(condition)
(declare (ignore condition))
(change-light-bulb)
(invoke-restart 'changed))))
(progn
(restart-case
(unless (eql *light-bulb* 'intact)
(signal 'burnt-out-bulb))
(changed ()))
*light-bulb*))
Changing bulb
INTACT
Alan Crowe
Edinburgh
Scotland
Alan Crowe <····@cawtech.freeserve.co.uk> writes:
> Kent M Pitman <······@nhplace.com> writes:
> > How many CL programmers does it take to change a light bulb?
> >
>
> They don't, they write a handler for the burnt-out-bulb
> exception:
Which for the original joke
Q: How many Common Lisp programmers does it take to change a light bulb?
suggests the obvious alternative endings ...
A: None. We've got the situation handled.
Then again, you might want to go with...
A: Trick question. Common Lisp is an industrial strength language,
so light bulbs implemented in Common Lisp don't burn out.
or
A: CL lightbulbs don't need to be changed. If they encounter problems,
the problems can be repaired in the debugger and then the existing use
continued.
or
A: No, no, no. When we said the light bulb was non-functional, we just
meant it lit things by side-effect, not that it wasn't working.
It doesn't need to be changed after all...
... Just go on about your business; CL is not a light-wait language.
On Mar 25, 1:58 am, Kent M Pitman <······@nhplace.com> wrote:
> Alan Crowe <····@cawtech.freeserve.co.uk> writes:
> > Kent M Pitman <······@nhplace.com> writes:
> > > How many CL programmers does it take to change a light bulb?
>
> > They don't, they write a handler for the burnt-out-bulb
> > exception:
>
> Which for the original joke
>
> Q: How many Common Lisp programmers does it take to change a light bulb?
>
> suggests the obvious alternative endings ...
>
> A: None. We've got the situation handled.
>
> Then again, you might want to go with...
>
> A: Trick question. Common Lisp is an industrial strength language,
> so light bulbs implemented in Common Lisp don't burn out.
>
> or
>
> A: CL lightbulbs don't need to be changed. If they encounter problems,
> the problems can be repaired in the debugger and then the existing use
> continued.
>
> or
>
> A: No, no, no. When we said the light bulb was non-functional, we just
> meant it lit things by side-effect, not that it wasn't working.
> It doesn't need to be changed after all...
>
> ... Just go on about your business; CL is not a light-wait language.
I don't know if these are good, but they may please the typing crowd.
Q: How many OCaml programmers does it take to change a light bulb?
A: Eventually a CL programmer does, because the OCaml programmers
refuse to figure out what type of light bulb they need by looking at
the socket.
Q: How many CL programmers does it take to change a light bulb?
A: Eventually an OCaml programmer does it because the CL programmers
don't know what type of light bulb they need.
There! Everybody should be happy now.
Cheers
--
Marco
Kent M Pitman wrote:
> Alan Crowe <····@cawtech.freeserve.co.uk> writes:
>
>> Kent M Pitman <······@nhplace.com> writes:
>>> How many CL programmers does it take to change a light bulb?
>>>
>> They don't, they write a handler for the burnt-out-bulb
>> exception:
>
> Which for the original joke
>
> Q: How many Common Lisp programmers does it take to change a light bulb?
>
> suggests the obvious alternative endings ...
>
> A: None. We've got the situation handled.
>
> Then again, you might want to go with...
>
> A: Trick question. Common Lisp is an industrial strength language,
> so light bulbs implemented in Common Lisp don't burn out.
>
> or
>
> A: CL lightbulbs don't need to be changed. If they encounter problems,
> the problems can be repaired in the debugger and then the existing use
> continued.
>
> or
>
> A: No, no, no. When we said the light bulb was non-functional, we just
> meant it lit things by side-effect, not that it wasn't working.
> It doesn't need to be changed after all...
>
> ... Just go on about your business; CL is not a light-wait language.
Here is the ContextL version:
Q: How many programmers does it take to change a light bulb?
A: Depends on the context.
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
I have one complaint about your blogging Kenny, you should have
started earlier.
Nice jokes Sohail, Kent.
cheers
Slobodan
http://tourdelisp.blogspot.com/
Slobodan Blazeski wrote:
> I have one complaint about your blogging Kenny, you should have
> started earlier.
Thx, we might agree. :) It's fun, beats programming.
Gotta do a Lisp entry soon, tho, live up to the blog title.
kzo
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ken Tilton <···········@optonline.net> writes:
> This one has absolutely nothing to do with Lisp!
>
>
> http://smuglispweeny.blogspot.com/2008/03/we-can-live-with-way-you-handled-that.html
Throw it in an XP group and see what happens :-)
S.
Stefan Arentz wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>
>>This one has absolutely nothing to do with Lisp!
>>
>>
>>http://smuglispweeny.blogspot.com/2008/03/we-can-live-with-way-you-handled-that.html
>
>
> Throw it in an XP group and see what happens :-)
?????
I mean, no, I am not going to, not sure where to find one or I might,
but I /am/ curious as to your prediction.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ken Tilton <···········@optonline.net> writes:
> Stefan Arentz wrote:
>> Ken Tilton <···········@optonline.net> writes:
>>
>>
>>>This one has absolutely nothing to do with Lisp!
>>>
>>>
>>>http://smuglispweeny.blogspot.com/2008/03/we-can-live-with-way-you-handled-that.html
>>
>>
>> Throw it in an XP group and see what happens :-)
>
> ?????
>
> I mean, no, I am not going to, not sure where to find one or I might,
> but I /am/ curious as to your prediction.
Well, according to Agile Believes <tm>, the end product WILL most
definitely vary extremely from the original :-)
This of course conflicts with Tilton's third law:
"Refinements to requirements cannot vary fundamentally from the
original"
And no, it's not pair programming if it is just you and your friend
the REPL.
S.
Stefan Arentz wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>
>>Stefan Arentz wrote:
>>
>>>Ken Tilton <···········@optonline.net> writes:
>>>
>>>
>>>
>>>>This one has absolutely nothing to do with Lisp!
>>>>
>>>>
>>>>http://smuglispweeny.blogspot.com/2008/03/we-can-live-with-way-you-handled-that.html
>>>
>>>
>>>Throw it in an XP group and see what happens :-)
>>
>>?????
>>
>>I mean, no, I am not going to, not sure where to find one or I might,
>>but I /am/ curious as to your prediction.
>
>
> Well, according to Agile Believes <tm>, the end product WILL most
> definitely vary extremely from the original :-)
>
> This of course conflicts with Tilton's third law:
>
> "Refinements to requirements cannot vary fundamentally from the
> original"
Probably the word "fundamentally" is wrong. Not sure what word is
better, so I gave the example of folks running the paths in baseball.
extreme variation? ok, one can sensibly travel a huge distance in
plausible human steps but along the way one will not have to shift even
a short distance by a discontinuous teletransporting leap.
btw, there is an exception to all this, the user's just did not go
there. especially in an old industry like banking one can get bizarro
practices that resist elegant solution. Indeed, look our for an upcoming
TLOP talking about how the solution should map isomorphically onto the
solution, including looking ugly where the problem is ugly. Kinda like
einstein's as simple as possible but no simpler.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Tue, 25 Mar 2008 20:41:58 -0400, Ken Tilton wrote:
> Probably the word "fundamentally" is wrong. Not sure what word is
> better, so I gave the example of folks running the paths in baseball.
I think fundamental is the right word. Maybe the analogy would have been
better understood if (for example) you wanted to change from playing on
grass to ice.
Or not.
--
Sohail Somani
http://uint32t.blogspot.com
Sohail Somani wrote:
> On Tue, 25 Mar 2008 20:41:58 -0400, Ken Tilton wrote:
>
>
>>Probably the word "fundamentally" is wrong. Not sure what word is
>>better, so I gave the example of folks running the paths in baseball.
>
>
> I think fundamental is the right word. Maybe the analogy would have been
> better understood if (for example) you wanted to change from playing on
> grass to ice.
>
> Or not.
>
I think not. Hell, you have me wanting to go find a frozen lake and play
some ball. Those crampons have to be somewhere...
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Tue, 25 Mar 2008 20:41:58 -0400, Ken Tilton wrote:
<snipitty>
> btw, there is an exception to all this, the user's just did not go
> there. especially in an old industry like banking one can get bizarro
> practices that resist elegant solution. Indeed, look our for an upcoming
> TLOP talking about how the solution should map isomorphically onto the
> solution, including looking ugly where the problem is ugly. Kinda like
> einstein's as simple as possible but no simpler.
>
>
> kt
Wait that's mine! Well, almost.
There's no such thing as the incompetence (incomputence?) fairy. If I
misspell "ambulance" it will not come out "pizza".