On Tuesday, 26 August 2014 at 09:45:15 UTC, Russel Winder via
Digitalmars-d wrote:
On Tue, 2014-08-26 at 08:46 +0000, Chris via Digitalmars-d
wrote:
[…]
The problem was that Java didn't behave as expected on
Windows. Things that worked fine on Linux and OS X didn't work
on Windows (even simple things like deleting files). User
reported all sorts of problems, one of them being that the
Java Access Bridge didn't work. Why, nobody knows. The lack of
a proper sound API / library. Then there was the versioning
hell with JRE/JVM and having to tell users what version they
had to download (the non tech savvy crowd). I know that MS
doesn't make it easy for Java either. Well, I could have
sorted the problems out with Java web start, SWT and all that
kind of stuff. Instead, I learned D which I can compile and
run on each platform without a problem.
If your users are having to install things then the problem is
your
deployment mechanism not the JVM dependency hell system. Java
deployments are actually really quite easy. Either you package
a total
system with all dependencies and provide entry scripts, or you
use Maven
Central (or increasingly BinTray) for accessing dependencies.
If I need deployment mechanisms like the ones above, then there's
something wrong with the language. All these crutches and
patches. To set up and test a deployment mechanism takes as long
as writing the program. No thank you.
This is
not to say there are not portability and dependency problems,
there are,
but it is good to blame the right reason at the right time.
See answer above.
I am surprised by the platform dependency problem you cite. Yes
there
are platform issues with the Java Platform but I had thought
all the
ones you are alluding to were fixed by Java 1.4.2.
It was long after 1.4.2.
Media APIs for Java have always been a bit of a pain. With any
luck
JavaFX, and the far more important GroovyFX, will cause a
resurgence of
interest in media APIs on the Java Platform, and this time get
them
right.
"With some luck". I can't wait that long. That's exactly what I
mean: you have to wait ages and hope and pray that you can write
a useful program someday. No thanks. With D I grabbed existing
C/C++ audio frameworks and moved on to more important issues.
In my opinion, if a technology like Java needs so many
crutches to make it work on different platforms, then it's
useless for cross-platform development. Also, once you need
interaction with the system or other (native) applications,
then it becomes frustrating pretty soon. D solved all these
problems for me and more, in fact it helped me to design a
better product, because it opened doors for me as regards both
programming patterns and interaction with the system and
various libraries. That there are other languages with which I
could have achieved similar things, I do not doubt. But I do
doubt that it would have been so easy, and the fact that new
languages that aim for what D already stands for are still
being invented (cf. Nimrod) shows that existing mainstream
technologies like Java, C++, C# don't meet programmers'
demands yet.
I am pleased D is working for you when you feel Java didn't at
that
time. Things move on though: what may have been true about Java
then may
not be now. Decisions must always be being reassessed after a
while.
Why on earth should I reassess this decision now? D works for
_me_ (maybe not for everybody). Why should I rewrite the whole
thing in Java or use Java for new projects, when I know there are
still issues that are absolute deal breakers for me (like the
sound API)? Java is just not a good language to write
cross-platform programs that have to be integrated into the
system or (native) 3rd party applications. So why bother?
All
languages have some platform dependent issues unless they are
only
working on only a single platform. Java, Python, Ruby, etc.
generally
depend on the virtual machine and support libraries to get
things right,
but allowing platform dependent application code as well. C,
C++, etc.
put essentially all of the portability issues into the
programmers hands
and hence lots of build sophistication or #if.
At least you have control over it.
Then there is the dynamic link library problem creating a mass
of pain.
D and Go ran away from this by having statically linked code
only, at
the expense of 2–10MB executables!
I have no problem with that, still better than delivering a 40 MB
Java package for an otherwise tiny plug-in. The DLL I have in D
is 855.6 kB, the whole package with libs and various resource
files is ~4.2 MB download size as zip and ~8 MB when installed.
With shared libraries becoming an issue in D again, that set of
dependency and platform problems will raise their heads.
