On 25 August 2014 12:19, Russel Winder via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Mon, 2014-08-25 at 08:40 +0000, Colin via Digitalmars-d wrote: […]
>>
>> Is this the beginnings of a London based DConf?
>> (Note: That'd be great!)
>
> Whilst it would be good for DConf to come to London for 2015 (*) this
> was about having a London D User Group meeting, hopefully on a regular
> basis (**).
>
>
> (*) I am sure we could get Skills Matter to run it.
>
> (**) Skills Matter would definitely host this for us.
>

Perhaps we should send a probe out ot see how many people would be:

[ ] Interested  [ ] Undecided  [ ] Not Interested

in wanting to come down to such a meeting.  Also topics for discussion. :)

Iain.

On Tue, 2014-08-26 at 11:27 +0100, Iain Buclaw via Digitalmars-d wrote:
> On 25 August 2014 12:19, Russel Winder via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> > On Mon, 2014-08-25 at 08:40 +0000, Colin via Digitalmars-d wrote: […]
> >>
> >> Is this the beginnings of a London based DConf?
> >> (Note: That'd be great!)
> >
> > Whilst it would be good for DConf to come to London for 2015 (*) this
> > was about having a London D User Group meeting, hopefully on a regular
> > basis (**).
> >
> >
> > (*) I am sure we could get Skills Matter to run it.
> >
> > (**) Skills Matter would definitely host this for us.
> >
> 
> Perhaps we should send a probe out ot see how many people would be:
> 
> [ ] Interested  [ ] Undecided  [ ] Not Interested

I am definitely Interested.

> in wanting to come down to such a meeting.  Also topics for discussion. :)

We could also mix and match as many other user groups do. So for example some have a presentation session one month, drinks session the next. Others are entirely code dojo oriented. I see no reason not to embrace all things that can be done when people get together. So some presentation sessions, possibly with longer and lightning talks mixed, some short hackergarten events, etc.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tuesday, 26 August 2014 at 10:27:47 UTC, Iain Buclaw via Digitalmars-d wrote:
> Perhaps we should send a probe out ot see how many people would be:
>
> [ ] Interested  [ ] Undecided  [ ] Not Interested
>
> in wanting to come down to such a meeting.  Also topics for discussion. :)
>
> Iain.

I totally hope to see you all in Brussels if FOSDEM proposal will fly ;)

>
>
>> 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 what you get with shared libraries.  If you don't want to deal with dependencies, either A) ship a static-linked binary or B) cross your fingers and pray.

I've found the java ecosystem to be quite well fleshed out and mature in handling lib/jar dependencies, such that it was an unpleasant shock dealing with C++ after years away.  Using maven, for instance, is a quick and easy way to abstract the problems away (though it is better suited for builds than deployments).


As D gets more support for dynamic libraries, it would be good to take lessons from how Java and others have dealt with dependency management.

On Tuesday, 26 August 2014 at 22:07:49 UTC, Jeremy Powers via Digitalmars-d wrote:
>>
>>
>>> 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 what you get with shared libraries.  If you don't want to deal with
> dependencies, either A) ship a static-linked binary or B) cross your
> fingers and pray.

Statically linked binaries are still the best option, if you want to make sure things will work for the user (and you don't have time for customer service). It's also a good strategy for cross-platform development, this or you have to use an approach similar to Textadept that ships everything in one package. I usually ship all the additional dlls / libs, if there are any.

Relying on system wide dynamic linking is more for cases when you develop for one particular environment or when you're 90% sure that a certain library exists on most systems you develop for. The C standard library comes to mind, but even there are differences between Linux and Windows. And don't forget that, unlike Linux users, people who use Windows are usually not tech savvy in the sense that they can deal with downloading additional libraries.

It all depends on the products you're developing. But for our stuff it's better to go static or ship everything.

> I've found the java ecosystem to be quite well fleshed out and mature in
> handling lib/jar dependencies, such that it was an unpleasant shock dealing
> with C++ after years away.  Using maven, for instance, is a quick and easy
> way to abstract the problems away (though it is better suited for builds
> than deployments).
>
>
> As D gets more support for dynamic libraries, it would be good to take
> lessons from how Java and others have dealt with dependency management.

Yes, only better. :-)

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.

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

Actually virtually all other languages, including D, are just as bad as Java (if not worse) in the aspects mentioned above. For example, if you write code which heavily interacts with the filesystem, you are bound to encounter platform/OS-specific problems no matter what language. I'd bet money those "even simple things like deleting files", you'd have in D as well. At least in Java the APIs they are usually careful to specify which aspects of behavior are implementation-specific.

In other cases, such as the sound library or accessibility library, most other cross-platform language don't even have those!, so how can you be saying that D runs better on each platform that Java?..
(Does a non-existent library run perfectly on every conceivable platform? one could say yes...)

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

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.

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

> Actually virtually all other languages, including D, are just as bad as Java (if not worse) in the aspects mentioned above. For example, if you write code which heavily interacts with the filesystem, you are bound to encounter platform/OS-specific problems no matter what language. I'd bet money those "even simple things like deleting files", you'd have in D as well. At least in Java the APIs they are usually careful to specify which aspects of behavior are implementation-specific.

Well, my statement refered to the fact that Java f**ked up big time there, which clearly breaks the promise "write once, run everywhere", especially because dealing with files is a feature one would expect to be part and parcel of a programming language. Deleting files should not give you a headache. Basically what you're saying is "Java is cross-platform but it's not, but hey, other languages are just as bad!". Well, then they should stop using the word "cross-platform" when advertising their language.

> In other cases, such as the sound library or accessibility library, most other cross-platform language don't even have those!, so how can you be saying that D runs better on each platform that Java?..
> (Does a non-existent library run perfectly on every conceivable platform? one could say yes...)

D interfaces to existing audio / sound libraries in C (libsndfile, portaudio). All you have to do is to include those libs and call the functions you need. Doing this with Java is a bit more complicated (you'll probably need tools).

You are welcome to report on any serious issues you've encountered when porting D programs to various platforms. Maybe it can be fixed in the core of the language and it would help to make D even more portable. A lot of cross-platform issues can be dealt with by including "version(Windows/Posix ...)" in your code.

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

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

>> Actually virtually all other languages, including D, are just as bad
>> as Java (if not worse) in the aspects mentioned above. For example, if
>> you write code which heavily interacts with the filesystem, you are
>> bound to encounter platform/OS-specific problems no matter what
>> language. I'd bet money those "even simple things like deleting
>> files", you'd have in D as well. At least in Java the APIs they are
>> usually careful to specify which aspects of behavior are
>> implementation-specific.
>
> Well, my statement refered to the fact that Java f**ked up big time
> there, which clearly breaks the promise "write once, run everywhere",
> especially because dealing with files is a feature one would expect to
> be part and parcel of a programming language. Deleting files should not
> give you a headache. Basically what you're saying is "Java is
> cross-platform but it's not, but hey, other languages are just as bad!".
> Well, then they should stop using the word "cross-platform" when
> advertising their language.
>

If the core of the language was "working with with filesystem", then yeah, they should not advertise it as cross-platform. But it's not the core of language (even if it's part of the standard library), it's just a minor library component, one amongst many (the vast majority of it being fully cross-platform).

>> In other cases, such as the sound library or accessibility library,
>> most other cross-platform language don't even have those!, so how can
>> you be saying that D runs better on each platform that Java?..
>> (Does a non-existent library run perfectly on every conceivable
>> platform? one could say yes...)
>
> D interfaces to existing audio / sound libraries in C (libsndfile,
> portaudio). All you have to do is to include those libs and call the
> functions you need. Doing this with Java is a bit more complicated
> (you'll probably need tools).
>
> You are welcome to report on any serious issues you've encountered when
> porting D programs to various platforms. Maybe it can be fixed in the
> core of the language and it would help to make D even more portable. A
> lot of cross-platform issues can be dealt with by including
> "version(Windows/Posix ...)" in your code.


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

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.

[1] Have a look at this. It was really just as simple:

http://wiki.dlang.org/Win32_DLLs_in_D

>>> Actually virtually all other languages, including D, are just as bad
>>> as Java (if not worse) in the aspects mentioned above. For example, if
>>> you write code which heavily interacts with the filesystem, you are
>>> bound to encounter platform/OS-specific problems no matter what
>>> language. I'd bet money those "even simple things like deleting
>>> files", you'd have in D as well. At least in Java the APIs they are
>>> usually careful to specify which aspects of behavior are
>>> implementation-specific.
>>
>> Well, my statement refered to the fact that Java f**ked up big time
>> there, which clearly breaks the promise "write once, run everywhere",
>> especially because dealing with files is a feature one would expect to
>> be part and parcel of a programming language. Deleting files should not
>> give you a headache. Basically what you're saying is "Java is
>> cross-platform but it's not, but hey, other languages are just as bad!".
>> Well, then they should stop using the word "cross-platform" when
>> advertising their language.
>>
>
> If the core of the language was "working with with filesystem", then yeah, they should not advertise it as cross-platform. But it's not the core of language (even if it's part of the standard library), it's just a minor library component, one amongst many (the vast majority of it being fully cross-platform).
>
>>> In other cases, such as the sound library or accessibility library,
>>> most other cross-platform language don't even have those!, so how can
>>> you be saying that D runs better on each platform that Java?..
>>> (Does a non-existent library run perfectly on every conceivable
>>> platform? one could say yes...)
>>
>> D interfaces to existing audio / sound libraries in C (libsndfile,
>> portaudio). All you have to do is to include those libs and call the
>> functions you need. Doing this with Java is a bit more complicated
>> (you'll probably need tools).
>>
>> You are welcome to report on any serious issues you've encountered when
>> porting D programs to various platforms. Maybe it can be fixed in the
>> core of the language and it would help to make D even more portable. A
>> lot of cross-platform issues can be dealt with by including
>> "version(Windows/Posix ...)" in your code.

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

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


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