Guess I'm not self respecting...
on
All The Rave
·
· Score: 1
All my MP3's are rips from personally owned CDs, or a few I downloaded from MP3.com legally. Of course, I'm also working with an Internet company that didn't spend thousands on ergo office chairs, uses an XP style design and development process and actually has had a product for a couple of years that makes revenue.
A "thick client" is a client that has a lot of processing done locally. In the case of our old model (before doing web interfaces) the client could do a lot of the logic for reports and screens locally. This is now considered bad design, but was the norm for 2 tier apps. The database was doing view transforms and was accessed via stored procedures. So, yes, pretty typical client/server. Our current model, being web based, doesn't provide for a lot of processing on the client side. Fortunately, our clients are large insurance companies with T1+ connectivity, so round trips are pretty painless. Our current model is "3 tier" in that we have web servers that render views, business logic servers that process the data and database servers that do the inital data retrieval and transforms. The browser isn't really a "tier" as it does almost no processing of it's own.
The web pretty much forces a "thin" client. We *could* put a lot of logic in Javascript, but it would probably break, and would be very browser dependent.
The problem with the old model was that if a user installed a different version of a tool we used in our product (say, Crystal Reports) then it would break our integration with that tool. Platform upgrades to the OS could also break the fragile DLL/COM linkages. With the web, we are mostly free of those concerns, as long as we stick to XHTML, level 1 DOM and a compatibility layer javascript library.
I pray I'm never your client. Turning DLL hell into a profit center seems "nice". I prefer my profit center be providing services, not milking the cow, thanks.
Discussion done... it's clear you have never written software that breaks because your os vendor has decreed that is shall break. The article is not about the fact there are still areas that you can eek out a living. Tiramisu is pretty arcane example, and spinright not working isn't a counter example. I already admitted that there are a lot of old windows 95 machines running old versions of applications, but look at Lotus sales and call that healthy? Wordperfect is just about given away, and about 50% of the law firms I work with now use Word 2000 or higher.
All that is irrelevant to the article's principle point: *why* write software where you have to eek out a living in arcane spaces where perhaps the giant foot of the vendor won't come down on you, when you can write applications in a space where you can evolve along with the market. Even our browser based product (which is used by some the largest insurance firms on the planet) has to work to keep up with bugs and progress (re: Spinrite), but IE's incompatibilities are nothing compared to what MS API changes did to my older thick client software.
I'm not opposed the the integration of Windows. I'm just agreeing with the article that it's hard to compete when you both have OS absorption of markets AND a company that can change the rules of the game at whim. I personally have been building web apps for some time, and appreciate the fact that we are affected by this only in the regards of new browser versions, and we can make our changes in one place.
Of course, that was what MS was fearing the browser would do: remove reliance on the OS. But that doesn't mean that I don't appreciate all the builtins... I haven't purchased a utility (except antivirus, and that looks like MS wants to cover that too) in many years, and most of my software comes from Microsoft. Which is the point: I would hate to be fighting for space on the desktop, and am glad that my product lives on the more "standards based" web. Of course, I think that bends MS nose a bit: my product doesn't care if you use Mozilla on Linux, Netscape on OSX or Opera on Windows.
I'm not saying you don't have to compete. However, in the MS word, you have to complete against an entity that "holds the keys to the kingdom". Surely in a "fair market" of competition, your host should not be able to simultaniously release a competitive product, either integrated or not, while having the ability to break your software. And yet that is what happens with utility software nearly every upgrade cycle... you don't have the information to change your software until *after* you gain a tarnish on your reputation for failure. "But wait, why use this broken piece of software when the feature is integrated!"
Reference the disk compression lawsuit during the DOS era, memory management bruhaha in the same, the DR DOS detection code in 16 bit windows, Symantec's lawsuit in the early 32 bit era and the AOL dialer (vs MS dialer) in early 32 bit. How does it being a corporation who steals code or breaks it deliberately better than a bunch of students who write from scratch?
But it isn't just the utility market that suffers: most companies didn't survive the transition from DOS to 16 bit windows very well because the APIs were not well documented to competitors. The recent suit in fact focused on APIs because of the long history of hiding them or breaking them. If the Office team needs a feature, its easy to get them in "early" (note many of the UI improvements to windows that somehow were "previewed" in office).
So how do you compete when your marketplace is simultaniously being absorbed and your target marketplace is shifting deliberately to prevent your existance. Sure, there are still markets for the utility space, but mostly because of inertia. Have you actually purchased a third party TCP/IP stack, defragmenter or scan utility? The only reason you *might* on the defragmenter is MS licensed a crippled version of diskkeeper. But even there when I upgraded Windows 2000 boxes to SP, the built in disk defrag kept working, but the *purchased extra* one broke. So why would I spend money to buy something that's going to break? I'm not.
Not a single one of your example utilities has been purchased by me for any of my clients or myself in the last 4 years. Nor have I purchased a non MS office suite, database or programming environment. I'm sure a vestigal market will remain... people still have Windows 95 of PC's, and there is always a tiny number of nonconformist OS users. But it won't be a healthy one. I'm just glad that I'm building web based solutions, not desktop ones, because I can fix my code once, in one place, when a new version of the browser (mozilla or IE based)/OS (MS, Apple or *nix like)/utility suite comes out, and look professional. I don't have that luxury when a service pack blindsides my desktop solution and turns it into a GP fault. I guess you could *beg* my clients to upgrade.
I believe the point of the article was to show that if you are building for a proprietary system, you are on "borrowed time". Basically, as soon as your sector becomes lucritive, it will be absorbed. The fact that users upgrade systems periodically means that the utility market becomes more and more marginalized. I am *not* saying this is a bad thing, but your original comment said "how many times" and I counted a few examples. Saying "you have to buy the upgrade" doesn't negate the fact that the next generation of computers won't need your tools.
Try: * Browser * Disk Defragmenting * Disk Diagnostics * Media Player * Remote Desktop Access * TCP Stack * Terminal Emulator * Accessibility Extensions * Zip file utility * I'm sure there are more, that's just from the top of my head...
Each of these *was* a viable community of third party software. Now they are just assumed into the OS. Some still have product out there, because of entrenchment. Microsoft says this is good for the consumer, and frankly I have to agree in most cases. But don't say "how many times", because the OS encloses more space on every revision.
If you have built good autoupdating tools (or are writing a web application) you can do quick and dirty with little impact on the user. If you *should* is is an endless argument (the XP crowd vs the Waterfall). My preference is for XP style, and so far it has allowed a company I'm part owner of to out maneuver a company that has (conservatively) 10,000 times the cash and resources that we have. They keep asking "how do you program so much so quickly". A handfull of *skilled* (don't try XP with newbies) designer/programmers will outperform a room full of lackies every time.
Leave you unskilled programmers to the task of "refining" code, and your talent to "building out" the code. The unskilled programmers slowly learn from the techniques they are working with, and join your design team over time. Thus quick and dirty evolves into "correct" code.
Shame this was posted as AC! Orginally patents were for an *implementation*. This meant that there were frequently ways to build a similar *acting* device, but it would bypass the patent because of the innovation in the mechansims. For example, a printing press has to apply ink to paper. The original flat plate method (if it had been patented) would have perhaps created the market for rotory plates more quickly, and thus the patent system would have *supported* innovation.
Now all you have to do is patent an *idea*, and all forms of that idea seem to now fall under its pervue. That makes no sense, because the "dodge the patent" approach is what caused patents to foster *some* creativity and innovation in the past. Sure, the alternate mechanism might not be as efficent, cheap or whatever. But maybe it was. Maybe it was better. Now patents can be applied over an *idea*, there is no room for such creativity to be applied.
"Selling over the interweb, eh? Well give me money."
If this kind of thing is allowed to continue, I suspect that the world's economies will spend the next two decades in a sort of "dark ages" where only the largest companies will be able to do business. Note that the targets of these insane patent suits are always the little guys, because there is no expectation that they can fight back. Once the big companies realize that they can get away with this kind of abuse of the patent system, you will likely see a flurry of activity where large companies simply outlaw competition via absurd licensing fees on things like "selling product (via common, but not yet patented channel)" or "maintaining a customer list (in a DATABASE)". I mean, feel the innovation!
Browser based games are probably the last thing Jack Thompson wants to try to explain as a source of violence. Hair trigger reflexes required? Nope. Adrenal gland stimulated by realistic graphics? Nope. Suspension of disbelief the size of Montana to accept that the 16 pixel by 32 pixel graphic of an orc *represents* an ork. Hmmmm, maybe something to work with there...
Hmmm. I don't think that the courts would put up with "we were distributing this code under the GPL, but we didn't read it first" defense. Ignorance is one thing courts rarely factor in, and in the case of corporate contracts, almost never. Deception is a different case, but I doubt anyone can say the GPL is deceptive - it states its intentions pretty clearly.
The fact that they had the GPL on the code makes the understanding of the ramifications a moot point. What SCO has said was they didn't know their code was in the product, and that *might* fly. The fact it was left in distribution for probably ~3 months after such discovery (assuming it took a month to fire the lawyers up and do the groundwork) is the interesting factor.
I was commenting more on the fact that this was about the *only* interesting thing the table had to say.
The argument contained within this table leans heavily on the "continued distribution of GPL code after realization of the consequences thereof". I believe they will try the "it took us time to remove it" argument, but that's pretty weak when you consider that the time elapsed isn't just the time from the public lawsuit, but that there must have been internal discussion as well...
Total agreement on this... small companies can rarely afford the specialist's rates unless the area of specialty is *guaranteed* to be required more than full time. In most cases, people are going to end up doing a lot of "non primary" tasks in a small compay.
I agree with other comments that Active Directory is overkill for small offices. Most of the companies I work with as a consultant *DO NOT* have a full time sysadmin. With 12-30 people working for the company, it's a hard cost to justify.
That said, I also can't condone the use of NT4 over the long term, due to the unstable platform it represents. The fact that machines on SP6 still needed their monthly reboot is proof of just how awful the fundementals were.
For this class of business, Microsoft is really pushing people twards exploring options like Samba. Here in Tucson, AZ I was consulting for a firm of 160 people, with 60 terminals (at lot of the employees were shop floor workers). This is considered a fairly *large* small business, and yet at that size, Active Directory makes little sense. Lots of extra complexity, not much I gained that I couldn't do before with perl scripts and run-as functionality.
They were recently pretty much forced into 2K for stability reasons, and the end of life concerns. If it wasn't for the fact that they have a Windows based DB running on one of the servers, I would have suggested a Samba based PDC. Except for that one application, everything else is file and print sharing. For smaller organizations *without* such lockdown issues, I have installed Samba PDCs, and with not so much as a hickup.
I'm in Tucson, AZ - we had great sport climbing routes on Mount Lemmon, but as most of it is burning, that isn't a popular choice right now. Another popular destination is "Cochise Stronghold" which is the area where the Apache Cheif Cochise holded up in the late 1800's and kicked serious butt. Really wild rock formations.
The games my wife and I have had success with in cooperative mode:
1. Cookies and Cream (mentioned many times already, and yes, you will have to help with ugly jumping puzzles). 2. Baldur's Gate: Dark Alliance - really simple RPG lite. 3. Gauntlet, although the later levels are too big and annoying. 4. Any 2 player puzzle game with adjustable difficulty. Bubble Bobble, Tetris, and Pokemon Puzzle League (yes, you can laugh, but it's a great puzzler)
On the PC we have played both Diablo I and II (with expansions) all the way though, and Baldur's Gate, although that gets to be a pause fest sometimes.
The best thing I ever did was discover the rock climbing gym. Now I got twice a week, have lost 25 pounds in the process and feel great! Normal exercise bored me to death, but there is something about hanging on the wall 20 feet up and puzzling out how to make the next move that is such a cool blend of mental and physical that I'm a total addict now. I have even started outdoor rock climbing on sports routes... very different, very cool.
Here here! Puerto Rico rocks, and whole designer game lines are easily available in via game stores (not toy stores) everywhere. My favorite games are where the "randomness" comes from the other players decisions, not cards or dice. Just looking at games with the name Dragon somewhere in it: Silent bidding games like Aladdins Dragons and Fist of the Dragons Stones are a blast. Dragon Delta likewise uses silent choice of move types, which creates a lot of tension.
That's not to say all American games suck: Robo Rally came from here.
After doing a bit of research on the linked sites, one can see that this falls under the "well meaning and very useful in nitches" category. If you are building software that *can't die* because it will be used in critical points like aircraft control systems or medical equipment, you can probably afford people smart enough to implement this.
The "language" itself looks like a cross between boolean algebra, set theory and relational algebras (which came from set theory). Using a truely functional language would make this much easier to implement (as you point out, procedural languages tend to allow you to wack the state at any time).
So we have a methodology that requires people to understand functional programming and some pretty abstract math concepts to boot. I guess you could have a really well payed designer with those attributes, but most business programmers would be lost forever.
That being said, another comment mentioned Gemplus, a JVM entirely proven by using the B method (which uses the Z language). This is used for smartcards, where "undesired functionality" would mean compromized financials. If it is possible to write a proven JVM, perhaps I fall in the "not bright enough" category to see how.
Ok, this may get me pounded, but I found this line amusing:
Z is a formal (i.e., mathematical) specification notation used by industry (especially in high-integraity systems) as part of the software (and hardware) development process
Slashdot Mirror
All my MP3's are rips from personally owned CDs, or a few I downloaded from MP3.com legally. Of course, I'm also working with an Internet company that didn't spend thousands on ergo office chairs, uses an XP style design and development process and actually has had a product for a couple of years that makes revenue.
Guess I'm square.
A "thick client" is a client that has a lot of processing done locally. In the case of our old model (before doing web interfaces) the client could do a lot of the logic for reports and screens locally. This is now considered bad design, but was the norm for 2 tier apps. The database was doing view transforms and was accessed via stored procedures. So, yes, pretty typical client/server. Our current model, being web based, doesn't provide for a lot of processing on the client side. Fortunately, our clients are large insurance companies with T1+ connectivity, so round trips are pretty painless. Our current model is "3 tier" in that we have web servers that render views, business logic servers that process the data and database servers that do the inital data retrieval and transforms. The browser isn't really a "tier" as it does almost no processing of it's own.
The web pretty much forces a "thin" client. We *could* put a lot of logic in Javascript, but it would probably break, and would be very browser dependent.
The problem with the old model was that if a user installed a different version of a tool we used in our product (say, Crystal Reports) then it would break our integration with that tool. Platform upgrades to the OS could also break the fragile DLL/COM linkages. With the web, we are mostly free of those concerns, as long as we stick to XHTML, level 1 DOM and a compatibility layer javascript library.
I pray I'm never your client. Turning DLL hell into a profit center seems "nice". I prefer my profit center be providing services, not milking the cow, thanks.
Discussion done... it's clear you have never written software that breaks because your os vendor has decreed that is shall break. The article is not about the fact there are still areas that you can eek out a living. Tiramisu is pretty arcane example, and spinright not working isn't a counter example. I already admitted that there are a lot of old windows 95 machines running old versions of applications, but look at Lotus sales and call that healthy? Wordperfect is just about given away, and about 50% of the law firms I work with now use Word 2000 or higher.
All that is irrelevant to the article's principle point: *why* write software where you have to eek out a living in arcane spaces where perhaps the giant foot of the vendor won't come down on you, when you can write applications in a space where you can evolve along with the market. Even our browser based product (which is used by some the largest insurance firms on the planet) has to work to keep up with bugs and progress (re: Spinrite), but IE's incompatibilities are nothing compared to what MS API changes did to my older thick client software.
I'm not opposed the the integration of Windows. I'm just agreeing with the article that it's hard to compete when you both have OS absorption of markets AND a company that can change the rules of the game at whim. I personally have been building web apps for some time, and appreciate the fact that we are affected by this only in the regards of new browser versions, and we can make our changes in one place.
Of course, that was what MS was fearing the browser would do: remove reliance on the OS. But that doesn't mean that I don't appreciate all the builtins... I haven't purchased a utility (except antivirus, and that looks like MS wants to cover that too) in many years, and most of my software comes from Microsoft. Which is the point: I would hate to be fighting for space on the desktop, and am glad that my product lives on the more "standards based" web. Of course, I think that bends MS nose a bit: my product doesn't care if you use Mozilla on Linux, Netscape on OSX or Opera on Windows.
I'm not saying you don't have to compete. However, in the MS word, you have to complete against an entity that "holds the keys to the kingdom". Surely in a "fair market" of competition, your host should not be able to simultaniously release a competitive product, either integrated or not, while having the ability to break your software. And yet that is what happens with utility software nearly every upgrade cycle... you don't have the information to change your software until *after* you gain a tarnish on your reputation for failure. "But wait, why use this broken piece of software when the feature is integrated!"
Reference the disk compression lawsuit during the DOS era, memory management bruhaha in the same, the DR DOS detection code in 16 bit windows, Symantec's lawsuit in the early 32 bit era and the AOL dialer (vs MS dialer) in early 32 bit. How does it being a corporation who steals code or breaks it deliberately better than a bunch of students who write from scratch?
But it isn't just the utility market that suffers: most companies didn't survive the transition from DOS to 16 bit windows very well because the APIs were not well documented to competitors. The recent suit in fact focused on APIs because of the long history of hiding them or breaking them. If the Office team needs a feature, its easy to get them in "early" (note many of the UI improvements to windows that somehow were "previewed" in office).
So how do you compete when your marketplace is simultaniously being absorbed and your target marketplace is shifting deliberately to prevent your existance. Sure, there are still markets for the utility space, but mostly because of inertia. Have you actually purchased a third party TCP/IP stack, defragmenter or scan utility? The only reason you *might* on the defragmenter is MS licensed a crippled version of diskkeeper. But even there when I upgraded Windows 2000 boxes to SP, the built in disk defrag kept working, but the *purchased extra* one broke. So why would I spend money to buy something that's going to break? I'm not.
Not a single one of your example utilities has been purchased by me for any of my clients or myself in the last 4 years. Nor have I purchased a non MS office suite, database or programming environment. I'm sure a vestigal market will remain... people still have Windows 95 of PC's, and there is always a tiny number of nonconformist OS users. But it won't be a healthy one. I'm just glad that I'm building web based solutions, not desktop ones, because I can fix my code once, in one place, when a new version of the browser (mozilla or IE based)/OS (MS, Apple or *nix like)/utility suite comes out, and look professional. I don't have that luxury when a service pack blindsides my desktop solution and turns it into a GP fault. I guess you could *beg* my clients to upgrade.
I believe the point of the article was to show that if you are building for a proprietary system, you are on "borrowed time". Basically, as soon as your sector becomes lucritive, it will be absorbed. The fact that users upgrade systems periodically means that the utility market becomes more and more marginalized. I am *not* saying this is a bad thing, but your original comment said "how many times" and I counted a few examples. Saying "you have to buy the upgrade" doesn't negate the fact that the next generation of computers won't need your tools.
Try:
* Browser
* Disk Defragmenting
* Disk Diagnostics
* Media Player
* Remote Desktop Access
* TCP Stack
* Terminal Emulator
* Accessibility Extensions
* Zip file utility
* I'm sure there are more, that's just from the top of my head...
Each of these *was* a viable community of third party software. Now they are just assumed into the OS. Some still have product out there, because of entrenchment. Microsoft says this is good for the consumer, and frankly I have to agree in most cases. But don't say "how many times", because the OS encloses more space on every revision.
Yep, that was all I wanted to say. I had been considering sending the link, but now I realize how wrong that would have been....
If you have built good autoupdating tools (or are writing a web application) you can do quick and dirty with little impact on the user. If you *should* is is an endless argument (the XP crowd vs the Waterfall). My preference is for XP style, and so far it has allowed a company I'm part owner of to out maneuver a company that has (conservatively) 10,000 times the cash and resources that we have. They keep asking "how do you program so much so quickly". A handfull of *skilled* (don't try XP with newbies) designer/programmers will outperform a room full of lackies every time.
Leave you unskilled programmers to the task of "refining" code, and your talent to "building out" the code. The unskilled programmers slowly learn from the techniques they are working with, and join your design team over time. Thus quick and dirty evolves into "correct" code.
Shame this was posted as AC! Orginally patents were for an *implementation*. This meant that there were frequently ways to build a similar *acting* device, but it would bypass the patent because of the innovation in the mechansims. For example, a printing press has to apply ink to paper. The original flat plate method (if it had been patented) would have perhaps created the market for rotory plates more quickly, and thus the patent system would have *supported* innovation.
Now all you have to do is patent an *idea*, and all forms of that idea seem to now fall under its pervue. That makes no sense, because the "dodge the patent" approach is what caused patents to foster *some* creativity and innovation in the past. Sure, the alternate mechanism might not be as efficent, cheap or whatever. But maybe it was. Maybe it was better. Now patents can be applied over an *idea*, there is no room for such creativity to be applied.
"Selling over the interweb, eh? Well give me money."
If this kind of thing is allowed to continue, I suspect that the world's economies will spend the next two decades in a sort of "dark ages" where only the largest companies will be able to do business. Note that the targets of these insane patent suits are always the little guys, because there is no expectation that they can fight back. Once the big companies realize that they can get away with this kind of abuse of the patent system, you will likely see a flurry of activity where large companies simply outlaw competition via absurd licensing fees on things like "selling product (via common, but not yet patented channel)" or "maintaining a customer list (in a DATABASE)". I mean, feel the innovation!
Makes me ill.
Browser based games are probably the last thing Jack Thompson wants to try to explain as a source of violence. Hair trigger reflexes required? Nope. Adrenal gland stimulated by realistic graphics? Nope. Suspension of disbelief the size of Montana to accept that the 16 pixel by 32 pixel graphic of an orc *represents* an ork. Hmmmm, maybe something to work with there...
Hmmm. I don't think that the courts would put up with "we were distributing this code under the GPL, but we didn't read it first" defense. Ignorance is one thing courts rarely factor in, and in the case of corporate contracts, almost never. Deception is a different case, but I doubt anyone can say the GPL is deceptive - it states its intentions pretty clearly.
The fact that they had the GPL on the code makes the understanding of the ramifications a moot point. What SCO has said was they didn't know their code was in the product, and that *might* fly. The fact it was left in distribution for probably ~3 months after such discovery (assuming it took a month to fire the lawyers up and do the groundwork) is the interesting factor.
I was commenting more on the fact that this was about the *only* interesting thing the table had to say.
The argument contained within this table leans heavily on the "continued distribution of GPL code after realization of the consequences thereof". I believe they will try the "it took us time to remove it" argument, but that's pretty weak when you consider that the time elapsed isn't just the time from the public lawsuit, but that there must have been internal discussion as well...
Total agreement on this... small companies can rarely afford the specialist's rates unless the area of specialty is *guaranteed* to be required more than full time. In most cases, people are going to end up doing a lot of "non primary" tasks in a small compay.
Aw man, and I was looking forward to a MMO siege of Jerusalem. Oh wait, I guess we get that in reality anyway. Damn PKs.
The comment about doing evil things preventing you from playing Jesus makes me wonder: how many Jesuses were they planning to allow?
"I'm a 10th level Jesus, just got my first disciple! How do I get him to go aggro again?."
I agree with other comments that Active Directory is overkill for small offices. Most of the companies I work with as a consultant *DO NOT* have a full time sysadmin. With 12-30 people working for the company, it's a hard cost to justify.
That said, I also can't condone the use of NT4 over the long term, due to the unstable platform it represents. The fact that machines on SP6 still needed their monthly reboot is proof of just how awful the fundementals were.
For this class of business, Microsoft is really pushing people twards exploring options like Samba. Here in Tucson, AZ I was consulting for a firm of 160 people, with 60 terminals (at lot of the employees were shop floor workers). This is considered a fairly *large* small business, and yet at that size, Active Directory makes little sense. Lots of extra complexity, not much I gained that I couldn't do before with perl scripts and run-as functionality.
They were recently pretty much forced into 2K for stability reasons, and the end of life concerns. If it wasn't for the fact that they have a Windows based DB running on one of the servers, I would have suggested a Samba based PDC. Except for that one application, everything else is file and print sharing. For smaller organizations *without* such lockdown issues, I have installed Samba PDCs, and with not so much as a hickup.
I'm in Tucson, AZ - we had great sport climbing routes on Mount Lemmon, but as most of it is burning, that isn't a popular choice right now. Another popular destination is "Cochise Stronghold" which is the area where the Apache Cheif Cochise holded up in the late 1800's and kicked serious butt. Really wild rock formations.
The games my wife and I have had success with in cooperative mode:
1. Cookies and Cream (mentioned many times already, and yes, you will have to help with ugly jumping puzzles).
2. Baldur's Gate: Dark Alliance - really simple RPG lite.
3. Gauntlet, although the later levels are too big and annoying.
4. Any 2 player puzzle game with adjustable difficulty. Bubble Bobble, Tetris, and Pokemon Puzzle League (yes, you can laugh, but it's a great puzzler)
On the PC we have played both Diablo I and II (with expansions) all the way though, and Baldur's Gate, although that gets to be a pause fest sometimes.
The best thing I ever did was discover the rock climbing gym. Now I got twice a week, have lost 25 pounds in the process and feel great! Normal exercise bored me to death, but there is something about hanging on the wall 20 feet up and puzzling out how to make the next move that is such a cool blend of mental and physical that I'm a total addict now. I have even started outdoor rock climbing on sports routes... very different, very cool.
Here here! Puerto Rico rocks, and whole designer game lines are easily available in via game stores (not toy stores) everywhere. My favorite games are where the "randomness" comes from the other players decisions, not cards or dice. Just looking at games with the name Dragon somewhere in it: Silent bidding games like Aladdins Dragons and Fist of the Dragons Stones are a blast. Dragon Delta likewise uses silent choice of move types, which creates a lot of tension.
That's not to say all American games suck: Robo Rally came from here.
After doing a bit of research on the linked sites, one can see that this falls under the "well meaning and very useful in nitches" category. If you are building software that *can't die* because it will be used in critical points like aircraft control systems or medical equipment, you can probably afford people smart enough to implement this.
The "language" itself looks like a cross between boolean algebra, set theory and relational algebras (which came from set theory). Using a truely functional language would make this much easier to implement (as you point out, procedural languages tend to allow you to wack the state at any time).
So we have a methodology that requires people to understand functional programming and some pretty abstract math concepts to boot. I guess you could have a really well payed designer with those attributes, but most business programmers would be lost forever.
That being said, another comment mentioned Gemplus, a JVM entirely proven by using the B method (which uses the Z language). This is used for smartcards, where "undesired functionality" would mean compromized financials. If it is possible to write a proven JVM, perhaps I fall in the "not bright enough" category to see how.
Perhaps they could include spell checking?