🚀 go-pugleaf

philstep@ix.netcom.com wrote:
> 
> I have resisted learning C++  for long time because  I've considered it
> too complex. Sure, operator overloading is powerful, but doesn't it
> allow  a  programmer to essentially createhis *own* language that
> only *he* understands?  Sure, pointers are powerful,  but they seem to
> cause more problems than they solve (particularly  in a competitive
> software market, where it is important  to get a product to market FAST,
>  never mind thoroughly debugging it.)  I'm happy that Java strips out
> some of the more complex aspectsof C++.  But, will people dump C++ for
> Java?  I sure  hope so. I  can hang my hat on Java.


Java is significantly less complex than C++, from a programmer
perspective.  Here are my thoughts on some of the issues you
raised:

1. Operator overloading

Many people think of this as a "powerful" feature.  In my experience,
operator overloading is, as you say, a way for a programmer to create
their own language.  In effect, operator overloading introduces a
form of "shorthand notation" into C++.

Is this powerful?  It is intended to be *conceptually* powerful,
allowing
users to easily understand operations like "Complex + Complex".
Operator
overloading does not add significant functionality to a language,
however.
Overloaded operators are just methods... you can implement identical
functionality using "regular" methods.

I am glad that Java does not have this feature.  Java already
has enough complexity; the more the language avoids unnecessarity
complexity, the more room there is for the *necessary* complexity.


2. Pointers

Pointers in C++ are a legacy of C.  They allow you to do a great many
things..... including shooting yourself in the foot in an infinite
variety of ways.

Let's face it.  Most modern programming languages have enough
expressivity
to allow you to write the programs you want to write.  It all comes down
to how difficult the task is in any particular language.  With C/C++,
you
must spend a great amount of time and energy worrying about pointers:
null pointers, un-initialized pointers, pointer arithmetic, pointers to
stack memory, pointers to heap memory, pointers to uninitialized memory,
pointers to de-allocated memory, pointer casting, pointers and data type
sizes, etc..  You spend a lot of time writing pointer-safety checks and 
using tools (ObjectCenter, Purify, BoundsChecker, etc.) to verify that
your code is not abusing pointers.

Part of Java's strength lies in the fact that that the programmer does
not have to worry about physical pointers.  Pointers (references) in
Java have no machine dependencies.  You don't even have to worry
about crashing the entire process when de-referencing a null pointer
(you just handle the NullPointerException).  A Java pointer/reference
is either null, or it refers to an object that is guaranteed to be
type-compatible with the reference.

On the flip side, part of what make applications easy to build in any
particular programming language are the tools and libraries available 
in that language.  In this respect, Java lags way behind C/C++.  The
tools are only now starting to become available.  If you adopt Java
now, you might be faced with building many of the tools/frameworks
that exist as off-the-shelf packages for C/C++.  In many situations,
these off-the-shelf packages will mean less overall development time
in C/C++ vs. Java.


3. Memory Management

You didn't touch on the issue of memory management, but I feel that
this is one of the strongest selling points of Java.  C/C++ programmers
spend so much time chasing memory leaks.... and designing and
re-designing their code to perform proper memory management.

Explicit memory management may be efficient for some applications.  It
may also be highly practical in some realms (like real-time systems).  

But for the majority of applications, explicit memory management is a
major headache.  These applications become *much* easier to construct
once the programmer is freed from the burden of explicitly managing
memory.


4. Threads and Monitors

C and C++ have very little to say about thread management, and less
to say about synchronization.  These are usually implemented as
external libraries..... with different APIs on different platforms.
Using threads and semaphores makes C/C++ applications much less
portable and much more difficult to debug.

Java, however, has a built-in threading and synchronization model.
The Java VM deals with the platform dependencies.  I recently wrote
a multi-threaded request queue in 1/2 hour in Java, just about as
fast as I could type it.  The code is portable to all platforms the
JVM runs on.  If I were to try this in C++, it would probably have
taken me 1 week to write the code, plus another week to port it to
other platforms.

I can't wait to see performance benchmarks for JIT compiled Java,
using native threads, running on a multi-processor machine.  You would
probably be able to beat the performance numbers with well written
C/C++, but then again, you could probably beat well written C/C++
using well written assembly language.  :)



5. What about Smalltalk?

Everything I've mentioned so far (with the exception of *real*
threading)
can also be said of Smalltalk.

In fact, Smalltalk is *way* ahead of Java w.r.t. many issues:  JIT
compilation, advanced graphical framework, development environments,
toolkit availability, database connectivity, stability, market share,
etc..

Java does have the jump on Smalltalk in other areas:

  * There is no unity in the Smalltalk market.  There are
incompatibilites
    between the major Smalltalk environments (VisualWorks, VisualAge,
    Enfin, etc.).  Java has unity, for now.  And Sun is intending to
    keep it that way, by allowing the Java name to be used only for
    "compliant" implementations.

  * Smalltalk still has a polling model for graphical interaction.  From
    what I hear, there is work going on to replace this with an event-
    driven model, but it's not here today.  The Java AWT is already
    event-driven.

  * Smalltalk does not use native threads.  Sun has already delivered
    native threading for Java/Win32.  I hear that sun is working on this
    for Solaris.  It would be logical to assume that Java will use
    native threading whenever possible.

  * Smalltalk does not yet have the byte-code security necessary for
    Internet executable content.  Java was [re]designed for this.

  * Java has been embedded in the Netscape browser.  As of today, you
    can write Applets that will execute over the Web on a Netscape
    browser.  Smalltalk can not make this claim.


For now, Smalltalk is probably a better choice for application 
development.  For Internet Applet development, however, the choice
is clear.


The question "Will Java Kill C++?" can really be expanded to:
"What effect will Java have on C++ and Smalltalk?"

I don't know the complete answer.  Java solves a number of problems
that programmers face.  If you were to attempt to build a major 
application in Java today, however, your programmers would face
difficulties that have already been solved in C++ and Smalltalk.

To further complicate the question, will Java expand from its
niche market (Internet executable content) to become a full-fledged
application development language?  Will people take it seriously
as such?

Java has promise.  But it will take time and energy to convert on
this promise.  The existing tools have to stabilize.  The graphical
library (AWT) must improve.  And many, many vendors need to
introduce commercial-quality software development tools/libraries.
In addition, the JDBC specification must deliver secure access
to corporate data.

Java also has momentum.  And along with that, media attention.  Yes,
there is a lot of hype, but that means that people are getting
excited about the language.  Nothing encourages investment in a
technology like *continued* media attention.


I haven't been around the computer industry long enough to predict
with certainty what will happen, but I doubt that Java will completely
uproot any existing language.  That's just too expensive.  Today's hot
technology will become tomorrow's legacy system (supporting an entire
arm of the consulting industry).  Some development will shift gradually
to Java, as the language stabilizes and offers more development tools.
Will it be C++ or Smalltalk that loses more to Java?  Intuitively, I
would say that C++ will be the first to lose programmers to Java.  Java
is syntactically similar to C++, so C++ programmers easily learn Java.
But Smalltalk will also lose programmers to Java if the major Smalltalk
players don't address the "Internet executable content" issue.

It will be an interesting next couple of years, at any rate.


-eric