Reddit: why aren't people using D?

[bearophile]

Walter Bright:

>Lazy parameter evaluation may turn out to be a bad idea, it doesn't seem to have found its "groove" anywhere.<

Lazy parameters allow me to implement a poor's man list comprehensions.
Once list comprehensions are built-in, I don't need lazy parameters much anymore.

Why list comprehensions are very useful: for a language it's important to "scale up", it means it can be used to build large programs/systems, you seem aware of this.
But in a modern language it's also very important to "scale down", that is to allow to write small functions/programs with less code an in a simple way. Many programs are small, and even large programs are made of small functions.
Note: "Scala", means "scalable language", it means it can be used for small programs too.


>The flattening thing is a problem. The rest can be done with better library support.<

A handy syntax to unpack too may be very useful, and it can't be done with a library:

a, b, c = foo()
a, d = [1, 2]


>>* Unit testing (not at compile time,<<
>You can do testing at compile time with static asserts.<

There's no nice way to assert that a template or compile time function raises a certain compile time assert/error.


>I agree that D's built-in unit testing is basic. But the fact that it exists *at all* is a huge improvement for a programming language.<

People today use C#, Python, C#, JavaScript, Ruby (and a bit of Java, and maybe in future Scala too). They are the languages D will be compared to. D will not be compared much to C/C++. Today improving a little over C++ is not enough.
D's built-in unit testing is not enough, it misses few important things. My suggestion is not to add more built-in unittest capabilities to D, but to do the opposite: to remove the built-in unit testing from D and replace it with enough means (reflection, and what else) necessary to add a simple but sufficiently good unit testing module to Phobos. This is a situation where teaching fishing is better. (It may be possible that no things have to be added to D. Then it's just a matter to see such module written by someone and added to Phobos).

-----------------------

Steven Schveighoffer:

>The one thing I think is missing from D in this area is struct interfaces.<

C# shows that you can use them in many useful ways.

-----------------------

Lutger:

>It's interesting why unittest (and assert) are such big success. My idea is that it's not in spite of, but because of their utter simplicity. I speculate that if it would have been different, for example if you would had to create a new file for a unittest, it would not have been used so much.<

It's another example of scaling. A good unit test system is the one that allows you to write quickly and in a very simple way simple tests. And to use them later to build more and more complex unit testing as the program gets bigger.
At the moment D unit testing is fit for small purposes only, but not for the larger ones (Python docstests are fit for even small purposes, you can use it for unit testing even if your program is 15 lines long).

-----------------------

Walter Bright:

>For instance, look at the installer thing. I think that downloading a zip file, and unzipping it, is so trivial. Yet this seems to be a blocker for people using D, over and over I hear about how hard it is to install. I find this baffling. But yet, it's obviously an issue.<

Most people don't has much problems installing the DMD compiler on Windows, or LDC on Ubuntu. The problem comes just later, when such people look for a way to have a complete system (toolchain), with IDE, etc. Eventually D will need a handy bundle with the basic tools to program (the compiler is just one of them).

-----------------------

Knud Soerensen:

>Now imagine one bad programmer broke the standard and wrote a unit test on a private function.<

Unit tests are part of the code, part of the program itself. Many times it's better to keep tests as close as possible to the code they test.

-----------------------

Walter Bright:

>It may indeed be the syntax, but consider that no other language adopted those constructs. There was a proposal to add contracts to C++0x which died. I added them to Digital Mars C++ and nobody cared.<

A way to solve this problem is to add features (to D2), and then later remove them (to D3) if they aren't appreciated. This breaks backward compatibility, as D2 does on D1.
Or even (silly idea) adding features to D1 may be good to test such features to see if they are worth addign to D2 :-) Using D1 as experimental field...

-----------------------

Michiel Helvensteijn:

>I don't know a compelling use-case either. But that doesn't mean there isn't any. Nor are there any real dangers. Arbitrarily restricting the possibilities of D doesn't seem like the right way to go.<

Adding random features to a language just because they look cool is a terrible thing to do.

-----------------------

Rainer Deyke:

>I want to throw these words back at you, because my first impression of D was "the bastard child of C++ and Java, with a random assortment of new features thrown in without rhyme or reason".  D is many things, but a simple and elegant language it is not.<

I agree. D is nicer than C++, etc. But it's also complex, unelegant, and sometimes it looks like a "random assortment of new features". D looks like a grown language, not a planned one. Still, I like it enough.

-----------------------

Walter Bright:

>My first years of C++ code also looked a lot like just plain old C (in fact, it arguably still does).<

You may look at the source code of some good C++ project. I guess you will not look at the source code of LLVM.

-----------------------

Ary Borenszweig:

>Unfortunately the designers of D doesn't care at all about IDE support for their language,<

*All* modern languages are designed to have good interactions with IDEs. So D will eventually need such things.

-----------------------

Andrei Alexandrescu:

>I think D should also visibly obviate some use of Python or Perl for prototyping.<

A good language works well with others, like Python, it doesn't try to fully "obviate" them.
But I agree that D may grow some features that allow it to "scale down". Syntax support for tuples and list comprehensions are two of the things that can help a lot in such regard.

-----------------------

Rainer Deyke:

>I *like* having to write 'gc_ptr<Object> p;' instead of 'Object p;'. I *like* having to write 'p->f();' instead of 'p.f();'.  It keeps my code clearly and more explicit.<

That's noisy and bad looking. In 90-95% of the lines of code you don't need that level of precision.

(Generally the point of D is to be simpler than C++, even if this means losing some of of the power of C++).

-----------------------

Ary Borenszweig:

int property foo(); // getter
int property foo(int value); // setter

Not bad. It's not handy as the C#3 syntax, but it's better than nothing.

-----------------------

Bye,
bearophile
(sorry for the late replay, I was away)