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

Reply via email to