www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D, Java? To D or not to D?

reply TPJ <tprimke interia.pl> writes:
I decided to start with a simple statement: with this post I don't intend to
start any flamewar. I'm definitely not a Java zealot, OS zealot, I'm not a
zealot at all. I'm just a programmer who seeks for future technologies today.
I'm doing it because I find investing in future technologies today very
profitable. Of course only in case of really good technologies...

I'm a freelancer programmer. I work under a GNU/Linux box and I'm interested
in development of portable desktop apps (*nices, Windows, MacOSX, perhaps
other OSes in the future) and games (the same OSes, plus mobile phones).

A few years ago I switched from C/C++ to Python. The reason was simple: I was
fed up with low-level development in C/C++, and I was impressed by high-level
development in Python. All I did in C/C++ could be done in Python with one
significant difference: code was written much, much faster.

Now, after several years of using Python, I decided to switch from Python to
Java. The reason is simple. Sometimes Python is too slow for my needs. Of
course, I can use C in those cases. But using C means using another language
and development becomes more complicated. In fact, I started to use Pyrex as
well... Three different tools, no documentation standard for all of them...
The hell.

Why Java? Because of many reasons:

a) Java programs are run by JVM. IMO it's a big advantage: the only thing I
have to do is to "compile" my app on my development box, and then I can ship
it without any changes for any OS with JVM.

b) I can write everything in Java. No need to use other languages and various
tools. It means easier development.

c) Static typing. No more dynamic typing hell known from Python. (Dynamic
typing is great in small scripts, but it becomes error-prone in more complex
projects. At least in my own case.)

d) Java programs run fast enough. Take a look at
http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=all
D got 67.6, and Java got 44.0. From MPOV this difference is not important. The
difference between Java (44.0) and Python (10.1) is much more significant.
67.6 / 44.0 = 1.54
44.0 / 10.1 = 4.36
67.6 / 10.1 = 6.69

e) Java is very popular. It makes Java programs easier to port. I intend to
write desktop apps for *nices, Windows and MacOSX systems, as well as some
games (2D only!!!) for those systems and mobile devices. In my opinion Java is
a good choice.

f) I don't care about memory. I can run Eclipse on my old Celeron 800 MHz +
256 MB RAM machine, and it just works.

g) There are great IDEs for Java. I use Eclipse, but NetBeans is also said to
be a good one.


And now I have found D. What can I say about it?

Disadvantages:

1) In order to run a program written in D I have to compile it on the target OS.


But it is really the case? Java was born in 1995, today it's a very known

Mars was born in 1988, D in 1999. How many people have heard about D? In



3) There is no D for mobile phones (AFAIK).

Advantages:

1) It's said to be faster than Java. But is it really an advantage? I find
Java fast enough for my needs, so why should I bother myself with D?

2) From FAQ: Since D can call C functions, any GUI library with a C interface
is accessible from D.
Does it mean that I can access *any* C library from D? If so, it a great
feature!


So I ask myself a question today: should I invest in learning D? Is it worth
my efforts?



Why I ask all those questions, you may ask. Well - the truth is that:
1) I know Java.

3) I don't know D.
4) I might be wrong.

Therefore I post this message here. I'd like to know what you (the people who
know D) say about it.
Jan 05 2007
next sibling parent reply Guest <Lester ewam-associates.com> writes:
TPJ Wrote:


 I decided to start with a simple statement: with this post I don't intend to
 start any flamewar. I'm definitely not a Java zealot, OS zealot, I'm not a
 zealot at all. I'm just a programmer who seeks for future technologies today.
 I'm doing it because I find investing in future technologies today very
 profitable. Of course only in case of really good technologies...
 
 I'm a freelancer programmer. I work under a GNU/Linux box and I'm interested
 in development of portable desktop apps (*nices, Windows, MacOSX, perhaps
 other OSes in the future) and games (the same OSes, plus mobile phones).
 
 A few years ago I switched from C/C++ to Python. The reason was simple: I was
 fed up with low-level development in C/C++, and I was impressed by high-level
 development in Python. All I did in C/C++ could be done in Python with one
 significant difference: code was written much, much faster.
 
 Now, after several years of using Python, I decided to switch from Python to
 Java. The reason is simple. Sometimes Python is too slow for my needs. Of
 course, I can use C in those cases. But using C means using another language
 and development becomes more complicated. In fact, I started to use Pyrex as
 well... Three different tools, no documentation standard for all of them...
 The hell.
 
 Why Java? Because of many reasons:
 
 a) Java programs are run by JVM. IMO it's a big advantage: the only thing I
 have to do is to "compile" my app on my development box, and then I can ship
 it without any changes for any OS with JVM.
 
 b) I can write everything in Java. No need to use other languages and various
 tools. It means easier development.
 
 c) Static typing. No more dynamic typing hell known from Python. (Dynamic
 typing is great in small scripts, but it becomes error-prone in more complex
 projects. At least in my own case.)
 
 d) Java programs run fast enough. Take a look at
 http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=all
 D got 67.6, and Java got 44.0. From MPOV this difference is not important. The
 difference between Java (44.0) and Python (10.1) is much more significant.
 67.6 / 44.0 = 1.54
 44.0 / 10.1 = 4.36
 67.6 / 10.1 = 6.69
 
 e) Java is very popular. It makes Java programs easier to port. I intend to
 write desktop apps for *nices, Windows and MacOSX systems, as well as some
 games (2D only!!!) for those systems and mobile devices. In my opinion Java is
 a good choice.
 
 f) I don't care about memory. I can run Eclipse on my old Celeron 800 MHz +
 256 MB RAM machine, and it just works.
 
 g) There are great IDEs for Java. I use Eclipse, but NetBeans is also said to
 be a good one.
 
 
 And now I have found D. What can I say about it?
 
 Disadvantages:
 
 1) In order to run a program written in D I have to compile it on the target
OS.
 

 But it is really the case? Java was born in 1995, today it's a very known

 Mars was born in 1988, D in 1999. How many people have heard about D? In


 
 3) There is no D for mobile phones (AFAIK).
 
 Advantages:
 
 1) It's said to be faster than Java. But is it really an advantage? I find
 Java fast enough for my needs, so why should I bother myself with D?
 
 2) From FAQ: Since D can call C functions, any GUI library with a C interface
 is accessible from D.
 Does it mean that I can access *any* C library from D? If so, it a great
feature!
 
 
 So I ask myself a question today: should I invest in learning D? Is it worth
 my efforts?
 

 
 Why I ask all those questions, you may ask. Well - the truth is that:
 1) I know Java.

 3) I don't know D.
 4) I might be wrong.
 
 Therefore I post this message here. I'd like to know what you (the people who
 know D) say about it.






I've heard D can run on Nokia phones.  I also believe D has a better future

managed apps only run on Win9x to Win Vista(and future win versions).  Most of



is the best as the .NET Platform with it is best supported and has 2.0 and 3.0
versions and is almost as fast as most C++ apps.  It was what I used before I
started using D.  Even now the only thing I love about it is the easiness of
writiing GUIs for windows.  I can hook it up to any DLL and it is still my main
GUI app system.  I have found alternatives and D and am Switching to them. 

very suspicious box.  

I love D for its simple syntax and support of everything C/C++ offered before I


haven't taken the time to learn any GUI package for D and the one I used to use
aint compatible with v1.0.

SO there u have it.  My thoughts on D exactly.  It's one of the best
programming languages invented
Jan 05 2007
parent reply Carlos Santander <csantander619 gmail.com> writes:
Guest escribió:

 
 
 
 

 very suspicious box.
 


Would you care to explain that, please? I haven't used Vista so I don't know 
what you're talking about.

-- 
Carlos Santander Bernal
Jan 05 2007
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Carlos Santander wrote:

 Guest escribió:


 in a
 very suspicious box.


 
 Would you care to explain that, please? I haven't used Vista so I don't 
 know what you're talking about.


If I remember correctly, .NET has a way of running native apps in a 
sandbox to apply its security features to the app.  During Microsoft's 
presentation, my first thought was "so this is how they plan to get MS 
Office running under .NET."  In theory it's kind of a neat idea, but the 
code security features are so badly designed that I don't expect them to 
be very popular.  The maintenance app in the control panel is ghastly, 
and in code I think it's actually possible to override code security if 
it's too much of an obstacle.  I can't remember the details of this last 
feature so I may be remembering it wrong, but at the time I was amazed 
that it was part of the design.


Sean
Jan 05 2007
parent Carlos Santander <csantander619 gmail.com> writes:
Sean Kelly escribió:

 
 If I remember correctly, .NET has a way of running native apps in a sandbox 
 to apply its security features to the app.  During Microsoft's presentation,
  my first thought was "so this is how they plan to get MS Office running
 under .NET."  In theory it's kind of a neat idea, but the code security
 features are so badly designed that I don't expect them to be very popular.
 The maintenance app in the control panel is ghastly, and in code I think it's
  actually possible to override code security if it's too much of an obstacle.
  I can't remember the details of this last feature so I may be remembering it
  wrong, but at the time I was amazed that it was part of the design.
 
 
 Sean



Guest escribió:

 
 I'm sorry for my long reply time.  I've read a couple of articles on running 
 native apps in Vista and they have all said that it will be ran in a box that
 supplies imense security features to protect the user.  It will abort the app
 as soon as it starts looking suspicious.  That's the box I'm talking about.
 So really you should use a .NET language on Vista because the .NET already
 has the security and won't be ran in a box.  I've also read the box will
 severely limit your programs access to resources (such as:
 files,hardware,etc.).
 
 I wish I wrote the url's down of those web pages so I could directly link 
 them to you and when I start reading up on vista again.  I will re reply with
  a list of url's you may visit.
 
 Guest
 


Two very similar answers with different points of view. Thanks guys!

-- 
Carlos Santander Bernal
Jan 05 2007
prev sibling next sibling parent reply Guest <Lester ewam-associates.com> writes:
Carlos Santander Wrote:


 Guest escribió:

 
 
 
 

 very suspicious box.
 


 
 Would you care to explain that, please? I haven't used Vista so I don't know 
 what you're talking about.
 
 -- 
 Carlos Santander Bernal


I'm sorry for my long reply time.  I've read a couple of articles on running
native apps in Vista and they have all said that it will be ran in a box that
supplies imense security features to protect the user.  It will abort the app
as soon as it starts looking suspicious.  That's the box I'm talking about.  So
really you should use a .NET language on Vista because the .NET already has the
security and won't be ran in a box.  I've also read the box will severely limit
your programs access to resources (such as: files,hardware,etc.).

I wish I wrote the url's down of those web pages so I could directly link them
to you and when I start reading up on vista again.  I will re reply with a list
of url's you may visit.

Guest
Jan 05 2007
parent reply Don Clugston <dac nospam.com.au> writes:
Guest wrote:

 Carlos Santander Wrote:
 

 Guest escribió:


 very suspicious box.


 Would you care to explain that, please? I haven't used Vista so I don't know 
 what you're talking about.

 -- 
 Carlos Santander Bernal


 
 I'm sorry for my long reply time.  I've read a couple of articles on running
native apps in Vista and they have all said that it will be ran in a box that
supplies imense security features to protect the user.  It will abort the app
as soon as it starts looking suspicious.  That's the box I'm talking about.  So
really you should use a .NET language on Vista because the .NET already has the
security and won't be ran in a box.  I've also read the box will severely limit
your programs access to resources (such as: files,hardware,etc.).


I find that a bit hard to believe. Consider what fraction of high-end 
PCs are used for games, which are almost exclusively native apps. 
Microsoft cannot afford to alienate that market.


 I wish I wrote the url's down of those web pages so I could directly link them
to you and when I start reading up on vista again.  I will re reply with a list
of url's you may visit.
 
 Guest
Jan 08 2007
parent =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Don Clugston wrote:

 Guest wrote:

 Carlos Santander Wrote:
 I'm sorry for my long reply time.  I've read a couple of articles on 
 running native apps in Vista and they have all said that it will be 
 ran in a box that supplies imense security features to protect the 
 user.  It will abort the app as soon as it starts looking suspicious.  
 That's the box I'm talking about.  So really you should use a .NET 
 language on Vista because the .NET already has the security and won't 
 be ran in a box.  I've also read the box will severely limit your 
 programs access to resources (such as: files,hardware,etc.).


 
 I find that a bit hard to believe. Consider what fraction of high-end 
 PCs are used for games, which are almost exclusively native apps. 
 Microsoft cannot afford to alienate that market.
 

 I wish I wrote the url's down of those web pages so I could directly 
 link them to you and when I start reading up on vista again.  I will 
 re reply with a list of url's you may visit.

 Guest




It is mostly true. Vista has a new "feature" called User Account 
Protection (UAP) that can be defined as a sandbox since it prevents an 
application from executing certain operations that are considered "for 
administrators only".

Current versions of most programs won't work (Even .NET ones) directly 
and have to be modified and programs that use system devices will be 
specially affected. (Most burning programs and anti-virus will need to 
be updated, for example).

The performance hit isn't as bad as one can imagine as most safeguards 
are placed at operations that already are relatively slow... like disk 
access, changing video modes, opening ports, etc...

A famous WTF related with UAP is that Visual Studio 6 will run perfectly 
while Visual Studio 2002, 2003 and 2005 will present "some problems":

http://msdn2.microsoft.com/en-us/vstudio/aa964140.aspx

Still from the new Vista "features" the one I worry about it's the DRM 
integration for HD content because it will hurt us even if we only use 
Linux or MacOSX. For more information read:

http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt
Jan 12 2007
prev sibling parent reply Guest <Lester ewam-associates.com> writes:
Carlos Santander Wrote:


 Guest escribió:

 
 
 
 

 very suspicious box.
 


 
 Would you care to explain that, please? I haven't used Vista so I don't know 
 what you're talking about.
 
 -- 
 Carlos Santander Bernal


Oh yeah. I forgot to tell you I don't have a Vista myself and would try to
switch to linux before buying the junk.
Jan 05 2007
parent Carlos Santander <csantander619 gmail.com> writes:
Guest escribió:

 Carlos Santander Wrote:
 

 Guest escribió:


 very suspicious box.


 Would you care to explain that, please? I haven't used Vista so I don't know 
 what you're talking about.

 -- 
 Carlos Santander Bernal


 
 Oh yeah. I forgot to tell you I don't have a Vista myself and would try to
switch to linux before buying the junk.


LOL!
I'm just happy to have Mac and Linux.

-- 
Carlos Santander Bernal
Jan 05 2007
prev sibling next sibling parent reply Boris Kolar <boris.kolar globera.com> writes:
My advice: use the best or the most popular language for the platform.
Don't bother with "slightly better but less popular" category. So, if



If you target JVM, use Java (also take a look at Scala - I don't like
it too much because it seems more complex than necessary).

If you must have fast startup times, or must integrate with OS API, use
C++ (most popular) or D (best). Maybe Eiffel is also worth considering.
D is not (yet) very good for real-time programming (see all garbage
collection, deterministic finalization threads for reasons), but Walter
will likely fix that soon.

I personally use D for OS-integrated projects and Java for all others.
If Boo for JVM (or native) existed, I would definitely use Boo (I'm almost
tempted to write JVM port of Boo myself).
Jan 05 2007
next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Boris Kolar wrote:

 My advice: use the best or the most popular language for the platform.
 Don't bother with "slightly better but less popular" category. So, if


 
 If you target JVM, use Java (also take a look at Scala - I don't like
 it too much because it seems more complex than necessary).
 
 If you must have fast startup times, or must integrate with OS API, use
 C++ (most popular) or D (best). Maybe Eiffel is also worth considering.
 D is not (yet) very good for real-time programming (see all garbage
 collection, deterministic finalization threads for reasons), but Walter
 will likely fix that soon.
 
 I personally use D for OS-integrated projects and Java for all others.
 If Boo for JVM (or native) existed, I would definitely use Boo (I'm almost
 tempted to write JVM port of Boo myself).


Good break down. From the OP's requirements, I dont see what would be 
enticing about D. Perhaps the clean, natural C-style syntax? Maybe the 
lack of bloat? How about the contract programming support?

Admittedly, the feature list is not _that_ impressive, the runtime 
implementation mediocre, libraries not generally very mature, but the 
people who use it do because it just feels *right*. The whole is 
logical, cohesive, clean. And not radically different, or horribly 
obtuse. Maybe even everything that C++ could have and should have been.

If that paragraph didn't make you go, "hmmm!" then maybe D doesn't have 
anything to offer you. It compiles natively, yes, but that isn't a win 
for you. Most everything else (tools, libraries) you can get better in 
Java if you dont mind the VM, and syntax bloat.

That said, things are just getting interesting around here in the 
library/toolset area. ;-)
Jan 05 2007
prev sibling parent reply janderson <askme me.com> writes:
Boris Kolar wrote:

 If you must have fast startup times, or must integrate with OS API, use
 C++ (most popular) or D (best). Maybe Eiffel is also worth considering.
 D is not (yet) very good for real-time programming (see all garbage
 collection, deterministic finalization threads for reasons), but Walter
 will likely fix that soon.


I disagree here, even in C++ allocation during the real-time part is 
best avoided.  In the past, my programs would assert if anyone tried to 
allocated during the real-time part.  D runs real-time just fine if you 
follow that simple rule.

-K
Jan 05 2007
parent "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
janderson schrieb:

 Boris Kolar wrote:

 If you must have fast startup times, or must integrate with OS API, use
 C++ (most popular) or D (best). Maybe Eiffel is also worth considering.
 D is not (yet) very good for real-time programming (see all garbage
 collection, deterministic finalization threads for reasons), but Walter
 will likely fix that soon.


 
 I disagree here, even in C++ allocation during the real-time part is
 best avoided.  In the past, my programs would assert if anyone tried to
 allocated during the real-time part.  D runs real-time just fine if you
 follow that simple rule.
 
 -K


I also do realtime programming in D. I use the "Realtime Application
Interface (RTAI)" for Linux.
Jan 05 2007
prev sibling next sibling parent reply Alexander Panek <a.panek brainsware.org> writes:
TPJ wrote:

 I decided to start with a simple statement: with this post I don't intend to
 start any flamewar. I'm definitely not a Java zealot, OS zealot, I'm not a
 zealot at all. I'm just a programmer who seeks for future technologies today.
 I'm doing it because I find investing in future technologies today very
 profitable. Of course only in case of really good technologies...
 


Always a good approach. :)


 I'm a freelancer programmer. I work under a GNU/Linux box and I'm interested
 in development of portable desktop apps (*nices, Windows, MacOSX, perhaps
 other OSes in the future) and games (the same OSes, plus mobile phones).
 


Seems like you'll like GDC, then..


 A few years ago I switched from C/C++ to Python. The reason was simple: I was
 fed up with low-level development in C/C++, and I was impressed by high-level
 development in Python. All I did in C/C++ could be done in Python with one
 significant difference: code was written much, much faster.
 
 Now, after several years of using Python, I decided to switch from Python to
 Java. The reason is simple. Sometimes Python is too slow for my needs. Of
 course, I can use C in those cases. But using C means using another language
 and development becomes more complicated. In fact, I started to use Pyrex as
 well... Three different tools, no documentation standard for all of them...
 The hell.
 
 Why Java? Because of many reasons:
 
 a) Java programs are run by JVM. IMO it's a big advantage: the only thing I
 have to do is to "compile" my app on my development box, and then I can ship
 it without any changes for any OS with JVM.
 
 b) I can write everything in Java. No need to use other languages and various
 tools. It means easier development.
 
 c) Static typing. No more dynamic typing hell known from Python. (Dynamic
 typing is great in small scripts, but it becomes error-prone in more complex
 projects. At least in my own case.)
 
 d) Java programs run fast enough. Take a look at
 http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=all
 D got 67.6, and Java got 44.0. From MPOV this difference is not important. The
 difference between Java (44.0) and Python (10.1) is much more significant.
 67.6 / 44.0 = 1.54
 44.0 / 10.1 = 4.36
 67.6 / 10.1 = 6.69
 
 e) Java is very popular. It makes Java programs easier to port. I intend to
 write desktop apps for *nices, Windows and MacOSX systems, as well as some
 games (2D only!!!) for those systems and mobile devices. In my opinion Java is
 a good choice.
 
 f) I don't care about memory. I can run Eclipse on my old Celeron 800 MHz +
 256 MB RAM machine, and it just works.
 
 g) There are great IDEs for Java. I use Eclipse, but NetBeans is also said to
 be a good one.
 
 
 And now I have found D. What can I say about it?
 
 Disadvantages:
 
 1) In order to run a program written in D I have to compile it on the target
OS.
 


Gregor Richards has found a way to compile D code to JVM compatible 
programs, that can be run in a JVM. So, if this is taken a bit further, 
maybe we can even say "D runs in a VM, too, if you want".



 But it is really the case? Java was born in 1995, today it's a very known

 Mars was born in 1988, D in 1999. How many people have heard about D? In


 


You can't compare Sun & Microsoft to a one man show (AFAIK) like 
Digitalmars. Those are other dimensions of marketing and promotion, really.


 3) There is no D for mobile phones (AFAIK).
 


There's a guy that tries to get D working on a Nokia 770, I hope he got 
it working. Apart from that, as D can theoretically be run in a JVM, .. 
you know the rest.


 Advantages:
 
 1) It's said to be faster than Java. But is it really an advantage? I find
 Java fast enough for my needs, so why should I bother myself with D?
 


I don't know how the speed advantage over Java is, but there's 
definitely more room for optimization than with Java. I can't answer you 
the question why you should bother yourself with D. That's your 
decision, after all. ;)


 2) From FAQ: Since D can call C functions, any GUI library with a C interface
 is accessible from D.
 Does it mean that I can access *any* C library from D? If so, it a great
feature!
 


Yes, any C library. Apart from that, there's a tool to bind C++ 
libraries, too. (BCDgen on dsource)


 
 So I ask myself a question today: should I invest in learning D? Is it worth
 my efforts?
 


Definitely.



 


That may be, but that doesn't mean D isn't worth working with - actually 
it's the other way round.


 Why I ask all those questions, you may ask. Well - the truth is that:
 1) I know Java.

 3) I don't know D.
 4) I might be wrong.
 
 Therefore I post this message here. I'd like to know what you (the people who
 know D) say about it.


Very honest and nice post, still. :)

Hope that helps, best regards,
Alex
Jan 05 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Alexander Panek wrote:

 TPJ wrote:

 And now I have found D. What can I say about it?

 Disadvantages:

 1) In order to run a program written in D I have to compile it on the 
 target OS.


 
 Gregor Richards has found a way to compile D code to JVM compatible 
 programs, that can be run in a JVM. So, if this is taken a bit further, 
 maybe we can even say "D runs in a VM, too, if you want".


 From what I remember it'll run but it won't be pretty...
IIRC he used GDC to compile to MIPS and then translated that to 
bytecode, using a huge array to simulate raw memory...
But yeah, if you _need_ it to run on a JVM, this may be an option.
I'm pretty sure he didn't get access to Java classes that way though.



 C/C++).
 But it is really the case? Java was born in 1995, today it's a very known

 And D?
 Mars was born in 1988, D in 1999. How many people have heard about D? In

 Java, in



 
 You can't compare Sun & Microsoft to a one man show (AFAIK) like 
 Digitalmars. Those are other dimensions of marketing and promotion, really.



But Java and .NET definitely have a bigger PR department, so it's not 
surprising they get all the press.


 3) There is no D for mobile phones (AFAIK).


 
 There's a guy that tries to get D working on a Nokia 770, I hope he got 
 it working. Apart from that, as D can theoretically be run in a JVM, .. 
 you know the rest.


He got it working:
Photo: http://www.flickr.com/photos/michaeldominic/329290303/
Coverage:
http://dblog.aldacron.net/2006/12/22/d-gets-nokiafied/
http://pvanhoof.be/blog/index.php/2006/12/22/d-on-the-nokia-770


 Advantages:

 1) It's said to be faster than Java. But is it really an advantage? I 
 find
 Java fast enough for my needs, so why should I bother myself with D?


 
 I don't know how the speed advantage over Java is, but there's 
 definitely more room for optimization than with Java. I can't answer you 
 the question why you should bother yourself with D. That's your 
 decision, after all. ;)


FWIW: 
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=dlang&lang2=java


 2) From FAQ: Since D can call C functions, any GUI library with a C 
 interface
 is accessible from D.
 Does it mean that I can access *any* C library from D? If so, it a 
 great feature!


 
 Yes, any C library. Apart from that, there's a tool to bind C++ 
 libraries, too. (BCDgen on dsource)


You need to convert C headers to D import modules to use them though.
It shouldn't be too hard unless too much preprocessor tricks are used, 
but it might be a bit of work for large files.
IIRC there's a tool that at least provides you with a starting point for 
that, not sure how far along it is these days.


 Why I ask all those questions, you may ask. Well - the truth is that:
 1) I know Java.

 3) I don't know D.
 4) I might be wrong.

 Therefore I post this message here. I'd like to know what you (the 
 people who
 know D) say about it.




I definitely prefer D over Java, but I've never written a program that 
needed to run on multiple operating systems and architectures.
You'll also have to use GDC to compile on anything but x86 Linux & 
windows, and I don't have much experience with it. Haven't heard much 
complaints about it though, and the Mac people definitely seem to like 
it :).
Theoretically it should eventually be portable to all architectures GCC 
supports, but IIRC it still needs some work in that department.
Jan 05 2007
parent Georg Wrede <georg nospam.org> writes:
Frits van Bommel wrote:

 Alexander Panek wrote:

 TPJ wrote:





 2) From FAQ: Since D can call C functions, any GUI library with a
 C interface is accessible from D. Does it mean that I can access
 *any* C library from D? If so, it a great feature!


 
 Yes, any C library. 


 
 You need to convert C headers to D import modules to use them though.
 It shouldn't be too hard unless too much preprocessor tricks are
 used, but it might be a bit of work for large files.


It's actually a lot easier than it sounds. :-)

And, there's no use converting everything, just convert the things in a 
C header that your program _actually_ uses! (Most people feel an 
inexplicable urge to convert the whole header file "just in case", or 
"later I'm going to need it anyway". Don't.)

Also, if the header file looks like "an exuberant show-off of 
preprocessor wizardry", then you might want to run it thorugh the 
preprocessor, and compare it with the original.
Jan 05 2007
prev sibling next sibling parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
TPJ wrote:


 1) It's said to be faster than Java. But is it really an advantage? I find
 Java fast enough for my needs, so why should I bother myself with D?


Yes, it's an advantage (speed and memory). No, you might not need it.


 2) From FAQ: Since D can call C functions, any GUI library with a C interface
 is accessible from D.
 Does it mean that I can access *any* C library from D? If so, it a great
feature!


Yes, D can call all C libraries that it has an "import module" for.
Generating these is somewhat tedious, but it can be mostly automated.

Unfortunately, most libraries for GUI development are either written
in C++ or use unavailable system libraries which makes using them hard.


 So I ask myself a question today: should I invest in learning D? Is it worth
 my efforts?


Why not ? If you already have a C/C++ and Python background, it
shouldn't be long before you decide whether you like it or not.






Having the GDC->JVM compiler (like Managed C++) would be nice...

--anders
Jan 05 2007
prev sibling next sibling parent Dave <Dave_member pathlink.com> writes:
TPJ wrote:

 I decided to start with a simple statement: with this post I don't intend to
 start any flamewar. I'm definitely not a Java zealot, OS zealot, I'm not a
 zealot at all. I'm just a programmer who seeks for future technologies today.
 I'm doing it because I find investing in future technologies today very
 profitable. Of course only in case of really good technologies...
 
 I'm a freelancer programmer. I work under a GNU/Linux box and I'm interested
 in development of portable desktop apps (*nices, Windows, MacOSX, perhaps
 other OSes in the future) and games (the same OSes, plus mobile phones).
 
 A few years ago I switched from C/C++ to Python. The reason was simple: I was
 fed up with low-level development in C/C++, and I was impressed by high-level
 development in Python. All I did in C/C++ could be done in Python with one
 significant difference: code was written much, much faster.
 
 Now, after several years of using Python, I decided to switch from Python to
 Java. The reason is simple. Sometimes Python is too slow for my needs. Of
 course, I can use C in those cases. But using C means using another language
 and development becomes more complicated. In fact, I started to use Pyrex as
 well... Three different tools, no documentation standard for all of them...
 The hell.
 
 Why Java? Because of many reasons:
 
 a) Java programs are run by JVM. IMO it's a big advantage: the only thing I
 have to do is to "compile" my app on my development box, and then I can ship
 it without any changes for any OS with JVM.
 
 b) I can write everything in Java. No need to use other languages and various
 tools. It means easier development.
 
 c) Static typing. No more dynamic typing hell known from Python. (Dynamic
 typing is great in small scripts, but it becomes error-prone in more complex
 projects. At least in my own case.)
 
 d) Java programs run fast enough. Take a look at
 http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=all
 D got 67.6, and Java got 44.0. From MPOV this difference is not important. The
 difference between Java (44.0) and Python (10.1) is much more significant.
 67.6 / 44.0 = 1.54
 44.0 / 10.1 = 4.36
 67.6 / 10.1 = 6.69
 
 e) Java is very popular. It makes Java programs easier to port. I intend to
 write desktop apps for *nices, Windows and MacOSX systems, as well as some
 games (2D only!!!) for those systems and mobile devices. In my opinion Java is
 a good choice.
 
 f) I don't care about memory. I can run Eclipse on my old Celeron 800 MHz +
 256 MB RAM machine, and it just works.
 
 g) There are great IDEs for Java. I use Eclipse, but NetBeans is also said to
 be a good one.
 
 
 And now I have found D. What can I say about it?
 
 Disadvantages:
 
 1) In order to run a program written in D I have to compile it on the target
OS.
 


You can execute D source-code from the command-line. See the -run switch and
(for more capability 
and executable caching), see http://www.digitalmars.com/d/rdmd.html .



 But it is really the case? Java was born in 1995, today it's a very known

 Mars was born in 1988, D in 1999. How many people have heard about D? In


 
 3) There is no D for mobile phones (AFAIK).
 
 Advantages:
 
 1) It's said to be faster than Java. But is it really an advantage? I find
 Java fast enough for my needs, so why should I bother myself with D?
 
 2) From FAQ: Since D can call C functions, any GUI library with a C interface
 is accessible from D.
 Does it mean that I can access *any* C library from D? If so, it a great
feature!
 
 
 So I ask myself a question today: should I invest in learning D? Is it worth
 my efforts?
 

 
 Why I ask all those questions, you may ask. Well - the truth is that:
 1) I know Java.

 3) I don't know D.
 4) I might be wrong.
 
 Therefore I post this message here. I'd like to know what you (the people who
 know D) say about it.
Jan 05 2007
prev sibling next sibling parent bobef <valid email.com> writes:
Once Tiport (or some other similar project) is done D will have all the
libraries in the world (C,C++ and Java), some of them even even written in D,
not just bindings, and Java is out of the game ;)
Jan 05 2007
prev sibling next sibling parent Leandro Lucarella <llucarella integratech.com.ar> writes:
TPJ escribió:

 d) Java programs run fast enough. Take a look at
 http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=all
 D got 67.6, and Java got 44.0. From MPOV this difference is not important. The
 difference between Java (44.0) and Python (10.1) is much more significant.
 67.6 / 44.0 = 1.54
 44.0 / 10.1 = 4.36
 67.6 / 10.1 = 6.69


Have you tried psyco (a kid of JIT for Python)?


 Disadvantages:
 
 1) In order to run a program written in D I have to compile it on the target
OS.


Gregor Richards managed to get Java Bytecode out of a D source[1] =)
So, that could change in the future if you prefer portability over speed.

[1] 
http://www.digitalmars.com/d/archives/digitalmars/D/announce/From_the_Department_of_Insane_Ideas_D_on_the_JVM_6264.html



 But it is really the case? Java was born in 1995, today it's a very known

 Mars was born in 1988, D in 1999. How many people have heard about D? In




Since I doesn't have Sun or Microsoft on his back, it probably will take 
MUCH longer for D to popularize (like Python or Ruby, did, they both are 
from early '90 and got popular about 10 years later, even so, it happend 
almost the same to C++, which didn't had a real bit enterprise either).


 3) There is no D for mobile phones (AFAIK).


Nokia 770 is not a mobile phone but is close enough (I think). As 
somebody says, Michael Dominic K.[2] apparently got D working on that 
internet tablet[3].

[2] http://www.mdk.org.pl/
[3] http://www.flickr.com/photo_zoom.gne?id=329290303&size=l

So, as you can see, or at least as I can see, D has a very prominent 
future (it's technically possible to make D do everything C/C++, Java 


or Python). Maybe a little less, because back when Python or C++ was 
created there were no so much fuzz about programming languages as there 
is now (I think), so the terrain is much more fertile for people to try 
new languages now.


 Advantages:
 
 1) It's said to be faster than Java. But is it really an advantage? I find
 Java fast enough for my needs, so why should I bother myself with D?


Less memory consumption, faster load times, and I think more 
responsiveness. When you use C/C++/D programs (native code programs) 
they fill lighter (at least I find them lighter).


 2) From FAQ: Since D can call C functions, any GUI library with a C interface
 is accessible from D.
 Does it mean that I can access *any* C library from D? If so, it a great
feature!


Yes. But wrappers can make your live much easier.


 So I ask myself a question today: should I invest in learning D? Is it worth
 my efforts?


I think yes. D has everything to success, it just need time. What I 
found really great of the is how well both worlds (native compiled and 
higher level with-killer-runtime) are mixed. You have the best of the 2 
worlds.

-- 
Leandro Lucarella
Integratech S.A.
4571-5252
Jan 05 2007
prev sibling next sibling parent Waldemar <waldemar wa-ba.com> writes:
== Quote from TPJ (tprimke interia.pl)'s article

 a) Java programs are run by JVM. IMO it's a big advantage: the only thing I
 have to do is to "compile" my app on my development box, and then I can ship
 it without any changes for any OS with JVM.


Sometimes VM is a no no, then you look for D.  Otherwise you don't.


 b) I can write everything in Java. No need to use other languages and various
 tools. It means easier development.


Does the "everything" include systems, communications, graphics, etc?  Of course
not.  Indeed, there is no point looking outside Java as long as you're in the
Java
land.  In other words, D is not competing with Java.  But it is targeted at Java
developers who look for another language to augment their projects.


 e) Java is very popular. It makes Java programs easier to port. I intend to
 write desktop apps for *nices, Windows and MacOSX systems, as well as some
 games (2D only!!!) for those systems and mobile devices. In my opinion Java is
 a good choice.


Yes.  If you can, that is.  But what if you can't?





That's a flat no.  D is competing with C/C++.  Some of my fellow D enthusiasts

no
chance against MS or Sun.


 But it is really the case? Java was born in 1995, today it's a very known

 Mars was born in 1988, D in 1999. How many people have heard about D? In




Both are corporate pushes with established base and $BB of investements.  That's
why D is not competing with them.  But One Man Shows can be viable, too.  C++ is
one example, Python is another, etc.  Of course, it takes a lot longer that way,
approximately 10 years for each.


 1) I know Java.

 3) I don't know D.
 4) I might be wrong.


Do you know C/C++?


 Therefore I post this message here. I'd like to know what you (the people who
 know D) say about it.
Jan 05 2007
prev sibling next sibling parent mike <vertex gmx.at> writes:
Am 05.01.2007, 11:22 Uhr, schrieb TPJ <tprimke interia.pl>:


 So I ask myself a question today: should I invest in learning D? Is it=


  =


 worth
 my efforts?



 Why I ask all those questions, you may ask. Well - the truth is that:
 1) I know Java.

 3) I don't know D.
 4) I might be wrong.

 Therefore I post this message here. I'd like to know what you (the  =



 people who
 know D) say about it.


It's a question of what you need to do. I'm working on an audio sequence=
r.  =

So performance is essential. Therefore I can't use Java. But if Java wor=
ks  =

for you, then use Java.

-mike

-- =

Erstellt mit Operas revolution=E4rem E-Mail-Modul: http://www.opera.com/=
mail/
Jan 05 2007
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
TPJ wrote:

 I decided to start with a simple statement: with this post I don't intend to
 start any flamewar. I'm definitely not a Java zealot, OS zealot, I'm not a
 zealot at all. I'm just a programmer who seeks for future technologies today.
 I'm doing it because I find investing in future technologies today very
 profitable. Of course only in case of really good technologies...
 
 I'm a freelancer programmer. I work under a GNU/Linux box and I'm interested
 in development of portable desktop apps (*nices, Windows, MacOSX, perhaps
 other OSes in the future) and games (the same OSes, plus mobile phones).
 
 A few years ago I switched from C/C++ to Python. The reason was simple: I was
 fed up with low-level development in C/C++, and I was impressed by high-level
 development in Python. All I did in C/C++ could be done in Python with one
 significant difference: code was written much, much faster.
 
 Now, after several years of using Python, I decided to switch from Python to
 Java. The reason is simple. Sometimes Python is too slow for my needs. Of
 course, I can use C in those cases. But using C means using another language
 and development becomes more complicated. In fact, I started to use Pyrex as
 well... Three different tools, no documentation standard for all of them...
 The hell.


[snip]

 So I ask myself a question today: should I invest in learning D? Is it worth
 my efforts?


It's the libraries.

Java. Their libraries are extensive, and were developed with massive 
budgets.
Right now, D cannot compete with those libraries. We got nothin'.

BUT...

D is a language that seems to be made for writing libraries. It is 
exceptionally easy to write rock-solid code in D. The powerful template 
system, coupled with language features such as lazy evaluation, inner 
functions, etc make it possible to create extremely appealing syntax for 
library users. I believe it is possible to create nicer libraries in D 
than in any of those other languages you've mentioned.

As a library developer, I reckon I'm about ten times productive in D as 
in C++. I predict we'll see a rapid expansion in D library development 
post-1.0.

The bottom line:
Don't use D right now unless you're prepared to do a lot of library 
development. But expect the situation to change rapidly.
Jan 05 2007
next sibling parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Don Clugston wrote:


 It's the libraries.

 Java. Their libraries are extensive, and were developed with massive 
 budgets.
 Right now, D cannot compete with those libraries. We got nothin'.


You got the C libraries (once wrapped) ? That's at least sumthin'.

And the native D libraries are starting to look rather good too...

--anders
Jan 05 2007
prev sibling next sibling parent "Paulo Herrera" <pauloh81 yahoo.ca> writes:
Hi,
I agree about D being an excellent language to write libraries.

The last two days I've been writing a multidimensional array class (yes,  
another one!!!).
I also wrote a similar library in C++. I am surprised of how much work I  
saved in D, and how useful
are things like static if, static assert, etc.

So, I agree with Don good libraries in D should start appearing in short  
time.

Paulo

On Fri, 05 Jan 2007 17:03:22 +0100, Don Clugston <dac nospam.com.au> wrote:


 TPJ wrote:

 I decided to start with a simple statement: with this post I don't  
 intend to
 start any flamewar. I'm definitely not a Java zealot, OS zealot, I'm  
 not a
 zealot at all. I'm just a programmer who seeks for future technologies  
 today.
 I'm doing it because I find investing in future technologies today very
 profitable. Of course only in case of really good technologies...
  I'm a freelancer programmer. I work under a GNU/Linux box and I'm  
 interested
 in development of portable desktop apps (*nices, Windows, MacOSX,  
 perhaps
 other OSes in the future) and games (the same OSes, plus mobile phones).
  A few years ago I switched from C/C++ to Python. The reason was  
 simple: I was
 fed up with low-level development in C/C++, and I was impressed by  
 high-level
 development in Python. All I did in C/C++ could be done in Python with  
 one
 significant difference: code was written much, much faster.
  Now, after several years of using Python, I decided to switch from  
 Python to
 Java. The reason is simple. Sometimes Python is too slow for my needs.  
 Of
 course, I can use C in those cases. But using C means using another  
 language
 and development becomes more complicated. In fact, I started to use  
 Pyrex as
 well... Three different tools, no documentation standard for all of  
 them...
 The hell.


 [snip]

 So I ask myself a question today: should I invest in learning D? Is it  
 worth
 my efforts?


 It's the libraries.

 Java. Their libraries are extensive, and were developed with massive  
 budgets.
 Right now, D cannot compete with those libraries. We got nothin'.

 BUT...

 D is a language that seems to be made for writing libraries. It is  
 exceptionally easy to write rock-solid code in D. The powerful template  
 system, coupled with language features such as lazy evaluation, inner  
 functions, etc make it possible to create extremely appealing syntax for  
 library users. I believe it is possible to create nicer libraries in D  
 than in any of those other languages you've mentioned.

 As a library developer, I reckon I'm about ten times productive in D as  
 in C++. I predict we'll see a rapid expansion in D library development  
 post-1.0.

 The bottom line:
 Don't use D right now unless you're prepared to do a lot of library  
 development. But expect the situation to change rapidly.




-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Jan 05 2007
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Don Clugston wrote:

 TPJ wrote:

 I decided to start with a simple statement: with this post I don't 
 intend to
 start any flamewar. I'm definitely not a Java zealot, OS zealot, I'm 
 not a
 zealot at all. I'm just a programmer who seeks for future technologies 
 today.
 I'm doing it because I find investing in future technologies today very
 profitable. Of course only in case of really good technologies...

 I'm a freelancer programmer. I work under a GNU/Linux box and I'm 
 interested
 in development of portable desktop apps (*nices, Windows, MacOSX, perhaps
 other OSes in the future) and games (the same OSes, plus mobile phones).

 A few years ago I switched from C/C++ to Python. The reason was 
 simple: I was
 fed up with low-level development in C/C++, and I was impressed by 
 high-level
 development in Python. All I did in C/C++ could be done in Python with 
 one
 significant difference: code was written much, much faster.

 Now, after several years of using Python, I decided to switch from 
 Python to
 Java. The reason is simple. Sometimes Python is too slow for my needs. Of
 course, I can use C in those cases. But using C means using another 
 language
 and development becomes more complicated. In fact, I started to use 
 Pyrex as
 well... Three different tools, no documentation standard for all of 
 them...
 The hell.


 
 [snip]

 So I ask myself a question today: should I invest in learning D? Is it 
 worth
 my efforts?


 
 It's the libraries.

 Java. Their libraries are extensive, and were developed with massive 
 budgets.
 Right now, D cannot compete with those libraries. We got nothin'.
 


I would say that the toolchain (like the IDEs) also plays a big factor 

Visual Studio GUI designer has allways been a great boon for .NET 
languages.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jan 07 2007
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
TPJ wrote:

 
 And now I have found D. What can I say about it?
 
 Disadvantages:
 
 1) In order to run a program written in D I have to compile it on the target
OS.


Yup.  Though there was one project in the past to compile D to CLI and 
have it run on .NET.  Things were pretty far along when the author's 
hard drive crashed and the data was lost.  So in terms of VM 
portability, this is possible if someone is willing to put in the time.



 But it is really the case? Java was born in 1995, today it's a very known

 Mars was born in 1988, D in 1999. How many people have heard about D? In




D was developed by one man, not a huge team.  And I think the real 
comparison for D should be to C/C++, which you discount.  What D really 
has going for it is that it's a systems programming language with a lot 
of the features of a high-level language (garbage collection, decent 
RTTI, etc).  This combination, along with its elegant design, is what 
makes it an appealing language to me personally.


 3) There is no D for mobile phones (AFAIK).


Only for the moment.  I know of someone who is in the process of making 
GDC work for ARM.


 Advantages:
 
 1) It's said to be faster than Java. But is it really an advantage? I find
 Java fast enough for my needs, so why should I bother myself with D?


Speed simply isn't a selling point for Java programmers, for the reasons 
you state.


 2) From FAQ: Since D can call C functions, any GUI library with a C interface
 is accessible from D.
 Does it mean that I can access *any* C library from D? If so, it a great
feature!


Yes.  C interoperability was a major design goal of D.


 So I ask myself a question today: should I invest in learning D? Is it worth
 my efforts?
 




Windows world for everyday applications, but Mono still isn't a 
fantastic solution for other OSes.  Were I looking for true binary 

C++/CLI, systems programming anywhere I'd choose D if possible, but 
realistically I'd probably still use C++ at least professionally.  I 
think D is a wonderful language, but it will take a while for it to gain 
traction in the commercial sector.


Sean
Jan 05 2007
prev sibling next sibling parent reply BCS <nothing pathlink.com> writes:
TPJ wrote:

 And now I have found D. What can I say about it?
 
 Disadvantages:
 

 But it is really the case? Java was born in 1995, today it's a very known

 Mars was born in 1988, D in 1999. How many people have heard about D? In





people with gobs of funding and AFAIN not a lot of user input. I have 
known it to be described as a shell around the .Net framework.

D is alos ~7 years old, is at V1.00 and is being develuped by one man 
with gobs of user input and AFAIN not a lot of funding. It is useful for 
practically anything.


 
 So I ask myself a question today: should I invest in learning D? Is it worth
 my efforts?


Yes, even if you don't start developing for-profit apps in it. It is 
also a good language to build personal toolkit apps in.


 
 Therefore I post this message here. I'd like to know what you (the people who
 know D) say about it.


The language CORE is great!! DMD is good and getting better. The 
tool-chain, libs and documentation suck. But that will change (I expect).

I wouldn't build a big for-profit project on D, not quite yet. But it's 
getting there.
Jan 05 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
BCS wrote:

 D is alos ~7 years old, is at V1.00 and is being develuped by one man 
 with gobs of user input and AFAIN not a lot of funding. It is useful for 
 practically anything.


D's funding: $0
D's paid staff: 0
D's marketing budget: $0

<g>
Jan 05 2007
parent reply Waldemar <waldemar wa-ba.com> writes:
== Quote from Walter Bright (newshound digitalmars.com)'s article

 BCS wrote:

 D is alos ~7 years old, is at V1.00 and is being develuped by one man
 with gobs of user input and AFAIN not a lot of funding. It is useful for
 practically anything.


 D's funding: $0
 D's paid staff: 0
 D's marketing budget: $0
 <g>


How did Guido do it?
Jan 05 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
Waldemar wrote:

 == Quote from Walter Bright (newshound digitalmars.com)'s article

 BCS wrote:

 D is alos ~7 years old, is at V1.00 and is being develuped by one man
 with gobs of user input and AFAIN not a lot of funding. It is useful for
 practically anything.


 D's funding: $0
 D's paid staff: 0
 D's marketing budget: $0
 <g>


 
 How did Guido do it?


I don't know (I don't know anything about the history of Python).
Jan 05 2007
parent reply Leandro Lucarella <llucarella integratech.com.ar> writes:
Walter Bright escribió:

 Waldemar wrote:

 == Quote from Walter Bright (newshound digitalmars.com)'s article

 BCS wrote:

 D is alos ~7 years old, is at V1.00 and is being develuped by one man
 with gobs of user input and AFAIN not a lot of funding. It is useful 
 for
 practically anything.


 D's funding: $0
 D's paid staff: 0
 D's marketing budget: $0
 <g>


 How did Guido do it?


 
 I don't know (I don't know anything about the history of Python).


Python was a good language, I took more than 10 years (or more) to 
spread out because of the lack of marketing (and the lack of internet 
popularity, not so many people had an internet connection back then). 
Same for Ruby (it's from 1995 but I'm sure you hear about it a couple of 
years ago because of RoR). It only took time, I guess.

The key is the language to be good (and I think D is), then, sooner or 
later, people will notice and start using it. As much as the people know 
it start to spread the word, the sooner this will happen.

Another way to help D to become popular is to write good opensource 
libraries and applications, specially libraries, almost all popular 
languages have a good base of libraries (and the most popular ones have 
good and large *standard* libraries. Of course D counts with all the C 
libraries (which is *a lot* and a great base), but you can't tell people 
to use raw C libraries because they are ugly to use and you lost a lot 
of D power, so I think wrappers (to make them feel comfortable and D'ish 
to work with) will be essential. Or, since D is a system programming 
languages, porting them could be an option too, but this libraries 
probably wont be as popular as C ones until D compilers are available on 
every platform like C compilers are now (and I really don't think this 
will happen in less than 20 years, if it ever happens at all).

Anyway, I think that, with 1.0 out there, there's time to work on useful 
library base and to spread the word so D community grow fast (which is 
essential to success on the first point :).

-- 
Leandro Lucarella
Integratech S.A.
4571-5252
Jan 05 2007
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Leandro Lucarella wrote:

 Walter Bright escribió:

 Waldemar wrote:

 == Quote from Walter Bright (newshound digitalmars.com)'s article

 BCS wrote:

 D is alos ~7 years old, is at V1.00 and is being develuped by one man
 with gobs of user input and AFAIN not a lot of funding. It is 
 useful for
 practically anything.


 D's funding: $0
 D's paid staff: 0
 D's marketing budget: $0
 <g>


 How did Guido do it?


 I don't know (I don't know anything about the history of Python).


 
 Python was a good language, I took more than 10 years (or more) to 
 spread out because of the lack of marketing (and the lack of internet 
 popularity, not so many people had an internet connection back then). 
 Same for Ruby (it's from 1995 but I'm sure you hear about it a couple of 
 years ago because of RoR). It only took time, I guess.
 


Hum, interesting, I didn't know those languages (Ruby and Python) had 
that age, they were older than I thought. If we extrapolate that 10 
years maturing time to D, then D will hit mainstream in about 3 years. I 
would say its a sound prediction to make,  let's see how it turns out.


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jan 07 2007
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
TPJ wrote:

 1) In order to run a program written in D I have to compile it on the target
OS.


I haven't talked about this much, but it is technically feasible to 
create a D runtime that enables "compile once, run everywhere". It is 
not necessary to have a VM to do it.
Jan 05 2007
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 TPJ wrote:

 1) In order to run a program written in D I have to compile it on the 
 target OS.


 
 I haven't talked about this much, but it is technically feasible to 
 create a D runtime that enables "compile once, run everywhere". It is 
 not necessary to have a VM to do it.


This would still be limited to a specific architecture, wouldn't it? 
ie. "This app runs on x86, regardless of OS."  Given that there are 
really very few architectures in the marketplace though, this is still a 
killer feature.


Sean
Jan 05 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
Sean Kelly wrote:

 Walter Bright wrote:

 TPJ wrote:

 1) In order to run a program written in D I have to compile it on the 
 target OS.


 I haven't talked about this much, but it is technically feasible to 
 create a D runtime that enables "compile once, run everywhere". It is 
 not necessary to have a VM to do it.


 
 This would still be limited to a specific architecture, wouldn't it?


Nope. But it would require one to code in a portable subset of D.


 ie. 
 "This app runs on x86, regardless of OS."  Given that there are really 
 very few architectures in the marketplace though, this is still a killer 
 feature.
 
 
 Sean
Jan 05 2007
parent Kyle Furlong <kylefurlong gmail.com> writes:
Walter Bright wrote:

 Sean Kelly wrote:

 Walter Bright wrote:

 TPJ wrote:

 1) In order to run a program written in D I have to compile it on 
 the target OS.


 I haven't talked about this much, but it is technically feasible to 
 create a D runtime that enables "compile once, run everywhere". It is 
 not necessary to have a VM to do it.


 This would still be limited to a specific architecture, wouldn't it?


 
 Nope. But it would require one to code in a portable subset of D.
 

 ie. "This app runs on x86, regardless of OS."  Given that there are 
 really very few architectures in the marketplace though, this is still 
 a killer feature.


 Sean




Are these trade secrets or can you elaborate?
Jan 06 2007
prev sibling next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Walter Bright wrote:

 TPJ wrote:

 1) In order to run a program written in D I have to compile it on the 
 target OS.


 
 I haven't talked about this much, but it is technically feasible to 
 create a D runtime that enables "compile once, run everywhere". It is 
 not necessary to have a VM to do it.


And why haven't you?  ;)  I'd just about guarantee some people would have a use
for this. 
  (Client software that needs to be distributed throughout a multi-platform
corporation 
environment, for example.  Would speed development, testing, and deployment
time all at once.)

So, when you say "technically feasible" should I assume that implies "but an
awful lot of 
work?"  Or just "but I haven't thought much on how to do it?"

-- Chris Nicholson-Sauls
Jan 05 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
Chris Nicholson-Sauls wrote:

 Walter Bright wrote:

 TPJ wrote:

 1) In order to run a program written in D I have to compile it on the 
 target OS.


 I haven't talked about this much, but it is technically feasible to 
 create a D runtime that enables "compile once, run everywhere". It is 
 not necessary to have a VM to do it.


 
 And why haven't you?  ;)  I'd just about guarantee some people would 
 have a use for this.  (Client software that needs to be distributed 
 throughout a multi-platform corporation environment, for example.  Would 
 speed development, testing, and deployment time all at once.)
 
 So, when you say "technically feasible" should I assume that implies 
 "but an awful lot of work?"  Or just "but I haven't thought much on how 
 to do it?"


It's just a fair project to get it to work. I don't see any technical 
obstacles, just resources. I worked out all the details about 5 years 
ago <g>.
Jan 05 2007
parent reply Jeff Nowakowski <jeff dilacero.org> writes:
Walter Bright wrote:

 It's just a fair project to get it to work. I don't see any technical 
 obstacles, just resources. I worked out all the details about 5 years 
 ago <g>.


Is that like "I have a truly marvelous proof of this proposition which 
this margin is too narrow to contain."?

This is meant in good humor, but seriously, why not put all your 
thoughts on the web somewhere?  It seems D could go much further via 
collaboration than one man doing all the work.  I was impressed by the 
benefits of open design while reading about lazy evaluation:

http://www.digitalmars.com/d/lazy-evaluation.html

-Jeff
Jan 05 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
Jeff Nowakowski wrote:

 Walter Bright wrote:

 It's just a fair project to get it to work. I don't see any technical 
 obstacles, just resources. I worked out all the details about 5 years 
 ago <g>.


 
 Is that like "I have a truly marvelous proof of this proposition which 
 this margin is too narrow to contain."?


I haven't written about it because part of the idea is another fellow's, 
and he wanted to keep it under wraps.
Jan 06 2007
parent Pragma <ericanderton yahoo.removeme.com> writes:
Walter Bright wrote:

 Jeff Nowakowski wrote:

 Walter Bright wrote:

 It's just a fair project to get it to work. I don't see any technical 
 obstacles, just resources. I worked out all the details about 5 years 
 ago <g>.


 Is that like "I have a truly marvelous proof of this proposition which 
 this margin is too narrow to contain."?


 
 I haven't written about it because part of the idea is another fellow's, 
 and he wanted to keep it under wraps.


/me head explodes

-- 
- EricAnderton at yahoo
Jan 09 2007
prev sibling next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Walter Bright wrote:

 TPJ wrote:

 1) In order to run a program written in D I have to compile it on the 
 target OS.


 
 I haven't talked about this much, but it is technically feasible to 
 create a D runtime that enables "compile once, run everywhere". It is 
 not necessary to have a VM to do it.


How would you implement a garbage collector in an 
architecture-independent way?

Or are you talking about using version(arch_1) to version(arch_N)? [1]
Because I'm pretty sure the garbage collector has to know some 
architecture-specific things. Start of stack, direction of stack, 
location of static data, threading API (if any), that sort of thing.
So you'd need to perform at least _some_ porting to get it to run on a 
new architecture, if only to tell the GC what its properties are.

Though I guess stack direction could be experimentally determined at 
runtime/install time, as could endianness... Threading API is going to 
be hard to determine in that way, I'd think.


[1] or "version(StackGrowsUp), version(BigEndian), version(HasFeatureX), 
version(HasFeatureY), ..." or something like that.
Jan 05 2007
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Frits van Bommel wrote:

 Walter Bright wrote:

 TPJ wrote:

 1) In order to run a program written in D I have to compile it on the 
 target OS.


 I haven't talked about this much, but it is technically feasible to 
 create a D runtime that enables "compile once, run everywhere". It is 
 not necessary to have a VM to do it.


 
 How would you implement a garbage collector in an 
 architecture-independent way?


I don't think you would.  Rather, I think you'd have a separate runtime 
library for each platform that handled all the necessary back-end tasks, 
but which then called through to the same user-level D program.  This 
would allow you to deal with platform-specific startup requirements, 
memory allocation scheme, executable file layout, etc.  So long as the 
ABI or whatever were sufficiently strict regarding how exception 
handling occurs and a few other details, I think the compiled user code 
would be portable across OSes.  But I'm not sure how this would interact 
with things like calling C libraries built by other compilers.  For 
example, DMD/Linux appears to pad doubles differently than DMD/Win32, so 
how would the D user code know what to do re: pushing the values onto 
the stack?


Sean
Jan 05 2007
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Sean Kelly wrote:

 Frits van Bommel wrote:

 Walter Bright wrote:

 TPJ wrote:

 1) In order to run a program written in D I have to compile it on 
 the target OS.


 I haven't talked about this much, but it is technically feasible to 
 create a D runtime that enables "compile once, run everywhere". It is 
 not necessary to have a VM to do it.


 How would you implement a garbage collector in an 
 architecture-independent way?


 
 I don't think you would.  Rather, I think you'd have a separate runtime 
 library for each platform that handled all the necessary back-end tasks, 
 but which then called through to the same user-level D program.  This 
 would allow you to deal with platform-specific startup requirements, 
 memory allocation scheme, executable file layout, etc.  So long as the 
 ABI or whatever were sufficiently strict regarding how exception 
 handling occurs and a few other details, I think the compiled user code 
 would be portable across OSes.  But I'm not sure how this would interact 
 with things like calling C libraries built by other compilers.  For 
 example, DMD/Linux appears to pad doubles differently than DMD/Win32, so 
 how would the D user code know what to do re: pushing the values onto 
 the stack?


Oh, I must've read it wrong. I thought this was about a runtime that 
would automagically compile on any platform... <blush>

That's different from "independent of OS" though, which seems to be what 
you're thinking of. ("run everywhere" does not equal "run on any x86". 
Not yet anyway ;) )

So this is about a single compiled form that'll work on any supported 
platform. Well, then it comes down to your definition of VM and 'compiled'.
You'd need some representation of the program that's independent of the 
platform. There are two basic forms of this: some form of bytecode or 
source code.
Since it's "compile once", I find it reasonable to assume there should 
be some compiling involved ;). That would indicate byte code. Unless you 
would care to argue that Winzip is a compiler? :P

So then you have several choices:
- Interpret the bytecode. This is basically the simplest VM possible. 
(Is this what Python does? At the very least, I'm pretty sure it used to 
do this)
- Perform another compilation at runtime: bytecode to machine code. This 
would basically be a JIT-compiling VM.
- Perform above compilation[1] at install time. This is the only option 
I see that doesn't require a VM... (For Java, this is possible through 
the Java bytecode frontend for GCC IIRC)
- {{ Did I miss anything? }}
- Some mixture of the above (such as: interpret uncommon parts, 
runtime-compile the most-ran code)

All options but the first require that the user environment has some 
form of compiler though, which might not be optimal either.


[1]: For this purpose, unpacking the source and performing a normal 
compilation would also work. It might take longer though.
Jan 05 2007
parent reply Sean Kelly <sean f4.ca> writes:
Frits van Bommel wrote:

 Sean Kelly wrote:

 Frits van Bommel wrote:

 Walter Bright wrote:

 TPJ wrote:

 1) In order to run a program written in D I have to compile it on 
 the target OS.


 I haven't talked about this much, but it is technically feasible to 
 create a D runtime that enables "compile once, run everywhere". It 
 is not necessary to have a VM to do it.


 How would you implement a garbage collector in an 
 architecture-independent way?


 I don't think you would.  Rather, I think you'd have a separate 
 runtime library for each platform that handled all the necessary 
 back-end tasks, but which then called through to the same user-level D 
 program.  This would allow you to deal with platform-specific startup 
 requirements, memory allocation scheme, executable file layout, etc.  
 So long as the ABI or whatever were sufficiently strict regarding how 
 exception handling occurs and a few other details, I think the 
 compiled user code would be portable across OSes.  But I'm not sure 
 how this would interact with things like calling C libraries built by 
 other compilers.  For example, DMD/Linux appears to pad doubles 
 differently than DMD/Win32, so how would the D user code know what to 
 do re: pushing the values onto the stack?


 
 Oh, I must've read it wrong. I thought this was about a runtime that 
 would automagically compile on any platform... <blush>
 
 That's different from "independent of OS" though, which seems to be what 
 you're thinking of. ("run everywhere" does not equal "run on any x86". 
 Not yet anyway ;) )


True :)  But it still means quite a bit of portability.  And I could 
have misunderstood as well.  I simply couldn't imagine a binary app 
compiled for, say, x86 (one instruction set, big-endian) actually 
working on PPC (another instruction set, little-endian) without some 
sort of JIT compile step.


 So this is about a single compiled form that'll work on any supported 
 platform. Well, then it comes down to your definition of VM and 'compiled'.
 You'd need some representation of the program that's independent of the 
 platform. There are two basic forms of this: some form of bytecode or 
 source code.


I'm far from an expert here, but I think the bulk of the actual binary 
program is probably consistent across OSes for the same architecture. 
The differences are probably in the executable startup code, the thread 
code, memory allocation, some portions of garbage collection, etc, all 
of which could theoretically be abstracted to a runtime library (in a 
sense, they already are: Phobos).  The issue would be figuring out how 
to go from the command prompt to running the proper version of 
everything.  Would a link step be required first?  Would the runtime 
library actually contain multiple versions of the code for different 
OSes and call the appropriate one dynamically?  Or perhaps the runtime 
could be in a dynamic lib that's loaded by some startup code linked into 
the app?  Note that none of these are Virtual Machine situations because 
the code is running natively in all cases.


Sean
Jan 05 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Sean Kelly wrote:

 Frits van Bommel wrote:

 Oh, I must've read it wrong. I thought this was about a runtime that 
 would automagically compile on any platform... <blush>

 That's different from "independent of OS" though, which seems to be 
 what you're thinking of. ("run everywhere" does not equal "run on any 
 x86". Not yet anyway ;) )


 
 True :)  But it still means quite a bit of portability.  And I could 
 have misunderstood as well.  I simply couldn't imagine a binary app 
 compiled for, say, x86 (one instruction set, big-endian) actually 
 working on PPC (another instruction set, little-endian) without some 
 sort of JIT compile step.


x86 is little-endian, PPC can IIRC be set to either, but is typically 
(i.e. on PPC Macs) set to big-endian.


 So this is about a single compiled form that'll work on any supported 
 platform. Well, then it comes down to your definition of VM and 
 'compiled'.
 You'd need some representation of the program that's independent of 
 the platform. There are two basic forms of this: some form of bytecode 
 or source code.


 
 I'm far from an expert here, but I think the bulk of the actual binary 
 program is probably consistent across OSes for the same architecture. 


I was talking about multiple architectures here. Sorry if that wasn't 
clear enough.


 The differences are probably in the executable startup code, the thread 
 code, memory allocation, some portions of garbage collection, etc, all 
 of which could theoretically be abstracted to a runtime library (in a 
 sense, they already are: Phobos).  The issue would be figuring out how 
 to go from the command prompt to running the proper version of 
 everything.  Would a link step be required first?  Would the runtime 
 library actually contain multiple versions of the code for different 
 OSes and call the appropriate one dynamically?  Or perhaps the runtime 
 could be in a dynamic lib that's loaded by some startup code linked into 
 the app?  Note that none of these are Virtual Machine situations because 
 the code is running natively in all cases.


Before you consider how the runtime is linked to the app, first consider 
how the app starts in the first place. Let's say the bare minimum is x86 
Linux and Windows compatibility.

I don't think there's currently any way to have it run directly on 
Windows and Linux simply because there's AFAIK no executable format 
that's supported by both OSs (ELF is supported on multiple OSs, but 
Windows doesn't support it). Furthermore, all executable formats I know 
of (except for plain binary, which AFAIK Linux doesn't support[1]) have 
some (unique) signature in the first few bytes, so a file can't be 
multiple of these formats at the same time.

So you'd need to either using some sort of custom loader binary for each 
OS or modify OSs to support a common binary format (i.e. a custom 
loader, but integrated into the OS).


[1]: Windows "supports" these for programs that fit in 64k: .com files 
are plain binaries. They're not really useful for anything but backwards 
compatibility though.
Jan 05 2007
next sibling parent Sean Kelly <sean f4.ca> writes:
Frits van Bommel wrote:

 Sean Kelly wrote:

 Frits van Bommel wrote:

 Oh, I must've read it wrong. I thought this was about a runtime that 
 would automagically compile on any platform... <blush>

 That's different from "independent of OS" though, which seems to be 
 what you're thinking of. ("run everywhere" does not equal "run on any 
 x86". Not yet anyway ;) )


 True :)  But it still means quite a bit of portability.  And I could 
 have misunderstood as well.  I simply couldn't imagine a binary app 
 compiled for, say, x86 (one instruction set, big-endian) actually 
 working on PPC (another instruction set, little-endian) without some 
 sort of JIT compile step.


 
 x86 is little-endian, PPC can IIRC be set to either, but is typically 
 (i.e. on PPC Macs) set to big-endian.


Oops, I had it backwards, you're right.  A bigger issue is 64 vs. 32-bit 
code.  At some point, the architectural differences are simply too great 
for binary portability of even user code.


 The differences are probably in the executable startup code, the 
 thread code, memory allocation, some portions of garbage collection, 
 etc, all of which could theoretically be abstracted to a runtime 
 library (in a sense, they already are: Phobos).  The issue would be 
 figuring out how to go from the command prompt to running the proper 
 version of everything.  Would a link step be required first?  Would 
 the runtime library actually contain multiple versions of the code for 
 different OSes and call the appropriate one dynamically?  Or perhaps 
 the runtime could be in a dynamic lib that's loaded by some startup 
 code linked into the app?  Note that none of these are Virtual Machine 
 situations because the code is running natively in all cases.


 
 Before you consider how the runtime is linked to the app, first consider 
 how the app starts in the first place. Let's say the bare minimum is x86 
 Linux and Windows compatibility.
 
 I don't think there's currently any way to have it run directly on 
 Windows and Linux simply because there's AFAIK no executable format 
 that's supported by both OSs (ELF is supported on multiple OSs, but 
 Windows doesn't support it). Furthermore, all executable formats I know 
 of (except for plain binary, which AFAIK Linux doesn't support[1]) have 
 some (unique) signature in the first few bytes, so a file can't be 
 multiple of these formats at the same time.


Hrm, right.  So there would probably have to be either a configuration 
step before the initial run or some sort of translation or linking that 
took place.  I'll be curious to see what comes of this.  If Walter can 
sort it out in a nice clean manner, it would be a killer feature.


Sean
Jan 05 2007
prev sibling parent reply Daniel Keep <daniel.keep+lists gmail.com> writes:
Frits van Bommel wrote:

 I don't think there's currently any way to have it run directly on 
 Windows and Linux simply because there's AFAIK no executable format 
 that's supported by both OSs (ELF is supported on multiple OSs, but 
 Windows doesn't support it). Furthermore, all executable formats I know 
 of (except for plain binary, which AFAIK Linux doesn't support[1]) have 
 some (unique) signature in the first few bytes, so a file can't be 
 multiple of these formats at the same time.
 
 So you'd need to either using some sort of custom loader binary for each 
 OS or modify OSs to support a common binary format (i.e. a custom 
 loader, but integrated into the OS).
 
 
 [1]: Windows "supports" these for programs that fit in 64k: .com files 
 are plain binaries. They're not really useful for anything but backwards 
 compatibility though.


Linux can support PEs (ie: .exe files); that's what Wine is for.

Aside: AFAIK, Mono (open source .NET implementation) is a bit more 
tricksy: its' compilers generate PEs using a Windows stub, but when you 
go to run said programs, it ignores the stub (it just looks for which 
.NET class to fire off and goes from there).

If Windows won't support it, you have to change everything else :3

	-- Daniel
Jan 05 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Daniel Keep wrote:

 Frits van Bommel wrote:

 I don't think there's currently any way to have it run directly on 
 Windows and Linux simply because there's AFAIK no executable format 
 that's supported by both OSs (ELF is supported on multiple OSs, but 
 Windows doesn't support it). Furthermore, all executable formats I 
 know of (except for plain binary, which AFAIK Linux doesn't 
 support[1]) have some (unique) signature in the first few bytes, so a 
 file can't be multiple of these formats at the same time.

 So you'd need to either using some sort of custom loader binary for 
 each OS or modify OSs to support a common binary format (i.e. a custom 
 loader, but integrated into the OS).


 [1]: Windows "supports" these for programs that fit in 64k: .com files 
 are plain binaries. They're not really useful for anything but 
 backwards compatibility though.


 
 Linux can support PEs (ie: .exe files); that's what Wine is for.


Read the first sentence that you quoted again. run _directly_. As in: 
you can type the name of the app at the prompt and it runs (without a 
batch file, script or loader application in between) as long as it's in 
the PATH variable.


 If Windows won't support it, you have to change everything else :3


Yeah, that's technically an option. But I don't think asking people to 
upgrade their kernel to run my apps is a very nice thing to do, unless 
absolutely necessary (i.e. "it actually uses a new syscall in the 
kernel" or "kernels before x.y.z have a bug that breaks this app", not 
"I used this cool new executable format").
Not to mention the difficulty you'd have in getting the Linux, BSD and 
Mac kernel hackers to ship all ship a patch to be able to load a Windows 
executable format...
Jan 06 2007
next sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Frits van Bommel wrote:

 to ship all ship a patch


Hmmm... Would that be an edit-o?
(Obviously, ignore the first 'ship')
Jan 06 2007
prev sibling parent reply Daniel Keep <daniel.keep+lists gmail.com> writes:
Frits van Bommel wrote:

 Daniel Keep wrote:

 Linux can support PEs (ie: .exe files); that's what Wine is for.


 
 Read the first sentence that you quoted again. run _directly_. As in: 
 you can type the name of the app at the prompt and it runs (without a 
 batch file, script or loader application in between) as long as it's in 
 the PATH variable.


I thought you *could* do that.  I remember reading an article somewhere 
on how the list of executable formats in Linux was open-ended, and you 
could add new stuff to it.

Maybe I'm just getting senile really, really early...

Ah, here's something: http://www.linux.it/~rubini/docs/binfmt/binfmt.html

I must have assumed that Wine added this functionality for Windows 
executables.  Silly me.

	-- Daniel
Jan 07 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Daniel Keep wrote:

 Frits van Bommel wrote:

 Daniel Keep wrote:

 Linux can support PEs (ie: .exe files); that's what Wine is for.


 Read the first sentence that you quoted again. run _directly_. As in: 
 you can type the name of the app at the prompt and it runs (without a 
 batch file, script or loader application in between) as long as it's 
 in the PATH variable.


 
 I thought you *could* do that.  I remember reading an article somewhere 
 on how the list of executable formats in Linux was open-ended, and you 
 could add new stuff to it.
 
 Maybe I'm just getting senile really, really early...
 
 Ah, here's something: http://www.linux.it/~rubini/docs/binfmt/binfmt.html
 
 I must have assumed that Wine added this functionality for Windows 
 executables.  Silly me.


Well, I'm not that sure either, since it's been a while since I used 
Wine. But when I last used it, you had to run something like "wine 
program.exe" IIRC...
Jan 07 2007
parent Johan Granberg <lijat.meREM OVE.gmail.com> writes:
Frits van Bommel wrote:


 Daniel Keep wrote:

 Frits van Bommel wrote:

 Daniel Keep wrote:

 Linux can support PEs (ie: .exe files); that's what Wine is for.


 Read the first sentence that you quoted again. run _directly_. As in:
 you can type the name of the app at the prompt and it runs (without a
 batch file, script or loader application in between) as long as it's
 in the PATH variable.


 
 I thought you *could* do that.  I remember reading an article somewhere
 on how the list of executable formats in Linux was open-ended, and you
 could add new stuff to it.
 
 Maybe I'm just getting senile really, really early...
 
 Ah, here's something: http://www.linux.it/~rubini/docs/binfmt/binfmt.html
 
 I must have assumed that Wine added this functionality for Windows
 executables.  Silly me.


 
 Well, I'm not that sure either, since it's been a while since I used
 Wine. But when I last used it, you had to run something like "wine
 program.exe" IIRC...


If i remember correctly both works but sometimes wine foo.exe is needed
because the program has the wrong permissions. (was sometime since I last
used wine so I might be mistaken)
Jan 07 2007
prev sibling next sibling parent Walter Bright <newshound digitalmars.com> writes:
Sean Kelly wrote:

 For 
 example, DMD/Linux appears to pad doubles differently than DMD/Win32,


It pads them to 12 on Linux (to match gcc on Linux).


 so 
 how would the D user code know what to do re: pushing the values onto 
 the stack?


It doesn't need to know.
Jan 05 2007
prev sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Sean Kelly wrote:

 Frits van Bommel wrote:

 Walter Bright wrote:

 TPJ wrote:

 1) In order to run a program written in D I have to compile it on 
 the target OS.


 I haven't talked about this much, but it is technically feasible to 
 create a D runtime that enables "compile once, run everywhere". It is 
 not necessary to have a VM to do it.


 How would you implement a garbage collector in an 
 architecture-independent way?


 
 I don't think you would.  Rather, I think you'd have a separate runtime 
 library for each platform that handled all the necessary back-end tasks, 
 but which then called through to the same user-level D program.  This 
 would allow you to deal with platform-specific startup requirements, 
 memory allocation scheme, executable file layout, etc.  So long as the 
 ABI or whatever were sufficiently strict regarding how exception 
 handling occurs and a few other details, I think the compiled user code 
 would be portable across OSes.  But I'm not sure how this would interact 
 with things like calling C libraries built by other compilers.  For 
 example, DMD/Linux appears to pad doubles differently than DMD/Win32, so 
 how would the D user code know what to do re: pushing the values onto 
 the stack?
 
 
 Sean


Or in other words, a D-"unique" stub exe format, and a dynamicly linked runtime
library... 
  probably ran via a loader program.  Huh, its a bit like a JVM.  ;)  Although
so long as 
it targeted a particular cpu (x86, PPC, blah) it wouldn't be using bytecodes.

-- Chris Nicholson-Sauls
Jan 05 2007
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Frits van Bommel wrote:

 How would you implement a garbage collector in an 
 architecture-independent way?
 
 Or are you talking about using version(arch_1) to version(arch_N)? [1]
 Because I'm pretty sure the garbage collector has to know some 
 architecture-specific things. Start of stack, direction of stack, 
 location of static data, threading API (if any), that sort of thing.
 So you'd need to perform at least _some_ porting to get it to run on a 
 new architecture, if only to tell the GC what its properties are.


The runtime system would have to be ported, just like the Java VM has to 
be ported, before the code will run. The GC is part of the runtime system.
Jan 05 2007
prev sibling next sibling parent reply Georg Wrede <georg nospam.org> writes:
Walter Bright wrote:

 TPJ wrote:
 

 1) In order to run a program written in D I have to compile it on the 
 target OS.


 
 I haven't talked about this much, but it is technically feasible to 
 create a D runtime that enables "compile once, run everywhere". It is 
 not necessary to have a VM to do it.


1. To run on any OS on one specific processor, either those OSes have to 
have different entry points to the "exe", or there has to be a way of 
probing the OS within "common" code, the result of which would cause a 
jump to an OS specific routine.

2. To run on different processor architectures, (most probably with some 
of the same OSes), the worst case scenario would be that the same OS 
with the same jump target gets invocated on a different processor. This 
would mean that one (er, Walter) would have to invent a series of binary 
instructions that would not cause an (unwanted) exception on any of the 
processors, would not have any harmful side effects, and would 
eventually result in a jump to some processor specific version of the code.

Both of these seem like formidable tasks. OTOH, there's nothing that 
directly says they'd be theoretically impossible. So, in practice, the 
fewer processors we want to support, the less likely this is to be 
impossible. But, the more processors, specifically: for each additional 
processor (of a different architecture philosophy) we want to support, 
the harder it gets. And IMHO exponentially. (In English: pretty hard, 
and it gets _vastly_ harder for each single new processor!)

----

Not right now having the additional patience to think this entirely 
through, I got to thinking about the following:

At first sight ("hearing" ?), it sounds too good to be true. Then one 
starts to suspect that either Walter has figured out a runtime gimmick 
that does it (thus rendering this (btw, patentable idea) independent of 
D), or it is some kind of result of the specific way D and its source 
code (more to the point, syntax domain) relate to the semantics of the 
source code, taken as a whole.

----

If there's any remotest chance that this may be patentable, I DEFINITELY 
don't want to hear a word about it for the next 18 months!

If not, I'd kill to hear more! :-)
Jan 05 2007
parent Don Clugston <dac nospam.com.au> writes:
Georg Wrede wrote:

 Walter Bright wrote:

 TPJ wrote:


 1) In order to run a program written in D I have to compile it on the 
 target OS.


 I haven't talked about this much, but it is technically feasible to 
 create a D runtime that enables "compile once, run everywhere". It is 
 not necessary to have a VM to do it.


 
 1. To run on any OS on one specific processor, either those OSes have to 
 have different entry points to the "exe", or there has to be a way of 
 probing the OS within "common" code, the result of which would cause a 
 jump to an OS specific routine.
 
 2. To run on different processor architectures, (most probably with some 
 of the same OSes), the worst case scenario would be that the same OS 
 with the same jump target gets invocated on a different processor. This 
 would mean that one (er, Walter) would have to invent a series of binary 
 instructions that would not cause an (unwanted) exception on any of the 
 processors, would not have any harmful side effects, and would 
 eventually result in a jump to some processor specific version of the code.



 At first sight ("hearing" ?), it sounds too good to be true. Then one 
 starts to suspect that either Walter has figured out a runtime gimmick 
 that does it (thus rendering this (btw, patentable idea) independent of 
 D), or it is some kind of result of the specific way D and its source 
 code (more to the point, syntax domain) relate to the semantics of the 
 source code, taken as a whole.


I've come up with one vague idea about how this could be done (which 
doesn't involve either 1 or 2), though it would involve an obscene hack, 
telling some serious lies to the OS. I can't think of a way it could be 
done for OSes with radically different file formats, though.
Jan 10 2007
prev sibling parent reply John Reimer <terminal.node gmail.com> writes:
On Fri, 05 Jan 2007 11:54:09 -0800, Walter Bright wrote:


 TPJ wrote:

 1) In order to run a program written in D I have to compile it on the target
OS.


 
 I haven't talked about this much, but it is technically feasible to 
 create a D runtime that enables "compile once, run everywhere". It is 
 not necessary to have a VM to do it.



Isn't this something that LLVM can be used for?

http://llvm.org/

-JJR
Jan 05 2007
parent Daniel Keep <daniel.keep+lists gmail.com> writes:
John Reimer wrote:

 On Fri, 05 Jan 2007 11:54:09 -0800, Walter Bright wrote:
 
 

TPJ wrote:


1) In order to run a program written in D I have to compile it on the target OS.


I haven't talked about this much, but it is technically feasible to 
create a D runtime that enables "compile once, run everywhere". It is 
not necessary to have a VM to do it.


 
 
 
 Isn't this something that LLVM can be used for?
 
 http://llvm.org/
 
 -JJR


I once thought about grabbing LLVM and poking around, but the 
requirements just to compile the damn thing scared me off.  I've had so 
much pain from GCC (and the entire GNU toolchain) on Windows, I just 
can't be arsed anymore.

It's somewhat unfair that the OS I got stuck with is the only non-NIXish 
OS left. :P

	-- Daniel
Jan 05 2007