Does D have too many features?

[Alex Rønne Petersen]

On 28-04-2012 23:41, Timon Gehr wrote:
> 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; } }

Nope.

First of all, you'd have to declare the setter like this in D:

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

so that you can write:

int v = obj.foo = 1; // valid C#

Next up is the issue of op-assign operations. In D, you can't do:

obj.foo += 1;
obj.foo++;

while in C#, you can (it results in a get -> add 1 -> set and get -> inc 
-> set, etc).

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


-- 
- Alex