View mode: basic / threaded / horizontal-split · Log in · Help
February 26, 2013
Re: D and Java [was Re: The DUB package manager]
On Sun, 2013-02-24 at 16:32 -0500, Nick Sabalausky wrote:
[…]
> Luckily, modern server hardware should support hardware virtualization,
> and most languages/libs are pretty good at cross-platform, so this
> one shouldn't be much of a "reason for JVM" anymore like it might have
> been ten or so years ago.

But this is where "virtual != virtual": hardware virtualization is a
different thing from virtual machines. The reason for JVM and PVM
remains even in a world of server virtualization. Cross platform is not
the application developers problem using a virtual machine as it is with
native codes. This has not changed.

-- 
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
February 26, 2013
Re: D and Java [was Re: The DUB package manager]
On Tuesday, 26 February 2013 at 05:13:10 UTC, Russel Winder wrote:
> On Sun, 2013-02-24 at 15:49 +0400, Dmitry Olshansky wrote:
> […]

> Any Java user still planning to stay with Java 6 or earlier and 
> not
> planning to switch asap to Java 7 will be on their own very 
> quickly and
> seen and just another legacy problem.
>

My employer is still getting requests for proposals with Java 
1.4! :(

> […]
> With the current marketing strategy, this is how D is going to 
> remain. D
> does not have an organization such as Google pushing it as Go 
> has had.

Even with my continous complains about lack of generics in 
gonuts, I do realize it is easier to push Go at the workplace 
using the "it is from Google" excuse.

That is how I have been pushing F# lately (being a Microsoft 
language).

>> b) No support for loading shared libraries (bye-bye sane 
>> plugin architecture)
>
> Go has eschewed all dynamic linking and is making this a 
> feature.

They might eventually be forced to reconsider it. Even Plan9 had 
dynamic linking support.

>
>> c) Lack of stable 3-rd party libs for pretty much everything
>> (this is getting better but is not there by miles)
>
> Go has managed to attract volunteer labour to write in Go new 
> versions
> of everything previously written in C other than actual OSs. 
> But even
> there people are beginning to write OSs in Go.


This I find great and is a reason I always give information about 
Oberon language family and Modula-3 based OS.

More people need to be aware it is possible to write proper OS in 
GC enabled system programming languages without a single line of 
C or C++.

--
Paulo
February 26, 2013
Re: D and Java [was Re: The DUB package manager]
On 2/26/13 12:12 AM, Russel Winder wrote:
> It is possible Java 9 or Java 10 will remove the primitive types
> completely so that all variables are reference types leaving it to the
> JVM to handle all boxing and unboxing internally thus making things a
> lot more efficient and faster.  Experiments are scheduled and underway,
> decisions made only once the results are in.

That's very interesting. Got any related links?

Thanks,

Andrei
February 26, 2013
Re: D and Java [was Re: The DUB package manager]
On Tuesday, 26 February 2013 at 05:13:10 UTC, Russel Winder wrote:
> Go has eschewed all dynamic linking and is making this a 
> feature. But it
> has a mechanism for being able to call C from libraries. Python 
> has a
> mechanism for calling C from shared libraries. D is at a 
> disadvantage.

I fail to see how D is at a disadvantage here.
February 26, 2013
Re: D and Java [was Re: The DUB package manager]
On Tue, 26 Feb 2013 05:16:29 +0000
Russel Winder <russel@winder.org.uk> wrote:

> On Sun, 2013-02-24 at 16:32 -0500, Nick Sabalausky wrote:
> […]
> > Luckily, modern server hardware should support hardware
> > virtualization, and most languages/libs are pretty good at
> > cross-platform, so this one shouldn't be much of a "reason for JVM"
> > anymore like it might have been ten or so years ago.
> 
> But this is where "virtual != virtual": hardware virtualization is a
> different thing from virtual machines. The reason for JVM and PVM
> remains even in a world of server virtualization.

How so? VM is about two things: sandboxing and cross-platform.
Hardware virtualization is sandboxing without the overhead of bytecode.
As for cross-platform:

> Cross platform is
> not the application developers problem using a virtual machine as it
> is with native codes. This has not changed.
> 

Anytime you actually *need* to take a platform difference into account,
a VM will not help you. If anything it might get in your way. In all
other cases, forcing handling of platform differences onto the
application developer is a failure of library API design - using native
does not change that.
February 26, 2013
Re: D and Java [was Re: The DUB package manager]
On Tue, 26 Feb 2013 05:12:59 +0000
Russel Winder <russel@winder.org.uk> wrote:

> On Sun, 2013-02-24 at 15:49 +0400, Dmitry Olshansky wrote:
> […]
> > You missed the point that these have to be the *real* integer
> > constants starting from 0. No frigging magic classes please.
> 
> I am not sure why they have to be hardware integers, this is a
> JVM-based system and hardware integers do not exist. I feel a
> contradiction between requirements and technology here!
> 

JVM runs on hardware therefore hardware integers clearly do exist
whether JVM chooses to expose them or block them.


> Safe Enum pattern/idiom is indeed all about the representation of the
> symbols being instances of a class. But small immutable objects are
> very cheap these days on the JVM.
> 

As cheap as a real native primitive?

> It is possible Java 9 or Java 10 will remove the primitive types
> completely so that all variables are reference types leaving it to the
> JVM to handle all boxing and unboxing internally thus making things a
> lot more efficient and faster.

How could that possibly be *more* efficient and faster?


> 
> Go has eschewed all dynamic linking and is making this a feature. But
> it has a mechanism for being able to call C from libraries. Python
> has a mechanism for calling C from shared libraries. D is at a
> disadvantage.
> 

D is also able to call C. And it doesn't pretend that missing dynamic
lib support is a "feature". D is certainly not at any disadvantage
here.

> 
> Go has managed to attract volunteer labour to write in Go new versions
> of everything previously written in C other than actual OSs. But even
> there people are beginning to write OSs in Go.
> 

FWIW, People have already written OS in D.
February 27, 2013
Re: D and Java [was Re: The DUB package manager]
26-Feb-2013 09:12, Russel Winder пишет:
> On Sun, 2013-02-24 at 15:49 +0400, Dmitry Olshansky wrote:
> […]
>> You missed the point that these have to be the *real* integer constants
>> starting from 0. No frigging magic classes please.
>
> I am not sure why they have to be hardware integers, this is a JVM-based
> system and hardware integers do not exist. I feel a contradiction
> between requirements and technology here!


'cause they are read from network stream. Basically they are tags/IDs.
Then there is a read-dispatch loop based on combination of tags/IDs.

In a sense all of this execution state that is dispatched to can be 
encapsulated inside of a class. One class per ID that can be called 
Command or Packet. Then switch translates to visitor that visits packets 
as these are constructed from stream.

Then you can even chain visitors together etc. and it would be beautiful 
were it not for slowness and tons of boilerplate to create all of the 
classes. Again the above thing could be easily done with a table of 
functor once Java has lambdas.

Everything I need seems to require easy to use lambdas ... a disturbing 
thought.

>
>> Citing Oracle:
>>    All enums implicitly extend java.lang.Enum. Since Java does not
>> support multiple inheritance, an enum cannot extend anything else.
>>
>> My thoughts after reading this: "holy crap, they are class instances".
>> Even then we seem to use enums where there is no need for integer
>> constants specifically.
>
> Safe Enum pattern/idiom is indeed all about the representation of the
> symbols being instances of a class. But small immutable objects are very
> cheap these days on the JVM.

M-hm. I'm not sure it would work when you actually store these as 
members of other instances like Command or Packet as above. But maybe 
JVM can cheat a bit even there I dunno.

> It is possible Java 9 or Java 10 will remove the primitive types
> completely so that all variables are reference types leaving it to the
> JVM to handle all boxing and unboxing internally thus making things a
> lot more efficient and faster.  Experiments are scheduled and underway,
> decisions made only once the results are in.

Till then. But e.g. Scala claims to do just fine with this approach.

> […]
>>   From what I read about Java 8 it is tolerable (as the language). Still
>> a far cry from D but largely more usable then now.
>
> Java 8 and Groovy (also Scala, possibly Clojure, Kotlin and Ceylon) will
> make it hard for any organization with a JVM heritage to even
> contemplate switching to native.
>
> No matter how good D is compared to C++ or Java, if there is no easy
> route for take up, D will remain is the traction position it currently
> is.
>
> […]

Mmm I wondering what does Go have to do with the topic at hand since it 
doesn't have direct C call mechanism and thus is worse then Java as I 
for one would call Go's GC quite pedestrian and  the ecosystem way to 
young. The other thing is that "it's from Google" won't sell it where I 
work at all (it will work against probably) since people are all 
technically skilled and have no respect for argumentum ad populum.

Again even Java was chosen given constraints and practical need. It 
wasn't my decision and I don't quite like it (I'm a newcomer there). 
Still I see the logic behind the choice and certain advantages it brings.

>> D would probably fit perfectly were it not for:
>> a) Not widely recognized but sometimes we may cheat and tell it's C++
>
> With the current marketing strategy, this is how D is going to remain. D
> does not have an organization such as Google pushing it as Go has had.
> Yet there is a strong analogy: Go is C with warts removed and modern
> stuff added. D is C++ with warts removed and modern stuff added. Go has
> a small hardcore that is active and outward looking trying to create
> replacements for all the C and Python codes that people actually use. Go
> sells itself on the purity of the concurrency model and it object model,
> not mention GC. D on the other hand has a small hardcore.


>> b) No support for loading shared libraries (bye-bye sane plugin
>> architecture)
>
> Go has eschewed all dynamic linking and is making this a feature. But it
> has a mechanism for being able to call C from libraries. Python has a
> mechanism for calling C from shared libraries. D is at a disadvantage.

D is twice better then Go then: it calls C directly and has (will have) 
shared library support. For now it just calls into C's shared libs we 
need both ways and that's all. And Go is worse then Python still ;)

>> c) Lack of stable 3-rd party libs for pretty much everything
>> (this is getting better but is not there by miles)
>
> Go has managed to attract volunteer labour to write in Go new versions
> of everything previously written in C other than actual OSs. But even
> there people are beginning to write OSs in Go.

There are moments when I think that wasn't it for Google backing behind 
it (and the large cult of Google world-wide) that language would never 
get any kind of traction.

[...]
>> Hmm. An OT question - how hard it is to convert some moderately sized
>> app to Grovvy from Java (just to see if it looses anything in terms of
>> performance, in static mode obviously)?
>
> No tools for this as yet, so down to manual transform. First step though
> is to run the Java through the Groovy compiler and see what happens.
> Once you have something compiling you refactor the code replacing Java
> verbosity with Groovy terseness until there is nothing left to refactor,
> you have a "pure Groovy" codebase.

Okay thanks for the data point as I think I've seen some claims that 
Java can be compiled as Groovy (almost) as is... Well, back to the old 
painful way.

-- 
Dmitry Olshansky
March 02, 2013
Re: The DUB package manager
On Saturday, February 16, 2013 18:10:21 Sönke Ludwig wrote:
> With the recent talk about Orbit, I thought it is time to also announce
> the package manager that we have been working out based on the simple
> VPM system that has always been in vibe.d. I don't really like stepping
> into competition with Jacob here (*), but the approach is different
> enough that I think it should be put on the table.

I justed messing around with dub on one of my projects, and at first glance, I 
like what I'm seeing. Hopefully, it'll be a good replacement for the ad-hoc 
build setups that I typically use. However, while the package format 
documentation seems to be fairly complete, the usage documentation is still 
sorely lacking:

http://registry.vibed.org/usage

As it stands, I don't even have a clue what the various directories that get 
generated are for, let alone something like how the docs target is supposed to 
work (I just get errors from it about one of the files it generates not being 
executable).

There should also probably clear examples of how to set up an application vs a 
library. It seems to want to set up an application by default, and I assume 
that you make it a library by mucking with dflags in the configuration file, but 
how that jives with having an executable with -unittest, I don't know.

And if dub is supposed to work with build scripts or other build tools as some 
of your posts here imply, then that definitely needs to be documented, because 
I don't see anything of the sort.

So, it looks like it has a good start, but without better instructions, it's 
going to be a bit hard to use it properly it seems.

- Jonathan M Davis
March 02, 2013
Re: The DUB package manager
Am 02.03.2013 09:19, schrieb Jonathan M Davis:
> On Saturday, February 16, 2013 18:10:21 Sönke Ludwig wrote:
>> With the recent talk about Orbit, I thought it is time to also announce
>> the package manager that we have been working out based on the simple
>> VPM system that has always been in vibe.d. I don't really like stepping
>> into competition with Jacob here (*), but the approach is different
>> enough that I think it should be put on the table.
> 
> I justed messing around with dub on one of my projects, and at first glance, I 
> like what I'm seeing. Hopefully, it'll be a good replacement for the ad-hoc 
> build setups that I typically use. However, while the package format 
> documentation seems to be fairly complete, the usage documentation is still 
> sorely lacking:
> 
> http://registry.vibed.org/usage

Agreed, there also needs to be a brief introduction how dub accomplishes
to usual tasks.

> 
> As it stands, I don't even have a clue what the various directories that get 
> generated are for, let alone something like how the docs target is supposed to 
> work (I just get errors from it about one of the files it generates not being 
> executable).

The "docs" target was just a quick draft added to have meaningful list
of standard built types and hasn't really been tested. I'll fix it right
away.

> 
> There should also probably clear examples of how to set up an application vs a 
> library. It seems to want to set up an application by default, and I assume 
> that you make it a library by mucking with dflags in the configuration file, but 
> how that jives with having an executable with -unittest, I don't know.

As it stands, there are just two modes of operation:

1. invoking dub on a project will build it as an application (any
"source/app.d" file is assumed to contain the main() function)
2. any dependent package is assumed to be a library and gets compiled in
without its "source/app.d" file.

This is currently tied to the simplified workflow that I use. Although I
find this to be a quite nice approach in general and it covers most uses
nicely, support to specify explicit library types will be added later.

> 
> And if dub is supposed to work with build scripts or other build tools as some 
> of your posts here imply, then that definitely needs to be documented, because 
> I don't see anything of the sort.

It's not yet implemented, although trivial.

> 
> So, it looks like it has a good start, but without better instructions, it's 
> going to be a bit hard to use it properly it seems.
> 

Right now everything has to be extended a bit to handle the different
use cases and project structures that came up until now in a comfortable
way. I hope this to settle down in one or two weeks and then I'll write
up a proper introduction on that page and make a quick announcement.
March 02, 2013
Re: The DUB package manager
On Saturday, March 02, 2013 15:07:33 Sönke Ludwig wrote:
> The "docs" target was just a quick draft added to have meaningful list
> of standard built types and hasn't really been tested. I'll fix it right
> away.

Ah. I thought that it was for generating the documentation with ddoc.

- Jonathan M Davis
13 14 15 16 17 18
Top | Discussion index | About this forum | D home