I can't help but have the strong feeling that you're on to something.
For the last couple of weeks I've been trying the best I can to read everything under the sun that has to do with alternative computer architectures. I know that just like in 'regular' science there is a fringe to computing, but what if there are viable alternatives to the von Neumann architecture and we just stopped looking for them ?
Even a really good alternative way to program existing computers would already be quite a step.
I don't have enough low level programming experience to say one is better than the other or that the Harvard architecture is as flexible as the Von Neumann architecture has proved to be in practice. I am just not that good of a computer scientist.
I can say, though, that I found Harvard an awful lot easier to get to grips with conceptually and fun to program - perhaps because I could map me+tool+task onto instruction memory + DSP + data.
If you are seriously interested in this I recommend getting hold of a DSP evaluation board for about $100. Analog Devices make the Sharc (and many others) which some people like because of their floating point capability; Motorola's 56k DSP series are fixed point which makes for a steeper learning curve, but many people say they're a better architecture. I learned 56k DSP. You could also look into PIC uControllers.
Please summarize and share your findings when you reach some sort of milestone.
Harvard architecture is pretty boring since it is strictly less powerful than von Neumann architecture; you can trivially emulate Harvard architecture on a regular computer by just not loading or storing from your text segment.
I've used DSPs with this architecture and I don't think it is a major contender to von Neumann, it has its applications though (DSP, embedded systems).
The original poster of the article has some very interesting things to say about the way computers are being programmed today. I'm not sure if that means we will depart with von Neumann, a radically different approach to programming would already give us some new insights.
I'm going to get shot down for this for sure, but since LISP there really has been no new original idea in how to write software. Java, python, PHP, C, C# and so on all look the same to me.
Languages that are different directions such as Forth, LISP and handfull of others have my interest because I think they will show us a path out of the swamp we are currently in.
Some of the people here on HN have side projects on the go that are extremely interesting from this point of view.
This article describes model driven application development, the focus of my current company, where an application is considered to have a model that describes the application state and a domain specific model and the model that describes application state may be varied dynamically. This is completely distinct from programming. Programming is about manipulating data and how a computer actually operates on data (threads & ram etc). Somebody will always have to do programming in some language in order to enable "interesting" business users with such point of views to do things easily. The other side of the model-driven coin (distinct from UI code) is using rules to describe data transformations. This is not exactly a shameless plug because I am leaving this company but you can see model driven development in action by downloading TopBraid Composer Maestro Edition http://www.topquadrant.com/products/TB_Composer.html and navigating to http://localhost:8083/tbl You will see several applications which you can select and then select a data model to work with.... at that point your application is in a particular state (such and such widget configuration) that application state may then be saved off as another application and so forth. Going back to TBC you can see that actual data models that represent this application state and you can look into SparqlMotion and SPIN for how inferencing can be used to add support for rules in a model driven manner. The advantage of TQ's approach is that it is based on open standards most notably RDF, which is a sufficiently generic data model that it may be considered universal. I still believe that actually implementing components and complex algorithms should still be done in code. To me the memory state of an operating system represents a very particular closed world that can then be mapped to the general, open world expressed in RDF (or however you like to express the universe of data, I believe RDF is best atm)
FTA: We like the element of discovery that comes from not knowing exactly how things will behave if they are joined together or taken apart. We like to say things like, “oh”, “aah”, or “that’s cool” when we half-intentionally fumble our way into a surprising design that does exactly what we want it to do and more.
Dijkstra, EWD 1041:
The programmers were horrified too: they derived their intellectual excitement from not quite understanding what they were doing and their professional satisfaction from finding weird bugs they had first introduced in their daring irresponsibility.
I'll add, people (users) tend to like it when their professionals know what they are doing. Surgeons shouldn't use chainsaws, even though it'd be more fun to do so.
This article appears to argue against basic facts about formal languages and the limits of machines. The argument seems to go something like "I don't like programming languages because they force me to work in a certain way! Now, here's another way to do programming!"
The "programming environments as toys" argument seems to be at odds with fixed syntactic and semantic interpretation for programming languages, which is a bit like arguing against steering wheels for cars - sure, having the car drive itself would be nice, but throwing away the steering wheel is really not going to have the desired effect.
Programming is not the only discipline that has adopted specialized languages. Disciplines like music and mathematics also use their own unique descriptive notations. Programming is not hard because of programming languages; on the contrary, learning a programming language is by far the easiest step in learning to program. Becoming a good musician, or a good mathematician, takes years of practise and study. Programming is no different.
That's not to say you can't simplify programming, in the same way that Guitar Hero and Wii Music simplify music. But you can only do this by hiding complexity, by restricting the user to a small subset of a very broad subject. This can be very useful; but you can't replace programming altogether using this technique, any more than Guitar Hero has made the electric guitar obsolete.
Not to disagree with your substantive point, but I think Guitar Hero is a very poor comparison. As far as I'm aware, there's no way to take one of these toys and create any kind of original music with it, other than by smashing it into something and recording the resulting noise. A better comparison would be instruments for making (mostly) electronic music, such as synthesizers, samplers, and sequencers.
These things too can become arbitrarily complex within their specific domains (Csound being a prime example), but most of the innovation is devoted to making it easier for the mediocre player to obtain interesting musical results, at the expense of some flexibility or authenticity. This can aid learning to some degree, and substantially democratizes toolsets - for example, although I have neither the space nor the cash to buy a piano, I have access to such good emulations that it doesn't matter. Of greater importance than either of these are the innovative possibilities for creating new kinds of music that are not achievable by conventional means - even if you dislike electronic music, you probably enjoy the contributions from of audio technology to film soundtracks.
You are quite right that electronic emulations will not and should not displace real instruments like guitars, trumpets, drums etc., no matter what their level of sophistication. The same is true is of domain-specific modeling tools and pure programming. However, I submit that within their limitations, such tools have the potential to vastly increase overall productivity. And as I've observed before, patch-based 'analog computers' have a trick or two up their sleeve yet: now that cheap digital von Neumann computers are a commodity, people are doing interesting and usual things with the emulated versions that would have been prohibitively expensive in the past.
He is arguing against "linguistic programming" and apparently proposes a graphical form of component-based programming.
This has been proposed before, and here is why it will not work: Core to programming is creating abstractions and naming them. No other tool (that I know of) beside language can do that. Sure, a graphic environment might let you connect a bunch of pre-defined components on the same abstraction level to solve a task. However, what will you do if you want to reuse this construct as part of a larger program?
Graphical tools/programming can be used for very specific pre-defined tasks on a single abstraction level, but it will never be useful for general programming.
Then maybe we need a nice bijection between a nice language (a Lisp, perhaps?) and a nice graphical language (maybe a Lispier version of LabView or this COSA nonsense).
What if the "components" are closed under the method of composition? You could probably get quite a bit of abstraction that way, not that it would be more powerful than what we already have which at least has this tool for creating abstraction...
But how would you represent your new composed component in the larger picture? Only solution I see is to give it a name that indicates the function. And pretty soon you are just moving boxes with names on around the canvas.
MATLAB's Simulink[1] is a graphical programming environment that allows you to create, name and reuse abstractions. Look at the picture[2] on their site for a simple example.
That is cool, but I am arguing that when you work primarily with named abstractions you are back to linguistic programming. And general purpose programming is about building abstractions on top of abstractions.
People have been experimenting with object models and component models for 30 years. Despite considerable progress, no one has found anything that really knocks your socks off. Old news.
True. In my opinion, it's because they got it wrong. The trick is to find the lowest common denominators of software, the DNA elements of software, if you will. These are the basic building blocks on which everything else is built.
Once you've done that, you need to come up with an organizational plan, not just for a given applications but for the entire universe of software applications. Like everything else in nature where order and complexity are the names of the game, the plan calls for a tree-like structure in which every possible application or object is a node in the tree. That, my friend, is the future of software construction. It's a future where every body and their uncle who uses a computer, is a programmer, whether they like or know it or not. Not a very enticing future for current programmers (their skills and knowledge will be obsolete) but an exciting one nonetheless.
Take a look around the site, the guy's a crank. He's been talking about how great COSA is for years, but he's never actually implemented it, or even shown examples of how it's supposed to look beyond a few trivialities.
My PhD supervisor and I talked about this, as the creation of a new category of IT worker: a component assembler .
It is less hardcore than a "real" programmer, but we are now at the point that you a person can create great value by assembling pre-existing components and create genuinely new things. The components amount to an abstraction, and the key questions are whether you can make an abstraction layer that is simple, and yet also powerful enough to accomplish worthwhile tasks without needing to break the abstraction. As examples, consider components in fields of engineering: nuts, screws, nails, resistors, capacitors, chips etc
The difficult part seems that putting these components together itself becomes a complex and difficult task. However, if we are prepared to limit the power, it is possible to make it simpler: consider audio components that plug together; or bicycle and car components. Maybe this is limited to "customization", but for some purposes, that's all you need to do. And with components that are sufficiently powerful, perhaps you really can build really useful new things.
Glue languages, like Python, already facilitate this to some extent, although the process of assembly is more complex than the blogger wishes, and of course people can and do real programming in Python.
There are words for proper "bigger Lego bricks": HLLs and libraries. There's also a word for the kind he wants: Duplo.
Also, you haven't known pain until you've tried to actually accomplish something by stringing together pretty boxes in a data-flow language like Max/MSP or Pure Data. Imagine operating an early AT&T switchboard with a pool cue, then crank up the suck.
It sounds like he wants something like Automator (http://www.macosxautomation.com/automator/) where you can just create sequences from very high level blocks of functionality. That has it's uses, of course, but it's not even on the same level as "real" programming, IMO.
29 comments
[ 5.5 ms ] story [ 83.3 ms ] threadFor the last couple of weeks I've been trying the best I can to read everything under the sun that has to do with alternative computer architectures. I know that just like in 'regular' science there is a fringe to computing, but what if there are viable alternatives to the von Neumann architecture and we just stopped looking for them ?
Even a really good alternative way to program existing computers would already be quite a step.
I don't have enough low level programming experience to say one is better than the other or that the Harvard architecture is as flexible as the Von Neumann architecture has proved to be in practice. I am just not that good of a computer scientist.
I can say, though, that I found Harvard an awful lot easier to get to grips with conceptually and fun to program - perhaps because I could map me+tool+task onto instruction memory + DSP + data.
If you are seriously interested in this I recommend getting hold of a DSP evaluation board for about $100. Analog Devices make the Sharc (and many others) which some people like because of their floating point capability; Motorola's 56k DSP series are fixed point which makes for a steeper learning curve, but many people say they're a better architecture. I learned 56k DSP. You could also look into PIC uControllers.
Please summarize and share your findings when you reach some sort of milestone.
The original poster of the article has some very interesting things to say about the way computers are being programmed today. I'm not sure if that means we will depart with von Neumann, a radically different approach to programming would already give us some new insights.
I'm going to get shot down for this for sure, but since LISP there really has been no new original idea in how to write software. Java, python, PHP, C, C# and so on all look the same to me.
Languages that are different directions such as Forth, LISP and handfull of others have my interest because I think they will show us a path out of the swamp we are currently in.
Some of the people here on HN have side projects on the go that are extremely interesting from this point of view.
Dijkstra, EWD 1041: The programmers were horrified too: they derived their intellectual excitement from not quite understanding what they were doing and their professional satisfaction from finding weird bugs they had first introduced in their daring irresponsibility.
I'll add, people (users) tend to like it when their professionals know what they are doing. Surgeons shouldn't use chainsaws, even though it'd be more fun to do so.
The "programming environments as toys" argument seems to be at odds with fixed syntactic and semantic interpretation for programming languages, which is a bit like arguing against steering wheels for cars - sure, having the car drive itself would be nice, but throwing away the steering wheel is really not going to have the desired effect.
Programming is not the only discipline that has adopted specialized languages. Disciplines like music and mathematics also use their own unique descriptive notations. Programming is not hard because of programming languages; on the contrary, learning a programming language is by far the easiest step in learning to program. Becoming a good musician, or a good mathematician, takes years of practise and study. Programming is no different.
That's not to say you can't simplify programming, in the same way that Guitar Hero and Wii Music simplify music. But you can only do this by hiding complexity, by restricting the user to a small subset of a very broad subject. This can be very useful; but you can't replace programming altogether using this technique, any more than Guitar Hero has made the electric guitar obsolete.
These things too can become arbitrarily complex within their specific domains (Csound being a prime example), but most of the innovation is devoted to making it easier for the mediocre player to obtain interesting musical results, at the expense of some flexibility or authenticity. This can aid learning to some degree, and substantially democratizes toolsets - for example, although I have neither the space nor the cash to buy a piano, I have access to such good emulations that it doesn't matter. Of greater importance than either of these are the innovative possibilities for creating new kinds of music that are not achievable by conventional means - even if you dislike electronic music, you probably enjoy the contributions from of audio technology to film soundtracks.
You are quite right that electronic emulations will not and should not displace real instruments like guitars, trumpets, drums etc., no matter what their level of sophistication. The same is true is of domain-specific modeling tools and pure programming. However, I submit that within their limitations, such tools have the potential to vastly increase overall productivity. And as I've observed before, patch-based 'analog computers' have a trick or two up their sleeve yet: now that cheap digital von Neumann computers are a commodity, people are doing interesting and usual things with the emulated versions that would have been prohibitively expensive in the past.
Actually the latest version of Guitar Hero ('World Tour') does include the ability to record, edit & share. It's very limited of course.
This has been proposed before, and here is why it will not work: Core to programming is creating abstractions and naming them. No other tool (that I know of) beside language can do that. Sure, a graphic environment might let you connect a bunch of pre-defined components on the same abstraction level to solve a task. However, what will you do if you want to reuse this construct as part of a larger program?
Graphical tools/programming can be used for very specific pre-defined tasks on a single abstraction level, but it will never be useful for general programming.
And by "cumbersome," I mean it gets to the point that just using a programming language would be both simpler and clearer.
[1]: http://www.mathworks.com/products/simulink/
[2]: http://www.mathworks.com/cmsimages/sl_fig1_wl_15362.gif
But I haven't used Simulink, so I may be wrong.
People have been experimenting with object models and component models for 30 years. Despite considerable progress, no one has found anything that really knocks your socks off. Old news.
Once you've done that, you need to come up with an organizational plan, not just for a given applications but for the entire universe of software applications. Like everything else in nature where order and complexity are the names of the game, the plan calls for a tree-like structure in which every possible application or object is a node in the tree. That, my friend, is the future of software construction. It's a future where every body and their uncle who uses a computer, is a programmer, whether they like or know it or not. Not a very enticing future for current programmers (their skills and knowledge will be obsolete) but an exciting one nonetheless.
http://www.rebelscience.org/Seven/bible.html http://www.rebelscience.org/Crackpots/notorious.htm
He has a good sense of humor about it though and even links to this Google search:
http://www.google.com/search?hl=en&q=%22louis+savain%22+...
It is less hardcore than a "real" programmer, but we are now at the point that you a person can create great value by assembling pre-existing components and create genuinely new things. The components amount to an abstraction, and the key questions are whether you can make an abstraction layer that is simple, and yet also powerful enough to accomplish worthwhile tasks without needing to break the abstraction. As examples, consider components in fields of engineering: nuts, screws, nails, resistors, capacitors, chips etc
The difficult part seems that putting these components together itself becomes a complex and difficult task. However, if we are prepared to limit the power, it is possible to make it simpler: consider audio components that plug together; or bicycle and car components. Maybe this is limited to "customization", but for some purposes, that's all you need to do. And with components that are sufficiently powerful, perhaps you really can build really useful new things.
Glue languages, like Python, already facilitate this to some extent, although the process of assembly is more complex than the blogger wishes, and of course people can and do real programming in Python.
Also, you haven't known pain until you've tried to actually accomplish something by stringing together pretty boxes in a data-flow language like Max/MSP or Pure Data. Imagine operating an early AT&T switchboard with a pool cue, then crank up the suck.