operator overloading

[Arne Vajhøj]

1962, actually. Logical operators first appeared in FORTRAN IV.

This is before I was born, but I find it difficult to see how
they could use Fortran for much without .eq., .ne. etc..

Arne

 

[Mark Thornton]

Another possibility would be an IDE that can display certain
Java prefix expression as an infix expression in an edit box.

It knows about BigDecimal and can learn about the operators
and precedence rules for other classes from annotations.

This has been done before: Some word processors have an
internal language for mathematical terms and contain WYSIWYG
formula editors for them.

It has been suggested many times. One concern is that without the
special IDE the resulting code may be unreadable.

Mark Thornton

 

[Mark Thornton]

This is before I was born, but I find it difficult to see how
they could use Fortran for much without .eq., .ne. etc..

Arne

They had an arithmetic if statement (from memory)

if(expr)labelNeg,labelZero,labelPos

The target label depended on the value of the expression. If negative
the first label was used, zero the second and positive values used the
third target. All the labels were of course integers.

Mark Thornton

 

[Andreas Leitgeb]

I'm thinking "lazy people." People who think that typing is a lot of
work and anything at all that can be done to cut down on programmer
typing (as opposed to the maintainer's effort) is a good thing. Or at
least it's kewl.

Almost correct, except that those people think that their cutting
down on typing effort actually *HELPS* also those who maintain
the code later.

 

[Stefan Ram]

http://en.wikipedia.org/wiki/Arithmetic_progression#Sum_.28arithmetic_series.29
Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2.

The transcription of such term sometimes matters:

»July 28, 1962 -- Mariner I space probe. A bug in the
flight software for the Mariner 1 causes the rocket to
divert from its intended path on launch. Mission control
destroys the rocket over the Atlantic Ocean. The
investigation into the accident discovers that a formula
written on paper in pencil was improperly transcribed into
computer code« ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

http://www.wired.com/software/coolapps/news/2005/11/69355

 

[Tom Anderson]

^ ^
This might break down if the methods mutate n; not if if they create new
objects for the results.

Yes. Also, the arithmetic operation would also break if arithmetic
operators mutate their operands, rather than creating new values.

Personally, i read it as implicit in both cases that they didn't.

tom

 

[Tom Anderson]

1962, actually. Logical operators first appeared in FORTRAN IV.

Dammit! When i posted that, the back of my mind was saying "ah, but did
the original fortran have those operators?", but i dismissed it as the
kind of thing that's unlikely to be the case, and even less likely to get
caught if it is. Wrongly!

tom

 

[Tom Anderson]

I'm thinking "lazy people." People who think that typing is a lot of work
and anything at all that can be done to cut down on programmer typing (as
opposed to the maintainer's effort) is a good thing. Or at least it's kewl.

So any class that has an "add" method will get overloaded versions of + just
in the name of kewl.

List myList = new List();
myList + "List Item 1";

instead of

myList.add( "List Item 1" );

Then they'll overload - for remove() because if one is kewl then two are even
kewler. And they'll overload ^ for contains() and % for toArray() and
that'll be sooperkewl. And then someone will overload << for toString()
because some *other* language they saw on the *internet* has it and then
it'll all have gone to s--t.

As i said before, and will keep on saying: THIS HAS NOT HAPPENED IN ANY
LANGUAGE WITH OPERATOR OVERLOADING OTHER THAN C++. Not in python, not in
smalltalk, not in ada (that i've heard), not anywhere. Why do you think
it'll happen in java when it hasn't happened in those languages?

And I mean individual programmers will sub-class existing (API) classes, and
writing their own classes. I'm sure Sun would never stoop to this. But
there's a lot of really, really lazy programmers out there, and I don't mean
that in a good "laziness is a virtue" way.

Do you think that java programmers are, on average, more stupid than
python, smalltalk or ada programmers?

Actually, i could believe that. Java being the big industrial language
that every idiot who doesn't fancy a career in McDonald's or Iraq is
learning, and the others being a bit more niche and sophisticated.

Some one else on this thread said that the Java community was composed
of traumatized C++ programmers. And say that's a good thing. I like to
learn from my mistakes, not repeat them.

Agreed. So let's learn from our mistakes and use operator overloading
without abusing it. Not having operator overloading is like giving up cake
because you once ate so much you were sick - don't give up cake, just
practice moderation in consuming it. I don't see why we shouldn't have our
cake and eat it too.

tom

 

[Patricia Shanahan]

The transcription of such term sometimes matters:

»July 28, 1962 -- Mariner I space probe. A bug in the
flight software for the Mariner 1 causes the rocket to
divert from its intended path on launch. Mission control
destroys the rocket over the Atlantic Ocean. The
investigation into the accident discovers that a formula
written on paper in pencil was improperly transcribed into
computer code« ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

http://www.wired.com/software/coolapps/news/2005/11/69355

I don't think anything is totally error free. I do think that the closer
the computer language form is to the original mathematical formula, the
better the chances of doing the transcription correctly.

Patricia

 

[Mark Space]

As i said before, and will keep on saying: THIS HAS NOT HAPPENED IN ANY
LANGUAGE WITH OPERATOR OVERLOADING OTHER THAN C++. Not in python, not in
smalltalk, not in ada (that i've heard), not anywhere. Why do you think
it'll happen in java when it hasn't happened in those languages?

I think "disaster hasn't struck yet" is a poor counter argument. I
suppose the engineer in me wants to make certain that disaster doesn't
strike, with a comfortable margin of error.

I like to design things that can't fail, not things that rely on above
average execution by the user.

Actually, i could believe that. Java being the big industrial language
that every idiot who doesn't fancy a career in McDonald's or Iraq is

Bingo. Java is far more popular than Smalltalk, Python, etc. Masses =
lower average IQ, even if it's just from time pressure to get projects done.

learning, and the others being a bit more niche and sophisticated.

I should have said "And I say that's a good thing." Messed up the
semantics there.

Agreed. So let's learn from our mistakes and use operator overloading
without abusing it. Not having operator overloading is like giving up
cake because you once ate so much you were sick - don't give up cake,

I'm actually excited to try things besides operator overloading. Why
*just* repeat the past? Why not invent something better? Think outside
the box! The idea of embedding some form of scriptlet, or linking with
..class files that were generated by a specialized parser, strikes me as
potentially much more powerful than operator overloading.

Just stuffing Java with every misfeature from past languages does not
have me excited. I'd like to try a new misfeature. At least it won't be
the same old boring misfeature we had be for, it'll be an interesting
new one.

 

[Tom Anderson]

I think "disaster hasn't struck yet" is a poor counter argument.

I see. Do tell me about the preparations you've made in case the sun
doesn't come up tomorrow morning, won't you? And how do you manage to get
around without ever crossing a road?

I suppose the engineer in me wants to make certain that disaster doesn't
strike, with a comfortable margin of error.

I like to design things that can't fail, not things that rely on above
average execution by the user.

Yes, that's definitely a good thing. But there's always a tension between
being an idiot-proof language and a useful language. In this case, we
agree (ish) on the usefulness of operator overloading, but disagree on the
proofness against idiots, and thus on whether operator overloading is a
good or bad thing.

Bingo. Java is far more popular than Smalltalk, Python, etc. Masses = lower
average IQ, even if it's just from time pressure to get projects done.

I'm not sure the liberal in me is quite ready to believe this. The elitist
in me certainly isn't ready to give up a useful feature for the good of
the hoi polloi!

I'm actually excited to try things besides operator overloading. Why *just*
repeat the past? Why not invent something better? Think outside the box!
The idea of embedding some form of scriptlet, or linking with .class files
that were generated by a specialized parser, strikes me as potentially much
more powerful than operator overloading.
....

Just stuffing Java with every misfeature from past languages does not
have me excited. I'd like to try a new misfeature. At least it won't be
the same old boring misfeature we had be for, it'll be an interesting
new one.

Ah, i see where you're going with this. Hopefully, this is in a different
direction to me ...

tom

 

[Patricia Shanahan]

I think "disaster hasn't struck yet" is a poor counter argument. I
suppose the engineer in me wants to make certain that disaster doesn't
strike, with a comfortable margin of error.

....

The decision not to do something has its own risks.

Consider the errors that may be made in translating formulas into Java,
or the programs that will be written in Fortran or C++ rather than Java,
because of Java's lack of a reasonable syntax for complex number arithmetic.

Neither having nor not having operator overloading is risk free. The
question, on which reasonable people can disagree, is which carries the
higher cost.

Patricia

 

[Andreas Leitgeb]

Wikipedia cites a suggestion from Conrad Wilson that the actual comment was
"an extraordinary number of notes".

Extraordinarily likely, the original comment was not in english language.
The german version I had in mind was "Zu viele Noten", but that might
indeed just be the version from the movie. I wasn't yet alive when it
was originally said, and neither was any of he Wiki chroniclers

To go back on-Topic:
If there are just more characters needed for a task, than logically
necessary, this doesn't automatically help maintainers.

Having simple bi=bi++; even for a BigInteger is one example that
would save later maintainers much work, compared to the contortions
that are now still needed for BigIntegers. I wouldn't propose "+" for
anything than scalar arithmetic types.

There, of course, also exist other situations, where Mark's comment
really applies, and some keystrokes saved by the programmer really
cost multiple on maintenance. (e.g. missing indentation, using only
one-letter field-/method-names)

 

[Andreas Leitgeb]

I think "disaster hasn't struck yet" is a poor counter argument. I
suppose the engineer in me wants to make certain that disaster doesn't
strike, with a comfortable margin of error.

I'd like to understand the nature of that "disaster" a bit better.

Is it one of the following list that gives you the creeps?
1) Someone might overload the operator + to do "-"
and the other way round, in order to obfuscate (on purpose)
his code.
2) Someone might overload operators with actions that
not everyone would associate with that operator.
3) Someone might create a library with such contortions
4) Sun might add operators for some methods.

1) and 2) are (imo) that "someone"'s own problem. If this
"someone" is not writing for his own joy, then he'd have
to follow some guidelines, anyway.
3) It's quite likely, that not many would really use such a
library, unless it is brilliant in other parts, but then
it's unlikely that someone capable to do those other
parts would fail so miserably on proper operator-use.
4) Quite unlikely that they defined really grossly unintuitive
associations.

I like to design things that can't fail, not things that rely
on above average execution by the user.

Such a design is usually in itself a failure

If you cannot rely on the users of a prog-language, you (in the
role of a prog-language-designer) should instantly stop designing
any prog-languages.

I'm actually excited to try things besides operator overloading.
Why *just* repeat the past?

Because *not everything* in it was bad.

Why not invent something better? Think outside
the box! The idea of embedding some form of scriptlet, or linking with
.class files that were generated by a specialized parser, strikes me as
potentially much more powerful than operator overloading.

Generating new classes for each legible calculation on BigIntegers ?
Strikes me as odd.

Just stuffing Java with every misfeature from past languages does not
have me excited. I'd like to try a new misfeature. At least it won't be
the same old boring misfeature we had be for, it'll be an interesting
new one.

Good luck! I prefer tried and tested "not-all-that-mis"-features.

 

[Andreas Leitgeb]

I see. Do tell me about the preparations you've made in case the sun
doesn't come up tomorrow morning, won't you?

In this group, one should probably say explicitly, that "sun" refers
to that shiny yellow ball in the sky usually visible on non-cloudy
days, and not just the nickname of some company somehow related to
Java language.

PS: The article "the" before "sun" actually indicates the intended
meaning, but may be a bit too subtle

 

[Arved Sandstrom]

Also true for having just fewer characters than are needed. The dicey
part is knowing what is "needed".

I've seen code where the use of cryptic, extremely short variable names
hurt readability. I bet you have to (plural "you"). That shows that it
is possible to have too few characters in a source line to help
maintainers.

A classic case of short variable names is "Numerical Recipes in C" (or
FORTRAN for that matter). I have a copy, and consider it valuable, but the
code sucks pretty bad...what's valuable is the discussion. While the choice
to use short variable names in this book was clearly driven by printing
space requirements it hurts the readability badly. I understand the code in
"Numerical Recipes in C++" is even worse. It's so bad that it's quite
difficult to type out a code snippet from these books without making
multiple errors (i.e. valid variables, just not the right ones).

Among the few super-short variable names that make sense to me are i, j, k
for loop indices and m, n for dimensions. Contextually these are easy to
understand and help readability (I also frequently use nr and nc instead of
m and n).

For pretty much anything else I ensure that variable names are descriptive.
I also find that I finetune variable name lengths according to their
placement in code and what they are...are they object references, do they
show up as arguments a lot, are they part of array index computations (*),
etc.

AHS

* And if such a computation gets too long I pull it out and assign it to a
variable. I find that readability is also hurt if the eye doesn't quickly
grok to matching [] or () or {} pairs, modern IDEs notwithstanding, and
doing too much inside such pairs (long variable names, lots of operators,
function calls) can impair this.

 

[Mark Thornton]

A classic case of short variable names is "Numerical Recipes in C" (or
FORTRAN for that matter). I have a copy, and consider it valuable, but the
code sucks pretty bad...what's valuable is the discussion. While the choice
to use short variable names in this book was clearly driven by printing
space requirements it hurts the readability badly. I understand the code in
"Numerical Recipes in C++" is even worse. It's so bad that it's quite
difficult to type out a code snippet from these books without making
multiple errors (i.e. valid variables, just not the right ones).

Among the few super-short variable names that make sense to me are i, j, k
for loop indices and m, n for dimensions. Contextually these are easy to
understand and help readability (I also frequently use nr and nc instead of
m and n).

For pretty much anything else I ensure that variable names are descriptive.
I also find that I finetune variable name lengths according to their
placement in code and what they are...are they object references, do they
show up as arguments a lot, are they part of array index computations (*),
etc.

There are plenty of cases on mathematics where the traditional
identifier is very short --- usually a single Greek letter. In languages
that permit such identifiers there is little to be gained by using
epsilon instead of ϵ.

Mark Thornton

 

[Stefan Ram]

There are plenty of cases on mathematics where the traditional
identifier is very short --- usually a single Greek letter. In languages
that permit such identifiers there is little to be gained by using
epsilon instead of ϵ.

You seem to have inserted the lunate epsilon U+03F5
(I am not sure whether it is quoted correctly above).

It might even be a valid identifier in Java, but a
small epsilon U+03B5 might look less strange.

 

[Andreas Leitgeb]

I like to design things that can't fail, not things that rely

First of all, I admit, that I missed the "above" in the quote.
With that word, Mark's comment makes more sense, than what I
read it as.

I am incredulous that anyone could even think to assert that "uch a design
is usually in itself a failure". How could anyone think that to design
against failure is "itself a failure"? That's nonsense.

I read it (wrongly) that he didn't even trust an average user. Also,
things that can't fail must be so simple that they're not really
interesting...

 

[Tom Anderson]

In this group, one should probably say explicitly, that "sun" refers
to that shiny yellow ball in the sky usually visible on non-cloudy
days, and not just the nickname of some company somehow related to
Java language.

Ha! An excellent point, Herr Leitgeb, and i will endeavour to
fully-qualify my nouns in future.

For now, please insert an:

import celestialobjects.* ;

at the top of my previous post!

tom