Does D have too many features?

[Timon Gehr]

On 04/28/2012 11:05 PM, q66 wrote:
> On Saturday, 28 April 2012 at 20:50:30 UTC, H. S. Teoh wrote:
>> On Sat, Apr 28, 2012 at 09:22:59PM +0200, q66 wrote:
>> [...]
>>> - AAs integrated in the language; you barely ever use AA literals and
>>> having them purely in Phobos would help get rid of the runtime fat, as
>>> well as better implementations
>>
>> On the contrary, AA's are a major reason I started programming in D. In
>> this day and age, it's simply inexcusable to *not* have some kind of
>> hash type available by default.
>>
>
> Besides AA literals, library can handle this JUST FINE.
>

That is why they should be a narrow wrapper around a library defined type.

>>
>>> - Phobos is too fat - it needs to shrink to just a few core modules,
>>> others being distributed via some system like CPAN for Perl
>>
>> Um... that's what a *library* is supposed to be: a large collection of
>> useful stuff from which you can pick the few that you need right now.
>>
>
> Too large collection becomes too hard to manage. Separating it and
> distributing in style "you pay for what you use" is IMO the right approach.
>

This sounds reasonable.

>>
>>> - Properties - they're kinda broken at this point and the value is
>>> questionable
>>
>> What kind of properties are you referring to?
>>
>
> The @property crap. It's broken. If anything, it needs something like in
> C#.
>

As I understand it, the 'agreed upon' design is that

@property int foo() { return x; }
@property void foo(int v) { x = v; }

Would be completely equivalent to C#:

int foo { set{ x = value; }; get{ return x; } }

I think it is even perfectly fine to just allow function calls without 
parentheses, but I wouldn't mind seeing that feature gone.

>>
>>> - @trusted @system
>>
>> These are necessary.
>>
>
> They're far from necessary.
>

Why? Memory safety is generally considered to be important.

>>
>>> - Exception handling - a lot of runtime, questionable value
>>
>> I completely disagree. No exception handling means lots and lots and
>> lots of boilerplate code for checking error codes, return values, which
>> are too tedious to write, which translates to many people leaving them
>> out and ending up with unreliable code that fail silently or crash
>> outright when a function call they assumed would work stopped working.
>>
>> If you've worked in large multi-person projects, you'll see very quickly
>> why you *need* exception handling. No modern language can do without
>> exception handling. Maybe you have a beef with how it's currently done
>> in D, but regardless, you *need* exception handling of some kind.
>>
>
> The exception handling system via try/catch is as bad and tedious as
> error codes, except the added runtime.

It can improve performance though, because the exceptional branches 
don't occur in the code that is normally executed.

> It all roots from the idea "catch everything that throws".
> This is broken, as you DON'T always need to
> handle all sorts of errors (letting it segfault or something sometimes
> simply proves to be better than trying to save the situation;

Except that it won't necessarily segfault.

That is not how _reliable_ systems work. Robustness is an important 
property of critical systems. If your software might kill people if it 
behaves in the wrong way, you really really don't want to ignore error 
conditions.

> or you can simply assert it).

Certainly, if it is a consistency criterion internal to the program, 
then assertions should be used.

> Also http://yosefk.com/c++fqa/exceptions.html#fqa-17.1
> [snip.]

The part of this article relevant for D is this:

"Still, in many cases, the benefits of exceptions are more important 
than their problems. For example, if your language manages memory 
automatically, the problem of releasing acquired resources becomes a 
small one (you only have to care about files, etc., which are a tiny 
part of the "resources" used by a program - most of the "resources" are 
memory). If your language throws exceptions when you violate its rules 
(for example, upon out-of-bounds array access), these exceptions will 
help you find lots of bugs, especially if you can get the call stack 
from an exception. If the purpose of an application is automated 
testing, and/or it's used as a quick-and-dirty internal tool as opposed 
to a product for an end user, this kind of exceptions is all you need to 
handle errors of almost all kinds. In some languages, you can even 
resume the execution from the point where the exception was raised after 
fixing the problem at the point where it was caught."

Anyway, I generally avoid exceptions if they are not an obvious fit.