My OperaThe Programming Language of the Future is in /dev/null
Friday, May 19, 2006 3:23:32 AM
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.
Anonymous # Monday, August 6, 2007 12:54:34 AM
Anonymous # Monday, August 6, 2007 12:55:04 AM
JKjonkvh # Tuesday, September 18, 2007 3:40:52 AM
Anonymous # Friday, March 21, 2008 10:19:47 AM
Anonymous # Monday, February 16, 2009 1:02:21 PM
Anonymous # Wednesday, February 25, 2009 2:10:56 PM
Anonymous # Wednesday, February 25, 2009 3:43:57 PM
Vorlath # Wednesday, February 25, 2009 10:13:51 PM
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 # Thursday, February 26, 2009 2:59:48 PM
Vorlath # Thursday, February 26, 2009 4:01:14 PM
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 # Tuesday, March 3, 2009 10:22:12 AM
Anonymous # Tuesday, March 3, 2009 4:42:59 PM
Vorlath # Tuesday, March 3, 2009 9:17:27 PM
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 # Wednesday, March 4, 2009 2:40:03 PM
Vorlath # Wednesday, March 4, 2009 3:47:29 PM
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 # Sunday, May 24, 2009 7:30:20 PM
Vorlath # Sunday, May 24, 2009 11:51:32 PM
Anonymous # Monday, May 25, 2009 5:03:17 PM
Vorlath # Thursday, June 4, 2009 5:13:03 PM
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 # Thursday, June 4, 2009 5:19:31 PM
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.
Anonymous # Monday, July 20, 2009 6:38:33 PM
Anonymous # Tuesday, April 13, 2010 12:57:41 PM
Anonymous # Wednesday, April 14, 2010 1:22:42 AM
Vorlath # Wednesday, April 14, 2010 2:58:17 AM
Functional languages do worry about order of execution. The data dependencies are tied to the execution, so the order is manipulated that way.
Functional languages are not implicitly parallel. Some of them can do certain things, but many of them implement specific functions like 'par' to execute things in parallel.
Also, this kind of parallism (whether automatic or by a built-in function) can only do certain kinds of parallel operations. For example, functional languages cannot send data without being impure. This is somewhat related to I/O, but only somewhat. Suppose a function is processing some data, but the called function suddenly receives data. Both functions cannot process data at the same time since the invoker uses the return value of the invoked function. This is the return to sender restriction that inhibits certain kinds of parallel operations. What languages like haskell have done is implement dataflow constructs to get around this. Dataflow can do things and remain pure whereas functional languages can only do them if they become impure. I/O being the most well-known culprit. But it applies to all sorts of situations requiring parallel processing.
Computing isn't restricted to programming languages. Learn about circuits and dataflow. Two common ways to compute something without a programming language.
Actually, it isn't. If you have operations that are coupled time-wise, then you cannot execute them at the same time. OTOH, if you have operations that aren't coupled in the time domain, you can execute them in parallel.
Incorrect. Concurrency is the ability to execute different operations at the same time. Parallelism is executing the same operations at the same time.
Note that many people use the word "parallel" to mean anything that executes at the same time (or through task switching) in general. I'm ok with that use as well.
This is incorrect. You can distribute tasks based on spatial domain.
So you're running different tasks on the same data? Ok, but that's just one subset of what is possible.
You're contradicting yourself with your terms.
Parallel = ONE VERSION OF CODE.
Concurrent = DIFFERENT CODE.
Please get this straight.
And true parallelism, whatever you mean by that, is inferior to concurency. It is also inferior to distributed computing where different code on different machines work together.
It depends on how the data is coupled in the spatial domain. Same thing with the time domain. You can't just issue a blanket statement like you did.
If I have two pieces of data A and B where B is a child node of A, then you need to traverse A before getting to B. There is no way to process both nodes at once. It is impossible. As such, even though they are in the spatial domain, there is no data parallelism possible here.
OTOH, a 2D image has its pixels coupled in position only. In the real world, we have to go from point A to point B as mentioned before. But in computers, we can jump to any pixel in the image. So the spatial coupling is actually removed. And when you can use data that is NOT spatially linked can you achieve parallelism.
But it's not the only way. You can achieve parallelism even in the first case if you have a development environment that can use the spatial domain. For example, pipelining is where one piece of data is dependent on the next piece of data and yet we can split up the steps so that step 1 is operating on data C while step 2 is operating on data B and step 3 is operating on data A. This is not possible in imperative or functional languages.
Also, your time domain assertion is likewise flawed. I could go through examples, but this is long enough as it is.
I'm afraid you've been brainwashed. There are only two kinds of processing possible. Imperative (von Neumann) or dataflow. That's it. There is nothing else more basic than that. Everything else is built on top of either one or both. Yes, even functional languages. I'll tell you right now that you cannot have a functional language without an imperative core.
Please tell me how this non-imperative processor would be designed? I'm all ears.
I won't have the same problems as you because dataflow is having multiple processors that only do ONE thing connected together. The Internet has millions of machines connected together that would work great for dataflow programming. Not only that, but multicore systems are commonplace now. Again, dataflow can live quite nicely here. And get this... The processors on these multicore machines can execute DIFFERENT THINGS!!! So I can reuse them for whatever operations I need in my dataflow network.
Functions have the return to sender limitation. There is no way that this is the most powerful design while that limitation is in place.
Oh, and dataflow is inherently parallel and distributed. It's one of its properties. With functional programming, this is certainly not the case as there are severe restrictions to what kind of parallelism is possible.
Did you miss the double quotes?
I was talking about the hardware layer that the software would run on. Dataflow is the only thing that can natively operate on the hardware of the Internet. Everything else is programmed to specifically talk to other nodes on the Internet. It's the difference between executing on many machines vs. executing on the Internet itself.
If you like the word "abstraction", then a better explanation is that dataflow abstracts away the individual nodes of the Internet and treats it as a single machine.
Actually, I did go into all these details at several points in this article and in other articles on my blog.
If you have any questions, I'll be happy to answer them. So don't think I'm hiding or refusing to provide any information
you may want.
Nonsense! This is ridulous. Functional proponents have been keen to claim ownership of anything they start including in their languages even if it has nothing to do with functional programming. Dataflow was invented by John Paul Morrison in the early 1970's when he worked at IBM. Functional programming was alive and well at the time and no one would have claimed that it was based on functional programming.
So please do everyone a favour and stop spewing nonsense like this. It doesn't help your credibility.
More nonsense. Functional programming is also limited by the return to sender limitation.
HAHAHAHA!!! This is laughable. This shows a great deal of naiveté on your part. You've been thoroughly brainwashed.
Unfortunately, the premise of your argument has been thoroughly debunked. So your attempt at cleverness has unfortunately fallen flat on its face.
Anonymous # Wednesday, April 14, 2010 4:58:43 PM
Anonymous # Thursday, April 15, 2010 2:16:34 PM
Anonymous # Thursday, April 15, 2010 3:46:15 PM
Anonymous # Thursday, April 15, 2010 5:26:48 PM
Vorlath # Thursday, April 15, 2010 9:04:30 PM
It's unidirectional message passing. Not the likes found in any other "paradigm". But you knew that, didn't you? Ahem.
Map/Reduce is a dataflow concept. Not a functional one. This one has been repeated so often that I don't know whether it's just for laughs or what. But it's completely baseless. Plus, the functional way of doing map/reduce is highly limiting. Again, you knew all this. Ahem.
No it isn't. It can make use of them, but it requires a multitude of processors where each one can do only ONE operation (heck, it only needs a NAND or NOR operation, either one will do.). But if that processor can accomplish more than one operation, then all the better.
So you see that dataflow has NO REQUIREMENT for von Neumann.
But you knew that too. Ahem.
I don't know who's replying to who in the rest of the comments. Accusing me of working for Microsoft is hilarious.
I'll respond to the following though.
From 1970's? Why would I think that the 70's are new?
That's exactly what I'm saying. Remove I/O from functional programming to keep them pure and see if you can get anything done.
No, because they are not functional in nature. Maybe he was inspired by something he saw in functional that could be improved. I don't know. But anyone that thinks dataflow is in any way functional in nature doesn't understand computing at all.