It's really hard to scale these kinds of clusters beyond certain limits, once you start getting into all the practical details.
There's the basic facilities stuff: fitting enough power and cooling density into a single datacenter to cram that many nodes within a reasonable distance of each other for cabling purposes.
There's the network architecture. A single switched network between your nodes doesn't get you all that far. Depending on the characteristics of the expected workload and all that jazz, there are many different technologies and topologies to choose from.
Don't forget storage and data moving in general. The data has to reach the processors somehow, and 2000 nodes mounting an nfs share from some central box just isn't going to work at all...
Then there's node management: installing/imaging, booting, detecting failures, recovering with minimal human intervention (automatic re-imaging), monitoring it all, etc. You could skip this step and hire a truckload of junior sysadmins and have them running all over the place with CDs and keyboards and monitors, but that doesn't really scale to thousands of densely packed nodes does it?
As another reply states - if you don't find the right solution to all of these problems, you face scalability limits. With a given overall design, there's going to be a maximal node count, beyond which scaling is infeasible or futile. It really is hard stuff.
Luckily the opensource world is making headway on some of the software-side manageability issues. For an example check out rocks.npaci.edu.
Harnessing that much of the tidal/wave energy will doubtless change the environment in bad ways. Are these people so stupid as to actually believe that they're tapping from a free power source here that won't affect anything else?
Spend the money on fusion research, it's the most viable long term option we've got at the moment. And when we succeed at fusion, that in turn will sustain humans long enough to advance far enough to move to space-based solar or other better systems.
It would be fairly easy to reduce the whole EM inteference argument with a better design for housing, communications, and power for the EGG/RNG/REG.
1) Design a power system that isn't susceptible to anything from AC line noise and frequency/voltage drifting. There are many ways to go about this - most of the simplest ones involve a pair of rechargeable batteries and a switch - at any given time one is being charged by the filtered DC coming from a wall socket adapter, and the other is powering the device. Capacitors can keep the voltage ok during the milliseconds it takes to flip the switch. (And the switching events timetsamps should be noted just in case they cause any spike).
2) Shielding. Put the device inside a cage that allows no EM interference, a lead hull and/or multiple faraday cages of different hole sizes. Might want to put some antennaes at various wavelengths inside the shielded area which record EM levels of various types, so that those an be correlated to the output (We got an event! Oh wait, there was an EM spike inside the cage at the same time, nevermind).
3) Communications: Shielded cable. Smarter processor inside. Processor should do a hash/checksum of packets of RNG data and include this checksum on each packet sent out of the shielded device, and also should buffer the data locally and employ and error-correction and retransmission protocol. This solves the problems with random bits flipped outside the confines of the shielded RNG device. Opto-isolate the electrical communications path between the RNG and the machine --- or better yet, just use a fiber-optic link.
The fac tthat these guys don't appear to be taking any steps in the above directions shows their scientific weakness. I still don't completely discount their results, but I'd like to see more of the same under more rigorous isolation.
Per-processor licensing has always been a shady sham thing anyways. The industry really needs to get the hell away from it. Even before this multi-core monkey-wrench got thrown in, it never made sense. Why should I pay twice as much to run your code on a crappy old quad 200Mhz Pentium Pro as I do to run it on a dual Opteron? Why should I pay more to run on a dual P3-933Mhz than I do to run it on a single P4-3.2Ghz? Some vendors try to bandaid the situation by classifying architectures and machine types into tiered per-processor pricing, but these inequities still abound even then.
If they're really stuck on the asinine idea that I should pay more for their code if I run it on bigger hardware, they could at least rate all the possible platforms they support in terms of MIPS or GFLOPS or something and charge per-performance-unit licensing.
Don't forget there's always a tradeoff between the costs paid to vendors and employment costs. Some companies choose to spend a lot more money on buying large fancy oversize overfeatured hardware and software with big support agreements and vendor consulting added into the purchase, which makes the employees' work much simpler and smaller. Some choose to nickle-and-dime everything on the vendor side, buying bare minimum generic stuff with minimal support (sometimes nonexistant other than warranty repairs) and then they pay more to hire a larger number of smarter employees to get it working and keep it working for them. Depending on your situation, your company, and your requirements, the optimal balance between these two extremes will be different in every situation. In the big picture sense, readjusting along this scale to somewhere that's most efficient for you can be a good overall direction to look for cost-savings in.
The "smarter" ones did better than the average ones in a no-pressure situation, but all involved did equally poorly when under pressure. A more accurate conclusory title might have been "Nobody performs well under pressure, even smart people".
In terms of the raw totals of important and useful software written in a language, and how widely society in general uses and relies on code written in a language, C has been the most widespread, useful, and productive language in the history of computer science. From telephone switches to operating systems to video encoders and a million other places. There are far worse things to look to for inspiration.
NFS, PAM, XFN, etc that you list... the standard was set by Sun as an open standard, but the open source versions of them were reinvented on the outside, not donated by Sun.
Sun didn't invent Gnome, they adopted it as a commercial strategy. The primary gnome developers were not Sun employees, although I havent kept track if they have become so recently.
OpenOffice is definitely a huge chunk of GPL code, but they also didn't develop that. They purchased a dying company and opensourced the company's product. It was a cheap move aimed at poking holes in Microsoft's officeware dominance.
I know full well about Sun's positions on the matter. I've raised the merits of Open Source repeatedly to my Sun sales and technical representatives, who generally frown at me and hand me Sun company dogma about how they're going to crush linux into the ground, and that open source is just a phase.
You're counting contributions by sun employees semi-officially and/or on their own time. Sun as a corporate entity isn't as giving to the GPL as you have portrayed them.
This brings a whole new meaning to the term "Rice Rocket". He does realize the flaw in his analogy right? You don't buy a Ferrari because it's reliable, you buy a Ferrari because you can hit 200 in it. If you try to bolt junkyard parts on a Honda in an attempt to go 200 in it, it will be far less reliable than the Ferrari.
Yes, computer generated art is art. Just like any form of art, is art. There's nothing relovutionary or special going on here, and your computer itself is not an artist. Neither is the code you wrote. You are the artist, and the code your wrote is a self-made tool, and the output is art which should be accredited to yourself.
I was there, thank you very much. But this server-side push with Java is still silly IMHO. More effort should have been put into making it the most viable client-side language, which it never became. Why on earth would anyone run their server-side inside a VM? The server side is the platform you control, the one where you can choose a single platform and don't have to worry so much about portability...
I still blows my mind that Java has come as far as it has to date on the server side, and equally blows my mind that it didn't make better inroads as a platform for thin client GUIs.
In the second edition of the book (which sports not only LarryWall as author, but also Tom Christiansen and Randal L. Schwartz as co-authors), there is a glossary which has pithy definitions for each of these terms:
Laziness
The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer, Also hence, this book. See also impatience and hubris. (p.609)
Impatience
The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to. Hence, the second great virtue of a programmer. See also laziness and hubris. (p.608)
Hubris
Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer. See also laziness and impatience. (p.607)
Seems most of the world is happy running an OS that can be remotely crippled at will by the underhanded, and they're about to get DRM forced down their throats, which effectively allows corporate and government interests to legally cripple you. This isn't much different.
I don't love Java. All things considered, I don't see that their efforts at cross-platform compatibility are really a big win over things like the Standard C Library. In both cases, you have a language and a supposedly cross-platform standard set of library calls, and in both cases you end up having to code around the quirks of the platforms you run on. I think the right place for Java to have targetted, the place where it could have been the most useful, was as a client-side platform-indepedant environment, ala Applets in the web browser and whatnot. Unfortunately all the effort went into perfecting a server-side environment instead.
This is just HA load-balancing of your inbound web traffic. Clustering is what happens on the back end between the servers, which the articles doesn't cover at all, presumably because in the example case the servers are just serving static content over http, and all that's needed to "cluster" it is to copy your changes to both machines when you change the static data.
The hard part of clustering is getting real HA and/or Loadbalancing for non-trivial content. Imagine if the websrever behind Kimmy's DNS setup was hosting an SSL-based service, where users logged into sessions, and posted on a message board to each other.
Now you have to get SSL working right for multiple machines, and you have to get sessioning to work right between multiple machines (the user's session would jump between servers with Kimmy's DNS), and the database the message board is storing in would have to be consistent across both servers.
The easy solution to most of this is of course to put the session-state in the same database as the message board, and put the message board database on a seperate back-end machine that both webservers hit, thereby removing all state from the web cluster. But now you've introduced a new single point of failure at the database level - DB goes poof, your webservers dont matter much.
So there's no easy way out of this, you can't play shell games and try to make the single points of failure magically disappear. May as well leave the database on the web server nodes (assuming load/space aren't problems), and use some kind of clustered database solution...
One way or another, you'll have to do real clustering at some layer - which will inevitably involve heartbeats and quorums and all that jazz, the complicated stuff referred to in the first paragraph of Kimmy's page.
You'll note I referenced LISP in my original post, I'm not unfamiliar with it. LISP does lack some high level expressiveness, but just like any turing complete language, you can of course invent such expressiveness in your code at the cost of some more characters typed.
I think we have failed to agree on what "expressiveness" means. I meant expressive in the sense that more information can be conveyed with a minimal code size. By my definition as I was using it, assembler is the least expressive practical language, and some hypothetical 4GL would be the most expressive. C is considerably better than assembler, and C++ and Java fall somewhere in the middle of C and that theoretical peak.
So by that I'm saying that while you can express anything in LISP that you could express in any other language, LISP is not as "expressive" by virtue of the fact that not as many idioms are embedded into the language design.
And it wouldn't be that hard to write a C-parsing library like our XML-parsing libraries. Nobody has done it because there isn't a great need. When people write tools that need to parse C, they tend to just roll their own. Might not be a bad project for someone to start up a reusable C-parsing library.
Just to drive home how silly this company is, realize that not only is their "Wireless Charging" really just inductive coupling, but that inductive coupling is basically what a Transformer does. You know Transformers, which have been ubiquitous since electricity came into widespread use. They're in every freaking wall dongle and virtually every electronic device's power supply. The difference between "Inductive Coupling Chargers" and transformers is that a transformer is housed in a single case, whereas the charger split the transformer out into two distinct coils in seperate package, which you place close to each other to transmit the inductive energy.
For that matter, my Sonicare toothbrush has been recharging via an inductive coupler for years now, so it's not like even this particular incarnation is new to the commercial world.
You could of course in theory build a PCI card ramdisk out of PC2700 memory (I remember a magazine had some rather simplistic plans way back when for building such a beast from old school DRAM chips on an ISA card). The problem is that the D in DRAM means Dynamic. When you lose power, you lose all the data. SRAM (Static) actually keeps it's state when you power it off, more like a hard drive does. SRAM is however considerably more expensive than DRAM. There are several vendors of commercial SRAM disks sporting IDE and SCSI interfaces these days, but the prices will scare you for any decent size.
However, if the "low latency storage" you need for your app can be wiped on powerloss/reboot (perhaps it's just a large cache of the "real" data on a real drive - or perhaps you'll snapshot a backup image to disk often enough that you don't mind losing a small time window of updates on crash/reboot/powerfal), then go for it.
For small peices of not-too-critical code, which probably constitutes a good chunk of all development done on the planet earth, source code revision control isn't terribly neccesary. Generally these little projects have only 1 developer, which helps a lot.
For me, personally - once a small project crosses some nebulous boundary between "hacking around on an idea, I'll probably rm -rf this at the end of the day" to "I'm gonna work on this, I think this code can do something good", I generally start using version control - just simple cvs with no tagging or branching (rcs or sccs would work just as well).
It serves as a backup system, and lets me be more bold with changes. I run in a tight loop of simultaneous architect/design/code/test, so once I've got revision control in place I can comfortably do global search and replace text substitutions on my source code, or wipe out whole files as part of a refactoring phase. I can be as aggressive as I want to be, and I can always go back into cvs to pick up what I was doing an hour ago when I realize I just took too many big steps in the wrong direction.
Therefore, I'm a fan. But - for many people doing little projects, just saving a zipfile/tarball of their source code tree as a daily snapshot in some directory somewhere provides them almost as much benefit, for considerably less effort than learning a version control tool.
But the grammars of these languages are virtually required by the complexity of expression they offer the user. The only way you're going to achieve a simple XML-based programming language that can be parsed by "just" a simple recursing XML parser (and I might remind you that XML parsing in itself isn't all that trivial, which is why we have support libraries just for that), is by designing a really horribly inexpressive language. If you bring back in the expressivity that coders want, you'll be adding superstructure to the XML which is beyond simple XML structure and beyond LALR as well.
Bottom line - switching an existing code language or something like it to an XML-based format is a matter of pointless, ugly, bloating search and replace. It doesn't accomplish anything in the machine sense or in the human sense, just wastes cycles.
Slashdot Mirror
It's really hard to scale these kinds of clusters beyond certain limits, once you start getting into all the practical details.
There's the basic facilities stuff: fitting enough power and cooling density into a single datacenter to cram that many nodes within a reasonable distance of each other for cabling purposes.
There's the network architecture. A single switched network between your nodes doesn't get you all that far. Depending on the characteristics of the expected workload and all that jazz, there are many different technologies and topologies to choose from.
Don't forget storage and data moving in general. The data has to reach the processors somehow, and 2000 nodes mounting an nfs share from some central box just isn't going to work at all...
Then there's node management: installing/imaging, booting, detecting failures, recovering with minimal human intervention (automatic re-imaging), monitoring it all, etc. You could skip this step and hire a truckload of junior sysadmins and have them running all over the place with CDs and keyboards and monitors, but that doesn't really scale to thousands of densely packed nodes does it?
As another reply states - if you don't find the right solution to all of these problems, you face scalability limits. With a given overall design, there's going to be a maximal node count, beyond which scaling is infeasible or futile. It really is hard stuff.
Luckily the opensource world is making headway on some of the software-side manageability issues. For an example check out rocks.npaci.edu.
Harnessing that much of the tidal/wave energy will doubtless change the environment in bad ways. Are these people so stupid as to actually believe that they're tapping from a free power source here that won't affect anything else?
Spend the money on fusion research, it's the most viable long term option we've got at the moment. And when we succeed at fusion, that in turn will sustain humans long enough to advance far enough to move to space-based solar or other better systems.
It would be fairly easy to reduce the whole EM inteference argument with a better design for housing, communications, and power for the EGG/RNG/REG.
1) Design a power system that isn't susceptible to anything from AC line noise and frequency/voltage drifting. There are many ways to go about this - most of the simplest ones involve a pair of rechargeable batteries and a switch - at any given time one is being charged by the filtered DC coming from a wall socket adapter, and the other is powering the device. Capacitors can keep the voltage ok during the milliseconds it takes to flip the switch. (And the switching events timetsamps should be noted just in case they cause any spike).
2) Shielding. Put the device inside a cage that allows no EM interference, a lead hull and/or multiple faraday cages of different hole sizes. Might want to put some antennaes at various wavelengths inside the shielded area which record EM levels of various types, so that those an be correlated to the output (We got an event! Oh wait, there was an EM spike inside the cage at the same time, nevermind).
3) Communications: Shielded cable. Smarter processor inside. Processor should do a hash/checksum of packets of RNG data and include this checksum on each packet sent out of the shielded device, and also should buffer the data locally and employ and error-correction and retransmission protocol. This solves the problems with random bits flipped outside the confines of the shielded RNG device. Opto-isolate the electrical communications path between the RNG and the machine --- or better yet, just use a fiber-optic link.
The fac tthat these guys don't appear to be taking any steps in the above directions shows their scientific weakness. I still don't completely discount their results, but I'd like to see more of the same under more rigorous isolation.
Per-processor licensing has always been a shady sham thing anyways. The industry really needs to get the hell away from it. Even before this multi-core monkey-wrench got thrown in, it never made sense. Why should I pay twice as much to run your code on a crappy old quad 200Mhz Pentium Pro as I do to run it on a dual Opteron? Why should I pay more to run on a dual P3-933Mhz than I do to run it on a single P4-3.2Ghz? Some vendors try to bandaid the situation by classifying architectures and machine types into tiered per-processor pricing, but these inequities still abound even then.
If they're really stuck on the asinine idea that I should pay more for their code if I run it on bigger hardware, they could at least rate all the possible platforms they support in terms of MIPS or GFLOPS or something and charge per-performance-unit licensing.
When at the checkout counter, say no to everything they ask you. No protection plan, no extended warranty, etc. They are always ripoffs.
Don't forget there's always a tradeoff between the costs paid to vendors and employment costs. Some companies choose to spend a lot more money on buying large fancy oversize overfeatured hardware and software with big support agreements and vendor consulting added into the purchase, which makes the employees' work much simpler and smaller. Some choose to nickle-and-dime everything on the vendor side, buying bare minimum generic stuff with minimal support (sometimes nonexistant other than warranty repairs) and then they pay more to hire a larger number of smarter employees to get it working and keep it working for them. Depending on your situation, your company, and your requirements, the optimal balance between these two extremes will be different in every situation. In the big picture sense, readjusting along this scale to somewhere that's most efficient for you can be a good overall direction to look for cost-savings in.
The "smarter" ones did better than the average ones in a no-pressure situation, but all involved did equally poorly when under pressure. A more accurate conclusory title might have been "Nobody performs well under pressure, even smart people".
In terms of the raw totals of important and useful software written in a language, and how widely society in general uses and relies on code written in a language, C has been the most widespread, useful, and productive language in the history of computer science. From telephone switches to operating systems to video encoders and a million other places. There are far worse things to look to for inspiration.
Quit being such a lopsided bigot.
NFS, PAM, XFN, etc that you list... the standard was set by Sun as an open standard, but the open source versions of them were reinvented on the outside, not donated by Sun.
Sun didn't invent Gnome, they adopted it as a commercial strategy. The primary gnome developers were not Sun employees, although I havent kept track if they have become so recently.
OpenOffice is definitely a huge chunk of GPL code, but they also didn't develop that. They purchased a dying company and opensourced the company's product. It was a cheap move aimed at poking holes in Microsoft's officeware dominance.
I know full well about Sun's positions on the matter. I've raised the merits of Open Source repeatedly to my Sun sales and technical representatives, who generally frown at me and hand me Sun company dogma about how they're going to crush linux into the ground, and that open source is just a phase.
You're counting contributions by sun employees semi-officially and/or on their own time. Sun as a corporate entity isn't as giving to the GPL as you have portrayed them.
This brings a whole new meaning to the term "Rice Rocket". He does realize the flaw in his analogy right? You don't buy a Ferrari because it's reliable, you buy a Ferrari because you can hit 200 in it. If you try to bolt junkyard parts on a Honda in an attempt to go 200 in it, it will be far less reliable than the Ferrari.
Yes, computer generated art is art. Just like any form of art, is art. There's nothing relovutionary or special going on here, and your computer itself is not an artist. Neither is the code you wrote. You are the artist, and the code your wrote is a self-made tool, and the output is art which should be accredited to yourself.
I was there, thank you very much. But this server-side push with Java is still silly IMHO. More effort should have been put into making it the most viable client-side language, which it never became. Why on earth would anyone run their server-side inside a VM? The server side is the platform you control, the one where you can choose a single platform and don't have to worry so much about portability...
I still blows my mind that Java has come as far as it has to date on the server side, and equally blows my mind that it didn't make better inroads as a platform for thin client GUIs.
"We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris."
-- LarryWall, ProgrammingPerl (1st edition), O'Reilly & Associates
In the second edition of the book (which sports not only LarryWall as author, but also Tom Christiansen and Randal L. Schwartz as co-authors), there is a glossary which has pithy definitions for each of these terms:
Laziness
The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer, Also hence, this book. See also impatience and hubris. (p.609)
Impatience
The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to. Hence, the second great virtue of a programmer. See also laziness and hubris. (p.608)
Hubris
Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer. See also laziness and impatience. (p.607)
Seems most of the world is happy running an OS that can be remotely crippled at will by the underhanded, and they're about to get DRM forced down their throats, which effectively allows corporate and government interests to legally cripple you. This isn't much different.
I don't love Java. All things considered, I don't see that their efforts at cross-platform compatibility are really a big win over things like the Standard C Library. In both cases, you have a language and a supposedly cross-platform standard set of library calls, and in both cases you end up having to code around the quirks of the platforms you run on. I think the right place for Java to have targetted, the place where it could have been the most useful, was as a client-side platform-indepedant environment, ala Applets in the web browser and whatnot. Unfortunately all the effort went into perfecting a server-side environment instead.
This is just HA load-balancing of your inbound web traffic. Clustering is what happens on the back end between the servers, which the articles doesn't cover at all, presumably because in the example case the servers are just serving static content over http, and all that's needed to "cluster" it is to copy your changes to both machines when you change the static data.
The hard part of clustering is getting real HA and/or Loadbalancing for non-trivial content. Imagine if the websrever behind Kimmy's DNS setup was hosting an SSL-based service, where users logged into sessions, and posted on a message board to each other.
Now you have to get SSL working right for multiple machines, and you have to get sessioning to work right between multiple machines (the user's session would jump between servers with Kimmy's DNS), and the database the message board is storing in would have to be consistent across both servers.
The easy solution to most of this is of course to put the session-state in the same database as the message board, and put the message board database on a seperate back-end machine that both webservers hit, thereby removing all state from the web cluster. But now you've introduced a new single point of failure at the database level - DB goes poof, your webservers dont matter much.
So there's no easy way out of this, you can't play shell games and try to make the single points of failure magically disappear. May as well leave the database on the web server nodes (assuming load/space aren't problems), and use some kind of clustered database solution...
One way or another, you'll have to do real clustering at some layer - which will inevitably involve heartbeats and quorums and all that jazz, the complicated stuff referred to in the first paragraph of Kimmy's page.
The quoted press release is from April of last year. Looks like someone's trying to get some hype for something.
How can that possibly be geekier than multiplatform Firefox?
You'll note I referenced LISP in my original post, I'm not unfamiliar with it. LISP does lack some high level expressiveness, but just like any turing complete language, you can of course invent such expressiveness in your code at the cost of some more characters typed.
I think we have failed to agree on what "expressiveness" means. I meant expressive in the sense that more information can be conveyed with a minimal code size. By my definition as I was using it, assembler is the least expressive practical language, and some hypothetical 4GL would be the most expressive. C is considerably better than assembler, and C++ and Java fall somewhere in the middle of C and that theoretical peak.
So by that I'm saying that while you can express anything in LISP that you could express in any other language, LISP is not as "expressive" by virtue of the fact that not as many idioms are embedded into the language design.
And it wouldn't be that hard to write a C-parsing library like our XML-parsing libraries. Nobody has done it because there isn't a great need. When people write tools that need to parse C, they tend to just roll their own. Might not be a bad project for someone to start up a reusable C-parsing library.
Just to drive home how silly this company is, realize that not only is their "Wireless Charging" really just inductive coupling, but that inductive coupling is basically what a Transformer does. You know Transformers, which have been ubiquitous since electricity came into widespread use. They're in every freaking wall dongle and virtually every electronic device's power supply. The difference between "Inductive Coupling Chargers" and transformers is that a transformer is housed in a single case, whereas the charger split the transformer out into two distinct coils in seperate package, which you place close to each other to transmit the inductive energy.
For that matter, my Sonicare toothbrush has been recharging via an inductive coupler for years now, so it's not like even this particular incarnation is new to the commercial world.
You could of course in theory build a PCI card ramdisk out of PC2700 memory (I remember a magazine had some rather simplistic plans way back when for building such a beast from old school DRAM chips on an ISA card). The problem is that the D in DRAM means Dynamic. When you lose power, you lose all the data. SRAM (Static) actually keeps it's state when you power it off, more like a hard drive does. SRAM is however considerably more expensive than DRAM. There are several vendors of commercial SRAM disks sporting IDE and SCSI interfaces these days, but the prices will scare you for any decent size.
However, if the "low latency storage" you need for your app can be wiped on powerloss/reboot (perhaps it's just a large cache of the "real" data on a real drive - or perhaps you'll snapshot a backup image to disk often enough that you don't mind losing a small time window of updates on crash/reboot/powerfal), then go for it.
For small peices of not-too-critical code, which probably constitutes a good chunk of all development done on the planet earth, source code revision control isn't terribly neccesary. Generally these little projects have only 1 developer, which helps a lot.
For me, personally - once a small project crosses some nebulous boundary between "hacking around on an idea, I'll probably rm -rf this at the end of the day" to "I'm gonna work on this, I think this code can do something good", I generally start using version control - just simple cvs with no tagging or branching (rcs or sccs would work just as well).
It serves as a backup system, and lets me be more bold with changes. I run in a tight loop of simultaneous architect/design/code/test, so once I've got revision control in place I can comfortably do global search and replace text substitutions on my source code, or wipe out whole files as part of a refactoring phase. I can be as aggressive as I want to be, and I can always go back into cvs to pick up what I was doing an hour ago when I realize I just took too many big steps in the wrong direction.
Therefore, I'm a fan. But - for many people doing little projects, just saving a zipfile/tarball of their source code tree as a daily snapshot in some directory somewhere provides them almost as much benefit, for considerably less effort than learning a version control tool.
I was imaging this big deathray pointing out of Sun's HQ towards Redmond.
But the grammars of these languages are virtually required by the complexity of expression they offer the user. The only way you're going to achieve a simple XML-based programming language that can be parsed by "just" a simple recursing XML parser (and I might remind you that XML parsing in itself isn't all that trivial, which is why we have support libraries just for that), is by designing a really horribly inexpressive language. If you bring back in the expressivity that coders want, you'll be adding superstructure to the XML which is beyond simple XML structure and beyond LALR as well.
Bottom line - switching an existing code language or something like it to an XML-based format is a matter of pointless, ugly, bloating search and replace. It doesn't accomplish anything in the machine sense or in the human sense, just wastes cycles.