Comparing Lisp conditions to Java Exceptions
William Bland
recently, and he agreed that Lisp's conditions have several points in
their favour. He did raise one point though, that I didn't know the
answer to.
In Java you may specify, as part of a method's signature, the classes of
Exception that it might throw. I had to admit that I knew of no facility
for declaring the conditions that might be signalled by a Lisp method or
function. Is there such a mechanism? If not, are there good reasons why
it would be an unnecessary or undesirable feature?
Thanks,
Bill.
Barry Margolin
William Bland <new...@abstractnonsense.com> wrote:
It doesn't exist in Lisp. In languages with static typing, exception
declarations allow the compiler to warn if you don't establish handlers
for all the possible conditions that may be thrown. But since Lisp
isn't statically typed, declarations like these don't really fit.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Dave Watson
> In Java you may specify, as part of a method's signature, the classes of
> Exception that it might throw. I had to admit that I knew of no facility
> for declaring the conditions that might be signalled by a Lisp method or
> function. Is there such a mechanism? If not, are there good reasons why
> it would be an unnecessary or undesirable feature?
>
> Thanks,
> Bill.
For the same reason one doesn't have to declare return values in lisp:
lisp is completely dynamic. It is just not necessary, because there is
no type-checking at compile time.
--
-Dave Watson
djwa...@docwatson.org
Kenny Tilton
Others have explained why it is inappropriate for Lisp, so let me take a
crack at undesirable. Why do I have to specify the conditions my code
may spawn? And change it when I change what the function actually
throws? Where did this housekeeping burden come from? Oh! Some genius
thinks the compiler can make my code Correct, if only I spend half my
time jumping thru compiler hoops.
The compiler can never guarantee my code is correct, so wasting time
jumping thru its hoops is undesirable.
This, as others did suggest, is just another sampling from the static vs
dynamic trade-off, long ago decided in favor of dynamic.
kenny
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Ulrich Hobelmann
> The compiler can never guarantee my code is correct, so wasting time
> jumping thru its hoops is undesirable.
Quite true in general, but sometimes it might remind you that you
forgot to catch that new exception you added to some code. From
Bruce Eckel's weblog (IIRC) I gathered that in dynamic languages
these errors are uncovered by good testing instead.
> This, as others did suggest, is just another sampling from the static vs
> dynamic trade-off, long ago decided in favor of dynamic.
It depends. I like static checking *a lot*, but the flexibility
and extensibility of Lisp seems nicer than the rigor of SML, so
you're probably right. Adding static rules for every new macro
might indeed be a PITA; sometime (like in 10 years) I might
experiment with some static checking... First I gotta get that
PCL book and walk the Lisp way; should arrive any day now!
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
Brian Downing
William Bland <new...@abstractnonsense.com> wrote:
> Exception that it might throw. I had to admit that I knew of no facility
> for declaring the conditions that might be signalled by a Lisp method or
> function. Is there such a mechanism? If not, are there good reasons why
> it would be an unnecessary or undesirable feature?
Another point not yet raised is that one could, if one wanted[1], write
a PEDANTIC-DEFUN that scanned its body for handlers and calls to other
PEDANTIC-DEFUN'd functions, and did the same "exception safety"
computations as Java does.
This, of course, requires that you DEFUN things in order and not change
them dynamically to throw more or less exceptions.
[1] You don't want to, though.
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
Stefan Nobis
> In Java you may specify, as part of a method's signature, the
> classes of Exception that it might throw.
Let me add why this is undesirable in Java, too: It clutters code
very much. Often you write code deep in a library that may throw
an exception, but handling the exception gracefully is only
possible at near toplevel. So in Java you have to pass this
exception by hand through all of the call chain! That's a burden,
not a gift.
Other static typed languages like C++ don't do this. In C++ it is
*possible* to declare which exception a function may throw, but it
is not neccessary to catch/declare them in all calling functions,
so you don't have to propagate the exception manually.
Java has nice typechecking and much of that is really helpful not
only to beginners. But i think the explicit declaration *and* the
rule to catch or declare every execption that a called function
may throw, is really braindead.
--
Stefan.
Christophe Rhodes
> Kenny Tilton wrote:
>> The compiler can never guarantee my code is correct, so wasting time
>> jumping thru its hoops is undesirable.
>
> Quite true in general, but sometimes it might remind you that you
> forgot to catch that new exception you added to some code. From Bruce
> Eckel's weblog (IIRC) I gathered that in dynamic languages these
> errors are uncovered by good testing instead.
And in Lisp, the absence of an explicit handler is not necessarily a
problem, for several reasons.
Firstly, not all conditions are errors, or even serious conditions:
warnings, storage-conditions, compiler notes, and the like quite
naturally don't always get handled.
Secondly, even in the case of serious conditions, it isn't necessary
to handle them all, particularly during development: unlike
environments where an unhandled exception leads to abrupt termination
of everything, in Lisp you end up in a debugger, with
implementation-defined but generally useful attributes -- often
including the ability to treat the condition as though it had been
handled, and continue computing from certain recovery points (such as
the start and end of the current frame) as well as being able to
choose restarts interactively.
Christophe
Thomas F. Burdick
> Firstly, not all conditions are errors, or even serious conditions:
> warnings, storage-conditions, compiler notes, and the like quite
> naturally don't always get handled.
>
> Secondly, even in the case of serious conditions, it isn't necessary
> to handle them all, particularly during development: unlike
> environments where an unhandled exception leads to abrupt termination
> of everything, in Lisp you end up in a debugger, with
> implementation-defined but generally useful attributes -- often
> including the ability to treat the condition as though it had been
> handled, and continue computing from certain recovery points (such as
> the start and end of the current frame) as well as being able to
> choose restarts interactively.
And to beat this horse a little more, "the debugger" is a program. By
default it probably prompts the user for input, but on a server
running in production mode, it more likely writes some info to a log
file and gets back to the server's toplevel.
Pascal Costanza
> William Bland wrote:
>
>> I was discussing Java Exceptions vs. Lisp conditions with a colleague
>> recently, and he agreed that Lisp's conditions have several points in
>> their favour. He did raise one point though, that I didn't know the
>> answer to.
>>
>> In Java you may specify, as part of a method's signature, the classes of
>> Exception that it might throw. I had to admit that I knew of no facility
>> for declaring the conditions that might be signalled by a Lisp method or
>> function. Is there such a mechanism? If not, are there good reasons why
>> it would be an unnecessary or undesirable feature?
>
> Others have explained why it is inappropriate for Lisp, so let me take a
> crack at undesirable. Why do I have to specify the conditions my code
> may spawn? And change it when I change what the function actually
> throws? Where did this housekeeping burden come from? Oh! Some genius
> thinks the compiler can make my code Correct, if only I spend half my
> time jumping thru compiler hoops.
>
> The compiler can never guarantee my code is correct, so wasting time
> jumping thru its hoops is undesirable.
>
> This, as others did suggest, is just another sampling from the static vs
> dynamic trade-off, long ago decided in favor of dynamic.
;)
Static checking can lead to more errors instead of less. How often do
Java programmers write this:
try {
...
} catch (Exception e) {
// deal with this later
}
This is especially bad because the unchecked RuntimeException class is a
subclass of Exception, so now you catch everything, including
NullPointerException and DivisionByZeroException etc., and they all are
just brushed under the carpet. This makes testing your code very hard.
Similar examples can be found for other kinds of static checking,
including static type checks.
(And in order to prevent flames, there are of course better static type
systems than that of Java... ;)
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Thomas Gagne
they don't need to be specified on the signatures.
Stefan Nobis wrote:
<snip>
Gisle Sælensminde
> In Java you may specify, as part of a method's signature, the classes of
> Exception that it might throw. I had to admit that I knew of no facility
> for declaring the conditions that might be signalled by a Lisp method or
> function. Is there such a mechanism? If not, are there good reasons why
> it would be an unnecessary or undesirable feature?
I consider this a misfeature of Java. Consider that you have written an application,
and want to add a feature by integrating an existing library. A function in this
library reads a configuration file, and since this file might not exist, it throws
IOException. This must either be catched at the call place, or the calling code
must also change the signature to throw the same exception. If you do that you will
get a cascading effect, since all functions calling this function must handle the
exception or change the signature. Now you have a nasty cascading effect, and the
result is that you often see that exceptions are silently ignored in java code.
This does of cause defeat the purpose of having exceptions in the first place,
but you cannot easily change the whole static callgraph above the function in a
several 100.000 lines program.
If this file is missing, the appropirate place to handle may be by asking the user,
but the static declaration of exceptions in java makes that difficult if you did
not think of at designtime, and makes it harder to change big programs.
In an earlier job, we soleved this by introducing CompanyNameException, that wraped
the original exception, so we could resolve it at an appropirate level
without changing the function signatures in the code, but this is really to
circumvent the feature.
--
Gisle Sælensminde, Phd student, Scientific programmer
Computational biology unit, University of Bergen, Norway
Email: gi...@cbu.uib.no | Complicated is easy, simple is hard.
William Bland
>
> Static checking can lead to more errors instead of less. How often do
> Java programmers write this:
>
> try {
> ...
> } catch (Exception e) {
> // deal with this later
> }
>
I've actually seen people do worse than this - they've caught Throwable,
which means masking even things like OutOfMemoryError!
Thanks for all the replies - I hadn't been thinking of this issue as part
of the static vs. dynamic thing before, but now I can see that it really
is.
Best wishes,
Bill.
Pascal Costanza
To be very clear here, the specific problem that RuntimeExceptions are
caught here is caused by RuntimeException being a subclass of Exception
and could have been fixed by doing it the other way around. (But that's
only a fix for this particular issue.)
Antonio Menezes Leitao
> gi...@kaktus.ii.uib.no writes:
>>A function in this library reads a configuration file, and
>>since this file might not exist, it throws IOException. This
>>must either be catched at the call place, or the calling code
>>must also change the signature to throw the same exception.
>
> The signatur would only have to be changed for certain kinds
> of exceptions, not for "runtime exceptions". So, if you do not
> want the signature to change, but still want to throw an
> exception, you might rethrow any exception as a runtime
> exception.
>
> For example, I wrote:
>
> static java.io.PrintStream newOutPrint()
> { java.io.PrintStream outPrint = null;
> java.lang.Exception ex = null;
> final java.io.FileDescriptor outDescriptor =
> java.io.FileDescriptor.out;
> try
> { java.io.FileOutputStream outStream =
> new java.io.FileOutputStream( outDescriptor );
> try
> { outPrint = new java.io.PrintStream( outStream, false, "UTF-8" ); }
> catch( java.io.UnsupportedEncodingException e ){ ex = e; }}
> catch( java.lang.SecurityException e ){ ex = e; }
> if( ex != null )throw new java.lang.RuntimeException( ex );
> return outPrint; }
and your code becomes much harder to write and read. Without the
try-catch to transform checked exceptions into unchecked exceptions,
your code is just:
static java.io.PrintStream newOutPrint() {
final java.io.FileDescriptor outDescriptor = java.io.FileDescriptor.out;
java.io.FileOutputStream outStream = new java.io.FileOutputStream( outDescriptor );
return new java.io.PrintStream( outStream, false, "UTF-8" );
}
[Obviously, we can make it even simpler:
static PrintStream newOutPrint() {
return new PrintStream(new FileOutputStream(FileDescriptor.out), false, "UTF-8");
}
]
IMHO, your example is a simple proof that checked exceptions are a bad
idea.
Checked exceptions are so annoying that I decided to include in my
Lisp to Java compiler the automatic inference of checked exceptions.
This means that you can write:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defun read-data ()
(let ((f (new 'file "data.dat")))
(let ((data (new 'data-input-stream (new 'file-input-stream f))))
(unwind-protect
(princ-to-string (read-int data))
(close data)))))
(defun make-alias (name/string)
(in (the java.rmi.naming)
(let ((remote (lookup name)))
(bind (concatenate 'string name "-alias")
remote))))
(defun make-alias-from-file-data ()
(make-alias (read-data)))
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
and it translates it into:
//////////////////////////////////////////////////////////////////////
public static String readData() throws IOException {
File f = new File("data.dat");
DataInputStream data = new DataInputStream(new FileInputStream(f));
try {
return "" + data.readInt();
} finally {
data.close();
}
}
public static void makeAlias(String name)
throws AlreadyBoundException, RemoteException,
MalformedURLException, NotBoundException {
Remote remote = Naming.lookup(name);
Naming.bind(name + "-alias", remote);
}
public static void makeAliasFromFileData()
throws NotBoundException, AlreadyBoundException, IOException {
makeAlias(readData());
}
//////////////////////////////////////////////////////////////////////
Note that the "function" makeAliasFromFileData doesn't throws
RemoteException (that is thrown by the called "function" makeAlias)
because it already throws its superclass IOException (that is thrown
by the other called "function" readData).
In this way, your code is easier to write (for Lispers) and easier
read (for Java programmers) and the throws clause becomes
documentation :-).
I presume it wouldn't be hard for those clever IDEs such as Eclipse to
automatically do the same. Maybe they already do it.
António Leitão.
Adam Connor
<tga...@wide-open-west.com> wrote:
>I remember Bruce Eckels suggesting throwing RuntimeExceptions because
>they don't need to be specified on the signatures.
Java's whole exception system is problematic. As far as I know, the
theory is that "checked" exceptions are those that the user should
always handle, whereas "unchecked" exceptions (RuntimeExceptions) are
for exceptions that cannot be profitably handled, e.g.,
NullPointerException. In practice, however, this involves the library
writer deciding what the library user can handle -- which is
impossible. Hence, SQLException is "checked", but many applications
simply wrap it in a RuntimeException and throw it upwards, since they
have no way to deal gracefully with database failures.
On top of that, the whole scheme interacts poorly with frameworks such
as Servlets. A servlet cannot throw arbitrary checked exceptions, so
any such exception that is not handled must be wrapped in another
exception and thrown upward. Etc.
In general, I regard checked exceptions as an experiment that failed.
--
adamnospamaustin.rr.com
s/nospam/c\./
Kent M Pitman
The CL condition system took this from the Lisp Machine condition system.
I've spent my career thinking about, teaching about, and using the condition
system and I absolutely believe that it was the right decision.
Moreover, I have been frequently hampered by the Java model in the
comparatively short time during my career that I've done serious Java
programming.
It introduces a problem into Java that if any caller signals a new kind of
error that its immediate callers do not want to handle, the entire morass
of callers is forced into dealing with it.
Often, as a result, Java programs I've seen have taken to using the I/O
system to pass information that is ripe for condition processing but that
is just too painful to observe. I've sometimes said that if you wanted to
cripple Java utterly, you could continue down the bad path they started down
and insist that they should make 'input/output' part of the type signature,
too, so that you wouldn't be able to escape the obviously intentional yet
agonizingly painful stranglehold of declaration by switching from a condition
to mere typeout.
There is sometimes a place for declaring such things. During standardization
of Common Lisp, I advocated that perhaps we should have had fields in the
definitons of the functions that said not only how they dealt with conditions
but what I/O or consing behavior or even algorithmic complexity each function
must not, might, or must have. It's often useful to users to know these
things WHERE THEY ARE KNOWN and WHERE KNOWING THEM IS A GOOD IDEA. But it's
bad for them to be promised merely as a matter of practice as if exposing
this info was always good, and as if relying on it were always good.
Consider a simple case: I have a function that computes a relatively complex
math or other analysis function. I realize it's got a problem and want to
take it out of service. I know a workaround is to task some oracle available
on the network. Slower, perhaps, because it does network I/O, but good.
Now consider:
(a) Why should I have to recompile my entire system to handle
network unavailable errors?
Bonus points:
(b) Why shouldn't I be able to have handled network unavailable errors
around a program that didn't document it was going to talk to the
net but that conceivably might have to.
Here's another case: Suppose I have limited storage, and so I implement
a database as:
(defun put-data (key value)
(format *desk-output* "~&Please remember the value of ~S is: ~S~%"
key value))
and
(defun get-data (key)
(format *desk-output* "~&What was the last value I gave you for ~S?~%"
key)
(read *desk-input*))
These programs might get I/O errors or other odd problems in what you thought
was a program that did no I/O.
I've picked these because they are very blatant examples, but real examples
are often more subtle. My real point is that you can often tell a lot about
the implementation of something by the exceptions it signals. But, moreover,
you can confine the possible set of implementations by limiting the exceptions.
Going back to the original design decision, the real reason that the
condition system should stand on the side and not be used for dispatch
is that you just don't know which condition handlers might be relevant.
It's very hard in the most complex of programs in an environment based
on dynamic data interchange, not static typing, to assume that you have
full world knowledge. AND, further, it's an illusion to claim that a
static type system can know either.
All you can do by static typing is limit the usefulness of your
program to what knowledge you had at the time you compiled it. Lisp
is designed to be able to, at runtime, allow programs to recognize
data they did not expect and to reason about it. So that means that if
you ever expect to have a new idea and to have your program confront it
after compilation, you'd better be programming in Lisp and not in static
languages because, of necessity, since a static program cannot represent
an idea newer than its design, it can't recognize one either. Every
new round peg either goes in through the square peg opening you wrote
originally or else is rejected as bad data. In a world where programs
must operate 24/7 continually confronting new protocols, data, concepts,
etc., that just isn't sufficient. In short, if new ideas are good ideas,
it follows from what I've said that a static program is provably incapable
of representing, and hence of recognizing, a good idea...
(Now people will follow with discussions of wrappers that allow you to
represent non-data as data of a different, 'foreign' kind that has to
be handled specially. But now you're talking about either 'separate
but equal' or else 'meta-languages without first-class access to the
underlying language'. Lisp, by contrast, offers fluid access back and
forth between its reflective parts and its underlying parts, so that
you can reflect out to the level of probing symbol names, class
structures, etc. or you can call down to reassemble things into
programs and even dynamically compile and use them without leaving the
runtime universe... Expressionally, all that is missing in most static
languages. It's barely there in some ways in Java, but it's irritatingly
painful to access. Java is an "implementational", not an "expressional"
language, to use the partition I often do.)
Kent M Pitman
The design of the CL declaration facility is about making this subtle
distinction between allowing you to say what you want, rather than
requiring you to say what some person without all appropriate context
thought you ought. I'd not oppose a declaration that said "I expect to
signal these conditions" so that a compiler could mention to the caller
that they hadn't handled them all. But I wouldn't want the compiler to
make the program not work (i.e., either not compile or else sabotage it to
keep it from running) because
(a) the debugger (the interactive error handler) counts as one of
the handlers and the interactive user might know what to do
(b) there might be later code loaded that wraps still more handlers
around, not known at the time of compilation
(c) the program might be getting used in a way that doesn't lead to
the signaling of those errors
(d) independent compilation of modules might mean that either part of
the program could get changed to fix the problem--it's a shared
problem, not a problem in the caller or the callee.
I suspect there are other reasons as well. These are just the ones that
come easily to mind.
Jim
> ...
> Often, as a result, Java programs I've seen have taken to using the I/O
> system to pass information that is ripe for condition processing but that
> is just too painful to observe. I've sometimes said that if you wanted to
> cripple Java utterly, you could continue down the bad path they started down
> and insist that they should make 'input/output' part of the type signature,
> too, so that you wouldn't be able to escape the obviously intentional yet
> agonizingly painful stranglehold of declaration by switching from a condition
> to mere typeout.
Actually Java does implement exactly that feature, namely the
SecurityManager. The granularity however is class (or package) rather
than method (also the checking is dynamic rather than static). The
ability to have fine-grained control over what code can do (with the
notable omission of time or space) is one of the best things about Java.
Alas security policies are abused even more than exceptions by the
vast majority of Java coders.
And for those folks sending Java condition info to i/o, I direct their
attention to Apache Log4j.
Jim
Jim
> My code is longer than necessary because I have created it
> combining several coding patterns in my brain (similar to what
> your translator might do in a computer).
>
> It would suffice to write (untested):
>
> static PrintStream newOutPrint() { try
> { return new PrintStream
> ( new FileOutputStream( FileDescriptor.out ), false, "UTF-8" ); }
> catch( Exception e ){ throw new RuntimeException( e ); return null; }}
If tested you would discover the addition of the "return null;" would
fail to compile as that code is unreachable.
Jim
Pascal Costanza
> Antonio Menezes Leitao <a...@aleph.local> writes:
>
>>r...@zedat.fu-berlin.de (Stefan Ram) writes:
>>
>>>static java.io.PrintStream newOutPrint()
>>>{ java.io.PrintStream outPrint = null;
>>> java.lang.Exception ex = null;
>>> final java.io.FileDescriptor outDescriptor =
>>> java.io.FileDescriptor.out;
>>> try
>>> { java.io.FileOutputStream outStream =
>>> new java.io.FileOutputStream( outDescriptor );
>>> try
>>> { outPrint = new java.io.PrintStream( outStream, false, "UTF-8" ); }
>>> catch( java.io.UnsupportedEncodingException e ){ ex = e; }}
>>> catch( java.lang.SecurityException e ){ ex = e; }
>>> if( ex != null )throw new java.lang.RuntimeException( ex );
>>> return outPrint; }
>>
>>static PrintStream newOutPrint() {
>> return new PrintStream(new FileOutputStream(FileDescriptor.out), false, "UTF-8");
>>}
>
> combining several coding patterns in my brain (similar to what
> your translator might do in a computer).
>
> It would suffice to write (untested):
>
> static PrintStream newOutPrint() { try
> { return new PrintStream
> ( new FileOutputStream( FileDescriptor.out ), false, "UTF-8" ); }
> catch( Exception e ){ throw new RuntimeException( e ); return null; }}
We're still not there:
- You don't want to catch RuntimeException and wrap it in another
RuntimeException. That makes other code unnecessarily complex.
- RuntimeException doesn't take another exception as a parameter. Java
has a specific exception class for wrapping checked exceptions.
The full code would be this:
static PrintStream newOutPrint() {
try {
return
new PrintStream(
new FileOutputStream(FileDescriptor.out), false, "UTF-8");
} catch (RuntimeException e) {
throw e;
} catch (Exception e) {
throw new UndeclaredThrowableException(e);
}
}
...and there's no macro facility to wrap this nonsense.
Another funny exception class in Java is the
UnsupportedOperationException. If you are required to implement a method
because of a declaration in an interface or an abstract superclass, but
really cannot or don't want to, the correct way to implement a stub for
it is this:
public int dontCareYet(...) {
throw new UnsupportedOperationException("dontCareYet");
}
Other alternatives, like returning a default value (0?), or simply doing
nothing in the case of void methods are incorrect and/or don't behave
well in test suites. The throw of an "unsupported operation exception"
is what dynamically typed languages do by default, though...
Pascal Costanza
> Pascal Costanza <p...@p-cos.net> writes:
>
>>RuntimeException doesn't take another exception as a parameter.
>
>
> I regard the following constructor of RuntimeException
> as one taking another exception as an argument:
>
> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/RuntimeException.html#RuntimeException(java.lang.Throwable)
OK, I see. They have added that in JDK 1.4 and I have checked against
the JDK 1.3 docu.
Kent M Pitman
> Kent M Pitman wrote:
>
> > ...
> > Often, as a result, Java programs I've seen have taken to using
> > the I/O system to pass information that is ripe for condition
> > processing but that is just too painful to observe. I've
> > sometimes said that if you wanted to cripple Java utterly, you
> > could continue down the bad path they started down and insist that
> > they should make 'input/output' part of the type signature, too,
> > so that you wouldn't be able to escape the obviously intentional
> > yet agonizingly painful stranglehold of declaration by switching
> > from a condition to mere typeout.
>
> Actually Java does implement exactly that feature, namely the
> SecurityManager. The granularity however is class (or package)
> rather than method (also the checking is dynamic rather than
> static). The ability to have fine-grained control over what code
> can do (with the notable omission of time or space) is one of the
> best things about Java.
I don't think anything I said is inconsistent with this statement,
which I largely agree with.
But at the same time, it's one of the reasons I classify Java as a
"good, high-level, assembly-language". It's the kind of 'connective
pipe' I am fine with having underly a good solid system as the
language and platform into which things compile. (I might or might not
choose it personally, mostly depending on the application, but I don't
rule it out.) At the same time, the cost in bookkeeping due to the
type signature thing is so high that it's not the sort of thing I can
bear to recommend to people as a first-line choice of what level to
program directly in. Compilers are good at bookkeeping, so I don't
mind them doing it.
Kaz Kylheku
William Bland wrote:
> I was discussing Java Exceptions vs. Lisp conditions with a colleague
> recently, and he agreed that Lisp's conditions have several points in
> their favour. He did raise one point though, that I didn't know the
> answer to.
>
> In Java you may specify, as part of a method's signature, the classes
of
> Exception that it might throw. I had to admit that I knew of no
facility
> for declaring the conditions that might be signalled by a Lisp method
or
> function.
That's because Lisp avoids the silly design of conditions being
signaled by a function. Conditions are signaled by invoking the API
that signals them, and are not bound to any function.
When a condition is signaled, that does not initiate unwinding. The
block in which the signaling is invoked does not terminate! So nothing
destructive is going on which requires containment. Merely, the dynamic
environment is being searched for a handler. But that handler is
invoked as a function.
Lisp condition handling is a lot more like machine-language exception
handling. When a machine encounters an exception such as an illegal
instruction opcode, division by zero or page fault, does unwinding
happen? Heck no. Rather than information being thrown away, information
about the CPU state is stacked! And then a handler is invoked as a
chained function call through the exception or interrupt vector table.
The interrupt handler can in fact cause the original code to be
restarted.
> Is there such a mechanism? If not, are there good reasons why
> it would be an unnecessary or undesirable feature?
Yes. The same reasons why you don't declare the return type of a
function, or the types of its parameters and so on. It's because Lisp
is a run-time-typed dynamic language, whose programs can be extended at
run-time with new code and data types.
Declaring what may or may not be thrown is basically an idiot's way of
dealing with his emotions of mistrust against advanced error handling.
It expresses a longing to go back to return-value-based error handling,
where you know exactly what happens because every function in a chall
chain is responsible for computing its error-indication, which follows
a hard-coded vocabulary of codes. It's basically a way of ``selling''
exception handling to crusty old programmers who have used return
values all their lives, and want exception handling to just be a
syntactic sugar for the same designs they are used to.
When you require another programmer to declare all of the error
conditions that may be returned by a function, you are essentially
saying: exception handling is nice within any given subsystem, just
don't throw anything unexpected my way across the interface boundary.
Let's agree on all possible conditions in your code today, and then
when any layers below you create unexpected problems in the future,
that is entirely your problem. You must obey the original interface
contract with respect to me, and ensure that you compensate for any new
misbehavior of the lower layers in your own domain, so that I don't see
any problem in mine!
In other words, when you see a function like this:
void foo () throws (X, Y, Z) { ... }
it might as well be written like this:
// returns fixed vocabulary of error codes
int foo () { ... }
so that you can then write:
// Let's have exception handling *within* our module, for
convenience
switch (foo()) {
case ERROR_X: throw X();
case ERROR_Y: throw Y();
case ERROR_Z: throw Z();
default: throw OopsieLowerLayerMisbehavior();
}
Since foo() is responsible for handling all errors going through it and
ensuring that only X, Y and Z can come out, it can just as easily
indicate errors with return values, except for the additional piece of
labor that the caller has to go through to write the switch statement
to convert the values to exceptions.
This is exactly what you would do if foo() is some kind of low level
RPC going between process or machine boundaries, where exceptions are
not supported directly, only arguments and returns that are simple data
types.
But main advantage of a condition system is that intermediate functions
in a calling chain do not have to be aware of what errors pass through
them! YOu can create protocols between distant layers of code without
the involvement of any incidental intermediate layers.
If I'm using MAPCAR, and the function that is processing the list
elements raises a condition, I want that to pass transparently through
MAPCAR. I can't recompile MAPCAR to give it permission to pass through
my newly defined condition types.
You can extend an existing system with some new piece of low-level
code, and some new piece of high level code, which handle errors
between each other thorugh the intermediate plumbing --- plumbing that
you don't even have to recompile!
Pete Kirkham
> - You don't want to catch RuntimeException and wrap it in another
> RuntimeException. That makes other code unnecessarily complex.
don't get this problem:
public static PrintStream newOutPrint () {
try {
return new PrintStream(
new FileOutputStream(FileDescriptor.out), false, "UTF-8");
} catch (UnsupportedEncodingException e) {
throw new RuntimeException(e);
}
}
Though in real life I often pass the exception on to a condition handler
class, that would log it or launch a debugger as appropriate. That does
require an extra loop if you want the code to retry the operation:
for(;;) {
try {
return new PrintStream(
new FileOutputStream(FileDescriptor.out), false, "UTF-8");
} catch (UnsupportedEncodingException e) {
Conditions.handleOrWrap(e);
}
}
Which will retry until it succeeds, or handleOrWrap throws a runtime
exception.
(which gets into another issue with Java and method dispatch, as you do
want to alter the handler behaviour based on the type of the exception
thrown)
> - RuntimeException doesn't take another exception as a parameter.
It does in version >= 1.4, see
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/RuntimeException.html
>Java has a specific exception class for wrapping checked exceptions.
Java has a very specific exception class for wrapping checked exceptions
which have been thrown by reflective invocation via the JVM's proxy
implementation, from methods where the invoked method throws exceptions
that are not handled by the invoking method. Using it here would be
inappropriate, as there are no reflective proxies involved. How you are
expected to wrap exceptions in Java is described in the API documents
for Throwable, see
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Throwable.html
Pete
Peter Schuller
happens to be pertinent to the problem I am currently experiencing.
> When you require another programmer to declare all of the error
> conditions that may be returned by a function, you are essentially
> saying: exception handling is nice within any given subsystem, just
> don't throw anything unexpected my way across the interface boundary.
> Let's agree on all possible conditions in your code today, and then
> when any layers below you create unexpected problems in the future,
> that is entirely your problem. You must obey the original interface
> contract with respect to me, and ensure that you compensate for any new
> misbehavior of the lower layers in your own domain, so that I don't see
> any problem in mine!
While I am in no way advocating checked exceptions, I do find the above
stance somewhat puzzeling; at least if I am interpreting this correctly.
I have written a lot of Java code, and is therefore used to the way exceptions
are used and documented in the Java world. But am always on the lookup for new
interesting languages to learn. Along the way I fell in love with
Smalltalk, which in turn led me (through discussions on comp.lang.smalltalk)
to both Lisp and Ruby. By far, I am the most excuited about Lisp, and
I have been intending to start writing some 'significant' applications
in Lisp for some time. I find Lisp light years head of Java in terms of
general flexibility and attractiveness.
But 'significant' means real practical stuff. And in real applications,
error handling is very important. A networking server must be able to deal
with sockets errors without terminating; a mail user agent must be able
to differentiate between expected real-life problems (i.e., networking
issues) and internal bugs. Unfortunately, I have personally found the
error handling situation lacking in Lisp (aswell as Ruby and Smalltalk). It
is not that the condition system in and of itself has a problem; it is rather
how it is used and documented.
Specifically, the problem is that the conditions signaled by a function is
almost never documented! I am not talking about every single possible problem
that might occurr as a result of internal library bugs or bugs in calling
code. But the *EXPECTED* conditions that *ARE* going to happen in real life.
In this regard, I must say that I find Java exemplary. Given a function that
operates on a stream, or a file, or any kind of external resource, there is
documentation as to how these error conditions are handled (be it by returning
some special value or by throwing an exception). This is information I, as someone
writing calling code, MUST know in order to write robust and correct code.
Consider this fictional pseudo-Java code that is part of a fictional RDBMS backed
lookup server similar to LDAP (or POP3 or whatever):
private void handleClient(Socket socket) {
try {
BufferedReader bin =
new BufferedReader(new InputStreamReader(socket.getInputStream()));
BufferedWriter bout =
new BufferedWriter(new OutputStreamWriter(socket.getOutputStream()));
... authenticate, parse a request
StuffBeingLookedUp stuff;
try {
stuff = myDatabase.getStuff(...);
} catch (SQLException e) {
... log the database problem
bout.write("-ERR internal server error\n");
bout.flush();
return;
}
bout.write("+OK data follows\n");
... write data
bout.flush();
} catch (IOException e) {
... possibly log the problem depending on debuglevel
} finally {
try {
socket.close();
} catch (IOException e) {
/* Assuming the code above has already flush():ed in the successful case,
* just ignore it because the problem is either irrelevant or has already
* been logged.
*/
}
}
}
A couple of things to note:
* The code is able to differentiate between I/O errors having to do with the
communication with the client, from database related errors caused by
the attempt to access the database. In ths context of the server, these are
logically quite different errors and must be treated differently.
* If the SQLException was thrown due to some underlying I/O problem, this information
is not lost; in fact it would be reported as the causal exception in a stacktrace. But
at this level in the calling code, all that is relevant is that it is a database
errors; we don't care whether the database is remote, local or in-memory or what
possible errors the implementation might encounter. Thus we expect the database
API (JDBC and the JDBC driver) to emit only SQLExceptions and subclasses thereof.
Note that someone made a very good point in this thread about how the Common Lisp
condition system allows two components to communicate via conditions, even though
the intervening code has no knowledge or support of said communication. In this case
we could have the calling code (the server) co-operate with the JDBC driver IF this
was desirable. But in cases where it is NOT desirable, we instead run into the problems
below.
How do I do this in Lisp? Consider (and *PLEASE* correct me if I am misstaken on anything):
* Reading the CLHS, the spec is only concearned with type errors when it comes to the
I/O functions (read-line, read-byte, write-byte, etc). The exact condition signaled in
case of a problem is entirely implementation dependent. Thus, if I am to be portable
I *cannot* do what the Java code does above, unless i go out and investigate the
situation for each and every Common Lisp I might want to support.
* Taking sbcl as an example, I have uncovered no documentation as to what conditions
are signaled by the various functions in sb-bsd-sockets (except nothing to the effect
of "might signal some kind of condition"). Looking at the source code I can figure it
out, but even then (if I remember correctly, and I might not because this was a while
ago) the exception hierarchy is mostly concerned with mirroring the possible return
values of underlying syscalls, rather than offering a categorical hierarchy (i.e.,
differentiating "connection failed" from "some error happened during normal I/O
on an open connection", etc - although in THIS case this is not offered by Java
either).
* If after having looked at the sb-bsd-sockets source code I make my code correct
for the case of sbcl, (1) I am still only supporting sbcl, and (2) I have no clue
how "official" the set of signalled exceptions is, or whether it might randomly
change in a future release.
I have experienced the same thing with other Lisp variants (I've looked at a number of
Scheme:s for example). In the case of Scheme the error handling *mechanisms* aren't even
all that useful in some cases; and in the cases where the *mechanism* is powerful "enough"
for my purposes, the documentation offers *no* clue as to actual error conditions signalled
by the library. I haven't gone so far as to inspect the source code of all these Schemes
I've looked at. The same goes for portability API:s like CLOCC and such - no "official"
error signaling seems to exist, and who knows what might happen on different implementations.
A cursory look at some of the source gave me the impression that's it is not just a
documentation issue, but that the issue really isn't tackeled, and code will result in
different conditions on different platforms (CL implementations).
Am I the only one who feel this is a problem? Have I missed something? How do people
solve this problem when writing real programs in Lisp?
For a while I have toyed with the idea of making my first "real" project a "Common Lisp
Common Library" of sorts; which would be a portable library with various functionality
that is often very practical, and which would have properly documented error conditions.
It would also try to present a "Lisp:ish" API rather than "superficial" wrappers around
various POSIX API:s. In short, my goeal would be to be able to write code similar to
the following and have it be portable (excuse any broken indentation and the fact that
it probably wouldn't even compile):
(defun listen-loop (socket)
(handler-case
(loop (start-thread #'handle-client (accept socket)))
(io-error (ioe) (log-error ioe)))
(defun handle-client (stream)
(unwind-protect
(handler-case
(progn
... authenticate and parse request
(handler-case
(let ((stuff (get-stuff client-request)))
(write-line stream "+OK data follows")
... write data)
(database-error
(dbe)
(progn
... log the problem
(write-line stream "-ERR internal server error"))))
(flush stream))
(io-error (ioe) (log-error ioe)))
(handler-case (close stream) (io-error () nil))))
(Things like (with-open-stream ...) to guarantee that the stream is
closed would clean that up a bit)
Does anybode agree with me, even a little? Should I just not bothering doing
something like this because nobody would be interested anyway?
--
/ Peter Schuller, InfiDyne Technologies HB
PGP userID: 0xE9758B7D or 'Peter Schuller <peter.s...@infidyne.com>'
Key retrieval: Send an E-Mail to getp...@scode.org
E-Mail: peter.s...@infidyne.com Web: http://www.scode.org
Christopher C. Stacy
space of possible conditions is not well elaborated, both in terms
of what all the conditions are, and which functions might signal what.
The ANSI standard doesn't have very much to say about that.
Certainly there are lots more conditions than are mentioned in there.
But it's implementation-dependant on what those might be.
> In this regard, I must say that I find Java exemplary. Given a function that
> operates on a stream, or a file, or any kind of external resource, there is
> documentation as to how these error conditions are handled (be it by returning
> some special value or by throwing an exception). This is information I, as someone
> writing calling code, MUST know in order to write robust and correct code.
That should be well documented by the Lisp that you are using.
If it's not, that's a vendor quality issue (and you should get
the vendor to do better, or change vendors I guess.)
> Consider this fictional pseudo-Java code that is part of a fictional
> RDBMS backed lookup server similar to LDAP (or POP3 or whatever):
ANSI Common Lisp doesn't define any interfaces to any RDBMS,
or for that matter to any network, or much of anything, really.
It just barely even defines any conditions for file systems.
But when you select a Lisp library (which may or may not be portable,
so please make sure to find one that meets your requirements in that
respect), it should fully document the conditions that can happen.
> A couple of things to note:
>
> * The code is able to differentiate between I/O errors having to do with the
> communication with the client, from database related errors caused by
> the attempt to access the database. In ths context of the server, these are
> logically quite different errors and must be treated differently.
Lisp can do that.
> * If the SQLException was thrown due to some underlying I/O problem, this information
> is not lost; in fact it would be reported as the causal exception in a stacktrace. But
> at this level in the calling code, all that is relevant is that it is a database
> errors; we don't care whether the database is remote, local or in-memory or what
> possible errors the implementation might encounter. Thus we expect the database
> API (JDBC and the JDBC driver) to emit only SQLExceptions and subclasses thereof.
Lisp can do that.
The condition object that the handler receives contains
the detailed information necessary to make those distinctions.
The structure of of the condition handlers should make sure
that you see the proper conditions. More about that, below.
> How do I do this in Lisp?
[The spec only defines a few conditions, tried SBCL but it didn't
document things well enough, tried the sb-bsd-sockets library but
had to read the source code and guess what the supported API is,
and it's SBCL=specifc anyway.]
Maybe you should consider using a Lisp system that is better
documented than SBCL?
My favorite Lisp system, which is unfortunately not available for
the machines that you have, shipped with a stack of manuals that
was over 4 feet high (and was also online as hypertext in the IDE).
It documented all these things really well. That was 20 years ago.
These days, I use both Lispworks and some of the free Lisp systems.
I find their documentation to be adequate, but that certainly doesn't
mean that it's good enough for you. I haven't seen the documentation
from Franz, but I bet it's really good. I would suggest approaching
your vendor on this issue.
> I have experienced the same thing with other Lisp variants
> (I've looked at a number of Scheme:s for example).
Well, anyone here will tell you that Scheme is evil and you
shouldn't be using it for Real Programs. Where's your Common Sense, man?
But seriously, your problem there sounds mainly the same as with the
Common Lisp implementations and libraries: lack of documentation.
> Am I the only one who feel this is a problem? Have I missed something?
> How do people solve this problem when writing real programs in Lisp?
They either think it's good enough, or they are picking better
libraries (perhaps from the commercial vendors) than you are,
or they are rolling their own portable compatability libraries.
I do all three of those things.
It's probably just not very easy to figure out how to make those
decisions. In Java, it's easier because it's pretty much one-stop
shopping, or at least you know which other major outlets you need
to visit. In Perl, there's CPAN, and there's also lots of marginal
crap that could confuse you. In Lisp, the situation is worse --
about the same as in C, I guess. It's not clear where to look,
who to trust, what you're going to get, etc.
Your model pseudo-program just looks to me like a lot of the code
that I write; I'm not sure why you think you can't write that.
Maybe you are missing something technical about the way that the
condition system works. I never saw you use HANDLER-BIND, which
is more dynamic than HANDLER-CASE. Do you realize that you can
catch conditions, look them over, decide not to handle them and
allow some higher-level caller the chance? Or that you could
handle them by deciding to signal some other condition?
Your complaint about not being able to distinguish one IO error
from another suggests that you might be confused about that.
Your RDBMS APL can catch an IO condition (eg. STREAM-CLOSED),
examine the condition object in detail, and then effectively
turn it into some other condition (eg. RDBMS-SERVER-FAILURE).
> Does anybode agree with me, even a little? Should I just not
> bothering doing something like this because nobody would be
> interested anyway?
I don't think that you are wasting your time, in general.
I suspect that many people have written libraries of the
sort you propose. They might not choose to release them.
But you ought to explore what's out there a little more
before you set off writing your own.
I would start by looking at the libraries that have been graciously
contributed from Franz (and made portable with additional work by
spirited volunteers) . Those seem to be pretty high quality.
For questions about the condition system per se, use this thread.
To ask about libraries for specific purposes (eg. network, DB, IO, etc.)
you should probably start a new thread for each of them, so as to
keep the conversations trackable and for easier indexing.
Christopher C. Stacy
> Your RDBMS APL can catch an IO condition (eg. STREAM-CLOSED),
TYPO[TYPO {iota} 'L'] {assign} 'I'
(But it's just not the same without the funny glyphs...)
Peter Schuller
> If it's not, that's a vendor quality issue (and you should get
> the vendor to do better, or change vendors I guess.)
Well, it seems to be the case in general - at least for free Lisps. Yet I
gather people *are* using these free Lisps for real programs.
But I am not so much interested in pointing out flaws in the implementation,
as I am i interested in determining whether the *seeming* dis-interest in
documentating error conditions is real (and if so, what I am missing); as opposed
to the lack of documentation simply being a result of lack of time by the implementor
of the APIs.
Though I can certainly see myself paying for e.g. Allegro, I am hesitant to go that
route because (1) there is no platform support guarantee; at the moment they support
certain distributions of Linux, meaning it will "probably" run with various amounts
of tweaking on any given Linux distribution, or on *BSD, but you never know what
will happen in the future. (2) it would lessen the usefulness of anything I write,
since my aim is to write open source software (not in-house commercial stuff).
>>> Consider this fictional pseudo-Java code that is part of a fictional
>> RDBMS backed lookup server similar to LDAP (or POP3 or whatever):
>
> ANSI Common Lisp doesn't define any interfaces to any RDBMS,
> or for that matter to any network, or much of anything, really.
> It just barely even defines any conditions for file systems.
>
> But when you select a Lisp library (which may or may not be portable,
> so please make sure to find one that meets your requirements in that
> respect), it should fully document the conditions that can happen.
I realize Common Lisp itself does not go as far as to define all the things you
find in a language like Java. However, the spec does not even specify a
generic "some kind of I/O related problem" base condition for use by implementors
when creating more specific error conditions! And that is kind of consistent with
the seemingly predominant tendency to mostly just ignore error handling.
In any case; I realize it is an implementation dependent issue; it's just that I
have not found *A SINGLE* implementation of Common Lisp (or any other Lisp) that
properly documents error conditions. Again - the commercial ones may very well be
very good in this regard.
>> * The code is able to differentiate between I/O errors having to do with the
>> communication with the client, from database related errors caused by
>> the attempt to access the database. In ths context of the server, these are
>> logically quite different errors and must be treated differently.
>
> Lisp can do that.
Ok - given the right implementation I will grant that.
>> * If the SQLException was thrown due to some underlying I/O problem, this information
>> is not lost; in fact it would be reported as the causal exception in a stacktrace. But
>> at this level in the calling code, all that is relevant is that it is a database
>> errors; we don't care whether the database is remote, local or in-memory or what
>> possible errors the implementation might encounter. Thus we expect the database
>> API (JDBC and the JDBC driver) to emit only SQLExceptions and subclasses thereof.
>
> Lisp can do that.
Same here.
>> How do I do this in Lisp?
>
> [The spec only defines a few conditions, tried SBCL but it didn't
> document things well enough, tried the sb-bsd-sockets library but
> had to read the source code and guess what the supported API is,
> and it's SBCL=specifc anyway.]
>
> Maybe you should consider using a Lisp system that is better
> documented than SBCL?
I will probably have another look at Allegro.
> These days, I use both Lispworks and some of the free Lisp systems.
> I find their documentation to be adequate, but that certainly doesn't
> mean that it's good enough for you. I haven't seen the documentation
> from Franz, but I bet it's really good. I would suggest approaching
> your vendor on this issue.
Which free Lisp systems would that be? I would be very much interested in hearing
that. I really don't have any extreme requirements when it comes to documentation;
it's just this specific issue of error conditions that have become somewhat of
a pet peeve of mine...
> Your model pseudo-program just looks to me like a lot of the code
> that I write; I'm not sure why you think you can't write that.
Perhaps I wasn't being very clear; by not being "able" to write
code like that I mean that I can't do it portable, and not without
digging through a lot of source code to satisfy myself that I am
really handling all expected runtime conditions.
(Again subject to the possibility that commercial Lisps, or free
Lisps I have not tried, are better on this point.)
> Maybe you are missing something technical about the way that the
> condition system works. I never saw you use HANDLER-BIND, which
> is more dynamic than HANDLER-CASE. Do you realize that you can
> catch conditions, look them over, decide not to handle them and
> allow some higher-level caller the chance? Or that you could
> handle them by deciding to signal some other condition?
Yes I do realize the condition system is much more flexible than
what I used in my little example (not necessarily unwinding the stack,
using established restarts, etc). I'm not used to *using* these features
of the languge though, so my example might have been much better written
in a much clearer way using common idioms that leverage this advantage.
In any case; I have absolutely no problem with the condition signalling
*system* - that of Common Lisp is about as advanced and flexible as
I have ever come across in a language.
> Your complaint about not being able to distinguish one IO error
> from another suggests that you might be confused about that.
I was more trying to refer to the fact that the Java code comes easily
based on a cursory examination of the API docs, while the equivalent
Lisp code (with condition types properly substituted for the implementation
in question) comes after digging through the source code and hoping
that it won't change in the future.
(Once again - might not apply to all Lisps, just those I've tried.)
>> Does anybode agree with me, even a little? Should I just not
>> bothering doing something like this because nobody would be
>> interested anyway?
>
> I don't think that you are wasting your time, in general.
> I suspect that many people have written libraries of the
> sort you propose. They might not choose to release them.
> But you ought to explore what's out there a little more
> before you set off writing your own.
Perhaps I will take a serious look at Allegro and just use that
until I am much more experienced with Lisp than I am now, and
re-visit the idea of a portable library at that time.
> I would start by looking at the libraries that have been graciously
> contributed from Franz (and made portable with additional work by
> spirited volunteers) . Those seem to be pretty high quality.
Will do.
> For questions about the condition system per se, use this thread.
> To ask about libraries for specific purposes (eg. network, DB, IO, etc.)
> you should probably start a new thread for each of them, so as to
> keep the conversations trackable and for easier indexing.
Will do; I don't have any specific issues at the moment though.
In an case; it was interesting to hear your thoughts. Thank you!
Christophe Rhodes
>> How do I do this in Lisp?
>
> [The spec only defines a few conditions, tried SBCL but it didn't
> document things well enough, tried the sb-bsd-sockets library but
> had to read the source code and guess what the supported API is,
> and it's SBCL=specifc anyway.]
<http://www.sbcl.org/manual/Sockets-Overview.html#Sockets%20Overview>
is very minimal documentation, but I think it's enough to do something
like the OP wants:
(define-condition database-condition ()
())
(define-condition database-socket-condition (database-condition)
((socket-condition :initarg :socket-condition :reader socket-condition))
(:report
(lambda (s c)
(format s "Received a socket condition: ~A" (socket-condition c)))))
(handler-bind ((sb-bsd-sockets:socket-condition
(lambda (c)
;; maybe something up the stack wants to handle this?
(signal c)
;; otherwise, error on a database condition
(error 'database-socket-condition :socket-condition c))))
(do-stuff))
or possibly
(restart-case
(handler-bind ((sb-bsd-sockets:socket-condition
(lambda (c)
(invoke-restart 'signal-database-socket-condition c))))
(do-stuff))
(signal-database-socket-condition (c)
(error 'database-socket-condition :socket-condition c)))
depending on needs (and of course these restart / handler functions
don't need to be as tightly bound as I have written them).
Christophe
Christopher C. Stacy
> > These days, I use both Lispworks and some of the free Lisp systems.
> > I find their documentation to be adequate, but that certainly doesn't
> > mean that it's good enough for you. I haven't seen the documentation
> > from Franz, but I bet it's really good. I would suggest approaching
> > your vendor on this issue.
>
> Which free Lisp systems would that be? I would be very much
> interested in hearing that. I really don't have any extreme
> requirements when it comes to documentation; it's just this specific
> issue of error conditions that have become somewhat of a pet peeve
> of mine...
I play around with all of them, but have delivered applicatins
for clients using CMUCL. (This is why I said that it was good
enough for me, but I'm not you! I've had decades of prior
experience so maybe can get by with less documentation.)
> > Your model pseudo-program just looks to me like a lot of the code
> > that I write; I'm not sure why you think you can't write that.
>
> Perhaps I wasn't being very clear; by not being "able" to write
> code like that I mean that I can't do it portable, and not without
> digging through a lot of source code to satisfy myself that I am
> really handling all expected runtime conditions.
My code (like that) is portable. I do most of my development
in Lispworks, but I sometimes deliver the program on CMUCL.
> Perhaps I will take a serious look at Allegro and just use that
> until I am much more experienced with Lisp than I am now, and
> re-visit the idea of a portable library at that time.
Look at Lispworks,too.
Have fun!
Aurélien Campéas
[...]
> Where did this housekeeping burden come from?
From the CLU language I believe (Lyskov and Snyder).
Aurélien.
Peter Schuller
> is very minimal documentation, but I think it's enough to do something
> like the OP wants:
Indeed; I had missed that part (I had been looking at the function list and
associated documentation).
Kent M Pitman
> But 'significant' means real practical stuff.
Then what kind of error do you signal when you get a hardware memory error
in an operation that is supposed to not signal any error, but that discovers
it has an incorrect result?
Java sweeps this under the rug of "runtime exceptions", but that makes it
hard to do type dispatch, and even harder in a world that is entirely
single-inheritance, since it assures that you cannot do
ARITHMETIC-EXCEPTION
/
RUNTIME-EXCEPTION FLOATING-POINT-EXCEPTION
\ /
RUNTIME-FLOATING-POINT-EXCEPTION
Instead you must have
EXCEPTION
/ \
RUNTIME-EXC STATIC-EXC
/ \
RUNTIME-ARITHMETIC-EXC STATIC-ARITHMETIC-EXC
...
Are you arguing that this is "better"?
Here's what I have to say about the design of "practical" stuff:
You cannot, through linguistic definition, make the Universe be other
than it is. All the ISO standards in the world will not make the world
single-inheritance. All the requirements in the world to declare all
possible conditions at compile time will not make those the only possible
conditions. The world is not static. I prefer a programming language
that is not either.
Nothing keeps you from annotating your program with exceptions based on what
YOU want to say about YOUR programs. Nothing keeps you from writing a
post-processor that assures that all your connectivity is solid according to
YOUR standards.
The question is not that here. You are (apparently) alleging that the
language (by which you can read "all people") should adhere to your theory.
You are advocating a theocracy. We have tried to design a language that
separates church from state.
> .. in real applications,
> error handling is very important. A networking server must be able to deal
> with sockets errors without terminating; a mail user agent must be able
> to differentiate between expected real-life problems (i.e., networking
> issues) and internal bugs. Unfortunately, I have personally found the
> error handling situation lacking in Lisp (aswell as Ruby and Smalltalk). It
> is not that the condition system in and of itself has a problem; it is rather
> how it is used and documented.
If you worry about these things, you need to be in a serious
discussion with your implementor about what situations are not
catchable. They SHOULD only be signaling fatal things using ERROR or
SERIOUS-CONDITION. You should be able to "catch" (but not necessarily
restart) those things. If you want to catch things without losing
state, you need to move these dynamic handlers inward in your program
to the nearest point where you don't mind the setup overhead but can
wrap around an operation you want to be restartable.
This is an issue of HOW you do it, not whether you can do it.
Curiously, although you don't say it, Java has the opposite problem. It
isn't about how but whether, because the language thinks it knows better
than the programmer. It forces me to NOT write code that will handle errors
that it thinks it cannot signal. That doesn't mean those errors won't
occur--the REAL WORLD determins what errors can occur [abstractly, I mean,
not as a language manifestiation]. But it means Java won't let you signal
them "in program" and won't let you negotiate how to handle them "in program",
and so forces yuu implement, extralinguistically, the support you want.
This does not seem to me practical for an expressional programming language,
and is why I classify Java as an high-level assembly language--to be used
but not seen. Your mileage may vary.
> Specifically, the problem is that the conditions signaled by a function is
> almost never documented!
This is not a problem of the language. You can easily force them to be
documented:
(DEFPACKAGE RIGID-LISP
(:USE COMMON-LISP)
(:SHADOW DEFUN)
(:EXPORT CAR CDR CONS ... RIGID-DEFUN ...)) ;<--better done programmatically,
; but you get the idea
(DEFMACRO RIGID-DEFUN (NAME CONDITIONS BVL ...) ...)
How easy is it to do the equivalent in Java to relax the standard if you
don't want it?
> I am not talking about every single possible problem
> that might occurr as a result of internal library bugs or bugs in calling
> code.
I am.
What solid program expects its libraries to be bug-free? Do you believe
that, by a bit of time and care, including the careful application of some
sort of induction, it's possible to build an infallible system?
The problem with proving programs correct is not the math, it's the
willingness to encode in logic all the possible ways a program can fail.
> But the *EXPECTED* conditions that *ARE* going to happen in real life.
That doesn't sound very rigorous or practical.
> In this regard, I must say that I find Java exemplary.
I find it exemplary, too--of something I'd least like to use. Heh.
But, you know, I'm not saying it shouldn't be used. I just question that
using it will provide all the things people think it will.
> Given a function that operates on a stream, or a file, or any kind
> of external resource, there is documentation as to how these error
> conditions are handled (be it by returning some special value or by
> throwing an exception).
Good documentation can be solved by commerce. If there is a market, people
will buy it. But if no one is springing for serious dollars for doc, then
don't think that you can fix this through the language design process.
It's been tried, I'm sure. I think Ada wanted a lot of doc. COBOL, too.
And you don't see those ruling the day.
And indeed, Java has lots of doc, but it's not always structured in the way
that's most useful. There turns out to be great value in documentation that
is not 100% aligned with the structure of the modules. I'm not discounting
the need for this structured doc, too--CLHS does it. I have internal doc
in my code that does this. But it is not all people are asking for when they
want doc. And language standards can't require it.
In 1980's, TECO used to require documentation on every function. And Emacs
Lisp, as a consequence, has this flavor. Emacs Lisp code is much more heavily
documented than other lisp dialects.
We tried to encourage documentation in Common Lisp by adding DOCUMENTATION
functions and whatnot, but that hasn't led people to do what they won't do
anyway.
And in this day of a tight economy, the price of excess will be squeezed out
of everything. If you can make time to market without such excess, that's
what will happen. You don't fix this by making the language more cumbersome;
that just makes the language an impractical vehicle for commercial use.
> This is information I, as someone
> writing calling code, MUST know in order to write robust and correct code.
Then talk to your vendor and tell him how much you'd pay.
Because I'm ASSUMING you mean you have no lisp on your desk now because you
won't pay for anything that is less than that. Or else I assume your meaning
of "must" is synonymous with a sense of optionality, since if you buy without
requiring it, YOU are making it optional, not required.
Lisp vendors react to money, not rhetoric in the design of their product.
The only Lisp dialect I know that specified all the conditions it signaled
in low-level code as Zetalisp, on the lisp machine, and it went bankrupt
years ago. (Not for that reason, but the point is that it has been tried.
And while it was useful, it didn't make the language so valuable that it
survived other, much more petty, market pressures.)
> Consider this fictional pseudo-Java code that is part of a fictional
> RDBMS backed lookup server similar to LDAP (or POP3 or whatever):
>
> ...
> A couple of things to note:
>
> * The code is able to differentiate between I/O errors having to do with the
> communication with the client, from database related errors caused by
> the attempt to access the database. In ths context of the server, these are
> logically quite different errors and must be treated differently.
Lisp lets you do the same. It does not standardize the behavior. Contact
your vendor and ask what conditions are signaled. They can tell you.
It is certainly EASY to tell you at the blunt level of an overall condition
like I/O error or SQL error. Lisp probably gives you hugely more refined
recovery than other languages. But these aspects are not part of standards
of today, so don't look to Lisp to answer your questions. Look to the
vendor. (It's not even clear that expecting standards to fix things would
work--it would impede the rapid change and responsiveness to the market
that comes from leaving it under vendor control.)
> * If the SQLException was thrown due to some underlying I/O problem,
> this information is not lost; in fact it would be reported as the
> causal exception in a stacktrace.
Stacktrace? Ugh. How low-level is your error reporting? Lisp will give you
lots better ways to cope than this. I suggest that you have not scratched
the surface of what it has to offer you.
> But at this level in the calling code, all that is relevant is that it
> is a database > errors; we don't care whether the database is remote,
> local or in-memory or what possible errors the implementation might
> encounter. Thus we expect the database API (JDBC and the JDBC driver)
> to emit only SQLExceptions and subclasses thereof.
I disagree with this. An SQL error is if SQL makes a mistake. A hardware
error, for example, is a sign of a serious malfunction in your computer. If
you mask this as an SQL error, you will file the report in the wrong place,
and will wait much longer to handle it than you should. Lisp's theory, which
you can feel free to agree with or disagree with, but which is at the heart of
dynamic condition handling, is that you should handle precisely the errors
you expect and not others. If I do
(handling-foo-errors ()
(invoke-bar-facility #'foo-service))
and BAR masks out any FOO error, how will HANDLING-FOO-ERRORS ever get a
chance to correct it.
KEEP IN MIND, that unlike the Java or most any other condition system save
ones like Dylan that are Lisp-like, conditions are handled in the point on
the stack wher they are signaled, and the stack has not been unwound. So a
FOO error could be RECOVERED quietly without the containing BAR facility
knowing it even happened. That's unlike anything Java offers.
> Note that someone made a very good point in this thread about how the Common Lisp
> condition system allows two components to communicate via conditions, even though
> the intervening code has no knowledge or support of said communication.
Indeed, a number of such points are made in the condition papers at my web
site. You might read them.
> In this case we could have the calling code (the server)
> co-operate with the JDBC driver IF this was desirable.
As it could happen in Lisp, but it seems cumbersome and non-abstract.
> But in
> cases where it is NOT desirable, we instead run into the
> problems below.
In what case would it be non-desirable to a person who understands Lisp and
how it is SUPPOSED to be used to modify a bunch of intervening functions
that were not involved, just to make them more fragile against future code
change??
> How do I do this in Lisp?
It's possible to do all of those things you cite straightforwardly.
> Consider (and *PLEASE* correct me if I am misstaken on anything):
>
> * Reading the CLHS, the spec is only concearned with type errors when
> it comes to the I/O functions (read-line, read-byte, write-byte, etc).
> The exact condition signaled in case of a problem is entirely
> implementation dependent.
You are incorrect. "only concerned with" is not an appropriate aggregation.
Standards cost money. We had no more money to keep doing standards-making.
So we stopped at this point. CERTAINLY we cared about doing more. It cost
a minimum of $450,000 and 6 years of full-time work by editors, not counting
man-years of review time, a lot of travel time, in-person time at dozens of
meetings, email in the tens of thousands of messages, etc. to produce ANSI
Common Lisp. Do you want to pony up the next chunk of cash to continue
that process? You sell us short by saying we were "only concerned with"
this much.
> Thus, if I am to be portable
> I *cannot* do what the Java code does above,
Java (i.e., Sun) has spent HUGELY more than we did making this portable.
(AND, incidentally, Sun's Java process has not been as open as ours.)
Find us a funding source as generous as Sun and we'll get right on it.
Seriously, this is such a ridiculous comparison I can bearly stand it.
> unless i go out and investigate the
> situation for each and every Common Lisp I might want to support.
Money, money, money.
And every single person who GIVES AWAY free software in the world should
think about how they bring down the price of software because now the world
thinks it should get everything FOR FREE. Which means it's EVEN HARDER
to get funding.
If you don't think money is everything in this equation, you're
denying reality.
> * Taking sbcl as an example, I have uncovered no documentation as to
> what conditions are signaled by the various functions in sb-bsd-sockets
> (except nothing to the effect of "might signal some kind of condition").
There are two ways to answer here:
First, SBCL is itself harming the industry by catering to the notion that you
don't have to pay to acquire something. If you had had to pay money to them,
maybe you would not have bought it because market forces would have said
"it doesn't offer what I want" and maybe it would have gotten better because
it wanted those dollars. But since it isn't responsive to dollars in that way,
it doesn't respond to that kind of market force.
Second, I don't doubt that the SBCL (or any) maintainers would take
your cash directly to get what you want. But I'm betting you're so spoiled
by Sun giving away free Java that you think anyone can mount the resources
they've mounted to manage a free operation of that size. I don't mean to
say this in a way that maligns you, just that opens your eyes to the fact
that what you get from Sun is very commercially valuable and the fact that
they don't make you PAY that value, they recover it in other ways, makes you
mistakenly believe that ANYONE could muster that kind of value and give it
away and find some other way to recover the cost. The world isn't
that simple. So before you go praising Java, consider whether if Java were not
free from Sun or anyone, how much would you pay for it. Now imagine if you
paid that same amount for a Lisp how much more doc they could provide. But
you won't pay that for Lisp, and not because it doesn't add value, but because
you can get Java for free, and it drives down the cost you'd pay for Lisp or
anything.
There are other threads here talking about trying to find jobs. You're kidding
yourself if you don't think all this is interconnected.
I saw a thread where someone said he was charging $1/hr and wondered
if someone wanted to underbid him. That is the road to the death of
an industry. The problem right now is not that the US charges too
much, it's that the rest of the world charges too little. When their
standard of living comes up enough, and if people learn some sense and
stop making free software, then we CS people may be able to charge for
the value we provide. But as long as everyone is just scrambling for
enough to eat, and when they're not eating and not working they think
it's appropriate to just give stuff away, the bottom will be forever
gone from the market.
Computer science people need to understand that they have something of
value that the world wants, and they need to charge for it. Not give
it away. Money is not evil. Money keeps people fed. Failing to charge
money won't mean other people don't get rich--it will just mean that no
one with computer science sensibilities will get rich. People who rule
the world will be people with no understanding of math, process, etc.
All the ethical force of a lot of bright people is presently hugely
misdirected due to the false god of free software.
And then it filters down to arguments like this where people try to
discuss value of things without discussing money. And compare things
they plan to pay no money to. Well, "zero" is in this equation a lot
(the amount you want to pay, mostly, but in a lot of places), and zero
tends to have non-linear effects on lots of equations, causing you to
misjudge things.
> Looking at the source code I can figure it
Lucky you can afford that. More value for free. No wonder again they
have no money coming in to support a doc effort.
> out, but even then (if I remember correctly, and I might not
> because this was a while ago) the exception hierarchy is mostly
> concerned with mirroring the possible return values of
> underlying syscalls, rather than offering a categorical
> hierarchy (i.e., differentiating "connection failed" from "some
> error happened during normal I/O on an open connection", etc -
> although in THIS case this is not offered by Java either).
Funny, I thought the "free software" answer to this was that YOU who want it
should contribute money or time to add what you want.
You sound like you're not holding up your end of the trade.
But then, you're not required to. Ain't "freedom" great?
> * If after having looked at the sb-bsd-sockets source code I make my
> code correct for the case of sbcl, (1) I am still only supporting sbcl,
> and (2) I have no clue how "official" the set of signalled exceptions
> is, or whether it might randomly change in a future release.
Ain't free software great? (did I say this already?)
Next time I'd withhold your funds from these evil folks.
> I have experienced the same thing with other Lisp variants
You've used others? But I thought it "MUST" have the doc you needed.
I guess "MUST" does in fact mean "doesn't really have to at all", as
I suspected above.
The free market is not a magic engine. It works only in one way. You
hold money back from people who don't give you what you want until they do.
When either they don't ask for money or you won't give it or you will freely
give it whether they give you what you want or not, I don't see how you
expect it to work. I've never seen "newsgroups" in any discussion of how
the free market works.
> (I've
> looked at a number of Scheme:s for example). In the case of Scheme
> the error handling *mechanisms* aren't even all that useful in some
> cases; and in the cases where the *mechanism* is powerful "enough"
> for my purposes, the documentation offers *no* clue as to actual
> error conditions signalled by the library. I haven't gone so far as
> to inspect the source code of all these Schemes I've looked at. The
> same goes for portability API:s like CLOCC and such - no "official"
> error signaling seems to exist, and who knows what might happen on
> different implementations. A cursory look at some of the source
> gave me the impression that's it is not just a documentation issue,
> but that the issue really isn't tackeled, and code will result in
> different conditions on different platforms (CL implementations).
>
> Am I the only one who feel this is a problem?
You're one of a small number who periodically don't understand the
economics and so barks up the wrong tree, aggravating people who have
given you stuff for free, wishing they'd give you more for free.
I don't like free software, but some people do. Even so, those people
who do have a moral code that says that when you don't like something,
you should fix it, not sit back and whine about it. That doesn't help.
So pick your paradigm. Like free software and work within it, or like
commercial software and spend your money where it will help.
And don't pretend that Java is a fair comparison to anyone. It isn't
a commercial endeavor per se. To understand Java, you must broaden your
view of the world wide enough that the money is accounted for. You have
to go wide enough to see all the consulting that goes into it. And you
have to understand that when it started, it didn't just survey available
languages for one to use, it made up a bunch of vaporware claims like
"write once, run eveywhere" which didn't turn out to be true. "write once,
debug everywhere" was soon after the motto. It's paid a lot to address
some of that, but the language continues to change when they promised it
wouldn't.
> Have I missed something?
Lots of things.
> How do people solve this problem when writing real programs in Lisp?
If they have a legitimate commercial need, they get in touch with their
vendor (by which I mean either a free software maker or a commercial seller,
incidentally, but either needs money to survive) and they tell them what
the missing feature is worth. Then the vendor says whether the amount they
have to offer is enough incentive. And then they do the rest, the part they
think is cheaper for them to do than to pay a vendor to do, themselves.
> For a while I have toyed with the idea of making my first "real"
> project a "Common Lisp Common Library" of sorts; which would be a
> portable library with various functionality that is often very
> practical, and which would have properly documented error
> conditions.
Just to give away? Do you think that will drive up or down the cost of
software? Do you think it will improve your ability to make money later?
What is your present source of funding?
If you think you'll sell this, do you think you'll add so much value or
make something so original that some free software "sniper" won't immediately
follow your effort with something free?
If you want my bet:
People are interested in bleeding you dry for anything you want to
offer for them to use for free.
As to paying, the only way to find out is to do it and see what comes.
There is no way to ask the question in advance and trust the answer.
It might work, but if you asked and people said "I'll pay" probably six
other people will rush to compete with you. And maybe no one really will
pay, and all six will lose. Or maybe there will be a big market. But
that might be true even if no one responded. comp.lang.lisp is not the
market, and arguably not even representative of the market.
Don Geddis
>> Thus, if I am to be portable
>> I *cannot* do what the Java code does above
Kent M Pitman <pit...@nhplace.com> wrote on Sun, 24 Apr 2005:
> Java (i.e., Sun) has spent HUGELY more than we did making this portable.
> (AND, incidentally, Sun's Java process has not been as open as ours.)
> Find us a funding source as generous as Sun and we'll get right on it.
> Seriously, this is such a ridiculous comparison I can bearly stand it.
Kent, the first half of your posting was about a technical comparison
between Lisp conditions and Java exceptions. I don't think Peter understood
the model of Lisp conditions, so mostly he was confused that there was a
missing piece to Lisp.
But the second half of your posting was about economics. That's interesting,
and possibly true, but from a technical comparison perspective perhaps
irrelevant.
If Peter wants to call some library database code, and portably distinguish
between network failures vs. SQL failures, that sounds like a reasonable goal.
And if Java has standardized these exceptions, but Lisp has not standardized
the analogous conditions, that's a reasonable technical evaluation to make.
Yes, you can then enter a side discussion about money, and why ANSI CL might
have missed some interesting topic areas due to resource constraints. But
really: this is one of the first times I've seen a Lisp advocate shy away
from a technical comparison. ANSI CL dominates pretty much every other
language in pretty much every way that matters (to "real" programmers), that
it seems alien to avoid a straight-up technical comparison.
In those small corners where some other language has managed to improve on
CL, is it really so difficult to acknowledge the improvement?
Java has a lot of mistakes in its design (for a "general purpose programming
language"), but one of the nice things they did was standardize some current
important algorithms, like networking, compression, regular expressions, etc.
If ANSI CL were being designed today, surely much these same libraries would
be added to the new CL design, and their lack is more due to the time frame
of standardization (and what was important at that time) than to financial
constraints.
I'm just so used to the fans of the all the other languages avoiding a direct
technical comparison with Lisp, that it seems odd to see a fan of Lisp do the
same thing.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ d...@geddis.org
Kent M Pitman
> Kent, the first half of your posting was about a technical comparison
> between Lisp conditions and Java exceptions. I don't think Peter understood
> the model of Lisp conditions, so mostly he was confused that there was a
> missing piece to Lisp.
>
> But the second half of your posting was about economics.
Well, yes, I agree with that. But he led with a remark about what the
language cares about. And that is, inherently, an economic position.
So I shifted modes to accomodate.
As I view it, the community underwent a shift at the end of ANSI CL.
Before that time, we relied on the big government super-state to tell
us what the language was. Everyone waited with a sense of grand
anticipation to find out what their language would be like. That's how
it had always been.
But standards are like interprocess synchronization in a
multi-processing system. They induce the possibility of a wait state
that the community does not want to afford if it can't. In the early
days of Computer Science, they provided such a critical need that they
had to be done. In the modern world, no one can afford the wait.
In the early days, vendors had all the money and there were almost no
users. In the modern world, users have all the money and there are
almost no vendors. To keep up, one must track the money. No vendor
can hope to keep up with what the user community can do, and vendors
certainly cannot afford to cripple themselves by holding back progress
to wait for their fellow vendors to agree. There is no longer a
single-axis monotonic notion of progress. The press "forward", such
as it is, is now a parametric graph, not a conventional graph.
Everyone's moving in a different direction, marching to a different
drummer as it were, and the only way sometimes to detect progress is
to compare a given vendor's work to their prior work. Or so I would
claim...
So the modern measure of what the language cares about is not "what's
in the standard" but "what individual vendors [in which I include free
implementation makers], working uncoordinated, invest in to serve their
various markets".
> That's interesting, and possibly true, but from a technical
> comparison perspective perhaps irrelevant.
Perhaps.
>
> If Peter wants to call some library database code, and portably distinguish
> between network failures vs. SQL failures, that sounds like a reasonable goal.
Absolutely. But the wrong conclusion is to say the language doesn't care.
The right conclusion is to say that talking to vendors about what's not
in the language is essential.
> And if Java has standardized these exceptions, but Lisp has not standardized
> the analogous conditions, that's a reasonable technical evaluation to make.
Heh. Here I would say that's a reasonable economic evaluation to make.
I'm not sure that standardization is a technical effect. It certainly has
technical impact. Standards and standards-related deicisions are often
made for non-technical reasons.
> Yes, you can then enter a side discussion about money, and why ANSI CL might
> have missed some interesting topic areas due to resource constraints. But
> really: this is one of the first times I've seen a Lisp advocate shy away
> from a technical comparison. ANSI CL dominates pretty much every other
> language in pretty much every way that matters (to "real" programmers), that
> it seems alien to avoid a straight-up technical comparison.
I'm not avoiding such a comparison. I'm saying you're crippling your view of
what the language today is by considering ANSI only. If you consider ANSI
only, you also can't create exe files, can't do CORBA, can't talk to SQL,
etc. yet most implementations can do things like this.
> In those small corners where some other language has managed to improve on
> CL, is it really so difficult to acknowledge the improvement?
The usefulness of the feature I do acknowledge. But I'm saying that in
practical terms, for people trying to get work done, this information IS
available. Maybe not as portably as you'd like, yes. But then, Java
overplays its portability card IMO.
> Java has a lot of mistakes in its design (for a "general purpose programming
> language"), but one of the nice things they did was standardize some current
> important algorithms, like networking, compression, regular expressions, etc.
Yes, this is why I never fail to emphasize its use as an assembly language.
It defines a very powerful virtual machine, quite appropriate to enabling
useful applications above it. I just don't like the cumbersome syntax and
some of the programming language decisions.
> If ANSI CL were being designed today, surely much these same libraries would
> be added to the new CL design, and their lack is more due to the time frame
> of standardization (and what was important at that time) than to financial
> constraints.
Doubtless.
> I'm just so used to the fans of the all the other languages avoiding a direct
> technical comparison with Lisp, that it seems odd to see a fan of Lisp do the
> same thing.
I agree such a comparison is useful. I just felt it was crippled by
considering only the standard. It's not like the community has been stagnant
since 1994. We have not been making a new standard since then because ours
holds up fine. New work HAS been done, and any fair analysis has to look to
where that work is happening not just say that because it's not being done
by a well-funded central organization, it isn't there.
Peter Schuller
> in an operation that is supposed to not signal any error, but that discovers
> it has an incorrect result?
Basically any kind of error; as calling code, I don't care (except in very
VERY special circumstances). As I stated in my original post, I was primarily
talking about *expected* error conditions. In other words, things like
networking errors or I/O errors while reading/writing a file (especially
the former).
> Java sweeps this under the rug of "runtime exceptions", but that makes it
> hard to do type dispatch, and even harder in a world that is entirely
> single-inheritance, since it assures that you cannot do
As I also stated in the pervious post, I am not advocating checked exceptions,
nor am I advocated the Java exception handling mechanism. I was merely making
an observation about the general tendency to ignore or de-emphasize error
handling (something which is not limited to Lisp), specifically in cases
where there is an obvious need to deal with errors.
> ARITHMETIC-EXCEPTION
> /
> RUNTIME-EXCEPTION FLOATING-POINT-EXCEPTION
> \ /
> RUNTIME-FLOATING-POINT-EXCEPTION
>
> Instead you must have
>
> EXCEPTION
> / \
> RUNTIME-EXC STATIC-EXC
> / \
> RUNTIME-ARITHMETIC-EXC STATIC-ARITHMETIC-EXC
> ...
>
> Are you arguing that this is "better"?
No I am not, or at least I did not intend to. What was it about my original
post that lead you to this conclusion?
> Here's what I have to say about the design of "practical" stuff:
>
> You cannot, through linguistic definition, make the Universe be other
> than it is. All the ISO standards in the world will not make the world
> single-inheritance. All the requirements in the world to declare all
> possible conditions at compile time will not make those the only possible
> conditions. The world is not static. I prefer a programming language
> that is not either.
>
> Nothing keeps you from annotating your program with exceptions based on what
> YOU want to say about YOUR programs. Nothing keeps you from writing a
> post-processor that assures that all your connectivity is solid according to
> YOUR standards.
>
>
> The question is not that here. You are (apparently) alleging that the
> language (by which you can read "all people") should adhere to your theory.
> You are advocating a theocracy. We have tried to design a language that
> separates church from state.
Again, I explicitly stated that I was not advocated checked exceptions. I
am not interested in this. I am only interested in being able to handle
*expected* conditions. Aside from 50 line one-off throw-away scripts, pretty
much all "real world" applications are in need of some error handling. Whether
it be a small application that monitors network connectivity or a MUA that
wants to behave properly in the face of networking errors and protocol errors.
Or a web spider that must be able to handle failure conditions without terminating;
or just about any kind of network server which must be able to deal with
network related errors specific to a client, that do not prevent the server
from continuing.
In light of this, I was missing a portable and documented way of identifying
these kinds of errors.
Once again, and I cannot stress this enough, I am *NOT* talking about every
single error condition that might theoretically happen; I am only talking about
the obvious expected errors that you KNOW will happen when you write the calling
code, and that you want to handle.
> If you worry about these things, you need to be in a serious
> discussion with your implementor about what situations are not
> catchable. They SHOULD only be signaling fatal things using ERROR or
> SERIOUS-CONDITION. You should be able to "catch" (but not necessarily
> restart) those things. If you want to catch things without losing
> state, you need to move these dynamic handlers inward in your program
> to the nearest point where you don't mind the setup overhead but can
> wrap around an operation you want to be restartable.
>
> This is an issue of HOW you do it, not whether you can do it.
I don't understand what it is you believe my problem is. All I am saying
is that in able to deal with error conditions properly (be it ERROR:s
or SERIOUS-CONDITION:s or something else), I want to know *what* error
conditions are signaled and under what circumstances (again: for expected
errors).
In *most* cases the issues is *not* about *restarting* an operationg (which
requires very specific knowledge about what went wrong), but rather logging
the error, perhaps informing the user or a client program connected to
the server, and performing proper clean-up.
> Curiously, although you don't say it, Java has the opposite problem. It
> isn't about how but whether, because the language thinks it knows better
> than the programmer. It forces me to NOT write code that will handle errors
> that it thinks it cannot signal. That doesn't mean those errors won't
> occur--the REAL WORLD determins what errors can occur [abstractly, I mean,
> not as a language manifestiation]. But it means Java won't let you signal
> them "in program" and won't let you negotiate how to handle them "in program",
> and so forces yuu implement, extralinguistically, the support you want.
> This does not seem to me practical for an expressional programming language,
> and is why I classify Java as an high-level assembly language--to be used
> but not seen. Your mileage may vary.
I agree, I never argued against this.
>> Specifically, the problem is that the conditions signaled by a function is
>> almost never documented!
>
> This is not a problem of the language. You can easily force them to be
> documented:
In MY code. The issue I was observing was a general lack of such documentation
for existing API:s.
> How easy is it to do the equivalent in Java to relax the standard if you
> don't want it?
Java is not even in the same ballpark as CL. I never argued against this.
>> I am not talking about every single possible problem
>> that might occurr as a result of internal library bugs or bugs in calling
>> code.
>
> I am.
Be my guest, but it has nothing to do with my original post. Handling EVERY
error that might EVER happen (including those that result from broken
hardware) is a *HUGELY* different problem from simply being able to
determine "ok, the file i tried to remove did not exist" or "ok, some
networking error occurred while trying to talk to the client".
> What solid program expects its libraries to be bug-free? Do you believe
> that, by a bit of time and care, including the careful application of some
> sort of induction, it's possible to build an infallible system?
No.
> The problem with proving programs correct is not the math, it's the
> willingness to encode in logic all the possible ways a program can fail.
Sure.
>> But the *EXPECTED* conditions that *ARE* going to happen in real life.
>
> That doesn't sound very rigorous or practical.
So you're telling me that if you want to write - say - a packaging system
that, among other things, needs to create, delete and modify the permissions
of files (aswell as create/delete symbolic links), you would not be helped
by having conditions documented? You would actually *WANT* to go digging
around in the source code of the CL implementation of your choice (assuming
it implemented the API necessary for the above) in order to determine how
to find out if a file deletion failed? And then have to re-dig through all
that source code in future releases because you have no idea what is
"official" and what is not?
And again, I'm not talking about errors being the result of broken hardware
or some internal bug in the API or whatever. I'm talking about the completely
obviouis and very real possible condition of "file not found" or "permission
denied".
> But, you know, I'm not saying it shouldn't be used. I just question that
> using it will provide all the things people think it will.
Again (sorry about sounding like a broken record), I am *NOT* advocating
Java as a language surperior to CL.
> Good documentation can be solved by commerce. If there is a market, people
> will buy it. But if no one is springing for serious dollars for doc, then
> don't think that you can fix this through the language design process.
> It's been tried, I'm sure. I think Ada wanted a lot of doc. COBOL, too.
> And you don't see those ruling the day.
>
> And indeed, Java has lots of doc, but it's not always structured in the way
> that's most useful. There turns out to be great value in documentation that
> is not 100% aligned with the structure of the modules. I'm not discounting
> the need for this structured doc, too--CLHS does it. I have internal doc
> in my code that does this. But it is not all people are asking for when they
> want doc. And language standards can't require it.
There are many reasons why documentation tends to never be totally complete. But
once again, I am talking about *OBVIOUS* error conditions. If I write code to
remove a file the very first thing I want to do is handle the case where the
removal failed. If I am writing a network server, the very first thing I want
to do is handle the case of I/O errors occurreding when communication with
a client. These aren't weird edge cases that are unforseen; there are completely
obvious error conditions that almost all 'real' applications will want to handle.
(And by "handle" I mean "identify and do SOMETHING about, even if just cleaning up
and/or logging the error")
> And in this day of a tight economy, the price of excess will be squeezed out
> of everything. If you can make time to market without such excess, that's
> what will happen. You don't fix this by making the language more cumbersome;
> that just makes the language an impractical vehicle for commercial use.
Not trying to.
> Then talk to your vendor and tell him how much you'd pay.
>
> Because I'm ASSUMING you mean you have no lisp on your desk now because you
> won't pay for anything that is less than that. Or else I assume your meaning
> of "must" is synonymous with a sense of optionality, since if you buy without
> requiring it, YOU are making it optional, not required.
>
> Lisp vendors react to money, not rhetoric in the design of their product.
This is completely and utterly irrelevant to the discussion at hand. If you
want to rant on about how I, as a private individual, should somehow finance
entire corporations to churn out their product - fine, but it has no bearing
on my original post.
Even assuming I am willing to pay for a commercial Lisp (which is no great
assumption I assure you, though at the moment I cannot afford the fee
required for the CL I was looking at possibly buying), there is still the issue
that any non-free CL is going to be restrictive in terms of portability. That
has nothing to do with money.
> The only Lisp dialect I know that specified all the conditions it signaled
> in low-level code as Zetalisp, on the lisp machine, and it went bankrupt
> years ago. (Not for that reason, but the point is that it has been tried.
> And while it was useful, it didn't make the language so valuable that it
> survived other, much more petty, market pressures.)
See above about documenting ALL conditions.
> Lisp lets you do the same. It does not standardize the behavior. Contact
> your vendor and ask what conditions are signaled. They can tell you.
You are missing my point again. Nevermind what is possible theoretically; I
was talking about overall tendencies and wondering what people actually did
when writing real world programs.
>> * If the SQLException was thrown due to some underlying I/O problem,
>> this information is not lost; in fact it would be reported as the
>> causal exception in a stacktrace.
>
> Stacktrace? Ugh. How low-level is your error reporting? Lisp will give you
> lots better ways to cope than this. I suggest that you have not scratched
> the surface of what it has to offer you.
I know the lisp condition system is very flexible. But the very point you
are trying to make - that documenting EVERY SINGLE condition that may arrise
is not feasable - is indicative that there is indeed a need for a good
way to identify what went wrong in the case of an unforseen problem. If
calling code cannot handle the problem, it is very useful if the problem can
at least be logged (in the form of a full backtrace), so that the person
who wrote the code (or the person using the code) can try to deduce what
actually went wrong.
> I disagree with this. An SQL error is if SQL makes a mistake. A hardware
> error, for example, is a sign of a serious malfunction in your computer. If
> you mask this as an SQL error, you will file the report in the wrong place,
> and will wait much longer to handle it than you should. Lisp's theory, which
> you can feel free to agree with or disagree with, but which is at the heart of
> dynamic condition handling, is that you should handle precisely the errors
> you expect and not others. If I do
See above about hardware errors, this isn't what I am talking about.
> KEEP IN MIND, that unlike the Java or most any other condition system save
> ones like Dylan that are Lisp-like, conditions are handled in the point on
> the stack wher they are signaled, and the stack has not been unwound. So a
> FOO error could be RECOVERED quietly without the containing BAR facility
> knowing it even happened. That's unlike anything Java offers.
I know. Again, I am not advocating Java. I realize CL's conditions system is
hugely more flexbiel than that of Java.
>> Note that someone made a very good point in this thread about how the Common Lisp
>> condition system allows two components to communicate via conditions, even though
>> the intervening code has no knowledge or support of said communication.
>
> Indeed, a number of such points are made in the condition papers at my web
> site. You might read them.
I would be very interesting in doing so. Which site is that?
>> In this case we could have the calling code (the server)
>> co-operate with the JDBC driver IF this was desirable.
>
> As it could happen in Lisp, but it seems cumbersome and non-abstract.
>
>> But in
>> cases where it is NOT desirable, we instead run into the
>> problems below.
>
> In what case would it be non-desirable to a person who understands Lisp and
> how it is SUPPOSED to be used to modify a bunch of intervening functions
> that were not involved, just to make them more fragile against future code
> change??
They should not have to modify anything. But if calling code and the programmer
writing that code does not have control over what the layer-in-between is using
as the next layer, then calling code and the programmer writing it will not know
what conditions are signaled by that code (unless it is documented).
>> Consider (and *PLEASE* correct me if I am misstaken on anything):
>>
>> * Reading the CLHS, the spec is only concearned with type errors when
>> it comes to the I/O functions (read-line, read-byte, write-byte, etc).
>> The exact condition signaled in case of a problem is entirely
>> implementation dependent.
>
> You are incorrect. "only concerned with" is not an appropriate aggregation.
> Standards cost money. We had no more money to keep doing standards-making.
> So we stopped at this point. CERTAINLY we cared about doing more. It cost
> a minimum of $450,000 and 6 years of full-time work by editors, not counting
> man-years of review time, a lot of travel time, in-person time at dozens of
> meetings, email in the tens of thousands of messages, etc. to produce ANSI
> Common Lisp. Do you want to pony up the next chunk of cash to continue
> that process? You sell us short by saying we were "only concerned with"
> this much.
Perhaps my phrasing was sub-optimabl; but all I meant was that it would have been
extremely useful to have a general-purpose "io-error" (or something similar) that
could have been documented at that level (and if more detailed errors are not
feasable to document in Common Lisp, at least there is a common base class for
I/O related errors). This would allow at least basic error handling in a portable way.
Note that I never intended to critize the CL spec as such, or the people behind it.
I was merely using it as an example of the general tendency I have experienced
among Lisps in general (Common Lisp and a bunch of Schemes), aswell as other
languages like Smalltak, Ruby and Python.
>> Thus, if I am to be portable
>> I *cannot* do what the Java code does above,
>
> Java (i.e., Sun) has spent HUGELY more than we did making this portable.
> (AND, incidentally, Sun's Java process has not been as open as ours.)
> Find us a funding source as generous as Sun and we'll get right on it.
> Seriously, this is such a ridiculous comparison I can bearly stand it.
Come on. I am merely talking about documentation of the most obvious
error condition; not some hugely complex and demanding process. I do understand
that the Common Lisp spec does not include this (and I can certainly
understand why). I was more "interested" in the general *tendench*; i.e., for
a given API written by a random person or company, there tends to be a
distinct lack of information on error conditions, even when they are very
much relevant and likely to happen.
I was more interested in "what am I missing? how do people write real programs
under this condition?".
>> unless i go out and investigate the
>> situation for each and every Common Lisp I might want to support.
>
> Money, money, money.
>
> And every single person who GIVES AWAY free software in the world should
> think about how they bring down the price of software because now the world
> thinks it should get everything FOR FREE. Which means it's EVEN HARDER
> to get funding.
>
> If you don't think money is everything in this equation, you're
> denying reality.
I never mentioned money in my original post.
Suppose I have an infinite amount of money (or at least enough so that I can
buy a $x (500 < x < 5000) license without difficulty). I am *still* hesitant
to go with non-free (free as in speech) solutions because they tend to limit
portability and flexibility. I abhore binary-only distributions and the problems
they create (practical problems, not some abstract ideological issue).
If I want to be able to move between Linux, FreeBSD, NetBSD and DragonFly BSD for
example, there is no commercial Lisp in existence, that I am aware of, that
allows me to do that (other than HOPING that the lastest version will work in
Linux emulation on the OS in question). I am mentioning those four OS:es because
it is an actual example - I am using these OS:es and I would like to be able
to run my own software on them.
As a result I am likely to go with a free (as in speech) alternative (basically
sbcl, cmucl or clisp at this point).
> There are two ways to answer here:
>
> First, SBCL is itself harming the industry by catering to the notion that you
> don't have to pay to acquire something. If you had had to pay money to them,
> maybe you would not have bought it because market forces would have said
> "it doesn't offer what I want" and maybe it would have gotten better because
> it wanted those dollars. But since it isn't responsive to dollars in that way,
> it doesn't respond to that kind of market force.
>
> Second, I don't doubt that the SBCL (or any) maintainers would take
> your cash directly to get what you want. But I'm betting you're so spoiled
> by Sun giving away free Java that you think anyone can mount the resources
> they've mounted to manage a free operation of that size. I don't mean to
Spoiled by Java? Not likely. Not in this context. See above - Java is NOT
exactly my idea of a portable language when it comes to being able to run
things on "less mainstream" OS:es. The only reason Java is usable at all on
Linux/BSD is because of the media hype that has sorrounded Linux for the
past few years.
> say this in a way that maligns you, just that opens your eyes to the fact
> that what you get from Sun is very commercially valuable and the fact that
> they don't make you PAY that value, they recover it in other ways, makes you
> mistakenly believe that ANYONE could muster that kind of value and give it
> away and find some other way to recover the cost. The world isn't
> that simple. So before you go praising Java, consider whether if Java were not
> free from Sun or anyone, how much would you pay for it. Now imagine if you
> paid that same amount for a Lisp how much more doc they could provide. But
> you won't pay that for Lisp, and not because it doesn't add value, but because
> you can get Java for free, and it drives down the cost you'd pay for Lisp or
> anything.
>
> There are other threads here talking about trying to find jobs. You're kidding
> yourself if you don't think all this is interconnected.
Again, nothing to do with my original post.
> I saw a thread where someone said he was charging $1/hr and wondered
> if someone wanted to underbid him. That is the road to the death of
> an industry. The problem right now is not that the US charges too
> much, it's that the rest of the world charges too little. When their
> standard of living comes up enough, and if people learn some sense and
> stop making free software, then we CS people may be able to charge for
> the value we provide. But as long as everyone is just scrambling for
> enough to eat, and when they're not eating and not working they think
> it's appropriate to just give stuff away, the bottom will be forever
> gone from the market.
Take it up with RMS :)
>> Looking at the source code I can figure it
>
> Lucky you can afford that. More value for free. No wonder again they
> have no money coming in to support a doc effort.
Again I was talking about a general tendency rather than trying to
complain that "nobody documents sbcl properly".
> Funny, I thought the "free software" answer to this was that YOU who want it
> should contribute money or time to add what you want.
>
> You sound like you're not holding up your end of the trade.
>
> But then, you're not required to. Ain't "freedom" great?
So we're going to this tired old argument. Sure. I am not allowed
to point out possible problems with a piece of software until I have
thrown out linux/bsd/apache/ssh/firefox/opera/etc and re-implemented
EVERYTHING myself from scratch? Not likely.
> You're one of a small number who periodically don't understand the
> economics and so barks up the wrong tree, aggravating people who have
> given you stuff for free, wishing they'd give you more for free.
I'm not even going to address this.
> I don't like free software, but some people do. Even so, those people
> who do have a moral code that says that when you don't like something,
> you should fix it, not sit back and whine about it. That doesn't help.
See above.
> And don't pretend that Java is a fair comparison to anyone. It isn't
> a commercial endeavor per se. To understand Java, you must broaden your
> view of the world wide enough that the money is accounted for. You have
> to go wide enough to see all the consulting that goes into it. And you
> have to understand that when it started, it didn't just survey available
> languages for one to use, it made up a bunch of vaporware claims like
> "write once, run eveywhere" which didn't turn out to be true. "write once,
> debug everywhere" was soon after the motto. It's paid a lot to address
> some of that, but the language continues to change when they promised it
> wouldn't.
I was not interested in the economical dynamics of the situation; I was
merely using Java as a suitable "benchmark" when it came to documenting
error conditions.
>> For a while I have toyed with the idea of making my first "real"
>> project a "Common Lisp Common Library" of sorts; which would be a
>> portable library with various functionality that is often very
>> practical, and which would have properly documented error
>> conditions.
>
> Just to give away?
Yes.
> Do you think that will drive up or down the cost of
> software? Do you think it will improve your ability to make money later?
Perhaps.
> What is your present source of funding?
In-house software development as a full-time employee.
> If you think you'll sell this, do you think you'll add so much value or
> make something so original that some free software "sniper" won't immediately
> follow your effort with something free?
I would not be interested in selling such a thing. It's the most useful being
free.
Arthur Lemmens
>> You're one of a small number who periodically don't understand
>> the economics and so barks up the wrong tree, aggravating people who have
>> given you stuff for free, wishing they'd give you more for free.
>
> I'm not even going to address this.
Right you are.
Peter Seibel gave a very interesting (and funny) talk at the European
Common Lisp Meeting yesterday. The first half of his talk gave an
overview of effective strategies for driving people away from Lisp.
Using the phrase "You don't understand X" was one of his examples.
Edi Weitz
> And every single person who GIVES AWAY free software in the world
> should think about how they bring down the price of software because
> now the world thinks it should get everything FOR FREE.
Yeah, but it takes two to tango, right? I mean, why do tightwads like
you use free software like Emacs and Gnus instead of buying a decent
commercial newsreader? If you'd put your money where your mouth is
you could help dimishing the market for those evil open source guys
until it finally disappears.
Cheers,
Edi.
PS: Nah, I don't really want to discuss this stuff. Just thought I'd
play smart ass.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq "spam...@agharta.de" 5) "edi")
Juho Snellman
> First, SBCL is itself harming the industry by catering to the notion that you
> don't have to pay to acquire something.
Thanks, we aim to please.
--
Juho Snellman
"Premature profiling is the root of all evil."
Kent M Pitman
> On Sun, 24 Apr 2005 17:33:00 GMT, Kent M Pitman <pit...@nhplace.com> wrote:
>
> > And every single person who GIVES AWAY free software in the world
> > should think about how they bring down the price of software because
> > now the world thinks it should get everything FOR FREE.
>
> Yeah, but it takes two to tango, right? I mean, why do tightwads like
> you use free software like Emacs and Gnus instead of buying a decent
> commercial newsreader? If you'd put your money where your mouth is
> you could help dimishing the market for those evil open source guys
> until it finally disappears.
I use Eudora, and pay money for it, but it has no associated mail reader
(or didn't last I checked... alas)
I also have paid for Microsoft Office, which has a commercial mail reader.
I just don't think it is as good as Emacs.
But none of that is relevant. The real pain of free software is that one
can't afford NOT to use it. By driving down the prices people can charge,
one has no more margin left on their products to buy commercial software!
I'd prefer to pay for software and to pass that cost through to people buying
mine, but it doesn't work that way. If I do that, I sell even less software
because myt prices are too high.
Ulrich Hobelmann
> I use Eudora, and pay money for it, but it has no associated mail reader
> (or didn't last I checked... alas)
Wasn't Eudora a mail program originally? That's what I remember
anyways.
> But none of that is relevant. The real pain of free software is that one
> can't afford NOT to use it. By driving down the prices people can charge,
> one has no more margin left on their products to buy commercial software!
It will be interesting to see, how Opera (.com, the browser
company) will fare, now with Firefox around, and the Mac having a
good browser out of the box.
> I'd prefer to pay for software and to pass that cost through to people buying
> mine, but it doesn't work that way. If I do that, I sell even less software
> because myt prices are too high.
I think nice small applications (like a really good newsreader for
the Mac) would be worth $10-20 for most people. It depends how
much you want to make on software, and how many customers you can get.
Consulting or coding on contract might be the best thing to do in
the future. There will always be demand for custom software (I
hope), and with good open tools the developing costs might be reduced.
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
Kent M Pitman
> Consulting or coding on contract might be the best thing to do in the
> future. There will always be demand for custom software (I hope), and
> with good open tools the developing costs might be reduced.
This is like saying to someone who wants to be a professional opera
singer "not to worry--there will always be advertising companies
wanting someone to belt out their stupid jingles, and there will
always be restaurants wanting to hire both the occasional live singer
or someone to record muzack for them". That's great for people who
find that fulfilling, but it misses the point. I'm not going to belabor
the point. I've done that many times. I just want to say that this
remark above misses it.
Kent M Pitman
> As I also stated in the pervious post, I am not advocating checked
> exceptions, nor am I advocated the Java exception handling
> mechanism. I was merely making an observation about the general
> tendency to ignore or de-emphasize error handling (something which
> is not limited to Lisp), specifically in cases where there is an
> obvious need to deal with errors.
Nothing could be farther from the truth. It was simply a HUGE project
to be explicit on this and there was no money to do that project.
We all wished for it, but none of us had access to the US Treasury's
machine for printing money.
In other words, for better or worse, you're reading more into intent than
is there.
Let me also echo a caution that someone from then-NBS (now NIST) made
in one of the very first X3J13 standards meetings: Standards are not
about design, they are about codifying what is already agreed upon.
To be sure, there were things in the ANSI CL standard that defied
this. But in MOST of those cases, it was because there were multiple
conflicting proposals and new design was felt to be the only path
toward community compromise, since adopting wholesale one or another
vendor's way of doing things while leaving another vendor completely
out in the cold was not acceptable. So multiple vendors had class
systems, and we had to make a new one to achieve consensus. But
multiple vendors did NOT do error systems at that time, so we simply
did not have the community experience to drive that process. It
wasn't that no vendor wanted this, it was that there was not enough
commercial experience to know what was wanted and so we didn't want to
prematurely standardize.
Reading this lack of consensus on details as a lack of interest is a
bit like reading the lack of a State Prayer in the US as saying there
is no interest in religion in the US. Sometimes the details matter
so much that standardization doesn't work.
Could we go back and make more standard now? Maybe. But we'd risk
destabilizing what we have. And it's not clear that it's needed. Not
because ways of doing things aren't need, but because _ANSI_ standards
are not the only vehicle for deliving ways of doing things.
> Again, I explicitly stated that I was not advocated checked exceptions.
I guess in all your advocacy of and/or comparison to Java I just missed
this point. Sorry about that. (It probably threw off some of my other
comments, too. Rather than address all of them in detail I'll just make
a vague blanket apology for derivative effects here as well.)
> I am only interested in being able to handle *expected* conditions.
I agree it's more work, but is there some reason "implementation-dependent"
or even "implementation-defined" does not work?
> > Then talk to your vendor and tell him how much you'd pay.
> [...]
> > Lisp vendors react to money, not rhetoric in the design of their product.
>
> This is completely and utterly irrelevant to the discussion at hand. If you
> want to rant on about how I, as a private individual, should somehow finance
> entire corporations to churn out their product - fine, but it has no bearing
> on my original post.
This is the part I'm struggling to understand--why you think that's not
relevant.
And, btw, when you use "corporation" do you mean to say you missed all those
places where I noted that by vendor I always mean to include a maker
of free software? (There needs to be some generic term for "supplier of
an implementation", and I use the term "vendor" for that, usually trying to
explicitly remark on my non-stnadard use of this term. Are you, likewise,
using "corporation" in that non-standard way or are you reading past my
parenthetical remarks about meaning to be thus inclusive and erroneously
thinking thatI am talking only of commercial Lisps when I make these remarks?)
> Even assuming I am willing to pay for a commercial Lisp (which is no
> great assumption I assure you, though at the moment I cannot afford
> the fee required for the CL I was looking at possibly buying), there
> is still the issue that any non-free CL is going to be restrictive
> in terms of portability. That has nothing to do with money.
The reason I'm assuming it does is that you're apparently concluding
that you're not yourself part of the community. you're standing on
the outside and not thinking that you yourself can change things.
when you don't see something in the formal standard written and
published over 10 years ago, you project the assumption (rightly or
wrongly) that the community doesn't care and that nothing has
happened since. take the bull by the horns. contact your vendor
and ask. tell them what you would pay. get your friends to pony up
money, too. i'm not saying pay for the whole thing UNLESS you find
you're the only one asking. what I'm saying is that your fair share
of the cost is
x/y
where
x = cost of doing what you want
y = number of people who want it enough to pay for it
It might be that x/y is too expensive for you. And then that's your answer.
Or it might be that you have a disagreement with your vendor about whether
y people will really pay. The problem with being a vendor is that you have
to guess and hope, and you pay the price of being wrong. Vendors are very
conservative about that computation. But if it's a feature that matters to
you and you believe that the value of y is large but the vendor doesn't,
you can help your case by instead of concluding that the vendor doesn't care,
going to the community and getting people to contact the vendor and assure
them that they'd pay if something was included.
OR, if it's open source as you say, WRITE THE DOC yourself and give it to
the vendor and say "Is this your intent for now and furture releases? If it
is, maybe you could thus document it." and then go to the vendor you think
that disagrees (causing non-portability) and tell them you care about
portability and ask if they could compromise.
This is how progress is made. By people shepherding change. Look how hard
people have worked to get DEFSYSTEM-like things into the language. Let me
paraphrase one of the vendors from ten+ years ago when I was pushing this:
"It's not that I don't want to include DEFSYSTEM in my release. Hell, I'm
distributing a CD-ROM full of shareware with my implementation and there are
at least three implementations of DEFSYSTEM on that CD-ROM. And I've got NO
problem putting DEFSYSTEM into my implementation. Just tell me which one
to put there. Because I've got no idea."
[And for DEFSYSTEM, in the modern world, I think the answer is: there is
no answer. Each provides some value, and my personal answer to this problem
is to get people to standardize on protocol. See my "Large Systems" paper
at my web site if you're curious how this could be reconciled portably.]
But for conditions I grant you it's not like syntax but like the underlying
protocol of my large systems paper--it's something that can't vary. But it
depends on individuals or a group getting together and changing things.
You have passion about this. Don't use your passion to convince people you
can't do something. Use your passion to name the specific change you want
and to push it through. If all you aspire to is convincing people there is
a problem, you'll win on that. But then people will think you're done and
they'll be demoralized.
I don't have trouble with your claim that this needs to be done. I have
trouble with your claim that no one cares. People DO care. But they are
waiting for someone with passion to fix each and every thing. Each of us
has only some time or some money. Use your time on earth doing your part
of something constructive, don't squander it in the false satisfaction of
thinking the problem is lack of caring and patting yourself on the back
for having succeeded. People already know it, what they seek is a workable
solution. Make one. Document something. Make your hobby-horse be getting
everyone to adopt it, NOTWITHSTANDING the absence of a very cumbersome
standards process to bless it. We don't need the blessing. We just need
the accidental fact.
When I see non-portabilities, I send email to vendor A or vendor B saying
"I think on this issue you should change." I don't say "because the
standard says". Often the standard is ambiguous or mute and everyone has
a reason for saying they already conform. But we all know portability matters,
and so sometimes it just takes the vendor being made to believe that it's
"their turn" to yield a little.
And, btw, this that I'm suggesting is all about each of our finite resources,
and finite energies, and whatnot. Which is why this is all about economics,
whether you're paying for your Lisp or not.
> I know the lisp condition system is very flexible.
[I somehow missed this in the original thing. Repeated apology here.]
> But the very point you
> are trying to make - that documenting EVERY SINGLE condition that may arrise
> is not feasable
No, i wasn't trying to make that point. I was trying to make the point that
ERROR _is_ a documentation of every single condition that might arise.
I'd prefer it if there were more fine grained names sometimes for the
conditions that might get signaled, sure. But I diagree with the
technical claim that we don't document what might get signaled. ERROR
might get signaled. It might be called FILE-NOT-FOUND or
NETWORK-INTERFACE-MISSING, but it's still ERROR. I'm not saying the
problem you're having doesn't exist. I'm just saying that your
on-and-off characterization of the error as "the error is not
documented" is the wrong phrasing and is not helping your case, it's
just confusing me into side-tracks of having to correct terminology.
Writing
(ERROR 'FILE-NOT-FOUND :NAME #P"/foo/bar")
_is_ an implementation of "an error of type ERROR will be signaled."
You might wish it said something more refined, but the problem is not
not that the error isn't documented, it's that the error that is documented
is not of an adequately specific type for you to allow you to distinguish
it from other kinds of errors that you don't want to handle. This is a
legitimate thing to want. It just needs to be spoken about properly as
you ask for it.
Your failure to use good error and type terminology makes it hard for
me to answer you on-topic. And when I reply correcting your
terminology, you think I'm saying I disagree with your cause, which I
don't. I just can't talk about causes with incorrect terminology--it
makes it appear I'm agreeing with false premises. [Sort of like the
"have you stoppped beating your wife?" problem. You might or might
not beat your wife, but if you don't, it's hard to have a discussion
on the subject that begins with a false premise.]
> > Indeed, a number of such points are made in the condition papers at my web
> > site. You might read them.
>
> I would be very interesting in doing so. Which site is that?
http://www.nhplace.com/kent/Papers/
look for the 1990 and 2001 papers on conditions.
> Perhaps my phrasing was sub-optimabl; but all I meant was that it
> would have been extremely useful to have a general-purpose
> "io-error" (or something similar) that could have been documented at
> that level (and if more detailed errors are not feasable to document
> in Common Lisp, at least there is a common base class for I/O
> related errors). This would allow at least basic error handling in a
> portable way.
IO-ERROR is there, I think. It's spelled STREAM-ERROR, though.
I don't think that's your problem in the specific. That doesn't mean
there aren't missing specific condition classes, I just don't think
this is the one. And in some cases maybe it doesn't say to use STREAM-ERROR
though I bet a lot of times you can.
> Note that I never intended to critize the CL spec as such,
I don't mind people criticizing the CL spec, btw.
The spec itself is largely text I wrote (or at least edited), and I've
got little ego about that. I'm the first to rush to criticize the text.
I often cringe at how crude it was.
But I hide behind resources sometimes. We had only so much money. And
we did the best we can. I say that NOT to be defensive but to teach a
life lesson about what's reasonable to expect and what's not. Because I
was right there asking for more and being told over and over again how
finite resources buys only a finite result. Because I know that was the
real issue. And because everyone should know that too.
> > Java (i.e., Sun) has spent HUGELY more than we did making this portable.
> > (AND, incidentally, Sun's Java process has not been as open as ours.)
> > Find us a funding source as generous as Sun and we'll get right on it.
> > Seriously, this is such a ridiculous comparison I can bearly stand it.
>
> Come on. I am merely talking about documentation of the most obvious
> error condition;
No, you're assuming that these are obvious.
First, we tried really, really hard to get agreement on as much as we could,
and you are under-estimating what is "obvious".
Some things may have changed in the interim. So keep that in mind, too.
But also, some things were just not as obvious as you think.
On streams, in particular, we had a lot of conflicts. Vendors felt then
that things you probably think "obvious" would restrict their implementation.
Keep in mind there was very little experience with conditions at the time.
A lot of people rejected the condition system we have completely and I
had to do a HUGE sale to the community that we should have ANYTHING. The
condition system itself may seem obvious now but it was not then.
The only implementation that more than just ERROR, that had any condition
classes at all, was the Lisp Machine, and people kept saying it required
special purpose implementations. I had to write a portable implementation
and give it away to convince people. And even then they didn't believe it.
I kept saying "JUST LOAD THE CODE. REALLY. IT WORKS." It took years of
lobbying to get them to just load it and little by little they would trickle
in with phone calls saying "Uh, I finally loaded your code. You're right,
it doesn't take special hardware. Can we, uh, actually use that code?"
And I'd say "of course". [See the original proposal and original
implementation--actually, revision 18 of that, just to give you some idea
of how many iterations it went through before adoption, at my web site.]
And even then, when accepted into the standard, CLOS was also new. So
no one was sure that [and this was a HUGE sticking point] that multiple
inheritance was there for the long run. So the committee INSISTED that
no pre-defined error condition could rely on multiple inheritance. All
error classes we defined had to be ones that made sense in a single-inheritance
system. So we couldn't install the "obvious" things like many file conditions
because the only extant, working, tested implementation was Symbolics Genera,
and it relied heavily on multiple inheritance and did not want the standard
to break it, while other vendors didn't want to commit to multiple
inheritance. "file not found", just to take a point, can happen when a
network is down, as a temporary error. Or it can happen when the network
is up becasue of a permanent error of the file just not being there. Both
result in a file not being visible. It can also happen due to a directory
not being present. And some of these make assumptions about host file
systems, which implies agreeing on more details about pathnames than we may
have specified. Signaling that a host is down was something some people
wanted to do by specifying a host, which gets into whether a host is
a representable object or just a string--some wanted one, some another. And
that's another way to bog down a proposal. So there were legit points of
disagreement. But don't call this a lack of caring. Call it a legitimate
reason that there is not a standard.
Propose a standard now and maybe people will adopt it WHETHER OR NOT
you do it formally. Adoption won't come on comp.lang.lisp. It will come
by your one-by-one convincing vendors to care. comp.lang.lisp may put you
in touch with people who can help, but since "me, too" posts are discouraged
here, mostly you'll find dissent, not support in this venue.
> not some hugely complex and demanding process. I do understand
> that the Common Lisp spec does not include this (and I can certainly
> understand why). I was more "interested" in the general *tendench*; i.e., for
> a given API written by a random person or company, there tends to be a
> distinct lack of information on error conditions, even when they are very
> much relevant and likely to happen.
>
> I was more interested in "what am I missing? how do people write real
> programs under this condition?".
Most people don't write portable programs. They write semi-portable.
They write to one implementation. When they port, they add some #+/#-
conditionals. They try to isolate this into macros. e.g.,
(defmacro handling-sql-errors (&body forms)
#+LispWorks ...
#+Franz ....)
Each time they port, they elaborate these a bit.
It seems to me that MANY people when they encounter a porting issue
will write to comp.lang.lisp saying "how do i...". That seems
normal. Your post seemed, by contrast, to have been leading with a
broad allegation/conclusion of "lack of caring", which seemed to me
way off base. Which is why I reacted strongly. I think you just don't
understand the issue of "obviousd".
Nor did any of us, by the way. In 1984, Steele published CLTL.
In 1986, we all (the people who worked on CLTL) got together in Monterrey,
California (a beautiful venue, btw) and had a meeting about whether there
was anything that needed fixing. We found we had no way to "vote" because
there were many new people there and no way to consolidate opinions. In the
end, this is how we came to ANSI. But in the process, Steele had a page or
two document labeled "obvious" or "non-controversial" or some such. Something
on the order of magnitude of about 50 things, each a one-liner like
"Add a function XOR which is like AND and OR but does the obvious thing."
He was _sure_ that no one would object to these. Nearly every one was objected
to by someone. And from this, we all learned a lot about how much we had
in common.
Note well again: This didn't mean no one cared about these issues. Most
they did. But they wanted to address each in different ways.
It's the issue of non-caring that I snagged on in your posts. The language
cares a lot. The people care a lot. But consensus is hard to achieve in
a diverse community where people's care has led to use, and where change,
even change for the better, can break things.
> > Money, money, money. [...]
>
> I never mentioned money in my original post.
Money is just a way of accounting for the fact that things in the world cost.
You did mention things you wanted, and I mentioned that the reason you aren't
getting it is an issue of resource.
Do not assume I mean dollars, except as a tally. It takes time to do
everything. It takes time for me to write this. Be glad I'm not billing
you to answer this message. ;) But don't think it doesn't cost me to
answer it.
> I abhore [sic] binary-only distributions and the problems
> they create (practical problems, not some abstract ideological issue).
I personally prefer not to look at source, even when it's there.
I prefer to look at doc.
Which is what makes this whole discussion odd. You want doc, and
I agree with you.
But you seem to think it's not your responsibility to make or to pay for.
In my world, where people pay for software, you just say what you'd pay.
And you hope others are paying too, so the cost is spread over all of them.
In your world, where people give you stuff for free, I thought you
were supposed to contribute the doc that was missing, as your
contribution to the whole sharing thing. Or you contract a freeware
maintainer to add the doc that will then be free for others. Maybe I
misunderstand the social contract of freeware, but I thought that was
how it worked.
> If I want to be able to move between Linux, FreeBSD, NetBSD and DragonFly BSD for
> example, there is no commercial Lisp in existence, that I am aware of, that
> allows me to do that (other than HOPING that the lastest version will work in
> Linux emulation on the OS in question). I am mentioning those four OS:es because
> it is an actual example - I am using these OS:es and I would like to be able
> to run my own software on them.
By the way, again to help you with the history, CL was standardized
before the only operating systems in the world were linux, windows and
pc. We planned for about two dozen operating systems, all with
radically different file systems. This made it hard to get agreement
too. Maybe some agreement would be easier now.
But then, don't assume all progress is monotonic. Let's not plan on the
world never getting better, and on there never being a new operating system
in the future. So I hope the decisions we make won't be betting against
progress. (I think you can satisfy both needs. But care is required.)
> [context elided]
> Spoiled by Java? Not likely. Not in this context. See above - Java is NOT
> exactly my idea of a portable language
(another place I was confused by your presentation i guess. sorry)
> > I saw a thread where someone said he was charging $1/hr and wondered
> > if someone wanted to underbid him. That is the road to the death of
> > an industry. The problem right now is not that the US charges too
> > much, it's that the rest of the world charges too little. When their
> > standard of living comes up enough, and if people learn some sense and
> > stop making free software, then we CS people may be able to charge for
> > the value we provide. But as long as everyone is just scrambling for
> > enough to eat, and when they're not eating and not working they think
> > it's appropriate to just give stuff away, the bottom will be forever
> > gone from the market.
>
> Take it up with RMS :)
Heh. Don't think I haven't. And may yet again. Not that dealing with
him privately is of much value. Again, this is an issue of how to be
constructive.
(I rant about it sometimes here on comp.lang.lisp, but just to do
consciousness-raising. And I get email from people who thank me for
doing so, because a lot of people are on autopilot about it and had
not stopped to think about it. Or were thinking they were alone and
are glad to know someone else thinks the same. So I think it's not
pointless for me to do. But I have the realistic understanding that
my speaking about it doesn't solve the problem--it just creates a
consciousness.)
It's fine if all you want to do is raise consciousness, too, but if you
want to change something, you'll have to do something different. Just as
I will if I want to fix this free sofware thing...
> > You're one of a small number who periodically don't understand the
> > economics and so barks up the wrong tree, aggravating people who have
> > given you stuff for free, wishing they'd give you more for free.
>
> I'm not even going to address this.
Probably just as well. I phrased it badly. It's not like I know you
personally and I try to be more careful about my wording in such cases.
Sometimes people think I am overly verbose. And maybe sometimes they are
right. But sometimes the reason I run long is that I don't think that
sentences like "You seem like someone who..." should be shortened to
"You are someone who..." because it loses the sense that it's my opinion.
And here I slipped and left out a "seems", making it appear that this
was other than a statement about my perception. So I apologize for not
having been more long-winded. ;)
> I was not interested in the economical dynamics of the situation; I was
> merely using Java as a suitable "benchmark" when it came to documenting
> error conditions.
Hmm. I guess I'm not interested in the economic dynamics either... as
a first-order effect. I'm just compelled to notice that, interested
or not, economics are what drives us all, even those of us doing free
software. So we inevitably confront economics, like it or not.
When I first started answering questions here about the ANSI CL spec,
people would ask questions they thought were technical. "Why does x
happen?" or "Why did they make the foo function do this?" and they
would expect a technical answer. But the answer is not always
technical. Often it is not technical. It is often political. Or
economic. That's not because it's how I like to express it. It's not
because I'm an economics major. It's not because I'm money grubbing
or politically scheming. It's just because it's true, and the truth
is sometimes hard to avoid. And when you don't speak about truth, you
end up with weird superstition like "no one cares" filling in because
nothing else seems to make sense.
I'm reminded of a friend who has a running thing with his girlfriend
(I can't remember who has which side, and maybe it doesn't matter)
where one of them claims they "like x" but the other observes they
"never do x". The person says "I never have time." And the other
says says, "Well, I'm sorry, but if you never have time for x, it's
not reasonable to conclude you like it. You don't do it, so therefore
you don't like it." It frustrates the person terribly. It's a
legitimate philosophical question, I guess, whether you can like
things you never do. And I guess it touches on the question of
whether there is an economics of "to like". I don't think there is
necessarily consensus.
Ulrich Hobelmann
I think that's not really a fitting comparison. People don't go
to operas because it's not their kind of music. Reducing the cost
of opera tickets wouldn't change this significantly.
I was talking about reducing the costs of developing software
(through good tools), so that custom software is more affordable.
I think with custom software prices ARE the determining factor,
it's why people often choose to buy instead of build.
So I'm not saying there will always be crappy jobs for them; I'm
saying with lower cost there will be more good clients, too,
because most clients would rather build than buy, if it were
affordable. Most COTS software sucks quite badly, after all, and
forces organizations to adapt to the software, not vice versa.
Maybe these kind of programming jobs are what you would consider
muzack-like, but at least they're jobs. Programmers are free to
find other ways to earn money if they can. I definitely don't
intend to work in some other field, just because (you imply?)
there is no hope for programmers.
About you having belabored that point many times: something on
your website, or something specific I could google for?
Harald Hanche-Olsen
| Kent M Pitman wrote:
| > I'm not going to belabor the point. I've done that many times.
| > I just want to say that this remark above misses it.
| About you having belabored that point many times: something on your
| website, or something specific I could google for?
Look for a long thread on comp.lang.lisp entitled "Learning new
things" around mid-March 2003.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Engelke Eschner
>
> I think nice small applications (like a really good newsreader for the
> Mac) would be worth $10-20 for most people. It depends how much you
> want to make on software, and how many customers you can get.
Unison maybe? $24.95 at http://www.panic.com/unison/
I'm using and liking it.
Ulrich Hobelmann
> + Ulrich Hobelmann <u.hob...@web.de>:
>
> | Kent M Pitman wrote:
>
> | > I'm not going to belabor the point. I've done that many times.
> | > I just want to say that this remark above misses it.
>
> | About you having belabored that point many times: something on your
> | website, or something specific I could google for?
>
> Look for a long thread on comp.lang.lisp entitled "Learning new
> things" around mid-March 2003.
Thanks.
It's interesting that Kent cites Ayn Rand (I haven't read Atlas
shrugged, but The Fountainhead is good). I mostly agree with what
Americans would call economic conservatism (for Europeans:
liberalism), but still don't really understand his comment to my post:
"This is like saying to someone who wants to be a professional opera
singer "not to worry--there will always be advertising companies
wanting someone to belt out their stupid jingles, and there will
always be restaurants wanting to hire both the occasional live singer
or someone to record muzack for them". That's great for people who
find that fulfilling, but it misses the point. I'm not going to
belabor
the point. I've done that many times. I just want to say that this
remark above misses it."
Somewhere in that old thread he mentions that everything has to be
paid for by someone. That's exactly what I'm saying. Find
somebody who pays you if you want to be paid (I take that one for
granted). If the price is low enough and the product good,
someone will accept it. It's about money, not fulfillment.
Fulfillment is a personal thing, and for most people unrelated to
making money (unfortunately).
Anyway, there's probably no point in picking nits here. Kent has
his view, and I have mine :)
Ulrich Hobelmann
I'll give it a try, although I don't think I want to pay $25 for a
newsreader...
Peter Schuller
post came across very critical of Common Lisp (that is, the Common Lisp
standard). This was not my intent. While I did use the abscence of
certain error conditions in CL as an example, this is not the focal point
of my "frustration". I was reflecting over the situation in general with
most API:s that deal with external circumstances (and thus are expected
to fail). My original "complaint", if you will, was not specific to Lisp,
but is a general issue I have experience with a number of libraries/API:s
for several different languages. My reasons for using Common Lisp as an
example are simply that (1) this is comp.lang.lisp and (2) Common Lisp
is what I want to use for the projects I have in mind.
> Nothing could be farther from the truth. It was simply a HUGE project
> to be explicit on this and there was no money to do that project.
> We all wished for it, but none of us had access to the US Treasury's
> machine for printing money.
I won't debate the facts you are pointing out. But I will say that I did
not indend to critisize the CL standardisation effort. Even disregarding
any monetary or time based constraints, I can certainly understand the
lack of certain things in the CL spec; things that have become much more
important in "modern" times. In particular, I do understand that you
consider my comparison with Java unfair; but it was truly not meant to
critize Lisp as compared to Java. I used Java as an example because it
happens to be very representative of what I am after when it comes to
*this specific (and very narrow) issue*.
[ snipped some very interesting few paragraphs on the CL standardization process
that I loved reading, but do not have much to say aboue since I really was
never trying to argue against any of it ]
>> I am only interested in being able to handle *expected* conditions.
>
> I agree it's more work, but is there some reason "implementation-dependent"
> or even "implementation-defined" does not work?
No; it does work. My frustation was primarily based on the difficulty I have
experienced in finding *out* those implementation dependent details. I was
interested in what people *do* in practice, as I have not run / looked at a
lot (actually, pretty much none) Common Lisp applications intended for
end-users, where showing a debugger with available restarts is not acceptible.
I probably put too much emphasis on the portability issue, which I suppose
contributed to my entire post sounding very critical of CL.
[ vendors and their financing ]
> This is the part I'm struggling to understand--why you think that's not
> relevant.
Because I was not making a complaint against anybody in particular, nor
against library/API authors in general (even if I may have given that
impression). I was (and still am) truly more interested in how these issues
are solved, in general, in real-world Lisp applications.
But then, I don't really know of any such applications. Particularly none
that use the libraries/API:s that I have been looking at. Perhaps they
just don't exist.
> And, btw, when you use "corporation" do you mean to say you missed all those
> places where I noted that by vendor I always mean to include a maker
> of free software? (There needs to be some generic term for "supplier of
> an implementation", and I use the term "vendor" for that, usually trying to
> explicitly remark on my non-stnadard use of this term. Are you, likewise,
> using "corporation" in that non-standard way or are you reading past my
> parenthetical remarks about meaning to be thus inclusive and erroneously
> thinking thatI am talking only of commercial Lisps when I make these remarks?)
Sorry - that was my misstake. I was commenting under the impression that you
where "implying" (by saying I should talk to my vendor) that I should buy
a commercially supported Lisp or stop complaining.
>> Even assuming I am willing to pay for a commercial Lisp (which is no
>> great assumption I assure you, though at the moment I cannot afford
>> the fee required for the CL I was looking at possibly buying), there
>> is still the issue that any non-free CL is going to be restrictive
>> in terms of portability. That has nothing to do with money.
>
> The reason I'm assuming it does is that you're apparently concluding
> that you're not yourself part of the community. you're standing on
> the outside and not thinking that you yourself can change things.
> when you don't see something in the formal standard written and
> published over 10 years ago, you project the assumption (rightly or
> wrongly) that the community doesn't care and that nothing has
> happened since. take the bull by the horns. contact your vendor
> and ask. tell them what you would pay. get your friends to pony up
> money, too. i'm not saying pay for the whole thing UNLESS you find
> you're the only one asking. what I'm saying is that your fair share
> of the cost is
> x/y
> where
> x = cost of doing what you want
> y = number of people who want it enough to pay for it
It is really not about making somebody ("they") just magically fix it because
I want it. I was interested in current common practice.
As I have indicated I would have no trouble "fixing" whatever I feel needs
fixing, assuming I have the time and knowledge required. However since I am
still fairly new to CL, I would probably do a very lousy job of creating that
hypothetical "CLCL" I mentioned. In terms of learning CL, I am looking at
writing some useful applications *first*.
Taking what is already there and applying it to something I want is easier
than making a high-quality re-usable library. And the usefulness of said
application is not as much reduced by my (what I assume will be) suboptimal
code quality, as in the case of a useful library (because the latter by
definition requires a certain quality in order to be useful, while the
former is mostly dependent on the final end-user visible result).
> OR, if it's open source as you say, WRITE THE DOC yourself and give it to
> the vendor and say "Is this your intent for now and furture releases? If it
> is, maybe you could thus document it." and then go to the vendor you think
> that disagrees (causing non-portability) and tell them you care about
> portability and ask if they could compromise.
I could; but again I was probably do a lousy job for now given my lack of
CL experience.
(The best I can see myself doing until I have more CL experience is put together
some kind of informal list of "tips" for people in my position.)
> I don't have trouble with your claim that this needs to be done. I have
> trouble with your claim that no one cares. People DO care.
Again I would like to apologies if I gave this impression; it was not my intent.
> for having succeeded. People already know it, what they seek is a workable
> solution. Make one. Document something. Make your hobby-horse be getting
> everyone to adopt it, NOTWITHSTANDING the absence of a very cumbersome
> standards process to bless it. We don't need the blessing. We just need
> the accidental fact.
No reason why I won't try to do so in the future.
> No, i wasn't trying to make that point. I was trying to make the point that
> ERROR _is_ a documentation of every single condition that might arise.
>
> I'd prefer it if there were more fine grained names sometimes for the
> conditions that might get signaled, sure. But I diagree with the
> technical claim that we don't document what might get signaled. ERROR
> might get signaled. It might be called FILE-NOT-FOUND or
> NETWORK-INTERFACE-MISSING, but it's still ERROR. I'm not saying the
> problem you're having doesn't exist. I'm just saying that your
> on-and-off characterization of the error as "the error is not
> documented" is the wrong phrasing and is not helping your case, it's
> just confusing me into side-tracks of having to correct terminology.
>
>
> Writing
>
> (ERROR 'FILE-NOT-FOUND :NAME #P"/foo/bar")
>
> _is_ an implementation of "an error of type ERROR will be signaled."
But it's *mostly* useless implementation as compared to using a documented
more specific exception.
The problem is that most robust applications are not going to want to catch
*ALL* errors - other than to do some kind of emergency cleanup and logging the
occurrance as a likely software bug. Catching *ALL* errors because you know
the file creation or file reference might fail is not a good solution,
because any other errors that might get signalled as a result of bugs in
your own code (or code you call) will suddenly be treated as "file not
found". At best, this is confusing and difficult to debug after the fact. At
worst, it's disastrous.
> You might wish it said something more refined, but the problem is not
> not that the error isn't documented, it's that the error that is documented
> is not of an adequately specific type for you to allow you to distinguish
> it from other kinds of errors that you don't want to handle. This is a
> legitimate thing to want. It just needs to be spoken about properly as
> you ask for it.
This was exactly the point I was trying to make, and exemplify by the Java
comparison. Thank you for providing the short and disambiguous explanation
I should have used to begin with :)
> Your failure to use good error and type terminology makes it hard for
> me to answer you on-topic. And when I reply correcting your
> terminology, you think I'm saying I disagree with your cause, which I
> don't. I just can't talk about causes with incorrect terminology--it
> makes it appear I'm agreeing with false premises. [Sort of like the
> "have you stoppped beating your wife?" problem. You might or might
> not beat your wife, but if you don't, it's hard to have a discussion
> on the subject that begins with a false premise.]
Fair enough, and I certainly won't refuse admit that my phrasing and choice
of words is far from perfect.
>> I would be very interesting in doing so. Which site is that?
>
> http://www.nhplace.com/kent/Papers/
>
> look for the 1990 and 2001 papers on conditions.
Thanks; I will have a look!
> IO-ERROR is there, I think. It's spelled STREAM-ERROR, though.
> I don't think that's your problem in the specific. That doesn't mean
> there aren't missing specific condition classes, I just don't think
> this is the one. And in some cases maybe it doesn't say to use STREAM-ERROR
> though I bet a lot of times you can.
I will look into STREAM-ERROR; I was not aware of it.
>> Come on. I am merely talking about documentation of the most obvious
>> error condition;
>
> No, you're assuming that these are obvious.
I fully accept that some of the stuff I would want now would not be at all so
obvious a number of years ago when this stuff was being hashed out.
> Keep in mind there was very little experience with conditions at the time.
> A lot of people rejected the condition system we have completely and I
> had to do a HUGE sale to the community that we should have ANYTHING. The
> condition system itself may seem obvious now but it was not then.
I'm curious; what was the propsed alternative (if any)? (Given that checking for
error return code is pretty much out if you are to maintain any kind of
Lispish style)
This was a very interesting read; thank you. I think the above paragraphs
covered more about the origins of Common Lisp as a standard as it appears
today, than pretty much all material on CL that I have read.
Obviously I cannot disagree with or argue any of it.
> Propose a standard now and maybe people will adopt it WHETHER OR NOT
> you do it formally. Adoption won't come on comp.lang.lisp. It will come
> by your one-by-one convincing vendors to care. comp.lang.lisp may put you
> in touch with people who can help, but since "me, too" posts are discouraged
> here, mostly you'll find dissent, not support in this venue.
Point taken.
> Most people don't write portable programs. They write semi-portable.
> They write to one implementation. When they port, they add some #+/#-
> conditionals. They try to isolate this into macros. e.g.,
>
> (defmacro handling-sql-errors (&body forms)
> #+LispWorks ...
> #+Franz ....)
>
> Each time they port, they elaborate these a bit.
>
> It seems to me that MANY people when they encounter a porting issue
> will write to comp.lang.lisp saying "how do i...". That seems
> normal. Your post seemed, by contrast, to have been leading with a
> broad allegation/conclusion of "lack of caring", which seemed to me
> way off base. Which is why I reacted strongly. I think you just don't
> understand the issue of "obviousd".
Again - my apologies for coming off like that.
> Nor did any of us, by the way. In 1984, Steele published CLTL.
> In 1986, we all (the people who worked on CLTL) got together in Monterrey,
> California (a beautiful venue, btw) and had a meeting about whether there
> was anything that needed fixing. We found we had no way to "vote" because
> there were many new people there and no way to consolidate opinions. In the
> end, this is how we came to ANSI. But in the process, Steele had a page or
> two document labeled "obvious" or "non-controversial" or some such. Something
> on the order of magnitude of about 50 things, each a one-liner like
> "Add a function XOR which is like AND and OR but does the obvious thing."
> He was _sure_ that no one would object to these. Nearly every one was objected
> to by someone. And from this, we all learned a lot about how much we had
> in common.
>
> Note well again: This didn't mean no one cared about these issues. Most
> they did. But they wanted to address each in different ways.
>
> It's the issue of non-caring that I snagged on in your posts. The language
> cares a lot. The people care a lot. But consensus is hard to achieve in
> a diverse community where people's care has led to use, and where change,
> even change for the better, can break things.
Point also taken.
(This post is turning out to be pretty light on content, with me just agreeing...)
>> I abhore [sic] binary-only distributions and the problems
>> they create (practical problems, not some abstract ideological issue).
>
> I personally prefer not to look at source, even when it's there.
> I prefer to look at doc.
Even if I don't have any intention of looking at the source, typical
open source solutions tends to be more portable and less susceptible to
the "oh we (the platform people) changed the version of library X and
thus application Y (the binary distributino) was broken on this
platform for 5 months because it happened at a poor time in the
application's release cycle" syndrome.
(E.g., the mess that was some of Sun's releases of the JDK for Linux,
inspite of the resources Sun has at its disposal.)
> In your world, where people give you stuff for free, I thought you
> were supposed to contribute the doc that was missing, as your
> contribution to the whole sharing thing. Or you contract a freeware
> maintainer to add the doc that will then be free for others. Maybe I
> misunderstand the social contract of freeware, but I thought that was
> how it worked.
In the broadest of sense, sure. But for a specific situation there are
any number of reasons why a certain person X cannot contribyte Y to Z
even though said person would like to see Y in Z.\
> By the way, again to help you with the history, CL was standardized
> before the only operating systems in the world were linux, windows and
> pc. We planned for about two dozen operating systems, all with
> radically different file systems. This made it hard to get agreement
> too. Maybe some agreement would be easier now.
Absolutely. My comment about portability between OS:es above was mostly
in response to the pay-the-vendor-or-stop-complaining argument that I
*thought* you were making, but now realize you were not.
[ again, a lot snipped that probably deserve insightful answers,
but unfortunately I'm not up to the task ]
Don Geddis
>>>Consulting or coding on contract might be the best thing to do in the
>>>future.
> Kent M Pitman wrote:
>> That's great for people who find that fulfilling, but it misses the point.
>> I'm not going to belabor the point. I've done that many times.
Ulrich Hobelmann <u.hob...@web.de> wrote on Wed, 27 Apr 2005:
> Maybe these kind of programming jobs are what you would consider muzack-like,
> but at least they're jobs. Programmers are free to find other ways to earn
> money if they can.
> About you having belabored that point many times: something on your website,
> or something specific I could google for?
Kent has written many times in the past (on comp.lang.lisp, among other places)
about some negative consequences of the free software movement.
Perhaps Kent will answer himself, but just for kicks let me put some words
in his mouth:
Kent wants to design new complex software, implement it, and sell it for a
premium price. Before the rise of free software, this was a feasible business
model, and would result in good wages for the programmer. These days, Kent
has to compete with free software offerings. Even if Kent's software is 10-20%
better on some metric, he won't find enough customers at a high enough price
to pay for his development. Whereas, before free software, the competitive
software was produced by organizations that had to recoup their costs, and
Kent could earn a nice living producing higher quality software for slightly
higher prices.
Kent is lamenting the fact that he can no longer do the kind of work that he
used to be able to do. Your response is that there are different jobs he
could do that also involve programming. You see how you are talking past him?
His complaint is that he wants to continue doing his old programming job,
and he (partially) blames free software for eliminating that job. You've
addressed neither his lack of opportunity to do the kind of programming he
wants, nor even his inference that free software is to blame.
So Kent had little to respond to you, because your comments didn't really
address his topic.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ d...@geddis.org
If a woman has to choose between catching a fly ball and saving an infant's
life, she will choose to save the infant's life without even considering if
there are men on base. -- Dave Barry
Kent M Pitman
> > Kent M Pitman wrote:
> >> That's great for people who find that fulfilling, but it misses the point.
> >> I'm not going to belabor the point. I've done that many times.
>
> Kent has written many times in the past (on comp.lang.lisp, among
> other places) about some negative consequences of the free software
> movement.
>
> Perhaps Kent will answer himself, but just for kicks let me put some words
> in his mouth: [...]
Hey, I'll go with those words, Don. Maybe not quite as rambly as I'd have
been -- and Kent usually isn't so Bob Dole-like as to write all of Kent's
remarks in third peson, but still... not bad. Thanks!
Ulrich Hobelmann
> Kent wants to design new complex software, implement it, and sell it for a
> premium price. Before the rise of free software, this was a feasible business
> model, and would result in good wages for the programmer. These days, Kent
> has to compete with free software offerings. Even if Kent's software is 10-20%
> better on some metric, he won't find enough customers at a high enough price
> to pay for his development. Whereas, before free software, the competitive
> software was produced by organizations that had to recoup their costs, and
> Kent could earn a nice living producing higher quality software for slightly
> higher prices.
I know. I'd also like to pursue the same kind of business
someday, and I share your feelings about open-source lowering the
prices of software, so that this business model is much harder today.
But hey, you can't change the world. As I wrote, it will be
interesting how a company like Opera will fare in the browser
market. And I also say again, that making tools better and
cheaper, there might be a possibility to still compete with
open-source.
> Kent is lamenting the fact that he can no longer do the kind of work that he
> used to be able to do. Your response is that there are different jobs he
> could do that also involve programming. You see how you are talking past him?
I didn't know what plans Kent had, so talking past him wasn't
intentional. I wrote "Consulting or coding on contract might be
the best thing to do in the future." in the sense that you create
software for money. Unlike the writing first and trying to sell,
you already made the sale (of your expertise) and then write the
software. I agree that it's not that fulfilling, but maybe I
won't be able to choose if I want a programming job.
> His complaint is that he wants to continue doing his old programming job,
> and he (partially) blames free software for eliminating that job. You've
> addressed neither his lack of opportunity to do the kind of programming he
> wants, nor even his inference that free software is to blame.
There's still lots of commercial software around that people pay
for, but I agree that the costs for an individual to compete with
open-source are sadly quite high.
In that sense we should even be thankful that the programmer
hordes don't use Lisp, so that we have a better amplifier for our
programming power then they do. Again: better tools lower the
cost of development, so competing is easier (either by lowering
the sale price, or by writing software that's much better than
theirs).
> So Kent had little to respond to you, because your comments didn't really
> address his topic.
True, because I didn't really know what his situation is. I share
the feelings, but there's nothing I can do about it, so I just
take it for granted...
Matthias Buelow
> But hey, you can't change the world. As I wrote, it will be interesting
> how a company like Opera will fare in the browser market. And I also
> say again, that making tools better and cheaper, there might be a
> possibility to still compete with open-source.
I think for end-consumer software that's a failing business model.
Who'd pay for a browser or mail reader? I'd never _use_ a mail reader
that wasn't open source, for obvious reasons (I've used many in the past
10+ years and they were all free software, which you had to compile
yourself). I'd wish software like Skype was not just "free" but
open-source so I could see for myself that it isn't the spyware one has
come to know from those guys. But at least it's free. Who's using
proprietary software? Well, large companies do. With special-purpose
business solutions. If you want something special, you have to pay.
That's a valid market for commercial, closed-source software. And
perhaps games. The rest isn't, anymore.
mkb.
Christopher C. Stacy
> Ulrich Hobelmann wrote:
>
> > But hey, you can't change the world. As I wrote, it will be interesting
> > how a company like Opera will fare in the browser market. And I also
> > say again, that making tools better and cheaper, there might be a
> > possibility to still compete with open-source.
> I think for end-consumer software that's a failing business model.
> Who'd pay for a browser or mail reader?
End-consumers.
> I'd never _use_ a mail reader that wasn't open source
End-consumers don't know what "source" is, and have no interest in it
> Who's using proprietary software?
All end-consumers.
All corporations.
> If you want something special, you have to pay.
> That's a valid market for commercial, closed-source software.
"Valid" market? What's that?
Ulrich Hobelmann
>>I think for end-consumer software that's a failing business model.
>>Who'd pay for a browser or mail reader?
>
>
> End-consumers.
Probably not. They have that software bundled with their system,
and it's already hard enough to use for them. They won't go
looking for another solution.
A meager 5% of Windowlers use Firefox now (estimated; I read that
all Mozilla Browsers on all platforms have almost 10% market share
now), and that's free, open, and cross-platform.
>>I'd never _use_ a mail reader that wasn't open source
>
>
> End-consumers don't know what "source" is, and have no interest in it
True. While I prefer my stuff being open-source, I also use some
of Apple's software. Well, not Mail, since it has no newsreader.
>>Who's using proprietary software?
>
>
> All end-consumers.
> All corporations.
Yes, but end-consumers expect everything to come with their PC.
They don't even consider looking for an OS (that's why they all
end up with a PC and a worm-ridded OS). Maybe they'll buy Office,
but OpenOffice has a much better price tag.
>>If you want something special, you have to pay.
>>That's a valid market for commercial, closed-source software.
>
>
> "Valid" market? What's that?
One where people actually pay you I suppose.
It looks like people don't pay for software anymore, but for
stupid ringtones for their phones, and for stupid little games.
Or maybe that's just the kids (mind-wise, includes many people
over 20), I don't know.
I'm hoping that there are enough other people out there, the kind
that enthuses when a new Mac OS comes out, the kind that actually
gets excited about good software, the kind that pays for it.
Maybe it's a good niche market, if the development cost can be
kept low.
Christopher C. Stacy
> Christopher C. Stacy wrote:
> >>I think for end-consumer software that's a failing business model.
> >>Who'd pay for a browser or mail reader?
> > End-consumers.
>
> Probably not. They have that software bundled with their system
which they paid for.
> it's already hard enough to use for them.
I don't know what that means. You're beginning to
sound like some kind of deranged Linux idiot.
Windows is WAY FUCKING EASIER and WAY LESS BUGGY for home users.
Someday it might be different, but wishful thinking will not change it.
I will not debate that point with you. If you don't agree,
then we live in different worlds, and that's that.
> They won't go looking for another solution.
Everyone that I know has purchased third-party end-user software.
Usually, lots of it.
As for browsers and mailers, some of them purchased Opera,
but I think that IE, Safari (both of which are proprietary,
and paid-for) and Firefox will dominate the market.
Lots of them have purchased Eudora, which is much better
than the Mozilla offering. Of course, most people use Outlook Express,
or in the corporate environment (and on their laptops): Outlook
> A meager 5% of Windowlers use Firefox now (estimated; I read that all
> Mozilla Browsers on all platforms have almost 10% market share now),
> and that's free, open, and cross-platform.
So what?
I didn't say that nobody uses free software.
I said that everybody uses proprietary software.
> >>I'd never _use_ a mail reader that wasn't open source
> > End-consumers don't know what "source" is, and have no interest in it
>
> True. While I prefer my stuff being open-source, I also use some of
> Apple's software. Well, not Mail, since it has no newsreader.
>
> >>Who's using proprietary software?
> > All end-consumers.
> > All corporations.
>
> Yes, but end-consumers expect everything to come with their PC.
No, they go to Micro Center and CompUSA and buy tons
of software, every day. It's a big business.
> They don't even consider looking for an OS (that's why they all end
> up with a PC and a worm-ridded OS). Maybe they'll buy Office, but
> OpenOffice has a much better price tag.
OpenOffice is a crappy second-rate replacement for MS Office.
Maybe it will get better someday.
> >>If you want something special, you have to pay.
> >>That's a valid market for commercial, closed-source software.
> > "Valid" market? What's that?
>
> One where people actually pay you I suppose.
Do you not have lots of "computer stores" where you live?
Here in the USA, we have them in every mall, and strip mall.
They sell software.
Kent M Pitman
> But hey, you can't change the world.
[Why do people say phrases like this as if they were undeniably true without
questioning the self-fulfilling prophecies they contain?]
No, but you can tell people when the world is not going how it should
be and you can yourself choose a path compatible with what you'd like.
There's a difference between failing to recognize the limits of your
power and failing to recognize the need to exercise the power you do
have. None of us can elect a president, but we can be sure that if we
don't go to the voting booth, the one we want will not get elected on
his own. You've got to behave as if your part matters.
So when I see things going awry, I speak and behave in ways intended
to make an effect.
Not to change the subject utterly, but there's a lot about modern
morality that has gone awry. I'm not recommending a return to
Victorian values, but I do think that Robert Reich hits in on the nose
in his recent "Reason: Why Liberals will win the Battle for America"
when he points out that while he doesn't agree with the Republicans
about their choice of values, he thinks they are on the mark in at
least talking about values. And that people ought not confuse a
society of "tolerance" with a society of "accepting anything". Even
in a tolerant society, there needs to be a difference between the
acceptable and the unacceptable, the desirable and the undesirable.
Otherwise, things will just drift unchecked in ways no one wants.
> > So Kent had little to respond to you, because your comments didn't really
> > address his topic.
>
> True, because I didn't really know what his situation is. I share the
> feelings, but there's nothing I can do about it, so I just take it for
> granted...
Nonsense. You can't fix the problem yourself, but you can have an incremental
effect. There is something you can do. When someone offers you something
for free, offer to pay them for the value you get. Tell them to charge
people rather than give away value.
I had a neighbor who used to cut my lawn for free sometimes when he was out.
I would still pay him. I told him if he wanted he could save the money and
buy back a service from me sometime. But having this done in money, and not
in "traded favors", means he can buy food or something else instead of my
personal services if he chooses. That's all money is--a reminder of good
deeds done in some form that allows you to trade with people other than the
one who did you the service or you did the service for.
When someone asks something free of you, ask a reasonable price.
There's nothing wrong with getting paid. There's nothing wrong with
having money. And don't kid yourself, there are times in your life
when you'll need it.
Jon Boone
> But hey, you can't change the world.
I observe many things about the world that change. I would think
that you do too. So, I don't think you mean to say the world
doesn't change.
Do you mean to say that you can't control how the world changes?
--jon
Ulrich Hobelmann
> Ulrich Hobelmann <u.hob...@web.de> writes:
>
>
>>Christopher C. Stacy wrote:
>>
>>>>I think for end-consumer software that's a failing business model.
>>>>Who'd pay for a browser or mail reader?
>>>
>>>End-consumers.
>>
>>Probably not. They have that software bundled with their system
>
>
> which they paid for.
Sure, but they don't notice it, since it comes with the PC.
>
>>it's already hard enough to use for them.
>
>
> I don't know what that means. You're beginning to
> sound like some kind of deranged Linux idiot.
> Windows is WAY FUCKING EASIER and WAY LESS BUGGY for home users.
Calm down, ok? When I started using Windows (98) I was appalled
by its weirdness. I started using Linux shortly after that and
while installing it might take some expertise, I found the UI more
consistent. To configure *anything* on Windows you often need to
be an expert. My friends *always* call a CS student when they
need to do anything on their machine. I got my dad a Centrino
laptop with XP and he also can't do anything with it. Ok, that's
my dad...
I switched to a Mac in Winter '03, and regret having gotten a
Windows machine for my dad. I thought more mainstream would be
better. Well...
> Someday it might be different, but wishful thinking will not change it.
> I will not debate that point with you. If you don't agree,
> then we live in different worlds, and that's that.
I never said I want to debate about Linux (which after all is used
by deranged idiots, in your perception). Different worlds, yes,
obviously.
>>They won't go looking for another solution.
>
>
> Everyone that I know has purchased third-party end-user software.
> Usually, lots of it.
The people I know (ok, the majority students) use mostly freeware.
The ones that got their machine custom-built (again, by CS
students) use illegal copies of XP in most cases. Because they
want, not because the student talked them into it.
> As for browsers and mailers, some of them purchased Opera,
> but I think that IE, Safari (both of which are proprietary,
> and paid-for) and Firefox will dominate the market.
Yes.
> Lots of them have purchased Eudora, which is much better
> than the Mozilla offering. Of course, most people use Outlook Express,
> or in the corporate environment (and on their laptops): Outlook
Interesting. I haven't seen any Eudora for about 7 years, and
that was on our high school mac (system 7?). Can't really
remember what it was like. Most people I know use Outlook. The
computer people use Thunderbird.
>>A meager 5% of Windowlers use Firefox now (estimated; I read that all
>>Mozilla Browsers on all platforms have almost 10% market share now),
>>and that's free, open, and cross-platform.
>
>
> So what?
>
> I didn't say that nobody uses free software.
> I said that everybody uses proprietary software.
Ok, I misinterpreted it.
>>Yes, but end-consumers expect everything to come with their PC.
>
>
> No, they go to Micro Center and CompUSA and buy tons
> of software, every day. It's a big business.
Ok, maybe my perception there is skewed. Poor students don't
spend much money anyway. Maybe the USA is different from Germany
in that respect, too.
>>They don't even consider looking for an OS (that's why they all end
>>up with a PC and a worm-ridded OS). Maybe they'll buy Office, but
>>OpenOffice has a much better price tag.
>
>
> OpenOffice is a crappy second-rate replacement for MS Office.
> Maybe it will get better someday.
It's crappy, and I only use it to read ppt and doc files.
I doubt that MS Office is much more usable, though (Sun sells OO
as Star Office, after all). Office suites in general are full of
UI complexity, far too much for me being able to use them for
about anything.
The people I know who use OO don't complain, BTW.
>>>>If you want something special, you have to pay.
>>>>That's a valid market for commercial, closed-source software.
>>>
>>>"Valid" market? What's that?
>>
>>One where people actually pay you I suppose.
>
>
> Do you not have lots of "computer stores" where you live?
> Here in the USA, we have them in every mall, and strip mall.
> They sell software.
In Germany there's many more small computer stores. The big malls
and department stores also have software corners, but I don't
really know if people buy lots of stuff there. I don't see people
using a really wide range of software.
Ulrich Hobelmann
> So when I see things going awry, I speak and behave in ways intended
> to make an effect.
Sure, better than not doing that.
> Not to change the subject utterly, but there's a lot about modern
> morality that has gone awry. I'm not recommending a return to
> Victorian values, but I do think that Robert Reich hits in on the nose
> in his recent "Reason: Why Liberals will win the Battle for America"
> when he points out that while he doesn't agree with the Republicans
> about their choice of values, he thinks they are on the mark in at
> least talking about values. And that people ought not confuse a
> society of "tolerance" with a society of "accepting anything". Even
> in a tolerant society, there needs to be a difference between the
> acceptable and the unacceptable, the desirable and the undesirable.
> Otherwise, things will just drift unchecked in ways no one wants.
Unfortunately people in our modern democracy don't care about
anything anymore (how many people go vote?). Well, except that
new (stupid) morality wave from those who call themselves
neo"conservatives". We ought to have positive values (honesty,
reliability, being on time, having a consistent opinion...),
instead of all this crap about saying that everyone who isn't 100%
pro-life or for the war, or against stem cell research is a bad
person. A tolerant government wouldn't constantly tell people
what's good or bad. We have churches and/or a common sense for that.
I hope liberals will make some ground in the US, but only because
there's way too many people almost starving and because I hope the
neoconses will make way for good old cons (hehe; maybe the world
needs garbage collection). But I'm only a libertarian minority...
> Nonsense. You can't fix the problem yourself, but you can have an incremental
> effect. There is something you can do. When someone offers you something
> for free, offer to pay them for the value you get. Tell them to charge
> people rather than give away value.
In my dorm usually fixing PCs involves getting a dinner cooked :)
I don't participate in that anymore, though; too much work/time
for the price, IMHO.
> When someone asks something free of you, ask a reasonable price.
Good idea. Even micropayments might make some sense. Among
friends it's kind of weird to ask for money though, since we
usually invite each other for a beer or two anyway.
> There's nothing wrong with getting paid. There's nothing wrong with
> having money. And don't kid yourself, there are times in your life
> when you'll need it.
I never said anything against money, did I?
Ulrich Hobelmann
> I observe many things about the world that change. I would think
> that you do too. So, I don't think you mean to say the world
> doesn't change.
It certainly does change, but it's hard to control that on your own.
> Do you mean to say that you can't control how the world changes?
Yes. I think there so much noise out there that talking usually
doesn't change anything. Just like demonstrations never do
anything, and the people doing them should rather make money in
that time and use that for some *real* changes.
I'm more for living my life the way I think is right, and then
hoping people will catch on.
(still hoping I might get rich someday, so I can actually have
more influence)
Larry Clapp
> Harald Hanche-Olsen wrote:
>> + Ulrich Hobelmann <u.hob...@web.de>:
>>
>> | Kent M Pitman wrote:
>> | > I'm not going to belabor the point. I've done that many times.
>> | > I just want to say that this remark above misses it.
>>
>> | About you having belabored that point many times: something on your
>> | website, or something specific I could google for?
>>
>> Look for a long thread on comp.lang.lisp entitled "Learning new
>> things" around mid-March 2003.
>
> paid for by someone. That's exactly what I'm saying. Find somebody
> who pays you if you want to be paid (I take that one for granted).
> If the price is low enough and the product good, someone will accept
> it. It's about money, not fulfillment. Fulfillment is a personal
> thing, and for most people unrelated to making money
> (unfortunately).
I think part of Kent's point comes in the realm of writing commercial
software. I would rather write a product once and sell it many times
than sell my time. Open Source/Free/What Have You software makes that
harder by driving down the acceptable cost of commercial products.
I don't really consider Kent's opera analogy all that apt, in this
case. I think perhaps a more apt analogy (and it's only an analogy)
would be to say to Stephen King, "The Internet has made commercial
books obsolete; too many people put up their content for free.
However, some people will pay you to come to their houses and recite
your work." Sure, maybe he could make a living at it, but I bet he'd
rather write a book once and sell it many times, in part because, if
he stops doing public performances, his income stream stops; if he
stops writing books, his income stream will continue.
[ Insert the name of any author for Stephen King, even an unsuccessful
one. The identity of the author has no bearing on the analogy. The
analogy speaks to cash flow and the relative ease of maintaining it
given two different distribution media. ]
To belabor the point: I have a limited amount of time. If I sell my
hours for dollars, my dollars are fundamentally limited. If I invest
my hours in creating a product, and then sell the product, my dollars
are much less fundamentally limited. In both cases my skill and other
factors limit my dollars, but only in one case do I have to keep
exhibiting my skill day after day after day after day after day.
Just my $0.02.
-- Larry
Nicolas Neuss
> Kent wants to design new complex software, implement it, and sell it for
> a premium price. Before the rise of free software, this was a feasible
> business model, and would result in good wages for the programmer. These
> days, Kent has to compete with free software offerings. Even if Kent's
> software is 10-20% better on some metric, he won't find enough customers
> at a high enough price to pay for his development. Whereas, before free
> software, the competitive software was produced by organizations that had
> to recoup their costs, and Kent could earn a nice living producing higher
> quality software for slightly higher prices.
Unfortunately, there is a problem with this argumentation. Software is
getting more and more complex and the cost of building up something
interesting takes more and more resources. This leads to a concentration
process which can be observed everywhere in our economy (larger companies
buying smaller concurrents)[*]. Without free software, there would be some
point when even Kent could only achieve results working as a small wheel
inside a large company as Microsoft, Oracle, etc... I doubt that this
would give him the satisfaction he longs for. With free software at hand,
there is at least some chance that a small group of people can put
something reasonable together which can compete against those large
companies.[+]
Kent's writing had indeed quite an impact on my view of free software, but
I still think that the world would be worse without it.
Nicolas.
[*] There are probably better examples, but here are some from software
technology which come to my mind: the CAS market dominated by
Mathematica/Maple (and seeing a strange limbo of Macsyma), maybe CAD
systems, maybe also simulation software. Also the market for operating
systems could very well be Microsoft-only without free software
(Linux/BSD/Hurd).
[+] GPL/BSD-licensing comment skipped, because I think that there is no
final answer also for this issue.
Tayssir John Gabbour
> Not to change the subject utterly, but there's a lot about modern
> morality that has gone awry. I'm not recommending a return to
> Victorian values, but I do think that Robert Reich hits in on the
> nose in his recent "Reason: Why Liberals will win the Battle for
> America" when he points out that while he doesn't agree with the
> Republicans about their choice of values, he thinks they are on the
> mark in at least talking about values. And that people ought not
> confuse a society of "tolerance" with a society of "accepting
> anything". Even in a tolerant society, there needs to be a
> difference between the acceptable and the unacceptable, the
> desirable and the undesirable. Otherwise, things will just drift
> unchecked in ways no one wants.
Robert Reich was interviewed by a BBC documentary called The Century of
Self. He helped explain why our bonds of community are much weaker than
before.
http://www.thecorporation.com/phpBB2/viewtopic.php?t=587
They claim that we've transitioned to a free market morality, every man
for herself; and politicians now pander to a small bloc of swing
voters.
> Nonsense. You can't fix the problem yourself, but you can have an
> incremental effect. There is something you can do. When someone
> offers you something for free, offer to pay them for the value you
> get. Tell them to charge people rather than give away value.
I'm curious what you think of technology automating away many
manufacturing jobs, destabilizing their wages and pushing them to
service jobs. This is not a "drive-by" question; I am honestly curious.
> When someone asks something free of you, ask a reasonable price.
>
> There's nothing wrong with getting paid. There's nothing wrong
> with having money. And don't kid yourself, there are times in
> your life when you'll need it.
True, money is only lubrication, to match up consumers and producers.
However, we seem to have the Java of monetary systems. And the
mechanism of controlling money appears outside our democratic control.
The function of the taxpayer has been to heavily subsidize research.
But not to subsidize production. If we lived in a serious democracy
where the citizenry did more than poke a chad every 4 years, taxpayers
would likely sponsor production of free software. Just as we provide
stable subsidies for (say) Lockheed-Martin to administer parking meters
and welfare-to-work programs.
Changing the subject, Jans Aasman of Franz explained this weekend that
Franz has been growing and increasingly able to utilize its engineering
department. I suspect free software has been BENEFICIAL to Franz's
business model. At least I have seen remarkably few people discuss this
fundamental issue seriously.
Bulent Murtezaoglu
TJG> [...] If we lived in a
TJG> serious democracy where the citizenry did more than poke a
TJG> chad every 4 years, taxpayers would likely sponsor production
TJG> of free software. [...]
Donations to FSF or SPI etc. _are_ tax-deductible in the US. I am
unsure what the 'serious democracy' locution means, but I imagine a
good sense of the headcount could be arrived at by looking at how many
people donated to these non-profits. For those who believe these
subsidies are a good idea, he obvious thing to do would be to convince
more people to donate and thus indirectly cause others (who don't want
to or care to pay) to pay. A probable side benefit of this scheme,
for people who like reading KMP's prose, would be provoking him to
explain to us why he'd prefer getting paid for the work he does by the
ones who actually buy it than through some allocation scheme that
effectively decouples producers from consumers. (Hmm or maybe not?
Perhaps I am being presumptuous?)
cheers,
BM
Paul Foley
> Robert Reich was interviewed by a BBC documentary called The Century of
> Self. He helped explain why our bonds of community are much weaker than
> before.
> http://www.thecorporation.com/phpBB2/viewtopic.php?t=587
> They claim that we've transitioned to a free market morality, every man
> for herself; and politicians now pander to a small bloc of swing
> voters.
What you're describing is "democratic morality" -- the polar opposite
of "free market morality". [I guess the closest thing you'd find to a
true "free market morality" would be in the relatively free-market
19th century -- precisely the time you're claiming our "bonds of
community" are now weaker than!]
Highly recommended reading on the same theme: Hans-Hermann Hoppe's
_Democracy: The God that Failed_
(http://www.amazon.com/exec/obidos/ASIN/0765808684 -- introduction
online at http://www.mises.org/hoppeintro.asp)
> True, money is only lubrication, to match up consumers and producers.
> However, we seem to have the Java of monetary systems. And the
More like the INTERCAL of monetary systems.
Without enough "please"s in the program.
> mechanism of controlling money appears outside our democratic control.
Bah. We can only wish.
--
If that makes any sense to you, you have a big problem.
-- C. Durance, Computer Science 234
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))
Tayssir John Gabbour
> >>>>> "TJG" == Tayssir John Gabbour <tayss...@yahoo.com> writes:
> TJG> [...] If we lived in a
> TJG> serious democracy where the citizenry did more than poke a
> TJG> chad every 4 years, taxpayers would likely sponsor
>
> Donations to FSF or SPI etc. _are_ tax-deductible in the US. I am
> unsure what the 'serious democracy' locution means,
Those who study the founding of America know that we don't have a
democracy, though there are democratic principles at work. Respectfully
speaking, I won't say any more on this because this is flamewar
material and people who really care have the entire internet to learn
further.
The free software problem is a deep one, and Kent is correct in
pointing out some of the problems. In fact, there are parallels with
manufacturing industries. While I spoke in global terms, I do not think
there is a central global solution. Nor is the solution a simple or
obvious master stroke.
Just as hundreds of people have wasted unbelievable amounts of time
debating Lisp vs. static typechecking, I do not want to reduce this to
X vs. Y. "He is wrong" vs. "He is right."
Bulent Murtezaoglu
TJG> did more than poke a chad every 4 years, taxpayers would
TJG> likely sponsor production of free software. [...]
BM> Donations to FSF or SPI etc. _are_ tax-deductible in the US. I
BM> am unsure what the 'serious democracy' locution means,
TJG> Those who study the founding of America know that we don't
TJG> have a democracy, though there are democratic principles at
TJG> work. [...]
Oh I believe I do more or less understand what the founders intended
over there, what I was unclear on is the nature of the proposed
replacement as it pertains to public funding for software. Arguably
OT here, but is that still flamewar material?
cheers,
BM
Tayssir John Gabbour
> On 28 Apr 2005 06:44:24 -0700, Tayssir John Gabbour wrote:
> > Century of Self. He helped explain why our bonds of
> > community are much weaker than before.
> > http://www.thecorporation.com/phpBB2/viewtopic.php?t=587
>
> > They claim that we've transitioned to a free market morality,
> > every man for herself; and politicians now pander to a small
> > bloc of swing voters.
>
> opposite of "free market morality". [I guess the closest thing
> you'd find to a true "free market morality" would be in the
> relatively free-market 19th century -- precisely the time
>
> Highly recommended reading on the same theme: Hans-Hermann Hoppe's
> _Democracy: The God that Failed_
> (http://www.amazon.com/exec/obidos/ASIN/0765808684 -- introduction
> online at http://www.mises.org/hoppeintro.asp)
Paul, we talked privately about this once.
I retract my last few paragraphs in my reply to Kent. It was foolish to
bring up a line of discussion which predictably would result in
pie-in-the-sky abstract debate. If you and I agree that our monetary
system is messed up, no matter what either of us think is the cause,
that is sufficient. In the same way, I retract and regret every single
time I've taken part in a static vs. dynamic typechecking debate.
I will not mention further any ideology that might hold anyone back
from viewing this problem thoughtfully.
Tayssir John Gabbour
> BM> Donations to FSF or SPI etc. _are_ tax-deductible in the US.
>
> TJG> Those who study the founding of America know that we don't
> TJG> have a democracy, though there are democratic principles at
> TJG> work. [...]
>
> Oh I believe I do more or less understand what the founders intended
> over there, what I was unclear on is the nature of the proposed
> replacement as it pertains to public funding for software. Arguably
> OT here, but is that still flamewar material?
That was only idle speculation on my part, and retract it. Its only
purpose was as an example, but on further reflection it's just a
landmine that diverts attention away from the serious issue.
I give up; it is too frustrating to communicate in this medium, which
has much less bandwidth than face-to-face.
Jon Boone
> With free software at hand, there is at least some chance that a
> small group of people can put something reasonable together which
> can compete against those large companies.
Putting aside patents, trade secrets and copyright issues, it
seems as if you are saying that you believe that the only ways to
avoid being a cog in a corporate machine are:
1. Sell your time (i.e. a service-oriented business model).
2. Try to produce a competitive product.
I can see how "free" software helps with #1 - there's plenty of
"make work" involved with supporting a lot of free software
packages, even when they "work" relatively well.
What isn't so clear is how it assists with #2. If your business
model is to put out the same crap (as the corporate machine) for
less $$$$, then I will conceed that it is at least theoretically
of assistance. Scieneer (based on cmucl) might be a good example,
although i'm not sure how well it compares against those corporate
behemoths Franz and Lispworks (or whomever they view as their
competition).
I know a bit about new product development (both from academic
classes and from work experience). In my opinion, there are three
basic ways to obtain market share:
1. Produce an "alternative" product that is "just as good as the
competition - only cheaper". This "loss leader" strategy can
sometimes be a good way to gain marketshare. However, it is a
very expensive way to do so - and can even undermine the
financial basis of the market itself. Hence, this strategy
can be a component of a business plan, but not the basis of
it.
2. Produce an "alternative" product that is "just as good" as the
competition and then focus on growing the market. This can
work for a while, but it does eventually reach the point of
diminishing returns as market penetration approaches 100% (or
worse, growth stagnates or even reverses as in the AI
winter). This is less expensive than the 1st strategy, and
more stable, but is still insufficient as the basis for a
long-term plan.
3. Produce an "innovative" product. Innovation is difficult to
do correctly, but if you can pull it off, you can score a real
coup. Sometimes you can create a market that didn't exist
before (bonus!). Sometimes you can transform the way a market
operates. Sometimes you just win big.
Innovation is also expensive, which is why companies tend to
cycle through periods where they innovate and then periods
when they coast (or stagnate). Because it is so difficult, it
is not a sufficient basis for a business plan.
A good business plan has to be based on all three of these
strategies, in the right proportion (depending on market
conditions, captial reserves, etc.).
I can see "free" software helping with 1. Someone else does the
heavy lifting (whoever produced the software) - and you use their
effort to put your competition out of business. Just try not to
put yourself out of business in the process...
I can see "free" software helping with 2. Someone else does the
heavy lifting (whoever produced the software) - and you add your
financial resources to grow the market.
I don't see "free" software helping significantly with 3. Most
of the free software that I am familiar with is simply a
re-implementation of something someone else has already done.
Occasionally, there is an innovative feature added, but the
fundamental application is typically not very innovative. (There
are, I assume, exceptions to this, but I probably don't use them
much).
What am I missing?
To wrap up, I (and I believe Kent) consider the effectiveness with
which Dell commoditized the PC hardware vending business to be a
warning sign to those who are interested in being software
vendors. The concern is that "free" software has the same effect
on the software vending market that Dell has had on the PC vending
market. If you want to be (or already are) a software vendor,
this is a reasonable concern (even if happens to not be true at
this time, as markets are not a static thing).
If you just want to be a programmer, then don't worry. "Free"
software is your friend (and probably always will be).
If you just want to be a consultant (e.g. a service vendor),
then don't worry. "Free" software can be your friend (or your
worst nightmare...).
If you just want to be a consumer of computing-related goods and
services, then don't worry. "Free" software is your friend (so
far).
--jon
Kent M Pitman
Absolutely.
I have not said that free software is bad. I have said that it is
a problem, and certainly NOT a panacea.
The problem I have with it is that people assume that anything they write
for free is automatically "good". This is like the church telling people
that any time they deny an abortion to a young girl, they have "enabled"
life. It simply isn't as simple as that. Sometimes abortions are safer
medically than bearing a baby. Sometimes people denied medical abortions
will resort to coathangers and die themselves in addition. And sometimes
unwanted babies will grow up to be unwanted by society, and will work against
rather than for society, perhaps even to stealing and killing for their own
survival. The equation is simply not that simple. Even the present battle
in the US over notification is not as cut and dried as some would have it be.
Some parents, when notified, will beat their children and do worse to them
than anything they were planning to do themselves.
I raise this issue not just because it's bugging me on a daily basis
as I sometimes listen to C-SPAN in background while I work, but also
because it highlights the clear difference between "dogma" (the blind
blessing of a tool's use) and "wisdom" (the blessing of a reasoned
thought process).
I have often said that the strange thing about wisdom is that two
people, applying reasoned thought, can reach differing outcomes. (I
suppose that could even go so far as to say that one wise person could
advocate blind creation of free software even though I, trying perhaps
arrogantly to claim I have a bit of wisdom on this issue, think the
opposite.) But really what I mean is that on any given occasion, one
must evaluate the consequences of free software. It is a tool.
Has it done good? I think it has. In some cases. It has given
Microsoft a run for its money, and that may be good not because
Microsoft is evil per se, but because there is a danger in any
overlarge company getting too comfortable. And there aren't many
challengers to Microsoft. The flip side, of course, is that there
soon won't be many challengers to Linux because the investment has
reached such a critical mass that competing with it is just too
expensive. And Postgres is another win for the free software
community, because database technology should have been integrated
tightly into languages and systems early on in computer science, and
was probably locked out by some quasi-monopolies on database
technology for a long time holding db technology too high. It should
have come down in price over time by natural market forces, but
didn't.
But on the other hend, free software has been a nightmare. The giving away
of small tools means that there isn't a nice market for small wares.
Rather, it means every time anyone comes out with anything that took only
modest investment and they want to sell for an appropriately modest price,
there is some thoughtless free software sniper ready to say "I'll save the
world from even that modest price by making a version of that which is free."
This means the person who did the original thing is wasting his time, and
it has been catastrophic to the market.
The remarkable thing is that there have been no lawsuits, but probably
because this is a war between poor people making each other poorer, and no
one can afford a lawyer.
In International News Service v. Associated Press, 248 U.S. 215 (1918),
the Associated Press sought (and I think got) relief when they were sending
people abroad to cover the war and then as soon as the results came back,
other news services (presumably International News Service in particular)
were republishing the results without having to invest in having a reporter
overseas. (I dredged up the URL and someone can doublecheck my memory, but
I don't have time to read it and check myself.
http://caselaw.lp.findlaw.com/scripts/getcase.pl?court=us&vol=248&invol=215
) The critical issues, as I recall anyway, were: (1) that ordinarily, news
enjoys not much copyright protection because it is "truth" and not "literary".
The truer something is, the less it has copyright hold. I recall that history
texts have more trouble getting copyright protection than other works, for
example, because there's a virtue in not having you rewrite the truth just
to get another wording that is copyright free, because this would cause drift.
But the problem on the other side was that in certain cases, like this, where
truth is expensive to obtain, saying that anyone can just copy it the instant
it is made could lead to a catastrophic failure of the market, and no one would
send reporters to cover wars because it wasn't economically worth it.
I'm quite surprised that people haven't made similar cases about free
software since the case seems structurally related. Code is not literary,
yet it takes time to organize it into libraries and funciton calls, and to
find what functions work well with others; as soon as you publish a spec,
though, anyone can copy it without doing this work. If you publish good doc,
it will tell you even about the hard cases and tricky bugs to avoid and again
save another implementor time. The result being that it is a disincentive
to doing the initial work in the first place.
Note I don't mean a disincentive to produce free software. But the
whole IP protection thing in the Constitution, too, seems to me to be
about promoting business, not busy-ness.
Kent M Pitman
> Oh I believe I do more or less understand what the founders intended
> over there, what I was unclear on is the nature of the proposed
> replacement as it pertains to public funding for software. Arguably
> OT here, but is that still flamewar material?
Just for the record, I don't think it's OT as long as subject lines
are maintained correctly. Perhaps we should have changed the subject
line a while ago. (But then, maybe having not done so is what has
kept anyone interested in a real flamewar from being cued to dive in.)
But in my mind, nothing could be more relevant to Lisp than how to use
it in a commercially successful way. We differ in many ways: on how
we specifically want to spend our time, on how much income we need or
want, and on what strategies we think will achieve that. But
something I assume we don't differ on is that we want to succeed
economically and we probably even want others to succeed too, so that
we can have a marketplace to do business in tomorrow. As such, not
only is this not philosophically off topic, but it offers
opportunities to enrich us in our on-topic pursuits.
Hence, I think no one should be shy about continuing to speak on this
topic as long as they keep their tone relatively civil. At least, IMO.
Don Geddis
> a BBC documentary called The Century of Self [...]
> They claim that we've transitioned to a free market morality, every man
> for herself; and politicians now pander to a small bloc of swing voters.
Perhaps surprisingly, that last "obvious" fact was decidedly not true in
the more recent US Presidential election. As you suggest, in almost all
elections the candidates pander to the swing voters at the end, who tend
to be "moderate" (which is why they're undecided).
In this election, the issues were so polarizing that most voters made up their
minds long ago, and wouldn't change them. There were very few true swing
voters available to pander to.
The Republicans led the innovative new idea to _ignore_ the swing voters,
and instead concentrate on turning out the base of "already decided" voters.
Turns out there were a lot more people who supported each candidate, but
usually just didn't bother to vote, then people who were truly undecided.
It was a successful election strategy for Bush/Rove, but it naturally led
to a feeling of divisiveness in the US, since neither candidate was trying
very hard to appeal to the "average voter", but instead spent most of their
energy appealing only to their own side. That structure highlights differences
rather than similarities.
Anyway, I just found it amusing that your conclusion of politicians
pandering to "a small bloc of swing voters" was not true in the last
major US election.
Thomas A. Russ
> I'm quite surprised that people haven't made similar cases about free
> software since the case seems structurally related. Code is not literary,
> yet it takes time to organize it into libraries and funciton calls, and to
> find what functions work well with others; as soon as you publish a spec,
> though, anyone can copy it without doing this work. If you publish good doc,
> it will tell you even about the hard cases and tricky bugs to avoid and again
> save another implementor time. The result being that it is a disincentive
> to doing the initial work in the first place.
Well, isn't this essentially an argument in favor of software patents?
They protect precisely the sort of thing that is expressed in that paragraph.
--
Thomas A. Russ, USC/Information Sciences Institute
Nicolas Neuss
> Nicolas Neuss <my....@iwr.uni-heidelberg.de> writes:
>
>> With free software at hand, there is at least some chance that a
>> small group of people can put something reasonable together which
>> can compete against those large companies.
>
> ...
>
> 3. Produce an "innovative" product. Innovation is difficult to
> do correctly, but if you can pull it off, you can score a real
> coup. Sometimes you can create a market that didn't exist
> before (bonus!). Sometimes you can transform the way a market
> operates. Sometimes you just win big.
>
> Innovation is also expensive, which is why companies tend to
> cycle through periods where they innovate and then periods
> when they coast (or stagnate). Because it is so difficult, it
> is not a sufficient basis for a business plan.
>
> ...
>
> I don't see "free" software helping significantly with 3. Most
> of the free software that I am familiar with is simply a
> re-implementation of something someone else has already done.
> Occasionally, there is an innovative feature added, but the
> fundamental application is typically not very innovative. (There
> are, I assume, exceptions to this, but I probably don't use them
> much).
>
> What am I missing?
Not much I think. On the other hand, I do not see that free software in
general does significantly harm #3. If you want to address the GPL
specifically, please do so.
Nicolas.
P.S.: I think that getting wealthy with 3 is possible, but getting very
wealthy is almost impossible. As soon as your business is starting to work
out you will get an offer of some large company working in the same domain.
Now, you have the choice... And I think it is very difficult to fight
against MS billions. See Netscape or many other cases.
Tayssir John Gabbour
> "Tayssir John Gabbour" <tayss...@yahoo.com> wrote on 28 Apr 2005
06:4:
> > a BBC documentary called The Century of Self [...]
> > They claim that we've transitioned to a free market morality,
> > every man for herself; and politicians now pander to a small
> > bloc of swing voters.
>
> pandering to "a small bloc of swing voters" was not true in the last
> major US election.
It is not my personal conclusion. If you look up a few lines, I wrote
"They claim..." And the documentary was in 2002. We are focussing on
half a sentence I wrote in some haste.
You're free to watch the documentary and explore further; but just like
Lisp, I'm sure it's not to everyone's interest.
Kent M Pitman
I'll think on that. I see where you're going but something seems
wrong about that. I think the main reason is that patents, unlike
copyrights, are expensive and require explicit bookkeeping and persist
for too long. So they're too heavyweight.
(Not that I don't think most software patents are inappropriate and
too heavyweight, too, btw. I believe strongly in software copyrights,
but don't think software patents are a good idea in most cases. I
think they have mostly hindered, rather than helped, the case. One
main problem with patents is "independent derivation" is an
infringement rather than a proof that the thing patented was "obvious"
and never should have been given a patent in the first place.)
Kent M Pitman
Actually, here I think you're slightly off in your account.
A lot of people who make free software think they will end up being able
to consult on the product when done, but I bet that in general it is rare
that the person who makes something gets to do that unless the product is
big and hard to understand. Being in the consultant business is a tough
thing because you have to have the right resources to respond to arbitrary
needs. In general, that means that big organizations can be consultants
but little guys will be whomped because they can't keep their plate
statistically full and so they have to charge a premium rate to cover down
time, while a big organization can have enough things going at once that it
can rely on statistical degrees of availability on this or that project and
shift people among.
I'm generalizing this from probably too little data, and I'm sure there are
bound to be exceptions, but my main point is not to rely on the "existence
proof"-like nature of the exceptional cases as proof of some universal truth.
>
> If you just want to be a consumer of computing-related goods and
> services, then don't worry. "Free" software is your friend (so
> far).
Right, exactly. A lot of people (and I hate to appear age-ist about this,
but I still think it's mostly young people who have not lived long enough
to have to have run into desperate shortages of money for sicknesses,
vacations, family emergencies, personal illness or disability, unrelated
financial problems, changes in market making their "skills" less valuable,
changes in the global market making their "money" less valuable, etc.) seem
to think that the problem is merely "making things I want to use cheaper
to get".
What's sad is that people think I'm complaining just for me. I'm also
saying "I think many of you on the other side of this are being deceived
and may come to regret your position later". I went through a very generous
time in my college days myself. I'm just grown up now. I see things
differently.
What I lament MOST, in fact, is that the politics of the world are screwed
up. There are some very generous and thoughtful people in CS who understand
"process" and "how to count" and stuff like that in ways that would allow
them to confront issues like overpopulation, global warming, fair voting,
and other important issues with more than a shrug and an "I don't see a
problem here" like we get from our all-too-comfortable and not-so-generous
leaders today. If those people in CS who have new ideas about how to make
the world work had money, they might make some changes to the world. But
instead they are breeding a whole generation and a whole industry of
economically disempowered people. And the people who are making the money
instead are laughing their way to the bank that all they have to do is
provide "free pacifiers" to these smart, valuable people and they'll work
for free.
Steven E. Harris
> And the people who are making the money instead are laughing their
> way to the bank that all they have to do is provide "free pacifiers"
> to these smart, valuable people and they'll work for free.
What are these "free pacifiers"? Can you be more specific?
--
Steven E. Harris
Kent M Pitman
I was making a metaphorical reference to "pacifiers" like you give babies
to quiet them. There are recurring references to needing to "pacify the
masses" in the study of political history... they need something to distract
them from the big issues. Drugs, television, free software, etc. Anything
to keep people from becoming involved directly in politics.
(And when that fails, make sure they're involved in the wrong things;
like making people think that gay marriage and abortion are what is
going to bring the US to its knees, and not economic bankruptcy due to
overspending on not just on social programs (many of which I support,
btw) but on wars, tax breaks for the rich, failure to restrain overuse
of critical fuels, failure to control pollution that will have to be
cleaned up later, etc.)
Yes, there are jobs. But there should be opportunities to get rich. Just
like in any other aspect of society. We're the only part of society I've
ever seen that has worked hard to disempower itself. Unilateral disarmament.
It's one thing if other industries are disempowered at the same time, but
it's quite another if it just means that all we'll ever be able to aspire to
is work-a-day jobs answering to someone who knows less about the industry
than us.
The solution to the problems of the world economy today, including the
severe outsourcing problem the US is seeing, is not free software.
It's people who are making things standing up and charging money for
it. In the US, workers unionized a while back and it worked. Now the
US unions are confusedly thinking they need to do more, demand more
wages. But they're wrong. What they need to do is to go abroad and
help people in other countries unionize. It's them, not us, who don't
demand enough money. When they finally do, we won't lose money so fast.
The market will start working again and people will select on normal value
issues. But right now everything is out of whack and the market can't work
because there isn't balance.
When everyone asks for what they are worth, the standard of living
will come up, not just where the jobs are going now but everywhere.
As long as someone is willing to ask for less, the person willing to
grovel most will be the person to typify the way we all live.
Ulrich Hobelmann
> Robert Reich was interviewed by a BBC documentary called The Century of
> Self. He helped explain why our bonds of community are much weaker than
> before.
> http://www.thecorporation.com/phpBB2/viewtopic.php?t=587
>
> They claim that we've transitioned to a free market morality, every man
> for herself; and politicians now pander to a small bloc of swing
> voters.
It's everybody for themselves because money is harder to make,
because we divide people on religious issues (in the US). Where
these things aren't an issue, there usually is a community,
despite the free market being everywhere.
>>Nonsense. You can't fix the problem yourself, but you can have an
>>incremental effect. There is something you can do. When someone
>>offers you something for free, offer to pay them for the value you
>>get. Tell them to charge people rather than give away value.
>
>
> I'm curious what you think of technology automating away many
> manufacturing jobs, destabilizing their wages and pushing them to
> service jobs. This is not a "drive-by" question; I am honestly curious.
I think it's normal. It has happened for two centuries now, with
our standard of living rising, and new kinds of jobs coming up all
the time. The trend is to services, right. That's doesn't have
to be bad, though. It's not all just waitresses and people in
hotel elevators ;)
> True, money is only lubrication, to match up consumers and producers.
> However, we seem to have the Java of monetary systems. And the
> mechanism of controlling money appears outside our democratic control.
It's the unit of trade. I don't know too much about monetary
systems or what you mean. I rather think that our political
systems are just wrong (in the US: not enough social security, and
too much stuff in the government; in Europe: waaaay too much stuff
in the government).
When stupid regulations go away (which work like resistors in
electric circuits), micromarkets can appear everywhere, which is
good. I think there are probably lots of business models that are
just not viable now.
> The function of the taxpayer has been to heavily subsidize research.
But why is this right or wrong? Historically I think it's been a
function of the cold war, that the "West" needed guaranteed money
flow into research to strengthen the military. A market can't
guarantee anything, in contrast. Now that the war is over, I'm
not sure if government funding is a good idea. Maybe it distorts
the market for private research.
OTOH it's a good idea to make all state-funded research open for
everybody. In that case tax-funding (by everybody) isn't
necessarily bad.
> But not to subsidize production. If we lived in a serious democracy
> where the citizenry did more than poke a chad every 4 years, taxpayers
> would likely sponsor production of free software. Just as we provide
> stable subsidies for (say) Lockheed-Martin to administer parking meters
> and welfare-to-work programs.
What does the poorness of modern democracy have to do with
sponsoring free software? I don't quite follow. I don't think a
communism-like general funding for whatever software the state (or
the FSF) deems appropriate is good. A market is a better alternative.
> Changing the subject, Jans Aasman of Franz explained this weekend that
> Franz has been growing and increasingly able to utilize its engineering
> department. I suspect free software has been BENEFICIAL to Franz's
> business model. At least I have seen remarkably few people discuss this
> fundamental issue seriously.
In what way does Franz profit in any way from open-source? Don't
they sell Allegro for money, and maybe services and consulting for
it? This seems to me like saying MS profits from open-source.
Ulrich Hobelmann
> Unfortunately, there is a problem with this argumentation. Software is
> getting more and more complex and the cost of building up something
> interesting takes more and more resources. This leads to a concentration
> process which can be observed everywhere in our economy (larger companies
> buying smaller concurrents)[*].
Large companies buy small competition mainly for innovation
purposes. The small companies aren't forced to sell, either.
They just choose to do so, because competing against giants is
hard, and because they are offered a good price usually.
Componentization (a consequence of specialization) leads to
deconcentration. See automobile manufacturers and all the
components they buy from various small companies that focus on
just a few components and excel at that.
In the software world componentization has already happened a bit
(free software are components, as is legacy software), and the
expensive part is glueing them. Therefore we see a huge rise in
scripting language popularity.
Other, big components don't really appear, because probably the
incompatibilties are too big (?). Markets don't develop because
there are not too many interchangeable components, I believe.
So I think that developing software as a small company might be
viable in the future, too. Just make sure you aren't directly
competing with a free software offering, or it could be really hard ;)
> Without free software, there would be some
> point when even Kent could only achieve results working as a small wheel
> inside a large company as Microsoft, Oracle, etc... I doubt that this
> would give him the satisfaction he longs for.
If he's writing stuff that people can get for free, yes.
> With free software at hand,
> there is at least some chance that a small group of people can put
> something reasonable together which can compete against those large
> companies.[+]
Most free software that you can use in commercial products are
libraries (under the LGPL). They are free components, so indeed
they might help a lot, since you don't have to reimplement their
functionality. I also put free tools (language implementations,
build systems ...) in that category. They help reduce the cost of
software development.
The problem is rather free *applications*. In a Firefox world it
will be hard to sell browsers for money -- maybe embedded ones to
phone companies, but even there free browsers are surely on their
way already.
Christopher C. Stacy
> This seems to me like saying MS profits from open-source.
FOSS helps to ensure that programmers are poor enough that they
can't compete with the resources that Microsoft brings to bear.
Christopher C. Stacy
> So I think that developing software as a small company might be viable
> in the future, too. Just make sure you aren't directly competing with
> a free software offering, or it could be really hard ;)
As soon as you release your product, if it's popular, some FOSS
people will organize to put you out of business by leveraging
your R&D efforts in order to bring out a free version.
(If they were a corporation, this would be illegal "dumping".)
Since you can predict this will happen, there's no point
in bothering to be creative in the first place, since you
won't be able to profit from it, and you need to somehow
make money to put the kids through college.
Ulrich Hobelmann
> A lot of people who make free software think they will end up being able
> to consult on the product when done, but I bet that in general it is rare
> that the person who makes something gets to do that unless the product is
> big and hard to understand. Being in the consultant business is a tough
> thing because you have to have the right resources to respond to arbitrary
> needs. In general, that means that big organizations can be consultants
> but little guys will be whomped because they can't keep their plate
> statistically full and so they have to charge a premium rate to cover down
> time, while a big organization can have enough things going at once that it
> can rely on statistical degrees of availability on this or that project and
> shift people among.
That's why I don't really like what IBM is doing with free
software. They pay a handful of programmers, and profit from
hundreds out there, that don't get paid anything for their work,
but sacrifice their free-time instead, some for fun, some maybe in
hope of a glorious programming career that might not happen.
If software is *really good* and easy to use, you don't need
consulting. Sendmail can sell consulting, because their software
is a complex lump, that is: not nearly good enough. Web servers
and application servers sell consulting, because they are hard to
install and hard to use (Java, J2EE etc.).
So you can't make any money on making a video game, or a really
good application, open-source. There will be nobody who needs
your consulting. It's sad that ESR and others don't seem to ever
consider this.
> What I lament MOST, in fact, is that the politics of the world are screwed
> up. There are some very generous and thoughtful people in CS who understand
> "process" and "how to count" and stuff like that in ways that would allow
> them to confront issues like overpopulation, global warming, fair voting,
> and other important issues with more than a shrug and an "I don't see a
> problem here" like we get from our all-too-comfortable and not-so-generous
> leaders today. If those people in CS who have new ideas about how to make
> the world work had money, they might make some changes to the world. But
> instead they are breeding a whole generation and a whole industry of
> economically disempowered people. And the people who are making the money
> instead are laughing their way to the bank that all they have to do is
> provide "free pacifiers" to these smart, valuable people and they'll work
> for free.
I think that in many ways operating systems are analogous to
global polito-economic systems. A small kernel is better and
easier to manage. The more processes run in user-space (in the
free market), the more they can be improved by independent parties
(people, not political parties :D). A difference is that most
trade doesn't need kernel-traps: people trade just among each
other; state intervention is only needed when someone breaks the
law (exception, fault).
I'm afraid that too many people, especially non-CSers, will think
I'm totally nuts when I should ever publicly state these comparisons.
Matthias Buelow
>In what way does Franz profit in any way from open-source? Don't they
>sell Allegro for money, and maybe services and consulting for it?
I would think that at least some people at Franz are also using free
software to do their work. How else would they be able to make their
product for Linux and FreeBSD?
>This seems to me like saying MS profits from open-source.
Of course they do. Hotmail runs on a FreeBSD server farm, they have
been using free software systems (or derived-from free software) for
their backend web servers for the microsoft.com domain at some time (a
couple years ago you could for some time directly telnet onto their
web servers and it came up with a BSDI login prompt...) And you don't
think that within MS every employee uses exclusively software that has
either been bought from a 3rd party or has been developed in-house?
Besides, there's plenty open-source software also for Windows, which
indirectly helps the OS vendor aswell by contributing to the
usefulness of the system for their customers.
mkb.
Tayssir John Gabbour
> Right, exactly. A lot of people (and I hate to appear age-ist
> about this, but I still think it's mostly young people who have
> not lived long enough to have to have run into desperate shortages
> of money for sicknesses, vacations, family emergencies, personal
> illness or disability, unrelated financial problems, changes in
> market making their "money" less valuable, etc.) seemto think that
> the problem is merely "making things I want to use cheaper to get".
An important issue is that many Europeans have better developed social
support systems than we do. Many free software contributors come from
there. So they don't have exactly the same worries.
In this light, the serious problem of the GPL could be that it opens
Americans to free market discipline. It subverts the good and bad parts
of copyright, which itself is a social contract.
(For those whose fingers are itching to reply saying the free market is
better than sliced bread, please note that I'm likely familiar with
what you're about to say, and don't have time to present the case. I
accept that most think Lisp users are nuts, and that most people
disagree with this post.)
Matthias Buelow
>consulting. Sendmail can sell consulting, because their software is a
>complex lump, that is: not nearly good enough. Web servers and
Having done a couple mail servers in my time (with different server
software) and hence read up a bit on the subject in the last couple
years, I have to dispute this. They sell consulting because
processing mail is often a very complicated issue. The software
simply tracks the real world. (I'm not going to indulge myself into
discussions about sendmail's configuration, and especially the
perceived incomprehensiveness of its configuration language here.
This would be way off-topic.)
mkb.
Kristian Elof Sørensen
> Yes, there are jobs. But there should be opportunities to get rich. Just
> like in any other aspect of society. We're the only part of society I've
> ever seen that has worked hard to disempower itself. Unilateral disarmament.
> It's one thing if other industries are disempowered at the same time, but
> it's quite another if it just means that all we'll ever be able to aspire to
> is work-a-day jobs answering to someone who knows less about the industry
> than us.
Maybe selling software products in the manner of the scrink-wrapped
software programs of the 80'ties is a bad business model to start with.
You will want to offer a way that a company with money and a problem can
turn a part of their money into a solution to their problem.
A solution to a companies problem can consist of stuff like ready made
business deals with 3. party providers of goods and services, standards
for goods and services supplemented with well thought out procedures for
checking and enforcing them, a service organisation with people on-call
who can fix problems fast so they do not delay busines, customiced
machinery, customiced software, shrink wrapped software or open source
software that you have integrated with the other parts of the solution,
well written documentation and training material, well thought out
business cases for everything involved etc.
Such an offering will often include all this and a promice of "we will
handle all this for you as long as you pay us xxx xxxx a month", thereby
providing the company with a problem an easy way to turn money into a
solution to their problem.
The software products that are parts of the offering or are used in its
creation or the ongoing day to day work, is probably not that important
to succes or fiasco.
However using open source can lower the need for capital when starting
such a company. The availability of open source to students and
professionals help them learn more about how to build and use software
than had they only had shrink wrapped software available to them. This
can only be of benefit to the cpmpanies that hire them or the companies
they start themself.
Kristian
Greg Menke
> >
> > If you just want to be a consumer of computing-related goods and
> > services, then don't worry. "Free" software is your friend (so
> > far).
>
> Right, exactly. A lot of people (and I hate to appear age-ist about this,
> but I still think it's mostly young people who have not lived long enough
> to have to have run into desperate shortages of money for sicknesses,
> vacations, family emergencies, personal illness or disability, unrelated
> financial problems, changes in market making their "skills" less valuable,
> changes in the global market making their "money" less valuable, etc.) seem
> to think that the problem is merely "making things I want to use cheaper
> to get".
>
> What's sad is that people think I'm complaining just for me. I'm also
> saying "I think many of you on the other side of this are being deceived
> and may come to regret your position later". I went through a very generous
> time in my college days myself. I'm just grown up now. I see things
> differently.
Ahh, the old "kids these days" argument.
Making things I want to use cheaper means I don't need to spend as much
to get them and I can get on with what I really want to do. I can be
more valuable for my clients because I can roll a server to do most
anything they want using Linux and whatever junk is in the closet. By
making it easier and cheaper to build infrastructure I can reduce its
cost which is of direct benefit to the people paying my salary. If it
undercuts the market for your neato software you're trying to sell,
you'd better fancy it up to make it worth my while or I'll go elsewhere.
This is why I buy Solaris for server infrastructure thats designated as
"important" and why I buy Lispworks because it brings a pile of stuff to
the table that I like and it saves me time. But lots of times Linux and
CLISP will do just fine. Must I buy Solaris and Lispworks for all my
server and Lisp programming needs?
I fail to see how I am deceived and how my skills are made less valuable
by using open source where it makes sense to. In some of your other
posts you argue that some of our current social debates are
oversimplistic, I'd argue that you're being oversimplistic in your
characterization of open source.
Gregm
Kent M Pitman
> I fail to see how I am deceived and how my skills are made less valuable
> by using open source where it makes sense to. In some of your other
> posts you argue that some of our current social debates are
> oversimplistic, I'd argue that you're being oversimplistic in your
> characterization of open source.
Because in my posts, I freely admit there are counterexamples, but am trying
to point to that there are also problems.
In the posts of those speaking to me, they seem to think the counterexamples
are irrelevant and that by pointing to the success of one, I must be wrong.
I claim I am not oversimplifying because I am not saying my problem is
everyone's problem. I am merely saying it is a substantial problem of some.
Do you think it's a substantial problem of some, also?
Do you believe your success is a countexample to the possibility that
others do not succeed?
Do you believe your success is representative of computer science in general?
I haven't tried to trivialize the success of some people. I've tried
to say that this success appears to me not to be shared as generally and
evenly as is sometimes claimed. In what sense is that an oversimplification?
Also, it is extremely hard to talk about a large problem in a way that
gives anyone any sense of gestalt about it. Some degree of simplification
is needed to get any handle on it. Bush talks about having improved life
in the US. Do you think he is oversimplifying by combining everyone into a
single number, or do you think people who are complaining there are still
ill effects of current policies and more things that need to be done are
oversimplifying by complaining that things are not going so well for them?
The term "oversimplification" is often used in a kind of pejorative
way to say "you have no right to speak in abstract, round terms". Or
"you're leaving out something substantial". When I've already
acknolwedged there are good effects and that I'm tryingto speak to the
less good effects, what am I leaving out? In your remarks, by
contrast, where have you acknowledged the things that you might be
leaving out in your account?
Ulrich Hobelmann
>>This seems to me like saying MS profits from open-source.
>
>
> Of course they do. Hotmail runs on a FreeBSD server farm, they have
Actually some time ago MS migrated Hotmail to Win2000. It was a
lot of work :)
> been using free software systems (or derived-from free software) for
> their backend web servers for the microsoft.com domain at some time (a
> couple years ago you could for some time directly telnet onto their
> web servers and it came up with a BSDI login prompt...) And you don't
Cool :)
Although BSDI is a commercial BSD.
> think that within MS every employee uses exclusively software that has
> either been bought from a 3rd party or has been developed in-house?
> Besides, there's plenty open-source software also for Windows, which
> indirectly helps the OS vendor aswell by contributing to the
> usefulness of the system for their customers.
Maybe. There are people who say that open-source available for
Windows keeps people from switching to Linux.
For most people I know the issue seems to be games, though. For
me it was multimedia, but fortunately a Mac can do both Unix and
multimedia.