From: David Steuber
Subject: Programming By The Seat Of Your Pants
Date:
Message-ID: <m2he21a30w.fsf@verizon.net>
This isn't really quite on topic for c.l.l, but it is strongly
related.
I am in a situation with myself where I need to basically code by the
seat of my pants. Why? I have no design, no solid requirements, and
generally have only a vague idea of what I want. Lisp* seems like
the tool for the job. Besides, the only way I'm going to learn Lisp
is to program in it.
Programming by the seat of my pants is something that I do more often
than not. Sure, I don't have a solid idea for my project, just a
vague notion. It is never really that different in the business
world that I have had experience with. The business wants X but they
don't seem to want to tell me what X really is.
When pressed, the business will come up with what they think is a
precise definition of X. To me, it is still hand waving, only with
pictures. Then they like to say, "so how long will this take?" Um.
Yeah. If I knew how long it would take, then I would know what the
problem was and its solution. If I know the solution, I have already
solved the problem.
I can't seem to convince people that time estimates are crap. There
are even programmers out there who think that meaningful time
estimates are possible. If you are one of those people, please tell
me what the hell you smoke so I can get some.
As for specifications that are not vague, I guess UML would be the
king. The problem with UML is that you model a solution or process
to such exacting detail that you have basically just programmed the
bloody thing. Just run the UML through a code generator and you are
done. UML and design patterns that go with it are popular because
C++ and, later, Java are really the suck for programming anything
that is not well defined ahead of time.
I don't work well that way. As a C++ programmer the text editor has
always been a doodle pad for me. I have always had a very tight code
compile test loop. When programming in Perl, the loop just got
tighter. The editor was still a scratch pad. I would program top
down. I need to do something like X. Well I can do that if I do A,
B, and C. And so on until the details were filled in.
I keep hearing about Lisp as a bottom up programming language. Is
that really the case? Yeah, you use macros to build the language up
to the problem level. If you do that unguided though, what are you
building up to? Top down seems more natural. You start out with
(DWIM X) and start to define DWIM.
Or do you just do stuff with macros and feel clever when you can do
something useful? That doesn't seem like a goal oriented approach to
me.
Getting closer to my specific situation which is really a nebulous
concept that I can't tell you about... I have a number of things
that I want to do. I have various entities that have various
properties and need to interact in a rules based environment.
Entities can have arbitrary properties and need to interact
accordingly, even though entity A may know nothing about B.
Add to that an external entity. This imaginary entity is called the
user and must direct the flow of the internal entities. When the
user is feeling lazy, some of the internal entities must self direct.
If I'm not being vague enough, please let me know.
So basically I have all this stuff going on. But it can't just go on
in a random fashion except when dice rolling is required. There are
rules that are part of a larger framework that all the entities have
to work in. The user may also want to customize an arbitrary set of
rules. That seems difficult to me, so I will probably have to
restrict the user.
Users hate to be restricted.
I think I can state my dilemma now. I need to program in such a way
as to take a random mash of ideas and self organize into a coherent
program in the way life organizes from cells into a living organism.
I just don't know what that organism is yet.
How is this problem solved in general and in Lisp in particular?
*When I say Lisp in this group, I mean ANSI Common Lisp.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
In article <··············@verizon.net>, David Steuber
<·············@verizon.net> wrote:
> This isn't really quite on topic for c.l.l, but it is strongly
> related.
>
> I am in a situation with myself where I need to basically code by the
> seat of my pants. Why? I have no design, no solid requirements, and
> generally have only a vague idea of what I want. Lisp* seems like
> the tool for the job. Besides, the only way I'm going to learn Lisp
> is to program in it.
>
> Programming by the seat of my pants is something that I do more often
> than not. Sure, I don't have a solid idea for my project, just a
> vague notion. It is never really that different in the business
> world that I have had experience with. The business wants X but they
> don't seem to want to tell me what X really is.
>
> When pressed, the business will come up with what they think is a
> precise definition of X. To me, it is still hand waving, only with
> pictures. Then they like to say, "so how long will this take?" Um.
> Yeah. If I knew how long it would take, then I would know what the
> problem was and its solution. If I know the solution, I have already
> solved the problem.
>
> I can't seem to convince people that time estimates are crap. There
> are even programmers out there who think that meaningful time
> estimates are possible. If you are one of those people, please tell
> me what the hell you smoke so I can get some.
"Extreme Programming" is the buzzword/brand-name for the particular
variety of packaged experience that I've seen working well with this
problem domain. There are other approaches that have pretty good
reputations.
I've been doing this software gig for about 15 years and have worked on
a variety of small-to-large projects. Some have been very well
organized and successful, some miserable failures. The most
consistently successful one I've ever seen is the one I'm working on
right now. It started as a group of engineers in a company that had
just discovered that its market had evaporated, and so we had to --
quickly -- come up with something we could do and that people would
want to buy. How's that for vague and underspecified? Well, we did it.
For various reasons, several of us liked the "Extreme Programming"
approach, and persuaded the company to adopt it as a methodology. It
has worked very well. To boil it down, you get a customer to make some
demands. You turn the demands into 'stories' (a paragraph or so for
each customer-imagined feature that explains what the customer wants it
to do).
Then engineers pair off and estimate how long it will take to implement
each feature. If one of them takes less than a day, you combine it with
something else. If something takes more than about five days, you break
it up into pieces and estimate those. That's because estimates less
than a day or more than five days are worthless.
Then your pairs of programmer implement, for each feature, the simplest
possible thing that could be said to satisfy the relevant 'story'. You
do it by first writing unit tests for something that, if it passes the
tests, it's a solution. Then you write code that passes the tests. Then
you show it to the customer and say 'what's wrong with it?' That
generates an amended version of the story and you repeat until the
software is (close to) what is wanted.
Key things are:
- you talk to the customer all the time
- you work with another programmer because it's faster and more reliable
- you test all the time
- you always have running code (one of our rules is that if anything
breaks the build or the test suite, everyone drops everything and works
on fixing the software until the build and the test suite work again;
in two years I don't think we've had a breakage last longer than about
a day).
- you refactor all the time.
Dynamic languages are very good for this model. It comes out of the
Smalltalk world, but Lisp is of course very good for it.
I've no doubt that there will be people who don't like the model, but
it has worked very well for us. Our survival has depended on it working
well, so you could argue that compels it to succeed; but on the other
hand, it's still a model that we were able to succeed with.
I think it's a lot friendlier to hackers than the waterfall model, and
other models that emphasize ultra-detailed specs and long formal
processes. The problem with those is exactly what you suggested: the
problem needs to be essentially solved before you do any work on it,
and that's rarely the case in writing software products or software for
business. Much more often the customers only have a vague idea of what
they want. The model of coding up a first approximation really fast and
showing it to them allows them to look at it and say 'yeah, but it
should do this instead', and you can triangulate the specification
fairly rapidly.
-- snip --
From: David Steuber
Subject: Re: Programming By The Seat Of Your Pants
Date:
Message-ID: <m265igaixb.fsf@verizon.net>
mikel <·····@evins.net> writes:
> Then engineers pair off and estimate how long it will take to implement
> each feature. If one of them takes less than a day, you combine it with
> something else. If something takes more than about five days, you break
> it up into pieces and estimate those. That's because estimates less
> than a day or more than five days are worthless.
I've done only a limited amount of XP. The biggest problem is that
you need two programmers who can work together!
The time estimate method you describe in the quoted paragraph sounds
good on paper, but I have never gotten it to work. The problem comes
in with the thing that takes longer than about five days (an
arbitrary time cut-off) and needs to be broken down. The number of
pieces required and the subsequent time estimates on those are sure
to lead to error. At least that has been my experience. Also, the
process of chunking down the problem is, by definition, analysis that
leads to solving the problem.
Another problem is when that one day long chunk takes three days ;-)
I've had so much pain with time estimates that I would rather deliver
a prototype product than an estimate. Both take about the same
effort.
Sadly, this leads to the problem of estimating how long it will take
to get a time estimate. Damn turtles all the way down.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
In article <··············@verizon.net>, David Steuber
<·············@verizon.net> wrote:
> mikel <·····@evins.net> writes:
>
> > Then engineers pair off and estimate how long it will take to implement
> > each feature. If one of them takes less than a day, you combine it with
> > something else. If something takes more than about five days, you break
> > it up into pieces and estimate those. That's because estimates less
> > than a day or more than five days are worthless.
>
> I've done only a limited amount of XP. The biggest problem is that
> you need two programmers who can work together!
That's true, and if you have a room full of programmers who can work
together then you may have solved a large part of the problem. Whether
through skill or through luck we seem to have a room full of
programmers who can all work together in more or less arbitrary
combination.
> The time estimate method you describe in the quoted paragraph sounds
> good on paper, but I have never gotten it to work. The problem comes
> in with the thing that takes longer than about five days (an
> arbitrary time cut-off) and needs to be broken down. The number of
> pieces required and the subsequent time estimates on those are sure
> to lead to error. At least that has been my experience. Also, the
> process of chunking down the problem is, by definition, analysis that
> leads to solving the problem.
> Another problem is when that one day long chunk takes three days ;-)
Yes. We solve both the above problems by assuming we are wrong to some
degree from the beginning and by iterating the schedule almost as often
as we do the tests. In particular, I iintroduced the 'screwedness
index', which calculates how screwed we are every day with respect to
meeting our planned release. Any time this index goes positive we
petition the customer to let us cut features for the release. That
handles the 'one day is really three days' problem. The cut features
remain on the schedule in a sort of limbo, sorted by customer-assigned
priority, and they get added back to the schedule when things get done
quicker than planned (which happens fairly regularly).
> I've had so much pain with time estimates that I would rather deliver
> a prototype product than an estimate. Both take about the same
> effort.
We always do the time estimates all together in teams in one day. We
have made every release deadline for two years (though we've sometimes
cut or deferred a few features to do it; on the other hand, we've
sometimes added a few features owing to strong customer demand, so
maybe it's a wash).
> Sadly, this leads to the problem of estimating how long it will take
> to get a time estimate. Damn turtles all the way down.
Logically, it's a problem. Practically, it doesn't seem to be. But I
can't say how much of our success is due to the method and how much is
due to the people and the culture we've invented for ourselves.
Presumably the latter are important. It is working very well, though;
as I said, better than I've seen before.
David Steuber <·············@verizon.net> writes:
> When pressed, the business will come up with what they think is a
> precise definition of X. To me, it is still hand waving, only with
> pictures. Then they like to say, "so how long will this take?" Um.
> Yeah. If I knew how long it would take, then I would know what the
> problem was and its solution. If I know the solution, I have already
> solved the problem.
>
> I can't seem to convince people that time estimates are crap. There
> are even programmers out there who think that meaningful time
> estimates are possible.
They are possible, but only sometimes. Sometimes you can kind of
guess -- you'll likely be wrong, but you can keep changing your
estimate as they change their requirements, so by the time they're
done changing their "spec", you've explored the problem space well
enough to make a meaningful estimate. And then there's the times you
just have no idea.
> If you are one of those people, please tell me what the hell you
> smoke so I can get some.
I think it's the coffee, actually :)
(Torrefazione and Lavazza)[*]
> I keep hearing about Lisp as a bottom up programming language. Is
> that really the case? Yeah, you use macros to build the language up
> to the problem level. If you do that unguided though, what are you
> building up to? Top down seems more natural. You start out with
> (DWIM X) and start to define DWIM.
The trick is, you do both. Where does X come from? (That's the first
thing the debugger is gonna complain about, anyway). Often, there are
a lot of modules that you can discover you need early on. Write those
bottom-up. Now start working on DWIM. Think about it, sketch stuff
out -- by now you've got a good idea of what you need to start
actually writing DWIM version 0.1-buggy. Go back to the bottom, and
start building yourself this custom language. Now you've got a bunch
of debugged modules, and a working language to write DWIM in, and you
can get back to the problem at hand, confident that any bugs are in
the layer you're working on. This approach is recursive, of course
(you take the same approach to implementing the language that DWIM is
written in, as you do implementing DWIM).
Bottom-up, as practiced in Lisp, is just eXtreeeeeeemeeee Programing,
without all the Mountain Dew or heavy metal.
[*] Look, ma, for once I corrected my aweful Italian spelling!
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@famine.OCF.Berkeley.EDU>, Thomas F. Burdick wrote:
> David Steuber <·············@verizon.net> writes:
{snip!}
> I think it's the coffee, actually :)
> (Torrefazione and Lavazza)[*]
>> You start out with
>> (DWIM X) and start to define DWIM.
{snip!}
> [*] Look, ma, for once I corrected my aweful Italian spelling!
You know, if you implemented DWIM, it would correct your spelling
-for- you (or have you already implemented it, and this is merely an
ironic posting because you're withholditg it from the rest of the world...?)
Bruce
--
·······@sdf.lonestar.org www.not-art.org
SDF Public Access UNIX System - http://sdf.lonestar.org
Habit diminishes the conscious attention
with which our acts are performed.
Bruce Nagel <·······@sdf.lonestar.org> writes:
> You know, if you implemented DWIM, it would correct your spelling
> -for- you (or have you already implemented it, and this is merely an
> ironic posting because you're withholditg it from the rest of the world...?)
I'm working on it, but I'm still 12 backtraces deep :)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
David Steuber wrote:
> Programming by the seat of my pants is something that I do more often
> than not. Sure, I don't have a solid idea for my project, just a
> vague notion. It is never really that different in the business
> world that I have had experience with. The business wants X but they
> don't seem to want to tell me what X really is.
>
> When pressed, the business will come up with what they think is a
> precise definition of X. To me, it is still hand waving, only with
> pictures. Then they like to say, "so how long will this take?" Um.
> Yeah. If I knew how long it would take, then I would know what the
> problem was and its solution. If I know the solution, I have already
> solved the problem.
If you are dealing with customers who don't understand what they want,
you really, really should employ an evolutionary model of development.
Have rapid releases for customer feedback, even if most of the functions
are just stubbed out.
You probably want to look at Extreme Programming or some similar
buzzword-compliant model. Lisp is well suited to this kind of
development.
Paul
David Steuber wrote:
> I think I can state my dilemma now. I need to program in such a way
> as to take a random mash of ideas and self organize into a coherent
> program in the way life organizes from cells into a living organism.
> I just don't know what that organism is yet.
I went thru all that on a grand scale with our big CliniSys application.
I identified a critical path of capabilities to be developed and
techical challenges to overcome, then went at them in some reasonable
order. As they fell into place, details which had not worried me were
filled in. Those get deferred as long as possible because the code
rapidly mushrooms, and the refactoring becomes that much more tedious.
That also means one can defer the "embedded language" thing longer,
until you are ready to scale.
Lisp and CLOS are good for this because the compiler doesn't much care
what you are doing, so you are free to move things around, compile
classes before their superclasses, redefine things left and right,
without fussing all the time with maintaining headers consistent with
the code youare trying to write.
kt
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Kenny Tilton <·······@nyc.rr.com> writes:
> Lisp and CLOS are good for this because the compiler doesn't much care
> what you are doing, so you are free to move things around, compile
> classes before their superclasses, redefine things left and right,
> without fussing all the time with maintaining headers consistent with
> the code youare trying to write.
In addition, Lisp and CLOS is good for underspecified projects because
of the powerful constructs that you can use to tweak your original model
as the specifications change. Here are a few tips on how to make your
application as tweakable as possible:
- remember to use keyword arguments to functions. Then you can add features
without breaking old calls to the function.
- don't be afraid of using CLOS. Don't fuss with structures or arrays/lists
if you're not positively sure that CLOS won't be fast enough.
- whenever you think a function might be a generic function, make it a
generic function. Suddenly you can get new specs that may be solved by
adding one single two-line method.
- dynamic variables are cool too. Sometimes the combination of a
dynamic variable, a tiny mixin class and a :around (or :before/after)
method can add orthogonal functionality to your system that you hadn't
even been able to _dream_ of when you wrote the original spec. (Who
needs AscpectJ?)
and finally,here's a little thought-food for those who think lisp is
an elite-only language:
Make the configuration part of your application be heavily based on
those "dangerous" multi-methods, let them dispatch on as many
variables as possible (not only on clos objects, EQL-dispatch is great
too) and then hide them from the user with a thick layer of
macrology. Then you'll see that you can write "configuration files"
that non- or half-programmers will be able to maintain and which will
compile into efficient code.
Here's a little example copied straight out of a program I'm currently
working on (there are probably much better examples, but this was
the most immediate at hand right now):
BO-TICKET 46 > (pprint
(macroexpand-1
'(define-fee-rule (t st no)
(+ (* value 0.0005) 30))))
(DEFMETHOD COMPUTE-FEE
((FEE-CLASS T)
(EXCH-CLASS (EQL :ST))
(COUNTRY-CLASS (EQL :NO))
(USER NO.NETFONDS.BO.DB:USER)
ORDERS)
(LET ((VALUE 0) (QUANTITY 0))
(DOLIST (O ORDERS)
(INCF VALUE (APPLY-CURRENCY-RATE O (DEAL-PRICE O) USER))
(INCF QUANTITY (DEAL-FILLED-NUMBER O)))
(+ (* VALUE 5.0E-4) 30)))
--
(espen)
"David Steuber" <·············@verizon.net> wrote in message
···················@verizon.net...
> This isn't really quite on topic for c.l.l, but it is strongly
> related.
>
> I am in a situation with myself where I need to basically code by the
> seat of my pants. Why? I have no design, no solid requirements, and
> generally have only a vague idea of what I want. Lisp* seems like
> the tool for the job. Besides, the only way I'm going to learn Lisp
> is to program in it.
>
> Programming by the seat of my pants is something that I do more often
> than not. Sure, I don't have a solid idea for my project, just a
> vague notion. It is never really that different in the business
> world that I have had experience with. The business wants X but they
> don't seem to want to tell me what X really is.
>
> When pressed, the business will come up with what they think is a
> precise definition of X. To me, it is still hand waving, only with
> pictures. Then they like to say, "so how long will this take?" Um.
> Yeah. If I knew how long it would take, then I would know what the
> problem was and its solution. If I know the solution, I have already
> solved the problem.
>
Buisiness people and managers are playing the power game. They don't want
craftsman, they want interchangeable parts. With that midset comes
necessarily the belief that what you do is factory work. They give you w
vague idea what they want and you should just tell them how long it will
take.
> I can't seem to convince people that time estimates are crap. There
> are even programmers out there who think that meaningful time
> estimates are possible. If you are one of those people, please tell
> me what the hell you smoke so I can get some.
>
I have had similar experiences. There is always the belief that if one
writes a careful spec then one can make precise time estimates. The problem,
as Paul Graham points out is that specs and code are made of the same thing.
If a spec were that precise it would be the code! And, its true that the
customer may say that want X but you have to look deeper to see that they
need Y. In the best case, when you're done they'll say "Yeah, but we also
need Z, that's easy enough to do right?" And if you have a GUI and there are
n people involved (and you have no bugs with your system) you can expect to
have n+1 opinions about how the GUI should be changed.
What I found was that if you are developing an product that is a "me too"
application, you find that even with poor specifications that everyone has
pretty nuch internalized a spec for the product. And times estimates in the
large can be more accurate if you'be done similar things. It's when you are
working on something that hasn't been built before that time estimaties are
very hard to do; that specifications written or otherwise are bad. You can
expect to have someone make you give an estimate of the time and then you
can expect to have the product change directions many times. During this
process, there is much more experimentation going on; of course, if you ever
mention to someone that you are experimenting you might be shown the door. I
found at the time that I could use scripting languages, Tcl/Tk (along with
various extentions like [Incr Tcl] that gave you an object system. Later it
was Python, a better scripting language. You had to fight against the rest
of the company that used "real" langauges like C or C++. Most people didn't
get that (especially new) product development could be done much faster with
dynamic interactive langauges. The problem I had was that for speed I had to
drop down to a "real" language. Thus, ultimately I ended up with
applications that had some scriptability, but suffered from
1). Having to interface 2 languages more than I wanted.
2). Working with lame scripting languages.
I wondered if I could find a language that was this interactive, yet could
compile to native code when I was done. I also wondered if I could find a
language that didn't have a dicked-up single dispatch object system. The
answer of course is Lisp. The problem is that once you start using Lisp it
is going to be really hard to go back to any other language. The problems I
see with using Lisp are the following:
1). Not much in the way of libraries.
a). Well, if you pick a hard problem, there most likely won't be much
library support in other langages either.
b). You can still write the core in Lisp, get scriptability and use a
foreign function interface to other libraries. Yes, I know the 2 langauges
thing. At least you won't be doing it for performance reasons.
2). Lisp is different. There is a lot to learn and the concepts don't map
easily to other langauges. We need better books or examples of how to use
the various features.
a). This is changing, I think you'll see at least one, maybe two books
next year that address this.
3). Standardization: This really impacts point (1). This is not so much of a
problem for an application as it is for people building libraries. We need
something akin to Perls CPAN. Without libraries that you can pull off the
internet and install easily, Lisp is going to find it hard to compete with
the scripting langagues in a lot of areas. I personally don't want to go
back to those languages.
a). I would like to see the ALU bless "defacto" standards and get the
vendors to work on standards for multi-processing, sockets, etc.
By defacto standards I mean the following:
defsystem --> ASDF
test harness --> PTESTER
Web server/HTML generation --> ASERVE, LML2
Regular Expressions --> CL-PPCRE
Foreign Function Interface --> UFFI
Emacs interafction --> ELI (A good interactive environment shows the
power of the interactive nature of Lisp.)
This is sure to spark some debate. Let me just say, if we can't agree on
one item, bless 2. So, if we can't determine whether ASDF or mkdefsystem is
better bless both. But lets try to agree to focus on writting ANSI compliant
libraries in a way that people with a minimal number of standard packages
can pull down libraries off the internet and just have them work. We should
also try and pull together some of the libraries we do have and put them in
one place.
4). GUI's:
Maybe the answer is to use a web interace. Or maybe there should be
something that the vendors can standardize (this is asking a lot and may be
unreasonable). Or, maybe the answer is CLIM. We'll need a lot more examples
of how to use this puppy if that is the case.
> As for specifications that are not vague, I guess UML would be the
> king. The problem with UML is that you model a solution or process
> to such exacting detail that you have basically just programmed the
> bloody thing. Just run the UML through a code generator and you are
> done. UML and design patterns that go with it are popular because
> C++ and, later, Java are really the suck for programming anything
> that is not well defined ahead of time.
>
Amen to that.
> I don't work well that way. As a C++ programmer the text editor has
> always been a doodle pad for me. I have always had a very tight code
> compile test loop. When programming in Perl, the loop just got
> tighter. The editor was still a scratch pad. I would program top
> down. I need to do something like X. Well I can do that if I do A,
> B, and C. And so on until the details were filled in.
>
Lisp is your friend here.
> I keep hearing about Lisp as a bottom up programming language. Is
> that really the case? Yeah, you use macros to build the language up
> to the problem level. If you do that unguided though, what are you
> building up to? Top down seems more natural. You start out with
> (DWIM X) and start to define DWIM.
>
> Or do you just do stuff with macros and feel clever when you can do
> something useful? That doesn't seem like a goal oriented approach to
> me.
>
There are much more eperienced people here than I. I have found that it is
best to think more closely at how defun is defined. It is a macro that
associates code with a symbol. You can do the same with whatever system you
want to define. I would first build the raw functions you need for your app,
then add a macro layer that allows you to write things the way you want to
write them. For instance, I have a fuzzy logic package. I have a macro that
defines a fuzzy system, its called deffuzzy. With this macro I can write a
fuzzy system the way that a customer (or myself) would like to see it
specified. The macro then takes a look at the arguements and does a lot of
checking. The macro checks the structure of the arguements, ranges,
consistency between various bits of information. Something, that a static
type checker can't do by the way. Performance - don't care here, I do as
much checking as I want. After checking, the fuzzy rules of the fuzzy
variables are COMPILED. Performance, - don't care here. By the way, the
compiler is built in, I didn't have to make one. When one runs the rules, I
have compiled code that is fast. Performance - I care now.
In other general purpose languages, the language designer made the tradoffs
for performance and error checking for a general purpose language. In Lisp,
I can, for a given domain, make the appropriate decisions myself. Did I
mention that I can call the compiler too?
"Scott McIntire" <····················@comcast.net> writes:
> 3). Standardization: This really impacts point (1). This is not so much of a
> problem for an application as it is for people building libraries. We need
> something akin to Perls CPAN. Without libraries that you can pull off the
> internet and install easily, Lisp is going to find it hard to compete with
> the scripting langagues in a lot of areas. I personally don't want to go
> back to those languages.
> a). I would like to see the ALU bless "defacto" standards and get the
> vendors to work on standards for multi-processing, sockets, etc.
> By defacto standards I mean the following:
> defsystem --> ASDF
> test harness --> PTESTER
> Web server/HTML generation --> ASERVE, LML2
> Regular Expressions --> CL-PPCRE
> Foreign Function Interface --> UFFI
> Emacs interafction --> ELI (A good interactive environment shows the
> power of the interactive nature of Lisp.)
>
> This is sure to spark some debate. Let me just say, if we can't agree on
> one item, bless 2. So, if we can't determine whether ASDF or mkdefsystem is
> better bless both. But lets try to agree to focus on writting ANSI compliant
> libraries in a way that people with a minimal number of standard packages
> can pull down libraries off the internet and just have them work. We should
> also try and pull together some of the libraries we do have and put them in
> one place.
Have you tried ASDF-INSTALL? A little utility that comes with asdf,
and uses CLiki to install libraries (and their dependencies) from the
internet. Who needs the ALU's blessing? I can _already_
asdf-install, from my lisp implementation,
araneida, lml2 (for web serving and html generation)
cl-ppcre, cl-interpol (for regexps)
uffi (for ffi)
mk-defsystem (should you wish to have /another/ defsystem :-)
and numerous other packages. See http://www.cliki.net/asdf-install
* (require 'asdf-install)
("SB-EXECUTABLE" "SB-GROVEL" "SB-POSIX" "SB-BSD-SOCKETS" "ASDF-INSTALL" "ASDF")
* (asdf-install:install 'uffi) ; I don't have it installed already
[ ... time passes ... uffi is downloaded, its signature checked,
placed in ~/.sbcl/site/uffi-1.3.6 and compiled. Subsequent
invocations of lisp can load it by (require 'asdf) (require 'uffi) ]
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
From: Scott McIntire
Subject: Re: Programming By The Seat Of Your Pants
Date:
Message-ID: <uExlb.2$HS4.413@attbi_s01>
"Christophe Rhodes" <·····@cam.ac.uk> wrote in message
···················@lambda.jcn.srcf.net...
> "Scott McIntire" <····················@comcast.net> writes:
>
> > 3). Standardization: This really impacts point (1). This is not so much
of a
> > problem for an application as it is for people building libraries. We
need
> > something akin to Perls CPAN. Without libraries that you can pull off
the
> > internet and install easily, Lisp is going to find it hard to compete
with
> > the scripting langagues in a lot of areas. I personally don't want to go
> > back to those languages.
> > a). I would like to see the ALU bless "defacto" standards and get the
> > vendors to work on standards for multi-processing, sockets, etc.
> > By defacto standards I mean the following:
> > defsystem --> ASDF
> > test harness --> PTESTER
> > Web server/HTML generation --> ASERVE, LML2
> > Regular Expressions --> CL-PPCRE
> > Foreign Function Interface --> UFFI
> > Emacs interafction --> ELI (A good interactive environment shows
the
> > power of the interactive nature of Lisp.)
> >
> > This is sure to spark some debate. Let me just say, if we can't
agree on
> > one item, bless 2. So, if we can't determine whether ASDF or mkdefsystem
is
> > better bless both. But lets try to agree to focus on writting ANSI
compliant
> > libraries in a way that people with a minimal number of standard
packages
> > can pull down libraries off the internet and just have them work. We
should
> > also try and pull together some of the libraries we do have and put them
in
> > one place.
>
> Have you tried ASDF-INSTALL? A little utility that comes with asdf,
> and uses CLiki to install libraries (and their dependencies) from the
> internet. Who needs the ALU's blessing? I can _already_
> asdf-install, from my lisp implementation,
> araneida, lml2 (for web serving and html generation)
> cl-ppcre, cl-interpol (for regexps)
> uffi (for ffi)
> mk-defsystem (should you wish to have /another/ defsystem :-)
> and numerous other packages. See http://www.cliki.net/asdf-install
>
> * (require 'asdf-install)
> ("SB-EXECUTABLE" "SB-GROVEL" "SB-POSIX" "SB-BSD-SOCKETS" "ASDF-INSTALL"
"ASDF")
>
> * (asdf-install:install 'uffi) ; I don't have it installed already
>
> [ ... time passes ... uffi is downloaded, its signature checked,
> placed in ~/.sbcl/site/uffi-1.3.6 and compiled. Subsequent
> invocations of lisp can load it by (require 'asdf) (require 'uffi) ]
>
> Christophe
No I wasn't aware of this, thanks Christophe. How do people make new
libraries so that they work with ASDF-INSTALL?
-R. Scott McIntire
"Scott McIntire" <····················@comcast.net> writes:
> "Christophe Rhodes" <·····@cam.ac.uk> wrote in message
> ···················@lambda.jcn.srcf.net...
>> Have you tried ASDF-INSTALL?
>
> No I wasn't aware of this, thanks Christophe. How do people make new
> libraries so that they work with ASDF-INSTALL?
It's largely documented on <http://www.cliki.net/asdf-install>.
Essentially, all that you need to do is have a tarball of your library
(with an asdf system description) in a web-accessible location, say
<http://example.com/foo_1.2.3.tar.gz>, and alongside it a gpg
signature, <http://example.com/foo_1.2.3.tar.gz.asc>. Then, on the
http://www.cliki.net/foo page, add
:(package "http://example.com/foo_1.2.3.tar.gz")
and hey presto. (There's more detail on cliki).
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes wrote:
> Have you tried ASDF-INSTALL? A little utility that comes with asdf,
> and uses CLiki to install libraries (and their dependencies) from the
> internet.
...
> * (require 'asdf-install)
> ("SB-EXECUTABLE" "SB-GROVEL" "SB-POSIX" "SB-BSD-SOCKETS" "ASDF-INSTALL" "ASDF")
>
> * (asdf-install:install 'uffi) ; I don't have it installed already
>
> [ ... time passes ... uffi is downloaded, its signature checked,
> placed in ~/.sbcl/site/uffi-1.3.6 and compiled. Subsequent
> invocations of lisp can load it by (require 'asdf) (require 'uffi) ]
That's beautiful but terrifying. What's to stop some
evildoer making a subtly altered version of (say) UFFI
that destroys your system, mails out viruses, or makes
demons fly out of your nose, when it's compiled, making
a GPG signature for it, and then editing the CLiki page
to point to his malicious version instead of where it
should point?
Of course, similar games can be played with any
package system, but most of them don't put the
package download locations on a universally-editable
server.
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <·····@g.local> writes:
>> [ ... time passes ... uffi is downloaded, its signature checked,
>> placed in ~/.sbcl/site/uffi-1.3.6 and compiled. Subsequent
>> invocations of lisp can load it by (require 'asdf) (require 'uffi) ]
>
> That's beautiful but terrifying. What's to stop some
> evildoer making a subtly altered version of (say) UFFI
> that destroys your system, mails out viruses, or makes
> demons fly out of your nose, when it's compiled, making
> a GPG signature for it, and then editing the CLiki page
> to point to his malicious version instead of where it
> should point?
The gpg test tests for the key being in a list of known-and-trusted
uids; if the key that has signed a package is not in the list, then
the debugger is entered.
This in many ways isn't ideal, and is a subtly different problem from
the "web of trust" problem in (some) other distributed efforts; as I
understand it, typically signing a gpg key means "I have made a
certain effort to establish that the owner of this key is indeed Joe
Bloggs", whereas here we want to establish "I reckon this key's owner
probably won't upload malicious code".
> Of course, similar games can be played with any
> package system, but most of them don't put the
> package download locations on a universally-editable
> server.
Indeed. :-)
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes <·····@cam.ac.uk> writes:
> Gareth McCaughan <·····@g.local> writes:
>> That's beautiful but terrifying. What's to stop some
>> evildoer making a subtly altered version of (say) UFFI
>> that destroys your system, mails out viruses, or makes
>> demons fly out of your nose, when it's compiled, making
>> a GPG signature for it, and then editing the CLiki page
>> to point to his malicious version instead of where it
>> should point?
>
> The gpg test tests for the key being in a list of known-and-trusted
> uids; if the key that has signed a package is not in the list, then
> the debugger is entered.
You probably get a couple of errors, in fact
First we check that there's a trust relationship between you and the
key that the package was signed with - so if Clarence just creates and
uploads a new key that purports to belong to Bob (a.k.a Kevin
Rosenberg, UFFI author), Alice will get an error when installing it.
[ There isn't much of a web of trust between PGP-using Lispers as far
as I know, but Kevin's a Debian developer and Debian developers take
GPG seriously, so find a local one and see if you can get a link to
him that way. Alternatively, this is a continuable error, so even
if you don't know any Linux hackers you can carry on at your own risk.]
Then, let's suppose that you _do_ have a trust relationship with the
interloper's key: in that case, the second line of defence is that we
check the package signature against a local approved-suppliers-of-lisp
list of fingerprints before we install it.
[ So currently you don't have any such list, because you don't know
which Lisp developers you can trust. Hey, guess, what, this is a
social problem, not a technical problem. Read the code, make up your
own mind as you'd have to anyway ]
I'm contemplating adding some kind of per-package mapping to allowed
signatures, so that I could say "install uffi only from kevin, cl-gd
only from edi weitz ...", but I think that probably just makes things
more complicated than people want to cope with.
:; cat ~/.sbcl/trusted-uids.lisp
(("595FF045057958C6" "Dr. Edmund Weitz <···@weitz.de>"))
:; # ok, I haven't installed much software on this machine lately
-dan
--
http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro
Christophe Rhodes wrote:
[I asked:]
> > That's beautiful but terrifying. What's to stop some
> > evildoer making a subtly altered version of (say) UFFI
> > that destroys your system, mails out viruses, or makes
> > demons fly out of your nose, when it's compiled, making
> > a GPG signature for it, and then editing the CLiki page
> > to point to his malicious version instead of where it
> > should point?
>
> The gpg test tests for the key being in a list of known-and-trusted
> uids; if the key that has signed a package is not in the list, then
> the debugger is entered.
Gotcha.
--
Gareth McCaughan
.sig under construc
From: ·············@comcast.net
Subject: Re: Programming By The Seat Of Your Pants
Date:
Message-ID: <7k2xdls4.fsf@comcast.net>
Gareth McCaughan <·····@g.local> writes:
> What's to stop some evildoer making a subtly altered version of
> (say) UFFI that destroys your system, mails out viruses, or makes
> demons fly out of your nose, when it's compiled, making a GPG
> signature for it, and then editing the CLiki page to point to his
> malicious version instead of where it should point?
How about lack of experience with Lisp?
But suppose that some evildoer *does* manage to infect the machines of
*every* Lisp hacker out there and attempts to launch a distributed
denial-of-service attack against some target.
No! You're not supposed to be laughing at this point!
Scott McIntire writes:
> 3). Standardization: This really impacts point (1). This is not so much of a
[...]
> This is sure to spark some debate. Let me just say, if we can't agree on
> one item, bless 2. So, if we can't determine whether ASDF or mkdefsystem is
> better bless both. But lets try to agree to focus on writting ANSI compliant
If I understand correctly, this is Kent Pitman's "substandards"
approach.
> write them. For instance, I have a fuzzy logic package. I have a macro that
> defines a fuzzy system, its called deffuzzy. With this macro I can write a
> fuzzy system the way that a customer (or myself) would like to see it
> specified. The macro then takes a look at the arguements and does a lot of
If this is not confidential information, you might consider adding an
entry for your company at the ALU CLiki industrial applications page:
http://alu.cliki.net
Paolo
--
Paolo Amoroso <·······@mclink.it>
From: Scott McIntire
Subject: Re: Programming By The Seat Of Your Pants
Date:
Message-ID: <5wBlb.394$Fm2.1449@attbi_s04>
"Paolo Amoroso" <·······@mclink.it> wrote in message
···················@plato.moon.paoloamoroso.it...
> Scott McIntire writes:
>
> > 3). Standardization: This really impacts point (1). This is not so much
of a
> [...]
> > This is sure to spark some debate. Let me just say, if we can't
agree on
> > one item, bless 2. So, if we can't determine whether ASDF or mkdefsystem
is
> > better bless both. But lets try to agree to focus on writting ANSI
compliant
>
> If I understand correctly, this is Kent Pitman's "substandards"
> approach.
>
Yes.
>
> > write them. For instance, I have a fuzzy logic package. I have a macro
that
> > defines a fuzzy system, its called deffuzzy. With this macro I can write
a
> > fuzzy system the way that a customer (or myself) would like to see it
> > specified. The macro then takes a look at the arguements and does a lot
of
>
> If this is not confidential information, you might consider adding an
> entry for your company at the ALU CLiki industrial applications page:
>
> http://alu.cliki.net
>
The work mentioned above is not confidential, it is part of my free( BSD
style) utilities at http://sourceforge.net/projects/com-lisp-utils
The reason I asked about standards is that I think it is important to write
libraries that any ANSI Common Lisp implementation will run. It took some
work and education for me to get these utilities to be compliant. I would
like it to be easier for people to do this. I would also like there to be a
common place to put them. My homework is to look into ASDF-INSTALL - maybe
that's the answer.
-- R. Scott McIntire
From: Nikodemus Siivola
Subject: Libraries (Was: Programming By The Seat Of Your Pants)
Date:
Message-ID: <bn88o0$38846$1@midnight.cs.hut.fi>
Scott McIntire <····················@comcast.net> wrote:
> We should
> also try and pull together some of the libraries we do have
> and put them in one place.
I hope that you are aware of the following:
http://www.cliki.net
http://common-lisp.net
http://ww.telent.net/cclan/
Also, on the subject of "blessing" individual libraries: languages with
benevolent dictators can do this, but we really can't. Small cliches of
lispers can, but thats the extent of it.
This can be a good thing: hopefully domains see small explosions of
diversity, followed by periods of contraction as authors of various
libraries on the same domain copy features from each other... then,
finally a reasonable de-facto standard can emerge.
On some domains this may never happen, but I'm not personally convinced
that eg. html-generation should have a standard. It may be better served
by several libraries, tailored for different circumstances.
This glacial process will no doubt frustrate some people, but I for one
think it's good on the long run. By the way of analogy, consider Red Hat
and Debian. ;)
While standing on the soap-box, I would like to point out the importance
of licensing here.
*sound of 10 000 newsreaders killfiling the thread*
For libraries aspiring to de-facto-standardhood GPL and LGPL are not good
choices. MIT, BSD-sans-advertising, and public domain seem to me to be the
most viable choices.
[ Provided that you are more interested in propagating Lisp in specific,
then free software in general. Individual priorities will differ,
naturally. ]
Cheers,
-- Nikodemus
Nikodemus Siivola wrote:
> While standing on the soap-box, I would like to point out the importance
> of licensing here.
>
> *sound of 10 000 newsreaders killfiling the thread*
>
> For libraries aspiring to de-facto-standardhood GPL and LGPL are not good
> choices. MIT, BSD-sans-advertising, and public domain seem to me to be the
> most viable choices.
Absolutely! When I first heard about the GPL when installing Linux, I
really liked it and was fascinated by it. The idea of a grass-roots
software community freely sharing code was very appealing.
But as I learned more about the GPL the infatuation ended.
Unfortunately, the GPL is a good excuse for Microsoft-bashing, so soon
you get loads of ignorant script-kiddies going "Open Source Open
Source Open Source!" without having the slightest idea what they mean.
And thus the virus spreads.
For Lisp in particular the GPL is not so suitable. The GPL and such
are based on some rigid distinction between a derived work (that uses
the source code of its original) and a separate (say, linked) work.
Such a distinction is less marked with Lisp. Does a Lisp macro that
expands into GPL-licensed code count as a derived work, or as a
separate work? Does a program written in a custom language that is
interpreted by a GPL-Lisp code count as a derived work or a separate
work? etc. Lisp is much too fluid to say.
The problem is that Law is not Mathematics, and that the above
distinction is ultimately based on the interpretaion of a judge, that
is to say it not known when you start writing your code. And say I'm
creating a program containing both GPL and non-GPL Lisp code. I don't
want to invest time, effort and money, only to find out later have the
GPL Jackals will sue me. Living in the constant uncertainty that my
interpretation of the GPL differs from RMS's is not my idea of
'protecting' the user's 'freedom'. (RMS's usage of these words is as
much doublethink as the terminology of commercial licences :-))
I urge all CL library writers to distribute their code under the
Bugger-Off Licence (http://www.geocities.com/SoHo/Cafe/5947/bugroff.html),
the One True Free Licence.
Sebastian
"Freedom is the freedom to say (= (+ 2 2) 4). If that is granted, all
else follows."
········@yahoo.com (Sebastian Stern) writes:
> I urge all CL library writers to distribute their code under the
> Bugger-Off Licence (http://www.geocities.com/SoHo/Cafe/5947/bugroff.html),
> the One True Free Licence.
The "No problem Bugroff" license is as follows...
The answer to any and every question relating to the copyright,
patents, legal issues of Bugroff licensed software is....
Sure, No problem. Don't worry, be happy. Now bugger off.
"I'd like to take your code, change it and misrepresent it as having been
written entirely by me. Also I want you to indemnify me against
any claim my users may make against me that relates to it."
Pretending the lawyers don't exist won't make them go away, you know.
-dan
--
http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro
Daniel Barlow <···@telent.net> writes:
> ········@yahoo.com (Sebastian Stern) writes:
>
> > I urge all CL library writers to distribute their code under the
> > Bugger-Off Licence (http://www.geocities.com/SoHo/Cafe/5947/bugroff.html),
> > the One True Free Licence.
No, please don't!
> Pretending the lawyers don't exist won't make them go away, you know.
And the "Bugg R Off" license probably has the opposite of the intended
effect. I wanted to use Fare's pattern-matcher, for example, but with
a non-license like "Bug R Off", I couldn't (this was for work, mind
you). Guessing that he released it to allow people to use it, I asked
him to let me have it under a modern BSD license. (And he did, and
you can get if from me under said license, if you want).
A modern BSD license (or an X11 license) grants someone the rights to
to pretty much whatever. Just use them, please. Otherwise, you're
not *really* making it available, you're just teasing.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
"Thomas F. Burdick" wrote:
> And the "Bugg R Off" license probably has the opposite of the intended
> effect. I wanted to use Fare's pattern-matcher, for example, but with
> a non-license like "Bug R Off", I couldn't.
Why not?
"Sebastian Stern" <··············@wanadoo.nl> writes:
> "Thomas F. Burdick" wrote:
> > And the "Bugg R Off" license probably has the opposite of the intended
> > effect. I wanted to use Fare's pattern-matcher, for example, but with
> > a non-license like "Bug R Off", I couldn't.
>
> Why not?
You elided the explanation: "(this was for work, mind you)"
I understand the BSD license. I don't understand the legal
implications of "Bugg R Off", and I doubt its implications are clear.
Just tell me I'm granted unlimited, nonexclusive rights to use the
software; but *say* that. Otherwise, I can't be sure that my clients
can use the software, and it would be massively irresponsible of me to
use it in work I do for them.
"Daniel Barlow" <···@telent.net> writes:
> Pretending the lawyers don't exist won't make them go away, you know.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
"Thomas F. Burdick" wrote:
> "Sebastian Stern" writes:
> > "Thomas F. Burdick" wrote:
> > > And the "Bugg R Off" license probably has the opposite of the intended
> > > effect. I wanted to use Fare's pattern-matcher, for example, but with
> > > a non-license like "Bug R Off", I couldn't.
> >
> > Why not?
>
> You elided the explanation: "(this was for work, mind you)"
>
> I understand the BSD license. I don't understand the legal
> implications of "Bugg R Off", and I doubt its implications are clear.
> Just tell me I'm granted unlimited, nonexclusive rights to use the
> software; but *say* that. Otherwise, I can't be sure that my clients
> can use the software, and it would be massively irresponsible of me to
> use it in work I do for them.
If it is your only concern is that the BOL is stated in too vague a language
for some people, than I agree with you. That is why I wrote in another post:
"Perhaps this licence should be stated in a more formal language that leaves
no room open for doubt, though that would not be as much fun to read. :-)"
However the intent of the BOL is clear, i.e., everyone is granted all
personal rights, as long as they do not impinge on other people's personal
rights.
There is nothing particularly special about the BOL itself. I would be quite
happy with a licence that is equivalent to the BOL, but is stated in an
clear verbose explicit unambiguous language that lawyers can understand and
agree upon. (The BSD licence is not completely equivalent, BTW.) Perhaps my
original remark was stated too harshly, so let me rephrase it: "I urge all
CL library writers to distribute their code under the BOL, or any (clear,
verbose, explicit, unambiguous, etc.) licence that is equivalent to the
BOL."
Sebastian
"Freedom is the freedom to say (= (+ 2 2) 4). If that is granted, all
else follows."
Daniel Barlow <···@telent.net> writes:
>
> Pretending the lawyers don't exist won't make them go away, you know.
>
It usually requires a more drastic solution. The traditional stake
through the heart is generally effective, but you may also need to
decapitate and burn the head.
"Daniel Barlow" wrote:
>
> The "No problem Bugroff" license is as follows...
>
> The answer to any and every question relating to the copyright,
> patents, legal issues of Bugroff licensed software is....
>
> Sure, No problem. Don't worry, be happy. Now bugger off.
>
> "I'd like to take your code, change it and misrepresent it as having been
> written entirely by me. Also I want you to indemnify me against
> any claim my users may make against me that relates to it."
Again, Law is not as clear-cut as Mathematics. To understand the licence you
must _interpret_ what the writer meant. He meant that all personal rights of
the user of the code are granted, and all duties disavowed. You are
therefore granted the right to take your code, and even say that it is
written by you, but you are not allowed to impose a duty on me, for that
would be denying my rights. The author of the BOL clearly states later: "No
matter what anyone else says or does, you [i.e. I] still have complete
freedom."
Perhaps this licence should be stated in a more formal language that leaves
no room open for doubt, though that would not be as much fun to read. :-)
········@yahoo.com (Sebastian Stern) writes:
> Nikodemus Siivola wrote:
> The problem is that Law is not Mathematics, and that the above
> distinction is ultimately based on the interpretaion of a judge,
> that is to say it not known when you start writing your code. And
> say I'm creating a program containing both GPL and non-GPL Lisp
> code. I don't want to invest time, effort and money, only to find
> out later have the GPL Jackals will sue me.
Two words: dual licensing.
If you want to make money off your software, a goal I am very
much in favor of, by the way, then get a non-GPL license for the
components you're using. If you want to contribute in exchange for
all the free software that you've no doubt benefited from, the GPL is
a great way to do so. It ensures that anyone who wants to profit
monetarily from your work will have to deal with you for an
alternative license.
The non-GPL licenses don't provide the same flexibility and
control.
Regards,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
···@spe.com | (C++, Java, ObjectStore, Oracle, CORBA, UML)
Patrick May <···@spe.com> wrote in message news:<··············@patrick.intamission.com>...
> ········@yahoo.com (Sebastian Stern) writes:
> > Nikodemus Siivola wrote:
> > The problem is that Law is not Mathematics, and that the above
> > distinction is ultimately based on the interpretaion of a judge,
> > that is to say it not known when you start writing your code. And
> > say I'm creating a program containing both GPL and non-GPL Lisp
> > code. I don't want to invest time, effort and money, only to find
> > out later have the GPL Jackals will sue me.
>
> Two words: dual licensing.
>
> If you want to make money off your software, a goal I am very
> much in favor of, by the way, then get a non-GPL license for the
> components you're using.
Ah yes, but then it isn't free anymore, now is it? :-)
> If you want to contribute in exchange for
> all the free software that you've no doubt benefited from, the GPL is
> a great way to do so.
No it isn't. GPL does not give you freedom. If you want freedom, real
freedom, use the Bugger-Off Licence.
> It ensures that anyone who wants to profit
> monetarily from your work will have to deal with you for an
> alternative license.
I don't _care_ if anyone makes a monetary profit of my work. If I
release some code under the BOL, and somone makes a million off it,
then so be it. At least I did not restrict their freedom. My point was
not that I can't make any money off the GPL, but that if I choose to
reuse GPL code, the GPL restricts my freedom.
>
> The non-GPL licenses don't provide the same flexibility and
> control.
I don't _want_ to _control_ anybody, and I don't want to be
controlled. That was my _whole point_. The GPL (and/or dual licencing)
deny you this freedom. To control someone is to deny them their
freedom. I don't mind what people do with any code I release, I don't
want to use the law to tell them what to do, and I don't want the law
to tell me what I can do with my derived code.
Sebastian
"Freedom is the freedom to say (= (+ 2 2) 4). If that is granted, all
else follows."
········@yahoo.com (Sebastian Stern) writes:
> > If you want to make money off your software, a goal I am very
> > much in favor of, by the way, then get a non-GPL license for the
> > components you're using.
>
> Ah yes, but then it isn't free anymore, now is it? :-)
That depends on the deal you negotiate with the owner of the
software. I find this objection to be something of a non-sequitur --
why would anyone expect to be able to use the product of someone
else's labor without compensation?
As an aside, I'm not going to attempt to defend the FSF
definition of "freedom". I suspect that RMS and I don't see eye to
eye.
> > If you want to contribute in exchange for all the free software
> > that you've no doubt benefited from, the GPL is a great way to do
> > so.
>
> No it isn't. GPL does not give you freedom. If you want freedom,
> real freedom, use the Bugger-Off Licence.
I didn't use the word "freedom". I said that the GPL is a great
way to repay in kind for the benefits you've gotten from free software
(okay, I did use the word "free", but not in the same context). I
stand by that contention.
> > It ensures that anyone who wants to profit monetarily from your
> > work will have to deal with you for an alternative license.
>
> I don't _care_ if anyone makes a monetary profit of my work. If I
> release some code under the BOL, and somone makes a million off it,
> then so be it.
That's quite generous of you. The BOL seems to fit your needs.
> At least I did not restrict their freedom. My point was not that I
> can't make any money off the GPL, but that if I choose to reuse GPL
> code, the GPL restricts my freedom.
For any reasonable defintion of "freedom", this is simply not
so. You do not have a right by default to use anyone's code. Some
developers are willing to make their code available for no cost, but
choose to place conditions on its use. The GPL is one such set of
conditions. Your freedom is in no way restricted by this because you
never had the right to use the code, with or without restrictions,
until the developer choose to make it available.
> > The non-GPL licenses don't provide the same flexibility and
> > control.
>
> I don't _want_ to _control_ anybody, and I don't want to be
> controlled. That was my _whole point_. The GPL (and/or dual
> licencing) deny you this freedom. To control someone is to deny them
> their freedom. I don't mind what people do with any code I release,
> I don't want to use the law to tell them what to do, and I don't
> want the law to tell me what I can do with my derived code.
The law isn't saying anything, the developer is. Would you deny
the developer the right to control his or her code?
Regards,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
···@spe.com | (C++, Java, ObjectStore, Oracle, CORBA, UML)
(This is getting really off-topic, BTW)
"Patrick May" wrote:
> ········@yahoo.com (Sebastian Stern) writes:
> > Ah yes, but then it isn't free anymore, now is it? :-)
>
> That depends on the deal you negotiate with the owner of the
> software.
Precisely: you have to negotiate. And with the BOL you do not have to
negotiate, you get freedom no matter what.
> I find this objection to be something of a non-sequitur --
> why would anyone expect to be able to use the product of someone
> else's labor without compensation?
I did not say this. I meant 'free' as in 'freedom', not as in
'compensation'. The GPL doesn't guarantee compensation either.
> > At least I did not restrict their freedom. My point was not that I
> > can't make any money off the GPL, but that if I choose to reuse GPL
> > code, the GPL restricts my freedom.
>
> For any reasonable defintion of "freedom", this is simply not
> so. You do not have a right by default to use anyone's code. Some
> developers are willing to make their code available for no cost, but
> choose to place conditions on its use. The GPL is one such set of
> conditions. Your freedom is in no way restricted by this because you
> never had the right to use the code, with or without restrictions,
> until the developer choose to make it available.
I agree with you, that you do not have a right by default to use anyone's
code. That is why I said "if I _choose_ to reuse GPL code". In which case I
must abide by their conditions, and these deny certain of my rights.
> > > The non-GPL licenses don't provide the same flexibility and
> > > control.
> >
> > I don't _want_ to _control_ anybody, and I don't want to be
> > controlled. That was my _whole point_. The GPL (and/or dual
> > licencing) deny you this freedom. To control someone is to deny them
> > their freedom. I don't mind what people do with any code I release,
> > I don't want to use the law to tell them what to do, and I don't
> > want the law to tell me what I can do with my derived code.
>
> The law isn't saying anything, the developer is.
Agreed, but the developer is using the law to enforce _his_ wishes, not
those of the user of the code.
> Would you deny
> the developer the right to control his or her code?
No, I didn't say this. If a developer chooses to release code under a
restrictive licence then this must of of course be respected. I just
recommend that people use the BOL. But, to each his own.
Sebastian
"Freedom is the freedom to say (= (+ 2 2) 4). If that is granted, all
else follows."
"Sebastian Stern" <··············@wanadoo.nl> writes:
> I agree with you, that you do not have a right by default to use
> anyone's code. That is why I said "if I _choose_ to reuse GPL
> code". In which case I must abide by their conditions, and these
> deny certain of my rights.
Which of your rights? You just agreed that you have no right by
default to use code developed by someone else. It therefore follows
that your rights cannot be infringed by that person allowing you to
use it only under certain conditions. You actually have more options
than you do by default, due to the generosity of the developer.
> > Would you deny the developer the right to control his or her code?
>
> No, I didn't say this. If a developer chooses to release code under
> a restrictive licence then this must of of course be respected. I
> just recommend that people use the BOL. But, to each his own.
But that's such a boring, reasonable position that we're unlikely
to get into a flamewar. Is there a reason you don't use the BSD
license instead?
Out of curiosity, why would you recommend that developers release
their code unconditionally? I'd be delighted to know that another
developer found something I produced to be interesting enough to use
in another Open Source project. I'd be most annoyed if some large
purveyor of desktop operating systems, for example, took my code and
incorporated it into their product without explicit permission and
compensation.
Regards,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
···@spe.com | (C++, Java, ObjectStore, Oracle, CORBA, UML)
[Off Topic]
"Patrick May" wrote:
> "Sebastian Stern" writes:
> > I agree with you, that you do not have a right by default to use
> > anyone's code. That is why I said "if I _choose_ to reuse GPL
> > code". In which case I must abide by their conditions, and these
> > deny certain of my rights.
>
> Which of your rights? You just agreed that you have no right by
> default to use code developed by someone else.
Sorry if I have not made myself clear. Under the BOL you have the right to
do anything with the code (say, distribute modifications in any way you
like). If however I choose to reuse GPL code, I also choose to give up this
right.
> It therefore follows
> that your rights cannot be infringed by that person allowing you to
> use it only under certain conditions.
Indeed. 'Infringed' is not the right word. When I choose to reuse GPL code,
nobody infringes the above right, I choose to give it up voluntarily. But
I'd prefer not to.
> You actually have more options
> than you do by default, due to the generosity of the developer.
If by 'default' you mean 'closed licences', then, indeed, the GPL gives me
more options. But the BOL gives me even more options.
> > > Would you deny the developer the right to control his or her code?
> >
> > No, I didn't say this. If a developer chooses to release code under
> > a restrictive licence then this must of of course be respected. I
> > just recommend that people use the BOL. But, to each his own.
>
> But that's such a boring, reasonable position that we're unlikely
> to get into a flamewar.
...and what is the use of Usenet without a good flamewar, right? :-)
> Is there a reason you don't use the BSD
> license instead?
First of all, in my original post I was not arguing against the BSD licence,
but against the GPL. But to answer your question: the (revised) BSD licence
is For All Practical Purposes sufficiently similar to the BOL. However, The
BSD licence demands that you give credit to the original creator. RMS
explains this better than I do (http://www.gnu.org/philosophy/bsd.html).
This is an issue that I agree upon with RMS. (It actually quite ironic that
RMS is against the BSD licence, while at the same time ardently whining that
everyone should use the name GNU/Linux, instead of just Linux, so he can get
the credit.) The BOL does not force you to do give credit, it gives you the
freedom to do as you choose.
> Out of curiosity, why would you recommend that developers release
> their code unconditionally?
'Unconditionally' is probably the wrong word. The BOL gives you the right to
do anything with the code, _unless_ it interferes with other people's
rights. To avoid ambiguity, restating the philosophy of the BOL into a
document in more legal lingo, would probably be a good idea if you plan on
releasing something serious.
> I'd be delighted to know that another
> developer found something I produced to be interesting enough to use
> in another Open Source project.
I you want to inflate your ego by requiring in the licence to give credit to
the creator of the code, you should not worry. Most Open Source people will
give credit where credit is due, even if this is not required by the
licence. So you can usually get the same satisfaction by using the BOL.
> I'd be most annoyed if some large
> purveyor of desktop operating systems, for example, took my code and
> incorporated it into their product without explicit permission and
> compensation.
It is quite possible to incorporate GPL code into closed systems. Although
this is of course illegal, it is almost impossible to check, and who knows
whether some large purveyor of desktop operating systems' main product is
actually a front end for Emacs? :-)
The GPL does little more than the BOL to protect you in this respect, and it
certainly does not force people to compensate you monetarily. If you are
annoyed by this, your only choice is to use closed source. I can not force
you to use the BOL. Doing so would in fact undermine the BOL philosophy,
which is that I should not force you to do anything against your will. I can
only state my postition and hope that people will listen.
Sebastian
"Freedom is the freedom to say (= (+ 2 2) 4). If that is granted, all
else follows."
From: David Steuber
Subject: Re: Libraries (Was: Programming By The Seat Of Your Pants)
Date:
Message-ID: <m2ptgo6m7v.fsf@verizon.net>
Nikodemus Siivola <········@kallio.cs.hut.fi> writes:
> For libraries aspiring to de-facto-standardhood GPL and LGPL are not good
> choices. MIT, BSD-sans-advertising, and public domain seem to me to be the
> most viable choices.
Although I am a big fan of the GPL, I agree with this. There may be
specific exceptions (as can be found in the CLISP CVS archive).
However, I think it is a given that not everyone is going to want to
use the GPL as the license for their software.
Public domain seems to be the most flexible. Although I would hope
that credit is still given where due. SBCL credits CMUCL even though
there is clearly no legal requirement to do so.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
David Steuber <·············@verizon.net> writes:
> Nikodemus Siivola <········@kallio.cs.hut.fi> writes:
>
> > For libraries aspiring to de-facto-standardhood GPL and LGPL are not good
> > choices. MIT, BSD-sans-advertising, and public domain seem to me to be the
> > most viable choices.
>
> Although I am a big fan of the GPL, I agree with this. There may be
> specific exceptions (as can be found in the CLISP CVS archive).
> However, I think it is a given that not everyone is going to want to
> use the GPL as the license for their software.
I would like to underline that a common misconception is that GPL is
antagonist to business. Quite on the contrary, a corporation that
wants to free its code can do it without damaging its interests under
a GPL: it prevents its competition to include the code into
proprietary, closed, competiting software. On the other hand, while
licenses like BSD are convenient for public, pre-paid, works like is
done in universities, it would be foolish for any corporation to
publish its code under such a license. Of course, the same apply to
individuals
--
__Pascal_Bourguignon__
http://www.informatimago.com/
From: David Steuber
Subject: Re: Libraries (Was: Programming By The Seat Of Your Pants)
Date:
Message-ID: <m265if3bjv.fsf@verizon.net>
Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> David Steuber <·············@verizon.net> writes:
>
> > Nikodemus Siivola <········@kallio.cs.hut.fi> writes:
> >
> > > For libraries aspiring to de-facto-standardhood GPL and LGPL are not good
> > > choices. MIT, BSD-sans-advertising, and public domain seem to me to be the
> > > most viable choices.
> >
> > Although I am a big fan of the GPL, I agree with this. There may be
> > specific exceptions (as can be found in the CLISP CVS archive).
> > However, I think it is a given that not everyone is going to want to
> > use the GPL as the license for their software.
>
> I would like to underline that a common misconception is that GPL is
> antagonist to business. Quite on the contrary, a corporation that
> wants to free its code can do it without damaging its interests under
> a GPL: it prevents its competition to include the code into
> proprietary, closed, competiting software. On the other hand, while
> licenses like BSD are convenient for public, pre-paid, works like is
> done in universities, it would be foolish for any corporation to
> publish its code under such a license. Of course, the same apply to
> individuals
I don't want to start another license debate. The example I was
thinking of was Apple making the Objective-C frontend GPL so that it
could be used with the GCC compiler. Side effects included having
Objective-C available to a wider audience, thus making the number of
people who would be interested in programming to Cocoa larger.
I think it worked out better for Apple that way than if they had a
proprietary front end for GCC.
Now that I think about it, a reference implementation for a proposed
standard package for Lisp could be GPL. Anyone wanting a non-GPL
license to use it can just write there own version. A standard isn't
much good if there aren't at least two implementations anyway.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
Hi David Steuber,
>> For libraries aspiring to de-facto-standardhood GPL and LGPL are not good
>> choices. MIT, BSD-sans-advertising, and public domain seem to me to be the
>> most viable choices.
>
> Although I am a big fan of the GPL, I agree with this. There may be
> specific exceptions (as can be found in the CLISP CVS archive).
Be aware that the copyright holders may have no legal right to grant
those specific exceptions (or notes as they are called in the licence):
<http://cvs.sourceforge.net/viewcvs.py/*checkout*/clisp/clisp/COPYRIGHT?content-type=text%2Fplain&rev=1.11>
The issue is that one cannot grant an exception to the terms of the GPL if
the licensed code is linked to any other GPLed code that is not licensed
with the same exceptions. So to maintain the exceptions it's usually
impractical to link to any other GPLed code that you don't own.
Consider the fact that CLISP links to Readline, which is a GPLed library,
and that the CLISP developers have no power to relicense it under a
GPL+exception licence. If CLISP incorporates and distributes non-exception
licensed GPL software then CLISP is licensed under the GPL without
exception.
The historical record of why CLISP became GPLed appears to support the
conclusion that CLISP could only incorporate the Readline library if
it was licensed under the GPL without exception:
<http://cvs.sourceforge.net/viewcvs.py/*checkout*/clisp/clisp/doc/Why-CLISP-is-under-GPL?content-type=text%2Fplain&rev=1.1>
Here's a more recent statement of the same issue:
<http://mail.gnu.org/archive/html/gcl-devel/2003-07/msg00068.html>
"Readline is released under the GPL, and only the GPL."
As an aside you might like to read about my attempts to get some
clarification of the CLISP exceptions. The result was chilling:
<http://groups.google.com/groups?selm=pan.2003.07.27.01.13.01.954438%40consulting.net.nz>
Regards,
Adam
From: David Steuber
Subject: Re: Libraries (Was: Programming By The Seat Of Your Pants)
Date:
Message-ID: <m2ptgdsv62.fsf@verizon.net>
Adam Warner <······@consulting.net.nz> writes:
> Hi David Steuber,
>
> >> For libraries aspiring to de-facto-standardhood GPL and LGPL are not good
> >> choices. MIT, BSD-sans-advertising, and public domain seem to me to be the
> >> most viable choices.
> >
> > Although I am a big fan of the GPL, I agree with this. There may be
> > specific exceptions (as can be found in the CLISP CVS archive).
>
> Be aware that the copyright holders may have no legal right to grant
> those specific exceptions (or notes as they are called in the licence):
> <http://cvs.sourceforge.net/viewcvs.py/*checkout*/clisp/clisp/COPYRIGHT?content-type=text%2Fplain&rev=1.11>
>
> The issue is that one cannot grant an exception to the terms of the GPL if
> the licensed code is linked to any other GPLed code that is not licensed
> with the same exceptions. So to maintain the exceptions it's usually
> impractical to link to any other GPLed code that you don't own.
>
> Consider the fact that CLISP links to Readline, which is a GPLed library,
> and that the CLISP developers have no power to relicense it under a
> GPL+exception licence. If CLISP incorporates and distributes non-exception
> licensed GPL software then CLISP is licensed under the GPL without
> exception.
I'm not sure exactly what you are trying to say. CLISP is GPL. End
of story. If you do not want your Lisp project to also be GPL, then
don't use CLISP. Or at least don't compile your distributed work
with CLISP. Use a different Lisp for that.
As I'm sure you've gathered, there is no way to make CLISP not GPL
unless you want to go back to the pre-readline code base and fork
from there. But that won't be CLISP.
The GPL is very clear in the license. Anything that uses GPL code as
CLISP does is also GPL. If you want a readline library without being
GPL, you need to look at the BSD readline library that is not part of
GNU.
I don't think a license debate is really on topic per se. However,
anyone who wishes to avoid the viral like nature of GPL should not
use CLISP as their Lisp system. There are other free alternatives.
CMUCL and SBCL are examples.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
Hi David Steuber,
> Adam Warner <······@consulting.net.nz> writes:
>
>> Hi David Steuber,
>>
>> >> For libraries aspiring to de-facto-standardhood GPL and LGPL are not good
>> >> choices. MIT, BSD-sans-advertising, and public domain seem to me to be the
>> >> most viable choices.
>> >
>> > Although I am a big fan of the GPL, I agree with this. There may be
>> > specific exceptions (as can be found in the CLISP CVS archive).
>>
>> Be aware that the copyright holders may have no legal right to grant
>> those specific exceptions (or notes as they are called in the licence):
>> <http://cvs.sourceforge.net/viewcvs.py/*checkout*/clisp/clisp/COPYRIGHT?content-type=text%2Fplain&rev=1.11>
>>
>> The issue is that one cannot grant an exception to the terms of the GPL if
>> the licensed code is linked to any other GPLed code that is not licensed
>> with the same exceptions. So to maintain the exceptions it's usually
>> impractical to link to any other GPLed code that you don't own.
>>
>> Consider the fact that CLISP links to Readline, which is a GPLed library,
>> and that the CLISP developers have no power to relicense it under a
>> GPL+exception licence. If CLISP incorporates and distributes non-exception
>> licensed GPL software then CLISP is licensed under the GPL without
>> exception.
>
> I'm not sure exactly what you are trying to say. CLISP is GPL. End
> of story.
Then you're close to understanding the point. "There may be specific
exceptions (as can be found in the CLISP CVS archive)." How can there be
specific exceptions when CLISP has been linked to non-exception licensed
GPL code?
> If you do not want your Lisp project to also be GPL, then don't use
> CLISP.
Do you realise how unusual this statement is? How popular do you think the
GNU C compiler would be if compiled programs became GPLed?
> Or at least don't compile your distributed work with CLISP. Use a
> different Lisp for that.
The claims of derived works extend to more than compiled code. It is
claimed that a program that would not run as well in any other Common Lisp
implementation is a derived work and must be licensed under the GPL.
Code incorporating (ext:cd "/home/adam/") or (ext:getenv) is a derived
work since this code doesn't work in any other Common Lisp implementation.
I know this sounds insane but if you follow the original links you will
discover this is what is being claimed.
> As I'm sure you've gathered, there is no way to make CLISP not GPL
> unless you want to go back to the pre-readline code base and fork from
> there. But that won't be CLISP.
>
> The GPL is very clear in the license. Anything that uses GPL code as
> CLISP does is also GPL.
I don't want to use the GPL code. I would potentially like to distribute
programs with GNU CLISP-specific functionality running on top of
CLISP without them automatically having to be licensed under the GPL.
Distributed C programs that implement GNU C specific extensions don't
automatically have to be licensed under the GPL.
> If you want a readline library without being GPL, you need to look at
> the BSD readline library that is not part of GNU.
>
> I don't think a license debate is really on topic per se. However,
> anyone who wishes to avoid the viral like nature of GPL should not use
> CLISP as their Lisp system. There are other free alternatives. CMUCL
> and SBCL are examples.
Regards,
Adam
From: David Steuber
Subject: Re: Libraries (Was: Programming By The Seat Of Your Pants)
Date:
Message-ID: <m21xstrvx7.fsf@verizon.net>
Adam Warner <······@consulting.net.nz> writes:
> Hi David Steuber,
>
> > Adam Warner <······@consulting.net.nz> writes:
> >
> >> Hi David Steuber,
> >>
> >> >> For libraries aspiring to de-facto-standardhood GPL and LGPL are not good
> >> >> choices. MIT, BSD-sans-advertising, and public domain seem to me to be the
> >> >> most viable choices.
> >> >
> >> > Although I am a big fan of the GPL, I agree with this. There may be
> >> > specific exceptions (as can be found in the CLISP CVS archive).
> >>
> >> Be aware that the copyright holders may have no legal right to grant
> >> those specific exceptions (or notes as they are called in the licence):
> >> <http://cvs.sourceforge.net/viewcvs.py/*checkout*/clisp/clisp/COPYRIGHT?content-type=text%2Fplain&rev=1.11>
> >>
> >> The issue is that one cannot grant an exception to the terms of the GPL if
> >> the licensed code is linked to any other GPLed code that is not licensed
> >> with the same exceptions. So to maintain the exceptions it's usually
> >> impractical to link to any other GPLed code that you don't own.
> >>
> >> Consider the fact that CLISP links to Readline, which is a GPLed library,
> >> and that the CLISP developers have no power to relicense it under a
> >> GPL+exception licence. If CLISP incorporates and distributes non-exception
> >> licensed GPL software then CLISP is licensed under the GPL without
> >> exception.
> >
> > I'm not sure exactly what you are trying to say. CLISP is GPL. End
> > of story.
>
> Then you're close to understanding the point. "There may be specific
> exceptions (as can be found in the CLISP CVS archive)." How can there be
> specific exceptions when CLISP has been linked to non-exception licensed
> GPL code?
Ok, I think I see where the disconnect is. The exceptions I referred
to were not exceptions to the GPL license. I was thinking of the
Objectiv-C front-end to the GCC compiler. Steve Jobs wanted to make
that part proprietary. However, linking to GCC meant he couldn't do
that because GCC is GPL. Jobs whent ahead and made the Objective-C
front-end GPL.
This allowed Jobs to use GCC at no cost to him and also made it
impossible for anyoen to "steal" the Objective-C front-end.
It also did not prevent Jobs from using GCC to create a proprietary
library/runtime for OS X. There is OpenStep, but that is NOT NeXT
Step.
> > If you do not want your Lisp project to also be GPL, then don't use
> > CLISP.
>
> Do you realise how unusual this statement is? How popular do you think the
> GNU C compiler would be if compiled programs became GPLed?
The reason for this is that the GCC compiler does not put GCC code
into your object files. Lisp is a whole other beast in that
respect. A Lisp image contains the Lisp runtime. If libc were GPL
instead of LGPL, almost no one would use it. It would have been
still born. Linking to a GPL libc would make your C program GPL.
Linking to an LGPL libc does not.
CLISP contains readline so is GPL. Since CLISP is GPL, then the
CLISP runtime is also GPL unless it is an entirely seperate entity in
the CLISP system. You can link other licensed code into GPL code in
many cases.
> > Or at least don't compile your distributed work with CLISP. Use a
> > different Lisp for that.
>
> The claims of derived works extend to more than compiled code. It is
> claimed that a program that would not run as well in any other Common Lisp
> implementation is a derived work and must be licensed under the GPL.
> Code incorporating (ext:cd "/home/adam/") or (ext:getenv) is a derived
> work since this code doesn't work in any other Common Lisp implementation.
> I know this sounds insane but if you follow the original links you will
> discover this is what is being claimed.
If you have Lisp code that is not GPL and will compile and work in
any ANSI compliant Lisp, then I don't see how a claim that the Lisp
code is GPL will hold up. What you include into a GPL code base will
have to be GPL, but what you don't doesn't.
> > As I'm sure you've gathered, there is no way to make CLISP not GPL
> > unless you want to go back to the pre-readline code base and fork from
> > there. But that won't be CLISP.
> >
> > The GPL is very clear in the license. Anything that uses GPL code as
> > CLISP does is also GPL.
>
> I don't want to use the GPL code. I would potentially like to distribute
> programs with GNU CLISP-specific functionality running on top of
> CLISP without them automatically having to be licensed under the GPL.
> Distributed C programs that implement GNU C specific extensions don't
> automatically have to be licensed under the GPL.
Extensions no. Libraries yes. If you want to use CLISP-specific
functionality, then you have to do it in a way that does not infringe
the GPL.
I think the problem you have here is that the CLISP runtime is GPL.
You don't need to use that. Since (ext:whatever) is GPL, you can
only use it if you wish to also be GPL. That is kinda that.
You can always create your own independent implimentation of that
functionality. It really depends on what is more work for you and
what your end goal is.
This is where the GPL gets messy. When you use a feature, is it a
language extension that doesn't affect your ability to use it, or is
it a library which does?
I don't have any simple answer. You may need to have a lawyer
familiar with IP law look at what you are using, its license, and
what you will be producing. I could be quite mistaken in my
conclusions. For example, you _might_ be able to release a FASL to
be loaded into a CLISP runtime. That FASL may not be required to be
GPL. I don't know. Then again, it is using a GPL runtime. That is
linking. Bang. You have been got again. Your way out would be if
the FASL loaded into another Lisp and worked. I think that would
free you of the GPL terms.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
David Steuber <·············@verizon.net> writes:
> The reason for this is that the GCC compiler does not put GCC code
> into your object files. Lisp is a whole other beast in that
> respect. A Lisp image contains the Lisp runtime. If libc were GPL
> instead of LGPL, almost no one would use it. It would have been
> still born. Linking to a GPL libc would make your C program GPL.
> Linking to an LGPL libc does not.
>
> CLISP contains readline so is GPL. Since CLISP is GPL, then the
> CLISP runtime is also GPL unless it is an entirely seperate entity in
> the CLISP system. You can link other licensed code into GPL code in
> many cases.
All this is very true, but there's no problem. It only implies that
you must package your deliverables in a certain way.
In the case of clisp, you must give your customers:
- a clisp binary along with its sources per GPL,
- your .fas files,
- a script that launch clisp and load and run your .fas files on
the customer's computer; OR, an _installation_ script that will
build a lisp image from the clisp and your .fas files on the
customer's computer.
This way, you can sell them your .fas with any license you like. And
it gives your customers the freedom to correct any bug found in clisp
or even to implement an alternative common-lisp able to load your .fas
files.
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Hi Pascal Bourguignon,
> David Steuber <·············@verizon.net> writes:
>> The reason for this is that the GCC compiler does not put GCC code
>> into your object files. Lisp is a whole other beast in that
>> respect. A Lisp image contains the Lisp runtime. If libc were GPL
>> instead of LGPL, almost no one would use it. It would have been
>> still born. Linking to a GPL libc would make your C program GPL.
>> Linking to an LGPL libc does not.
>>
>> CLISP contains readline so is GPL. Since CLISP is GPL, then the
>> CLISP runtime is also GPL unless it is an entirely seperate entity in
>> the CLISP system. You can link other licensed code into GPL code in
>> many cases.
>
> All this is very true, but there's no problem. It only implies that
> you must package your deliverables in a certain way.
>
> In the case of clisp, you must give your customers:
>
> - a clisp binary along with its sources per GPL,
>
> - your .fas files,
>
> - a script that launch clisp and load and run your .fas files on
> the customer's computer; OR, an _installation_ script that will
> build a lisp image from the clisp and your .fas files on the
> customer's computer.
>
> This way, you can sell them your .fas with any license you like. And
> it gives your customers the freedom to correct any bug found in clisp
> or even to implement an alternative common-lisp able to load your .fas
> files.
1) Do the authors make this claim upon legal grounds?
The authors cannot grant exceptions to the GPL and then link their code
to non-exception licensed GPL code. Hopefully people will at least
understand this as a moot point.
2) Since you emphasise distribution of .fas files rather than source code
you must be concerned about the recipient not being able to easily decode
them. .fas files contain an extensive amount of information about the
original source. Extensive.
secret.lisp:
(defparameter *secret-list* '(1 1.2 3/4 "easy to decode"))
(loop for secret-variable in *secret-list* collect secret-variable)
secret.fas:
(system::version '(20030222.))
#0Y utf-8
#Y(#:|(defparameter *secret-list* '(1 1.2 3/4 ...))-1|
#20Y(00 00 00 00 00 00 00 00 00 01 DA 31 5A DB DC 31 52 C6 19 01)
(common-lisp::t . common-lisp::t)
(common-lisp::special common-lisp-user::*secret-list*)
common-lisp-user::*secret-list* (1. 1.2d0 #10r3/4 "easy to decode"))
#Y(#:|(loop for secret-variable ...)-2|
#33Y(00 00 00 00 00 00 00 00 00 01 6B 00 01 02 1B 08 87 02 01 14 84 00 83 02
AE 8D 92 74 AC 31 A4 19 04)
(common-lisp::t . common-lisp::t) common-lisp-user::*secret-list*)
We can see the whole dynamic variable assignment is just sitting in the
.fas file. But let's disassemble it anyway:
(disassemble #Y(#:|(defparameter *secret-list* '(1 1.2 3/4 ...))-1|
#20Y(00 00 00 00 00 00 00 00 00 01 DA 31 5A DB DC 31 52 C6 19 01)
(common-lisp::t . common-lisp::t)
(common-lisp::special common-lisp-user::*secret-list*)
common-lisp-user::*secret-list* (1. 1.2d0 #10r3/4 "easy to decode")))
Disassembly of function #:|(defparameter *secret-list* '(1 1.2 3/4 ...))-1|
(CONST 0) = (SPECIAL *SECRET-LIST*)
(CONST 1) = *SECRET-LIST*
(CONST 2) = (1 1.2d0 3/4 "easy to decode")
0 required arguments
0 optional arguments
No rest parameter
No keyword parameters
7 byte-code instructions:
0 (CONST&PUSH 0) ; (SPECIAL *SECRET-LIST*)
1 (CALLS1 90) ; PROCLAIM
3 (CONST&PUSH 1) ; *SECRET-LIST*
4 (CONST&PUSH 2) ; (1 1.2d0 3/4 "easy to decode")
5 (CALLS1 82) ; SYSTEM::SET-SYMBOL-VALUE
7 (CONST 1) ; *SECRET-LIST*
8 (SKIP&RET 1)
That's every single piece of high level information the first line of
source contains.
The disassembly of the next function doesn't tell us as much. We do know
it's a loop using the lexical variable named secret-variable that loops
over the special variable *SECRET-LIST*:
Disassembly of function #:|(loop for secret-variable ...)-2|
(CONST 0) = *SECRET-LIST*
0 required arguments
0 optional arguments
No rest parameter
No keyword parameters
reads special variable: (*SECRET-LIST*)
14 byte-code instructions:
0 (GETVALUE&PUSH 0) ; *SECRET-LIST*
2 (PUSH-NIL 2)
4 (JMP L14)
6 L6
6 (LOAD&CAR&STORE 2 1)
9 (PUSH)
10 (LOAD&CONS&STORE 0)
12 (LOAD&CDR&STORE 2)
14 L14
14 (LOAD&PUSH 2)
15 (CALLS1&JMPIFNOT 146 L6) ; ENDP
18 (LOAD&PUSH 0)
19 (CALLS1 164) ; SYSTEM::LIST-NREVERSE
21 (SKIP&RET 4)
Regards,
Adam
From: David Steuber
Subject: Re: Libraries (Was: Programming By The Seat Of Your Pants)
Date:
Message-ID: <m23cd8rdqg.fsf@verizon.net>
Adam Warner <······@consulting.net.nz> writes:
> 1) Do the authors make this claim upon legal grounds?
>
> The authors cannot grant exceptions to the GPL and then link their code
> to non-exception licensed GPL code. Hopefully people will at least
> understand this as a moot point.
I don't see how what Pascal Bourguignon suggests would work in any
case. This is exactly what Steve Jobs wanted to do with the
Objective-C compiler. He could not do so because of the linking
issue. Jobs decided that using GCC was more important than keeping
the Objectiv-C compiler proprietary. He was still able to maintain a
proprietary library though. That library is currently in OS X.
The only way around the GPL requirement that I can see is to not use
GPL code in the first place. The GPL was designed to force users of
the GPL code to also release their code under GPL.
If your Lisp code will compile and run properly (even if it is not as
well) under another Lisp system, then you can release your code with
that Lisp system provided it has a license that is agreeable to you.
There are commercial Lisp systems that will allow you to do what you
want. It may be that they also make it easier for you to distribute
works created with them. Commercial systems tend to have more
polished methods for doing such things. I doubt CLISP is so powerful
that it has a feature set that can not be duplicated anywhere else.
Then again, who knows?
If you feel your project is married to CLISP, you may have to bite
the bullet and sell it under GPL. You can sell it. You just have to
provide all the source and allow others to distribute it under the
GPL. No one will make more money than you doing so.
The issue gets intersting when you consider the Linux kernel. The
Kernel is GPL but it is OK to release proprietary software for it.
The reason this is so is that Linux Torvolds added an ammendment to
the GPL he uses that states that he does not consider system calls to
be linking for licensing purposes.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
Hi David Steuber,
> Adam Warner <······@consulting.net.nz> writes:
>
>> 1) Do the authors make this claim upon legal grounds?
>>
>> The authors cannot grant exceptions to the GPL and then link their code
>> to non-exception licensed GPL code. Hopefully people will at least
>> understand this as a moot point.
>
> I don't see how what Pascal Bourguignon suggests would work in any case.
He's describing the terms of the CLISP COPYRIGHT file:
<http://cvs.sourceforge.net/viewcvs.py/*checkout*/clisp/clisp/COPYRIGHT?content-type=text%2Fplain&rev=1.11>
There used to be a document on the CLISP website giving an exact
description of Pascal's explanation.
(snip)
> The issue gets interesting when you consider the Linux kernel. The
> Kernel is GPL but it is OK to release proprietary software for it. The
> reason this is so is that Linus Torvalds added an amendment to the GPL
> he uses that states that he does not consider system calls to be linking
> for licensing purposes.
The issue is more complicated than your comment implies. Prominent
developers have contributed non-exception licensed GPL code to the Linux
kernel. For example Alan Cox writes:
<http://lwn.net/2001/0614/a/ac-modules.php3>
"Linus opinion on this is irrelevant. Neither I nor the FSF nor many
others have released code under anything but the vanilla GPL. By merging
such code Linus lost his ability to vary the license."
Regards,
Adam
David Steuber writes:
>> The issue gets interesting when you consider the Linux kernel. The
>> Kernel is GPL but it is OK to release proprietary software for it. The
>> reason this is so is that Linus Torvalds added an amendment to the GPL
>> he uses that states that he does not consider system calls to be linking
>> for licensing purposes.
Adam Warner <······@consulting.net.nz> writes:
> The issue is more complicated than your comment implies. Prominent
> developers have contributed non-exception licensed GPL code to the Linux
> kernel. For example Alan Cox writes:
> <http://lwn.net/2001/0614/a/ac-modules.php3>
>
> "Linus opinion on this is irrelevant. Neither I nor the FSF nor many
> others have released code under anything but the vanilla GPL. By merging
> such code Linus lost his ability to vary the license."
Note that David's talking about proprietary userland applications
(which interface to Linux by making system calls) whereas Adam is
talking about kernel modules, which are linked into the same address
space as the kernel and may freely call any kernel function. Not the
same thing at all.
-dan
--
http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro
David Steuber <·············@verizon.net> writes:
> Adam Warner <······@consulting.net.nz> writes:
>
> > 1) Do the authors make this claim upon legal grounds?
> >
> > The authors cannot grant exceptions to the GPL and then link their code
> > to non-exception licensed GPL code. Hopefully people will at least
> > understand this as a moot point.
>
> I don't see how what Pascal Bourguignon suggests would work in any
> case. This is exactly what Steve Jobs wanted to do with the
> Objective-C compiler. He could not do so because of the linking
> issue. Jobs decided that using GCC was more important than keeping
> the Objectiv-C compiler proprietary. He was still able to maintain a
> proprietary library though. That library is currently in OS X.
That was not the same. NeXT Computer Inc. did modify the source of gcc
to extend the Objective-C language, and at the same time, distributed
binaries of the modified compiler. The NeXTSTEP/OPENSTEP libraries
were never considered in this affair.
The "application notes" of the GPL are clear on this point.
> The only way around the GPL requirement that I can see is to not use
> GPL code in the first place. The GPL was designed to force users of
> the GPL code to also release their code under GPL.
This is FUD.
--
__Pascal_Bourguignon__
http://www.informatimago.com/
From: David Steuber
Subject: Re: Libraries (Was: Programming By The Seat Of Your Pants)
Date:
Message-ID: <m2fzh6q5z1.fsf@verizon.net>
Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> > The only way around the GPL requirement that I can see is to not use
> > GPL code in the first place. The GPL was designed to force users of
> > the GPL code to also release their code under GPL.
>
> This is FUD.
It's not intended to be. My understanding of the GPL is that if you
use GPL code in your application (presumably a significant amount
rather than a max() function), then you must also be GPL. If you
link to a GPL library, then you must be GPL.
You can compile proprietary or other license software with GCC. That
is different. You are not linking to GCC or using GCC code to do
that.
I am a fan of the GPL and don't want to spread FUD about it. I don't
see how what I said can be called FUD anyway. I have no fear,
uncertainty or doubt that a 100% pure GPL system is possible and
viable. In fact, I think it would be a good thing.
SETEC ASTRONOMY.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
Adam Warner <······@consulting.net.nz> writes:
> Hi Pascal Bourguignon,
>
> > David Steuber <·············@verizon.net> writes:
> >> The reason for this is that the GCC compiler does not put GCC code
> >> into your object files. Lisp is a whole other beast in that
> >> respect. A Lisp image contains the Lisp runtime. If libc were GPL
> >> instead of LGPL, almost no one would use it. It would have been
> >> still born. Linking to a GPL libc would make your C program GPL.
> >> Linking to an LGPL libc does not.
> >>
> >> CLISP contains readline so is GPL. Since CLISP is GPL, then the
> >> CLISP runtime is also GPL unless it is an entirely seperate entity in
> >> the CLISP system. You can link other licensed code into GPL code in
> >> many cases.
> >
> > All this is very true, but there's no problem. It only implies that
> > you must package your deliverables in a certain way.
> >
> > In the case of clisp, you must give your customers:
> >
> > - a clisp binary along with its sources per GPL,
> >
> > - your .fas files,
> >
> > - a script that launch clisp and load and run your .fas files on
> > the customer's computer; OR, an _installation_ script that will
> > build a lisp image from the clisp and your .fas files on the
> > customer's computer.
> >
> > This way, you can sell them your .fas with any license you like. And
> > it gives your customers the freedom to correct any bug found in clisp
> > or even to implement an alternative common-lisp able to load your .fas
> > files.
>
> 1) Do the authors make this claim upon legal grounds?
>
> The authors cannot grant exceptions to the GPL and then link their code
> to non-exception licensed GPL code. Hopefully people will at least
> understand this as a moot point.
The authors no. But the user yes. And anybody is entitled to write
and distribute with any license he wants a script to build a system.
> 2) Since you emphasise distribution of .fas files rather than source code
> you must be concerned about the recipient not being able to easily decode
> them. .fas files contain an extensive amount of information about the
> original source. Extensive.
That's not the point even obfuscated encrypted binary can be
disassembled, reverse engineered, and debugged. It only asks for more
dedicated hackers.
Conversely, that's exactly the point of Richard Stallman. He would
never had started the FSF and GPL if purveyors of software and
firmware had continued to deliver the sources, even with their
restricted commercial licenses.
--
__Pascal_Bourguignon__
http://www.informatimago.com/
From: ·············@comcast.net
Subject: Re: Programming By The Seat Of Your Pants
Date:
Message-ID: <fzhl2sud.fsf@comcast.net>
David Steuber <·············@verizon.net> writes:
> This isn't really quite on topic for c.l.l, but it is strongly
> related.
>
> I am in a situation with myself where I need to basically code by the
> seat of my pants. Why? I have no design, no solid requirements, and
> generally have only a vague idea of what I want. Lisp* seems like
> the tool for the job. Besides, the only way I'm going to learn Lisp
> is to program in it.
This is the kind of situation where Lisp *really* shines.
Lisp is great when you really have no idea what you are doing.
There are several reasons for this:
1) Interactive development: compile and go one step at a
time. It's ok to start without knowing what's next.
2) Incremental development: you don't need to have every
function defined in order to compile and link.
3) Integrated debugger/error handler: with a bit of practice, this
is a powerful tool. Called an undefined function? No problem.
Just wait a sec... define it.. and continue execution from
where you left off. Don't feel like writing it now? Well,
if you know what it would return, tell the debugger to pretend
the undefined function returned a value.
4) Highly dynamic environment: Need to change the class hierarchy?
Do it on the fly, no need to recompile. That object has some
bad data in it? Use the inspector and repair it.
5) Stability. Keep the safety high when developing and you'll get
informative error messages rather than mysterious core dumps.
> I can't seem to convince people that time estimates are crap. There
> are even programmers out there who think that meaningful time
> estimates are possible. If you are one of those people, please tell
> me what the hell you smoke so I can get some.
There's a paper I read recently (I hope someone has a reference) that
argues that meaningful time estimates are impossible because of
Godel's theorem and algorithmic complexity. If you have an algorithm
for estimating how long it takes to finish a project, then mathematically
that algorithm either
a) provably gives the wrong answer on some problems
or
b) provably takes at least as long as the project to produce
an estimate.
It's a provocative viewpoint.
> I keep hearing about Lisp as a bottom up programming language. Is
> that really the case? Yeah, you use macros to build the language up
> to the problem level. If you do that unguided though, what are you
> building up to? Top down seems more natural. You start out with
> (DWIM X) and start to define DWIM.
I prefer to call it a `stratified' approach. You build some sort
of model of what you are doing at some level of abstraction. You build
a little low level stuff to get it to stagger into life, you build a
little high level stuff to make it easier to use, then you start
fleshing out the middle and adding things here and there.
> Getting closer to my specific situation which is really a nebulous
> concept that I can't tell you about... I have a number of things
> that I want to do. I have various entities that have various
> properties and need to interact in a rules based environment.
> Entities can have arbitrary properties and need to interact
> accordingly, even though entity A may know nothing about B.
>
> Add to that an external entity. This imaginary entity is called the
> user and must direct the flow of the internal entities. When the
> user is feeling lazy, some of the internal entities must self direct.
>
> If I'm not being vague enough, please let me know.
Sounds like you are developing a game.
> I think I can state my dilemma now. I need to program in such a way
> as to take a random mash of ideas and self organize into a coherent
> program in the way life organizes from cells into a living organism.
> I just don't know what that organism is yet.
That's an ambitious project, but what the heck.
> How is this problem solved in general and in Lisp in particular?
Generally, you model the entities as separate from the environment.
There would be certain `physical laws' that govern the effect of the
environment upon the entities, and then there would be more specific
rules for entity to entity interaction.
You might want to start your entities off as CLOS classes and use
generic functions to define the interactions.
But this is a completly random guess.
·············@comcast.net wrote:
> There's a paper I read recently (I hope someone has a reference) that
> argues that meaningful time estimates are impossible because of
> Godel's theorem and algorithmic complexity. If you have an algorithm
> for estimating how long it takes to finish a project, then mathematically
> that algorithm either
> a) provably gives the wrong answer on some problems
> or
> b) provably takes at least as long as the project to produce
> an estimate.
>
> It's a provocative viewpoint.
:)
I would definitely like to read that paper. Please let us know when you
find out about the reference.
Thanks,
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
·············@comcast.net writes:
> There's a paper I read recently (I hope someone has a reference) that
> argues that meaningful time estimates are impossible because of
> Godel's theorem and algorithmic complexity. If you have an algorithm
> for estimating how long it takes to finish a project, then mathematically
> that algorithm either
> a) provably gives the wrong answer on some problems
> or
> b) provably takes at least as long as the project to produce
> an estimate.
Perhaps one of these?
http://www.idiom.com/~zilla/Work/Softestim/kcsest.pdf
http://www.idiom.com/~zilla/Work/Softestim/softestim.html
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
From: ·············@comcast.net
Subject: Re: Programming By The Seat Of Your Pants
Date:
Message-ID: <brs92kcb.fsf@comcast.net>
Raymond Wiker <·············@fast.no> writes:
> ·············@comcast.net writes:
>
>> There's a paper I read recently (I hope someone has a reference) that
>> argues that meaningful time estimates are impossible because of
>> Godel's theorem and algorithmic complexity. If you have an algorithm
>> for estimating how long it takes to finish a project, then mathematically
>> that algorithm either
>> a) provably gives the wrong answer on some problems
>> or
>> b) provably takes at least as long as the project to produce
>> an estimate.
>
> Perhaps one of these?
>
> http://www.idiom.com/~zilla/Work/Softestim/kcsest.pdf
> http://www.idiom.com/~zilla/Work/Softestim/softestim.html
Yes, those are the papers.
From: David Steuber
Subject: Re: Programming By The Seat Of Your Pants
Date:
Message-ID: <m2brs8ajid.fsf@verizon.net>
·············@comcast.net writes:
> Raymond Wiker <·············@fast.no> writes:
>
> > ·············@comcast.net writes:
> >
> >> There's a paper I read recently (I hope someone has a reference) that
> >> argues that meaningful time estimates are impossible because of
> >> Godel's theorem and algorithmic complexity. If you have an algorithm
> >> for estimating how long it takes to finish a project, then mathematically
> >> that algorithm either
> >> a) provably gives the wrong answer on some problems
> >> or
> >> b) provably takes at least as long as the project to produce
> >> an estimate.
> >
> > Perhaps one of these?
> >
> > http://www.idiom.com/~zilla/Work/Softestim/kcsest.pdf
> > http://www.idiom.com/~zilla/Work/Softestim/softestim.html
>
> Yes, those are the papers.
I am glad that someone else agrees with me! This was something I
learned through experience and intuition. I've never been good at
proving things that I think are axiomatic though.
Thanks for those links.
wget is my friend.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
From: Joe Marshall
Subject: Re: Programming By The Seat Of Your Pants
Date:
Message-ID: <brs7gbyv.fsf@ccs.neu.edu>
David Steuber <·············@verizon.net> writes:
> I am glad that someone else agrees with me! This was something I
> learned through experience and intuition. I've never been good at
> proving things that I think are axiomatic though.
>
> Thanks for those links.
I particularly like the Challenge Scenario:
``You are a manager, and you believe that you can objectively estimate
development schedules.
``How long will it take your team to write a program to solve the
Goldbach conjecture? (Idea from John Casti). By the equivalence
of math and computation this is possible, and judging from other
number theory proofs the program might be pretty short (but this
is for you to estimate).''
Goldbach's conjecture is that every even number greater than 4 is
the sum of two prime numbers.
From: David Steuber
Subject: Re: Programming By The Seat Of Your Pants
Date:
Message-ID: <m2r8136d63.fsf@verizon.net>
Joe Marshall <···@ccs.neu.edu> writes:
> Goldbach's conjecture is that every even number greater than 4 is
> the sum of two prime numbers.
I take it the same prime number can be used twice? (+ 3 3)
I guess if the problem could be done that easily, Goldbach's
conjecture would either be lie or law.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
From: David Steuber
Subject: Re: Programming By The Seat Of Your Pants
Date:
Message-ID: <m2u16093wr.fsf@verizon.net>
·············@comcast.net writes:
> > If I'm not being vague enough, please let me know.
>
> Sounds like you are developing a game.
Something along those lines. It may even turn into a game.
Thanks to you, and the others, for posting some very good ideas. I
am looking at something here that is possibly larger than I can chew
no matter how many bites I take.
I'm also wondering why SBCL is taking so long to do:
; $ /Users/david/usr/src/sbcl/sbcl/contrib/sb-bsd-sockets/a.out
>/Users/david/usr/src/sbcl/sbcl/contrib/sb-bsd-sockets/constants.lisp-temp
but that is another topic for the SBCL mailing list if it never
finishes.
At least Lisp sounds like the right choice for me. I have some
friends and colleagues who don't think the language is practical for
real projects. It makes me a rather lonely programmer. Not good for
XP.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
David Steuber <·············@verizon.net> writes:
> I'm also wondering why SBCL is taking so long to do:
>
> ; $ /Users/david/usr/src/sbcl/sbcl/contrib/sb-bsd-sockets/a.out
> >/Users/david/usr/src/sbcl/sbcl/contrib/sb-bsd-sockets/constants.lisp-temp
PPC, by any chance? There's a bug somewhere in RUN-PROGRAM which
people are poking at as we speak.
-dan
--
http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro
From: David Steuber
Subject: Re: Programming By The Seat Of Your Pants
Date:
Message-ID: <m2vfqg6mux.fsf@verizon.net>
Daniel Barlow <···@telent.net> writes:
> David Steuber <·············@verizon.net> writes:
>
> > I'm also wondering why SBCL is taking so long to do:
> >
> > ; $ /Users/david/usr/src/sbcl/sbcl/contrib/sb-bsd-sockets/a.out
> > >/Users/david/usr/src/sbcl/sbcl/contrib/sb-bsd-sockets/constants.lisp-temp
>
> PPC, by any chance? There's a bug somewhere in RUN-PROGRAM which
> people are poking at as we speak.
Yes. Mac PowerBook G4 12". Please don't laugh.
I hit that in two spots. The second has to do with POSIX. I think.
I have been able to kick the build in the butt so to speak by using
the Process Viewer's "Force Quit" option on sbcl. I think that is
just doing a 'kill -9' but I'm not sure. Building continues at that
point. I don't know if this means that my sockets are broken. That
would suck for using SLIME as I see that a TCP connection is used for
IPC.
Not that it would really help me, but is there a way to force myself
into the debugger when I hit this spot while running make.sh? Or has
fact that I've passed the --disable-debugger to sbcl disabled that
option? (I edited make.sh)
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
David Steuber <·············@verizon.net> writes:
> Yes. Mac PowerBook G4 12". Please don't laugh.
laugh?
At the ILC-03 the PB with OS X looked like the lisper's platform of
choice (I think more than half of the speakers had PBs, I was one of
the exceptions with my x86-linux laptop).
--
(espen)
David Steuber <·············@verizon.net> writes:
> Daniel Barlow <···@telent.net> writes:
>
>> David Steuber <·············@verizon.net> writes:
>>
>> > I'm also wondering why SBCL is taking so long to do:
>> >
>> > ; $ /Users/david/usr/src/sbcl/sbcl/contrib/sb-bsd-sockets/a.out
>> > >/Users/david/usr/src/sbcl/sbcl/contrib/sb-bsd-sockets/constants.lisp-temp
>>
>> PPC, by any chance? There's a bug somewhere in RUN-PROGRAM which
>> people are poking at as we speak.
>
> Yes. Mac PowerBook G4 12". Please don't laugh.
I'm not laughing; I have the 1st-generation PB G4 12" myself.
I _love_ it.
> I hit that in two spots. The second has to do with POSIX. I think.
>
> I have been able to kick the build in the butt so to speak by using
> the Process Viewer's "Force Quit" option on sbcl. I think that is
> just doing a 'kill -9' but I'm not sure. Building continues at that
> point. I don't know if this means that my sockets are broken. That
> would suck for using SLIME as I see that a TCP connection is used for
> IPC.
>
> Not that it would really help me, but is there a way to force myself
> into the debugger when I hit this spot while running make.sh? Or has
> fact that I've passed the --disable-debugger to sbcl disabled that
> option? (I edited make.sh)
I don't think this will help - my current theory about this is
that using SIGCHLD to collect the status of child processes causes
SBCL to hang in certain situations.
One workaround that *seems* to work, is to add (sleep 0.5)
after the call to process-wait in run-program (which in turn is in
src/code/run-program.lisp).
Another option is to not use SIGCHLD and instead poll
explicitly in process-wait (still in run-prgram.lisp). Youd do this by
commenting out the call to sb-sys:enable-interrupt for SIGCHLD in
run-program, and adding the form
(get-processes-status-changes)
to process-wait, somewhere inside the loop.
The first workaround has the downside that it slows things
down. The second requires that you periodically call
sb-impl:get-processes-status-changes if you use run-program with :wait
nil (the other case is handled by the call in process-wait).
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
From: David Steuber
Subject: Re: Programming By The Seat Of Your Pants
Date:
Message-ID: <m2wuav6dg5.fsf@verizon.net>
Raymond Wiker <·············@fast.no> writes:
> One workaround that *seems* to work, is to add (sleep 0.5)
> after the call to process-wait in run-program (which in turn is in
> src/code/run-program.lisp).
This seems to be the easiest option for now. Are you referring to
the call on line 609 in src/code/run-program.lisp?
Is there a better way to rebuild the core than make.sh? I would
think I could just recompile that one file into the core and dump out
a new core. Then I can try rebuilding the system again and see if
that worked.
I'm going to hit the docs to see how to do that. If I can't figure
it out, I'll be back.
I really need my mail working on this machine so I can use the
mailing list.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
David Steuber <·············@verizon.net> writes:
> Raymond Wiker <·············@fast.no> writes:
>
>> One workaround that *seems* to work, is to add (sleep 0.5)
>> after the call to process-wait in run-program (which in turn is in
>> src/code/run-program.lisp).
>
> This seems to be the easiest option for now. Are you referring to
> the call on line 609 in src/code/run-program.lisp?
Yes. Specifically, the form
(when (and wait proc)
(process-wait proc))
should be turned into
(when (and wait proc)
(process-wait proc)
(sleep 0.5))
>
> Is there a better way to rebuild the core than make.sh? I would
> think I could just recompile that one file into the core and dump out
> a new core. Then I can try rebuilding the system again and see if
> that worked.
You should be able to change run-program.lisp, compile it and
load it into a running sbcl. At that point, you can use
sb-ext:save-lisp-and-die to create new lisp image.
If you have a terminal window open and cd into your sbcl
source directory, you should be able to do something like this (after
you have edited run-program.lisp):
src/runtime/sbcl --core output/sbcl.core
* (compile-file "src/code/run-program.lisp")
* (load "src/code/run-program")
* (sb-ext:save-lisp-and-die "output/sbcl.core.new")
mv output/sbcl.core output/sbcl.core.org
mv output/sbcl.core.new sbcl.core
Note: the three lisp forms could be put into a lisp file (say,
"fixup.lisp"; you should then be able to do
src/runtime/sbcl --core output/sbcl.core --load fixup.lisp
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
From: David Steuber
Subject: Re: Programming By The Seat Of Your Pants
Date:
Message-ID: <m2znfr1w6w.fsf@verizon.net>
Raymond Wiker <·············@fast.no> writes:
> > This seems to be the easiest option for now. Are you referring to
> > the call on line 609 in src/code/run-program.lisp?
>
> Yes. Specifically, the form
>
> (when (and wait proc)
> (process-wait proc))
>
> should be turned into
>
> (when (and wait proc)
> (process-wait proc)
> (sleep 0.5))
Ok, I got the right one then.
It did let the compile go straight through.
> You should be able to change run-program.lisp, compile it and
> load it into a running sbcl. At that point, you can use
> sb-ext:save-lisp-and-die to create new lisp image.
I was poking around the docs and found a similar way to do the job
that you describe. I made the change in src/code/run-program.lisp
and sucked it in this way:
sbcl --load src/code/run-program.lisp
I used save-lisp-and-die inside the Lisp to dump the new core.
After doing that, I used the new core to do a full rebuild again to
confirm that it worked and it did.
Now I'm just left with wondering why slime locks up Emacs on my Mac.
CPU pegs, so I'm guessing some sort of infinite loop. Or maybe it is
a similar problem with process-wait. I'll have to inspect the Lisp
code in swank-sbcl.lisp.
I'm going to try out ilisp to see how I like that.
Thanks.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
David Steuber <·············@verizon.net> writes:
> I'm also wondering why SBCL is taking so long to do:
>
> ; $ /Users/david/usr/src/sbcl/sbcl/contrib/sb-bsd-sockets/a.out
> >/Users/david/usr/src/sbcl/sbcl/contrib/sb-bsd-sockets/constants.lisp-temp
It's because of a bug in the MacOSX port of SBCL... I have a
simple work-around for this (two, in fact), but no real solution.
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
David Steuber writes:
> I am in a situation with myself where I need to basically code by the
> seat of my pants. Why? I have no design, no solid requirements, and
> generally have only a vague idea of what I want. Lisp* seems like
> the tool for the job. Besides, the only way I'm going to learn Lisp
Paul Graham has a paper on this. He compares programming to painting.
> world that I have had experience with. The business wants X but they
> don't seem to want to tell me what X really is.
>
> When pressed, the business will come up with what they think is a
> precise definition of X. To me, it is still hand waving, only with
Or maybe the business doesn't exactly know either.
> I keep hearing about Lisp as a bottom up programming language. Is
> that really the case? Yeah, you use macros to build the language up
> to the problem level. If you do that unguided though, what are you
Macros are just one of the available tools for bottom-up programming.
Paolo
--
Paolo Amoroso <·······@mclink.it>
[Project problems]
I recommend "The Pragmatic Programmer" (Andrew Hunt, David Thomas).
You need tracer bullets (p.48).
From: David Steuber
Subject: Re: Programming By The Seat Of Your Pants
Date:
Message-ID: <m2znfs9472.fsf@verizon.net>
Stefan Scholl <······@no-spoon.de> writes:
> [Project problems]
>
> I recommend "The Pragmatic Programmer" (Andrew Hunt, David Thomas).
> You need tracer bullets (p.48).
You don't need to tell me that I need tracer bullets :-P
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
"David Steuber" <·············@verizon.net> wrote in message
···················@verizon.net...
> This isn't really quite on topic for c.l.l, but it is strongly
> related.
>
> I am in a situation with myself where I need to basically code by the
> seat of my pants. Why? I have no design, no solid requirements, and
> generally have only a vague idea of what I want. Lisp* seems like
> the tool for the job. Besides, the only way I'm going to learn Lisp
> is to program in it.
That's the best plan.
In my case, I knew exactly what was coming down on my plate was something
that was not only ill-specified, but subject to change at a moments notice.
Pages of spec details that are taken as gospel, coded up, testing started,
only to have it thrown out. "Just kidding!"
"Hey, you know all of those documents that you foolishy based you
assumptions of what we wanted upon? They're gone. Here's a new set..."
The power of Lisp is that you can work both bottom up and top down at the
same time. The goal being to meet in the middle. A lot of the bottom up
parts are simply in the language itself, or through any useful libraries.
It's very easy to "think" (or doodle in your case) in S-Expressions to try
and get your head around what you want to do. Once you have your task
"modeled" into these S-Expressions, then you can put yourself to task of
making those expressions actual code. Remarkably, in the end, you're
application is your model.
It's great because you just type your thoughts in, express your ideas, work
it out in your head, craft up some utility functions, concoct the high level
framework so your doodlings actually compile, if not necessarily do
anything.
Combining functions, macros, and the reader, if you stick with basic
S-Expressions, you can come up with pretty much anything, quickly.
Also, another great facet is that half of your application can simply be
broken withouth affecting the other half. It's frustrating when you have to
keep the whole app in sync with your development just to try things out.
Playing with the listener, redefining code and objects on the fly, testing
them in place is much easier. Make a change to a C++ file and all of a
sudden nothing compiles, you have to percolate your change out to all sorts
of places that rely on the old version just to compile it. This behavior
does not promote experiments and Seat Of Your Pants coding.
The best part is that once you're "in the groove", once you've made the leap
and your code gets some reasonable mass, but not necessarily a lot of
momentum, then you can be very reactive to changing requirements. The
problem with other systems is that not only does the code gain mass, it
gains a LOT of momentum that makes it difficult to change quickly. Lisp can
have the mass, but takes on that momentum a lot later on in the process, I
think.
You can read my Opus on this on google:
http://groups.google.com/groups?safe=off&ie=UTF-8&oe=UTF-8&as_umsgid=4caA9.1
··················@newssvr14.news.prodigy.com&lr=&hl=en
Regards,
Will Hartung
(·····@msoft.com)
Here are my rules of thumb for attacking the type of problem you describe.
[BTW: Comments are welcome - I would like to write a magazine article on
this topic someday. This note is a first attempt to organize these ideas.]
Overview:
1) Distinguish between programming and architecture.
2) Apply rules of thumb.
3) Relevance to Lisp.
1) Architecture vs. programming.
As a crucial first step, recognize that "programming" is divided up into a
number of activities. To keep things simple in this discussion, I will
keep the number down to 2, but there are more.
If you miss this step (or if you simply disagree with me), then the rest of
my rules-of-thumb will appear to be completely insane (corollary: if my
rules-of-thumb seem insane, try re-reading this section).
"Programming" is what you do when you know exactly what you want to
accomplish. You code up the solution and test it against the "spec".
"Architecture" is what you do to organize a set of programmed (or
to-be-programmed) parts. The unknown and unpredictable portions of a
software project are almost always architecture-related. Architecture
often appears on a Gantt chart at both ends - at the front, it is called
"Design", at the back, it is called "Integration".
Almost no textual programming language deals with the architecture problem
directly. Lisp comes an order-of-magnitude closer to this ideal than
anything else I know of [1]. Scripting languages, like "sh", "bash", have
a flavor of architecture to them - it might help to remember these
scripting languages as you read the rules-of-thumb, below.
A good architect attempts to reduce the amount of code for a specific
application. A bad architect inadvertently increases the amount of code by
over-parameterizing, over-ooping and over-specifying an application.
A badly architected application will incur unpredictable "integration time",
while the ideally-architected application will have close-to-zero
integration time [2].
Good architecture involves "rewiring" - plugging software components
together as if they were stereo components.
Bad architecture involves "parameterization" [3].
Everyone who has been near a whiteboard has performed a weak form of
architecture. Strong architecture is a set of rules that apply to real
coding practices.
You use both of these techniques to solve a problem. Sometimes, you Program
bottom-up. At other times, you Architect from the top-down.
If you adopt this split, your problem is already half as hard. If you can
ignore the Programming part for a while, then you only have to solve the
Architecture half. When you get really bored, or are having a particularly
anal day, or you've finished the Architecture, you can Program.
You also discover that the programming part becomes more predictable, while
the architecture part remains unpredictable. Dealing with two units of
work - one predictable and one unpredictable - is still better than dealing
with one larger, unpredictable unit of work.
2) Rules of thumb for architecture.
The goal of creating a flexible architecture is to compose an application
AND to ensure that the application's behaviour can be radically changed on
short notice. Corollary: The goal of Programming is to provide units of
work that the architecture can use to accomplish the goals of Architecture.
Here are some rules of thumb for Architecture:
- Keep control/data *flow* and data *structure* strongly separated.
Architecture is about flow-of-control and flow-of-data. Corollary:
Programming is about the structure of data and operations on the data.
- Don't use OOP to describe an architecture. Corollary: if you use OOP, use
it to describe the data, not the flow-of-control nor the the flow-of-data
[4].
- Use Composition, not Inheritance. Architecture expresses time-related
flow of control and information. Inheritance obfuscates such time-related
details.
- Remove control-flow constructs from your data-oriented code (the Program
stuff), e.g. use no (or few) IF's, WHILE's, etc. in code that deals with
data. Another way to say this is: each Program chunk implements exactly
one "function point" [5].
- A good architecture has 0 (zero, no) variables [6]. If you must supply
parameters to a function, use as few as possible - 0 or 1 [7].
- Avoid implicit stacking. The point of architecture is to clearly display
and accurately define what needs to be done. If the architecture requires
more than one copy of an object, then the architecture should display this
fact explicitly. For example, if you need more than one copy of an object,
don't use variables or parameters to "hide" these architectural objects on
the machine stack. Instead, use an explicit stack object which is
manipulated by the architecture's sequencer(s).
- Be specific. Do not use abstraction. Architecture is about solving *a*
problem, not all of the problems in the world. In my experience, this
specificity leads to a counter-intuitive result: units of programming can
be more easily adapted to wild design changes. The units (functions,
subprograms, classes) tend to be smaller, more easily understood and more
easily used and more easily rewritten and replaced [8].
- Expunge CALL/RETURN. The best unit of encapsulation is the "process".
Processes provide as-good or better data encapsulation as oop objects. In
addition, processes provide control-flow encapsulation, whereas CALL/RETURN
leads to architecturally-hidden, deep dependencies (time-dependent, control
flow chains). When working on a architecture, use processes instead of
libraries or classes [9][10][11].
- Structure your control flow. Readable, understandable architecture is a
hierarchical tree, not a graph. The root of the tree is a "Sequencer" that
controls its childrens' actions. Each successive (non-terminal) node is
also a "Sequencer". No child should communicate with another child, other
than through the parent [12].
3) Relevance to Lisp
Some of Lisp's Architectural features include:
- Multi-paradigm programming: allows one to choose sub-architectures as
necessary, the architecture is not constrained to only one paradigm. This
means that you can conveniently separate control flow from data
construction in the same language, for example you can use CLOS for the
data structuring and use sequential programming or rule-based programming
for the control-flow portions.
- Cheap syntax + functions + industrial-strength macros + closures: make
composing architectural sub-languages imaginable.
- Ability to hide / ignore data structuring concerns plus ability to switch
to an excruciatingly detailed structuring when necessary (i.e. production
engineering for efficiency can be done after the architecture and
programming phases have been completed).
- Interactivity => testability: when you do write Program units, they can be
immediately tested and then promoted to the architecture's palette of
components.
- Ability to compile and run incomplete programs, ie. a Lisp program can run
even when many functions are as-yet undefined. This allows you to write the
code for an architecture, check it and compile it and run it, even when the
details are missing. If you can compile/check/run an architecture before
the rest of the programming is done, then the "Integration" step moves up
the software life-cycle. Since Architecture and Integration are the
biggest unknowns in the software lifecycle, moving both to the front of the
lifecycle makes it possible to predict the rest of the software lifecycle
(i.e. Programming) with more reliability.
- Lisp's syntax makes everything look like a function call. This has an
important psychological property - it seems easier to write parameterless
functions in lisp, you don't feel like you are giving up efficiency to do
so, e.g. macros can be used to deal with efficiency while keeping the
visual appearance of the textual code architecturally sound (no variables,
no parameters). People point out that Lisp code has very little "momentum"
- they feel much freer to perform massive alterations to a Lisp program
than to a program written in most other languages.
Paul Tarvydas
········@allstream.net
[1] BTW: I am currently working on a graphical language that does deal
directly with the problems of architecture. Surprise!
[2] "Integration time" is the most unpredictable and least schedulable
aspect of a software project. If you could integrate a project (at the
architectural level) before doing the programming, then most of the
scheduling problems for Programming will disappear. The concept of "daily
build" is an attack on this problem, but, is a defeatist admission that the
architecture was poorly defined at the onset of the programming phase. One
can integrate a project before the onset of programming by using the above
rules-of-thumb.
[3] Parameterization: adding features that are enabled by flags and/or
inheritance.
[4] You will notice that oop-ists invent architectures like MVC and use oop
to implement them, but they use pictures to describe these architectures.
In other words, their oop languages are insufficient to accurately
*describe* an architecture (as are most textual languages). Oop languages
tend to have an even more architecture-hostile bent to them - they
obfuscate control flow via inheritance and method overriding (something
which you quickly discover when you are sitting in a backtrace trying to
figure out what combination of inherited methods caused your program to
crash).
[5] If you don't know what a "function point" is: roughly, it is a measure
used to predict application complexity by counting the number different
actions in a spec. Basically, an action can be thought of as a change in
control flow or a decision point. In real life, every IF-THEN-ELSE, every
WHILE, etc. contributes to increased complexity. If you try to segregate
these decision points away from the units of data-oriented work, you have a
better chance of spotting overly-complex regions of code and you have a
better chance of rearranging an architecture on short notice.
[6] The best example of a variable-less language is the compiler language
S/SL - Holt, et al. S/SL deals only with control and data flows, has no
variables and allows 0 parameters or 1 parameter to functions.
[7] Many parameters - in the architectural functions - implies that the
function contains many function points and is hiding them from
architectural view. This is often caused by a failure to sufficiently
decompose an architecture.
[8] This is where I strongly disagree with UML. Architecture (and
architectural pictures - blueprints) should be used to describe an intended
solution to a problem. A set of patterns might be a good reference for the
architect, but the blueprint produced by the architect should be specific
enough that there is no decision-making left in the hands of the
tradespeople (Programmers).
[9] Note that RPC (remote procedure call) is a particularly sadistic form of
CALL/RETURN - pure architectural evil.
[10] It might be hard to generate an architecture using present-day
processes, because process support is too heavy-weight in most textual
languages that I know about (although I have not looked to see how heavy
CSP and Occam are). I'm talking about (and have constructed on repeated
occasions) architectures with some 300 intercommunicating "processes". (We
build our own "kernels" which remove the especially inefficient aspects of
processes).
[11] Paul Graham - if you are reading this and want to know where to blow
more CPU cycles in ARC, consider adding implicit function-(or
statement)-level concurrency. Bash and sh have it.
[12] Observation: it is very tempting to create code which breaks this
architectural-tree convention by allowing sibling functions to call one
another. This is one of the temptations that leads to the software crisis
- hard to track bugs, unmaintainable code.
From: ··········@YahooGroups.Com
Subject: Re: Architecting By The Seat Of Your Pants
Date:
Message-ID: <REM-2004mar31-002@Yahoo.Com>
> Date: Sat, 25 Oct 2003 18:48:28 GMT
(Sorry I didn't see this article at the time it was fresh. I was rather
occupied with the fact my car had died and I had a new wonderful
almost-girlfriend, unfortunately she didn't last past Nov.26.)
> From: Paul Tarvydas <········@attcanada.ca>
> Here are my rules of thumb for attacking the type of problem you
> describe. [BTW: Comments are welcome - I would like to write a
> magazine article on this topic someday. This note is a first attempt
> to organize these ideas.]
Yes, I'll comment on your fascinating ideas...
> Overview:
> 1) Distinguish between programming and architecture.
Overview of my response to this part (which is relevant to
comp.programming too, too bad it's not cross-posted there):
What you call "programming" is what I call "bottom-up input-to-output
tool-building". With a mind toward the overall program objective, I
build very low-level tools to accomplish key data-processing tasks,
starting from the input and working toward the output. In C I have to
start at a very very low level, whereas in LISP most of the very low
level stuff is already written and I can start working up from a higher
level. Regardless of the language, the hardest part for me is the input
parser, converting some alien syntax into meaningful pointy-structure.
This of course assumes I have access to actual data from the start, so
I can debug my tools on actual data and be sure the parser is working
early-on and then be sure each subsequent processing stage is working
too.
What you call "architecture", the top-down design and integration, I
might mostly decide from the start, or I might treat mostly as an open
research project, seeing the picture better after some tools have been
developed that perform some of the processing so I know what I'm really
dealing with. (My last paying jobs, long long ago, were true R&D,
trying to solve problems not previously solved, so we couldn't say from
the very start how things would turn out, although we did have some
idea of top-level design from the start. I wish somebody would hire me
to program again. I *really* **really** need the money before I become
homeless!!)
> Good architecture involves "rewiring" - plugging software components
> together as if they were stereo components.
> Bad architecture involves "parameterization" [3].
Um, when building tools to be installed in a commonly-available
library, such as most of the LISP specification, it's a useful thing to
parameterize in reasonable ways. For example:
(position <item> <sequence> &key :from-end :test :test-not :start :end :key)
It's good architecture to use those tools, supplying specific
keyword-value pairs as appropriate for each particular use, rather than
re-invent a specialized routine that isn't parameterized. Disagree?
When building new tools for a specific application, perhaps one should
build only the capability one immediately needs, then when it becomes
apparent that parameterizing via additional keywords would be of
benefit, i.e. when there are several similar tools needed and it seems
better to parameterize one function rather than write several variants
of it, do that at that time. But other times it's easiest to just copy
the block of code, change the function name, make tiny changes, and get
the new function working, and not bother with merging the two functions
into a single parameterized function. Sometimes it's just a matter of
what mood I'm in at the time, because either way works, and whichever I
can get working quickest in my current mood is best, since storage
space and CPU time are a lot cheaper than programmer time lately.
Agree?
> The goal of creating a flexible architecture is to compose an
> application AND to ensure that the application's behaviour can be
> radically changed on short notice.
Nit: If you grossly change the behaviour, then you don't have the same
application (program) as before, you have some other application only
similar to the original. In math, if you have a set {A B Q} and you
change it so you have {A B W}, it's not the same set as it was before.
(Alices Adventures in Wonderland explored some of these questions about
whether you really can say two different things are the same.)
Likewise, if you want to change the behaviour of an application,
sometimes there's one key component you can simply copy and grossly
changes, so it's not at all the same component as it was before, and
the overall application isn't quite the same with this new component as
it was with the original component. With a most extreme change in
behaviour, you simply write a totally new application, sharing hardly
any code with the old application, and you tell the user which
application to use for which purposes. How radical exactly can you
change the behaviour on short notice? Like previously it was a program
to sort your mailbox spam/notspam, and suddenly you want it to play a
video game with you, or solve interplanetary trajectories, instead? Get
real!
> The goal of Programming is to provide units of work that the
> architecture can use to accomplish the goals of Architecture.
I.e. the goal of Programming is to build useful D/P tools.
> - Keep control/data *flow* and data *structure* strongly separated.
> Architecture is about flow-of-control and flow-of-data. Corollary:
> Programming is about the structure of data and operations on the data.
The extreme interpretation of this would be to always use ADTs
(Abstract Data Types) as the interface between Architecture and
Programming. For example, Architecture team decides we need a way of
representing e-mail messages, and a way of representing CTW (Complain
To Whom) information, and some algorithm to look at spam and figure out
the corresponding CTW for it. We also need a way to scan a in-mailbox
to find which messages are spam, move the spam to a different mailbox,
and then in background call that message-to-CTW function and auto-send
the spam complaints accordingly. Programming deals with the interface
needs to the in-mailbox and the out-email, the data format specific o
this application, and the algorithms. Right?
> - Don't use OOP to describe an architecture. Corollary: if you use
> OOP, use it to describe the data, not the flow-of-control nor the the
> flow-of-data [4].
I'm half with you. But when you combine small tools to make larger
tools, can't you then encapsulate the larger tools into the OOP
framework sometimes, to make it easy to be used? So then some flow of
control is needed to put tool 1 before tool 2 in building bigTool12345.
I think this point needs clarification by example.
> - Use Composition, not Inheritance. Architecture expresses
> time-related flow of control and information. Inheritance obfuscates
> such time-related details.
Maybe I agree most of the time, but wouldn't inheritance be useful when
you have several different sub-types of a given type which all handle a
particular event pretty much the same way? For example, several
different kinds of windows, when clicked, first check whether they are
foreground or background, and if background they just go to foreground
and immediately return from the event handler, whereas if already
foreground they do something different. Isn't it best to code that
toplevel back/foreground decision once in the parent class instead of
having to copy the code again in each new kind of window, or even have
to copy the one line of code that calls the generic back/foreground
decision?
> - Remove control-flow constructs from your data-oriented code (the
> Program stuff), e.g. use no (or few) IF's, WHILE's, etc. in code that
> deals with data. Another way to say this is: each Program chunk
> implements exactly one "function point" [5].
I think this carries Dijkstra's ideas too far. When combining tool1 and
tool2 to make tool12345, we might need to check the result from tool1
before deciding whether to call tool2 or tool3 next. This is strictly
Programming in regard to the overall project, even if it is
Architecture in relation to the indivdiual tool1 and tool2.
I see no reason not to code like this:
(defun tool12345 (frob1 frob2)
(let ((result1 (tool1 frob1)))
(if result1 (tool5 (tool4 (tool3 result1 frob2)))
(tool2 frob1 frob2))))
This is data-oriented code, simply writing a tool to to process two
items of data and produce one resultant item of data, making a decision
along the way. Sometimes the decision is more complicated:
(defun try12345 (frob)
(or (try1 frob) (try2 frob) (try3 frob) (try4 frob) (try5 frob)
(error "Nothing worked.")))
Is there something wrong with that, in your opinion?
> - A good architecture has 0 (zero, no) variables [6]. If you must
> supply parameters to a function, use as few as possible - 0 or 1 [7].
This seems to go against functional programming, and against LISP.
What's the alternative to passing 3 parameters here?
(sort <list> <compareFn> :key <keyFn>)
What's the alternative to passing 5 parameters here?
(make-bicycle <frame> <front-axle-assembly> <front-wheel> <rear-wheel>)
Is it really important, from the toplevel view, to specify the
sequence, like this:
(make-whole-bicycle
(make-almost-bicycle
(make-main-bicycle-part-of-bycycle <frame> <front-axle-assembly>)
<rear-wheel>)
<front-wheel>)
What if the toplevel Architecture team doesn't know or care which of
the two wheels is put on first. Can't that decision be safely hidden
down in the innerds-implementation (Programming) team? For that matter,
maybe the front wheel is attached to the front fork before the fork is
attached to the frame. Or the rear wheel is attached to the frame
before the front fork (with or without front wheel). If a structure has
four main parts, can't the toplevel call simply say what the four parts
are without specifying the sequence they'll be put together?
Now consider the hash-table ADT in LISP (yes, it really is an ADT,
where only the functionality, not the implementation, is documented for
the user):
(make-hash-table &key :test :size :rehash-size :rehash-threshold)
It might seem reasonable that first you need to build the basic table,
so you need to know the size first, then you need to say what test
function to use, then you need to say what the rehash thrshold is,
finally you need to say what the rehash size will be, so the user
should have to build it in pieces:
(start-building-hash-table &key :size)
(set-hashtable-test &key :test)
(set-hashtable-threshold &key :threshold)
(set-hashtable-newsize &key :rehash-size)
(get-fully-built-hadh-table) ==> result we want
But isn't that rather absurd?
Also, maybe a totally different structure is needed for EQUAL compared
to EQ tables, so the builder needs to know the :test before the :size.
It seems to me the user doesn't care the sequence and would prefer to
specify all four arguments all at one time.
Maybe you need to clarify what you really meant to say here.
> [7] Many parameters - in the architectural functions - implies that
> the function contains many function points and is hiding them from
> architectural view. This is often caused by a failure to sufficiently
> decompose an architecture.
Sometimes the Architecture team cares how the various parts are
organized into sub-structures, and sometimes it doesn't. Instead of
being hardlined about this issue, I suggest we be flexible. If it's
really important for the Architecture team to know that these two
pieces are in one sub-assembly whereas these three other pieces are in
a different sub-assembly, then the interface would be like:
(make-whole-frob
(make-sub-assembly-1 <part1a> <part1b>)
(make-sub-assembly-2 <part2a> <part2b> <part2c>)
)
But if all the Architecture team cares about is that the five pieces
all get put in the correct places, it'd be better to interface with
keywords all at the same level like this:
(make-whole-bicycle
:front-wheel ... :front-fork ... :frame ...
:rear-wheel: ... :light ...)
where the sequence isn't important, only the matching of part-names
with part-specs.
> Architecture is about solving *a* problem, not all of the problems in
> the world.
I agree. But on the other hand, a tool that has many uses, so you'll
use it in a lot of applications, and use it several times in each
application, so you won't forget about it, is often better than a tool
that works only for this one application. If it's easier to make the
tool rather general, and harder to restrict it to work only for this
one application, then clearly you should usually make it rather
general. Only if it's harder to make it general than specific, then you
have a tradeoff between ease of making that tool and possibility of
re-use. In that case, whatever mood I'm in at the time, whether I feel
it's easier to write one slightly parameterized tool that'll be
immediately used both ways, or write one specific tool then need to
write another slightly differently later. I think you need to consider
both options and be flexible in your decision, or just go with your
mood.
> [8] ... the blueprint produced by the architect should be specific
> enough that there is no decision-making left in the hands of the
> tradespeople (Programmers).
I disagree. The artictect should say what the goal is for a particular
D/P tool and leave it to the programmers to decide how best to achieve
that goal. For example, I want these 40 items sorted into ascending
sequence by girth, and I don't care whether the programmer uses bubble
sort or something "more efficient", and I don't even care whether items
of equal girth are kept in the same sequence or not.
> - Expunge CALL/RETURN.
Huh? Is this a joke?? I invoke a D/P tool to process some data and
produce some other data and/or produce a side-effect. I CALL the tool,
and when the tool is done it RETURNs the resultant data to me.
For example, I call a dictionary tool, given some word I provide, to
give me back a definition of that word. What's the alternative??
> [9] Note that RPC (remote procedure call) is a particularly sadistic
> form of CALL/RETURN - pure architectural evil.
Speaking generically of client/server relationships for query/response,
such as DNS for mapping host name to IP number, not specifically about
Sun RPC (RFC 1057), I admit timeouts and failures to connect can be a
nuisance, but what alternative do you suggest?
> - Structure your control flow. Readable, understandable architecture
> is a hierarchical tree, not a graph. The root of the tree is a
> "Sequencer" that controls its childrens' actions. Each successive
> (non-terminal) node is also a "Sequencer". No child should
> communicate with another child, other than through the parent [12].
I mostly agree, and if you draw the chart right then siblings can't
call each other simply because you drew the chart that way, and I
suppose it's fine if you hate tail recursion, but ...
Are you saying recursion is a stupid idea in all cases??
You said something about replacing recursion with an explicit
stack ADT or somesuch. Do you really mean that? Instead of
(defun copy-deep (sexpr)
(if (consp sexpr)
(cons (copy-deep (car sexpr))
(copy-deep (cdr sexpr)))
(if (vectorp sexpr)
(map (type-of sexpr) #'copy-deep sexpr)
sexpr)))
you would want to write that explicitly in terms of pushing things onto
a stack ADT and later popping them back off, with a toplevel loop for
repeatedly deciding what to do next? I disagree strongly.
Regarding LISP:
> - Interactivity => testability: when you do write Program units, they
> can be immediately tested and then promoted to the architecture's
> palette of components.
Indeed, that's the way I write LISP code only moreso: one "line" (D/P
tool-call) at a time, immediately seeing if it worked before moving on
to the next tool-call, then when I've finished all the pieces of the
next-higher tool I finish wrapping the (DEFUN ...) around it and
evaluate that to get a function and immediately re-test it on the same
data I used manually before then maybe on some other different data.
For example, here's a historical re-creation of something I was
building last night:
;Setting up the test data:
(setq topsyms '(BD0))
;Setting up initial conditions of loop:
(setq donesyms (list))
(setq thesesyms topsyms)
;Calling the next-lower-level tool I had just finished debugging:
(setq nextply (save-these-only thesesyms))
;Updating a loop variable:
(setq donesyms (append donesyms thesesyms))
;Setting up what remains to be done:
(setq nextply (nset-difference nextply donesyms))
;Asking me if I want to do next batch, and moving the next-batch list
; to the main loop variable:
(when (and nextply
(y-or-n-p "At the next ply, there are ~D boards not ~
yet saved. Save them now?" (length nextply)))
(setq thesesyms nextply) ;(go lp)
)
Note: GO not valid outside PROG, so because I'm doing this one line at
a time I need to suppress the GO here. If this code were already
written, and I found a bug, using an automated single-step package
inside the entire function definition would be nifty, but during
initial code-writing time it's easier to do the single-stepping under
manual control, and SETQs are easier to deal with than LET* or LOOP.
So anyway I manually cycle through those steps until I'm satisfied the
code is working piece by piece, then I add a new statement in the
middle and test it with the others, then put the wrapper around it, and
copy&edit the test-rig and function-call syntax to make a test case at
the very end:
(defun save-board-symbols-to-disk (topsyms) ;(setq topsyms '(BD0))
(prog (donesyms thesesyms nextply)
(setq donesyms (list))
(setq thesesyms topsyms)
(if (probe-file "gosyms.dat-tmp")
(if (y-or-n-p "Warning: File already exists, destroy it?")
(delete-file "gosyms.dat-tmp")))
lp
(setq nextply (save-these-only thesesyms))
(setq donesyms (append donesyms thesesyms))
(format t "~%So-far, a total of ~D board-symbols saved to disk.~%"
(length donesyms))
(setq nextply (nset-difference nextply donesyms))
(when (and nextply
(y-or-n-p "At the next ply, there are ~D boards not ~
yet saved. Save them now?" (length nextply)))
(setq thesesyms nextply) (go lp))
))
;(save-board-symbols-to-disk '(BD0))
Then I execute that test form at the end to verify it really works.
I could rearrange the code to use an outer set of (LET ...) then a
(LOOP ...) and another inner set of (LET ...), just to avoid using
PROG, but why bother? It ain't broken so it don't need fixing!
> - Ability to compile and run incomplete programs, ie. a Lisp program
> can run even when many functions are as-yet undefined.
Even better (per example above): No need to compile anything,
especially a big "program", and no need to run the whole program at all
during tool-building. Just set up test rig for the one tool you're
planning to write next, then execute one line of code at a time
manually before those lines of code are even really part of a tool
except in your mind.
For some appliations, there never really is a "program", merely bigger
and bigger tools until there is a tool that does most of what you want
done today so you stop programming until later when you think of even
more you'd like done with a different tool by itself or a different
took combined with the old tool(s) into an even bigger tool.
> - Lisp's syntax makes everything look like a function call.
That's one of the many things I like about LISP. I write an open
parenthesis, then some English-language word-like thingy that I can
look up in the alphabetical index in the back of the manual or search
for in an online LISP manual/spec, instead of having the key operator
somewhere in the middle where I have to look to find it and worry about
operator precedence to figure which is really the toplevel operator:
A = B + C % D < E ! F && G , H;
(I hate C compared to LISP! That's one of many reasons.)
> This has an important psychological property - it seems easier to
> write parameterless functions in lisp, you don't feel like you are
> giving up efficiency to do so, e.g. macros can be used to deal with
> efficiency while keeping the visual appearance of the textual code
> architecturally sound (no variables, no parameters).
I don't like this idea at all. You want a single huge batch of global
variables that get side-effected by the code (or equivalently a huge
global state-vector-object whose many slots are side-effected by the
code), and the user who calls a function has no idea which globals are
used and which are modified, and the user has no way to explicitly run
parallel chains of data processing, such as:
(setq input1 "Foo is a word.")
(setq input2 "Bar is another word.")
(setq parse1 (parse-test input1))
(setq parse2 (parse-test input2))
(setq result1 (try-doing parse1))
(setq result2 (try-doing parse2))
How would you do something like that if functions didn't take
parameters, all you had was (set-global-text) which opened a dialog to
get user input then set up global variable $text$, (parse-global-text)
which used $text$ to produce $parse$, and (try-doing-global-parse)
which used $parse$ to do something and set up $result$, and
(examine-global-result) which allowed you to examine $result$?
Would you do it by having two processes, and the user switches between
the two to pick which state-vector-object will be used at any given
time? If so, what if you want to cross data from one process to
another, or combine data from two processes into a third? With explicit
parameters and variables it's easy, with no hassle, for example:
(show-differences result1 result2)
I think parameters are great. You have the choice of canned test:
(setq ichan (open "foo.dat"))
or choose-on-the-fly:
(setq ichan (open (user-file-dialog)))
You can just look at that code and see what's happening at the level
you need to know. What's wrong with that??