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
