Does D have too many features?

[Adam Wilson]

On Sat, 28 Apr 2012 14:03:26 -0700, H. S. Teoh <hsteoh at quickfur.ath.cx>  
wrote:

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

I have written code that will do just that. You can check it out here:  
https://github.com/LightBender/dmd.git. It builds both the DRuntime and  
Phobos perfectly, however, the Phobos makefile has not yet been updated to  
generate DI files. However, Phobos uses the Druntime DI files for it's  
build.

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


-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/