Re: Low-level vs. High-level programming (was My First Computer)

[pausch@saaf.se (Paul Schlyter)]

In article <bcs938$sbn$5@titan.btinternet.com>,
Kevin Lawton <kepla@btinternet.com> wrote:
> Paul Schlyter <pausch@saaf.se> wrote:
>| In article <bcqv6a$d0a$4@sparta.btinternet.com>,
>| Kevin Lawton <kepla@btinternet.com> wrote:
>|
>|| Kelly Hall <hall@priest.com> wrote:
..................
>||| In my opinion, *programs* can be fast and efficient; programming
>||| languages themselves are rather neutral.  For example: a good
>||| programmer can implement a fast and efficient algorithm in Java that
>||| would outperform a bad algorithm in C.
>||
>|| I think it would take a brilliant Java programmer and an extremely
>|| bad C algorithm for that situation to arise.
>|
>| Not at all: you could do it yourself!  For instance, implement a
>| bubblesort in C and a quicksort in Java, and sort a large number
>| of items.  Which code do you think will run fastest?
> 
> I'm not too sure how the quicksort in Java works internally.
 
The assumption was you shouldn't use any built-in algorithm but
implement one yourself, in Java.
 
> It would not be exactly brilliant programming practise to use a
> bubblesort in C to sort a very large number of items.  In fact, I
> don't think it a particularly great idea to use a bubblesort to
> sort large numbers of items in any language.
 
Of course not!  So we can agree bubblesort is here an "extremely
bad algorithm".  And one wouldn't need to be a brilliant Java
programmer to write a quicksort which outperformed a bubblesort
written in C.
 
Choosing an appropriate algorithm is _THE_ greatest optimization one
can perform on any given problem.  One cannot, by using other
optimization techniques, compensate for a badly chosen algorithm.
Heck, even a quicksort written in interpreted BASIC would outperform
a bubble sort written in carefully hand optimized assembly language,
if the number of data items to sort was large enough!!!!!
 
> A bubblesort is more suited to working on reasonably small numbers
> of items.
 
But of course..... :-)
 
>|| My point was that given programmers of reasonably similar competency,
>|| the C code will be smaller
>|
>| I don't think so - Java bytecode is actually quite compact.
> 
> Because it is not the whole program as seen by the platform, just
> instructions to be executed in the JVM.
 
Well, you can say the same about so-called "native machine code": it's
not the whole program -- a lot more is present in the hardware CPU
which is to interpret and execute this machine code.
 
> 
>|| and quicker than the Java.
>|
>| THAT will depend on the platform.  And it'll be very very hard to
>| find a Java compiler and a C compiler which produces code for the
>| same platform -- then you'd need to find either a C compiler emitting
>| Java byte code, or a Java compiler emitting native code.
> 
> Yes, because the Java compiler produces byte-code for the JVM to execute.
> So, the JVM has to be included as part of the resulting applicatin which the
> platform sees. Consider the 'platform' to be the hardware plus the operating
> system, and the application to be the software and any run-time environment
> needed to execute it. In just the same way, a machine running a BASIC
> program has to make room for the BASIC interpreter as well as the program
> itself.
 
I think we have different definitions of "platform" here: I consider
the JVM and its environment a platform of its own.  That platform has
not, AFAIK, been implemented directly in hardware but is emulated,
using software running on another platform.  That's no news really --
people running Apple II emulators do the same with the Apple II
platform.  Does that mean the Apple II isn't a platform of its own?
Of course not!  Likewise the JVM is also a platform of its own.
 
Of course, interpreting one platform on another platform carries
a burden of software, and of execution speed.  That's valid when
emulating the Apple II platform as well as the JVM platform.
 
>| The main disadvantage of Java here is the lack of an actual hardware
>| platform able to directly execute Java bytecode.
> 
> Obviously, that would make a massive difference as the relationship
> between the Java bytecode and that platform would be like an
> executable to a processor. The instructions would be understood by
> hardware (well, microcode).
 
Thus there's still a level of interpretation present, even on a
so-called "hardware CPU"....
 
> I do believe that there are hardware platforms available like
> this, but don't think they are really relevent to this discussion.
 
Why not?  Their presence makes the JVM a platform of its own, just
like other hardware platforms.  True, they're rarely used because
they're not that common -- just like most Apple II software today
are run on emulators rather than actual Apple II hardware.
 
And even without the presence of these JVM hardware CPU's, the JVM
would still be a platform of its own - why?  Because it has a very
careful specification, both of the bytecode itself and of the
virtual environment within which this bytecode is supposed to run.
A good JVM must follow this specification carefully.
 
>|| Also, I would not expect the C programmer to take much longer than
>|| the Java programmer to write their program, though Java programmers
>|| appear to be paid a littlew more than C programmers. Net result,
>|| similar development costs but less efficient Java programs.
>|
>| Wait a little here -- the development costs doesn't merely include
>| "writing the program" -- it also includes debugging and maintaining
>| the program.  And here Java offers a lot of advantages: array bounds
>| overflow are always caught, and memory management is automatic.  Some
>| of the most hairy bugs in C programs (particularly large and complex
>| programs) often include "wild pointers" or memory leaks, but this can
>| never happen in a Java program.
> 
> This, to a large degree, depends on the skill and expertise of the C
> programmer
 
THE programmer ?????
 
You seem to implicitly assume all programming projects are small
enough for one single programmer to be able to handle it.  That may
be true for most hobbyists projects, and in such a case the skill and
expertise of the programmer of course matters a lot.  However,
whenever you're developing software in a commercial project, i.e. in
a situation where someone actually pays for the time the coding
takes, and when there also often are tight demands for the project to
be finished to some specified date, one rarely assigns one single
programmer to the project.  Instead a team of programmers are
allocated, and they may even reside in different parts of the world.
Also, they often don't write all code by themselves but use
third-party libraries written earlier by others.  Even if each and
every one of these programmers are skilled experts, there will still
be misunderstandings when they communicate with one another.  If they
use a programming language like 'C', a lot of these errors won't be
discovered until the final code crashes or behaves erratically while
executing.  If they instead use a language like Java, most of these
errors will be caught by the compiler, while integrating the program.
 
> and quality of documentation produced.
 
Skilled programming experts frequently don't enjoy writing good
documentation.... :-)  Yep, that's a fact: if you require of each
and every one of your programmers that they shall be both skilled
programming experts and very good documentors, then I think you'll
find it very hard to find enough programmers for any merium-sized
to large project....  It's not an ideal situation, of course, but
in programming as well as in other human activities, we'll have to
deal with ... human error.
 
> You say that memory leaks can 'never happen' within Java. I recall
> seeing a Java application running on the Java 1.2 JVM which would
> gradually 'eat up' the available memory on the machine it was
> running over a couple of days untill the whole system eventually
> went down. The Java program was the core of a messaging system
> which needed to run 24 x 365. I am sure that a bad or stupid enough
> programmer can get Java to leak memory away merrily, it's not
> impossible to circuumvent garbage collection.
 
OK, I'll take that back: a thread which never deallocates a particular
memory block but also stops using it will of course cause a memory
leaks, and a large enough number of such threads may of course
cause real trouble by these leaks.
 
However, it's much easier to create memory leaks in C since there
you must explicitly deallocate your memory blocks in your code,
and since programmers aren't perfect, they will sometimes forget
to do that.  In Java, memory blocks are deallocated automatically,
and as a result memory leaks will be much rarer.  But of course
they MAY happen, as you correctly pointed out above.
 
In C you can also do another thing which is impossible to do in Java:
you can deallocate a memory block and then try to use it later
anyway.  Or you can try to use a pointer which hasn't even been
initialized yet.  This is indeed impossible to do in Java, because
taht language don't have pointers.  At least not explicit pointers
which can be freely manipulated at the Java source code level (an
object reference in Java is of course really a pointer, but the
pointer semantics is handled by the language; the programmer need
not worry about it).
 
-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://www.stjarnhimlen.se/
         http://home.tiscali.se/pausch/