The article contains the link to the channel9 presentation. What you will learn is that:
Microsoft is not trying to turn developers into designers and/or vice versa. They are trying to bridge the gap between designer and developer. This means that a developer can mock up an application just to see that the code does what it's supposed to, and a designer can drop in a design on top of that, and "it will just work". This is quite similar to how web-applications are developed if the template system is good enough; the developer does his thing, the designer does his thing.
The problem with desktop applications today is that a designer will probably submit a design to the developers, who have to slice the UI and write some kind of skinning library to properly display it. Making changes to this creates the need to redo all this work. And sometimes the skinning library might not do what the designer envision in the first place.
People are whining about how painful it is using apps that "designers" have created. Sparkle makes it easier to create designer-designed applications, but because the turnaround from designer to working app is shorter, it's a lot easier to see what actually works. So it should be easier to make designer-apps better; probably a lot better than developer-designed apps.
If you think my example seems to throws away type information, you don't understand how type inference works.
Here are two simple examples, both iterating collections of strings to output the length of the string, one using object, the other using var (type inference):
var collection = new [] {"This", "is", "a", "demonstration"};
foreach (object o in collection) {
if (o is string) {// Check to see if o is string
Console.WriteLine("Lenght of string: {0}", ((string)o).Length));
} }
with inference:
var collection = new [] {"This", "is", "a", "demonstration"};
foreach (var s in collection) {
Console.WriteLine("Length of string: {0}", s.Length);// It is known that s is of type string }
So while it might seem to throw away the information about the underlying type, it doesn't.
The first line in both examples uses the new feature called implicitly typed arrays (26.6 in the specification). From that point on, it's known that collection is an array of strings.
The "foreach (var s in collection)" then infers that the type of s is indeed string. This gives you an obvious benefit of "foreach (object o in collection)" as the example shows: you'll have to check that o is the expected type and add the extra typing for the cast. Both runtime overhead and inconvenience.
The problem is that your code throws away the type information. If you want to do anything with the item, you have to downcast it. This is incurs runtime overhead and has the possibility of failing at runtime. Errors in handling the "var"-reference will be handled at compile-time.
The point is that var is a convenience. Writing:
var s = "Hi!";
is equivalent with writing:
string s = "Hi!";
The exact same code will be generated. The benefit of using var is that it's usually less to write (especially when working with collection types like Dictionary<int, string>, for example).
What I was trying to illustrate with the foreach is that code written works for more cases without sacrificing any kind of strong typing. Using "var" never results in a hidden "object" unless you write
var o = new object();
The scaremongers that indicate that this will somehow sacrifice either runtime-security or make it harder to track down bugs are just prematurely worried. I actually think that the opposite will be the case, thanks to code that's easier to read. So I guess you could say I'm prematurely sighing with relief.;)
What I was trying to say with the foreach-example is simply:
foreach (var item in collection) {//... }
will work regardless of the T in IEnumerable. It is less code to maintain, and it works exactly like continuously substituting the "var" for the T. This makes the written code more generic. It works with more types of data without sacrificing type safety. You can do operations on "item" without doing a downcast and errors will be found at compiletime, unlike working with object.
Don't know the answers to all your questions, but I can fill in some of the blanks. Null-fields are supported through nullable types. It basically allows you to make versions of value-types that can also be null:
int? i = null;// int which can also be "null"
What I've seen so far has been on the query-side of things, but there is often mention of "setting" data. From what I heard in one of the videos, this will actually replace ADO.NET in future versions, so you will obviously need the ability to insert data into the database. Chances are that it will be outside of "LINQ", tho, as the Q is for Query.
SQL-server 2005 can use C# for stored procedures. I know Vista will ship with WinFX, which is basically a bunch of.NET accesible-stuff.
Anything that can be enumerated can be queried, so regarding WMI, my guess is that it is fairly simple to apply. The PDC-keynote uses an enmeration of processes on the system as a starting point. If the data is non-linear, it is a fairly simple thing to implement the interface LINQ uses to query the data, so you can make sure the semantics are correct.
That makes files in a directory incredibly simple to work with using LINQ, actually a lot simpler than manually foreach'ing. If you look at the PDC keynote video, you'll get info that is immediately applicable to the file system too.
Regarding volatile data, I'm not sure. We've all seen a foreach-loop throw when the collection being iterated is modified, but what the future holds I do not know. My guess is that it will not be up to LINQ whether or not it works; querying and iterating a database datasource doesn't care if data is modified, some local datacollections do. I guess the simplest and best would be just to let it be up to the underlying source and callee to handle it.
From what I understand, it's the same thing. Some examples on the LINQ samples query the expression tree. It basically means that for SQL Server which supports C#/.NET in the server, you can transport the expression tree from the client to the server to minimize the transported resultset. It can obviously also be used to build the SQL on the client side for databases that doesn't support.NET on the server side by querying the expression tree and making SQL that reflects the contents of the expression.
It would be excellent to have real macros too, but I haven't heard any mention of it yet.:(
I'm going to go out on a limb here and state my personal opinion: Java, as a mainstream platform for developing desktop applications has failed.
The enterprise isn't everything, and while Java 5 is excellent at creating enterprise applications, it just cannot compete with C# on.NET or Mono for desktop applications.
Feel free to point at any number of successful Java desktop applications (Eclipse, X-Develop, etc), but they all demonstrate the same thing: Java was never created to play ball with the other kids (I will not speculate whether this is accidental or intentional). This is especially true for Windows, which is the largest target platform for desktop applications. Take a look at how you install Eclipse on Windows, for example. Does it even slightly resemble the rest of the desktop experience?
As a desktop user, I constantly "notice" Java applications, whether during installation or when it's running, because of odd looking UIs, missing runtime environments (which are often painful to get a hold of. Even WinFX-applications have a fairly nice download frontend.). I don't want to "notice" the applications, I just want to run them.
Regarding the enterprise, I think Java is an excellent alternative, just keep it away from the users. I think that currently.NET might have an advantage in developer productivity, but Java wins hands down because of the richness of runtime environments supported. And Java is great, as long as you maintain a nice bufferzone between it and your customers (be it a web-presentation layer or a web-service, etc).
It will be fun to see what happens with the enterprise, but I feel that someone needs to take a big step back if they are to stop C#/.NET/Mono from taking the desktop. Saying "I'm just sticking with C, and so should you" is only going to work until the gap becomes large enough. While I personally find the managed environments superior today, noone can argue the speed at which things are progressing. The managed environments,.NET and Mono are going at light speed while C is at a virtual stand-still.
Writing unmanaged C++ for Windows applications for Vista and beyond is not going to be a good idea; it's going to take a long time compared to the alternatives (C++/CLI, C#, VB.NET), and the result is not going to be better (look at the Avalon-applications from the PDC keynote, which are mainly XAML, and Sparkle which is completely managed; they are the coolest UI-experiences I've ever seen).
I know what you're saying, but "the code that actually manipulates the items' methods and properties" will of course fail at compiletime if it is not valid. Noone is advocating this as a fantastic new approach to systems development; in the context of just writing code outside lambda expressions it's nothing but a convenience. But to me, after having watched a number of webcasts, it seems very convenient indeed. It is the comfort of writing python with the strength of C#, and I cannot wait to start using it myself.
Well, I have actually downloaded the stuff, so I am already using it.;)
For anyone interested in development on Windows, or the possible future direction of Mono, I recommend checking out the PDC Keynote for day 1. The duration is about 3:20, and you'll see demonstrations of the 5219-build of Vista, a lot of Avalon apps, four great architects at Microsoft doing live coding (showcasing LINQ, Indigo (WCF), Avalon (WPF) and Atlas, among other things) and a lot of interesting information about where things are heading.
Migration away from Windows might be a problem, but you can't escape the fact that on Windows, currently and in the future, C# and other.NET languages are The Big Gun. It's too expensive not to use it, because if your competition does, they will be running around you in circles, blowing holes in you. There simply is no product that delivers the same kind of raw productivity.
And the way I see it, the same is about to become true for Mono on Linux, even though they might only currently share a subset which is compatible. C# on Linux with managed bindings (Gtk#, for example) is extremely potent (see Beagle, Diva, F-Spot, etc.).
As the compatible subset becomes larger, there will obviously be an added benefit. The work being done in both camps (MS for innovation and Mono for re-implementation) is, IMHO, very impressive.
It also allows you to write pieces of code that are more generic. The LINQ samples have a lot of examples of this.
For example:
foreach (string s in collection) {
Console.WriteLine(s); }
means you have to change the type everytime you change the type in the collection.
foreach (var item in collection) {
Console.WriteLine(item); }
means that you can use it with any time that implements ToString, which is pretty much any type.
There are numerous other benefits from the type inference, and they become more apparent with lambda expressions, where you can write expressions like "x => x % 2 == 0" instead of writing the equivalent bool-returning delegate with a typed parameter.
Most of the new features of C# 3.0 are quite impressive and more importantly very useful.
That says nothing of her avalibility for dating. However, there's nobody who reads that scenario who doesn't get what Dave actually meant to communicate: That Anna is married, with children.
Which doesn't neccessarily mean "stay away". It could mean "go for it; some like the mother, some like the daughter, and some like both at the same time". Giggity.
There's no need to be a machine to consistently misinterpret.
most of the webcomics i've read aren't remotely funny, interesting or worth the webspace
Everyone should read Leisure Town ( http://www.leisuretown.com/ ). I am saying this because I totally love that comic. It's one of those things that manages to be amazingly stupid and mindboggling intelligent at the same time. It's fantasticly cheezy and infinitely stylish. It tackles both serious and lightweight issues. I does contain both good and great artwork. For an example of the latter, read "The Dog Mess" (Wasn't this called "The Dog Messiah" previously? Is my mind playing tricks on me?)
The story "What do people do all day" contains a joke so potent that I've pretty much been telling it two times a month since I first read it. It single handedly got me beaten up in the bathroom of the bar "99 bottles" in Santa Cruz. Or perhaps it had a little help from some of those 99 bottles, but I don't think I could have done it without the help from the joke.
If I'm not mistaken, the creator of Leisure Town is also the original author of "the Dilbert Hole", which I found amazingly funny. The strips can be found in the fantastic "A Comedy Crisis" on the Leisure Town site, although the script is played out by bunnies instead of Dilberts.
Leisure Town caters to all audiences, both wankers and techheads. You owe it to yourself to check it out, because chances are you are in fact both.
And while I'm at it, fanboying and meat puppeting, I need to shamelessly plug my own creation, the GladHeads. You can find it here: http://www.pacheads.com/
Not sure about the license, but I suppose it is somewhat restrictive. The point with having source code to a game like Allegiance isn't really to benefit from great technology in other games, but allow you to keep playing a new versions of a great game for free.
Regarding registration on related sites, I think you might have some trouble using anything that is remotely "throwaway"; at one point you actually had to be able to prove you were an american citizen to be able to register, using Paypal attached to a US account, IIRC. The people who are still playing seem quite happy about the current state of affairs, and people registering from bogus accounts could really kill the experience in a game which relies so much on team play.
Even Microsoft does it! The superfansastic MMO-tactical space shooter Allegiance, developed by Microsoft Research, is released with source. It seems to still have a large following, and I've been meaning to pick it personally. It gives me sort of the same feeling I got from reading about the "Battle Room" in Ender's Game.
Beware, it's a very complex game and it will take you some time to learn if you should decide to start playing. And considering that the current crop of players probably has 3+ years of experience, I think you'll find the competition a little better than your average AI.;)
All in all, it's my favorite PC game of all time, next to Shiny's excellent Sacrifice.
"Io is small prototype-based programming language. The ideas in Io are mostly inspired by Smalltalk (all values are objects), Self, NewtonScript and Act1 (prototype-based differential inheritance, actors and futures for concurrency), LISP (code is a runtime inspectable/modifiable tree) and Lua (small, embeddable)."
This cannot be stressed enough: throwing more bodies into the problem only makes the project last longer.
I once had the opportunity to work for a boss who had the sense to remove people from lagging projects instead of throwing more people at it. Not necessarily the "bad coders", but the observation was that there is speed in smaller numbers. Especially true for those projects that just seem to be stuck at "90% finished" no matter how much time you sink into them.
I use IM for people I know IRL. I cannot remember the last time I emailed someone I hang out with, seldomly or regularly. If they're not online, I use SMS. Email is either used to get to know new people or for business.
But when you move to a graphical interface, so huge is the change in interface mechanics that the idea of the end-user setting up a chain of programs to run from one mouse click should be alien.
I've been playing with this idea in an application. It's sort of similar to the automator in Tiger, I've been told, except my system allows many-to-many-connections:
I currently work with the HP NonStop on the server side doing financial transaction processing.
While some of your points are indeed valid, your post loses some value because it's incomplete. True, Guardian, the underlying operating system, has "odd" limitations, like eight-character filenames, etc, but most applications we write these days uses OSS, which is a POSIX-layer on top of Guardian, allowing for "normal" UNIX-style filenames. True enough, there's always something that's different enough to make straight ports of UNIX software difficult, but the work involved is usually minimal.
The key strength (IMHO) of the system, is the "pathway system", which is a transaction based, load balancing message passing system which allows you to scale an application close to infinately, across physical machines and sites. It's simple to monitor, and it allows you to see which server processes need more instances easily. It's also very easy to setup more server instances, and your application code doesn't necessarily need to take extra steps to be instantaneously scalable. It also ties into the SQL-based databases which run on the system, so errors can be effectively backed out of.
Regarding disaster-recovery, I would hardly call HP NonStop "flawed". We have a separate physical site in case of fires, bombing, etc, and although there's no "automatical" failover setup in our facilities, failover from one physical site to another is an important piece of the NonStop design, and we rely on it. It's also very convenient to have another site to run an application when doing major upgrades, etc.
Next generation NonStop-machines will also be Itanium based, which, IIRC, will allow application programmers to use Intel C/C++ which is great at optimizing and very good at conforming to standards. That being said, the current line of development tools (ETK) allow you to write C/C++ with embedded SQL on the PC, hosted in Visual Studio, cross compiling with built in deployment-features using FTP. I think it's a fairly nice environment to work with considering the age of the hardware this is running on.
If you're in the market for a platform to do massive transaction based processing, you'll do yourself a favor by considering HP NonStop.
Slashdot Mirror
Obviously.
No, the benefit is also that the code you wrote is generic, and you won't have to change it when you change the collection type.
Sparkle has been featured on slashdot before:
0 9/16/0016214&from=rss
http://developers.slashdot.org/article.pl?sid=05/
The article contains the link to the channel9 presentation. What you will learn is that:
Microsoft is not trying to turn developers into designers and/or vice versa. They are trying to bridge the gap between designer and developer. This means that a developer can mock up an application just to see that the code does what it's supposed to, and a designer can drop in a design on top of that, and "it will just work". This is quite similar to how web-applications are developed if the template system is good enough; the developer does his thing, the designer does his thing.
The problem with desktop applications today is that a designer will probably submit a design to the developers, who have to slice the UI and write some kind of skinning library to properly display it. Making changes to this creates the need to redo all this work. And sometimes the skinning library might not do what the designer envision in the first place.
People are whining about how painful it is using apps that "designers" have created. Sparkle makes it easier to create designer-designed applications, but because the turnaround from designer to working app is shorter, it's a lot easier to see what actually works. So it should be easier to make designer-apps better; probably a lot better than developer-designed apps.
Look at the video, it's good stuff.
Here are two simple examples, both iterating collections of strings to output the length of the string, one using object, the other using var (type inference):with inference:So while it might seem to throw away the information about the underlying type, it doesn't.
The first line in both examples uses the new feature called implicitly typed arrays (26.6 in the specification). From that point on, it's known that collection is an array of strings.
The "foreach (var s in collection)" then infers that the type of s is indeed string. This gives you an obvious benefit of "foreach (object o in collection)" as the example shows: you'll have to check that o is the expected type and add the extra typing for the cast. Both runtime overhead and inconvenience.
The point is that var is a convenience. Writing:is equivalent with writing:The exact same code will be generated. The benefit of using var is that it's usually less to write (especially when working with collection types like Dictionary<int, string>, for example).
What I was trying to illustrate with the foreach is that code written works for more cases without sacrificing any kind of strong typing. Using "var" never results in a hidden "object" unless you writeThe scaremongers that indicate that this will somehow sacrifice either runtime-security or make it harder to track down bugs are just prematurely worried. I actually think that the opposite will be the case, thanks to code that's easier to read. So I guess you could say I'm prematurely sighing with relief.
What I was trying to say with the foreach-example is simply:will work regardless of the T in IEnumerable. It is less code to maintain, and it works exactly like continuously substituting the "var" for the T. This makes the written code more generic. It works with more types of data without sacrificing type safety. You can do operations on "item" without doing a downcast and errors will be found at compiletime, unlike working with object.
SQL-server 2005 can use C# for stored procedures. I know Vista will ship with WinFX, which is basically a bunch of
Anything that can be enumerated can be queried, so regarding WMI, my guess is that it is fairly simple to apply. The PDC-keynote uses an enmeration of processes on the system as a starting point. If the data is non-linear, it is a fairly simple thing to implement the interface LINQ uses to query the data, so you can make sure the semantics are correct.
That makes files in a directory incredibly simple to work with using LINQ, actually a lot simpler than manually foreach'ing. If you look at the PDC keynote video, you'll get info that is immediately applicable to the file system too.
Regarding volatile data, I'm not sure. We've all seen a foreach-loop throw when the collection being iterated is modified, but what the future holds I do not know. My guess is that it will not be up to LINQ whether or not it works; querying and iterating a database datasource doesn't care if data is modified, some local datacollections do. I guess the simplest and best would be just to let it be up to the underlying source and callee to handle it.
From what I understand, it's the same thing. Some examples on the LINQ samples query the expression tree. It basically means that for SQL Server which supports C#/.NET in the server, you can transport the expression tree from the client to the server to minimize the transported resultset. It can obviously also be used to build the SQL on the client side for databases that doesn't support .NET on the server side by querying the expression tree and making SQL that reflects the contents of the expression.
:(
It would be excellent to have real macros too, but I haven't heard any mention of it yet.
It allows you to write:The usefulness of this isn't immediately apparent, before you look at query projections:The example is stolen from the LINQ examples at http://msdn.microsoft.com/vcsharp/future/linqsamp
These just isn't a sensible way (that I can think of) to reference the anonymous type with the same degree of type safety.
I'm going to go out on a limb here and state my personal opinion: Java, as a mainstream platform for developing desktop applications has failed.
.NET or Mono for desktop applications.
.NET might have an advantage in developer productivity, but Java wins hands down because of the richness of runtime environments supported. And Java is great, as long as you maintain a nice bufferzone between it and your customers (be it a web-presentation layer or a web-service, etc).
.NET and Mono are going at light speed while C is at a virtual stand-still.
The enterprise isn't everything, and while Java 5 is excellent at creating enterprise applications, it just cannot compete with C# on
Feel free to point at any number of successful Java desktop applications (Eclipse, X-Develop, etc), but they all demonstrate the same thing: Java was never created to play ball with the other kids (I will not speculate whether this is accidental or intentional). This is especially true for Windows, which is the largest target platform for desktop applications. Take a look at how you install Eclipse on Windows, for example. Does it even slightly resemble the rest of the desktop experience?
As a desktop user, I constantly "notice" Java applications, whether during installation or when it's running, because of odd looking UIs, missing runtime environments (which are often painful to get a hold of. Even WinFX-applications have a fairly nice download frontend.). I don't want to "notice" the applications, I just want to run them.
Regarding the enterprise, I think Java is an excellent alternative, just keep it away from the users. I think that currently
It will be fun to see what happens with the enterprise, but I feel that someone needs to take a big step back if they are to stop C#/.NET/Mono from taking the desktop. Saying "I'm just sticking with C, and so should you" is only going to work until the gap becomes large enough. While I personally find the managed environments superior today, noone can argue the speed at which things are progressing. The managed environments,
Writing unmanaged C++ for Windows applications for Vista and beyond is not going to be a good idea; it's going to take a long time compared to the alternatives (C++/CLI, C#, VB.NET), and the result is not going to be better (look at the Avalon-applications from the PDC keynote, which are mainly XAML, and Sparkle which is completely managed; they are the coolest UI-experiences I've ever seen).
Yes, the code throws away type information, while my example does not. Type inference is convenience. You type less with the same functionality.
Hi!
;)
I know what you're saying, but "the code that actually manipulates the items' methods and properties" will of course fail at compiletime if it is not valid. Noone is advocating this as a fantastic new approach to systems development; in the context of just writing code outside lambda expressions it's nothing but a convenience. But to me, after having watched a number of webcasts, it seems very convenient indeed. It is the comfort of writing python with the strength of C#, and I cannot wait to start using it myself.
Well, I have actually downloaded the stuff, so I am already using it.
For anyone interested in development on Windows, or the possible future direction of Mono, I recommend checking out the PDC Keynote for day 1. The duration is about 3:20, and you'll see demonstrations of the 5219-build of Vista, a lot of Avalon apps, four great architects at Microsoft doing live coding (showcasing LINQ, Indigo (WCF), Avalon (WPF) and Atlas, among other things) and a lot of interesting information about where things are heading.
t es.mspx (Click on the "On-Demand Webcast"-link. High up on the page.)
A lot of it is market-speak and sales, but it is a developer conference. The link can be found here: http://www.microsoft.com/events/executives/billga
Migration away from Windows might be a problem, but you can't escape the fact that on Windows, currently and in the future, C# and other .NET languages are The Big Gun. It's too expensive not to use it, because if your competition does, they will be running around you in circles, blowing holes in you. There simply is no product that delivers the same kind of raw productivity.
And the way I see it, the same is about to become true for Mono on Linux, even though they might only currently share a subset which is compatible. C# on Linux with managed bindings (Gtk#, for example) is extremely potent (see Beagle, Diva, F-Spot, etc.).
As the compatible subset becomes larger, there will obviously be an added benefit. The work being done in both camps (MS for innovation and Mono for re-implementation) is, IMHO, very impressive.
You type less, obviously.
It also allows you to write pieces of code that are more generic. The LINQ samples have a lot of examples of this.
For example:
foreach (string s in collection) {
Console.WriteLine(s);
}
means you have to change the type everytime you change the type in the collection.
foreach (var item in collection) {
Console.WriteLine(item);
}
means that you can use it with any time that implements ToString, which is pretty much any type.
There are numerous other benefits from the type inference, and they become more apparent with lambda expressions, where you can write expressions like "x => x % 2 == 0" instead of writing the equivalent bool-returning delegate with a typed parameter.
Most of the new features of C# 3.0 are quite impressive and more importantly very useful.
Damn you, crazy frog, and your ability to ruin any song and any day, regardless of weather and earning potential. Please leave open source alone.
Which doesn't neccessarily mean "stay away". It could mean "go for it; some like the mother, some like the daughter, and some like both at the same time". Giggity.
There's no need to be a machine to consistently misinterpret.
Everyone should read Leisure Town ( http://www.leisuretown.com/ ). I am saying this because I totally love that comic. It's one of those things that manages to be amazingly stupid and mindboggling intelligent at the same time. It's fantasticly cheezy and infinitely stylish. It tackles both serious and lightweight issues. I does contain both good and great artwork. For an example of the latter, read "The Dog Mess" (Wasn't this called "The Dog Messiah" previously? Is my mind playing tricks on me?)
The story "What do people do all day" contains a joke so potent that I've pretty much been telling it two times a month since I first read it. It single handedly got me beaten up in the bathroom of the bar "99 bottles" in Santa Cruz. Or perhaps it had a little help from some of those 99 bottles, but I don't think I could have done it without the help from the joke.
If I'm not mistaken, the creator of Leisure Town is also the original author of "the Dilbert Hole", which I found amazingly funny. The strips can be found in the fantastic "A Comedy Crisis" on the Leisure Town site, although the script is played out by bunnies instead of Dilberts.
Leisure Town caters to all audiences, both wankers and techheads. You owe it to yourself to check it out, because chances are you are in fact both.
And while I'm at it, fanboying and meat puppeting, I need to shamelessly plug my own creation, the GladHeads. You can find it here: http://www.pacheads.com/
Not sure about the license, but I suppose it is somewhat restrictive. The point with having source code to a game like Allegiance isn't really to benefit from great technology in other games, but allow you to keep playing a new versions of a great game for free.
Regarding registration on related sites, I think you might have some trouble using anything that is remotely "throwaway"; at one point you actually had to be able to prove you were an american citizen to be able to register, using Paypal attached to a US account, IIRC. The people who are still playing seem quite happy about the current state of affairs, and people registering from bogus accounts could really kill the experience in a game which relies so much on team play.
Even Microsoft does it! The superfansastic MMO-tactical space shooter Allegiance, developed by Microsoft Research, is released with source. It seems to still have a large following, and I've been meaning to pick it personally. It gives me sort of the same feeling I got from reading about the "Battle Room" in Ender's Game.
;)
Check it out at: http://www.freeallegiance.org/
Beware, it's a very complex game and it will take you some time to learn if you should decide to start playing. And considering that the current crop of players probably has 3+ years of experience, I think you'll find the competition a little better than your average AI.
All in all, it's my favorite PC game of all time, next to Shiny's excellent Sacrifice.
Consider the Io language:
"Io is small prototype-based programming language. The ideas in Io are mostly inspired by Smalltalk (all values are objects), Self, NewtonScript and Act1 (prototype-based differential inheritance, actors and futures for concurrency), LISP (code is a runtime inspectable/modifiable tree) and Lua (small, embeddable)."
Example of Io-code:
http://iolanguage.com/about/samplecode/
My personal experience is that it's extremely easy to write, transparent and very introspective.
I like to think that I pay for access to the Internet, not some corporation's idea of what the Internet should be like.
Unfortunately, that's not the case.
I once had the opportunity to work for a boss who had the sense to remove people from lagging projects instead of throwing more people at it. Not necessarily the "bad coders", but the observation was that there is speed in smaller numbers. Especially true for those projects that just seem to be stuck at "90% finished" no matter how much time you sink into them.
Those were the days.
I use IM for people I know IRL. I cannot remember the last time I emailed someone I hang out with, seldomly or regularly. If they're not online, I use SMS. Email is either used to get to know new people or for business.
I've been playing with this idea in an application. It's sort of similar to the automator in Tiger, I've been told, except my system allows many-to-many-connections:
http://www.ignosaurus.com/pf1337/
The URL contains some screenshots and a flash demo.
I think there's definitely room for this kind of inter-application chaining, but in a more refined form. It makes batching a breeze.
The "acquire"-module is similar to a simple "ls" in many ways.
I currently work with the HP NonStop on the server side doing financial transaction processing.
While some of your points are indeed valid, your post loses some value because it's incomplete. True, Guardian, the underlying operating system, has "odd" limitations, like eight-character filenames, etc, but most applications we write these days uses OSS, which is a POSIX-layer on top of Guardian, allowing for "normal" UNIX-style filenames. True enough, there's always something that's different enough to make straight ports of UNIX software difficult, but the work involved is usually minimal.
The key strength (IMHO) of the system, is the "pathway system", which is a transaction based, load balancing message passing system which allows you to scale an application close to infinately, across physical machines and sites. It's simple to monitor, and it allows you to see which server processes need more instances easily. It's also very easy to setup more server instances, and your application code doesn't necessarily need to take extra steps to be instantaneously scalable. It also ties into the SQL-based databases which run on the system, so errors can be effectively backed out of.
Regarding disaster-recovery, I would hardly call HP NonStop "flawed". We have a separate physical site in case of fires, bombing, etc, and although there's no "automatical" failover setup in our facilities, failover from one physical site to another is an important piece of the NonStop design, and we rely on it. It's also very convenient to have another site to run an application when doing major upgrades, etc.
Next generation NonStop-machines will also be Itanium based, which, IIRC, will allow application programmers to use Intel C/C++ which is great at optimizing and very good at conforming to standards. That being said, the current line of development tools (ETK) allow you to write C/C++ with embedded SQL on the PC, hosted in Visual Studio, cross compiling with built in deployment-features using FTP. I think it's a fairly nice environment to work with considering the age of the hardware this is running on.
If you're in the market for a platform to do massive transaction based processing, you'll do yourself a favor by considering HP NonStop.