Does D have too many features?

SomeDude lovelydear at mailmetrash.com
Sat Apr 28 14:04:19 PDT 2012


On Saturday, 28 April 2012 at 20:49:33 UTC, Maxim Fomin wrote:
> On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
>> Andrei and I had a fun discussion last night about this 
>> question. The idea was which features in D are redundant 
>> and/or do not add significant value?
>>
>> A couple already agreed upon ones are typedef and the cfloat, 
>> cdouble and creal types.
>>
>> What's your list?
>
> I guess the underlying problem is inability to formulate the 
> target state of the language with specified relations between 
> different components. Being looking at the language since late 
> 2011 I found problematic to know the language as a whole. When 
> a newcomer looks for information he either gets a common 
> overview "native efficiency, ..." at dlang.org with (outdated) 
> documentation or videos on youtube which explains how 
> scope(xxx) beats exceptions and templates are superior to that 
> in C++ and similar posts in the web, let alone toolchain lack 
> complaints.
>
> My comment was provoked mainly by 
> http://forum.dlang.org/thread/vwpzirpppabcgylmvpsx@forum.dlang.org 
> discussion (D3 idea).
>
> You ask which features are redundant or not significant, but 
> this depends on how features are integrated in the rest of 
> language and without clear and completed vision there is no 
> answer. And please remember, that each of D member has its own 
> (biased) information about D and what to do. The language is 
> moving and it is hard to reveal how any change will affect 
> other components. Even if you found a particular item redundant 
> there is no guarantee that the situation will not change in 
> future.
>
> Currently I (who looked for a language that combines C# 
> "usability" and C performance) view D as a ship which sails in 
> unknown direction with lots of holes (look at bugzilla 
> proposals how to make a language) and what I found the most 
> dreaded is that the direction of the ship movement today is 
> determined by which hole was fixed yesterday.
>
> So, you are free to ask ship's crew about what hole and how to 
> fix and expect that it will tomorrow bring ship to a better 
> place, but without final destination this brownian movement may 
> theoretically last infinitely, but of course, in practice it 
> will lead either to ship crashing, departure of sailors or 
> finally targeting an unexpected place with unsatisfactory 
> result.

That's a very well worded post. That's one more reason why the 
most important thing imho is to have the current feature set 
stabilized, and not adding or removing features every other 
month, because we don't have enough experience with D to be 
certain such feature is redundant. This kind of experience can 
only be gained with feedback from hundreds or thousands of users, 
and there aren't that many users in this newsgroup.

D is large enough that I'm pretty sure no two programmers use the 
same features. That's why we have so different answers to the 
question "which features is useless ?". Yet every programmer has 
his favorite feature that saves his ass at one point or another, 
and that's why everybody finds it's a joy to use. Were it 
missing, someone would complain. I'm pretty confident that in a 
sufficiently large program, nearly every single feature of the 
language will be put to good use.

Now what people don't like is when features or Phobos don't work 
as expected, I suppose that's what you call holes. And that's 
another matter. I've browsed through hundreds of bug reports last 
week, and I could see many many features don't work as expected. 
And that's the most important problem in my opinion. That's where 
most of the efforts should be put.


More information about the Digitalmars-d mailing list