Does D have too many features?

H. S. Teoh hsteoh at quickfur.ath.cx
Sat Apr 28 14:35:39 PDT 2012


On Sat, Apr 28, 2012 at 11:05:10PM +0200, 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.

I'm the one who's working on moving AA's out of the compiler into
druntime, y'know... ahhh the irony.


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

Wat? A library *is* paying only for what you use. A properly designed
library only pulls in what is absolutely necessary to make feature X
work, where feature X is what you asked for. Walter has stated that he
wishes to move in this direction, especially in Phobos. This is
orthogonal to having plenty of stuff *available* in the library (it's
there for your use, you don't *have* to use it -- stuff you don't used
don't get compiled into your program).


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

Yeah D needs some work in this area. But I don't use properties, though,
so I can't say I see the usefulness of them.


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

Explain.


[...]
> >>- 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 all roots from the idea
> "catch everything that throws".

That's a misconception of what exceptions are.


> 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; or you can simply assert it).

On the contrary, having a proper exception system allows you to handle
errors which you can, and propagate the rest. In many large-scale
enterprise systems you *need* to do this. Having no exception handling
built into the language means doing it yourself, which means lots and
lots and lots of boilerplate code everywhere (with a few missing places
which will come back to bite you when your code is running on mission
critical servers on your customer's production site), which also means
it's much more likely to write wrong code. Boilerplate is never a plus,
ever.


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

C++ is hardly the model for what exception handling should be. If that's
where you got your impression of exceptions from, then I'm not surprised
you're so averse to them. C++'s implementation of exceptions is so
fundamentally b0rken it's not even funny. Try using them in a language
where they're implemented in a much saner way than C++, and you might
even start to like them.


> >>- Versions - not redundant, but needs a better system (with AND/OR,
> >>possibility of de-versioning, the assignment op to set versions is
> >>kinda bad)
> >[...]
> >
> >I find versions sorta neat... and they're simple enough that they
> >don't add to much bloat to the language. (Whereas if you added AND
> >and OR to them, then they start duplicating the function of static
> >if, and that's when they become redundant.)
> >
> 
> They're nearly unusable now. And the syntax simply makes no sense.
[...]

Yeah I agree the syntax leaves much to be desired.


T

-- 
I'm still trying to find a pun for "punishment"...


More information about the Digitalmars-d mailing list