for faster programming
to eliminate a lot of needless typing, the F-keys could be mapped to the most common key words and symbols for the given language. of course, symbols that don't require the shift key would be left out.
intellisense helps but it's not the same. it's easier just to type 'new', for example, than to try to let intellisense complete it for you. with this system typing 'new' would be one keypress.
this could also support binding to any arbitrary words/symbols you want.
the ide could even optionally track what you're using most and bind those things and have a display at the top of the screen constantly showing you the current bindings.
the only problem is that the F-keys are so far up on the keyboard that it may defeat the purpose -- having to shift your entire hand every time you use one. one solution could be to have a second key below the spacebar. it would be like another ctrl, shift, or alt, but more easily accessible. perhaps call it Func. whenever the Func key is pressed, the entire keyboard is mapped to symbols/keywords/whatevers.
the only problem with that is (besides the fact that it requires somebody to manufacture a new kind of keyboard), it's radical enough that probably only extreme programmers (not to be confused with eXtreme Programmers) would be interested in it.
Thursday, June 18, 2009
Monday, June 15, 2009
Easier Integration for Programming Languages
inhahe (9:59:43 PM): you know what would be neat
inhahe (10:00:16 PM): a scripting language like python, supported in .net (ironpython already is this), but with the ability to arbitrarily create functions and classes in c# or msil
inhahe (10:00:24 PM): within the same source file
I mentioned it in the context of .net, but the idea doesn't have to be limited to .net. For example it could be just Python (or any other scripting language) intermixed with, say, C++, just without having to use external modules. However that kind of requires hacking two different languages together, but in the .net case both IronPython and C# compile to .net so it's not such a hack. The point of doing it is that Python (or some other scripting language) is higher-level than, say, C++ or even C#. (I believe that even though IronPython compiles to CLI, it's slower than C#, VB.net, etc. because of its higher level of dynamicism.) So by being able to include different levels of languages within the same source (hey, how about being able to in-line direct CLI, too?) it makes it easier for people to take advantage of both RAD languages and high-performance languages at the same time by writing the most CPU-intensive loops in a lower level language.
inhahe (9:59:43 PM): you know what would be neat
inhahe (10:00:16 PM): a scripting language like python, supported in .net (ironpython already is this), but with the ability to arbitrarily create functions and classes in c# or msil
inhahe (10:00:24 PM): within the same source file
I mentioned it in the context of .net, but the idea doesn't have to be limited to .net. For example it could be just Python (or any other scripting language) intermixed with, say, C++, just without having to use external modules. However that kind of requires hacking two different languages together, but in the .net case both IronPython and C# compile to .net so it's not such a hack. The point of doing it is that Python (or some other scripting language) is higher-level than, say, C++ or even C#. (I believe that even though IronPython compiles to CLI, it's slower than C#, VB.net, etc. because of its higher level of dynamicism.) So by being able to include different levels of languages within the same source (hey, how about being able to in-line direct CLI, too?) it makes it easier for people to take advantage of both RAD languages and high-performance languages at the same time by writing the most CPU-intensive loops in a lower level language.
Thursday, June 11, 2009
Per-function memory protection
There should be a way for the CPU to support confining a function's memory access without putting that function in another thread. By modularizing something in that way you incur the overheads of context switching and IPC, but without it a module carries the risk of corrupting the memory for the whole process and making the caller unstable. What's needed is for the CPU to support memory segments that apply only for a particular function call, so that if it segfaults we can catch that and have the function return a failure. So how do we do this?
* We could provide an opcode for switching only the segment registers
* We could set up associations for the MMU beteen certain EIP ranges and certain segments
* We could create a second "call" opcode that takes a second parameter which is an index to a segment context
Would this actually save any time, or does switching segments actually imply most of the overhead you'd get from a complete context-switch anyway?
If it works, this would allow us to have the benefits of a monolithic kernel and a microkernel at the same time.
There should be a way for the CPU to support confining a function's memory access without putting that function in another thread. By modularizing something in that way you incur the overheads of context switching and IPC, but without it a module carries the risk of corrupting the memory for the whole process and making the caller unstable. What's needed is for the CPU to support memory segments that apply only for a particular function call, so that if it segfaults we can catch that and have the function return a failure. So how do we do this?
* We could provide an opcode for switching only the segment registers
* We could set up associations for the MMU beteen certain EIP ranges and certain segments
* We could create a second "call" opcode that takes a second parameter which is an index to a segment context
Would this actually save any time, or does switching segments actually imply most of the overhead you'd get from a complete context-switch anyway?
If it works, this would allow us to have the benefits of a monolithic kernel and a microkernel at the same time.
Subscribe to:
Posts (Atom)
