Does anyone have any experience applying this methodology to
Lisp-based projects?
I read the web site yesterday and it looked like they have interesting
ideas, which Lisp would fit rather well, although I'm generally a bit
distrustful of `methodologies' to put it mildly...
I'm asking because I'm working somewhere where there is a requirement
for *some* kind of accepted process (huge company, huge client and so
on) but where the release schedule is really too fast for what the
processes that exist can do, and I'm wondering about suggesting a
guerilla reimplementation using some much faster process. There are
some other technical issues alas which probably kill a Lisp solution
in the long term but a fast answer might hold the fort long enough for
those to be overcome.
Thanks
--tim
The first time I saw the Extreme Programming book, I told a friend
I thought it should be called "The Lisp Way". From my point of
view, it's basically how to program in a good Lisp environment,
without, perhaps, using lisp. I didn't read the whole book, but
I found nothing new that was helpful in my brief examination of it.
Brad Lucier
Bradley J Lucier wrote:
> The first time I saw the Extreme Programming book, I told a friend
> I thought it should be called "The Lisp Way". From my point of
> view, it's basically how to program in a good Lisp environment,
> without, perhaps, using lisp. I didn't read the whole book, but
> I found nothing new that was helpful in my brief examination of it.
Well, XP comes out of the Smalltalk world, and things are
quite similar there -- sophisticated development environments,
very dynamic language, most programmers are rather cleverer
than the average, and so on. So it's not surprising that there
are similarities. If by "the Extreme Programming book" you mean
"Extreme Programming Explained: Embrace Change" (ugh, what a
terrible title), then you shouldn't expect to find anything
very interesting in it -- it's all tremendously vague. "Extreme
Programming Installed" has much more detail.
I'm afraid I haven't anything very helpful to say to the
original questioner; almost all my programming is done on
my own, which puts a lot of the XP practices out of
consideration.
--
Gareth McCaughan ················@pobox.com
sig under construc
···@cs.purdue.edu (Bradley J Lucier) writes:
> The first time I saw the Extreme Programming book, I told a friend
> I thought it should be called "The Lisp Way". From my point of
> view, it's basically how to program in a good Lisp environment,
> without, perhaps, using lisp. I didn't read the whole book, but
> I found nothing new that was helpful in my brief examination of it.
>
Oh no, I think there's more too it than that. For instance one of the
things they say is this business about doing minimal design -- solve
the problem at hand, don't try to generalise until you have to &c. I
think that's almost the opposite of the `MIT way' of writing Lisp
systems where people really try to be very general and think ahead.
--tim
Tim Bradshaw <···@tfeb.org> writes:
[...]
> Oh no, I think there's more too it than that. For instance one of the
> things they say is this business about doing minimal design -- solve
> the problem at hand, don't try to generalise until you have to &c. I
> think that's almost the opposite of the `MIT way' of writing Lisp
> systems where people really try to be very general and think ahead.
When I first heard the term "extreme programming" it immediately
triggered the same synapses as "for idiots" and "in 21 days". I try
hard to pretend that all this revolting tripe has nothing to do with
my profession or my peers. (So, obviously, I haven't read the material.)
I sincerely hope that this "minimal design" business is part of a
passage about project triage or exploratory prototyping...
My curiosity has been piqued now -- but not in a good way. I'll bite
my tongue and reserve further comment until I've actually read some of
this stuff.
-- Kaelin
Kaelin Colclasure <······@everest.com> writes:
> Tim Bradshaw <···@tfeb.org> writes:
>
> [...]
> > Oh no, I think there's more too it than that. For instance one of the
> > things they say is this business about doing minimal design -- solve
> > the problem at hand, don't try to generalise until you have to &c. I
> > think that's almost the opposite of the `MIT way' of writing Lisp
> > systems where people really try to be very general and think ahead.
>
> When I first heard the term "extreme programming" it immediately
> triggered the same synapses as "for idiots" and "in 21 days". I try
> hard to pretend that all this revolting tripe has nothing to do with
> my profession or my peers. (So, obviously, I haven't read the material.)
>
> I sincerely hope that this "minimal design" business is part of a
> passage about project triage or exploratory prototyping...
>
> My curiosity has been piqued now -- but not in a good way. I'll bite
> my tongue and reserve further comment until I've actually read some of
> this stuff.
Well, for a concise overview I went to this web site:
<http://www.extremeprogramming.org/>
I am relieved and pleased to see that, based on the material presented
there, extreme programming does appear to espouse sound and
responsible engineering practices. Apparently you can't judge a book
by its cover. :-) [I still think the name is a bit unfortunate -- but
perhaps "extreme" measures are required to get people's attention
these days.]
Tim, you've undoubtedly read more that I on this topic, but I really
did not take away the impression that your statement quoted above
gave. Take, for instance, this confusingly worded quote from the Web
site:
"Software which is engineered to be simple
and elegant is no more valuable than software that is
complex and hard to maintain. Can this really be
true? Extreme Programming (XP) is based on the
idea that this is not in fact true."
In other words, simplicity and elegance are valuable characteristics,
and thus are important goals to strive for in software engineering.
The site then goes on to espouse the virtues of frequent refactoring,
continuous testing, etc. All motherhood and apple pie in my book. And
certainly all in accordance with "the MIT way." [And "the New Jersey
way" for that matter -- the essential difference between the two being
the precise definition of "simplicity."]
-- Kaelin
Kaelin Colclasure <······@everest.com> wrote:
> Well, for a concise overview I went to this web site:
>
> <http://www.extremeprogramming.org/>
Also look at <http://www.xprogramming.com/>, IMHO the canonical starting
point for online information on XP.
More dynamic info on XP can be found starting at
<http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap>.
Michael
--
Michael Schuerig
···············@acm.org
http://www.schuerig.de/michael/
Kaelin Colclasure <······@everest.com> writes:
>
> Tim, you've undoubtedly read more that I on this topic, but I really
> did not take away the impression that your statement quoted above
> gave. Take, for instance, this confusingly worded quote from the Web
> site:
>
Well I think there is other stuff in there which implies what I
claimed -- for instance in
wwww.extremeprogramming.com/rules/early.html they say:
Turn a blind eye towards future requirements and extra
flexibility. Concentrate on what is scheduled for today only.
and various other stuff. For someone (like me) who has spent a lot of
time trying to produce general, reusable code, this is quite
unnerving. But actually it's pretty interesting, as a lot of the
`reusable', `general' design that gets done actually isn't. It's also
very similar, I think, to what Richard Gabriel argues for. Lisp is
also terribly well suited to this kind of thing, as it's so fluid and
easy to redefine stuff.
Incidentally, like you I find the name really horrible and offputting,
but I think that they actually have some interesting ideas, and
although I'm really not a great methodology person, this looks like
not such a bad one.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> Kaelin Colclasure <······@everest.com> writes:
>
> >
> > Tim, you've undoubtedly read more that I on this topic, but I really
> > did not take away the impression that your statement quoted above
> > gave. Take, for instance, this confusingly worded quote from the Web
> > site:
> >
>
> Well I think there is other stuff in there which implies what I
> claimed -- for instance in
> wwww.extremeprogramming.com/rules/early.html they say:
>
> Turn a blind eye towards future requirements and extra
> flexibility. Concentrate on what is scheduled for today only.
>
> and various other stuff. For someone (like me) who has spent a lot of
> time trying to produce general, reusable code, this is quite
> unnerving. But actually it's pretty interesting, as a lot of the
> `reusable', `general' design that gets done actually isn't. It's also
> very similar, I think, to what Richard Gabriel argues for. Lisp is
> also terribly well suited to this kind of thing, as it's so fluid and
> easy to redefine stuff.
Hmmm, I couldn't resolve that URL (I did drop the extra #\w). I was
hoping to get a feel for how broadly they propose this mindset should
be applied. The context could make some difference here.
It's certainly true that many engineer/hours get wasted needlessly,
because of a fundamental lack of "bigger picture" perspective. But
this is where industry experience comes into play. [I mean experience
measured in years and decades, not weeks and months.] And, at least in
my personal experience, lossage due to "over-engineering" ranks in the
noise when compared to lossage incurred chasing that most holy of
grails -- efficiency. Of course, I count almost every piece of
application software written in C or C++ in the past five or six years
as at least 50% lossage... :-) [And yes, I've wasted plenty of time
there myself.]
> Incidentally, like you I find the name really horrible and offputting,
> but I think that they actually have some interesting ideas, and
> although I'm really not a great methodology person, this looks like
> not such a bad one.
I agree that they've collected some interesting ideas, and I certainly
agree that an organization could do a lot worse in choosing a
methodology to adopt! :-)
-- Kaelin
Kaelin Colclasure <······@everest.com> wrote:
+---------------
| Tim Bradshaw <···@tfeb.org> writes:
| > wwww.extremeprogramming.com/rules/early.html they say:
| >
| > Turn a blind eye towards future requirements and extra
| > flexibility. Concentrate on what is scheduled for today only.
|
| Hmmm, I couldn't resolve that URL (I did drop the extra #\w).
+---------------
Try <URL:http://www.extremeprogramming.org/rules/early.html>.
[The .com site is some guys who build websites, and don't seem
to have anything to do with XP per se.]
-Rob
-----
Rob Warnock, 31-2-510 ····@sgi.com
Network Engineering http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
On 16 Dec 2000 07:33:05 -0800, Kaelin Colclasure <······@everest.com>
wrote:
> My curiosity has been piqued now -- but not in a good way. I'll bite
> my tongue and reserve further comment until I've actually read some of
> this stuff.
Some basic resources:
Extreme Programming: A Gentle Introduction
http://www.extremeprogramming.org/
Extreme Programming
http://c2.com/cgi/wiki?ExtremeProgramming
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
···@cs.purdue.edu (Bradley J Lucier) writes:
> The first time I saw the Extreme Programming book, I told a friend
> I thought it should be called "The Lisp Way". From my point of
> view, it's basically how to program in a good Lisp environment,
> without, perhaps, using lisp. I didn't read the whole book, but
> I found nothing new that was helpful in my brief examination of it.
There are some very fundamental differences to the Lisp way IMHO. One
of the tenets of XP is "You Aren't Gonna Need It" which strongly
prohibits people from doing anything more then the problem requires
right now, no generalisations allowed. Also they're very much against
hooks etc. I'd say XP is more the New Jersey way of continuous
hacking, saved by an emphasis on refactoring and more advanced
programming environments.
--
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
Lieven Marchand <···@bewoner.dma.be> writes:
> ···@cs.purdue.edu (Bradley J Lucier) writes:
> > The first time I saw the Extreme Programming book, I told a friend
> > I thought it should be called "The Lisp Way". From my point of
> > view, it's basically how to program in a good Lisp environment,
> > without, perhaps, using lisp. I didn't read the whole book, but
> > I found nothing new that was helpful in my brief examination of it.
> There are some very fundamental differences to the Lisp way
> IMHO. One of the tenets of XP is "You Aren't Gonna Need It" which
> strongly prohibits people from doing anything more then the problem
> requires right now, no generalisations allowed. Also they're very
> much against hooks etc. I'd say XP is more the New Jersey way of
> continuous hacking, saved by an emphasis on refactoring and more
> advanced programming environments.
Remember that the material is _largely_ focusing on incremental work
done in dynamic programming environments.
The dynamic part obviates the _usual_ problem with "not always trying
to think ahead" that you suffer from being forever stuck with whatever
the initial design pops out because it's too hard to change it later.
They're _depending_ on the idea that if the problem is understood
wrongly, the environment can support fixing things up.
Furthermore, there's an interesting subtlety here; you're supposed to
solve the problem you know about, and focus on finding out the nature
of the problems, as opposed to the more usual situation of trying to
retrofit the operation into whatever "best practices" the software
already dictates that they're going to have to _pretend_ are
representative of their system...
--
(reverse (concatenate 'string ····················@" "454aa"))
<http://www.ntlug.org/~cbbrowne/>
"Wow! You read advocacy groups once in a while, thinking you'll find
the occasional gem, but when you unearth the Taj Mahal you still have
to stand back and gape a little." -- Paul Phillips <·····@go2net.com>
In article <·······················@news1.giganews.com>, ········@hex.net wrote:
>Lieven Marchand <···@bewoner.dma.be> writes:
>> ···@cs.purdue.edu (Bradley J Lucier) writes:
>> > The first time I saw the Extreme Programming book, I told a friend
>> > I thought it should be called "The Lisp Way". From my point of
>> > view, it's basically how to program in a good Lisp environment,
>> > without, perhaps, using lisp. I didn't read the whole book, but
>> > I found nothing new that was helpful in my brief examination of it.
>
>> There are some very fundamental differences to the Lisp way
>> IMHO. One of the tenets of XP is "You Aren't Gonna Need It" which
>> strongly prohibits people from doing anything more then the problem
>> requires right now, no generalisations allowed. Also they're very
>> much against hooks etc. I'd say XP is more the New Jersey way of
>> continuous hacking, saved by an emphasis on refactoring and more
>> advanced programming environments.
>
>Remember that the material is _largely_ focusing on incremental work
>done in dynamic programming environments.
>
>The dynamic part obviates the _usual_ problem with "not always trying
>to think ahead" that you suffer from being forever stuck with whatever
>the initial design pops out because it's too hard to change it later.
>
>They're _depending_ on the idea that if the problem is understood
>wrongly, the environment can support fixing things up.
>
>Furthermore, there's an interesting subtlety here; you're supposed to
>solve the problem you know about, and focus on finding out the nature
>of the problems, as opposed to the more usual situation of trying to
>retrofit the operation into whatever "best practices" the software
>already dictates that they're going to have to _pretend_ are
>representative of their system...
From what I have read about XP the idea is to start out with the
simplest possable solution to the problem at hand, I need
something that works now said the boss. Now if the project
is big enough there will be places where you can refactor the
objects into more general parent classes with specific child
classes. With everybody working on all the code there is a
constant peer review going on. If done properly the books
say this will lead to more general objects. The difference
between XP and MIT, as I understand it, is that XP says it
will be general enough for this project and MIT says to try
and make it general enough for all projects. It seems to me
that if XP is done properly across multple related projects
that you could end up with a MIT style set of classes at the
end of the cycle. Aslo do not forget about the constant
testing that is going on with the use of version controle,
you can make any changes you want and see if they work and
if they don't fix them. Another one of the XP ideas is that
the customer knows the problem best so give them something
and see what they like then give them more of that. We
all have had days where we thought we were done and the
customer said "we do not need that but could you add this" or
"we realy need this subset first". XP seems to say since this
always happens lets run with it to give the customer the best
possable value for there money in the most timely fashion.
This all seems to be a good idea in the corporate world.
marc
>--
>(reverse (concatenate 'string ····················@" "454aa"))
><http://www.ntlug.org/~cbbrowne/>
>"Wow! You read advocacy groups once in a while, thinking you'll find
>the occasional gem, but when you unearth the Taj Mahal you still have
>to stand back and gape a little." -- Paul Phillips <·····@go2net.com>
Lieven Marchand <···@bewoner.dma.be> writes:
> There are some very fundamental differences to the Lisp way IMHO. One
> of the tenets of XP is "You Aren't Gonna Need It" which strongly
> prohibits people from doing anything more then the problem requires
> right now, no generalisations allowed. Also they're very much against
> hooks etc.
Yes, but that's balanced by "Once and Only Once", which I take to mean
that generalisation is perfectly fine (and required) if you can prove
a need for it. i.e. after you've already done it once, and you find
you need something similar, you abstract the original code to cope
with both cases. "Do the simplest thing that could possibly work" is
applied to the system as a whole, not individually to the code written
for each requirement.
In short, it's not against abstraction, it's against abstraction that
you don't yet have a need for.
> I'd say XP is more the New Jersey way of continuous
> hacking, saved by an emphasis on refactoring and more advanced
> programming environments.
I'm assuming you're using `hacking' in a slightly perjorative way, and
on that basis I think I disagree. Kent Beck gets asked this question
a lot:
"I have a little rant I do sometimes about how XP is just
hacking. Well, first the customer tells you which two weeks to hack
on first, but then it's just hacking. Well, the iteration plan
breaks down the functionality into tasks, and during the breakdown
you discuss a lot of analysis and design issues with the team, but
then it's just hacking. Well, ..."
(See http://ootips.org/xp.html (scroll down to "More on Design") for
a longer version of the same thing)
I agree that XP is still not the Lisp way - and I don't think the
approach is intended for many of the problems that Lisp is good for.
My impression is that it works best on application programs, and is a
mot such a good fit for designing something like a framework - a
project for which the bottom-up "first, create a domain-specific
language" Lisp approach would fit better.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Generalization has two aspects: (1) that a more general system will
be in some portion more complex because it is expected to handle
a greater variation, and (2) generalization as abstraction that may
be seen as an approximate solution. I.e., in the second case a
generalized solution may be seen as a common component of a
number of related solutions but where the related solutions may
require specific additions to the generalized solution. Generalized
solutions tend toward reuse or initial close approximation better
than specific solutions because specific solutions are by definition
intended to be restricted to an unique or small problem set.
E.g., XP as a methodology is somewhat implied by its proponents
to be a _general_ method, whereas if one was to eschew general
methods according to XP methodology, one would not use XP since
it is a general method.
I suggest that what is required is a balancing of the tradeoffs
between more general methods that can be reused as against any
additional fitting required in using a general method for a specific
case. So there are opposing goals: one needs to generalize to
increase reuse efficiency while avoiding over-generalization that
will make an approximate solution increasingly useless against
any unique requirements and all in the context of minimizing
overall programming effort.
Prototyping and refinement or learning solution methods may be
seen as the increasing refinement of generalized solutions such that
XP's generalization is in the approximation and adaptive refinement.
The argument against generalization is that one does not need to
spend time on solving a more inclusive problem set than the one
required. However, against this minimization of the solution is the
possibility, now likely greatly underutilized, of using the current
solution as a close approximation to other problems. We may be
avoiding over-generalization not because it is inherently inefficient
but because we are not efficiently reusing prior solutions.
Regards,
Neil Nelson
Daniel Barlow <···@telent.net> writes:
> Lieven Marchand <···@bewoner.dma.be> writes:
> > There are some very fundamental differences to the Lisp way IMHO. One
> > of the tenets of XP is "You Aren't Gonna Need It" which strongly
> > prohibits people from doing anything more then the problem requires
> > right now, no generalisations allowed. Also they're very much against
> > hooks etc.
>
> Yes, but that's balanced by "Once and Only Once", which I take to mean
> that generalisation is perfectly fine (and required) if you can prove
> a need for it. i.e. after you've already done it once, and you find
> you need something similar, you abstract the original code to cope
> with both cases. "Do the simplest thing that could possibly work" is
> applied to the system as a whole, not individually to the code written
> for each requirement.
>
> In short, it's not against abstraction, it's against abstraction that
> you don't yet have a need for.
>
But unless you start thinking really hard up front, there is a chance
you're going to miss higher level commonality that doesn't show itself
by the "Once and Only Once" rule. I doubt any amount of refactoring
would come up with a general protocol like the CLOS way of allowing
the programmer to interact with object creation/modification through
SHARED-INITIALIZE and its siblings.
> > I'd say XP is more the New Jersey way of continuous
> > hacking, saved by an emphasis on refactoring and more advanced
> > programming environments.
>
> I'm assuming you're using `hacking' in a slightly perjorative way, and
> on that basis I think I disagree. Kent Beck gets asked this question
> a lot:
>
> "I have a little rant I do sometimes about how XP is just
> hacking. Well, first the customer tells you which two weeks to hack
> on first, but then it's just hacking. Well, the iteration plan
> breaks down the functionality into tasks, and during the breakdown
> you discuss a lot of analysis and design issues with the team, but
> then it's just hacking. Well, ..."
>
> (See http://ootips.org/xp.html (scroll down to "More on Design") for
> a longer version of the same thing)
>
You're bringing up one of my major problems with XP: "The source code
is the design". I agree with the XPers that some methodologies have
made of design a paper mill with few added value, but I absolutely
loathe stuff that is defined by implementation. All too many C++
frameworks I've had the displeasure to use turn programming in a
guessing game. I want to do that: can I override this function in this
class or need I do that function also. No documentation at all about
the protocol, just experiment and fiddle until it works (and gets
broken by the next release of the framework).
--
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
In article <··············@localhost.localdomain>, Lieven Marchand wrote:
>Daniel Barlow <···@telent.net> writes:
>
>> Lieven Marchand <···@bewoner.dma.be> writes:
[snip]
>>
>> I'm assuming you're using `hacking' in a slightly perjorative way, and
>> on that basis I think I disagree. Kent Beck gets asked this question
>> a lot:
>>
>> "I have a little rant I do sometimes about how XP is just
>> hacking. Well, first the customer tells you which two weeks to hack
>> on first, but then it's just hacking. Well, the iteration plan
>> breaks down the functionality into tasks, and during the breakdown
>> you discuss a lot of analysis and design issues with the team, but
>> then it's just hacking. Well, ..."
>>
>> (See http://ootips.org/xp.html (scroll down to "More on Design") for
>> a longer version of the same thing)
>>
>
>You're bringing up one of my major problems with XP: "The source code
>is the design". I agree with the XPers that some methodologies have
>made of design a paper mill with few added value, but I absolutely
>loathe stuff that is defined by implementation. All too many C++
>frameworks I've had the displeasure to use turn programming in a
>guessing game. I want to do that: can I override this function in this
>class or need I do that function also. No documentation at all about
>the protocol, just experiment and fiddle until it works (and gets
>broken by the next release of the framework).
XP does not say do not do a design document, it says do it at the end
of the project, after it is built. With XP that is the only time the
project will be stable enough to document. Also you have a complete
set of tests covering all the functional areas of the project. One
other thing, everybody talks to everybody else and works in the same
area so you could go the person who wrote it and ask them. If a
product ships with out documentation that is a seperate issue entirely.
marc
>
>--
>Lieven Marchand <···@bewoner.dma.be>
>Lambda calculus - Call us a mad club
Lieven Marchand <···@bewoner.dma.be> writes:
>
> But unless you start thinking really hard up front, there is a chance
> you're going to miss higher level commonality that doesn't show itself
> by the "Once and Only Once" rule. I doubt any amount of refactoring
> would come up with a general protocol like the CLOS way of allowing
> the programmer to interact with object creation/modification through
> SHARED-INITIALIZE and its siblings.
My theory is that there are two kinds of thing:
* `language-class' design. This is stuff that ends up as part of a
language. CLOS is language-class design. This is *incredibly
difficult* to do, but whan you get it right you have something which
is really generally useful. If a project to develop an application
undertakes language-class design it's likely to fail due to the huge
cost of doing it right. Language-class design may also implement
substrates rather than solutions -- a good example of this is the
implementation, in the MOP, of facilities sufficient to allow copying
of objects without actually commiting to a specific copying
function, because it turns out to be impossible to implement a
language-class copying function. Of course I would think this was a
good example as I wrote a paper about it...
* `application-specific' design. This is something which is intended
to be just general enough for the problem at hand. It's
deliberately *not* intended to be general enough for everything. An
example of this might be an object copying or equivalence framework:
an application can easily have well-defined notions of these, but
trying to generalise them into a language-class framework is
incredibly difficult (and it turns out that there isn't actually a
generalisation there, so it's also doomed).
I think there's generally held to be a third kind of thing:
* `library-class' design. This is intended to be somehow intermediate
between application-specific and language-class. These libraries
should be reusable across applications
Obviously a huge amount of stuff that is meant to fall into this
category is done. But I think that XP may be claiming (and Richard
Gabriel I think claims this, and I may also be claiming it) that this
is generally worthless. *unless* you do language-class design then
you end up with a lot of stuff that looks reusable but actually is
not. And since language-class design is horribly expensive, then it's
often better just not to try to generalise too far.
--tim
In article <··············@localhost.localdomain>, ···@bewoner.dma.be
says...
> ···@cs.purdue.edu (Bradley J Lucier) writes:
>
> There are some very fundamental differences to the Lisp way IMHO. One
> of the tenets of XP is "You Aren't Gonna Need It" which strongly
> prohibits people from doing anything more then the problem requires
> right now, no generalisations allowed. Also they're very much against
> hooks etc. I'd say XP is more the New Jersey way of continuous
> hacking, saved by an emphasis on refactoring and more advanced
> programming environments.
>
When you have a clear picture about a problem it gives you a clear road-
map (for the needed generalisations). But often, in large projects, you
dont have someone overlooking all of the complexity or all of the
technologies, so making a "simple" starting solution with on-going
refactoring may be the best and fastest way. In that way you avoid wrong
and complex design and tend to simple, clean design.
What I really loved about xP was the very strong accent on refactoring.
And I liked the sentence "We hate visionaries" :) :(
--
Samir Sekkat
Munich, Germany
············@bigfoot.DELETETHIS.com
Samir Sekkat <············@bigfoot.com> writes:
> What I really loved about xP was the very strong accent on refactoring.
Would you mind if I ran screaming around the room for a bit?
--
vsync
http://quadium.net/ - last updated Tue Dec 19 20:37:35 PST 2000
(cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner
(cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil))
vsync <·····@quadium.net> writes:
> Samir Sekkat <············@bigfoot.com> writes:
>
> > What I really loved about xP was the very strong accent on refactoring.
>
> Would you mind if I ran screaming around the room for a bit?
>
What's wrong with it (other than being an overly buzzword-compliant
way of saying `go back and fix the stuff you got wrong')?
--tim
Tim Bradshaw <···@tfeb.org> writes:
> vsync <·····@quadium.net> writes:
>
> > Samir Sekkat <············@bigfoot.com> writes:
> >
> > > What I really loved about xP was the very strong accent on refactoring.
> >
> > Would you mind if I ran screaming around the room for a bit?
> >
>
> What's wrong with it (other than being an overly buzzword-compliant
> way of saying `go back and fix the stuff you got wrong')?
>
That IS what's wrong with it. Why encorouge buzzwords? It seems to
suggest that NOONE had the idea that refining designs according to
your experience was a good idea before 'extreme' programming. Running
screaming around the room is how I feel when I read phrases like "What
I really loved about xP was the very strong accent on refactoring."
Sorry.
Barry.
> . Why encorouge buzzwords?
What?! You don't like buzzwords?! You're no fun.
> It seems to
> suggest that NOONE had the idea that refining designs according to
> your experience was a good idea before 'extreme' programming.
OK, like I replied toTim, my take was "Thank god redesign is getting top billing
over 'get it to work'!"
Do you all understand the power of language? Of course we are all above that, but
what about the mere mortals in cubicles to either side of us? Buzzwords can be
how idea viruses penetrate well-insulated bodies of bad practice. Image is
something, if I recollect Mr Agassi correctly.
I don't think you all have worked in the body shops of systems development. I
have been laughed at and groaned at rather angrily for proposing better
approaches. I have had a manager good-naturedly hide under his desk seeing me
approach for the third time in one day with that "better idea" gleam in my eye.
The people I work with, I tell them the fact that some code works is faint
praise, they look at me like I am from Mars.
Listen, we are the priests, the sainted. We really are holier than them. ya gotta
understand that XP was not written for us, it was written for madding crowd, the
hoy-polloy, the great unwashed...
Don't worry, they won't get it. They will remake it in their own form. Lisp is
safe.
t
Kenny Tilton <·······@nyc.rr.com> writes:
> Listen, we are the priests, the sainted. We really are holier than them. ya gotta
> understand that XP was not written for us, it was written for madding crowd, the
> hoy-polloy, the great unwashed...
If you insist in thinking in these terms, at least learn how to spell
hoi polloi.
--
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
In article <··············@localhost.localdomain>, Lieven Marchand wrote:
>Kenny Tilton <·······@nyc.rr.com> writes:
>
>> Listen, we are the priests, the sainted. We really are holier than them. ya gotta
>> understand that XP was not written for us, it was written for madding crowd, the
>> hoy-polloy, the great unwashed...
>
>If you insist in thinking in these terms, at least learn how to spell
>hoi polloi.
>
If we're arguing about the proper spelling of a phrase written originally
with a non-Roman alphabet, let's at least drop the 'the' first. (It's like
saying 'I see the el gato sitting at the gate of the el Dorado')
--
-Simon Raahauge DeSantis
> If we're arguing about the proper spelling of a phrase written originally
> with a non-Roman alphabet, let's at least drop the 'the' first. (It's like
> saying 'I see the el gato sitting at the gate of the el Dorado')
>
> --
> -Simon Raahauge DeSantis
Fantastic! As I was (mis)typing hoi polloi I had this free-floating sense of doom, and
indeed now that you mention it I remember reading about that gotcha, Wm Safire probably
in the El Nueva York Tiempos.
t
>
> If you insist in thinking in these terms, at least learn how to spell
> hoi polloi.
OK. tell me how it's spelled and I promise to memoize it. :)
And if you insist on telling other people what to do, pick something that matters.
Spelling? Not.
t
"I said I was The Greatest, not the smartest." -- Muhammad Ali after failing the Army
intelligence test.
>
> And if you insist on telling other people what to do, pick something that matters.
> Spelling? Not.
>
Spelling is very important. It speaks directly to the degree of
precision you bring to your assertion- and the degree of care you put
into its presentation. You don't misspell function calls, why should
you misspell your writing?
Gregm
Greg Menke <··············@zxy.mindspring.com> writes:
> Spelling is very important. It speaks directly to the degree of
> precision you bring to your assertion- and the degree of care you put
> into its presentation. You don't misspell function calls, why should
> you misspell your writing?
Because humans don't need to compile?
--
Craig Brozefsky <·····@red-bean.com>
LispWeb -- Mailing list for Lisp Based Web Development
Homepage: http://www.red-bean.com/lispweb
> > into its presentation. You don't misspell function calls, why should
> > you misspell your writing?
>
> Because humans don't need to compile?
Dammit, man! I wanted to say that! :) Actually, I was going to say two
things:
1. Because computers are stoopid. (Your point, really.)
2. I do too mispell my functions! When I don't, it is because...
3. ...I know how to spell my functions. On the other hand...
4. ...I do not know how to spell the hoi polloi
Thank god we don't have to talk about XP anymore!
t
On 23 Dec 2000 21:02:31 -0500, Greg Menke
<··············@zxy.mindspring.com> wrote:
>> And if you insist on telling other people what to do, pick something that matters.
>> Spelling? Not.
>>
>Spelling is very important. It speaks directly to the degree of
>precision you bring to your assertion- and the degree of care you put
>into its presentation. You don't misspell function calls, why should
>you misspell your writing?
There are a couple of grammatical errors in your message.
That speaks much more eloquently of your "degree of precision"
To paraphrase your bogus argument:
You do not make mistakes in the syntax of your function calls, why
should you foul up the syntax of your native language ?
israel raj thomas <·······@optushome.com.au> writes:
> You do not make mistakes in the syntax of your function calls, why
> should you foul up the syntax of your native language ?
That comma was used incorrectly. You should have used a semicolon or
some kind of conjunction.
--
vsync
http://quadium.net/ - last updated Tue Dec 19 20:37:35 PST 2000
(cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner
(cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil))
vsync wrote:
> israel raj thomas <·······@optushome.com.au> writes:
>
> > You do not make mistakes in the syntax of your function calls, why
> > should you foul up the syntax of your native language ?
>
> That comma was used incorrectly.
Avoid the passive form.
:)
t
vsync <·····@quadium.net> writes:
> israel raj thomas <·······@optushome.com.au> writes:
>
> > You do not make mistakes in the syntax of your function calls, why
> > should you foul up the syntax of your native language ?
>
> That comma was used incorrectly. You should have used a semicolon or
> some kind of conjunction.
People, people! The important thing is to not use "gh"s. }:)
--
Tom Breton, http://world.std.com/~tob
Not using "gh" 1997-2000. http://world.std.com/~tob/ugh-free.html
Some vocal people in cll make frequent, hasty personal attacks, but if
you killfile them cll becomes usable.
> Spelling is very important. It speaks directly to the degree of
> precision you bring to your assertion- and the degree of care you put
> into its presentation.
Dude, do you even know when spelling was invented? I mean the idea that there is such a
thing as "correct" spelling? You know that is very recent as things cultural go, right?
As for "It speaks directly to the degree of precision you bring to your assertion", two
things:
1. Next time could you bring a greater degree of pomposity to your assertion?
2. My assertion was that we here on c.l.l are the chosen, the blessed, the high
priests...how much more precision do you want?
Ok, ok, jes kiddin', I lub spellin' too, jes thought it was silly to be taken to task
fer blowin' hoi polloi in an NG. But i greatly enjoyed the the redundancy reminder.
Anyway, speaking of Latin, i am reminded with delight of The Life of Brian and John
Cleese's lesson on "Romans go home!".
Re: XP. having a kick-ass suite of regression tests on hand totally roolz. been there,
done that, loved it. Pairs programming? I've tasted that, as well, though not in any
formalized scheme...anyway, definitely had its charms.
One thing is true, programmers basically work in isolation. Solitary sucks. And it
reallye xposes you to blame---bring production down and it comes back to one name. Ring
ring. Kenny, your job went down. get yer ass in here. Also breeds noncompliance with
standards...folks just code their own little ways, screw the group. And you don't find
out how bad Little Joe is doing over in Cubicle 12 until a week before production... but
ya know what? XP will roll off folks like that's backs like water off a duck... so can
we just back to work? :)
t
>
> Spelling is very important. It speaks directly to the degree of
> precision you bring to your assertion- and the degree of care you put
> into its presentation. You don't misspell function calls, why should
> you misspell your writing?
I'd like to apologize for the above- I certainly shouldn't be making
such comments in areas I'm not qualified. I had a bad moment. Sorry
about that...
Happy Holidays,
Gregm
Funny, in a different context I just observed to someone that when 99 out of
100 programmers 'go back and fix something they got wrong' they simply hack
away until the problem at hand goes away. I observed further this is why it is
conventional wisdom that at a certain age applications must be rewritten; there
are so many patches the thing can't be changed without collapsing in a heap.
The alternative we all follow of course is to ask if the immediate problem is a
manifestation of some deep design error, if so we do not just amke the
immediate problem go away, we redesign.
I am not sure if I am in love with the word refactor, but at least it means
"don't just slap a bandaid on it" to me, I think it makes an important
distinction, and if having a buzzword at all encourages the Bandaid Squad to
pull their chins a little, good for them.
From now on when they catch me sitting back in my chair in my cubicle with my
eyes closed, I am just going to say i am refactoring. :)
kt
Tim Bradshaw wrote:
> vsync <·····@quadium.net> writes:
>
> > Samir Sekkat <············@bigfoot.com> writes:
> >
> > > What I really loved about xP was the very strong accent on refactoring.
> >
> > Would you mind if I ran screaming around the room for a bit?
> >
>
> What's wrong with it (other than being an overly buzzword-compliant
> way of saying `go back and fix the stuff you got wrong')?
>
> --tim
Here is an idea I have been thinking about for some time. To
keep it marginally in the thread, I'll call it XXXP. But basically
it is a maximization of automatic programming (AP). Lisp and
its relatives are common in this area.
Automatic generation of code from goal specification
----
http://www.hiof.no/hiof/avd/it_aut/prosjekter/hoit/html/nr1_95/autgen.html
http://www.cs.utexas.edu/users/novak/cs394p.html
Machine Learning
----
http://www.aic.nrl.navy.mil/~aha/research/machine-learning.html
Code Analysis
----
http://www.iam.unibe.ch/~lanza/codecrawler/ccdocu.html
The overall perspective I generally think of as being Kolmogrov
complexity (see. the excellent book by Li and Vitanyi). And so
essentially we have a number of basic Turing complete languages
from which applications or function classes or language sets are
constructed. I.e., an application may be seen as a function
or a particularized language, a language for a specific purpose.
And then we can intertranslate the various Turing complete
languages and frequently identify different algorithms in the same
language that give the same function. I.e., though the algorithmic
equivalence of functions is undecidable, we may still show
equivalences between languages in most every case and
algorithms in many cases.
What we want to do then is to remove or normalize the issue
of language difference via the equivalence. We will then have
what might be called prefix codes, generators, or a hierarchy
of algorithmic primitives with some normalization between these
generators. E.g., a sort function is a common generator. It is used
frequently as a subroutine, and there are several different kinds
of sort routines where we could substitute one for another or
have a generalized sort applicable to a large variety of
situations.
And then as previously mentioned, the development of new
applications represents a search in some likely algorithm domain
for an algorithm that satisfies the goal specification. The critical
factor for doing automatic programming is the expected effective
size of the domain that must be searched with respect to the amount
of computational ability that may be applied. This is a very parallel
kind of search and the power and ability to cluster PCs increases
exponentially such that at some not to far distant time searches
of useful algorithmic spaces could be reasonably done. E.g.,
gigahertz PCs are now becoming such that, say, a 10 gigahertz
cluster in a small computer department may be easily assembled.
(It is common knowledge that the potential number of excess compute
cycles on commonly used PCs is enormous.)
And then in addition to speed, and as mentioned previously, prior
solutions can be used to reduce the new problem by the difference
between the prior and expected solutions. I.e., we need to build a
detailed database of normalized solutions and their related goal sets
so that new goals can be compared with old goals and only the
difference searched.
The ideal would then be: (1) some goal specification was given,
(2) an automatic search for similar prior goals made and an
approximate solution proposed, (3) the programmer or user
could then refine the goal specification or keep the prior
specification, (4) the computer would search the algorithmic space
using as estimates prior solutions that may work and hopefully
for small, restricted sub-goals that have been identified, and (5)
the developer would work on breaking down (detailing) the sub-
goals of an expected large search space.
And so the programmer would be working to make the specification
sufficiently detailed to allow the current computational ability and
solution knowledge to be automatically applied and provide detailed
code where the automatic method was not efficient.
This is much too strategic for XP where one is expected to solve
the immediate problem. But there is some reason to think that a
focus on the immediate problem will become progressively
obsolete. The new problem is becoming: how does one specify
goal requirements sufficient for automatic solution in those cases
where the initial goal does not become computationally trivial.
Regards,
Neil Nelson
In article <··············@piro.quadium.net>, ·····@quadium.net says...
> Samir Sekkat <············@bigfoot.com> writes:
>
> > What I really loved about xP was the very strong accent on refactoring.
>
> Would you mind if I ran screaming around the room for a bit?
>
I think there is a small misunderstanding. For me, xP was a way to
introduce some common sense practices in "conventional" (non-Lisp)
projects. So, working in such projects, I found it sometime useful to
have a methodology like xP to print and hand out, as managers tend to
believe paper more then spoken words.
Myself, I love to work in CL, with a development approach that is very
different then in C++ for example.
So if you still want to scream, just tell me why...
--
Samir Sekkat
Munich, Germany
············@bigfoot.DELETETHIS.com
>>>>> "Lieven" == Lieven Marchand <···@bewoner.dma.be> writes:
Lieven> ···@cs.purdue.edu (Bradley J Lucier) writes:
>> The first time I saw the Extreme Programming book, I told a
>> friend I thought it should be called "The Lisp Way". From my
>> point of view, it's basically how to program in a good Lisp
>> environment, without, perhaps, using lisp. I didn't read the
>> whole book, but I found nothing new that was helpful in my
>> brief examination of it.
Lieven> There are some very fundamental differences to the Lisp way
Lieven> IMHO. One of the tenets of XP is "You Aren't Gonna Need It"
Lieven> which strongly prohibits people from doing anything more then
Lieven> the problem requires right now, no generalisations
Lieven> allowed. Also they're very much against hooks etc. I'd say XP
Lieven> is more the New Jersey way of continuous hacking, saved by an
Lieven> emphasis on refactoring and more advanced programming
Lieven> environments.
Arguable either way; the "no generalizations" indicates that the goal
is to solve the problems you actually have in front of you, as opposed
to making up other problems that _might_ resemble them.
On the one hand, this represents a process that would certainly never
invent CLOS.
On the other hand, by focusing on actually solving the problem at
hand, the XP approach results in a really strong _problem_ focus.
You're focused on solving problems, not on making up your own
problems.
Abstraction will certainly be needed at some point; I don't think it
is harmful to choose, for a time, to eschew that in favor of a "myopia
of the immediate problem." And after having to change the system
three or four times to accomodate changes in the specs, you may
actually start to see the common "generalization" that accomodates all
of it at once.
--
(reverse (concatenate 'string ····················@" "454aa"))
<http://www.ntlug.org/~cbbrowne/>
For example, if errors are detected in one of the disk drives, the system
will allow read-only access to memory until the problem is resolved. This,
PE claimed, prohibits a damaged disk drive from entering errors into the
system.
-- Computerworld 8 Nov 82 page 4.
From: Robert Virding
Subject: Re: extreme programming
Date:
Message-ID: <3a41f3f7$1@news.pi.se>
In article <··········@arthur.cs.purdue.edu>,
···@cs.purdue.edu (Bradley J Lucier) writes:
>The first time I saw the Extreme Programming book, I told a friend
>I thought it should be called "The Lisp Way". From my point of
>view, it's basically how to program in a good Lisp environment,
>without, perhaps, using lisp. I didn't read the whole book, but
>I found nothing new that was helpful in my brief examination of it.
We have been doing "extreme programming" for many years now, both here
and at places I have worked at earlier, but we called it prototyping.
If we had thought of calling it by a cooler name like Extreme
Programming it might have been easier to sell to the organisation. :-)
--
Robert Virding Tel: +46 (0)8 545 55 017
Alteon Web Systems Email: ··@bluetail.com
S:t Eriksgatan 44 WWW: http://www.bluetail.com/~rv
SE-112 34 Stockholm, SWEDEN
"Folk s�ger att jag inte bryr mig om n�gonting, men det skiter jag i".
Robert Virding <··@bluetail.com> wrote:
> In article <··········@arthur.cs.purdue.edu>,
> ···@cs.purdue.edu (Bradley J Lucier) writes:
> >The first time I saw the Extreme Programming book, I told a friend
> >I thought it should be called "The Lisp Way". From my point of
> >view, it's basically how to program in a good Lisp environment,
> >without, perhaps, using lisp. I didn't read the whole book, but
> >I found nothing new that was helpful in my brief examination of it.
>
> We have been doing "extreme programming" for many years now, both here
> and at places I have worked at earlier, but we called it prototyping.
> If we had thought of calling it by a cooler name like Extreme
> Programming it might have been easier to sell to the organisation. :-)
So you have been doing pair programming for all production code? You
have written unit tests _before_ writing the code to be tested? If not,
by definition you haven't done extreme programming. That's not bad, just
something different.
Michael
--
Michael Schuerig
···············@acm.org
http://www.schuerig.de/michael/
Tim Bradshaw wrote:
> I'm asking because I'm working somewhere where there is a requirement
> for *some* kind of accepted process (huge company, huge client and so
> on) but where the release schedule is really too fast for what the
> processes that exist can do, and I'm wondering about suggesting a
> guerilla reimplementation using some much faster process. There are
> some other technical issues alas which probably kill a Lisp solution
> in the long term but a fast answer might hold the fort long enough for
> those to be overcome.
Not knowing Lisp and looking for a good, free Lisp compiler, I stumbled
into this newsgroup and then stumbled upon this thread, did the Extreme
review (fast and dirty) of http://www.extremeprogramming.org and thought
I would give my one (half?) cent.
I guess the idea in a programming project is to _sufficiently_ meet the
solution requirements while sufficiently meeting an expense requirement
primarily in terms of programming labor. I.e., the result will be some
complex complex function satisfying the desired relation (input-output)
constructed within a time-period and cost (these factors determined by
the customer). The programming/construction labor translates the IO
relation to known or searched computable functions.
A minimization of labor translates to a minimization of the solution search
space by a sufficiency of requirements definition--If we do not know
what we are trying to obtain then what may be obtained is unbounded--
and by search methods expected to be fast in the search space
restricted by the requirements. E.g. most commonly, new requirements
are sufficiently similar to previously satisfied requirements such that
a prior solution can be used as an approximation for the new solution,
and where the expected difference between the prior and expected
solution identifies a small search space. I.e., education and experience
provide approximate solutions to certain classes of problems, depending
on the type of education and experience, such that a future class problems
may be expected to be solved quickly according to a small search in
the difference area between prior experience and new problem.
The critical factors then divide into a restriction of the search space
through requirements and a minimization of that resulting search space
by existing approximate solutions. The remaining effective search space
is expected to be sufficiently small for a random search or if not small
is expected to yield to a learning search, or in this second case that
essentially the search space exhibits a structure that will admit
a progressive compression. Without an expectation of progressive
compression of typical problems, very few useful problems could be
solved in any useful time, and many problems cannot be solved in a
useful time or become solved only after some arbitrary amount of time
is expended beyond any local (small) use-cost justification.
And so the restricted search space minimization is obtained primarily
through an effective reuse of existing solutions and secondarily through
a compressive learning of the difference search space. Of the two
minimization methods, solution reuse should have the greatest impact on
commercial problems in that for this category education and experience
are held to be very effective and because there now exists a large number
of software methods applicable to commercial problems. I.e., if one
could look-up the solution in a catalogue of solutions according to the
requirements, that would be a very fast search. And so it will be
desirable to build and utilize increasingly large existing solution
databases and their efficient searching methods.
And then to search the prior-new difference space there are
methods in statistics and mathematics (pac-learning) that can be
used. These are not simple as the general problem is maximally hard,
but the essential idea is that partial searches will yield a partial
structure that may be exploited to reduce the remaining search area.
And keeping in mind that some search areas may be random such
that no learning method will be effective in reducing the remaining
area.
And then there is the human group dynamics aspects. To the degree
that this problem can be well-defined, it will also yield to prior solution
descriptions as just done above. My suggestion is to adopt a
recognized, reasonable method and then adapt that method in the
prior learning mode according to certain criteria. But this will depend
on a wide variety of factors including personnel capabilities and
tendencies. Frequently, as it seems to me, the limiting factor on the
speed of large scale solutions is an inability of the social organization
to adapt in ways that could reasonably be seen to be more efficient.
We get stuck in a particular organization, for perhaps security or a
natural fixing of social structure reasons, that then becomes
obsolete relative to a new problem set. A particular social
organization can be seen as a prior solution class that will contribute
toward or away from different solution classes.
Regards,
Neil Nelson
Tim Bradshaw <···@tfeb.org> writes:
> Does anyone have any experience applying this methodology to
> Lisp-based projects?
We "used" a limited form of it on a web development project. We have
a geographically distributed team, so the "partner programming" was
out of the question. Also, we were thru the design phase already when
we found the extreme programming methodology, so another large chunk
of it was not suitable for us.
However, we did attempt to use the testing harness they advocate, with
some success. We have an XPTEST package that we could make available,
which implements their test framework. Drop me a line if you're
interested, as it's presently on ur internal CVS server, as opposed to
our public one.
As far as the philosphical underpinnings, the notion of not
generalizing until things fully revealed themselves, and not
implementing what was not needed, that was something we have done for
awhile. However, having it vocalized and discussed by the team did
help to re-enforce it and make it easier for us to do as a group.
--
Craig Brozefsky <·····@red-bean.com>
LispWeb -- Mailing list for Lisp Based Web Development
Homepage: http://www.red-bean.com/lispweb
In doing a programming project there is frequently the
assumption that programming is required. But if we
could solve the problem without programming or identify
a solution within the cost-benefit of doing programming
without programming--short schedules by the customer
imply that they want a solution at low cost, whereas an
optimally programmed solution will have in inherent cost
irrespective of what is desired--, then a solution will
have been obtained without programming. The customer will
be satisfied in the shortest time at the least expense.
But of course it will be difficult to be paid well for
little work unless some method is arranged for partici-
pating in the avoided expense (resulting in increased
profit). I.e., we have saved/made you money to our
detriment as per your prior expectations and should be
properly paid as any factor that contributes to your
profit.
Should the software external (manual or other) methods
of the company be modified? Can the system be divided
into segments such that one or more segments, previously
assumed to be programmed, may be handled by existing
software? How fast will the expected solution become
obsolete? What detriments arise from an approximate
solution that may be quickly assembled against a precise
comprehensive solution that will take much longer? Can
the programmed solution be marketed to other companies?
I.e., though other companies may also reduce their expense
and be more competitive by having this company's solution,
if this company could partake in a marketing of their
solution via, say, a software company, then this company
could still remain more competitive overall by sharing
in the expense reduction of the other companies. This
is often a likely scenario as little is new in the world
and if it is any good it is quickly copied.
Though I do a lot of programming, it would seem that the
faster and less expensive the solution, all other things
being equal, the less programming involved.
Another area that could be explored deals with the
automatic evolution of software and automatic methods
to make software more malleable to higher level
manipulation: automatic programming.
Also search methods frequently utilize a multiple path method
in some small portion that enables the search to evolve.
I.e., sometimes and perhaps much of the time, some portion
of the method should be: how could we do this differently,
then do it both differently along with the current high
probability path, and then change the high probability path
when the different path proves better. This then brings
into the overall method, optimization methods applied to
investigated alternatives. Multiple path optimization is
best employed when the search space is large, an approximate
solution will be sufficient, and some additional expense
can be used for the additional paths and justified by the
large search space. But in any case, different path ideas
frequently need to be at least considered as possible
alternatives as ideas are fairly inexpensive and may provide
considerable savings.
Regards,
Neil Nelson
>>>>> Tim Bradshaw writes:
Tim> Does anyone have any experience applying this methodology to
Tim> Lisp-based projects?
Yes, I, and a team of 4 to 5 (it varies) are doing an XP project
in Common Lisp. So yes, *someone* does have experience with it. :-)
Seriously, we do
* pair programming
* unit test driven development
* the simple thing which could possibly work (sometimes,...
this is by far the most contentious aspect)
* the planning game (business describes functionality,
engineering estimates cost, business selects which part of system
they want)
Shameless plug: Memetrics is always looking
for good Lisp programmers wanting to relocate
to lovely Sydney, Australia.
--
Alain Picard
Memetrics
"Alain Picard" <············@memetrics.com> wrote in message
···················@outback.memetrics.local...
> Shameless plug: Memetrics is always looking
> for good Lisp programmers wanting to relocate
> to lovely Sydney, Australia.
>
> --
> Alain Picard
> Memetrics
I believe you recently found at least one, didn't you?
Coby :-)
In article <··············@outback.memetrics.local>,
Alain Picard <············@memetrics.com> wrote:
> >>>>> Tim Bradshaw writes:
>
> Tim> Does anyone have any experience applying this methodology to
> Tim> Lisp-based projects?
>
> * unit test driven development
48 messages into this thread and there are two (2) mentions of "Test"
and zero (0) mentions of "Test-Driven Design".
So I'll do it: Test-Driven Design.
-fishlike
Sent via Deja.com
http://www.deja.com/
In article <············@nnrp1.deja.com>,
········@my-deja.com wrote:
> In article <··············@outback.memetrics.local>,
> Alain Picard <············@memetrics.com> wrote:
> > >>>>> Tim Bradshaw writes:
> >
> > Tim> Does anyone have any experience applying this methodology to
> > Tim> Lisp-based projects?
> >
> > * unit test driven development
>
> 48 messages into this thread and there are two (2) mentions of "Test"
> and zero (0) mentions of "Test-Driven Design".
>
Oops, nobody's perfect: the correct mantra is "Test-First Design"
While at the Immersion, I brought a copy of ACL and was noodling
around while the other students were yelling at Beck and company...being
just an amateur at lisp this may make no sense, but FWIW:
(require :trace)
;;;(load "c:/Program Files/acl501/eli/fi-site-init")
;;; DIDN'T HAVE TO DEFINE IMPLEMENTATION FIRST
(setq *global-property* 1)
(setq *global-property* "hi")
(defun test-function () (print "I am a test function"))
(defun test-function () (non-existent-function))
;;; UNIT TESTS TEST ASSERTS, NOT JUST A SYSTEM RUN WITH ADVICE ENABLED.
;;; NEED SEPARATE UNIT TEST CLASS TO CONTAIN ALL ASSERTS
;;; WHICH CAN CONTAIN ADVISE STATEMENTS, BUT MUST CONTAIN
;;; INVOKATIONS OF ALL THE ASSERTS IN SEPARATE TEST METHODS
;;; STATELESS UNIT TEST MAKES A UNIQUE INSTANCE OF THE TEST CLASS
;;; FOR EACH TEST METHOD. STATEFUL TESTING METHODS ARE FOR PERSISTENT
;;; OR LONG-TERM INSTANCES LIVING IN THE ADDRESS SPACE AND ARE
;;; REPEATEDLY CALLED AT AD HOC OR AUTOMATIC INTERVALS. WHAT
;;; CONSTRAINTS OF XP PRACTICE COULD BE EMBEDDED IN THE LANGUAGE.
;;; (deftest)
;;; SHOULD BE ABLE TO REFER TO NON-EXISTENT THINGS
;;; START WITH THE TEST, REFER TO OTHER TESTS
(excl:advise test-function :before my-advice nil (print "assert"))
(excl:advise test-function :after my-advice-after nil
(if (not (integerp *global-property*))
(error "Improper *global-property*: ~A"
*global-property*)
))
(excl:advise non-existent-function :before my-current-advice nil
(another-nil-func)) ;OK
(excl:advise non-existent-function :after another-test-case nil (print
"assert?")) ;OK
(defun non-existent-function () (print "I do not exist"))
(defun another-nil-func () (print "Are we on our own here?"))
-fishlike
Sent via Deja.com
http://www.deja.com/
········@my-deja.com writes:
> In article <··············@outback.memetrics.local>,
> Alain Picard <············@memetrics.com> wrote:
> > >>>>> Tim Bradshaw writes:
> >
> > Tim> Does anyone have any experience applying this methodology to
> > Tim> Lisp-based projects?
> >
> > * unit test driven development
>
> 48 messages into this thread and there are two (2) mentions of "Test"
> and zero (0) mentions of "Test-Driven Design".
>
> So I'll do it: Test-Driven Design.
Okay. Having worked for Alain in the past, I can try to describe the
framework he uses in his development. Note that this is just my take
on it.
The first thing about this `extreme programming' thing is that,
productivity-wise, it *is* very extreme. It sometimes seems that the
pair programming impedes productivity, because programmers often tend
to argue over minutiae, or style. But by and large, you end up
getting much more done, much faster, with lots more insight into the
problem (since the pointwise solutions end up using two people's
combined understanding and knowledge. It's much less boring, builds
excellent team trust, respect cooperation, and also helps the flow of
information, both about how to program, and how the software works.
This is especially useful in Common Lisp development, where I've
worked with very few people who I'd say have an expert understanding
of Common Lisp, and know all of it enough to not benefit mutually from
pair programming.
Besides the pair programming stuff, the other, very major part of it
for me was this idea of writing a "unit" test to test what a logically
atomic part of the program should do, and writing that test out
*first*, and then doing the implementation. God. I resisted this at
first, since it was not how I programmed, and I seemed to do okay
without such seemingly awkward, and even anal, paradigms. It didn't
take too long (a month or so) to realize that test-driven
implementation (I'll not call it design, but implementation, since
that seems to be more accurate) was the way to go. Let me explain:
Suppose business determines that they want XYZ. They spec it out as
best they can, but it's almost always the case that going from that
high-level business spec to code is quite a bit of work, involving
lots of design and lots of implementation. Alain happened to be chief
architect of the system, and developed a large part of the high-level
design, data models, and class hierarchy. But what was most
interesting and important to me was how we were to go about
implementing it.
We would ask ourselves the following (often difficult) question: Can
we write a program (``driver'', ``script'', whatever you want to call
it) that, if executed successfully, would indicate an ideal, working
logical unit -- the unit we were going to build? Then, we would
proceed to write that "unit test", written in Common Lisp, of course,
and then, when we were comfortable that the unit test was complete,
extensive, and correct, we would only then proceed to implement
(design) the code. I guess unit test driven programming assists very
much in design as well, as you look first at your unit test, and
therefore the API, or design of the underlying code you're calling out
to, and can easily see if it's sufficient, and you're satisfied with
it. Then, what's great is that once you have it, you have a MUCH
better sense of what you're trying to implement, and implementation
goes much faster. You also know when you're done! when the test
passes. Finally, you have a piece of code that can be run at any time
to make sure that that unit of the code works properly.
There's a lot more to extreme programming, but that's the part that
affected me the most. Of course, I have chosen this as the
development paradigm for serious development (or at least aspects of
it that work in a given situation; obviously, if you're a one-man
off-site contractor, you can't really do the pair programming bit,
etc.)
It's a great model, but not trivial to implement in the workplace. It
involves a fair bit of understanding, only some aspectes of which I
know anything about. But I've been very pleased to work in this
framework, and feel that it has helped me become a better programmer
in many ways.
dave
If you look at an article written about 20 years ago in Computing Surveys (I
think it was called LISP: The Interactive Programming Experience), you'll
see that much of the coding issues are quite similar to what XP proposes.
This is not surprising - even Kent says that "most of this is not new".
The places where XP differs from basic Lisp programming (in my estimation)
is threefold:
(a) Pair programming - There is no reason why Lisp couldn't be pair
programmed, but it usually isn't.
(b) Less of an emphasis on "you aren't going to need it" - Most Lisp
programmers, when faced with a simple task, will try to find a generic
solution rather than stick to a point solution. In fact, Graham in "On
Lisp" explicitly expouses this as an advanced technique.
(c) Process-related stuff - XP explicitly tries to go with episodic
programming as a scheduling technique. In general, there is no reason why
Lisp folk don't do this, but at this time, it usually isn't.
All-in-all, XP works well with Lisp (as it would with most programming
languages). i actually tried a small-scale project using XP with Lisp as a
language (a unit testing framework, because I didn't like RT too much). I
laid out the project using a set of stories about what I wanted to do WRT
testing and divided the work into about three extremely small episodes of
programming. I got a simple self-testing structure going in about 3 coding
cycles of two to three hours each, including refactoring from CLOS classes
using subclassing to build tests to CLOS classes that held functions to
perform the tests.
Although there were some flaws with this test (e.g., small project size,
implementor being customer, no pair programming), I do think that the XP
form of scheduling and dividing work into episodes works quite well for Lisp
projects.
As for the interactive programming stuff... Well, we've always done that...
faa
"Tim Bradshaw" <···@tfeb.org> wrote in message
····················@tfeb.org...
> Does anyone have any experience applying this methodology to
> Lisp-based projects?
>
> I read the web site yesterday and it looked like they have interesting
> ideas, which Lisp would fit rather well, although I'm generally a bit
> distrustful of `methodologies' to put it mildly...
>
> I'm asking because I'm working somewhere where there is a requirement
> for *some* kind of accepted process (huge company, huge client and so
> on) but where the release schedule is really too fast for what the
> processes that exist can do, and I'm wondering about suggesting a
> guerilla reimplementation using some much faster process. There are
> some other technical issues alas which probably kill a Lisp solution
> in the long term but a fast answer might hold the fort long enough for
> those to be overcome.
>
> Thanks
>
> --tim
In article <···············@tfeb.org>,
Tim Bradshaw <···@tfeb.org> wrote:
> I read the web site yesterday and it looked like they have interesting
> ideas, which Lisp would fit rather well, although I'm generally a bit
> distrustful of `methodologies' to put it mildly...
Be distrustful, my fireidn, be very distrusgul for you don't need a
degree in endocrinology to know that hormones are responsible for
exerting powerful effects on the human body. What man
is not aware that internal secretions of estrogen are the "magical"
essence of a woman's behavioral mystique? This can be powergully
suverted by some of the hidden views inside thedse methodologies.
SCIENCE magazine was founded by Thomas Edison in the late 1880's. This
prestigious journal is read by over 500,000 scientists every week. On
January 23rd, 1998 (vol. 279. p. 563), IGF-I was identified as the key
factor in prostate cancer. Nowhere in that article was it mentioned that
there are forty-seven hundred species of mammal, and millions of
different proteins in nature, and that IGF-I is IDENTICAL in humans and
cows.
"New Calf Diarrhea Vaccine Now Available"
The ad explains that their vaccine protects agains 4 strains of E coli,
clostridium, coroma-virus, and 3 strains of rota-virus. If you
still drink body fluids from diseased animals, this news may gross you
out.
Do you eat their flesh? The first column ("Hoard's has Heard...")
reveals that "evidence of hairy heel warts was found in 29 percent of
dairy cows shipped to a Southeast slaughterhouse." Investigators found
leg lesions, and 61 percent of the cows harbored infectious spirichetes.
Seee, more hidden stuff.
Sent via Deja.com
http://www.deja.com/