• bearophile <bearophileHUGS lycos.com> Nov 30 2010
• Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Nov 30 2010

bearophile <bearophileHUGS lycos.com> writes:

Andrei:

 Wonder how the reply is related to the quote.


Sorry, I meant that if your purpose is to "allow many good designs to
expressible as easily as possible" you risk creating a puzzle language as
Scheme or Forth. So you have to be careful in how much flexibility you give to
your language. Some hardcoding or some less general features make a language
less flexible, but avoid some of the risk of turning programming into a kind of
puzzle solving.

Sometimes it's also a matter of who uses the language. A very flexible language
like CLisp is good in the hands of a very intelligent programmer, but for most
other people a less flexible language (as Java) is better and has less risks.


 Same discussion goes about non-nullable. We don't need the compiler to
 understand non-nullable types, we need to imbue the compiler with the
 ability to enforce arbitrary user-defined state invariants, non-null
 being one of them.


I see, you are saying that if D3 adds typestates (maybe managed through
user-defined attributes), then implementing full nonnullable semantics probably
becomes easy enough :-)

Bye,
bearophile

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 11/30/10 3:23 PM, bearophile wrote:
 Andrei:

 Wonder how the reply is related to the quote.


 Sorry, I meant that if your purpose is to "allow many good designs to
 expressible as easily as possible" you risk creating a puzzle
 language as Scheme or Forth. So you have to be careful in how much
 flexibility you give to your language. Some hardcoding or some less
 general features make a language less flexible, but avoid some of the
 risk of turning programming into a kind of puzzle solving.


The explanation doesn't add up any more than the original retort. I 
would understand the comment in case I would have said: "the key is to 
make the language as flexible as possible".

 Sometimes it's also a matter of who uses the language. A very
 flexible language like CLisp is good in the hands of a very
 intelligent programmer, but for most other people a less flexible
 language (as Java) is better and has less risks.
 Same discussion goes about non-nullable. We don't need the compiler to
 understand non-nullable types, we need to imbue the compiler with the
 ability to enforce arbitrary user-defined state invariants, non-null
 being one of them.


 I see, you are saying that if D3 adds typestates (maybe managed
 through user-defined attributes), then implementing full nonnullable
 semantics probably becomes easy enough :-)


Well I wasn't saying that either :o).


Andrei