Does D have too many features?

[H. S. Teoh]

On Sat, Apr 28, 2012 at 09:58:02PM +0200, foobar wrote:
[...]
> D has a lot of ad-hock features which make the language
> needlessly large and complex. I'd strive to replace these with
> better general purpose mechanisms.
> 
> My list:
> * I'd start with getting rid of foreach completely. (not just
> foreach_reverse). This is nothing more than a fancy function with
> a delegate parameter.

I disagree. Having a dedicated foreach construct allows the compiler to
optimize away the delegate in certain cases. I wouldn't want to incur
the cost of creating and passing a delegate in something as simple as
foreach (i; 0..100), for example.


> * enum - enum should be completely redesigned to only implement
> what it's named after: enumerations.

Actually, I rather like the enum idiom of declaring compile-time
constants. Though it could do with a renaming to something more
befitting.


> * version - this does not belong in a programming language. Git
> is a much better solution.

This is an interesting idea. But using separate git branches just for
having versioned code seems a bit like total overkill... plus a
maintenance nightmare since you have to continue pull and merge changes
to every porting branch every time development happens. Whereas having
everything represented in source means that whoever writes a new feature
is also responsible for making it work with whatever versions are
currently out there. After-the-fact fixes are always painful.


> * di files - a library should encapsulate all the info required
> to use it. Java Jars, .Net assemblies and even old school; Pascal
> units all solved this long ago.

I proposed a while ago that .di files should be replaced by something
better: omit ALL function bodies, template bodies, private members,
etc., and just keep the "real" public API in the human-readable part of
the file. Function and template bodies should be kept in as a binary
blob readable by the compiler (which obviously needs to know them
otherwise it won't be able to expand templates).

(Yes the binary blob can be reverse-engineered, but so can executables,
so it's a moot point. We're not trying to write cryptographic security
here, but it's nice to separate what the compiler needs to know vs. what
the user of a library needs to know.)


> * This is a big one: get rid of *all* current compile time
> special syntax. It should be replaced by a standard compilation
> API and the compiler should be able to use plugins/addons. This
> would reduce the size of the language to half of its current
> size, maybe even more.

I have to disagree here. CTFE and compile-time features is a major
reason I like D. I argue rather that compile-time features should be
*improved*. The current situation is good, but not quite there yet. It
can be made better.


T

-- 
Be in denial for long enough, and one day you'll deny yourself of things you wish you hadn't.