D benchmark code review

Sat Dec 14 11:46:35 PST 2013

On Saturday, 14 December 2013 at 18:46:50 UTC, Joseph Rushton 
Wakeling wrote:
> Very curious about what you mean here -- I think most of us 
> find that D's template syntax is much superior to C++, so I'd 
> really like to understand what you find problematic.

I dislike the syntax. :-) And well, as far as I can tell I also 
dislike the semantics, but it is no worse than C++. I would like 
to see a modern language with templates to do it well. That is to 
be more in the direction of readable term-rewriting, 
pattern-matching with constraints that will make it possible to 
do clean operator-overloading etc.  More in the direction of 
legible Pure, Haskell etc.

> Out of curiosity, is this a show-stopper for theoretical 
> reasons, or did you actually run into practical problems with 
> the GC?

It is a showstopper because I only do C++ like stuff that is 
realtime,  like graphics and audio. I use Python for things that 
can be done as batch.

I once wrote a D-program to sort my email archives in memory, it 
took a while for the GC to kick in, but it got kind of slow… 
Still, this was a couple of years ago.

What I want is a programming language that I can write clean code 
in and that allows me to have a mental map of how it maps onto 
the hardware. C does this, except it does not allow for clean 
programming.

> I don't think things are actually as spread out as you think.  
> In reality, there is one compiler frontend that everyone 
> collaborates on.

You could be right, I am only talking about the impression I am 
getting. "The smoke-signals being received from a distance". When 
you don't have one excellent compiler, but three in-the-works, it 
sends signals of a lack of direction and implies a lack of a 
leader that can rally everyone into something cohesive. This is 
not a critique of anyone, most programmers want to be creative 
and argumentative, not to "nurture", "manipulate" and "wave the 
whip" ( I am not even sure I like people who are "great leaders" 
;^).

> I think it might be worth giving things another spin.  If the 
> last time you tried using D was a couple of years ago, you will 
> find that things have changed a great deal in terms of 
> performance, features and general quality.

Let me rephrase what I am perceiving like this: for me D is 
currently a solution without a problem.

D is probably a better language than Dart, but Dart is addressing 
a real problem: writing programs for browsers that are longer 
than 1000 lines without javascript. And it does so by compiling 
to javascript. So I am using Dart now. Dart is currently the only 
sane solution for web-app programming.

D is probably a better language than Python, but Python has many 
great libraries (like importing excel), is available for 
AppEngine with fast spin-up, and have a nice interpreter for 
experimenting with text-manipulation and code-snippets. So I am 
using Python, even though a dynamic language is crap on a server 
(runtime errors).

D is probably a better language than Go, but it isn't available 
on AppEngine and the Go team is making it work well for web 
servers so while it is still in experimental status it probably 
will be support fully on AppEngine. So I am spending some time 
with Go.

D is probably a better language than C++ in many areas (like 
header files!), but I cannot easily and effortlessly get rid of 
the GC and I will probably have performance problems with real 
time program code (audio is hard realtime, if you don't fill the 
buffer you get "pops").

D is certainly a much better language than 
Objective-C/Objective-C++, but it won't run on iOS. So when doing 
app-programming I'd use Objective-C++ (and do as much as possible 
in the C++ part).

The only hobbyist project I have that I would like to use D for 
is to do a little bit of experimenting with creating a tiny 
hobbyist OS in 64-bit mode, but I have no idea what it takes to 
do that with D.

My personal opinion is that D would get much more traction if it 
was a true C/C++ replacement. That is to have the same level of 
minimal runtime-system/mental-mapping-to-hardware. So, if there 
was a tar-ball with a small mini-OS/D-compiler that I could 
dabble with I most certainly would give D a spin, but as of today 
I see D as a solution with no obvious problem to solve. There is 
no "best-application-area" for D, which in turns leads it to not 
being the first choice for any given problem even though it 
probably is a better language in many areas than the languages 
that "win" in their respective areas.

I think the ideal direction for D would be to take clang, rip out 
the c++ parser and allow D to interface with (llvm based) C++ 
seamlessly and to add the ability to generate c++ code from D 
code. That way programmers could start integrating D into their 
C++ projects with no risk. As of today, I feel that it is better 
to just stick to C++ without D, because the risks of using D does 
not outweigh the advantages it may provide for me.

Do you think I am unfair?

Ola.