The great Java showcase (re: 2nd historic mistake)

The great Java showcase (re: 2nd historic mistake)

[Bertrand Meyer]

In my message on the "second historic mistake" I had
written that, whereas Eiffel has successful commercial
applications approaching the million lines of source
code, there was no comparable experience in Java outside
of applets and of the Java tools themselves. 

A few weeks ago there was an interesting exchange:

	[Ken Garlington]

	!!! The discussion is interesting in that Meyer
	!!! (a) criticizes Java for not being used on large
	!!! projects (whatever happened to unfair criticism
	!!! of new languages?

	[Robert Dewar]

	> > Hmmm! I guess he does not consider the Corel office
	> > suite large. Or perhaps simply does not know about it.

	[Bertrand Meyer]

	> It would be difficult not to know about it,
	> as it gets hammered over and again by Java proponents
	> (along with Java tools themselves) as the example of
	> completed Java development, to the extent that one
	> may wonder whether there is any other.

It's really fascinating to read this again a month later,
with the recent announcements -- widely reported by the
press -- that Corel is dropping its Java strategy altogether.

So much for the showcase success of the century...

-- 
Bertrand Meyer, President, ISE Inc.
ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
http://www.eiffel.com, with instructions for download

Re: The great Java showcase (re: 2nd historic mistake)

[Flavius.Vespasianus]

In article <34023FC9.59E2B600@eiffel.com>, Bertrand Meyer <Bertrand.Meyer@eiffel.com> wrote:

>So much for the showcase success of the century...

Have you seen the computer game "Lemmings"?

------------------------------------------------
Doesn't the marketing person who decided 
"Windows 4.0" should be called "Windows '95" 
look really stupid right now?


Home Page:
http://home.att.net/~miano

Home of the Delphi Component Writers' FAQ

EMail Address:
|m.i.a.n.o @    |
|w.o.r.l.d.n.e.t . |
|a.t.t .| 
|n.e.t |


Full Name:
-------------------
-J.o.h.n?M.i.a.n.o-
-------------------

Re: The great Java showcase (re: 2nd historic mistake)

[BruceMount]

Brett:

>>From: "Brett J. Stonier" <bretts@brightwood.com>
>>What's fascinating to *me* is how much time and energy Eiffel proponents
>>spend attacking Java, instead of being content to use and offer this
>>(supposedly) superior language that, if it is truely so much better,
>>should win out in the end.

As much as I wish it were true, the "better mousetrap" does NOT
frequently win in the marketplace and I find it surprising that
people still think it does.

VHS out-marketed the technically superior Betamax.  Mac were
technically superior to Windows for years and lost the marketing wars.
Objective-C is better than C++ and it lost the marketing wars.

>>Is this "runner-up syndrome" (ala Burger King attacking McDonald's....

 ...another good example.  McDonalds is the unquestioned market
leader.  Does that mean the best food "won out"?

I am particularly suspicious of anything that is totally hyped so that
it is being sold as the cure-all.  I get especially irritated when Sun
(the proprietary owner of Java) run national ads saying "Java is open".

No, Java is not an evil language.  It has many improvements over C++.
No, Eiffel is not a cure-all language either.  However, I do feel that the
Java hype machine has created a tidal wave out of very little water.

As someone that has studied Marketing I can't help but be impressed, just
as I'm impressed by the marketing prowess of Microsoft.

But as a life-long technical person I can't help buy say "the inferior
product is winning......again."  Marketing, it seems, is a much stronger
force than technical reasoning.

How sad.

--Bruce
  BruceMount@aol.com

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet

Re: The great Java showcase (re: 2nd historic mistake)

[Brett J. Stonier]

Bruce -

I can certainly appreciate you opinion.  Although I like playing with it
and see promise for it, I, too, do not think Java to be the end-all,
be-all of development tools.  And, yes, Sun is overhyping it for the
wrong reasons.  And, yes, it can be frustrating when technically
superior products (especially ones you have an interest in, like one in
which you have programming experience) do not win out over inferior
products that have better marketing.  I have a good degree of
programming experience in SQLWindows, for example.  SQLWhat?  "Oh, its
like Powerbuilder or (shudder) VB, but much better."  :-)  Nowadays, its
pretty much dead.  :-(

However, from a fairly unbias observer's standpoint on these Eiffel vs.
Java threads, I am saying that the Eiffel proponents are taking the
wrong approach.  Most of the threads have been kicked off by posts by
Meyer, who presents an arrogant, condescending attititude towards Java.
When you insult Java like that you are insulting Java programmers and
creating resentment towards yourself.

I went into these posts fairly neutral, with a positive image of both
Java and Eiffel, and came out turned off towards Eiffel.  I believe this
is the exact opposite of the effect that is desired.  If this is the
marketing approach that will be used, let's learn a bit from these
technological history lessons everyone's been presenting, and seal the
fate of Eiffel right now.

Brett S.
http://www.mtjeff.com/~calvin/devhbook

Re: The great Java showcase (re: 2nd historic mistake)

[Jon S Anthony]

In article <3406C150.3EE5EE0E@stratasys.com> Jeff Kotula <jkotula@stratasys.com> writes:

> I'm not saying that Eiffel advocates shouldn't tone down their
> rhetoric, but the rest of us should probably open up a bit. We are,
> after all, supposed to be engineers/scientists and remain free of
> bias :)

Sounds good to me.  I note here that I really don't have a love affair
with any programming language.  Put another way, I feel they all suck
one way or another and that they need to be evaluated for each context
to see which one sucks the least for that context of use.  I also
favor (heresy of heresies) multi-language development in those (many,
imo) cases where it makes sense.  The thing that is annoying about
these ultra-fanatical Eiffel people, isn't Eiffel - it _is_ a language
that sucks less than many - it's that they basically have bought into
their own rhetoric that Eiffel is the absolute paragon of perfection
in PLs.  IMO, there are many perspectives from which it is not even
remotely close to this.  Take expressivity for example.  Compared to
CL/CLOS, Eiffel is about as expressive as the original BASIC.

/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: The great Java showcase (re: 2nd historic mistake)

[Jay Martin]

Jon S Anthony wrote:
> 
> In article <3406C150.3EE5EE0E@stratasys.com> Jeff Kotula <jkotula@stratasys.com> writes:
> 
> > I'm not saying that Eiffel advocates shouldn't tone down their
> > rhetoric, but the rest of us should probably open up a bit. We are,
> > after all, supposed to be engineers/scientists and remain free of
> > bias :)
 
> Sounds good to me.  I note here that I really don't have a love affair
> with any programming language.  Put another way, I feel they all suck
> one way or another and that they need to be evaluated for each context
> to see which one sucks the least for that context of use. 

Seems reasonable.  My "roots" are in "programming in the large
with "non-brilliant programmers" so I prefer "anal", "hand holding",
"strongly typed" and simple languages.  Though I would love
to see my "beliefs" challenged by say stellar improvements in
productivity  studies using more "loose" languages on projects
consisting of say a few million lines of code and heh "room temperature" 
programming IQs.

>  I also
> favor (heresy of heresies) multi-language development in those (many,
> imo) cases where it makes sense. 

Multi-language development projects can be a pain and usually
more languages means even more pain. 

> The thing that is annoying about
> these ultra-fanatical Eiffel people, isn't Eiffel - it _is_ a language
> that sucks less than many - it's that they basically have bought into
> their own rhetoric that Eiffel is the absolute paragon of perfection
> in PLs.  

I have never used Eiffel but it looks to be a very good language
that has few compromises on "quality".

> IMO, there are many perspectives from which it is not even
> remotely close to this. Take expressivity for example.  Compared to
> CL/CLOS, Eiffel is about as expressive as the original BASIC.

It seems to me if you are doing "prototypes", short lived programs
and small programs, etc, then expressivity is a desirable
feature.  As you go into "a programming the large" situation, then
"expressivity" has its costs.  And it may just be my "roots"
but "large" situations seem much more challenging and critical
than "small programs" which can easily be dumped and rewritten.
I guess I find "unscalable" programming in the small
languages and programming philosophies less compelling than
"large" ones.


Jay

Re: The great Java showcase (re: 2nd historic mistake)

[Jon S Anthony]

In article <34072C68.DAFB500E@earthlink.net> Jay Martin <jaymmartin@earthlink.net> writes:

> Jon S Anthony wrote:
> > 
> > Sounds good to me.  I note here that I really don't have a love affair
> > with any programming language.  Put another way, I feel they all suck
> > one way or another and that they need to be evaluated for each context
> > to see which one sucks the least for that context of use. 
> 
> Seems reasonable.  My "roots" are in "programming in the large
> with "non-brilliant programmers" so I prefer "anal", "hand holding",
> "strongly typed" and simple languages.  Though I would love

That's quite reasonable for that sort of situation.  No argument.

> to see my "beliefs" challenged by say stellar improvements in
> productivity studies using more "loose" languages on projects
> consisting of say a few million lines of code and heh "room
> temperature" programming IQs.

As you've pointed out in the past - even if this were true, the chance
of getting verifying studies showing it is about as likely as being
hit by a meteorite...


> >  I also
> > favor (heresy of heresies) multi-language development in those (many,
> > imo) cases where it makes sense. 
> 
> Multi-language development projects can be a pain and usually
> more languages means even more pain. 

Yes, I know that's the traditional argument.  But shoehorning
inappropriate work into a language model not really supportive of it
is even worse.  Now, I don't claim you should have dozens of languages
or something - but 2 (or maybe even three in some cases) is not that
big of a deal.


> > IMO, there are many perspectives from which it is not even
> > remotely close to this. Take expressivity for example.  Compared to
> > CL/CLOS, Eiffel is about as expressive as the original BASIC.
> 
> It seems to me if you are doing "prototypes", short lived programs
> and small programs, etc, then expressivity is a desirable
> feature.

Absolutely.  But the (IMO extreme) importance of this in prototypes
(and prototypes /= final work) is largely unrecognized to the
detriment of subsequent quality in the "manufactured" version.


> As you go into "a programming the large" situation, then
> "expressivity" has its costs.

In general I think this is quite true.  But I don't see this as being
in any sort of conflict with my position.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: The great Java showcase (re: 2nd historic mistake)

[W. Wesley Groleau x4923]

> productivity  studies using more "loose" languages on projects
> consisting of say a few million lines of code and heh "room temperature"
> programming IQs.

You mean an IQ of 70 (Fahrenheit) or 35 (Celsius) ?

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: The great Java showcase (re: 2nd historic mistake)

[Tim Ottinger]

Not all brilliant people are always pleasant people, granted, and
language wars are either dull or inflammatory, but let's not lose
perspective.

Meyer is brilliant. If you read his books or articles with your
"language war filter" on full blast, you find that he has many wonderful
ideas and a very solid foundation for his thoughts and even his stronger
opinions. I learn something everytime I take a look at his Eiffel book.

He did create a powerful construct in "design by contract". He did
create a powerful language to support it. He's said more than once that
DBC seems to him to be more important than all the rest of the OO-ness
supported by modern OO languages. I'm sure that he's very proud of his
accomplishments, and it's embittering to see language developers and
users staying away in droves.

I'm sure that Meyer has driven people away by some of his postings, and
I'm sure that that's also a horrible shame. But people should try to
separate their bias against the man from their bias against the ideas or
products that he's developed.

> > However, from a fairly unbias observer's standpoint on these Eiffel
> vs.
> > Java threads,
>
> More accurately, it's Eiffel vs. The World.
>
>  I am saying that the Eiffel proponents are taking the
> > wrong approach.  Most of the threads have been kicked off by posts
> by
> > Meyer, who presents an arrogant, condescending attititude towards
> Java.
>
> ^^^^^
> _anything_

Re: The great Java showcase (re: 2nd historic mistake)

[not]

On 08/27/97, Fergus Henderson wrote:
>
>Objective-C was not better than C++.  Objective-C was a basically
>"Smalltalk in C": a dynamically typed OOP language embedded inside C.
>In my humble opinion, this is not a good match.  To the best of my
>knowledge, Objective-C lacked static checking and was much less efficient
>than C++.
>

I think that Objective-C from Stepstone permitted both static type checking 
and static binding as an option.  Objective-C from NeXT permits static type 
checking.  NeXT also introduced Objective-C "Protocols" which were used by 
Sun as a model for Java "Interfaces".  In either case you can determine the 
"type" of an object without knowing it's class.

Objective-C is somewhat slower than C++.  I've seen empirical estimates 
that place the difference in the range of 10%.  If you need that extra 10% 
performance, and you can design a nice efficient system and implement it 
successfully using C++, go ahead.  Taligent had a lot of trouble with sytem 
design using C++.  But maybe you can do it.

Let me know how you make out after you've profiled your C++ code and you 
want to make some changes in the design in order to improve performance.  
You might find it's possible to arrive at a more efficient design, given 
the same resources, with a language that supports dynamic type checking, 
notwithstanding the overhead imposed by the run time environment.


-- 
invert:  umich.edu jdevlin
insert:  shift "2"

Re: The great Java showcase (re: 2nd historic mistake)

[Richard A. O'Keefe]

fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>Objective-C was not better than C++.

Well, it depends on what you mean by "better".

- Cheaper to enter?
  Someone here wrote an Objective C compiler in a couple of months spare
  time several years ago.  You got more OOP bang for the compiler
  development buck.  

- Compiler reliability?
  _Because_ the job of an Objective-C compiler is much much simpler than
  the job of a C++ compiler, you get rather more compiler reliability
  for the same level of investment.

- Library design?
  The Objective-C libraries were designed with the language, just like
  Eiffel.  Unfortunately, a split developed, with StepStone owning the
  original libraries, and other free libraries being developed, which
  eroded this benefit.

- Better support for OOP?
  Objective-C provided things like save/load for objects.

- Better support for evolutionary programming.
  The fact that Objective-C is dynamic and C++ is static is not an
  accident.  Stroustrup was starting from a Simula background and
  trying to "sell" OOP to people who demanded "efficiency", which
  implies a static language.  The designer of Objective-C was more
  concerned with long-span _maintenance_ costs and chose a design
  that he thought would reduce _that_:  no good having a fast program
  if it is now far too expensive to make it do what you want.

>Objective-C was a basically
>"Smalltalk in C": a dynamically typed OOP language embedded inside C.
>In my humble opinion, this is not a good match.

Objective C _has_ changed, and there is a bit more static checkability
than there used to be, but dynamicity was what the design was supposed
to achieve.  I imagine that _any_ level of dynamicity will be a poor
match with C.  Don't forget, Dylan was years in the future when ObjC
was designed (:-).

>To the best of my
>knowledge, Objective-C lacked static checking and was much less efficient
>than C++.

"Much less efficient"?  At what?  It's possible to win all the battles
and still lose the war.  ObjC was designed to permit certain _kinds_ of
efficiency (like code-sharing and development time) at the expense of
others; C++ was designed to permit certain _kinds_ of efficiency (like
run-time) at the expense of others.  One could quite fairly say that
ObjC dynamism doesn't encourage bloated programs the way that C++ 
templates do, and for the sizes of machines current when ObjC was designed,
that was a major factor in over-all _system_ efficiency.  (Why do I need
to give a certain web browser 16Mb of memory?  Amongst other things, because
of OOP languages that _aren't_ dynamic.  Why don't I use that browser on
machine X? Because I only _have_ 16Mb on that machine, and the OS needs
some of it.)

Efficiency is a property of _programs_, not _languages_.  I once had a
Prolog program that ran faster than the Fortran program it replaced,
and the Fortran compiler generated native code and the Prolog program
didn't.  Reason?  Prolog had encouraged me to think in a way that
suggested a far more efficient algorithm and made it easy for me to write
that algorithm.  

Is there any evidence that _applications_ developed in Objective C in the
NextStep environment are materially less efficient than similar applications
developed in C++ for that or some other environment on the same hardware?
-- 
Unsolicited commercial E-mail to this account is prohibited; see section 76E
of the Commonwealth Crimes Act 1914 as amended by the Crimes Legislation
Amendment Act No 108 of 1989.  Maximum penalty:  10 years in gaol.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: The great Java showcase (re: 2nd historic mistake)

[Nick Leaton]

There is a large article in the Wall Street Journal on Java 
Dated 28th August

-- 

Nick

Re: The great Java showcase (re: 2nd historic mistake)

[Tim Ottinger]

> - Better support for OOP?
>   Objective-C provided things like save/load for objects.

So you consider saving and loading to be an OO aspect of programming?
That's very unusual. I don't consider this to be an OO aspect at all,
but a general programming need.

Moreover, from an OO perspective, I personally find it distasteful for
business objects to have anyknowledge of presentation or persistence.
This even further created confusion over the idea of save/load methods
in objects being OOP.

Finally, I can have save/load methods in objects if I really wanted to.
What does Objective-C add to ease the burden and support the
aftermarket? I actually don't know, so this is a chance to explain or
evangelize.

Care to comment? I'd love to hear your perspective.

Re: The great Java showcase (re: 2nd historic mistake)

[W. Wesley Groleau x4923]

> > - Better support for OOP?
> >   Objective-C provided things like save/load for objects.
> Finally, I can have save/load methods in objects if I really wanted 
> to.  What does Objective-C add to ease the burden and support the
> aftermarket? I actually don't know, so this is a chance to explain or
> evangelize.
> 
> Care to comment? I'd love to hear your perspective.

Since I don't know Objective-C, I may not be talking about the 
same thing.  But since you posted to comp.lang.ada....

Ada has 'Read and 'Write functions predefined for everything.

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: The great Java showcase (re: 2nd historic mistake)

[Patrick Doyle]

In article <3402FD4D.C196785B@brightwood.com>,
Brett J. Stonier <bretts@brightwood.com> wrote:
>
>What's fascinating to *me* is how much time and energy Eiffel proponents
>spend attacking Java, instead of being content to use and offer this
>(supposedly) superior language that, if it is truely so much better,
>should win out in the end.  Is this "runner-up syndrome" (ala Burger
>King attacking McDonald's, Pepsi attacking Coke, etc.?)  What's the true
>motivation here?

  That's exactly what it is.  Java is what programmers are currently
turning to in droves, and the Eiffel people are trying to turn some
of that tide their way by highlighting what Eiffel does better than
Java.  I don't blame them.  I happen to think their points are mostly
right.  They do tend to be a bit overexuberant at times, though.

  And by the way, there's certainly no reason to believe that Eiffel
will win out in the end because it's better.  It's going to take
some careful marketing.

>If you're trying to enlighten the world to the wisdom of Eiffel, you
>should know that you're going about it the wrong way.  The
>self-rightous, condescending attitudes used to do it (like the above
>gloating) have turned me off to Eiffel completely.

  I tend to agree with that.  But if you get the opportunity, you should
really give Eiffel a chance.  It's a pretty good system.

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: The great Java showcase (re: 2nd historic mistake)

[Paul Johnson]

In article <3402FD4D.C196785B@brightwood.com>, bretts@brightwood.com says...

>What's fascinating to *me* is how much time and energy Eiffel proponents
>spend attacking Java, instead of being content to use and offer this
>(supposedly) superior language that, if it is truely so much better,
>should win out in the end. 

If you really think that the technically superior solution will always win,
I suggest you read up on the history of technology.  Some counter-examples
are:

VHS vs BETAMAX
Decca vs LORAN
IBM PC vs just about anything else.
C++ vs Ada

Paul.

-- 
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244         +-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: The great Java showcase (re: 2nd historic mistake)

[Brett J. Stonier]

Paul Johnson wrote:

> In article <3402FD4D.C196785B@brightwood.com>, bretts@brightwood.com
> says...
>
> >What's fascinating to *me* is how much time and energy Eiffel
> proponents
> >spend attacking Java, instead of being content to use and offer this
> >(supposedly) superior language that, if it is truely so much better,
> >should win out in the end.
>
> If you really think that the technically superior solution will always
> win,
> I suggest you read up on the history of technology.  Some
> counter-examples
> are:
>
> VHS vs BETAMAX
> Decca vs LORAN
> IBM PC vs just about anything else.
> C++ vs Ada
>
> Paul.
>
> --
> Paul Johnson            | GEC-Marconi Ltd is not responsible for my
> opinions. |
> +44 1245 242244
> +-----------+-----------------------------------------+
> Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of
> little
> Home: <Paul@treetop.demon.co.uk>    | standards, all different.

I never said *always*, but yes, it does help.  What about the Japanese
car companies of the 80s?  However, that was not my main point, which is
that the Eiffel supporters are making themselves out to be elitists and
whiners.  Do you think it would have helped Betamax to stamp their feet
and yell "VHS sucks, we're better!" and "VHS tapes are only suitable for
music videos!"?  The problem here is that too many people already had
VHS machines, and when the competition tells you what you just purchased
is lousy (implying you must be a bit slow to have bought it in the first
place) it only serves to make you dislike them and turn you off to their
product.

So, when Eiffel people say "Java is a toy", all they are doing is
building resentment towards Eiffel, further sealing its fate.

Brett

P.S.  Your C++ vs Ada example is purely subjective.

P.P.S.  I do really like your Zork reference, though.

--
Brett S.
http://www.mtjeff.com/~calvin/devhbook

Re: The great Java showcase (re: 2nd historic mistake)

[Robert Dewar]

Paul Johnson said

<<IBM PC vs just about anything else>>

Another example where the techies think they know better than customers.
If you don't understand why the IBM PC succeeded over what seem to you
to be clearly technically superior alternatives, you just don't understand
that market place!

Re: The great Java showcase (re: 2nd historic mistake)

[Paul Johnson]

In article <dewar.872791624@merv>, dewar@merv.cs.nyu.edu says...
>
>Paul Johnson said
>
><<IBM PC vs just about anything else>>
>
>Another example where the techies think they know better than customers.
>If you don't understand why the IBM PC succeeded over what seem to you
>to be clearly technically superior alternatives, you just don't understand
>that market place!

I understand that marketplace perfectly well.  I know the history of the 
IBM PC and its clones.  I can see the logic of each decision which 
brought us to where we are now (me typing this on a P5-90 under Win95).
That does not negate my point.  If anything, it re-enforces it.

I've talked to people about Eiffel, and then watched them go out and buy
C++.  And I understand their reasons perfectly well.

Paul.


-- 
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244         +-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: The great Java showcase (re: 2nd historic mistake)

[Jeff Brown]

In article <5u3co8$gtf$3@miranda.gmrc.gecm.com>, paul.johnson@gecm.com (Paul Johnson) writes:
 
> VHS vs BETAMAX
ARHGGG!!!!!

Re: The great Java showcase (re: 2nd historic mistake)

[James P. White]

Bertrand Meyer wrote:
> 
> In my message on the "second historic mistake" I had
> written that, whereas Eiffel has successful commercial
> applications approaching the million lines of source
> code, there was no comparable experience in Java outside
> of applets and of the Java tools themselves.
> 
> A few weeks ago there was an interesting exchange:
> 
>         [Ken Garlington]
> 
>         !!! The discussion is interesting in that Meyer
>         !!! (a) criticizes Java for not being used on large
>         !!! projects (whatever happened to unfair criticism
>         !!! of new languages?
> 
>         [Robert Dewar]
> 
>         > > Hmmm! I guess he does not consider the Corel office
>         > > suite large. Or perhaps simply does not know about it.
> 
>         [Bertrand Meyer]
> 
>         > It would be difficult not to know about it,
>         > as it gets hammered over and again by Java proponents
>         > (along with Java tools themselves) as the example of
>         > completed Java development, to the extent that one
>         > may wonder whether there is any other.
> 
> It's really fascinating to read this again a month later,
> with the recent announcements -- widely reported by the
> press -- that Corel is dropping its Java strategy altogether.
> 
> So much for the showcase success of the century...

As I am sure you will hear, those reports were entirely inaccurate.

What Corel dropped was the already doomed, regardless of language of
development, approach of creating monolithic personal computer product
suites for the consumer marketplace.

In its place is a true network centric architecture in which servers
provide the high volume memory and cpu cycles.  This is an inevitable
consequence of the economics of computing which is now playing out as
the cost of communications decreases.  Corel, along with most other
players in the industry, are and will be using Java to implement that.

As for the size of the products developed with Java so far I am sure the
experience of my company is not unique in having built a working system
of over 500K lines in less than 12 months (and it will be growing into a
system of millions of lines over the next two years).  This involved
combining large modules (50K to 200K lines each) which successfully
integrated with no serious failures even though the respective modules
are all rather immature and barely out of beta (and sometimes not even
that).

Even though Java lacks anything as comprehensive as DBC, in our
experience the simple matter of having automatic memory management and
pointer protection has yielded a productivity boost of several hundred
percent.

jim
-----------------------------------------------------------------------
James P. White                        Netscape DevEdge Champion for IFC
Director of Technology Adventure Online Gaming http://www.gameworld.com
Developers of Gameworld -- Live Action Role-Playing and Strategic Games
jim@pagesmiths.com        Pagesmiths' home is http://www.pagesmiths.com

Re: The great Java showcase (re: 2nd historic mistake)

[Robert Dewar]

James White says

<<What Corel dropped was the already doomed, regardless of language of
development, approach of creating monolithic personal computer product
suites for the consumer marketplace.>>

doomed? how does Microsoft Office-97 NOT fit this description?

Re: The great Java showcase (re: 2nd historic mistake)

[Bertrand Meyer]

James P. White wrote:
 
[Quoting me]
> > It's really fascinating to read this again a month later,
> > with the recent announcements -- widely reported by the
> > press -- that Corel is dropping its Java strategy altogether.
> >
> > So much for the showcase success of the century...

[James P. White]

> As I am sure you will hear, those reports were entirely inaccurate.

The Toronto Globe and Mail wrote that Corel was "ditching"
Java efforts. This has been criticized on some newsgroups
as being exaggerated. But here is the report from Computer
Reseller News in Techwire (see
http://192.215.107.71/wire/news/aug/0817corel.html
for the full text):

        OTTAWA -- Corel has rethought its Java strategy, 
        according to sources briefed by the company.

        Now, the plan is to put the bulk of application
        logic on servers, which would then
        serve up what's needed to the client, whether that client
        is a PC or a Network Computer, said Amy Wohl, president
        of Wohl Associates, a Narberth, Pa., researcher.

        Previously, the company was rewriting its bread-and-butter
        drawing and productivity applications in Java. But that
        effort has been delayed significantly.

        Corel now plans to use home-grown technology, code-named
        Remagen [...]
        
        There still will be a lower-end Java suite for NCs due in
        October, Wohl noted, but the thrust has shifted considerably
        to the enterprise.

The word "altogether" in "Dropping its Java strategy altogether"
was based on the initial press reports and may turn out to be too
strong. The jury is still out as to how "altogether" the drop is,
although in the software business "delayed significantly" is often a
euphemism for something more fatal. The point of my note (not a flame,
just a reporting of fact) stands: that the great showcase of Java
triumph, reported everywhere including in these newsgroups, was
perhaps advertized a bit prematurely.

See also: http://www4.zdnet.com/anchordesk/story/story_799.html.

-- 
Bertrand Meyer, President, ISE Inc.
ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
http://www.eiffel.com, with instructions for download

Re: The great Java showcase (re: 2nd historic mistake)

[Matthew S. Whiting]

Bertrand Meyer wrote:
> 
> The Toronto Globe and Mail wrote that Corel was "ditching"
> Java efforts. This has been criticized on some newsgroups
> as being exaggerated. But here is the report from Computer
> Reseller News in Techwire (see
> http://192.215.107.71/wire/news/aug/0817corel.html
> for the full text):
> 
>         OTTAWA -- Corel has rethought its Java strategy,
>         according to sources briefed by the company.
> 
>         Now, the plan is to put the bulk of application
>         logic on servers, which would then
>         serve up what's needed to the client, whether that client
>         is a PC or a Network Computer, said Amy Wohl, president
>         of Wohl Associates, a Narberth, Pa., researcher.
> 
>         Previously, the company was rewriting its bread-and-butter
>         drawing and productivity applications in Java. But that
>         effort has been delayed significantly.
> 
>         Corel now plans to use home-grown technology, code-named
>         Remagen [...]
> 
>         There still will be a lower-end Java suite for NCs due in
>         October, Wohl noted, but the thrust has shifted considerably
>         to the enterprise.
> 
> The word "altogether" in "Dropping its Java strategy altogether"
> was based on the initial press reports and may turn out to be too
> strong. The jury is still out as to how "altogether" the drop is,
> although in the software business "delayed significantly" is often a
> euphemism for something more fatal. The point of my note (not a flame,
> just a reporting of fact) stands: that the great showcase of Java
> triumph, reported everywhere including in these newsgroups, was
> perhaps advertized a bit prematurely.
> 
> See also: http://www4.zdnet.com/anchordesk/story/story_799.html.

The "Toronto Globe and Mail" doesn't sound like a technical publication
to me, but rather a generic newspaper.  Correct?

As a pilot, I know how accurately most newspapers report airplane
accidents.  If this level of accuracy also applies to technology
strategy reports (and I'll wager it does given the technical awareness
of most newspaper reporters), then I don't think I'd quote this source
in a technically oriented newsgroup.

Matt

Re: The great Java showcase (re: 2nd historic mistake)

[Flavius.Vespasianus]

In article <3404E9D8.6E3D@epix.net>, whiting@epix.net wrote:
>Bertrand Meyer wrote:
>> 
>> The Toronto Globe and Mail wrote that Corel was "ditching"
>> Java efforts. This has been criticized on some newsgroups
>> as being exaggerated. But here is the report from Computer
>> Reseller News in Techwire (see
>> http://192.215.107.71/wire/news/aug/0817corel.html
>> for the full text):
>> 
>>         OTTAWA -- Corel has rethought its Java strategy,
>>         according to sources briefed by the company.
>> 
>>         Now, the plan is to put the bulk of application
>>         logic on servers, which would then
>>         serve up what's needed to the client, whether that client
>>         is a PC or a Network Computer, said Amy Wohl, president
>>         of Wohl Associates, a Narberth, Pa., researcher.
>> 
>>         Previously, the company was rewriting its bread-and-butter
>>         drawing and productivity applications in Java. But that
>>         effort has been delayed significantly.
>> 
>>         Corel now plans to use home-grown technology, code-named
>>         Remagen [...]
>> 
>>         There still will be a lower-end Java suite for NCs due in
>>         October, Wohl noted, but the thrust has shifted considerably
>>         to the enterprise.
>> 
>> The word "altogether" in "Dropping its Java strategy altogether"
>> was based on the initial press reports and may turn out to be too
>> strong. The jury is still out as to how "altogether" the drop is,
>> although in the software business "delayed significantly" is often a
>> euphemism for something more fatal. The point of my note (not a flame,
>> just a reporting of fact) stands: that the great showcase of Java
>> triumph, reported everywhere including in these newsgroups, was
>> perhaps advertized a bit prematurely.
>> 
>> See also: http://www4.zdnet.com/anchordesk/story/story_799.html.
>
>The "Toronto Globe and Mail" doesn't sound like a technical publication
>to me, but rather a generic newspaper.  Correct?
>
>As a pilot, I know how accurately most newspapers report airplane
>accidents.  If this level of accuracy also applies to technology
>strategy reports (and I'll wager it does given the technical awareness
>of most newspaper reporters), then I don't think I'd quote this source
>in a technically oriented newsgroup.

As a computer professional (and a pilot as well), I know how accurately most 
trade rags report on the computer industry. The accuracy is no better than in 
the regular newspapers.

------------------------------------------------
Doesn't the marketing person who decided 
"Windows 4.0" should be called "Windows '95" 
look really stupid right now?


Home Page:
http://home.att.net/~miano

Home of the Delphi Component Writers' FAQ

EMail Address:
|m.i.a.n.o @    |
|w.o.r.l.d.n.e.t . |
|a.t.t .| 
|n.e.t |


Full Name:
-------------------
-J.o.h.n?M.i.a.n.o-
-------------------

Re: The great Java showcase (re: 2nd historic mistake)

[Mike Coffin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2911 bytes --]


Bertrand Meyer <Bertrand.Meyer@eiffel.com> writes:

> James P. White wrote:
>  
> [Quoting me]
> > > It's really fascinating to read this again a month later,
> > > with the recent announcements -- widely reported by the
> > > press -- that Corel is dropping its Java strategy altogether.
> > >
> > > So much for the showcase success of the century...
> 
> [James P. White]
> 
> > As I am sure you will hear, those reports were entirely inaccurate.
> 
> The Toronto Globe and Mail wrote that Corel was "ditching"
> Java efforts. This has been criticized on some newsgroups
> as being exaggerated. But here is the report from Computer
> Reseller News in Techwire...

Rather than rely on sources that are notoriously unreliable when it
comes to technical information, how about just going to the source?
E.g., http://www.corel.com/javastrat/index.htm.  Here is the
front matter:

    "This document outlines Corel's Business Applications strategy and
    the role that Java plays. The future focus of Corel's Business
    Applications targets three primary areas.

    "The first area of concentration for Corel is to add Java
    technology (code named Remagen) to its existing suite that will
    allow Corel� WordPerfect� Suite 8, or other software such as
    Microsoft� Office, to be run on a server and accessed via a thin
    Java client on any Java virtual machine. Targeted to the corporate
    community, this product will allow for lower maintenance costs and
    cross-platform access to the Corel family of products and any
    other Windows NT�-based application.

    "The second step is to produce a new line of products that are
    Internet-centric and take advantage of Corel's Java
    expertise. This new product line will combine concepts found in
    our present CorelCENTRAL product that ships in Corel�
    WordPerfect� Suite 8, evolving technology from our Corel� Office
    for Java, and other technology and concepts that are presently
    being worked on at Corel. This development will create a new
    generation of products for information management and knowledge
    handling inside and outside the organization.

    "The third area of concentration for Corel is to continue producing
    and evolving its present suite of Windows� products.  Corel's
    customers can expect to see future versions of Corel WordPerfect
    Suite as the company moves these business applications forward."

None of this sounds much like Corel is "ditching" Java.  I think that,
as usual, the press is engaging in pack journalism.  Someone early on
interpreted what Corel did as a retreat from Java, so journalists from
all over raced off to write that story.  The fact that it wasn't
actually true doesn't matter much: it's a *big* story, and lot's of
people *want* it to be true.  So we get a sort of Gresham's law of
journalism where bad journalism drives out good.

-mike

Re: The great Java showcase (re: 2nd historic mistake)

[Robert Dewar]

Mike Coffin says

<<Rather than rely on sources that are notoriously unreliable when it
comes to technical information, how about just going to the source?>>

Several people on this newsgroup have (very reasonably) cautioned that
newspapers may not be the best source of information. I would like to
suggest that neither is the PR department of the company affected, which
is of course working to put the best possible spin on this situation!

Re: The great Java showcase (re: 2nd historic mistake)

[James P. White]

Robert Dewar wrote:
> 
> Mike Coffin says
> 
> <<Rather than rely on sources that are notoriously unreliable when it
> comes to technical information, how about just going to the source?>>
> 
> Several people on this newsgroup have (very reasonably) cautioned that
> newspapers may not be the best source of information. I would like to
> suggest that neither is the PR department of the company affected, which
> is of course working to put the best possible spin on this situation!

That may be true is some general sense, but of course is not relevant to
the topic of this thread which is not the credibility of the source of
public information but rather the totally inaccurate report that Corel
had made a major shift or retreat in their Java strategy when in fact
what the company had said was that they were expanding their Java
efforts.

jim 
-----------------------------------------------------------------------
James P. White                        Netscape DevEdge Champion for IFC
Director of Technology Adventure Online Gaming http://www.gameworld.com
Developers of Gameworld -- Live Action Role-Playing and Strategic Games
jim@pagesmiths.com        Pagesmiths' home is http://www.pagesmiths.com

Re: The great Java showcase (re: 2nd historic mistake)

[Jon S Anthony]

In article <dewar.872856497@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Mike Coffin says
> 
> <<Rather than rely on sources that are notoriously unreliable when it
> comes to technical information, how about just going to the source?>>
> 
> Several people on this newsgroup have (very reasonably) cautioned that
> newspapers may not be the best source of information. I would like to
> suggest that neither is the PR department of the company affected, which
> is of course working to put the best possible spin on this situation!

Wise words - that apply at least as much to the _source_ of this
particular rumor's occurance here.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: The great Java showcase (re: 2nd historic mistake)

[James P. White]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3162 bytes --]


Bertrand Meyer wrote:
> ...
> http://192.215.107.71/wire/news/aug/0817corel.html
> for the full text):
> 
> ...
>         Corel now plans to use home-grown technology, code-named
>         Remagen [...]
>...

There's another thing which illustrates how the reporters totally missed
the point, Remagen is implemented in Java!  It is Corel's network
centric (or as they say with the current marketing buzz - "enterprise")
application server technology.

For those who actually care about what Corel is doing, you can go to
their home page <http://www.corel.com>.  They have a link on their front
page pointing you directly to  documentation of their current efforts
and product roll out plans for their Java technology.  One of the pages
there (updated to dispel the misinformation from that article) is
<http://www.corel.com/javastrat/commitment.htm>, which begins:

>    Corel's Commitment to Java�Stronger Than Ever
>    100% Pure Java on the Desktop 
> 
>    With the development of the prototype Corel Office for Java product, 
> Corel has pioneered the use
>    of Java in the implementation of mission-critical business applications. 
> Network-centric computing
>    has rapidly emerged as the dominant new direction for the enterprise. 
> Corel's new Java-based
>    solution creates a bridge to existing Windows applications and legacy 
> files, and also empowers
>    the emerging Network Computing (NC) paradigm.
>...

So while I understand your glee at the prospect that your prediction
about Java's eminent failure had already received the confirmation of a
major casualty, you will have to accept that Corel is anything but.  In
fact the whole point of their announcement was that their early efforts
confirmed their strategy and that they are now expanding it into the
next stage of both technology development and deployment.  

So Corel continues as the Great Java Showcase and I predict that they
will consequently have considerable success in the marketplace for
corporate office software, an area in which they  (the WordPerfect
product they bought from Novell) were about to fall into oblivion.  

When Corel's success with their office software in Java is examined
several years from now, it will be understood simply as the normal
process of competitive pressure leading an innovative company into
creating a new technology to out compete the dinosaurs who are stuck
with the old paradigm (unfortunately for Corel, Microsoft has also
demonstrated that Bill understands the future of Java too by having
dropped their previous strategy for network dominence - Blackbird - in
favor of Java only weeks after JDK 1.0 was released).

Also, the next time you start another one of these cross posted
monsters, please use comp.lang.java.advocacy instead of
comp.lang.java.tech.

jim
-----------------------------------------------------------------------
James P. White                        Netscape DevEdge Champion for IFC
Director of Technology Adventure Online Gaming http://www.gameworld.com
Developers of Gameworld -- Live Action Role-Playing and Strategic Games
jim@pagesmiths.com        Pagesmiths' home is http://www.pagesmiths.com

Re: The great Java showcase (re: 2nd historic mistake)

[Dennis Weldy]

 Of course, newspper reports never misquote, or misunderstand what was
stated. 
Evidently, Corel has a rebutal on its web page. What about that?

Dennis


Bertrand Meyer wrote in article <34048653.63DECDAD@eiffel.com>...

>James P. White wrote:
> 
>[Quoting me]
>> > It's really fascinating to read this again a month later,
>> > with the recent announcements -- widely reported by the
>> > press -- that Corel is dropping its Java strategy altogether.
>> >
>> > So much for the showcase success of the century...
>
>[James P. White]
>
>> As I am sure you will hear, those reports were entirely inaccurate.
>
>The Toronto Globe and Mail wrote that Corel was "ditching"
>Java efforts. This has been criticized on some newsgroups
>as being exaggerated. But here is the report from Computer
>Reseller News in Techwire (see
>http://192.215.107.71/wire/news/aug/0817corel.html
>for the full text):
>
>        OTTAWA -- Corel has rethought its Java strategy, 
>        according to sources briefed by the company.
>
>        Now, the plan is to put the bulk of application
>        logic on servers, which would then
>        serve up what's needed to the client, whether that client
>        is a PC or a Network Computer, said Amy Wohl, president
>        of Wohl Associates, a Narberth, Pa., researcher.
>
>        Previously, the company was rewriting its bread-and-butter
>        drawing and productivity applications in Java. But that
>        effort has been delayed significantly.
>
>        Corel now plans to use home-grown technology, code-named
>        Remagen [...]
>        
>        There still will be a lower-end Java suite for NCs due in
>        October, Wohl noted, but the thrust has shifted considerably
>        to the enterprise.
>
>The word "altogether" in "Dropping its Java strategy altogether"
>was based on the initial press reports and may turn out to be too
>strong. The jury is still out as to how "altogether" the drop is,
>although in the software business "delayed significantly" is often a
>euphemism for something more fatal. The point of my note (not a flame,
>just a reporting of fact) stands: that the great showcase of Java
>triumph, reported everywhere including in these newsgroups, was
>perhaps advertized a bit prematurely.
>
>See also: http://www4.zdnet.com/anchordesk/story/story_799.html.
>
>-- 
>Bertrand Meyer, President, ISE Inc.
>ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
>805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
>http://www.eiffel.com, with instructions for download
>.
> 

Re: The great Java showcase (re: 2nd historic mistake)

[Charles Ditzel]

Unfortunately the erroneous articles have caused confusion...and it nothing
as "fatal" as Mr Meyer imagines.

Try http://www.corel.com/javastrat/index.html.  This explains with a bit
more clarity what is going on.  Corel, when all is said and done, is 
INVESTING MORE HEAVILY IN JAVA.  Two projects "Remagan" and "Alta" with 
time to markets of Winter '97 and Spring '98 (according to their charts).

Overall - as ambitious (in many ways) as the Office Suite for Java - simply
they have rethought and adapted to the emerging Java competition (i.e. Lotus, 
Applix, etc.) and the new web-based groupware market.



Dennis Weldy wrote:
> 
>  Of course, newspper reports never misquote, or misunderstand what was
> stated.
> Evidently, Corel has a rebutal on its web page. What about that?
[more stuff deleted]
[Stuff from Mr. Meyer]
> >The word "altogether" in "Dropping its Java strategy altogether"
> >was based on the initial press reports and may turn out to be too
> >strong. The jury is still out as to how "altogether" the drop is,
> >although in the software business "delayed significantly" is often a
> >euphemism for something more fatal. The point of my note (not a flame,
> >just a reporting of fact) stands: that the great showcase of Java
> >triumph, reported everywhere including in these newsgroups, was
> >perhaps advertized a bit prematurely.
[stuff deleted]
> >Bertrand Meyer, President, ISE Inc.

Re: The great Java showcase (re: 2nd historic mistake)

[Robert Dewar]

James P. White <jim@pagesmiths.com> wrote in article
<3404670B.C3A2C4A2@pagesmiths.com>...
> Even though Java lacks anything as comprehensive as DBC, in our
> experience the simple matter of having automatic memory management and
> pointer protection has yielded a productivity boost of several hundred
> percent.

If automatic memory management really cut down your development time by
a factor of several, I hate to think of what on earth you were doing to
waste that much time previously. Sure memory management problems can be
persnickety, but if they are taking up 80% of your time, something is
VERY wrong with the way you are writing programs.

Re: The great Java showcase (re: 2nd historic mistake)

[James P. White]

Robert Dewar wrote:
> 
> James P. White <jim@pagesmiths.com> wrote in article
> <3404670B.C3A2C4A2@pagesmiths.com>...
> > Even though Java lacks anything as comprehensive as DBC, in our
> > experience the simple matter of having automatic memory management and
> > pointer protection has yielded a productivity boost of several hundred
> > percent.
> 
> If automatic memory management really cut down your development time by
> a factor of several, I hate to think of what on earth you were doing to
> waste that much time previously. Sure memory management problems can be
> persnickety, but if they are taking up 80% of your time, something is
> VERY wrong with the way you are writing programs.

Yes, there is something VERY wrong with the way most programmers (not me
of course) write programs.  

When combining modules from multiple sources it inevitably turns out
that multiple, not very compatible, memory management schemes are used
(sometimes, but not often, more than one scheme in the same module).  It
is also inevitable (lacking the resources of NASA) that the modules have
had insufficient inspection and stress testing and are rife with memory
management bugs and memory munging that are not caught.  The integration
phase (which is where the vast majority of the savings comes) when using
C and C++ with commercial and developmental libraries and modules has
been a black hole for resources in large systems which has swallowed
many (extremely well funded) projects whole. 

Being able to proceed through integration needing little more than
functional testing is a huge boon to large system development and is
reason enough (although there are others) to use Java for commercial
applications.

Your derisive comment does make me wonder how many systems of 500K lines
or more you have designed and built (I am on my fourth one and have had
many happy clients).

jim
-----------------------------------------------------------------------
James P. White                        Netscape DevEdge Champion for IFC
Director of Technology Adventure Online Gaming http://www.gameworld.com
Developers of Gameworld -- Live Action Role-Playing and Strategic Games
jim@pagesmiths.com        Pagesmiths' home is http://www.pagesmiths.com

Re: Memory management techniques -- was Re: The great Java showcase

[Jon S Anthony]

In article <EFnKuI.4rI@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:

> [Eiffel and Java newsgroups removed because they use GC]

Java has GC since the JVM provides it.  So, any Ada->JVM impl will
have it, e.g., Aonix ObjectAda or Intermetrics AdaMagic.  So, anywhere
Java GC is, you have Ada GC...

/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: The great Java showcase (re: 2nd historic mistake)

[Bert Bril]

James P. White wrote:
> 
> Robert Dewar wrote:
> >
> > James P. White <jim@pagesmiths.com> wrote in article
> > <3404670B.C3A2C4A2@pagesmiths.com>...
> > > Even though Java lacks anything as comprehensive as DBC, in our
> > > experience the simple matter of having automatic memory management and
> > > pointer protection has yielded a productivity boost of several hundred
> > > percent.
> >
> > If automatic memory management really cut down your development time by
> > a factor of several, I hate to think of what on earth you were doing to
> > waste that much time previously. Sure memory management problems can be
> > persnickety, but if they are taking up 80% of your time, something is
> > VERY wrong with the way you are writing programs.
> 
> Yes, there is something VERY wrong with the way most programmers (not me
> of course) write programs.

So, do the programmers decide not to use GC? That _is_ a major problem.
Because it's a design issue. And if the boost of GC is so large
somewhere, then they should get GC immediately there. For any serious
language there is GC available nowadays. And, e.g., in C++ you can now
even choose which parts you want to handle manually, and which part not
(see e.g. http://www.geodesic.com ).

It's always the same story. People find themselves in a badly managed
environment with bad QA, bad Design, bad everything. And then, of
course, the language is to blame. Java may be the best choice for a lot
of situations. But the evaluation of whether it is the best should be
kept separated from these managerial problems. If you have no QA: make
sure you get that first. You'll not make good software using Java then,
either.


Bert

-- de Groot - Bril Earth Sciences B.V.
-- Boulevard 1945 - 24, 7511 AE Enschede, The Netherlands
-- mailto:bert@dgb.nl , http://www.dgb.nl
-- Tel: +31 534315155 , Fax: +31 534315104

Re: The great Java showcase (re: 2nd historic mistake)

[Jay Martin]

Bert Bril wrote:

> It's always the same story. People find themselves in a badly managed
> environment with bad QA, bad Design, bad everything. And then, of
> course, the language is to blame. Java may be the best choice for a lot
> of situations. But the evaluation of whether it is the best should be
> kept separated from these managerial problems. If you have no QA: make
> sure you get that first. You'll not make good software using Java then,
> either.

I don't agree.  Which tools are best is dependent on
the environment. Bozo environments need special restricted
tools that cater to their bozo natures.  Its best not to give
loaded guns to 3 year olds. Of course it is best
not have have "bozo environments" but the incompetent programmers
and managers in this (sewer) industry make that a pipe dream.

Jay

Re: The great Java showcase (re: 2nd historic mistake)

[Mike Charlton]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> James P. White <jim@pagesmiths.com> wrote in article
> <3404670B.C3A2C4A2@pagesmiths.com>...
> > Even though Java lacks anything as comprehensive as DBC, in our
> > experience the simple matter of having automatic memory management and
> > pointer protection has yielded a productivity boost of several hundred
> > percent.
> 
> If automatic memory management really cut down your development time by
> a factor of several, I hate to think of what on earth you were doing to
> waste that much time previously. Sure memory management problems can be
> persnickety, but if they are taking up 80% of your time, something is
> VERY wrong with the way you are writing programs.

A couple of people have said that Robert's statement is a cheap shot.  I'd
have to disagree.  I think the difference of opinion comes about from
different ways of measuring productivity.

Automatic memory management will surely not affect the requirements stage.
It should only slightly affect the design stage (the design will be different,
but you really don't have to spend all that much time worrying about memory
issues).  In coding, it will have some effect on productivity, but if you
have some experienced programmers, it shouldn't be more than 20-30% of the 
time (IMHO).  Back end testing shouldn't uncover too many issues (especially
if you have already used a memory checking program like Purify).  So again,
20-30% of your time should be plenty.

Support and maintenance is another question.  Tracking down memory problems
is a real pain.  In my experience, 10 or 15% of issues are memory related.
They also take an inordinate amount of time to deal with.  Making sure you
have good code reviews should keep this to a minimum, though.

Anyway, I agree with Robert.  If you are spending 80% (or even 50%) of your
time *for the whole project* on memory issues, you have some serious
problems (lack of code inspections and inexperienced people qualify as
serious problems with me).

I have worked with both large C++ projects and large projects using
a proprietary language with automatic memory management.  Yes, with C++
we spent a lot of time thinking about memory.  However, using automatic
memory management, we spent a lot of time thinking about performance.
I'd say it's a bit of a toss up.  No one solution will work well for
every problem.

           Mike

Re: The great Java showcase (re: 2nd historic mistake)

[Mike Charlton]

Dave Sparks <Dave.Sparks@sisyphus.demon.co.uk> writes:

> >>>>> "MC" == Mike Charlton <mikechar@nortel.ca> writes:
> 
>   MC> ...
> 
>   MC> I have worked with both large C++ projects and large projects using a
>   MC> proprietary language with automatic memory management.  Yes, with C++
>   MC> we spent a lot of time thinking about memory.  However, using
>   MC> automatic memory management, we spent a lot of time thinking about
>   MC> performance.  I'd say it's a bit of a toss up.  No one solution will
>   MC> work well for every problem.
> 
> Are you saying that when you used C++ you spent so much time on
> memory management that you couldn't afford to think about performance?

I'm not sure if that was meant to be a rhetorical question, but in case
it wasn't -- the answer is "No".  We just didn't need to spend very much
time tweaking performance.  My point was that automatic garbage collection
makes life easier for you.  But it doesn't come for free.  You *can*
overcome performance difficulties, but I figure it takes about as much
effort as memory stuff using C++ (IMHO, anyway -- YMMV).

        Mike

P.S. Please note that the requirements for different projects vary
considerably.  What may constitue a performance difficulty in one project
may have no impact on another.  I'll use Java, Smalltalk, Eiffel (or
whatever) on projects for which thet make sense.  I'll also use C++ on
projects for which it makes sense (and it *does* occasionally :-)).

Re: The great Java showcase (re: 2nd historic mistake)

[Dave Sparks]

>>>>> "MC" == Mike Charlton <mikechar@nortel.ca> writes:

  MC> Dave Sparks <Dave.Sparks@sisyphus.demon.co.uk> writes:
  >> >>>>> "MC" == Mike Charlton <mikechar@nortel.ca> writes:
  >> 
  MC> ...
  >>
  MC> I have worked with both large C++ projects and large projects using a
  MC> proprietary language with automatic memory management.  Yes, with C++
  MC> we spent a lot of time thinking about memory.  However, using
  MC> automatic memory management, we spent a lot of time thinking about
  MC> performance.  I'd say it's a bit of a toss up.  No one solution will
  MC> work well for every problem.
  >>  Are you saying that when you used C++ you spent so much time on
  >> memory management that you couldn't afford to think about performance?

  MC> I'm not sure if that was meant to be a rhetorical question, but in
  MC> case it wasn't -- the answer is "No".  We just didn't need to spend
  MC> very much time tweaking performance.  My point was that automatic
  MC> garbage collection makes life easier for you.  But it doesn't come
  MC> for free.  You *can* overcome performance difficulties, but I figure
  MC> it takes about as much effort as memory stuff using C++ (IMHO, anyway
  MC> -- YMMV).

The question _was_ rhetorical - the point being that when you have
one _huge_ problem, the other, smaller, problems disappear into
the background and can get forgotten.

We've been using a byte-coded interpreted language with mark-sweep
garbage collection for over ten years, and the GC costs are
typically about 1% of the total.  Individual GCs take less than
0.1 seconds with a 2Mb heap on a SUN SparcStation 5, which is not
a problem in our context.  We used to have performance problems,
but we solved them by re-engineering the application (delivering
the 10::1 improvement we'd had to promise to get the funding).
It's doubtful that this product would have been written in C or
C++, but if it had been I don't think it would ever have met our
current performance expectations.

We also have C and C++ code where memory management is a very
difficult problem, partly because some of the code involved is not
under our control.  This area also needs re-engineering, because
the risk of memory leaks is unacceptably high.  This
re-engineering will not be easy.

Java performance does seem to be poor at the moment, but I expect
it to improve.  Remember that at one time performance was cited as
the reason for routinely using assembly code rather than a
high-level language.  This claim is uncommon today, and I expect
to see a similar change in attitude over the choice of
fully-compiled or compiled-and-interpreted languages.

I do know of one case, from twenty years ago, where two versions
of a COBOL compiler were written simultaneously by two separate
teams.  One version was written in assembly code, while the other
used a purpose-designed compiled-and-interpreted language, which
was developed as part of the project (and never used for any other
purpose).  Each team beleived that its method was the better one,
and was determined to prove it.  When the initial versions of the
copilers were compared, the assembly-code version was faster.  A
month later, the compile-and=interpret team, using the
instrumentation that the interpreter made possible, had improved
their compiler's performance enough to beat the assembly-coded
version (where performance improvements could not be accurately
targeted).

(The requirement was to replace an earlier COBOL compiler badly
written by assembly-code programmers unwillingly using a
high-level fully-compiled language.)

-- 
Dave Sparks, Staffordshire, England

Re: The great Java showcase (re: 2nd historic mistake)

[Peter Hermann]

Patrick Doyle (doylep@ecf.toronto.edu) wrote:

>   For my part, I'd guess that at least 40 to 50% of my time is
> spent looking for memory allocation bugs in C++.

great! keep on spending  :-)

>   If this isn't the case with you then, well, I suppose you're
> just the greatest darn programmer in the whole world.

Not at all, he simply uses Ada ;-)

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: The great Java showcase (re: 2nd historic mistake)

[Robert Dewar]

Patrick said

<<  That's a pretty cheap shot, Robert.  Plus, it's not necessarily
true.  There are applications that just beg for automatic memory
management, and if they happend upon one of these, they certainly
could have seen such an improvement.

  For my part, I'd guess that at least 40 to 50% of my time is
spent looking for memory allocation bugs in C++.

  If this isn't the case with you then, well, I suppose you're
just the greatest darn programmer in the whole world.>>


Well different people have different styles in programming. I personally
like programming, but hate debugging, so I perfer to spend my effort
getting this right to start with. But I realize others prefer to spend
their time debugging -- it's a matter of taste partly -- although I
suspect that a lot of people do spend far too much time with a debugger.

It's interesting to ask a roomful of C and C++ programmers how mnay of
them routinely use a dynamic debugger. You will get pretty much a 100%
response, plus a reaction that the question is curious.

If you ask the same question in a roomful of Ada programmers, you will
find a split, somewhere close to 50/50. 

That's partly a language difference, but also partly a style difference.

Particularly in C++, proper abstraction and encapsulation should make
it possible to minimize problems with dynamic allocation. Now I must
admit that most C and to somewhat lesser an extent C++ programmers
seem blissfully unaware of what abstraction is all about.

As for applications where you can get a factor of several productivtiy
improvement by using garbage collection, I think that is rubbish. Remember
I speak here as someone who fully knows the vale of garbage collection.
I wrote the SPITBOL systems (see the paper in SP&E, 1977, which describes
the interesting approach SPITBOL uses to GC), and was deeply involved in
the Algol-68 design.

So I know the advantage, and it is consderable, but the idea that GC alone
could cut down the time to design/document/code/test/integrate/productize
a product by a factor of several seems ludicrous to me.

Perhaps you are just talking about coding time -- even there the estimate
is way high.

You do NOT have to be the "greatest darn programmer in the whole world" to
avoid wasting 40-50% of your time looking for memory allocation bugs in
C++, you just need to create the proper abstractoins in the first place.

Now to be fair, you may well be spending this time on other people's
poorly written code, in which case the blame lies elsewhere.

But if you think my comment is a cheap shot, then you are far from being
sufficiently aware of what can be achieved by proper software process,
and this does NOT require super duper clever programmers, it is something
that can be achieved by good management, and good choice of techniques,
languages, and tools, with typical competent programmers, not super stars.

Re: The great Java showcase (re: 2nd historic mistake)

[Patrick Doyle]

In article <dewar.872872168@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Patrick said
>
><<For my part, I'd guess that at least 40 to 50% of my time is
>spent looking for memory allocation bugs in C++.
>
>  If this isn't the case with you then, well, I suppose you're
>just the greatest darn programmer in the whole world.>>
>
>
>Well different people have different styles in programming. I personally
>like programming, but hate debugging, so I perfer to spend my effort
>getting this right to start with. But I realize others prefer to spend
>their time debugging -- it's a matter of taste partly -- although I
>suspect that a lot of people do spend far too much time with a debugger.

  Hey, I don't like debugging either...

>You do NOT have to be the "greatest darn programmer in the whole world" to
>avoid wasting 40-50% of your time looking for memory allocation bugs in
>C++, you just need to create the proper abstractoins in the first place.

  I'd love to know how.  Do you have any references to techniques
for this sort of thing?

>Now to be fair, you may well be spending this time on other people's
>poorly written code, in which case the blame lies elsewhere.

  Actually, in my case, that's true.  In fact, for the bulk of my
professional career, I've been upgrading legacy code, and I don't
really know much else, so maybe I'm overestimating my problems
with memory.

>But if you think my comment is a cheap shot, then you are far from being
>sufficiently aware of what can be achieved by proper software process,
>and this does NOT require super duper clever programmers, it is something
>that can be achieved by good management, and good choice of techniques,
>languages, and tools, with typical competent programmers, not super stars.

  Sure, but I still think it was a cheap shot.  Someone said "I spend
X amount of time finding memory bugs" and you said "then you must
be doing something terribly wrong".  Now that you've explained your 
reasoning, I think we're all better off.

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: The great Java showcase (re: 2nd historic mistake)

[Jon S Anthony]

In article <dewar.872872168@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> As for applications where you can get a factor of several productivtiy
> improvement by using garbage collection, I think that is rubbish. Remember

I find myself in complete agreement with you here - despite the
likelyhood that I am often seen as a GC fanatic.


> So I know the advantage, and it is consderable, but the idea that GC alone
> could cut down the time to design/document/code/test/integrate/productize
> a product by a factor of several seems ludicrous to me.

Again (though I find it hard to choke out, :-), I find that I must
agree.  Even a factor of 2 is rather hard to believe, let alone
"several factors".  Let's face, getting even a 10% advantage is a rare
thing.  OTOH, even a 10% advantage must then be characterized as a
"big deal".  Personally, I think GC varies anywhere from 0% to maybe
15-20% depending on the application characteristics.


> Perhaps you are just talking about coding time -- even there the estimate
> is way high.

Agreed.  The coding advantage is really the biggest win as you don't
have to put the same level of effort up front in ensuring things will
behave correctly wrt dynamic memory issues.


> You do NOT have to be the "greatest darn programmer in the whole
> world" to avoid wasting 40-50% of your time looking for memory
> allocation bugs in C++, you just need to create the proper
> abstractoins in the first place.

OK, I'm still choking, but again, I must agree...

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: The great Java showcase (re: 2nd historic mistake)

[Robert Dewar]

JOn said

<<Again (though I find it hard to choke out, :-), I find that I must
agree.  Even a factor of 2 is rather hard to believe, let alone
"several factors".  Let's face, getting even a 10% advantage is a rare
thing.  OTOH, even a 10% advantage must then be characterized as a
"big deal".  Personally, I think GC varies anywhere from 0% to maybe
15-20% depending on the application characteristics.
>>


Absolutely, gains of 10 or 20% are very significant and very important
to pursue. The trouble is that if people really start to believe the
"several hundred percent" or "order of magnitude improvement" claims,
they may overlook the achievable smaller bug significant gains.

Re: The great Java showcase (re: 2nd historic mistake)

[Jon S Anthony]

In article <dewar.873149189@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> JOn said
> 
> "several factors".  Let's face, getting even a 10% advantage is a rare
> thing.  OTOH, even a 10% advantage must then be characterized as a
> "big deal".  Personally, I think GC varies anywhere from 0% to maybe
> 15-20% depending on the application characteristics.
> >>
> 
> Absolutely, gains of 10 or 20% are very significant and very important
> to pursue. The trouble is that if people really start to believe the
> "several hundred percent" or "order of magnitude improvement" claims,
> they may overlook the achievable smaller bug significant gains.

Absolutely agreed.  The importance of this is really hard to
over-emphasize as you can lose site of very real and tangible gains.
Gains that are quite readily seen but are dismissed as not being "good
enough", simply because they aren't that "magic bullet" level
increase.  But the latter is largely a fiction and so you simply mire
yourself into non-progressing technology.  A 10% here a 20% there
etc. really begins to add up over the long term and eventually we
might actually get this "several factors" over the course of building
on these very real "small gains".  That's why the overly prevalent
"all or nothing" attitude in this business is so destructive and self
defeating.

/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: The great Java showcase (re: 2nd historic mistake)

[Robert Dewar]

Jon said

<<Absolutely agreed.  The importance of this is really hard to
over-emphasize as you can lose site of very real and tangible gains.
Gains that are quite readily seen but are dismissed as not being "good
enough", simply because they aren't that "magic bullet" level
increase.  But the latter is largely a fiction and so you simply mire
yourself into non-progressing technology.  A 10% here a 20% there
etc. really begins to add up over the long term and eventually we
might actually get this "several factors" over the course of building
on these very real "small gains".  That's why the overly prevalent
"all or nothing" attitude in this business is so destructive and self
defeating.>>

You don't even need to let them "add up", a single 10% gain is highly
valuable. Anyone who does not think so is welcome to send me a check
for 10% of the cost of their next software project on the grounds that
they will not notice the difference (but I will :-)

Re: The great Java showcase (re: 2nd historic mistake)

[Jon S Anthony]

In article <dewar.873477226@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Jon said
> <<<
> yourself into non-progressing technology.  A 10% here a 20% there
> etc. really begins to add up over the long term and eventually we
> might actually get this "several factors" over the course of building
> on these very real "small gains".  That's why the overly prevalent>>>
> 
> You don't even need to let them "add up", a single 10% gain is highly
> valuable.

Right.  What I meant above was "adding up" across a sequence of
technologies giving such increments, not adding up on a project.

> Anyone who does not think so is welcome to send me a check
> for 10% of the cost of their next software project on the grounds that
> they will not notice the difference (but I will :-)

Exactly.  Hey, I'll take 10% of your 10% and will be a very happy
camper!

/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: The great Java showcase (re: 2nd historic mistake)

[Arthur Nelson]

Patrick Doyle wrote:
> 
> In article <dewar.872791474@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
> >James P. White <jim@pagesmiths.com> wrote in article
> ><3404670B.C3A2C4A2@pagesmiths.com>...
> >> Even though Java lacks anything as comprehensive as DBC, in our
> >> experience the simple matter of having automatic memory management and
> >> pointer protection has yielded a productivity boost of several hundred
> >> percent.
> >
> >If automatic memory management really cut down your development time by
> >a factor of several, I hate to think of what on earth you were doing to
> >waste that much time previously. Sure memory management problems can be
> >persnickety, but if they are taking up 80% of your time, something is
> >VERY wrong with the way you are writing programs.
> 
>   That's a pretty cheap shot, Robert.  Plus, it's not necessarily
> true.  There are applications that just beg for automatic memory
> management, and if they happend upon one of these, they certainly
> could have seen such an improvement.
> 
>   For my part, I'd guess that at least 40 to 50% of my time is
> spent looking for memory allocation bugs in C++.
> 
>   If this isn't the case with you then, well, I suppose you're
> just the greatest darn programmer in the whole world.
> 
>  -PD
> --
> --
> Patrick Doyle
> doylep@ecf.utoronto.ca

40 to 50% is astounding.

Re: The great Java showcase (re: 2nd historic mistake)

[Patrick Doyle]

In article <3406C0B0.546F@vineyard.net>,
Arthur Nelson  <art@vineyard.net> wrote:
>Patrick Doyle wrote:
>> 
>>   For my part, I'd guess that at least 40 to 50% of my time is
>> spent looking for memory allocation bugs in C++.
>
>40 to 50% is astounding.

  PLEASE share your techniques.  I could really use some help in
this area, it seems.

 -PD

PS.  Perhaps I should mention that I'm maintaining and upgrading
legacy code.  That's one main reason I spend so much time on
memory issues--the original programmer wasn't too concerned
with them.
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: The great Java showcase (re: 2nd historic mistake)

[Robert Dewar]

Patrick said

<<PS.  Perhaps I should mention that I'm maintaining and upgrading
legacy code.  That's one main reason I spend so much time on
memory issues--the original programmer wasn't too concerned
with them.>>

OK, but then that says nothing about the inherent importance of this
particular issue. If you were working on code where an incompetent
original programmer had written all their floating-point formulae
thinking that real arithmetic was possible on machines, you might
be spending 40-50% of your time on that, but it does not prove
that as a generalization, this is an important general issue!

Re: The great Java showcase (re: 2nd historic mistake)

[Laurent Guerby]

doylep@ecf.toronto.edu (Patrick Doyle) writes:
> > [...]
>   That's a pretty cheap shot, Robert.  Plus, it's not necessarily
> true.  There are applications that just beg for automatic memory
> management, and if they happend upon one of these, they certainly
> could have seen such an improvement.
> 
>   For my part, I'd guess that at least 40 to 50% of my time is
> spent looking for memory allocation bugs in C++.
> [...]

   Ada has the ability to manipulate unconstrained objects (something
like returning dynamic sized objects/arrays) without requiring user
heap management. The greatly obviates the need for user
allocation/deallocation, you can write very large Ada programs without
doing fine grained heap management (and I agree with you, very error
prone unless you're some kind of programming deity ;-).

   When doing graph/tree stuff, you'll often see a big dynamically
allocated array behind the scene in Ada programs, reallocated when
there's not enough room, a good example of this is GNAT (see the
generic unit table in the sources).

   It is an area where language matters, by allowing stack (the Ada
compiler may use dymaic allocation behind your back, but I guess most
modern Ada technologies use a secondary stack) allocated complex
dynamic types (Ada case) or by providing garbage collection (Java).

   I've seen high level translation to Ada of C++ API, which
originately required the user to worry a lot about heap management
(conventions C1, C2, ... C6, that kind of stuff), giving an Ada
version without any heap management (discrimated types and
unconstrained arrays doing the job). Needless to say, bye bye the "40%
to 50% of the time" chasing heap problems ;-).


-- 
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: The great Java showcase (re: 2nd historic mistake)

[Samuel Mize]

Patrick Doyle wrote:
> 
> In article <fxrabd1l2c.fsf@boole.enst-bretagne.fr>,
> Laurent Guerby  <Laurent.Guerby@enst-bretagne.fr> wrote:
> >doylep@ecf.toronto.edu (Patrick Doyle) writes:
> >
> >   Ada has the ability to manipulate unconstrained objects (something
> >like returning dynamic sized objects/arrays) without requiring user
> >heap management. The greatly obviates the need for user
> >allocation/deallocation, you can write very large Ada programs without
> >doing fine grained heap management (and I agree with you, very error
> >prone unless you're some kind of programming deity ;-).
> 
>   I'm not sure I follow the Ada approach.  How do these "unconstrained
> objects" work?

Here's a very brief discussion (since this thread is so cross-
posted).  For more info, see the tutorials at www.adahome.com.

An Ada object must be constrained (have a definite size) when it
exists.  However, you can define a type that is not constrained.
Each object of that type gets its constraints when created.  If
a procedure parameter is unconstrained, it gets its constraints
from the value given when the procedure is called.

Here's a concrete example:

declare

  -- Define an integer-indexed array of characters.  We do NOT
  -- define the min or max indexes, or the size of the array.

  type Flex_Array is array (integer range <>) of character;

  A, B: Natural; -- integers greater than or equal to zero

  procedure X (F: in Flex_Array);
begin

  -- get values for A and B somehow
  ...

  declare
    Flex_A: Flex_Array (1..A);
    Flex_B: Flex_Array (3..B);
  begin
    X (Flex_A);
    X (Flex_B);
  end;
end;


Where Flex_A and Flex_B exist, they have well-defined sizes.
However, these sizes are defined at run time.

In the first call to X, F'First (the first array index) will be
1.  In the second call to X, F'First will be 3.  If B is less than
3, Flex_B is a null array, which is perfectly fine in Ada.

Sam Mize

Re: The great Java showcase (re: 2nd historic mistake)

[Lee Webber]

On 28 Aug 1997 14:05:41 -0400, dewar@merv.cs.nyu.edu (Robert Dewar)
wrote:

>James P. White <jim@pagesmiths.com> wrote in article
><3404670B.C3A2C4A2@pagesmiths.com>...
>> Even though Java lacks anything as comprehensive as DBC, in our
>> experience the simple matter of having automatic memory management and
>> pointer protection has yielded a productivity boost of several hundred
>> percent.
>
>If automatic memory management really cut down your development time by
>a factor of several, I hate to think of what on earth you were doing to
>waste that much time previously.

And here you ignored "and pointer protection".  There is more to
pointer problems than the premature release of objects.

Re: The great Java showcase (re: 2nd historic mistake)

[Robert Dewar]

neil says

<<Eiffel has had that for years, so your productivity boost is only over the
C languages. For the other several hundred percent you need to apply DBC,
even if only methodologically.>>


Any time that people claim giant factors in productivity improvements, they
do the technology for which they make the claim a disservice.

The trouble is that when anyone reads a silly claim like the above, they
tend to assosicate it with everyone who has been supporting the feature.
Certainly Betrand Meyer is not going to claim a "several hundred percent
improvement" in  productivity from using DBC. Just that it can provide
in some circumstances a significant productivity boost.

Ada has been hurt in the past by ludicrous claims, and it is a common
phenomenon.

Of course when a methodology, or language, or technique, or whatever,
has the effect of resulting in working code instead of catastrophic
non-working code, then in some sense the improvement in productivity
is infinite, but this is not a useful quantitative way to look at things.

Re: The great Java showcase (re: 2nd historic mistake)

[Lee Webber]

On 28 Aug 1997 14:03:51 -0400, dewar@merv.cs.nyu.edu (Robert Dewar)
wrote:

>neil says
>
><<Eiffel has had that for years, so your productivity boost is only over the
>C languages. For the other several hundred percent you need to apply DBC,
>even if only methodologically.>>
>
>Any time that people claim giant factors in productivity improvements, they
>do the technology for which they make the claim a disservice.
[etc]

Here's the article to which neil was responding:

>James P. White <jim@pagesmiths.com> wrote in article
><3404670B.C3A2C4A2@pagesmiths.com>...
>> Even though Java lacks anything as comprehensive as DBC, in our
>> experience the simple matter of having automatic memory management and
>> pointer protection has yielded a productivity boost of several hundred
>> percent.

Seeing the two together, it's obvious that neil was not making a
precise technical claim.  Leaving out what you did was a distortion of
his message.

Re: The great Java showcase (re: 2nd historic mistake)

[James P. White]

Neil Wilson wrote:
> 
> James P. White <jim@pagesmiths.com> wrote in article
> <3404670B.C3A2C4A2@pagesmiths.com>...
> > Even though Java lacks anything as comprehensive as DBC, in our
> > experience the simple matter of having automatic memory management and
> > pointer protection has yielded a productivity boost of several hundred
> > percent.
> 
> Eiffel has had that for years, so your productivity boost is only over the
> C languages. For the other several hundred percent you need to apply DBC,
> even if only methodologically.

Yes, you are quite right, I did not explain that I was comparing the
experience with C and C++ using large commercial libraries for GUI,
database, and communications.  LISP has had those features too for
nearly 40 years now and Smalltalk for 14 years.  So obviously there is
more to Java and its success than just those features.  I personally
have been using DBC and OO methodolgy for 16 years, so I already have
those several hundred percent (which does have a good deal to do with my
success in developing large and reliable systems).

jim
-----------------------------------------------------------------------
James P. White                        Netscape DevEdge Champion for IFC
Director of Technology Adventure Online Gaming http://www.gameworld.com
Developers of Gameworld -- Live Action Role-Playing and Strategic Games
jim@pagesmiths.com        Pagesmiths' home is http://www.pagesmiths.com

Re: The great Java showcase (re: 2nd historic mistake)

[Jon S Anthony]

In article <34034658.7DE14518@eiffel.com> Bertrand Meyer <Bertrand.Meyer@eiffel.com> writes:

> Jon S Anthony wrote:
> > 
> > In article <34023FC9.59E2B600@eiffel.com> Bertrand Meyer <Bertrand.Meyer@eiffel.com> writes:
> > 
> > [More inflam[m]atory BM statements...]
> > 
> 
> That is a really honest and constructive way to cite

In this particular case - yes it is.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari