Re: Help me!! Why java is so popular


Some belated "just curious" questions here .... :



My first experience with Java was about 1996 when for grits and shins
*** schnipp ****
buffer" --

String or StringBuffer?

String. Before I get flamed, keep in mind I knew NOTHING about Java.
I picked up a Java Unleashed or some rot that was laying around,
perused it, figured String was the same as "char string[BUFSIZE];" and
so I used it. The language accepted it, no warnings, and thus I
figured it was all good.

I know now about immutability and such, I know now about garbage
collection, etc. It's not enough to understand syntax and semantics,
there's meta knowledge about how objects behave that's bigger than any
data structure in C, and more impactful than most (but not all) of
those in C++.



I know a lot of Java experts are shaking their heads,

Well, I'm no Java expert, just someone with intermediate-level
experience with the language, but -- I don't spot anything about
your pseudocode that's obviously bad. ?

What's bad is the String class is immutable -- rereading into the same
buffer forced instantiation of a new String object every time.

A fair change in the C program would have been instead of doing "char
buffer[sizebuf];" type of thingy, to do :

char* buffer = malloc(buffer);
read(buffer);
search(buffer);
free(buffer);

That was inherent in the way String was used, but not blatantly
obvious to this programmer when coding the application at that time.

StringBuffer in place of String would have been closer to "char
buffer[sizebuf];"


Dramatic results, all right. It might be interesting to repeat this
test sometime .... Hm, it might be interesting to first repeat it
using your original code (since Java compilers / runtime systems
have improved) and again with code written using what you now know
about Java.

I'm going to do some benchmarking this week (time permitting) because
this thread has really sparked an interest in me.


Of course today I know using a String was bad and that a StringBuffer
would have been better,

It would? You're not changing the contents of the lines you read
from the file, so how would a StringBuffer be better?

The StringBuffer would not be reinstantiated each time causing the
garbage collector to run like a squirrell on crack. The original app
innocently violated good Java programming best practices.

plus declaring an Object inside the loop was
causing GC to run nonstop I imagine.

But, of course, you're not doing that; you're declaring an object
reference.

But forcing a "new" each time. A StringBuffer outside of the loop
instantiated once would circumvent some of the problems I experienced.


I'm not convinced that this makes Java different from other languages,
though. It seems to me that there are two issues here: whether
familiarity with the language's quirks can have a dramatic impact
on performance, and quality of implementation (compiler, library,
runtime system if any).

The difference between using a Vector and an ArrayList, for instance,
is that Vector has an inherent lock. You won't tend to find that in
char, char* to buffer, struct&, struct* in C, or object&, object*, etc
in C++. A COBOL PIC X(1000) or COBOL PIC X OCCURS 1000 TIMES wouldn't
get you either. Some objects in Java are orders of magnitude more
efficient and you need to be aware of that when you use them.


With regard to whether familiarity with the language's quirks can
affect performance, the obvious answer is "of course it can" -- and
I don't quite get how Java is different from C++, or any other
language, in that regard.

With regard to quality of implementation, well, as I said above,
I wonder whether if you repeated your tests now you would get the
same results. As I understand it, and as others have described,
changes to Java implementations over the years have resulted in the
potential for much better performance.

I did something along similar lines a few years back -- rewrote a C
program to compute something Mandelbrot-set-related (in which most
of the computation involves calculations using complex numbers) in
C++, specifically so I could replace the ugly use of two doubles to
represent each complex number with instances of a class for complex
numbers, complete with appropriate operator overloading. The resulting
program was a lot prettier but was slower by a factor of about 1.5.
To me this was a convincing demonstration that there *are* situations
in which it's a good idea to focus more on performance than on making
the code pretty, and I cited it often. Not too long ago, though,
I repeated this experiment and found .... that the C++ program ran
just as fast as the original C. So much for my nice example!
I guess my point is that claims about performance maybe have to be
re-evaluated from time to time. <shrug>, maybe.

[ snip ]


I think it's about understanding effects.

For instance, in some native assemblers you can peruse the instruction
set and find that choice of instruction can effect performance. A DIV
by a factor of 2 is far less efficient than a SHR. IBM's 360/370
instruction sets contain some peculiar instructions that were built to
enhance COBOL. The EDTMK (I might have that mneumonic wrong -- been a
LONNNNNGGG time) can take packed data and make it into a character
string with dollar signs, commas and decimal points in one statement.
But your data has to be packed decimal to use it. Packed decimal is
not as good for math operations as binary. So you'd need to know that
so you could either convert to packed just before your EDMKs or leave
it packed all the time.

The avg person would only care if it "worked" or not -- realtime
system programmers go nutz when they see inefficiencies at this level.

There's lots of collections that will work in the same algorithm, but
which one you chose and how you apply it can really make a big
difference. From the languages I know, this kind of data structure
choice is more prevalent by far with the Java runtime than with
anything else I've used.

.

Relevant Pages

  • Re: my mother wants to code?
    ... There are more languages that have C-like syntax (C, C++, Java, C# etc.), while Ruby's syntax is less transferable. ... If she doesn't get programming in Java, you might say to her "can ... that ability to abstract problems into code, in which case language ... You have to explain a dozen foreign, arcane and useless concepts, only to output a string on the console. ...
    (comp.lang.ruby)
  • Re: References and comparisons
    ... I am saying that until a budding programmer does encounter String ... that they do not have full claim to be called a Java programmer. ... Java as a language ... think of the pooling mechanism with constant expressions, ...
    (comp.lang.java.help)
  • Re: OT: Why is C so popular?
    ... and I love Java. ... > say that Java is the perfect language. ... string and strings are so cool so we convert everything else to a ... You can get my public key from any of the ...
    (Debian-User)
  • Re: question about assigning null to a reference object
    ... String getAuthor() ... void setAuthor ... b.setTitle("Thinking in Java 4th Edition"); ...
    (comp.lang.java.help)
  • Re: Java questions: Urgent
    ... why I would expect almost any Java programmer to be able to answer ... Which is the main reason I "butted" in a bit.. ... on the characters in the String. ... > therefore naturally cover all the basics, or they have missed out badly ...
    (comp.lang.java.programmer)