On Monday, 25 August 2014 at 14:54:33 UTC, ketmar via Digitalmars-d wrote:
> On Mon, 25 Aug 2014 14:41:46 +0000
> via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> D does seem to lack type variables? So it is quite static in comparison.
> the problem with "overly dynamic" languages like Smalltalk (and
> especially Self) is that it's insanely hard to write an efficient
> compiler which generates fast machine code. JIT compilation,
> polymorphic inline caching and alot of other techniques allows this
> languages to work with "acceptable speed", but primitive C compiler with
> peephole optimizer can beat 'em easily.
>
> D is aimed to generate efficient machine code, so it must be "static".
> we can emulate dynamic calls with AA and opDispatch, but this will
> be... not fast. ;-)

May be, but JIT were created thanks to Lisp and Smalltalk.

In Smalltalk's case, the genesis to Java Hotspot JIT, lies in this paper,

http://dl.acm.org/citation.cfm?id=894616

--
Paulo

On Mon, 25 Aug 2014 16:33:00 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> I think the whole separate compilation idea is going to be old fashioned real soon now. It makes little sense to not have the build system as a service run on a cluster and the program as a database with builtin versioning.
but i don't want to buy and setup 42 servers in my room just to compile "hello world"! ;-)

and no, i will not buy all that modern BS about "clouds".

> Why recompile the whole file when only a tiny function should be according to the dependencies?
i forgot the language, but i clearly seen something like that. database demon which keeping either sources or AST (i don't remember) and compiler which uses that info. it was... strange, but interesting.

On Mon, 25 Aug 2014 14:36:21 -0300
Ary Borenszweig via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> The trick is to not use virtual tables, but do multiple dispatch (or only use virtual tables when needed). If you have:
> 
> a = Foo.new
> a.some_method
such simple code analysis easily confused by function calls. or we have to analyse function body at each call and instantiate parameterised functions. ah, hello, interprocedural analysis. and what if function is in another module? ah, hello, full program analysis. and bye-bye, compilation speed.

> To me, the real problem with OOP is to automatically relate it to virtual tables, interfaces, etc.
i myself thinking about message passing when i see OOP mentioned. ;-)

On Mon, 25 Aug 2014 17:50:35 +0000
Paulo Pinto via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> May be, but JIT were created thanks to Lisp and Smalltalk.
i know that. i'm interested in JIT developement and know about Self, Strongtalk and other strange words. ;-)

and i really hate SUN for practically killing Strongtalk. Java sux and Strongtalk is dead. loose-loose.

On 8/25/2014 2:01 AM, Chris wrote:
> The main thing that put me off Java was not so much the fact that you're
> restricted to OOP and that it's verbose etc., but that it caused all sorts of
> problems when shipping the actual programs. "Write once run everywhere" is a
> myth, if you ask me. D is much closer to that than Java. In the end we
> encountered so many problems that I dumped Java for cross platform development
> (and for development in general). Nobody in the Java world ever talks about
> this, but cross platform doesn't really work (apart from running simple programs).

I haven't ported much Java code, but I have found D code to be significantly easier to port than C++.

The varying sizes of basic types in C++ is what causes most of the problems.

On Tuesday, 26 August 2014 at 04:03:17 UTC, ketmar via Digitalmars-d wrote:
> On Mon, 25 Aug 2014 16:33:00 +0000
> via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> I think the whole separate compilation idea is going to be old fashioned real soon now. It makes little sense to not have the build system as a service run on a cluster and the program as a database with builtin versioning.
> but i don't want to buy and setup 42 servers in my room just to compile
> "hello world"! ;-)

You won't, your single home computer will be enough for small programs.  But if your code ever grows large enough to benefit from a cluster, you'll just sign up for an account online and you tools will automatically start sending your diffs to the remote cluster and compiling the code there.

> and no, i will not buy all that modern BS about "clouds".

It is amazing that the "cloud" is being applied to a host of problems, but not really to speed up building software yet.  Of course, there's a bunch of giant corporations, like Facebook or Google, putting their own private "clouds" to such uses, but the vast majority of programmers just use a powerful workstation instead, the old '80s model of software development.  That will change.

It's not that you can't roll your own and do it on AWS right now, it just isn't dead simple to do it off the shelf, so most don't.  And of course test runs have been increasingly pushed into these remote clusters.  Other than a few devs with privacy and security concerns, most will move to such a "cloud" model in the coming years.

On Tue, 26 Aug 2014 05:59:45 +0000
Joakim via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Other than a few devs with privacy and security concerns
it's about me. ;-)

On Tuesday, 26 August 2014 at 05:58:36 UTC, Walter Bright wrote:
> On 8/25/2014 2:01 AM, Chris wrote:
>> The main thing that put me off Java was not so much the fact that you're
>> restricted to OOP and that it's verbose etc., but that it caused all sorts of
>> problems when shipping the actual programs. "Write once run everywhere" is a
>> myth, if you ask me. D is much closer to that than Java. In the end we
>> encountered so many problems that I dumped Java for cross platform development
>> (and for development in general). Nobody in the Java world ever talks about
>> this, but cross platform doesn't really work (apart from running simple programs).
>
> I haven't ported much Java code, but I have found D code to be significantly easier to port than C++.
>
> The varying sizes of basic types in C++ is what causes most of the problems.

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.

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.

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