View mode: basic / threaded / horizontal-split · Log in · Help
March 03, 2006
why and how D can solve the next software crisis (was Re: Negative)
In article <du7fo5$1uqo$1@digitaldaemon.com>, Walter Bright says...
>
>A lot of excellent comments. Some more from me embedded:

Thanks.

>"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message 
>news:du5hbu$2bag$1@digitaldaemon.com...
>> So the C++ team adds hard-to-implement/use stuff to the language, and 
>> rarely
>> adds easy-to-implement/use stuff, because the easy-to-implement stuff is 
>> doable
>> with macros/template magic.  Macro/template language is much more powerful 
>> than
>> macro-only magic.  But the illusion still breaks down ... everyone has an
>> ITERATE macro that doesnt quite work seamlessly.
>
>Yes, my thoughts exactly.
>
>> I think the crown might pass to any language that could fix C++ 
>> performance and
>> syntax... once it declared for the throne.  D does very well syntactically 
>> and
>> performance wise, but I think it still has the "not ready yet" label stuck 
>> on
>> the front of the box, because of the sub-1.0 version and lack of ... 
>> (insert
>> wishlist items).
>
>The wishlist thing is an ever-growing thing. It's a problem, mostly my 
>fault.

For some reason I always want to write "the only thing on the wishlist I really
care about is...", but then I think of 10 things right away.  When I write here
I tend to write a lot of stuff off the cuff, in a sort of "noone's ever done X,
I wonder if it would be useful..." style.

But:

>> (Question: What was the "trigger" that made people start
>> adopting Java for projects?)
>
>The initial trigger was the idea you could embed Java applets into a web 
>page, coupled with the idea that it was a C++ like language that was, in 
>contrast, easilly mastered. 

You and Ianc wrote about this side of it, and it makes sense now - I have been
thinking of Java strictly in terms of language design.

Now I realize something..

Business people, and for that matter, most other people, tend to explain their
own logic (and history itself) via "narratives".  Everyone used X, but then
problem Y happened.  Language Z came along and solved this.  Political movement
X was replaced by movement Y when World War Z occurred.  Cause->Effect.

But the original rationale rarely stays put.  C was for systems programming (but
took over everything).  Java was designed for the web, but now is used for
desktop applications, etc.  Computers originally were marketed for the home on
the rationale that they can manage recipes for dishes.

So... from this kind of marketing point of view, what problems are just over the
horizon that D can get ahead of the curve on?  It's very good at what C, C++,
and Java already can do, better than those languages, IMHO.

But I'm coming around to the idea that to "win the election", D needs to look
like a solution to a crisis, or at least some phenomena that Bill Manager can
claim was a new problem that needed a new solution.  Little problems won't cut
it, even if your project is dying of thousands of little papercuts.

(As an illustration, I changed the title of this post - snappier, right?  The
following may seem a bit cynical, but I'm just trying to be practical.)

People who pick (or at least sign off on) programming languages will drag their
heels to adopt unless there is a motivation they can "feel".  Reduces pointer
errors by 35% and code length by 20% is not good enough, even if it would save
the software industry.  I once described D to a colleage as a language that
"improves hundreds of little things that taken together are revolutionary".  But
I couldn't think of a "killer app" story for D.

This is not a criticism of business, its just that to take a big risk, managers
need to know (1) what problem they are solving, (2) how to measure whether the
solution is working.  Otherwise they feel they could easily get conned by silver
bullet salesmen -- it's happened before, right?  If you ask a big-name CEO what
problem he is solving with a new initiative, its a "moment of truth" question
for him.  He won't argue incremental improvements, he'll strike at the core of
something he thinks is close to your heart and explain how his company can help.

Let me propose some general hype; these will look a little like hyperbole, but
most of them are more or less true (or could be without *too* much pain):

1. D unites scripting style and C/C++ performance.

2. D is like C++ after the lessons learned from Java, Python, and Perl.

3. D is a high performance Java.

4. D can do Perl or Python-style rapid development, but is safe enough and fast
enough for "BIG" problems.

5. D is like Java, but for systems programming tasks.

6. D has all the power of C++ with the safety of Java.

[ Noone knows exactly what the previous means, but it leverages Java's claims.
Since much of Java's safety claims were on the basis of pointer elimination, D
can legitimately claim much of the same benefit. ]

5. D is compile anywhere, run anywhere.

This is not true yet; would be immense to accomplish unless the D compiler was
distributed with GCC.  This is unfortunate, since the DMD compiler is so fast
and focused, but I think lack of platform portability is a killer for a compiler
(but not so much for an interpreter for some reason.)

I see two possible futures in which D is ubiquitous, i.e. as much as Java now.

FUTURE 1: The DMD compiler is used for fast development and to run D "scripts".
The high compile speed makes it perfect for scripting and rapid development on
the platforms it does support, and GCC's D compiler makes sure the rest of the
platforms don't have to go begging.  Everyone gets fast development and every
platform can build binaries.  But GCC would need to support D out of the box.

FUTURE 2: The D compiler occupies a niche like Perl or Python, Tcl, etc, where
there is one "blessed" compiler, but it still gets installed by everyone.  All
of these seem to be scripting languages (why is that??).  The only way this can
happen (I think) is if D supports every platform (very very much work, I
think...) or can at least produce and run some kind of bytecode.

[ D in bytecode sounds tricky, but I don't know enough to know how many genuine
obstacles there are.  I would think the "Java subset" of D could be done this
way, but... ]

Compiled languages generally don't seem to take off until there is a compiler
available for every big platform.  (Am I wrong about this?)

And to top it off, a "customer anecdote":

I work at a government job, writing public services and C++ libraries for
biotech apps.  I imagine walking into a meeting and saying that there is this
cool new language, D, "but it only works on 32 bit amd/intel".  This would be
enough to reject D (all our servers are 64 bit amd/intel already, and we also
provide Solaris, IRIX, OSX, and Windows binaries).

Which is too bad, because we are a high-performance project (we worry about
cache lines and register pressure all the time), that suffers from C language
pointer-related mishaps and C++ syntax related burn out.  In many ways, D is
perfect for the niche we are in.

But on the other hand, our project has spent the last 3-5 years shifting from C
to a rewritten-in-C++ version.  So it's probably a no-fly zone for new language
adoption in any case, for the next few years.

Kevin
March 03, 2006
Re: why and how D can solve the next software crisis (was Re: Negative)
Kevin Bealer wrote:

> 5. D is compile anywhere, run anywhere.
> 
> This is not true yet; would be immense to accomplish unless the D compiler was
> distributed with GCC.  This is unfortunate, since the DMD compiler is so fast
> and focused, but I think lack of platform portability is a killer for a compiler
> (but not so much for an interpreter for some reason.)
> 
> I see two possible futures in which D is ubiquitous, i.e. as much as Java now.
> 
> FUTURE 1: The DMD compiler is used for fast development and to run D "scripts".
> The high compile speed makes it perfect for scripting and rapid development on
> the platforms it does support, and GCC's D compiler makes sure the rest of the
> platforms don't have to go begging.  Everyone gets fast development and every
> platform can build binaries.  But GCC would need to support D out of the box.

I just don't see why GDC would have to be bundled with the rest of
the GNU Compiler Collection in order for it to be used everywhere ?

Yes, I know that the main GCC distribution also contains frontends for
Objective C, Fortran, Java, and Ada. But those are more "different"... ?

As it is now, most GCC-using systems support C and C++ "out of the box",
and if you want an "odd" language like Pascal or D - you go download it:

http://www.gnu-pascal.de/                 (GNU Pascal Compiler, gpc)
http://home.earthlink.net/~dvdfrdmn/d/    (GNU D Compiler, gdc)

We *should* probably get GDC listed at http://gcc.gnu.org/frontends.html
(putting it on the TODO list for next GDC release, along with new site)


But then again most people don't want GDC, but want DMD on all platforms
and only want a Digital-Mars-supported graphical interface such as DWT ?

And there isn't much anyone but Walter himself can do about those, IMHO.
(I don't have time for both, so I'll worry about the GNU / wx versions)


> FUTURE 2: The D compiler occupies a niche like Perl or Python, Tcl, etc, where
> there is one "blessed" compiler, but it still gets installed by everyone.  All
> of these seem to be scripting languages (why is that??).  The only way this can
> happen (I think) is if D supports every platform (very very much work, I
> think...) or can at least produce and run some kind of bytecode.
> 
> [ D in bytecode sounds tricky, but I don't know enough to know how many genuine
> obstacles there are.  I would think the "Java subset" of D could be done this
> way, but... ]

Color me sceptic, but I'm not too sure about "D the scripting language".
It just doesn't seem to be in the nature of the language, to do that...

I'd love to be wrong, by someone providing a .NET or Parrot backend :-)
But DMDScript is probably more likely to fill the DM scripting needs ?

--anders
March 03, 2006
Re: why and how D can solve the next software crisis (was Re: Negative)
Kevin, I think your analysis is totally correct.
Future 1 and 2 are both possibilitites. 
But for anything to happen (as has i think been discussed prev):
- D v1.0 with decent standard libs needs to be reached.
- D frontend standard with gcc install with dmd the optimised commercial option.

A while back on Slashdot there was a discussion about what language the gnome
framework, desktop and apps should be written in. C was felt to be too low, C++
too tricky, python was a scripting language, mono and java were vm based and
tied to ms/sun.

Walter - or someone using his name - suggested D. D would be perfect for this.
Imagine a desktop stack build in D...ahhh. But i can't see it happening.
(Actually, C# on gcc would be good i.e c# as a compiled language. c# syntax and
semantics are pretty good. I think someone may have had a go at this but it
didn't progress).
March 03, 2006
Re: why and how D can solve the next software crisis (was Re: Negative)
In article <du91ou$1rd4$1@digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>Kevin Bealer wrote:
>
>> 5. D is compile anywhere, run anywhere.
>> 
>> This is not true yet; would be immense to accomplish unless the D compiler was
>> distributed with GCC.  This is unfortunate, since the DMD compiler is so fast
>> and focused, but I think lack of platform portability is a killer for a compiler
>> (but not so much for an interpreter for some reason.)
>> 
>> I see two possible futures in which D is ubiquitous, i.e. as much as Java now.
>> 
>> FUTURE 1: The DMD compiler is used for fast development and to run D "scripts".
>> The high compile speed makes it perfect for scripting and rapid development on
>> the platforms it does support, and GCC's D compiler makes sure the rest of the
>> platforms don't have to go begging.  Everyone gets fast development and every
>> platform can build binaries.  But GCC would need to support D out of the box.
>
>I just don't see why GDC would have to be bundled with the rest of
>the GNU Compiler Collection in order for it to be used everywhere ?
>
>Yes, I know that the main GCC distribution also contains frontends for
>Objective C, Fortran, Java, and Ada. But those are more "different"... ?
>
>As it is now, most GCC-using systems support C and C++ "out of the box",
>and if you want an "odd" language like Pascal or D - you go download it:
>
>http://www.gnu-pascal.de/                 (GNU Pascal Compiler, gpc)
>http://home.earthlink.net/~dvdfrdmn/d/    (GNU D Compiler, gdc)
>
>We *should* probably get GDC listed at http://gcc.gnu.org/frontends.html
>(putting it on the TODO list for next GDC release, along with new site)
>
>
>But then again most people don't want GDC, but want DMD on all platforms
>and only want a Digital-Mars-supported graphical interface such as DWT ?
>
>And there isn't much anyone but Walter himself can do about those, IMHO.
>(I don't have time for both, so I'll worry about the GNU / wx versions)
>
>
>> FUTURE 2: The D compiler occupies a niche like Perl or Python, Tcl, etc, where
>> there is one "blessed" compiler, but it still gets installed by everyone.  All
>> of these seem to be scripting languages (why is that??).  The only way this can
>> happen (I think) is if D supports every platform (very very much work, I
>> think...) or can at least produce and run some kind of bytecode.
>> 
>> [ D in bytecode sounds tricky, but I don't know enough to know how many genuine
>> obstacles there are.  I would think the "Java subset" of D could be done this
>> way, but... ]
>
>Color me sceptic, but I'm not too sure about "D the scripting language".
>It just doesn't seem to be in the nature of the language, to do that...
>
>I'd love to be wrong, by someone providing a .NET or Parrot backend :-)
>But DMDScript is probably more likely to fill the DM scripting needs ?
>
>--anders

Anders, despite my inital thoughts D does not probably need to be part of gcc
install. The desktop has settled on x86 and dmd is strong there. Any idea what
Digital Mars biz model is for D when version 1 is released?
March 03, 2006
Re: why and how D can solve the next software crisis (was Re: Negative)
ianc wrote:

>>I just don't see why GDC would have to be bundled with the rest of
>>the GNU Compiler Collection in order for it to be used everywhere ?
>>
> Anders, despite my inital thoughts D does not probably need to be part of gcc
> install. The desktop has settled on x86 and dmd is strong there.

We probably do agree that packaging GDC up neatly is a Good Thing ?
And *that* is something I've been pretty much involved in, already.

A GDC-only package is in the 3-4 MB range, while a full GCC/G++/GDC
distribution is more in the 30-40 MB range. Still very downloadable ?

This could be discussed a lot more, but should go in the D.gnu group.
(or contact me privately - by email, if not for public NG discussion)


> Any idea what
> Digital Mars biz model is for D when version 1 is released?

No idea, but it would be interesting if they (he?) could expand on it...
I *guess* it would be similar to their C/C++ business model, though ?

http://www.digitalmars.com/shop.html

--anders
March 03, 2006
Re: Negative
Andrew Fedoniouk wrote:

>>
>> Java launched for 3 reasons(outside of Suns marketing), IMO:
>>
>> 1. Server side web programming was just taking off. This was Java's
>> killer
>> app.  Case in point: Flash does most interactive embedded stuff today in
>> web pages.
>>
>> 2. No pointers. No memory leaks eliminates large classes of errors. Even
>> though it existed in other languages, coupled with #1 this made Java a
>> much better C++.
>>
>> 3. A comprehensive set of tools and a company willing to support them. In
>> getting business to adopt your tech they need support and Sun delivers(at
>> least on Solaris and Win32 initially).
>>
> 
> 4. Execution model: VM + real GC. Safe sandbox. Pure byte code cannot GPF
> in principle.
> 
> 5. Extremely simple Java Native Interface mechanism - bridge to native
> code for
> mission crititcal pieces.

I beg to differ here. I've worked on several projects on Linux that use JNI
extensively and it's anything but easy to use. It may work for simple
cases, but it has all kinds of quirks and it's unnecessarily verbose. Every
JVM has its JNI functions in different libraries, so there's no hope of
simple portability between them. To top it all, just try to embed the JVM
inside a process that uses threads and Unix signals to see what "all hell
breaks loose" really means.

I think the guy who designed JNI really didn't want it to be used.
March 03, 2006
Re: Negative
In article <du9qmo$9rk$1@digitaldaemon.com>, Juan Jose Comellas says...
>
>Andrew Fedoniouk wrote:
>
>>>
>>> Java launched for 3 reasons(outside of Suns marketing), IMO:
>>>
>>> 1. Server side web programming was just taking off. This was Java's
>>> killer
>>> app.  Case in point: Flash does most interactive embedded stuff today in
>>> web pages.
>>>
>>> 2. No pointers. No memory leaks eliminates large classes of errors. Even
>>> though it existed in other languages, coupled with #1 this made Java a
>>> much better C++.
>>>
>>> 3. A comprehensive set of tools and a company willing to support them. In
>>> getting business to adopt your tech they need support and Sun delivers(at
>>> least on Solaris and Win32 initially).
>>>
>> 
>> 4. Execution model: VM + real GC. Safe sandbox. Pure byte code cannot GPF
>> in principle.
>> 
>> 5. Extremely simple Java Native Interface mechanism - bridge to native
>> code for
>> mission crititcal pieces.
>
>I beg to differ here. I've worked on several projects on Linux that use JNI
>extensively and it's anything but easy to use. It may work for simple
>cases, but it has all kinds of quirks and it's unnecessarily verbose. Every
>JVM has its JNI functions in different libraries, so there's no hope of
>simple portability between them. To top it all, just try to embed the JVM
>inside a process that uses threads and Unix signals to see what "all hell
>breaks loose" really means.
>
>I think the guy who designed JNI really didn't want it to be used.


yeh even ID wanted to use java for gameplay in quake 2 but found the JNI a
jumbled mess - and so different on each platform it was not possible to use a
single codebase. luckally they saw the light of day, threw java away, and wrote
quakec.

coming from a gamedev background, i cant really stand java....
March 03, 2006
Re: why and how D can solve the next software crisis (was Re: Negative)
In article <du91ou$1rd4$1@digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>Kevin Bealer wrote:
>
>> 5. D is compile anywhere, run anywhere.
>> 
>> This is not true yet; would be immense to accomplish unless the D compiler was
>> distributed with GCC.  This is unfortunate, since the DMD compiler is so fast
>> and focused, but I think lack of platform portability is a killer for a compiler
>> (but not so much for an interpreter for some reason.)
>> 
>> I see two possible futures in which D is ubiquitous, i.e. as much as Java now.
>> 
>> FUTURE 1: The DMD compiler is used for fast development and to run D "scripts".
>> The high compile speed makes it perfect for scripting and rapid development on
>> the platforms it does support, and GCC's D compiler makes sure the rest of the
>> platforms don't have to go begging.  Everyone gets fast development and every
>> platform can build binaries.  But GCC would need to support D out of the box.
>
>I just don't see why GDC would have to be bundled with the rest of
>the GNU Compiler Collection in order for it to be used everywhere ?
>
>Yes, I know that the main GCC distribution also contains frontends for
>Objective C, Fortran, Java, and Ada. But those are more "different"... ?
>
>As it is now, most GCC-using systems support C and C++ "out of the box",
>and if you want an "odd" language like Pascal or D - you go download it:
>
>http://www.gnu-pascal.de/                 (GNU Pascal Compiler, gpc)
>http://home.earthlink.net/~dvdfrdmn/d/    (GNU D Compiler, gdc)
>
>We *should* probably get GDC listed at http://gcc.gnu.org/frontends.html
>(putting it on the TODO list for next GDC release, along with new site)


There is no technical reason.  But go to your boss and tell him you want to use
a new language.  He'll be sceptical...  Now tell him you need to build your own
patched version GCC to get a compiler for it...


>But then again most people don't want GDC, but want DMD on all platforms
>and only want a Digital-Mars-supported graphical interface such as DWT ?
>
>And there isn't much anyone but Walter himself can do about those, IMHO.
>(I don't have time for both, so I'll worry about the GNU / wx versions)


DMD is much better, but since DMD produces machine code directly, it seems
likely that IA64, and even moreso, every non-intel version is going to require a
big chunk of Walter's time.  This seems non-scalable right now...  maybe the
code for DMD is flexible enough to make this happen quickly, but I don't know
enough.... correct me if I'm wrong, please.


>> FUTURE 2: The D compiler occupies a niche like Perl or Python, Tcl, etc, where
>> there is one "blessed" compiler, but it still gets installed by everyone.  All
>> of these seem to be scripting languages (why is that??).  The only way this can
>> happen (I think) is if D supports every platform (very very much work, I
>> think...) or can at least produce and run some kind of bytecode.
>> 
>> [ D in bytecode sounds tricky, but I don't know enough to know how many genuine
>> obstacles there are.  I would think the "Java subset" of D could be done this
>> way, but... ]
>
>Color me sceptic, but I'm not too sure about "D the scripting language".
>It just doesn't seem to be in the nature of the language, to do that...


I think the main feature scripting languages have that make them so great in
their niche is that container classes, regexes, and a fair amount of system call
oriented syntax (i.e. backticks to run commands) are built right in.

D doesn't have all of this yet, but it's far ahead of C and C++ here.  I think
it can handle the "scripty" end of the application spectrum better than most
other compiled languages.

It may never have bytecode, but users don't actually care about that if
compile/link is fast -- which seems to be true for dmd but not necessarily gdc.
The dmd compile feels faster than just starting the Java interpreter.  I haven't
benchmarked it though.

>I'd love to be wrong, by someone providing a .NET or Parrot backend :-)
>But DMDScript is probably more likely to fill the DM scripting needs ?
>
>--anders
March 03, 2006
Re: why and how D can solve the next software crisis (was Re: Negative)
Kevin Bealer wrote:
> 
> Now I realize something..
> 
> Business people, and for that matter, most other people, tend to explain their
> own logic (and history itself) via "narratives".  Everyone used X, but then
> problem Y happened.  Language Z came along and solved this.  Political movement
> X was replaced by movement Y when World War Z occurred.  Cause->Effect.

I think this is true of people in general.  In fact, Bruce Schneier has 
made the same observation with respect to security issues in that most 
security initiatives have attempted to address "movie scenarios" rather 
than actually improve security in a general sense.  There's something 
very compelling about a situation we can envision.

> Compiled languages generally don't seem to take off until there is a compiler
> available for every big platform.  (Am I wrong about this?)

If you have Microsoft's marketing strength I think it's quite possible 
to push a Windows-only solution.  And I suspect people are willing to 
take what they can get with niche platforms.  But in general I suspect 
this is true.  Just look at ObjectiveC.

> And to top it off, a "customer anecdote":
> 
> I work at a government job, writing public services and C++ libraries for
> biotech apps.  I imagine walking into a meeting and saying that there is this
> cool new language, D, "but it only works on 32 bit amd/intel".  This would be
> enough to reject D (all our servers are 64 bit amd/intel already, and we also
> provide Solaris, IRIX, OSX, and Windows binaries).

We're actually heading the opposite direction.  Our software was 
designed for 64-bit Sparc machines and we've recently ported it to 
64-bit AMD.  But 32-bit will never happen--memory requirements are 
simply too high.

> Which is too bad, because we are a high-performance project (we worry about
> cache lines and register pressure all the time), that suffers from C language
> pointer-related mishaps and C++ syntax related burn out.  In many ways, D is
> perfect for the niche we are in.

Same here.  Though we'd have to make limited use of the GC for memory 
size and performance reasons.  Still, I think that would fit in nicely 
with the way the system is designed.


Sean
March 03, 2006
Re: why and how D can solve the next software crisis (was Re: Negative)
Kevin Bealer wrote:

>>I just don't see why GDC would have to be bundled with the rest of
>>the GNU Compiler Collection in order for it to be used everywhere ?
[...]
> There is no technical reason.  But go to your boss and tell him you want to use
> a new language.  He'll be sceptical...  Now tell him you need to build your own
> patched version GCC to get a compiler for it...

But one can still build binary packages for it (GDC), without it first 
being a FSF project ? The only caveat being that if your system compiler 
is too far away from what GDC works with, you'll need *another* GCC too.
(which could still be offered as an alternative installation, though...)

I don't necessarily think it's a bad idea. Just wonder why it has to be.
I'd worry more about the language spec not being open, or even finished.

[...]
> It may never have bytecode, but users don't actually care about that if
> compile/link is fast -- which seems to be true for dmd but not necessarily gdc.
> The dmd compile feels faster than just starting the Java interpreter.  I haven't
> benchmarked it though.

Part of this speed comes from optlink, I think ? (when it doesn't crash)
At least I've found the GCC linking to be slower, doubly so for C++...

--anders
11 12 13 14 15 16
Top | Discussion index | About this forum | D home