Avoiding the second historic mistake
Bertran...@eiffel.com
--
"Think Java. Write new applications in Java.
Rewrite legacy apps with Java.
Don't upgrade or downgrade. Sidegrade instead to
a Java desktop device. Don't get hit with the
PC's massively negative ROI.
I don't understand why anybody would be
programming in anything other than Java"
Scott McNealy, Open Finance (a Sun publication),
Spring 1997.
Ten years ago or so, when object technology first captured
the industry's attention, projects moved en masse to C++.
This was not the right decision. Not that everything was bad
with C++ (then it would not have attracted so many
people); it was simply not appropriate for serious software
engineering. C++ was a transition technology, useful to make C
developers and their managers object-aware, but not appropriate
for the development of durable, high-quality software systems.
Interestingly enough, this was clear to many people; virtually
every object-oriented expert would privately concede that C++
was an inadequate solution - but carefully refrain from saying
so in public, for fear of appearing to go against the tide.
This is happening again with Java. Once again we have an
approach that has some major contributions to make but is
hyped as the solution to everything - and is not.
The contributions are clear enough. Java is good as
a language to write applets, and (through its virtual
machine) as a portable vehicle for executing programs written
in various languages. Its dynamic aspects are also interesting
for many applications.
But Java is inadequate as a software engineeering language for
enterprise applications. The deafening and at times indecent
marketing campaign that has been running continuously for almost
two years now (the quote at the beginning of this article is
typical) conveniently overlooks the limitations of Java:
- Unproven on large projects. Applets are great, but then
what?
- No multiple inheritance. (The marketing spin here is
quite smart: trying to convince people that multiple
inheritance is "bad", a contention for which not a single
piece of concrete evidence has ever been published, whereas
anyone who has practiced O-O development knows how important
it is to be able to combine separate abstractions.)
- No generic classes (forcing the frequent use of type casts,
with disastrous effects on both performance and safety).
- No assertions (even the modest "assert" of C++ has been
removed). This means - let's be clear about it -
that it is impossible to write serious reusable components
in Java, because serious reuse requires that the components
be specified. (See
http://www.eiffel.com/doc/manuals/technology/contract/ariane)
for a $500-million example of what happens when one violates
this elementary rule.) It's great to devise fancy names,
such as JavaBeans, but once the hype subsides
who is going to trust a mission-critical development to
"reusable" components who do not even document, let
alone monitor, their own specification?
- A neutered form of overriding (redefinition): when you
redefine a routine, you cannot change its signature.
This severely limits the application of polymorphism
and other fundamental O-O techniques. (If A has e.g.
a routine `copy' that takes an argument of type A,
representing an object to be copied, its redefinition
in a descendant class B must take an argument of type
B - otherwise it makes no sense. The only solution in
a no-signature-change language again appears to be the
use of casts, removing the benefits of type controls.)
- Violations of information hiding, hampering
object-oriented principles (you can write
a.x = value directly, i.e. modify an object field
without going through the interface of the class!).
- The confusing name overloading mechanism of C++ (what does
a.f (x) mean if a and x are polymorphic and f is both
redefined and overloaded for the corresponding types?).
- The confusing syntax of C, replete with special characters
and counter-intuitive conventions.
- Inadequate tools and environments (as confirmed recently by
a survey in ComputerWorld).
- Major performance problems (a project we know gave
up on Java after experiencing a tenfold performance
degradation compared to C++). Of course the vendors promise
that all will be fixed, and again the buzzwords are impressive,
as with "Just in Time Compiling", but buzzwords don't make
an application run faster.
As one .sig found on the net (I believe from Roland Turner)
states: "Java: the elegant simplicity of C++ and the blazing
speed of Smalltalk".
It is interesting to compare this with Eiffel:
- Used in projects large and small for eleven years.
- At the basis of large, successfully deployed commercial
projects in banking, networking, telecommunications,
health care etc.
- Taught successfully for many years in universities around
the world, because it is simple, clear and convincing.
- Used by experienced programmers as well as managers,
bankers, traders, engineers and specialists from widely
different backgrounds.
- The only approach that covers the entire lifecycle,
from analysis to design, implementation and maintenance
(no need for complex diagramming mechanisms
such as UML). Avoids the split personality of many
projects, where the analysis says one thing and the
software does another, and no one understands both.
- Widely cited as the most serious O-O language around
(e.g. in the OMT book by Rumbaugh et al.: "Eiffel is the
best commercially available object-oriented language",
and scores of similar comments in the literature).
- Offers a powerful inheritance mechanism supporting single,
multiple and repeated inheritance in a clear and simple way.
- Comes with thousands of proven reusable components, such
as EiffelBase, EiffelVision (portable graphics), EiffelNet
(client-server object communication), EiffelMath (numerical
computing), WEL (Windows graphics), EiffelStore (relational
database support), Matisse and Versant interfaces...
- Makes true reuse possible through the application of
carefully thought out reuse principles ("Reusable Software",
Prentice Hall).
- The only approach that can make reuse succeed on a truly
large scale thanks to its built-in support for assertions
(testable component specification, included in the
components themselves and used to generate the documentation).
- Runs on all major industry platforms, from Windows NT and
95 to all significant Unixes and VMS, with full source
compatibility.
- Run-time performance similar to C or C++.
- Instant recompilation, independent of project size,
thanks (in ISE Eiffel) to the Melting Ice Technology.
- An amazingly powerful environment, whose browsing facilities
have no equivalent for any language.
- Built-in automatic memory management and garbage collection.
- Interface to popular GUI builders through the Eiffel
Resource Bench. (Why redo what already exists? Object
technology is about leveraging software value, not doing
everything differently.)
- Interfaces to CORBA (soon to be released) and many other
industry-standard products.
- Backed (see http://www.eiffel.com/doc) by at least two
dozen books in English, Italian, French, German, Russian,
including in-depth descriptions of practical Eiffel
projects ("Object-Oriented Applications", Prentice Hall).
Extensive, award-winning on-line documentation at
http://www.eiffel.com.
- Now with support for multi-threading and (in SCOOP,
to be released later this year) arbitrary concurrency.
- Cheap personal versions (Windows, Linux), generous
university packages
(http://www.eiffel.com/services/university),
affordable token-based licensing.
Does this mean that one should drop everything else? Of course not.
As Roy Phillips noted in a recent posting to comp.lang.eiffel,
there is room and need for more than one language.
Eiffel recognizes the presence and usefulness of both
C++ (including C) and Java. Through its C++ interface and C++
wrapper (the recently released "Legacy++", see
http://www.eiffel.com/doc/manuals/technology/cpp/index.html),
ISE Eiffel provides clean encapsulation of C++ classes, in the
same way that it provides encapsulation of C functions.
Through its Java generation mechanism, slated for release later
this year, it will allow Eiffel developers to take advantage of
the Java VM and to combine Eiffel and Java code.
But the forced march to Java in 1997 is no more justified than the
mass conversions to C++ in 198. This time we don't have the
excuse that we don't know; and no spacecraft hides, ready to
rescue us, behind the comet.
Can we as an industry learn from our mistakes? How many more
Taligent-like catastrophes are needed, with Java replacing C++,
to discover the obvious? Must we lose another ten years?
No. One does not have to sacrifice the success of projects
to the fashion of the day. That you can use a language to spin
a fancy picture on a Web page does not mean you should use it
to program your bank's market trading.
There is money to be made now by choosing the right technical
approach. Using Eiffel, you can bring your projects to
completion faster and better. You can develop professional
reusable components and sell them. You can underprice the
competition on bids because you have a better technology.
One mistake is good; we as an industry can learn from it.
Two is one too many.
--
Bertrand Meyer, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <Bertran...@eiffel.com>
Web page: http://www.eiffel.com
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Peter van der Linden
Yeah, yeah, yeah. Bjarne Stroustrup is equally peeved that Java has
pushed C++ out of the game.
--
---
Peter van der Linden
Java Programmers FAQ ---> http://www.best.com/~pvdl
Chance favors the prepared mind.
D'Arcy Smith
This is a multi-part message in MIME format.
--------------F19794E9F01B09027889815D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bertran...@eiffel.com wrote:
> - Unproven on large projects. Applets are great, but then
> what?
Variaous parts of the JDK (javac, rmic, javadoc, etc...), HotJava,
Java Web Server, Corel Office for Java, etc...
> - Major performance problems (a project we know gave
> up on Java after experiencing a tenfold performance
> degradation compared to C++). Of course the vendors promise
> that all will be fixed, and again the buzzwords are impressive,
> as with "Just in Time Compiling", but buzzwords don't make
> an application run faster.
Have you tried any JIT's? I and others (not associated with Symantec)
have seen JIT'ed code that outperforms C++ (I'll freely admit that
it isn't common place).
JIT technology is young (just over a year) in the Java world.
Native code compilers can (potentialy) do better optimization
that C/C++ compilers.
> As one .sig found on the net (I believe from Roland Turner)
> states: "Java: the elegant simplicity of C++ and the blazing
> speed of Smalltalk".
:-)
> It is interesting to compare this with Eiffel:
>
> - Used in projects large and small for eleven years.
What did people say about Eiffel in the first few years of it's
public life? (I don't know but I'd imagine that they were not
all taken with it...)
> - At the basis of large, successfully deployed commercial
> projects in banking, networking, telecommunications,
> health care etc.
This is happening in Java now.
> - Taught successfully for many years in universities around
> the world, because it is simple, clear and convincing.
Java is being taught as a first language in some places...
> - Used by experienced programmers as well as managers,
> bankers, traders, engineers and specialists from widely
> different backgrounds.
And Java is not?
> - Widely cited as the most serious O-O language around
> (e.g. in the OMT book by Rumbaugh et al.: "Eiffel is the
> best commercially available object-oriented language",
> and scores of similar comments in the literature).
Give it's public life compared to that of Java this is not
hard to believe.
> - Comes with thousands of proven reusable components, such
> as EiffelBase, EiffelVision (portable graphics), EiffelNet
> (client-server object communication), EiffelMath (numerical
> computing), WEL (Windows graphics), EiffelStore (relational
> database support), Matisse and Versant interfaces...
Again given it's longer life...
> - Backed (see http://www.eiffel.com/doc) by at least two
> dozen books in English, Italian, French, German, Russian,
> including in-depth descriptions of practical Eiffel
> projects ("Object-Oriented Applications", Prentice Hall).
> Extensive, award-winning on-line documentation at
> http://www.eiffel.com.
I wander into my bookstore... and see how many Java books?
Now I'll agree that the Eiffel ones are problably better right
now... but given the longer public life of Eiffel...
> - Cheap personal versions (Windows, Linux), generous
> university packages
> (http://www.eiffel.com/services/university),
> affordable token-based licensing.
Free from javaSoft...
> But the forced march to Java in 1997 is no more justified than the
> mass conversions to C++ in 198.
---
^
|
How old is Bjarne? :-)--------|
Not to "Dis" (he he) Eeiffel but you've got a vested interest in seeing
it do better than Java (as I have with Java).
..darcy
--
D'Arcy Smith
Symantec, Internet Tools
JDK 1.1 for Cafe 1.53 Prerelease 2 - ftp://itools/pub/windows/cafe/1.53/
http://cafe.symantec.com
ftp://itools.symantec.com
snews://secnews.netscape.com/netscape.symantec.visualcafe
--------------F19794E9F01B09027889815D
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for D'Arcy Smith
Content-Disposition: attachment; filename="vcard.vcf"
begin:vcard
fn:D'Arcy Smith
n:Smith;D'Arcy
org:Symantec, Internet Tools
adr:City Center One;;20300 Stevens Creek Blvd;Cupertino;CA;95014;USA
email;internet:d...@itools.symantec.com
title:Sr. Software Engineer
x-mozilla-cpt:;0
x-mozilla-html:FALSE
end:vcard
--------------F19794E9F01B09027889815D--
Lars Marius Garshol
d...@itools.symantec.com wrote:
>
>> - At the basis of large, successfully deployed commercial
>> projects in banking, networking, telecommunications,
>> health care etc.
>
>
I think you're missing Meyers point. It is happening in Java now,
but no one has any experience with it over time, and most projects
using it are just starting up. Ie: Eiffel is proven, Java is not, although
it may be.
Meyers point (IMHO :-) is why use something that we have little
experience with, and that has serious shortcomings when there are
proven alternatives? (I noticed that you did not try to refute his
criticisms of Java.)
--Lars M.
_______________________________________________________________________________
http://www.ifi.uio.no/~larsga/ http://birk105.studby.uio.no/
Mark Bernstein
In article <862714...@dejanews.com>, Bertran...@eiffel.com
critized Java's lack of multiple inheritance:
> - No multiple inheritance. (The marketing spin here is
> quite smart: trying to convince people that multiple
> inheritance is "bad", a contention for which not a single
> piece of concrete evidence has ever been published, whereas
> anyone who has practiced O-O development knows how important
> it is to be able to combine separate abstractions.)
Perceptive readers will not Meyer applies a double standard -- concrete
evidence is demanded on the one hand, but the competitive belief can be
defended by anecdotal or insubstantial grounds (anyone knows).
Anyone familiar with the research literature knows that the advantages and
disadvantages of multiple inheritance have been widely discussed, and that
multiple inheritance continues to have both supporters and opponents.
Anyone familiar with the research literature on programming languages and
programmer behavior knows that concrete empirical evidence is exceedingly
hard to come by.
Procedural note: doesn't this belong in advocacy>
Jeffrey W. Stulin
D’arcy has many valid points on particular implementation issues.
In my opinion, however, it is important to focus on this key issue:
Eiffel, to the limit of practicality, implements the lessons learned
from software engineering. Java, despite many practical benefits, does
not. And that, considering Java’s utility, is a great shame.
P.S.
I have no financial stake in either language.
Jeffrey W. Stulin
j...@tiac.net
In article <336C1DC9...@itools.symantec.com>,
d...@itools.symantec.com says...
>
>This is a multi-part message in MIME format.
>--------------F19794E9F01B09027889815D
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>Bertran...@eiffel.com wrote:
>
>> - Unproven on large projects. Applets are great, but then
>> what?
>
>Variaous parts of the JDK (javac, rmic, javadoc, etc...), HotJava,
>Java Web Server, Corel Office for Java, etc...
>
>
>> - Major performance problems (a project we know gave
>> up on Java after experiencing a tenfold performance
>> degradation compared to C++). Of course the vendors promise
>> that all will be fixed, and again the buzzwords are impressive,
>> as with "Just in Time Compiling", but buzzwords don't make
>> an application run faster.
>
>Have you tried any JIT's? I and others (not associated with Symantec)
>have seen JIT'ed code that outperforms C++ (I'll freely admit that
>it isn't common place).
>
>JIT technology is young (just over a year) in the Java world.
>
>Native code compilers can (potentialy) do better optimization
>that C/C++ compilers.
>
>
>> As one .sig found on the net (I believe from Roland Turner)
>> states: "Java: the elegant simplicity of C++ and the blazing
>> speed of Smalltalk".
>
>:-)
>
>
>> It is interesting to compare this with Eiffel:
>>
>> - Used in projects large and small for eleven years.
>
>What did people say about Eiffel in the first few years of it's
>public life? (I don't know but I'd imagine that they were not
>all taken with it...)
>
>
>> - At the basis of large, successfully deployed commercial
>> projects in banking, networking, telecommunications,
>> health care etc.
>
>This is happening in Java now.
>
>
>> - Taught successfully for many years in universities around
>> the world, because it is simple, clear and convincing.
>
>Java is being taught as a first language in some places...
>
>
>> - Used by experienced programmers as well as managers,
>> bankers, traders, engineers and specialists from widely
>> different backgrounds.
>
>And Java is not?
>
>
>> - Widely cited as the most serious O-O language around
>> (e.g. in the OMT book by Rumbaugh et al.: "Eiffel is the
>> best commercially available object-oriented language",
>> and scores of similar comments in the literature).
>
>Give it's public life compared to that of Java this is not
>hard to believe.
>
>
>> - Comes with thousands of proven reusable components, such
>> as EiffelBase, EiffelVision (portable graphics), EiffelNet
>> (client-server object communication), EiffelMath (numerical
>> computing), WEL (Windows graphics), EiffelStore (relational
>> database support), Matisse and Versant interfaces...
>
>Again given it's longer life...
>
>
>> - Backed (see http://www.eiffel.com/doc) by at least two
>> dozen books in English, Italian, French, German, Russian,
>> including in-depth descriptions of practical Eiffel
>> projects ("Object-Oriented Applications", Prentice Hall).
>> Extensive, award-winning on-line documentation at
>> http://www.eiffel.com.
>
>I wander into my bookstore... and see how many Java books?
>Now I'll agree that the Eiffel ones are problably better right
>now... but given the longer public life of Eiffel...
>
>
>> - Cheap personal versions (Windows, Linux), generous
>> university packages
>> (http://www.eiffel.com/services/university),
>> affordable token-based licensing.
>
>Free from javaSoft...
>
>
>> But the forced march to Java in 1997 is no more justified than the
>> mass conversions to C++ in 198.
Jeffrey W. Stulin
While I acknowledge the controversy on Multiple Inheritance, I do
believe most of the negatives are due to poor implementations. I think
that almost all who have used MI in Eiffel are impressed with its
usefulness and ease of use. I see no practical negatives whatsoever.
In my opinion, as the Java community starts trying to combine the
functionality of the numerous components available to them, they will
soon tire of the software kludges forced by the limits of single
inheritance and multiple interfaces.
I apologize for offering no immediate proof of this opinion. I think,
however, that the proof will show itself over the next year or two.
Jeffrey W. Stulin
In article <Bernstein-040...@bstnma-01-62.port.shore.net>,
Bern...@eastgate.com says...
>
>In article <862714...@dejanews.com>, Bertran...@eiffel.com
>critized Java's lack of multiple inheritance:
>
>> - No multiple inheritance. (The marketing spin here is
>> quite smart: trying to convince people that multiple
>> inheritance is "bad", a contention for which not a single
>> piece of concrete evidence has ever been published, whereas
>> anyone who has practiced O-O development knows how important
>> it is to be able to combine separate abstractions.)
>
Jeffrey C. Dege
On 4 May 1997 08:11:51 GMT, Lars Marius Garshol <lar...@ifi.uio.no> wrote:
>
>Meyers point (IMHO :-) is why use something that we have little
>experience with, and that has serious shortcomings when there are
>proven alternatives? (I noticed that you did not try to refute his
>criticisms of Java.)
>
The core question is _why_ do developers prefer C++ over Eiffel? And
then again, _why_ do developers prefer Java to Eiffel? Because it
is obvious that they do. And it isn't because of core language
features. There is something about Eiffel that keeps it from
being considered by many development organizations, and it hasn't
anything to do with the language and its tools.
If I were in Meyer's place, I would try to identify just what it is
about Eiffel that keeps it on the fringe, and to address those
issues. Public diatribes of the sort we've seen in this thread
don't help at all.
--
It is practically impossible to teach good programming style to students
that have had prior exposure to BASIC: as potential programmers they are
mentally mutilated beyond hope of regeneration.
-- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5
Brandon Grooters
> This is an interesting marketing approach you have, although I don't
> see what value this article has other than an attempt to sell
> eiffel.
Most of your conclusions are faulty, and your logic suspect. Not only
that, but you blatenly distort historcal facts.
Nice try...
Andrew Koenig
In article <slrn5mpdcf...@jdege.visi.com> trimthi...@jdege.visi.com_trimthis writes:
> The core question is _why_ do developers prefer C++ over Eiffel? And
> then again, _why_ do developers prefer Java to Eiffel?
Well, I was seriously considering learning Eiffel until I read
the ISE license agreement.
--
--Andrew Koenig
a...@research.att.com
http://www.research.att.com/info/ark
Allen Campbell
> Native code compilers can (potentialy) do better optimization
> that C/C++ compilers.
What native code compilers? I am very interested in obtaining a
Java native code compiler for Windows and/or SCO.
Richard Coleman
a...@research.att.com (Andrew Koenig) writes:
> > The core question is _why_ do developers prefer C++ over Eiffel? And
> > then again, _why_ do developers prefer Java to Eiffel?
Because the are either
1) Following the hype
2) Forced to use Java because their managers told them to
3) Don't know the details about the alternatives.
Don't get me wrong. I believe Java is a fine language. But I believe
Bertrand's major point was that the industry seems eager to jump on
the Java bandwagon before the technology has proven itself.
No other "engineering" discipline is so prone to fads and marketing.
Would a civil engineer use a new, but unproven buiding material that
he had just heard about on the radio. I dont' believe so. Yet the
software industry does this everyday.
My guess is that most of this will change when software houses are
forced to take more legal responsibility for the quality of their
software.
> Well, I was seriously considering learning Eiffel until I read
> the ISE license agreement.
ISE is not the only vendor for Eiffel. Also, there is a free
implementation of Eiffel available.
Richard Coleman
col...@math.gatech.edu
Matt Austern
a...@research.att.com (Andrew Koenig) writes:
> In article <slrn5mpdcf...@jdege.visi.com> trimthi...@jdege.visi.com_trimthis writes:
>
> > The core question is _why_ do developers prefer C++ over Eiffel? And
> > then again, _why_ do developers prefer Java to Eiffel?
>
> Well, I was seriously considering learning Eiffel until I read
> the ISE license agreement.
ISE isn't the only Eiffel compiler out there, though. There might
even be some freeware Eiffel compilers by now; there weren't when I
last checked, but that was a year or two ago.
I would recommend learning Eiffel: it has some interesting
capabilities, and also some interesting and rather subtle limitations.
I don't agree that Eiffel is unambiguously an improvement over C++,
particularly as far as generic programming is concerned, but it is a
very clean language in some ways.
Peter van der Linden
Lars Marius Garshol <lar...@ifi.uio.no> wrote:
>Meyers point (IMHO :-) is why use something that we have little
>experience with, and that has serious shortcomings when there are
>proven alternatives? (I noticed that you did not try to refute his
>criticisms of Java.)
Oh, if *that* was his point (as opposed to just "use my language instead")
the reasons to use Java are simple:
- what he sees as "serious shortcomings" are not viewed that way
by the rest of the world.
- the economics of the software business are totally about volume. Totally.
There are now more than 400,000 Java programmers. Sun has predicted
that by 1998 there will be more people programming in Java than for
the Windows APIs.
- the ability to "write once/run anywhere" is so compelling for ISVs,
customers, and hardware vendors that it outweighs almost other concerns.
If a language like Visual Basic offered this, people may well be using
that instead.
But Eiffel-tourists don't have to fight Java -- simply port your compiler code
generator to target the Java virtual machine, and you will have the benefit
of software portability working for you, too. Who knows, perhaps people
will then switch to Eiffel in droves.
It's a common mistake to just concentrate on one aspect of a product,
and "prove" that it is "better". People (quite rightly) make technology
decisions based on all aspects of a product: technical merit, cost,
availability, number of platforms it runs on, critical mass in the market,
and so on.
D'Arcy Smith
This is a multi-part message in MIME format.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Asymetrix has a Win32 one, we have given a demo of ours (not publicly
avaialble yet). There was a post about JTower (or something close to
that I think in one of that c.l.j newsgroups that is for Win32.
Also GCC is supposed to be in the process of getting a Java front end.
I don't think that any Java compiler right now exceeds C++ compilers
(I said potential).
..darcy
--
D'Arcy Smith
Symantec, Internet Tools
JDK 1.1 for Cafe 1.53 Prerelease 2 - ftp://itools/pub/windows/cafe/1.53/
http://cafe.symantec.com
ftp://itools.symantec.com
snews://secnews.netscape.com/netscape.symantec.visualcafe
--------------66500A947E391E89856413AF
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for D'Arcy Smith
Content-Disposition: attachment; filename="vcard.vcf"
begin:vcard
fn:D'Arcy Smith
n:Smith;D'Arcy
org:Symantec, Internet Tools
adr:City Center One;;20300 Stevens Creek Blvd;Cupertino;CA;95014;USA
email;internet:d...@itools.symantec.com
title:Sr. Software Engineer
x-mozilla-cpt:;0
x-mozilla-html:FALSE
end:vcard
--------------66500A947E391E89856413AF--
D'Arcy Smith
This is a multi-part message in MIME format.
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Jeffrey W. Stulin wrote:
> D’arcy has many valid points on particular implementation issues.
> In my opinion, however, it is important to focus on this key issue:
> Eiffel, to the limit of practicality, implements the lessons learned
> from software engineering. Java, despite many practical benefits, does
> not. And that, considering Java’s utility, is a great shame.
Java is continuing to grow... so you can safely assume that
some of the lessons learned in other languages will make it into
Java in the future. However I agree that it is a shame that some
lessons haven't made it in yet.
..darcy
--
D'Arcy Smith
Symantec, Internet Tools
JDK 1.1 for Cafe 1.53 Prerelease 2 - ftp://itools/pub/windows/cafe/1.53/
http://cafe.symantec.com
ftp://itools.symantec.com
snews://secnews.netscape.com/netscape.symantec.visualcafe
--------------2F52CDF166389E1216F2AC5C
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for D'Arcy Smith
Content-Disposition: attachment; filename="vcard.vcf"
begin:vcard
fn:D'Arcy Smith
n:Smith;D'Arcy
org:Symantec, Internet Tools
adr:City Center One;;20300 Stevens Creek Blvd;Cupertino;CA;95014;USA
email;internet:d...@itools.symantec.com
title:Sr. Software Engineer
x-mozilla-cpt:;0
x-mozilla-html:FALSE
end:vcard
--------------2F52CDF166389E1216F2AC5C--
D'Arcy Smith
This is a multi-part message in MIME format.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lars Marius Garshol wrote:
> I think you're missing Meyers point. It is happening in Java now,
> but no one has any experience with it over time, and most projects
> using it are just starting up. Ie: Eiffel is proven, Java is not, although
> it may be.
Eiffel had to start domewhere as well... other arguments could have been
made about Eiffel -vs- C or C++ -vs- C when those languages were new.
Just because something is new doesn't mean it is bad - I am glad to not
be
coding in COBOL.
> Meyers point (IMHO :-) is why use something that we have little
> experience with, and that has serious shortcomings when there are
> proven alternatives? (I noticed that you did not try to refute his
> criticisms of Java.)
No I did not try to refute them - some I could have but didn't want
to take the time - others are valid. Java is not perfect. Java may
not be the best language for what you need to implement - neither is
Eiffel in all cases. I am somewhat at a disadvantage in this since
I do not know all that much about Eiffel - so I'll keep my moth shut
for the parts that I am in doubt about.
I am sure that Eiffel has shortcomings compared to Basic - so should
you dump Eiffel and use Basic?
..darcy
--
D'Arcy Smith
Symantec, Internet Tools
JDK 1.1 for Cafe 1.53 Prerelease 2 - ftp://itools/pub/windows/cafe/1.53/
http://cafe.symantec.com
ftp://itools.symantec.com
snews://secnews.netscape.com/netscape.symantec.visualcafe
--------------4F224A43A9D447B48B9434AC
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for D'Arcy Smith
Content-Disposition: attachment; filename="vcard.vcf"
begin:vcard
fn:D'Arcy Smith
n:Smith;D'Arcy
org:Symantec, Internet Tools
adr:City Center One;;20300 Stevens Creek Blvd;Cupertino;CA;95014;USA
email;internet:d...@itools.symantec.com
title:Sr. Software Engineer
x-mozilla-cpt:;0
x-mozilla-html:FALSE
end:vcard
--------------4F224A43A9D447B48B9434AC--
Lars Marius Garshol
d...@itools.symantec.com wrote:
>
>Eiffel had to start domewhere as well... other arguments could have been
>made about Eiffel -vs- C or C++ -vs- C when those languages were new.
>Just because something is new doesn't mean it is bad - I am glad to not
>be coding in COBOL.
The original point (with which I wholeheartedly agree) is that the tendency
now is that _all_ new projects are to use Java, which very likely is not a
good idea.
>No I did not try to refute them - some I could have but didn't want
>to take the time - others are valid. Java is not perfect.
I didn't agree with all of them either, but I perceive most of them to be
valid. There are features in Eiffel that I really miss in Java, although I
think the history of the language could explain why it is so simple: It
wasn't meant to be a software engineering language from the outset.
>Java may
>not be the best language for what you need to implement - neither is
>Eiffel in all cases.
Very true, and that was the point :-) There are a lot of things for which
Java is great, but it isn't the right thing for every project.S
Nils Myklebust
This is an extremely important issue.
Java is advertised and hyped so heavily very many will jump on the
bandwagon for that reason alone. Others will jump on for the money to
be made, and not care about the quality.
As technical people we should discuss the issues of the quality of the
tools we are using, and do as much as possible to avoide beeing
trapped by politics and advertising and be stuck with less than we
could have had.
I know of only two languages, that are commersially available and more
or less extensively used, that it's proponents claim are substantially
better as languages than anything else. These are Eiffel and Lisp.
The Java community claim it's better than C++, but that's hardly and
achievment, but do not compare it much to other alternatives. They do
however say there are other advantages to Java than the language
alone, and are of course right in this.
Some people who like Smalltalk, Objective-C and other alternatives say
their language is better, but non have presented arguments of a power
similar to the Eiffel and Lisp communities.
From the little I know of Eiffel it seems prety clear that it's a much
better language than Java - as a language.
From the even less I know about Lisp this also seems like a major
stride forward in language technology, but that is an evaluation
mostly based on what I hear from other people whose judgement I trust
to some extent.
Please don't come up with arguments against Lisp based on you
perceiving it as an "AI" language only, or because you *feal* it has
an arcane syntax.
Both these languages are "old", but still going strong. Strange that
the concepts developed didn't make it into Java.
It seems to me very sad indeed that the Java designers didn't do a
better job of creating the language itself. It's clear it has some
serious deficiensies. If they are realy serious, and we have to live
with them for another 10 to 20 years it would be extremely sad.
Now the interesting part is: Is Java good enough? In case it is not,
can it be fixed.
The Eiffel people are proposing a "fix" in that they will create a
compiler that will output Java byte code. That's interesting in some
cases.
Would it however be possible to extend the Java language with things
like intelligently implemented multiple inheritance without breaking
Java? I have seen no serious doubt from anyone that multiple
inheritance is extremely usefull when implemented correctly, the
discussions in different language communities notwithstanding.
What about generic classes?
Assertions?
Overriding with changed signatures?
The other issues mentioned by Bertrand Meyer? And how important are
these? (I can live with somewhat arcane syntax, although I will
eternaly dislike the Java designers for including it.)
The Lisp community have several other complaints, which they claim are
more serious. They also say they can't compile efficiently to Java
byte code due to some features lacking in it that they need for
efficient implementation.
Any comments would be appreciated.
The complaint about inadequate tools and performance problems are
mostly non issues. The tools bussiness is actually one good reason for
using Java. So much is beeing invested in tools it would be to
incredible if we will not have a lot of good alternatives reasonably
soon. As to performance in many cases the current performance is no
problem, and some companies have allready shown technology to compile
Java to native code with the execution speed of C. One of the Eiffel
compiler companies seems to be hard at work on this also.
Comments from Bertrand Meyer on Lisp would be particularly
interesting.
Bertran...@eiffel.com wrote:
:--
Nils.My...@idg.no
NM Data AS, P.O.Box 9090 Gronland, N-0133 Oslo, Norway
My opinions are those of my company
Nils Myklebust
You are right, Peter, in your evaluations of why Java is so
interesting, and why one would want to use it.
However I am quite sure Meyers point isn't only to sell Eiffel. I
don't even think that was an important part. His Eiffel part had to be
there to show how Eiffel is a better alternative in some interesting
aspects.
The interesting parts are the shortcomings of Java the language. His
idea of a second historic mistake may be a little strong, but it's
still both interesting and important to discuss the problems in the
language itself. They are there, and they will limit developers.
Java isn't as bad as C++, but if it could have been made much better
it would have been a good thing. If it can be fixed or even partly
fixed that's even better, and interesting to discuss.
If someone can show me Java is bad enough that it will hurt me, and my
abilities to create the products I intend to creat I will lissen.
pv...@best.com (Peter van der Linden) wrote:
:Lars Marius Garshol <lar...@ifi.uio.no> wrote:
:>Meyers point (IMHO :-) is why use something that we have little
:>experience with, and that has serious shortcomings when there are
:>proven alternatives? (I noticed that you did not try to refute his
:>criticisms of Java.)
:
:Oh, if *that* was his point (as opposed to just "use my language instead")
:the reasons to use Java are simple:
:
: - what he sees as "serious shortcomings" are not viewed that way
: by the rest of the world.
They sure are, several of them at least. The part of the world that
know what they are talking about generally agree on these. Those who
don't aren't interesting.
: - the economics of the software business are totally about volume. Totally.
: There are now more than 400,000 Java programmers. Sun has predicted
: that by 1998 there will be more people programming in Java than for
: the Windows APIs.
:
: - the ability to "write once/run anywhere" is so compelling for ISVs,
: customers, and hardware vendors that it outweighs almost other concerns.
: If a language like Visual Basic offered this, people may well be using
: that instead.
:
:But Eiffel-tourists don't have to fight Java -- simply port your compiler code
:generator to target the Java virtual machine, and you will have the benefit
:of software portability working for you, too. Who knows, perhaps people
:will then switch to Eiffel in droves.
:
:It's a common mistake to just concentrate on one aspect of a product,
:and "prove" that it is "better". People (quite rightly) make technology
:decisions based on all aspects of a product: technical merit, cost,
:availability, number of platforms it runs on, critical mass in the market,
:and so on.
Lars Marius Garshol
pv...@best.com wrote:
>
>Oh, if *that* was his point (as opposed to just "use my language instead")
>the reasons to use Java are simple:
>
> - what he sees as "serious shortcomings" are not viewed that way
> by the rest of the world.
You don't think the lack of parameterized types (in Eiffel jargon: generic
classes), assertions and multiple inheritance are serious shortcomings? Also:
how many development environments today support full JDBC, JavaBeans
and RMI? In addition to this, Meyers comments about possible troubles with
the overloading mechanism did not sound good, and although this may not
be a problem in real-world use I don't think there is sufficient experience with
the language yet to draw any conclusions.
> - the economics of the software business are totally about volume. Totally.
This is true, although I don't agree that it should be this way. This is why Basic
and Fortran still exist.
> - the ability to "write once/run anywhere" is so compelling for ISVs,
> customers, and hardware vendors that it outweighs almost other concerns.
> If a language like Visual Basic offered this, people may well be using
> that instead.
I must admit ignorance here. Is Java so much better at this than C++ and Eiffel?
And do people really consider this so important?
>But Eiffel-tourists don't have to fight Java -- simply port your compiler code
>generator to target the Java virtual machine, and you will have the benefit
>of software portability working for you, too. Who knows, perhaps people
>will then switch to Eiffel in droves.
From what I hear, this is difficult to do efficiently, as the JVM heavily favours
Java. Does anyone have any details on this? Or know how efficient Kawa
(Scheme interpreter/compiler for the JVM) is?
>People (quite rightly) make technology
>decisions based on all aspects of a product: technical merit, cost,
>availability, number of platforms it runs on, critical mass in the market,
>and so on.
Here we disagree, but I think mostly on the weighting of the different
factors. I'm not sure if there's more to be said.
If anyone wants to read about the experience of someone who has tried to
use Java in programming, go to http://www.cs.fiu.edu/~weiss/sigcse97.ps
The conclusion is positive, but not overwhelmingly so.
Bertran...@eiffel.com
----------
Unrelated to Mr. Bernstein's message, let me correct a typo in
my original post:
> > > But the forced march to Java in 1997 is no more justified than
the > > > mass conversions to C++ in 198.
The last word should have been: 1987 (i.e. ten years earlier). Sorry.
----------
Mark Bernstein wrote (elements in brackets [...] are mine):
> In article <862714...@dejanews.com>, Bertran...@eiffel.com
> critized Java's lack of multiple inheritance:
[quotation omitted]
> Perceptive readers will not[e] Meyer applies a double standard
> -- concrete evidence [of the alleged disadvantages of multiple
> inheritance] is demanded on the one hand, but the
> competitive belief [of the need for multiple inheritance]
> can be defended by anecdotal or insubstantial grounds (anyone knows).
Certainly not. I am not familiar with any published evidence
indicting multiple inheritance. I'd be glad to study such evidence
if someone can cite it. (A number of people have of
course railed against inheritance per se, multiple or not;
but this is not relevant to the present discussion, since all
languages considered support single inheritance.)
There is no lack of published *disparagement* of multiple
inheritance, but all the criticism I have seen is based on
opinions. The arguments tend in fact to be of the "anecdotal
or insubstantial" kind, as in the following quote from an
(otherwise excellent) book emphasizing Simula and Beta:
"The examples of use [of multiple inheritance]
presented in other languages strongly
indicated that it was used for code sharing, as a kind of
library facility, rather than for modeling".
From: Knudsen, Lofgren, Lehrmann Madsen and Magnusson,
"Object-oriented Environments: The Mjolner Approach",
Prentice Hall, 1994, page 94).
Note how this: (1) is based on a criticism of alleged *uses* of the
facility by *unnamed* projects; (2) assumes that uses of inheritance
for "code sharing" and as a "library facility" are bad, two unproven
allegations; and (3) does not explain why "code sharing" and "use
for libraries", if indeed they were misuses, would arise more with
multiple inheritance than with single inheritance.
Later on (same page) the authors write:
"Also, if multiple inheritance were to be added to the
language there would be many places where the meaning of
programs would have to be specified arbitrarily".
Why? How? In the absence of evidence I take this to be simply
incorrect.
Every criticism of multiple inheritance that I have seen is
of this kind - based on impressions and unproven assumptions.
In addition, such criticism seldom makes the distinction between
plain multiple inheritance (combining two separate abstractions)
and REPEATED inheritance (inheriting twice or more from the
SAME class); usually the examples invoked to suggest that
multiple inheritance is messy are examples of *repeated*
inheritance (as in Knudsen et al., page 67).
As to the need FOR multiple inheritance it has been amply
documented, among other places, in the Eiffel literature.
My own "Object-Oriented Software Construction, 2nd edition"
(see http://www.eiffel.com/doc/oosc.html) contains a 50-page
chapter on the topic, not to mention a 60-page chapter on
how to use inheritance well, single or multiple,
and dozens of examples of multiple inheritance throughout the book.
To use Mr. Bernstein's terms I feel the "concrete evidence"
is on the side of MI, and the "anecdotal or unsubstantiated"
claims on the other side.
People who claim multiple inheritance
is "bad" or "messy" or "unneeded" should explain how to
handle elegantly and effectively, without multiple inheritance,
examples such as COMPANY_PLANE (page 521 in my book),
INTEGER/REAL/DOUBLE (page 523-524), WINDOW (page 525),
TREE (page 525-526), COMPOSITE_FIGURE (pages 527-530),
etc. etc.
It is also interesting to note that the design of C++ initially
did not support multiple inheritance - with the usual justifications
that "it's too complicated" etc. - then found it necessary to add it
(although not, in my opinion at least, in the best possible way).
Surely there must have been a reason, or is this "anecdotal"
evidence?
--
Bertrand Meyer, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <Bertran...@eiffel.com>
Web page: http://www.eiffel.com
(including instructions to download Eiffel 4 for Windows)
Andrew Koenig
> The Java community claim it's better than C++, but that's hardly and
> achievment, but do not compare it much to other alternatives.
You are quite right -- claiming that Java is better than C++ is not an
achievement at all, but an opinion.
For such opinions to be anything more than noise, they must be backed up
by evidence -- preferably gathered by someone who does not have a vested
interest in any particular conclusion to be drawn from that evidence.
Ma...@mwilden.com
Mark Bernstein wrote:
>
>
> Anyone familiar with the research literature knows that the advantages and
> disadvantages of multiple inheritance have been widely discussed, and that
> multiple inheritance continues to have both supporters and opponents.
I've read reasonable arguments for why MI should not be used, but not
why it shouldn't be supported for those who do use it.
jason hummel
> Andrew Koenig wrote:
>It looks like dynamic binding is an after-thought that someone
> is trying to scab on on certain platforms, but is not available yet for
> Win32, and not a naturally-supported option. No concept of portable
> downloadable code, and it is does not appear likely to be easy the way
> it has been structured. Not a chance it will ever do the Java
> safe/portable download/bind trick without an incredible amount of
> reengineering, IMHO. It might be good for monolithic projects, but to
> me that seems to run counter to some important goals of OO which is to
> get away from monolithic stuff and reuse independant objects and
> classes.
hmmmm, some one isn't doing thier home work.
want an answer to your problem?
read the book below. Eiffel? C++? Pascal?
who cares? it's a binary spec, the ultimate
in reuse. o, and of course it's easier to implement
with C++/multiple inheritance.
--
/*----------------------------------------------------*/
kill the "++" in the reply to address.
this weeks book:
"Inside COM" by Dale Rogerson
publisher: Microsoftpress
isbn# 1-57231-349-8
why: explains the foundations of COM and how it works
in plain C++. more importantly, it doesn't use
MFC or ATL in great detail so it's just as
applicable in a unix enviroment. the last example,
tangram, use's openGL.<g>
/*----------------------------------------------------*/
Bertrand Meyer
(Answer on some points only.)
D'Arcy Smith wrote:
>
> Bertran...@eiffel.com wrote:
>
> > - Unproven on large projects. Applets are great, but then
> > what?
>
> Variaous parts of the JDK (javac, rmic, javadoc, etc...), HotJava,
> Java Web Server, Corel Office for Java, etc...
I notice these examples are all self-applied, however (Java
developments supporting Java tools).
>
> > But the forced march to Java in 1997 is no more justified than the
> > mass conversions to C++ in 198.
> ---
> ^
> |
> How old is Bjarne? :-)--------|
Sorry, should have read "1987". Maybe a result of the Year 1000 problem.
> Not to "Dis" (he he) Eeiffel but you've got a vested interest in seeing
> it do better than Java (as I have with Java).
Right, and we are both honest about it...
--
Bertrand Meyer, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <Bertran...@eiffel.com>
Web page: http://www.eiffel.com
Peter van der Linden
>I've read reasonable arguments for why MI should not be used, but not
>why it shouldn't be supported for those who do use it.
The argument against MI, operator overloading, generic types, etc. is that
the cost is incurred by everyone, not merely those who use them. The compiler
and all tools, (debuggers, linkers, etc) become more complicated and hence
expensive. Program maintenance is more expensive. Less effort is devoted
to parts of the compiler that other people might wish such as performance
and usability.
There is a high cost to these features even if no program uses them.
Ell
Bertran...@eiffel.com wrote:
: Ten years ago or so, when object technology first captured
: the industry's attention, projects moved en masse to C++.
:
: This was not the right decision. Not that everything was bad
: with C++ (then it would not have attracted so many
: people); it was simply not appropriate for serious software
: engineering.
There are many, many developers who would disagree with this, because in
fact they have done serious software engineering using C++. I do not see
how one can responsibly overlook that fact. Serious projects using C++
have been and are written about in the literature all the time.
: C++ was a transition technology, useful to make C
: developers and their managers object-aware, but not appropriate
: for the development of durable, high-quality software systems.
Apparently C++ is durable and high-quality enough to be used in an
extremely large number of serious projects.
Elliott
D'Arcy Smith
This is a multi-part message in MIME format.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lars Marius Garshol wrote:
> d...@itools.symantec.com wrote:
> >Eiffel had to start domewhere as well... other arguments could have been
> >made about Eiffel -vs- C or C++ -vs- C when those languages were new.
> >Just because something is new doesn't mean it is bad - I am glad to not
> >be coding in COBOL.
> The original point (with which I wholeheartedly agree) is that the tendency
> now is that _all_ new projects are to use Java, which very likely is not a
> good idea.
That is not the reality of the trend (at least from what I have heard).
Java is still, for the most part, just being tried out in larger
organizations. I can point out real apps that have been done in
Java as well... but that doesn't mean that other languages are not
being used.
Java cannot be adopted by larger organizations until it is somewhat
proven (I used to work for the 12th largest bank in the world so I
have some idea of what I'm talking about). Thankfully some large
companies are trying out Java for internal projects... some others
are using it for cstomer applications.
If nobody uses the language it won't get adopted, if people use the
language then they run some risk... a bit of a catch-22...
..darcy
--
D'Arcy Smith
Symantec, Internet Tools
JDK 1.1 for Cafe 1.53 Prerelease 2 - ftp://itools/pub/windows/cafe/1.53/
http://cafe.symantec.com
ftp://itools.symantec.com
snews://secnews.netscape.com/netscape.symantec.visualcafe
--------------5CA2209F9363EC7A48E537F1
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for D'Arcy Smith
Content-Disposition: attachment; filename="vcard.vcf"
begin:vcard
fn:D'Arcy Smith
n:Smith;D'Arcy
org:Symantec, Internet Tools
adr:City Center One;;20300 Stevens Creek Blvd;Cupertino;CA;95014;USA
email;internet:d...@itools.symantec.com
title:Sr. Software Engineer
x-mozilla-cpt:;0
x-mozilla-html:FALSE
end:vcard
--------------5CA2209F9363EC7A48E537F1--
Andrew Plotkin
Peter van der Linden (lin...@positive.eng.sun.com) wrote:
> Yeah, yeah, yeah. Bjarne Stroustrup is equally peeved that Java has
> pushed C++ out of the game.
I've got a nice shiny quarter which says that before Dec.31,2000, you
look into that same peevish mirror yourself, and see the unshaven face of
Java staring back at you. And some other language or "technology" or
something will be the hottest thing to come down the pike.
--Z
("Java? Yeah, that and a nice shiny quarter will buy you a cup of, of, a
cup of tea. Yeah.")
--Z
(note followups.)
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Matt Landau
In article <rc3es3c...@redwood.skiles.gatech.edu>, Richard Coleman <col...@math.gatech.edu>
<5khgc7$t2o$1...@glitnir.ifi.uio.no>
<slrn5mpdcf...@jdege.visi.com> <E9o33...@research.att.com> wrote:
>a...@research.att.com (Andrew Koenig) writes:
>> > The core question is _why_ do developers prefer C++ over Eiffel? And
>> > then again, _why_ do developers prefer Java to Eiffel?
>
>1) Following the hype
>2) Forced to use Java because their managers told them to
>3) Don't know the details about the alternatives.
4) Because they want to write applets and, for better or worse, the most
popular Web browsers support embedded Java applets, not embedded Eiffel
applets
5) Because there's a widely available free implementation of Java that runs on
a wide variety of platforms. The same cannot be said of Eiffel.
--
Matt Landau mla...@ziplink.net
Waiting for a flash of enlightenment in all this blood and thunder.
George Reese
Bertran...@eiffel.com wrote:
> One mistake is good; we as an industry can learn from it.
> Two is one too many.
Sounds like some serious sour grapes.
--
George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg
ik ben de borg
Thaddeus L. Olczyk
a...@research.att.com (Andrew Koenig) wrote:
>You are quite right -- claiming that Java is better than C++ is not an
>achievement at all, but an opinion.
One thing Java has done that C++ could never do:
There is a large community of people who pick up C++ for football
players in 13 seconds tyupe books , read them halfway and then
proclaim themselves hotshot C++ programmers . This group is
diminishing. Why? Because they are learning Java instead.
---------------------------------------------
Thaddeus L. Olczyk
Net boy, net girl
Send your impulse 'round the world
Put your message in a modem
And throw it in the Cyber Sea
Bert Bril
Mark Bernstein wrote:
>
> In article <862714...@dejanews.com>, Bertran...@eiffel.com
> critized Java's lack of multiple inheritance:
>
> > quite smart: trying to convince people that multiple
> > inheritance is "bad", a contention for which not a single
> > piece of concrete evidence has ever been published, whereas
> > anyone who has practiced O-O development knows how important
> > it is to be able to combine separate abstractions.)
>
> evidence is demanded on the one hand, but the competitive belief can be
> defended by anecdotal or insubstantial grounds (anyone knows).
I think you're right that it's a bit sub-standard - but that is so
easily done when you're building an argument like this. And, I don't
think it's as bad as you say. 'Concrete evindence' can also come from
outside the research literature. But, I agree, anyone knows should be
replaced by something like: I have yet to find anyone who has practiced
real O-O development that did not ... Therefore, speaking from own and
other people's experience. For these people, it is obvoiously so
evident, that it need not be explained further.
>
> Anyone familiar with the research literature knows that the advantages and
> disadvantages of multiple inheritance have been widely discussed, and that
> multiple inheritance continues to have both supporters and
>
> Anyone familiar with the research literature on programming languages and
> programmer behavior knows that concrete empirical evidence is exceedingly
> hard to come by.
The key problem with your reply is the 'research literature' part.
Research literature almost always considers making a software system as
only a theoretical problem: How do we convert a specification into an
implementation. In that case, indeed it may be "easy" to avoid multiple
inheritance.
This is only a part of what happens when real systems are built. That is
why I think Mr Meyer doesn't refer to the research literature: any
software engineer 'knows' (yes, no proof of any sort given here) that
the literature does not help a lot when e.g. changing requirements
become an important factor.
Without proof I do adhere to Mr Meyer that real OO projects of any
significant size cannot do without multiple inheritance. If this feature
is (willingly?) omitted sub-optimal solutions in terms of flexibility,
robustness, etc. will be present.
A fact which is often ignored by the opponents of multiple inheritance
is that any good software engineer will avoid it when there is a good
alternative. But although there may always be an alternative
(theoretically), for an alternative solution being good depends on all
the factors that count in the specific context of the problem.
Thus, we multiple-inheritancers also try to avoid it. But not if it is a
superior solution. And Mr Meyer exactly states why: 'to be able to
combine separate abstractions'. If you can't see the importance of being
able to do this (without having to use tricks to get the same effect)
then, well, you take your pick.
Bert Bril
-- de Groot - Bril Earth Sciences B.V.
-- Boulevard 1945 - 24, 7511 AE Enschede, The Netherlands
-- mailto:be...@dgb.nl , http://www.dgb.nl
-- Tel: +31 534315155 , Fax: +31 534315104
D'Arcy Smith
This is a multi-part message in MIME format.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tyler Baker wrote:
> (1) JAVA does not have a lot of barely relevant features that rarely
> help you out in application development like in C++. Multiple
> inheritance falls into this category as MI makes projects over time
> completely non-portable as say one parent class changes for a particular
> class, then the implementation of handling all of the other inherited
> parent classes may need to change in the descended class. However, with
> interfaces, you do not need to worry about this and it significantly
> decreases the amount of time and money spent on application development
> in the first place.
Don't be to quick to take the Java line of less is more.
There are problems that things that are missing in Java.
(And yes I'm on the Java "Bandwagon" someehat - been here for over
2 years starting with Alpha 3).
> (2) Grunt JAVA programmers, now far and few, will soon be the real meat
> of the programming industry and will demand far less salary as the
> learning curve on JAVA and its API's is much faster than C, C++, or
> Eiffel.
I'm hoping that you don't think this is a good thing.
I think that you wrong with this opinion.
> As far as Eiffel is concerned, if Eiffel was so great, then in its 11
> years everyone would be using it. I have seen Eiffel, and I find it to
> be highly unsuitable for the average programmer.
As Java has shown - C/C++ syntax is a good thing to have...
> More does not equal better. I would agree Eiffel has more irrelevant
> features than JAVA which serve no concrete useful role for application
> development, but this is not necessarily better. Remember JAVA was
> designed to be small, efficient, portable, and secure. Most other
> programming languages have the unfortunate characterstic of being large
> and feature specific with no concept of security at all built into the
> language.
Well I suppose I'm somewhat of an acidemic... but some big things were
left out of Java (inner classes being one that was just added)... this
needs to be addressed.
> One reason for C's popularity is its
> simple design and its straightforward syntax; even for a language that
> is over 20 years old. Intelligently for JAVA, unlike that of Eiffel,
> SUN adopted the straightforward syntax of C.
That is the first time I've heard of C being non-cryptic :-)
Ever soo COBOL... (no I don't like it but...). And yes I like
C/C++ syntax.
> What needs to be fixed are the implementations of the language (geese
> JAVA is slightly more than 2 years old) but not the language itself.
> Adding more crap to it would destroy the main purposes of JAVA as a
> language in the first place.
Oak was started in '90. Oak became Java. Java is basicaly 6/7 years
old.
> I have seen stuff like this for a variety of programming languages and
> they are mostly intended for legacy code conversion to work with JAVA.
> Trying to write a new application in Eiffel that runs on a JAVA VM is a
> bad idea. It is better to just learn JAVA (only took me a few weeks)
> and do it in JAVA in the first place.
No it is a good idea. Java (as a language) is not ment to solve all
of the worlds problems - if people are more productive in Eiffel and
they want to run on the JVM then that is fine by me.
Is the Lucent effort of having Java output Dis bytecodes a bad idea too?
> > What about generic classes?
>
> Well there is some argument for having this in JAVA, but at the VM and
> compiler level, there are many reasons why not having generic classes
> may be good idea.
Name them.
> > Assertions?
>
> Ever heard of try, catch, exception handling in JAVA and exception
> handling in general?
Different idea...
> Well one thing I don't think will ever happen is JAVA surpassing the
> speed of C. It may surpass the speed of C++ for certain routines, but
> never C.
Not having to worry so much about pointers the compiler can potentialy
do
better optimizations... since C is a lot of pointer manipulations it
may be possible.
I'd suggest that you step back and take a look around you.
Smalltalk has been around for "ever" and Java didn't take as much
of Smalltalk as one would hope (as well as from other languages).
Just because a feature is not used by 90% of the people doesn't make
it a bad feature - and were it not for acidemics you woudn't get a
lot of new stuff...
..darcy
--
D'Arcy Smith
Symantec, Internet Tools
JDK 1.1 for Cafe 1.53 Prerelease 2 - ftp://itools/pub/windows/cafe/1.53/
http://cafe.symantec.com
ftp://itools.symantec.com
snews://secnews.netscape.com/netscape.symantec.visualcafe
--------------BE08F82EB32C75AE78B30978
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for D'Arcy Smith
Content-Disposition: attachment; filename="vcard.vcf"
begin:vcard
fn:D'Arcy Smith
n:Smith;D'Arcy
org:Symantec, Internet Tools
adr:City Center One;;20300 Stevens Creek Blvd;Cupertino;CA;95014;USA
email;internet:d...@itools.symantec.com
title:Sr. Software Engineer
x-mozilla-cpt:;0
x-mozilla-html:FALSE
end:vcard
--------------BE08F82EB32C75AE78B30978--
Tyler Baker
Nils Myklebust wrote:
>
> This is an extremely important issue.
> Java is advertised and hyped so heavily very many will jump on the
> bandwagon for that reason alone. Others will jump on for the money to
> be made, and not care about the quality.
Well yes I have been on the JAVA bandwagon for over 2 years (and yes I
struggled through just about every bug in the AWT of 1.0.2 myself like
everyone else), and started coding about a month after 1.0 was released
and have since been coding in it professionally as well as for fun ever
since. And what I develop are not cheesy web applets as I find those
applications of JAVA to be the lowest common denominator of programming
in JAVA itself.
My main reason for coding in JAVA for real applications is pretty
simple: it is the best all-around programming language with real
industry support out there. In other words, JAVA is not just a fad that
will come and go. JAVA will be here to stay for at least 10 years. Yes
coding in C is faster than JAVA as it is pure and simple and has had
over 20 years of study put into it. I know C very well, and now I hate
it (at least for application development). But with optimized chips
coming out to directly process JAVA bytecodes, many of the performance
problems of JAVA should be significantly reduced.
> As technical people we should discuss the issues of the quality of the
> tools we are using, and do as much as possible to avoide beeing
> trapped by politics and advertising and be stuck with less than we
> could have had.
>
Well believe it or not, and besides the fact that JAVA is a great
overall application development language, JAVA is also great to the
business community. Why? Well here are some of them:
(1) JAVA does not have a lot of barely relevant features that rarely
help you out in application development like in C++. Multiple
inheritance falls into this category as MI makes projects over time
completely non-portable as say one parent class changes for a particular
class, then the implementation of handling all of the other inherited
parent classes may need to change in the descended class. However, with
interfaces, you do not need to worry about this and it significantly
decreases the amount of time and money spent on application development
in the first place.
(2) Grunt JAVA programmers, now far and few, will soon be the real meat
of the programming industry and will demand far less salary as the
learning curve on JAVA and its API's is much faster than C, C++, or
Eiffel. I spent two weeks learning Eiffel and found it to be so
annoying with its syntax that I gave up on it. Especially, since I
could not get a real compiler for it. I spent two weeks with JAVA and
managed to get a simple spreadsheet up and running. But then again, I
was only interested in Eiffel cause someone told me it was a cool
programming language. Well with Eiffel I found otherwise.
(3) Having a programming language that is extremely complex and only
serves the needs of the academic elite does 99% of the programming world
no good at all. JAVA is easy enough to learn that I know 13 year olds
who can program in it already (not very well but at least they could get
Hello World to compile). Eiffel, on the other hand I found so obtuse as
a language that I could not believe it has actually lasted 11 years (as
was said on that German company's web site that writes the compiler for
it). If Eiffel is so great, then I must say that those marketing Eiffel
really suck at marketing and it must be that 400,000 JAVA programmers
have not yet been enlightened to Eiffel even though it has had 11 years
to do so.
> I know of only two languages, that are commersially available and more
> or less extensively used, that it's proponents claim are substantially
> better as languages than anything else. These are Eiffel and Lisp.
Lisp? Are you crazy. Lisp has no practical use for application
development at all. It is strictly an academic research language for
studies on such topics as Artificial Intelligence and statistics.
As far as Eiffel is concerned, if Eiffel was so great, then in its 11
years everyone would be using it. I have seen Eiffel, and I find it to
be highly unsuitable for the average programmer.
> The Java community claim it's better than C++, but that's hardly and
> achievment, but do not compare it much to other alternatives. They do
> however say there are other advantages to Java than the language
> alone, and are of course right in this.
JAVA is the best all around programming language right now as it is
generally portable (yah the current implementations of the AWT is why I
do not say JAVA is completely portable), easy to learn, soundly
designed, and addresses the all around language concerns in an efficient
manner. I mean, if SUN wanted to put in operator overloading, or
multiple inheritance, then they could of done that easily, but then JAVA
would be nothing more than just another programming language as
portability and ease of use would be shot out the door.
> Some people who like Smalltalk, Objective-C and other alternatives say
> their language is better, but non have presented arguments of a power
> similar to the Eiffel and Lisp communities.
Eiffel and LISP again mostly reside in the academic communities and are
not taken seriously for commericial purposes, cause many of their
features are there to solve computer science problems and not real world
application problems. If you are going into academia and you have
enough time, money, and brainpower to get a PhD, then learn everything
there is, otherwise you will have to pick and choose where the money is
in the future and right now it is in COBOL, C, C++, and VB, but very
soon it will be mostly JAVA for each of these 4 languages.
> From the little I know of Eiffel it seems prety clear that it's a much
> better language than Java - as a language.
More does not equal better. I would agree Eiffel has more irrelevant
features than JAVA which serve no concrete useful role for application
development, but this is not necessarily better. Remember JAVA was
designed to be small, efficient, portable, and secure. Most other
programming languages have the unfortunate characterstic of being large
and feature specific with no concept of security at all built into the
language.
> From the even less I know about Lisp this also seems like a major
> stride forward in language technology, but that is an evaluation
> mostly based on what I hear from other people whose judgement I trust
> to some extent.
Well the only significant area that I have ever seen LISP applied to is
AI models and a little for statistics and math in general. LISP is also
one of the oldest languages around that people still actually use.
> Please don't come up with arguments against Lisp based on you
> perceiving it as an "AI" language only, or because you *feal* it has
> an arcane syntax.
Well it is also 100% interpreted. Anyone ever really heard of a LISP
native code compiler?
> Both these languages are "old", but still going strong. Strange that
> the concepts developed didn't make it into Java.
Many of the concepts did make it into JAVA, but many did not make it
into JAVA cause they really serve no real useful purpose in the real
world of programming. All that these extra unnecessary "concepts" would
of done is make JAVA into just another bloated programming language that
was extremely cryptic and complex. One reason for C's popularity is its
simple design and its straightforward syntax; even for a language that
is over 20 years old. Intelligently for JAVA, unlike that of Eiffel,
SUN adopted the straightforward syntax of C.
> It seems to me very sad indeed that the Java designers didn't do a
> better job of creating the language itself. It's clear it has some
> serious deficiensies. If they are realy serious, and we have to live
> with them for another 10 to 20 years it would be extremely sad.
No the deficiency would be if SUN put in a lot of unncessary crap to
bloat the compilers and the outputed JAVA byte code that follows it.
Imagine if JAVA had to use 16 bit operation codes instead of 8 bit
operation codes to send to the VM. Think of how pathetically slow JAVA
would be if you don't like the interpreted performance of JAVA right
now.
> Now the interesting part is: Is Java good enough? In case it is not,
> can it be fixed.
What needs to be fixed are the implementations of the language (geese
JAVA is slightly more than 2 years old) but not the language itself.
Adding more crap to it would destroy the main purposes of JAVA as a
language in the first place.
> The Eiffel people are proposing a "fix" in that they will create a
> compiler that will output Java byte code. That's interesting in some
> cases.
I have seen stuff like this for a variety of programming languages and
they are mostly intended for legacy code conversion to work with JAVA.
Trying to write a new application in Eiffel that runs on a JAVA VM is a
bad idea. It is better to just learn JAVA (only took me a few weeks)
and do it in JAVA in the first place.
> Would it however be possible to extend the Java language with things
> like intelligently implemented multiple inheritance without breaking
> Java? I have seen no serious doubt from anyone that multiple
> inheritance is extremely usefull when implemented correctly, the
> discussions in different language communities notwithstanding.
Lets see "when implemented correctly". Well see that is the problem
with giving crappy programmers overly complex features. They write
code, then I have to try and use it. And when something breaks, it is
very hard to find out what the problem is. In addition, say I have
inherited two different classes written by two separate programmers
(possibly from separate companies). Well if something goes wrong in my
class I cannot go to one of them without the possibility of them giving
me the "well the problem must be the other parent class" runaround.
This is akin to calling up a software vendor for technical support and
them telling you it is a hardware problem, and then calling up a
hardware vendor and then having them tell you it is a software problem.
Most programmers that do application development do not have time for
this crap, so this is one of the many reasons why interfaces make much
more sense than with the use of multiple inheritance in the real world
of software development.
> What about generic classes?
Well there is some argument for having this in JAVA, but at the VM and
compiler level, there are many reasons why not having generic classes
may be good idea.
> Assertions?
Ever heard of try, catch, exception handling in JAVA and exception
handling in general? I found exception handling to be in Eiffel, but it
was done in such a cryptic fashion that I said: "Why bother".
Nevertheless, there are alternatives to that type of side-effect
programming if you like that style.
> Overriding with changed signatures?
Give me 10 real world examples of how this could ever be potentially
useful for the general real world application.
> The other issues mentioned by Bertrand Meyer? And how important are
> these? (I can live with somewhat arcane syntax, although I will
> eternaly dislike the Java designers for including it.)
As someone that has looked at both languages, I would say Eiffel has the
arcane syntax. JAVA's syntax is extremely straightforward and to the
point, just like C.
> The Lisp community have several other complaints, which they claim are
> more serious. They also say they can't compile efficiently to Java
> byte code due to some features lacking in it that they need for
> efficient implementation.
Well this is why the LISP community or any other language community
wishing to use the portability of JAVA bytecodes should be coding in
JAVA in the first place.
> The complaint about inadequate tools and performance problems are
> mostly non issues. The tools bussiness is actually one good reason for
> using Java. So much is beeing invested in tools it would be to
> incredible if we will not have a lot of good alternatives reasonably
> soon. As to performance in many cases the current performance is no
> problem, and some companies have allready shown technology to compile
> Java to native code with the execution speed of C. One of the Eiffel
> compiler companies seems to be hard at work on this also.
Well one thing I don't think will ever happen is JAVA surpassing the
speed of C. It may surpass the speed of C++ for certain routines, but
never C. But then again, with CPU being relatively cheap these days,
network I/O getting better, JAVA enhanced chips, better JAVA compilers,
and programmers learning how to efficiently code in JAVA, the issue of
JAVA performance for most applications will really be a non-issue pretty
soon.
Tyler
Tyler Baker
Thaddeus L. Olczyk wrote:
>
> a...@research.att.com (Andrew Koenig) wrote:
>
> >You are quite right -- claiming that Java is better than C++ is not an
> >achievement at all, but an opinion.
>
> One thing Java has done that C++ could never do:
>
> There is a large community of people who pick up C++ for football
> proclaim themselves hotshot C++ programmers . This group is
> diminishing. Why? Because they are learning Java instead.
Why could this be, because people other than pointy head intellectual
types can actually code in a language that is still powerful enough to
do something more than add 2 + 2 and spit it out to stdout?
Again this goes to the argument that many programmers fear JAVA because
most people can actually learn and code in it efficiently, rather than
spend years and years learning cryptic API's and mastering the ability
not to leave dangling pointers all over the place. This will of course
put the pointy heads on the same level as the rest of the programming
community they like to look down upon when stepping up to bat at their
performance review, or else on an interview.
But then again, you cannot just read a 13 second type book on any
programming language and be able to code outright. You need to get your
hands dirty with writing code in it first, however, you get your hands a
lot dirtier and faster with JAVA than C or C++.
Tyler
Bert Bril
Bertran...@eiffel.com wrote:
>
> --
> "Think Java. Write new applications in Java.
> Rewrite legacy apps with Java.
>
> Don't upgrade or downgrade. Sidegrade instead to
> a Java desktop device. Don't get hit with the
> PC's massively negative ROI.
>
> I don't understand why anybody would be
> programming in anything other than Java"
>
> Scott McNealy, Open Finance (a Sun publication),
> Spring 1997.
>
> Ten years ago or so, when object technology first captured
> the industry's attention, projects moved en masse to C++.
>
> This was not the right decision. Not that everything was bad
> with C++ (then it would not have attracted so many
> people); it was simply not appropriate for serious software
> engineering. C++ was a transition technology, useful to make C
> developers and their managers object-aware, but not appropriate
> for the development of durable, high-quality software systems.
> Interestingly enough, this was clear to many people; virtually
> every object-oriented expert would privately concede that C++
> was an inadequate solution - but carefully refrain from saying
> so in public, for fear of appearing to go against the tide.
I have omitted the rest of the article, which everybody should read. Mr
Meyer is absolutely right in almost all parts. Although we use C++
almost exclusively in our company, I can see from the specifications and
concrete examples that Eiffel has many advantages over C++ and Java (the
language he's really attacking here).
The popularity of these languages is probably largely due to the
marketing effort of many big companies. Another factor is 'I like what I
know': the languages look like C. Yet, why do I also like many of the
arguments by e.g. Robert Martin (e.g.
http://www.oma.com/Publications/publications.html )? I think there are
two things to be considered that Mr Meyer does not handle:
1) The fact only that C++ and Java are popular gives them an advantage.
This is a real argument. Transitions cost money and benefits must be
enough in the particular interest of a certain company. You can't expect
the community to change for a small gain in benefit (I am not suggesting
that the benefit of using Eiffel is small). How about getting skilled
programmers? Software engineers that know what can and cannot be done
with Eiffel? Thus, marketing push can influence even rational
decision-making, because other people are influenced by it.
2) I can still not believe that there is one best solution for all sorts
of software. As an example, think of the 'generic programming' paradigm
which is used in the C++ STL library. This is a new way of getting
things done that may help a substantial community of programmers. Why do
we not use it? Because our software is not helped a lot by it. Further,
it is in a way incompatible with OO programming.
A great factor of importance for us is the ability to manage memory
'manually'. Automatic memory management is great, except when you don't
want it. So, where automatic management may be great for 90% of the
people, we need at least ways to be able to do it ourselves.
Java is here and it's here to stay. For us, Java only has disadvantages
over C++ (they are all in the list of disadvantages w.r.t. Eiffel). The
advantages of Java just don't count (again - for us). The Java hype is
not good for us: the continuous growth of C++ is being stopped and I
fear that Java will 'take over' in a lot of areas.
My message is, then: It is good that at least someone puts Java on its
place, but I think we'll have to learn to live with it. My message to Mr
Meyer is: try saying more about the advantages of Eiffel, less about the
disadvantages of other languages. People just don't like to see their
precious ones attacked. And yes, they'll probably need to go through
this phase, anyway - it may cost a few years (not 10, I hope).
Lars Marius Garshol
d...@itools.symantec.com wrote:
>> As far as Eiffel is concerned, if Eiffel was so great, then in its 11
>> years everyone would be using it. I have seen Eiffel, and I find it to
>> be highly unsuitable for the average programmer.
>
>As Java has shown - C/C++ syntax is a good thing to have...
Bjarne Stroustrup, A History of C++, paper from the 2nd History of Programming
Languages conference:
"My eventual rationale for leaving things [ie: the syntax] as they were was that any
new syntax would (temporarily at least) add complexity to a known mess. Also,
even though the old style is a boon to teachers of trivia and to people wanting to
ridicule C, it is not a significant problem for C programmers. In this case, I'm not
sure if I did the right thing, though.
The agony to me and other C++ implementers, documenters and tool builders
caused by the perversities of syntax has been significant."
Here Java is a major improvement, but IMHO it still leaves a lot to be desired.
Zooko
Peter van der Linden <lin...@positive.eng.sun.com> wrote:
>>I've read reasonable arguments for why MI should not be used, but not
>>why it shouldn't be supported for those who do use it.
>
>The argument against MI, operator overloading, generic types, etc. is that
>the cost is incurred by everyone, not merely those who use them. The compiler
>and all tools, (debuggers, linkers, etc) become more complicated and hence
>expensive. Program maintenance is more expensive. Less effort is devoted
>to parts of the compiler that other people might wish such as performance
>and usability.
>
>There is a high cost to these features even if no program uses them.
To me the biggest cost is not in the tools, but in the code and
libraries that _others_ write that you have to use, debug, modify,
etc.
I've struggled with other people's ugly obscure kludges and subtle
memory-mismanagement bugs enough times to be intensely grateful
when a language _prevents_ programmers from having easy-to-abuse
features like pointer arithmetic and multiple inheritance.
Regards,
Zooko Journeyman
signatures follow
+ island Life in a chaos sea
Not speaking for DigiCash or /.
the University of Colorado / br...@colorado.edu or
---* br...@digicash.com
Lars Marius Garshol
ty...@infinet.com wrote:
>
>Nils Myklebust wrote:
>> I know of only two languages, that are commersially available and more
>> or less extensively used, that it's proponents claim are substantially
>> better as languages than anything else. These are Eiffel and Lisp.
>
>Lisp? Are you crazy. Lisp has no practical use for application
>development at all. It is strictly an academic research language for
>studies on such topics as Artificial Intelligence and statistics.
Do you know what you're talking about here? Personally, I think Lisp and
ML show the way forward for programming languages, not Eiffel or Java.
In the words of Jim Backus (inventor of FORTRAN) in 1978: "I now regard
all conventional languages (eg. the FORTRANs, the ALGOLs, their
successors and derivatives) as increasingly complex elaborations of
the style of programming dictated by the von Neumann computer. These
'von Neumann' languages create enormous, unnecessary intellectual
roadblocks in the thinking about programs [...] We have come to regard
the DO, FOR, WHILE statements and the like as powerful tools, whereas
they are in fact weak palliatives that are necessary to make the primitive
von Neumann style of programming viable at all."
I think he's right. Most languages designed after 1955 are shockingly similar
compared to the languages that preceded them. SQL, Prolog, Snobol, LISP
and Smalltalk (to some extent also Beta) are exceptions, and LISP I think is
still the best of these.
I challenge you to argue convincingly that LISP (ie: Common LISP or Scheme)
is useless for application programming, or even unsuitable.
>> Please don't come up with arguments against Lisp based on you
>> perceiving it as an "AI" language only, or because you *feal* it has
>> an arcane syntax.
>
>Well it is also 100% interpreted. Anyone ever really heard of a LISP
>native code compiler?
Interestingly, Kawa compiles Scheme into JVM bytecode. Also: LISP is
so dynamic that it is best served by an interpreter. What is the problem
with that?
>One reason for C's popularity is its
>simple design and its straightforward syntax; even for a language that
>is over 20 years old.
Straightforward syntax? :-) Other than that, I think you might be right, if you
add standardized separate compilation schemes as well as standardized
access to the OS environment.
Also: could you mention a language that has a simpler syntax and design
than LISP? The BNF web club lists a complete grammar with 7 productions.
The Java syntax listed there has 48, and as for C: "Please do not ask for
adding C or C++ BNF descriptions. C programmers don't need syntax rules,
they forge them with #define macros ;-)"
>No the deficiency would be if SUN put in a lot of unncessary crap to
>bloat the compilers and the outputed JAVA byte code that follows it.
I agree that for a language designed for use in consumer electronics
a small language would best, but now it is being used for quite different
things, and so a superset might perhaps be a good idea.
>Well this is why the LISP community or any other language community
>wishing to use the portability of JAVA bytecodes should be coding in
>JAVA in the first place.
Scheme and CLISP have been portable for a long time now, as has
Smalltalk. Also: see my reference to Kawa above.
(http://www.gamelan.com/pages/resources/tmp-resource8871.html)
--Lars M.
______________________________________________________________________________
_
http://www.ifi.uio.no/~larsga/ http://birk105.studby.uio.no/
L. Darrell Ray
In article <862781...@dejanews.com>, Bertran...@eiffel.com says:
> snip<
>Certainly not. I am not familiar with any published evidence
>indicting multiple inheritance. I'd be glad to study such evidence
>if someone can cite it. (A number of people have of
>course railed against inheritance per se, multiple or not;
>but this is not relevant to the present discussion, since all
>languages considered support single inheritance.)
>
>There is no lack of published *disparagement* of multiple
>inheritance, but all the criticism I have seen is based on
>opinions. The arguments tend in fact to be of the "anecdotal
>or insubstantial" kind, as in the following quote from an
>(otherwise excellent) book emphasizing Simula and Beta:
>
I don't remember the refereneces but I have seen studies that show it can
cause maintenance problems. Of course this does not mean it is bad just
that the trade offs *must* be considered *before* deciding to use it and
IMO this is seldom done.
morpheus
D'Arcy Smith <d...@itools.symantec.com> wrote in article
<336DC69C...@itools.symantec.com>...
> Tyler Baker wrote:
>
> > As far as Eiffel is concerned, if Eiffel was so great, then in its 11
> > years everyone would be using it. I have seen Eiffel, and I find it to
> > be highly unsuitable for the average programmer.
Please explain. *WHAT* exactly makes Eiffel unsuitable for the average
programmer? Is it reuse, correctness, the *high* quality of the literature
available for it, or something equally irrelevent? And what is an average
programmer?
>
> > More does not equal better. I would agree Eiffel has more irrelevant
> > features than JAVA which serve no concrete useful role for application
> > development, but this is not necessarily better.
Please address then genericity (in C++, templates), multiple inheritance,
Design By Contract, covariant signatures, etc. I do not think that it can
be rationally argued that these features "serve no concrete useful role".
Steve Thompson
morp...@mci2000.com
Mike Champion
Jeffrey C. Dege wrote:
>
> On 4 May 1997 08:11:51 GMT, Lars Marius Garshol <lar...@ifi.uio.no> wrote:
> >
> >Meyers point (IMHO :-) is why use something that we have little
> >experience with, and that has serious shortcomings when there are
> >proven alternatives? (I noticed that you did not try to refute his
> >criticisms of Java.)
> >
>
> is obvious that they do. And it isn't because of core language
> features. There is something about Eiffel that keeps it from
> being considered by many development organizations, and it hasn't
> anything to do with the language and its tools.
>
Off the top of my head, I'd say:
1) Ability to move incrementally from C to C++, both because C++ is
relatively easy for C programmers to learn, and because legacy C code
can be easily incorporated into a C++ application.
2) The support infrastructure. For better or worse, C was the de-facto
standard programming language in the Unix and PC worlds in the early
'90s when C++ began to hit its stride. Compiler vendors, tools
developers, book authors, etc. could relatively easily move to C++, so
they did. (Just as in the last year, they could easily move from C++ to
Java, so they did).
3) Eiffel is generally reputed to be (I don't know it, myself) a
cleaner, clearer, more elegant language than C++, has a superior
inheritance model, and has built-in garbage collection. But C++ is
"good enough" for most people, who came to C++ knowing how to work
around C's peculiarities, probably don't use multiple inheritance
anyway, and think that it is perfectly reasonable to manually manage
memory (the poor deluded fools!). Most developers (and their bosses)
would require a LOT of convincing to believe that they could REALLY get
their IMMEDIATE jobs done faster and better in Eiffel than C++. (And
this is not an industry that weights long-run considerations very
heavily).
4) Finally, there are thousands and thousands of jobs available for C++
programmers; I personally have never seen any demand whatever for an
Eiffel programmer.
Java is succeeding because it runs everywhere, is a real step up from
C++ in elegance and cleanness, has garbage collection, AND lets people
and companies (and tool vendors, and authors) leverage the intellectual
and financial investments they have in C and C++ to quickly move to
Java. Whether it is "inferior" to Eiffel in some academic sense is
almost totally irrelevant to those considering adopting it.
Piotr Teczynski
On Mon, 05 May 1997 06:29:51 -0400, Tyler Baker <ty...@infinet.com>
wrote:
>Nils Myklebust wrote:
>> I know of only two languages, that are commersially available and more
>> or less extensively used, that it's proponents claim are substantially
>> better as languages than anything else. These are Eiffel and Lisp.
>Lisp? Are you crazy. Lisp has no practical use for application
>development at all. It is strictly an academic research language for
>studies on such topics as Artificial Intelligence and statistics.
Don't you like Emacs? ;) BTW, (no flame) what about Perl?
>JAVA is the best all around programming language right now as it is
>generally portable (yah the current implementations of the AWT is why I
>do not say JAVA is completely portable), easy to learn, soundly
...wait a moment, please. Portable as a slow bytecode ``universal''
interpreters, or ``portable'' as a fast specific chip-optimized
compilers?
//Piotr
--
Piotr Teczynski
mailto:pte...@hum.amu.edu.pl
http://hum.amu.edu.pl/%7Epteczyn/
Scott Fahlman
Tyler Baker <ty...@infinet.com> writes:
> Lisp? Are you crazy. Lisp has no practical use for application
> development at all. It is strictly an academic research language for
> studies on such topics as Artificial Intelligence and statistics.
> Well it is also 100% interpreted. Anyone ever really heard of a LISP
> native code compiler?
Your ignorance of Lisp is awesome, which casts a good deal of doubt on
the rest of what you are spewing.
Lisp has had native-code compilers since the mid-1960's at least, and
some extremely competitive implementations (competitive with Fortran
and C if you don't use more expensive features not available in those
languages) since the mid-1970's.
A legitimate complaint is that Lisp carries too much of its
development environment around at runtime, compared to languages like
Dylan or Java, and the the environment is too big and monolithic.
That can be fixed, and has been in dialects and implementations, but
the big commercial Lisp vendors turned their full attention to
small-footprint delivery too late in the game. This created an
opportunity for something like Java to occupy that niche, and Java has
done so.
The unusual Lisp syntax is only a small barrier to learning, even if
you're coming from C or C++, but syntax seems to have a big effect in
how ahrd people THINK it will be to learn a new langauge, and
therefore on their willingness to take the plunge. Only after people
try to settle in to C++ do they really realize how different it is
from C, and similarly with the transition from C++ to Java.
As for "irrelevant features", all the features in Common Lisp are
there for a reason, and those reasons had their roots in real
programming of large systems, not of toy AI problems. (Even a text
editor today has a lot of what once would have been called AI.) One
can certainly argue about whether one Lisp feature or another is worth
the complexity and implementation cost it adds. There are a number of
things in Common Lisp that I would throw out or shove into libraries,
but they are not, in general, the things the Java people threw out.
It probably isn't worth discussing these trade-offs with someone who
thinks that all Lisps are interpreted, however.
The Lisp community does tend to reject your view that if powerful
programming constructs are given to average programmers, that is very
dangerous. I think we have greater faith in the ability of average
programmers to handle sharp tools. It's very important that there be
simple ways to do simple things, so that beginners don't have to jump
immediately into the deep end of the pool. But when you need
something like multiple inheritance, the gyrations you go through to
simulate it are much more bug-prone and less efficient than just using
a built-in facility.
-- Scott
===========================================================================
Scott E. Fahlman Internet: s...@cs.cmu.edu
Principal Research Scientist Phone: 412 268-2575
Department of Computer Science Fax: 412 268-5576
Carnegie Mellon University Latitude: 40:26:46 N
5000 Forbes Avenue Longitude: 79:56:55 W
Pittsburgh, PA 15213 Mood: :-)
===========================================================================
Mike Laster
Jeffrey C. Dege wrote:
> The core question is _why_ do developers prefer C++ over Eiffel? And
> then again, _why_ do developers prefer Java to Eiffel? Because it
> is obvious that they do. And it isn't because of core language
> features. There is something about Eiffel that keeps it from
> being considered by many development organizations, and it hasn't
> anything to do with the language and its tools.
My first experience with OO languages was in Eiffel, which I learned in
college. I think Eiffel is a great teaching language for OO concepts.
Now, I primarily program in Objective-C and am starting to work with
Java.
There are a couple of major Eiffel limitations I have ran into in my
experience:
1) No multithreading capability (in ISE Eiffel anyway). I primarily
write
server processes, and coding is easier (and cleaner) with the
one-thread-per-client
model.
2) No dynamic loading capability. Unlike Objective-C or Java, there is
no standard
way to add new classes to a system at runtime. This ability is required
to make
a system that is extensible by third-parties. This is similar to the
plug-in
architecture of Netscape.
Michael S. Jenkins
The argument might be a little more compelling if it were not
so obviously self-serving:
\/\/\/\/\/\/\/\/\/\/\/\/\/
>>>> Bertrand Meyer, ISE Inc. <<<<<
>>>> Bertran...@eiffel.com <<<<<
>>>> www.eiffel.com <<<<<
/\/\/\/\/\/\/\/\/\/\/\/\/\
Some of Betrands sour grapes may be due to the fact that eiffel
has never made it as a mainstream language. I'm not saying that
eiffel isn't a good language. Nor am I saying that it hasn't been
used on some very large scale projects. It's just never been the
industry language of choice. We've run the gamut from COBOL to ADA
to RPG (I,II,III) to C to C++ over the last couple of decades.
Eiffel has never been up there as a "big" language.
So seeing Java come out of the gate and immediately capture the
industry's attention is probably very grating on everybody at ISE.
Beyond that, Betrand has some good points. He also has some
bad points. It is recognized that Java is still an immature
language. It has a way to go yet before it can be considered
a truely general purpose programming language. Given that,
there are a lot of inaccuracies and conjectures in the following:
Bertran...@eiffel.com wrote:
>
> Ten years ago or so, when object technology first captured
> the industry's attention, projects moved en masse to C++.
This is not true. The majority of large projects did not take
the C++ plunge until relatively recently ( the last 3-5 years ).
A good gage of what programming language is at the forefront is
to take a look at the staffing requirements being issued by
large corporations. The most popular developers 10 years ago
were still in C, COBOL, and ADA.
> This was not the right decision. Not that everything was bad
> with C++ (then it would not have attracted so many
> people); it was simply not appropriate for serious software
> engineering.
The question would be, if eiffel was such a superior alternative,
why didn't the industry jump on *that* bandwagon?
> This is happening again with Java. Once again we have an
> approach that has some major contributions to make but is
> hyped as the solution to everything - and is not.
This statement is true. Java is a bit over-hyped. But then again
anything that has to do with "The Internet", even loosely, gets
over-hyped these days.
> ... conveniently overlooks the limitations of Java:
>
> - Unproven on large projects. Applets are great, but then
> what?
This is completely untrue. There are many large scale projects
out there using Java as the core technology. I am working on one
such project for the CBOT.
> - No multiple inheritance. (The marketing spin here is
> quite smart: trying to convince people that multiple
> inheritance is "bad", a contention for which not a single
> piece of concrete evidence has ever been published, whereas
> anyone who has practiced O-O development knows how important
> it is to be able to combine separate abstractions.)
Very good point. I have been saying from the beginning
that the Java people (JavaSoft) take any feature that
they don't want to include in the language and label it
as "BAD". This is recognized by most professionals
in the industry as simply a marketing ploy
( obviously pretty successful ).
> - No generic classes (forcing the frequent use of type casts,
> with disastrous effects on both performance and safety).
While parameterized types would be very useful in Java, there is no
real necessity to have them. I would think that you estimate of the
"disastrous effects on both performance and safety" are a bit
overstated. Type casting in Java is in fact much safer than it
ever was in C++ where you could force cast any type into another.
> - No assertions (even the modest "assert" of C++ has been
> removed). This means - let's be clear about it -
> that it is impossible to write serious reusable components
> in Java, because serious reuse requires that the components
> be specified.
Assertions, again, are useful. I really don't think you can
dininitively state that their absense makes it "impossible"
to write serious components.
> - A neutered form of overriding (redefinition): when you
> redefine a routine, you cannot change its signature.
> This severely limits the application of polymorphism
> and other fundamental O-O techniques. (If A has e.g.
> a routine `copy' that takes an argument of type A,
> representing an object to be copied, its redefinition
> in a descendant class B must take an argument of type
> B - otherwise it makes no sense. The only solution in
> a no-signature-change language again appears to be the
> use of casts, removing the benefits of type controls.)
I'm sorry, but this is just a load of cr*p! Judicious use of
overriding and overloading make the derived objects MORE useful
and safe. The ability to change the signature of overridden
methods leads to confusion in the API.
< SNIP - a bunch of comments just proving that Bertrand is
anti-C/C++ as well as anti-Java >
> - Inadequate tools and environments (as confirmed recently by
> a survey in ComputerWorld).
Developing full-time in Java, I don't find this to be true.
ComputerWorld findings not withstanding.
> - Major performance problems (a project we know gave
> up on Java after experiencing a tenfold performance
> degradation compared to C++). Of course the vendors promise
> that all will be fixed, and again the buzzwords are impressive,
> as with "Just in Time Compiling", but buzzwords don't make
> an application run faster.
JITC isn't vapor in Java. There are decent JIT's on all
of the major platforms available today.
> It is interesting to compare this with Eiffel:
>
> - Used in projects large and small for eleven years.
But not a "Language of Choice" for the industry.
> - At the basis of large, successfully deployed commercial
> projects in banking, networking, telecommunications,
> health care etc.
The same can be said for C, C++, COBOL, etc.
> - Taught successfully for many years in universities around
> the world, because it is simple, clear and convincing.
So is PASCAL. That doesn't make it more useful in real-world
projects.
> - Used by experienced programmers as well as managers,
> bankers, traders, engineers and specialists from widely
> different backgrounds.
How many bankers and traders use ANY programming language?
> - The only approach that covers the entire lifecycle,
> from analysis to design, implementation and maintenance
> (no need for complex diagramming mechanisms
> such as UML). Avoids the split personality of many
> projects, where the analysis says one thing and the
> software does another, and no one understands both.
A programming language, any programming language, is no substitute
for good project management.
< SNIP - A bunch of plugs for ISE features >
I'm sorry, but I can't take seriously such a biased viewpoint.
This forum is for people who already advocate Java, or are at
least interested in Java as a technical solution. Anti-Java/
Pro-Eiffel propaganda should be kept in the comp.lang.eiffel
groups.
The first and last mistake has always been to listen to those
with vested interests touting an "unbiased" viewpoint.
--
Michael S. Jenkins |
Jenkins Consulting Services, Inc. | So long, and thanks
mailto:mjen...@jcs-inc.com | for all the fish!
http://www.wwa.com/~mjenkins |
Tyler Baker
D'Arcy Smith wrote:
>
> Don't be to quick to take the Java line of less is more.
> There are problems that things that are missing in Java.
> (And yes I'm on the Java "Bandwagon" someehat - been here for over
> 2 years starting with Alpha 3).
>
Well I agree there are many annoying things about JAVA (take for example
the peer classes) as it stands right now, but if SUN continues to keep
adding new things that require new op codes, then JAVA will be about as
portable as boulder from Stonehenge and the whole "Write once run
anywhere" slogan will be moot. I mean anyone who has tried running JDK
1.0.2 applets/applications under the JDK 1.1 realizes that much of their
hard work has gone to waste as they have to change the entire event
handling structure of their applets/applications among other things.
Before, the event handling was strictly object oriented and you wrote
your code as such. Now the event handling is listener based, and the
structure of your code has to follow the model, view, controller
paradigm that I believe was initially developed for SmallTalk.
> > (2) Grunt JAVA programmers, now far and few, will soon be the real meat
> > of the programming industry and will demand far less salary as the
> > learning curve on JAVA and its API's is much faster than C, C++, or
> > Eiffel.
>
> I'm hoping that you don't think this is a good thing.
> I think that you wrong with this opinion.
>
Not a good thing for JAVA developers, but very good for general software
companies except for the "write once run anywhere" idea which will put a
lot of programmers (and companies) out of work. But for society as a
whole, this is a much more efficient way of doing things. But if there
continue to be major "upgrades" to JAVA, this efficiency will never be
realized. For a lot of people I hate to admit, JAVA is not your friend
but your biggest nightmare.
> > More does not equal better. I would agree Eiffel has more irrelevant
> > features than JAVA which serve no concrete useful role for application
> > development, but this is not necessarily better. Remember JAVA was
> > designed to be small, efficient, portable, and secure. Most other
> > programming languages have the unfortunate characterstic of being large
> > and feature specific with no concept of security at all built into the
> > language.
>
> Well I suppose I'm somewhat of an acidemic... but some big things were
> left out of Java (inner classes being one that was just added)... this
> needs to be addressed.
Well I think I did not clarify too well what I meant by LISP and Eiffel
being used in academic arenas. Academia generally is concerned with
science and new ideas, many of which are very complex, require much
specialty of expertise, and are not profit oriented. This is of course
100% essential as "new ideas" are not necessarily profitable or socially
acceptable and only in the academic arena will these ideas by tested as
a commercial setting generally requires some sort of profit. This is
one reason why Nobel prize winners are usually found in Universities and
not in companies. If Jim Gosling and Bill Joy were still professors at
CMU, and developed JAVA there, I highly doubt JAVA would have 1/10th the
popularity it does now.
> > One reason for C's popularity is its
> > simple design and its straightforward syntax; even for a language that
> > is over 20 years old. Intelligently for JAVA, unlike that of Eiffel,
> > SUN adopted the straightforward syntax of C.
>
> That is the first time I've heard of C being non-cryptic :-)
> Ever soo COBOL... (no I don't like it but...). And yes I like
> C/C++ syntax.
Well I will agree that the ANSI standard C functions are cryptic, but
the language itself I find simple. Either way it is simply a matter of
memorization.
> > What needs to be fixed are the implementations of the language (geese
> > JAVA is slightly more than 2 years old) but not the language itself.
> > Adding more crap to it would destroy the main purposes of JAVA as a
> > language in the first place.
>
> Oak was started in '90. Oak became Java. Java is basicaly 6/7 years
> old.
>
Well saying Oak is what JAVA is now, is like saying Windows NT 1.0 is
what Windows NT 5.0 will be. A ton has actually been accomplished since
SUN got serious in making JAVA a network aware programming language.
> > I have seen stuff like this for a variety of programming languages and
> > they are mostly intended for legacy code conversion to work with JAVA.
> > Trying to write a new application in Eiffel that runs on a JAVA VM is a
> > bad idea. It is better to just learn JAVA (only took me a few weeks)
> > and do it in JAVA in the first place.
>
> No it is a good idea. Java (as a language) is not ment to solve all
> of the worlds problems - if people are more productive in Eiffel and
> they want to run on the JVM then that is fine by me.
>
Well that is not what I was saying. Any language could conceivably spit
out JAVA bytecodes from its compiler, however you would have to negate
many of the features (crippling yourself) from that language in order to
achieve these goals.
> Is the Lucent effort of having Java output Dis bytecodes a bad idea too?
>
Well not bad, but I highly doubt it will be profitable in the long run
to Lucent. But it is their money to spend, so I need not say more.
> > > What about generic classes?
> >
> > Well there is some argument for having this in JAVA, but at the VM and
> > compiler level, there are many reasons why not having generic classes
> > may be good idea.
>
> Name them.
>
Well for example, JAVA has eight primitives as well as the classes Array
and Object. If you have all sorts of other special generic templates,
then the JVM would no longer have the luxury of dealing with one Object,
but would instead have to worry about multiple Object types.
Nevertheless, I did not say having generic classes would be bad, just
that it might be bad
> > > Assertions?
> >
> > Ever heard of try, catch, exception handling in JAVA and exception
> > handling in general?
>
> Different idea...
>
I guess I was not specific enough in saying that they are not the same,
but the same effects can be produced by using a different style of
coding. Assertions (never really choose to use them though) are very
important in C++ as the C++ compiler is not as rigourous as the JAVA
compiler and bounds checking must be done at run-time with assertions,
rather than with try, catch clauses.
> > Well one thing I don't think will ever happen is JAVA surpassing the
> > speed of C. It may surpass the speed of C++ for certain routines, but
> > never C.
>
> Not having to worry so much about pointers the compiler can potentialy
> do
> better optimizations... since C is a lot of pointer manipulations it
> may be possible.
>
Well you may be right, but only time will tell.
> I'd suggest that you step back and take a look around you.
> Smalltalk has been around for "ever" and Java didn't take as much
> of Smalltalk as one would hope (as well as from other languages).
> Just because a feature is not used by 90% of the people doesn't make
> it a bad feature - and were it not for acidemics you woudn't get a
> lot of new stuff...
>
> ..darcy
Well I acknowledge that. Much of Java's credit can be owed to
SmallTalk. In fact much of JAVA I would say is more like SmallTalk than
C++, syntax aside. Also, I was not saying that academics are bad, yet I
feel most are highly overpaid and college costs are way too high for
most people. This aside, I was only arguing that JAVA is an application
development language. I really don't see JAVA being great for research,
writing a DBMS, or even an OS.
Tyler
Michael S. Jenkins
> >inheritance, but all the criticism I have seen is based on
> >opinions. The arguments tend in fact to be of the "anecdotal
> >or insubstantial" kind, as in the following quote from an
> >(otherwise excellent) book emphasizing Simula and Beta:
> >
>
> I don't remember the refereneces but I have seen studies that show it can
> cause maintenance problems. Of course this does not mean it is bad just
> that the trade offs *must* be considered *before* deciding to use it and
> IMO this is seldom done.
Generally maintenence problems are not a product of the programming
language used. They are a product of the programmers who wrote
and/or are trying to maintain the design and the code. If you are
suffering from maintenence headaches, the first thing to re-examine
is the people involved with the project. A competent development
team will choose the right language to implement the design.
Michael Malak
In article <336DB6...@infinet.com>, Tyler Baker <ty...@infinet.com> wrote:
>And what I develop are not cheesy web applets as I find those
>applications of JAVA to be the lowest common denominator of programming
>in JAVA itself.
Eiffel's claimed strengths shine in projects involving teams of
programmers. I haven't used Eiffel, but I can appreciate its
claimed advantages because it addresses problems I have encountered
working on medium to large C++ applications.
Have you had an opportunity to use Java in a team environment?
>My main reason for coding in JAVA for real applications is pretty
>simple: it is the best all-around programming language with real
>industry support out there.
"All-around" would mean good for teams, too. Your sentence which I
quoted above says "I develop". It would be erroneous to extrapolate
experiences in solo development to team development.
In particular:
>> What about generic classes?
>
>Well there is some argument for having this in JAVA, but at the VM and
>compiler level, there are many reasons why not having generic classes
>may be good idea.
Generic classes are necessary for adhering to a strong static-typing
system. Strong static typing can detect bugs at compile time (when
bugs are cheaper to fix). Bugs which would violate static typing
often come about from misunderstandings between team members.
>> Assertions?
>
>Ever heard of try, catch, exception handling in JAVA and exception
>handling in general? I found exception handling to be in Eiffel, but it
>was done in such a cryptic fashion that I said: "Why bother".
>Nevertheless, there are alternatives to that type of side-effect
>programming if you like that style.
The reason to "bother" is, again, to account for misunderstandings
between team members. A solo programmer can barely keep straight
in his mind the intricacies of a program. It is difficult to
communicate these intricacies throughout a team. Eiffel's "Design
By Contract," from what I have read of it, seems to superbly address
this issue. DBC's preconditions, postconditions, and invariants
are automatically checked, with no need to remember to litter code
manually with a multitude of assertions.
HOWEVER, the market reality is that, at least in the PC world in
which I work, Eiffel will never be adopted because it is not
being pushed by Microsoft.
--
Michael Malak Magic forwarding e-mail address:
Washington, DC ma...@acm.org
Bryan Althaus
Bert Bril (be...@dgb.nl) wrote:
: Bertran...@eiffel.com wrote:
:
<snip>
: > Ten years ago or so, when object technology first captured
: > the industry's attention, projects moved en masse to C++.
: >
: > with C++ (then it would not have attracted so many
: > people); it was simply not appropriate for serious software
: > developers and their managers object-aware, but not appropriate
: > for the development of durable, high-quality software systems.
: > Interestingly enough, this was clear to many people; virtually
: > every object-oriented expert would privately concede that C++
: > was an inadequate solution - but carefully refrain from saying
: > so in public, for fear of appearing to go against the tide.
:
: I have omitted the rest of the article, which everybody should read. Mr
: Meyer is absolutely right in almost all parts. Although we use C++
: almost exclusively in our company, I can see from the specifications and
: concrete examples that Eiffel has many advantages over C++ and Java (the
: language he's really attacking here).
That's because he's already attacked C++ to death. Years ago I heard
Stroustrup stopped going to OOPSLA(?) because of the Mr. Meyer's and
his Eiffel cult. C++ was attacked with the MI arguement by Mr. Meyer's
and was proabably a major factor in this feature being added to C++
before templates and exception handling. Something Mr. Stroustrup
wrote he later regretted. I know I wish templates and exceptions had
been added first and MI second.
In any case, it's annoying for someone like myself who had to sit
through the first attacks in comp.lang.c++, to find myself again
having to read this stuff again, now only in comp.lang.java.
If the Eiffel people would only respect others rights to choose their
own computer language, and stay out other comp.lang groups, I know alot
of people would be much better off.
And last, after 4 years with C++, and 7 with C before, Java peaked my
interest not for money (one can make more doing PowerBuilder), or the
language itself, it's the fact it's an environment in which the language
gives me API's. JDBC for RDBMS access, and soon (thankfully) JFC for
doing GUI, all platform independent.
I'm not dropping C++. It's still a good tool. But Java is the right tool
for alot of things. If your case is not one of them, don't use it. The
same for any language.
Ray Whitmer
Andrew Koenig wrote:
> In article <slrn5mpdcf...@jdege.visi.com>
> trimthi...@jdege.visi.com_trimthis writes:
>
> > The core question is _why_ do developers prefer C++ over Eiffel?
> And
> > then again, _why_ do developers prefer Java to Eiffel?
>
> Well, I was seriously considering learning Eiffel until I read
> the ISE license agreement.
That was always the number one killer for me.
And the worst problem for me with C++ was the lack of dynamic binding.
Guess what? Eiffel seems to lack it, too. Apparently the goal of an
Eiffel program is to become a "C" source at the end of the development
cycle. It looks like dynamic binding is an after-thought that someone
is trying to scab on on certain platforms, but is not available yet for
Win32, and not a naturally-supported option. No concept of portable
downloadable code, and it is does not appear likely to be easy the way
it has been structured. Not a chance it will ever do the Java
safe/portable download/bind trick without an incredible amount of
reengineering, IMHO. It might be good for monolithic projects, but to
me that seems to run counter to some important goals of OO which is to
get away from monolithic stuff and reuse independant objects and
classes.
The language itself may have a few bright spots in the way it defines
things, but the negatives certainly seem to really outweigh the
positives. I investigated the language before Java existed, but in the
mean time forgot why I was unimpressed. And now I remember.
I am certain I may have misunderstood something on their pages, and am
certain to get flamed for it. :-). But after the recent barrage of
shallow answers given by Eiffel proponents in Java groups... while
carefully neglecting Eiffel's apparent deficiencies and Java's strengths
etc....
Ray Whitmer
Hans Rohnert
Andrew Koenig (a...@research.att.com) wrote:
: In article <336ce5bb...@gate.idg.no> Nils.My...@idg.no writes:
:
: > The Java community claim it's better than C++, but that's hardly and
: > achievment, but do not compare it much to other alternatives.
: You are quite right -- claiming that Java is better than C++ is not an
: achievement at all, but an opinion.
: For such opinions to be anything more than noise, they must be backed up
: by evidence -- preferably gathered by someone who does not have a vested
: interest in any particular conclusion to be drawn from that evidence.
Sure such a statement is rightfully criticized by Andrew. When comparing
Java and C++ we should consider the different perspectives.
C++ was developed in a C community not respecting any overhead over C.
Back in the early 80ies performance was of paramount importance. Today we
are willing to trade some performance for programmer productivity,
robustness, platform independence, etc.
So, it's a bit unfair to just say something like "C++ arrays are bad".
Rather, the design tradeoffs were different. No range checking and direct
access via memory addresses was the reasonably fast way C did it
and had to be taken as is.
Another unsafe construct: a pointer to a C++ object can be misused to
randomly offset into its memory. Java's way of spending an additional
handle data structure is more secure but also more expensive.
Again different tradeoffs.
BTW, for those interested in migrating from C++ to Java I recommend
Taligent's cookbook (www.taligent.com).
I admit that this thread (including my message) only scratches the surface.
There are many more technical and market issues involved. I am looking
forward to more insights from the C++/Java/Eiffel communities.
Question: what feature did you miss most in your Java programming ?
(note: I said "programming" in contrast to reading about the language)
Lars Marius Garshol
br...@panix.com wrote:
>
>C++ was attacked with the MI arguement by Mr. Meyer's
>and was proabably a major factor in this feature being added to C++
>before templates and exception handling.
Are you sure about this? Stroustrup writes in the C++ paper from the
HOPL2 conference that the reason was that nobody doubted that he
could do templates or exceptions efficiently, but MI was regarded as
difficult and thus seemed more of a challenge. When he heard of an
efficient solution through Stein Krogdahl (of ifi.uio.no :-) he "couldn't
resist the challenge". (He also says that this was in 1984, ie before
Eiffel was released.)
>Something Mr. Stroustrup
>wrote he later regretted. I know I wish templates and exceptions had
>been added first and MI second.
According to his paper, Dr. Stroustrup is of the same opinion. He doesn't
say why, though. What, in your opinion, would be the difference?
Andrew Koenig
> Do you know what you're talking about here? Personally, I think Lisp and
> ML show the way forward for programming languages, not Eiffel or Java.
> In the words of Jim Backus (inventor of FORTRAN) in 1978: "I now regard
> all conventional languages (eg. the FORTRANs, the ALGOLs, their
> successors and derivatives) as increasingly complex elaborations of
> the style of programming dictated by the von Neumann computer. These
> 'von Neumann' languages create enormous, unnecessary intellectual
> roadblocks in the thinking about programs [...] We have come to regard
> the DO, FOR, WHILE statements and the like as powerful tools, whereas
> they are in fact weak palliatives that are necessary to make the primitive
> von Neumann style of programming viable at all."
Thank you for identifying your personal opinion as an opinion.
I also enjoy programming in ML, but I think that most of the ML advocates
I have met underestimate how hard it is to get people interested in
using it for practical projects. Some people, for example, lose interest
as soon as they find that (-1) is not a valid expression in ML (because
ML doesn't allow the same symbol to be overloaded as a unary and binary
operator, it uses ~ for unary negation instead of -). Unfortunately,
such little syntactic details matter more than I wish they would.
Think about how long it took Dijkstra to talk people out of using goto
statements. It has been more than 29 years since his `Goto considered
harmful' letter first appeared. More radical changes in programming style
are even harder.
--
--Andrew Koenig
a...@research.att.com
http://www.research.att.com/info/ark
Robert C. Martin
Tyler Baker wrote:
> Again this goes to the argument that many programmers fear JAVA because
> most people can actually learn and code in it efficiently, rather than
> spend years and years learning cryptic API's and mastering the ability
> not to leave dangling pointers all over the place. This will of course
> put the pointy heads on the same level as the rest of the programming
> community they like to look down upon when stepping up to bat at their
> performance review, or else on an interview.
This is silly. Java doesn't make it any easier for anybody. Software
is just plain hard. And no language is going to change that. In
particular,
no language will turn a mediocre programmer into an excellent
programmer.
Not Java, Not Eiffel, Not C++, Not Nothin'.
>
> But then again, you cannot just read a 13 second type book on any
> programming language and be able to code outright. You need to get your
> hands dirty with writing code in it first, however, you get your hands a
> lot dirtier and faster with JAVA than C or C++.
>
Do you really think so? I don't. I think getting your arms around
Java is a very difficult task, and not one to be taken lightly.
Oh, and by the way, you can make all the claims you want to about
dangling pointers, and then smile smugly that such things can't exist
in Java. But that doesn't mean that there aren't similar foibles in
Java.
Such as references that have not been nulled, and therefore result in
overuse of memory, and application slowdowns due to excessive garbage
collection
scans. Or unwanted GC scans in critical real-time areas.
This isn't a slam against Java; I think Java is very cool. But Java is
not THE answer. Nor is it an unqualified improvement over C++. It is
just another interesting language. Thats all.
--
Robert C. Martin | Design Consulting | Training courses offered:
Object Mentor | rma...@oma.com | Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 | C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com
"One of the great commandments of science is:
'Mistrust arguments from authority.'" -- Carl Sagan
Robert C. Martin
While I think that Dr. Meyer's views are somewhat extreme; I *do*
think he has a point. I don't agree that using Java is a "mistake";
but I do think that Java would benefit from some of the constructs
of "Design by Contract". These are powerful constructs, and powerful
ideas.
Mats Olsson
In article <336DF7...@jcs-inc.com>,
Michael S. Jenkins <mjen...@jcs-inc.com> wrote:
>Generally maintenence problems are not a product of the programming
>language used. They are a product of the programmers who wrote
>and/or are trying to maintain the design and the code. If you are
>suffering from maintenence headaches, the first thing to re-examine
>is the people involved with the project. A competent development
>team will choose the right language to implement the design.
Competent people are scarcer and cost more money than halfway decent
programmers (or incompetent ones). If a language helps and supports
"correct" programming, it will be easier for those less competent people
to do a decent job.
/Mats
Silvio Calissi
Bertran...@eiffel.com wrote in article <862714...@dejanews.com>...
>
> One mistake is good; we as an industry can learn from it.
> Two is one too many.
>
C++ is seen as a better C and one can even try OO programming. That's why
C++ is so used.
JAVA is seen as a better C++ and one can even try reusable components.
That's why JAVA is so used.
Unfortunatly, it seems that programmers do not like to spend time in
learning a new language (and the concepts it supports), they prefer when
their language is improved by small steps.
IMH, there is not a second mistake, there is only one: to improve a tool
instead of using another one.
Silvio.
Richie Bielak
Hans Rohnert wrote:
[...]
> Question: what feature did you miss most in your Java programming ?
> (note: I said "programming" in contrast to reading about the language)
>
Assertions! After programming in Eiffel for a while, I feel naked
without assertions.
I'm still not fully recovered from the shock of finding out that
the designers of Java knew about Eiffel and did not include
assertions in Java.
...richie
--
* ric...@netlabs.net - at home | Richie Bielak *
* ric...@calfp.com - at work | *
* Home page: http://www.netlabs.net/hp/richieb *
* "Fight software piracy, use free software!" (me) *
* (Remove NOSPAM from my address before replying) *
Frieder Monninger
Ray Whitmer wrote:
>
> Andrew Koenig wrote:
> And the worst problem for me with C++ was the lack of dynamic binding.
> Guess what? Eiffel seems to lack it, too. Apparently the goal of an
> Eiffel program is to become a "C" source at the end of the development
> cycle.
Why ? Our Eiffel (visual Eiffel) system produces native code - like
any C (++) compiler. (http://www.sigco.com/visual)
>It looks like dynamic binding is an after-thought that someone
> is trying to scab on on certain platforms, but is not available yet for
> Win32, and not a naturally-supported option. No concept of portable
> downloadable code, and it is does not appear likely to be easy the way
> it has been structured. Not a chance it will ever do the Java
> safe/portable download/bind trick without an incredible amount of
> reengineering, IMHO. It might be good for monolithic projects, but to
> me that seems to run counter to some important goals of OO which is to
> get away from monolithic stuff and reuse independant objects and
> classes.
What do you think about ActiveX (supported by our system) ?
Our discussion is only a (tiny) part of the elephants dance/fight
(Micro$oft against some smaller companies [Sun, Novell, IBM] seeing a
chance).
The most important thing (which was mentioned before) is that the
software business is completely taken over by the marketing
guys. Thats (fortunately !!) different in other engineering sciences -
I belive most of us would not be alife, if they had not improved in
centuries (yes, the car industry is marketing driven - but only the
cars, not the way thay are constructed. And, there are even very strong
federal regulations as far I know). Have you ever heard about recalls
of programs - and fines paid by software companies to customers whose
program crashed (as my Win95 today ;-). Whats about Boeing ???
So, Bertrand Meyer just tries to be a engineer - and he wants to
convince other software producers to follow him. Even James Martin
(another person in the same business) seconds him.
But, if the people he tries to convince don't want - even Boeing is
sometimes very difficult to convince. I just read that they are
reday to pay 100,000$ for each killed person last year - only to
avoid public discussions in the US (in fact mostly Germans were
killed). This crash was apparently an error in the documentation
of the aircraft.
But as long there are no fines and no federal offices dealing with
software, there is no real reason to produce stable and safe software.
Or, am I wrong ?
--
Frieder Monninger SIG Computer GmbH
<f...@sigco.com> D 35619 Braunfels
http://www.sigco.com + 49 6472-2096 (fax -911 031)
David L. Shang
In article <wburafm...@kaarne.cs.tut.fi> Pulkkinen Esa
<es...@kaarne.cs.tut.fi> writes:
> I think the same is happening in other languages. For example, there's
> this another new language, Transframe. As far as technical merits (in
> practice) are concerned, I think it must be one of the best languages
> available.
Thanks for mentioning Transframe, which is also derived from C. For
people who are interested, you can get the information at
http://www.transframe.com.
> But currently I can't recommend it for any purpose (except
> perhaps for studying programming languages). This is because from the
> advertisements I can only conclude that the designer(s)/implementor(s)
> of the language don't know how to implement a portable compiler, AFAIK
> there isn't a compiler available for any other platform than
> Windows. For almost any other language, there are compilers for most of
> the platforms, even free ones.
The reference compiler is still under development. It is a platform
independent compiler and it will be free on all platforms. The compiler
eventualy generates C code or TF Virtual Machine Code.
Windows-based implementation is a graphic environment for people
who are non-programmers. It is designed for the fast development
of various domain-specific applications. Transframe is used as
a script language which is dynamically loaded in source like
Pearl.
Fortunately, the implementation of the graphic environment (MagicWand)
is not heavily dependent on Mircrosoft Windows. It uses minimum features
in MS Windows. All graphic controls including buttons, menus,
scroll bars, tables, spreadsheet, forms, trees, list, frames,
tabbed books or cards, etc. are Transframe objects, not Winodws
controls. This enables implementation to be easily ported to
other graphic operating systems. In fact, the current implementation
has already included the portions for the X Window, though the first
release will be on Windows only due to our resource limit.
Transframe Techonology Corporation has plan to make MagicWand
a multi-platform enviroment with identical look and feel with a
much fancier graphic interface than the current standard
window systems. For example, a tabbed book can give a
look and feel of a real book with a flip sound and a 3D page
turn-over animation. It seemlessly combines 3D and 2D graphic
objects for best preseation and best efficiency. It supports plugins.
It supports internationalization (which is not Java's localization,
rather, an application that can be "tought" to speak one's
native language at run-time). It can read Transframe source like
HTML or VRML and create instant applications like web pages.
It also supports dynamic application development in a more
convienient way than Visual Basic, because you do not need to
separate the runing version and the design version during
development phase -- What you are designing is what you are
runing in the same time.
> I would add that the libraries provided with current implementations of
> Java are very poorly designed. You don't really want an UI library
> [awt] that handles images using streams (except for storing on the
> disk), do you?
For people who are intereted in images, MagicWand supports
tranparent/semi-tranparent and animated images which is independent
on graphic formats, e.g. you can use format like JPEG to
produce semi-tranparent objects in your animated surroundings.
> Or an UI library where all tools (widgets) have to
> derive from the same implementation base class that has functions for
> drawing ellipses, and you have to expose those functions to the user?
MagicWand graphic drawing utilities are not limited to
basic graphic like ellipses and rectangles. It offers many
special effects like motion trails, morphing, fading,
3D tranformations, etc.
> Or
> handle events with a function 'HandleEvent' that has to use a
> switch-case structure to filter through interesting events?
> [again I would point out my information about Java libraries is from
> about a year ago so it may be little out-of-date].
>
MagicWand provides various domain-specific models, including
event-driven models in which users design applications in
graphic timing charts.
David Shang
Frieder Monninger
Peter van der Linden wrote:
>
> >I've read reasonable arguments for why MI should not be used, but not
> >why it shouldn't be supported for those who do use it.
>
> The argument against MI, operator overloading, generic types, etc. is that
> the cost is incurred by everyone, not merely those who use them. The compiler
> and all tools, (debuggers, linkers, etc) become more complicated and hence
> expensive.So, we all should use binary code ;-)
> Program maintenance is more expensive. ++++++++++++++++++++++++++++++++++++++
Sorry, this sentence is just stupid. (please, no flames, but the
topic of the discussion is to important - we should not repeat
stupid marketing noise). Btw, I remember about the comment
of a Borland marketing person asked about MI in Turbopascal -
the "object version":
"MI is not necessary, but if the market needs it, we will implement
it in 14 days."
I agree, this type of MI makes maintenance more expensive. So, Peter
you may be right. But we spoke about Eiffel MI.
---
Jerome Mrozak
Matt Landau wrote:
> >> > The core question is _why_ do developers prefer C++ over Eiffel? And
> >> > then again, _why_ do developers prefer Java to Eiffel?
> >
> >Because the are either
> >1) Following the hype
> >2) Forced to use Java because their managers told them to
> >3) Don't know the details about the alternatives.
>
> 4) Because they want to write applets...
> 5) Because there's a widely available free implementation of Java that runs on
> a wide variety of platforms. The same cannot be said of Eiffel.
6) Because Java, like VB, provides _easy_ reuse of components -- so
easy, that these components are popular and even sold in CompUSA for <
$100! I vaguely quote Byte magazine here: The Visual Basic VBX
controls deliver the reusability promised so long for C++. Visual Basic
is popular because it provides this reusability and because it vastly
simplifies problems of the GUI interface.
Java is copying this simplification in two ways. First, its standard
distribution includes AWT, a simple, portable GUI. Don't worry about
Mac interface. Don't worry about Motif, Windows or <insert favorite
here>. Just use the Java GUI. It is simple to use, too! Second,
JavaBeans provides the (relatively simple) way to design and reuse
components, in the same way that VBX components can be reused.
Note that I didn't say "reusable objects", but instead "reusable
components". No, VB stuff isn't *truly* object oriented. But I get the
effects of reuse (of the vendor's component). With a multi-million
dollar industry built around VB (and soon around JavaBeans), that is
experiential proof of the concept.
7) Because I like to eat, and the new jobs are being built around the
Internet and Java. C'mon, Bertrand, how about a Internet capable
version of Eiffel?
(Note to Bill Gates: how about a Internet capable version of Microsoft
_anything_? The only downloadable thing I can embed ActiveX stuff into
right now is HTML or Java. That means I have to ftp distribute anything
from Microsoft and (gasp!) install it into the Win *registry* before
using it. To me, that is rather intimate relations with a program
before I hardly say hello :-0 ).
> Waiting for a flash of enlightenment in all this blood and thunder.
Will "show me the money" do for enlightenment?
--
Jerome Mrozak jm...@srds.com go...@super.zippo.com
Internet Consultant, Zeal Inc. http://www.zealinc.com
George Reese
Jeffrey C. Dege wrote:
>
> On 4 May 1997 08:11:51 GMT, Lars Marius Garshol <lar...@ifi.uio.no> wrote:
> >
> >Meyers point (IMHO :-) is why use something that we have little
> >experience with, and that has serious shortcomings when there are
> >proven alternatives? (I noticed that you did not try to refute his
> >criticisms of Java.)
> >
>
> The core question is _why_ do developers prefer C++ over Eiffel? And
> then again, _why_ do developers prefer Java to Eiffel? Because it
> is obvious that they do. And it isn't because of core language
> features. There is something about Eiffel that keeps it from
> being considered by many development organizations, and it hasn't
> anything to do with the language and its tools.
>
> If I were in Meyer's place, I would try to identify just what it is
> about Eiffel that keeps it on the fringe, and to address those
> issues. Public diatribes of the sort we've seen in this thread
> don't help at all.
The answer to this is the same as that of CORBA and NeXTStep: cost of
entry. If I am just hanging out with nothing to do and decide I want to
learn a new language, I have to mortgage my first born child to learn
Eiffel. Java is free. That alone accounts for a hell of a lot.
Bradley Thompson
>
> Why could this be, because people other than pointy head intellectual
> types can actually code in a language that is still powerful enough to
> do something more than add 2 + 2 and spit it out to stdout?
>
> Again this goes to the argument that many programmers fear JAVA because
> most people can actually learn and code in it efficiently, rather than
> spend years and years learning cryptic API's and mastering the ability
> not to leave dangling pointers all over the place. This will of course
> put the pointy heads on the same level as the rest of the programming
> community they like to look down upon when stepping up to bat at their
> performance review, or else on an interview.
>
> programming language and be able to code outright. You need to get your
> hands dirty with writing code in it first, however, you get your hands a
> lot dirtier and faster with JAVA than C or C++.
>
I have problems with both C++ and Java. However, for serious programmers,
C++ would be the better choice [opinion]. Java was created for several
reasons. First, Sun wanted a platform independant, secure programming
language, presumably to profit by selling JavaStations. Second, Sun felt
that C++ was too complicated and tried to simplify it. Third, Sun wanted
to ingrain itself into the internet even more than its already enviable
situation dictacting the API in a very microsoft hostile way.
This leads to several problems. First, the API is ridiculous. For anyone
who has not seen it, it is a haphazard and restrictive interface. It
does not support terminals to any reasonable extent. This could be
possible to remedy, but no one has stepped up to the challenge yet. The API
and language are too intertwined and controlled by sun for any reasonable
change to be expected. No single corporate entity should have control
over a language like that; it leads the proprieters of the standards to
sell influence and model the language for monetary gain (Macromedia has
"invested" in Java to a significant extent).
Another point people forget to mention is that C++ and Java ARE NOT
intended for the same audience. C and C++ were designed as systems
programming languages; Java is first and formost a scripting/mini-
application language. Its complete lack of memory manipulation cannot
be dealt with. It removes many features deemed "confusing", so a new
user could comprehend the language. The experienced programmers
writing systems and heavy duty application code were never expected
to use java.
And in fairness, I will now criticize C++. It would be nice if garbage
collection were introduced. Perhaps, for backwards compatibility, it
could be dealt with by an "object" keyword, for example:
object MyClass
{
private:
int a,b;
public:
int get_a();
void set_a(int n_a);
...
};
This would be the same as a similar "class" or "struct", only it would
have a reference count and be destroyed when the reference count reaches
zero.
Okay, enough ranting for me. Intelligent replies welcome.
--brad
--
_____________________________________
Bradley Thompson <bra...@ids.net>
http://www.ids.net/~bradley
Jay Martin
Scott Fahlman <s...@clyde.boltz.cs.cmu.edu> writes:
>As for "irrelevant features", all the features in Common Lisp are
>there for a reason, and those reasons had their roots in real
>programming of large systems, not of toy AI problems.
Not anal, not strongly typed, thus sucks for practical large systems.
Most Lisp advocates obviously do not have experience programming on
large systems with millions of lines of code programmed by software
dimwits.
>The Lisp community does tend to reject your view that if powerful
>programming constructs are given to average programmers, that is very
>dangerous. I think we have greater faith in the ability of average
>programmers to handle sharp tools.
Unfortunately, this religious faith is completely unjustified which is
why the Lisp community is incompetent at Software Engineering and
language design. Just another example of the "hacker priesthood"
mentality.
>===========================================================================
>Scott E. Fahlman Internet: s...@cs.cmu.edu
>Principal Research Scientist Phone: 412 268-2575
>Department of Computer Science Fax: 412 268-5576
>Carnegie Mellon University Latitude: 40:26:46 N
>5000 Forbes Avenue Longitude: 79:56:55 W
>Pittsburgh, PA 15213 Mood: :-)
>===========================================================================
Ah, a CS academic. (Heh, as a PHD student I give "understand" academics)
Cheers to Computer Science Academia for totally fucking up the software field!
Jay
Bradley Thompson
>
> (1) JAVA does not have a lot of barely relevant features that rarely
> help you out in application development like in C++. Multiple
> inheritance falls into this category as MI makes projects over time
> completely non-portable as say one parent class changes for a particular
> class, then the implementation of handling all of the other inherited
> parent classes may need to change in the descended class. However, with
> interfaces, you do not need to worry about this and it significantly
> decreases the amount of time and money spent on application development
> in the first place.
>
A set of parent classes in C++ is no more likely to change than a set
of interfaces in Java. The interfaces in java are less functional
(ie you can call the routines of a parent class but not an interface).
I do not personally use MI, but I see *no* reason not to support it
for those people who do use it.
> (2) Grunt JAVA programmers, now far and few, will soon be the real meat
> of the programming industry and will demand far less salary as the
> learning curve on JAVA and its API's is much faster than C, C++, or
> Eiffel.
Any idiot can learn a language in absolutely no time if they have
experience in another language. It took me about an hour to learn
lisp. *However*, it takes years to learn a language well. And
anyone who would be classified as a "grunt programmer" will not be
stealing any jobs from talented C++ programmers any time soon.
> (3) Having a programming language that is extremely complex and only
> serves the needs of the academic elite does 99% of the programming world
> no good at all.
Perhaps languages that serve the academic elite can also server other
well, too (i.e. lisp). However, C, which you seem to dislike a great
deal was created at Bell Labs, for *very* practical purposes.
> JAVA is easy enough to learn that I know 13 year olds
> who can program in it already (not very well but at least they could get
> Hello World to compile).
Big fucking deal. I could program in C at age 13, and do a hell of a lot
more than get "Hello, world!" to compile.
>
> JAVA is the best all around programming language right now as it is
> generally portable (yah the current implementations of the AWT is why I
> do not say JAVA is completely portable), easy to learn, soundly
> designed, and addresses the all around language concerns in an efficient
> manner. I mean, if SUN wanted to put in operator overloading, or
> multiple inheritance, then they could of done that easily, but then JAVA
> would be nothing more than just another programming language as
> portability and ease of use would be shot out the door.
>
"Best all arounf programming language" is pure drivel. No one language
is good for everything. I use C, C++, perl, lisp, and shellscripts for
different purposes. Though everyone has their preferences, no one in
their right mind can do everything with one language.
> If you are going into academia and you have
> enough time, money, and brainpower to get a PhD, then learn everything
> there is, otherwise you will have to pick and choose where the money is
> in the future and right now it is in COBOL, C, C++, and VB, but very
> soon it will be mostly JAVA for each of these 4 languages.
I'll believe it when I see it.
>
> Well the only significant area that I have ever seen LISP applied to is
> AI models and a little for statistics and math in general. LISP is also
> one of the oldest languages around that people still actually use.
>
Lisp is an excellent scripting language. Old does not neccesarily mean
bad. It was well designed, and though you don't like it, much more flexible
than any other language I have ever seen.
>
> Well it is also 100% interpreted. Anyone ever really heard of a LISP
> native code compiler?
>
No. Ever heard of a Java native code compiler?
>
> I have seen stuff like this for a variety of programming languages and
> they are mostly intended for legacy code conversion to work with JAVA.
> Trying to write a new application in Eiffel that runs on a JAVA VM is a
> bad idea. It is better to just learn JAVA (only took me a few weeks)
> and do it in JAVA in the first place.
>
Legacy code? Maybe they don't like java.
>
> Lets see "when implemented correctly". Well see that is the problem
> with giving crappy programmers overly complex features. They write
> code, then I have to try and use it. And when something breaks, it is
> very hard to find out what the problem is. In addition, say I have
> inherited two different classes written by two separate programmers
> (possibly from separate companies). Well if something goes wrong in my
> class I cannot go to one of them without the possibility of them giving
> me the "well the problem must be the other parent class" runaround.
> This is akin to calling up a software vendor for technical support and
> them telling you it is a hardware problem, and then calling up a
> hardware vendor and then having them tell you it is a software problem.
> Most programmers that do application development do not have time for
> this crap, so this is one of the many reasons why interfaces make much
> more sense than with the use of multiple inheritance in the real world
> of software development.
>
Languages should not take "crappy programmers" into account. This is
akin to choosing MSDOS over Unix because Unix has too many compilcated
features.
>
> Well one thing I don't think will ever happen is JAVA surpassing the
> speed of C. It may surpass the speed of C++ for certain routines, but
> never C.
C++ is an extension of C. It has no extra overhead. Therefore, it will
be no slower for an intelligent programmer.
Andrew Koenig
In article <336DF42F...@itsnet.com> raywh...@itsnet.com writes:
> Andrew Koenig wrote:
> > Well, I was seriously considering learning Eiffel until I read
> > the ISE license agreement.
> That was always the number one killer for me.
Incidentally, I apologize for bringing up this issue at all, because
it may or may not be relevant to anyone else. I *thought* I had mentioned
it in private email as a response to someone else's posting. When I
found I had posted it as an article instead, I cancelled it immediately,
but apparently it made it out anyway and people followed it up.
So let me just say that I am pickier about license agreements than
most people. If you are considering using Eiffel -- or any other
licensed product, for that matter -- read the legalese and make up
your own mind whether you are willing to go along with it.
Mark Allen Framness
In message <336DB8...@infinet.com> - Tyler Baker <ty...@infinet.com>
writes:
:>
:>Thaddeus L. Olczyk wrote:
:>>
:>> a...@research.att.com (Andrew Koenig) wrote:
:>>
:>> >You are quite right -- claiming that Java is better than C++ is not an
:>> >achievement at all, but an opinion.
:>>
:>>
:>> There is a large community of people who pick up C++ for football
:>> players in 13 seconds type books , read them halfway and then
:>> proclaim themselves hotshot C++ programmers . This group is
:>> diminishing. Why? Because they are learning Java instead.
:>
:>Why could this be, because people other than pointy head intellectual
:>types can actually code in a language that is still powerful enough to
:>do something more than add 2 + 2 and spit it out to stdout?
:>
:>Again this goes to the argument that many programmers fear JAVA because
:>most people can actually learn and code in it efficiently, rather than
:>spend years and years learning cryptic API's and mastering the ability
:>not to leave dangling pointers all over the place.
I was reading somewhere that many of the features of C++ were left out and/or
automated so as to make it easier to write bug free (some culprits mentioned
in particular were: multiple inheritance, operator overloading and memory
allocation and deallocation) code. The same reading (I remember now, it came
from TYJ in 21 Days by Sams Net) went on to say that research indicates that
there is 1 bug to about every 50 lines of C/C++ code. That C/C++ is a big
language for programming appliances and such (as I understand this was the
initial impetus behind JAVA) and the author just wondered about all those bugs
in the code running the appliances we use on a daily basis (his particular
example was code used in the chips running our cars).
I'm working on both JAVA and C/C++. Each have their place and will continue
to have their place in computing, though JAVA will be displacing C/C++ in more
than a few niche applications. Guess what language gives me more satisfaction
at the moment? My current level in C is mildly competent up to pointers
(forget fancy pancy things like OS/2 PM programming or OS/2 specific
programming in general) but geeze in JAVA I can make the Grateful Dead's
dancing bears dance! I'm going to code a silly little game for my homepage in
the near future, and with less than perhaps 30 hours of working on JAVA I'm
very confident that I will be able to do it.
Take Care!
postmaster@[127.0.0.1]
^^^^^^^^^^^^^^^^^^^^^^
Spam booby trap!!!
FROM: Mark Allen Framness
HOME: framness@.NO_SPAM.EMIRATES.NET.AE
^^^^^^^^
To reply delete the reply to address and delete the NO_SPAM from the above
address.
WORK: m477@NO_SPAM.ugru.uaeu.ac.ae
^^^^^^^
To reply delete the reply to address and delete the NO_SPAM from the above
address.
HTTP: http://netnet.net/~farmer/index.html
To send me e-mail use the above address and delete NOSPAM from the one in the
reply field.
All standard disclaimers apply. Anyone who says likewise is itching for a
fight!
Visit my homepage and answer the Trivial Troubles question!
/************** NOTE NOTE NOTE NOTE NOTE NOTE ***********************/
For a fee of $500.00 I will proofread your unsolicited commercial e-mail.
Mailing me commercial e-mail constitutes acceptance of the above terms.
D. Erway
>>>>> "pvdl" == Peter van der Linden <lin...@positive.eng.sun.com> writes:
pvdl> The argument against MI, operator overloading, generic types, etc. is that
pvdl> the cost is incurred by everyone, not merely those who use them. The compiler
pvdl> and all tools, (debuggers, linkers, etc) become more complicated and hence
pvdl> expensive. Program maintenance is more expensive. Less effort is devoted
pvdl> to parts of the compiler that other people might wish such as performance
pvdl> and usability.
pvdl> There is a high cost to these features even if no program uses them.
There is a high cost to a structured langauge, and to garbage collection.
There is a high cost to macro assemblers. Should we all just use a hex
translator and do our own hand assembled and linked machine code? No. The
cost would be too high.
Tool cost is insignificant compared to programmer costs. Every feature that
helps the programmer do what she or he needs to do a little better, should be
included.
The cost of getting MI right is not so great, (Eiffel, CLOS, Python, Dylan,
etc all have it "right", in the sense that it can be used fluidly without
getting bound up in disasters a la C++). The cost of *not* having it for
large projects (large enough to have a significant multi year maintenance
phase), is *huge*! All those tons of unnecessary, useless delagation methods
to maintain for all those years, through design and interface changes, etc.
The cost of getting generic types right is not so high. The cost of not
having them is large. I have to give up a lot of static (compile time), type
safety, that I could have for free if Java only had generic types. In fact,
it is my understanding that the Java designers now agree with this.
The cost of getting operator overloading right is almost insignificant. Yet,
its value for mathematical expressions with user defined types is *huge*. I
know, and I don't care, that this feature can be abused. It doesn't matter.
Without it, mathematical expressions become a horrendous mess of nested method
invocations, with even further maintenance cost. The abusers will all end up
broke and out of business anyway.
Again, I say, you are putting the cart before the horse. Tools cost are small
compared to programmer costs. Powerful tools are the most cost effective ones.
Don
Don Erway derway at ndc.com
Software Manager
NDC Systems 818-939-3847
5314 N. Irwindale Ave Fax:939-3870
Irwindale, CA, 91706
Ray Whitmer
Silvio Calissi wrote:
> IMH, there is not a second mistake, there is only one: to improve a
> tool
> instead of using another one.
And Eiffel certainly looks like it would need major improvement. Is it
just me, or is Java, for all its supposed inadequacy, the only language
to provide static typing with the flexibility of dynamic binding? I
might settle for untyped before I settled for static binding -- a hard
choice since both are essential. So when I see a language with both, I
will use it until something that is more useful comes along.
I can always use a better tool and have switched many times. Perhaps a
truly better tool might be Eiffel syntax/contracts/etc. on top of a
Java-like VM and approach to platform independance and binding. What's
taking the Eiffel proponents so long? How can something be reusable
when it is statically bound, almost like preprocessor substitutions, to
the hardware and surrounding objects?
That's what made it clear to me that C++ was inadequate from the start
for OO, not the lack of a better "lint" -- we were comparing to "C",
which was worse still. Existing "C" object models, including Windows
itself and many other home-brewed varieties, COM, etc. turned out to be
better/more dynamic, very poor and misconcieved as they were, than the
C++ wrappers people were trying to put around them. And Eiffel seems to
be no better in this regard. Offer us something more compelling, not
less.
Java is more "new" when it comes to its model than Eiffel, which appears
to be just a newer, safer syntax on C, apparently just like C++ but
safer. Java is an old-but-simplified-and-safer syntax on a new model.
Safety is nice, and can even make monoliths more maintainable. I might
consider Eiffel next time I want to build such a monolith, and we are
effectively being told by proponents of Eiffel that the proof of the
language is in the monolithic systems that have been constructed using
it. I measure my success a little differently, however, in delivering
flyweight, generically reusable, building blocks that interoperate
safely with other objects from people I have never met.
Ray Whitmer
Tyler Baker
Robert C. Martin wrote:
> This is silly. Java doesn't make it any easier for anybody. Software
> is just plain hard. And no language is going to change that. In
> particular,
> no language will turn a mediocre programmer into an excellent
> programmer.
> Not Java, Not Eiffel, Not C++, Not Nothin'.
Well yah true, but I will say that writing code in C, then C++, and now
JAVA, that for application development (despite all of the bugs in the
AWT) is a much easier task in JAVA than for C or C++. Many people will
highly disagree, but I only know from personal experience.
> > But then again, you cannot just read a 13 second type book on any
> > programming language and be able to code outright. You need to get your
> > hands dirty with writing code in it first, however, you get your hands a
> > lot dirtier and faster with JAVA than C or C++.
> >
>
> Do you really think so? I don't. I think getting your arms around
> Java is a very difficult task, and not one to be taken lightly.
Well really, I think that going from a procedural style of coding to an
OO style of coding may be confusing to a lot of people initially, but
once they make the transition you will see the positive difference.
> Oh, and by the way, you can make all the claims you want to about
> dangling pointers, and then smile smugly that such things can't exist
> in Java. But that doesn't mean that there aren't similar foibles in
> Java.
> Such as references that have not been nulled, and therefore result in
> overuse of memory, and application slowdowns due to excessive garbage
> collection
> scans. Or unwanted GC scans in critical real-time areas.
>
Well calling the garbage collector explicitly at non-critical CPU
processing intervals will solve these problems. In addition, it is my
experience that if you routinely call the garbage collector, you will
not have to worry about a major slowdown all at once as you get the
added benefit of having a smaller garbage collected heap, as well as
less Objects and JAVA primitives to deallocate memory for. But even if
a programmer does not null their references when unused (generally a
good practice) they will not have to worry about their application
crashing. One little dangling pointer in C or C++ can give you hours of
headaches of tracing your error in memory when your application gets
huge in scope. For JAVA I never need to use a debugger as a simple text
editor like PFE or Emacs coulped with javac, appletviewer, and java is
good enough for me. In fact, at this current point in time, I find this
to be a much better way of developing applications, than using an IDE as
the major ones are still buggy as well.
> This isn't a slam against Java; I think Java is very cool. But Java is
> not THE answer. Nor is it an unqualified improvement over C++. It is
> just another interesting language. Thats all.
Well eliminate the word "interesting" in your second to last sentence
and you have just quoted William Gates III. I will agree that for
certain programs, JAVA is definitely not the answer, but for all around
application development, JAVA is a godsend.
Tyler
George Reese
Michael S. Jenkins wrote:
>
> L. Darrell Ray wrote:
> >
> > In article <862781...@dejanews.com>, Bertran...@eiffel.com says:
> > > snip<
> >
> > >There is no lack of published *disparagement* of multiple
> > >inheritance, but all the criticism I have seen is based on
> > >opinions. The arguments tend in fact to be of the "anecdotal
> > >or insubstantial" kind, as in the following quote from an
> > >(otherwise excellent) book emphasizing Simula and Beta:
> > >
> >
> > I don't remember the refereneces but I have seen studies that show it can
> > cause maintenance problems. Of course this does not mean it is bad just
> > that the trade offs *must* be considered *before* deciding to use it and
> > IMO this is seldom done.
>
> language used. They are a product of the programmers who wrote
> and/or are trying to maintain the design and the code. If you are
> suffering from maintenence headaches, the first thing to re-examine
> is the people involved with the project. A competent development
> team will choose the right language to implement the design.
While the ability of your programmers affects maintainability, I
guarantee you a Perl coder of the same skill as a Java coder will
produce much less maintainable code than the Java coder.
--
George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg
ik ben de borg
George Reese
morpheus wrote:
>
> D'Arcy Smith <d...@itools.symantec.com> wrote in article
> <336DC69C...@itools.symantec.com>...
> > Tyler Baker wrote:
> >
> > > As far as Eiffel is concerned, if Eiffel was so great, then in its 11
> > > years everyone would be using it. I have seen Eiffel, and I find it to
> > > be highly unsuitable for the average programmer.
>
> Please explain. *WHAT* exactly makes Eiffel unsuitable for the average
> programmer? Is it reuse, correctness, the *high* quality of the literature
> available for it, or something equally irrelevent? And what is an average
> programmer?
$$$$$$$$$$$$$$$$$$$$
Eiffel is a snooty little elitist language :)
Seriously, the cost of entry into Eiffel programming is way too high.
People learn a language in one of two ways:
* by choice, i.e. they toy around with it for a while
* by force, i.e. they are hired to do something with it
Eiffel does not lend itself to learning by choice.
> >
> > > More does not equal better. I would agree Eiffel has more irrelevant
> > > features than JAVA which serve no concrete useful role for application
> > > development, but this is not necessarily better.
>
> Please address then genericity (in C++, templates), multiple inheritance,
> Design By Contract, covariant signatures, etc. I do not think that it can
> be rationally argued that these features "serve no concrete useful role".
The end of the world!!! The end of the world!!!
Really, some of the things you mention above are useful. Covariant
signatures is a crock of shit. But none of them, by any means, make
Java an inferior language. Several people have already gone off on some
of Eiffel's weaknesses.
Tyler Baker
Brad Appleton wrote:
> As for why Eiffel hasnt had quite the following that many would like,
> I agree wholeheartedly with Bert Bril. Although it certainly is NOT
> the ONLY reason, one reason why many havent moved so quickly to Eiffel
> is the way in which it has been presented and advocated. Whether or
Well Eiffel has had 11 years. However, when I was in the process of
learning Eiffel on my own I ran into the problem of not being able to
find a free Eiffel compiler to mess around with. Even though I was told
by a friend that this was a great programming language, I now feel
otherwise. Yes it may be good for somethings, but if it is as good as
Bertrand Meyer claims, ISE should immediately fire their marketing
department as something that is so good and has been around for 11 years
has had its time to prove itself.
> not Dr. Meyer has intended to do so deliberately, he (and others) has
> alienated many of the people he most needs to reach. A great many of
> Meyer's expositions come across as venom-barbed attacks against a
> language and/or its users (perhaps against Dr. Meyer's wishes, or
This is not just Dr. Meyer, but many of the academic elite who in
general would rather go around calling everyone else stupid and talk
amongst themselves, than listen to anyone elses ideas or problems. This
is one reason Universities suck so bad in the US, cause professors care
much more about their egotistical reputation in a scholarly quarterly
than actually teaching their students who sometimes pay $25,000 dollars
or more for them to lecture to a chalkboard and delegate all of their
other tasks to barely English proficient TA's. But as long as the
academic elite keeps getting their overly inflated paychecks, they will
be laughing all the way to the bank. Note, there are many professors
out there who sincerely care about their students getting their money's
worth out of school, but a great number of them would rather spend their
time engulfing themselves in their own adulation, than actually doing
their jobs.
> perhaps not). It is hard to endear others to your language when they
> *percieve* you to have pretty much labeled them imbeciles and
> incompetents for using another language like C++. Your technical
> arguments and conclusions may in fact be brilliant and correct, but
> the way in which you present them needs some dramatic re-work and
> serious study of how best to present information for the purpose of
> effecting a change in people's perceptions and behavior.
Well if it was possible to get a free compiler to mess with in Eiffel I
might actually give it a try for at least knowledge's sake. In fact, if
the SUN JDK was not free, I would probably still be coding in C and
C++. Good move SUN, bad move ISE as you have had 11 years to push your
products into the mainstream.
> So rather than focusing on warding people off of C++ or Java, I think
> it would be far more productive to spend time and effort trying to
> disseminate accurate information about the benefits of Eiffel WHILE
> AT THE SAME TIME taking great pains to ensure that you DO not alienate
> or offend potential users at the same time. I have seen Dr. Meyer say
Well the thing that alienated me most about Eiffel is that I could find
very little documentation on it, as well as being frustrated by not
being able to find a compiler. When I was in college with little money,
buying a several hundred dollar compiler is just not an option. Perhaps
the people the develop Eiffel need a little more marketing and a lot
less arrogance.
> that we will not "coddle the masses" for the sake of shamelessly
> peddling a language. While that is noble, there is also a difference
> between "coddling" the masses, and trying real hard to NOT "spit on the
> masses" (which is how Dr. Meyer often comes across despite his best
> intentions). Furthermore, some amount of coddling or hand-holding in
Coddling. Actually, I found Dr. Meyer's post to be an act of
desperation as there are probably many Eiffel developers switching to
JAVA as we speak. Naturally, he fears losing his job.
> necessary in the field of education. Simply lecturing is not sufficient.
> If you dont do that bare minimal amount of "coddling" to help guide
> people along and reinforce or at least maintain their self-esteem and
> self-worth (without being dishonest of course), then dont expect those
> same "masses" to embrace you or your products anytime soon.
>
Well make a free version of your dev kits and that might help.
Arrogance aside, I would still like to at least mess around with Eiffel
even though for a whole host of reasons I find JAVA much more useful and
powerful for the application development I am involved in.
Tyler
Jeffrey W. Stulin
The fact that Tyler believes C syntax to be straightforward is all we
need to know about the level of his objectivity and quality of his
arguments.
Jeffrey W. Stulin
In article <336DB6...@infinet.com>, ty...@infinet.com says...
>
>Nils Myklebust wrote:
>>
>> This is an extremely important issue.
>> Java is advertised and hyped so heavily very many will jump on the
>> bandwagon for that reason alone. Others will jump on for the money to
>> be made, and not care about the quality.
>
>Well yes I have been on the JAVA bandwagon for over 2 years (and yes I
>struggled through just about every bug in the AWT of 1.0.2 myself like
>everyone else), and started coding about a month after 1.0 was released
>and have since been coding in it professionally as well as for fun ever
>since. And what I develop are not cheesy web applets as I find those
>applications of JAVA to be the lowest common denominator of programming
>in JAVA itself.
>
>My main reason for coding in JAVA for real applications is pretty
>simple: it is the best all-around programming language with real
>industry support out there. In other words, JAVA is not just a fad
that
>will come and go. JAVA will be here to stay for at least 10 years.
Yes
>coding in C is faster than JAVA as it is pure and simple and has had
>over 20 years of study put into it. I know C very well, and now I hate
>it (at least for application development). But with optimized chips
>coming out to directly process JAVA bytecodes, many of the performance
>problems of JAVA should be significantly reduced.
>
>> As technical people we should discuss the issues of the quality of
the
>> tools we are using, and do as much as possible to avoide beeing
>> trapped by politics and advertising and be stuck with less than we
>> could have had.
>>
>
>Well believe it or not, and besides the fact that JAVA is a great
>overall application development language, JAVA is also great to the
>business community. Why? Well here are some of them:
>
>(1) JAVA does not have a lot of barely relevant features that rarely
>help you out in application development like in C++. Multiple
>inheritance falls into this category as MI makes projects over time
>completely non-portable as say one parent class changes for a
particular
>class, then the implementation of handling all of the other inherited
>parent classes may need to change in the descended class. However,
with
>interfaces, you do not need to worry about this and it significantly
>decreases the amount of time and money spent on application development
>in the first place.
>
>(2) Grunt JAVA programmers, now far and few, will soon be the real meat
>of the programming industry and will demand far less salary as the
>learning curve on JAVA and its API's is much faster than C, C++, or
>Eiffel. I spent two weeks learning Eiffel and found it to be so
>annoying with its syntax that I gave up on it. Especially, since I
>could not get a real compiler for it. I spent two weeks with JAVA and
>managed to get a simple spreadsheet up and running. But then again, I
>was only interested in Eiffel cause someone told me it was a cool
>programming language. Well with Eiffel I found otherwise.
>
>(3) Having a programming language that is extremely complex and only
>serves the needs of the academic elite does 99% of the programming
world
>no good at all. JAVA is easy enough to learn that I know 13 year olds
>who can program in it already (not very well but at least they could
get
>Hello World to compile). Eiffel, on the other hand I found so obtuse
as
>a language that I could not believe it has actually lasted 11 years (as
>was said on that German company's web site that writes the compiler for
>it). If Eiffel is so great, then I must say that those marketing
Eiffel
>really suck at marketing and it must be that 400,000 JAVA programmers
>have not yet been enlightened to Eiffel even though it has had 11 years
>to do so.
>
>> I know of only two languages, that are commersially available and
more
>> or less extensively used, that it's proponents claim are
substantially
>> better as languages than anything else. These are Eiffel and Lisp.
>
>Lisp? Are you crazy. Lisp has no practical use for application
>development at all. It is strictly an academic research language for
>studies on such topics as Artificial Intelligence and statistics.
>
>As far as Eiffel is concerned, if Eiffel was so great, then in its 11
>years everyone would be using it. I have seen Eiffel, and I find it to
>be highly unsuitable for the average programmer.
>
>> The Java community claim it's better than C++, but that's hardly and
>> achievment, but do not compare it much to other alternatives. They do
>> however say there are other advantages to Java than the language
>> alone, and are of course right in this.
>
>JAVA is the best all around programming language right now as it is
>generally portable (yah the current implementations of the AWT is why I
>do not say JAVA is completely portable), easy to learn, soundly
>designed, and addresses the all around language concerns in an
efficient
>manner. I mean, if SUN wanted to put in operator overloading, or
>multiple inheritance, then they could of done that easily, but then
JAVA
>would be nothing more than just another programming language as
>portability and ease of use would be shot out the door.
>
>> Some people who like Smalltalk, Objective-C and other alternatives
say
>> their language is better, but non have presented arguments of a power
>> similar to the Eiffel and Lisp communities.
>
>Eiffel and LISP again mostly reside in the academic communities and are
>not taken seriously for commericial purposes, cause many of their
>features are there to solve computer science problems and not real
world
>application problems. If you are going into academia and you have
>enough time, money, and brainpower to get a PhD, then learn everything
>there is, otherwise you will have to pick and choose where the money is
>in the future and right now it is in COBOL, C, C++, and VB, but very
>soon it will be mostly JAVA for each of these 4 languages.
>
>> From the little I know of Eiffel it seems prety clear that it's a
much
>> better language than Java - as a language.
>
>More does not equal better. I would agree Eiffel has more irrelevant
>features than JAVA which serve no concrete useful role for application
>development, but this is not necessarily better. Remember JAVA was
>designed to be small, efficient, portable, and secure. Most other
>programming languages have the unfortunate characterstic of being large
>and feature specific with no concept of security at all built into the
>language.
>
>> From the even less I know about Lisp this also seems like a major
>> stride forward in language technology, but that is an evaluation
>> mostly based on what I hear from other people whose judgement I trust
>> to some extent.
>
>Well the only significant area that I have ever seen LISP applied to is
>AI models and a little for statistics and math in general. LISP is
also
>one of the oldest languages around that people still actually use.
>
>> Please don't come up with arguments against Lisp based on you
>> perceiving it as an "AI" language only, or because you *feal* it has
>> an arcane syntax.
>
>Well it is also 100% interpreted. Anyone ever really heard of a LISP
>native code compiler?
>
>> Both these languages are "old", but still going strong. Strange that
>> the concepts developed didn't make it into Java.
>
>Many of the concepts did make it into JAVA, but many did not make it
>into JAVA cause they really serve no real useful purpose in the real
>world of programming. All that these extra unnecessary "concepts"
would
>of done is make JAVA into just another bloated programming language
that
>was extremely cryptic and complex. One reason for C's popularity is
its
>simple design and its straightforward syntax; even for a language that
>is over 20 years old. Intelligently for JAVA, unlike that of Eiffel,
>SUN adopted the straightforward syntax of C.
>
>> It seems to me very sad indeed that the Java designers didn't do a
>> better job of creating the language itself. It's clear it has some
>> serious deficiensies. If they are realy serious, and we have to live
>> with them for another 10 to 20 years it would be extremely sad.
>
>No the deficiency would be if SUN put in a lot of unncessary crap to
>bloat the compilers and the outputed JAVA byte code that follows it.
>Imagine if JAVA had to use 16 bit operation codes instead of 8 bit
>operation codes to send to the VM. Think of how pathetically slow JAVA
>would be if you don't like the interpreted performance of JAVA right
>now.
>
>> Now the interesting part is: Is Java good enough? In case it is not,
>> can it be fixed.
>
>What needs to be fixed are the implementations of the language (geese
>JAVA is slightly more than 2 years old) but not the language itself.
>Adding more crap to it would destroy the main purposes of JAVA as a
>language in the first place.
>
>> The Eiffel people are proposing a "fix" in that they will create a
>> compiler that will output Java byte code. That's interesting in some
>> cases.
>
>I have seen stuff like this for a variety of programming languages and
>they are mostly intended for legacy code conversion to work with JAVA.
>Trying to write a new application in Eiffel that runs on a JAVA VM is a
>bad idea. It is better to just learn JAVA (only took me a few weeks)
>and do it in JAVA in the first place.
>
>> Would it however be possible to extend the Java language with things
>> like intelligently implemented multiple inheritance without breaking
>> Java? I have seen no serious doubt from anyone that multiple
>> inheritance is extremely usefull when implemented correctly, the
>> discussions in different language communities notwithstanding.
>
>Lets see "when implemented correctly". Well see that is the problem
>with giving crappy programmers overly complex features. They write
>code, then I have to try and use it. And when something breaks, it is
>very hard to find out what the problem is. In addition, say I have
>inherited two different classes written by two separate programmers
>(possibly from separate companies). Well if something goes wrong in my
>class I cannot go to one of them without the possibility of them giving
>me the "well the problem must be the other parent class" runaround.
>This is akin to calling up a software vendor for technical support and
>them telling you it is a hardware problem, and then calling up a
>hardware vendor and then having them tell you it is a software problem.
>Most programmers that do application development do not have time for
>this crap, so this is one of the many reasons why interfaces make much
>more sense than with the use of multiple inheritance in the real world
>of software development.
>
>> What about generic classes?
>
>Well there is some argument for having this in JAVA, but at the VM and
>compiler level, there are many reasons why not having generic classes
>may be good idea.
>
>> Assertions?
>
>Ever heard of try, catch, exception handling in JAVA and exception
>handling in general? I found exception handling to be in Eiffel, but
it
>was done in such a cryptic fashion that I said: "Why bother".
>Nevertheless, there are alternatives to that type of side-effect
>programming if you like that style.
>
>> Overriding with changed signatures?
>
>Give me 10 real world examples of how this could ever be potentially
>useful for the general real world application.
>
>> The other issues mentioned by Bertrand Meyer? And how important are
>> these? (I can live with somewhat arcane syntax, although I will
>> eternaly dislike the Java designers for including it.)
>
>As someone that has looked at both languages, I would say Eiffel has
the
>arcane syntax. JAVA's syntax is extremely straightforward and to the
>point, just like C.
>
>> The Lisp community have several other complaints, which they claim
are
>> more serious. They also say they can't compile efficiently to Java
>> byte code due to some features lacking in it that they need for
>> efficient implementation.
>
>Well this is why the LISP community or any other language community
>wishing to use the portability of JAVA bytecodes should be coding in
>JAVA in the first place.
>
>> The complaint about inadequate tools and performance problems are
>> mostly non issues. The tools bussiness is actually one good reason
for
>> using Java. So much is beeing invested in tools it would be to
>> incredible if we will not have a lot of good alternatives reasonably
>> soon. As to performance in many cases the current performance is no
>> problem, and some companies have allready shown technology to compile
>> Java to native code with the execution speed of C. One of the Eiffel
>> compiler companies seems to be hard at work on this also.
>
>Well one thing I don't think will ever happen is JAVA surpassing the
>speed of C. It may surpass the speed of C++ for certain routines, but
>never C. But then again, with CPU being relatively cheap these days,
>network I/O getting better, JAVA enhanced chips, better JAVA compilers,
>and programmers learning how to efficiently code in JAVA, the issue of
>JAVA performance for most applications will really be a non-issue
pretty
>soon.
>
>Tyler
Jim Balter
Peter van der Linden wrote:
>
> pushed C++ out of the game.
Argument by ridicule is not a valid rhetorical technique.
Between you and Dr. Meyer, I don't think there is any question
which is the bigger fool.
--
<J Q B>
Bradley Thompson
>
> Are you claiming that you _want_/_need_ to directly manage remote
> system resources? The fact is, truly experienced programmers DON'T
> want to handle mundane memory/system issues. Your inexperience is
> showing!
>
I am claiming that there are times when you need to manipulate
resources directly. Not all of the time. Some of the time.
The standard C library has not caused unix vendors to drop
support of ioctl, fcntl, etc., just as Sun should not have
had to drop support of pointers. Do I want to handle mundane
issues? No. But there is no operating system/language that can
anticipate everything anyone could concievably want to do.
Nils Myklebust
ma...@dtek.chalmers.se (Mats Olsson) wrote:
:In article <336DF7...@jcs-inc.com>,
:Michael S. Jenkins <mjen...@jcs-inc.com> wrote:
:>Generally maintenence problems are not a product of the programming
:>language used. They are a product of the programmers who wrote
:>and/or are trying to maintain the design and the code. If you are
:>suffering from maintenence headaches, the first thing to re-examine
:>is the people involved with the project. A competent development
:>team will choose the right language to implement the design.
:
: Competent people are scarcer and cost more money than halfway decent
:programmers (or incompetent ones). If a language helps and supports
:"correct" programming, it will be easier for those less competent people
:to do a decent job.
This is so obviously false. A competent programmer will finish any
project both faster and at a higher quality thereby beeing cheaper in
the end than the less competent ones. There is more than 10 to 1
difference between the half decent and the competent. If you pay 5
times higher wage you will save money. Normally you might pay perhaps
3 times higher wage for the competent and save even more.
This utterly fals argument is used by many as argument against putting
in this or that feature. The incompetent will misuse it they say. So
they want to cripple the abilities of the competent for the sace of
the incompetent. What an argument.
Nils.My...@idg.no
NM Data AS, P.O.Box 9090 Gronland, N-0133 Oslo, Norway
My opinions are those of my company
Ray David Whitmer
D. Erway wrote:
> I think you missed something. Eiffel has the exact same dynamic
> reference
> semantic model as does Java. Why post misinformation and ignorance?
All I have to go on is the pages of the vendors of the language. They
made repeated reference to outputting of "C" source, which is not
typically dynamic in nature, and only a passing reference to a "dynamic
binding" project that was only available on Solaris. I spent quite a
while on several occasions combing the sources for any references to
dynamic binding and other aspects of how objects negotiated and
interacted. Perhaps you can point me to the paper that describes this
better. Also, what format do these classes occur in, etc.
> So what? You can write dynamic code using C. You just have to do
> alot of
> work. Now, the Eiffel compiler does it for you. And producing C
> source is
> arguably more portable than the JVM...
Anything is arguable, but I have done much dynamic binding in both, and
have apparently had very different experiences from yours.
> This is totally wrong. Dynamic binding is fundamental to everything
> Eiffel is
> about. There are no platform differences. What the hell are you
> talkin' about??
> :)
I can refer you to the places in their pages, and perhaps you can
explain the correct understanding better than I. But after a lot of
reading, it sounded like a glorified "C" preprocessor, not to knock it,
because I have written object models that worked that way much better
than C++, but nothing approaching what Java provides.
> The safe/portable dowload/bind trick is only useful for Applets!
> Who gives a
> damn about applets?
You have managed to compress a lot of error into that statement. I have
always written business apps, very significant ones for the last 12
years, but the Applet model is very significant, and even in apps, the
untrusted model for classes is important. Likewise, the portability of
the class is extremely important.
> If you actually understood some of the interactions of strongly
> typed OO, you
> would be impressed. Everyone very knowledgable in the field,
> (except for the
> SmallTalkers, who feel pure dynamic typing is the way to go),
> acknowledges the
> fact that Eiffel is beautiful, powerful, and has the best set of
> features to
> support the OO programming style of any language.
There are many opinions in the field of OO, all of whom think they are
knowledgeable. I believe also Lisp is considered to be OO by some, but
lacks typing as I understand it. Then, there are the Microsoft COM
crowd, who think dynamic typing is the only way to go. While I believe
all of these groups are dead wrong, they all consider themselves
foremost in the field. I have very healthy respect for good typing
having managed many extremely complex projects. It would be nice to
find an open source of info. Perhaps I did not look long enough, but
frankly, everything I saw looked bad for the language. I would be happy
to review the pages with you section by section.
> The only negatives with Eiffel is marketing - it doesn't have enough
> market
> share to produce a big enough component market, and it didn't use a
> syntax derived from C...
I still think there are far more negatives to Eiffel than the marketing,
although a few years ago perhaps that was all. Perhaps the syntax of
Java is considered a strength by some. I do not consider the syntax a
particular strength, though, although it is not too bad a liability
because it has been repaired a lot in Java.
> Well, a little. But seriously, your post was based on ignorance and
> misinformation, so you have to expect to get flames as a result.
Yes, together with the people who provide the pages where it is being
sold.
> Read some of my other posts on what I have found wrong while doing
> real work with Java.
Fine, but first you show me the pages. Where is the object model, where
is the VM, the portability, the dynamic object model, the dynamic
binding, and so on of Eiffel. I can tell you where to find the similar
specs on Java. I don't care what others think about Eiffel. Because I
haven't seen what I would call a real successful deployment of typed OO
in any language but Java. I care about how strong it is as an object
model. Plenty of people think C++ is fine, too, and I disagree with
them, too, and I didn't see enough difference in the descriptions.
Or I can take the opposite tack and quote all the pages that I found
describing Eiffel and why they seemed to describe a very ugly language.
I'd be happy to compare notes. I have done serious Java work, that
qualifies as a very large project consisting of many small objects and
sets of objects that interact very well according to well-laid-out
well-formed rules, and have already gone through a number of development
cycles. Other than the lack of a good IDE and foundation classes, I
have no complaint.
Ray Whitmer
Jim Balter
D'Arcy Smith wrote:
> I am sure that Eiffel has shortcomings compared to Basic - so should
> you dump Eiffel and use Basic?
Note what Dr. Meyer actually wrote:
======
"Think Java. Write new applications in Java.
Rewrite legacy apps with Java.
Don't upgrade or downgrade. Sidegrade instead to
a Java desktop device. Don't get hit with the
PC's massively negative ROI.
I don't understand why anybody would be
programming in anything other than Java"
Scott McNealy, Open Finance (a Sun publication),
Spring 1997.
Ten years ago or so, when object technology first captured
the industry's attention, projects moved en masse to C++.
This was not the right decision. Not that everything was bad
with C++ (then it would not have attracted so many
people); it was simply not appropriate for serious software
engineering. C++ was a transition technology, useful to make C
developers and their managers object-aware, but not appropriate
for the development of durable, high-quality software systems.
Interestingly enough, this was clear to many people; virtually
every object-oriented expert would privately concede that C++
was an inadequate solution - but carefully refrain from saying
so in public, for fear of appearing to go against the tide.
This is happening again with Java. Once again we have an
approach that has some major contributions to make but is
hyped as the solution to everything - and is not.
[...]
It is interesting to compare this with Eiffel:
[...]
Does this mean that one should drop everything else? Of course not.
As Roy Phillips noted in a recent posting to comp.lang.eiffel,
there is room and need for more than one language.
[...]
But the forced march to Java in 1997 is no more justified than the
mass conversions to C++ in 198. This time we don't have the
excuse that we don't know; and no spacecraft hides, ready to
rescue us, behind the comet.
[...]
======
Note that Dr. meyer is cautioning against Scott Nealy's bullshit.
By failing to pay attention to what he actually wrote, you and
a lot of other Java advocates are coming across like idiots that
you aren't; it looks a lot like Americans during the cold war who
would froth at the mouth about the evils of the Soviet Union whenever
anyone questioned U.S. policy; it is formally a fallacy of affirmation
of the consequent. I eagerly await some more intelligent comments that
actually pertain to the points that Dr. Meyer made, none of which
were that Nealy's "one size fits all" comments hold for some other
language such as Eiffel.
--
<J Q B>
Corey Minyard
Mike Champion <m...@arbortext.com> writes:
>
> Jeffrey C. Dege wrote:
> >
> > On 4 May 1997 08:11:51 GMT, Lars Marius Garshol <lar...@ifi.uio.no> wrote:
> > >
> > >Meyers point (IMHO :-) is why use something that we have little
> > >experience with, and that has serious shortcomings when there are
> > >proven alternatives? (I noticed that you did not try to refute his
> > >criticisms of Java.)
> > >
> >
> > The core question is _why_ do developers prefer C++ over Eiffel? And
> > then again, _why_ do developers prefer Java to Eiffel? Because it
> > is obvious that they do. And it isn't because of core language
> > features. There is something about Eiffel that keeps it from
> > being considered by many development organizations, and it hasn't
> > anything to do with the language and its tools.
> >
>
> Off the top of my head, I'd say:
>
> 1) Ability to move incrementally from C to C++, both because C++ is
> relatively easy for C programmers to learn, and because legacy C code
> can be easily incorporated into a C++ application.
I was a C programmer for 10 years before I learned C++. I found C++
arcane and difficult to understand compared to C. Ada95 was a breeze
in comparison. I have done no serious work in Eiffel, so I can't
speak to that although its use of symbols over words perhaps makes
learning it a bit more difficult. Of course, I can program in C in
C++, but I really would be using C++-- :-).
>
> 2) The support infrastructure. For better or worse, C was the de-facto
> standard programming language in the Unix and PC worlds in the early
> '90s when C++ began to hit its stride. Compiler vendors, tools
> developers, book authors, etc. could relatively easily move to C++, so
> they did. (Just as in the last year, they could easily move from C++ to
> Java, so they did).
I would think having a C compiler would not make a C++ compiler
significantly easier to build and I would not think having a C++
compiler would make a Java compiler easier to build. They are all
very different things. I look the the GNU compilers for this
observation.
>
> 3) Eiffel is generally reputed to be (I don't know it, myself) a
> cleaner, clearer, more elegant language than C++, has a superior
> inheritance model, and has built-in garbage collection. But C++ is
> "good enough" for most people, who came to C++ knowing how to work
> around C's peculiarities, probably don't use multiple inheritance
> anyway, and think that it is perfectly reasonable to manually manage
> memory (the poor deluded fools!). Most developers (and their bosses)
> would require a LOT of convincing to believe that they could REALLY get
> their IMMEDIATE jobs done faster and better in Eiffel than C++. (And
> this is not an industry that weights long-run considerations very
> heavily).
You are correct, this is not an industry that weighs long-term
considerations heavily. And look where it has gotten us. The
year-2000 problem, poor reuse, etc. How much do those types of things
cost? Maybe some will see the light.
>
> 4) Finally, there are thousands and thousands of jobs available for C++
> programmers; I personally have never seen any demand whatever for an
> Eiffel programmer.
>
> Java is succeeding because it runs everywhere, is a real step up from
> C++ in elegance and cleanness, has garbage collection, AND lets people
> and companies (and tool vendors, and authors) leverage the intellectual
> and financial investments they have in C and C++ to quickly move to
> Java. Whether it is "inferior" to Eiffel in some academic sense is
> almost totally irrelevant to those considering adopting it.
Java is succeeding because of hype. All the features you talk about
are not new. It's like people thinking Microsoft invented
multiprocessing; it's all marketing. And try to write a C or C++ to
Java translator. I think the financial investment in C and C++ is
useless for moving to Java. Sure, Java looks a little like C or C++,
but semantically it is closer to Ada and Smalltalk.
--
Corey Minyard Internet: min...@acm.org
Work: min...@nortel.ca UUCP: min...@wf-rch.cirr.com
Frieder Monninger
Frieder Monninger wrote:
> sometimes very difficult to convince. I just read that they are
> reday to pay 100,000$ for each killed person last year - only to
> avoid public discussions in the US (in fact mostly Germans were
> killed). This crash was apparently an error in the documentation
> of the aircraft.
Please accept my apologies:
.. only for the people killed at the crash at the dominicanic republic -
about 180 persons, not for each person killed in 1996.
--
D. Erway
>>>>> "nm" == Nils Myklebust <Nils.My...@idg.no> writes:
nm> This is an extremely important issue.
nm> I know of only two languages, that are commersially available and more
nm> or less extensively used, that it's proponents claim are substantially
nm> better as languages than anything else. These are Eiffel and Lisp.
With Dylan showing up this fall.
nm> From the little I know of Eiffel it seems prety clear that it's a much
nm> better language than Java - as a language.
Yes.
nm> From the even less I know about Lisp this also seems like a major
nm> stride forward in language technology, but that is an evaluation
nm> mostly based on what I hear from other people whose judgement I trust
nm> to some extent.
Yes.
We are using Java, even though, in some sense, we know better - we have
studied and experimented with Eiffel and Lisp. But we couldn't quite sell
them to management, due to lack of a large vendor community, off the shelf
components, mind share, etc. Well we could sell Java, and that is a good
thing in some ways compared to C++, but now that we are actually getting down
and dirty in the code, I have to say, we seriously miss some of the missing
bits of Java, and can already see large long term economic costs due to their
lack:
1) Parameterized Types!!! We already have a abstract superclasses that
should be able to hold most of the implementation, but can't, due to the
subclasses needing to be parameterized. (We are moving the implementation
down, rather than use dynamic casts, to maintain safety and performance.)
2) Multiple Inheritance - We already have interfaces and corresponding
implementation classes which require the actual implementing classes to
delegate all the methods of the interface to a contained implementation
object. This is already onerous, and will only become a bigger and bigger
maintenance load as time goes on.
3) User Defined Value Types - Even C's typdefs let us do this. We
want to use an abstract user defined type, and make it equivalent to float.
This lets us latter change our minds and make it double. We can't do this in
Java. And the cost of using a reference type, with an extra reference in
every single computation of the innermost inner loop is just too high. Not to
mention the intellectual cost of then being unable to do ordinary mathematical
expressions with it, (so I guess add operator overloading to the list).
4) Closures and first class methods - Yeah, I know inner classes are
supposed to be the cure. But any language where you can't easily define
abstract high level control functions, (like mapping any method to each
element of any collection), is BROKEN. I don't want to spend my life writing
while/for loops!
5) Multiple Dispatch - After working with the Common Lisp Object
System, and early versions of Dylan, I have to say, I find thinking and
designing in a single dispatch way to be extremely limiting. I now find I
want to think about abstract data types, and then about the functions I want
to do in my data flow. I would like to see a language like Eiffel that
encourages good encapsulation of abstract data types, (and simple operations)
within classes, and then let me use a dynamic, high abstraction level,
multiple dispatch style of programming at the upper levels to process
instances of these data types.
nm> Would it however be possible to extend the Java language with things
nm> like intelligently implemented multiple inheritance without breaking
nm> Java? I have seen no serious doubt from anyone that multiple
nm> inheritance is extremely usefull when implemented correctly, the
nm> discussions in different language communities notwithstanding.
Yes please!
nm> What about generic classes?
Yes please!
nm> Assertions?
Yes please!
nm> Overriding with changed signatures?
Yes please!
nm> The other issues mentioned by Bertrand Meyer? And how important are
nm> these? (I can live with somewhat arcane syntax, although I will
nm> eternaly dislike the Java designers for including it.)
I agree. Actually, (granted I have used C and now Java for many years), I
prefer C type syntax over Eiffel. I also prefer Lisp syntax over Eiffel. But
this is really of minor importance compared to the power of the langauge
semantics.
Jim Balter
Bryan Althaus wrote:
>
> Jim Balter (j...@netcom.com) wrote:
> <snip>
>
> : By failing to pay attention to what he actually wrote, you and
> : a lot of other Java advocates are coming across like idiots
>
I'm not an "Eiffel person"; I get paid to write Java.
> I just emailed
> you this when I read you calling another person a fool
I didn't call anyone a fool; you seem to have a reading comprehension
problem. Peter van de Linden posted a very ad hominem comment about
Dr. Meyer which he has since been wise enough to withdraw; in response
I said it was clear which of them is a bigger fool. Of course, neither
of them is a fool, but this point seems to subtle for you.
> and asked
> why Eiffel people always have to use words like fool, idiot, etc.
Why do you make idiotic generalizations about "Eiffel people"?
> Then I read this post and there's the word idiot.
Yep, there it is, but I didn't call anyone an idiot.
[idiotic ad hominem ranting about "the Eiffel cult" and so on snipped]
--
<J Q B>
Jim Balter
D'Arcy Smith wrote:
>
> Lars Marius Garshol wrote:
> > The original point (with which I wholeheartedly agree) is that the tendency
> > now is that _all_ new projects are to use Java, which very likely is not a
> > good idea.
>
> That is not the reality of the trend (at least from what I have heard).
But that was content of the quote from Scott Nealy that Bertrand
Meyer warned about. This discussion would be a lot higher quality
if people would actually read what was written.
--
<J Q B>
Brad Appleton
[ Note: spam-retardant email addresses used in article headers,
use the address in my signature for email replies ]
In article <336DC...@dgb.nl>, Bert Bril <be...@dgb.nl> writes:
> My message is, then: It is good that at least someone puts Java on its
> place, but I think we'll have to learn to live with it. My message to Mr
> Meyer is: try saying more about the advantages of Eiffel, less about the
> disadvantages of other languages. People just don't like to see their
> precious ones attacked. And yes, they'll probably need to go through
> this phase, anyway - it may cost a few years (not 10, I hope).
Hear! Hear!
As far as "missing features" go, Java is young and is still likely to
add new features. Some of them (like genericity) may be more likely to
be added than others. But undoubtedly some will be added, while others
will not. I personally would love to see genericity, MI, and assertions
in the Java language (or just about any OOPL), but I dont hold out hope
that they *all* will.
Eiffel is certainly one of the better O-O languages available (I wont
start flames by claiming any one language is best). I personally
prefer being a polyglot over fanatically religious adherence to a
particular language. The vast majority of OOPLs have some good and
valuable things to teach us, as well as lessons from which we can
learn. Recognizing those aspects in multiple languages is crucial for
increasing ones depth of experience and understanding.
As for why Eiffel hasnt had quite the following that many would like,
I agree wholeheartedly with Bert Bril. Although it certainly is NOT
the ONLY reason, one reason why many havent moved so quickly to Eiffel
is the way in which it has been presented and advocated. Whether or
not Dr. Meyer has intended to do so deliberately, he (and others) has
alienated many of the people he most needs to reach. A great many of
Meyer's expositions come across as venom-barbed attacks against a
language and/or its users (perhaps against Dr. Meyer's wishes, or
perhaps not). It is hard to endear others to your language when they
*percieve* you to have pretty much labeled them imbeciles and
incompetents for using another language like C++. Your technical
arguments and conclusions may in fact be brilliant and correct, but
the way in which you present them needs some dramatic re-work and
serious study of how best to present information for the purpose of
effecting a change in people's perceptions and behavior.
So rather than focusing on warding people off of C++ or Java, I think
it would be far more productive to spend time and effort trying to
disseminate accurate information about the benefits of Eiffel WHILE
AT THE SAME TIME taking great pains to ensure that you DO not alienate
or offend potential users at the same time. I have seen Dr. Meyer say
that we will not "coddle the masses" for the sake of shamelessly
peddling a language. While that is noble, there is also a difference
between "coddling" the masses, and trying real hard to NOT "spit on the
masses" (which is how Dr. Meyer often comes across despite his best
intentions). Furthermore, some amount of coddling or hand-holding in
necessary in the field of education. Simply lecturing is not sufficient.
If you dont do that bare minimal amount of "coddling" to help guide
people along and reinforce or at least maintain their self-esteem and
self-worth (without being dishonest of course), then dont expect those
same "masses" to embrace you or your products anytime soon.
Cheers!
--
Brad Appleton <bra...@enteract.com> | http://www.enteract.com/~bradapp/
"And miles to go before I sleep." | 2700+ WWW links on CS & Sw-Eng
D. Erway
>>>>> "mj" == Michael S Jenkins <mjen...@jcs-inc.com> writes:
mj> The argument might be a little more compelling if it were not
mj> so obviously self-serving:
I'm sorry, but I have to disagree with this. Bertrand Meyer has been writing
extremely clear work about OO programming for over a decade. If you have read
any of those writings you will know that Meyer is primarily interested in
pointing out clearly why solving problems with the OO/contract style requires
certain features in a programming language. I feel strongly that Meyer is
primarily interested in the betterment of the industry, more than simple
greed.
mj> The question would be, if eiffel was such a superior alternative,
mj> why didn't the industry jump on *that* bandwagon?
Syntax & lack of marketting funding...
>> ... conveniently overlooks the limitations of Java:
>>
>> - Unproven on large projects. Applets are great, but then
>> what?
mj> This is completely untrue. There are many large scale projects out there
mj> using Java as the core technology. I am working on one such project for
mj> the CBOT.
So am I. I still view Java as unproven. Have you delivered? Have you
maintained and extended and evolved it for a decade?
>> - No multiple inheritance. (The marketing spin here is quite smart: trying
>> to convince people that multiple inheritance is "bad", a contention for
>> which not a single piece of concrete evidence has ever been published,
>> whereas anyone who has practiced O-O development knows how important it is
>> to be able to combine separate abstractions.)
mj> Very good point. I have been saying from the beginning that the Java
mj> people (JavaSoft) take any feature that they don't want to include in the
mj> language and label it as "BAD". This is recognized by most professionals
mj> in the industry as simply a marketing ploy ( obviously pretty successful
mj> ).
So why do you address the surface of his comment, and not the meat? Lack of
Multiple Inheritance in Java is a disgrace. It really comes damn near to
making it useless for large projects. Not useless, but it incurs needless
extra overhead in maintaining all those stupid delegations over the years.
>> - No generic classes (forcing the frequent use of type casts,
>> with disastrous effects on both performance and safety).
mj> While parameterized types would be very useful in Java, there is no
mj> real necessity to have them. I would think that you estimate of the
mj> "disastrous effects on both performance and safety" are a bit
mj> overstated. Type casting in Java is in fact much safer than it
mj> ever was in C++ where you could force cast any type into another.
This is bogus, and totally misses the point. If you want *statically
prove-able* type safety, you should not be using untyped collections, and
random casts. Why give this up when you don't have to? In Java, you have to.
In eiffel, (or even C++ with templates), you don't.
Further, you cannot pass primitives (like float, double, etc), into methods
expecting Object, so in these cases you may have no choice but to move
implementation down into subclasses and do "cut-n-paste inheritance", with all
its horrible effects on long term maintenance costs.
>> - No assertions (even the modest "assert" of C++ has been
>> removed). This means - let's be clear about it -
>> that it is impossible to write serious reusable components
>> in Java, because serious reuse requires that the components
>> be specified.
mj> Assertions, again, are useful. I really don't think you can
mj> dininitively state that their absense makes it "impossible"
mj> to write serious components.
Actually, I was surprised that Meyer stopped there. I would have thought he
would say that it makes it impossible to use serious components. Without
knowing whether the pre-conditions or post-conditions of component method
invocation are violated, you cannot know which component is failing to do the
right thing, or if it is your glue code.
>> - A neutered form of overriding (redefinition): when you
>> redefine a routine, you cannot change its signature.
>> This severely limits the application of polymorphism
>> and other fundamental O-O techniques. (If A has e.g.
>> a routine `copy' that takes an argument of type A,
>> representing an object to be copied, its redefinition
>> in a descendant class B must take an argument of type
>> B - otherwise it makes no sense. The only solution in
>> a no-signature-change language again appears to be the
>> use of casts, removing the benefits of type controls.)
mj> I'm sorry, but this is just a load of cr*p! Judicious use of
mj> overriding and overloading make the derived objects MORE useful
mj> and safe. The ability to change the signature of overridden
mj> methods leads to confusion in the API.
I'm sorry, but you again miss the point. Read Meyer's work about anchored
types, and covariant method redefinition, etc, or read David Shang's work on
Transframe and you will quickly see that these are *necessary* features to
provide the most compile time type safety.
<SNIP - a bunch of comments just proving that Jenkins is anti anything but
C/C++/or Java.>
>> - Used by experienced programmers as well as managers,
>> bankers, traders, engineers and specialists from widely
>> different backgrounds.
mj> How many bankers and traders use ANY programming language?
mj> A programming language, any programming language, is no substitute
mj> for good project management.
That is just his point. Eiffel goes smoothly from a conceptual design
langauge through to a programming language.
Joe Presley
Bradley Thompson <bra...@conan.ids.net> wrote in article
<earafld...@conan.ids.net>...
>
> I have problems with both C++ and Java. However, for serious
programmers,
> C++ would be the better choice [opinion]. Java was created for several
> reasons. First, Sun wanted a platform independant, secure programming
> language, presumably to profit by selling JavaStations. Second, Sun felt
> that C++ was too complicated and tried to simplify it. Third, Sun wanted
> to ingrain itself into the internet even more than its already enviable
> situation dictacting the API in a very microsoft hostile way.
The above is Brad's opinion. I have never seen a Sun document claiming
these goals.
> This leads to several problems. First, the API is ridiculous. For
anyone
> who has not seen it, it is a haphazard and restrictive interface. It
> does not support terminals to any reasonable extent. This could be
> possible to remedy, but no one has stepped up to the challenge yet. The
API
> and language are too intertwined and controlled by sun for any reasonable
> change to be expected. No single corporate entity should have control
> over a language like that; it leads the proprieters of the standards to
> sell influence and model the language for monetary gain (Macromedia has
> "invested" in Java to a significant extent).
[opinion, see above]
> Another point people forget to mention is that C++ and Java ARE NOT
> intended for the same audience. C and C++ were designed as systems
> programming languages; Java is first and formost a scripting/mini-
> application language. Its complete lack of memory manipulation cannot
> be dealt with. It removes many features deemed "confusing", so a new
> user could comprehend the language. The experienced programmers
> writing systems and heavy duty application code were never expected
> to use java.
[opinion (ad nauseum) ]
Are you claiming that you _want_/_need_ to directly manage remote
system resources? The fact is, truly experienced programmers DON'T
want to handle mundane memory/system issues. Your inexperience is
showing!
>
> Okay, enough ranting for me. Intelligent replies welcome.
Tyler Baker
Scott Fahlman wrote:
>
> Tyler Baker <ty...@infinet.com> writes:
>
> > Lisp? Are you crazy. Lisp has no practical use for application
> > development at all. It is strictly an academic research language for
> > studies on such topics as Artificial Intelligence and statistics.
>
> > native code compiler?
>
> the rest of what you are spewing.
>
Ok you got me here as I should of said "Well it is also 100% interpreted
as far as I know". As far as I knew LISP was totally interpreted, so I
apologize here even though I did indeed say "Anyone ever really heard of
a LISP native code compiler? I was asking a question, simply put.
> Lisp has had native-code compilers since the mid-1960's at least, and
> some extremely competitive implementations (competitive with Fortran
> and C if you don't use more expensive features not available in those
> languages) since the mid-1970's.
Competitive, name 10 real world LISP applications that are used today
which have actually been developed outside of academia. I have never
ever seen a job posting for a LISP programmer other than for the $5.25
slave wages undergraduate research assistants get at their local
university so they can pay for the bloated salary of their professors.
> A legitimate complaint is that Lisp carries too much of its
> development environment around at runtime, compared to languages like
> Dylan or Java, and the the environment is too big and monolithic.
>
Again a reason why LISP makes no sense anymore. If you think LISP is so
great, why did CMU (your university) dump it from their 15-212 course in
favor of ML and yes JAVA. As far as I know LISP is now only taught at
CMU in graduate work, but I reserve the right to be wrong on this one.
Not to start another language war, but who actually uses ML for real
application development anyways.
> That can be fixed, and has been in dialects and implementations, but
> the big commercial Lisp vendors turned their full attention to
> small-footprint delivery too late in the game. This created an
> opportunity for something like Java to occupy that niche, and Java has
> done so.
Well I think C, C++, VB, and even SmallTalk occupied this niche far
before Java.
> The unusual Lisp syntax is only a small barrier to learning, even if
> you're coming from C or C++, but syntax seems to have a big effect in
> how ahrd people THINK it will be to learn a new langauge, and
> therefore on their willingness to take the plunge. Only after people
> try to settle in to C++ do they really realize how different it is
> from C, and similarly with the transition from C++ to Java.
Humm, it is not just the syntax but the style of programming as well.
Though from a CS standpoint, functional programming is the preferred way
to go, but for real world applications abusing recursion is generally
not a great way to churn put code.
> As for "irrelevant features", all the features in Common Lisp are
> there for a reason, and those reasons had their roots in real
> programming of large systems, not of toy AI problems. (Even a text
> editor today has a lot of what once would have been called AI.) One
> can certainly argue about whether one Lisp feature or another is worth
> the complexity and implementation cost it adds. There are a number of
> things in Common Lisp that I would throw out or shove into libraries,
> but they are not, in general, the things the Java people threw out.
> It probably isn't worth discussing these trade-offs with someone who
> thinks that all Lisps are interpreted, however.
A text editor? Come on, when I am on a UNIX OS, I generally use Emacs
if it is available, but amazingly I have found that a simple text editor
for win32 named PFE is much more useful than Emacs ever was. Well it is
probably not worth discussing the trade-offs with some person who
actually thinks LISP is suitable today for real application
development. Again, name 10 real applications today that you can buy in
the consumer market that were written in LISP. Name 10 games, name 10
any real programs written in LISP that people actually give a damn about
(other than the people who write them).
> The Lisp community does tend to reject your view that if powerful
> programming constructs are given to average programmers, that is very
> dangerous. I think we have greater faith in the ability of average
> programmers to handle sharp tools. It's very important that there be
> simple ways to do simple things, so that beginners don't have to jump
> immediately into the deep end of the pool. But when you need
> something like multiple inheritance, the gyrations you go through to
> simulate it are much more bug-prone and less efficient than just using
> a built-in facility.
Well there are tradeoffs to every language, but I feel that the
positives of using interfaces instead of multiple inheritance outweigh
the negatives for major application development.
Tyler
Tyler Baker
George Reese wrote:
>
> Jeffrey C. Dege wrote:
> > If I were in Meyer's place, I would try to identify just what it is
> > about Eiffel that keeps it on the fringe, and to address those
> > issues. Public diatribes of the sort we've seen in this thread
> > don't help at all.
>
> The answer to this is the same as that of CORBA and NeXTStep: cost of
> entry. If I am just hanging out with nothing to do and decide I want to
> learn a new language, I have to mortgage my first born child to learn
> Eiffel. Java is free. That alone accounts for a hell of a lot.
Well even though CORBA may be sort of complex, it is the only real ORB
out there that is powerful enough to accomplish out tasks. I was going
to use RMI, but RMI is too pathetically slow with the registry lookup
and other than distributed garbage collection does not offer anything
CORBA does not already have. But more importantly CORBA is an open
standard other people can write to, while RMI and JAVA is not an open
standard. If JAVA passes ISO certification, then I guess you could then
call JAVA open.
Tyler
Matthew Cravit
In article <eapvv5c...@conan.ids.net>,
Bradley Thompson <bra...@conan.ids.net> wrote:
[Much snippage]
>No. Ever heard of a Java native code compiler?
As a matter of fact, yes. Asymmetrix (sp?) has a Java development environment
for Windoze that will, among other features, output native code binaries for
Win32. One can debate whether this is a Good Thing, or a Bad Thing, but there
it is.
And, FWIW, my two cents on the rest of the thread is that people use the
tools which are comfortable for them and which allow them to get the job
done. Mr. Thompson seems to like Lisp. I tend to prefer perl and Java,
personally. I can get my job done using the tools I like, and I assume Mr.
Thompson can do the same thing. Arguing that a hammer should really have
been a screwdriver (or vice versa) is silly, IMHO. If the toolset you choose
allows you to get the job done, then the toolset that other people choose to
use to solve _their_ problems is, IMHO, immaterial.
/MC
--
--
Matthew Cravit, N9VWG | Experience is what allows you to
E-mail: mcr...@best.com (home) | recognize a mistake the second
mcr...@taos.com (work) | time you make it.
morpheus
George Reese <bo...@imaginary.com> wrote in article
> >
> > If I were in Meyer's place, I would try to identify just what it is
> > about Eiffel that keeps it on the fringe, and to address those
> > issues. Public diatribes of the sort we've seen in this thread
> > don't help at all.
>
> The answer to this is the same as that of CORBA and NeXTStep: cost of
> entry. If I am just hanging out with nothing to do and decide I want to
> learn a new language, I have to mortgage my first born child to learn
> Eiffel. Java is free. That alone accounts for a hell of a lot.
>
There are versions of Eiffel which are free too. And what environment are
you using with Java? I used to use Visual Cafe, which was certainly
inexpensive, but definitely not free. As its the case that you can get an
Eiffel environment with full debugging capabilities, native code
compilation, etc for less than $300, I'm uncertain what value one should
place upon first born children...
George Reese
Hans Rohnert wrote:
>
> Andrew Koenig (a...@research.att.com) wrote:
> : In article <336ce5bb...@gate.idg.no> Nils.My...@idg.no writes:
> :
> : > The Java community claim it's better than C++, but that's hardly and
> : > achievment, but do not compare it much to other alternatives.
> : You are quite right -- claiming that Java is better than C++ is not an
> : achievement at all, but an opinion.
> :
> : by evidence -- preferably gathered by someone who does not have a vested
> : interest in any particular conclusion to be drawn from that evidence.
>
> Sure such a statement is rightfully criticized by Andrew. When comparing
> Java and C++ we should consider the different perspectives.
>
> C++ was developed in a C community not respecting any overhead over C.
> Back in the early 80ies performance was of paramount importance. Today we
> are willing to trade some performance for programmer productivity,
> robustness, platform independence, etc.
>
> So, it's a bit unfair to just say something like "C++ arrays are bad".
> Rather, the design tradeoffs were different. No range checking and direct
> access via memory addresses was the reasonably fast way C did it
> and had to be taken as is.
>
> Another unsafe construct: a pointer to a C++ object can be misused to
> randomly offset into its memory. Java's way of spending an additional
> handle data structure is more secure but also more expensive.
> Again different tradeoffs.
>
> BTW, for those interested in migrating from C++ to Java I recommend
> Taligent's cookbook (www.taligent.com).
>
> I admit that this thread (including my message) only scratches the surface.
> There are many more technical and market issues involved. I am looking
> forward to more insights from the C++/Java/Eiffel communities.
>
> Question: what feature did you miss most in your Java programming ?
> (note: I said "programming" in contrast to reading about the language)
>
> --
> Hans.R...@mchp.siemens.de
Definitely multiple inheritance. While I can get by without it (the
criticisms made by the original post on this thread border on
hysterical), I think that it was a serious mistake on the part of Java's
designers to leave it out.
Miguel Angel Sepulveda
> - Cheap personal versions (Windows, Linux), generous
> university packages Miguel Angel Sepulveda Frick Hall Princeton
>University Room 206 Department of Chemistry phone (609)2586183
>http://www.princeton.angel/~angel FAX (609)2586746
> (http://www.eiffel.com/services/university),
> affordable token-based licensing.
Well, I don't know why you think the following pirces are cheap:
EiffelCase 395 US$
EiffelNet 295 US$
EiffelMath 395 US$
GDS 295 US$
The JDK is free for multiple platforms. Java is available for free for
both windoze and Linu users giving access to students to learn it.
There are not many studentd that can afford the above licenses.
David Bradley
Tyler Baker <ty...@infinet.com> wrote:
>Not a good thing for JAVA developers, but very good for general software
>companies except for the "write once run anywhere" idea which will put a
>lot of programmers (and companies) out of work. But for society as a
>whole, this is a much more efficient way of doing things. But if there
>continue to be major "upgrades" to JAVA, this efficiency will never be
>realized. For a lot of people I hate to admit, JAVA is not your friend
>but your biggest nightmare.
But this idea of "Write once run anywhere" is not new. And there is
no reason I should have to forfeit valuable features to obtain it.
I'd love to move to a JIT compiler, but in my opinion JAVA is not the
right language for me.
--------------------------------------------
David Bradley dav...@datalytics.com
Software Engineer
Datalytics, Inc. http://www.datalytics.com
David Bradley
D'Arcy Smith <d...@itools.symantec.com> wrote:
>JIT technology is young (just over a year) in the Java world.
There isn't anything wrong with JIT's. The problem I have is Java.
Why should I have to give up so much to move to a JIT? Why not bring
JIT to other languages?
D. Erway
>>>>> "rw" == Ray Whitmer <raywh...@itsnet.com> writes:
rw> And the worst problem for me with C++ was the lack of dynamic binding.
rw> Guess what? Eiffel seems to lack it, too.
I think you missed something. Eiffel has the exact same dynamic reference
semantic model as does Java. Why post misinformation and ignorance?
rw> Apparently the goal of an Eiffel program is to become a "C" source at the
rw> end of the development cycle.
So what? You can write dynamic code using C. You just have to do alot of
work. Now, the Eiffel compiler does it for you.
rw> It looks like dynamic binding is an after-thought that someone is trying
rw> to scab on on certain platforms, but is not available yet for Win32, and
rw> not a naturally-supported option.
This is totally wrong. Dynamic binding is fundamental to everything Eiffel is
about. There are no platform differences. What the hell are you talkin' about??
:)
rw> No concept of portable downloadable code, and it is does not appear
rw> likely to be easy the way it has been structured. Not a chance it will
rw> ever do the Java safe/portable download/bind trick without an incredible
rw> amount of reengineering, IMHO.
The safe/portable dowload/bind trick is only useful for Applets! Who gives a
damn about applets?
rw> It might be good for monolithic projects, but to me that seems to run
rw> counter to some important goals of OO which is to get away from
rw> monolithic stuff and reuse independant objects and classes.
rw> The language itself may have a few bright spots in the way it defines
rw> things, but the negatives certainly seem to really outweigh the
rw> positives. I investigated the language before Java existed, but in the
rw> mean time forgot why I was unimpressed. And now I remember.
If you actually understood some of the interactions of strongly typed OO, you
would be impressed. Everyone very knowledgable in the field, (except for the
SmallTalkers, who feel pure dynamic typing is the way to go), acknowledges the
fact that Eiffel is beautiful, powerful, and has the best set of features to
support the OO programming style of any language.
The only negatives with Eiffel is marketing - it doesn't have enough market
share to produce a big enough component market, and it didn't use a syntax
derived from C...
rw> I am certain I may have misunderstood something on their pages, and am
rw> certain to get flamed for it. :-).
Well, a little. But seriously, your post was based on ignorance and
misinformation, so you have to expect to get flames as a result.
rw> But after the recent barrage of shallow answers given by Eiffel
rw> proponents in Java groups... while carefully neglecting Eiffel's apparent
rw> deficiencies and Java's strengths etc....
Read some of my other posts on what I have found wrong while doing real work
with Java.
Don
Don Erway derway at ndc.com