The Programming Language of the Future is in /dev/null
Friday, 19. May 2006, 03:23:32
A few years ago, a time traveller came by and gave me a copy of the most popular programming language from around the year 3254. He asked me to take a look at it and after I did, he asked me what I thought of it. I typed "mv FuturePL /dev/null" and promptly pressed the "Enter" key. Then I looked at him and said: "That's what I think of it." True story! He said his name was John Titor and that he was looking for an IBM 5100 portable computer.
If someone were to ask me what I believed in more, future (or current) programming languages or John Titor, I'd say John Titor 100%!
I don't know exactly how future programs will be created, but I know one thing with 100% certainty. It won't be done with programming languages. I can guarantee it.
Why do I say this? Because programming languages have provided nothing new when it comes to designing software, only more confusion. I would say that I'm surprised that no one is worried about being able to program multi-core machines, but the truth is that I was the same way. I was too busy to notice. The free ride that is Moore's Law is over for sequential machines. Multi-core machines are here to stay. And yet we still have no "language" that supports dynamically adaptable concurrent programming. Not ONE! That is a dismal state of affairs for the computing community.
Ok, so that's in the past. What about the future? Well, the picture can't improve if we still believe that programming languages are the answer. We've tried it for 50 years and look at the results. It's a common thread that if we built cars like we build software, we'd all be dead. Proving the correctness of your software with the current writing style is like trying to prove that the Sun won't set. You can circle the Earth, but I'm sure it's not worth the trouble. My issue isn't with proving the correctness of your software. Quite the contrary, I do believe that it should be possible. This should surprise quite a few people. Anyhow, what I have issue with is WHAT is being proven. The way we write software is not very conducive to proofs. The entire computing community is with me on this one. Or rather, I'm with them. There's even proofs of things that can't be guaranteed in distributed computing. Should this not be an indication that perhaps the way we are writing software is completely off base?
You just plain don't need a programming language to create software. So when someone from the future hands me a programming language from the future, I already know it's a kid's project on extinct software design practices. There is absolutely no way that I can believe we will still be using programming languages in the future. Every piece of literature on the subject points in the same direction. That it is inadequate for our needs. Memory allocation, memory deallocation, persistent storage management, execution priority, race conditions, deadlock, livelock, starvation, failsafe and many more are all issues that are unique to programming languages. They are human made problems that need not exist. If you use programming languages, of course you're going to get these problems. They're all sequential.
I am stating now for the record that any programming technique that tries to handle concurrency with a programming language will never be free of the problem mentioned in the last paragraph. I also state that trying to write software with concurrency in mind will likewise have problems. If our future cannot come up with something better than the notion of a programming language, then we are doomed to repeat the last 50 years. We've already repeated the last 20. Doesn't look like it will change. Also for the record, the problems in the last paragraph need not exist.
If you're still reading this, you may be wondering how software will be created in the future. I don't know for sure, but I do know that many of my ideas in past entries will be used. Not because I'm arrogant, but because it is supported by evidence and because many have written about these solutions. Unfortunately, NOT ONE single person is prepared to admit that perhaps programming languages aren't the answer. They haven't been for the past 50 years, yet we continue to use them. Imagine if the pyramid builders had the same stubborn mentality. Every time their pyramid came crashing down, they would try and rebuild it in the exact same fashion. Wouldn't be too bright, now would it? But that's what programmers are doing. We are master wheel re-inventors. A broken wheel, but a wheel regardless.
Another thing stopping us is that everything is written in procedural code. There is ZERO out there that is different. It's all based on the sequential processing of instructions.
Ok, let's take a scenario from the future. Let's take a loading dock (on the ground or in space) where there are machines that will load and unload your vehicle's cargo. In our current way of programming, we want to give the "robot" a list of commands. Use object recognition to detect what is cargo, detect its size, adjust grappling or lifting mechanism, move robot to destination and continue like this. Well, I'll tell you right now that this is absurd. Instead of telling the robot HOW to move the cargo, we should be telling it WHAT we want moved and where to. It's already configured on how to move cargo, so that should stay the same. But the cargo's manifest and each item's specification should be given to the robot.
Now, you may think that we can do that kind of thing now. The key word here is "can". What if I change the robots wheels into anti-grav propulsion system? By today's programming style, we would never think of adding that into the programming. We can't think of everything that "CAN" be configured. So in the future, the way software is written is where everything can be configured. You don't actually write in "if (box)... if (ball)... if (nuclear waste)... if (config.cargo[X])"... That's poor man's programming. Forget that shit!
In the future, the robot's motor control will be swapped out with alternate controls. And when designing the software, you don't have to take this into account. It will be inherent in the way software is constructed. Any software you write, any part of it will be swappable without having to write it in. Ever write a program that loaded a file? BAD! Ever write a program that took input from the keyboard? BAD! Ever write a program that used sockets? BAD! Don't get me wrong, I'm not criticizing your programming style. I'm criticizing the fact that you have to be so specific because of current programming languages. What if the input no longer comes from the keyboard? The programmer has to rewrite the software. What if there's a new kind of network that runs in parallel with the Internet, but is handled quite differently? Again, rewrite the software. That's crazy talk.
This new kind of software development is possible. It's been possible for over 50 years. Well, maybe some of the physical resources may have been a hindrance, but at least since 1980. I don't know what the state of computing was before that time, so I can't really comment. But I do know that from what I've seen in videos from the 60's, that a lot of this was possible back then.
I don't pretend I'll be able to create this new kind of programming. All I'm hoping for is getting it started. 100% of software design today is the same no matter what language. It is true that if you know one language, you pretty much know them all. Maybe not APL though. However, my design will be based on WHAT you want done, not the HOW. The HOW will be at the lowest levels where software meets hardware. It's long overdue where we shouldn't be dealing with this stuff anymore. At the higher levels, we'll only deal with WHAT we want done. The computer's execution handler can figure out HOW to do WHAT you want done and load up that code and put it together. You can still write code on HOW to do things, but those are non-portable hardware specific constructs. These should never be mixed with the overall logic of your software. So if you want your software to run on another computer, you only need tell it WHAT you want done. Portability without any of that VM, GC, simulation or any of that jazz.
And don't for one second believe that bytecode is stating what you want done or that programming languages state what you want done. Threads, files, socket and GUI’s are all things that specify HOW to access certain inputs, outputs or other hardware specific operations. What if I don't want to use a GUI, or a socket or whatever else? I should be able to plug in my own access methods without having the programmer redesign the software.
Even in 20 or 40 years, if someone hands me something that is supposed to be some kind fancy new programming language, off to /dev/null it goes. We should all be like /dev/null and never ever let garbage get back out. Now where's my 101 Java directories and why does it need so many installations? More important, how does it sneak it's way back? More malicious than the worst of viruses.
If someone were to ask me what I believed in more, future (or current) programming languages or John Titor, I'd say John Titor 100%!
I don't know exactly how future programs will be created, but I know one thing with 100% certainty. It won't be done with programming languages. I can guarantee it.
Why do I say this? Because programming languages have provided nothing new when it comes to designing software, only more confusion. I would say that I'm surprised that no one is worried about being able to program multi-core machines, but the truth is that I was the same way. I was too busy to notice. The free ride that is Moore's Law is over for sequential machines. Multi-core machines are here to stay. And yet we still have no "language" that supports dynamically adaptable concurrent programming. Not ONE! That is a dismal state of affairs for the computing community.
Ok, so that's in the past. What about the future? Well, the picture can't improve if we still believe that programming languages are the answer. We've tried it for 50 years and look at the results. It's a common thread that if we built cars like we build software, we'd all be dead. Proving the correctness of your software with the current writing style is like trying to prove that the Sun won't set. You can circle the Earth, but I'm sure it's not worth the trouble. My issue isn't with proving the correctness of your software. Quite the contrary, I do believe that it should be possible. This should surprise quite a few people. Anyhow, what I have issue with is WHAT is being proven. The way we write software is not very conducive to proofs. The entire computing community is with me on this one. Or rather, I'm with them. There's even proofs of things that can't be guaranteed in distributed computing. Should this not be an indication that perhaps the way we are writing software is completely off base?
You just plain don't need a programming language to create software. So when someone from the future hands me a programming language from the future, I already know it's a kid's project on extinct software design practices. There is absolutely no way that I can believe we will still be using programming languages in the future. Every piece of literature on the subject points in the same direction. That it is inadequate for our needs. Memory allocation, memory deallocation, persistent storage management, execution priority, race conditions, deadlock, livelock, starvation, failsafe and many more are all issues that are unique to programming languages. They are human made problems that need not exist. If you use programming languages, of course you're going to get these problems. They're all sequential.
I am stating now for the record that any programming technique that tries to handle concurrency with a programming language will never be free of the problem mentioned in the last paragraph. I also state that trying to write software with concurrency in mind will likewise have problems. If our future cannot come up with something better than the notion of a programming language, then we are doomed to repeat the last 50 years. We've already repeated the last 20. Doesn't look like it will change. Also for the record, the problems in the last paragraph need not exist.
If you're still reading this, you may be wondering how software will be created in the future. I don't know for sure, but I do know that many of my ideas in past entries will be used. Not because I'm arrogant, but because it is supported by evidence and because many have written about these solutions. Unfortunately, NOT ONE single person is prepared to admit that perhaps programming languages aren't the answer. They haven't been for the past 50 years, yet we continue to use them. Imagine if the pyramid builders had the same stubborn mentality. Every time their pyramid came crashing down, they would try and rebuild it in the exact same fashion. Wouldn't be too bright, now would it? But that's what programmers are doing. We are master wheel re-inventors. A broken wheel, but a wheel regardless.
Another thing stopping us is that everything is written in procedural code. There is ZERO out there that is different. It's all based on the sequential processing of instructions.
Ok, let's take a scenario from the future. Let's take a loading dock (on the ground or in space) where there are machines that will load and unload your vehicle's cargo. In our current way of programming, we want to give the "robot" a list of commands. Use object recognition to detect what is cargo, detect its size, adjust grappling or lifting mechanism, move robot to destination and continue like this. Well, I'll tell you right now that this is absurd. Instead of telling the robot HOW to move the cargo, we should be telling it WHAT we want moved and where to. It's already configured on how to move cargo, so that should stay the same. But the cargo's manifest and each item's specification should be given to the robot.
Now, you may think that we can do that kind of thing now. The key word here is "can". What if I change the robots wheels into anti-grav propulsion system? By today's programming style, we would never think of adding that into the programming. We can't think of everything that "CAN" be configured. So in the future, the way software is written is where everything can be configured. You don't actually write in "if (box)... if (ball)... if (nuclear waste)... if (config.cargo[X])"... That's poor man's programming. Forget that shit!
In the future, the robot's motor control will be swapped out with alternate controls. And when designing the software, you don't have to take this into account. It will be inherent in the way software is constructed. Any software you write, any part of it will be swappable without having to write it in. Ever write a program that loaded a file? BAD! Ever write a program that took input from the keyboard? BAD! Ever write a program that used sockets? BAD! Don't get me wrong, I'm not criticizing your programming style. I'm criticizing the fact that you have to be so specific because of current programming languages. What if the input no longer comes from the keyboard? The programmer has to rewrite the software. What if there's a new kind of network that runs in parallel with the Internet, but is handled quite differently? Again, rewrite the software. That's crazy talk.
This new kind of software development is possible. It's been possible for over 50 years. Well, maybe some of the physical resources may have been a hindrance, but at least since 1980. I don't know what the state of computing was before that time, so I can't really comment. But I do know that from what I've seen in videos from the 60's, that a lot of this was possible back then.
I don't pretend I'll be able to create this new kind of programming. All I'm hoping for is getting it started. 100% of software design today is the same no matter what language. It is true that if you know one language, you pretty much know them all. Maybe not APL though. However, my design will be based on WHAT you want done, not the HOW. The HOW will be at the lowest levels where software meets hardware. It's long overdue where we shouldn't be dealing with this stuff anymore. At the higher levels, we'll only deal with WHAT we want done. The computer's execution handler can figure out HOW to do WHAT you want done and load up that code and put it together. You can still write code on HOW to do things, but those are non-portable hardware specific constructs. These should never be mixed with the overall logic of your software. So if you want your software to run on another computer, you only need tell it WHAT you want done. Portability without any of that VM, GC, simulation or any of that jazz.
And don't for one second believe that bytecode is stating what you want done or that programming languages state what you want done. Threads, files, socket and GUI’s are all things that specify HOW to access certain inputs, outputs or other hardware specific operations. What if I don't want to use a GUI, or a socket or whatever else? I should be able to plug in my own access methods without having the programmer redesign the software.
Even in 20 or 40 years, if someone hands me something that is supposed to be some kind fancy new programming language, off to /dev/null it goes. We should all be like /dev/null and never ever let garbage get back out. Now where's my 101 Java directories and why does it need so many installations? More important, how does it sneak it's way back? More malicious than the worst of viruses.
WIDGETIZE
Anonymous # 6. August 2007, 00:54
wow... itz amazing...
Anonymous # 6. August 2007, 00:55
fuck..
jonkvh # 18. September 2007, 03:40
Anonymous # 21. March 2008, 10:19
Take a good look at the processor board of the IBM 5100. One of the 'proms' does not function unless its only used as a 'backup' recall. This "accidently installed Mercury Project" 'prom' chip has the most unusual instruction set ever! It contributes to this in some ways. I am not going into details of how I know this, etc... find out for yourself.
Anonymous # 16. February 2009, 13:02
Very inspirational essay
Anonymous # 25. February 2009, 14:10
So, you're talking about prolog then?
Anonymous # 25. February 2009, 15:43
A computer is a dumb stateful machine that takes a set of instructions from somewhere and performs actions based upon those instructions. It doesn't understand what, or how. Whatever way you look at it, someone is going to have to program the underlying interpreter for your magic ability to tell the machine what you want done.
So yes, he's talking about prolog.
Vorlath # 25. February 2009, 22:13
And a machine doesn't have to be a stateful machine that executes instructions. That's von Neumann and isn't the only way to do things. Spatial computing (vs. temporal) is much more powerful.
If you don't have an understanding about the different fundamental styles of computing, you'll never understand what I talk about on this blog. Most of what I talk about cannot be found in books and certainly isn't taught in any school, University or college. The funny thing is that much of it has been known for at least 30 years though and is slowly becoming more prevalent.
There's a whole world of computing out there that 99% of programmers have never seen.
Anonymous # 26. February 2009, 14:59
First of all, I apologize for the rant ;-)
I agree that a lot of the "cutting edge" programming technology is actually shockingly old now and I certainly dont't disagree with 99% of programmers not having seen most of what computing has to offer. I even agree with your fundamental point about how programming languages are lacking. Yet somewhere amongst your post (this specific one, I admit that I have not yet read any of your other blog posts) is something I can't quite agree with..
Its probably just a bunch of little things that bug me. For example, you state "if you know one language, you pretty much know them all", but that isn't true. If you know one language of a particular paradigm, then you pretty much know all languages of that paradigm - that I can agree with, but there are many completely different paradigms.
Example time: do you really think that a C programmer pretty much knows Prolog? Or haskell? Or Forth? Or Lisp? Or.. *shudder* FP? (Or J is you prefer, since I don't know of any FP implementations) FP is so fundamentally different from C that you couldn't possibly expect a C programmer to "pretty much know them all". Imperative, OO, declarative/logic, functional, function-level, concatenative... they are all quite different.
My point here isn't to nitpick your blog post (maybe a little, but just cause I'm not a nice person :-D), but rather to point out that all programming languages are not fundamentally the same and languages certainly aren't born equal. Therefore, I think that you are overgeneralizing. Perhaps that was the point though.
Maybe its your wording more than anything else: saying programming languages are bad and cant cope with problems is a little vague. How else are you going to program your computer? Switching to a declarative modal (even if its much more advanced than Prolog) is still using programming languages - its just more powerful than what we use now.
What about something like this: http://www.rebelscience.org/Cosas/COSA.htm
Personally, I think the problem with computing isn't programming languages. Yes, they are partially at fault - or rather, the "popular" ones are - but the problems are much deeper. If we were all using Lisp, running Genera on a Symbolics Lisp machine, I think we'd be a lot better off than we are now. Yes, the popular programming languages are very much lacking, but they aren't exactly the cutting edge of programming technology either. A quick glance at any recent SIGPLAN publications would show this.
The biggest flaw is that using my computer requires too much work on my part. Like you said, why do I have to tell it exactly what to do? But apply this across the board - not just to programming. Why am I concerned about what programs are running? I'm not - I only care about editing that text or whatever I need to get my work done. Why am I concerned about saving my files and work? I shouldn't need to be - the system should employ some form of orthogonal persistence which would handle it for me in the background. With versioning. etc etc
Why don't we have these things now? The technology certainly exists! The problem is, IMHO, that people have got used to having crap software and having to perform stupid mundane tasks which the computer could easily do for us and because people are used to it, there is no demand for change.
It is the same with programming languages. People are so used to the current ways of programming that theres little demand for change. Or they're so reliant on legacy software that they cannot afford to risk changing. This can easily be seen among existing programming languages. So much software is STILL being written in the mess of a language known as (and I apologize, fans) C. Every day people are writing yet more buffer overflows and whatnot. But C isn't very advanced at all.
Compare it to, for example, Objective Caml - a functional, imperative OO language with type inference, parametric types, pattern matching, a decent module system and garbage collection, amongst other things. It can also be compiled to bytecode OR efficient native code. Why aren't more people using OCaml instead of C? Or how about (arguably, depending on who you ask, I guess) Lisp?? Or one of my more recent favorites, Factor.
There are plenty of languages out there which are more advanced and powerful than the popular languages.
We could have a similar discussion about operating systems. Or hardware.
Back to your blog post:
How do you propose the computer will magically know how to accomplish what you want? Using your robot example, would somebody not need to implement the motor logic which your main control program conveniently overlooks? Some sort of interface to it still needs to exist. It sounds to me that you are envisioning a modular, tiered high level language where the higher tiers don't care about the lower tiers - just that they exist. You give a high level specification of what you want done and the system delegates this down the tiers of software until the low level instructions are reached.
This sounds familiar.. yep, it was discussed in Structure and Interpretation of Computer Programs and I believe video lecture 4b (I guessed the number from looking at the list, so I may be wrong) covered that issue too. In fact, Lisp is exceptionally good at this!
Of course, SICP discusses it in terms of a math library which doesn't care about the underlying representation of polynomials or circles or fractions or whatever it happened to be, but you can apply the concept to pretty much anything.
So, in conclusion, I think, programming wise at least, you really want a modern Lisp with a cleverly designed and powerful standard library upon which you can write higher level tiers of software.
Maybe if Lisp machines were to return, everything (hardware and software) could be controlled by the Lisp system and all those difficult problems like concurrency could be automagically managed for us.
Vorlath # 26. February 2009, 16:01
This is a telling statement. Until a few years ago, I thought it was impossible to write software without functions. I did know about declarative languages and other less known ways to produce software, but generally functions are It. Spatial software development requires no functions at all. And programming languages would be inadequate toward this kind of development.
(edit: corrected second last sentence to say "Spatial software". Used to say "Temporal software" which isn't right.)
That has many similarities to what I'm working on, but only superficially. COSA still has a trigger mechanism and is event based. It's a step in the right direction, but there are many areas where you will get into a bottleneck and someone who hasn't dealt with this kind of stuff will have no idea why they are stuck in the first place.
I hope you're joking. Functional languages have an identity crisis. They don't know whether to be data flow or imperative. And using functions creates its own set of limitations.
As an example of a limitation, map and reduce must have all of its input beforehand. It can't deal with dynamic data unless the program itself uses monads or the list is computed. If the data comes from an external source, then that function would be deemed unpure. Enter the monad.
But an equivalent dataflow transformation would remain pure no matter the source of the data. (edit: I should add that a monad is a dataflow concept bastardized to the point where it appears to be imperative. But since it is dataflow, functional programming can use a monad to retain purity to get around the limitations of functional programming).
A while back, I actually watched every single one of those lectures just cuz I look at almost everything that comes my way. But talk about boring. Can't believe I made it through the whole thing. Lots of bogus stuff in there.
I don't remember anything in there about hierarchical modularity. I do remember how you could have different implementations, but while watching this, I could not help but think "Who manages the interfaces?" The answer is that it isn't. The teacher even talked about it briefly. For a second, I thought there was hope. I was really interested in what he'd say. But he didn't say anything. Just continued on.
Sorry, but Lisp SUCKS at this. There's a reason why Java has a gigantic library and why perl has a repository. To be fair, I have no idea if Lisp has fixed this issue since then. Even if they got to the point of having a common repository, it'd still be wholly inadequate for true advancement of the computing field because functional programming itself makes it impossible.
I have an article on ONE aspect of this:
http://my.opera.com/Vorlath/blog/2008/07/25/hierarchies-and-equivalence
Note that there are many more factors as to why Lisp cannot do what I need/want. I can try and find those articles too if you'd like.
HAHAHAHA
Now THAT is what I call funny. Nice one.
Lisp can only do hierarchical concurrency on local hardware. It cannot do implicit distributed concurrency which should be available on all software development tools from here on out.
Anonymous # 3. March 2009, 10:22
I will reply to your last comment later, when I have more time to do so. I was wondering though, what you think of Subtext as a concept for a programming language? http://subtextual.org
Anonymous # 3. March 2009, 16:42
SICP & hierarchies: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-17.html#%_sec_2.4
"Note that there are many more factors as to why Lisp cannot do what I need/want. I can try and find those articles too if you'd like."
If its not too much trouble, then yes, I would like. I am always interested in learning more about this subject and certainly don't mind being corrected if I'm wrong.
I had started to reply to the rest of your comment, but decided not to. Instead I would rather admit defeat and ask you this:
What is your definition of "Programming Language"?
From looking at the rest of your blog, it is obvious that dataflow seems to be the direction you personally lean, in respect to software development and Project V appears to be a visual dataflow system. But how is this NOT a programming languages? Visual programming languages are programming languages just as much as textual ones are, whether they are data flow languages, functional, imperative, declarative, or anything else. On this note, what do you think of LabVIEW?
I know that I'm asking a lot of questions, but I'd really like to understand your view better (and I am working my way through your older posts).
Vorlath # 3. March 2009, 21:17
To me, a programming language is rather all encompassing. I tend to use it for software development environments that require text files. I also tend to narrow it down to those languages that allow temporal execution though I'm not too strict about it. But yeah, mostly in the temporal execution realm with text files.
The only reason I try not to use the term "programming language" for Project V is that the term "programming" involves sequences of events. Like television programming means the sequence of shows. When you go see a play, you get a program that will lay out the acts and maybe other social events that will take place that day. The term "programming" is very much rooted in the temporal sequencing of events. So it's not really appropriate for dataflow environment, but I really don't have any issues with considering it a programming language if they wish. I've probably done it a few times in the past before I really looked at the definition of "programming".
About Lisp not doing what I need is mainly rooted in its substitution model. The result must be used where the function itself is used. IOW, there is no different between the data and the function. I think this was a goal of Lisp. But that completely stops me in my tracks. I think you already looked at hierarchical differences where Lisp uses stacked and I'd rather have a flat hierarchy which is more conducive to modularity.
I'll try and find those articles again. Some of my older articles I don't really like anymore because back then, it was a learning process as to the differences between temporal and spatial computing. Functional programmers tend to think in imperative vs. functional. But it's really temporal vs. spatial. Functional is very much rooted in the temporal aspect (as well as spatial to a certain extent). So it's more like imperative programming than one would like to admit. Back then, I didn't fully understand these differences. And also how the substitution model fit in with all of this.
BTW, I should mention that my original attempts at a new way of programming actually led to me to a variation of Lisp on several occasions. That's why I had to laugh when you mentioned that I'm looking for Lisp. It reminded me of all the work I've done to correct those mistakes.
This is probably the best short article that explains why Lisp won't work. The summary is that the Internet is the best computing model for concurrency that we have, so the "programming language" has to fit that model. Lisp simply doesn't fit. Project V can use the Internet itself as the machine it runs on.
http://my.opera.com/Vorlath/blog/2007/11/01/when-it-starts-to-click
Although I talk mostly about imperative programming, the following article is specifically about why the function cannot be used. It's a VERY old article, but probably one of the best ones on the topic of functions.
http://my.opera.com/Vorlath/blog/show.dml/285699
Here's a good article as to how parallelization is better with data flow. It should also explain a little bit about modularity and reuse.
http://my.opera.com/Vorlath/blog/2008/01/06/simple-example-of-the-difference-between-imperative-functional-and-data-flow
This is an article I just wrote not long ago. It shows different techniques in Project V and also has a section on automatic component updates. I'm sure you can note some differences as to why Lisp wouldn't be able to do many of the things mentioned there.
http://my.opera.com/Vorlath/blog/2009/02/13/project-v-development-techniques
There are other articles, but these should provide the basics of why functional is not good enough. I'll recap.
1. Functions require the use of a stacked hierarchy. I need a flat hierarchy because this is best suited for modularity and being able to spread computations amongst computational nodes (like the Internet computing model). IOW, flat computing hierarchies are best suited for concurrency and Lisp doesn't fit that model because it uses functions.
2. Concurrency. Lisp can only handle specific types of concurrency and its substitution model is yet another hindrance.
3. Purity in Temporal vs. Spatial software development. Lisp combines BOTH temporal and spatial development together into a single unit called the function. So it retains an imperative component. This is why certain functional languages have implemented things like monads and arrows. These are dataflow concepts that can remain pure when the functional equivalent is non-pure. So there are more opportunities to use pure components in dataflow than there are in functional because functional retains an imperative aspect. I know most functional programmers don't like this, but it's a fact.
4. Interfaces. I have a plan for having the machine learn over time. I have no idea how Lisp or any other language could even approach the topic.
There are probably more points, but hopefully this gives you enough information on why I can't use Lisp or functional languages. The 'function' is a flawed concept IMO.
Anonymous # 4. March 2009, 14:40
First of all, thank you for the clarification and for the links! It was indeed helpful.
I guess it makes sense to avoid the word "programming language" since it gives one a specific preconception which isn't necessarily true. Programming does have a historical attachment to temporal sequences. Perhaps "software language" is a better more general term?
Yes, I can see how the root "problem" then is due to the reliance on functions and the temporal construction of software which they imply. I don't think that the function is a flawed concept though - it serves its purpose quite well (mathematical functions: dump input in, get result out - a substitution as you said). The issue then is that they have been misapplied to problems which they were never really suited for. I suppose this happened because A) it was easy and B) a lot of software, especially early software, is used to perform mathematical computations, so functions made sense.
I can also agree that spatial software development is much better suited to parallelism and parallel systems is the way computers are moving, so this is certainly an important issue.
Interestingly enough, a project which I have been intending to work on (and am now more motivated to do so, so thanks!) is actually a spreadsheet of sorts. It was originally intended to be a "more powerful spreadsheet" tuned towards a specific set of users to bridge the gap between what these users are used to (Excel) and software specifically designed for their tasks (which generally have too steep a learning curve because the target user is used to using... Excel). However, now I see that this has a lot more potential (I had thought about it before, but discarded the idea for whatever reason) as a general purpose spatial software development system. Spreadsheets are inherently spatial - just much too clumsy and brittle IMHO. They also lend themselves well to dataflow systems.
I think perhaps its time to gather my ideas together (dependency stuff, flat component architectures, concatenative languages, spreadsheets) and design a spreadsheet-based spatial dataflow software language.
I am very interested in learning about how you intend on having the machine learn and am going to read your comment on that as soon as I hit the Submit button :-P
I guess I'll stay quiet now until I have finished reading your links :-D but I must congratulate you on changing my view on these things - it can be difficult to do sometimes (and my first reaction seeing this blog post was "what a twat" - I take it back now).
Vorlath # 4. March 2009, 15:47
About your last comment, don't feel bad. I think the vast majority of the everyone online has called me names at one point or another. I actually revel in it. But the reason I write my articles is because I want to make sure my theories are correct and also to present my conclusions. What really is a waste of effort are those that don't want to understand the topics I present. They never present anything about the facts. So even though I'm called a nutjob, it's the name callers that I feel are losing out.
I enjoyed responding to your comments, but I hope you will speak up if you find something you disagree with. Doesn't mean I'll agree with you, but I'm not here to convince anyone. I'm here to share ideas. That's why I was happy to see you have your own ideas and projects in mind.
Good luck!
About machine learning, that's in the future. I need to finish a beta of Project V before I get into that. It's a simple concept, so I'm not sure what else to say about it. Have a repository of interfaces with different implementations. When developing software, you would mostly use interfaces. The main concept is that one layer's interface is another layer's implementation.
For example quicksort is an interface. You can implement it in many different ways. But the quicksort interface is also an implementation for the sort interface.
The result of this is that you can specify implementation as high up as you wish. For example, if your application is meant to play videos, then in contemporary programming, you main function would be an implementation for the VideoPlayer interface. If a user wants to play a video, the machine will load up the implementation that the user has previously set up. But VideoPlayer can be used as an implementation in other software as well. Do you see how an interface can be used both as an implementation and an interface? Project V will use the highest level implementation possible. Most high level implementations will end up using more lowel level interfaces, so the process repeats until Project V sees a machine specific implementation available to its own database on the machine itself (external to the software). The software would only supply these generic implementations that use other interfaces. Project V would extract these generic implementations and store them locally.
Also, you can provide machine specific implementations if you wish directly within the application, but you'd normally simply supply a link to your site for Project V to retrieve implementations from. If they apply to the current machine, it will extract this as well and place it in the local implementation repository. So another program that uses the same interface will know how to do that task without having to fetch it.
What this also means is that your software will be continuously updated if many different software developers use the same set of interfaces. I'm hoping to have a global official standard set of interfaces that people can use.
The purpose of this is that no one is locked to ONE set of opcodes like the JVM and all other virtual machines. So interfaces are your new opcodes. In the future, if certain interfaces start to have widespread use, hardware manufactures may provide hardware implementations. Won't be limited to video codecs and the like. ANYTHING that is in widespread use could be put into hardware. Not only that, but you could have technology where you can add these on. You can have interface modules. If you want an xvid codec, plug it in. If you want a 3D renderer, plug it in. If you want a faster quicksort, plug it in.
It could significantly change the way we produce software. At least I hope so.
The main point I hope you take away is that ALL software that uses any of these things would AUTOMATICALLY start using the hardware versions since they would be better (or they should be anyways).
Project V doesn't care WHAT or HOW the implementation works. Heck, a human being could provide computions with pencil and paper if provided with a way to input data. So humans can be implementations as well. Project V software could span different architectures. You could have machine1->human->machine2 and be a valid network. I've never heard of such a thing, but it'd be perfectly acceptable, if terribly slow. In fact, this is EXACTLY how user interfaces are going to be constructed. The human user is PART of your software.
Hope this helps see the bigger picture, and that yes, maybe I am crazy. But maybe you can also see why being called names brings out a sense of pride.
Anonymous # 24. May 2009, 19:30
I like your comments. I am going to quote to to conclude the paper I have written about computer programming languages.
Vorlath # 24. May 2009, 23:51
Anonymous # 25. May 2009, 17:03
Hi again :-P
I'm just wondering what you think of the Oz programming language? (I'm sure you know it, but if not: http://en.wikipedia.org/wiki/Oz_programming_language its an interesting multi-paradigm language which has some dataflow elements)
I started reading Concepts, Techniques and Models of Computer Programming, which uses Oz for the examples and was wondering what your view of this language is. Its obviously nothing like Project V, but surely its closer than most languages, or?
Looking forward to hearing your thoughts.
Dan.
Vorlath # 4. June 2009, 17:13
Dan writes:
Speaking of CTM, the first chapter dealing with concurrency states "Concurrency need not be difficult" and then proceeds to talk about dataflow. Coincidence? Of course not.
Even more interesting, in the chapter about storing internal state, it briefly mentions that in the next chapter they reintroduce concurrency, this time in a stateful model, like the one we know and love from mainstream programming languages. It then states that "programming in this model is extremely difficult".
So CTM agrees: dataflow makes concurrency easy, traditional models make it hard! No surprises there, but interesting to see stated so clearly by someone who, presumably, is not biased (because, lets face it, even though you've been saying it all along, you're clearly biased (for good reasons, I admit) towards dataflow).
Vorlath # 4. June 2009, 17:19
As to Oz, I only looked at it briefly. I wasn't impressed, but it's been too long, so I can't mention specifics right now. It's nice to see dataflaw being recognized as a valid tool though. Thanks for mentioning the reference.