Does D have too many features?

[SomeDude]

On Saturday, 28 April 2012 at 23:25:10 UTC, foobar wrote:
> On Saturday, 28 April 2012 at 20:43:38 UTC, Timon Gehr wrote:
>> On 04/28/2012 09:58 PM, foobar wrote:
>>> On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright 
>>> wrote:
>>>> Andrei and I had a fun discussion last night about this 
>>>> question. The
>>>> idea was which features in D are redundant and/or do not add
>>>> significant value?
>>>>
>>>> A couple already agreed upon ones are typedef and the 
>>>> cfloat, cdouble
>>>> and creal types.
>>>>
>>>> What's your list?
>>>
>>> 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).
>>
>>
>> foreach is very useful. Have you actually used D?
>>
>
> I have used D and didn't claim that foreach isn't useful.
> What I said that is that it belongs in the library, NOT the 
> language.
>

Well, it's your opinion. But I bet it's not the opinion of 
thousands of programmers, it's not the opinion of the Java/C# 
designers, and I even believe they wanted to add foreach in C++ 
(or is it already the case ?).
Putting things in the library isn't the solution for everything: 
it's often hard (if possible) to make it work as well as in the 
core language, and error messages are usually more cryptic. Basic 
features like this should stay in the core language in my opinion.

>>> This is nothing more than a fancy function with
>>> a delegate parameter.
>>>
>>
>> That would be opApply.
>
> Indeed but I'd go even further by integrating it with ranges so 
> that ranges would provide an opApply like method e.g.
> auto r = BinaryTree!T.preOrder();  // returns range
> r.each( (T elem) { ...use elem...}); // each method a-la Ruby
>
>>
>>> * enum - enum should be completely redesigned to only 
>>> implement
>>> what it's named after: enumerations.
>>>
>>
>> What is the benefit?
>
> On the one hand the current enum for manifest constants is a 
> hack due to weaknesses of the toolchain and on the other hand 
> it doesn't provide properly encapsulated enums such as for 
> instance the Java 5.0 ones or the functional kind.
>
>>
>>> * version - this does not belong in a programming language. 
>>> Git
>>> is a much better solution.
>>>
>>
>> So you'd maintain a git branch for every OS if there is some 
>> small part that is OS-dependent? I don't think that is a 
>> better approach at all.
>
> It is far better than having a pile of #ifdef styled spaghetti 
> code.
> I'd expect to have all the OS specific code encapsulated 
> separately anyway,
> not spread around the code base. Which is the current 
> recommended way of using
> versions anyway. The inevitable conclusion would be to either 
> use a version management system like git or have separate 
> implementation modules for platform specific code and use the 
> build tool to implement the logic of select the modules to 
> include in the build.
>

No it isn't. Ask the kernel hackers why they still use #ifdef 
instead of using hundreds of git branches for every feature and 
platform they must maintain.

>>
>>> * 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.
>>>
>>> * This is a big one: get rid of *all* current compile time
>>> special syntax.
>>
>> What would that be exactly?
>
> This includes __traits, templates, static ifs, etc..
>
>>
>>> It should be replaced by a standard compilation
>>> API and the compiler should be able to use plugins/addons.
>>
>> Are you serious?
>
> No I'm joking.
>
> The current system is a pile of hacks on top of the broken 
> model of c++ templates.
>
> I should be able to use a *very* minimalistic system to write 
> completely _regular_ D code and run it at different times. This 
> is a simple matter of separation of concerns: what we want to 
> execute (what code) is separate to the concern of when we want 
> to execute it.
>
>
>>
>>> This would reduce the size of the language to half of its 
>>> current
>>> size, maybe even more.
>>
>> I am certain that it would not.
>>
>>
>> You missed to present the 'general purpose mechanisms'.


You should use Go. It fits better to your views about programming 
languages than D.