Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

CL & CORBA

26 views
Skip to first unread message

Bjoern-Falko Andreas

unread,
Sep 1, 1998, 3:00:00 AM9/1/98
to
Hi!

Has anyone made any expriences with Allegro ORBlink? Is there a Linux
version for the latter? Franz Inc. doesn't answer on this one (again),
so I have to ask you.
I have seen a posting from somebody saying that he had made good
experiences with Xerox PARCs ILU. Is ILU preferable to ORBlink? My major
concern is the stability of ILU, since we would have to rely on it.

CU/2 Bjoern

Rainer Joswig

unread,
Sep 1, 1998, 3:00:00 AM9/1/98
to
In article <35EBEA8E...@ki.informatik.uni-ulm.de>,
and...@ki.informatik.uni-ulm.de wrote:

Harlequin seems to offer Corba support in their next version of
LispWorks.

Joachim Achtzehnter

unread,
Sep 2, 1998, 3:00:00 AM9/2/98
to
Bjoern-Falko Andreas <and...@ki.informatik.uni-ulm.de> writes:
>
> Has anyone made any expriences with Allegro ORBlink?

No, haven't tried that yet. Came far too late for our project, so
wasn't considered.

> Franz Inc. doesn't answer on this one (again),

Worrying, isn't it?

> I have seen a posting from somebody saying that he had made good

> experiences with Xerox PARCs ILU. My major concern is the stability


> of ILU, since we would have to rely on it.

This may have been my posting. We are using ILU for a major
project. Certainly, there are rough edges, it is still classified as
alpha software after all. But the pieces that exist work well. And let
us not underestimate the value of having access to the source code!

> Is ILU preferable to ORBlink?

Really can't say because I haven't seen ORBlink. Had some early
discussions with one of the Franz people who designed the mapping, and
judging by that it seems Franz have chosen a CORBA mapping that is
incompatible with the one used in ILU. The OMG has not yet
standardised a Lisp binding! So switching in mid-project will require
some effort.

Joachim

--
private: joa...@kraut.bc.ca (http://www.kraut.bc.ca)
work: joa...@mercury.bc.ca (http://www.mercury.bc.ca)

Marco Antoniotti

unread,
Sep 2, 1998, 3:00:00 AM9/2/98
to

jos...@lavielle.com (Rainer Joswig) writes:

> In article <35EBEA8E...@ki.informatik.uni-ulm.de>,
> and...@ki.informatik.uni-ulm.de wrote:
>
> > Hi!
> >
> > Has anyone made any expriences with Allegro ORBlink? Is there a Linux
> > version for the latter? Franz Inc. doesn't answer on this one (again),
> > so I have to ask you.

> > I have seen a posting from somebody saying that he had made good

> > experiences with Xerox PARCs ILU. Is ILU preferable to ORBlink? My major


> > concern is the stability of ILU, since we would have to rely on it.
> >

> > CU/2 Bjoern
>
> Harlequin seems to offer Corba support in their next version of
> LispWorks.

(WITH-PROVOCATEUR-MODE-ON
"Will I be able to run code written for Allegro ORBLink with the
Harlequin implementation?"
)

Cheers

--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 80 79 23, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it

Espen Vestre

unread,
Sep 2, 1998, 3:00:00 AM9/2/98
to
Marco Antoniotti <mar...@galvani.parades.rm.cnr.it> writes:

> (WITH-PROVOCATEUR-MODE-ON
> "Will I be able to run code written for Allegro ORBLink with the
> Harlequin implementation?"
> )

(with-frustration-mode-on
"I went to a CORBA tutorial at the Object Expo Europe in London this
summer, and went out totally frustrated. The title was 'Tips and
Techniques for Building Distributed CORBA Applications', but the
content was rather 'How to survive as a CORBA programmer while
the OMG changes its mind every week'.

So I think I'll avoid using CORBA as long as possible, and for my own
distributed applications I'm much more happy inventing my own little
tcp protocols with lisp syntax.

(a side note: AFAIK, the CORBA guys have just _started_ thinking
about security, and I saw the first major security hole on BUGTRAQ
some weeks ago. Expect to see more!)

--

(regards
(espen vestre))

Klaus Schilling

unread,
Sep 2, 1998, 3:00:00 AM9/2/98
to
Joachim Achtzehnter <joa...@kraut.bc.ca> writes:

> Bjoern-Falko Andreas <and...@ki.informatik.uni-ulm.de> writes:
> >
> > Has anyone made any expriences with Allegro ORBlink?
>

> No, haven't tried that yet. Came far too late for our project, so
> wasn't considered.
>

> > Franz Inc. doesn't answer on this one (again),
>

> Worrying, isn't it?


>
> > I have seen a posting from somebody saying that he had made good

> > experiences with Xerox PARCs ILU. My major concern is the stability


> > of ILU, since we would have to rely on it.
>

> This may have been my posting. We are using ILU for a major
> project. Certainly, there are rough edges, it is still classified as
> alpha software after all. But the pieces that exist work well. And let
> us not underestimate the value of having access to the source code!

But the ilu source is only to look at. The license fails to allow the
distribution of modification patches.

Klaus Schilling

Rainer Joswig

unread,
Sep 2, 1998, 3:00:00 AM9/2/98
to
In article <lwg1ebv...@galvani.parades.rm.cnr.it>, Marco Antoniotti
<mar...@galvani.parades.rm.cnr.it> wrote:

> jos...@lavielle.com (Rainer Joswig) writes:
>
> > In article <35EBEA8E...@ki.informatik.uni-ulm.de>,
> > and...@ki.informatik.uni-ulm.de wrote:
> >
> > > Hi!
> > >
> > > Has anyone made any expriences with Allegro ORBlink? Is there a Linux
> > > version for the latter? Franz Inc. doesn't answer on this one (again),
> > > so I have to ask you.

> > > I have seen a posting from somebody saying that he had made good

> > > experiences with Xerox PARCs ILU. Is ILU preferable to ORBlink? My major


> > > concern is the stability of ILU, since we would have to rely on it.
> > >

> > > CU/2 Bjoern
> >
> > Harlequin seems to offer Corba support in their next version of
> > LispWorks.
>

> (WITH-PROVOCATEUR-MODE-ON
> "Will I be able to run code written for Allegro ORBLink with the
> Harlequin implementation?"
> )
>

> Cheers


(with-optimistic-mode (t :naive :extreme)
"Somebody mentioned that both company shared design docs.")

Bjoern-Falko Andreas

unread,
Sep 2, 1998, 3:00:00 AM9/2/98
to
Joachim Achtzehnter wrote:

>
> Bjoern-Falko Andreas <and...@ki.informatik.uni-ulm.de> writes:
> >
> > Has anyone made any expriences with Allegro ORBlink?
>
> No, haven't tried that yet. Came far too late for our project, so
> wasn't considered.
I gave up on ORBlink because the Franz guys didn't answer to my mail
concerning wether there is ORBlink for Linux or not.

> > I have seen a posting from somebody saying that he had made good

> > experiences with Xerox PARCs ILU. My major concern is the stability


> > of ILU, since we would have to rely on it.
>

> This may have been my posting. We are using ILU for a major
> project. Certainly, there are rough edges, it is still classified as
> alpha software after all. But the pieces that exist work well. And let
> us not underestimate the value of having access to the source code!

Ho-hum. Do you know when the 2.0 final of ILU is due? We all _KNOW_ the
horror of browsing through code we haven't written ourselves. I remember
patching and debugging and extending Jim Firbys RAP. And I guess,
everybody will agree that scarcly documented LISP code isn't very easy
to understand.

>
> > Is ILU preferable to ORBlink?
>

> Really can't say because I haven't seen ORBlink. Had some early
> discussions with one of the Franz people who designed the mapping, and
> judging by that it seems Franz have chosen a CORBA mapping that is
> incompatible with the one used in ILU. The OMG has not yet
> standardised a Lisp binding! So switching in mid-project will require
> some effort.

I think nobody besides us is really interested in LISP. Everybody is
jumping onto the Java bandwagon. Lisp isn't supported as it deserves.

Anyway, I have to connect LISP, C/C++ and Java processes. And I don't
want to write this stuff, when there already are solutions for this.
Sure, the ACL-C connectivity via foreign-function-calls is sufficent for
our purposes, been there, done that. But LISP-Java would be ACL ffcing
to C and then to Java. If I had much more time at hand I'd go that way.

>
> Joachim

CU/2 Bjoern (yes, I still believe in OS/2)

Lewis Stiller

unread,
Sep 2, 1998, 3:00:00 AM9/2/98
to
Hi,

ORBLink is in final and is supported on any Allegro CL 5.0 platform
including Linux.

For more detailed information, contact in...@franz.com or orb...@franz.com.

As one of the main developers of ORBLink and as an employee of the company
that vends it, I am not qualified to comment in a disinterested manner on
the stability or quality of the product or of competing products. Like any
software product, it presumably is appropriate for some applications and
inappropriate for others; we encourage customers to try it risk free on an
evaluation basis in order more accurately to determine its suitability for
their needs.


Bjoern-Falko Andreas wrote:

> Hi!
>
> Has anyone made any expriences with Allegro ORBlink? Is there a Linux
> version for the latter? Franz Inc. doesn't answer on this one (again),
> so I have to ask you.

> I have seen a posting from somebody saying that he had made good

> experiences with Xerox PARCs ILU. Is ILU preferable to ORBlink? My major


> concern is the stability of ILU, since we would have to rely on it.
>

> CU/2 Bjoern

Regards,

--
Dr. Lewis Stiller Franz Inc.
1995 University Ave., Berkeley, CA 94704
sti...@franz.com


clive

unread,
Sep 3, 1998, 3:00:00 AM9/3/98
to

Rainer Joswig <jos...@lavielle.com> wrote in article
<joswig-0209...@pbg3.lavielle.com>...


> > (WITH-PROVOCATEUR-MODE-ON
> > "Will I be able to run code written for Allegro ORBLink with the
> > Harlequin implementation?"
> > )
> >
> > Cheers
>
>
> (with-optimistic-mode (t :naive :extreme)
> "Somebody mentioned that both company shared design docs.")

Harlequin and Franz have agreed on an initial version of a Common Lisp IDL
binding document - this means that the mapping of the basic IDL types will
be the same for both products. Until any Lisp binding becomes ratified by
the OMG, the products are likely to provide slightly different sets of
helper functions and differ in minor ways in other areas.

Even with a ratified binding document, there's more to writing a CORBA
server than the parsing of the IDL - for example, we support the POA in our
ORB (I don't know about OrbLink), and the ORBs are likely to offer
configuration parameters specific to their designs, as well as
infrastructure functions for closing connections and setting timeouts.


Clive Tong Email: cl...@harlequin.co.uk
These opinions are not necessarily those of Harlequin Ltd.


jon....@totient.demon.co.uk

unread,
Sep 3, 1998, 3:00:00 AM9/3/98
to
In article <01bdd723$0896ce10$5dee58c0@monkhouse>,
(in-package :inquisitive)

(how-compatible-is-the-idl-binding-with-ilu)


-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum

Klaus Schilling

unread,
Sep 3, 1998, 3:00:00 AM9/3/98
to
"clive" <cl...@harlequin.co.uk> writes:

> Rainer Joswig <jos...@lavielle.com> wrote in article
> <joswig-0209...@pbg3.lavielle.com>...
> > > (WITH-PROVOCATEUR-MODE-ON
> > > "Will I be able to run code written for Allegro ORBLink with the
> > > Harlequin implementation?"
> > > )
> > >
> > > Cheers
> >
> >
> > (with-optimistic-mode (t :naive :extreme)
> > "Somebody mentioned that both company shared design docs.")
>
> Harlequin and Franz have agreed on an initial version of a Common Lisp IDL
> binding document - this means that the mapping of the basic IDL types will
> be the same for both products. Until any Lisp binding becomes ratified by
> the OMG, the products are likely to provide slightly different sets of
> helper functions and differ in minor ways in other areas.
>
> Even with a ratified binding document, there's more to writing a CORBA
> server than the parsing of the IDL - for example, we support the POA in our
> ORB (I don't know about OrbLink), and the ORBs are likely to offer
> configuration parameters specific to their designs, as well as
> infrastructure functions for closing connections and setting timeouts.
>

are there some sample specifications for already existing idl bindings etc.
available on the net?

what are the criteria the omg uses for refuting specs submitted by independant
parties?

Klaus Schilling

Juliusz Chroboczek

unread,
Sep 3, 1998, 3:00:00 AM9/3/98
to
Would it be possible to ask Franz, Harlequin, and any other vendors
who are listening to publish their CORBA mappings on the web so we can
have a look?

I'd like to say that at least Harlequin has a very good record of pub-
lishing manuals in this manner. Franz more than compensates for this
with the free version (documentation included) of ACL/Linux. It would
be nice if it were a systematic habit (good for the education of the
youth and handy when porting code).

J. Chroboczek

Martin Cracauer

unread,
Sep 3, 1998, 3:00:00 AM9/3/98
to
Klaus Schilling <Klaus.S...@home.ivm.de> writes:

>Joachim Achtzehnter <joa...@kraut.bc.ca> writes:

>> This may have been my posting. We are using ILU for a major
>> project. Certainly, there are rough edges, it is still classified as
>> alpha software after all. But the pieces that exist work well.

As I understand, the primary reason for "alpha" isn't code quality but
to remind people that the interface may change between two alpha
releases, where "true" releases should be source-compatible.

>> And let
>> us not underestimate the value of having access to the source code!

>But the ilu source is only to look at. The license fails to allow the
>distribution of modification patches.

That is the bullshit Richard Stallman told the GNOME people. The ILU
license is one fo the most permissive in the free software
world. "Unlimited use, reproduction, and distribution". Using a
software means all using all features and all known in everything you
got under that license. In the case of ILU, you get the sourcecode to
make use of it. Dozends of people exchange contributed code for ILU
and so far XEROX failed so sue them.

At the very least, it is not an agressive licens as the GPL so that
you can actually use it in bigger projects (together with modules
under different licenses).

Martin

Joachim Achtzehnter

unread,
Sep 4, 1998, 3:00:00 AM9/4/98
to
Bjoern-Falko Andreas <and...@ki.informatik.uni-ulm.de> writes:

> Joachim Achtzehnter wrote:
> >
> > And let us not underestimate the value of having access to the
> > source code!
>

> We all _KNOW_ the horror of browsing through code we haven't written
> ourselves. I remember patching and debugging and extending Jim
> Firbys RAP. And I guess, everybody will agree that scarcly
> documented LISP code isn't very easy to understand.

What point are you trying to make? Maybe the source code is not easy
to understand, but the alternative is to not have access to source
code! Scarcely documented Lisp code is a hell of a lot easier to
understand and fix than an executable image or DLL. Imagine you have
committed to using a particular product, then find a show stopper
bug. With source code you can fix it yourself with more or less
effort, without source code you can only beg your vendor (and nobody
else) to fix the problem for you.

And even with source code being available you don't *have* to fix it
yourself, you have always the option to wait until it is fixed by
others, or to pay others to fix it for you depending on how important
the bug is for you. Just because source code is available doesn't mean
you are somehow forced to mess with it. It gives you additional
freedoms and removes dependency on a vendor, thereby reducing your
risk.

Klaus Schilling

unread,
Sep 4, 1998, 3:00:00 AM9/4/98
to
crac...@wavehh.hanse.de (Martin Cracauer) writes:

> Klaus Schilling <Klaus.S...@home.ivm.de> writes:
>
> >Joachim Achtzehnter <joa...@kraut.bc.ca> writes:
>
> >> This may have been my posting. We are using ILU for a major
> >> project. Certainly, there are rough edges, it is still classified as
> >> alpha software after all. But the pieces that exist work well.
>
> As I understand, the primary reason for "alpha" isn't code quality but
> to remind people that the interface may change between two alpha
> releases, where "true" releases should be source-compatible.
>

> >> And let
> >> us not underestimate the value of having access to the source code!
>

> >But the ilu source is only to look at. The license fails to allow the
> >distribution of modification patches.
>
> That is the bullshit Richard Stallman told the GNOME people. The ILU
> license is one fo the most permissive in the free software
> world. "Unlimited use, reproduction, and distribution". Using a
> software means all using all features and all known in everything you
> got under that license. In the case of ILU, you get the sourcecode to
> make use of it. Dozends of people exchange contributed code for ILU
> and so far XEROX failed so sue them.
>
> At the very least, it is not an agressive licens as the GPL so that
> you can actually use it in bigger projects (together with modules
> under different licenses).
>
> Martin

ILU is not free software, due to the mentioned modification prohibition.

Klaus Schilling

Marc Dzaebel

unread,
Sep 4, 1998, 3:00:00 AM9/4/98
to
Klaus Schilling wrote:

>But the ilu source is only to look at. The license fails to allow the
>distribution of modification patches.

...

> ILU is not free software, due to the mentioned modification prohibition.

crac...@wavehh.hanse.de (Martin Cracauer) wrote:

> That is the bullshit ...
> XEROX failed so sue them

Could anyone from Xerox tell us what we may belive?

thanks, Marc

Erik Naggum

unread,
Sep 4, 1998, 3:00:00 AM9/4/98
to
* Klaus Schilling <Klaus.S...@home.ivm.de>
| ILU is not free software...

one could argue that "free", as in Free Software Foundation, is not free
at all. freedom usually means the absence of means of coercion to make
one do something other than what one wishes to do. where there are means
of coercion, the acceptable restrictions on freedom usually involve
averting some form of actual harm to some party. the GNU Public License
prohibits a number of reasonable courses of action (which it is of course
free to do), but without any reasonable explanation of the actual harm
that is averted by the restriction on people's freedom. in this sense,
it is NO MORE FREE than any other license agreement one enters, since the
freedom that comes from _agreeing_ with whoever has the power is not
worth all that much.

I'm strongly in favor of the availability of source code, yet recognize
that it will _always_ have a price. the question is which price to pay,
and whether GPL is actually more expensive and restrictive than entering
an agreement with the owner of the source that basically says they retain
all rights of ownership to the source and to derivative works.

unlike what many seem to believe, the license agreement that comes with
software in the absence of any other agreements is _not_ the final word.
reasonable people will enter other agreements as they see their value,
and often those values can transcend monetary exchanges, which I regard
as the least common denominator in otherwise incompatible value systems
-- meaning that other forms of compatibility will yield other forms of
exchangable values.

the GPL is basically incompatible with the exchange of monetary values,
which means it enforces compatibility on other values or value systems.
the end result is that you cannot use GPL _unless_ you agree with the
underlying value system. given that that was the intent behind the GPL,
one must applaud the execution of the idea, but it still does not mean
that it is actually "free" for any normal interpretation of the word.
while people everywhere may free themselves from other agreements by
exchanging money and/or signing new agreements, this is expressly _not_
an option for GPL'ed software. in this sense, "free software" is LESS
FREE than source code guarded by non-disclosure agreements which again
guard monetary investments.

to some, the value systems required of GPL users is not a problem. for
those for whom it is, GPL offers no alternatives but to abandon GPL'ed
software. I think this is quite tragic, but we need to look for new ways
to ensure the availability of source code when the GPL is so hostile to
those who do not share its values and money is no longer a common ground.

#:Erik
--
http://www.naggum.no/spam.html is about my spam protection scheme and how
to guarantee that you reach me. in brief: if you reply to a news article
of mine, be sure to include an In-Reply-To or References header with the
message-ID of that message in it. otherwise, you need to read that page.

Joachim Achtzehnter

unread,
Sep 4, 1998, 3:00:00 AM9/4/98
to
Klaus Schilling <Klaus.S...@home.ivm.de> writes:
>
> But the ilu source is only to look at. The license fails to allow
> the distribution of modification patches.
>
> ILU is not free software, due to the mentioned modification
> prohibition.

There is no such prohibition. But let the license speak for itself:

Unlimited use, reproduction, and distribution of this software is
permitted. Any copy of this software must include both the above
copyright notice of Xerox Corporation and this paragraph. Any
distribution of this software must comply with all applicable United
States export control laws. This software is made available AS IS,
and XEROX CORPORATION DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING WITHOUT LIMITATION THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE, AND NOTWITHSTANDING ANY OTHER
PROVISION CONTAINED HEREIN, ANY LIABILITY FOR DAMAGES RESULTING FROM
THE SOFTWARE OR ITS USE IS EXPRESSLY DISCLAIMED, WHETHER ARISING IN
CONTRACT, TORT (INCLUDING NEGLIGENCE) OR STRICT LIABILITY, EVEN IF
XEROX CORPORATION IS ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

There was a long discussion about this on the ILU mailing list
(archived are at www.findmail.com) back in December 1997. Richard
Stallman had consulted a laywer, Professor Eben Moglen. He pointed out
that there is no explicit mention of "modification" or "derivative
works" and, therefore, one cannot necessarily conclude that it is
allowed. However, neither can one conclude that modification is
prohibited, it would depend on what Xerox's intent was (said the
lawyer).

The response from Xerox was by one of the developers, Bill Janssen
(not a lawyer):

The current license is certainly intended to allow modification of
the code. We are sorry if Richard's interpretation of the licence
differs from ours; I've talked with him about this topic, but
(unfortunately) changing the copyright notice on ILU involves
opening a can of Xerox legal worms that I'm not eager to encounter.

In my opionion, to claim that distribution of ILU modifications is
prohibited is a wild misrepresentation of the facts. I accept Richard
Stallman's position to insist on wording that is 100% water-tight,
especially regarding possible use in Gnome which only exists because
of licensing issues with KDE/Qt in the first place. But to turn around
and say the ILU source is for viewing only is preposterous.

Joachim

PS: I am neither employed by for nor do I speak for Xerox.

--
joa...@kraut.bc.ca (http://www.kraut.bc.ca)
joa...@mercury.bc.ca (http://www.mercury.bc.ca)

Kent M Pitman

unread,
Sep 4, 1998, 3:00:00 AM9/4/98
to
Joachim Achtzehnter <joa...@kraut.bc.ca> writes:

I'm not a lawyer but circumstances you can all probably imagine have
caused me to read a bit of copyright law. The following is my lay
opinion, FWIW... (no warranty expressed or implied, etc.)

There are a number of specific orthogonally controlled rights (see 17
USC Sec. 106), such as: reproduction, derivative works, distribution
of copies, interpretive performance of a scripted work, display, and
public performance of a recorded work. The absence of an explicit
statement is not equivalent to a vaguery; it reserves the right.
Indeed, all works "fixed in a medium" are automatically copyrighted,
regardless of statement, and all rights therein are automatically
reserved. So it may be that Xerox intends you not to modify this work
(i.e., not to create a derivative work) and didn't mention it because
they didn't think they needed to, or it may be they intended to allow
it and failed to mention it, but I bet is very unlikely that some
lawyer omitted it thinking it would go without saying that you could
modify it. And I bet it's also very unlikely that you'll find a
lawyer who will tell you you're save in modifying it if this is the
statement. Further, as I understand it, copyright is conveyed using a
written instrument, not orally, so anything anyone at Xerox tells you
to reassure you is not worth anything if they don't put it in writing.

It may be that the confusion centers on the use of the term "use"
is used. To my knowledge, "use" is not a term of art and does not
unambiguously express the particular mode of use. (I don't know
that there are good terms to use, but I'd recommend more verbiage in
English to clarify.) "Unlimited use" might mean "no limit on when
and where and how many times the code is executed" and does not
unambiguously imply "no limit on rights to modify"--especially since
there IS a term of art ("create a derivative work") for expressing
that concept if it needs to be expressed. 17 USC Sec 117 on the
limitations of exclusive rights for computer programs doesn't
mention this for example, and uses the noun "adaptation" to apparently
refer to using a modified copy.

It is certainly plain that 17 USC Sec 6 neesd a clause 7 to enumerate
the specific issues involved in use of a computer program text, but
absent such you're in a bind.

> The response from Xerox was by one of the developers, Bill Janssen
> (not a lawyer):
>
> The current license is certainly intended to allow modification of
> the code. We are sorry if Richard's interpretation of the licence
> differs from ours; I've talked with him about this topic, but
> (unfortunately) changing the copyright notice on ILU involves
> opening a can of Xerox legal worms that I'm not eager to encounter.

Again, I'm not a lawyer, but I'd bet that while electronic
communication like a README file with a software release would stand
up as "written", an e-mail message in general is probably more
questionable. Especially one like this which merely referred
obliquely to intent and didn't come out and say firmly "I, whomever,
hereby grant you the following specific rights...."

If unsure, get a lawyer to tell you for sure--and insist on a
copyright lawyer, since in my experience general legal practioners not
having studied copyrights specially are often as confused about
copyright law as any lay person.

> In my opionion, to claim that distribution of ILU modifications is
> prohibited is a wild misrepresentation of the facts. I accept Richard
> Stallman's position to insist on wording that is 100% water-tight,
> especially regarding possible use in Gnome which only exists because
> of licensing issues with KDE/Qt in the first place. But to turn around
> and say the ILU source is for viewing only is preposterous.

Where Richard and I part in apparent opinion is that he probably moralizes
about whether it's right to make something nonmodifiable. I don't mind
if anyone does that. But where we appear from the above representation
to agree is that legally the above boilerplate allows you only to distribute
unmodified copies.

You can find the US Code on Copyright itself at:
http://www.law.cornell.edu/uscode/17/
You can find 17 USC Sec 106 at:
http://www.law.cornell.edu/uscode/17/106.shtml
Likewise 17 USC Sec 117 is in:
http://www.law.cornell.edu/uscode/17/117.shtml
You can find numerous pointers to general legal resources at my page
http://world.std.com/~pitman/law.html

Joachim Achtzehnter

unread,
Sep 4, 1998, 3:00:00 AM9/4/98
to
Kent M Pitman <pit...@world.std.com> writes:

> I'm not a lawyer... [long legal discussion omitted]

Well, you certainly sound like one... :-)

Earlier Joachim had said:
>
> > In my opionion, to claim that distribution of ILU modifications is
> > prohibited is a wild misrepresentation of the facts. I accept Richard
> > Stallman's position to insist on wording that is 100% water-tight,
> > especially regarding possible use in Gnome which only exists because
> > of licensing issues with KDE/Qt in the first place. But to turn around
> > and say the ILU source is for viewing only is preposterous.

Reading my own words again, I realise that I should have been a little
more explicit: The last sentence was not referring to anything Richard
had said, instead somebody else was making such claims. As I said,
I find Richard's position acceptable.

> legally the above boilerplate allows you only to distribute
> unmodified copies.

Yes, no big objection, this is all you can be sure of without further
clarification by Xerox or by a court decision. What I was objecting to
were statements that claimed flat out that the ILU copyright PROHIBITS
modifications of source code or redistribution thereof. Even with the
weak interpretation of "unlimited use", which lawyers appear to prefer
in this case, it would still be up to Xerox to state whether or not
modification is permitted or not. This was also the opinion of Richard
Stallman's lawyer, who said in the mailing list discussion I mentioned
earlier that once Xerox makes an authoritative statement to the effect
that "unlimited use" was meant to include modifications, then this
would be sufficient for Stallman's purposes and it would not be
necessary to change the actual wording of the license.

An employee of Xerox who is one of the principal developers of ILU,
and who represents Xerox at the OMG, stated that this was indeed the
intention. One can argue whether or not he had suffient authority in
these matters, or whether email is sufficient or not for legal
purposes. But all indications are that Xerox's interpretation of the
term "unlimited use" did cover modification of source code. I have no
problem if people insist on a more definitive legal statement from
Xerox, but to state flat out that the license prohibits modifications
is not supported by facts, IMHO.

Joachim

Kent M Pitman

unread,
Sep 5, 1998, 3:00:00 AM9/5/98
to
Joachim Achtzehnter <joa...@kraut.bc.ca> writes:

> What I was objecting to
> were statements that claimed flat out that the ILU copyright PROHIBITS
> modifications of source code or redistribution thereof.

But what I'm saying is that this is a distinction without a
difference. My understanding is that the default situation is that
you are prohibited. So unless it gives permission, it amounts to the
same.

> Even with the
> weak interpretation of "unlimited use", which lawyers appear to prefer
> in this case, it would still be up to Xerox to state whether or not
> modification is permitted or not.

This is not my understanding of the law. My understanding of the law
is that you are automatically protected even with NO notice and that
a giving of one of the six kinds of notice is not to be construed as
a giving of any of the others.

Certainly in the end, all legal situations come down to a matter of
aspiration and intimidation. If it is not the aspiration of Xerox to
sue you, then the legalese has no operational effect no matter how
strong it might be. If you are adequately intimidated, then no matter
how liberal the wording is, it doesn't matter. So to some degree your
task is to reliably assess your risk within the bounds these
establish. (Just to keep this on topic: Programming languages are
really no different. Sometimes we'll tell you a behavior is undefined
but you may find it works fine for you. For some people, that's
enough. For others, it's not.)

> This was also the opinion of Richard
> Stallman's lawyer, who said in the mailing list discussion I mentioned
> earlier that once Xerox makes an authoritative statement to the effect
> that "unlimited use" was meant to include modifications, then this
> would be sufficient for Stallman's purposes and it would not be
> necessary to change the actual wording of the license.

I know lawyers who won't rely on such statements. I imagine that
has something to do with taste for risk, willingness to litigate,
etc.



> An employee of Xerox who is one of the principal developers of ILU,
> and who represents Xerox at the OMG, stated that this was indeed the
> intention.

You'd better not take any statement I make about Harlequin's legal
posture from anything I say. I'm permitted to speak for Harlequin in
design meetings, etc. but I don't speak for the company's legal force.
I'd be terribly surprised if Xerox allowed non-lawyers to speak for
any of its legal posture. Unless the person is an officer of the
company, I suspect he doesn't have legal standing to be defaultly
assumed as representative of the company, but my understanding of
business law is much more sketchy and I might be confused on that.

> One can argue whether or not he had suffient authority in
> these matters, or whether email is sufficient or not for legal
> purposes. But all indications are that Xerox's interpretation of the
> term "unlimited use" did cover modification of source code. I have no
> problem if people insist on a more definitive legal statement from
> Xerox, but to state flat out that the license prohibits modifications
> is not supported by facts, IMHO.

It's a safer thing to state than to say it permits modifications.
Both legally, and in terms of the consequences. The point is that
anyone who wants to proceed absent a specific wording should be
consulting a lawyer or knowing they're at some risk. Telling them
they're not is what seems flat out wrong to me.

In general, I think the default assumption is that you are always at
legal risk, certainly in the US, and that all lawyers are ever really
capable of doing is working with you to take steps to have that legal
risk be at a comfortable point. :-)

All of the above is just my (non-lawyer) opinion.

Tim Bradshaw

unread,
Sep 5, 1998, 3:00:00 AM9/5/98
to
* Kent M Pitman wrote:
> Joachim Achtzehnter <joa...@kraut.bc.ca> writes:
>> What I was objecting to
>> were statements that claimed flat out that the ILU copyright PROHIBITS
>> modifications of source code or redistribution thereof.

> But what I'm saying is that this is a distinction without a
> difference. My understanding is that the default situation is that
> you are prohibited. So unless it gives permission, it amounts to the
> same.

For what it's worth, I am fairly sure that under British copyright law
(about 10 years ago, so it may be EU copyright or something else
now!), that this is exactly the default situation: if it doesn't *say*
you can do these things, you can not do them.

I'm not a lawyer either!

--tim

Martin Cracauer

unread,
Sep 5, 1998, 3:00:00 AM9/5/98
to
Bjoern-Falko Andreas <and...@ki.informatik.uni-ulm.de> writes:

>> > I have seen a posting from somebody saying that he had made good

>> > experiences with Xerox PARCs ILU. My major concern is the stability


>> > of ILU, since we would have to rely on it.
>>

>> This may have been my posting. We are using ILU for a major
>> project. Certainly, there are rough edges, it is still classified as

>> alpha software after all. But the pieces that exist work well. And let


>> us not underestimate the value of having access to the source code!

>Ho-hum. Do you know when the 2.0 final of ILU is due? We all _KNOW_ the


>horror of browsing through code we haven't written ourselves. I remember
>patching and debugging and extending Jim Firbys RAP. And I guess,
>everybody will agree that scarcly documented LISP code isn't very easy
>to understand.

Did you actually look at the source code? So you think this whole
source-available software thing is for masochists.

As someone who actually had to digg into the C parts of ILU code I
assume you there is nothing in it that supports your claim, except for
people who are write-only coders.

>>
>> > Is ILU preferable to ORBlink?
>>

>> Really can't say because I haven't seen ORBlink. Had some early
>> discussions with one of the Franz people who designed the mapping, and
>> judging by that it seems Franz have chosen a CORBA mapping that is
>> incompatible with the one used in ILU. The OMG has not yet
>> standardised a Lisp binding! So switching in mid-project will require
>> some effort.

Yes, but I doubt anyone would prefer to have a standard formed before
its time, with unforseen drawbacks to no end and be locked in it for
the next 10 years.

>I think nobody besides us is really interested in LISP. Everybody is
>jumping onto the Java bandwagon. Lisp isn't supported as it deserves.

The C folks already declare victory over Java. So what?

It is sad that the Lisp part of ILU doesn't get more contributors and
I have to touch my own nose here, but I currently have other goals
than Lisp or Corba.

I don't think the situation of Lisp in projects like ILU is not as bad
as it seems. From my observation, the Lisp community is just a little
behind other languages when it comes to support free software.

Although there are many free Lisp packages, multi-person
Internet-based maintainance just had begone.

CL-HTTP, CMUCL and CLISP are Lisp projects powered by a kind of
community that made this now called "OpenSource" projects happen. On
the contrary, languages like Python and Perl grew up in such a
community from start.

It's only a question of time when other Lisp software joins it,
creating a snowball effect. MK:DEFSYSTEM, (by the athour answering
license questions again or by reimplementation), a GUI toolkit (CLIM
if some free source shows up, Garnet when not) and people improving
Lisp support for free ORBs are upcoming.

>Anyway, I have to connect LISP, C/C++ and Java processes. And I don't
>want to write this stuff, when there already are solutions for this.

ILU just does this, at a cost and the cost is to stop complaining
about things that might be there and spend the saved time approaching
the problems that are real.

Martin

Erik Naggum

unread,
Sep 6, 1998, 3:00:00 AM9/6/98
to
* Bjoern-Falko Andreas <and...@ki.informatik.uni-ulm.de>

| We all _KNOW_ the horror of browsing through code we haven't written
| ourselves. ... And I guess, everybody will agree that scarcly

| documented LISP code isn't very easy to understand.

(I have started to respond to this several times, never finishing because
it seems like such an obviously counter-productive attitude, and the
arguments against it so obvious, but let's give it a shot.)

first, I have been working with other people's code as a firefighting
consultant for the past 15 years. projects have failed or are close to
failing or are unmaintainable when I get called in. still, I'd rate only
10% of the code I have not only "browsed", but thoroughly analyzed, as "a
horror". let me give you an example of horrible string comparison in C.
yes, this is _actual_ code from a past project. comments are redundant.

if (( Buffer[ 0] | 0x20) == 'f' &&
( Buffer[ 1] | 0x20) == 'l' &&
( Buffer[ 1] | 0x20) == 'o' &&
( Buffer[ 2] | 0x20) == 'w') {
Flow = 1;
Buffer+=4;
}

while not very accurate numbers, I could rate 20% as "uncomfortable", 30%
as "comfortable", and 40% as "a breeze". of the _free_ source I have
looked at, _nothing_ has come close to the shitware produced by huge
outfits like Anderson Insulting. programmers who actually have to
maintain their own code also make a huge effort to keep it maintainable,
compared to the drones who code for the big consulting firms -- they know
they will _never_ see their own code again, and only the low-lives (fresh
out of school) will maintain such code, thus learning only bad habits
from "real" code they are exposed to, and probably learning to hate other
people's code in general, too. (this is why I want good source code to
be available for everybody to learn from and the author to be proud of.)

second, the ability to read and understand code in a language well enough
to acquire an intuition that works is _essential_. that is, when you
think _in_ the language, as opposed to think in some other language and
then translating into the programming language, it doesn't really matter
how ugly the code is, you still see _what_ it does, even if it takes a
little more effort to read than well-written code.

third, it's the _why_ that needs documenting, and if the general plan is
well enough explained, comments most often just get in the way. Lisp has
documentation as part of the language, and they should be used to convey
proper documentation of the interface and intended use. that's all you
should need if the implementation is solid, and if it isn't, you either
fix it so it is or drop it entirely. in any case, the contract with your
callers is what matters. if it is spelled out and fully obeyed, the code
can look like shit or be exploiting undefined or implementation dependent
features or system internals all it wants.

fourth, I have never found a language easier to understand than Common
Lisp, documented, undocumented, commented, uncommented, whatever. while
there are a lot of ways to do most things in Common Lisp, I have yet to
stumble on a disingenious exploitation of cryptic side effects, such as
are frequently the _rule_ in the Unix languages.

so, in summary, I _KNOW_ what working with other people's code means and
what effort and concentration it takes, yet I don't recognize the pain
and suffering that some people impute to _all_ code they have not written
themselves (which kind of tells me _they_ write really bad code).
however, I must admit to having stopped using the phrase "the worst code
I have ever seen" after I had spent a few months with 25,000 lines of
mind-boggling stupidity in the project I showed a small piece of above.

Kent M Pitman

unread,
Sep 6, 1998, 3:00:00 AM9/6/98
to
Erik Naggum <cle...@naggum.no> writes:

> [...] first, I have been working with other people's code as a


> firefighting consultant for the past 15 years. projects have
> failed or are close to failing or are unmaintainable when I get
> called in. still, I'd rate only 10% of the code I have not only
> "browsed", but thoroughly analyzed, as "a horror". let me give
> you an example of horrible string comparison in C. yes, this is
> _actual_ code from a past project. comments are redundant.
>
> if (( Buffer[ 0] | 0x20) == 'f' &&
> ( Buffer[ 1] | 0x20) == 'l' &&
> ( Buffer[ 1] | 0x20) == 'o' &&
> ( Buffer[ 2] | 0x20) == 'w') {
> Flow = 1;
> Buffer+=4;
> }
>

> [...] the ability to read and understand code in a language well
> enough to acquire an intuition that works is _essential_. [...]

Without detracting from your other remarks, I want to
opportunistically leap in here in strong defense of the novice and of
the idea that intuition is not to be acquired, but to be kept from
premature death.

Note: Practically speakiing, the processes I discuss below are "long
arc" processes that can't solve one's problems today and what you are
speaking about is really "short arc" stuff about how to cope
day-to-day. So we're talking at a certain amount of crossed purposes,
and I don't mean to really contradict the points you're making--but
only to say there are some powerful truths which are in tension with
the truths you're expounding, and to encourage people to understand
that we don't get to decide that the world contains no conflicting
truths, we only get to decide to either deal with the fact of
conflicting truths or find we've overlooked important priorities in
the process of (over)simplifying things to our liking.

You can hardly blame them. I don't write much C but I'll come right
out and admit I did this very thing myself until I caught onto the
"trick" of C; that is, (a) the language is kept "small" by having
absolutely essential stuff (i'm sorry, but I don't consider strings
optional) into libraries that don't count as part of the language and
(b) programs like strcmp are named in obscure ways that defy easy
recognition as what you wnat.

I'm not trying to bash C, just obliquely to defend that I think
Lisp did the right thing, no matter what some people say (and they
do say it) by putting the 'library' in the language and by using
names that containing meaningful substrings, and by providing apropos.

The idea that 'string' is not a primitive datatype is as bad as the
idea that a character is not a primitive datatype (which it wasn't in
Maclisp--Common Lisp in 1984 finally fixed that, but before that
people variously used fixnum or symbol for characters). C would have
done well to fix the absence of string at the same time. Being able
to 'implement' a string is not the same as being able to 'express' a
string, IMO; not computationally more, but conceptually more.

But if you adopt the attitude that it's not, and that strings are just
arrays of chars, you should ABSOLUTELY expect that users of your
language will use array operations just as you show above. It is the
naive user who has nothing to be embarrassed for, and the language
that has everything to be embarrassed for, and the savvy
expert/guru/wizard will (IMO) lay the blame appropriately, not protect
his job by saying "when you are old and have studied long, you will
understand as I do and in the meantime people can pay me well to know
should-be-obvious facts". I'm not accusing you personally of being
such a person, trying to protect his job in the amassing knowledge of
trivial bugs rather than merely fixing them, but I am saying the
industry as a whole appears to me to have a few of those.

In Maclisp, there were numerous operations that appeared to do certain
things but you'd find that they weren't as bullet-proof as you thought
because myriad special variables or extra args had strange effects
that most programmers did not understand. For a while, I started to
amass this trivia and think myself a wizardly programmer for knowing
it when others did not. But fortunately, this was a phase I passed
through and it wasn't long before I realized that these problems were
avoidable by better design and that it wasn't winning any friends for
Lisp to have the semantics be so darned obscure. (The error system
was full of problems like that. One was that you had a way of
signalling an error type along with an error. There were only a
handful of built-in types and if you didn't have an error of the
standard type, you couln't specify a type. But if they had one, naive
users would often gleefully provide it. However, and this bit me
several times, if you provided it and weren't prepared to handle it,
as in:
(unless (boundp var)
(error ...args i don't remember exactly...))
you got screwed because a call to ERROR with the extra info about the
type ALSO meant that you were prepared to have the function ERROR
return a value to use. So you had to do
(unless (boundp var)
(set var (car (error ...))))
or some such thing. Failure to do this assignment meant your program
executed forward with bad data and was unreliable. In modern Lisp,
we fixed that by applying what I now (thanks to jonl white's naming)
call Pitman's Two-Bit Rule: Don't try to represent two bits of
information with a single bit. In this case, when people specify
the error type they are not saying they are prepared to handle; that
information must be supplied orthogonally in CL; and it also means
you can supply the information in CL about how to proceed without
supplying the error type.

Some problems are ubiquitous and should be solved centrally. C did
not solve its string problem centrally (and numerous others) so users
suffered. C++ and Java and even Dylan are, to some extent attempts to
fix this by frustrated users who could no longer wait for the solution
from C central.

A design principle I personally use a lot for Lisp and think others
should seriously consider is to jealously guard whatever insight you
can from the rare untainted mind with the wisdom to program in ways
intuitive. Too many we see and think of as naive have already been
polluted into doing things in obscure ways, and after a while we come
to think of the obscure as the way that's right.

Often a novice will say something obscure and you'll be tempted to
just dismiss it because it doesn't fit into the overall model of what
you've developed. Perhaps sometimes dismissing it IS right. But it
is not a priori right just because it doesn't fit. Sometimes it's the
missing link between a powerful system and an intuitive system. When
you have time, give it the time of day it deserves and ask yourself if
the world would be such a bad place if we catered to the intuitions
people have.

In T (Yale Scheme), there's a notion called the "locale". (Or there
was. I haven't checked recently.) It came about because Jonathan
Rees and I had a big fight over "global environments". He said
(correctly) that global environments were bad because people would
bash each others' code in the global environment. And I said (I think
correctly) that although they were bad, people liked them and got
power from them even if they were semantically bad. So after much
debate, I suggested the notion of something we came to call a
"locale", which gave a kind of local feeling of being global. Where
if you set a variable, you didn't have to bind it first. But the
binding wasn't really created in a global environment, just an
environment that added new bindings as needed. There could be many
such locally global environments, so unrelated users didn't step on
one another.

My Lisp Pointers paper http://world.std.com/~pitman/PS/Ambitious.html
offers yet another example of how if you free yourself of the
preconceptions of being an expert, you can learn something from
novices.

I enjoy creating various binary partitions of languages and then
seeing how various languages fall into the sides. Among them is the
partition which is "languages that restrict what's possible to reason
about by what's known to be possible to implement" vs "languages that
offer tools for how people really want to reason and make a commitment
to find a way to implement it". Most languages fall in the former
camp. C and (I think) Scheme among them. (IMO, that's why I don't
think Scheme is a Lisp). Lisp, Prolog, and Smalltalk are
in the latter camp. (For example, Prolog paid its price of admission
to the 'stretch the imagination' camp when it went back and added
'cut' in recognition of how 'far out' its ideas had been, but still
stuck by its fundamental style of expression rather than retrench in
the safety of what was efficient and well-understood.)
Lisp, too, is a language about expression and imagination, rather
than about reduction of ideas to mere implementation. In Scheme, many
things are not there just to keep things small, but some are absent
also because they're hard to implement efficiently. Lisp offers
things that are hard to implement efficiently in some cases because it
knows that people will still do them whether you offer them in the
language or not. And by offering them in a central, well-defined way,
improvements can be made over time so that programs we write today
will also speak to the future, with only the language implementation
needing upgrade. (GC is a perfect example; it was added to the
language long before we really understood all its implications, but it
has grown up with the language as a result of our commitment to the
need, not the ability. Lisp's declarations are another promise it
makes to the future, since there are many more declarations one can
make than one has optimizations for at this moment.) Any language
that never offers a feature it can't efficiently implement is destined
to be obsolete soon because people think up new ways to efficiently
implement things all the time. So this is once again a reason to
trust what people "want to do" more than "what you thionk you can do".

Erik Naggum

unread,
Sep 6, 1998, 3:00:00 AM9/6/98
to
* Erik Naggum (quoting horrible code _not_ his own)

| if (( Buffer[ 0] | 0x20) == 'f' &&
| ( Buffer[ 1] | 0x20) == 'l' &&
| ( Buffer[ 1] | 0x20) == 'o' &&
| ( Buffer[ 2] | 0x20) == 'w') {
| Flow = 1;
| Buffer+=4;
| }

* Kent M Pitman <pit...@world.std.com>


| You can hardly blame them. I don't write much C but I'll come right out
| and admit I did this very thing myself until I caught onto the "trick" of
| C; that is, (a) the language is kept "small" by having absolutely
| essential stuff (i'm sorry, but I don't consider strings optional) into
| libraries that don't count as part of the language and (b) programs like
| strcmp are named in obscure ways that defy easy recognition as what you

| want.

ok, so I won't try to detract from your points, either, but when out of
those 25,000 lines, 8,000 lines are individual character comparisons like
this, instead of being smart enough to save himself a _lot_ of work and
write a _new_ function that did whatever strncasecmp does if he didn't
know it, he did this, there's no way I'm going to give him any lenience,
and certainly not when he must have been a "novice" for a least 10 years
(he had quoted "10 years experience in C" on his resumé at he time he was
hired by the consluting company). novices are cool only as long as they
don't stay that way for very long. I don't think a _real_ novice would
do the "| 0x20" bit (sorry), either.

however, the reason I picked this one particular example was that this
stupid "programmer" compared the second character of the "Buffer" against
_both_ `l' and `o', causing the test to fail always, and it's damn hard
to _spot_ that mistake because of the boneheaded way he wrote his code.
(it seems you missed this on your first reading. I won't blame you...)

incidentally, if this has been code delivered in the course of some
education the poor sap was _paying_ for, it'd been OK, but when you pay
for a programmer, you should be able to expect him to be fully educated.
(however, "C programmers" who can barely spell "C" get jobs these days.)

oh, the system has been completely reimplemented in 2500 lines of Common
Lisp, runs about 10 times faster on similar hardware, does not crash, and
is a _lot_ easier to administrate. further, it could _easily_ have been
written in "only" 10,000 lines of C.

Tim Bradshaw

unread,
Sep 7, 1998, 3:00:00 AM9/7/98
to
* Bjoern-Falko Andreas wrote:
> Ho-hum. Do you know when the 2.0 final of ILU is due? We all _KNOW_ the
> horror of browsing through code we haven't written ourselves. I remember
> patching and debugging and extending Jim Firbys RAP. And I guess,

> everybody will agree that scarcly documented LISP code isn't very easy
> to understand.

This is a kind of parallel remark to Erik's, I think I agree with him
but I started this before I got his article!

I think that going through code not written by yourself isn't
necessarily a horror. I think it's probably an acquired skill, which
after a while can actually become quite enjoyable. It is certainly
possible to approach quite large systems and produce modifications to
them or fix bugs in a reasonable time -- I've done that on numerous
occasions for a wide range of systems. The main techniques I find
useful are not trying to understand the whole thing, and not being
frightened by how large it is. For someone in my position (system
manager in an academic unix environment), it is a very useful skill
to have indeed!

Lisp systems are typically easier to understand than C (say), but
there are different pathologies that occur in Lisp. One of the
problems with some Lisp code I've had to deal with is that it is
written by people who are really academics, and seem to not think it
is worth learning how to program well. In at least some of these
circumstances it's been clear that the right approach was
reimplementation.

Unlike Erik though, I don't find C unspeakably bad. That may be
because most of the C systems I've dealt with have been effectively
`open source' from the start, and people like to avoid being
publically embarrassed!

In fact, I think that the good code quality of open source systems is
an extremely strong reason why they are worth using even for
commercial people (not to mention that you can fix bugs really fast if
you need to and are not afraid of the source!).

--tim

--
Tim Bradshaw, System Manager,
Artificial Intelligence Applications Institute,
University of Edinburgh

Bjoern-Falko Andreas

unread,
Sep 10, 1998, 3:00:00 AM9/10/98
to
Joachim Achtzehnter wrote:
>
> Bjoern-Falko Andreas <and...@ki.informatik.uni-ulm.de> writes:
>
> > Joachim Achtzehnter wrote:
> > >
> > > And let us not underestimate the value of having access to the
> > > source code!
> >
> > We all _KNOW_ the horror of browsing through code we haven't written
> > ourselves. I remember patching and debugging and extending Jim
> > Firbys RAP. And I guess, everybody will agree that scarcly
> > documented LISP code isn't very easy to understand.
>
> What point are you trying to make? Maybe the source code is not easy
> to understand, but the alternative is to not have access to source
> code!

Of course you are right. Not having the source isn't nice. But see, I
spent 1/4 year trying to understand a big LISP project. It's very hard
to track which function does what and tracking down bugs due to not
passing initial parameters in recursions. Just for instance. Of course I
like to have the sources. But I even more prefer not having to have
them, if you get my point.

CU/2 Bjoern

Bjoern-Falko Andreas

unread,
Sep 10, 1998, 3:00:00 AM9/10/98
to
Martin Cracauer wrote:
>
> Bjoern-Falko Andreas <and...@ki.informatik.uni-ulm.de> writes:
>
> >> > I have seen a posting from somebody saying that he had made good
> >> > experiences with Xerox PARCs ILU. My major concern is the stability
> >> > of ILU, since we would have to rely on it.
> >>
> >> This may have been my posting. We are using ILU for a major
> >> project. Certainly, there are rough edges, it is still classified as
> >> alpha software after all. But the pieces that exist work well. And let

> >> us not underestimate the value of having access to the source code!
>
> >Ho-hum. Do you know when the 2.0 final of ILU is due? We all _KNOW_ the

> >horror of browsing through code we haven't written ourselves. I remember
> >patching and debugging and extending Jim Firbys RAP. And I guess,
> >everybody will agree that scarcly documented LISP code isn't very easy
> >to understand.
>
But LISP is only a niche. There's only a little bunch of supporters. I
wonder about it's future. No, I'm not worried about its death but mor
about stagnation. Don't get me wrong. I strongly believe in LISP. Once
you used it, you gotta love it. But you know the pains of creating big
LISP applications. You'll always come to a point where there is a need
of connecting to C/C++ processes and defforeigning to C/C++ clients for
some server processes isn't exactly what I'd call a clean solution. What
I want is a standard for doing so, not proprietary ACL or anything else.
There is a need for a IPC standard for LISP and as far as I can see,
there's none on the horizon. A Harlequin/Franz alliance is only a
shimmer on the horizon, but no standard. That's what I meant by LISP not
getting what it deserves. Face it, the future lies in distributed
applications and if we aren't able to find clean solutions, we'll find
ourselves on the loosers lane.
BTW at the moment I'm doing the LISP coding on a large distributed OS
for robots. Considering this, you'll understand why I am a little bit
anxious. I'm the only active guy in this project who can handle LISP. If
I were to quit, the project would be thrown back at least 1/2 years. And
I'm only a student who has just finished his bachelor in computer
siences.

CU/2 Bjoern


--
I wonder about the purpose of this .signature file. I've found no
man-page dealing with it. How do I quit vi? ZZ :q erm ESC first, you
dummy

Bjoern-Falko Andreas

unread,
Sep 10, 1998, 3:00:00 AM9/10/98
to
Erik Naggum wrote:
>
> * Bjoern-Falko Andreas <and...@ki.informatik.uni-ulm.de>

> | We all _KNOW_ the horror of browsing through code we haven't written
> | ourselves. ... And I guess, everybody will agree that scarcly

> | documented LISP code isn't very easy to understand.
*snip*


> so, in summary, I _KNOW_ what working with other people's code means and
> what effort and concentration it takes, yet I don't recognize the pain
> and suffering that some people impute to _all_ code they have not written
> themselves (which kind of tells me _they_ write really bad code).
> however, I must admit to having stopped using the phrase "the worst code
> I have ever seen" after I had spent a few months with 25,000 lines of
> mind-boggling stupidity in the project I showed a small piece of above.
>
> #:Erik

Somehow you didn't really convince me. There is still no standard of how
to write maintainable code. There are many strategies and you cannot
know all. I'm quite able to understand what I have produce a year ago,
since I know my style. But the style of other people? You have to admit
that understanding their line of thought isn't always easy to
understand. I rest my case. I prefer not to have to have the source,
though having it can be useful. In my blackest moments I wonder if I
wouldn't be better off, if I did my stuff all alone. For instance, I had
to track down a bug that showed up only 1 in a 1000 times. I wasn't even
able to locate where it originated from. After spending 16+ hours of
tracing in one session I found it. By sheer luck. It's still preferrable
not to have to do this. There is not enough aspirin in the world to cure
all the headaches browsing foreign code produces.

Rainer Joswig

unread,
Sep 11, 1998, 3:00:00 AM9/11/98
to
In article <6srkmd$lco$1...@wavehh.hanse.de>, crac...@wavehh.hanse.de
(Martin Cracauer) wrote:

> Although there are many free Lisp packages, multi-person
> Internet-based maintainance just had begone.

Emacs? The mother of all "free" software?

> CL-HTTP, CMUCL and CLISP are Lisp projects powered by a kind of
> community that made this now called "OpenSource" projects happen. On
> the contrary, languages like Python and Perl grew up in such a
> community from start.

Well, the Lisp machines always had lots of source and
its user were improving this. Same for MCL. It comes
with lots of code and users made lots of contributions.
So the free source code even worked for users of commercial
Lisp systems.

I think in 40 years of Lisp there should be lots of "Open Source"
success stories available. Lisp was already there when most
of these programmers didn't even know they are going to
reinvent the wheel.

> if some free source shows up, Garnet when not) and people improving
> Lisp support for free ORBs are upcoming.

I for my person do not believe to much in the "Open Source" ideology.
I'd prefer a commercial backed Lisp machine over tons of free adhoc
code everyday. A lot of current stuff is just a copy what is
already out there, loses in a big way, has sick design (Unix!), etc.

There is lots of code out there. Still we have few users and
we have even fewer applications. In theory it should be
easy to write a cool mail server in Lisp. In practice,
(almost) nobody is doing this. Instead stuff like PERL/TCL/Python
is being used.

Coming up with a design that is elegant and will survive is
always hard. Lisp has this kind of design - Lisp applications
with the same properties are needed.

Rainer Joswig

Erik Naggum

unread,
Sep 11, 1998, 3:00:00 AM9/11/98
to
* Bjoern-Falko Andreas <and...@ki.informatik.uni-ulm.de>

| But LISP is only a niche. There's only a little bunch of supporters. I
| wonder about it's future.

you just described the music I like, as well. somehow, I enjoy what's
already there and support artists who create the music I like, instead of
wondering about its future. I think that's how it will _have_ a future.

| But you know the pains of creating big LISP applications.

I know the pain of creating big applications in C, and creating big Lisp
applications is a breeze _in_comparison_. however, nothing great is ever
easy. everything worth doing takes a lot of hard work and causes pain
for the creators. that's why it's important not to waste hard work and
pain on that which isn't worth doing, and _that_ is the lesson many have
yet to learn.

| You'll always come to a point where there is a need of connecting to
| C/C++ processes and defforeigning to C/C++ clients for some server
| processes isn't exactly what I'd call a clean solution. What I want is a
| standard for doing so, not proprietary ACL or anything else.

why doesn't C and C++ come with a standard way to interface to Lisp?

Erik Naggum

unread,
Sep 11, 1998, 3:00:00 AM9/11/98
to
* Bjoern-Falko Andreas <and...@ki.informatik.uni-ulm.de>

| There is still no standard of how to write maintainable code.

why this clamoring for standards?

| But the style of other people? You have to admit that understanding
| their line of thought isn't always easy to understand.

no, it isn't _always_ easy. but so? I said 10% were a horror, and 20%
were uncomfortable, but the _rest_ is "easy". however, it sounds like
you are of the "easy generation", for whom everything must be easy.

| For instance, I had to track down a bug that showed up only 1 in a 1000
| times. I wasn't even able to locate where it originated from. After
| spending 16+ hours of tracing in one session I found it. By sheer luck.
| It's still preferrable not to have to do this. There is not enough
| aspirin in the world to cure all the headaches browsing foreign code
| produces.

the cause of your headaches isn't "foreign code", it's your attitude to
work in general. debugging is painful, it's a fucking waste. sometimes,
it's better to rewrite the code from scratch. sometimes it's better to
scrap the whole damn thing and consider it impossible. which is better
of debugging, reimplementing, and abandoning takes some experience to
know. if debugging is the best choice, at least you know the other two
choices are more work and/or less rewarding. that's _something_.

FYI, I spent nine months debugging and understandign 25,000 lines of
horrible C code -- it was fun in the way that all meaningless challenges
are. you'll have a very hard time convincing me you deserve sympathy for
your 16+ hours. the most insidious bug in GNU Emacs I found was so hard
to pin down I found it only after having worked on it for more than 300
hours over several months. you see, I _hate_ crashes, and this was a bug
that _sometimes_ caused Emacs to attempt to redraw the screen before it
had updated its size parameters after a resize, causing Emacs to write
screen contents into all sorts of unrelated memory, some of which took
until the next GC to crash Emacs, and some of which caused bizarre
behavior elsewhere. this is not the proper forum for macho bug-killing
stories, however. you just need to know that we've all been there and
that we've all spent days, weeks, or months on trivial problems. it's
what this trade requires of its practitioners, just like doctors have to
live with patiens who die. it sucks, but if you can't hack it, get out.

Jason Trenouth

unread,
Sep 11, 1998, 3:00:00 AM9/11/98
to
On Thu, 10 Sep 1998 23:03:52 +0200, Bjoern-Falko Andreas
<and...@ki.informatik.uni-ulm.de> wrote:

...


> You'll always come to a point where there is a need
> of connecting to C/C++ processes and defforeigning to C/C++ clients for
> some server processes isn't exactly what I'd call a clean solution. What
> I want is a standard for doing so, not proprietary ACL or anything else.

> There is a need for a IPC standard for LISP and as far as I can see,
> there's none on the horizon. A Harlequin/Franz alliance is only a
> shimmer on the horizon, but no standard. That's what I meant by LISP not
> getting what it deserves. Face it, the future lies in distributed
> applications and if we aren't able to find clean solutions, we'll find
> ourselves on the loosers lane.

Hey. Franz and Harlequin are producing the standard CORBA IDL binding for
Common Lisp. The OMG demands that systems which meet the standards are
commercially available from the specification submitters within a given time
frame, so we've been working together on both a specification _and_ our
implementations.

If you can make it to Comdex Enterprise in Frankfurt you can see Harlequin's
Common Lisps talking to C++, Java, and Dylan via IIOP. Or check out Franz's
ORBLink or Xerox's ILU.

Distributed programming solutions for Common Lisp are here now. Standards
ratification is just around the corner. If you've got an application that
needs this stuff, then get in touch.

Regards,

__Jason

Joachim Achtzehnter

unread,
Sep 11, 1998, 3:00:00 AM9/11/98
to
Bjoern-Falko Andreas <and...@ki.informatik.uni-ulm.de> writes:
>
> I'm quite able to understand what I have produce a year ago, since I
> know my style. But the style of other people? You have to admit that

> understanding their line of thought isn't always easy to
> understand. I rest my case. I prefer not to have to have the source,
> though having it can be useful. In my blackest moments I wonder if I
> wouldn't be better off, if I did my stuff all alone.

What world do you live in? Do it all alone? Never use software that
wasn't written by you? Tell this to the manager of a major bank! Or to
anybody responsible for a large software system! You must have seen
only a very small segment of the software business to have such an
opinion.

Writing a big software system from scratch is a prescription for major
failure. Successful large systems grow in an evolutionary way. And
working with other people's software is unavoidable with such big
systems.

> For instance, I had to track down a bug that showed up only 1 in a
> 1000 times. I wasn't even able to locate where it originated
> from. After spending 16+ hours of tracing in one session I found
> it. By sheer luck. It's still preferrable not to have to do this.

Sure, it is preferable to have bugfree software. What else is new? In
reality, however, you just won't find bugfree software once it reaches
a certain complexity.

0 new messages