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. 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 wi! th 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. Bye, bearophile
