Mike S: >the needs of game programmers should be taken seriously while considering D's >evolution:<
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 :-) >Right now, D hasn't completely found its niche, but it seems to position >itself as a sane successor to C++ for systems-level programming.< 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; - Some of D unsafe characteristics are worked on to improve their safety, but there's lot of road to travel still, for example null-safety and integers-overflow-safety are far away still. People are trying to explain Walter still why null-safety has some importance. - D2 defaults to mutables. This can be acceptable, I don't know; - Currently D2 is not designed from the start to work with an IDE (but I think this problem can be fixed with not too much work); - The built-in unit testing and documentation are not fit for professional usage (but the documentation is easy to extend because they are just comments, so it's a smaller problem). - etc. 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). >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. >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. >I think D will eventually be used for writing other heavy-duty non-OS >frameworks and software systems,< >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). >You're right that the garbage collector is a major issue - probably the >biggest one inherent to the language design - but I haven't determined it's a >dealbreaker, at least not yet.< 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. 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. >In the case of dynamic arrays, resizing capacity deterministically is one of >those small things that would be really helpful to anal game programmers, and >it probably wouldn't hurt anyone else, either. Plus, it's easier to implement >than "smart nondeterministic" resizing anyway. :)< 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. Bye, bearophile
