Java Risks (Was: Ada News Brief - 96-05-24

Java Risks (Was: Ada News Brief - 96-05-24

[Richard Riehle]

Andreas,

Thanks for you commentary on my observations regarding the potential risks
associated with Java for proprietary software products.

On 29 May 1996, Andreas Zeller wrote:

> I don't get the point in here.  If I have some compiled code, where's
> the difference in whether the source code was written in Java or Ada?
> If I have some bytecode for the Java virtual machine, couldn't it have
> been produced by some Ada compiler as well?

  The Java code could certainly be produced by an Ada compiler or
  an Eiffel compiler, etc. No argument with that.  In fact, Intermetrics
  has a product which does this, and ISE is working on an Eiffel compiler
  that will do this.

> Although there are many Java interpreters and Ada compilers, neither
> the Java language nor the Ada language impose a particular model of
> program execution (compiler, interpreter, distribution, etc.)

  I think you may have identified a key difference in the opening
  lines of the preceding paragraph.  Compiled source code is usually
  optimized, and passed through other processes (linkers, binders, etc.)
  which makes applications a bit more difficult to unravel back to their
  original source code.  Ada adds an additional layer in the form of an
  RTE which varies from one compiler publisher to another.

  Interpreted code is relatively easy to reverse-engineer. Consequently,
  it is harder to protect proprietary algorithms.

> Saying that one language has a greater risk in disclosing intellectual
> property is just as misleading than saying that one language is more
> efficient than another.  These are properties of the programming and
> execution environment, not of the language itself.  I don't see why
> choosing Ada or Java should make a difference here.

  One of Java's premier virtues is is portability.  Another is its ease
  of use.  Neither of those features should be weakened.  However, both
  features make it easier to reverse-engineer applications written in
  Java.  Let me emphasize that I do not see this as a bad thing.

  On the other hand, for publishers of commercial software products, there
  is greater security of the intellectual property for compiled code than
  for interpreted code.

  In many ways, Java is BASIC for the next century.  In time, Java will be
  offerred as a compiled language,  clever people will add new features to
  make it more secure, and others will tack on features to make it more
  incomprehensible.  Already, feature-creep is beginnning to manifest
  itself as self-enlightened software gurus conclude that Java would be
  even better if it just had this one or two more features.

  I like Java. I hope it can survive long enough in its present form long
  enough to resist the wide-spread temptation to "make it better."  Let it
  mature.  Let its users mature.  Then, later (much later) revisit the
  language design.  One of the problems with C++ is that it is evolving
  beyond Stroustop's original vision into a collection of features in
  which seem to be on a collsion course with each other. Somehow, the
  ISO Ada 95 standard managed to improve on the ISO Ada 87 standard
  without mangling the language.

  Anyway, my main point is that Java's very benefits for interactive
  software are also its drawbacks for secure software. It is a simple
  trade-off. But it needs to be recognized.

  Richard Riehle

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Brian N. Miller]

In article <Pine.GSO.3.92.960530095503.21075A-100000@nunic.nu.edu>, Richard Riehle <rriehle@nunic.nu.edu> writes:
|
|  Java is BASIC for the next century.

Now that's .sig worthy!

|  One of the problems with C++ is that it is evolving
|  beyond Stroustop's original vision into a collection of features in
|  which seem to be on a collsion course with each other.

A disbelieve that C++ is evolving awkwardly.  Is there a publication
which claims so?  Or is this 2-bit usenet opinion?  ;')

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Jon S Anthony]

In article <Pine.GSO.3.92.960530095503.21075A-100000@nunic.nu.edu> Richard Riehle <rriehle@nunic.nu.edu> writes:


> > Although there are many Java interpreters and Ada compilers, neither
> > the Java language nor the Ada language impose a particular model of
> > program execution (compiler, interpreter, distribution, etc.)
> 
>   I think you may have identified a key difference in the opening
>   lines of the preceding paragraph.  Compiled source code is usually
>   optimized, and passed through other processes (linkers, binders, etc.)
>   which makes applications a bit more difficult to unravel back to their
>   original source code.  Ada adds an additional layer in the form of an
>   RTE which varies from one compiler publisher to another.

Sorry, this just plain does not make any sense.  All languages add an RTE,
including (and in some sense, especially) Java.  What do you think the JVM
is???


>   Interpreted code is relatively easy to reverse-engineer. Consequently,
>   it is harder to protect proprietary algorithms.

Really?  Presumably this is relative to machine code, but it is just
plain not true.  If for no other reason than one implementation's
"interpreted" code could become another's "machine" code.  This
actually happened with P-code and there has even been some talk about
it with respect to J-code.  Again, this just plain makes no sense.
Now, you _can_ make an argument that the particular "interpreted"
code, viz. J-code, itself has some interesting aspects where it
maintains more "source" level type information than some other low
level architecture (oh, say, a SPARC).  But even then, what you're
claiming is a real stretch.


> > Saying that one language has a greater risk in disclosing intellectual
> > property is just as misleading than saying that one language is more
> > efficient than another.  These are properties of the programming and
> > execution environment, not of the language itself.  I don't see why
> > choosing Ada or Java should make a difference here.
> 
>   One of Java's premier virtues is is portability.  Another is its ease
>   of use.  Neither of those features should be weakened.  However, both
>   features make it easier to reverse-engineer applications written in
>   Java.  Let me emphasize that I do not see this as a bad thing.

He's right.  In this respect there is absolutely no difference.  I
have Ada code that ports without changing a single character between
VMS, UNI*, and Win/NT.  With no "preprocessor" crap either.  The same
code.  That's pretty damn portable.  I could also just use AdaMagic
and get the exact same portability you mention via J-code/JVM as Java.
Really, Richard, you are completely in the weeds here.


>   Anyway, my main point is that Java's very benefits for interactive
>   software are also its drawbacks for secure software. It is a simple
>   trade-off. But it needs to be recognized.

Yes, I think we understand that is your point, it's just that it is
completely wrong.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Bob Crispen]

Jon S Anthony wrote:

>>   Interpreted code is relatively easy to reverse-engineer. Consequently,
>>   it is harder to protect proprietary algorithms.
>
>Really?  Presumably this is relative to machine code, but it is just
>plain not true.  If for no other reason than one implementation's
>"interpreted" code could become another's "machine" code.

Yup.  Having written a 6809 disassembler (wonderful chip!) and a Forth
decompiler, I can state unequivocally that disassemblers are easier.
And remember, I had all the Forth environment around, so it was no trick
at all to get the name from the compiled address.  But it's them ifs and
loops that getcha.  And Forth is scarcely a high-level language to begin
with.

But so I don't get mistaken by Robert Dewar for the first guy who mentioned
good old Forth here, let me ask him, are you sure the JVM is threaded?
It would seem like quite a waste of processor power, especially when you
don't need to do much fancy business like single stepping in the normal
course of events.  And it must be a nightmare converting addresses between
machines.  One reason Forth threading was fast was that you knew the exact
address where everything was.  Well I suppose I could go to the manual
and find out.

>This
>actually happened with P-code and there has even been some talk about
>it with respect to J-code.  Again, this just plain makes no sense.

Ditto for Forth.  Anybody remember the Forth machine?  It was a little
hummer.

Bob Crispen
crispen@hiwaay.net

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Richard Riehle]

I realize that I am out on a limb with this thread. But it may be worth
exploring just a little further.

On 31 May 1996, Jon S Anthony wrote:

> Sorry, this just plain does not make any sense.  All languages add an RTE,
> including (and in some sense, especially) Java.  What do you think the JVM
> is???

  OK. Now, when I distribute an application in bytecode, what is it that
  i am providing?  If I understand correctly, my bytecode is portable and
  can be executed by any platform with a bytecode interpeter.  If the
  standard for a bytecode interpreter is consistent from one platform
  to another, my application is truly portable. No compilation required.

  As new platforms, new processors, come on-line, all we need to do is
  write a new Java bytecode interpreter to run the existing application.
  Sounds good to me. I have no need to buy a license for your new version
  the application that you have targeted to the new platform.

  In certain Pacific-Rim countries, software piracy is a way-of-life; at
  least a way of doing business.  Anyone who believes that this is going
  to change is dreaming, or needs to change brands of peanut butter. Any
  model for the sale and distribution of commercial software that fails
  to acknowledged this fact, will have to endure its consequences.

  Additionally, the more a competitor can learn about the internal
  structure of your application, the easier it will be to make incremental
  improvements and being them to market quickly.  If this were only
  a domestic U.S. issue, we would simply engage the services of the hordes
  of underemployed lawyers.

> >   Interpreted code is relatively easy to reverse-engineer. Consequently,
> >   it is harder to protect proprietary algorithms.

> Really?  Presumably this is relative to machine code, but it is just
> plain not true.  If for no other reason than one implementation's
> "interpreted" code could become another's "machine" code.

  I agree with the latter sentence. However, bytecode is interpreted as
  if it were a kind of universal machine code.  All one needs is a
  bytecode intepreter.  Historically, machine code programs have been
  translated or emulated so they will run on new hardware. This is
  usually not as efficient as running in native mode.  If one writes
  a native mode bytecode interpreter, I would guess that there would
  be a somewhat more satisfactory outcome.

> This
> actually happened with P-code and there has even been some talk about
> it with respect to J-code.

  Yes, I do recall P-Code.  Interesting point. Not sure if it applies to
  this argument, though.

> Again, this just plain makes no sense.
> Now, you _can_ make an argument that the particular "interpreted"
> code, viz. J-code, itself has some interesting aspects where it
> maintains more "source" level type information than some other low
> level architecture (oh, say, a SPARC).  But even then, what you're
> claiming is a real stretch.

  So, can I write a bytecode interpreter for a brand X machine without
  permission from the author of the Applet?

> > > Saying that one language has a greater risk in disclosing intellectual
> > > property is just as misleading than saying that one language is more
> > > efficient than another.

  This analogy does not hold.  It is close to an apples and oranges thing.

> >   One of Java's premier virtues is is portability.

> He's right.  In this respect there is absolutely no difference.  I
> have Ada code that ports without changing a single character between
> VMS, UNI*, and Win/NT.  With no "preprocessor" crap either.  The same
> code.  That's pretty damn portable.  I could also just use AdaMagic
> and get the exact same portability you mention via J-code/JVM as Java.
> Really, Richard, you are completely in the weeds here.

  Still not the same thing. You cannot port your executable Ada program
  from VMS to Win/NT.  Once I publish an application and license it to
  you for your Win/NT, I defy you to execute it, without considerable
  trouble, on a VMS machine.

  At the source code level, Ada is emminently portable. No argument.
  So is Java.  Nor argument.  Java goes one step further and makes the
  executable portable becuase it can be interpreted by bytecode.
  Argument?    OK.  Now, which proprietary software product is more
  secure, the executable created from Ada source code, or the
  interpretable bytecode originating in Java?

  Jon, thanks for your ideas on this topic.  At some point, we will start
  to bore the others on this forum, and we can take it private. Meanwhile,
  I am still not certain that an interpreted language such as Java is as
  low-risk as a compiled language such as Ada, or even Eiffel.

  Richard Riehle

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Richard Riehle]

On 31 May 1996, Brian N. Miller wrote:

> In article <Pine.GSO.3.92.960530095503.21075A-100000@nunic.nu.edu>, Richard Riehle <rriehle@nunic.nu.edu> writes:
> |
> |  Java is BASIC for the next century.
>
> Now that's .sig worthy!

  Thanks. I actually think Java is a worthwhile contribution in
  the evolution of software tool-building.

> A disbelieve that C++ is evolving awkwardly.  Is there a publication
> which claims so?  Or is this 2-bit usenet opinion?  ;')

   It is probably a two-bit Usenet opinion.

   There are aspects of C++ that, as orginally  conceived by Dr.
   Stroustrup, make very good sense.  The fundamental idea of
   expanding the stuct into a class was a stroke of brilliance.

   Now, C++ is becoming a larger language than Ada. And the behavior
   of some of the new features seems to be making the possible
   interactions between those features more complex, and even more
   unpredictable.  In particular, the exception mechanism in C++
   is fraught with potential dangers.  There are other points one
   could make in this regard, but it would take to many pages to
   enumerated them all.

   It does amuse me, however, to read comments in periodicals that
   assume that C++ is less complex than Ada because "Ada was designed
   by a committee."  Of course, Ada was not designed by a committee,
   but no matter.  C++,as it goes through the ISO standardization
   process, also undergoes a transformation based on input from the
   international software community.  In the end, ISO C++ may end up
   as more the product of a committee than Ada.

   Richard Riehle

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Jon S Anthony]

In article <Pine.GSO.3.92.960602130408.12386B-100000@nunic.nu.edu> Richard Riehle <rriehle@nunic.nu.edu> writes:


Richard,

I sent you an extended version of this in email, but here are a few
bits for public consumption...


> >  All languages add an RTE,
> > including (and in some sense, especially) Java.  What do you think the JVM
> > is???
> 
>   OK. Now, when I distribute an application in bytecode, what is it that
>   i am providing?  If I understand correctly, my bytecode is portable and
>   can be executed by any platform with a bytecode interpeter.  If the
>   standard for a bytecode interpreter is consistent from one platform
>   to another, my application is truly portable. No compilation required.

This is equally true for any single platform (OS/HW combination, JVM, etc.)


>   As new platforms, new processors, come on-line, all we need to do is
>   write a new Java bytecode interpreter to run the existing application.
>   Sounds good to me. I have no need to buy a license for your new version
>   the application that you have targeted to the new platform.

Yes, but then how do you get the JVM for the new platform?  As things
are currently going it looks like this will thrown in as a kind of
loss leader.  Just like Windoze/X is for Intel based machines.  Again
in this respect there really is no difference.  Now for completely new
HW, it is true that JVM has an upper hand because it is a lot simpler
to build a new JVM (as software thing) than a new piece of HW - of
course it prolly has a lot more bugs in it too! :-)


>   translated or emulated so they will run on new hardware. This is
>   usually not as efficient as running in native mode.  If one writes

First, emulation is just another word for interpreted.  Second, the
efficiency issue depends on several things.  For example, there are
cases where Alpha boxes running NT can "emulate" x486 Windoze code
about as fast and sometimes faster than the real thing.  Lastly,
J-code is in the same boat.  If "emulated" it will always be slower,
but if cast in silicon it will be just another HW architecture.


> > actually happened with P-code and there has even been some talk about
> > it with respect to J-code.
> 
>   Yes, I do recall P-Code.  Interesting point. Not sure if it applies to
>   this argument, though.

The only reason it does is that it gives a another indication that
"interpretation" has nothing to do with any of the issues you raise.
None.  Is the silicon P-code machine code somehow harder to decode
than the interpreted version?  Don't see how.


> > Again, this just plain makes no sense.
> > Now, you _can_ make an argument that the particular "interpreted"
> > code, viz. J-code, itself has some interesting aspects where it
> > maintains more "source" level type information than some other low
> > level architecture (oh, say, a SPARC).  But even then, what you're
> > claiming is a real stretch.
> 
>   So, can I write a bytecode interpreter for a brand X machine without
>   permission from the author of the Applet?

Can't make out what you're asking here: are you asking about a JVM for
a new HW? or a new interpreter for a Applet?  what applet?  If Sun
licenses the JVM architecture for peanuts or nothing, then sure you
can hack a new JVM for arbitrary new HW.

The main point of my quoted comment here is that you can make a claim
that the architecture evinced by J-code *is* higher level than your
standard RISC HW.  To *that* extent you *can* claim that J-code is
*easier* to work with when attempting a "decompile".  But it would
still be a pain.  Besides, which actual code are you going to attempt
to reconstruct?  The Ada? Java? Eiffel?  X?  What do you have anyway?
You're not going to find it much easier getting at algorithms here
than from straight machine code.


>   At the source code level, Ada is emminently portable. No argument.
>   So is Java.  Nor argument.  Java goes one step further and makes the
>   executable portable

But the JVM is *not* tied to Java the language.  If you really want an
example of apples to apple pickers just compare Ada (or Eiffel or Java
the language or ...) to the JVM (or J-code).


>   becuase it can be interpreted by bytecode.
>   Argument?    OK.  Now, which proprietary software product is more
>   secure, the executable created from Ada source code, or the
>   interpretable bytecode originating in Java?

The executable generated from Ada source that runs on the JVM?  The
standard SPARC executable from Java (I seem to recall that there *is*
a native Java compiler available from a house in England, but in any
event they are surely coming)?  Or how about the available just in
time native compilation of J-code to native code?


>   Jon, thanks for your ideas on this topic.  At some point, we will start
>   to bore the others on this forum, and we can take it private. Meanwhile,
>   I am still not certain that an interpreted language such as Java is as
>   low-risk as a compiled language such as Ada, or even Eiffel.

The key point is that Java *the language* is no more interpreted (via
byte code or what-have-you) than Ada or Eiffel.  And the JVM has only
a peripheral connection to Java the language.  Just as there turned
out to be compilers for P-code and the PVM for all sorts of languages,
there will be for J-code and the JVM.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Ken Garlington]

Brian N. Miller wrote:
> 
> 
> A disbelieve that C++ is evolving awkwardly.  Is there a publication
> which claims so?  Or is this 2-bit usenet opinion?  ;')

See Plauger's comments in Embedded Systems Programming, for example.
(I'm not sure why an opinion in a publication is necessarily better
than one on the Internet, but nonetheless, there it is...)

-- 
LMTAS - "Our Brand Means Quality"

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Norman H. Cohen]

In article <Pine.GSO.3.92.960602134300.12386C-100000@nunic.nu.edu>,
Richard Riehle <rriehle@nunic.nu.edu> writes: 

|>    There are aspects of C++ that, as orginally  conceived by Dr.
|>    Stroustrup, make very good sense.  The fundamental idea of
|>    expanding the stuct into a class was a stroke of brilliance.

I disagree.  It is the confusion of classes and structs (along with the
confusion of class-as-type-definition and class-as-module) that leads to
absurdities such as the following: 

   class C {
      protected: 
         typedef ... T;
         static T x;  // perfectly legal
         struct S {
            T x;      // illegal: protected "member" T inaccessible inside
         } y;         //    a struct, despite nesting.
   }

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Imonics Corporation]

In article <4ov36b$1665@watnews1.watson.ibm.com>,
Norman H. Cohen <ncohen@watson.ibm.com> wrote:
>Richard Riehle <rriehle@nunic.nu.edu> writes: 
>
>|>    There are aspects of C++ that, as orginally  conceived by Dr.
>|>    Stroustrup, make very good sense.  The fundamental idea of
>|>    expanding the stuct into a class was a stroke of brilliance.
>
>I disagree.  It is the confusion of classes and structs (along with the
>confusion of class-as-type-definition and class-as-module) that leads to
>absurdities such as the following: 
  <coding anomaly deleted>
>Norman H. Cohen    ncohen@watson.ibm.com

I think you may have misunderstood.  What I got out of the
statement was that the conceptual expansion was a stroke of
brilliance, not that the details of a C construct being expanded
into a C++ construct was.

rc

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Richard Riehle]

Norman,

As you know, I am no advocate of the virtues of C++. However, I do
believe that, if one needed to extend C into a OOP language, the
decision taken by Stroustrop was, if not brilliant (I do tend to
hyperbole sometimes), at least intelligent.

The fact that it can lead to kind of absurdities illustrated in your
response, does not diminish the intelligence of the idea.  It simply
shows that there are ways to corrupt it through misuse. My position
vis a vis C++ has been that it is not well-suited to the development of
software that must work with consistent reliabilty.  And you have shown
an example to support that view.  It is unfortunate that C++ is so
vulnerable to exposure from such examples.  And it gets worse as new
features are added.  In particular, the exception handling in C++ is
a rather sad sight to behold.

On 3 Jun 1996, Norman H. Cohen wrote:

> In article <Pine.GSO.3.92.960602134300.12386C-100000@nunic.nu.edu>,
> Richard Riehle <rriehle@nunic.nu.edu> writes:
>
> |>    There are aspects of C++ that, as orginally  conceived by Dr.
> |>    Stroustrup, make very good sense.  The fundamental idea of
> |>    expanding the stuct into a class was a stroke of brilliance.
>
> I disagree.  It is the confusion of classes and structs (along with the
> confusion of class-as-type-definition and class-as-module) that leads to
> absurdities such as the following:
>
>    class C {
>       protected:
>          typedef ... T;
>          static T x;  // perfectly legal
>          struct S {
>             T x;      // illegal: protected "member" T inaccessible inside
>          } y;         //    a struct, despite nesting.
>    }

  OK, so my langauge is a little exagerrated sometimes.  I do think it was
  kind of a smart idea, even though it does lend itself to the kind of
  corrupt thinking illustrated in this example. In all honesty, very few
  C++ programmers would design a class with such an obviously ugly
  profile.

  All in all, thanks for a rather amusing example, though.

  Richard Riehle

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Bill Brooks]

In article <31B2B06A.43FE@lmtas.lmco.com>,
Ken Garlington  <garlingtonke@lmtas.lmco.com> wrote:
>Brian N. Miller wrote:
>> 
>> 
>> A disbelieve that C++ is evolving awkwardly.  Is there a publication
>> which claims so?  Or is this 2-bit usenet opinion?  ;')
>
>See Plauger's comments in Embedded Systems Programming, for example.
>(I'm not sure why an opinion in a publication is necessarily better
>than one on the Internet, but nonetheless, there it is...)
>
 
I too tend to disbelieve claims that C++ is evolving awkwardly, but
anyone who hasn't seen the <em> reams</em> of material published on
this topic must be living under a rock! The number of articles on the
error-proness of C++ exception handling alone could supply all the
material for a graduate level seminar. 

Start out with: <quote>The Evolution of C++: Language Design in the
Marketplace of Ideas</quote>, 1993, edited by Jim Waldo, which traces
the history of C++ from USENIX conferences to today's most popular
OOPL.  Waldo concludes that the language at one point had a clear
design center, but that it doesn't now.


-- 
"More computing sins are committed in the name of efficiency (without
necessarily achieving it) than for any other reason -- including blind
stupidity." -- Wm. A. Wulf

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Norman H. Cohen]

In article <Pine.GSO.3.92.960604155403.19912B-100000@nunic.nu.edu>,
Richard Riehle <rriehle@nunic.nu.edu> writes: 

|> >    class C {
|> >       protected: 
|> >          typedef ... T;
|> >          static T x;  // perfectly legal
|> >          struct S {
|> >             T x;      // illegal: protected "member" T inaccessible inside
|> >          } y;         //    a struct, despite nesting.
|> >    }
...
|>                                                 In all honesty, very few
|>   C++ programmers would design a class with such an obviously ugly
|>   profile.

But it's not an ugly profile, it's a perfectly reasonable idiom.  S and T
are strictly part of the implementation of class C, so the programmer
wants to keep them hidden in protected declarations.  The C++ code above
is the direct analog of the following Ada code: 

   package C is

      type C_Type is private;
      ...

   private

      type T is ...;

      type S is
         record
            x: T;   -- T is usable here even though hidden outside
                    --   of package C.
            ...
         end record;

      type C_Type is
         record
            y: S;
            ...
         end record;

   end C;

   package body C is
      ...
      x: T;  -- Corresponds to the C++ static member above, but is hidden
             --    in the package body, where it belongs.
      ...
   end C;

As an aside, here's the latest C/C++ pitfall to bite me: 
*** Error: Mixed metaphor.           ^^^^^^^    ^^^^

     char * six_string_guitar[6] =
        { "E string",
          "A string",
          "D string"
          "G string",
          "B string",
          "E string"
        };

Because of the missing comma following "D string" (did you notice it?),
six_string_guitar is actually quietly initialized to {"E string",
"A string", "D stringG string", "B string", "E string", 0}.  (Adjacent
string constants are concatenated, and default values--zero in the case
of a pointer--are used for missing elements in an initializer.)  What a
language!

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Bill Brennamw]

In article <4p44m2$tc5@watnews1.watson.ibm.com>,
Norman H. Cohen <ncohen@watson.ibm.com> wrote:
>As an aside, here's the latest C/C++ pitfall to bite me: 
>*** Error: Mixed metaphor.           ^^^^^^^    ^^^^

Of course you meant "pitbull to bite me".

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Alan Brain]

Bob Crispen <crispen@hiwaay.net> wrote:

>Ditto for Forth.  Anybody remember the Forth machine?  It was a little
>hummer.

No, but my Exidy Sorcerer, with a whopping 32K after I put in more memory chips, had 
a FORTH RomPac added soon after purchase. Vintage 1979.

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Bjarne Stroustrup <9758-26353> 0112760]

wbrooks@lwaxana.acs.calpoly.edu (Bill Brooks) writes

 > In article <31B2B06A.43FE@lmtas.lmco.com>,
 > Ken Garlington  <garlingtonke@lmtas.lmco.com> wrote:
 > >Brian N. Miller wrote:
 > >> 
 > >> 
 > >> A disbelieve that C++ is evolving awkwardly.  Is there a publication
 > >> which claims so?  Or is this 2-bit usenet opinion?  ;')
 > >
 > >See Plauger's comments in Embedded Systems Programming, for example.
 > >(I'm not sure why an opinion in a publication is necessarily better
 > >than one on the Internet, but nonetheless, there it is...)
 > >
 >  
 > I too tend to disbelieve claims that C++ is evolving awkwardly, but
 > anyone who hasn't seen the <em> reams</em> of material published on
 > this topic must be living under a rock! The number of articles on the
 > error-proness of C++ exception handling alone could supply all the
 > material for a graduate level seminar. 
 > 
 > Start out with: <quote>The Evolution of C++: Language Design in the
 > Marketplace of Ideas</quote>, 1993, edited by Jim Waldo, which traces
 > the history of C++ from USENIX conferences to today's most popular
 > OOPL.  Waldo concludes that the language at one point had a clear
 > design center, but that it doesn't now.

For a contrary view see

	Bjarne Stroustrup: The Design and Evolution of C++
	Addison Wesley ISBN 1-201-54330-3

by and large I think the committee has done an excellent job and that
ISO C++ will be a close approximation of what I hoped for.

	- Bjarne

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Robert Dewar]

I think it is important not to borrow ideas that seem attractive without
doing quite a bit of research to make sure that the idea is reasonable.
The complaint that the C++ design is out of control and/or is designed
by committee may be appealing to Ada fans, but just remember that lots
of people make the same (unjustified) comments about Ada.

In fact I think that in this regard the development of the two languages
is rather similar, with a strong central design, influenced, as is 
certainly appropriate, by community input, but certainly not dicated
by this input.

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Peter Wentworth]

In <4ov36b$1665@watnews1.watson.ibm.com> ncohen@watson.ibm.com (Norman H. Cohen) writes:

>In article <Pine.GSO.3.92.960602134300.12386C-100000@nunic.nu.edu>,
>Richard Riehle <rriehle@nunic.nu.edu> writes: 

>|>    There are aspects of C++ that, as orginally  conceived by Dr.
>|>    Stroustrup, make very good sense.  The fundamental idea of
>|>    expanding the stuct into a class was a stroke of brilliance.

>I disagree.  It is the confusion of classes and structs (along with the
>confusion of class-as-type-definition and class-as-module) that leads to
>absurdities such as the following: 

...

With natural languages I've never had too much concern that it might
be possible to construct ambiguous or difficult-to-understand absurdities.
I don't assess the quality of a violin on the basis that some hacker
might be able to make it sound bad by getting poor interaction between
the bow and two or more strings...

But there is a pervasive idea among many Computer Scientists that 
seems to assess the quality of a language in terms of whether 
they can find some interesting way to abuse it.  This particular
"evaluation paradigm" (and the usual text-book stuff of orthogonality
of base concepts, etc.) isn't necessarily God-given, written-in-concrete,
the one-and-only-true-way.

I think the C++ critics would get a much better hearing, at least from
me, if they tried to explain about those things they were not able to do 
cleanly or elegantly (and there are probably many!).  Anybody can write 
rubbish in any language.  So what? 

Peter
--
EP Wentworth - Dept. of Comp. Sci. - Rhodes University - Grahamstown - RSA.
cspw@cs.ru.ac.za               "If you come to a fork in the road, take it."
fax: +27 461 311915                                              Yogi Bear

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Brian N. Miller]

In article <4p44m2$tc5@watnews1.watson.ibm.com>, ncohen@watson.ibm.com says...
>
>Here's the latest C/C++ pitfall to bite me: 
>
>     char * six_string_guitar[6] =
>        { "E string",
>          "A string",
>          "D string"
>          "G string",
>          "B string",
>          "E string"
>        };
>
>Because of the missing comma following "D string" (did you notice it?),
>six_string_guitar is actually quietly initialized to {"E string",
>"A string", "D stringG string", "B string", "E string", 0}. 

How about this one which prints nothing because mispelled 'default:'
is treated as a goto label:

enum {red,white,blue} color = white;
switch (color) {
   case red:  printf("red"); break;
   case blue: printf("blue"); /* Fall thru */
   defualt: printf("blue or other color");
};

Re: Java Risks (Was: Ada News Brief - 96-05-24

[Jim Kingdon]

(I probably have something better to do than following up, but....)

    How about this one which prints nothing because mispelled 'default:'
    is treated as a goto label:

    enum {red,white,blue} color = white;
    switch (color) {
       case red:  printf("red"); break;
       case blue: printf("blue"); /* Fall thru */
       defualt: printf("blue or other color");
    };

My compiler catches this:

bash$ gcc -Wall def.c 
def.c: In function `main':
def.c:9: warning: enumeration value `white' not handled in switch
def.c:8: warning: label `defualt' defined but not used
bash$