Signed word lengths and indexes

[Walter Bright]

bearophile wrote:
> Don:
> 
>> Indeed, only a subset of D is useful for low-level development.<
> 
> A problem is that some of those D features (that are often useful in
> application code) are actively negative for that kind of development.
> 
> 
>> But D has more close-to-the-metal features than C does.<
> 
> I don't know if those extra D features are enough.

Since it has more than C does, and C is used for kernel dev, then it must be enough.

> And the C dialect used for
> example by Linux is not standard C, it uses many other tricks. I think D
> doesn't have some of them (I will try to answer this better to a Walter's
> post).

I'll await your reply there.


>> So I agree that describing the data is important, but at the same time, the
>> things that really need the most description are how the data hangs
>> together, what the consistency requirements are, what the locking rules are
>> (and not for a single data object either), etc etc. And my suspicion is
>> that you can't easily really describe those to a compiler. So you end up
>> having to write that code yourself regardless. And hey, maybe it's because
>> I do just low-level programming that I think so. As mentioned, most of the
>> code I work with really deeply cares about the kinds of things that most
>> software projects probably never even think about: stack depth, memory
>> access ordering, fine-grained locking, and direct hardware access.<
> 
> D gives few more ways to give complex semantics to the compiler, but probably
> other better languages need to be invented for this. I think it is possible
> to invent such languages, but maybe they will be hard to use (maybe as Coq
> http://en.wikipedia.org/wiki/Coq ), so they will be niche languages. Such
> niche can be so small that maybe the work to invent and implement and keep
> updated and debugged such language is not worth it.


With all due respect to Linus, in 30 years of professionally writing software, 
I've found that if you solely base improvements on what customers ask for, all 
you have are incremental improvements. No quantum leaps, no paradigm shifts, no 
game changers.

To get those, you have to look quite a bit beyond what the customer asks for. It 
also requires understanding that if a customer asks for feature X, it really 
means he is having problem Y, and there may be a far better solution to X than Y.

One example of this is transitive immutability. Nobody asked for it. A lot of 
people question the need for it. I happen to believe that it offers a quantum 
improvement in the ability of a programmer to manage the complexity of a large 
program, which is why I (and Andrei) have invested so much effort in it, and are 
willing to endure flak over it. The payoff won't be clear for years, but I think 
it'll be large.

Scope guard statements are another example. So are shared types.