int n = random();
arran[n];
Tim Sweeney on programming languages
Author
Link.
Some of his statements lead me to believe he has no idea what he is talking about. For example, he suggests that array bounds access should be entirely verified at compile time. How does he propose to statically verify this:
Yet at the same time, it's completely inexcusable that this is perfectly good C code:
int arr[10];
arr[11] = 2346;
You may not be able to check everything statically, but you should check as much as you possibly can.
Also, if we assume that random() is something that returns any 32 bit int, some stricter type checking for boundedness may be statically resolvable as well. For example:
int arr[10];
int n = random() % 10;
arr[n] = 5;
Compiles, but:
int arr[10];
int n = random();
arr[n] = 5;
Does not compile. That would be another potential static check to do.
int arr[10];
arr[11] = 2346;
You may not be able to check everything statically, but you should check as much as you possibly can.
Also, if we assume that random() is something that returns any 32 bit int, some stricter type checking for boundedness may be statically resolvable as well. For example:
int arr[10];
int n = random() % 10;
arr[n] = 5;
Compiles, but:
int arr[10];
int n = random();
arr[n] = 5;
Does not compile. That would be another potential static check to do.
EDIT: Damn I missed your last sentence where you gave the same idea I have just written, anyway could you give an example where it couldn't be checked statically?
Well that might not be able to check at compile-time in C, C++, C#, Java etc. but this isn't about adding his features to existing languages. Say a function could be defined like this:
This would mean that random will return a type between 0 and 2^32 (0xFFFFFFFF), so in your example the compiler would see that there is a possibility that it will result in an access outside the array.
In the same way you might for input have:
Now here the compiler would also be able to see that there is a possibility that we will access an element outside keys.
Now defining such return type could be a big problem, especially if for example 1, 6, 15 and a lot of other numbers can be returned (Especially if programmers can define "wrong" ranges, which could easily introduce hard to catch errors).
A better approach would be to make the compiler determine the range of the return value. The functions provided by the compiler could have the return value range specified and then the compiler could figure out the types itself. Take this simple example:
Here the compiler sees that random and random both have a minimum of 0 and a maximum of 2^32 so the minimum of special_random is 0*0 = 0 and the maximum of special_random is 2^32 * 2^32 = 2^64. If the language can do the same as assembly language I can see no case where the compiler can't figure out the return-value range. I can see two problems (and the second not being a big one).
This was just something I thought about, so there is most likely better alternatives.
Well that might not be able to check at compile-time in C, C++, C#, Java etc. but this isn't about adding his features to existing languages. Say a function could be defined like this:
int[0,2^32] random(){ stuff.}This would mean that random will return a type between 0 and 2^32 (0xFFFFFFFF), so in your example the compiler would see that there is a possibility that it will result in an access outside the array.
In the same way you might for input have:
int[0,MAX_KEYS] get_key(){ stuff.}key_state keys[MAX_KEYS-1];keys[get_key()].pressed = true;Now here the compiler would also be able to see that there is a possibility that we will access an element outside keys.
Now defining such return type could be a big problem, especially if for example 1, 6, 15 and a lot of other numbers can be returned (Especially if programmers can define "wrong" ranges, which could easily introduce hard to catch errors).
A better approach would be to make the compiler determine the range of the return value. The functions provided by the compiler could have the return value range specified and then the compiler could figure out the types itself. Take this simple example:
// random is defined to return an int between 0 and 2^32int special_random(){ return random()*random();}Here the compiler sees that random and random both have a minimum of 0 and a maximum of 2^32 so the minimum of special_random is 0*0 = 0 and the maximum of special_random is 2^32 * 2^32 = 2^64. If the language can do the same as assembly language I can see no case where the compiler can't figure out the return-value range. I can see two problems (and the second not being a big one).
This was just something I thought about, so there is most likely better alternatives.
Quote:Original post by CoffeeMug
Some of his statements lead me to believe he has no idea what he is talking about.
lol, I didn't like it either...
using a couple of assert's and good programming practices, most of the problems he talked about will be gone.
Quote:Original post by XeeeQuote:Original post by CoffeeMug
Some of his statements lead me to believe he has no idea what he is talking about.
lol, I didn't like it either...
using a couple of assert's and good programming practices, most of the problems he talked about will be gone.
Yes, but wouldn't it be better if the compiler did all that?
Quote:Original post by XeeeBecause god knows Tim Sweeney wouldn't know anything about designing scalable, robust, extensible, and stable software that can survive major changes in technology and requirements.Quote:Original post by CoffeeMug
Some of his statements lead me to believe he has no idea what he is talking about.
lol, I didn't like it either...
using a couple of assert's and good programming practices, most of the problems he talked about will be gone.
Quote:Original post by gregs
See my comment in this thread.
See my comments where I show gregs is just talking rubbish and completely out of context.
Author
Quote:Original post by Promit
Because god knows Tim Sweeney wouldn't know anything about designing scalable, robust, extensible, and stable software that can survive major changes in technology and requirements.
Does that in any way imply that he's a programming language design guru and cannot possibly make statements that he pulled out of his ass?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
