steveh:

> I've known there are hidden tradeoffs when using these 'intelligent' types.

Right, every design has some trade-offs.


> Non-null types add terrible runtime checks everywhere.

This is not true. They may "add" some runtime checks, but in practice you 
normally need to perform those cheeks anyway, manually. In practice I think 
nonnull types may even reduce a bit the total number of cheeks present in 
critical paths (because if you have a nonnull, there is no need to test it 
again and again, once is enough).


> It's simply not acceptable in a systems programming language. Operating 
> system kernel uses very efficient uninitialized arrays for buffers. It's 
> crazy to force this non-null hype down our throats.

You are just not following the discussion and the things said. The normal 
pointers and references will keep being used in the same way and they will have 
no runtime cheeks (the compiler in safe modules may ask in some way for them to 
be tested before being used, this is a point not discussed enough yet in this 
thread).


> I fail to see why non-null is needed.

Huge C programs show that many features of D aren't actually necessary, you are 
able to program and live without them. But I think in theory nonull reference 
types may help avoid some bug.


> Sometimes even immutability seems too difficult.

It is :-)


> You can write safe code, you can write efficient code, and you can write 
> simple code. But these can't be the same code!

I agree that those are three things difficult to have at the same time. But I 
think D may allow you to pick two as you like, this is the good thing.


> Is Spec# used anywhere?

It's used in some universities to teach some ideas it contains. It has created 
the Contracts of C#4 and a verified C compiler, so even if Spec# dies today, it 
has done more than 98% of other languages invented so far.


> We should forget it.

Good ideas should be listened to despite the success of the language that 
contains them. History of computer languages if *full* of failed languages that 
have taught ideas to more successful languages. If you ignore the ideas just 
because they come from a failed language, they you are shutting yourself 95% of 
the progress and development in the story of language design :-)

Bye,
bearophile

Reply via email to