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)?

> As for OOP evangelists, had Java not happened, probably your rant would be now be about Smalltalk and Eiffel. The two OO languages getting an enterprise foothold at the time Sun started pushing Java.
>
> --
> Paulo

It's not a rant. I'm happier in the D world than in the Java world, that's all. It's only when you step outside of the Java world that you realize who restricted and restrictive it is. For what it's worth, Java is a safe enough technology for companies. Middle of the road type of thing.

On 9/5/2014 11:42 PM, Chris wrote:
> On Friday, 5 September 2014 at 14:18:46 UTC, Paulo  Pinto wrote:

>
> It's not a rant. I'm happier in the D world than in the Java world,
> that's all. It's only when you step outside of the Java world that you
> realize who restricted and restrictive it is. For what it's worth, Java
> is a safe enough technology for companies. Middle of the road type of
> thing.

Java has its place. I would say that Python plugins isn't it. Right tool for the job and all that. Like you, I'm happier in the D world, but I don't see it as a silver bullet. I'd still choose Java for particular projects for the same reasons I'd choose Java over C++ for those same projects. I don't find it restrictive at all (I actually enjoy it; I also enjoy C). As long as you work within its boundaries and use it as it's meant to be used, it works perfectly well.

That holds true for any language and, IMO, is what trips people up the most when moving from one language to another. This is very clear when you take, say, a Java programmer who actually likes it and one who uses it for the day job but prefers C++ and compare their list of gripes. Eckel's books are called "Thinking in..." for a reason.


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

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

On Friday, 5 September 2014 at 15:13:02 UTC, Mike Parker wrote:
> On 9/5/2014 11:42 PM, Chris wrote:
>> On Friday, 5 September 2014 at 14:18:46 UTC, Paulo  Pinto wrote:
>
>>
>> It's not a rant. I'm happier in the D world than in the Java world,
>> that's all. It's only when you step outside of the Java world that you
>> realize who restricted and restrictive it is. For what it's worth, Java
>> is a safe enough technology for companies. Middle of the road type of
>> thing.
>
> Java has its place. I would say that Python plugins isn't it. Right tool for the job and all that. Like you, I'm happier in the D world, but I don't see it as a silver bullet. I'd still choose Java for particular projects for the same reasons I'd choose Java over C++ for those same projects. I don't find it restrictive at all (I actually enjoy it; I also enjoy C). As long as you work within its boundaries and use it as it's meant to be used, it works perfectly well.

The plugin had to be for Python, and for other languages to be able to plug into native MSAPI, OS X etc. Among other things, Java's unpluginability (if that's a word :) kicked it out of the race. Atm, I don't see any reason to start a project in Java. Even server side programming can be done by D.

Maybe I'll consider Java again when they have AOT compilation. I really liked Java, but it became more and more useless for my purposes. And once you have the freedom that D offers, it's hard to go back.

"I don't find it  restrictive at all (I actually enjoy it; I also enjoy C). As long as you work within its boundaries and use it as it's meant to be used, it works perfectly well."

Isn't this statement a bit contradictory :) It's not restrictive as long as you stay within its boundaries. In D you can stretch the boundaries a bit.

> That holds true for any language and, IMO, is what trips people up the most when moving from one language to another. This is very clear when you take, say, a Java programmer who actually likes it and one who uses it for the day job but prefers C++ and compare their list of gripes. Eckel's books are called "Thinking in..." for a reason.
>
>
> ---
> This email is free from viruses and malware because avast! Antivirus protection is active.
> http://www.avast.com

On Friday, 5 September 2014 at 14:18:46 UTC, Paulo  Pinto wrote:
> You can write DLLs in Java, for example with http://www.excelsiorjet.com/.
>
> The fact that the Java reference implementation is a VM, doesn't tie the language to a VM.
>

True, but it is VERY hard to get performance out of it outside a
VM. Java is tailored for a VM.

On Friday, 5 September 2014 at 14:18:46 UTC, Paulo  Pinto wrote:
> You can write DLLs in Java, for example with http://www.excelsiorjet.com/.
>
> The fact that the Java reference implementation is a VM, doesn't tie the language to a VM.

Why pick Java if not for JVM? It is mediocre language at most, very limited and poor feature-wise, lacking expressive power even compared to C++ (you can at least abuse templates in the latter). JVM, however, may be the best VM environment implementation out there and that can be useful.

Am 05.09.2014 23:56, schrieb Dicebot:
> On Friday, 5 September 2014 at 14:18:46 UTC, Paulo  Pinto wrote:
>> You can write DLLs in Java, for example with
>> http://www.excelsiorjet.com/.
>>
>> The fact that the Java reference implementation is a VM, doesn't tie
>> the language to a VM.
>
> Why pick Java if not for JVM? It is mediocre language at most, very
> limited and poor feature-wise, lacking expressive power even compared to
> C++ (you can at least abuse templates in the latter). JVM, however, may
> be the best VM environment implementation out there and that can be useful.

Enterprise answer:

- lots of libraries to chose from;
- lots of easy to find (replacable) programmers;

--
Paulo

On 9/6/2014 12:32 AM, Chris wrote:

>
> "I don't find it  restrictive at all (I actually enjoy it; I also enjoy
> C). As long as you work within its boundaries and use it as it's meant
> to be used, it works perfectly well."
>
> Isn't this statement a bit contradictory :) It's not restrictive as long
> as you stay within its boundaries. In D you can stretch the boundaries a
> bit.

Not contradictory, no. Every language has boundaries and you can stretch them in any language. My point is that when you do so you are then in the wild frontier and are more likely to be frustrated in your efforts.


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

06-Sep-2014 04:50, Paulo Pinto пишет:
> Am 05.09.2014 23:56, schrieb Dicebot:
>> On Friday, 5 September 2014 at 14:18:46 UTC, Paulo  Pinto wrote:
>>> You can write DLLs in Java, for example with
>>> http://www.excelsiorjet.com/.
>>>
>>> The fact that the Java reference implementation is a VM, doesn't tie
>>> the language to a VM.
>>
>> Why pick Java if not for JVM? It is mediocre language at most, very
>> limited and poor feature-wise, lacking expressive power even compared to
>> C++ (you can at least abuse templates in the latter). JVM, however, may
>> be the best VM environment implementation out there and that can be
>> useful.
>
> Enterprise answer:
>
> - lots of libraries to chose from;

Any JVM language has that.

> - lots of easy to find (replacable) programmers;

That is both blessing and the curse.
>
> --
> Paulo


-- 
Dmitry Olshansky

On Saturday, 6 September 2014 at 00:50:26 UTC, Paulo Pinto wrote:
> Am 05.09.2014 23:56, schrieb Dicebot:
>> On Friday, 5 September 2014 at 14:18:46 UTC, Paulo  Pinto wrote:
>>> You can write DLLs in Java, for example with
>>> http://www.excelsiorjet.com/.
>>>
>>> The fact that the Java reference implementation is a VM, doesn't tie
>>> the language to a VM.
>>
>> Why pick Java if not for JVM? It is mediocre language at most, very
>> limited and poor feature-wise, lacking expressive power even compared to
>> C++ (you can at least abuse templates in the latter). JVM, however, may
>> be the best VM environment implementation out there and that can be useful.
>
> Enterprise answer:
>
> - lots of libraries to chose from;
> - lots of easy to find (replacable) programmers;
>
> --
> Paulo

That's exactly it, I mean the second point. This is why it's the preferred choice of companies and that's why they hold on to it (and they can pay less, based on "a dime a dozen"). Also, it's the safe middle ground. If a manager uses Java, s/he's sound. If s/he used D or something else, s/he'd have a hard time justifying his/her choice. Java: no questions asked.