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

["Kevin Lawton" <kepla@btinternet.com>]

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:
||| "Kevin Lawton" <kepla@btinternet.com> wrote in message
||| news:bcplc6$b5e$4@titan.btinternet.com...
|||| One thing I have noticed is that
|||| programming languages seem to evolve to absorb the processing power
|||| available to them. Assembler and C are massively powerfull and
|||| efficient, but require much skill to use properly. The result is
|||| small fast programs which can get the best performance out of the
|||| hardware they are running on.
|||
||| 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. 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. A
bubblesort is more suited to working on reasonably small numbers of items.

|| 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.

|| 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.

| 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). I do believe that there are hardware platforms available like
this, but don't think they are really relevent to this discussion.

|| 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 and quality of documentation produced. 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.