On Java and C++

[Phlip]

Less of an issue now than back in the horrid days of applets.

Ooh, I love it when they fight back.

They are. But they're not C/C++ "syntactic sugar for pointers".

There is no language C/C++.

Arrays in C++ convert to pointers very easily, but they are still
first-class objects. They have a complete type, including a length, and all
these can be manipulated by ... generics.

Noone prevents you from using vi to write Java. Well, maybe the Emacs
tribalists do.

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.

Read:

http://c2.com/cgi/wiki?RubyVsJava

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

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

That's not just fewer lines; it's an order of magnitude fewer, for the exact
same feature set.

Please don't say "that's because Java programmers write more professional
comments..."

Language defines what is virtual or not. It's up to the (virtual)
hardware to comply.

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.

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

Is that the "let's pretend this block of memory is something else"
stuff "inherited" from C's union and void*?

Write an Any or Variant class in Java.

Whatever for? I've written GUIs in Java, and the Swing MVC system is
decent enough to use. Where do you need either of those?

You have insufficient experience with block closures.

A GUI should be event-driven. Block closures make those as easy as falling
off a log. 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. Block closures simply turn
that problem inside out. The language does the plumbing, and all you need to
do is add the custom behaviors.

 

[Phlip]

[A spanking] to all VB programmers and the buggers that dreamed up the
language!

Take a nap, it saves lives.

A 6-hour work day to all VB buggers.

As the mental clarity takes effect, they will ask "why am I debugging all
the time instead of thinking?"

;-)

 

[Mishagam]

This is very easily over come by using a decent IDE which shows all the
method signatures - all the time. eclipse, intellj, etc...

And allow folding of areas you currently don't want to look at.

 

[Oliver Wong]

Andrey Kuznetsov schrieb: [Timo wrote:]

you should try Opera.
While Firefox needs up to 5 second for applet on my page
(http://reader.imagero.com),
with Opera it starts immediately!

Some browsers handle the initialisation better than others. But for most
users, applets just take a long time to appear. Flash is generally much
quicker, regardless of platform or browser.

FWIW, in my experience, Flash is not "much quicker".

- Oliver

 

[Oliver Wong]

Not Befunge?

It's pretty easy to write a Befunge interpreter. To write a compiler,
you could simply generate an executable that contains the interpreter as
code, and the befunge source code as an embedded resource.

- Oliver

 

[Remon van Vliet]

*SNIP*

That comparison is quite a stretch. GC is, as far as I know and as far
as Java implements it, totally unaccessable to the programmer. Can you
force the GC to delete anything? There may be certain times when you
can expect the GC to do some cleanup but you cannot guarantee it nor
can you control it. On the other hand, refrence counting using smart
pointers is 100% programmer controlled. You _can_ force something to
get deleted and you know for certain that the object will get deleted
the instant the last reference to it leaves scope or is destroyed.
This is a totally dependable action that is 100% guaranteed. With the
GC you can have no references to an object but it hangs out until who
knows when and then gets destroyed sometime after the last reference to
it leaves scope or is destroyed..../sometime/ after.

Which is a problem because? You dont have to point out continuously that the
GC doesnt allow exact control over cleaning up discarded objects. We all
know that and consider that a good thing. What'd be more interesting is to
finally hear a valid reason why it's actually a problem rather than an
advantage.

Does that mean it works if the programmer doesn't work? No. But it
means that RAII _can_ be depended on to perform the actions it has been
described so long as the programmer does their job. Requiring correct
code is not unreasonable and in reality RAII is quite effective at
keeping a lot of bugs out of code so long as it is followed.

Why are you so stuck on wanting control over these kind of things? Are you
under the impression you do a better job at manually alloc/deallocing memory
and cleaning up objects than the latest generation Java GC will do? I'm
getting a bit tired of all these unsupported assumptions. Either come with
practical examples/facts or just agree to disagree.

 

[Oliver Wong]

[...]

There may be certain times when you
can expect the GC to do some cleanup but you cannot guarantee it nor
can you control it. On the other hand, refrence counting using smart
pointers is 100% programmer controlled. You _can_ force something to
get deleted and you know for certain that the object will get deleted
the instant the last reference to it leaves scope or is destroyed.
This is a totally dependable action that is 100% guaranteed. With the
GC you can have no references to an object but it hangs out until who
knows when and then gets destroyed sometime after the last reference to
it leaves scope or is destroyed..../sometime/ after.

Which is a problem because? You dont have to point out continuously that
the GC doesnt allow exact control over cleaning up discarded objects. We
all know that and consider that a good thing. What'd be more interesting
is to finally hear a valid reason why it's actually a problem rather than
an advantage.
[...]

Why are you so stuck on wanting control over these kind of things? Are you
under the impression you do a better job at manually alloc/deallocing
memory and cleaning up objects than the latest generation Java GC will do?
I'm getting a bit tired of all these unsupported assumptions. Either come
with practical examples/facts or just agree to disagree.

Even if (whoever "you" refers to here) does believe that they are better
at manually allocating and deallocating memory than a modern GC, there's
still the issue of whether the average programmer is better as well, or if
("you") is simply gifted in that respect. If it's the latter, non-garbage
collected programming languages may be suitable for ("you"), but not
suitable for anyone else.

- Oliver

 

[Timo Stamm]

Andrey Kuznetsov schrieb: [Timo wrote:]

I think applets are much worse than Flash. They take a long time to
load, their abilities to communicate with the browser (Javascript)
is even worse than Flashs.

you should try Opera.
While Firefox needs up to 5 second for applet on my page
(http://reader.imagero.com),
with Opera it starts immediately!

Some browsers handle the initialisation better than others. But for
most users, applets just take a long time to appear. Flash is
generally much quicker, regardless of platform or browser.

FWIW, in my experience, Flash is not "much quicker".

Thanks for sharing your experience.

But do you really mean that Flashs /initialization/ is not generally
much faster for you than Applets? Or were you thinking of rendering and
computing performance?

Right now on my Powerbook with Safari, it takes 11 seconds until the
following very simple applet showed it's input elements:
http://java.sun.com/applets/jdk/1.4/demo/applets/ArcTest/example1.html

The following Flash movie shows instantly, without any measurable delay:
http://www.contourdesign.com/rollermouse/rollermouse_flash.htm

My experience with other Browsers on Windows and Linux is more or less
the same. Of course there is caching. The second time I load above
Applet, it only takes about one second. This might be even better on
Windows.

I have never experienced such a slow initialization with Flash on any
platform or browser. It never takes even close to one second. This is
very important to most Flash customers, because they don't want any
glitches, hiccups or blinking when the plugin starts.


Timo

 

[Remon van Vliet]

[...]

There may be certain times when you
can expect the GC to do some cleanup but you cannot guarantee it nor
can you control it. On the other hand, refrence counting using smart
pointers is 100% programmer controlled. You _can_ force something to
get deleted and you know for certain that the object will get deleted
the instant the last reference to it leaves scope or is destroyed.
This is a totally dependable action that is 100% guaranteed. With the
GC you can have no references to an object but it hangs out until who
knows when and then gets destroyed sometime after the last reference to
it leaves scope or is destroyed..../sometime/ after.

Which is a problem because? You dont have to point out continuously that
the GC doesnt allow exact control over cleaning up discarded objects. We
all know that and consider that a good thing. What'd be more interesting
is to finally hear a valid reason why it's actually a problem rather than
an advantage.
[...]

Why are you so stuck on wanting control over these kind of things? Are
you under the impression you do a better job at manually alloc/deallocing
memory and cleaning up objects than the latest generation Java GC will
do? I'm getting a bit tired of all these unsupported assumptions. Either
come with practical examples/facts or just agree to disagree.

Even if (whoever "you" refers to here) does believe that they are
better at manually allocating and deallocating memory than a modern GC,
there's still the issue of whether the average programmer is better as
well, or if ("you") is simply gifted in that respect. If it's the latter,
non-garbage collected programming languages may be suitable for ("you"),
but not suitable for anyone else.

- Oliver

I was referring to Noah. And yes, very true, but even so his point is
flawed. Recent tests and research (from IBM, amongst others) showed that the
latest generation of garbage collectors not only meet the performance of
manual memory managment in the vast majority of cases, it's often
considerably faster. So even if you've perfected the art of manual memory
managment the odds are now still against you (and yes i can actually explain
why that would be rather than just claim it).

It's an argument quite similar to that of people claiming natively compiled
code will always (or mostly) be faster than Java code running in the VM. It
was true, but it hasnt been so for quite a while now.

- Remon van Vliet

 

[Gordon Beaton]

This is very important to most Flash customers, because they don't
want any glitches, hiccups or blinking when the plugin starts.

If there's even a flash plugin available for your particular platform
(I don't know of any for mine).

/gordon

 

[Remon van Vliet]

Some browsers handle the initialisation better than others. But for most
users, applets just take a long time to appear. Flash is generally much
quicker, regardless of platform or browser.

It can be, but with Java2D API you have access to hardware accelerated
graphical features that should be on par with Flash performance. In my
opinion everything that can be done in Flash can be done in Java. However,
Flash is way more efficient from a time to market point of view, it's just a
bit easier (and dare i say it better) for web based content.

 

[Oliver Wong]

Thanks for sharing your experience.

But do you really mean that Flashs /initialization/ is not generally much
faster for you than Applets? Or were you thinking of rendering and
computing performance?

Right now on my Powerbook with Safari, it takes 11 seconds until the
following very simple applet showed it's input elements:
http://java.sun.com/applets/jdk/1.4/demo/applets/ArcTest/example1.html

The following Flash movie shows instantly, without any measurable delay:
http://www.contourdesign.com/rollermouse/rollermouse_flash.htm

Windows XP with SP2, Pentium 4 1.8Ghz, 1024MB RAM, Firefox 1.5.0.2.

Java took 3 seconds, Flash took 5 seconds.

- Oliver

 

[Noah Roberts]

FWIW, in my experience, Flash is not "much quicker".

Here's your half penny...payment for services rendered...

 

[Remon van Vliet]

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.

The point wasnt exactly strong to begin with. Surely you're not serious
here, if you are you're shooting down your own credibility.

Read:

http://c2.com/cgi/wiki?RubyVsJava

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

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

That's not just fewer lines; it's an order of magnitude fewer, for the
exact same feature set.

Please don't say "that's because Java programmers write more professional
comments..."

Okay i wont say that, i'll rephrase it a bit since you're proving yourself
to be misinformed. As per Java convention the Java version has the lowest
level API reference documentation included in it's source code which
obviously adds quite a few newlines (an odd measurement of verbosity to
begin with but hey). It also happened to be properly spaced and indented
code. Now i took the liberty of browsing through the code of the Ruby
equivalent you mentioned and it has none of that (as in, hardly any comments
and horribly formatted code). Since both are more a matter of taste/style i
dont see it's relevance anyway. I'm pretty sure a similar amount of input
went into both versions (code + docs).

Write an Any or Variant class in Java.

Never had to. Would very rarely want to.

You have insufficient experience with block closures.

A GUI should be event-driven. Block closures make those as easy as falling
off a log. 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. Block closures simply
turn that problem inside out. The language does the plumbing, and all you
need to do is add the custom behaviors.

I can only agree, GUI development is tedious and overly complicated in Java
nad most available visual editors produce code nobody even wants to look
at). I must say a few well chosen design patterns make the lack of block
closure functions (if that's what you were referring to) not quite as
painful, but still...Java definately loses here. And btw, it can be
succesfully argued that any need for dynamic typing will negatively affect
the robustness of your program in the majority of cases.

 

[Remon van Vliet]

Andrey Kuznetsov schrieb: [Timo wrote:]
I think applets are much worse than Flash. They take a long time to
load, their abilities to communicate with the browser (Javascript) is
even worse than Flashs.

you should try Opera.
While Firefox needs up to 5 second for applet on my page
(http://reader.imagero.com),
with Opera it starts immediately!

Some browsers handle the initialisation better than others. But for most
users, applets just take a long time to appear. Flash is generally much
quicker, regardless of platform or browser.

FWIW, in my experience, Flash is not "much quicker".

Thanks for sharing your experience.

But do you really mean that Flashs /initialization/ is not generally much
faster for you than Applets? Or were you thinking of rendering and
computing performance?

I think it's fair to say that on average Java initialises a bit slower than
Flash (not surprising considering the implementation differences). Graphics
performance is probably slightly in favour of Flash although Java2D uses
hardware acceleration as well. In terms of raw computing power i suspect
Java will blow Flash out of the water as i'm boldly assuming the "VM" of
Flash is not nearly as capable as an average JIT JVM. I must stress that's
an assumption rather than fact though.

 

[Remon van Vliet]

and your point is?

longevity of use is no indicator of a 'good' language - its simply that
the application does what it was supposed to OR the company is unwilling
to rewrite for some reason if it isn't doing as its supposed to.

longevity is usually solely related to the people that design the
application rather than the language it was developed in. That said, i think
he was simply making a point that writing commercial quality applications
using VB is tricky at best. I think that point is pretty valid.

 

[Chris Smith]

It can be, but with Java2D API you have access to hardware accelerated
graphical features that should be on par with Flash performance. In my
opinion everything that can be done in Flash can be done in Java. However,
Flash is way more efficient from a time to market point of view, it's just a
bit easier (and dare i say it better) for web based content.

The problem is not with the performance of the graphics hardware. The
limiting factor is the initialization of the virtual machine.
Undoubtedly, if things got anywhere near the point of maxing out the
graphics card, an applet would greatly outperform Flash.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Timo Stamm]

Andrey Kuznetsov schrieb:
[Timo wrote:]
Some browsers handle the initialisation better than others. But for most
users, applets just take a long time to appear. Flash is generally much
quicker, regardless of platform or browser.

FWIW, in my experience, Flash is not "much quicker".

Thanks for sharing your experience.

But do you really mean that Flashs /initialization/ is not generally much
faster for you than Applets? Or were you thinking of rendering and
computing performance?

I think it's fair to say that on average Java initialises a bit slower than
Flash (not surprising considering the implementation differences).

That's my experience on a lot of different systems and with a lot of
flash movies. I am surprised that Oliver has a different experience and
I'd like to know the reason. I have quite a few customers who would not
accept a delay of five seconds.

Graphics performance is probably slightly in favour of Flash although
Java2D uses hardware acceleration as well. In terms of raw computing
power i suspect Java will blow Flash out of the water as i'm boldly
assuming the "VM" of Flash is not nearly as capable as an average JIT
JVM. I must stress that's an assumption rather than fact though.

Flash graphics performance is not very good. I have never made any
tests, but I guess that Applets are better. Flash graphics performance
on the mac is very bad, even though they improved it with version 8 of
the player.

Computing performance of Java is far superior. Even with the upcoming
version of the player that was rewritten from scratch.


Timo

 

[Remon van Vliet]

By the way, if i may add, i dont know who submitted the language comparison
articles for that wiki but it is littered with information that simply is
not true.

 

[Remon van Vliet]

Oliver Wong schrieb:
Andrey Kuznetsov schrieb:
[Timo wrote:]
Some browsers handle the initialisation better than others. But for
most users, applets just take a long time to appear. Flash is
generally much quicker, regardless of platform or browser.

FWIW, in my experience, Flash is not "much quicker".
Thanks for sharing your experience.

But do you really mean that Flashs /initialization/ is not generally
much faster for you than Applets? Or were you thinking of rendering and
computing performance?

I think it's fair to say that on average Java initialises a bit slower
than Flash (not surprising considering the implementation differences).

That's my experience on a lot of different systems and with a lot of flash
movies. I am surprised that Oliver has a different experience and I'd like
to know the reason. I have quite a few customers who would not accept a
delay of five seconds.

Well it's worth noting that the VM initialisation is what's causing the
delay, and that only happens once. Actually loading and starting the Applet
(at least on my system) is a matter of a second or slight more.

Flash graphics performance is not very good. I have never made any tests,
but I guess that Applets are better. Flash graphics performance on the mac
is very bad, even though they improved it with version 8 of the player.

Oh yes? That surprises me, i've always assumed Flash to be faster if you're
going for the same graphical quality, especially where antialiasing is
involved. Interesting stuff..

Computing performance of Java is far superior. Even with the upcoming
version of the player that was rewritten from scratch.

Yeah i thought so