Eliminate assert and lazy from D?

[Andrei Alexandrescu]

bearophile wrote:
> Andrei Alexandrescu:
> 
>> This also brings up "lazy", which seems to be quite botched. Are
>> there suggestions on how to replicate its functionality in a
>> different way? I even seem to recall lazy was discussed as a
>> disadvantage in the recent dialog on reddit, see
>> 
>> http://www.reddit.com/r/programming/comments/9qf8i/i_wrote_some_d_today_and_its_completely_blowing/
>> 
> 
> I refuse that critics about lazy. They know D far less than me.
> 
> I like lazy as it is now, I use it often. It allows me to simulate
> (in a not perfect way, but sometimes acceptable) Python list
> comphrensions that no D dev seems interested in adding (or even
> understanding why they are useful, it seems) to the D language.

I use lazy too, it is sometimes useful. The problem is that lazy is very 
much an oddball. It's a storage class that actually changes
the type of a value. You sometimes need to add parens to get the value
of a lazy variable, and sometimes not. It's unclear how lazy works with
forwarding and how it interacts with templates. One litmus test is that
it's very difficult to explain someone how lazy exactly works. I think
it's a bad feature, and within reason we should clean the language of
bad features.

> General note: removing features from a language, making a language
> more general to allow programmers to implement such feature by
> themselves, sometimes looks positive. But you must keep in mind that
> it also has some drawbacks and costs. So you must always balance such
> costs with such advantages. For example compilation times and
> compilation memory may grow, the syntax may become a little worse,
> recovery in case of programmer/syntax mistakes may be a little worse,
> and error messages may become a little (or a lot) worse. The
> complexity of the language may increase, so people need a bit more
> time to learn the language (while learning higher-level built-in
> features often doesn't require a lot of time). A higher number of low
> level & general features (necessary to manually implement the higher
> level features that have being removed) make the language more
> flexible, but this is the kind of flexibility of an "amoeba", like
> Forth & Lisp, that despite being very flexible languages with 30-45+
> years of life, can become hard to use, quite hard to understand, and
> so on. Languages that hope to become very widespread have to offer a
> very well chosen set of features, must not offer too much
> flexibility, they need a certain amount of rigidity and "internal
> constraints" that make them a bit less flexible and nice, but make
> them fit for teams of programmers to build large programs (see the
> success of Java/C#, etc). So every time you want to remove a
> higher-level built-in feature you have to think about those factors
> too.

IMHO what makes a language real hard to learn and use is the presence of 
misdesigned features. Then I'm not sure what you enjoy. Usually you're 
all for adding features (hey, you just brought up the switch again! 
isn't that ironic?) and cleaning up bad parts of the language, and now 
all of a sudden you wax poetic about this and that and the other, few of 
which have anything to do with the topic at hand.

Next time I'll try a post "Let's keep lazy in the language" - that's 
bound to get a better response.


Andrei