Does D have too many features?

[Alex Rønne Petersen]

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

Yeah, we tried that in C++. It sucked.

The reason it works for many functional languages is that they have even 
more terse syntax than D. It would suck to make foreach a function in D.

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

Yeah, we tried that in C and C++. It sucked. See: Autotools.

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


-- 
- Alex