C++, C# or Java.

[Roedy Green]

How big of an issue is reflection in all of that? I never use reflection
and I've often thought it seems like an awful waste to have it available
all the time and use it only rarely. I imagine that classes would be a
lot smaller in memory without it.

not really. If you don't use reflection classes, they never get
loaded.

However you are correct, if you use reflection even once, those
classes will stay loaded though may get swapped out.

 

[Roedy Green]

Is there some way to eliminate the cost of reflection when it's not
wanted?

If you need it just for a short while, you could use a custom class
loader, load your reflection, then drop the classloader.

see http://mindprod.com/jgloss/classloader.html

 

[Bent C Dalager]

Personally I love operator overloading, and having more control over memory
usage. But especially operator overloading. I think Java has been growing
up with the generics (templates) in 1.5. Now if it had operator
overloading it would be completely matured.

I have seen a lot of operator overloading i C++, and with the
exception of some use of "==" and "!=", I have never seen it used
appropriately. It is almost always used as some sort of short-hand
hack to save the programmer a few keystrokes at the expense of ending
up with incomprehensible code.

I do not doubt that there are legitimate uses for operator
overloading, but I personally never use maths libraries and rarely
find the need to do matrix or vector multiplication, so never see
it. For such a marginal field of "appropriate" use, I find the feature
completely unnecessary and, as it turns out, directly destructive to
the readability of source code.

Now, if you could have "operator definition" in stead of overloading,
that might have some uses, but the existing operators would have to
remain off limits. I could see some use in defining custom operators
such as $, or @, etc., but I suspect that this would also degenerate
into unreadability. The best way to find out, I suppose, would be for
some widely used prototype language to implement it, wait a few years,
and see how much of a mess it turned into. Do they still accept

Judge for yourself, what's more intuitive:

String s1 = "hello";
String s2 = "hello";

if(s1 != s2)
System.out.printf("%s != %s", hello, hello);

This is a really bad idea as the basic notion that != and == compare
on object identity is exceedingly useful and I wouldn't want to have
to second-guess this functionality every time I need to use it.

Cheers
Bent D

 

[Bent C Dalager]

How big of an issue is reflection in all of that? I never use reflection
and I've often thought it seems like an awful waste to have it available
all the time and use it only rarely. I imagine that classes would be a
lot smaller in memory without it.

Is there some way to eliminate the cost of reflection when it's not
wanted?

If you are thinking of the size penalty to keeping around symbol
names, you might get rid of a lot of that by using an obfuscator-like
tool that shortens all your names.

While I haven't tried it, I think the obfuscator at yworks.com tries
to do this.

Cheers
Bent D

 

[Chris Smith]

How big of an issue is reflection in all of that? I never use reflection
and I've often thought it seems like an awful waste to have it available
all the time and use it only rarely. I imagine that classes would be a
lot smaller in memory without it.

Is there some way to eliminate the cost of reflection when it's not
wanted?

Since all the information is available in the class file, it's
conceivable that reflection alone could be implemented with no runtime
cost when it isn't used. However, pretty much the exact same set of
information is used for dynamic linking, and dynamic linking is a major
piece of the very foundation of the Java language. Even if you don't
load new classes based on class names from config files, the language
spec outright promises that any class -- even if statically referenced
-- won't be loaded until it is used for the first time. So eliminating
reflection doesn't buy you much.

Native compilers such as Jet, of course, are a different matter. In
that case, the linking is done ahead of time in the binary image, with
clever tricks used to put off all visible side-effects until such time
as the language spec says the class should be loaded. In that case, use
of reflection and truly dynamic class loading does indeed swell the size
of the application.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[zero]

Well obviously most people here hate operator overloading. I still like
it, and I think it makes code much more readable. But I guess that's one
of the objective factors I mentioned in my first post.

I yield to the majority and will now shut up about it

 

[Thomas G. Marshall]

Bent C Dalager coughed up:

I have seen a lot of operator overloading i C++, and with the
exception of some use of "==" and "!=", I have never seen it used
appropriately. It is almost always used as some sort of short-hand
hack to save the programmer a few keystrokes at the expense of ending
up with incomprehensible code.

I do not doubt that there are legitimate uses for operator
overloading, but I personally never use maths libraries and rarely
find the need to do matrix or vector multiplication, so never see
it. For such a marginal field of "appropriate" use, I find the feature
completely unnecessary and, as it turns out, directly destructive to
the readability of source code.

Now, if you could have "operator definition" in stead of overloading,
that might have some uses, but the existing operators would have to
remain off limits.

Still would contribute to horrible code in my opinion. When looking at a
line of code, there are *ENOUGH* reasons to have to look elsewhere to see
what the heck it is doing.

I could see some use in defining custom operators
such as $, or @, etc., but I suspect that this would also degenerate
into unreadability.

I don't know if it would /degenerate/ into unreadability, but instead
*immediately* be /prone/ to /rampant/ horribly hard to maintain code.
People have got to start thinking of the engineer, even say the brightest
guy on the planet, who is worn out at 3am and hopped on caffeine. Forget
about the junior engineers, *everyone* is libel to misread code, and you
just don't need to add to the likelihood of that.

....[rip]...

 

[Mark Thornton]

I do not doubt that there are legitimate uses for operator
overloading, but I personally never use maths libraries and rarely
find the need to do matrix or vector multiplication, so never see
it. For such a marginal field of "appropriate" use, I find the feature
completely unnecessary and, as it turns out, directly destructive to
the readability of source code.

I think it is a very important field, albeit one with a relatively small
number of practitioners.

Mark Thornton
(PhD, Mathematics)

 

[Mark Thornton]

Well obviously most people here hate operator overloading.

It isn't all that surprising that many of those who hate overloading
have gravitated to Java (and obviously haven't moved 'on' to C#).

Mark Thornton

 

[Mark Thornton]

A main point of slowness is that everything in Java is on the heap. C++
works really hard to let you put things on the stack so that nothing has
to be malloc'ed or released and its generally faster to reference the
stack.

On the other hand Java's heap allocation is often faster than that in
C++ and especially slow when using multiple threads.

Java also has to do index checking on array access except under some
optimizations with limitted applicability.

Actually quite common: iterating over the elements of an array.

Mark Thornton

 

[Bent C Dalager]

I don't know if it would /degenerate/ into unreadability, but instead
*immediately* be /prone/ to /rampant/ horribly hard to maintain code.

I suspect the same. I don't find it half as bad as operator
overloading, though, in that when you see e.g.,
int a = b @ c;
you fully expect something strange to be going on and you'll know to
look up the operator definitions on b and c.

Not so when you see
int a = b + c;
in which case you expect "+" to do what "+" always does and rarely
think to look up on b and c to check if they're being naughty. (Not to
mention that you also expect "=" to do what "=" always does . . . one
only counts oneself lucky that ";" indeed _does_ do what ";" always
does <g>)

But I certainly have much sympathy for your argument

(I still think someone should talk the C++ crowd into trying it out
for a decade or so just to see if it's worth considering at all . . .)

Cheers
Bent D

 

[Dimitri Maziuk]

Roedy Green sez:

I think it means you can handle much larger loads simply by increasing
the speed and capacity of the hardware, or the number of cpus, or
expense of the container software and database engine, without a
fundamental rewrite of the code.

What do you think it means?

In my experience, when users take your application developed and
tested on a sample set of 1K values, and feed it a real-life input
set ot 100G data points, throwing more hardware at it doesn't help
that much -- unless you wrote your code with that kind of load in
mind to begin with. Scalability is not one of Java's strengths.

Running on another (bigger) server without a recompile, that's
"portability", and that is Java's big selling point. I like C++,
but every piece of C++ we still use had to be _ported_ from MIPSPro
to g++-2, then from g++-2 to g++-3, and now it has to be _ported_
to g++-4. Nobody's got the time to port it to other compilers we
have here, like Sun workshop. Which is why no new projects here
are done in C++, it's all Java.

Dima

 

[Roedy Green]

Well obviously most people here hate operator overloading. I still like
it, and I think it makes code much more readable. But I guess that's one
of the objective factors I mentioned in my first post.

Operator overloading might be more readable for the author, but
opaque for anyone else. Also over time it will become opaque for the
original author.

Almost never do you want to totally erase the difference between int +
and matrix +. I can see you wanting to use array notation for
something that is not an array because you want people treat your new
thing exactly as if it were an array. However, you never want to
treat matrix plus exactly as if it were int plus.

You just want a notation that is not clumsy, close to the original
mathematical notation.

You can get that allowing NEW operators. You don't need overloading.

look how much confusion + being also used for concatenation causes!

Now you want 10 other meanings piled on top?

One of the nicest features of Java is the way it sort of guides people
to write stereotypical code. Overloaded operators are a feature to get
fancy pants and dazzle and obscure what you are doing. It requires
the reader to be smarter than you to understand the code. It requires
the reader to carefully study the context of each operator to
understand what it means. There simply is not time these days for that
luxury.

 

[Roedy Green]

Scalability is not one of Java's strengths.

Certainly hooking into wide range of SQL database engines or Servlet
wombs is a form or scalability.

Java threads likewise.

I worked on a team that devised a multithreaded spreadsheet engine. It
was designed to keep threads working on different parts of the grid
out of each other's hair as much as possible.

This thing ran without modification on a Sun server with 256 cpus at
blinding speed, the same code as was running on my dinky little
desktop.

Too bad it did not survive. Other wise we may have seen customer
customisations written as tiny spreadsheets rather than XML files.

 

[Tim Tyler]

I would go for user-defined operators, but no overloading of the
primitives. If you want an additive operator, use one of the many
possible Unicode symbols. Hands off +. It has too many meanings
already.

How would programmers enter and edit these symbols using a conventional
keyboard?

Are there any other programming languages that have adopted this approach?

 

[Tim Tyler]

I have seen a lot of operator overloading i C++, and with the
exception of some use of "==" and "!=", I have never seen it used
appropriately. It is almost always used as some sort of short-hand
hack to save the programmer a few keystrokes at the expense of ending
up with incomprehensible code.

I do not doubt that there are legitimate uses for operator
overloading, but I personally never use maths libraries and rarely
find the need to do matrix or vector multiplication, so never see
it. For such a marginal field of "appropriate" use, I find the feature
completely unnecessary and, as it turns out, directly destructive to
the readability of source code.

Now, if you could have "operator definition" in stead of overloading,
that might have some uses, but the existing operators would have to
remain off limits. I could see some use in defining custom operators
such as $, or @, etc., but I suspect that this would also degenerate
into unreadability. The best way to find out, I suppose, would be for
some widely used prototype language to implement it, wait a few years,
and see how much of a mess it turned into.

I quite like the idea that JPP used.

It allowed operator-style shorthand - but it *insisted* that it be
distinguished from non-overloaded operators as follows:

a (=) b -> a.equals(b)
a (*) b -> a.times(b)
a (-) b -> a.minus(b)

....and so on.

No confusion about whether an operator was a shortcut to a method or
not ;-)

The downsides - compared to conventional overloading - are that the
extra brackets represent visual noise - and that if you want to switch
between a standard operator and an overloaded one, all the instances of
its usage have to change.

Perhaps a bearable set of drawbacks for getting most of the benefits of
OO - without most of the pain.

Having said that, these days, you ought to be able to have *real*
operator overloading - and have your IDE tell you whether the base
class operator is being called or not via syntax colouring.

 

[Tim Tyler]

not really. If you don't use reflection classes, they never get
loaded.

That is not really accurate - type:

java -verbose:class

....and you'll see that a whole bunch of reflection classes get loaded -
even if all that is happening is printing an error message.

 

[Tim Tyler]

Roedy Green sez:

In my experience, when users take your application developed and
tested on a sample set of 1K values, and feed it a real-life input
set ot 100G data points, throwing more hardware at it doesn't help
that much -- unless you wrote your code with that kind of load in
mind to begin with. Scalability is not one of Java's strengths.

Running on another (bigger) server without a recompile, that's
"portability", and that is Java's big selling point. I like C++,
but every piece of C++ we still use had to be _ported_ from MIPSPro
to g++-2, then from g++-2 to g++-3, and now it has to be _ported_
to g++-4. Nobody's got the time to port it to other compilers we
have here, like Sun workshop. Which is why no new projects here
are done in C++, it's all Java.

I'm still not clear on what do you think "scalability" means.

 

[Roedy Green]

How would programmers enter and edit these symbols using a conventional
keyboard?

Your IDE would be involved. You would likely configure them much the
way you configure editor commands.

Another way to handle it is to give the operators names as well. Then
you can type the names and optionally have the IDE show you the code
with Unicode symbols for the operators. You pretty well have to have
a way of flipping the code back and forth between rich char set and
impoverished charset or no one could post such code in newsgroups.

 

[Roedy Green]

The downsides - compared to conventional overloading - are that the
extra brackets represent visual noise - and that if you want to switch
between a standard operator and an overloaded one, all the instances of
its usage have to change.

A smart IDE could show you (*) as a single glyph.