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.


Well, there are hundreds of Java/Swing applications. :)
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.


 Well, there are hundreds of Java/Swing applications. :)
 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 


 Well, there are hundreds of Java/Swing applications. :)
 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/


 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. :)


: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




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  =?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...


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


Ok, this is offtopic, but one off Java "slowness" problems is that people
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


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


 Ok, this is offtopic, but one off Java "slowness" problems is that people
 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?)


 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



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.


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


  > too "heavy".

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


  > too "heavy".
 
 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?




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 

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 

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. 
 
 




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:


	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:

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:

 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! 
 
 


Taking this a step further, look at the massively scalar CELL processor.

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!


 Taking this a step further, look at the massively scalar CELL processor.
 
 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:

 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.


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)

- 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)

 - 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

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


 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.


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.
 


If one should take the full step with D (Although a bit too late now), 
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 

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 

 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)


 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


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.




 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.


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.




 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.


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