On Java and C++

java-programmer, On Java and C++ On 28 Apr 2006 00:59:19 -0700, "al pacino" <email***@***.com>
wrote, quoted or indirectly quoted someone who said :

>improve your programming skills and what better tool to do that than
>using c++.

You might find the work of W. Edwards Deming interesting. He was the
man who taught the art of quality control to the Japanese.

He argues there is no point in exhorting people to be better. You
have to change the environment so they naturally and without
additional effort produce better results.

C++ allows well made programs but does little to insist on or even
encourage them. The beautiful quality remains a theoretical goal
rarely achieved. It is a bit like an impressive high wire act.

You can see the effect. If you look over C++ code you will see a huge
range of quality. If you look at Java code it is much more uniform.
The artisan in you yearns for the sporadic brilliance, but the manager
prefers the uniformity.

As a programmer you see the effect. In Java, a higher percentage of
trouble is caught at compile time. Once you have the compiler happy,
usually the code works. Because of the null pointer checks, enforced
initialisation and subscript checks, if a program works at all there
is a higher probability it is working correctly than the equivalent
C++ program. That means a poor programmer who writes buggy code has a
bigger safety net with Java to watch over him to catch these errors.

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

java-programmer >> On Java and C++ On 28 Apr 2006 00:59:19 -0700, "al pacino" <email***@***.com>
wrote, quoted or indirectly quoted someone who said :

>improve your programming skills and what better tool to do that than
>using c++.

You might find the work of W. Edwards Deming interesting. He was the
man who taught the art of quality control to the Japanese.

He argues there is no point in exhorting people to be better. You
have to change the environment so they naturally and without
additional effort produce better results.

C++ allows well made programs but does little to insist on or even
encourage them. The beautiful quality remains a theoretical goal
rarely achieved. It is a bit like an impressive high wire act.

You can see the effect. If you look over C++ code you will see a huge
range of quality. If you look at Java code it is much more uniform.
The artisan in you yearns for the sporadic brilliance, but the manager
prefers the uniformity.

As a programmer you see the effect. In Java, a higher percentage of
trouble is caught at compile time. Once you have the compiler happy,
usually the code works. Because of the null pointer checks, enforced
initialisation and subscript checks, if a program works at all there
is a higher probability it is working correctly than the equivalent
C++ program. That means a poor programmer who writes buggy code has a
bigger safety net with Java to watch over him to catch these errors.

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

java-programmer >> On Java and C++
"Noah Roberts" <email***@***.com> wrote in message
news:email***@***.com...
>
> Roedy Green wrote:
>> On 27 Apr 2006 10:54:17 -0700, "Noah Roberts" <email***@***.com>
>> wrote, quoted or indirectly quoted someone who said :
>>
>> >Yes, but all the benefits you are listing are things you *can't* do and
>> >the things forced upon you. Where are the list of things you *can* do?
>> > You make Java sound like a jail sentance.
>>
>> Team coding and coding on your own are quite different experiences. I
>> presume you work mostly on your own. The conventions are very useful
>> to prevent bloodshed between team members. They are just accepted and
>> you get on with something more important to fight about.
>
> I don't see how your assertion applies to my quoted statement above.
> If you want to be understood I suggest you make your point more
> clearly.

I think Roedy is saying that when you work in a team, there are certain
things you can't do (e.g. ignore the conventions of the team). Java helps
you not do those things (by establishing a convention, as opposed to having
each team coming up with their own, so you have to relearn conventions when
switching teams). Or something along those lines.

>
> I also don't see how my quoted statement above would lead one to
> believe I have never worked in a team...but whatever. It is clear you
> don't have any good, and valid, arguments for you assertion that Java
> is better than C++. This is frankly not surprising to me as such
> assertions are always riddled with illogic and falacy.

I don't think Roedy asserted that "Java is better than C++". See
http://en.wikipedia.org/wiki/Psychological_projection

- Oliver

java-programmer >> On Java and C++
"Noah Roberts" <email***@***.com> wrote in message
news:email***@***.com...
>
> I'm still looking for the can. You listed all the thing Java *can't*
> do but haven't come with anything it can. I don't see much advantage
> in *can't*.

That you can't shoot yourself in the foot (or at least not as easily as
in some other languages) seems like a big advantage to me.

- Oliver

java-programmer >> On Java and C++
Oliver Wong wrote:
> See
> http://en.wikipedia.org/wiki/Psychological_projection

Ahhh yes, the last ditch attack from the weak. I grant you that it
appears to be a big gun as there is no way to argue against it...any
such attempt is of course also projecting. But only the unintelligent
cannot see it for what it is; I'll count you among them.

java-programmer >> On Java and C++
Roedy Green wrote:

> However, I know C++ is not the best choice for many others. I know
> from first hand, rather than second hand experience. For a start,
> there is not even such an animal as a C++ Applet.

Holy crap, you people actually comming up with a can??!! Almost
anyway...I'll count it.

Took you long enough...damn!!!

> There is nothing
> comparable to rich set of GUARANTEED PRESENT class libraries.

Of course there is something comparable. The whole second half of the
C++ standard specifies the GUARANTEED PRESENT class (and other object
type) libraries.

> C++ is
> hopeless at platform-independent code.

Not even remotely true.

java-programmer >> On Java and C++ In comp.lang.java.advocacy, peter koch
<email***@***.com>
wrote
on 27 Apr 2006 14:51:39 -0700
<email***@***.com>:
>
> The Ghost In The Machine skrev:
>
> [snip]
>> "finally" is to RAII as manual transmission is to
>> automatic, from the looks of things.
>
> Not at all. RAII is to finally what a printing machine is to a pen.
> RAII simplifies a nontrivial and tedious task. Or do you always check
> for your objects being of the IDisposable type before deciding if you
> can leave their destruction to the garbage collector or if you will
> have to destroy them manually?
> If not - how will your program cope with classes that change?
> Also - how do you write generic code if you do not know if you will
> have to destroy your objects - except than by using run-time
> information?

How indeed? The best Java can do in that department is
a dispose() method (Swing) -- and that's not supported
in the language, unlike C++'s virtual destructor. finalize()
is overridable but it's never clear exactly when that will
be called.

[.sigsnip]

--
#191, email***@***.com
Windows Vista. Because it's time to refresh your hardware. Trust us.

java-programmer >> On Java and C++ Martin Vejn醨 <email***@***.com> wrote:
> Could you please give me equivalent Java code for this...
>
> // C++
> func()
> {
> class_with_possible_ressource cwpr, cwpr2;
> dosomethingwith(cwpr, cwpr2);
> }
>
> ...and for this?
>
> // C++
> func()
> {
> class_with_possible_ressource cwprs[1000];
> dosomethingwith(cwprs);
> }

No. :) I think you already know the answer. The latter would generally
be done by modifying the structure a bit. If there's really a need to
hold all those resources open at the same time, then some kind of
aggregate class could be written whose close method attempts to close
all of the resources in a collection.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

java-programmer >> On Java and C++
Roedy Green wrote:
> On 27 Apr 2006 16:16:20 -0700, "Noah Roberts" <email***@***.com>
> wrote, quoted or indirectly quoted someone who said :
>
> >I also don't see how my quoted statement above would lead one to
> >believe I have never worked in a team...
>
> I would think anyone who had ever worked on a team was familiar with
> the ego battles that go on especially over how code should be
> formatted. You would have seen the necessity of deciding on project
> coding conventions to keep people from each others' throats.
>
> You made several comments of form "conventions are like a
> straightjacket", which indicated you had never experienced a situation
> where you needed them or where pre-existing conventions eased the
> tensions.
>
> You appeared to believe they had no value at all.
>
> You also sounded independent and argumentative, not the type of person
> who can stand working in a corporate team environment for very long.
> You have to bite your tongue till it bleeds.

This entire avenue of argument is not only riddled with ego and
argumentative remarks but it is also entirely beside the point even if
true.

java-programmer >> On Java and C++ Mishagam wrote:
>>
>> OK. True, the D language has cleaned up old C inheritances C++ suffers
>> from. However, I doubt anyone would switch to D unless you provide a
>> large class library for almost everything. That's the only true
>> benefit of Java, the large std library.
>>
> Yes, large standard library helps. However Perl, Python, C# have
> something close.
> I would give additional benefits (for me).
> a) You don't have to think should you include fields of have variables
> as objects or references or pointers. It is decided for you usually
> close to optimal way (closest to references).
> b) You don't have to bother to use auto_pointer (not working with
> collections) or new delete or automatic destructor. It is decided for
> you to use something like auto_ptr but much better.
> c) You don't have to decide about programming style. Sun provided
> standard Java style.
> d) You don't have to decide about naming of files and classes - they are
> the same.
> e) Logical package directory structure is forced on you.
> f) You don't have to choose between char *, string, CString ... - String
> is better (or same) than either of them and it is only choice.
> g) you don't have to choose between long int, unsigned int, WORD, DWORD,
> size_t .... - close to optimal choice if forced on you.
> h) You don't decide do you use internal or external functions
> definitions, or do you use macro. - close to optimal choice if only one
> possible.
> i) You don't have to decide if you use methods or define new operators.
> Java choice is sometimes more verbose, but usually more clear.
> ...
> As you can guess, I can continue.
> Dropping all these choices first - makes programming easier, you have
> less things to bother about, second - makes language smaller and more
> easy to understand. Of course such approach could lead to very bad
> language - but Java luckily has good design. And I thing C++ standard
> committee just made bad design - introducing complexities which doesn't
> add enough benefits to justify them.
And of course one of main items:
j: In Java you generally don't have to think how to report error - you
throw Exception. In C++ you have different conventions for different
systems changing over time. Some programs return NULL or 0 or -1 or
SIGNALS ..., Microsoft COM programs returned HRESULT, lately C++ started
using exceptions, but I am sure it is still only one of choices. I don't
know, but doubt that C++ exceptions are as convenient as in Java. Of
course this result of Java being designed later when exceptions already
were well known .

java-programmer >> On Java and C++ peter koch wrote:
> Roedy Green wrote:
>> However, I know C++ is not the best choice for many others. I know
>> from first hand, rather than second hand experience. For a start,
>> there is not even such an animal as a C++ Applet. There is nothing
>> comparable to rich set of GUARANTEED PRESENT class libraries. C++ is
>> hopeless at platform-independent code.
> I do agree that Java probably should be used for client side web-based
> programming.
> That said there is ATL which COM which is used extensively in those
> area - resulting in platform dependent code, of course.
>
> /Peter
If you are talking about IE ActiveX controls they were also responsible
for a lot of security breaches (I am not expert here), because C++ and
specifically ActiveX controls don't have Java Applets inherent security.

java-programmer >> On Java and C++ Noah Roberts schrieb:
> Oliver Wong wrote:
>> See
>> http://en.wikipedia.org/wiki/Psychological_projection
>
> Ahhh yes, the last ditch attack from the weak.

You are the only one who takes this discussion for a battle. Oliver
didn't attack you, he just tried to help you realizing what is going on.

Timo

java-programmer >> On Java and C++
"Alf P. Steinbach" <email***@***.com> wrote in message
news:email***@***.com...
>* Roedy Green:
>> On Fri, 28 Apr 2006 01:19:40 +0200, "Alf P. Steinbach"
>> <email***@***.com> wrote, quoted or indirectly quoted someone who said :
>>
>>> Apart from the lack of connection from premise to conclusion, that's not
>>> a fact, it's an excuse for sloppiness.
>>
>> In java, memory leaks and packratting are quite different problems and
>> require quite different tools to detect them and quite different
>> solutions.
>
> Exactly how can the memory leak that cannot exist, be detected and require
> a different solution?

If Roedy had written "require quite different sets of tools and quite
different sets of solutions", would that have been better? Then you could
say that for problems which do not exist, the appropriate sets are the empty
sets.

Obviously, if one problem can occur, and another problem cannot occur,
then they must be different problems, which I believe was Roedy's main
point, even if he failed to express it properly.

>
>> If you wished, you could make the same distinction in C++, but you
>> don't because the distinction does not matter so much for C++.
>
> On the contrary, in C++ it's meaningful to talk about different kinds of
> memory leaks, such as when there's still a reference somewhere, what you
> call a "packrat", and when there's no reference anywhere. If the case of
> no reference couldn't exist, as in Java, then it would be meaningless to
> distinguish it. That distinction is meaningless for Java.

(Ditto as above, I think what Roedy meant is clear, though he may have
not have expressed it in a way that you wanted).

>> there is no way on earth you will convince us that C++ memory
>> allocation is easier and more fool proof, especially when you don't
>> even claim to know Java.
>
> I have not made the claims you assert. I don't believe that you talk on
> behalf of "us", as you imply.

Maybe this is a psychological phenomena, but when I read "us", I had
assumed he was referring to "Java folks" (perhaps because I am one of those
Java folks). I think there's a lot of emotional energy here which may cause
us to say things we wish we hadn't (where we here is both Java folks and C++
folks). There's too much of an us-versus-them mentality going on, and it's
very easy for a Java person, posting from a Java newsgroup, to see an
unfamiliar name, and think "must be some C++ fanatic" and vice versa.

> Perversely, I hope you're trolling.

If you go through the Google archives of comp.lang.java.programmer,
you'll see Roedy has a pretty good track record of being a helpful
contributor to the Java community. I don't suspect him of trolling. Rather,
I suspect these kind of threads bring out the worst in us.

- Oliver

java-programmer >> On Java and C++
Roedy Green wrote:
> On 27 Apr 2006 10:59:36 -0700, "Noah Roberts" <email***@***.com>
> wrote, quoted or indirectly quoted someone who said :

> The big advantage of the Java approach is it FORCES you to write
> cleaner code.

> Your name Noah, suggests you might be the son of fundamentalist
> parents. Fundamentalists are people who are utterly convinced their
> faith is the one true faith, and guarantee they never change their
> opinion by scrupulously avoiding studying any others.

Another totally unrelated ad hominem. You are obviously a very stupid
person. I base this on your method of argument, your inability to
argue effectively, your inability to comprehend simple statements, and
your overwhelming supply of idiotic assumptions that have nothing,
whatsoever, to do with the purported evidence.

...there is ample evidence in your own statements to support that you
are in fact an idiot.

Interesting set in this last post of yours though...bring up Java's
nature to force you into doing something the way a set of people
decided where best and then call ME a fundamentalist - you have no
evidence to support that statement except the fact that there was a
famous and important Hebrew that shared my namesake but your own
statements lend some support to the argument that in fact you are very
likely a fundamentalist as well as a facist.

Irony can be a facinating thing.

Yes, this is also a personal attack having nothing to do with the
topic, however, instead of grasping at staws in an attempt to discredit
you based on assumed ansestry and upbringing I am simply pointing out
the fact that you already discredited yourself through your own words
and methods.

You loose, no question about it. Of course this has no bearing on the
usefulness of the Java language...it only means you are a piss poor
advocate of it and not a particularly intelligent or nice person.

java-programmer >> On Java and C++
Oliver Wong wrote:
> "Alf P. Steinbach" <email***@***.com> wrote in message
> news:email***@***.com...
> >* Roedy Green:
> >> On Fri, 28 Apr 2006 01:19:40 +0200, "Alf P. Steinbach"
> >> <email***@***.com> wrote, quoted or indirectly quoted someone who said :
> >>
> >>> Apart from the lack of connection from premise to conclusion, that's not
> >>> a fact, it's an excuse for sloppiness.
> >>
> >> In java, memory leaks and packratting are quite different problems and
> >> require quite different tools to detect them and quite different
> >> solutions.
> >
> > Exactly how can the memory leak that cannot exist, be detected and require
> > a different solution?
>
> If Roedy had written "require quite different sets of tools and quite
> different sets of solutions", would that have been better? Then you could
> say that for problems which do not exist, the appropriate sets are the empty
> sets.
>
> Obviously, if one problem can occur, and another problem cannot occur,
> then they must be different problems, which I believe was Roedy's main
> point, even if he failed to express it properly.

That is really grasping at straws. Using set theory to weed out a
meaning you like from a the rewording of a statement. If we were in
the middle of an argument about abstract math then maybe it would have
its place...but we are not.

java-programmer >> On Java and C++ "peter koch" <email***@***.com> wrote in message
news:email***@***.com...

Very interesting post, Koch. I've snipped the parts I've agreed with, and am
only including some concerns I have about C++ and clarifications on Java.

>
> I do not
> understand why each class MUST have its own file (unless you make that
> class a secondary citizen).

Actually, only the top level public classes should be in their own
files. Private classes, or nested classes, can be within any file. I suspect
the reason why is primarily a pragmatic one: So that the classloader can
easily locate the file that contains the bytecode for the classes and load
them.

It has some nice side effects. When I'm given someone else's code base,
and I have a qualified class name, I always immediately know the full path
to the source code file. I don't even have to browse a directory listing or
anything like that.

>
> There are three kinds of lies. Lies, statistics and benchmarks.... or
> so I've heard. The nice thing about C++ strings is that the number of
> characters in a string is a O(1) operation. In Java, you would have to
> check the number of surrogates making it a O(n) operation. Also C++
> strings are more powerful than Java strings. All in all I believe I'd
> prefer using C++ strings, switching to some specialised class in the
> unlikely case string-handling did turn up to take a significand part of
> my programs execution time.

I'm surprised unicode-stuff would appear as an advantage of C++ over
Java. I won't dispute this, since I don't know enough about the state of C++
libraries, but I was under the impression that the lowest common denominator
for C++ was ASCII, while the lowest common denominator for Java was the BMP
(Basic Multilingual Plane) portion of unicode.

I can't speak for others (e.g. archeologists, etc.), but I've never used
characters characters outside the BMP. For example, while I am interested in
writing text in English, French and Japanese, I am not interested in writing
in cuneiform, cypriot, or byzantinne musical notation. So I've never had a
problem with text in Java applications.

However, I have had problems with C++ applications which assumed ASCII.
WinAmp is one example. It has trouble handling the ID3 tags of my Japanese
songs. iTunes seems a bit better at this. *SOMETIMES* it properly renders
the kanji characters, but other times the track name will show up as a bunch
of question marks.

So I was under the impression that C++ support for unicode was behind
Java, not ahead of it. I guess times have changed.

> Javas type system is not freedom but rather a jail. It has prevented
> porting of Java to several platforms, it gives cumbersome Unicode
> support and it forces Java to stick with inefficient 32-bit integers in
> a world that is soon turning to 64 bits.

In its defense, I think the fact that the size of Java's primitive
datatypes remains constant is a "good thing". If an when you want to use a
64 bit datatype, you'd simply use "long" instead of "int". And I don't think
there's any technical reason why, in a few years from now, if 128 bit were
desired, a new datatype couldn't be added to Java to support that, without
breaking any previous code (except possibly via the addition of a new
keyword, which could no longer be used as a variable or method name).

The company I work at, Castor Technologies, makes some money by porting
C code from 32 bit platforms to 64 bit platforms. The fact that we're making
money must mean it's too painful for our clients to do the migration
themselves. I don't know if this C situation applies to C++ as well.

- Oliver

java-programmer >> On Java and C++
Mishagam wrote:
> peter koch wrote:
> > Roedy Green wrote:
> >> However, I know C++ is not the best choice for many others. I know
> >> from first hand, rather than second hand experience. For a start,
> >> there is not even such an animal as a C++ Applet. There is nothing
> >> comparable to rich set of GUARANTEED PRESENT class libraries. C++ is
> >> hopeless at platform-independent code.
> > I do agree that Java probably should be used for client side web-based
> > programming.
> > That said there is ATL which COM which is used extensively in those
> > area - resulting in platform dependent code, of course.
> >
> > /Peter
> If you are talking about IE ActiveX controls they were also responsible
> for a lot of security breaches (I am not expert here), because C++ and
> specifically ActiveX controls don't have Java Applets inherent security.

Yes, Applets have to be given to Java as something it can do that
current incarnations of C++ cannot. I do not know that this is
inherent to the language or more because of the way Java is normally
processed.

Also it must be mentioned that flash is also used quite a bit in this
area and in fact, in my opinion at least, results in better output.
Flash "applets" seem to work better on more platforms than Java. Hell,
at home where I use Linux I will use Flash but won't even bother with
installing the Java plugins because much of the time the applets just
don't function well.

However, flash is much more expensive for the devolper, who doesn't
even have to pay for the JDK but has to pay a fortune for flash. When
I write applets it is with Java, not Flash and certainly not C++. But
when I write cross-platform code that won't be running in a browser
most of the time I use C++, not Flash, and not Java (though sometimes I
think about that as an alternative).

java-programmer >> On Java and C++
"Noah Roberts" <email***@***.com> wrote in message
news:email***@***.com...
>
> Oliver Wong wrote:
>> See
>> http://en.wikipedia.org/wiki/Psychological_projection
>
> Ahhh yes, the last ditch attack from the weak. I grant you that it
> appears to be a big gun as there is no way to argue against it...any
> such attempt is of course also projecting. But only the unintelligent
> cannot see it for what it is; I'll count you among them.
>

Taken in context, you wrote:

<quote>
It is clear you
don't have any good, and valid, arguments for you assertion that Java
is better than C++.
</quote>

and I wrote

<quote>
I don't think Roedy asserted that "Java is better than C++". See
http://en.wikipedia.org/wiki/Psychological_projection
</quote>

Assuming that I am correct in thinking that Roedy did not make the
assertion you claim he made, what would you call your behaviour, if not
psychological projection?

Alternatively, perhaps he DID make that assertion somewhere, and I had
forgotten about it, or perhaps that particular message never arrived at my
newsgroup server. If so, I apologize for any offense I may have caused you
by suggesting that you might have been projecting.

I don't mind if you think I'm "weak" or "unintelligent". My goal wasn't
to earn your praise, but rather to point out a possible source of the
apparent disagrement you're having with Roedy.

- Oliver

java-programmer >> On Java and C++
Luc The Perverse wrote:

> You can't use 6th grade rhetoric to try to convince a group of people who
> have been using Java for years that suddenly it "sucks" because you say so.

Quote me saying that.

Simple request...

You won't...because you can't...because I never said it.

Come back when you can understand.

java-programmer >> On Java and C++ The Ghost In The Machine wrote:
> In comp.lang.java.advocacy, peter koch

>> Not at all. RAII is to finally what a printing machine is to a pen.
>> RAII simplifies a nontrivial and tedious task. Or do you always check
>> for your objects being of the IDisposable type before deciding if you
>> can leave their destruction to the garbage collector or if you will
>> have to destroy them manually?
>> If not - how will your program cope with classes that change?
>> Also - how do you write generic code if you do not know if you will
>> have to destroy your objects - except than by using run-time
>> information?
>
> How indeed? The best Java can do in that department is
> a dispose() method (Swing) -- and that's not supported
> in the language, unlike C++'s virtual destructor. finalize()
> is overridable but it's never clear exactly when that will
> be called.
I understand that RAII is basically use automatically called
destructor's to dispose resources? I agree it is useful where it can be
used.
It works if you work with objects as values, it doesn't work if you work
with pointers or references. In such cases destructor can easily leave
dangling pointer. If you work with references you are on your own, or
have to duplicate something like reference counting or Java GC. I don't
think you can work without using references in big program.
I think because of this STL mostly works (in examples) with value
elements, and this creates a lot of problems - you cannot place
descended class objects were you can place base objects, you have to
deal with constructors, destructor's, copy constructors called in
strange places, you waste memory and so on. Also, you have to have
different generated code for different objects and use templates. And in
Java one Collections library works OK with any object.

java-programmer >> On Java and C++ peter koch wrote:

> I agree here. Readability matters a lot. And here C++ is a clear
> winner, due to its more advanced features such as templates, operator
> overloading and RAII,

You are joking, Right?

java-programmer >> On Java and C++
Bent C Dalager wrote:
> In article <email***@***.com>,
> Noah Roberts <email***@***.com> wrote:
> >
> >I know all about that. Point is that it was asserted that C++ is not
> >as good as Java because Java binary code will run on some processors
> >but C++ source code won't.
>
> That is an assertion that may exist inside your head, but you will not
> actually find it in this thread.

Really? I guess you never said the following then:

"Interestingly, of course, while there are no CPUs that support C++
instructions natively (that I know of anyway), there are those that
support Java bytecode natively. The conclusion being that while it is
possible to have a pure Java system, it is not possible to have a pure
C++ system :-) "

Now, that statement can only be talking about C++ source code as all
other forms of C++ come in the form of binary codes meant for execution
by a CPU or in the intermediate object form, also composed primarily of
CPU instructions but without enough total information to be a true
executable...sort like pulling a Java .class file out of its package
and trying to run it.

At any rate, no matter how you slice it...the comparison is purposfully
scewed, being a compiled form on one hand and something other than a
complete compilation on the other...it's a red herring, and not a very
good one.

java-programmer >> On Java and C++ On 28 Apr 2006 08:37:45 -0700, "Noah Roberts" <email***@***.com>
wrote, quoted or indirectly quoted someone who said :

>
>That is really grasping at straws. Using set theory to weed out a
>meaning you like from a the rewording of a statement. If we were in
>the middle of an argument about abstract math then maybe it would have
>its place...but we are not.

You are not a programmer at heart. You would make a better lawyer.
They get paid to deliberately misinterpret.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.