Using D

Fri Sep 5 08:21:59 PDT 2014

On Friday, 5 September 2014 at 14:42:05 UTC, Chris wrote:
> On Friday, 5 September 2014 at 14:18:46 UTC, Paulo  Pinto wrote:
>> On Friday, 5 September 2014 at 13:42:56 UTC, Chris wrote:
>>> On Friday, 5 September 2014 at 11:27:17 UTC, Bruno Medeiros 
>>> wrote:
>>>> On 04/09/2014 16:21, Chris wrote:
>>>>> On Thursday, 4 September 2014 at 14:19:02 UTC, Bruno 
>>>>> Medeiros wrote:
>>>>>> On 26/08/2014 09:46, Chris 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.
>>>>>>
>>>>>> The promise of "Write once run everywhere" is still pretty 
>>>>>> much
>>>>>> accurate if you stick to core Java code and libraries. Of 
>>>>>> course once
>>>>>> you start using OS/implementation specific code you will 
>>>>>> have to code
>>>>>> more carefully, and are more likely to encounter 
>>>>>> cross-platform
>>>>>> problems. That's just the nature of things, you can't say 
>>>>>> it's a
>>>>>> failure of Java.
>>>>>> It's like coding in D using lots of malloc/free in your 
>>>>>> code, and then
>>>>>> when your program breaks, you complain that "the D GC 
>>>>>> doesn't work!".
>>>>>> Of course the GC only is only guaranteed to work if you 
>>>>>> stick to
>>>>>> GC-managed memory.
>>>>>
>>>>> I can expect the Java Access Bridge to work, because Java 
>>>>> offers it as a
>>>>> built-in technology. If it does not work, it's a broken 
>>>>> promise. Simple
>>>>> as that.
>>>>>
>>>>
>>>> Does Java Access Bridge really not work, or you just didn't 
>>>> use it right? Or are you trying to use in for a purpose it's 
>>>> aimed to be used? Unfortunately, I'm not familiar with JAB, 
>>>> so I can't comment further on it..
>>>
>>> I used it with Swing. It was ignored by all the screen 
>>> readers.
>>>
>>>>>> To be honest I smell a load of Java-biased *BS* here, 
>>>>>> especially
>>>>>> because of this sentence:
>>>>>> "Instead, I learned D which I can compile and run on each 
>>>>>> platform
>>>>>> without a problem."
>>>>>
>>>>> Which is true. I could compile it on Linux, OS X and 
>>>>> Windows. It was
>>>>> almost trivial to write a DLL that third party software can 
>>>>> use. Try
>>>>> that with Java and tell me if it's trivially easy. I think 
>>>>> what you
>>>>> meant was _anti_-Java *BS*. I'm only writing about my 
>>>>> experience with
>>>>> the two languages. The one worked for me, the other didn't.
>>>>>
>>>>
>>>> When you say DLL, do you mean a shared library in general, 
>>>> or really an actual Windows DLL? I'm assuming it's the 
>>>> former, otherwise that doesn't make sense. Well In Java you 
>>>> can create them quite easily: jars. They are trivial to be 
>>>> used by other Java programs! I don't see your point.
>>>
>>> I mean a DLL that can be loaded by say a Python program (as 
>>> in my case) or any other software that wants to use my 
>>> plug-in[1]. A jar can only be used by another Java program. 
>>> Making a Java program accessible to 3rd party software via a 
>>> DLL is not so simple, and the JVM has to be up and running 
>>> all the time. Java is cross-platform as long as you stay 
>>> within the safe and cosy Java bubble that floats on top of 
>>> the JVM. But once you step outside of the JVM, gravity kicks 
>>> in.
>>>
>>> Don't get me wrong. I like the concept of a VM. Only Java has 
>>> been screwed up over the years by bad and wrong decisions, 
>>> partly due to ideology and partly due to strategic / 
>>> marketing decisions. It's a pity really. It started out as a 
>>> very promising language but got caught under the wheels of 
>>> corporate decisions and OOP evangelists.
>>>
>>
>> You can write DLLs in Java, for example with 
>> http://www.excelsiorjet.com/.
>
> I know, I know, but in D it comes for free. This would have 
> broken the bank.
>
>> The fact that the Java reference implementation is a VM, 
>> doesn't tie the language to a VM.
>>
>> There are quite a few commercial compilers and JVMs with AOT 
>> support to choose from.
>>
>> Oracle is finally thinking about adding a AOT compilation mode 
>> to the standard toolchain in the Java 9+ release.
>>
>> http://www.oracle.com/technetwork/java/jvmls2014goetzrose-2265201.pdf
>
> Finally, I've been waiting for this since forever. I always 
> wondered why they didn't do it. Then again it was all about the 
> "write once ..." ideology and they thought AOT would undermine 
> this (which is not true). Why shouldn't programmers be able to 
> make the decision (VM / AOT where it makes sense)?

I once read in a forum, shortly after the Oracle/Sun acquisition 
aftermath that there was a strong political position inside Sun 
against AOT.

The post was arguably from an ex-Sun employee, but I cannot say 
s/he was really telling the truth.

Actually, I think it was a bad decision to have gone fully VM, 
without any optional AOT options in the standard toolchain.

At least in the ML, Lisp, .NET, Oberon, AS/400 worlds ..., you 
get to choose.

--
Paulo