Project V: Purpose
Sunday, 17. September 2006, 00:36:03
In relating all the advantages of FBP (Flow Based Programming) or LSD (Logistical Software Development), we sometimes end up with a feeling of emptiness. Yes, all these things are great. But so what? What use is it exactly? All languages and tools have a specifically defined goal. I shall endeavour to state that goal here. Note that I cannot speak for FBP, only for Project V.
There are three goals for Project V:
If you'll note, these are the three "holy grails" of computing. This is what people have been trying to achieve for over 50 years. Let's go through each one in more detail.
Implicit Portability
Portability is simply the ability of a piece of software to execute on any machine. There is still no solution to this problem with conventional tools. No VM or emulator will give you portability. A VM IS an emulator. It emulates a virtual machine. But you still need a VM on the destination computer. Yes, in any portable solution, you need some kind of startup code to get you going, but in this case, VM are too large. There is no need of this. And even if porting a VM is relatively easy, it is not the best solution. The reason for this is that higher level operations and higher level languages are what is portable. This is the reason we program in high level languages rather than assembly. C is more portable than assembler. To be more portable, we must go higher. And this is what Project V accomplishes. It is higher level than all the current high level languages in existence today combined. A VM sits between a low level bytecode and the machine. It's too low level to be truly portable.
We have only talked about portability, but what does it mean to be implicitly portable? It means that each machine can implicitly use the best features and functionality of that machine to make sure your software executes. This means that if a machine has better hardware or better code to execute certain operations in your software, then your programs will execute that much more efficiently. It's a way to never change your software, yet have it become more efficient over time or on different hardware and even low level software. This is simply not possible with VM's or any current high level programming language. They can accomplish some of it if it is written in the VM, but most of the time, the source code states in too precise a fashion what needs to be done and cannot be replaced for fear of breaking the code.
An example of this would be code that has a built-in video codec and later on some hardware is developed to handle this codec. Would a VM be able to detect which parts of the source code are used for the codec and replace it with access to the hardware? The answer is a resounding no. But with Project V, each component is clearly distinguishable and can be replaced at any time. This is why I've always promoted Project V as portability through specialisation, and NEVER by generalisation. It seems to me most of the computing world has things backwards when it comes to portability and for these reasons, they will never achieve it.
Implicit Concurrency, Parallelism and Distributed Software
Here is another feature that theorists and computer scientists are pulling their hair out trying to figure out. If you ask them, they will tell you to use functional languages or to brush up on threading and traditional concurrent programming techniques using semaphores, locking and such. This is not the way to do things.
The correct way to do this is to leave these things to the machine itself. They all relate to execution points. Parallelism is the same code executing on multiple processors. Concurrency is different software executing on multiple processors. And distributed software is either parallel or concurrent code running on separate machines. These are all execution models. They should not matter one iota as to what is to be done with our data.
Take this example:
Does the calling of this function do anything to the data in question? Does it alter or in any way dictate any relationship to the number 5? No! The function is nothing but a burden. The calling and returning serves no real purpose to the execution of the program. Functions are useful to separate often used code. Unfortunately, they also carry a hidden drawback that is the calling mechanism. There is no need for it.
Project V does away completely with anything low level that has to do with the machine. There is no execution point, no if statement that jumps to blocks of code, no execution loops, no while statements and especially no function calls. This frees up the machine or machines to use whatever execution model they wish. But if you include it directly into the source code as we've been doing for the past 50 years, you must use what's specified in the source. If you use threads, then the machine must use threads exactly as you've specified. You're basically hard coding the execution model into your software.
This topic has a lot to do with implicit portability since it allows any machine to execute our software. Whatever hardware, including processors of any kind, can be used to execute our programs. By not specifying the execution model, this means that ANY execution model can be used and it's of YOUR choosing. You do not need to change the software in question. You can use parallel, concurrent or distributed computing. The choice is yours. You'll never have to write a thread again.
Implicit Reusability
We've already touched on this a little. Every part of your software is built of connected components. Most of these components will be pre-existing components. J. Paul Morrison, the creator of FBP, has already done research on this and found that the vast majority of components in any given FBP application are pre-existing ones. Over time, as more and more components are built, especially with the open source movement, this trend should tend toward 100%. I can fully envision a time where most applications use 100% of pre-existing components and just connecting them together as appropriate. (Yes, I actually quoted a reference to what I'm saying... scary!)
Reusability isn't the only advantage, but having this be made implicit. If a machine has a better version of the component, then it can use that instead without you having to specify anything in your software. That's implicit reusability. You can reuse versions of components that you haven't even seen yet. As was said before, by reusing higher level components, better versions (whether in hardware or software) can appear and make your software more efficient. In today's programming world, using newer versions is fraught with problems that can break earlier code. Replacing code is almost always difficult to impossible. I want to make this seamless.
Afterthoughts
Since Logistical Software Development is highly visual, I'm currently rewriting my graphics library. I couldn’t find anything out there that suited my needs. I require highly flexible operations that use alpha channels. Unfortunately, the amount of people that understand alpha channels and anti-aliasing are far and few between. Only another day or two's work and I should be done converting the library. I may add MMX and ISSE later on for added speed. I will do this because it's the only fun I have programming any more. I find current high level languages rather tedious because they slow me down. I've surpassed any speed they can give me. Assembler lets me do exactly what I want without any obstacles.
This tool isn't all positive though. I haven't seen too many drawbacks to actual software development and that by itself is a drawback to many. In this development environment, once you have developed a component, you never need to create it again. After a while, all the simple stuff will have been done. In conventional languages, even if you have the best written library, this won't stop you from writing simple stuff like loading files and writing loops. Those will always be there. But in Project V, you would simply link one component to the next. It takes about one second to do. Where's the drawback, you may ask? Well, after all the simple stuff is done, do you think the programming requirement will go up or down? People don't like that their jobs are worth less. Personally, I don't like that we have to keep re-inventing the wheel just because some people don't want to lose their jobs.
Next is the fact that the academic world is currently in complete denial. If this is going to get any traction, I will have to do it despite educational institutions. The simple fact is that if Project V or FBP ends up being a success, it will totally discredit most of the proofs and papers written in the past 50 years on the topic of computing. All type theory, functional approaches and most everything else is false. Just this last statement, can you imagine the resistance? Could you imagine if your life's work ends up being false? This is the same phenomenon happening in astrophysics. The bigs guns kill off the little ones that would try to discredit them. They cut off their access to equipment and publications. They are blacklisted. In the computing field, they can't cut off my access to my computer, but they will do their best to discredit my work. Once we get rid of the Turing machine, we will be much better off. But current momentum seems to indicate otherwise. If your see the term "Turing complete" in a paper and it uses as support or in relation to an argument, you can rest assured that it's rubbish.
A third obstacle is that Logistical Software Development is NOT programming. Programming involves a sequence of events. Logistics involves the handling of many details. That's why Project V is not programming. We do not concern ourselves with the sequence of commands, but rather with the handling of the data. There are no programming languages in existence that work this way. With 100% of programmers used to conventional languages, who will use Project V or this new way to build applications? Not many, I think. That's why I've always said I expect absolute beginners to try it out because I'm hoping Project V will be simple enough for them to use and they have no dogma hindering them from trying it out. The other people I said would try it out are the elites of the programming world who do not have anything to prove and can do as they please without fear of ridicule. These people may be all the traction that Project V needs.
Do I believe regular programmers will try it out? Sure. Will they like it? Doubtful. It's connecting a bunch of boxes together. It really does warp your mind if you're used to programming in conventional languages. It took me over 9 months to properly define the differences. I'm sure I will yet uncover more differences. I know one thing for certain. If you're used to conventional languages, it will be almost impossible for you to truly see these differences. You will keep thinking in the old ways and become frustrated that Project V doesn't match your way of thinking. I'm the creator of Project V and even I still fall into that trap from time to time. I'm finding telling the machine what to do to be more and more unnatural and in a way, I'm resentful that something like Project V doesn't yet exist in schools, colleges and universities.
The Turing machine is but one way to do computations. There are no reasons why we should emulate it and a million and one reason why we should completely ignore it and pretend like it never existed. The primary reason being that it is near impossible to convert a program from one Turing-complete machine to another. Equivalency doesn't extend to portability. In fact, it goes against it. The VM world is coming head to head with this obstacle as we speak.
In the future, the machine won't matter as far as software is concerned. It will matter in the implementation of components, but not in the design of software. Just as there are architects and trades people in construction, so will there be in the computing field as well. Current programmers are trades people. They are all low level programmers who like to be hands on. Unfortunately, they think they are high level and use the word "abstract" every chance they get. If logistical development ever takes off, these programmers will be low level component implementors. Software architects will be a completely different breed.
This is my view of the future. In case you haven't noticed, I'm feeling great and back in full force!
There are three goals for Project V:
- Implicit Portability.
- Implicit Concurrency, Parallelism and Distributed Software.
- Implicit Reusability.
If you'll note, these are the three "holy grails" of computing. This is what people have been trying to achieve for over 50 years. Let's go through each one in more detail.
Implicit Portability
Portability is simply the ability of a piece of software to execute on any machine. There is still no solution to this problem with conventional tools. No VM or emulator will give you portability. A VM IS an emulator. It emulates a virtual machine. But you still need a VM on the destination computer. Yes, in any portable solution, you need some kind of startup code to get you going, but in this case, VM are too large. There is no need of this. And even if porting a VM is relatively easy, it is not the best solution. The reason for this is that higher level operations and higher level languages are what is portable. This is the reason we program in high level languages rather than assembly. C is more portable than assembler. To be more portable, we must go higher. And this is what Project V accomplishes. It is higher level than all the current high level languages in existence today combined. A VM sits between a low level bytecode and the machine. It's too low level to be truly portable.
We have only talked about portability, but what does it mean to be implicitly portable? It means that each machine can implicitly use the best features and functionality of that machine to make sure your software executes. This means that if a machine has better hardware or better code to execute certain operations in your software, then your programs will execute that much more efficiently. It's a way to never change your software, yet have it become more efficient over time or on different hardware and even low level software. This is simply not possible with VM's or any current high level programming language. They can accomplish some of it if it is written in the VM, but most of the time, the source code states in too precise a fashion what needs to be done and cannot be replaced for fear of breaking the code.
An example of this would be code that has a built-in video codec and later on some hardware is developed to handle this codec. Would a VM be able to detect which parts of the source code are used for the codec and replace it with access to the hardware? The answer is a resounding no. But with Project V, each component is clearly distinguishable and can be replaced at any time. This is why I've always promoted Project V as portability through specialisation, and NEVER by generalisation. It seems to me most of the computing world has things backwards when it comes to portability and for these reasons, they will never achieve it.
Implicit Concurrency, Parallelism and Distributed Software
Here is another feature that theorists and computer scientists are pulling their hair out trying to figure out. If you ask them, they will tell you to use functional languages or to brush up on threading and traditional concurrent programming techniques using semaphores, locking and such. This is not the way to do things.
The correct way to do this is to leave these things to the machine itself. They all relate to execution points. Parallelism is the same code executing on multiple processors. Concurrency is different software executing on multiple processors. And distributed software is either parallel or concurrent code running on separate machines. These are all execution models. They should not matter one iota as to what is to be done with our data.
Take this example:
int func()
{
return 5;
}
Does the calling of this function do anything to the data in question? Does it alter or in any way dictate any relationship to the number 5? No! The function is nothing but a burden. The calling and returning serves no real purpose to the execution of the program. Functions are useful to separate often used code. Unfortunately, they also carry a hidden drawback that is the calling mechanism. There is no need for it.
Project V does away completely with anything low level that has to do with the machine. There is no execution point, no if statement that jumps to blocks of code, no execution loops, no while statements and especially no function calls. This frees up the machine or machines to use whatever execution model they wish. But if you include it directly into the source code as we've been doing for the past 50 years, you must use what's specified in the source. If you use threads, then the machine must use threads exactly as you've specified. You're basically hard coding the execution model into your software.
This topic has a lot to do with implicit portability since it allows any machine to execute our software. Whatever hardware, including processors of any kind, can be used to execute our programs. By not specifying the execution model, this means that ANY execution model can be used and it's of YOUR choosing. You do not need to change the software in question. You can use parallel, concurrent or distributed computing. The choice is yours. You'll never have to write a thread again.
Implicit Reusability
We've already touched on this a little. Every part of your software is built of connected components. Most of these components will be pre-existing components. J. Paul Morrison, the creator of FBP, has already done research on this and found that the vast majority of components in any given FBP application are pre-existing ones. Over time, as more and more components are built, especially with the open source movement, this trend should tend toward 100%. I can fully envision a time where most applications use 100% of pre-existing components and just connecting them together as appropriate. (Yes, I actually quoted a reference to what I'm saying... scary!)
Reusability isn't the only advantage, but having this be made implicit. If a machine has a better version of the component, then it can use that instead without you having to specify anything in your software. That's implicit reusability. You can reuse versions of components that you haven't even seen yet. As was said before, by reusing higher level components, better versions (whether in hardware or software) can appear and make your software more efficient. In today's programming world, using newer versions is fraught with problems that can break earlier code. Replacing code is almost always difficult to impossible. I want to make this seamless.
Afterthoughts
Since Logistical Software Development is highly visual, I'm currently rewriting my graphics library. I couldn’t find anything out there that suited my needs. I require highly flexible operations that use alpha channels. Unfortunately, the amount of people that understand alpha channels and anti-aliasing are far and few between. Only another day or two's work and I should be done converting the library. I may add MMX and ISSE later on for added speed. I will do this because it's the only fun I have programming any more. I find current high level languages rather tedious because they slow me down. I've surpassed any speed they can give me. Assembler lets me do exactly what I want without any obstacles.
This tool isn't all positive though. I haven't seen too many drawbacks to actual software development and that by itself is a drawback to many. In this development environment, once you have developed a component, you never need to create it again. After a while, all the simple stuff will have been done. In conventional languages, even if you have the best written library, this won't stop you from writing simple stuff like loading files and writing loops. Those will always be there. But in Project V, you would simply link one component to the next. It takes about one second to do. Where's the drawback, you may ask? Well, after all the simple stuff is done, do you think the programming requirement will go up or down? People don't like that their jobs are worth less. Personally, I don't like that we have to keep re-inventing the wheel just because some people don't want to lose their jobs.
Next is the fact that the academic world is currently in complete denial. If this is going to get any traction, I will have to do it despite educational institutions. The simple fact is that if Project V or FBP ends up being a success, it will totally discredit most of the proofs and papers written in the past 50 years on the topic of computing. All type theory, functional approaches and most everything else is false. Just this last statement, can you imagine the resistance? Could you imagine if your life's work ends up being false? This is the same phenomenon happening in astrophysics. The bigs guns kill off the little ones that would try to discredit them. They cut off their access to equipment and publications. They are blacklisted. In the computing field, they can't cut off my access to my computer, but they will do their best to discredit my work. Once we get rid of the Turing machine, we will be much better off. But current momentum seems to indicate otherwise. If your see the term "Turing complete" in a paper and it uses as support or in relation to an argument, you can rest assured that it's rubbish.
A third obstacle is that Logistical Software Development is NOT programming. Programming involves a sequence of events. Logistics involves the handling of many details. That's why Project V is not programming. We do not concern ourselves with the sequence of commands, but rather with the handling of the data. There are no programming languages in existence that work this way. With 100% of programmers used to conventional languages, who will use Project V or this new way to build applications? Not many, I think. That's why I've always said I expect absolute beginners to try it out because I'm hoping Project V will be simple enough for them to use and they have no dogma hindering them from trying it out. The other people I said would try it out are the elites of the programming world who do not have anything to prove and can do as they please without fear of ridicule. These people may be all the traction that Project V needs.
Do I believe regular programmers will try it out? Sure. Will they like it? Doubtful. It's connecting a bunch of boxes together. It really does warp your mind if you're used to programming in conventional languages. It took me over 9 months to properly define the differences. I'm sure I will yet uncover more differences. I know one thing for certain. If you're used to conventional languages, it will be almost impossible for you to truly see these differences. You will keep thinking in the old ways and become frustrated that Project V doesn't match your way of thinking. I'm the creator of Project V and even I still fall into that trap from time to time. I'm finding telling the machine what to do to be more and more unnatural and in a way, I'm resentful that something like Project V doesn't yet exist in schools, colleges and universities.
The Turing machine is but one way to do computations. There are no reasons why we should emulate it and a million and one reason why we should completely ignore it and pretend like it never existed. The primary reason being that it is near impossible to convert a program from one Turing-complete machine to another. Equivalency doesn't extend to portability. In fact, it goes against it. The VM world is coming head to head with this obstacle as we speak.
In the future, the machine won't matter as far as software is concerned. It will matter in the implementation of components, but not in the design of software. Just as there are architects and trades people in construction, so will there be in the computing field as well. Current programmers are trades people. They are all low level programmers who like to be hands on. Unfortunately, they think they are high level and use the word "abstract" every chance they get. If logistical development ever takes off, these programmers will be low level component implementors. Software architects will be a completely different breed.
This is my view of the future. In case you haven't noticed, I'm feeling great and back in full force!
WIDGETIZE
the word is fraught not wrought
By anonymous user, # 17. September 2006, 11:00:53
By Vorlath, # 17. September 2006, 16:04:43