On Java and C++

[Noah Roberts]

I cannot abide a lack of civility.

Doesn't seem to stop you from being plenty proficient at it.

 

[Chris Smith]

Java references, or whatever you call them behave EXACTLY like C++ pointers.

Sorta. There are, obviously, fewer operators defined to operate on a
Java reference than on a C++ pointer.

References in C++ are just pointers that are automatically dereferenced. (I
mean from a usage standpoint, if it is handled differently somehow in the
compiler I am not aware of it.)

The problem is not usage versus compiler viewpoints. The problem is
that you are introducing a more complex concept (a pointer) in order to
explain a less complex concept. A C++ reference isn't any kind of thing
at all -- it's just a name, used to signify some other thing that
already exists. The new name (the reference) can be visible in a
different scope, but it is still the same thing.

C++ references CAN be described as pointers, except that operators and
type conversions and method overload resolution and so forth all act
differently on them. Then again, I could just as validly describe a
Java int as a String, except that the "." syntax for accessing methods
or fields is illegal, than <, <=, >, >=, -, <<, >>, >>>, and so forth
are defined, that == and != do different things, that type conversions
and method overloads and so forth act differently on them, etc. There
are an infinite number of possible and valid mental models that can be
coerced into making sense to describe the behavior of a language with
sufficient complexity, but that doesn't means it's always reasonable to
think of things according to those models. References can be easily
understood by someone who's never heard of pointers. They are not
pointers, even if it remains possible to describe their behavior in
terms of pointers.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Tor Iver Wilhelmsen]

There is no language C/C++.

It was shorthand for "C or C++". For someone promoting less clutter in
languages you sure seem unable to "parse" common English with reduced
clutter.

You missed the point. If an editor can parse your code and predict what you
are trying to do, then the language could too. The language itself could
finish these lines, and all I'd have to do is start them.

I notice your English sentences are full of words that can be omitted
without changing its meaning, since they can be implied. Why is that?
Do you prefer a readability in English that you would deny in
programming languages?

log4j's src folder has 31,764 lines of code.

Ah. The "this book is better than that book because it's shorter"
argument?

log4r's src folder has 2,071 lines of code.

Noone disputes Ruby code can be more compact than Java code. The
question is whether something - like readability - is lost in the more
terse code.

Again you missed the point. 'virtual' is a weak, primitive keyword
that I can use to assemble a class or an interface. I can control
how concrete and how abstract the class is. Just because I _should_
create interfaces doesn't mean the language should _force_ me to.

Why not? You are forcing yourself to use grammatically correct
English, knowing that plenty of the words you write can be omitted or
replaced by symbols or abbreviations. Like this:

"Again: missed pt. 'virtual' = weak, prim. kwd. I can use 2 assemble
class/interf. I can ctrl. how concrete+abstract class is. I
_should_ create interf. != language _force_ me 2."

See how much space you could save?

(Try playing a MMORPG like World of Warcraft sometime - it's amazing
how compact English can be written using "u" for "you", "r" for "are"
etc.)

You cannot legislate morality. (You _can_, however, legislate immorality!)

It's legislating readability and understanding among developers. A
language that invites a million different ways of doing things takes
the disease of unmanageability with it. I want to learn a language,
not a language plus the particular habits of ten developers who worked
on code before me. Even C++ dev houses decide upon a limited set of
ways to do things.

Write an Any or Variant class in Java.

Are any of those used in other ways than Object is in Java? "A Rose by
any other name" etc. You could probably make something using
Proxy/InvocationHandler and a Map to hold values.

You have insufficient experience with block closures.

No, I have used Smalltalk. Don't pretends something doesn't exist just
because the syntax is different. It's the same way you can implement
multiple inheritance of implementation in Java using nested classes:
People just don't "see" it because the syntax would be too different
from C++.

A GUI should be event-driven.

Java's are, whether AWT or Swing. Haven't programmed SWT but I guess
they use it as well.

Block closures make those as easy as falling off a log.

No, they just invite a terser syntax than Java's. Again, a book
doesn't become better from being shorter.

Most of the code you write in a static-typing OO language, for a
GUI, is excess plumbing to route events to handlers, and then excess
plumbing to convey state variables into handlers.

Correct - in a way. Except it's not "excess" but a consequence of
language design.

Block closures simply turn that problem inside out. The language
does the plumbing, and all you need to do is add the custom
behaviors.

But you lose Java's event system's listeners' access to the listeners'
code, unless the closure delegates to code in the listeners, in which
case your closure has just taken on the role of AWT and Swing's event
dispatchers.

It seems you are against static typing (with its compile-time checking
and implicit documentation of argument values and return types)
because you are willing to take the risk of catching type errors only
at runtime in order to get the terser syntax of dynamic type
languages. The question is whether it's the programmer's needs or the
customer's needs that are at the forefront in software engineering...

 

[Mraco G.]

Im sometimes amazed at how many people seem to know.
mostly its the "CV" effect.
People put gazillions of languages in their CVs to make it look
impressive.
it turns out the "Assembler" experience is the 3day homework they did
in college some years ago... PHP and SQL Experience come from the
private homepage they copy pasted to sho off their "world".
Java is mostly Java script that was ripped off some site to put a cool
menu to the homepage...
i mean i think the sentence:
"Most of the messages in this thread appear to be written by people who
only know one programming language."
is meant like:
you know this language well and have worked full time with it in a
professional environment for some years.
gosh, i do work like that with C++ and can definitely understand and
code C if i have to without problems... but i would not say i "know" C.
i could not design a bigger system from scratch taking full advantage of C.

I could also write a good dozen of languages i've worked with in the
last years... but im only proficient with 3 or 4 of them.
Guys stay in the ground.

I also think every language has its strenghts and weaknesses.
True knowlegde of the language means also knowing which language suits
best fo the desired task.
There is no better or worse.
Alone discussing about that show a lot of your knowledge and so i say:

WillemF wrote:
"Most of the messages in this thread appear to be written by people who
only know one programming language."

FULL ACK!!!

 

[Tor Iver Wilhelmsen]

Oracle, for example, provides both a pure Java driver and a driver
that uses JNI, but I don't know of anyone using the latter.

That's because the JNI driver requires Oracle client software to be
installed on the computer, and java.library.path to point to its
libraries (either explicitly or implicitly). Too much hassle when the
"thin" driver works fast enough.

(I guess the OP can argue that at some point pure Java JDBC drivers
need to use a Socket, and then you delegate to the native
implementation of that - but that would be being argumentative for the
sake of it.)

 

[Tor Iver Wilhelmsen]

Java has two adressing modes - one for the ints and one for the
objects. And this approach is simple but with drawbacks.

No, the modes are the same: Values are put on the stack. The
difference is that an object "value" (the pointer) can be further used
to get values from that object - ints cannot.

If you insist the addressing modes are different, feel free to
demonstrate.

 

[Tor Iver Wilhelmsen]

The day we have a programming language that is so good a monkey could
produce quality software with it is the day we have won.

No, then we get replaced by monkeys, and have to drive taxkis to make
a living. Unless cars get so automated monkeys can drive them, too.

 

[Raymond Haeb]

I actually laughed out loud when I read the above. That's very rare
for me. The punchline, that making Java more like C++ would *reduce*
confusion, was very unexpected.

Why would you need explicit notation to differentiate between Foo and
Bar if a given environment has only Foos and no Bars?

Because it has Bars and just hides them, so that the user (programmer)
does not see them. But it would be (imo) better to clearly differentiate
between both.

Raymond

 

[Andrew McDonagh]

Because it has Bars and just hides them, so that the user (programmer)
does not see them. But it would be (imo) better to clearly differentiate
between both.

Raymond

no - it just has foos.

'there is no spoon'

 

[Chris Smith]

Because it has Bars and just hides them, so that the user (programmer)
does not see them. But it would be (imo) better to clearly differentiate
between both.

No, it doesn't have both. This is why it's important to really learn a
language and understand it before pretending to know it. You can
understand Java in C++ terms, if you like, but you will see a very
complicated language. Heck, you could insist on understanding LISP in
C++ terms, if you so desire. The resulting complexity is not a
necessary consequence of the language; it exists because you've picked
the wrong mental model to understand the language.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Andrew McDonagh]

No, it doesn't have both. This is why it's important to really learn a
language and understand it before pretending to know it. You can
understand Java in C++ terms, if you like, but you will see a very
complicated language. Heck, you could insist on understanding LISP in
C++ terms, if you so desire. The resulting complexity is not a
necessary consequence of the language; it exists because you've picked
the wrong mental model to understand the language.

oh come on now - my 'there is no spoon' is much funnier!

 

[Jerry Coffin]

Im sometimes amazed at how many people seem to know.
mostly its the "CV" effect.
People put gazillions of languages in their CVs to make it look
impressive.

That depends -- some of us learn a lot of languages
simply because languages we learned early on have gone
out of style to some degree or other. Back when I was a
whole lot younger, I wrote a fair amount of code in
FORTRAN IV, Pascal, SNOBOL, APL, and assembly languages
for PDP-11's, CDC Cyber mainframes and most of the old 8-
bit CPUs (6502, 8080/8085/Z80, etc.)

Most of these are simply of little or not practical use
for what I'm doing now -- my choices were to learn new
languages or start some entirely different occupation.

[ ... ]

i mean i think the sentence:
"Most of the messages in this thread appear to be written by people who
only know one programming language."
is meant like:
you know this language well and have worked full time with it in a
professional environment for some years.

Personally, I think that's a bit excessive. In fact, the
requirement that you work with it full-time for some
years more or less makes it a tautology that nobody
really CAN know more than one language by this
definition. If you use two languages on a regular and
ongoing basis, clearly you're using each of them only
part of the time.

[ ... ]

I also think every language has its strenghts and weaknesses.
True knowlegde of the language means also knowing which language suits
best fo the desired task.
There is no better or worse.

IMO, you're displaying a high level of ignorance here. Go
study Brainfuck or Intercal, and then try to keep a
straight face while you claim they're not worse!

 

[Mraco G.]

Personally, I think that's a bit excessive. In fact, the
requirement that you work with it full-time for some
years more or less makes it a tautology...

Well i do also worked with some amount of languages for a while... but i
know the difference between "I wrote a fair amount of code" and "I
worked with this language for a couple of years".

IMO, you're displaying a high level of ignorance here. Go
study Brainfuck or Intercal, and then try to keep a
straight face while you claim they're not worse!

well fine... then tell us which is the master language, that 0wnz all
other? you seem to know.

 

[Jerry Coffin]

[ ... ]

well fine... then tell us which is the master language, that 0wnz all
other? you seem to know.

Not at all -- as I pointed out, some are worse. I'm not
at all sure that means there's one that's better than all
others. If there is, I'm not at all sure what it would
be.

 

[Bent C Dalager]

No, then we get replaced by monkeys, and have to drive taxkis to make
a living. Unless cars get so automated monkeys can drive them, too.

I expect we are referring to different 'we's

I wouldn't mind if programming became so easy I could be replaced by a
monkey. I can always find something else interesting to do, and it
would do miracles for society if software development projects became
effectively free.

Cheers
Bent D

 

[Jerry Coffin]

I expect we are referring to different 'we's

I wouldn't mind if programming became so easy I could be replaced by a
monkey. I can always find something else interesting to do, and it
would do miracles for society if software development projects became
effectively free.

While I agree, I don't think it's a reasonable
expectation or even goal. I don't think I'm even going
out on a limb very far to say that nothing we can hope
for in the way of a programming language will really make
much difference in this regard. The real difficulty
involved in a software project is rarely writing the
code. The real difficulty is deciding what the software
should do. Perhaps I lack imagination, but I don't see
much way for a language to help much in making that kind
of decision -- in fact, most of it is entirely
independent of any programming language at all.

 

[Tomás]

Computers are great, but they lack one thing: Intelligence. If you want them
to do something, you've to tell them EXACTLY what way to do it -- they don't
take any hints.

Monkeys have intelligence, but not as much of it as we humans do --
therefore we'll always be the better programmers.

So, maybe if you wanted cheap programming, you could approach the monkey
industry, and if you wanted high-quality programming, you could approach the
few remaining human programmers (assuming the monkey industry kicks off).


-Tomás

 

[Oliver Wong]

IMO, you're displaying a high level of ignorance here. Go
study Brainfuck or Intercal, and then try to keep a
straight face while you claim they're not worse!

Brainfuck and Intercal are not "worse" at what they were designed for:
to be difficut to program and maintain in. In fact, these languages are,
IMHO, one of the best for the task of confusing the programmer and the
reader. Use the right tool for the job and all that.

- Oliver

 

[Noah Roberts]

Actually, your example from before shows that i MIGHT change. At least
logically change.

class I{
int & handle;
public:
I(int& x):handle(x){};
void morph()const{
handle++;
}
void dump(){
cout<<handle<<endl;
}
};

void foo(I i){
i.morph();
}

I guess you could argue that it was the int& that changes. But clearly,
the state of the original i is not the same before and after that call.

Actually, considering this further I in fact does not change, neither
logically nor semantically. The object that handle refers to is not
part of I. I itself cannot change and won't...this is guaranteed
(short of the mutable keyword). What is not guaranteed is that an
immutable object won't mutate any other object that is mutable. I
believe this is a good thing.

Clearly, the state of the original i is the same both before and after
that call. Nothing about i has changed but objects that i refers to
have...and i itself made those changes. The value of the object handle
refers to is not part of the state of i.

The above case is actually perfect for explaining why... If in fact
the value of the int handle refers to where part of I instances then it
would not be necissary, nor wanted, to use a reference. The fact that
i accepts a non-const reference to an int and assigns it upon
construction to its own non-const reference to that same int means that
int is not a part of I instances and is not intended to be. This int
should be, and is by the compiler, considered a reference to an
_external_ entity. Such entities cannot be considered a part of I
instances, only the references can be...and that reference couldn't be
changed even if it where implemented in the form of a pointer, which
unlike references can be reseated.

To further illustrate the point:

int x = 5;

I i(x);

x = 7;

x has been changed without talking to i in any way...therefor it is not
a part of i and cannot be considered to be so...logically or otherwise.
If alterations to the value of x cause i to change its behavior it is
because i's behavior is based on an external input...not because this
value is part of i's state.

 

[Earl Purple]

There are many strange features in this chart. Why C always so much
higher than C++?

Probably because they count most C++ as C programmers too, with the
common notion that people program in C/C++. C is thus higher when you
add in those who program only in C.

And then there are all those device-driver programmers.