OT Java stuff [was Using D]

[Russel Winder via Digitalmars-d]

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. 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.

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.

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.

> 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. 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.

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!

With shared libraries becoming an issue in D again, that set of
dependency and platform problems will raise their heads.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140826/122fe13e/attachment.sig>