bearophile wrote:
The short D1 history shows that designers of small games are willing to use D.
Some game designers seem almost desperate to find an usable language simpler
than C++. So I agree with you that D2 can be designed keeping an eye at game
designers too. But that's very demanding people, it's not easy to satisfy them
even with a mature language + compiler + std lib + dev tools. And currently
nothing in D2 is mature. For them maybe not even the most mature thing you can
find in D world, the back-end of ldc (llvm), is mature enough :-)
Yeah, you're right about the demanding tool and maturity requirements
that game studios have, but assuming people continue working on D and
other people adopt it and enhance the tools, those things will flesh out
over time. I'm young enough that I look forward to seeing it overtake
C++ in the game world someday.
I am not able to tell the future. Some parts of D design are already old-style:
- Some early design decisions make hard to inline D virtual functions (so if
you write D code in Java style, you see a significant slow down compared to
similar Java code running with HotSpot). So far no one seems to care of this,
we'll see if I am right to see a problem here;
Well, writing code Java-style is certainly no problem for game devs,
considering they already minimize virtual function usage, at least in
lower code layers. ;)
<snip>
A system language is something that you can use to write very small binaries, that can be
used to write a kernel like Linux, device drivers for a smaller computer+CPU, etc. Such
things are hard to do in D2, I don't see Linus using D2 to write his kernel, he even
thinks C++ is unfit. So I see D2 more like a "low-level application language",
on a level located somewhere between C and C#. It can also become a numerics language
(see below).
This is true, but I do recall seeing an executable size comparison
somewhere, and the D version of a program (hello world?) beat out the
C++ version by about a factor of two. The C version killed both, but
still, perhaps D might not be eternally unfit even if C++ is. ;) Then
again, maybe the C++ program was just including a superfluous amount of
library code, and maybe D programs are generally larger than their C++
equivalents. Plus, if it was hello world, it obviously wasn't using a
lot of higher-level features.
Either way though, even if D does become fit for kernel/driver code
someday, it'll still be a long time before someone actually starts from
scratch to write a new kernel using it anyway.
As it stands, I believe there are only two major kinds of programmers who still
use C++, and those are game programmers and masochists. ;)<
There's also an army of legacy programmers that have to update and debug tons
of C++ code. Part of the human society works thanks to a mountain of C++ code.
Online programming competitions are usually won by C++ code.
People will find ways to use C++ for many more years, it will probably outlast
us all.
You're right, and I actually realized I misspoke here a little bit ago
while I was eating. The legacy code just might keep people using C++
until the sun dies. Still, I maintain that game developers and
masochists probably comprise a large portion of programmers starting
completely new projects in C++. :D
It's too low-level for scripting tasks,<
I have asked several times to have Python-style array/lazy comprehensions in D
:-) They help. I think their introduction can reduce by 10-30% the length of D2
programs.
How difficult do you think that would be for the compiler devs to
implement in the semantic sense? Assuming it can be done without major
hardship or compromising the design of the language, that would be
really cool. Syntactically speaking, Python list comprehensions make
the source so much more compact, expressive, and clean that a statically
compiled language using them would really stand out. If they're
implemented correctly, I can't see any reasons why the syntactic sugar
would be any slower than spelling everything out explicitly, either.
The syntax would have to be a bit different to feel at home in D, but
the idea itself probably isn't too foreign.
I also noticed a discussion about Python tuples from October 2009 I
think, and native tuples in D would also be useful...more useful than in
Python, in fact. After all, Python lists can contain mixed types
(unlike arrays in D), so they make tuples largely redundant except for
their different conventional meanings (and except for the ability to
used named tuples). In comparison, built-in tuples in D with similarly
elegant syntax would fill in a much larger gap. I suppose they'd work
something like implicitly generated struct types, which could be hastily
constructed as lvalues or rvalues, returned from functions,
packed/unpacked and passed to functions, etc. Honestly, I think there's
a lot to be learned from the expressiveness of scripting languages
(especially Python, given its elegant syntax without all of the Perl/PHP
@#$%^&crazysymb...@#$%^&), and I think a lot of it can be readily
applied to statically compiled languages without speed hits or design
compromises.
> From what I've seen so far I think D2 will appeal to some numerics
folks too, so it can eat a bit of Fortran pie too. Some improvements can
make D2 more appealing to them, Don is working on this too. (Some ideas
from Chapel language can help here, but I think no one here has taken a
serious look at it so far).
It interested me when you mentioned numerics above, because game engine
design is also moving more in the direction of dataflow-oriented
programming, where the object hierarchy is more streamlined and there's
more of a focus on transforming one type of data to another. This helps
with both cache efficiency and exposing data-level parallelism. With
all of the vector and matrix math involved in those transformation steps
(physics engines, etc.), the same improvements that appeal to
FORTRAN/numerics programmers might also find some use cases here. Of
course, I could be talking out of my ass, since I don't quite know what
D 2.0 improvements you're referring to, but I imagine they might apply.
The situation with the D GC is interesting.
First of all D GC is not refined, Java VM GCs are way more advanced. So D GC
will need a much more modern GC.
Another problem is that the current D GC is quite imprecise, this causes leaks
when you use it in real programs that have to run for more than few minutes.
Part of this problem can be solved using a better GC that's more precise (this
can slow it down a bit, but avoids a good amount of memory leaks).
The other problem is intrinsic of the language, that makes it hard or
impossible to invent a fully precise GC for D.
And D makes it hard to use a modern generational moving GC with D. You can't
just adopt a JavaVM GC with D. Even the Mono GC (that knows the notion of
pinned/unpinned memory) can be unfit (because it's designed for mostly unpinned
memory).. This is partially caused by D being a low level language with
pointers, and it's partially caused by D2 type system unable to tell apart:
1) hand-managed pointers, to GC memory or C heap memory;
2) GC-managed pointers to pinned memory;
3) GC-managed pointers to unpinned memory.
I think Walter think that telling them apart in the language makes D too much
complex, and he can be right. But the current situation makes it hard to design
a very efficient GC for D. So I don't think high-performance game designers
will use D GC for the next few years, they will manage most or all the memory
manually. I am ignorant, but I think D designers have to work a little harder
in finding ways to allocate unpinned objects. This (with a refined GC able to
move unpinned memory, that keeps a stack-like Eden plus two or three
generations of objects) can help a lot for programs written in Java-style.
Yeah, that's really a shame about the current state of the garbage
collector. Any memory leaks at all are the death knell of console
games, and they're also the death of pretty much any long-running
application. Are the memory leaks eternal and irrevocable, or are we
just talking about memory that takes a long time for the garbage
collector to figure out it should free?
That said, my interest in D is less about its state today and more about
its state tomorrow. I'm not planning on dying anytime soon, so I
imagine I'll be coding for a long time...and I hope it's not just going
to be C++, C++, and more C++ for the rest of my life!
But computer science history has shown that if enough people work on a problem
they can often find some partial solution. At the beginning Java was very slow.
So there's a bit of hope still. Of course enough GC experts will work on the D
GC only if D will have some success.
That's pretty much the way I look at it too. Assuming people don't just
abandon D, it's only a matter of time before the genius programmers of
the world fix the rough spots.
Don't nail your mind only on that problem, that's only one of many problems.
You can think that dynamic arrays are simple, but from what I've seen there's
nothing simple in D dynamic arrays, people have found a way to improve them a
little only now, after years of discussions about them, and I am not fully sure
yet the recent changes are worth it, I mean I am not sure yet that the current
D2 arrays are better than the older ones + an appender helper struct. There is
no good benchmarking suite yet to test if they are an improvement.
You're right: It's just that when I saw this thread, I figured I could
bring up this one problem of many which happens to be an easy fix. :)
Bye,
bearophile
