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

Java/Lisp Language Evolution Correlates

29 views
Skip to first unread message

vsync

unread,
Jun 14, 2000, 3:00:00 AM6/14/00
to
Eew... Micros~1 sm*rtq**tes!

PM <deja...@my-deja.com> writes:

> I've noticed an interesting similarity between the evolution of the
> Java and Lisp languages. Lisp (and more recently CLOS) have evolved
> over a period of decades to become a rather bloated language and

I don't know... I rather enjoy the choice I have with Common Lisp.
I've looked at Scheme, but it seems way too pared-down for real work.
IMHO of course.

> library combination. Java, on the other hand, has done exactly the
> same thing, but in "internet-time", managing to become a bloated
> abomination far faster than any other programming language in history.

Same as above. Another thing to remember is that many of the packages
(especially those starting with anything other than "java." (except
for Swing, of course (why they didn't put that in "java." instead of
"javax." is beyond me))) aren't part of Java per se, but just
libraries that Sun and others have made. They're also working on
promoting Java in Micro, Standard, and Enterprise editions, something
I have mixed feelings about, but it should cut down on some
unnecessary bloat.

> The only real difference is that Lisp, as a language, was far better
> designed from the outset and has maintained its utility over time
> because of this, whereas the Java language lacked any real

Definitely.

> intellectual investment in its conception and owes its current momentum
> more to Sun marketing and the anti-Microsoft jihad rather than to any
> real quality of language design. Will Java also disappear
> in "internet-time" once the artificial propping up of the language is
> removed?

Now _that_ was just flamebait... :-)

Anyway, I think Java is a great language for certain things. However,
the features that can make it simple and fairly easy to use, such as
single inheritance only, clearly defined namespaces, and a strict
security model, can also make it very difficult to use for more
complex programs.

I think Java is a good solution for some areas, especially where
security is a key factor or a more component-based model is desired.
I would agree with you that its usefulness in certain arenas has been
overrated, but that's marketing for you. Myself, I just try to use
the best tool for the job and ignore the marketroids. Sometimes that
means C, sometimes that means Java, and more and more it means Lisp,
if I can just convince my bosses to let me. =)

--
vsync
http://quadium.net/ - last updated Mon Jun 12 23:31:13 MDT 2000
Orjner.

pete@nowhere

unread,
Jun 14, 2000, 3:00:00 AM6/14/00
to
In article <8i9os9$55c$1...@nnrp1.deja.com>, PM says...


>Java, on the other hand, has done exactly the
>same thing, but in "internet-time", managing to become a bloated
>abomination far faster than any other programming language in history.
>

What a moron.

You call java rich and wide ranging standard libraries a 'bloat' ?

That is the main attraction of Java. With Java standard libraries,
one write anything from serial communications to programming a TV
to writing 2D and 3D to socket programming, to threads to reading
graphic files, to running in a browser, to program a smart card
to communicate with a database, to interface to CORBA and million
of other things. All in portable way.

You call this 'bloat' ? But the above is what is attracting millions
of programmers to Java, along with it being an excellent language.

I guess you are so smart, and the millions of Java programmers are
the stupid one? Let me give you a hint, you are the stupid one. Java
is here to stay, and it is getting more and more popular every day, so
go back to you dying C and C++ or stick to lisp (I hear
there are now 50 people who use lisp, so you will not be alone).


PM

unread,
Jun 15, 2000, 3:00:00 AM6/15/00
to
I’ve noticed an interesting similarity between the evolution of the
Java and Lisp languages. Lisp (and more recently CLOS) have evolved
over a period of decades to become a rather bloated language and
library combination. Java, on the other hand, has done exactly the

same thing, but in "internet-time", managing to become a bloated
abomination far faster than any other programming language in history.

The only real difference is that Lisp, as a language, was far better


designed from the outset and has maintained its utility over time
because of this, whereas the Java language lacked any real

intellectual investment in its conception and owes its current momentum
more to Sun marketing and the anti-Microsoft jihad rather than to any
real quality of language design. Will Java also disappear
in "internet-time" once the artificial propping up of the language is
removed?

Maybe we need a “Scheme” version of Java?

Cheers,
- Peter.

Sent via Deja.com http://www.deja.com/
Before you buy.

Jun Nolasco

unread,
Jun 15, 2000, 3:00:00 AM6/15/00
to
pete@nowhere wrote:
>
> I guess you are so smart, and the millions of Java programmers are
> the stupid one? Let me give you a hint, you are the stupid one. Java
> is here to stay, and it is getting more and more popular every day, so
> go back to you dying C and C++ or stick to lisp (I hear
> there are now 50 people who use lisp, so you will not be alone).

... until the inevitable next "greatest thing since sliced bread" comes
along to claim the crown, of course.


Besides, how many developers (and/or managers) do you think actually
selected Java because they knew it can get the job done, and not for
some other reason such as popularity, earning potential, ... or
effective marketing on Sun's part?

How many times have you heard someone ask: "I head that Java is getting
popular (or more recently, that Java pays a lot). Do you think I should
learn the language"?. In my case, a whole lot. I wouldn't exactly call
them stupid though (i.e. profit motive). :-)


Jun Nolasco

Rene

unread,
Jun 15, 2000, 3:00:00 AM6/15/00
to
You want a nice small clean language designed for eternity? There is no such
thing, besides for school puposes. I am tempted to say: "Stick with a Turing
machine". But I rather should not be ironic, because "small is beautiful"
the attitude of yours is something to be found very often.

So, if YOU do not develop real world applications, I do, and many others
too. For this we need real world libraries. Java offers these across
platforms. Admittedly, if we stick with a particular OS, like Windows, or in
your case more prabably Unix, we find the same functionality preloaded, and
a small and beautiful language, which can use these, might suffice. But the
essence of Java is multi-platform development.

Think of it another way. Your OS may die sooner than you. Or you may want to
switch. Then you can carry your applications over to the new OS. So Java is
more for eternity than your clean language.

Rene


pete@nowhere

unread,
Jun 15, 2000, 3:00:00 AM6/15/00
to
In article <87hfav1...@quadium.net>, vsync says...


>
>Anyway, I think Java is a great language for certain things. However,
>the features that can make it simple and fairly easy to use, such as
>single inheritance only, clearly defined namespaces, and a strict
>security model, can also make it very difficult to use for more
>complex programs.
>

Wow, the guys talks as if he knows what he is talking about.
Show an example where single inhertitance only can make it difficult
to write those compelex applications you are talking about?

And 'clearly defined namespaces' makes it more difficult?

What an idiot.


Jason Trenouth

unread,
Jun 15, 2000, 3:00:00 AM6/15/00
to
On 15 Jun 2000 00:53:27 -0700, pete@nowhere wrote:

> In article <87hfav1...@quadium.net>, vsync says...
>
> >
> >Anyway, I think Java is a great language for certain things. However,
> >the features that can make it simple and fairly easy to use, such as
> >single inheritance only, clearly defined namespaces, and a strict
> >security model, can also make it very difficult to use for more
> >complex programs.
> >
>
> Wow, the guys talks as if he knows what he is talking about.
> Show an example where single inhertitance only can make it difficult
> to write those compelex applications you are talking about?

One example is when programming serverside code using CORBA's POA. You
basically want to inherit the implementation of both the communication and the
application classes. Since you can't do that in Java, the normal workaround is
to inherit the communication classes and delegate to the application objects.
CORBA jargon calls this the TIE approach. You end up with a lot of trivial
methods just to do the delegating.

__Jason

PM

unread,
Jun 15, 2000, 3:00:00 AM6/15/00
to
In article <8ia21n$2d...@drn.newsguy.com>,

pete@nowhere wrote:
> In article <87hfav1...@quadium.net>, vsync says...

>


> Wow, the guys talks as if he knows what he is talking about.
> Show an example where single inhertitance only can make it difficult
> to write those compelex applications you are talking about

While there is no doubt that multiple-inheritance can be abused (and
this is true of many language & paradigm features), it is also true
that languages that prohibit true multiple inheritance _increase_ the
complexity of the code simply because such a language lacks the
expressive power to implement solutions that validly require multiple
inheritance. In such cases, alternate work-arounds must be used.

Here's an example. Multiple inheritance can implement relationships
known as "subtyping for combination". This is the case where a class
is a special type of two other classes and those two base classes are
from different domains. Without multiple inheritance, you are forced
to contain all but one of the base classes and then must provide
delegation functions to the other contained classes, thereby creating a
more complex solution than would otherwise be required.

> What an idiot.

Very typical of innexperience Java "programmers". They learn a little
then think they know it all.

PM

unread,
Jun 15, 2000, 3:00:00 AM6/15/00
to
In article <8i9s6i$24...@drn.newsguy.com>,
pete@nowhere wrote:
> In article <8i9os9$55c$1...@nnrp1.deja.com>, PM says...

>
> What a moron.
>
> You call java rich and wide ranging standard libraries a 'bloat' ?
> That is the main attraction of Java.

Yes, its the main attraction to people who don't know any better.

> With Java standard libraries,
> one write anything from serial communications to programming a TV
> to writing 2D and 3D to socket programming, to threads to reading
> graphic files, to running in a browser, to program a smart card
> to communicate with a database, to interface to CORBA and million
> of other things. All in portable way.

Ever heard the saying: "Jack of all trades, master of none"? Here's a
hint, its not a compliment.

> I guess you are so smart, and the millions of Java programmers are
> the stupid one? Let me give you a hint, you are the stupid one. Java
> is here to stay, and it is getting more and more popular every day, so
> go back to you dying C and C++ or stick to lisp (I hear
> there are now 50 people who use lisp, so you will not be alone).

Maybe you can try hacking into the embedded Java PICO processor in your
nappies to override the moisture detection sensors. That should keep
you happy till you're old enough to enter the real world.

Marco Antoniotti

unread,
Jun 15, 2000, 3:00:00 AM6/15/00
to

PM <deja...@my-deja.com> writes:

...

> real quality of language design. Will Java also disappear
> in "internet-time" once the artificial propping up of the language is
> removed?
>
> Maybe we need a “Scheme” version of Java?

First we need DEFSTRUCT and multidimensional arrays *in* RxRS :)

Cheers

--
Marco Antoniotti ===========================================

brl...@sperience.com

unread,
Jun 15, 2000, 3:00:00 AM6/15/00
to
PM,

What did comp.lang.lisp and comp.lang.scheme do to you that make you
want to drag us into this flame war?

--
(for-each (lambda (str) (display (string-append (make-string (- 40
(quotient (string-length str) 2)) #\space) str)) (newline)) '(""
"Bruce Lewis" "MIT 1990" " http://brl.sourceforge.net/
"))

mwo...@server-4.stpauls.usyd.edu.au

unread,
Jun 15, 2000, 3:00:00 AM6/15/00
to
brl...@sperience.com <brl...@sperience.com> wrote:
>PM,
>
>What did comp.lang.lisp and comp.lang.scheme do to you that make you
>want to drag us into this flame war?

Especially considering it's *.advocacy. No offence to the denizens of
that fine froup, but advocacy groups tend toward the argumentative.
If it were a serious question, why not post to comp.lang.java instead?

mrak

Philip Lijnzaad

unread,
Jun 15, 2000, 3:00:00 AM6/15/00
to

Jason> On 15 Jun 2000 00:53:27 -0700, pete@nowhere wrote:
>> In article <87hfav1...@quadium.net>, vsync says...
>>
>> >
>> >Anyway, I think Java is a great language for certain things. However,
>> >the features that can make it simple and fairly easy to use, such as
>> >single inheritance only, clearly defined namespaces, and a strict
>> >security model, can also make it very difficult to use for more
>> >complex programs.
>> >
>>
>> Wow, the guys talks as if he knows what he is talking about.
>> Show an example where single inhertitance only can make it difficult
>> to write those compelex applications you are talking about?

Jason> One example is when programming serverside code using CORBA's POA.

ehr, no: it has nothing to do with POA; BOA can also use TIE's and both C++
and Java ORBS have done so for years.

Jason> You basically want to inherit the implementation of both the
Jason> communication and the application classes. Since you can't do that in
Jason> Java, the normal workaround is to inherit the communication classes
Jason> and delegate to the application objects. You end up with a lot of
Jason> trivial methods just to do the delegating.

Ehr, yes, but you don't have to write the delegating code. The ORB compiler
produces code that does this for you. All you have to do is implement the
methods you promised you would in your IDL, then instantiate the object _and_
the tie-Object in a sligthly different manner. The fact that some calls are
delegated is hidden.

if you have the following IDL:

interface Foo {
string bar(in long n);
};

you would implement this roughly as

public class FooImpl implements FooOperations {
// interface FooOperations is generated by ORB.

// (constructor left out)

public String bar(int n) {
return "n = "+n;
}
}
// (constructor left out)

public String bar(int n) {
return "n = "+n;
}
}

And instantiate this baby as

class FooServer {

public static void main(String[] args) {
orb = ...;
FooOperations myFooImpl = new FooImpl(...);

Foo realFoo = FooTie(myFooImpl, ...); // FooTie generated by ORB
// OR _tie_Foo() or Foo_tie(); name of Tie-class is not standardized

// presto: object Foo now available to network.
}
}

(details of the tie approach are not standardized yet, so treat with care)

--
Ban GM foods! Long live the Mesolithicum, pesticides and starvation
-----------------------------------------------------------------------------
Philip Lijnzaad, lijn...@ebi.ac.uk \ European Bioinformatics Institute,rm A2-24
+44 (0)1223 49 4639 / Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) \ Cambridgeshire CB10 1SD, GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53

Eugene Zaikonnikov

unread,
Jun 15, 2000, 3:00:00 AM6/15/00
to
<pete@nowhere> wrote in message news:8i9s6i$24...@drn.newsguy.com...

> In article <8i9os9$55c$1...@nnrp1.deja.com>, PM says...
[snip]
> That is the main attraction of Java. With Java standard libraries,

> one write anything from serial communications to programming a TV
> to writing 2D and 3D to socket programming, to threads to reading
> graphic files, to running in a browser, to program a smart card
> to communicate with a database, to interface to CORBA and million
> of other things. All in portable way.
>
Some decades ago an attempt was undertaken by IBM to create an all-in-one
language, namely PL/1. It was quite popular that times (very much like C,
then C++, and now Java), and is used to some extent even now.
Anyway, you need not worry about Java extinction, since you believe it is
the ultimate language. And even if you wrong, Java is far too young to die.

> You call this 'bloat' ? But the above is what is attracting millions
> of programmers to Java, along with it being an excellent language.
>

Smoking is attracting millions people, including me :) I mean, language
quality is not the main cause of language popularity. Don't take it as an
offense on Java: personally I find it better language than C++.

> I guess you are so smart, and the millions of Java programmers are
> the stupid one? Let me give you a hint, you are the stupid one. Java
> is here to stay, and it is getting more and more popular every day, so
> go back to you dying C and C++ or stick to lisp (I hear
> there are now 50 people who use lisp, so you will not be alone).
>

Much more, actually.

--
Eugene.


David Rush

unread,
Jun 15, 2000, 3:00:00 AM6/15/00
to
brl...@sperience.com writes:
> PM,
> What did comp.lang.lisp and comp.lang.scheme do to you that make you
> want to drag us into this flame war?

We can only hope that Erik Naggum decides to jump into the
fray. That'll teach him.

david rush
--
Or would that violate some kind of flame non-proliferation treaty?

mike555@nospam

unread,
Jun 15, 2000, 3:00:00 AM6/15/00
to
In article <8iaj6e$nff$1...@nnrp1.deja.com>, PM says...

>
>> What an idiot.

>
>Very typical of innexperience Java "programmers". They learn a little
>then think they know it all.

No. You think you know it all.

Very smart people designed Java. There are many other good OO languages
that have single inhertance only (check Ada95 for example). And this
was done for a good practical reason.

I assume you know about the problem that can come from using MI.

In the real world, and I have been programming for zillion years,
I have never ever once had a need for MI of implementation.

In Java, you can use interfaces for this sort of thing. It is safer
and more elegent. You also use containment/aggregation to achive
the same effect as MI.

While you c++ programmers are setting there wasting time debugging
your MI application, we Java programmer are cranking out solid
bug free code that works.

c++ programmers think they know more and smarter than any one else,
becuase their language is more complicated, they think this is good
to have more complicated mess to work with, they think using a simpler
language means one is not as smart as they are.

don't you c++ programmer have more debugging to do today?

Mike


Arne Knut Roev

unread,
Jun 15, 2000, 3:00:00 AM6/15/00
to
In comp.lang.lisp pete@nowhere wrote:
[snip!]

> I guess you are so smart, and the millions of Java programmers are
> the stupid one? Let me give you a hint, you are the stupid one. Java
> is here to stay, and it is getting more and more popular every day, so
> go back to you dying C and C++ or stick to lisp (I hear
> there are now 50 people who use lisp, so you will not be alone).
^^^^^^^^^^^^^^^^^^^^^^^^^^

;-)))

Boy, you _sure_ are looking for trouble, posting such drivel to the
comp.lang.lisp newsgroup...

But no, I'll be kind to the children tonight...

Instead of the roasting you ought to get, I will give you a few facts and a
web reference, and I suggest you do yourself the favour of looking it up and
reading a little of what is posted at that site.

So, first the facts:

At the web site of the Association of Lisp Users, there is a list of
commercial uses for Lisp, and in this list I counted over one hundred
company names (the actual number of companies listed is probably about 150
or so, but when I passed 100 I lost interest in counting...).

Granted, among those companies we find a lot of small and virtually unknown
companies, such as:

Aerospatiale, Boeing, British Aerospace, Delta Airlines,
General Electric, Hughes Aircraft, Hughes Space & Communications,
Lockheed, NASA, Northrop, Pratt & Whitney, Rolls Royce,
Ford Motor Company, General Motors, Honda, Mazda, Peugeot,
Amoco, Exxon, Mitsubishi, Motorola, Sony Electronics, Inc.

And the website I am recommending for your perusal, has this address:
<URL: http://www.lisp.org/>

--
Arne Knut Roev <akr...@online.no> Snail: N-6141 ROVDE, Norway
=
The Gates of Hell shall not prevail:
Darkness now; then Light!

Thant Tessman

unread,
Jun 15, 2000, 3:00:00 AM6/15/00
to

mike555@NOSPAM wrote:

[...]

> c++ programmers think they know more and smarter than any one else,
> becuase their language is more complicated, they think this is good
> to have more complicated mess to work with, they think using a simpler
> language means one is not as smart as they are.

You're posting to a Scheme group. Around here, arguing that Java is
better than C++ is like arguing that grasshoppers taste better than tree
bark.

-thant

Joe Marshall

unread,
Jun 15, 2000, 3:00:00 AM6/15/00
to
mike555@NOSPAM writes:

> Very smart people designed Java.

What happened?

> .... we Java programmer are cranking out solid bug free code that
> works.

I'm still laughing over this one.

Ed Falis

unread,
Jun 15, 2000, 3:00:00 AM6/15/00
to
mike555@NOSPAM wrote:
> Very smart people designed Java. There are many other good OO
> languages that have single inhertance only (check Ada95 for example).
> And this was done for a good practical reason.

I probably have a slightly different perspective. I come from the Ada
world, and have done Java as well as Eiffel (which supports MI).

Ada does not provide a direct syntactic construct for MI, but it does
provide building blocks (constrained genericity and "views") that allow
one to implement MI with a little bit more verbiage than in languages
like C++ or Eiffel. The equivalent of Java interfaces can also be done.
But one can multiply inherit behavior (implementation) without having to
go through the trouble of reimplementing methods that don't need to be
overridden. So the "single inheritance only" characterization isn't
quite accurate.

That said, I prefer Eiffel's approach to multiple inheritance because
it's cleaner and provides more straightforward control.

> I assume you know about the problem that can come from using MI.

My feeling is that the problem is largely a matter of whether the
language provides adequate capabilities when an ancestor class comes in
from more than one inheritance path for dealing handling joining,
selection and renaming. So, this is largely an implementation issue, in
my opinion.

> In the real world, and I have been programming for zillion years, I
> have never ever once had a need for MI of implementation.

Comes to a matter of appropriate expressibility, don't you think? Of
course, one can do without it. On the other hand when using a technique
like Reenskaug's approach to role modeling, where a given object may
implement multiple roles or protocols, MI can be a very nice way to
express and implement the classes of such objects.

> In Java, you can use interfaces for this sort of thing. It is safer
> and more elegent. You also use containment/aggregation to achive the
> same effect as MI.

You can, but I consider it less elegant and more work than the way
Eiffel handles MI.

> While you c++ programmers are setting there wasting time debugging

> your MI application, we Java programmer are cranking out solid bug
> free code that works.

Not a C++ programmer, but I find both Ada and Eiffel to be easier to
write relatively bug-free code. The "design by contract" capabilities of
Eiffel, taken in conjuction with aggressive unit testing, are especially
nice. Fortunately there are limited implementations of DbC and public
domain unit test frameworks available for both Java and Ada.

> c++ programmers think they know more and smarter than any one else,
> becuase their language is more complicated, they think this is good to
> have more complicated mess to work with, they think using a simpler
> language means one is not as smart as they are.

Smirk ;-)

- Ed

>

- E


felix

unread,
Jun 15, 2000, 3:00:00 AM6/15/00
to

David Rush wrote in message ...

>We can only hope that Erik Naggum decides to jump into the
>fray. That'll teach him.


You shouldn't encourage him!


felix


felix

unread,
Jun 15, 2000, 3:00:00 AM6/15/00
to

Marco Antoniotti wrote in message ...

>>
>> Maybe we need a “Scheme” version of Java?
>
>First we need DEFSTRUCT and multidimensional arrays *in* RxRS :)
>


Or first-class continuations in the Hyperspec :):)


felix


PM

unread,
Jun 15, 2000, 3:00:00 AM6/15/00
to
In article <8ibb8q$1g...@drn.newsguy.com>,

mike555@NOSPAM wrote:
>
> I assume you know about the problem that can come from using MI.

Yes, I mentioned it can be abused, just like other language and
paradigm features.

>
> In the real world, and I have been programming for zillion years,
> I have never ever once had a need for MI of implementation.

Maybe you haven't _recognised_ the need for MI and produced an overly
complicated design as a result. There ARE valid uses for MI. If you
don't realisethis then I suggest you have a bit more learning to do
about OO. If you only have a hammer, everything looks like a nail,
right?

> You also use containment/aggregation to achive
> the same effect as MI.

As I pointed out in a previous post, this is a more complicated
solution (a hack) implemented to get around the lack of MI in the
language.

> While you c++ programmers are setting there wasting time debugging
> your MI application, we Java programmer are cranking out solid
> bug free code that works.

Why on earth did you bring up C++?? MI does not equal C++.

PM

unread,
Jun 15, 2000, 3:00:00 AM6/15/00
to
In article <aegm64w...@alum.mit.edu>,
Joe Marshall <jmar...@alum.mit.edu> wrote:

> mike555@NOSPAM writes:
>
> > Very smart people designed Java.
>
> What happened?
>
> > .... we Java programmer are cranking out solid bug free code that
> > works.
>

> I'm still laughing over this one.
>

Yep, Java programmers ego's are also inflating in "internet-time"!

The funniest thing I saw recently was a utility to help you find memory
leak problems in your Java code. "What the $#%#" you exclaim, "Java
was supposed to free programmers from worrying about such memory
problems!". Sadly, it just hides them so that the programmer just
_thinks_ he is churning out wonderful, bug-free code while his
application is chewing up and never freeing chunks of memory all over
the place.

PM

unread,
Jun 15, 2000, 3:00:00 AM6/15/00
to
In article <lwog539...@parades.rm.cnr.it>,

Marco Antoniotti <mar...@parades.rm.cnr.it> wrote:
>
> >
> > Maybe we need a “Scheme” version of Java?
>
> First we need DEFSTRUCT and multidimensional arrays *in* RxRS :)
>

Definately a DEFSTRUCT in Scheme would be _very_ nice. I don't know why
this wasn't introduced years ago.

I'm not so sure about multidimensional arrays though. Could these be
better handled by a library or class in some hypothetical OO version of
scheme?

> Marco Antoniotti ===========================================

Peter ----------------------------------------------------

PM

unread,
Jun 15, 2000, 3:00:00 AM6/15/00
to
In article <nm9hfav...@department-of-alchemy.mit.edu>,

brl...@sperience.com wrote:
> PM,
>
> What did comp.lang.lisp and comp.lang.scheme do to you that make you
> want to drag us into this flame war?

Well, I was just pointing out that both Java and Common Lisp had both
evolved into large, unwieldy language/library combinations, but that
Java has done so far faster and with far less thought or input by
skilled language/library designers than was the case with Lisp. Then I
suggested that someone do a "Scheme" on Java, that is, created a more
elegant, refined version. Hey, is it my fault that some people took
this as an invitation to start arguing about Java/Ada/Eiffel/C++ &
multiple inheritance? :)

Hartmann Schaffer

unread,
Jun 15, 2000, 3:00:00 AM6/15/00
to
In article <8i9s6i$24...@drn.newsguy.com>,

pete@nowhere writes:
> ...
> What a moron.
>
> You call java rich and wide ranging standard libraries a 'bloat' ?
>
> ...

> I guess you are so smart, and the millions of Java programmers are
> the stupid one? Let me give you a hint, you are the stupid one. Java

i don't know about the millions (there must be some bright people among
them), but you most certainly are.

> ...

--

Hartmann Schaffer


Ed Falis

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to
brl...@sperience.com wrote:
> PM,
>
> What did comp.lang.lisp and comp.lang.scheme do to you that make you
> want to drag us into this flame war?

PM <deja...@my-deja.com> wrote:
> Well, I was just pointing out that both Java and Common Lisp had both
> evolved into large, unwieldy language/library combinations, but that
> Java has done so far faster and with far less thought or input by
> skilled language/library designers than was the case with Lisp. Then I
> suggested that someone do a "Scheme" on Java, that is, created a more
> elegant, refined version. Hey, is it my fault that some people took
> this as an invitation to start arguing about Java/Ada/Eiffel/C++ &
> multiple inheritance? :)
>
> Sent via Deja.com http://www.deja.com/ Before you buy.

Sorry, guys, I didn't notice the cross-posting until after I hit the
send button. If I'm involved in any followups, I'll be sure to trim.

- Ed

Reality is a point of view

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to
+---- th...@acm.org wrote (Thu, 15 Jun 2000 14:44:19 -0600):
| You're posting to a Scheme group. Around here, arguing that Java is
| better than C++ is like arguing that grasshoppers taste better than tree
| bark.
+----

If I were interested in security for Scheme (|lisp) what would
win?

--
Gary Johnson gjoh...@season.com
Privacy on the net is still illegal.
<a href=http://www.ibm.com/GNU/Linux>heh</a>

Courageous

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to

> In Java, you can use interfaces for this sort of thing. It is safer
> and more elegent. You also use containment/aggregation to achive

> the same effect as MI.

Not cleanly, you can't. When you need MI, you need it. There
indeed are cases where MI is the most appropriate solution.

> While you c++ programmers are setting there wasting time debugging

> your MI application, we Java programmer are cranking out solid


> bug free code that works.

Java would be no less functional than it is now if it had MI.

> c++ programmers think they know more and smarter than any one else,
> becuase their language is more complicated, they think this is good
> to have more complicated mess to work with, they think using a simpler
> language means one is not as smart as they are.

In case you're not keeping up on current events, you're not posting
to a C++ newgroup.

C/

William Deakin

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to
felix wrote:

> Marco Antoniotti wrote in message ...

> >> Maybe we need a “Scheme” version of Java?
> >
> >First we need DEFSTRUCT and multidimensional arrays *in* RxRS :)
> >

> Or first-class continuations in the Hyperspec :):)

Why?

;)will


Espen Vestre

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to
Thant Tessman <th...@acm.org> writes:

> You're posting to a Scheme group. Around here, arguing that Java is
> better than C++ is like arguing that grasshoppers taste better than tree
> bark.

You're much too kind - comparing java to edible stuff like grasshoppers!

--
espen ;-)

at ncal point verio point com x@x.x tom

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to
Jun Nolasco <nol...@inx.net> writes:
> Besides, how many developers (and/or managers) do you think actually
> selected Java because they knew it can get the job done, and not for
> some other reason such as popularity, earning potential, ... or
> effective marketing on Sun's part?

While a lot of that may be going on now, Java wouldn't have succeeded
if knowledgeable and skilled people at places like IBM and Sun hadn't
pushed for it. And if you look at those people, they were often long
time Lisp and Smalltalk users, and sometimes had actually even been
involved in standardization and implementation of Lisp, Smalltalk, and
similar languages. For one Lisp user's view on this, I recommend
reading Steele's "Growing a Language" paper.

Many of the technical people I know founding startups and choosing
Java also have a long time background in Lisp, Scheme, and other
dynamic languages.

My hope is that language designers, in particular for dynamic
languages, will take Java as an important data point and challenge to
do better. To do that, it's important to understand what Java does
well and what technical reasons caused it to succeed. And there is
quite a bit that Java does rather well.

Tom.


at ncal point verio point com x@x.x tom

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to
"Eugene Zaikonnikov" <vik...@cit.org.by> writes:
> <pete@nowhere> wrote in message news:8i9s6i$24...@drn.newsguy.com...
> > In article <8i9os9$55c$1...@nnrp1.deja.com>, PM says...
> > That is the main attraction of Java. With Java standard libraries, [...]

>
> Some decades ago an attempt was undertaken by IBM to create an all-in-one
> language, namely PL/1. It was quite popular that times (very much like C,
> then C++, and now Java), and is used to some extent even now.
> Anyway, you need not worry about Java extinction, since you believe it is
> the ultimate language. And even if you wrong, Java is far too young to die.

But Pete was talking about extensive libraries, not complex language
design. Java is a modest and simple language as far as languages go.
It doesn't try to be an "all-in-one language", it merely tries to give
you a good set of libraries.

If anything, CommonLisp tries to be an "all-in-one language". Perhaps
your analogy with PL/1 is much more apt there.

Good libraries with a simple language seems to be a winning
combination. A complex language with limited libraries usually has a
much harder time.

Tom.

Tim Bradshaw

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to
* William Deakin wrote:
> felix wrote:

>> Or first-class continuations in the Hyperspec :):)

> Why?

Keeps the academics happy. Very important.

William Deakin

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to

Oh, my mistake ;)

brl...@sperience.com

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to
PM <deja...@my-deja.com> writes:

> Well, I was just pointing out that both Java and Common Lisp had both
> evolved into large, unwieldy language/library combinations, but that
> Java has done so far faster and with far less thought or input by
> skilled language/library designers than was the case with Lisp.

Gee, and I thought you were starting a flame war; what was I thinking?

Actually, I think Java did have input from skilled language designers
(Guy Steele?), but Java has a very different purpose from Lisp. Java is
intended (1) to be a marketing success, (2) to provide a gentle
migration path away from C/C++, and (3) to be a better language than
C++. I think its design methodology is consistent with these goals.

To be a marketing success, you have to push features out the door while
they're still "hot" ideas. Chances are you will include some design
flaws that need to be deprecated later, but that's OK because your
time-to-market is so good. The "implement first; design later"
methodology does just what it's supposed to do.

Part of Scheme's purpose is to be a good language for Computer Science
textbook examples. The last thing Scheme needs is a feature that gets
deprecated, embarrassing textbook authors who used it before it was
found to be a bad idea. As a result, the core Scheme specification only
gets a new feature when the authors are fairly sure they've found the
best design for that feature.

The result is great for textbooks, but lousy for time-to-market, and
also for various implementations of Scheme that end up with similar but
slightly different features. The SRFI process was invented to address
this problem by encouraging features to be implemented when a few people
agree on them, not when they've been found to be perfect.

> Then I suggested that someone do a "Scheme" on Java, that is, created
> a more elegant, refined version.

A language that is to Java as Scheme is to Lisp? What purpose would
such a language have? What features of such a language would you want
to see worked back into Java the way Scheme features were worked back
into Lisp?

If you prefer Scheme but have to work with Java, there are Java
implementations of Scheme available with FFIs to manipulate Java
objects. I use Kawa, which I've extended to implement BRL, a
gentle-slope (http://www.arsdigita.com/asj/application-servers near the
bottom of the page) server-side web programming system which provides
the benefits of JSP without the drawbacks. IMO it's the cleanest, most
elegant way to create database-generated web pages in existence; look at
the examples in the manual.

My point is, you can get a lot of elegance in a Java environment right
now without the need for yet another programming language. Just use
Scheme.

Since I'm talking more about Scheme than about other languages, I've set
Followup-To: comp.lang.scheme

--
(for-each (lambda (str) (display (string-append (make-string (- 40
(quotient (string-length str) 2)) #\space) str)) (newline)) '(""
"Bruce Lewis" "MIT 1990" " http://brl.sourceforge.net/
"))

Yiorgos Adamopoulos

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to
In article <8ibb8q$1g...@drn.newsguy.com>, mike555@NOSPAM wrote:
>While you c++ programmers are setting there wasting time debugging
>your MI application, we Java programmer are cranking out solid
>bug free code that works.

Dream On! Do you imply that you are able to write bug free code?

--
${talks}

Marco Antoniotti

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to

"felix" <fe...@anu.ie> writes:

> Marco Antoniotti wrote in message ...
> >>
> >> Maybe we need a “Scheme” version of Java?
> >
> >First we need DEFSTRUCT and multidimensional arrays *in* RxRS :)
> >
>
>

> Or first-class continuations in the Hyperspec :):)

Touche`! :) But it is *FAR LESS WORK* to get the above items in RxRS!
So the question is: why has this not happened yet? Maybe because it
would break the main design constraint of Scheme? :)

Cheers

--
Marco Antoniotti ===========================================

Marco Antoniotti

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to

PM <deja...@my-deja.com> writes:

> In article <lwog539...@parades.rm.cnr.it>,
> Marco Antoniotti <mar...@parades.rm.cnr.it> wrote:
> >
> > >

> > > Maybe we need a “Scheme” version of Java?
> >
> > First we need DEFSTRUCT and multidimensional arrays *in* RxRS :)
> >
>

> Definately a DEFSTRUCT in Scheme would be _very_ nice. I don't know why
> this wasn't introduced years ago.
>
> I'm not so sure about multidimensional arrays though. Could these be
> better handled by a library or class in some hypothetical OO version of
> scheme?

Seconddly, we need CLOS *in* RxRS. :) (Sorry, you asked for it :) )

--
Marco Antoniotti ===========================================

Jason Trenouth

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to
On 15 Jun 2000 16:53:39 +0100, Philip Lijnzaad <lijn...@ebi.ac.uk> wrote:

> Jason> One example is when programming serverside code using CORBA's POA.
>
> ehr, no: it has nothing to do with POA; BOA can also use TIE's and both C++
> and Java ORBS have done so for years.

Ehr, I didn't claim any exclusivity for the POA.

..

> Ehr, yes, but you don't have to write the delegating code. The ORB compiler
> produces code that does this for you. All you have to do is implement the
> methods you promised you would in your IDL, then instantiate the object _and_
> the tie-Object in a sligthly different manner. The fact that some calls are
> delegated is hidden.

Ehr, but not hidden in the memory columns in the task manager. :-j

Perhaps, having written an IDL compiler for Java, I'm more conscious of the
behind-the-scenes hoop-jumping.

The fact remains: multiple inheritance simplifies some programming tasks.

__Jason

Joe Marshall

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to
PM <deja...@my-deja.com> writes:

> Definately a DEFSTRUCT in Scheme would be _very_ nice. I don't know why
> this wasn't introduced years ago.

Most implementations of Scheme have a variant on DEFSTRUCT. The
problem is that the variants are incompatible, and no one has managed
to persuade the other implementors that one variant is clearly
superior.

Joe Marshall

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to
gjoh...@dream.season.com (Reality is a point of view) writes:

> +---- th...@acm.org wrote (Thu, 15 Jun 2000 14:44:19 -0600):

> | You're posting to a Scheme group. Around here, arguing that Java is
> | better than C++ is like arguing that grasshoppers taste better than tree
> | bark.

> +----
>
> If I were interested in security for Scheme (|lisp) what would
> win?

Tree bark. Hands down.

Eugene Zaikonnikov

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to
"tom" <tmb at ncal point verio point com x@x.x> wrote in message
news:pb8ya46...@aimnet.com...
> "Eugene Zaikonnikov" <vik...@cit.org.by> writes:
[snip]

> > Some decades ago an attempt was undertaken by IBM to create an
all-in-one
> > language, namely PL/1. It was quite popular that times (very much like
C,
> > then C++, and now Java), and is used to some extent even now.
> > Anyway, you need not worry about Java extinction, since you believe it
is
> > the ultimate language. And even if you wrong, Java is far too young to
die.
>
> But Pete was talking about extensive libraries, not complex language
> design. Java is a modest and simple language as far as languages go.
> It doesn't try to be an "all-in-one language", it merely tries to give
> you a good set of libraries.
>
This is quite depends on what to count as a library. If we define library as
a set of code providing common useful functionality *and* written in the
language it intended to be used with, then Java has not too many libraries.
The fact that a lot of Java librariy cores (and even JVMs (BTW, does JVM
written in Java exists?)) are written in C++ makes me think that Java is not
that cross-platform. I mean, since libraries are not written in the portable
language itself, they may behave different on different platforms. And some
of them do behave different.

> If anything, CommonLisp tries to be an "all-in-one language". Perhaps
> your analogy with PL/1 is much more apt there.
>

With Lisp it was somewhat different. Functionality had to be proven useful
and polished by years (sometimes by decades) in order to be incorporated
into the standard. And even then it had to pass through the hands of widely
recognized Lisp gurus to be embedded to the language in the Right Way.
Some things that existed for decades but were not polished enough or that
were not portable by definition (like GUI and multithreading support) hadn't
passed to standard (it doesn't means however that the Lisp vendors do not
provide their own threading implementations or GUIs).
After all, the aim of the standartization effort was not to produce a
language that has everything in it, but to enable people to use facilities
that they use already in a uniform, standard, portable way.

> Good libraries with a simple language seems to be a winning
> combination. A complex language with limited libraries usually has a
> much harder time.
>

It's a matter of personal preference. You just *absolutely need* some things
(e.g. containers) to make anything useful, and defined they as a libraries
or as a part of language per se is a matter of second importance.
Anyway, nothing restricts one to wirte libraries for Lisp :)

--
Eugene.

David Hanley

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to

pete@nowhere wrote:

> In article <87hfav1...@quadium.net>, vsync says...
>
> >
> >Anyway, I think Java is a great language for certain things. However,
> >the features that can make it simple and fairly easy to use, such as
> >single inheritance only, clearly defined namespaces, and a strict
> >security model, can also make it very difficult to use for more
> >complex programs.
> >
>
> Wow, the guys talks as if he knows what he is talking about.
> Show an example where single inhertitance only can make it difficult
> to write those compelex applications you are talking about?

That's pretty trivial. You have a class "car" with functionality. You
have a class "pet carrier" also with functionality. You want to use
your car to carry a pet. If you have MI, you can do this trivially.
If you don't, you have to make interface for each of these, and
make a class which delegates to both. This is a lot more work
to do in the first place, and maintenance effort later.

> What an idiot.

Now, now, the rubber and glue rule may have to come into effect.

dave

David Hanley

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to

mike555@NOSPAM wrote:

>
> In the real world, and I have been programming for zillion years,
> I have never ever once had a need for MI of implementation.

huh. And doing oop for all that time too, eh? :) You must
have a programming time machine.

Well, i have been programming for a trillion bajillion years, and
i think it's important. So there. :)


> In Java, you can use interfaces for this sort of thing. It is safer
> and more elegent.

How is writing a ton of delegation methods safer and more elegant?
It's more code to maintain, and, not to mention, contain bugs.

dave


Yiorgos Adamopoulos

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to
In article <394A50BC...@ncgr.org>, David Hanley wrote:
>> In Java, you can use interfaces for this sort of thing. It is safer
>> and more elegent.
>
>How is writing a ton of delegation methods safer and more elegant?
>It's more code to maintain, and, not to mention, contain bugs.

Oh but it is! As someone else posted earlier in this thread, Java
programmers are bug free.

--
${talks}

Dorai Sitaram

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to
In article <ya45ws...@alum.mit.edu>,

The biggest usability problem I see with the
defstructs in the major Scheme impls is that they all
require one to memorize the (mostly arbitrary)
order of the slots in the struct. Which I think is
antithetical to the motivation behind defstruct.

--d

at ncal point verio point com x@x.x tom

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to
"Eugene Zaikonnikov" <vik...@cit.org.by> writes:
> > But Pete was talking about extensive libraries, not complex language
> > design. Java is a modest and simple language as far as languages go.
> > It doesn't try to be an "all-in-one language", it merely tries to give
> > you a good set of libraries.
> >
> This is quite depends on what to count as a library. If we define library as
> a set of code providing common useful functionality *and* written in the
> language it intended to be used with, then Java has not too many libraries.

I don't see why such a definition of "language" and "library" would be
useful. I think the reason simple languages are good is that people
can learn them easily, tools are easier to write, and the behavior of
programs is easier to predict. OTOH, whether a library internally
uses some native code makes little difference to the programmer;
often, native code is just used to reuse an existing large chunk of
software, and sometimes (e.g., OS calls), the requirement is imposed
by the environment. Sometimes native code is used for speed, although
that's getting less and less necessary.

In any case, I think you underestimate the amount of pure Java code in
the Java libraries. Almost all of Swing is written in pure Java (and
both Swing and AWT could be written in 100% pure Java if anyone wanted
to bother), as are many of the relational database interfaces,
persistence, collection classes, string handling, IDEs, Internet
protocols, compilers, and other tools.

> With Lisp it was somewhat different. Functionality had to be proven useful
> and polished by years (sometimes by decades) in order to be incorporated
> into the standard. And even then it had to pass through the hands of widely
> recognized Lisp gurus to be embedded to the language in the Right Way.

Perhaps one of the biggest obstacles to Lisp evolution (and why so
many people have switched) is this insistence that it does things "the
Right Way". I think that kind of attitude inhibits progress and
evolution. Many Java designers and developers would agree that there
are lots of things that Java does not do "the Right Way" (just read
Steele's paper "Growing a Language"), but I think there are also lots
of things that neither Scheme nor CL do "the Right Way". In fact, I
don't even think there is "the Right Way"--what is "right" depends on
the application.

> Anyway, nothing restricts one to wirte libraries for Lisp :)

Sure: when we look at the CL definition, we find a lack of a standard
FFI, an incompletely specified condition system, incompletely
specified effects of type declarations, lack of multithreading, lack
of sockets, lack of fast binary I/O, incompletely specified
reflection, to name just a few. Holes like these in the CL and Scheme
specifications make it very difficult to write a pretty wide range of
classes of libraries portably and efficiently. The best one can do is
write a library to a particular implementation. I think that's why
you see so many Scheme and CL libraries that work only on this or that
implementation.

Tom.


Joe Marshall

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to
ds...@goldshoe.gte.com (Dorai Sitaram) writes:

> The biggest usability problem I see with the
> defstructs in the major Scheme impls is that they all
> require one to memorize the (mostly arbitrary)
> order of the slots in the struct. Which I think is
> antithetical to the motivation behind defstruct.

Huh? I don't recall ever having to memorize the slot order in any of
the Scheme defstruct implementations I've used. Could you give an
example?


norm@-

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to
In article <394A4F76...@ncgr.org>, David says...


>> Show an example where single inhertitance only can make it difficult
>> to write those compelex applications you are talking about?

>
>That's pretty trivial. You have a class "car" with functionality. You
>have a class "pet carrier" also with functionality. You want to use
>your car to carry a pet. If you have MI, you can do this trivially.
>If you don't, you have to make interface for each of these, and
>make a class which delegates to both. This is a lot more work
>to do in the first place, and maintenance effort later.
>

NO you idiot. Simply make an instance of "pet carrier" inside your
class "car". (you said yourself the car want to carry a pet).

A sign of a typical OO moron programmer is one who will use
inhertance to extend functionality instead of anything else.

>> What an idiot.
>

>Now, now, the rubber and glue rule may have to come into effect.

He was right, you ARE an idiot.

Norm


Dorai Sitaram

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to
In article <puphwi...@alum.mit.edu>,

Let's say we have the following struct (I'm
using MzScheme syntax)

(define-struct message
(type
tstr-id
create-time
create-time-hhmmss
create-time-mmddyyyy
status
action-time
action-time-hhmmss
action-time-mmddyyyy
message
already-processed))

To make an instance of this struct, I'd have
to say

(make-message
"program-error"
"fws11"
895005437
"15:37:17"
"5-12-1998"
"pending"
895006054
"15:47:34"
"5-12-1998"
"(CNAS:1)No GD matches listed"
#f)

I had better remember the (totally arbitrary) order of
the slots, because if I didn't, make-message
will populate the wrong slots in the instance with the
given values. Much less error-prone would be the
CL-esque

(make-message
'type "program-error"
'tstr-id "fws11"
'create-time 895005437
'create-time-hhmmss "15:37:17"
'create-time-mmddyyyy "5-12-1998"
'status "pending"
'action-time 895006054
'action-time-hhmmss "15:47:34"
'action-time-mmddyyyy "5-12-1998"
'message "(CNAS:1)No GD matches listed"
'already-processed #f)

in which the order of the twosomes doesn't matter.

--d


Joe Marshall

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to
ds...@goldshoe.gte.com (Dorai Sitaram) writes:

In cases where you have lots of slots, BOA constructors are
error-prone. But this isn't necessarily a problem with Scheme
structures. The DEFINE-STRUCTURE macro in MIT Scheme has a
keyword-constructor option that gives you the behavior you want.

David Hanley

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to

mike555@NOSPAM wrote:

>
> In the real world, and I have been programming for zillion years,
> I have never ever once had a need for MI of implementation.

huh. And doing oop for all that time too, eh? :) You must
have a programming time machine.

Well, i have been programming for a trillion bajillion years, and
i think it's important. So there. :)

> In Java, you can use interfaces for this sort of thing. It is safer
> and more elegent.

How is writing a ton of delegation methods safer and more elegant?
It's more code to maintain, and, not to mention, contain bugs.

dave


David Hanley

unread,
Jun 16, 2000, 3:00:00 AM6/16/00
to

pete@nowhere wrote:

> In article <87hfav1...@quadium.net>, vsync says...
>
> >
> >Anyway, I think Java is a great language for certain things. However,
> >the features that can make it simple and fairly easy to use, such as
> >single inheritance only, clearly defined namespaces, and a strict
> >security model, can also make it very difficult to use for more
> >complex programs.
> >
>
> Wow, the guys talks as if he knows what he is talking about.

> Show an example where single inhertitance only can make it difficult
> to write those compelex applications you are talking about?

That's pretty trivial. You have a class "car" with functionality. You
have a class "pet carrier" also with functionality. You want to use
your car to carry a pet. If you have MI, you can do this trivially.
If you don't, you have to make interface for each of these, and
make a class which delegates to both. This is a lot more work
to do in the first place, and maintenance effort later.

> What an idiot.

Now, now, the rubber and glue rule may have to come into effect.

dave

Dorai Sitaram

unread,
Jun 17, 2000, 3:00:00 AM6/17/00
to
In article <j7vbt11...@sun.cs.rice.edu>,

Shriram Krishnamurthi <shr...@cs.rice.edu> wrote:
>ds...@goldshoe.gte.com (Dorai Sitaram) writes:
>
>> Let's say we have the following struct (I'm
>> using MzScheme syntax)
>> [...]
>
>So define a macro. Big deal. Indeed, it is interesting that you
>should bring up PLT Scheme, because DEFINE-STRUCT is actually a
>macro over STRUCT. STRUCT just returns a multitude of values; you can
>name these as you wish, along the way wrapping the constructor to pull
>apart an association list, check for argument types, or whatever else
>you might wish.

No disrespect toward PLT Scheme -- quite the
contrary. I was just using MzScheme "syntax"
(which I happen to remember best) to give a
real-world answer to the request for an example. The
point is not specific to MzScheme.

In the event, I do use a macro. However the context I
was responding to was deliberately not considering
user-defined solutions. They were discussing how
Scheme doesn't have a standard defstruct. I was
showing why any implementation-specific defstruct
isn't good enough to be considered for
standardship.

My view is that a defstruct whose constructors are BOA
is... constricting. BOA doesn't scale. To say BOA is
OK for small numbers of slots undercuts the canonical
motivation behind defstruct. For if we can put up
with BOA for the construction part of a struct, so can
we also put up with the usual non-struct ways of
dealing with slot access/update. If remembering the
slot order is not so very hard for construction
purposes, then remembering them again for slot
access/update cannot suddenly become so
oppressively difficult that we need defstruct.

>> Much less error-prone would be the

>> CL-esque [...]
>
>I've never seen a satisfying exposition of how this is compiled
>efficiently. Perhaps you can provide one (satisfying or otherwise)?

No. I don't have a solution (else I'd be writing up
an SRFI instead of posting to Usenet). I just don't
think the "best" solutions are good (let alone good
enough).

--d

John Clonts

unread,
Jun 17, 2000, 3:00:00 AM6/17/00
to
Dorai Sitaram wrote:
[snip]

>
>
> My view is that a defstruct whose constructors are BOA
> is... constricting. BOA doesn't scale. To say BOA is
> OK for small numbers of slots undercuts the canonical
> motivation behind defstruct. For if we can put up
> with BOA for the construction part of a struct, so can
> we also put up with the usual non-struct ways of
> dealing with slot access/update. If remembering the
[snip]

Excuse me, what does BOA stand for?

Cheers,
John

Michael Hudson

unread,
Jun 17, 2000, 3:00:00 AM6/17/00
to
John Clonts <jcl...@mastnet.net> writes:

By Order of Argument. "BOA constructor" is a contender for the worst
pun I've ever encountered in a computing context...

Cheers,
Michael

--
Those who have deviant punctuation desires should take care of their
own perverted needs.
<chorus>So I'm rabidly intolerant on this. Sue me.</chorus>
-- Erik Naggum, comp.lang.lisp

John Clonts

unread,
Jun 17, 2000, 3:00:00 AM6/17/00
to
Michael Hudson wrote:
>
> John Clonts <jcl...@mastnet.net> writes:
>
> > Dorai Sitaram wrote:
> > [snip]
> > >
> > >
> > > My view is that a defstruct whose constructors are BOA
> > > is... constricting. BOA doesn't scale. To say BOA is
> > > OK for small numbers of slots undercuts the canonical
> > > motivation behind defstruct. For if we can put up
> > > with BOA for the construction part of a struct, so can
> > > we also put up with the usual non-struct ways of
> > > dealing with slot access/update. If remembering the
> > [snip]
> >
> > Excuse me, what does BOA stand for?
>
> By Order of Argument. "BOA constructor" is a contender for the worst
> pun I've ever encountered in a computing context...
>
> Cheers,
> Michael

OH THAT IS CHOICE, I LOVE IT!

Pierre R. Mai

unread,
Jun 17, 2000, 3:00:00 AM6/17/00
to
John Clonts <jcl...@mastnet.net> writes:

> Dorai Sitaram wrote:
> [snip]
> >
> >
> > My view is that a defstruct whose constructors are BOA
> > is... constricting. BOA doesn't scale. To say BOA is
> > OK for small numbers of slots undercuts the canonical
> > motivation behind defstruct. For if we can put up
> > with BOA for the construction part of a struct, so can
> > we also put up with the usual non-struct ways of
> > dealing with slot access/update. If remembering the
> [snip]
>
> Excuse me, what does BOA stand for?

From the HyperSpec entry on defstruct, discussing :constructor:

Because a constructor of this type operates ``By Order of Arguments,''
it is sometimes known as a ``boa constructor.''

IMHO the whole discussion (as well as numerous other discussions on
similar topics, and the experience of DSSSL) indicates that Scheme
might be in need of standardized keyword arguments, which could then
be used to include a CL-like defstruct facility, which allows for both
BOA and keyword-based constructors (and combinations of same).

F'up to c.l.l since I don't read c.l.scheme regularly anymore.

Regs, Pierre.

--
Pierre Mai <pm...@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]

Marco Antoniotti

unread,
Jun 17, 2000, 3:00:00 AM6/17/00
to

> In article <j7vbt11...@sun.cs.rice.edu>,
> Shriram Krishnamurthi <shr...@cs.rice.edu> wrote:
> >ds...@goldshoe.gte.com (Dorai Sitaram) writes:
> >
> >> Let's say we have the following struct (I'm
> >> using MzScheme syntax)
> >> [...]
> >
> >So define a macro. Big deal. Indeed, it is interesting that you
> >should bring up PLT Scheme, because DEFINE-STRUCT is actually a
> >macro over STRUCT. STRUCT just returns a multitude of values; you can
> >name these as you wish, along the way wrapping the constructor to pull
> >apart an association list, check for argument types, or whatever else
> >you might wish.

A better answer is: use CL. Big Deal. Your program will work on any CL
implementations and in all the Scheme that do the right thing:
re-implement the wheel.

Reality is a point of view

unread,
Jun 17, 2000, 3:00:00 AM6/17/00
to
+----

Is that a 'nothing, there is not any available' answer with a
reference to tree bark v grasshopper? Is that what passes for
intellectual behavior in Lisp/Schemeland nowadays? How sad.

--
Gary Johnson gjoh...@season.com
Privacy on the net is still illegal.
<a href=http://www.ibm.com/GNU/Linux>heh</a>

Tom Breton

unread,
Jun 17, 2000, 3:00:00 AM6/17/00
to
John Clonts <jcl...@mastnet.net> writes:

> Dorai Sitaram wrote:
> [snip]
> >
> >
> > My view is that a defstruct whose constructors are BOA
> > is... constricting. BOA doesn't scale. To say BOA is
> > OK for small numbers of slots undercuts the canonical
> > motivation behind defstruct. For if we can put up
> > with BOA for the construction part of a struct, so can
> > we also put up with the usual non-struct ways of
> > dealing with slot access/update. If remembering the
> [snip]
>
> Excuse me, what does BOA stand for?

By Order of Argument.

Usually it refers to an arglist whose default values can safely depend
on earlier args but not on later ones.

But as used in this thread, it seems to mean a ctor whose args are not
keyword-based, but position-based according to the order slots are
declared.

--
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
Some vocal people in cll make frequent, hasty personal attacks, but if
you killfile them cll becomes usable.

Boris Schaefer

unread,
Jun 18, 2000, 3:00:00 AM6/18/00
to
norm@- writes:

| In article <394A4F76...@ncgr.org>, David says...
|

| >> Show an example where single inhertitance only can make it difficult
| >> to write those compelex applications you are talking about?
|
| >
| >That's pretty trivial. You have a class "car" with functionality. You
| >have a class "pet carrier" also with functionality. You want to use
| >your car to carry a pet. If you have MI, you can do this trivially.
| >If you don't, you have to make interface for each of these, and
| >make a class which delegates to both. This is a lot more work
| >to do in the first place, and maintenance effort later.
| >
|

| NO you idiot. Simply make an instance of "pet carrier" inside your
| class "car". (you said yourself the car want to carry a pet).

well, your car which contains a pet carrier is not a pet carrier, so

instanceof(petcarrier); (or whatever Java syntax is required here)

will not be true in your case while with MI this would be true. If
you want the car to also be of type petcarrier, you have to use
complicated delegation mechanisms, if you don't have MI.

--
Boris Schaefer <bo...@uncommon-sense.net>

If we could sell our experiences for what they cost us, we would
all be millionaires.
-- Abigail Van Buren

Eugene Zaikonnikov

unread,
Jun 19, 2000, 3:00:00 AM6/19/00
to

"tom" <tmb at ncal point verio point com x@x.x> wrote in message
news:pb866r9...@aimnet.com...

> "Eugene Zaikonnikov" <vik...@cit.org.by> writes:
> > > But Pete was talking about extensive libraries, not complex language
> > > design. Java is a modest and simple language as far as languages go.
> > > It doesn't try to be an "all-in-one language", it merely tries to give
> > > you a good set of libraries.
> > >
> > This is quite depends on what to count as a library. If we define
library as
> > a set of code providing common useful functionality *and* written in the
> > language it intended to be used with, then Java has not too many
libraries.
>
> I don't see why such a definition of "language" and "library" would be
> useful. I think the reason simple languages are good is that people

Because in this case you may limit yourself to your favorite language only,
without intermediation of 'inferiorities' (as Pete was assuming) like C
code.

> can learn them easily, tools are easier to write, and the behavior of
> programs is easier to predict. OTOH, whether a library internally

Lisp has pretty uniform and simple syntax in this regard, not more complex
than Java, at least. OTOH, when you start using various APIs, libraries and
third-party tools for real work you need to grok a lot of accompanying stuff
no matter which language you use, and the amount of work to learn language
syntax constitutes a little fraction of the whole mental effort.

> In any case, I think you underestimate the amount of pure Java code in
> the Java libraries. Almost all of Swing is written in pure Java (and
> both Swing and AWT could be written in 100% pure Java if anyone wanted
> to bother), as are many of the relational database interfaces,
> persistence, collection classes, string handling, IDEs, Internet
> protocols, compilers, and other tools.
>

As well as it is possible to implement multithreading model within pure
Common Lisp, if anyone cared.
I can't judge about amount of native code in Java libraries, but I know that
there is some in almost all of them. Correct me if I wrong, but in my
understanding Java code in libraries is limited to high-level functionality
and wrappers across native code, be it TCP stack, GUI hooks, smart-card
interface or anything else. And as the underlying code varies across
platfoms, one can't declare 100% portability. Lisp approach was not to
engrave in stone things that can't be done orthogonal. This means that spec
would rather clearly state that 'behavior is implementation-dependent', than
cheat you claiming it would work uniformily everywhere.

> Perhaps one of the biggest obstacles to Lisp evolution (and why so
> many people have switched) is this insistence that it does things "the
> Right Way". I think that kind of attitude inhibits progress and

My feeling is that "the Right Way" is the essence of Lisp. Without it, Lisp
couldn't have remained Lisp. If I wanted to float in a sea of assorted
components like that hypothetic von Neumann robot I'd rather choose Java.
But again, this is only IMO.

> > Anyway, nothing restricts one to wirte libraries for Lisp :)
>
> Sure: when we look at the CL definition, we find a
> lack of a standard FFI

Agreed.

> an incompletely specified condition system
I never had any troubles or discomfort using condition system. Could you
point the missing parts? (Not that I'm implying there are none).

> incompletely specified effects of type declarations

They specified as advises to implementations.

> lack of multithreading
In times when Lisp for Connection Machine existed, 'standard multithreading'
was rather blurry term. Anyway, why restrict to multithreading only? How
about process migration?

> lack of sockets
Sockets is a way too narrow. I'd better say lack of communications support.

> lack of fast binary I/O
Binary I/O is specified. It's speed is up to implementation and out of
standard's scope.

> incompletely specified reflection
Come on :) I'm happy you didn't pointed out missing list processing
facilities :)

BTW, it's time for ANSI standard revision. Does anyone knows what can be
added/changed?

--
Eugene.


David Hanley

unread,
Jun 19, 2000, 3:00:00 AM6/19/00
to

norm@- wrote:

> In article <394A4F76...@ncgr.org>, David says...
>
> >> Show an example where single inhertitance only can make it difficult
> >> to write those compelex applications you are talking about?
>
> >
> >That's pretty trivial. You have a class "car" with functionality. You
> >have a class "pet carrier" also with functionality. You want to use
> >your car to carry a pet. If you have MI, you can do this trivially.
> >If you don't, you have to make interface for each of these, and
> >make a class which delegates to both. This is a lot more work
> >to do in the first place, and maintenance effort later.
> >
>
> NO you idiot. Simply make an instance of "pet carrier" inside your
> class "car". (you said yourself the car want to carry a pet).

Listen. YOU don't understand the example. If you put a instance
of class 'carrier' inside of class 'car' how are you going to pass
that object to a function which wants a 'carrier?' You're going
to have to have abstract interfaces for 'car' and 'carrier' and
implements all those interfaces in your encapsulating class. Then
if you add a method to the base, you've got to find all those
proxies and manually extend them, instead of doing no work
at all in the MI case.

Ignoring the rest of your post.

dave


Sashank Varma

unread,
Jun 19, 2000, 3:00:00 AM6/19/00
to
In article <96142534...@cpl2500.cit.org.by>, "Eugene Zaikonnikov"
<vik...@cit.org.by> wrote:

[snip]


>If I wanted to float in a sea of assorted
>components like that hypothetic von Neumann robot I'd rather choose Java.

[snip]

:-)

sashank

Steven M. Haflich

unread,
Jun 19, 2000, 3:00:00 AM6/19/00
to
Eugene Zaikonnikov wrote:

> BTW, it's time for ANSI standard revision. Does anyone knows what can be
> added/changed?

Anything at all can be changed. It lacks only people willing to invest
the significant time and energy required by standards work. The committe
that manages the standard is NCITS/J13; some of the frequent posters to
this list are members, others are not.

The 1994 ANS was reaffirmed in 1999 for the required review every five
years. It can be reopened any time the committee wants to submit to NCITS
a proposal for a new "work item" to revise or extend the standard. At the
Oct 1999 J13 meeting there was significant interest in starting work in
a number of areas. I am personally aware of a couple individuals or small
groups working on test implementations of things that might eventually be
proposed for standardization. However, efforts within J13 itself to draft
work item proposals for NCITS seem stalled. Perhaps none of the work areas
are yet mature -- most in the committee reasonably believe that
implementation should precede standardization.

[NCITS is one of several standards organizations qualified to ANSI to manage
ongoing standards. J13 is the Technical Committee for Lisp, although in
practice J13 has concerned itself only with CL and liason to related
languages such as Eulisp. Since this is cross posted to comp.lang.lisp and
comp.lang.scheme, I should point out that J13 has never concerned itself with
Scheme as Scheme operates successfully in a different forum. Nonetheless, if
someone should raise a Scheme issue with NCITS, it would be forwarded to J13
at least for comment.

Membership in NCITS technical committees is open to any individual or
organization interested in the technical area and is _not_ restricted to U.S.
members. However, it does cost $600 per year for either organizational or
individual membership.]

You are welcome to visit http://www.ncits.org or contact me directly if
you'd like to consider joining.

Steven Haflich
Chair, NCITS/J13
s...@alum.mit.edu

Russell Wallace

unread,
Jun 20, 2000, 3:00:00 AM6/20/00
to
Dorai Sitaram wrote:
> My view is that a defstruct whose constructors are BOA
> is... constricting. BOA doesn't scale. To say BOA is
> OK for small numbers of slots undercuts the canonical
> motivation behind defstruct. For if we can put up
> with BOA for the construction part of a struct, so can
> we also put up with the usual non-struct ways of
> dealing with slot access/update. If remembering the
> slot order is not so very hard for construction
> purposes, then remembering them again for slot
> access/update cannot suddenly become so
> oppressively difficult that we need defstruct.

It's a question of how many times it's done.

Let's say I'm creating a struct instance with 10 members. I'm not going
to be sure of remembering all the names exactly anyway, so I bring up
the struct definition, and type in the 10 initial items in another
window, save myself the trouble of redundantly typing the 10 slot names
again. To verify that they match exactly, I just put them side by
side. (2 keystrokes in Brief, I assume Emacs can do it similarly?)

But on the subsequent two dozen occasions when I access one element I
usually am sure I remember the name of that one element and I don't want
to have to repeat that procedure each time and I've only one name to
retype each time so I always want by-keyword for access.

That said, given that people disagree, a struct facility should probably
have good support for both by-order and by-keyword construction.

--
"To summarize the summary of the summary: people are a problem."
Russell Wallace
mailto:rwal...@esatclear.ie
http://www.esatclear.ie/~rwallace

Erik Naggum

unread,
Jun 20, 2000, 3:00:00 AM6/20/00
to
* Yiorgos Adamopoulos

| Oh but it is! As someone else posted earlier in this thread, Java
| programmers are bug free.

I get the impression from this comment and your last comment that
you are the kind of programmer who can't write even an expression,
let alone a line of code, that is bug free, and you don't want any
other programmers to be able to claim that they can write hundreds,
if not thousands, of expressions/lines without any bugs.

The fact that humans are mortal does not mean that it's a good idea
to kill people. The fact that we are mortal is in some sense what
makes _life_ so much worth living. Likewise, the fact that software
is so hard to write that we are bound to get some things wrong does
not mean that we should create broken software from the outset or
break things that people depend on, but rather find ways to cherish
the ways we discover to write bug-free code.

#:Erik
--
If this is not what you expected, please alter your expectations.

Thant Tessman

unread,
Jun 20, 2000, 3:00:00 AM6/20/00
to

Erik Naggum wrote:
>
> * Yiorgos Adamopoulos
> | Oh but it is! As someone else posted earlier in this thread, Java
> | programmers are bug free.
>
> I get the impression from this comment and your last comment that
> you are the kind of programmer who can't write even an expression,
> let alone a line of code, that is bug free, and you don't want any
> other programmers to be able to claim that they can write hundreds,
> if not thousands, of expressions/lines without any bugs.

[...]

He said Java *programmers* are bug free, not Java *programs*.

-thant

felix

unread,
Jun 20, 2000, 3:00:00 AM6/20/00
to

Erik Naggum wrote in message <31705094...@naggum.no>...

>* Yiorgos Adamopoulos
>| Oh but it is! As someone else posted earlier in this thread, Java
>| programmers are bug free.
>
> I get the impression from this comment and your last comment that
> you are the kind of programmer who can't write even an expression,
> let alone a line of code, that is bug free, and you don't want any
> other programmers to be able to claim that they can write hundreds,
> if not thousands, of expressions/lines without any bugs.
>

I think he was just using a little bit of irony, Erik!


felix


Erik Naggum

unread,
Jun 20, 2000, 3:00:00 AM6/20/00
to
* Thant Tessman <th...@acm.org>

| He said Java *programmers* are bug free, not Java *programs*.

Not the first time around. I'm subtracting some in the precision
department due to the visibly limited English skills of the author.

In <slrn8kkd8v...@castro.dbnet.ece.ntua.gr>, he wrote:

| Dream On! Do you imply that you are able to write bug free code?

I find comments scornful of quality indicative of incompetence
bordering on the criminal. When repeated, it was no accident.

People who are _unable_ to write bug-free code should wake up and
smell the coffee and do the world a favor by just abstaining from
writing any more buggy code. We have enough people who write buggy
code who are at least _able_ to write bug-free code...

Yiorgos Adamopoulos

unread,
Jun 20, 2000, 3:00:00 AM6/20/00
to
In article <skve3nh...@corp.supernews.com>, felix wrote:
>
>I think he was just using a little bit of irony, Erik!
>

Indeed I was. I do not even care to explain my programming abilities to
anyone. However, I am going to keep the flame that I received as one of
the best I have ever seen on the USENET.

Thank you.

--
${talks}

felix

unread,
Jun 20, 2000, 3:00:00 AM6/20/00
to

Yiorgos Adamopoulos wrote in message ...


Oh, there are much better ones! ;-)


felix


Erik Naggum

unread,
Jun 20, 2000, 3:00:00 AM6/20/00
to
* "felix" <fe...@anu.ie>

| I think he was just using a little bit of irony, Erik!

What a useful comment. Now, back to whatever you were discussing.

Yiorgos Adamopoulos

unread,
Jun 20, 2000, 3:00:00 AM6/20/00
to
[ I think this is off topic, but what the hell, this is the USENET after
all ]

In article <31705147...@naggum.no>, Erik Naggum wrote:
> Not the first time around. I'm subtracting some in the precision
> department due to the visibly limited English skills of the author.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

My English is very good, thank you very much.

>| Dream On! Do you imply that you are able to write bug free code?
>
> I find comments scornful of quality indicative of incompetence

And you can judge quality? Or even I? How? Who?

> bordering on the criminal. When repeated, it was no accident.

Indeed. But you totally missed my point and clearly it was not my
incompetence on English. More, it was you being ready to fire at me, since
you disliked my comment.

> People who are _unable_ to write bug-free code should wake up and
> smell the coffee and do the world a favor by just abstaining from
> writing any more buggy code. We have enough people who write buggy
> code who are at least _able_ to write bug-free code...

I am uncapable of many things. Writing code is not one of them. And of
couse when I write code that is more than say 100 lines, then it is
probable that bugs will be in it. Even if I stick to procedures. After
all, we all are humans.

Yes, I wrote ``Java programmers are bug free'' and this was to be taken as
a humorous comment. s/Java/the-language-you-like/g and you will get my
point.

...But instead you chose to flame the ``visibly limited in English skills''
Greek who dared to post to your newsgroup, expressing in a harsh way
something you do not like.

Using the same logic as you, I might be able to conclude that assuming
twice that I cannot write code is no mistake: You too cannot write code,
although you think you can.

But I am wrong, ain't I?

So please, lets end it here and read something usefull to both of us.
--
${talks}

Yiorgos Adamopoulos

unread,
Jun 20, 2000, 3:00:00 AM6/20/00
to
In article <31705186...@naggum.no>, Erik Naggum wrote:
> "USENET" is what each one of us makes of it. Judging by your
> comments, I don't want what you want to make of it, so end the
> meta-discussion if you want me to respond to you. If not: EOD.

If it makes your ego feel better, I appologize for not standing up to your
standards. And I appologize to the group as a whole.

Boy, you are surely a tough man to live with (if you behave the same IRL).

--
${talks}

Erik Naggum

unread,
Jun 20, 2000, 3:00:00 AM6/20/00
to
* Yiorgos Adamopoulos

| [ I think this is off topic, but what the hell, this is the USENET
| after all ]

"USENET" is what each one of us makes of it. Judging by your


comments, I don't want what you want to make of it, so end the
meta-discussion if you want me to respond to you. If not: EOD.

#:Erik

PCM

unread,
Jun 21, 2000, 3:00:00 AM6/21/00
to

"Erik Naggum" <er...@naggum.no> wrote in message
news:31705147...@naggum.no...
> * Thant Tessman <th...@acm.org>

>
> | Dream On! Do you imply that you are able to write bug free code?
>
> People who are _unable_ to write bug-free code should wake up and
> smell the coffee and do the world a favor by just abstaining from
> writing any more buggy code. [...]

If that were to happen, it would leave the world with approximately zero
programmers. Honestly Erik, you sound like you have never written a program
of any realistic size. Whenever you enter the real world you will be in for
a very big shock.

Espen Vestre

unread,
Jun 21, 2000, 3:00:00 AM6/21/00
to
"PCM" <p...@netspace.net.au> writes:

> If that were to happen, it would leave the world with approximately zero
> programmers. Honestly Erik, you sound like you have never written a program
> of any realistic size. Whenever you enter the real world you will be in for
> a very big shock.

let me first assure you that Eriks software, from what I've heard of it,
works and solves quite hard problems in the very real business world.

But otherwise, I agree with you - I don't like the word "bug-free".
Maybe it would be better to talk about more and less bug-infested code.
As someone (who was that?) once put it: "A completely bug-free program
is either uninteresting or outdated".
--
(espen)

Thant Tessman

unread,
Jun 21, 2000, 3:00:00 AM6/21/00
to

PCM wrote:
>
> "Erik Naggum" <er...@naggum.no> wrote in message
> news:31705147...@naggum.no...
> > * Thant Tessman <th...@acm.org>
> >
> > | Dream On! Do you imply that you are able to write bug free code?

I didn't write this. Yiorgos Adamopoulos did. And I'm actually very
sympathetic to Eric Naggum's point about scorn toward quality, although
I think he overreacted. The complexity of the task of programming and
the already established low standards of quality should not lull us into
expecting software to be buggy. (And I don't believe for a second that
Yiorgos' use of "programmers" in place of "programs" was an intentional
attempt at humor.)

> >
> > People who are _unable_ to write bug-free code should wake up and
> > smell the coffee and do the world a favor by just abstaining from
> > writing any more buggy code. [...]
>

> If that were to happen, it would leave the world with approximately zero
> programmers. Honestly Erik, you sound like you have never written a program
> of any realistic size. Whenever you enter the real world you will be in for
> a very big shock.

-thant

Espen Vestre

unread,
Jun 21, 2000, 3:00:00 AM6/21/00
to
Thant Tessman <th...@acm.org> writes:

> The complexity of the task of programming and
> the already established low standards of quality should not lull us into
> expecting software to be buggy.

I couldn't agree more, but I still think a little care should be
taken before using the word "bug-free", although a certain rich
man from Washington State dares to use it when speaking about
software that others know is notoriously bug-infested.

--
(espen)

Kenneth P. Turvey

unread,
Jun 21, 2000, 3:00:00 AM6/21/00
to
On 21 Jun 2000 11:27:47 +0200, Espen Vestre <espen@*do-not-spam-me*.vestre.net> wrote:

>"PCM" <p...@netspace.net.au> writes:
>
>> If that were to happen, it would leave the world with approximately zero
>> programmers. Honestly Erik, you sound like you have never written a program
>> of any realistic size. Whenever you enter the real world you will be in for
>> a very big shock.
>
>let me first assure you that Eriks software, from what I've heard of it,
>works and solves quite hard problems in the very real business world.
>
>But otherwise, I agree with you - I don't like the word "bug-free".
>Maybe it would be better to talk about more and less bug-infested code.
>As someone (who was that?) once put it: "A completely bug-free program
>is either uninteresting or outdated".

And many would consider outdated a bug.

--
Kenneth P. Turvey <kt-...@SprocketShop.com>
http://www.tranquility.net/~kturvey/resume/resume.html
--------------------------------------------------------
The optimist thinks this is the best of all possible worlds. The
pessimist fears it is true.
-- Robert Oppenheimer

Erik Naggum

unread,
Jun 21, 2000, 3:00:00 AM6/21/00
to
* "PCM" <p...@netspace.net.au>

| If that were to happen, it would leave the world with approximately
| zero programmers. Honestly Erik, you sound like you have never
| written a program of any realistic size. Whenever you enter the
| real world you will be in for a very big shock.

How come you guys who obviously want everybody to be _unable_ to
write bug-free code of _any_ complexity all have to attack _me_?

Could there be a relation between the inability to write code that
is actually _correct_ and the ability to _think_ and _argue_? Nah.

#:Erik, disgusted

felix

unread,
Jun 21, 2000, 3:00:00 AM6/21/00
to

Erik Naggum wrote in message <31705154...@naggum.no>...

> What a useful comment. Now, back to whatever you were discussing.


Hey, Erik, old pal! Howzitgoin?


Simon Brooke

unread,
Jun 22, 2000, 3:00:00 AM6/22/00
to
pete@nowhere writes:

> In article <87hfav1...@quadium.net>, vsync says...
>
> >
> >Anyway, I think Java is a great language for certain things. However,
> >the features that can make it simple and fairly easy to use, such as
> >single inheritance only, clearly defined namespaces, and a strict
> >security model, can also make it very difficult to use for more
> >complex programs.
> >
>
> Wow, the guys talks as if he knows what he is talking about.


> Show an example where single inhertitance only can make it difficult
> to write those compelex applications you are talking about?

Well, for example, mixins. Suppose you want to have a piece of
behaviour which is exhibited by a range of different objects with
different anticedents.

In Java, you define an interface, and every class that implements the
interface must have a complete copy of the code required to implement
that interface - even if the code is actually identical.

With multiple inheritence, you just inherit from the mixin class. You
don't have to reinvent the wheel, and you substantially reduce the
probability of subtle inconsistencies of behaviour.

--
si...@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/

Wise man with foot in mouth use opportunity to clean toes.
;; the Worlock

Shriram Krishnamurthi

unread,
Jun 22, 2000, 3:00:00 AM6/22/00
to
Simon Brooke <si...@jasmine.org.uk> writes:

> In Java, you define an interface, and every class that implements the
> interface must have a complete copy of the code required to implement
> that interface - even if the code is actually identical.
>
> With multiple inheritence, you just inherit from the mixin class. You
> don't have to reinvent the wheel, and you substantially reduce the
> probability of subtle inconsistencies of behaviour.

Yes, but then you're stuck with MI in your language, and if you
believe that MI is a misfeature, then you haven't really made
progress.

You can get the benefits of MI with the simplicity of SI if you
redesign your language slightly. See a proposal that shows what this
design would be in the Java context.

http://www.cs.rice.edu/CS/PLT/Publications/#popl98-fkf
Classes and Mixins
Flatt, Krishnamurthi, Felleisen
POPL 1998

You can use a similar style of programming in PLT Scheme, but you
don't get all the same name access benefits. To illustrate why this
form of mixins is especially powerful in the context of a good module
system, see

http://www.cs.rice.edu/CS/PLT/Publications/#icfp98-ff
Modular Object-Oriented Programming with Units and Mixins
Findler, Flatt
ICFP 1998

'shriram

Thomas A. Russ

unread,
Jun 22, 2000, 3:00:00 AM6/22/00
to
Shriram Krishnamurthi <shr...@cs.rice.edu> writes:

> Yes, but then you're stuck with MI in your language, and if you
> believe that MI is a misfeature, then you haven't really made
> progress.

I'm curious about why you thing multiple inheritance is a misfeature. I
looked at the first few pages of the paper (the TR version) and didn't
find much of an argument against MI, other than the fact that the C++
version was not taught much. In as much as I consider MI hopelessly
braindead (a sentiment I believe is shared by many Common Lispers), this
hardly seems like an overwhelming argument.

Common Lisp has well-defined semantics for class combination and method
dispatch, as well as a MI analogy to Java's super.method() invocation.

--
Thomas A. Russ, USC/Information Sciences Institute t...@isi.edu

Kenneth P. Turvey

unread,
Jun 22, 2000, 3:00:00 AM6/22/00
to
On 22 Jun 2000 10:08:30 -0500, Shriram Krishnamurthi <shr...@cs.rice.edu> wrote:
>
>Yes, but then you're stuck with MI in your language, and if you
>believe that MI is a misfeature, then you haven't really made
>progress.

If you believe that MI is a misfeature... why not just avoid using it?
I don't really understand the aversion to MI. It does make things
somewhat more complicated if it is used without thought, but I miss it
in Java when nothing else is really as satisfactory.

It seems like a lot of Java programming is working out ways to mimic MI
without really using it.


--
Kenneth P. Turvey <kt-...@SprocketShop.com>
http://www.tranquility.net/~kturvey/resume/resume.html
--------------------------------------------------------

There are two major products that come out of Berkeley: LSD and UNIX.
We don't believe this to be a coincidence.
-- Jeremy S. Anderson

Thomas A. Russ

unread,
Jun 22, 2000, 3:00:00 AM6/22/00
to

Updating my previous comments, to fix an omission that Erik Naggum
kindly pointed out to me:

t...@sevak.isi.edu (Thomas A. Russ) writes:


> Shriram Krishnamurthi <shr...@cs.rice.edu> writes:
>
> > Yes, but then you're stuck with MI in your language, and if you
> > believe that MI is a misfeature, then you haven't really made
> > progress.
>

> I'm curious about why you thing multiple inheritance is a misfeature. I
> looked at the first few pages of the paper (the TR version) and didn't
> find much of an argument against MI, other than the fact that the C++
> version was not taught much. In as much as I consider MI hopelessly
> braindead (a sentiment I believe is shared by many Common Lispers), this

^
|
|
in C++

> hardly seems like an overwhelming argument.
>
> Common Lisp has well-defined semantics for class combination and method
> dispatch, as well as a MI analogy to Java's super.method() invocation.

Thomas A. Russ, USC/Information Sciences Institute t...@isi.edu


Bernhard Pfahringer

unread,
Jun 23, 2000, 3:00:00 AM6/23/00
to
Simon Brooke <si...@jasmine.org.uk> writes:
>
> Well, for example, mixins. Suppose you want to have a piece of
> behaviour which is exhibited by a range of different objects with
> different anticedents.
>
> In Java, you define an interface, and every class that implements the
> interface must have a complete copy of the code required to implement
> that interface - even if the code is actually identical.
>
> With multiple inheritence, you just inherit from the mixin class. You
> don't have to reinvent the wheel, and you substantially reduce the
> probability of subtle inconsistencies of behaviour.
>

If the code is really identical, couldn't you bundle it
up into something like:

(defun mixed-in-behavior-function (object other-args)
...)

and simply dispatch from all classes that "implement" the "interface"
like:

(defmethod mixed-in-behavior ((class1 class1) &rest other-args)
(mixed-in-behavior-function class1 other-args))

(defmethod mixed-in-behavior ((class2 class2) &rest other-args)
(mixed-in-behavior-function class2 other-args))

...

Can something like this be done in Java?

cheers, Bernhard

--------------------------------------------------------------------------
Bernhard Pfahringer
Dept. of Computer Science, University of Waikato
G1.25, 838 4041
bern...@cs.waikato.ac.nz
--------------------------------------------------------------------------

Pierre R. Mai

unread,
Jun 23, 2000, 3:00:00 AM6/23/00
to
Bernhard Pfahringer <bern...@cs.waikato.ac.nz> writes:

> Simon Brooke <si...@jasmine.org.uk> writes:
> >
> > Well, for example, mixins. Suppose you want to have a piece of
> > behaviour which is exhibited by a range of different objects with
> > different anticedents.
> >
> > In Java, you define an interface, and every class that implements the
> > interface must have a complete copy of the code required to implement
> > that interface - even if the code is actually identical.
> >
> > With multiple inheritence, you just inherit from the mixin class. You
> > don't have to reinvent the wheel, and you substantially reduce the
> > probability of subtle inconsistencies of behaviour.
> >
>
> If the code is really identical, couldn't you bundle it
> up into something like:
>
> (defun mixed-in-behavior-function (object other-args)
> ...)
>
> and simply dispatch from all classes that "implement" the "interface"
> like:
>
> (defmethod mixed-in-behavior ((class1 class1) &rest other-args)
> (mixed-in-behavior-function class1 other-args))
>
> (defmethod mixed-in-behavior ((class2 class2) &rest other-args)
> (mixed-in-behavior-function class2 other-args))
>

> Can something like this be done in Java?

Of course you can work around missing MI, but the point of much of OO
was to express certain concepts more concisely, so this seems to
defeat this intent pretty cleverly.

Also note that the behaviour of the mixin might be distributed across
a large number of generic functions, which will get you a certain
explosion of functions and stub methods. Furthermore the added
behaviour for a certain GF might want to invoke call-next-method
(or might indeed want to be a :before/:after or :around method), in
which case your approach would have to use macros, which aren't
available in Java. But there is still cut'n'paste, which always comes
to the rescue of languages that are not capable of directly expressing
what you want to express... ;)

In languages where MI has properly useful semantics (i.e. not the
brain dead C++ semantics), I have used MI without problems, but with
big success, since it often is the most natural way to express
implementation mixins:

Take for example the case of resources in an HTTP server: They
implement a protocol which includes GFs that determine whether an
access is allowed, perform the access, etc. In this case you might
have classes that implement the access itself, like e.g.

- static-resource which statically returns a pre-computed entity, or
- dynamic-resource which calls out to a user specified function to
compute the entity to be returned, or
- automagic-resource which is a user-defined resource class which does
even more intricate application-specific processing to compute a
response entity.

OTOH you might have classes that perform certain auxilliary tasks:

- base-authentication-mixin to provide for basic authentication via a
fixed user/password
- ldap-authentication-mixin to provide for basic authentication via an
LDAP user database
- standard-logging-mixin to provide for standardized logging of
requests
- performance-logging-mixin to provide for optimized logging of
requests
- session-leader-mixin and sessioned-resource-mixin to provide for the
tracking of user sessions and corresponding session-data across
requests (e.g. via cookies, or other means).

Now it seems both natural and elegant to create the final resource
classes by mixing together a certain number of the above classes.

Regs, Pierre.

--
Pierre Mai <pm...@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]

George Neuner

unread,
Jun 23, 2000, 3:00:00 AM6/23/00
to
On Thu, 15 Jun 2000 14:44:19 -0600, Thant Tessman <th...@acm.org>
wrote:

>
>
>mike555@NOSPAM wrote:
>
>[...]
>
>> c++ programmers think they know more and smarter than any one else,
>> becuase their language is more complicated, they think this is good
>> to have more complicated mess to work with, they think using a simpler
>> language means one is not as smart as they are.
>
>You're posting to a Scheme group. Around here, arguing that Java is
>better than C++ is like arguing that grasshoppers taste better than tree
>bark.
>
>-thant

Grasshoppers definately taste better ... particularly when fried 8^)


George


David Thornley

unread,
Jun 23, 2000, 3:00:00 AM6/23/00
to
In article <31706050...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:
>* "PCM" <p...@netspace.net.au>
>| If that were to happen, it would leave the world with approximately
>| zero programmers. Honestly Erik, you sound like you have never
>| written a program of any realistic size. Whenever you enter the
>| real world you will be in for a very big shock.
>
Um, I think Erik is in the real world.

> How come you guys who obviously want everybody to be _unable_ to
> write bug-free code of _any_ complexity all have to attack _me_?
>

The obvious answer:

I, at least, cannot write bug-free code of significant complexity.
This is not for lack of trying, tools, or formal techniques. Everybody
who has told me whether they write bug-free code or not either
admits to being unable to write bug-free code, appears to me to be
completely unreliable, is named Erik, or some combination of the
first two (the last category may become intermingled, should I
meet another Erik).

This means that, when you imply that a competent programmer should be
able to write bug-free code, you imply that a whole lot of us out here
are incompetent. Naturally, some people perceive that as an attack
and react accordingly.



> Could there be a relation between the inability to write code that
> is actually _correct_ and the ability to _think_ and _argue_? Nah.
>

You are correct with the "Nah". Since approximately everybody I know
is unable to write bug-free code*, there would be no statistical
validity in any correlation based on that.

*Actually, everybody except one guy in Norway who write large programs,
apparently of high quality, and claims he writes them bug-free.


--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-

David Thornley

unread,
Jun 23, 2000, 3:00:00 AM6/23/00
to
In article <871z1o3...@orion.dent.isdn.cs.tu-berlin.de>,

Pierre R. Mai <pm...@acm.org> wrote:
>
>In languages where MI has properly useful semantics (i.e. not the
>brain dead C++ semantics), I have used MI without problems, but with
>big success, since it often is the most natural way to express
>implementation mixins:
>
FWIW, Metrowerks built an application framework in C++ for the Macintosh
that depends heavily on multiple inheritance to use mixins. It is
very successful, and lots of Mac applications are built on it. Any
attempt not to use MI in Powerplant would either make things more
difficult to use, or push lots of stuff into a towering class hierarchy
that would include a whole lot of unused functionality for any given
object.

Not that MI is implemented without flaw in C++, but it is useful, for
some of the same reasons it is in Lisp.

mato...@iname.com

unread,
Jun 23, 2000, 3:00:00 AM6/23/00
to
In article <394E987B...@ncgr.org>,
David Hanley <d...@ncgr.org> wrote:

> Listen. YOU don't understand the example. If you put a instance
> of class 'carrier' inside of class 'car' how are you going to pass
> that object to a function which wants a 'carrier?' You're going
> to have to have abstract interfaces for 'car' and 'carrier' and
> implements all those interfaces in your encapsulating class. Then
> if you add a method to the base, you've got to find all those
> proxies and manually extend them, instead of doing no work
> at all in the MI case.

He. And you don't even have C's sorry excuse for a macro system..
[Of course not having such trash is comparatively "right"]

Well, maybe all the hard work of the Dylan folks will eventually be
useful after all :->

--
Fernando D. Mato Mira


Sent via Deja.com http://www.deja.com/
Before you buy.

Robert Monfera

unread,
Jun 24, 2000, 3:00:00 AM6/24/00
to
I found the pun from Yiorgos quite funny.

Someone I could not identify to Erik (after the thread lost track):

> Dream On! Do you imply that you are able to write bug free code?

Throughout the course of the last few years Erik has published countless
code snippets (among other things), and as far as I looked at them and
remember, only one or two of them had any bugs. It's a good ratio,
given that most snippets weren't trivial at all, and they demonstrated
an expressive and compact coding style.

Robert

Yiorgos Adamopoulos

unread,
Jun 24, 2000, 3:00:00 AM6/24/00
to

Whereas I never published any. Correct, since he has proven his
competence. But I replied to the one (obviously Erik) that said
something along the lines (leave us who write bug free code alone).

We are all humans, and as such, prone to error no matter what. We are
prone to error, even if all our prior work is bugless. That is why I
found this statement annoying and I replied in the harsh way that I did
(not that Erik's answers were smoother).

--
I've got a problem solver and his name is revolver --Dr. Dre

Robert Monfera

unread,
Jun 24, 2000, 3:00:00 AM6/24/00
to
mike555@NOSPAM wrote:

> In the real world, and I have been programming for zillion years, I
> have never ever once had a need for MI of implementation.

I have seen quite a few unimaginative programmers in the real world(tm),
and you fight hard to demonstrate you are one of them. (Or maybe you
don't need OO at all to write device drivers or whatever, but then why
would you care to make comments on MI.)

To give you an example: maybe you have a class hierarchy of financial
instruments covering deposits, loans and derivatives. There are
specific ways to calculate their balances. Another classification
specifies if you implement caching for balance calculations. It is only
beneficial if the response time gains outweigh caching costs, so you
would only mix in the cached-class for instrument classes whose balance
computation is time-consuming. If you want your variable rate based
deposits cached, you can successfully do so via multiple inheritance.
It would result in compact code with a clear distinction between
financial logic and performance optimization scheme.

Similarly, a financial instrument class may be the subclass of several
other classes, like investment, discount or derivative. Your savings
account would inherit from investment, interest-earning and
variable-rate classes.

You should also discover multiple argument dispatch and other mechanisms
that keep your code expressive.

Java now simply does not provide abstraction tools like MI, which are
essential for non-trivial application development. This is not
surprising, given the roots of the Java/Oak language (embedded code for
appliances).

Robert

It is loading more messages.
0 new messages