www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D vs Java

reply "Walter Bright" <newshound digitalmars.com> writes:
I'm no expert on Java programming, but I get this question a lot: "What 
compelling reason does D have that would entice a Java programmer to switch 
to D?"

I know several of you have come to D from Java, and are expert Java 
programmers, so you folks' reasons would be very valuable. 
Mar 18 2006
next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Walter Bright wrote:
 I'm no expert on Java programming, but I get this question a lot: "What 
 compelling reason does D have that would entice a Java programmer to switch 
 to D?"
 
 I know several of you have come to D from Java, and are expert Java 
 programmers, so you folks' reasons would be very valuable. 
 
 

no VM!! If it wasn't for Java's VM, maybe I wouldn't have moved to D. Other reasons that maybe compelling for some: not restrictively OO (although in java you can work around it by declaring static methods & variables all over the place)
Mar 18 2006
parent pragma <pragma_member pathlink.com> writes:
In article <dvhr8j$eg0$1 digitaldaemon.com>, Hasan Aljudy says...
Walter Bright wrote:
 I'm no expert on Java programming, but I get this question a lot: "What 
 compelling reason does D have that would entice a Java programmer to switch 
 to D?"
 
 I know several of you have come to D from Java, and are expert Java 
 programmers, so you folks' reasons would be very valuable. 
 
 

no VM!! If it wasn't for Java's VM, maybe I wouldn't have moved to D. Other reasons that maybe compelling for some: not restrictively OO (although in java you can work around it by declaring static methods & variables all over the place)

I'll second that. These are the core reasons for switching from Java to D, or even .NET to D for that matter. The rest is just icing on the cake. On a less technical note, I have enjoyed the fact that "D is just D". Its a nice switch from the "Sun Java(tm)" branding that has been pasted on everything Java from the very start. When one uses Java, the branding is so overt that it makes one feel like they're using someone else's tool, rather than one of their own. I honestly feel that its small touches like this that keep D near and dear to our hearts. - EricAnderton at yahoo
Mar 18 2006
prev sibling next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:dvhohr$asa$1 digitaldaemon.com...
 I'm no expert on Java programming, but I get this question a lot: "What 
 compelling reason does D have that would entice a Java programmer to 
 switch to D?"

 I know several of you have come to D from Java, and are expert Java 
 programmers, so you folks' reasons would be very valuable.

They are not strictly comparable to be honest. E.g. Java programmer doing server side stuff will not switch to D. Completely different execution models. Such switch makes more sense for GUI Java programmers (client side): 0) D application does not require JRE (java runtime) to be installed on client machine. 1) D allows to write Java code and at the same time to write code hidden behind JNI - a.k.a native. Thus you don't need two completely different environments. 2) D is natively compileable, has structures and compile time templates (vs runtime generics). 3) If someone will forget his/her Java background then he/she will be able to write code which will execute way faster than Java code. Andrew.
Mar 18 2006
parent reply U.Baumanis <U.Baumanis_member pathlink.com> writes:
In article <dvhtsa$hh5$1 digitaldaemon.com>, Andrew Fedoniouk says...
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:dvhohr$asa$1 digitaldaemon.com...
 I'm no expert on Java programming, but I get this question a lot: "What 
 compelling reason does D have that would entice a Java programmer to 
 switch to D?"

 I know several of you have come to D from Java, and are expert Java 
 programmers, so you folks' reasons would be very valuable.

They are not strictly comparable to be honest. E.g. Java programmer doing server side stuff will not switch to D. Completely different execution models. Such switch makes more sense for GUI Java programmers (client side): Andrew.

I don't agree about GUI - Java GUI (Swing) is very strong. There is no comparable alternative in D (yet). Don't tell me about DWT. ;) -- ub
Mar 18 2006
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 I don't agree about GUI - Java GUI (Swing) is very strong. There is no
 comparable alternative in D (yet). Don't tell me about DWT. ;)

There are no real GUI Applications using Swing either :) So score: 1:1. Your turn. Andrew.
Mar 18 2006
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Andrew Fedoniouk wrote:

I don't agree about GUI - Java GUI (Swing) is very strong. There is no
comparable alternative in D (yet). Don't tell me about DWT. ;)

There are no real GUI Applications using Swing either :)

Is that like how the Java CLI applications aren't "real" programs ? If they work OK, does it *really* matter if it's virtual or native ? If you wanted a Java/Swing application to be "more native", couldn't you just compile it with GCJ/SWT and keep the same APIs in the code ? I think Swing makes perfect sense for the default interface of Java, and it's actually SWT that is the "strange one" in my own book :-) Could be just because I originally learnt it in that way, of course... From what I see in the current SWT it has come a very long way since. --anders
Mar 19 2006
prev sibling next sibling parent reply U.Baumanis <U.Baumanis_member pathlink.com> writes:
In article <dvitlk$2848$1 digitaldaemon.com>, Andrew Fedoniouk says...
 I don't agree about GUI - Java GUI (Swing) is very strong. There is no
 comparable alternative in D (yet). Don't tell me about DWT. ;)

There are no real GUI Applications using Swing either :) So score: 1:1. Your turn. Andrew.

Take a look at http://java.sun.com/products/jfc/tsc/sightings/ Yes, Swing has steep learning curve, but it is well designed and very flexible. Actually it is my choice Nr.1 for GUI apps and I would like to have something similar in D standard library (?may be based on Cairo graphics?). People who thinks that Java/Swing is too slow reads Slashdot too much or probably tryed Java in last centuary. ;) Another think what I really miss in D is a JDBC's type interface to databases. On the other hand D is small, compact, powerful, has better interface to C and somehow gives again good feeling like in old C days. :) Absence of IDE for D is not so big problem as lack of good standard libraries (gui, db, comm, etc.) And this is one thing what keeps D off of using in big projects. You cannot fully concentrate on problem domain. -- ub
Mar 19 2006
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"U.Baumanis" <U.Baumanis_member pathlink.com> wrote in message 
news:dvjhl2$fks$1 digitaldaemon.com...
 In article <dvitlk$2848$1 digitaldaemon.com>, Andrew Fedoniouk says...
 I don't agree about GUI - Java GUI (Swing) is very strong. There is no
 comparable alternative in D (yet). Don't tell me about DWT. ;)

There are no real GUI Applications using Swing either :) So score: 1:1. Your turn. Andrew.

Take a look at http://java.sun.com/products/jfc/tsc/sightings/

I knew that you will show me this page. You've missed capital letter A in Applications. How to explain what I mean? Well, the most popular Java IDEs were built on everything but not Swing. I think this fact can be an illustration of what I mean. Swing is a child of academic development and is primarily used in univercities for educational purposes. Swing is conceptually best toolkit - classical I would say. But only in theory, practical implementation is far from ideal - to heavy to be used in real life. About Java GUI practical implementation: Here is my proof of concept: http://www.terrainformatica.com/org/j-smile/index.htm This is my JavaVM running typical GUI tasks. System of classes of this micro GUI is close to Swing Even this small example shows that Java could run GUI successfully but for some reasons nobody really wants Java GUI. BTW: It would be interesting to implement JavaVM in D.
 Yes, Swing has steep learning curve, but it is well designed and very 
 flexible.
 Actually it is my choice Nr.1 for GUI apps and I would like to have 
 something
 similar in D standard library (?may be based on Cairo graphics?). People 
 who
 thinks that Java/Swing is too slow reads Slashdot too much or probably 
 tryed
 Java in last centuary. ;)
 Another think what I really miss in D is a JDBC's type interface to 
 databases.
 On the other hand D is small, compact, powerful, has better interface to C 
 and
 somehow gives again good feeling like in old C days. :)

 Absence of IDE for D is not so big problem as lack of good standard 
 libraries
 (gui, db, comm, etc.) And this is one thing what keeps D off of using in 
 big
 projects. You cannot fully concentrate on problem domain.

I am using VS6 for D. Not ideal but pretty sufficient. Andrew.
Mar 19 2006
next sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
I use Visual Studio .NET 2003 with my customized version of DCoder. 
IMHO, it's easily more than just sufficient.

What is insufficient about it?  Simply the fact that the debugger and 
such do not mesh?

-[Unknown]

 
 I am using VS6 for D. Not ideal but pretty sufficient.
 
 Andrew.

Mar 19 2006
prev sibling parent reply U.Baumanis <U.Baumanis_member pathlink.com> writes:
In article <dvk4a7$1utv$1 digitaldaemon.com>, Andrew Fedoniouk says...
"U.Baumanis" <U.Baumanis_member pathlink.com> wrote in message 

Take a look at http://java.sun.com/products/jfc/tsc/sightings/

I knew that you will show me this page. You've missed capital letter A in Applications. How to explain what I mean? Well, the most popular Java IDEs were built on everything but not Swing. I think this fact can be an illustration of what I mean.

Well, Netbeans one of most popular Java IDE built on Swing.
Swing is a child of academic development and is primarily
used in univercities for educational purposes.
Swing is conceptually best toolkit - classical I would say.
But only in theory, practical implementation is far from ideal - to heavy
to be used in real life.

I use Swing daily to write applications. They are fast, responsive, easy to maintain, and clients don't have any issues with speed. :) It is really conceptually very good and speed is the last thing to chose D (with DWT?) over Java/Swing. Well, I am not OS/kernel developer. :)
About Java GUI practical implementation:

Here is my proof of concept:
http://www.terrainformatica.com/org/j-smile/index.htm
This is my JavaVM running typical GUI tasks.
System of classes of this micro GUI  is close to Swing
Even this small example shows that Java could run GUI
successfully but for some reasons nobody really wants Java GUI.

nice work! :) -- ub
Mar 19 2006
parent Tom <ihate spam.com> writes:
U.Baumanis escribió:
 In article <dvk4a7$1utv$1 digitaldaemon.com>, Andrew Fedoniouk says...
 "U.Baumanis" <U.Baumanis_member pathlink.com> wrote in message 
 Well, there are hundreds of Java/Swing applications. :)
 Take a look at http://java.sun.com/products/jfc/tsc/sightings/

You've missed capital letter A in Applications. How to explain what I mean? Well, the most popular Java IDEs were built on everything but not Swing. I think this fact can be an illustration of what I mean.

Well, Netbeans one of most popular Java IDE built on Swing.
 Swing is a child of academic development and is primarily
 used in univercities for educational purposes.
 Swing is conceptually best toolkit - classical I would say.
 But only in theory, practical implementation is far from ideal - to heavy
 to be used in real life.

I use Swing daily to write applications. They are fast, responsive, easy to maintain, and clients don't have any issues with speed. :) It is really conceptually very good and speed is the last thing to chose D (with DWT?) over Java/Swing. Well, I am not OS/kernel developer. :)

:0 What!? Speed IS a known issue the same as it is memory consumption. If there is speedy apps written in Java, then those are the least. Or at most, to write quick apps in Java is pretty difficult. Maybe I have the wrong impression but there has been hundreds of _desktop apps_ I've reviewed and 95% of them are just *slow*.
Mar 19 2006
prev sibling parent reply "BLS" <lietz wanadoo.fr> writes:
"Andrew Fedoniouk" <news terrainformatica.com> schreef in bericht
news:dvitlk$2848$1 digitaldaemon.com...
 I don't agree about GUI - Java GUI (Swing) is very strong. There is no
 comparable alternative in D (yet). Don't tell me about DWT. ;)


DWT is indeed strange, but I think DFace could be the way to make GUI programming more comfortable. wxD (your child, i think) is in general a good thing but has the problem that it is based on wxNet respective the wxc. I guess the this project is at a stand still. ( see last updates, the mailing list) if not dead. So what will you do next ? In my opinion you only have the choice to pick up Andy Friesen s SWIG for D project to make further progress........
 There are no real GUI Applications using Swing either :)

Really ? What about the Netbeans IDE. <g> (and not to forget the apps build based on the Netbeans platform. ) Sorry about the OFF TOPIC Bjoern
Mar 19 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
BLS wrote:

 wxD (your child, i think) is in general a good thing but has the problem
 that it is based on wxNet respective the wxc. I guess the this project is at
 a stand still. ( see last updates, the mailing list)  if not dead. 

The wxD project is not at a stand-still or dead. In fact, we are just preparing a new release... New version has some bugfixes for bool and DMC, and adds some missing classes for sound support. See http://wxd.sourceforge.net/ for the details... Sharing code with wx.NET project is not a problem ? --anders
Mar 19 2006
parent reply "BLS" <lietz wanadoo.fr> writes:
Hi Anders,
Good News!
regarding my previous message :
I do not mean that you will let wxD die. I mean the wxNet project is quit
dead. So the problem I am talking about is  the fact that wxD depends on
wxc.
Bjoern

"Anders F Björklund" <afb algonet.se> schreef in bericht
news:dvjlcn$ns9$1 digitaldaemon.com...
 BLS wrote:

 wxD (your child, i think) is in general a good thing but has the problem
 that it is based on wxNet respective the wxc. I guess the this project


 a stand still. ( see last updates, the mailing list)  if not dead.

The wxD project is not at a stand-still or dead. In fact, we are just preparing a new release... New version has some bugfixes for bool and DMC, and adds some missing classes for sound support. See http://wxd.sourceforge.net/ for the details... Sharing code with wx.NET project is not a problem ? --anders

Mar 19 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
BLS wrote:

 I do not mean that you will let wxD die. I mean the wxNet project is quit
 dead. So the problem I am talking about is  the fact that wxD depends on
 wxc.

It's actually not really a problem, just means "more work for us". The last two or three wxD versions have added features that are not available (yet?) in wx.NET, and we're moving towards wx 2.6.3 now... The "wxc" that we use is specific to wxD now, just as our "wxd" is a ported version of the wx.NET classes. So it's a clean fork anyway ? It's all good. We don't *need* the wx.NET project, even if it's sad to see it go... (guess most people are using GTK# instead, since it's recommended ?) Do of course need the main wxWidgets project, but that's a good thing since it is very active and since we can use the same wx libraries ? --anders PS. I'm trying to fix some more of the wxD crashing bugs / memory leaks, but we could always use some more testing and feedback, I suppose... Tracker is at http://sourceforge.net/tracker/?group_id=133831
Mar 19 2006
prev sibling next sibling parent "Jim Miller" <gordon.j.miller gmail.com> writes:
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 3/18/06, Walter Bright <newshound digitalmars.com> wrote:
 I'm no expert on Java programming, but I get this question a lot: "What
 compelling reason does D have that would entice a Java programmer to
 switch
 to D?"

 I know several of you have come to D from Java, and are expert Java
 programmers, so you folks' reasons would be very valuable.

1) Native binaries 2) Garbage collection 3) Module system I've programmed quite a bit of Java over the past 12 years but most of my Java programming is server side, non-gui, non-web applications. Attempting to do supervised management of Java programs as daemons is very difficult (how do I ensure my application is running?) without having to roll in the Java Management extensions which just bloats my code.
Mar 18 2006
prev sibling next sibling parent reply Tom <ihate spam.com> writes:
Walter Bright wrote:
 I'm no expert on Java programming, but I get this question a lot: "What 
 compelling reason does D have that would entice a Java programmer to switch 
 to D?"
 
 I know several of you have come to D from Java, and are expert Java 
 programmers, so you folks' reasons would be very valuable. 

Java - Sucks 'cause of its horrendous slowness - Has a VM (this is the worst disadvantage) - Eats memory as a monster of hell (even in simple apps) - Language itself is nice but clearly D is more than a superset of it - The JDK is enormous _OMG_, never nice to download! + "Dynamic Linking" of packages with JAVA is damn easy! + Infrastructure is really complete (IDE and stuff) Tom;
Mar 18 2006
parent reply David Medlock <ashleymedlock no.spam.yahoo.com> writes:
Tom wrote:
 Walter Bright wrote:
 
 I'm no expert on Java programming, but I get this question a lot: 
 "What compelling reason does D have that would entice a Java 
 programmer to switch to D?"

 I know several of you have come to D from Java, and are expert Java 
 programmers, so you folks' reasons would be very valuable. 

Java - Sucks 'cause of its horrendous slowness

This hasn't been true in quite some time. Check Javas position relative to C++ here: http://dada.perl.it/shootout/craps.html I will agree/add with my list below: 1. No runtime to install. (80 megs?) 2. JVM is a memory hogg. 3. Much better low-level facilities(OpenGL, bit twiddling)
Mar 19 2006
next sibling parent reply Tom <ihate spam.com> writes:
David Medlock escribió:
 Tom wrote:
 Walter Bright wrote:

 I'm no expert on Java programming, but I get this question a lot: 
 "What compelling reason does D have that would entice a Java 
 programmer to switch to D?"

 I know several of you have come to D from Java, and are expert Java 
 programmers, so you folks' reasons would be very valuable. 

Java - Sucks 'cause of its horrendous slowness

This hasn't been true in quite some time. Check Javas position relative to C++ here: http://dada.perl.it/shootout/craps.html

That's very nice, but it has been many years and still I'VE NEVER seen a quick Java app in my life (maybe two or tree very small programs).
 I will agree/add with my list below:
 
 1. No runtime to install. (80 megs?)
 2. JVM is a memory hogg.
 3. Much better low-level facilities(OpenGL, bit twiddling)

Mar 19 2006
next sibling parent reply U.Baumanis <U.Baumanis_member pathlink.com> writes:
In article <dvjnjd$taj$1 digitaldaemon.com>, Tom says...
 Java
 - Sucks 'cause of its horrendous slowness

This hasn't been true in quite some time. Check Javas position relative to C++ here: http://dada.perl.it/shootout/craps.html

That's very nice, but it has been many years and still I'VE NEVER seen a quick Java app in my life (maybe two or tree very small programs).

usually want to use all hot/popular frameworks (EJB, Hibernate, Spring, XML, etc.) in their cool megabucks projects (just for marketing!) and use code generated by GUI designers, all operations in one thread, ... In such way you can broke app written in any language. -- ub
Mar 19 2006
parent Tom <ihate spam.com> writes:
U.Baumanis escribió:
 In article <dvjnjd$taj$1 digitaldaemon.com>, Tom says...
 Java
 - Sucks 'cause of its horrendous slowness

Check Javas position relative to C++ here: http://dada.perl.it/shootout/craps.html

quick Java app in my life (maybe two or tree very small programs).

usually want to use all hot/popular frameworks (EJB, Hibernate, Spring, XML, etc.) in their cool megabucks projects (just for marketing!) and use code generated by GUI designers, all operations in one thread, ... In such way you can broke app written in any language.

Maybe, but this is *very* common. Tom;
Mar 19 2006
prev sibling parent reply Charles <noone nowhere.com> writes:
 That's very nice, but it has been many years and still I'VE NEVER seen a
 quick Java app in my life (maybe two or tree very small programs).

Do you mean desktop apps ? If so I agree they usually are unbearably slow -- the only exception to this seems to be SWT apps. Server side apps is where Java shines usually .
 Check Javas position relative to C++ here:
 http://dada.perl.it/shootout/craps.html


That only measures CPU usage , I would argue that you _want_ a program to use as much CPU as possible. The memory usage page http://dada.perl.it/shootout/craps_mem.html , puts Java back in its place near dead last. Tom wrote:
 David Medlock escribió:
 
 Tom wrote:

 Walter Bright wrote:

 I'm no expert on Java programming, but I get this question a lot: 
 "What compelling reason does D have that would entice a Java 
 programmer to switch to D?"

 I know several of you have come to D from Java, and are expert Java 
 programmers, so you folks' reasons would be very valuable. 

Java - Sucks 'cause of its horrendous slowness

This hasn't been true in quite some time. Check Javas position relative to C++ here: http://dada.perl.it/shootout/craps.html

That's very nice, but it has been many years and still I'VE NEVER seen a quick Java app in my life (maybe two or tree very small programs).
 I will agree/add with my list below:

 1. No runtime to install. (80 megs?)
 2. JVM is a memory hogg.
 3. Much better low-level facilities(OpenGL, bit twiddling)


Mar 19 2006
next sibling parent Tom <ihate spam.com> writes:
Charles escribió:
  > That's very nice, but it has been many years and still I'VE NEVER seen a
  > quick Java app in my life (maybe two or tree very small programs).
 
 Do you mean desktop apps ?  If so I agree they usually are unbearably 
 slow -- the only exception to this seems to be SWT apps.
 
 Server side apps is where Java shines usually .

You're right, desktop apps I mean.
Mar 19 2006
prev sibling parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Charles wrote:
 That's very nice, but it has been many years and still I'VE NEVER seen a
 quick Java app in my life (maybe two or tree very small programs).

Do you mean desktop apps ? If so I agree they usually are unbearably slow -- the only exception to this seems to be SWT apps.

Ahem, AFAIK Eclipse is the primary desktop app using SWT and it's damn slow on Linux (although the weakest link in the chain seems to be GTK+, not SWT, I think).
Mar 19 2006
prev sibling next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 I will agree/add with my list below:

 1. No runtime to install. (80 megs?)

JRE is about 5megs or so. And as I've shown in this thread already: http://www.terrainformatica.com/org/j-smile/index.htm j-smile-demo is JavaVM + GUI ruintime = 200k. Set of .class files of the demo app = another 200k. All together = 400k. This example deomstrates that JavaVM can be made small enough to be bundled with application code eliminating need of JRE at all.
 2. JVM is a memory hogg.

Bad design of GUI libraries. Not more. Andrew.
Mar 19 2006
next sibling parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Andrew Fedoniouk wrote:
 I will agree/add with my list below:

 1. No runtime to install. (80 megs?)

JRE is about 5megs or so.

I have the Windows installer for 1.5.0.06 on my hard drive, and it's precisely 16 779 392 bytes.
Mar 19 2006
parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
And that's assuming you can use that specific version of the runtime 
with the specific version of the Java program you want to use.

Otherwise it's another 16 megabytes.  And the large updates you're 
always prompted to install.

Unpacked it's significantly larger, but I realize most people these days 
don't care if their simple text editor requires 200 megabytes of hard 
drive space.

-[Unknown]


 Andrew Fedoniouk wrote:
 I will agree/add with my list below:

 1. No runtime to install. (80 megs?)


I have the Windows installer for 1.5.0.06 on my hard drive, and it's precisely 16 779 392 bytes.

Mar 19 2006
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Andrew Fedoniouk wrote:
 JavaVM + GUI ruintime = 200k.

Hmm. Compared with D "Hello World", I'm getting worried.
Mar 20 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:

 Hmm. Compared with D "Hello World", I'm getting worried.

D programs are bigger than C and Java, but smaller than C++ ? Here are some old Hello test results I had: (on Mac OS X 10.3) 31b hello.sh (script) Hello, World! 0.01 real 0.00 user 0.00 sys 12K hello_c (executable) Hello, World! 0.03 real 0.00 user 0.00 sys 368K hello_cpp (including libstdc++) Hello, World! 0.09 real 0.00 user 0.02 sys 104K hello_d (including Phobos) Hello, World! 0.04 real 0.01 user 0.01 sys 637b hello.jar (archive) Hello, World! 0.66 real 0.38 user 0.19 sys Results for C, C++, D, Java 1.4 and Bourne Shell respectively... If the Java runtime comes with the system, Java's really small ! (then again, it's also the far slowest to start up and execute which makes it less suitable for small programs like this one) BTW: Having a programming language that needs separate compilation as a first language is pretty mean I think. But that's just me. (better to go with a scripting language, such as Ruby or Python ? and it avoids having to unlearn things picked up from Pascal...) But I learned Pascal in school, and Ada in university. Hated both. :) I think you need to learn at least three languages. Preferrably more. --anders PS. #!/bin/sh echo "Hello, World!" ----------------------------------------- #include <stdio.h> int main(int argc, char *argv[]) { puts("Hello, World!"); return 0; } ----------------------------------------- #include <iostream> using namespace std; int main(int argc, char *argv[]) { cout << "Hello, World!" << endl; return 0; } ----------------------------------------- import std.stdio; void main() { writeln("Hello, World!"); } ----------------------------------------- public class hello { public static void main(String[] args) { System.out.println("Hello, World!"); } }
Mar 21 2006
next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Anders F Björklund wrote:
 Georg Wrede wrote:
 
 Hmm. Compared with D "Hello World", I'm getting worried.

D programs are bigger than C and Java, but smaller than C++ ? Here are some old Hello test results I had: (on Mac OS X 10.3) 31b hello.sh (script) Hello, World! 0.01 real 0.00 user 0.00 sys 12K hello_c (executable) Hello, World! 0.03 real 0.00 user 0.00 sys 368K hello_cpp (including libstdc++) Hello, World! 0.09 real 0.00 user 0.02 sys 104K hello_d (including Phobos) Hello, World! 0.04 real 0.01 user 0.01 sys 637b hello.jar (archive) Hello, World! 0.66 real 0.38 user 0.19 sys

12k would be my dream for D! Seriously. I think we'll get a lot smaller executables once 1.0 has been out for some time and we get down to the basic, mundane stuff in development. Or Walter does. :-)
 BTW:
 Having a programming language that needs separate compilation
 as a first language is pretty mean I think. But that's just me.

The 5 years I taught CS made me a firm believer in how immensely important the choice of the first language to teach really is. The things in that language stick with you for the rest of your life, no matter how many others you learn after it.
 (better to go with a scripting language, such as Ruby or Python ?
 and it avoids having to unlearn things picked up from Pascal...)

They're both excellent languages, but IMHO D is it. I don't dare to elaborate on this, it would just become an enormous OT-thread here.
 But I learned Pascal in school, and Ada in university. Hated both. :)
 I think you need to learn at least three languages. Preferrably more.

Oh yes! Definitely.
Mar 21 2006
next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Tue, 21 Mar 2006 22:38:53 +1100, Georg Wrede <georg.wrede nospam.org>  
wrote:


 The 5 years I taught CS made me a firm believer in how immensely  
 important the choice of the first language to teach really is. The  
 things in that language stick with you for the rest of your life, no  
 matter how many others you learn after it.

I must be doomed then ... my first was COBOL ;-) And then I learnt PL/I, Autocoder, IBM-360 Assembler, Pascal, C, BASIC, Forth, dBASEII, ... -- Derek Parnell Melbourne, Australia
Mar 21 2006
parent Don Clugston <dac nospam.com.au> writes:
Derek Parnell wrote:
 On Tue, 21 Mar 2006 22:38:53 +1100, Georg Wrede <georg.wrede nospam.org> 
 wrote:
 
 
 The 5 years I taught CS made me a firm believer in how immensely 
 important the choice of the first language to teach really is. The 
 things in that language stick with you for the rest of your life, no 
 matter how many others you learn after it.

I must be doomed then ... my first was COBOL ;-) And then I learnt PL/I, Autocoder, IBM-360 Assembler, Pascal, C, BASIC, Forth, dBASEII, ... --Derek Parnell Melbourne, Australia

That really is a litany of woe. I'm impressed. : OVER SWAP DUP ROT SWAP ; Georg is right. For me it was Z-80 (programmed in hex), BASIC, 6502 asm, Forth, Pascal, x86 asm, C, C++, FORTRAN, LISP, SQL... and I'm still a Z-80 programmer at heart. I still remember a frightening number of the opcodes. C++ was the only other language I actually liked, until D came along.
Mar 21 2006
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:

 12k would be my dream for D! Seriously.

9-10k is overhead of the Mach-O format, so that's as low as it gets... It's possible to make C++ and D programs of an equivalent size too, by making their standard runtime libraries dynamically linked instead of statically linked like in the list I posted. (as those libs are *big*) Of course, then you also need to make sure that the receiving end of those programs have the correct version of runtime library installed, something that is a Huge Pain for distributing C++ programs on Linux... But Bjarne doesn't have to worry about those small practical things, (see http://public.research.att.com/~bs/bs_faq.html#Hello-world) and having Phobos statically linked might prove to be a Good Thing ? So until D is much more stable, I think Phobos should be kept static.
 I think we'll get a lot smaller executables once 1.0 has been out for 
 some time and we get down to the basic, mundane stuff in development. Or 
 Walter does. :-)

This was with GDC, you could probably make smaller programs with DMD ?
 The 5 years I taught CS made me a firm believer in how immensely 
 important the choice of the first language to teach really is. The 
 things in that language stick with you for the rest of your life, no 
 matter how many others you learn after it.

My first programming language ever was HyperTalk, believe it or not. --anders
Mar 21 2006
next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Anders F Björklund wrote:
 Georg Wrede wrote:
 
 So until D is much more stable, I think Phobos should be kept static.

What I'd love is statically linked D programs where only the used parts of the library are linked in. IIRC, Turbo Pascal used to do that.
 My first programming language ever was HyperTalk, believe it or not.

Not a bad language at all to start with. And an excellent one for somebody learning on their own. With HyperTalk one was up and productive in no time at all. (In 1985 I earned money doing HyperTalk stuff.)
Mar 21 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:

 My first programming language ever was HyperTalk, believe it or not.

Not a bad language at all to start with. And an excellent one for somebody learning on their own. With HyperTalk one was up and productive in no time at all. (In 1985 I earned money doing HyperTalk stuff.)

It's still around "in spirit", even if Apple _slowly_ killed HyperCard: http://www.runrev.com/, commercial products from Runtime Revolution Ltd Even reads HyperCard: http://support.runrev.com/resources/hypercard.php Just haven't had any reason to use it, as people tend to prefer to have their development done using the inferior products available elsewhere ? Same reason why I am not doing development with WebObjects or OPENSTEP. And a big reason why I prefer Open Source, as it is less likely to die. --anders
Mar 21 2006
prev sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Anders F Björklund wrote:

 Of course, then you also need to make sure that the receiving end of
 those programs have the correct version of runtime library installed,
 something that is a Huge Pain for distributing C++ programs on Linux...

void fix() { if (user.experiencing == HugePainWithLibraries) { auto GentooLinux = download(www.gentoo.org/stage3); try { user.install(GentooLinux); } catch(TinyEmergeProblem p) { GentooBugzilla.report(p); wait(); emerge(sync); continue install; } } // done, user happy } -- Jari-Matti
Mar 21 2006
next sibling parent Dave <Dave_member pathlink.com> writes:
In article <dvpdvd$qpk$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= says...
Anders F Björklund wrote:

 Of course, then you also need to make sure that the receiving end of
 those programs have the correct version of runtime library installed,
 something that is a Huge Pain for distributing C++ programs on Linux...

void fix() { if (user.experiencing == HugePainWithLibraries) { auto GentooLinux = download(www.gentoo.org/stage3); try { user.install(GentooLinux); } catch(TinyEmergeProblem p) { GentooBugzilla.report(p); wait(); emerge(sync); continue install; } } // done, user happy } -- Jari-Matti

You wouldn't happen to have a system like this would you: Gentoo Linux 2005.1 stage 3, gentoo-sources-2.6.13-r5, Reiserfs Running a P4? If so, please e-mail me at godaves #at# yahoo #dot# com. I'm trying to isolate some odd problems that I can't reproduce anywhere else. Thanks, - Dave
Mar 21 2006
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Jari-Matti Mäkelä wrote:

Of course, then you also need to make sure that the receiving end of
those programs have the correct version of runtime library installed,
something that is a Huge Pain for distributing C++ programs on Linux...

void fix() { if (user.experiencing == HugePainWithLibraries) { auto GentooLinux = download(www.gentoo.org/stage3); try { user.install(GentooLinux); }

Well, maybe I was overstating the problem. It's easy enough to fix the dependencies on libstdc++.so.5 or libstdc++.2.9 or whatever, if you have a Linux distribution with a reasonable ports/package manager. (all of Gentoo and Ubuntu and Fedora qualifies, as far as I'm concerned) --anders
Mar 21 2006
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Jari-Matti Mäkelä wrote:

     catch(TinyEmergeProblem p) {
       GentooBugzilla.report(p);
       wait();
       emerge(sync);
       continue install;
     }
   }
   // done, user happy
 }

Speaking of Gentoo, anyone know what happens with: http://bugs.gentoo.org/show_bug.cgi?id=46806 ? I don't really use Gentoo myself anymore (too "LFS") but the ebuild is still working OK for version 150. --anders
Mar 21 2006
parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Anders F Björklund wrote:
 Jari-Matti Mäkelä wrote:
 
     catch(TinyEmergeProblem p) {
       GentooBugzilla.report(p);
       wait();
       emerge(sync);
       continue install;
     }
   }
   // done, user happy
 }

Speaking of Gentoo, anyone know what happens with: http://bugs.gentoo.org/show_bug.cgi?id=46806 ? I don't really use Gentoo myself anymore (too "LFS") but the ebuild is still working OK for version 150.

We still need the find a friendly developer to take care of the ebuild. Gentoo is too "LFS"? Well, it's already possible to install Gentoo with a graphical installer, genkernel eliminates the need to hack with the kernel and package management / USE-flag editing do both have graphical frontends. The only problem is that there's no handy way to install up-to-date prebuilt binary packages compiled with custom use-flags and cflags. Debian/Slackware/Arch aren't really much "higher level". I'm using Arch myself on slower PCs since portage is currently a bit too "heavy". -- Jari-Matti
Mar 22 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Jari-Matti Mäkelä wrote:

 We still need the find a friendly developer to take care of the ebuild.

A maintainer ? OK, the same problem as with Debian then... I understand.
 Gentoo is too "LFS"? Well, it's already possible to install Gentoo with
 a graphical installer, genkernel eliminates the need to hack with the
 kernel and package management / USE-flag editing do both have graphical
 frontends. The only problem is that there's no handy way to install
 up-to-date prebuilt binary packages compiled with custom use-flags and
 cflags. Debian/Slackware/Arch aren't really much "higher level". 

I like Gentoo a lot, it sort of reminds me of FreeBSD which I also like. Found that doing a Gentoo install was well documented but very hands-on. Just that marketing forces has me running distros originating from R.H. And I still think that Ubuntu and Linspire are less scary for "users" ? So while I still have Gentoo installed, I don't really use it much :-( But maybe I should take another look at 2006.0, it looks much improved.
 I'm using Arch myself on slower PCs since portage is currently a bit

Yeah, sounds like "typical Python" :-) But I have never seen Arch Linux. Sounds like a nice inbetween of Slack and Gentoo, but I might be wrong ? --anders
Mar 22 2006
parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Anders F Björklund wrote:
 Jari-Matti Mäkelä wrote:
 Gentoo is too "LFS"? Well, it's already possible to install Gentoo with
 a graphical installer, genkernel eliminates the need to hack with the
 kernel and package management / USE-flag editing do both have graphical
 frontends. The only problem is that there's no handy way to install
 up-to-date prebuilt binary packages compiled with custom use-flags and
 cflags. Debian/Slackware/Arch aren't really much "higher level". 

I like Gentoo a lot, it sort of reminds me of FreeBSD which I also like. Found that doing a Gentoo install was well documented but very hands-on. Just that marketing forces has me running distros originating from R.H. And I still think that Ubuntu and Linspire are less scary for "users" ?

I also think they have very good features for easy tasks. Still I prefer community-based distros for everyday hacking and developing bleeding-edge software.
 
 So while I still have Gentoo installed, I don't really use it much :-(
 But maybe I should take another look at 2006.0, it looks much improved.

Maybe.
 
 I'm using Arch myself on slower PCs since portage is currently a bit

Yeah, sounds like "typical Python" :-) But I have never seen Arch Linux. Sounds like a nice inbetween of Slack and Gentoo, but I might be wrong ?

Portage really needs a rewrite from scratch. Maybe some CPU-intensive parts of it could be written in D! :) Yes, Arch is a lightweight distro for experienced users. Much less features, packages and configuration scripts included, but it's fast, and "easy" to install and update. A good alternative for people who like Gentoo and ports-like package management, but don't want to spend all day compiling source packages. -- Jari-Matti
Mar 22 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Jari-Matti Mäkelä wrote:

Just that marketing forces has me running distros originating from R.H.
And I still think that Ubuntu and Linspire are less scary for "users" ?

I also think they have very good features for easy tasks. Still I prefer community-based distros for everyday hacking and developing bleeding-edge software.

Yeah, I'm using Fedora Core... (mostly since I need to support RHL/RHEL)
But maybe I should take another look at 2006.0, it looks much improved.

Maybe.

It's now running an emerge from like 2004 or so, could take a while. :-)
 Portage really needs a rewrite from scratch. Maybe some CPU-intensive
 parts of it could be written in D! :)

For the record, Yum sucks just as much for RPM. Hmm, Python there too... http://rhesa.hates-software.com/2005/11/06/707b5e44.html Prefer APT-RPM. > Yes, Arch is a lightweight distro for experienced users. Much less
 features, packages and configuration scripts included, but it's fast,
 and "easy" to install and update. A good alternative for people who like
 Gentoo and ports-like package management, but don't want to spend all
 day compiling source packages.

Sounded like a good alternative to Slackware, for the knowledgable user. --anders
Mar 22 2006
prev sibling parent reply Lucas Goss <lgoss007 gmail.com> writes:
Anders F Björklund wrote:
 31b     hello.sh (script)
 Hello, World!
         0.01 real         0.00 user         0.00 sys
 ...

Hmm, sounds like fun. Same tests for bourne shell, C, C++, and D (GDC) on linux x86 (ubuntu dapper) code size real user sys sh 31b 0.016 0.010 0.006 0.017 0.007 0.009 0.018 0.011 0.006 C 6.8K 0.003 0.002 0.000 0.003 0.000 0.002 0.003 0.000 0.002 C++ 8.3K 0.127 0.005 0.001 0.007 0.003 0.003 0.006 0.001 0.004 GDC 426.5K 0.014 0.002 0.002 0.004 0.001 0.002 0.005 0.002 0.003 I kinda wonder how dmd does? I would have tried it but it links to libstdc++.so.5, currently I have libstdc++.so.6 and didn't feel like installing the old libstdc++ on this machine (I have others with older versions that run dmd).
Mar 21 2006
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Lucas Goss wrote:

 C++     8.3K     0.127   0.005   0.001
                  0.007   0.003   0.003
                  0.006   0.001   0.004
 
 GDC   426.5K     0.014   0.002   0.002
                  0.004   0.001   0.002
                  0.005   0.002   0.003

That's with a dynamic lib for C++, right ? (i.e. like when you run "ldd" on the binary)
 I kinda wonder how dmd does? I would have tried it but it links to 
 libstdc++.so.5, currently I have libstdc++.so.6 and didn't feel like 
 installing the old libstdc++ on this machine (I have others with older 
 versions that run dmd).

Don't you have a compat-libstdc++ or similar pkg ? (run that on Fedora Core, for DMD's old binary...) --anders
Mar 21 2006
parent reply Lucas Goss <lgoss007 gmail.com> writes:
Anders F Björklund wrote:
 That's with a dynamic lib for C++, right ?

Of course. But why would you statically link the whole stdc++ lib :) 3.3 MB static linking (g++ -ohellocpp -static -lstdc++ hello.cpp)
 Don't you have a compat-libstdc++ or similar pkg ?
 (run that on Fedora Core, for DMD's old binary...)

There is a libstdc++5-3.3, I just didn't want to install the old... well, ok... size real user sys DMD 207.0K 0.004 0.002 0.002 0.004 0.001 0.002 0.004 0.001 0.002
Mar 21 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Lucas Goss wrote:

 That's with a dynamic lib for C++, right ?

Of course. But why would you statically link the whole stdc++ lib :)

Well, it did that on Mac OS X 10.3 (it doesn't on Mac OS X 10.4) /usr/lib/gcc/darwin/3.3/libstdc++.a Just for a comparison... --anders
Mar 21 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <dvpatk$mtg$1 digitaldaemon.com>, Lucas Goss says...
Anders F Björklund wrote:
 31b     hello.sh (script)
 Hello, World!
         0.01 real         0.00 user         0.00 sys
 ...

Hmm, sounds like fun. Same tests for bourne shell, C, C++, and D (GDC) on linux x86 (ubuntu dapper) code size real user sys sh 31b 0.016 0.010 0.006 0.017 0.007 0.009 0.018 0.011 0.006 C 6.8K 0.003 0.002 0.000 0.003 0.000 0.002 0.003 0.000 0.002 C++ 8.3K 0.127 0.005 0.001 0.007 0.003 0.003 0.006 0.001 0.004 GDC 426.5K 0.014 0.002 0.002 0.004 0.001 0.002 0.005 0.002 0.003 I kinda wonder how dmd does? I would have tried it but it links to libstdc++.so.5, currently I have libstdc++.so.6 and didn't feel like installing the old libstdc++ on this machine (I have others with older versions that run dmd).

How do you like Ubuntu, say, compared to Fedora Core 4 if you've used that? (I'm past the stage where I want to compile kernel modules, etc. to install a *nix system, so how is the setup routine?). Thanks, - Dave
Mar 21 2006
parent Lucas Goss <lgoss007 gmail.com> writes:
Dave wrote:
 How do you like Ubuntu, say, compared to Fedora Core 4 if you've used that?
 
 (I'm past the stage where I want to compile kernel modules, etc. to install a
 *nix system, so how is the setup routine?).

Setup for Ubuntu is pretty easy (and the new dapper is nice). Compared to Fedora 4 I like it better just because I've always had a problem their RPM and updates (somehow I could always break them), but maybe they've got better? Ubuntu is nice though. I'm kinda torn though because I don't like the whole 6 month release thing (which is why I run Ubuntu alphas). So Gentoo would be nice. But at the same time I don't want to spend a lot of time compiling, well unless it's my programs.
Mar 21 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <dvjlj0$pk0$1 digitaldaemon.com>, David Medlock says...
Tom wrote:
 Walter Bright wrote:
 
 I'm no expert on Java programming, but I get this question a lot: 
 "What compelling reason does D have that would entice a Java 
 programmer to switch to D?"

 I know several of you have come to D from Java, and are expert Java 
 programmers, so you folks' reasons would be very valuable. 

Java - Sucks 'cause of its horrendous slowness

This hasn't been true in quite some time. Check Javas position relative to C++ here: http://dada.perl.it/shootout/craps.html

Here's a later version of that benchmark 'suite': http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=all Along with the resurrected tests from the site above (note that this site as uniform 'weights' for all of the tests that don't benefit one language over another): http://shootout.alioth.debian.org/old/benchmark.php?test=all&lang=all IIRC, there was some argument a while back that they weren't running the tests long-enough to take advantage of Hotspot. Since then they've increased the length of the tests to account for that (and startup time is subtracted from those results as well, I believe). Of course, these being benchmarks, take everything with a grain of salt <g> IMHO, the purpose they best serve is to point out potential weaknesses to implementors, but anyway...
I will agree/add with my list below:

1. No runtime to install. (80 megs?)
2. JVM is a memory hogg.
3. Much better low-level facilities(OpenGL, bit twiddling)

Mar 19 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Dave" <Dave_member pathlink.com> wrote in message 
news:dvkbvk$2hn5$1 digitaldaemon.com...
 IIRC, there was some argument a while back that they weren't running the 
 tests
 long-enough to take advantage of Hotspot. Since then they've increased the
 length of the tests to account for that (and startup time is subtracted 
 from
 those results as well, I believe).

I attended a seminar at SDWest which talked about the "myth" of slow Java. Turns out, the code is interpreted for a while, then it gets compiled, then certain things can *invalidate the compiled code* so it goes back to interpreting it, then compiling it again, etc. Is it invalid to include all these compile times, even if they occur well into the execution, as part of the benchmark time? I don't think so. At the end of the day, the time the user is sitting their waiting is what matters, and that will include all the startup, interpretation, compilation and recompilation times. The presenter confidently predicted that in 10 years, Java will outperform C in the general case. Color me skeptical.
Mar 19 2006
next sibling parent Tom <ihate spam.com> writes:
Walter Bright escribió:
 "Dave" <Dave_member pathlink.com> wrote in message 
 news:dvkbvk$2hn5$1 digitaldaemon.com...
 IIRC, there was some argument a while back that they weren't running the 
 tests
 long-enough to take advantage of Hotspot. Since then they've increased the
 length of the tests to account for that (and startup time is subtracted 
 from
 those results as well, I believe).

I attended a seminar at SDWest which talked about the "myth" of slow Java. Turns out, the code is interpreted for a while, then it gets compiled, then certain things can *invalidate the compiled code* so it goes back to interpreting it, then compiling it again, etc. Is it invalid to include all these compile times, even if they occur well into the execution, as part of the benchmark time? I don't think so. At the end of the day, the time the user is sitting their waiting is what matters, and that will include all the startup, interpretation, compilation and recompilation times.

I agree 100%. Users in the end, can and will note many of these background "moves" of the VM. The benchmark for testing Java vs. other languages in terms of perceivable speed should be: start the timer just before running the app and stop the timer when terminating it (of course, taking all the cares that are needed to be fair).
 The presenter confidently predicted that in 10 years, Java will outperform C 
 in the general case. Color me skeptical. 

Amen! (this is truly unbelievable)
Mar 19 2006
prev sibling next sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <dvkklp$2pl$1 digitaldaemon.com>, Walter Bright says...
"Dave" <Dave_member pathlink.com> wrote in message 
news:dvkbvk$2hn5$1 digitaldaemon.com...
 IIRC, there was some argument a while back that they weren't running the 
 tests
 long-enough to take advantage of Hotspot. Since then they've increased the
 length of the tests to account for that (and startup time is subtracted 
 from
 those results as well, I believe).

I attended a seminar at SDWest which talked about the "myth" of slow Java. Turns out, the code is interpreted for a while, then it gets compiled, then certain things can *invalidate the compiled code* so it goes back to interpreting it, then compiling it again, etc.

That explains a lot... I had read somewhere a while back that some parts of earlier VM's had to be 'detuned' because optimizations based on real-time info. were often counter-productive and/or causing bugs in apps. I guess in some cases they decided to invalidate cached code rather than 'detune' it.
Is it invalid to include all these compile times, even if they occur well 
into the execution, as part of the benchmark time? I don't think so. At the 
end of the day, the time the user is sitting their waiting is what matters, 
and that will include all the startup, interpretation, compilation and 
recompilation times.

The presenter confidently predicted that in 10 years, Java will outperform C 
in the general case. Color me skeptical. 

It's funny, but I've read predictions like that every year for the last 10 <g> And for many things I think the original JIT's were still the best. From what I gather, there has been huge amounts of R & D into the problem from all kinds of organizations - I figure by now if they haven't figured it out there are reasons other than for trying. A manager I know likes to call stuff like that "polishing the turd" <g>
Mar 19 2006
parent "Walter Bright" <newshound digitalmars.com> writes:
"Dave" <Dave_member pathlink.com> wrote in message 
news:dvksli$ihh$1 digitaldaemon.com...
 From what I gather, there has been huge amounts of R & D into the problem 
 from
 all kinds of organizations - I figure by now if they haven't figured it 
 out
 there are reasons other than for trying. A manager I know likes to call 
 stuff
 like that "polishing the turd" <g>

Certainly, Sun has poured enormous resources into research trying to find ways to make it faster. At some point, though, a point of diminishing returns will be reached.
Mar 19 2006
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 "Dave" <Dave_member pathlink.com> wrote in message 
 news:dvkbvk$2hn5$1 digitaldaemon.com...
 IIRC, there was some argument a while back that they weren't running the 
 tests
 long-enough to take advantage of Hotspot. Since then they've increased the
 length of the tests to account for that (and startup time is subtracted 
 from
 those results as well, I believe).

I attended a seminar at SDWest which talked about the "myth" of slow Java. Turns out, the code is interpreted for a while, then it gets compiled, then certain things can *invalidate the compiled code* so it goes back to interpreting it, then compiling it again, etc. Is it invalid to include all these compile times, even if they occur well into the execution, as part of the benchmark time?

Not at all. In fact, a similar issue came up during the C++/C#/Java template comparison that Herb Sutter did. Someone said they'd heard C# was faster than C++, and Herb felt honor bound to respond. The gist of Herb's response was this: he said that C++ was heavily optimized at compile time and since C++ has been around for quite a while, we've gotten quite good at optimizing it. C#, on the other hand, is hardly optimized at all at compile time, and since the JIT process needs to be near instantaneous to avoid run-time stutter, almost no optimizations take place during run-time compilation as well. Assuming that Java is similar to C# in this respect (which seems quite likely), I would be skeptical of any claims that Java could out-perform C++, as they have similar semantics and C++ is far more heavily optimized. If Java could make one performance claim over C++ it would be that manipulating references could be more efficient than passing copies, but D could make the same claim... and can also take advantage of the optimizations that contribute the performance of C++. Sean
Mar 19 2006
parent reply Dave <Dave_member pathlink.com> writes:
In article <dvld6m$1f37$1 digitaldaemon.com>, Sean Kelly says...
similar semantics and C++ is far more heavily optimized.  If Java could 
make one performance claim over C++ it would be that manipulating 
references could be more efficient than passing copies, but D could make 
the same claim... and can also take advantage of the optimizations that 
contribute the performance of C++.

But C++ can also pass (and return) by reference if needed (obviating the need to call copy ctors), correct? And it can allocate class objects on the stack, which is an option Java doesn't have.
Sean

Mar 20 2006
parent Sean Kelly <sean f4.ca> writes:
Dave wrote:
 In article <dvld6m$1f37$1 digitaldaemon.com>, Sean Kelly says...
 similar semantics and C++ is far more heavily optimized.  If Java could 
 make one performance claim over C++ it would be that manipulating 
 references could be more efficient than passing copies, but D could make 
 the same claim... and can also take advantage of the optimizations that 
 contribute the performance of C++.

But C++ can also pass (and return) by reference if needed (obviating the need to call copy ctors), correct? And it can allocate class objects on the stack, which is an option Java doesn't have.

I think the important distinction is that you can do almost anything in C++ as the situation dictates. Bjarne had a presentation on C++ performance where he presented hard data where C++ was shown to outperform highly tuned C code and even Fortran by multiple orders of magnitude. This was achieved through the use of templates (implicit template instantiation is basically necessary for this), which were unique to C++ until D came along :-) He also made a point of saying that when people compare performance between languages they typically compare specific language features, which I don't think presents a very accurate picture of things. If someone has an example of Java outperforming C++, I suspect it's this kind of example, ie. comparing a tuned Java program to a badly written C++ equivalent using deep inheritance trees, DMA, and tons of virtual method calls with no optimization being performed. In the hands of experts, I think Java has no chance of competing with C++, and I don't see that changing tremendously with time. What Java has going for it is utility, not speed. Sean
Mar 20 2006
prev sibling next sibling parent Dave <Dave_member pathlink.com> writes:
In article <dvkklp$2pl$1 digitaldaemon.com>, Walter Bright says...
Is it invalid to include all these compile times, even if they occur well 
into the execution, as part of the benchmark time? I don't think so. At the 

No doubt it is valid to include that. Not only user time but time it takes from other processes on a heavly used system. It's hard to measure how much overhead this incurs in a real-life program. Sun has -Xprof which can give some info. but I've not seen this used on production programs.
end of the day, the time the user is sitting their waiting is what matters, 
and that will include all the startup, interpretation, compilation and 
recompilation times.

On one 80 line program I have here that takes 1.5 secs to run, the profiler says compilation is 1% of the total, and that doesn't seem to include the time to do the runtime profiling for the optimizer. That's one small program that has one main loop calling one function. On large real-world programs with many loops, functions, selective finalization and all kinds of references floating around and being moved by the GC, the reprofiling/recompilation probably happens a lot more. Since they've been perfecting this stuff for years, IMO there's pretty compelling evidence that there may be intractable problems with this type of approach.
Mar 20 2006
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:
 
 The presenter confidently predicted that in 10 years, Java will
 outperform C in the general case. Color me skeptical.

The number of languages "faster than C", either "now" or "real soon now" that I've heard at various venues, is more than one hand's fingers. Somehow I share your skepticism.
Mar 20 2006
parent David Medlock <noone nowhere.com> writes:
Georg Wrede wrote:

 Walter Bright wrote:
 
 The presenter confidently predicted that in 10 years, Java will
 outperform C in the general case. Color me skeptical.

The number of languages "faster than C", either "now" or "real soon now" that I've heard at various venues, is more than one hand's fingers. Somehow I share your skepticism.

In business, faster is relative believe it or not. If I have an Application which is 30% too slow I can either pay programmers 2 weeks x 2 programmers(40/hr) = 6400$ to optimize it... or I can spend $6400 extra on my hardware to run it(A good AMD64 server from SUN is around this range), and put the developers on other tasks. I think concurrency is really coming into its own in the coming years: we need ways to easily leverage hardware effectively. A good read on the subject: http://labs.google.com/papers/mapreduce-osdi04.pdf -DavidM
Mar 21 2006
prev sibling next sibling parent sai <sai_member pathlink.com> writes:
One and only one reason for me : speed

Sai



In article <dvhohr$asa$1 digitaldaemon.com>, Walter Bright says...
I'm no expert on Java programming, but I get this question a lot: "What 
compelling reason does D have that would entice a Java programmer to switch 
to D?"

I know several of you have come to D from Java, and are expert Java 
programmers, so you folks' reasons would be very valuable. 

Mar 18 2006
prev sibling next sibling parent John Demme <me teqdruid.com> writes:
Walter Bright wrote:

 I'm no expert on Java programming, but I get this question a lot: "What
 compelling reason does D have that would entice a Java programmer to
 switch to D?"
 
 I know several of you have come to D from Java, and are expert Java
 programmers, so you folks' reasons would be very valuable.

I converted from Java a few years ago after just having finished a large Java server and client system. There are a lot of reasons, but since I tend to make gut decisions, it's hard to say why I prefer D. I guess it boils down to three things: the lack of a VM, it's close relationship to the metal (bare-metal) and it's flexibility. -Java's VM sucks up memory and CPU time like nothing else. It takes some time to start, and makes it difficult to interface Java programs with the system and each other. D has not these problems. The initialization that D programs require is miniscule in comparison. -D can (and does) interface with C. Yes, yes, so can Java, but D can do it in an easy and meaningful way. This means that it's trivial for me to do things like get an environment variable via a system call, whereas this is non-trivial in Java. -Thanks to D being bare-metal, I can do a lot of cool stuff, like manual memory-management (only where it makes sense, of course.) For instance, in my SAX parser, I make almost no memory allocations (and the few which I do can be avoided.) I'm able to do cool stuff like copy a String onto the stack. My linked list class could use a free-list of nodes and still use new to instiante them and let the GC manage them. Hell, we've got inline assembly! Again, my XML parser takes advantage of some text searching instructions (via calls to mango.text.Text) on x86 machines. -DMD is super-fast. Automatically inlining function/method calls is great-- it actually speeds up my XML parser by 25%! -All this and I haven't even talked about the language itself yet. Flexibility. I can program however I like. As a Java guy, I used to think that pointers and goto statements were the devil, but now that I can use them I've found that pointers help make more than a few things easier and legible (if you understand pointers) and I've actually used the goto statement a few times in ways which I would consider legimate. -D's templates-- OMFG!!! (to use the parlance of our times.) The containers library I made for Mango makes extensive use of templates. I can't imagine a containers library without them, and this is only the most basic usage of templates. Compile time regular expressions! Awesome! Generics? Phfff! A child's plaything! There are, however, several things which I prefer about Java: -Application support. Yes, the chicken-and-the-egg thing. Since everybody and their wicked step sister program in Java a lot of things are easier. It'd be nice if emacs had better D support. I don't consider this point a big deal, however. It'll come with time. -Java's package system: Java's protection attributes are consistent and (generally) make sense. (D's are close.) D's modules and packages are OK, but not great. I like that Java makes you put one class per source file (to be public). It makes it A LOT easier to find code. That said, given that not everything in D is a class, this system probably doesn't make sense for D. Perhaps that's another advantage to Java: compared to D it's quite simple. Where there's one or two reasonable ways to do something in Java, there's 15 or 20 reasonable ways in D. I both love and hate this. All in all, I generally recommend D to people who understand C programming but like Java's abstractions. I think it's easier to blow your foot off with D, but that's only because D is a compact fully-automatic shotgun with builtin sniper rifle, whereas Java is a tank. I probably got a bit off topic, but I like D because it's a swiss army knife; it'll do whatever I want it to and really well. ~John Demme
Mar 18 2006
prev sibling next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Walter Bright wrote:
 I'm no expert on Java programming, but I get this question a lot: "What 
 compelling reason does D have that would entice a Java programmer to switch 
 to D?"
 
 I know several of you have come to D from Java, and are expert Java 
 programmers, so you folks' reasons would be very valuable. 
 
 

I came from C#, so I think the same reasons should be valid. D is: Native (Speed!) (This is the primary reason to switch for me) Garbage Collected (although, this is a must) Simple Powerful Modern C is not: Garbage Collected Modern (Preprocessor? You gotta be kidding.) Powerful C++ is not: Garbage Collected (out of the box) Simple Modern Interpreted (Ruby, Perl, etc.) are not: Native D is the best suited language for my purposes. That said: C# is: All about the LIBRARIES D is not: All about the LIBRARIES So, if we could get a standard library as extensive and well written as the .NET libraries, D would be the ideal language in my opinion.
Mar 19 2006
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter Bright wrote:

 I'm no expert on Java programming, but I get this question a lot: "What 
 compelling reason does D have that would entice a Java programmer to switch 
 to D?"

And if anyone wants to elaborate on the "How?" in additon to the "Why?", the page on "Java to D" transition at Wiki4D could need some updating... The link to the page is: http://www.prowiki.org/wiki4d/wiki.cgi?JavaToD It was meant as a complement to the C/C++ pages, that Walter has done: http://www.digitalmars.com/d/ctod.html http://www.digitalmars.com/d/pretod.html http://www.digitalmars.com/d/cpptod.html --anders BTW; There is also a bunch of differences and comparisons listed at: http://www.prowiki.org/wiki4d/wiki.cgi?NotesForProgrammersUsedTo/JavaLanguage
Mar 19 2006
prev sibling next sibling parent reply james <james_member pathlink.com> writes:
I picked up Java because C++ was rich but had to much complexity.
Java was simple and had good support for "programming in the large" with jars
and packages.

But Java is too simple ... and quite dull.  And relies on a fat VM.

D makes the same tradeoffs as Delphi - a fast compiled language with pointers
available if you want them. And modules!

Also there seems to be two major approaches to app development emerging:
Java/c# and a virtual machine
VS
c/c++/D and scripting languages like ECMAScript, Python, Lua.

I think the latter is the way to go. And the fact that DMDScript(ie ECMAScript)
is written in D is great.
Mar 19 2006
parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
james wrote:
 Also there seems to be two major approaches to app development emerging:
 Java/c# and a virtual machine
 VS
 c/c++/D and scripting languages like ECMAScript, Python, Lua.
 
 I think the latter is the way to go. And the fact that DMDScript(ie ECMAScript)
 is written in D is great.

Using VMs is not a solution, it's a terribly perverted workaround. The real problem is that current operating systems are far too monolithic and hang/corrupt the whole machine when one unfortunate process dies/does something bad. Modern micro/exokernel OS:es (see demo.tudos.org), a safe native code low/high-level hybrid-language (D, of course) and some high-level scripts on top of that is a lot more flexible and effective approach. Having a true modular kernel actually means that the VM is kernel-level stuff and it's always on. Huge improvement IMHO. -- Jari-Matti
Mar 19 2006
next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Jari-Matti Mäkelä" <jmjmak utu.fi.invalid> wrote in message 
news:dvk2v1$1rf1$1 digitaldaemon.com...
 Using VMs is not a solution, it's a terribly perverted workaround. The
 real problem is that current operating systems are far too monolithic
 and hang/corrupt the whole machine when one unfortunate process
 dies/does something bad.

I agree. The job of the operating system is to sandbox processes so that when one dies, it is isolated from all the others, which it does a reasonably good job doing (but it could do better). The CPU hardware certainly is set up to support this. You can even run Windows entirely in a virtual machine!
Mar 19 2006
next sibling parent reply james <james_member pathlink.com> writes:
I agree. The job of the operating system is to sandbox processes so that 
when one dies, it is isolated from all the others, which it does a 
reasonably good job doing (but it could do better). The CPU hardware 
certainly is set up to support this. You can even run Windows entirely in a 
virtual machine! 

The real test of a language/technology is "eating your own dogfood". And its interesting to note that MS seem to be pulling back abit from putting the clr very deep into the os. Rather .net classes are just wrappers for c++. A much better approach is D plus DMDScript. Will DMDScript implement the forthcoming ECMAScript v4 spec which hopefully will make it a decent all round scripting language. It seems like scripting languages are converging on a certain set of semantics.
Mar 20 2006
parent reply Sean Kelly <sean f4.ca> writes:
james wrote:
 I agree. The job of the operating system is to sandbox processes so that 
 when one dies, it is isolated from all the others, which it does a 
 reasonably good job doing (but it could do better). The CPU hardware 
 certainly is set up to support this. You can even run Windows entirely in a 
 virtual machine! 

The real test of a language/technology is "eating your own dogfood". And its interesting to note that MS seem to be pulling back abit from putting the clr very deep into the os. Rather .net classes are just wrappers for c++. A much better approach is D plus DMDScript.

According to Herb Sutter, MS is pushing C++/CLI as *the* language to write .NET code in. I suppose its rather unique ability to combine managed and unmanaged code in a single assembly has turned out to be more useful than originally anticipated. So this seems to lend credence to the claim that Windows isn't going to turn into a pure .NET VM any time soon. It's almost too bad, as I'm still hoping for an undeniable reason to drop Windows for an alternative OS ;-) Sean
Mar 20 2006
parent reply Brad Anderson <brad dsource.dot.org> writes:
Sean Kelly wrote:
It's almost too bad, as I'm still hoping for an undeniable
 reason to drop Windows for an alternative OS ;-)

So do it anyway, like I did, and many others. It's the little things that hit you daily - cumulatively, they won't let you go back to Windows. BA
Mar 20 2006
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Brad Anderson wrote:
 Sean Kelly wrote: It's almost too bad, as I'm still hoping for an
 undeniable
 
 reason to drop Windows for an alternative OS ;-)

So do it anyway, like I did, and many others. It's the little things that hit you daily - cumulatively, they won't let you go back to Windows.

Right! Consider, on the one hand, an OS that's from the beginning made just to get everybody's money. And only that. ("We're writing stuff 'for them'!") And on the other hand, an OS made _by_ the users, _for_ the users. And on top of that, based on Unix, which _from_the_start_ was an OS for software development. And for the able user and not "for the masses". Oughtta be a no-brainer. Not to mention licences, payments, and all that crap. Except that, today Linux is not an Alternative OS.
Mar 20 2006
parent reply Sean Kelly <sean f4.ca> writes:
Georg Wrede wrote:
 Brad Anderson wrote:
 Sean Kelly wrote: It's almost too bad, as I'm still hoping for an
 undeniable

 reason to drop Windows for an alternative OS ;-)

So do it anyway, like I did, and many others. It's the little things that hit you daily - cumulatively, they won't let you go back to Windows.

Right! Consider, on the one hand, an OS that's from the beginning made just to get everybody's money. And only that. ("We're writing stuff 'for them'!") And on the other hand, an OS made _by_ the users, _for_ the users. And on top of that, based on Unix, which _from_the_start_ was an OS for software development. And for the able user and not "for the masses".

Doesn't matter if the OS that gets money also has the apps I want to run. In an ideal world, I be using OSX. If I wanted to make a practical choice for idealistic reasons, I'd use a Linux or BSD. As it is, I simply haven't been given enough reason to decide against Windows despite its utility. Though it's worth mentioning that one of the motivating factors in my decision is which OS has the best games ;-) Sean
Mar 20 2006
next sibling parent reply Lucas Goss <lgoss007 gmail.com> writes:
Sean Kelly wrote:
 ...  Though it's worth mentioning that one of the 
 motivating factors in my decision is which OS has the best games ;-)
 

Yeah, that was tough for me. I left Windows for Linux about two years ago, but there are a few benefits. One, I spend more time programming now then on games. Which is good because I need to make some demos or games so I can get hired by (or start) a game company. And two, the windows platform is saturated with games, whereas Mac and Linux could use some help (so it might be easier to break into the market there). My only problem with Linux is that most people expect free software, and there isn't really an easy way to distribute paid software (and packaging software seems like a pain). So hopefully I'll be getting a Mac soon. Only no dmd... doh!
Mar 20 2006
parent reply james <james_member pathlink.com> writes:
In article <dvnse4$1pq8$1 digitaldaemon.com>, Lucas Goss says...
Sean Kelly wrote:
 ...  Though it's worth mentioning that one of the 
 motivating factors in my decision is which OS has the best games ;-)
 

Yeah, that was tough for me. I left Windows for Linux about two years ago, but there are a few benefits. One, I spend more time programming now then on games. Which is good because I need to make some demos or games so I can get hired by (or start) a game company. And two, the windows platform is saturated with games, whereas Mac and Linux could use some help (so it might be easier to break into the market there). My only problem with Linux is that most people expect free software, and there isn't really an easy way to distribute paid software (and packaging software seems like a pain). So hopefully I'll be getting a Mac soon. Only no dmd... doh!

Interesing point. I think the "Free Software" model is flawed. Programmers need to get paid. Apple with OSX have shown that people are willing to pay for a decent integrated experience - at a reasonable price. eg iLife and iWork are $79. A decent biz model would be the os(kernel and desktop) is free with the app suites paid for. With as much as the source code as possible available for viewing to keep the techies happy. Quite franky i find it reassuring that the company that makes things i use has a biz model - and can survive in the longterm.
Mar 21 2006
next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Free Software uses a different business model - I should know, I used to 
be quite involved with it.  The idea is to make money from the service, 
not from the product.

In other words, instead of charging $80 per license and spending huge 
amuonts on piracy prevention and litigation, give it away for free.  If 
your software is worth using, you'll have ten or a hundred times as many 
users.

Then, you charge for support - say, $50 a year.  This seems more fair. 
Other people cannot pirate service.  There's much less legal (but it's 
always still there.)  People keep paying, even if they stay with older 
versions.

Search Google for "Why free is better".  It's down at the fifth result 
now unless you use quotes, but you can read more of the idea there.

So, I have to respectfully disagree.

-[Unknown]


 Interesing point. I think the "Free Software" model is flawed. Programmers need
 to get paid. Apple with OSX have shown that people are willing to pay for a
 decent integrated experience - at a reasonable price. eg iLife and iWork are
 $79. A decent biz model would be the os(kernel and desktop) is free with the
app
 suites paid for. With as much as the source code as possible available for
 viewing to keep the techies happy. Quite franky i find it reassuring that the
 company that makes things i use has a biz model - and can survive in the
 longterm.
 
 

Mar 21 2006
parent reply Lucas Goss <lgoss007 gmail.com> writes:
Unknown W. Brackets wrote:
 Free Software uses a different business model - I should know, I used to 
 be quite involved with it.  The idea is to make money from the service, 
 not from the product.
 
 Interesing point. I think the "Free Software" model is flawed. 


I somewhat agree with both points. I see the value of open source and how it can work as a service, but it doesn't always seem to work this way. Maybe someone can clear this up for me... or maybe I'll just muddy the waters. Does it work in these cases? This one I'm not sure about, but what if I make an innovative new software product and release it as open source. Some business comes along and likes my product, so they have their developers (who are paid) to make enhancements to my original. Then they decide to support clients who use this software (as they bundle the software with their product). And since this company is bigger in the market, most people that need the support go to this company. How do I make money from that? Secondly... games! This is where open source doesn't fit in my opinion. I make a game and release it, who will pay for support. Users will think it's a bad game if it doesn't work or if it's buggy. And gamers won't pay to add things (unless it's maybe like $5), and instead choose to try to do Mod's. So it seems... Business/Education = Linux Home/Entertainment = Mac/Windows Hmm...
Mar 21 2006
next sibling parent james <james_member pathlink.com> writes:
In article <dvpces$oti$1 digitaldaemon.com>, Lucas Goss says...
Unknown W. Brackets wrote:
 Free Software uses a different business model - I should know, I used to 
 be quite involved with it.  The idea is to make money from the service, 
 not from the product.
 
 Interesing point. I think the "Free Software" model is flawed. 


I somewhat agree with both points. I see the value of open source and how it can work as a service, but it doesn't always seem to work this way. Maybe someone can clear this up for me... or maybe I'll just muddy the waters. Does it work in these cases? This one I'm not sure about, but what if I make an innovative new software product and release it as open source. Some business comes along and likes my product, so they have their developers (who are paid) to make enhancements to my original. Then they decide to support clients who use this software (as they bundle the software with their product). And since this company is bigger in the market, most people that need the support go to this company. How do I make money from that? Secondly... games! This is where open source doesn't fit in my opinion. I make a game and release it, who will pay for support. Users will think it's a bad game if it doesn't work or if it's buggy. And gamers won't pay to add things (unless it's maybe like $5), and instead choose to try to do Mod's. So it seems... Business/Education = Linux Home/Entertainment = Mac/Windows Hmm...

Fair points. Suppose a group of developers produced a very slick/functional Office suite which supported WordML and the other XML Office formats under GPL. Without the backing of Sun(OpenOffice) how would the developers get paid. The linux distributions could include it without paying the developers. This mainly applies to slick desktop software. Not enough people may be willing to pay for a software support service. Personally i would be happy with a halfway house. The developers charge a reasonable amount (eg an iLife-ish $79) and release as much source as possible. And individual developers who like the app can submit patches and new functionality etc. And make it free for educational use! A kind of halfway house. For me its more about seeing the source and having confidence in the source than software being free.
Mar 21 2006
prev sibling next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
AFAIK, we were in the process or already a not-for-profit.  Honestly, I 
don't remember anymore.  That helps a lot.

There are two different terms here:
   - open source: this is a philosophical term.  It means source with as 
few restrictions to the end user as possible, except those necessary to 
keep it that way.
   - free software: software which is free.  It may also have less 
restrictions than non-free software.

Technically, the software I developed and supported was not open source. 
  We did not allow people to redistribute the code in full - only 
patches, etc. were allowed.  You were also required to display a 
copyright notice visibly.  But it was free software, and the source code 
was available.

Many different groups and organizations have different business models 
and strategies.  For example, Mozilla gets money from many large 
businesses interested in their software running on mobile devices, and 
similar.

The model I have described works best for good programmers.  If you can 
write something well, with a good concept, and support it well, you will 
prosper.  If someone else comes along and enhances your code, and 
supports it better than you, you've just been pwned.

We had software vendors who rebranded our software and sold it, or 
support for it.  They paid us for this, of course.  At first they didn't 
expect to, and so we told them we had a lawyer.  Situation solved. 
Seriously, if you do your job well, and you license it correctly, this 
won't be a problem.

I don't go quite as far as some with the philosophy of open source.  I 
believe it is great, amazing, and only logical for the code to be 
available.  For others to be able to compile it, patch it, change it.  I 
do not believe it is fair for them to provide it under their own name. 
I do not believe it is always fair for them to be able to redistribute 
it, even (although for smaller things it is.)

Free software scales a lot faster, in my experience.  You get people who 
care.  Who will throw tomatoes at this other company.  It's PR without a 
department for it.

For games, I'll agree with you.  Those usually just don't work.  Open 
source and free software just don't apply to everything.  But it's more 
about plot.  However, think of this:

You provide a framework with which people can make games (except, let's 
assume you actually make it so the games can be unique and of some 
quality, not something useless.)  This isn't far from what big game 
companies do, by the way.  Then, you open source/free this.  You provide 
support for it, services again.

For plot, for other things... open source is strange.  It's all about 
the code.

I didn't mention a lot of benefits it gives you.  Bugs, evangelism/free 
marketing department, peer support (which isn't great compared to yours, 
but takes slack off your back), third party plug-ins/extensions, reach, etc.

The only problem is, if you suck as a programmer, you're gonna have 
problems.  People can see it, people can see your glaring security 
holes, people will find your backdoors... etc.  But although I don't 
know much of you, considering you're interested in D I'll assume this 
won't be a problem.

All that said (yes, I know I'm long-winded), the computer my mouse is 
attached to almost always runs Windows.

However, all my servers are Linux or Unix-based (RHEL, FreeBSD, CentOS, 
etc.) and some consider my company to be in the "entertainment industry" 
(since we do websites for Fox, etc.)  But I suppose that's still business.

-[Unknown]


 Unknown W. Brackets wrote:
 Free Software uses a different business model - I should know, I used 
 to be quite involved with it.  The idea is to make money from the 
 service, not from the product.

 Interesing point. I think the "Free Software" model is flawed.


I somewhat agree with both points. I see the value of open source and how it can work as a service, but it doesn't always seem to work this way. Maybe someone can clear this up for me... or maybe I'll just muddy the waters. Does it work in these cases? This one I'm not sure about, but what if I make an innovative new software product and release it as open source. Some business comes along and likes my product, so they have their developers (who are paid) to make enhancements to my original. Then they decide to support clients who use this software (as they bundle the software with their product). And since this company is bigger in the market, most people that need the support go to this company. How do I make money from that? Secondly... games! This is where open source doesn't fit in my opinion. I make a game and release it, who will pay for support. Users will think it's a bad game if it doesn't work or if it's buggy. And gamers won't pay to add things (unless it's maybe like $5), and instead choose to try to do Mod's. So it seems... Business/Education = Linux Home/Entertainment = Mac/Windows Hmm...

Mar 21 2006
parent reply Lucas Goss <lgoss007 gmail.com> writes:
Unknown W. Brackets wrote:
 You provide a framework with which people can make games (except, let's 
 assume you actually make it so the games can be unique and of some 
 quality, not something useless.)  This isn't far from what big game 
 companies do, by the way.  Then, you open source/free this.  You provide 
 support for it, services again.

Yeah, this is how I'm thinking of doing it (games that is). I'm all for open source for the framework as it will allow others making games to contribute useful additions and fixes as well. I even think it would be nice to give away the source for the game for those that buy it. But obviously this can be a problem.
 The only problem is, if you suck as a programmer, you're gonna have 
 problems.

Hmm, what are you trying to say about my coding skills? :) Well I learned Pascal in high school and college and taught myself C, C++, and a whole bunch of other languages. I guess I'll just have to work twice as hard so that I don't make a fool of myself. I just wish I could retain all of the information I've read in books and websites...
Mar 22 2006
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Well, what you can do is wait for the game to get old, and then release 
the source.  You won't lose much doing that, but others will gain from 
the source and that will feed back to you.

I'm not saying anything about your coding skills!  I just mean it as a 
warning: some people these days are not good coders, and they get 
completely shown up when they try to do open source.  A lot of 
closed-source programmers could never make it in open source.

But, then, there's always people who will use crappy code, because they 
don't know or don't care.  But it causes problems.

But as I said, as long as you know what you're getting into, it's cool. 
  Forum software, which I did a lot of, is rough because security and 
functionality constantly fight each other.  XSS is really a hard thing 
to master.  Games don't have to worry about these things as much.

Hopefully my comments are of some help to you :).

Thanks,
-[Unknown]


 Unknown W. Brackets wrote:
 You provide a framework with which people can make games (except, 
 let's assume you actually make it so the games can be unique and of 
 some quality, not something useless.)  This isn't far from what big 
 game companies do, by the way.  Then, you open source/free this.  You 
 provide support for it, services again.

Yeah, this is how I'm thinking of doing it (games that is). I'm all for open source for the framework as it will allow others making games to contribute useful additions and fixes as well. I even think it would be nice to give away the source for the game for those that buy it. But obviously this can be a problem.
 The only problem is, if you suck as a programmer, you're gonna have 
 problems.

Hmm, what are you trying to say about my coding skills? :) Well I learned Pascal in high school and college and taught myself C, C++, and a whole bunch of other languages. I guess I'll just have to work twice as hard so that I don't make a fool of myself. I just wish I could retain all of the information I've read in books and websites...

Mar 22 2006
parent Lucas Goss <lgoss007 gmail.com> writes:
Unknown W. Brackets wrote:
 Well, what you can do is wait for the game to get old, and then release 
 the source.  You won't lose much doing that, but others will gain from 
 the source and that will feed back to you.

Ah yes, that would be best most likely.
 Hopefully my comments are of some help to you :).

Yes, thanks.
Mar 23 2006
prev sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Lucas Goss wrote:
 Secondly... games! This is where open source doesn't fit in my opinion. 
 I make a game and release it, who will pay for support. Users will think 
 it's a bad game if it doesn't work or if it's buggy. And gamers won't 
 pay to add things (unless it's maybe like $5), and instead choose to try 
 to do Mod's.
 

Do you know what Valve did with their games? (Half-Life/Half-Life2) They released the source to the game engine (*not* the graphics engine, only the game logic, which by the way, is huge), and allowed hobyists to modify it and distribute their modifications (aka Mods). That's how Counter-Strike was born. Yeah, it's not really open source, but it's close. It seemed to work great for Valve!
Mar 22 2006
parent Lucas Goss <lgoss007 gmail.com> writes:
Hasan Aljudy wrote:
 Do you know what Valve did with their games? (Half-Life/Half-Life2)
 
 They released the source to the game engine (*not* the graphics engine, 
 only the game logic, which by the way, is huge), and allowed hobyists to 
 modify it and distribute their modifications (aka Mods). That's how 
 Counter-Strike was born.

Ah yes. I knew about the Half-Life mod stuff, but never actually used it myself. But I believe it is similar to Tribes, now the Torque engine made by GarageGames which I've used a little. It's basically an engine done in C/C++ with many of the functions available through a scripting language. The biggest problem with those engines though is that they are very geared towards FPS games/style. But yes, that could be another way to do it.
Mar 23 2006
prev sibling parent =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:
 Interesing point. I think the "Free Software" model is flawed. Programmers need
 to get paid. Apple with OSX have shown that people are willing to pay for a
 decent integrated experience - at a reasonable price. eg iLife and iWork are
 $79. A decent biz model would be the os(kernel and desktop) is free with the
app
 suites paid for. With as much as the source code as possible available for
 viewing to keep the techies happy. Quite franky i find it reassuring that the
 company that makes things i use has a biz model - and can survive in the
 longterm.

Well, there is many business models for free software which one do you think is flawed ?? 1) Free software don't have to be a business it can just be a hobby like tennis, gardening or chess. 2) Make a open source library and make it dual licence Where one licence is GPL and the other is commercial. So, that every one writing a close source app. using the library should buy a commercial license or release there app. open source. 3) Make a non-profit organisation. Your develop open source apps. and let clients donate money for there favorite extension. You get paid and they get there open source extension and a tax writeof. 4) Get money from real estate investments write open source software for fun and education. That is just some of the ideas that comes to mind.
Mar 21 2006
prev sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Sean Kelly wrote:
 Georg Wrede wrote:
 
 Brad Anderson wrote:
 
 Sean Kelly wrote: It's almost too bad, as I'm still hoping for an
  undeniable
 
 reason to drop Windows for an alternative OS ;-)

So do it anyway, like I did, and many others. It's the little things that hit you daily - cumulatively, they won't let you go back to Windows.

Right! Consider, on the one hand, an OS that's from the beginning made just to get everybody's money. And only that. ("We're writing stuff 'for them'!") And on the other hand, an OS made _by_ the users, _for_ the users. And on top of that, based on Unix, which _from_the_start_ was an OS for software development. And for the able user and not "for the masses".

Doesn't matter if the OS that gets money also has the apps I want to run. In an ideal world, I be using OSX. If I wanted to make a practical choice for idealistic reasons, I'd use a Linux or BSD. As it is, I simply haven't been given enough reason to decide against Windows despite its utility. Though it's worth mentioning that one of the motivating factors in my decision is which OS has the best games ;-)

Well, I have to admit I still use Windows too. All my Word, Excel, and time management stuff is on Windows, and most of my surfing and e-mail. For such, W2k just feels smoother. On Linux I do programming, CS research, remote server management, web site construction, and other "serious" or "demanding" stuff. Even programs that are aimed for Windows, I develop on Linux, and once it's done except for the GUI part, I switch to Windows. --- As for getting money out of software, Windows is it. The [computer]world is increasingly becoming divided between the haves and have-nots, where the former are computer savvy guys with Linux (and usually Windows) knowledge, and the latter are "Windows users" who are used to paying for stuff. Windows is increasingly becoming like a DVD player: whatever you put in it you pay for (unless it's ripped or bootleg, of course). And, come to think of it, that's exactly what Windows was originally invented for: just a vehicle to create demand for stuff that you pay for. It never even was a secret. X-box does it more overtly, but the idea still is the same with Windows.
Mar 21 2006
prev sibling parent reply David Medlock <noone nowhere.com> writes:
Walter Bright wrote:

 "Jari-Matti Mäkelä" <jmjmak utu.fi.invalid> wrote in message 
 news:dvk2v1$1rf1$1 digitaldaemon.com...
 
Using VMs is not a solution, it's a terribly perverted workaround. The
real problem is that current operating systems are far too monolithic
and hang/corrupt the whole machine when one unfortunate process
dies/does something bad.

I agree. The job of the operating system is to sandbox processes so that when one dies, it is isolated from all the others, which it does a reasonably good job doing (but it could do better). The CPU hardware certainly is set up to support this. You can even run Windows entirely in a virtual machine!

Which do you think could harness that power better? A VM or a compiled language? (Note that not every VM needs to be as complicated as the JVM). Obviously the choice of language itself matters a great deal, but the VM approach certainly has a step up in this reguard. This is not to impugn D, just to point out the larger picture... -DavidM
Mar 20 2006
parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
David Medlock wrote:
 Walter Bright wrote:
 
 "Jari-Matti Mäkelä" <jmjmak utu.fi.invalid> wrote in message
 news:dvk2v1$1rf1$1 digitaldaemon.com...

 Using VMs is not a solution, it's a terribly perverted workaround. The
 real problem is that current operating systems are far too monolithic
 and hang/corrupt the whole machine when one unfortunate process
 dies/does something bad.

I agree. The job of the operating system is to sandbox processes so that when one dies, it is isolated from all the others, which it does a reasonably good job doing (but it could do better). The CPU hardware certainly is set up to support this. You can even run Windows entirely in a virtual machine!

Which do you think could harness that power better? A VM or a compiled language? (Note that not every VM needs to be as complicated as the JVM). Obviously the choice of language itself matters a great deal, but the VM approach certainly has a step up in this reguard. This is not to impugn D, just to point out the larger picture...

We can create this next generation VM for CELL-processors using D. :)
Mar 20 2006
prev sibling parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jari-Matti Mäkelä schrieb am 2006-03-19:
 james wrote:
 Also there seems to be two major approaches to app development emerging:
 Java/c# and a virtual machine
 VS
 c/c++/D and scripting languages like ECMAScript, Python, Lua.
 
 I think the latter is the way to go. And the fact that DMDScript(ie ECMAScript)
 is written in D is great.

Using VMs is not a solution, it's a terribly perverted workaround. The real problem is that current operating systems are far too monolithic and hang/corrupt the whole machine when one unfortunate process dies/does something bad. Modern micro/exokernel OS:es (see demo.tudos.org), a safe native code low/high-level hybrid-language (D, of course) and some high-level scripts on top of that is a lot more flexible and effective approach. Having a true modular kernel actually means that the VM is kernel-level stuff and it's always on. Huge improvement IMHO.

One huge advantage of VMs is their design: * lot's of prior experiences with all sorts of architectures and libs * a clean sheet, thus no cludges for supporting applications from the parent architecture * a strong seperation between normal applications and the used hardware(including the CPU) -> "smart" phone applications * most important: the potential to design according to todays requirements and available technology instead of those from the 70th and 80th (the C99 standart only specifies how to access files but not how to list directories?!) There are domains where VMs make sence, but you are right a secure modular kernel could be used in most places where Java and .NET are currently used. One nice point about the Java and .NET runtimes are the large amount of OS/architecture agnostic tools/objects/functions. Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFEHcwa3w+/yD4P9tIRAlhxAJ9zw2rifCqh2WWC5VelR9Dnvc8A+wCZAU7L BnRhnVE/qhph4iT8YQxYuYY= =QF5v -----END PGP SIGNATURE-----
Mar 19 2006
parent =?UTF-8?B?SmFyaS1NYXR0aSBNw6RrZWzDpA==?= <jmjmak utu.fi.invalid> writes:
Thomas Kuehne wrote:
 One huge advantage of VMs is their design:
 * lot's of prior experiences with all sorts of architectures and
 libs

Well, this might only be a matter of time.
 
 * a clean sheet, thus no cludges for supporting applications from
 the parent architecture
 

Actually D is doing very well here too. A normal end-user application coder doesn't need to care about all the low level stuff.
 * a strong seperation between normal applications and the used
 hardware(including the CPU) -> "smart" phone applications

True.
 * most important: the potential to design according to todays
 requirements and available technology instead of those from
 the 70th and 80th
 (the C99 standart only specifies how to access files but not
 how to list directories?!)

D is able to fix most of these issues without any VMs. Even though you have a decent VM today, tomorrow someone will invent a new thingie that suddenly everybody needs. Updating an existing VM/language isn't that painless. Java has a huge load of deprecated junk for backwards compatibility.
 
 There are domains where VMs make sence, but you are right
 a secure modular kernel could be used in most places where
 Java and .NET are currently used. One nice point about
 the Java and .NET runtimes are the large amount of
 OS/architecture agnostic tools/objects/functions.
 

Certainly there are domains where a VM'ed language suits better than bare metal access alternative but unfortunately this "managed code" is often used excessively. If I recall correctly, some vendors even use C# in basic end-user GUI-based configurators for device drivers. These programs usually require you to reboot, when you change something. I cannot see, why a VM written in C + a wrapper library using C/C++ GUI-bindings + a byte code program performs any better than a modular kernel + script interpreter and GUI libraries written in D + a high level configurator script. The latter one starts up much faster, eats only a small fraction of memory compared to the bloaty VM-version and is actually more light-weight in terms of LOC. -- Jari-Matti
Mar 19 2006
prev sibling next sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Walter Bright wrote:
 I'm no expert on Java programming, but I get this question a lot: "What 
 compelling reason does D have that would entice a Java programmer to switch 
 to D?"
 
 I know several of you have come to D from Java, and are expert Java 
 programmers, so you folks' reasons would be very valuable. 
 
 

D: + templates + contracts + delegates + raw power + no VM + it's practical&simple + community <-> language developer -interaction Java: + a lot of API/GUI/IDE:s + does not segfault + smaller amount of compiler bugs + very easy to use - very easy to use (makes libraries too complex) -- Jari-Matti
Mar 19 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jari-Matti Mäkelä" <jmjmak utu.fi.invalid> wrote in message 
news:dvk3en$1sqc$1 digitaldaemon.com...
 + does not segfault

Debug build null reference checks. That's all I'm saying.
Mar 19 2006
prev sibling next sibling parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <dvhohr$asa$1 digitaldaemon.com>, Walter Bright says...
I'm no expert on Java programming, but I get this question a lot: "What 
compelling reason does D have that would entice a Java programmer to switch 
to D?"

Very few, I think. I've thought about it, and in the end I think Java has some good points that can't be beaten so esily: - Compile once and run everywhere. I write, compile and test my program with my Windows PC, then download it in a Linux-based CN, a VxWorks-based terminal and a WinCE one (last two with an ARM processor). The application works the same on the 4 platform, the user doesn't notice. You only have to care for a few things, like case sensitiveness for file names, or not using the latest whistles & bells not present in that particularily old VM. - Swing. Once you get used to it, you think you can't work without it. It's extremely flexible, making possible to write a 5-lines GUI for a quick hack, or a big application with custom appearence. And it can scale down to little targets, as a StrongArm 133MHz with 32 MB of RAM, with some effort. - The library. You can make almost everything with the base standard library. It's big, but it works. Here in Italy we say: "non capita, ma se capita..." ("it won't happen, but if it happens..."), so from a programmer's point of view, more is better. Java is slower, but who cares? My customers don't know I use Java, they don't notice the 30 ms delay in menu showing. CPU intensive parts are JIT compiled, so the overall overhead of the VM results in an impercettible delay in GUI responsiveness. My GUIs are still faster than their users. Something that D can do and Java don't is system programming. Pointers, assembler, the full C api, and so on are something the system programmer would keep handy. What D has, that Java don't, is a better language. More complex, but more powerful. Something I miss in Java: - the version{} construct - properties - switch-case with strings - RAII - array slices - the 'ditto' keyword in javadoc - true typedefs (if only they worked in D...) - I think in the long period I will use contracts - maybe I'll use opApply() with foreach D templates are better than Java generics (and than C++ templates), but I don't write Java generics everyday (nor C++ templates), I mostly use them. Their use is similar, so I don't think it will add something to D. Ciao --- http://www.mariottini.net/roberto/
Mar 20 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Roberto Mariottini" <Roberto_member pathlink.com> wrote in message 
news:dvltsr$2771$1 digitaldaemon.com...
 - Compile once and run everywhere. I write, compile and test my program 
 with my
 Windows PC, then download it in a Linux-based CN, a VxWorks-based terminal 
 and a
 WinCE one (last two with an ARM processor). The application works the same 
 on
 the 4 platform, the user doesn't notice. You only have to care for a few 
 things,
 like case sensitiveness for file names, or not using the latest whistles & 
 bells
 not present in that particularily old VM.

This portability isn't the result of a VM, it's the result of cleaning up all the undefined and implementation defined behaviors in the language. D is about halfway in between C++ and Java in this regard. It could be better.
Mar 20 2006
parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <dvn3fd$q65$1 digitaldaemon.com>, Walter Bright says...

This portability isn't the result of a VM, it's the result of cleaning up 
all the undefined and implementation defined behaviors in the language.

I still think the VM has its own part. Think to having backends for IA32, IA64, AMD64, PowerPC, SPARC, ARM and so on. They will have their bugs and special cases acording to the underlying architecture. The "compile once and run everywhere" thing for Java is literally true.
D is about halfway in between C++ and Java in this regard. It could be 
better. 

Sure, this will make D highly portable. But I think the VM will win anyway. Because I am lazy. I don't want to buy/download, install and test 4 different (cross-)compilers for my 4 systems. And I don't want to compile my program 4 times. If one compiler can do it, with acceptable performance, I will use the one-compiler solution. I think there are three categories: - Scripting languages, for quick tricks (Python, Ruby) - VM-based languages, for maximum portability (Java, C#) - CPU-compiled languages, for maximum efficency (D, C++, C) And there is enough space for all. Ciao --- http://www.mariottini.net/roberto/
Mar 21 2006
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Roberto Mariottini wrote:

 I think there are three categories:
 
 - Scripting languages, for quick tricks (Python, Ruby)
 - VM-based languages, for maximum portability (Java, C#)
 - CPU-compiled languages, for maximum efficency (D, C++, C)
 
 And there is enough space for all.

I agree with you, although I would probably group them like: - Scripting: Shell, Perl, PHP, Python, Ruby - Extension: Lua, ECMAScript, Tcl, Guile - Object-oriented: Java, C#, Smalltalk - Hybrid: D, C++, Objective-C - Lowlevel: C, Assembler And that leaves out a whole bunch of other languages, still. --anders PS. http://en.wikipedia.org/wiki/List_of_programming_languages
Mar 21 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Roberto Mariottini" <Roberto_member pathlink.com> wrote in message 
news:dvof2n$2i65$1 digitaldaemon.com...
This portability isn't the result of a VM, it's the result of cleaning up
all the undefined and implementation defined behaviors in the language.

IA64, AMD64, PowerPC, SPARC, ARM and so on. They will have their bugs and special cases acording to the underlying architecture.

So do the VMs. Write once, debug everywhere. <g>
 Sure, this will make D highly portable.
 But I think the VM will win anyway. Because I am lazy.
 I don't want to buy/download, install and test 4 different 
 (cross-)compilers for
 my 4 systems. And I don't want to compile my program 4 times.
 If one compiler can do it, with acceptable performance, I will use the
 one-compiler solution.

With VMs, you have a lot more platforms to test, because you cannot control which version of which VM your customers will be using. Back in the early days, Microsoft shipped a linker with MS-DOS. Great, I didn't have to write a linker for my compiler, just use the MS one everyone had. Unfortunately, MS shipped version after version of that linker. Some worked, some didn't, and soon the number of different versions grew into the scores. I had disks full of different versions, and started keeping logs of which worked and which didn't. Even worse, when customer X had a non-working linker, I couldn't ship him one that worked, as I had no license to. It was so bad it became clear that I had to come up with our own linker. Essentially, I learned that if you are supporting an application, and you need to be in control of your support costs, you have to be able to control the generation of the executable. That's impossible with a VM. But also, really, what is the difference between relying on a JIT compiler for each platform, and a native compiler for each platform? Why should the JIT compiler be more reliable? There's no technical reason it should be. If the language has portable semantics, and the compilers implement those semantics correctly, it should be write once, run everywhere. There's no technical reason a VM is required to make that happen.
Mar 21 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 
 Essentially, I learned that if you are supporting an application, and you 
 need to be in control of your support costs, you have to be able to control 
 the generation of the executable. That's impossible with a VM.

Very interesting point.
 But also, really, what is the difference between relying on a JIT compiler 
 for each platform, and a native compiler for each platform? Why should the 
 JIT compiler be more reliable? There's no technical reason it should be. If 
 the language has portable semantics, and the compilers implement those 
 semantics correctly, it should be write once, run everywhere. There's no 
 technical reason a VM is required to make that happen. 

There is no difference :-) The only reason a VM was attractive is because it allowed applets to run in a sandbox. And since Java applets failed as a technology, there's no real reason to consider default VM support as an advantage. Others are also quick to point out that there's no reason C++ or D couldn't run on a VM as well, as .NET has proven. Sean
Mar 21 2006
prev sibling next sibling parent Def <Def_member pathlink.com> writes:
In article <dvpfa8$sq1$1 digitaldaemon.com>, Walter Bright says...

But also, really, what is the difference between relying on a JIT compiler 
for each platform, and a native compiler for each platform? Why should the 
JIT compiler be more reliable? There's no technical reason it should be. If 
the language has portable semantics, and the compilers implement those 
semantics correctly, it should be write once, run everywhere. There's no 
technical reason a VM is required to make that happen. 

For me the biggest difference is that a VM makes "sort of" cross-compiling possible. As a user of Win32 & beginning/experimenting with Linux on an x86 machine, I simply can't afford to buy a Mac just to support MacOS. Still, I can't test a Java app on a Mac - I can only hope that it works reasonably well. But GDC for Mac won't help me at all unless I give the sources to someone with a Mac. Of course, this is not D's fault. One could blame Apple for not releasing their libraries free of charge or at low cost for cross-compiling from non-Mac machines. It's a pity there's no Mac equivalent to MinGW available. Anyway, with Intel Mac's I might be able to boot Win/Mac/Linux in the future. :-) Def
Mar 21 2006
prev sibling parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <dvpfa8$sq1$1 digitaldaemon.com>, Walter Bright says...

With VMs, you have a lot more platforms to test, because you cannot control 
which version of which VM your customers will be using.

In theory, and in the general case, yes. In practice I never had a JVM bug reported in 10 years. In any JVM. In the end the bug was in my code. Also, in my particular case I can control the VM, because it's me that put the VM in the machine I sell to customers.
Back in the early days, Microsoft shipped a linker with MS-DOS. Great, I 
didn't have to write a linker for my compiler, just use the MS one everyone 
had. Unfortunately, MS shipped version after version of that linker. Some 
worked, some didn't, and soon the number of different versions grew into the 
scores. I had disks full of different versions, and started keeping logs of 
which worked and which didn't. Even worse, when customer X had a non-working 
linker, I couldn't ship him one that worked, as I had no license to. It was 
so bad it became clear that I had to come up with our own linker.

Essentially, I learned that if you are supporting an application, and you 
need to be in control of your support costs, you have to be able to control 
the generation of the executable. That's impossible with a VM.

This is something I was afraid of, at the beginnin of my work with Java. In the end, after 10 years, I can say it never applied to Java. I don't exclude that in the Java VM design there's something that ease the verification of the VM correctness, giving always high quality VMs. And I don't use only Sun's JVM. The fact that you have to pass a lot of test by Sun before you can use the word "Java" for your VM maybe means something.
But also, really, what is the difference between relying on a JIT compiler 
for each platform, and a native compiler for each platform? Why should the 
JIT compiler be more reliable? There's no technical reason it should be.

Maybe there's one: the JIT compiler task is much like the work of a macro assembler than that of a HLL compiler.
If 
the language has portable semantics, and the compilers implement those 
semantics correctly, it should be write once, run everywhere. There's no 
technical reason a VM is required to make that happen. 

In theory you are right. In practice a VM makes the task more easy and lead to more robust results. Prove me wrong with D ;-). Ciao --- http://www.mariottini.net/roberto/
Mar 22 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Roberto Mariottini" <Roberto_member pathlink.com> wrote in message 
news:dvr4c1$4de$1 digitaldaemon.com...
 This is something I was afraid of, at the beginnin of my work with Java. 
 In the
 end, after 10 years, I can say it never applied to Java.
 I don't exclude that in the Java VM design there's something that ease the
 verification of the VM correctness, giving always high quality VMs. And I 
 don't
 use only Sun's JVM. The fact that you have to pass a lot of test by Sun 
 before
 you can use the word "Java" for your VM maybe means something.

Sun has worked hard at solving this problem by providing a comprehensive test suite. I think they've been reasonably successful at doing that, although I regularly read that people still have to tweak for various VM's. But once again, this is *not* an inherent charactistic of VM's. If, for example, one had a comprehensive compiler test suite for various platforms, and one prevented calling any that didn't pass it a "D compiler", one could do just as well.
Mar 22 2006
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:

 If, for example, one had a comprehensive compiler test suite for
 various platforms, and one prevented calling any that didn't pass it
 a "D compiler", one could do just as well.

This might not be a bad idea for D.
Mar 23 2006
parent Kyle Furlong <kylefurlong gmail.com> writes:
Georg Wrede wrote:
 Walter Bright wrote:
 
 If, for example, one had a comprehensive compiler test suite for
 various platforms, and one prevented calling any that didn't pass it
 a "D compiler", one could do just as well.

This might not be a bad idea for D.

Ever heard of dstress? ;-)
Mar 23 2006
prev sibling next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:
 I'm no expert on Java programming, but I get this question a lot:
 "What compelling reason does D have that would entice a Java
 programmer to switch to D?"
 
 I know several of you have come to D from Java, and are expert Java 
 programmers, so you folks' reasons would be very valuable.

(I may write another post in this thread later. Right now I'm thinking of Java vs D in *academic* surroundings.) "Some" years ago, we had to substitute Java for Pascal as the First Language in my university. It was not like anyone had any solid criticism against Pascal (especially when we were teaching Borland Pascal, which is 1. the de facto standard, 2. pretty usable, both as GUI stuff and CL stuff). It was because the students were about to start a riot against "a passé language forced upon them, on account of the faculty being old moldheads". Who cares if Pascal was actually _invented_ to be the first language. Now, as a teacher of IT, I always found it hard to stand at the front on the first day, and having to answer questions like: "Ok, now it says 'public static void main... on the chalkboard. Would you, Sir, mind telling us what that means?' How am I going to explain that to folks new to programming, on their first day? ---- Some reasons for skipping Java for an "unknown, obscure language that nobody has ever heard of": - this language you can use *even* after the semester, for your own stuff and needs - it makes standalone programs, so you can do something and copy that to your friends -- and they don't have to install all kinds of VMs or whatever - the main *concepts* in programming look the same in D, Java, C, and some other important languages. Therefore, even if you end up programming in any of those others, stuff *will* look familiar to you - compared to [most of the "competing" languages] D has a straightforward way of representing the majority of both traditional and the more modern concepts of programming -- thus letting the teacher _and_ the students concentrate on the issue at hand, as opposed to learning language specific quirks or idioms - the VM that Java resides upon, is just another burden for the teacher. Especially the smarter students have a hard time visualising or conceptualising what's really going on - programming concepts (taken as a whole) manifest themselves more clearly and more straightforward to the students, than e.g. in Java. (Note, here some might argue that C is superior, but nobody in their right mind would teach C as a First Language, and we haven't eve started to talk about C++) - if you take the gamut of Programming Abstraction Levels that Java spans and compare it to that of D, you'll find that D now spans the distance logarithmically from C to almost Lisp. (!!!) (( Where Java is half-way, and *stays* there.)) - blinding compilation speed combined with aborting before 10 miles of error messages, does really make a difference to student comprehension, and motivation - copyable and runnable results of compilation, that you can give to your friends or antagonists in the class - while knowing several programming languages right from the first year is considered a forte, some teachers forget that *one* language that the students *feel* their own [like a mother tongue], is rather important if one is to entertain a life long understanding, comfortability and handiness with programming as such - in CS, a language has to be useful both in _to_the_metal_ classes as well as a vehicle for teaching the more abstract concepts. IMHO, D serves both of these needs excellently -- additionally, with no gap in between - some CS classes contain Assembler programming. I have yet to see anything that even comes close to the ease (for the teacher) with which you can let the students concentrate on the assignments at hand, without struggling with all kinds of [to that class irrelevant] obligatories and inconsistencies [with initial setup of the registers, return values, stack handling, etc.] Be it with Windows or Linux. === I've said before, that I consider D as an almost perfect First Language. This should *never* be taken as belittling D, or its capabilities! (There's a law in several European countries that says Driving School cars have to have stick shift. But none of them require that the car is a WW2 Jeep with a non-synchronized gear box. Or separate pedals for left and right brakes. (I've driven a Real Farmer Tractor, it had separate brake pedals for left and right! You don't wanna try that at home when you're on reverse gear.) Just as nobody in their right mind would push C++ as the first language for *anybody*. === (Walter,) anytime somebody doubts D as a superior Academic Language, have them talk with me. Another thing, if we can get D popular in the academia, both research and teaching will gain a lot. And as an aside, 5 years after that, who'll ever want to do programming in any other language???
Mar 20 2006
next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
These are a lot of very interesting observations that never occurred to me.

Are you teaching D as a first language, or just thinking about it? 
Mar 20 2006
next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Walter Bright wrote:
 These are a lot of very interesting observations that never occurred to me.
 
 Are you teaching D as a first language, or just thinking about it? 
 
 

I think D would make a perfect first language. All we need is for the compiler to silently insert "import std.stdio;" And .. a book, of course!
Mar 20 2006
next sibling parent reply tjohnson [at] prtsoftware . com <tjohnson_member pathlink.com> writes:
In article <dvo182$1vl4$1 digitaldaemon.com>, Hasan Aljudy says...
Walter Bright wrote:
 These are a lot of very interesting observations that never occurred to me.
 
 Are you teaching D as a first language, or just thinking about it? 
 
 

I think D would make a perfect first language. All we need is for the compiler to silently insert "import std.stdio;" And .. a book, of course!

I bet most people would think that would be ok as long as there was a compiler switch to disable it. I too think that D would be a great first language. I learned Pascal when getting my CIS degree and loved it. How in the world do you teach pointers and trees and other such structures using Java?. My nine year old son is learning VB, but maybe I should switch him over to D. We are writing a puzzle game together and it looks like either DWT or DFL are far enough along to do the GUI parts. In a couple of years he will probably be out programming me. Kids suck up information like a sponge. Oh, yea. I too like the :D symbol....especially in reversed text. Tom J
Mar 20 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
tjohnson [at] prtsoftware . com wrote:

 I too think that D would be a great first language.  I learned Pascal when
 getting my CIS degree and loved it.  How in the world do you teach pointers and
 trees and other such structures using Java?.  

All objects are pointers in Java, so I don't think that would be hard... --anders
Mar 21 2006
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Hasan Aljudy wrote:

 All we need is for the compiler to silently insert "import std.stdio;"

No, we really really don't want that. We already have it silently inserting parts of std.c.stdio and it sucks.
 And .. a book, of course! 

That would be very nice to have, yes. Especially if there was one that was under an open publication license ? --anders
Mar 21 2006
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:
 These are a lot of very interesting observations that never occurred
 to me.
 
 Are you teaching D as a first language, or just thinking about it?

In 2000 I was _dragged_ out of the university, to do Java development. When I left, I told everyone on the department that I'll be back unless I get rich quick. Now I'm [more than] toying with the idea that I'll go back to teaching, and get my Ph.D. on the side. Additionally I am collecting material and doing research on "Introduction to Programming, Using D". Vol 1 would be a general introduction to stuff that every first year CS student should know, and Vol 2 would contain advanced stuff for the second and third year. (I'm still catching my breath after the divorce, but it's downright likely that's where I'll be once I get half a grip.)
Mar 21 2006
parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Georg Wrede wrote:
 Walter Bright wrote:
 These are a lot of very interesting observations that never occurred
 to me.

 Are you teaching D as a first language, or just thinking about it?

In 2000 I was _dragged_ out of the university, to do Java development. When I left, I told everyone on the department that I'll be back unless I get rich quick. Now I'm [more than] toying with the idea that I'll go back to teaching, and get my Ph.D. on the side. Additionally I am collecting material and doing research on "Introduction to Programming, Using D". Vol 1 would be a general introduction to stuff that every first year CS student should know, and Vol 2 would contain advanced stuff for the second and third year. (I'm still catching my breath after the divorce, but it's downright likely that's where I'll be once I get half a grip.)

My university teaches Scheme as the first language, modeled after the MIT curricula, where the course is based on SICP (the purple book). Seems a good idea to me, as Scheme is much more simple than Java and D, and so the teaching can focus on the general programming concepts. Frankly I really don't see D as much better/simpler than Java for the purposes of a first language. -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 23 2006
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Bruno Medeiros wrote:

 My university teaches Scheme as the first language, modeled after the 
 MIT curricula, where the course is based on SICP (the purple book). 
 Seems a good idea to me, as Scheme is much more simple than Java and D, 
 and so the teaching can focus on the general programming concepts.

I went through a class using SICP. The teacher was as new to the stuff as we were. At the time, the local bookstores refused to carry the book just for us, and the WWW or Amazon didn't exist. (Later he got fired for this, since SICP+Scheme is just a bit too steep to teach off-hand. (That is, without a profound knowledge of it yourself.) At the end of the year, nobody actually got credits!) It was tough, but this was so long ago that one had to lie, cheat and steal to even get the interpreter. Not all did. (And yes, I do know that of all languages, Lisp is the one that can actually be taught without access to computers. But as students, at the time, we didn't understand this!) Anyhow, I still consider this as one of the most eye-opening CS classes I've ever taken. And it has made a life long difference in how I program, how I think about programming, and how I evaluate programming languages and paradigms.
 Frankly I really don't see D as much better/simpler than Java for the 
 purposes of a first language.

This might sound offending, condescending, patronising and whatever, but: Learning to program (in school/university, vs. on your own) does contain issues one never notices. The choice of language, the "scene" at the time, the predicted future of the students (and of course what they never tell you: access to knowledgeable teachers in the various choices), all do play a role. The faculty (hopefully) makes a choice genuinely based _only_ on their combined experience which (in the best case) might today be like n * 30 years, n being the number of professors participating in the decision. There is no way for the individual student to match this combined knowledge, and its implicit implications. Still, if the faculty is not able to explain the decision adequately, students may feel that "it's a dumb choice". But then again, that's _exactly_ why universities do exist. They're there to tell you what to learn. Anybody who "thinks he knows better" might be better off studying on their own. (Like, if you really _do_ know better, then do it, honestly(!), but if you only _believe_ you know better, then your future isn't all that rosy.) The absolute top universities are in a position to not have to explain their choices. (What they do, actually _defines_ what is best! But then, this is a burden and a responsibility such universities usually can carry!) --- A SICP course _as_a_first_language_, I'd teach (maybe) to students of Philosoply, Law, or theoretical Physics. But never to CS students. I admit this is a personal opinion, and I don't expect the world to agree. (Wouldn't be the first time.) After three of four languages, then I think CS students _would_ get orders of magnitude more Real Hard Core mental tools to think with. (( Think about it: anybody using Emacs and not being fluent in Lisp, is a joke. The key bindings suck hard, and a mental model of the workings and True Interface of Emacs just never become clear to you unless you're fluent enough to from the hip do short Lisp programs for one-shot needs while writing a source file. The only thing left are (First) being able to tell everybody you're a Real Programmer (and, way later as Second) possibly using some of the innumerable "modes" and "emacs extensions" that are readily available. )) --- Back to Philosoply, Law, or theoretical Physics, these folks need some rigor to their thinking. Early on. And such rigor is very hard to teach without a tool that only accepts correct thinking and punishes you for anything vague. (Rigor being just another tool in their chest, by no means the master.) (( I'm actually not expecting anyone here to agree, or even understand, since I haven't made much effort of a sufficient explanation. My bad, I confess. I'm not even sure I bother to argue if somebody starts shooting this down. This really is not a venue for that discussion. ))
Mar 23 2006
parent reply Sean Kelly <sean f4.ca> writes:
Georg Wrede wrote:
 Bruno Medeiros wrote:
 
 Frankly I really don't see D as much better/simpler than Java for the 
 purposes of a first language.

This might sound offending, condescending, patronising and whatever, but: Learning to program (in school/university, vs. on your own) does contain issues one never notices. The choice of language, the "scene" at the time, the predicted future of the students (and of course what they never tell you: access to knowledgeable teachers in the various choices), all do play a role. The faculty (hopefully) makes a choice genuinely based _only_ on their combined experience which (in the best case) might today be like n * 30 years, n being the number of professors participating in the decision.

Oddly, this topic came up at SDWest as well--someone asked Bjarne how he felt about universities switching from C++ to Java as a teaching language. He said that this change often coincided with a general "watering down" of the curriculum (to something more suitable for a BA program, I assume), but that aside... he said that recently there's been a push from the industry to re-instate C++ as a teaching language because it's used far more broadly than Java and companies wanted graduates to have experience in the language they were likely to use professionally. Apparently, Texas A&M just switched from Java back to C++, though there's no saying whether this has anything to do with Bjarne teaching there.
 Back to Philosoply, Law, or theoretical Physics, these folks need some 
 rigor to their thinking. Early on. And such rigor is very hard to teach 
 without a tool that only accepts correct thinking and punishes you for 
 anything vague. (Rigor being just another tool in their chest, by no 
 means the master.)

I like that you group Philosophy in with Theoretical Physics. Most people seem to think Philosophers are all either goofballs with their heads in the clouds or clueless name-droppers. Sean
Mar 23 2006
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Sean Kelly wrote:
 Georg Wrede wrote:
 Bruno Medeiros wrote:
 
 Frankly I really don't see D as much better/simpler than Java for
  the purposes of a first language.

This might sound offending, condescending, patronising and whatever, but: Learning to program (in school/university, vs. on your own) does contain issues one never notices. The choice of language, the "scene" at the time, the predicted future of the students (and of course what they never tell you: access to knowledgeable teachers in the various choices), all do play a role. The faculty (hopefully) makes a choice genuinely based _only_ on their combined experience which (in the best case) might today be like n * 30 years, n being the number of professors participating in the decision.

Oddly, this topic came up at SDWest as well--someone asked Bjarne how he felt about universities switching from C++ to Java as a teaching language. He said that this change often coincided with a general "watering down" of the curriculum (to something more suitable for a BA program, I assume),

IMHO, it's to do with increasing pressure for "efficiency". Unfortunately, even universities are facing this to an ever increasing degree. As such, I think it is good. But the problem is, politicians never bother to really get into _what_ efficiency is, so it becomes something shallow, like graduates per dollar, graduates per year, etc. What it should be, is more like "what serves the nation (or even mankind) best". And that certainly is not "watering down curricula" to get more folks "graduated" faster and cheaper. (Been there, done that. And I'm ashamed.) If (e.g.) doubling dollars per graduate (while, say, keeping graduation time constant) returns even 10% more output during the graduate's professional life, then I think the nation is a winner, no question. But try telling that to the politicians!
 but that aside... he said that recently there's been a push from the 
 industry to re-instate C++ as a teaching language

I can understand this. Suppose I had to find 10 top-notch programmers for a demanding project with a deadline. (And to make the point clearer, it would be written neither in Java nor C++.) On my desk I have the applicatons of 20 top of the line CS graduates, half with honors in Java, half with honors in C++. No question I choose the latter. Learning Java is so easy that a mediocre person can easily achieve honors in it. It's just a matter of hard and motivated work. But getting honors in C++ is way different. To get that, one has to have fought the idiotic error messages, mastered all kinds of pointer gotchas, never gotten scared of mounds of intellectually challenging (and still useless) trivial obstacles, thoroughly understood (the existence of, and properties of) the Computer Abstraction of C and C++, etc. And have repeatedly found productive ways of expressing oneself to the compiler and computer -- in spite of the language itself! By that time, you're a Real Programmer Candidate.
 because it's used far more broadly than Java and companies wanted 
 graduates to have experience in the language they were likely to use 
 professionally.

Half of that is true. The unstated part is, it's way easier to teach Java to C++ programmers than the other way around, should the need arise. Heh, mastering C++ should actually be considered a rite of passage. (Even after D takes over the world!)
 Apparently, Texas A&M just switched from Java back to C++, though 
 there's no saying whether this has anything to do with Bjarne 
 teaching there.

:-)
 Back to Philosoply, Law, or theoretical Physics, these folks need 
 some rigor to their thinking. Early on. And such rigor is very hard
 to teach without a tool that only accepts correct thinking and 
 punishes you for anything vague. (Rigor being just another tool in
 their chest, by no means the master.)

I like that you group Philosophy in with Theoretical Physics. Most people seem to think Philosophers are all either goofballs with their heads in the clouds or clueless name-droppers.

When I had to choose university, my opinion on Philosophers was _literally_ "goofballs with their heads in the clouds or clueless name-droppers"! Too bad. In hindsight, I should've chosen it.
Mar 24 2006
parent Sean Kelly <sean f4.ca> writes:
Georg Wrede wrote:
 Sean Kelly wrote:
 
 If (e.g.) doubling dollars per graduate (while, say, keeping graduation
 time constant) returns even 10% more output during the graduate's
 professional life, then I think the nation is a winner, no question. But
 try telling that to the politicians!

True. It's pretty much futile to mention long-term benefit to the bean counters. Though they do like to insist they should have been informed once things go wrong ;-)
 but that aside... he said that recently there's been a push from the 
 industry to re-instate C++ as a teaching language

I can understand this. Suppose I had to find 10 top-notch programmers for a demanding project with a deadline. (And to make the point clearer, it would be written neither in Java nor C++.) On my desk I have the applicatons of 20 top of the line CS graduates, half with honors in Java, half with honors in C++. No question I choose the latter.

Same here. I also very much like to see indications that people are interested in the discipline beyond its use as a means to a paycheck, as it often means the difference between someone who will continue to improve over time and someone who won't.
 Learning Java is so easy that a mediocre person can easily achieve
 honors in it. It's just a matter of hard and motivated work. But getting
 honors in C++ is way different. To get that, one has to have fought the
 idiotic error messages, mastered all kinds of pointer gotchas, never
 gotten scared of mounds of intellectually challenging (and still 
 useless) trivial obstacles, thoroughly understood (the existence of,
 and properties of) the Computer Abstraction of C and C++, etc. And have
 repeatedly found productive ways of expressing oneself to the compiler
 and computer -- in spite of the language itself! By that time, you're a
 Real Programmer Candidate.

A while back I went looking for an up-to-date book on assembly programming and was surprised and disappointed to find that the only decent book--"The Art of Assembly Language"--deals almost exclusively with HLA (high-level assembly, a C-like language) because students apparently found learning actual assembly to be too difficult. I feel very strongly that such compromises do the students a tremendous disservice and I sometimes wonder if we're producing a generation of Comp. Sci. graduates who haven't been taught much beyond some common data structure designs and the elementary use of a high-level language or two. I know that education is largely what you make of it, but I'd prefer that universities teach subjects more deeply and produce fewer graduates than gloss over the details and graduate hordes of ignoramuses.
 because it's used far more broadly than Java and companies wanted 
 graduates to have experience in the language they were likely to use 
 professionally.

Half of that is true. The unstated part is, it's way easier to teach Java to C++ programmers than the other way around, should the need arise.

True enough.
 When I had to choose university, my opinion on Philosophers was
 _literally_ "goofballs with their heads in the clouds or clueless
 name-droppers"! Too bad. In hindsight, I should've chosen it.

I felt much the same until I took a Philosophy course to fulfill a distributional requirement and was lucky enough to have a fantastic teacher. And it is a fairly accurate stereotype regardless of the underlying material :-) Sean
Mar 24 2006
prev sibling next sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Here is about the only point at which I disagree.  I learned QuickBASIC 
as my very first language, back quite some years ago.

Today I have a rather low opinion of that language and of BASIC in 
general.  Really, a bias.  I learned a lot of things back then - memory 
management (64k of string memory was rough), how great XMS used to be, 
why Assembler rocked, what the use of optimization was, etc.

My "mother tongue" in programming is nothing like QuickBASIC.  I tried 
to program some in it recently, and ASP more recently, and it was slow 
goings.  C is what I really latched onto.  Perl, PHP, C++, D, and other 
languages all feel the same.

Even so, I think QuickBASIC was a good first language for me.  I'm not 
comparing it to D here, but I'm just saying that the first language and 
the "mother tongue" language need not be the same.

In other words, even for Java programmers... learning D first might be 
better.  Then again, they might not ever actually be able to become Java 
programmers after that.

Still, having trials and tribulations... having to deal with limitations 
that suck, speed that is second rate... it helps.  I work in interactive 
media, and the good Flash/ActionScript programmers are often those who 
had to deal with Flash 5, from what I've seen.  Flash 5 was slow.  Flash 
5 was limited.  Flash 8 is so much better.  But Flash 5 taught you what 
not to do.

Just my opinion.

-[Unknown]


  - while knowing several programming languages right from the first year 
 is considered a forte, some teachers forget that *one* language that the 
 students *feel* their own [like a mother tongue], is rather important if 
 one is to entertain a life long understanding, comfortability and 
 handiness with programming as such

Mar 20 2006
prev sibling parent reply Niko Korhonen <niktheblak hotmail.com> writes:
Georg Wrede wrote:
 (Walter,) anytime somebody doubts D as a superior Academic Language, 
 have them talk with me.
 
 Another thing, if we can get D popular in the academia, both research 
 and teaching will gain a lot. And as an aside, 5 years after that, 
 who'll ever want to do programming in any other language???

Don't you think some high-level language of declarative nature such as Scheme, Haskell, Ruby or Python (or even Boo, O'Caml or Scala for that matter) would serve better as a first language? Scheme and Haskell really concentrate on expressing computational problems in their own domain, hence reputed as "executable specification". Even though D is very nice it really can't compete in "high-levelness" with the aforementioned languages. I personally see D more as a professional's tool for building real-life software as academic research language. As a side note, unfortunately none of the academic research languages are used widely for building real-life software, although they are *designed* to allow easy expression of computational ideas, i.e. to be easy to use. I for one would be extremely happy of getting a chance of using something like Haskell at work. Come to think of it, I would be extremely happy to use D. For some reason IT industry is both extremely sadistic and masochistic by insisting it's workers to use the worst languages available (C++) for all work (especially if the language doesn't suit the problem domain at all), constantly doing huge layoffs, offshoring and delivering products so bad and faulty that any traditional industry would be out of business on the first day. -- Niko Korhonen SW Developer
Mar 23 2006
parent Fredrik Olsson <peylow treyst.se> writes:
Niko Korhonen skrev:
 Georg Wrede wrote:
 (Walter,) anytime somebody doubts D as a superior Academic Language, 
 have them talk with me.

 Another thing, if we can get D popular in the academia, both research 
 and teaching will gain a lot. And as an aside, 5 years after that, 
 who'll ever want to do programming in any other language???

Don't you think some high-level language of declarative nature such as Scheme, Haskell, Ruby or Python (or even Boo, O'Caml or Scala for that matter) would serve better as a first language? Scheme and Haskell really concentrate on expressing computational problems in their own domain, hence reputed as "executable specification". Even though D is very nice it really can't compete in "high-levelness" with the aforementioned languages. I personally see D more as a professional's tool for building real-life software as academic research language. As a side note, unfortunately none of the academic research languages are used widely for building real-life software, although they are *designed* to allow easy expression of computational ideas, i.e. to be easy to use. I for one would be extremely happy of getting a chance of using something like Haskell at work. Come to think of it, I would be extremely happy to use D. For some reason IT industry is both extremely sadistic and masochistic by insisting it's workers to use the worst languages available (C++) for all work (especially if the language doesn't suit the problem domain at all), constantly doing huge layoffs, offshoring and delivering products so bad and faulty that any traditional industry would be out of business on the first day.

one should not have chosen the Simula school of OOP but the Smalltalk OOP school. D is super nice, and I love it. But if I take a step back and look at it, it really is barely more than C++ with a better syntax, and a few goodies thrown in for good measure. It is not like it allows for anything radically new and better, just the same old in a better package and with more convenience. As D never aimed for compatibility with C++ classes, there never was a need for following that trail. Stuff like dynamic typing, runtime access to the class system, really do makes a difference. The Objective-C solution is truly nice, anyone who have coded in OpenSTEP or Cocoa can agree that the difference in implementation allows for some really great and productive stuff. Unfortunately Objective-C is ugly as sin :). But I see no reason why someone could not make a language with C-like syntax that follows the Smalltalk paradigms. Heck, for novices and most everyday use no one would know the difference :) // Fredrik
Mar 24 2006
prev sibling next sibling parent Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Walter Bright skrev:
 I'm no expert on Java programming, but I get this question a lot: "What 
 compelling reason does D have that would entice a Java programmer to switch 
 to D?"

Apart from the reasons others have mentioned, I would just like to add: Expressiveness -- an area where I think D has far surpassed Java and even C++ and is closing up on the more popular scripting languages. /Oskar
Mar 21 2006
prev sibling parent reply Matthias Spycher <matthias coware.com> writes:
Walter Bright wrote:
 I'm no expert on Java programming, but I get this question a lot: "What 
 compelling reason does D have that would entice a Java programmer to switch 
 to D?"
 
 I know several of you have come to D from Java, and are expert Java 
 programmers, so you folks' reasons would be very valuable. 
 
 

I agree with Andrew that D and Java belong in separate categories. Java is intended for managed environments where the guts of the runtime are not exposed to the programmer. The object model is simple, the dynamic linking mechanism with class loaders is very powerful, and dynamic compilation achieves performance that is acceptable for many applications. If you look at just the language, it would be very easy to say D is competitive or superior. But if you look at the whole application life-cycle from specification, development, deployment, management, maintenance, evolution, etc., and the tools that support you in this cycle; D has quite a ways to go -- not so much the language, but the ecosystem around it. I do believe that, for certain applications, a dynamic compiler will at some point do a better job of optimizing code than a static compiler. Why? 1. A dynamic compiler knows about the architecture of the machine, e.g. cache sizes; and the profile of the running application, e.g. I/O boundedness. The data path is likely to be the main bottleneck in coming years. 2. Languages like Java have the advantage that they don't expose the actual layout of objects in memory to the programmer. Any language with pointers has a disadvantage in the context of dynamic optimization. 3. Multicore/multithreaded systems will provide for enough computational bandwidth for dynamic compilers and GCs to run in parallel with the programs they operate on. Performance degradation due to compilation at runtime will become a moot point on server systems very soon. 4. The ability to run multiple applications in the same runtime context; i.e. sharing the heap, the GC and the dynamically compiled bits of code; will reduce the overhead (which today is clearly a big issue for certain applications). Such a feature will be more easily implemented for a language like Java than D. Scalability. Java scales quite well to very large projects. Applications with millions of lines of code built by hundreds of developers (with different skill sets) are not out of the ordinary. If D can achieve this scalability (with the right tools, of course) then it will have come a long way. C/C++ do not scale this well primarily because they are system-dependent, have weaker semantics, limited library functionality, expose memory to the programmer and don't support garbage collection. Ownership patterns in large code bases are lost on the masses, and programming in the large becomes increasingly a breeding ground for dictatorships. One might argue Java is a mediocre programming language, but most programmers are mediocre, so less is more... Mobility. If you were a Comcast or a Vodafone, would you like to manage native downloadable applications for each and every gadget architecture that will appear on the planet. The ARM Cortex A8 architecture has this Jazelle RTC technology which will help byte-code apps scale on mobile, embedded systems. The infrastructure to manage native binaries is too expensive (not to mention fragile) and the performance degradation for byte code apps will be addressed (in hardware, if necessary). The choice for me will be to use D instead of C or C++ when I need to program at the system level -- when it's ready. I certainly think D is on the right track, so keep up the good work. IMHO, Java/C# are on a different track. Matthias
Mar 21 2006
next sibling parent reply Def <Def_member pathlink.com> writes:
In article <dvpq5q$1be1$1 digitaldaemon.com>, Matthias Spycher says...

1. A dynamic compiler knows about the architecture of the machine, e.g. 
cache sizes; and the profile of the running application, e.g. I/O 
boundedness. The data path is likely to be the main bottleneck in coming 
years.

As I see it, there's no technical reason why a static compiler couldn't do the same with run-time checks for different CPU versions, cache sizes, current system load, etc. and invoking different code versions accordingly. To prevent bloat such alternative code sections could even be loaded dynamically into RAM. It's just that it is a whole lot of work to implement such a compiler. But I'm sure Walter is already working on this... ;-) Def
Mar 21 2006
parent Roald Ribe <rr.nospam nospam.teikom.no> writes:
Def wrote:
 In article <dvpq5q$1be1$1 digitaldaemon.com>, Matthias Spycher says...
 
 1. A dynamic compiler knows about the architecture of the machine, e.g. 
 cache sizes; and the profile of the running application, e.g. I/O 
 boundedness. The data path is likely to be the main bottleneck in coming 
 years.

As I see it, there's no technical reason why a static compiler couldn't do the same with run-time checks for different CPU versions, cache sizes, current system load, etc. and invoking different code versions accordingly. To prevent bloat such alternative code sections could even be loaded dynamically into RAM. It's just that it is a whole lot of work to implement such a compiler. But I'm sure Walter is already working on this... ;-)

In the dynamic compiler case, the VM/compiler could be written 20 years later than the program itself, optimizing for a CPU/Arch that the developer team had never heard of at the time the program was developed. A static compiler could never do anything like that. (given that source code is not available) Java can be statically compiled with gcj (with some limitations). I see no reason why a D compiler could not produce instructions for a VM/dynamic compiler like .NET/Mono/JVM. In fact I think a D compiler should have that as a codegen option, to give developers/ users as much flexibility as possible. It would also be a very good temporary measure until a native compiler exists for all platforms. Roald
Mar 22 2006
prev sibling next sibling parent reply kris <foo bar.com> writes:
Matthias Spycher wrote:
 Walter Bright wrote:
 
 I'm no expert on Java programming, but I get this question a lot: 
 "What compelling reason does D have that would entice a Java 
 programmer to switch to D?"

 I know several of you have come to D from Java, and are expert Java 
 programmers, so you folks' reasons would be very valuable.

I agree with Andrew that D and Java belong in separate categories. Java is intended for managed environments where the guts of the runtime are not exposed to the programmer. The object model is simple, the dynamic linking mechanism with class loaders is very powerful, and dynamic compilation achieves performance that is acceptable for many applications. If you look at just the language, it would be very easy to say D is competitive or superior. But if you look at the whole application life-cycle from specification, development, deployment, management, maintenance, evolution, etc., and the tools that support you in this cycle; D has quite a ways to go -- not so much the language, but the ecosystem around it. I do believe that, for certain applications, a dynamic compiler will at some point do a better job of optimizing code than a static compiler. Why? 1. A dynamic compiler knows about the architecture of the machine, e.g. cache sizes; and the profile of the running application, e.g. I/O boundedness. The data path is likely to be the main bottleneck in coming years. 2. Languages like Java have the advantage that they don't expose the actual layout of objects in memory to the programmer. Any language with pointers has a disadvantage in the context of dynamic optimization. 3. Multicore/multithreaded systems will provide for enough computational bandwidth for dynamic compilers and GCs to run in parallel with the programs they operate on. Performance degradation due to compilation at runtime will become a moot point on server systems very soon. 4. The ability to run multiple applications in the same runtime context; i.e. sharing the heap, the GC and the dynamically compiled bits of code; will reduce the overhead (which today is clearly a big issue for certain applications). Such a feature will be more easily implemented for a language like Java than D. Scalability. Java scales quite well to very large projects. Applications with millions of lines of code built by hundreds of developers (with different skill sets) are not out of the ordinary. If D can achieve this scalability (with the right tools, of course) then it will have come a long way. C/C++ do not scale this well primarily because they are system-dependent, have weaker semantics, limited library functionality, expose memory to the programmer and don't support garbage collection. Ownership patterns in large code bases are lost on the masses, and programming in the large becomes increasingly a breeding ground for dictatorships. One might argue Java is a mediocre programming language, but most programmers are mediocre, so less is more... Mobility. If you were a Comcast or a Vodafone, would you like to manage native downloadable applications for each and every gadget architecture that will appear on the planet. The ARM Cortex A8 architecture has this Jazelle RTC technology which will help byte-code apps scale on mobile, embedded systems. The infrastructure to manage native binaries is too expensive (not to mention fragile) and the performance degradation for byte code apps will be addressed (in hardware, if necessary). The choice for me will be to use D instead of C or C++ when I need to program at the system level -- when it's ready. I certainly think D is on the right track, so keep up the good work. IMHO, Java/C# are on a different track. Matthias

Amen; on every point. What seems to be missing in this topic is the notion of selecting the right tool for the job. One could endlessly debate the overlap and distinction between D and Java, but in the end it's just horses for courses all over again. Heck ~ one might argue that D /is/ statically compiled Java, with the addition of pointers and structs, yet without the library support :-p It would be more interesting if this were entitled D vs C++. After all, isn't that (as Mattias indicated) the target "competition" ?
Mar 21 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"kris" <foo bar.com> wrote in message news:4420779B.6020604 bar.com...
 It would be more interesting if this were entitled D vs C++. After all, 
 isn't that (as Mattias indicated) the target "competition" ?

We've already had those threads in spades <g>.
Mar 21 2006
parent reply kris <foo bar.com> writes:
Walter Bright wrote:
 "kris" <foo bar.com> wrote in message news:4420779B.6020604 bar.com...
 
It would be more interesting if this were entitled D vs C++. After all, 
isn't that (as Mattias indicated) the target "competition" ?

We've already had those threads in spades <g>.

True <g> Did anyone mention DDL? Given that it would make D the only compiled language I've heard of with a runtime link-loader, that would seem to have some bearing?
Mar 21 2006
parent reply Kyle Furlong <kylefurlong gmail.com> writes:
kris wrote:
 Walter Bright wrote:
 "kris" <foo bar.com> wrote in message news:4420779B.6020604 bar.com...

 It would be more interesting if this were entitled D vs C++. After 
 all, isn't that (as Mattias indicated) the target "competition" ?

We've already had those threads in spades <g>.

True <g> Did anyone mention DDL? Given that it would make D the only compiled language I've heard of with a runtime link-loader, that would seem to have some bearing?

Just what I was thinking. Can DDL make compile once, run everywhere possible? (assuming that is an idiom we would like to support)
Mar 22 2006
parent reply kris <foo bar.com> writes:
Kyle Furlong wrote:
 kris wrote:
 
 Walter Bright wrote:

 "kris" <foo bar.com> wrote in message news:4420779B.6020604 bar.com...

 It would be more interesting if this were entitled D vs C++. After 
 all, isn't that (as Mattias indicated) the target "competition" ?

We've already had those threads in spades <g>.

True <g> Did anyone mention DDL? Given that it would make D the only compiled language I've heard of with a runtime link-loader, that would seem to have some bearing?

Just what I was thinking. Can DDL make compile once, run everywhere possible? (assuming that is an idiom we would like to support)

No, DDL does no such thing. Nor is it intended to (instead, it's deliberately machine-architecture specific). Functionality exposed by DDL is roughly the equivalent of a Java class-loader, but for pre-optimized native object-code exposing a D callable interface. This is a highly unusual attribute for native code runtime, and is (in my opinion) one of the most important assets for the D language. DDL also has the potential to support full reflection.
Mar 22 2006
next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <dvr64c$6sv$1 digitaldaemon.com>, kris says...
Kyle Furlong wrote:
 kris wrote:
 
 Walter Bright wrote:

 "kris" <foo bar.com> wrote in message news:4420779B.6020604 bar.com...

 It would be more interesting if this were entitled D vs C++. After 
 all, isn't that (as Mattias indicated) the target "competition" ?

We've already had those threads in spades <g>.

True <g> Did anyone mention DDL? Given that it would make D the only compiled language I've heard of with a runtime link-loader, that would seem to have some bearing?

Just what I was thinking. Can DDL make compile once, run everywhere possible? (assuming that is an idiom we would like to support)

No, DDL does no such thing. Nor is it intended to (instead, it's deliberately machine-architecture specific). Functionality exposed by DDL is roughly the equivalent of a Java class-loader, but for pre-optimized native object-code exposing a D callable interface. This is a highly unusual attribute for native code runtime, and is (in my opinion) one of the most important assets for the D language. DDL also has the potential to support full reflection.

I couldn't have said it better myself. :) A pleasant side-effect from all this is that it may help increase code-mobility across the windows/linux/mac divide, for any dynamic D binaries (x86 object files that comply with the D ABI) that are free from OS-specific code. Provided, that's just theory for now, but it should be possible. While that's not "run-everywhere", it gets you far enough to make certain styles of plugin architectures very possible. - EricAnderton at yahoo
Mar 22 2006
parent reply Don Clugston <dac nospam.com.au> writes:
pragma wrote:
 In article <dvr64c$6sv$1 digitaldaemon.com>, kris says...
 Kyle Furlong wrote:
 kris wrote:

 Did anyone mention DDL? Given that it would make D the only compiled 
 language I've heard of with a runtime link-loader, that would seem to 
 have some bearing?

Just what I was thinking. Can DDL make compile once, run everywhere possible? (assuming that is an idiom we would like to support)

deliberately machine-architecture specific). Functionality exposed by DDL is roughly the equivalent of a Java class-loader, but for pre-optimized native object-code exposing a D callable interface. This is a highly unusual attribute for native code runtime, and is (in my opinion) one of the most important assets for the D language. DDL also has the potential to support full reflection.

I couldn't have said it better myself. :) A pleasant side-effect from all this is that it may help increase code-mobility across the windows/linux/mac divide, for any dynamic D binaries (x86 object files that comply with the D ABI) that are free from OS-specific code. Provided, that's just theory for now, but it should be possible. While that's not "run-everywhere", it gets you far enough to make certain styles of plugin architectures very possible. - EricAnderton at yahoo

In digitalmars.com digitalmars.D:35128, Walter said of the difference in reals between Linux and Windows:
 pragma's DDL lets you (to some extent) mix Linux and Windows .objs.
 Eventually, we may need some way to deal with the different padding.


I think it's a pipe dream to expect to be able to mix obj files between operating systems. The 96 bit thing is far from the only difference. Now, he's quite knowledgeable, but I'd love to prove him wrong on this one. I find it hard to believe that it would be impossible. I guess the question is, will the subset of functionality that works be sufficient to be useful? I guess we won't know until the ELF side is working. "Compile once, run everywhere that matters"? (Win, Linux, Intel Mac). Exception handling (especially Windows SEH) might be a big problem, maybe a show stopper?
Mar 22 2006
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Don Clugston wrote:

 Now, he's quite knowledgeable, but I'd love to prove him wrong on this
 one. I find it hard to believe that it would be impossible. I guess the
 question is, will the subset of functionality that works be sufficient
 to be useful? I guess we won't know until the ELF side is working.

Heh, that would be cool. Hmm, drat, I'm the one supposed to do the ELF part... well, I'll get to it still. As for for cross-OS compatibility, it would have been easier if COFF still were widely used in the unix world, ELF is a totally different beast regarding datastructures and link semantics. But I will plug at it again soon now, DDL might even get some "professional" attention from me ;)
Mar 22 2006
prev sibling next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <dvrrca$103i$1 digitaldaemon.com>, Don Clugston says...
In digitalmars.com digitalmars.D:35128, Walter said of the difference in 
reals between Linux and Windows:

 pragma's DDL lets you (to some extent) mix Linux and Windows .objs.
 Eventually, we may need some way to deal with the different padding.


I think it's a pipe dream to expect to be able to mix obj files between operating systems. The 96 bit thing is far from the only difference.

I read Walter's remark, and it came to me like a shot from the blue.
Now, he's quite knowledgeable, but I'd love to prove him wrong on this 
one. I find it hard to believe that it would be impossible. I guess the 
question is, will the subset of functionality that works be sufficient 
to be useful? I guess we won't know until the ELF side is working.

"Compile once, run everywhere that matters"? (Win, Linux, Intel Mac).

Pipe dream or not, I think its worth looking into. And you're right: the portable subset of features may be just barely usable. Until we get some people really pounding away on this, we'll never quite know.
Exception handling (especially Windows SEH) might be a big problem, 
maybe a show stopper?

I must confess: I don't know enough. The 96/80-bit real thing is one issue, and if the D ABI doesn't specify what the exception mechanism is, then that becomes vendor/platform specific too. Is there anything else? I suppose I made the mistake of assuming that the D ABI was to become more encompassing than what it presently is. My understanding was that D aimed to fix things on a binary level as well as in the sourcecode. After all, C/C++ doesn't have a strong ABI and suffers directly because of it. It would be nice if we knew exactly what was left up to the compiler writers and what was not - at least then one could make some solid reccomendations for this mode of development. :( - EricAnderton at yahoo
Mar 22 2006
parent reply Sean Kelly <sean f4.ca> writes:
pragma wrote:
 In article <dvrrca$103i$1 digitaldaemon.com>, Don Clugston says...
 In digitalmars.com digitalmars.D:35128, Walter said of the difference in 
 reals between Linux and Windows:

 pragma's DDL lets you (to some extent) mix Linux and Windows .objs.
 Eventually, we may need some way to deal with the different padding.


operating systems. The 96 bit thing is far from the only difference.

I read Walter's remark, and it came to me like a shot from the blue.
 Now, he's quite knowledgeable, but I'd love to prove him wrong on this 
 one. I find it hard to believe that it would be impossible. I guess the 
 question is, will the subset of functionality that works be sufficient 
 to be useful? I guess we won't know until the ELF side is working.

 "Compile once, run everywhere that matters"? (Win, Linux, Intel Mac).

Pipe dream or not, I think its worth looking into. And you're right: the portable subset of features may be just barely usable. Until we get some people really pounding away on this, we'll never quite know.

For what it's worth, there was a thread on comp.std.c++ recently about a standard shared library format, and someone said that library formats have recently become sufficiently similar that this is a possibility. Sean
Mar 22 2006
parent reply pragma <pragma_member pathlink.com> writes:
In article <dvs41e$1ae5$1 digitaldaemon.com>, Sean Kelly says...
pragma wrote:
 In article <dvrrca$103i$1 digitaldaemon.com>, Don Clugston says...
 In digitalmars.com digitalmars.D:35128, Walter said of the difference in 
 reals between Linux and Windows:

 pragma's DDL lets you (to some extent) mix Linux and Windows .objs.
 Eventually, we may need some way to deal with the different padding.


operating systems. The 96 bit thing is far from the only difference.

I read Walter's remark, and it came to me like a shot from the blue.
 Now, he's quite knowledgeable, but I'd love to prove him wrong on this 
 one. I find it hard to believe that it would be impossible. I guess the 
 question is, will the subset of functionality that works be sufficient 
 to be useful? I guess we won't know until the ELF side is working.

 "Compile once, run everywhere that matters"? (Win, Linux, Intel Mac).

Pipe dream or not, I think its worth looking into. And you're right: the portable subset of features may be just barely usable. Until we get some people really pounding away on this, we'll never quite know.

For what it's worth, there was a thread on comp.std.c++ recently about a standard shared library format, and someone said that library formats have recently become sufficiently similar that this is a possibility.

Ahh, thanks for the info Sean (and for reminding me what a godsend *this* particular NG is). Its funny looking at the posts that go back a year or two to see folks lobbying around a "Module format" or "module include" (read: import) operator. Overall, I think we're on the right track with D and DDL. If any ABI for cross-platform binaries/libraries/modules is going to come about, it'll likely come up later out of necessity - so far I've been *anticipating* need rather than satisfying it. On an unrelated note, I also stumbled into Bjarne's proposal on XTI which is just flat-out scary: http://lcgapp.cern.ch/project/architecture/XTI_accu.pdf - EricAnderton at yahoo
Mar 22 2006
parent Georg Wrede <georg.wrede nospam.org> writes:
Disclaimer:

I'M JUST BLURTING OFF-HAND HERE, ANYONE IN A HURRY, OR LOOKING FOR
WORTHWHILE CONTENT, OUGHT TO SKIP THIS POST.


pragma wrote:
 In article <dvs41e$1ae5$1 digitaldaemon.com>, Sean Kelly says...
 
 pragma wrote:
 
 In article <dvrrca$103i$1 digitaldaemon.com>, Don Clugston 
 says...
 
 In digitalmars.com digitalmars.D:35128, Walter said of the 
 difference in reals between Linux and Windows:
 
 pragma's DDL lets you (to some extent) mix Linux and 
 Windows .objs. Eventually, we may need some way to deal 
 with the different padding.






If we specify a new spec, we could have library files that are usable in several architectures. The compiler could even automatically generate them as multi-platform binaries. As to the main executable, this might be harder.
 I think it's a pipe dream to expect to be able to mix obj files
 between operating systems. The 96 bit thing is far from the 
 only difference.




The obj files the compiler makes, don't necessarily need to have anything to do with the OS or OS calls. If all system calls go through the runtime library, then it can sort out any OS-specific stuff. And, especially now that Win, Lin, and Mac all run on the same processors, large parts of the .obj files should look the same already. Having the end result runnable on all three OSs may be an unnecessary thing. But accepting that _targeting_ will be per os, then the .obj files could theoretically be the same for all of them. At the end of the day the .objs of an app get linked together, and with the OS-specific runtime library and startup code. This would be neat -- if every processor was IA. But since we want to write D for other processors (and hopefully for embedded processors too), the one-obj-for-all-archs is wasted savings. And of course, if the calling conventions are different, then it may present an obstacle. But then again, as long as all calls to non-D stuff go through the runtime library, then we're safe. Except for efficiency issues.
 I read Walter's remark, and it came to me like a shot from the 
 blue.



Having 80=96 bit floats is handled in Linux -- after all, it's Linux itself that "wants" it. The math unit returns 80 bit entities, which are then stored in 96 bits. No problem. For program portability, there are mainly two issues here: - internal representation - user defined data structures The issues with the internal representation are fixed already (why else could one stay oblivious of the fact), in Linux. Storing these floats in user defined data structures may be another thing. Ideally this could be solved with a convention (or standard), where they are stored as 80 bit or 96 bit, whatever is commonly agreed upon. (For example, D for Windows could decide simply to store 80 bit floats as 96 bits, period.) Code for calling system calls or libraries could take care of the alignment.
 Now, he's quite knowledgeable, but I'd love to prove him wrong 
 on this one. I find it hard to believe that it would be 
 impossible. I guess the question is, will the subset of 
 functionality that works be sufficient to be useful? I guess we
  won't know until the ELF side is working.
 
 "Compile once, run everywhere that matters"? (Win, Linux, Intel
  Mac).




Truly multi-OS applications would be cool, of course. But then again, wouldn't software vendors like to sell two boxes instead of one? "You want to run this on both x and y, right!" Besides, there's all the GUI related differences too. If the binaries would be multi-OS by default, then the programmer should have to (at least) have a general idea of what not to do.
 Pipe dream or not, I think its worth looking into.  And you're 
 right: the portable subset of features may be just barely usable.
 Until we get some people really pounding away on this, we'll 
 never quite know.



I think it's doable. But as to if it is worth the effort, I'd need some persuasion. If not else, the resulting app could by default become a small (OS-dependent) "loader" plus the binary. So you'd always get 4 files: the three (mac, lin, win) loaders, and the "real program".
 For what it's worth, there was a thread on comp.std.c++ recently 
 about a standard shared library format, and someone said that 
 library formats have recently become sufficiently similar that this
 is a possibility.

Ahh, thanks for the info Sean (and for reminding me what a godsend *this* particular NG is). Its funny looking at the posts that go back a year or two to see folks lobbying around a "Module format" or "module include" (read: import) operator. Overall, I think we're on the right track with D and DDL. If any ABI for cross-platform binaries/libraries/modules is going to come about, it'll likely come up later out of necessity - so far I've been *anticipating* need rather than satisfying it. On an unrelated note, I also stumbled into Bjarne's proposal on XTI which is just flat-out scary: http://lcgapp.cern.ch/project/architecture/XTI_accu.pdf

XTI, Extended Type Information (possibly classes or trees) XPR, External Program Representation (Human + computer readable) Incidentally, XPR looks Pascal like, to me. An idea I got the other year was, to have the IDE not use program source code at all. "Source" files would be binary representations of the source code (probably as trees), and the only place where "conventional source code" would exist, is only on the screen of the program editor. (Yes, I do know this has been implemented (to various extents) already elsewhere since way back, no problem. But now I'm thinking D.) As an aside, this would let one have comments, drawings and such stuff directly "in the source code". It would also enable faster compilation, since tokenizing, parsing and semantics would already be done. (And of course, there'd be an Export to "normal source code", for long term backups and such.) Since any modern editor needs all kinds of intellisense, bells and whistles, keeping the code in an IPR (internal program representation) would make this much easier. If a standard file format existed, then every programmer could have his own program layout (meaning curly brace placement, indentation, comment style and formatting, etc.) on his screen, even if he collaborates with others. Processing of binary source would be very easy compared with textual source, as even Bjarne points out in the pdf. One could do all kinds of automatic processing, testing and measurement, and automatic derivation and analysis, or convenient automated refactoring. And conversion of source code to/from XML would be trivial. Search and replace and such would then be more intelligent! You could globally replace a word in one sense and not in others. D can already exist in HTML, enabling in-source pictures and a rich "source experience", theoretically with sound and videos embedded in the source code. (The usefulness of these remains to be seen.) One big problem witht this is debugging and editing, they become more work for the programmer, so currently the HTML-D format mainly suits education.
Mar 23 2006
prev sibling parent David Medlock <noone nowhere.com> writes:
Don Clugston wrote:

<snip>

 I couldn't have said it better myself. :)

 A pleasant side-effect from all this is that it may help increase 
 code-mobility
 across the windows/linux/mac divide, for any dynamic D binaries (x86 
 object
 files that comply with the D ABI) that are free from OS-specific code.
 Provided, that's just theory for now, but it should be possible.  
 While that's
 not "run-everywhere", it gets you far enough to make certain styles of 
 plugin
 architectures very possible.

 - EricAnderton at yahoo

In digitalmars.com digitalmars.D:35128, Walter said of the difference in reals between Linux and Windows: > > pragma's DDL lets you (to some extent) mix Linux and Windows .objs. > > Eventually, we may need some way to deal with the different padding. I think it's a pipe dream to expect to be able to mix obj files between operating systems. The 96 bit thing is far from the only difference. Now, he's quite knowledgeable, but I'd love to prove him wrong on this one. I find it hard to believe that it would be impossible. I guess the question is, will the subset of functionality that works be sufficient to be useful? I guess we won't know until the ELF side is working.

One thing I would rather see in portable object formats is hierarchical formats rather than linear ones. Code is inherently tree-like, yet Java byte codes(and other binaries) are in linear, stack based format. The slim binaries idea from Oberon used tree byte codes, and it compiled modules it loaded on the fly! -DavidM
Mar 23 2006
prev sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
kris wrote:
 Kyle Furlong wrote:
 kris wrote:

 Walter Bright wrote:

 "kris" <foo bar.com> wrote in message news:4420779B.6020604 bar.com...

 It would be more interesting if this were entitled D vs C++. After 
 all, isn't that (as Mattias indicated) the target "competition" ?

We've already had those threads in spades <g>.

True <g> Did anyone mention DDL? Given that it would make D the only compiled language I've heard of with a runtime link-loader, that would seem to have some bearing?

Just what I was thinking. Can DDL make compile once, run everywhere possible? (assuming that is an idiom we would like to support)

No, DDL does no such thing. Nor is it intended to (instead, it's deliberately machine-architecture specific). Functionality exposed by DDL is roughly the equivalent of a Java class-loader, but for pre-optimized native object-code exposing a D callable interface. This is a highly unusual attribute for native code runtime, and is (in my opinion) one of the most important assets for the D language. DDL also has the potential to support full reflection.

I wasn't talking about across architectures, just operating systems. Obviously the object code is platform specific.
Mar 22 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <dvpq5q$1be1$1 digitaldaemon.com>, Matthias Spycher says...
1. A dynamic compiler knows about the architecture of the machine, e.g. 
cache sizes; and the profile of the running application, e.g. I/O 
boundedness. The data path is likely to be the main bottleneck in coming 
years.

As someone else pointed out, there is no reason why this can't be done in static compilers - as it is now by GCC, Intel C/C++/Fortran and MS VC++ and probably several other high-perf. compilers.
2. Languages like Java have the advantage that they don't expose the 
actual layout of objects in memory to the programmer. Any language with 
pointers has a disadvantage in the context of dynamic optimization.

If you're talking about the famous "pointer alias problem" then Java is certainly not immune to that (maybe even less so because of all of the references floating around). If your talking about memory, see: http://www-128.ibm.com/developerworks/java/library/j-jtp06243.html
3. Multicore/multithreaded systems will provide for enough computational 
bandwidth for dynamic compilers and GCs to run in parallel with the 
programs they operate on. Performance degradation due to compilation at 
runtime will become a moot point on server systems very soon.

A compiler on these systems can be extremely complex, a VM even more so. A contemporary case in point is the Itanium compiler (it's not multi-core, but supposed to operate many pipelines per clock and a big part of that is the compilers job). If anything the difference between an Itanium static compiler and Java VM's is more pronounced on these systems because of the amount of work involved in optimizing for them. Chips like IBM's Cell system will make the problem even worse, not better.
4. The ability to run multiple applications in the same runtime context; 
i.e. sharing the heap, the GC and the dynamically compiled bits of code; 
will reduce the overhead (which today is clearly a big issue for certain 
applications). Such a feature will be more easily implemented for a 
language like Java than D.

Perhaps, but there will also be much more 'context switching' and synchronization, and there will always be an overhead involved there.
Mar 22 2006
parent reply Matthias Spycher <matthias coware.com> writes:
Dave wrote:
 2. Languages like Java have the advantage that they don't expose the 
 actual layout of objects in memory to the programmer. Any language with 
 pointers has a disadvantage in the context of dynamic optimization.

If you're talking about the famous "pointer alias problem" then Java is certainly not immune to that (maybe even less so because of all of the references floating around).

True, but accurate garbage collection is a requirement if you're going to scale to support large, long-running applications. C-pointer functionality eliminates the potential. The D community might (in the future) consider the introduction of a managed D subset that would make accurate GC possible.
 3. Multicore/multithreaded systems will provide for enough computational 
 bandwidth for dynamic compilers and GCs to run in parallel with the 
 programs they operate on. Performance degradation due to compilation at 
 runtime will become a moot point on server systems very soon.

A compiler on these systems can be extremely complex, a VM even more so. A contemporary case in point is the Itanium compiler (it's not multi-core, but supposed to operate many pipelines per clock and a big part of that is the compilers job). If anything the difference between an Itanium static compiler and Java VM's is more pronounced on these systems because of the amount of work involved in optimizing for them. Chips like IBM's Cell system will make the problem even worse, not better.

I agree it's not easy, especially for asymmetrical multi-core processors like Cell. Time will tell. I don't believe dynamically compiled apps will consistently beat the equivalent statically compiled program. But for many apps the performance difference will probably be similar to that between an assembly program and the equivalent C/C++ implementation. And that will have to be weighed against all other factors, e.g. productivity during development, deployment costs, maintenance, etc. Matthias
Mar 22 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Matthias Spycher wrote:
 Dave wrote:
 2. Languages like Java have the advantage that they don't expose the 
 actual layout of objects in memory to the programmer. Any language 
 with pointers has a disadvantage in the context of dynamic optimization.

If you're talking about the famous "pointer alias problem" then Java is certainly not immune to that (maybe even less so because of all of the references floating around).

True, but accurate garbage collection is a requirement if you're going to scale to support large, long-running applications. C-pointer functionality eliminates the potential. The D community might (in the future) consider the introduction of a managed D subset that would make accurate GC possible.

The D standard doesn't have any language that prevents this. I think it would be quite possible to implement an incremental GC in D if one had control over code generation.
 I agree it's not easy, especially for asymmetrical multi-core processors 
 like Cell. Time will tell. I don't believe dynamically compiled apps 
 will consistently beat the equivalent statically compiled program. But 
 for many apps the performance difference will probably be similar to 
 that between an assembly program and the equivalent C/C++ 
 implementation. And that will have to be weighed against all other 
 factors, e.g. productivity during development, deployment costs, 
 maintenance, etc.

I suppose it's a good thing that there's nothing stopping someone from compiling D code to a VM target either :-) Sean
Mar 22 2006
parent reply Matthias Spycher <matthias coware.com> writes:
Sean Kelly wrote:
 Matthias Spycher wrote:

 True, but accurate garbage collection is a requirement if you're going 
 to scale to support large, long-running applications. C-pointer 
 functionality eliminates the potential. The D community might (in the 
 future) consider the introduction of a managed D subset that would 
 make accurate GC possible.

The D standard doesn't have any language that prevents this. I think it would be quite possible to implement an incremental GC in D if one had control over code generation.

Are you suggesting whole-program analysis? Would one have to compile a certain way ahead-of-time to support a particular kind of GC? If yes, do you think that's practical? How would you deal with shared libraries that may be dynamically loaded -- fall back to a conservative GC?
Mar 22 2006
parent Sean Kelly <sean f4.ca> writes:
Matthias Spycher wrote:
 Sean Kelly wrote:
 Matthias Spycher wrote:

 True, but accurate garbage collection is a requirement if you're 
 going to scale to support large, long-running applications. C-pointer 
 functionality eliminates the potential. The D community might (in the 
 future) consider the introduction of a managed D subset that would 
 make accurate GC possible.

The D standard doesn't have any language that prevents this. I think it would be quite possible to implement an incremental GC in D if one had control over code generation.

Are you suggesting whole-program analysis? Would one have to compile a certain way ahead-of-time to support a particular kind of GC? If yes, do you think that's practical? How would you deal with shared libraries that may be dynamically loaded -- fall back to a conservative GC?

Incremental garbage collection requires compiler support, and it does basically involve whole-progam analysis. For those unfamiliar with incremental GC, the way it works (even in Java) is for the compiler to inject code around all pointer modifications which signals the GC that the pointer has changed. This allows the GC to know which memory blocks to rescan later. The problem with incremental GCs is that it's difficult to guarantee that the GC will make progress, as frequent pointer changes could force the GC start over repeatedly (I read one paper that did describe such an incremental GC, but such implementations are definately not the norm). Also, the code injection means pointer modifications are far more expensive--from 10 to 100 instructions depending on the situation (if my memory serves me). However, this slower average performance is counterbalanced by the elimination of "stop the world" collections. I can see this being a very reasonable approach for some realtime applications, but perhaps not as a general purpose strategy. There are a few odd alternatives out there, such as Boehm's "mostly parallel" which marks memory blocks as read-only using VMM calls during its initial scanning phase (which doesn't stop the world), and then has a much shorter "stop the world" phase later on. However, these memory page manipulations are very expensive, so this approach is probably not optimal in most situations. I think an incremental GC could be done for a subset of D without too much trouble (ie. any code that uses plain old reference manipulation), but being able to pass pointers and arrays of pointers to C functions is a stumbling block. An incremental GC may still be possible, but it would need to be over-conservative in how pointer changes are tracked. Basically, any time pointer data is passed to an opaque function the compiler would have to assume that it could be modified and to signal the GC appropriately. The more liekly situation is that D will always use a conservative GC "with hints," so type information is used whenever possible to focus the scan phase, but untyped memory allocations will be scanned by default, though the user could indicate that this is not necessary. In Ares, I'm going to eventually parameters to malloc/calloc/realloc for this purpose. Sean
Mar 22 2006
prev sibling next sibling parent Dave <Dave_member pathlink.com> writes:
In article <dvs40o$1amc$1 digitaldaemon.com>, Matthias Spycher says...
Dave wrote:
 2. Languages like Java have the advantage that they don't expose the 
 actual layout of objects in memory to the programmer. Any language with 
 pointers has a disadvantage in the context of dynamic optimization.

If you're talking about the famous "pointer alias problem" then Java is certainly not immune to that (maybe even less so because of all of the references floating around).

True, but accurate garbage collection is a requirement if you're going to scale to support large, long-running applications. C-pointer functionality eliminates the potential. The D community might (in the future) consider the introduction of a managed D subset that would make accurate GC possible.
 3. Multicore/multithreaded systems will provide for enough computational 
 bandwidth for dynamic compilers and GCs to run in parallel with the 
 programs they operate on. Performance degradation due to compilation at 
 runtime will become a moot point on server systems very soon.

A compiler on these systems can be extremely complex, a VM even more so. A contemporary case in point is the Itanium compiler (it's not multi-core, but supposed to operate many pipelines per clock and a big part of that is the compilers job). If anything the difference between an Itanium static compiler and Java VM's is more pronounced on these systems because of the amount of work involved in optimizing for them. Chips like IBM's Cell system will make the problem even worse, not better.

I agree it's not easy, especially for asymmetrical multi-core processors like Cell. Time will tell. I don't believe dynamically compiled apps will consistently beat the equivalent statically compiled program. But for many apps the performance difference will probably be similar to that between an assembly program and the equivalent C/C++ implementation. And that will have to be weighed against all other factors, e.g. productivity during development, deployment costs, maintenance, etc. Matthias

Good points... I'm not so sure accurate GC can't be done on non-raw-pointer data with D as-is. Conservative collectors for C/C++ as they are of course is a must, but I'm not so sure w/ D because the compiler/GC interface can be synchronized. Don't ask me to expound on it because I can't, just something in the back of my tiny mind somewhere. <g> - Dave
Mar 22 2006
prev sibling parent James Dunne <james.jdunne gmail.com> writes:
Matthias Spycher wrote:
 Dave wrote:
 
 2. Languages like Java have the advantage that they don't expose the 
 actual layout of objects in memory to the programmer. Any language 
 with pointers has a disadvantage in the context of dynamic optimization.

If you're talking about the famous "pointer alias problem" then Java is certainly not immune to that (maybe even less so because of all of the references floating around).

True, but accurate garbage collection is a requirement if you're going to scale to support large, long-running applications. C-pointer functionality eliminates the potential. The D community might (in the future) consider the introduction of a managed D subset that would make accurate GC possible. [snip] Matthias

Garbage collection is absolutely not a requirement of scaling to support large, long-running applications. Take a look at Apache and Subversion for their use of memory pools (both use the APR). However, If your point was to show 'accurate' garbage collection as a requirement over 'conservative' collection, then yes I agree. :) -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O M-- V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e h>--->++ r+++ y+++ ------END GEEK CODE BLOCK------ James Dunne
Mar 23 2006