High level languages have always been compared to cognitive semantics and grammatical styles. That is the higher the level of the language the easier it is for us humans to read and write it. Conversely, the lower the level the language is the more discreet steps are needed to describe an instruction or data.
Speed of program languages or machine languages are not measured by how high or low level they are to us. They are also measured by time to develop and implement the program. The article basically makes a point of it, that it's "better to let someone else" to optimize the low-level code while you write with the high-level language. You could write a super fast machine coded program, but it'll take you much longer to write it than with a simpler higher level language.
The new debate is over datatypes and the available methods to manipulate them. Older hardware gave us the old debate with primitive datatypes and a general set of instructions to manipulate the data. Newer hardware can give us more than just primitives. For example, a unicoded string datatype seen by the hardware as a complete object instead of an array of bytes. With hardware instructions to manipulate unicoded strings, that would pratically take away any low-level implementation of unicoded strings. The same could be done for UTF-8 strings. We could implement hardware support for XML documents and other common protocols. How these datatypes are actually implemented in hardware is the center of the debate.
Eventually, there will be so many datatypes that there will be seperate low-level languages specifically designed for a domain a datatypes. The article makes the point there exists an increase in complexity for newer compliers to understand what was intended by a set of low-level instructions. Today's CPUs have a static limit of low-level instructions. The future beholds hardware implemented datatypes and their dynamic availability of low-level instructions. Newer processors will need to be able to handle the dynamic set of machine language instructions.
Does the new debate conflict with Turing's goal to simply make a processor unit extensible without the need to add extra hardware? For now, we have virtualization.
Has it been said exactly where the overall flow of the money is going? I mean it is a US firm and the money got put into EU hands. Is this also a way for the EU to take US money? Microsoft may deserve it, but does that mean in return it should affect the US security?
The key point to virtualization that is missed is the ability to seperate the device OS from the user OS. You run a virtualization software to give backwards compatiblity to current OS. The OS sees the devices and thinks they are real. This part is known.
Now, there can exists a new market for a device OS, with hardware support instead of software, that doesn't even have to touch the user OS. Linux, Microsoft, Mac, etc all have heavy ties to make the devices cooperate with the users. Instead, the device OS will be in a totally seperate environment. With today's new chips, the device OS could be on a totally seperate processor from the user OS. The user OS uses devices and communicates through portals to reach the device OS instead of directly to the hardware.
Security in a system where the devices are seperate from the user OS is greatly enhanced. Rootkits, and like, aren't possible from the user OS.
These used to be seperate in the past. That got put together under the same roof. Now, they have started to split up again.
Consider that there are those of us that run a server on a home network. The home server is very useful to have application run on the web within the home. Perhaps, the intention of the article appears to require some external service you have to pay for in order to get this functionality home. Surely, with a home server that hosts such web application, this is not the case, and we can do it freely at home without some extra pay service. How many people do you know run their own mail server and access it anywhere? The idea isn't new, and it doesn't need to be touted only in an ugly "pay for service" style.
Slashdot Mirror
High level languages have always been compared to cognitive semantics and grammatical styles. That is the higher the level of the language the easier it is for us humans to read and write it. Conversely, the lower the level the language is the more discreet steps are needed to describe an instruction or data.
Speed of program languages or machine languages are not measured by how high or low level they are to us. They are also measured by time to develop and implement the program. The article basically makes a point of it, that it's "better to let someone else" to optimize the low-level code while you write with the high-level language. You could write a super fast machine coded program, but it'll take you much longer to write it than with a simpler higher level language.
The new debate is over datatypes and the available methods to manipulate them. Older hardware gave us the old debate with primitive datatypes and a general set of instructions to manipulate the data. Newer hardware can give us more than just primitives. For example, a unicoded string datatype seen by the hardware as a complete object instead of an array of bytes. With hardware instructions to manipulate unicoded strings, that would pratically take away any low-level implementation of unicoded strings. The same could be done for UTF-8 strings. We could implement hardware support for XML documents and other common protocols. How these datatypes are actually implemented in hardware is the center of the debate.
Eventually, there will be so many datatypes that there will be seperate low-level languages specifically designed for a domain a datatypes. The article makes the point there exists an increase in complexity for newer compliers to understand what was intended by a set of low-level instructions. Today's CPUs have a static limit of low-level instructions. The future beholds hardware implemented datatypes and their dynamic availability of low-level instructions. Newer processors will need to be able to handle the dynamic set of machine language instructions.
Does the new debate conflict with Turing's goal to simply make a processor unit extensible without the need to add extra hardware? For now, we have virtualization.
Has it been said exactly where the overall flow of the money is going? I mean it is a US firm and the money got put into EU hands. Is this also a way for the EU to take US money? Microsoft may deserve it, but does that mean in return it should affect the US security?
The key point to virtualization that is missed is the ability to seperate the device OS from the user OS. You run a virtualization software to give backwards compatiblity to current OS. The OS sees the devices and thinks they are real. This part is known. Now, there can exists a new market for a device OS, with hardware support instead of software, that doesn't even have to touch the user OS. Linux, Microsoft, Mac, etc all have heavy ties to make the devices cooperate with the users. Instead, the device OS will be in a totally seperate environment. With today's new chips, the device OS could be on a totally seperate processor from the user OS. The user OS uses devices and communicates through portals to reach the device OS instead of directly to the hardware. Security in a system where the devices are seperate from the user OS is greatly enhanced. Rootkits, and like, aren't possible from the user OS. These used to be seperate in the past. That got put together under the same roof. Now, they have started to split up again.
Consider that there are those of us that run a server on a home network. The home server is very useful to have application run on the web within the home. Perhaps, the intention of the article appears to require some external service you have to pay for in order to get this functionality home. Surely, with a home server that hosts such web application, this is not the case, and we can do it freely at home without some extra pay service. How many people do you know run their own mail server and access it anywhere? The idea isn't new, and it doesn't need to be touted only in an ugly "pay for service" style.