www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Reddit: why aren't people using D?

reply bearophile <bearophileHUGS lycos.com> writes:
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,<<


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)
Jul 27 2009
next sibling parent Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
bearophile wrote:

 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.

This was about overloading &&, || and !, right? It's not a random feature. It's a logical consequence of the operator overloading system. Leaving them out is arbitrary. You will never convince me that a potentially useful feature should be left out because it could potentially be abused. By the way, I did think of a compelling use-case just yesterday. Boost has a three-valued bool type. true, false and maybe. Seems pretty logical to overload the boolean operators for it. -- Michiel Helvensteijn
Jul 27 2009
prev sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
bearophile wrote:


 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).

Yes, but practically every other language implements testing in libraries. My suggestion was not build a big unit testing system in the language, but just to add those one or two changes in order to build such a testing library on top of the existing system. ...
 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.

Isn't this a bit contradictory? ...
 
 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.

list comprehensions are only worth it if you add tuples imho. Otherwise I think we can get by just fine with map/filter/reduce plus extension methods.
Jul 27 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Lutger:

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

Isn't this a bit contradictory?<

I don't see a contradiction. For example list comprehensions and unit testing module aren't random features, they are known to be quite useful.
list comprehensions are only worth it if you add tuples imho.<

Nope. Lazy/eager sequence comprehensions can be useful in many situations even if you don't have tuples.
Otherwise I think we can get by just fine with map/filter/reduce plus extension
methods.<

Reduce is not intuitive. And a sequence comp is shorter and more readable (IF the syntax is really good) than most map/filter/xmap/xfilter. Bye, bearophile
Jul 27 2009
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
bearophile wrote:

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

Isn't this a bit contradictory?<

I don't see a contradiction. For example list comprehensions and unit testing module aren't random features, they are known to be quite useful.

Sure, I was referring to your suggestion of adding features to see how they pan out and then removing them, not any particular feature.
list comprehensions are only worth it if you add tuples imho.<

Nope. Lazy/eager sequence comprehensions can be useful in many situations even if you don't have tuples.

list comprehensions don't do anything useful over map & friends but make them look better. They are super handsome in python in combination with tuples. So my point was, if you go for list comprehensions as a sweetener, you really should have some tuples with them too.
Jul 27 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Lutger:

I was referring to your suggestion of adding features to see how they pan out
and then removing them, not any particular feature.<

Yes, there's a small contradiction there, because usually there's no a single best solution to a problem, and even oppostite strategies may be both useful in different situations. But I was mostly talking about finding a way to play very well with an experimental feature before adding it to the real language.
list comprehensions don't do anything useful over map & friends but make them
look better.<

I don't agree because: - They are indeed syntax sugar, but they allow for shorter, less noisy/cluttered, and more readable code (IF and only if their syntax is really good), this improves code, makes it more readable, avoids errors, etc. - You often don't need delegates, so: (x * x for x in xrange(10, 20) if x & 1) doesn't require the compiler to be able to inline two closures as in: xfilter((int x){ return x & 1; }, xmap((int x){ return x * x; }, xrange(10, 20))) (This is code from my dlibs, and it's not much readable. "xsomething" means it's lazy, as in that Python line of code. Phobos2 usually doesn't need delegates here. Currently DMD and LDC aren't able to inline closures it seems no one is interested in this and I don't know why).
They are super handsome in python in combination with tuples.<

Tuples are very handy, and I'd like to have a good support for them in D. But note that there are no tuples in that code I have just shown. Bye, bearophile
Jul 27 2009
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
python: 
  (x * x for x in xrange(10, 20) if x & 1)

D as of now:
  map!("a * a")( filter!("a & 1")( range!(10,20) ) )

D with extension methods:
  range!(10,20).filter!("a & 1").map!("a * a")

Not too bad right? 

(the range function is fictional, I forgot if and which one exists in 
phobos) 
Jul 27 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Lutger:
 python: 
   (x * x for x in xrange(10, 20) if x & 1)
 
 D as of now:
   map!("a * a")( filter!("a & 1")( range!(10,20) ) )
 
 D with extension methods:
   range!(10,20).filter!("a & 1").map!("a * a")
 
 Not too bad right?

It's not terrible, but it's far from being nice. Strings are sharp and rough tools, when used for such purposes. Map and filter of Phobos2 are lazy only, so if you need an array you have to add another function call (that's named array() in my dlibs, I don't remember the Phobos2 name).
 (the range function is fictional, I forgot if and which one exists in 
 phobos)

In Phobos2 it's named iota (from APL, maybe), it doesn't require the exclamation mark (bang, !) (but it's not smart enough yet to accept just one argument, and default the first one to zero). Bye, bearophile
Jul 27 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Lutger:
 python: 
   (x * x for x in xrange(10, 20) if x & 1)

 D as of now:
   map!("a * a")( filter!("a & 1")( range!(10,20) ) )

 D with extension methods:
   range!(10,20).filter!("a & 1").map!("a * a")

 Not too bad right?

It's not terrible, but it's far from being nice. Strings are sharp and rough tools, when used for such purposes. Map and filter of Phobos2 are lazy only, so if you need an array you have to add another function call (that's named array() in my dlibs, I don't remember the Phobos2 name).

array. Andrei
Jul 27 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Lutger wrote:
 python: 
   (x * x for x in xrange(10, 20) if x & 1)
 
 D as of now:
   map!("a * a")( filter!("a & 1")( range!(10,20) ) )
 
 D with extension methods:
   range!(10,20).filter!("a & 1").map!("a * a")
 
 Not too bad right? 
 
 (the range function is fictional, I forgot if and which one exists in 
 phobos) 

(It's called iota.) Andrei
Jul 27 2009
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Andrei Alexandrescu wrote:

 Lutger wrote:
 python:
   (x * x for x in xrange(10, 20) if x & 1)
 
 D as of now:
   map!("a * a")( filter!("a & 1")( range!(10,20) ) )
 
 D with extension methods:
   range!(10,20).filter!("a & 1").map!("a * a")
 
 Not too bad right?
 
 (the range function is fictional, I forgot if and which one exists in
 phobos)

(It's called iota.) Andrei

Oh yes, I remember being freaked out reading about the APL after that one: (~R∊R∘.×R)/R←1↓⍳R (this finds all prime numbers from 1 to R in the APL)
Jul 27 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Lutger:
 Oh yes, I remember being freaked out reading about the APL after that one:
 (~R∊R∘.×R)/R←1↓⍳R
 (this finds all prime numbers from 1 to R in the APL)

I can't read that APL code, and Python code that does the same is more than twice longer (and it may also be slower):
 n = 20
 [x for x in xrange(2,n) if all(x % i for i in xrange(2,x))]



Bye, bearophile
Jul 27 2009