Does D have too many features?

[Alex Rønne Petersen]

On 29-04-2012 01:49, SomeDude wrote:
> 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.

C++11 has range-based for (which is basically foreach).

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


-- 
- Alex