I wish I could use D for everything

[Brad Roberts]

dsimcha wrote:
> == Quote from Brad Roberts (braddr at puremagic.com)'s article
>> dsimcha wrote:
>>>  D2 is a complex language, but it's not complex in a haphazard way.  It's complex
>>> because it statically proves stuff about your code (const, etc), and allows
>>> extremely powerful, generic user-defined types.  These are the kinds of things
>>> that most people only dream about.
>> I'd like to drill into this 'd2 is a complex language' assertion more.  Can we
>> build a factual list of the delta of complexity between d1 and d2?
>> The primary area is the type system:
>>   1) introduction of const
>>       -- optional and doesn't affect callers of api's that declare const params
>>   2) introduction of immutable
>>       -- less optional since it's not as coercable, but also less frequently
>> used in apis.
>>   3) introduction of pure
>>       -- optional, will not affect callers of apis
>>   4) introduction of nothrow
>>       -- optional, will not affect callers of apis
>> Others:
>> 5) template if clause
>> I'm specifically leaving out Phobos and other library layer issues, though feel
>> free to count the runtime as part of the language when adding to this list.
>> -- Brad
> 
> Template alias parameters, ref returns, shared (even though it's not implemented,
> it's on its way, so it still counts), closures, alias this, template literals,
> struct ctors and dtors (and in general structs becoming more like classes) to name
> a few.  I love all of these, and I personally think the complexity is justified.
> It's just that I don't know how easy it would be to convince someone coming from
> Java of this, so I'm playing devil's advocate a little.
> 
> On the other hand, I do see a pattern here:  Most of these features are things you
> only need to care about if you're writing near the tip of the pyramid, stuff like
> generic, reusable code.  In fact, I've realized that my mindset when coding in D
> is completely different when working on something that aims to be extremely
> generic (like rangeextra or dstats, stuff I wouldn't even be able to do in any
> language besides D) vs. when working on day-to-day code that just has to solve one
> problem well.  The latter is a lot easier, but also a lot less fun, from a
> programming perspective.

I'm going to play devils advocate too...

struct ctor/dtor's are simplifiers.  They remove a hard to explain difference
and aren't even a little bit hard to understand.

I'm tempted to say the same about ref return, but we can leave it in the adds
column.

The rest I'll agree with (at least enough not to quibble much).


-- Brad