It occured to me that the lisp/scheme programmers I have some sort of
communication with do not seem to be all that hot about XP
( http://www.extremeprogramming.org/rules.html for a description ).
I'm wondering if:
1) It's true that lisp programmers eschew XP.
2) Why it's true if it's true.
My feeling is that lisp programmers generally do not follow a
methodology but have something I would call a "style" of programming
which is similar to a methodology and that they tend to believe in
that methodology.
Thaddeus L Olczyk wrote:
> It occured to me that the lisp/scheme programmers I have some sort of
> communication with do not seem to be all that hot about XP
> ( http://www.extremeprogramming.org/rules.html for a description ).
> I'm wondering if:
> 1) It's true that lisp programmers eschew XP.
No. Just like some non-Lisp programmers, some use it some do not. Among
those that do, they do not necessarily follow all of the tenets of Beck's
book. A couple of the things that people tend to eschew/modify:
* Not so heavy a reliance on "simple design". Lisp programmers tend to be
somewhat above average and can predict the future with slightly more
prescience than your average Java hacker. Thus, they can make an
investment in doing some slightly more complex algorithms from the get go.
We tend to program with generic utilities and abstractions from first steps
rather than using simple code and refactoring it to work after discovery of
code duplication, etc. This is possible because the language (especially
CLOS) supports incomplete abstractions better than most languages and
because the environment supports rapid change. If you do some extra work
that's too complex to be reliably supportable, you can back out easily
enough. This use of well-informed "prefactoring" vs. refactoring can
improve coding velocity, as well.
* Unit tests are performed, but generally not saved. I've developed a tool
called CLUnit that allows Lisp programmers to define, save, and re-run
these tests. I've found it of use when I'm changing algorithms or data
structures. No, it's not in common use yet...
Finally, I can't comment on more of the team/release practices of XP in a
Lisp environment (pairing, planning game, collective code ownership). Most
of my projects have been individual in basis and/or released on my own
schedule. However, I would assume that most of the same issues would apply
as for any language (except that I haven't seen Lisp programmers get as
possessive of their code as C++ programmers).
> 2) Why it's true if it's true.
I don't think it's true, but some people might not call anything outside
the bounds of "pure XP" XP. If you wish, you can call it Agile Programming
in Lisp instead, although with those initials, things might be bit
confusing.
> My feeling is that lisp programmers generally do not follow a
> methodology but have something I would call a "style" of programming
> which is similar to a methodology and that they tend to believe in
> that methodology.
I would say that most Lisp programmers have a methodology defined at least
as well as most of the early RAD methodologies. The interesting thing
about XP is that it allowed methodologists to study less formal development
systems and characterize them in a more rigorous way. All-in-all,
knowledge of agile methodologies is a good thing because Lisp programmers
have been agile for years. Look back at Sandoval's initial InterLisp-based
interactive programming paper in Computing reviews for one of the first
good descriptions of coding agility...
faa
"Frank A. Adrian" wrote:
> * Unit tests are performed, but generally not saved. I've developed a tool
> called CLUnit that allows Lisp programmers to define, save, and re-run
> these tests. I've found it of use when I'm changing algorithms or data
> structures. No, it's not in common use yet...
Is there a reason you didn't just reuse the Waters 'RT' package?
Paul
Paul Dietz wrote:
> "Frank A. Adrian" wrote:
>
>> * Unit tests are performed, but generally not saved. I've developed a
>> tool called CLUnit that allows Lisp programmers to define, save, and
>> re-run
>> these tests. I've found it of use when I'm changing algorithms or data
>> structures. No, it's not in common use yet...
>
> Is there a reason you didn't just reuse the Waters 'RT' package?
Actually a few, and please forgive me if my recollection is a bit hazy
about the attributes of RT - it's been about a year since I last looked at
it.
First, I wanted to have an XP-style test system. That meant that there had
to be a few things:
*All tests could be stored within the source code of the system (RT had
that).
*All tests needed to be runnable, in bulk, at a given time (RT had that),
with error trapping (RT didn't have that) and aggregate pass/fail
scores accumulated (RT didn't have that).
*For my own debugging use, I wanted to be able to run a specified subset of
the tests (RT didn't have that). I assigned categories to tests for this
purpose.
* I wanted to select whether or not errors were trapped during the test run
- no for my own debugging use, yes for the automated tests (RT didn't have
that).
* I wanted a more complex concept of test that RT has. In RT, you run a
function and it returns nil or non-nil. In CLUnit, a test is specified by
a function that computes input, a function that is the test function, a
function that returns the expected output, and a function that compares the
test function's output with the expected output. All of these have proper
defaults, allow constants as inputs as well as functions in the proper
places, and work in a well-defined way with multiple values.
All of this was wrapped up into a self-testing package with a nice deftest
macro and appropriate functional interfaces for doing all of the above.
You can find the CLUnit documentation and code at http://www.ancar.org. The
cover page explains a bit more about why I did it. The code as of now has
been tested with LispWorks, Franz Allegro, Corman Lisp, CMUCL, and CLisp
and is released unger the LGPL, so you can include it even in a released
product without contagion. The documentation is built in a CLHS-style and
includes a tutorial for the package. You can read the docs online before
you decide whether or not to download the package.
The current version is V1.1. V2.0 is coming out in a couple of weeks. The
changes are that the tests are no longer stored using classes, but in
structures. This speeds up test execution and allows the system to be used
in more primitive Lisps. In addition, I've done some function renaming and
cleanup and kept a compatibility package for v1.x users).
Of course, anyone who wants to use the package is welcome to do so. I
would appreciate any feedback, etc., if you do use it.
faa
"Frank A. Adrian" <·······@qwest.net> writes:
> * I wanted a more complex concept of test that RT has. In RT, you run a
> function and it returns nil or non-nil. In CLUnit, a test is specified by
> a function that computes input, a function that is the test function, a
> function that returns the expected output, and a function that compares the
> test function's output with the expected output. All of these have proper
> defaults, allow constants as inputs as well as functions in the proper
> places, and work in a well-defined way with multiple values.
I have written a few testing frameworks, and would point out that for complete
generality, it is useful to have the notion that a test is just a function that
gets executed with access to some sort of test context, such that it is
responsible for explicitly setting pass or fail itself (as opposed to returning
a pass/fail value)
Then, the business of requiring inputs, generating outputs, and comparing to
expected outputs is just a special case of this.
This generality is important, since it allows one to construct tests with
arbitrary evaluation criteria. For example, consider a test where outputs and
expected outputs are most easily calculated together in an interleaved
fashion. Instead of being required to construct output values for later
comparison, it can be easier to simply perform ongoing pass/fail verification
immediately. The test sources themselves document the expected
behaviour/output.
This generality in no way prevents the CLUnit-style tests. It simply allows for
additional flexibility.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@telus.net The Rhythm has my soul.
In article <···················@nntp.interaccess.com>, Thaddeus L Olczyk wrote:
>It occured to me that the lisp/scheme programmers I have some sort of
>communication with do not seem to be all that hot about XP
>( http://www.extremeprogramming.org/rules.html for a description ).
>I'm wondering if:
>1) It's true that lisp programmers eschew XP.
>2) Why it's true if it's true.
XP is a grab-bag of unrelated recipes, not just one thing. There are
some useful things in XP, some not so useful. A hodgepodge of process
for programming, managing the project, etc.
Rapid development without a whole lot of upfront design is something that
is well-supported by Lisp, so this part of XP seems to be a natural fit.
Pair programming Lisp? Good thing; you go from being the only guy doing
Lisp in your organization to two people, so what the heck. ;)
>My feeling is that lisp programmers generally do not follow a
>methodology but have something I would call a "style" of programming
>which is similar to a methodology and that they tend to believe in
>that methodology.
Intelligent, experienced programmers simply don't believe in what they
perceive to be gimmicks. But everyone has certain rituals. It's not like
you wake up every morning and invent a whole new way of doing your job.
The downside of XP is the way it is packaged, and the stupid name.
You get managers that get all excited about it and want to push it onto
developers, which doesn't go over well with the cynical crowd.
···@ashi.footprints.net (Kaz Kylheku) writes:
> The downside of XP is the way it is packaged, and the stupid name.
Truly said. XPers have been bemoaning this fact for four years now.
The inventors are simply unwilling to change the name. Several good
alternatives have been put forth, too: "agile programming",
"customer centered programming", "value drivern programming" etc.
> Intelligent, experienced programmers simply don't believe in what they
> perceive to be gimmicks.
Indeed. Unfortunately, this seems not to be true of most managers
(who are always so dying for a silver bullet that they'll swallow
anything) and inexperienced, bandwagon programmers.
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
In article <·······················@news3.calgary.shaw.ca>,
···@ashi.footprints.net wrote:
>XP is a grab-bag of unrelated recipes, not just one thing. There are
>some useful things in XP, some not so useful. A hodgepodge of process
>for programming, managing the project, etc.
This seems like an odd thing to say when Beck's "Extreme Programming
Explained" spends quite a bit of time on how the various practices
depend on each other to be workable, as does the XP web site
http://www.extremeprogramming.org/
e.g.,
http://www.extremeprogramming.org/map/project.html
Many criticisms of XP practices come from people claiming
practice A can't work, forgetting that A in XP is supported
by practices B and C.
In article <······························@news.it.nwu.edu>, Chris
Riesbeck wrote:
>In article <·······················@news3.calgary.shaw.ca>,
>···@ashi.footprints.net wrote:
>
>>XP is a grab-bag of unrelated recipes, not just one thing. There are
>>some useful things in XP, some not so useful. A hodgepodge of process
>>for programming, managing the project, etc.
>
>This seems like an odd thing to say when Beck's "Extreme Programming
>Explained" spends quite a bit of time on how the various practices
>depend on each other to be workable, as does the XP web site
In Beck's opinion.
In reality, you can pick and choose whatever works for you. For example,
programming in pairs is useful independently of anything else in XP. I
did that before XP (or should that be EP?) became a buzzword. I also
wrote unit tests long before XP.
Of course, XP needs such explanations to justify its own existence as
a concept, rather than a collection of things.
Religions are the same way. You can't just pick and choose from our
teachings what appeals to you, they say; only by applying everything
can you get into heaven. You may be nice to people all your life, but
without accepting Christ, it's all for naught. ;)
It's not hard to take a soup of related ideas and identify relationships
among them; with a little imagination, these can be elevated into
supporting relationships.
Yes, I think XP as a concept is largely balderdash; so you don't have
to guess at what my position is. I think some of the the ideas are
good on their own, and none of them are original. Their repackaging
as Extreme Programming is unnecessary.
XP was tried in my organization and largely failed to catch on. Only
one project acquired a unit test frame work, and only two developers
wrote any unit tests, I being one of them. Pair programming often falls
by the wayside, in favor of the old fashioned peer review. Iterations
were largely abandoned. Management tried to push all of the XP ideas
at the same time, and it just didn't work. I just didn't see how they
support each other; they do on paper only. Nobody even mentions XP any
more, except in reference to the operating system from Redmond. It's a
fad that came and went.
For XP to work, people simply have to believe in it. They have to read
the website repeatedly until they can murmur its wisdoms subconsciously
like mantras. Lastly, I don't really trust the motivations of the
extremeprogramming.org people.
Everyone has some gimmick to sell, for some ulterior motives. On the other
hand, there is no proof that any of that works, but plenty of proof that
XP is capable of generating buzz, and the accompanying merchandising that
goes with this sort of thing: books, coffee mugs, T-shirts, seminars.
For example, from the main website is the link to an International
Conference on Extreme Programming. What else could this be but an
all-expenses-paid holiday for a few geeks that want to be doing
anything but programming, and an opportunity for methodologists
to swoop in on some unsuspecting prey?
···@ashi.footprints.net (Kaz Kylheku) writes:
> Of course, XP needs such explanations to justify its own existence as
> a concept, rather than a collection of things.
>
> Religions are the same way.
> Yes, I think XP as a concept is largely balderdash
>
> Everyone has some gimmick to sell, for some ulterior motives.
Well, I don't like defending XP in this forum, as it's inappropriate, but I
do think you are giving it a bad rap, and do not understand its history.
Paradoxically, it is largely _in reaction to_ big methodology which
"has something to sell" (think Rational Rose) that XP grew up.
All XP wants you to buy are 3x5" index cards; even I can afford those. :-)
You don't need the books, the meetings, etc etc. You and I both know that
in our field, _anything_ even mildly successful will generate a bandwagon
entourage of people trying to profit from it.
Anyone wishing to make up their own mind about XP is encouraged to just
start reading from the ExtremeProgrammingRoadmap on the c2 wiki; it costs
nothing, and you can make your own intelligent decision in a day or two
of reading. Pretty cheap.
Again, bringing this back to lisp; lisp and XP are IMO orthogonal; lisp is
an implementation technology, XP are a set of practices used to deliver
better software quickly (at least, that's what its practitioners believe).
XP may OR MAY NOT BE appropriate for a given company or project. Just
like lisp. :-)
Finally,
> XP was tried in my organization and largely failed to catch on. Only
> one project acquired a unit test frame work, and only two developers
> wrote any unit tests,
This hardly sounds like XP.
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
Alain Picard <·······@optushome.com.au> writes:
> All XP wants you to buy are 3x5" index cards; even I can afford those. :-)
> You don't need the books, the meetings, etc etc. You and I both know that
> in our field, _anything_ even mildly successful will generate a bandwagon
> entourage of people trying to profit from it.
I appreciate this aspect of it.
> > XP was tried in my organization and largely failed to catch on. Only
> > one project acquired a unit test frame work, and only two developers
> > wrote any unit tests,
>
> This hardly sounds like XP.
We have had a similiar experience at my shop. XP failed to catch on,
XP did not fail itself as we never implemented all of XP. We had some
champions for a few of it's practices, which helped us quite a bit,
but parts of XP had to be organially grafted into the culture we had
created over the past few years of working together. We have very few
top-down directives here, so any new process or methodology has to be
integrated into our work at several levels. It needs to have LOW
initial investment, LOW impact on immediate productivity (we have to
focus on short or mid term productivity right now), and otherwise fit
into our existing practice with minimal change.
I'm not trying to present this as the ideal working situation, but it
is what we're having to deal with presently. CL is certianly the
ideal tool for this.
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
Ask me about Common Lisp Enterprise Eggplants at Red Bean!
······@interaccess.com (Thaddeus L Olczyk) writes:
> I'm wondering if:
> 1) It's true that lisp programmers eschew XP.
Well, _this_ lisp programmer set up an XP shop.
> My feeling is that lisp programmers generally do not follow a
> methodology but have something I would call a "style" of programming
> which is similar to a methodology and that they tend to believe in
> that methodology.
Well, programming style and methodology don't have much to do with
each other. And methodology is not something you "believe in"
(that's called "religion"), it's a process you follow because it helps
you create usable, cheap, maintainable software quickly. Or not,
depending on your methodology. :-)
I'm guessing that most lisp programmers are less into the "methodology" thing
than most communities because they use a language which is incredibly
powerful, so they can do their job with a much smaller team. Small teams
make methodology issues less important, I _suspect_.
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
Alain Picard <·······@optushome.com.au> writes:
> I'm guessing that most lisp programmers are less into the "methodology" thing
> than most communities because they use a language which is incredibly
> powerful, so they can do their job with a much smaller team. Small teams
> make methodology issues less important, I _suspect_.
I've worked in a small CL team, ranging in size from 2-5, over the
last few years and in my situation methodology, formalized to varying
degrees and adressing the process at several levels of abstraction, is
quite important. The group I work with has been together for several
years, so some of the methodological structures are sublimated beneath
basic operating assumptions and would be difficult to abstract from
our situation in a manner that would fit many other situations. Other
parts are more formalized, recognizable and documented community
practices with regards to things like coding/text style, source
management, bug tracking, user relationship management. Then there
are formal methodological tactics we've picked up from outside
sources; release packaging, documentation formats, licensing and
regression testing.
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
Ask me about Common Lisp Enterprise Eggplants at Red Bean!