Creating Something Out of Nothing
Sunday, 4. December 2005, 16:35:04
What if I told you that if you wanted to drive, you had to get rid of your steering wheel. If you wanted to fly, you had to get rid of the pilots and the wings too. If you wanted to write software, you had to get rid of the programming language.
What are the building blocks of any language? Operators. Nothing gets done without operators. In C, C++ and Java, there are quite a few. Many of these are unecessary, yet useful. For example, multiplication can be simulated with addition and shifting. Negation can be simulated with XOR and adding 1. There are many operators that simply build on top of others. This is like the CISC version or programming languages. Complex Instruction Set Language. CISL.
In assembler, if another instruction comes out, I can start using it right away. In high level languages, if I want to add another operator that cannot be built from existing operators, what do I do? I have to resort to inline assembly. Or in the case of Java, I can pull my hair out.
Basically, high level languages are like a restricted form of assembly. Where you have a set of instructions and can build other intructions based on these ones either in the form of operator overloading or function or higher yet classes. Why they have three different categories of grouping is beyond me. You have operators, functions and classes. Would not one type suffice? They all group instructions and data. They all work basically the same.
The real issue is not that they have three different classifications for the same thing. The problem is that functions must be built with the basic set of operators. Even if some operators are overloaded, they are also functions and thus resolve down to a sequence of the basic set of operators. For classes, it's the same thing. They simply group things even more. And you can assign operators for the class. But these must all resolve down to the basic set of operators that the language provides.
Just as you have primitive types, you have primitive instructions. Or rather operators. While some languages claim that everything is an object, they forget about operators. Most languages have both primitive types and primitive operators as well as objects, yet no corresponding equivalent for operators.
You may think that's a rather odd idea. And in any case, objects group not only data, but also functions which contain sequences of operators. That's not the issue. The issue is that you can create new types, but not new operators.
Here's what I mean. I can create a class for large integers. Integers that are larger than the normal 32bits. What if I make a class that handles 128 bit integers. I can create an internal data storage to store this number. I can overload operators so that you can add, subtract, multiply, etc. But wait a second. No, I cannot do this. I do not have access to the hardware instructions that actually provide 128bit addition, subtraction and other operations. With MMX and ISSE, these are now available. But they are not provided in the language. While I can use the class as if it's a new type, I cannot use the operators. The overloaded operators must use the original set of operators provided by the language even though there is a perfectly acceptable CPU instruction that can add and subtract 128bit integers.
Every language in existance today, whether a VM or compiled, gives you a primitive set of instructions and you're stuck with that. There can be no expansion. There is no mechanism in the language to create truly new operators.
I have done away with all this. I have removed the operators entirely. I have removed almost everything entirely. You can group things together, but what they actually are is dependant on you. You can set this group to be a function, a class, an operator... anything you wish. You then create other code that tells the compiler what to do with it. The same for operators. If these are built on top of operators, then it's simply as every other language does it. But at some point, these operators cannot be divided any further. These are the 7 tenets of computing that I described in an earlier blog entry. These you could output machine ar assembly language or whatever else you wish that will make the hardware work.
You can also use this same mechanism to describe more complicated operators of functions such as shifting, multiplications, vector operations, etc... If these basic CPU instructions aren't available on other computers, then it will decompose in a normal manner into more primitive operations.
So instead of working bottom up... from a set of primitive instructions and data types and put these together to build programs, I turned this idea upside down and decided to work from the plan down. You build the ideas and concepts first. Then go down into ever more precise details all the way down to the machine. So when you port, if the primitive operators (a library of sorts) is available, you can compile your same source code on this new computer. Only the most primitive of operators will be substituted for the appropriate ones on this computer. Not only that, but if there are assembler equivalents to higher concept (functions), then these will also be replaced with the CPU equivalent.
This is why it's important to have a standard library of concepts. Especially for OS functionality. These should be standard operators or classes as well. They simply have a different implementation on different computers.
A language that doesn't let you create new operators that aren't based on existing operators is a dead-end language, or at least not a general purpose one. I have no problem with languages that have a specific use though. But Java and C++ claim to be general purpose languages. I ask you this. Create in C++ a new operator, but you can't use any existing operator inside the code. This is a completely new operation that cannot be simulated. How would you do it? You can't in Java because Sun made sure of that by going to court against MS. So Sun has announced that its language is not a viable option for the future. In C++, you have to resort to assembler language. The only problem is that there's no standard way of having this code replaced on other computers and you have to rewrite everything every time.
The next step in language evolution will be able to create new operators or instructions that are not dependant on existing operators. Where you can program at any level of abstraction. If you want to code in really high concepts with classes, you can. If you want to handle how things are done on a certain machine down to the hardware, you can. When you port, the compiler will tell you if anything isn't able to be converted to the new CPU and you can simply convert those parts and be done with it. Actually, it won't convert anything. Anything that is marked for the other CPU won't be used. The code for any operators on this computer will be used instead.
And if current languages are any indication, you will not have to recode anything that often. But it will be useful for games and simulators that need to get the most out of current hardware. Right now, they must resort to inline assembler. It will be somewhat true in the future as well, but at least it will be better structured and there will be a better and simpler way of doing this.
Why is there such a hoopla about primitive types and that a truly OO language has everything as an object? Yet, they continue to have primitive operators. You can create new data types, but not operators? Since when has data become more important than the instructions that operate on them? I have no problem with primitive types and operators. What I have a problem with is being able to create new data types and new operators alike. Not having that feature is the bane of all current languages. No current language is truly extensible. Not even assembler, but at least they can create a macro, but those do not truly work like the other instructions in the language.
With data, everything is built with bytes. So current languages have been able to create new data types by grouping bytes together. Operators do not work this way. But what if we come out with another type of data storage that doesn't work in the conventional sense? What are we to do? How will current languages cope? They can't. They will have to build something from scratch.
In my programming environment, you can simply define the new data type and describe how it is to be handled. You can even re-use existing software with this new technology. The data will be automatically "converted" if you so desire. You don't have to wait for a new version of the compiler. You don't have to wait for the next version of the VM. In fact, you can never be sure a new version will come out at all because the language isn't made to be extensible. The best you could hope for is a custom native library. Not exactly transparent integration.
It is strange to see a disparity between the hardware world and the software world. In the hardware world, new technologies come out all the time. Faster and better ways to do things. New devices, new data storage, new display, new CPU's, new GPU's, etc... But in the software world... stagnation. No new operators. No new constructs to take advantage of these new technologies. While data storage concepts such as the class have become more prevalent, the concept of new ways to handle this data has been met with resistance... nay, outright refusal.
In reality, I think I'm hoping someone will take my ideas and create something. But I doubt they will ever understand these concepts as much as I do. I've read books on top languages designers in the field and they are oblivious. It hasn't even crossed their minds and not a single one has ever mentioned this concept with operators. Of course not, it would corrupt their ideology of a high level language.
Top down instead of bottom up. I feel so ashamed for the computing world that no one has thought of it before for programming languages. And we wonder why things haven't changed.
What are the building blocks of any language? Operators. Nothing gets done without operators. In C, C++ and Java, there are quite a few. Many of these are unecessary, yet useful. For example, multiplication can be simulated with addition and shifting. Negation can be simulated with XOR and adding 1. There are many operators that simply build on top of others. This is like the CISC version or programming languages. Complex Instruction Set Language. CISL.
In assembler, if another instruction comes out, I can start using it right away. In high level languages, if I want to add another operator that cannot be built from existing operators, what do I do? I have to resort to inline assembly. Or in the case of Java, I can pull my hair out.
Basically, high level languages are like a restricted form of assembly. Where you have a set of instructions and can build other intructions based on these ones either in the form of operator overloading or function or higher yet classes. Why they have three different categories of grouping is beyond me. You have operators, functions and classes. Would not one type suffice? They all group instructions and data. They all work basically the same.
The real issue is not that they have three different classifications for the same thing. The problem is that functions must be built with the basic set of operators. Even if some operators are overloaded, they are also functions and thus resolve down to a sequence of the basic set of operators. For classes, it's the same thing. They simply group things even more. And you can assign operators for the class. But these must all resolve down to the basic set of operators that the language provides.
Just as you have primitive types, you have primitive instructions. Or rather operators. While some languages claim that everything is an object, they forget about operators. Most languages have both primitive types and primitive operators as well as objects, yet no corresponding equivalent for operators.
You may think that's a rather odd idea. And in any case, objects group not only data, but also functions which contain sequences of operators. That's not the issue. The issue is that you can create new types, but not new operators.
Here's what I mean. I can create a class for large integers. Integers that are larger than the normal 32bits. What if I make a class that handles 128 bit integers. I can create an internal data storage to store this number. I can overload operators so that you can add, subtract, multiply, etc. But wait a second. No, I cannot do this. I do not have access to the hardware instructions that actually provide 128bit addition, subtraction and other operations. With MMX and ISSE, these are now available. But they are not provided in the language. While I can use the class as if it's a new type, I cannot use the operators. The overloaded operators must use the original set of operators provided by the language even though there is a perfectly acceptable CPU instruction that can add and subtract 128bit integers.
Every language in existance today, whether a VM or compiled, gives you a primitive set of instructions and you're stuck with that. There can be no expansion. There is no mechanism in the language to create truly new operators.
I have done away with all this. I have removed the operators entirely. I have removed almost everything entirely. You can group things together, but what they actually are is dependant on you. You can set this group to be a function, a class, an operator... anything you wish. You then create other code that tells the compiler what to do with it. The same for operators. If these are built on top of operators, then it's simply as every other language does it. But at some point, these operators cannot be divided any further. These are the 7 tenets of computing that I described in an earlier blog entry. These you could output machine ar assembly language or whatever else you wish that will make the hardware work.
You can also use this same mechanism to describe more complicated operators of functions such as shifting, multiplications, vector operations, etc... If these basic CPU instructions aren't available on other computers, then it will decompose in a normal manner into more primitive operations.
So instead of working bottom up... from a set of primitive instructions and data types and put these together to build programs, I turned this idea upside down and decided to work from the plan down. You build the ideas and concepts first. Then go down into ever more precise details all the way down to the machine. So when you port, if the primitive operators (a library of sorts) is available, you can compile your same source code on this new computer. Only the most primitive of operators will be substituted for the appropriate ones on this computer. Not only that, but if there are assembler equivalents to higher concept (functions), then these will also be replaced with the CPU equivalent.
This is why it's important to have a standard library of concepts. Especially for OS functionality. These should be standard operators or classes as well. They simply have a different implementation on different computers.
A language that doesn't let you create new operators that aren't based on existing operators is a dead-end language, or at least not a general purpose one. I have no problem with languages that have a specific use though. But Java and C++ claim to be general purpose languages. I ask you this. Create in C++ a new operator, but you can't use any existing operator inside the code. This is a completely new operation that cannot be simulated. How would you do it? You can't in Java because Sun made sure of that by going to court against MS. So Sun has announced that its language is not a viable option for the future. In C++, you have to resort to assembler language. The only problem is that there's no standard way of having this code replaced on other computers and you have to rewrite everything every time.
The next step in language evolution will be able to create new operators or instructions that are not dependant on existing operators. Where you can program at any level of abstraction. If you want to code in really high concepts with classes, you can. If you want to handle how things are done on a certain machine down to the hardware, you can. When you port, the compiler will tell you if anything isn't able to be converted to the new CPU and you can simply convert those parts and be done with it. Actually, it won't convert anything. Anything that is marked for the other CPU won't be used. The code for any operators on this computer will be used instead.
And if current languages are any indication, you will not have to recode anything that often. But it will be useful for games and simulators that need to get the most out of current hardware. Right now, they must resort to inline assembler. It will be somewhat true in the future as well, but at least it will be better structured and there will be a better and simpler way of doing this.
Why is there such a hoopla about primitive types and that a truly OO language has everything as an object? Yet, they continue to have primitive operators. You can create new data types, but not operators? Since when has data become more important than the instructions that operate on them? I have no problem with primitive types and operators. What I have a problem with is being able to create new data types and new operators alike. Not having that feature is the bane of all current languages. No current language is truly extensible. Not even assembler, but at least they can create a macro, but those do not truly work like the other instructions in the language.
With data, everything is built with bytes. So current languages have been able to create new data types by grouping bytes together. Operators do not work this way. But what if we come out with another type of data storage that doesn't work in the conventional sense? What are we to do? How will current languages cope? They can't. They will have to build something from scratch.
In my programming environment, you can simply define the new data type and describe how it is to be handled. You can even re-use existing software with this new technology. The data will be automatically "converted" if you so desire. You don't have to wait for a new version of the compiler. You don't have to wait for the next version of the VM. In fact, you can never be sure a new version will come out at all because the language isn't made to be extensible. The best you could hope for is a custom native library. Not exactly transparent integration.
It is strange to see a disparity between the hardware world and the software world. In the hardware world, new technologies come out all the time. Faster and better ways to do things. New devices, new data storage, new display, new CPU's, new GPU's, etc... But in the software world... stagnation. No new operators. No new constructs to take advantage of these new technologies. While data storage concepts such as the class have become more prevalent, the concept of new ways to handle this data has been met with resistance... nay, outright refusal.
In reality, I think I'm hoping someone will take my ideas and create something. But I doubt they will ever understand these concepts as much as I do. I've read books on top languages designers in the field and they are oblivious. It hasn't even crossed their minds and not a single one has ever mentioned this concept with operators. Of course not, it would corrupt their ideology of a high level language.
Top down instead of bottom up. I feel so ashamed for the computing world that no one has thought of it before for programming languages. And we wonder why things haven't changed.
WIDGETIZE
How to use Quote function: