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.

2) D might be perceived as an alternative to Java or C# (I don't count C/C++).
But it is really the case? Java was born in 1995, today it's a very known
language. C# was born in 1999, today it's popularity is still rising. And D?
Mars was born in 1988, D in 1999. How many people have heard about D? In
comparison, say, to C#? How many apps and libraries are written in Java, in
C#, and in D?

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?

To be honest, I still think that C# has better future than D.

Why I ask all those questions, you may ask. Well - the truth is that:
1) I know Java.
2) I don't know C#.
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.
 
 2) D might be perceived as an alternative to Java or C# (I don't count C/C++).
 But it is really the case? Java was born in 1995, today it's a very known
 language. C# was born in 1999, today it's popularity is still rising. And D?
 Mars was born in 1988, D in 1999. How many people have heard about D? In
 comparison, say, to C#? How many apps and libraries are written in Java, in
 C#, and in D?
 
 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?
 
 To be honest, I still think that C# has better future than D.
 
 Why I ask all those questions, you may ask. Well - the truth is that:
 1) I know Java.
 2) I don't know C#.
 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 than C# because it supports more OSes than it. C# can't run on Win95 because managed apps only run on Win9x to Win Vista(and future win versions). Most of the implementations of C# do not comply to the standard and add stuff to it. Mono and VisualC# are the best but Mono don't do 2.0 and Visual C# adds to many extensions that make it impossible to compile it on mono at times. Visual C# 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. Only real reason to use C# is for Win Vista apps since native apps run in a very suspicious box. I love D for its simple syntax and support of everything C/C++ offered before I switched to C#. C# don't even barely have templates. I recomend D for all apps including GUIs even though I still basically use C# for that. I just 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ó:
 
 
 
 
 Only real reason to use C# is for Win Vista apps since native apps run 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. -- Carlos Santander Bernal
Jan 05 2007
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Carlos Santander wrote:
 Guest escribió:
 Only real reason to use C# is for Win Vista apps since native apps run 
 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ó:
 
 
 
 
 Only real reason to use C# is for Win Vista apps since native apps run 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. -- 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ó:
 Only real reason to use C# is for Win Vista apps since native apps run in a
 very suspicious box.

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ó:
 
 
 
 
 Only real reason to use C# is for Win Vista apps since native apps run 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. -- 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ó:
 Only real reason to use C# is for Win Vista apps since native apps run in a
 very suspicious box.

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
you target .NET, use C# (most popular) or Boo/Nemerle (best), don't
bother with VB.NET, J# and others.

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
 you target .NET, use C# (most popular) or Boo/Nemerle (best), don't
 bother with VB.NET, J# and others.
 
 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".
 2) D might be perceived as an alternative to Java or C# (I don't count C/C++).
 But it is really the case? Java was born in 1995, today it's a very known
 language. C# was born in 1999, today it's popularity is still rising. And D?
 Mars was born in 1988, D in 1999. How many people have heard about D? In
 comparison, say, to C#? How many apps and libraries are written in Java, in
 C#, and in D?
 

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.
 To be honest, I still think that C# has better future than D.
 

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.
 2) I don't know C#.
 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.
 2) D might be perceived as an alternative to Java or C# (I don't count 
 C/C++).
 But it is really the case? Java was born in 1995, today it's a very known
 language. C# was born in 1999, today it's popularity is still rising. 
 And D?
 Mars was born in 1988, D in 1999. How many people have heard about D? In
 comparison, say, to C#? How many apps and libraries are written in 
 Java, in
 C#, and in D?

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

Yeah, D is much better than Java (never really used C#, so can't compare). 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.
 2) I don't know C#.
 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.
 To be honest, I still think that C# has better future than D.

There is room for both. And D is more "up against" C++ than C# ? 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 .
 2) D might be perceived as an alternative to Java or C# (I don't count C/C++).
 But it is really the case? Java was born in 1995, today it's a very known
 language. C# was born in 1999, today it's popularity is still rising. And D?
 Mars was born in 1988, D in 1999. How many people have heard about D? In
 comparison, say, to C#? How many apps and libraries are written in Java, in
 C#, and in D?
 
 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?
 
 To be honest, I still think that C# has better future than D.
 
 Why I ask all those questions, you may ask. Well - the truth is that:
 1) I know Java.
 2) I don't know C#.
 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
 2) D might be perceived as an alternative to Java or C# (I don't count C/C++).
 But it is really the case? Java was born in 1995, today it's a very known
 language. C# was born in 1999, today it's popularity is still rising. And D?
 Mars was born in 1988, D in 1999. How many people have heard about D? In
 comparison, say, to C#? How many apps and libraries are written in Java, in
 C#, and in D?

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 and C# can do, picking the best features of each), but I think it would take about 10 to D to get really popular (as popular as C/C++, Java, C# 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?
 2) D might be perceived as an alternative to Java or C# (I don't count C/C++).

That's a flat no. D is competing with C/C++. Some of my fellow D enthusiasts find a way to use D where Java and C# rule but the reality is One Man Show has no chance against MS or Sun.
 But it is really the case? Java was born in 1995, today it's a very known
 language. C# was born in 1999, today it's popularity is still rising. And D?
 Mars was born in 1988, D in 1999. How many people have heard about D? In
 comparison, say, to C#? How many apps and libraries are written in Java, in
 C#, and in D?

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.
 2) I don't know C#.
 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?

 To be honest, I still think that C# has better future than D.

 Why I ask all those questions, you may ask. Well - the truth is that:
 1) I know Java.
 2) I don't know C#.
 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. The thing C# really has going for it is the .NET libraries. Likewise 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.
 The thing C# really has going for it is the .NET libraries. Likewise 
 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. The thing C# really has going for it is the .NET libraries. Likewise 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. The thing C# really has going for it is the .NET libraries. Likewise 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 for Java and C#, not just the libraries. Especially for C#, where the 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.
 2) D might be perceived as an alternative to Java or C# (I don't count C/C++).
 But it is really the case? Java was born in 1995, today it's a very known
 language. C# was born in 1999, today it's popularity is still rising. And D?
 Mars was born in 1988, D in 1999. How many people have heard about D? In
 comparison, say, to C#? How many apps and libraries are written in Java, in
 C#, and in D?

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?
 
 To be honest, I still think that C# has better future than D.

I think it depends on the target market. C# has a huge future in the Windows world for everyday applications, but Mono still isn't a fantastic solution for other OSes. Were I looking for true binary portability I'd choose Java, RAD development on Windows I'd choose C# or 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:
 
 2) D might be perceived as an alternative to Java or C# (I don't count C/C++).
 But it is really the case? Java was born in 1995, today it's a very known
 language. C# was born in 1999, today it's popularity is still rising. And D?
 Mars was born in 1988, D in 1999. How many people have heard about D? In
 comparison, say, to C#? How many apps and libraries are written in Java, in
 C#, and in D?

C# is ~7 years old and on, what V2.0? It was developed by a group of 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 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 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 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 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 next 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 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
prev sibling parent 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