GWT Java-to-JS compiler does not reproduce the entire Java emulation library (or even your own code) as JS. It only compiles the parts that are being used in your application.
every Mac application is an MDI application, only the outer "application" window is always maximized and always transparent, with its menu always at the top of the screen.
I'd have to disagree with that somewhat. Yes, it's true that the OSX application menu takes over the top of the desktop and only one app menu can be displayed at a time. In other words, you're always in an application context. And so, when we switch windows, we are potentially switching application contexts, which makes sense. However, one thing I can do on OSX, I can't do in an MDI UI is bring just one of many application windows to the foreground, then switch to another application's one of many windows without bringing all the other applications' windows with it. That's an important distinction.
As of late, I'm a 100% XP user and have gotten used to the various idiosyncrasies of the different applications I use. I'm not really bashing MDI at all. I think it's appropriate to have different UI paradigms for different kinds of applications. In general I see shortcomings of all the different paradigms. It seems, the main problem with MDI is that one cannot easily reference other applications running behind the one you're in. At the same time, the thing that irritated me about the OSX way is that I never knew if there were windows belonging to an application I just switched to that I wasn't seeing. I fully admit that this was on a much earlier version of OSX and I may have been missing some usability tricks that would have rectified that situation.
One curious thing is a kind of MDI hybrid idea, where you have a document-based application, that also needs to bring some support windows along with it. GIMP is a good example. There's no parent window containing the document windows, as would have been the case in the more traditional MDI approach, but as soon as you switch to a document window, you see other GIMP windows appear as well. I find that a pretty good balance. Still, when it gets crowded on the desktop, I find myself often firing up a desktop switcher, like Virtual Dimension. I guess as long as we're proficient at whatever tools we have, there's no one right way of doing things, is there?
I'd say the point of this discussion is not the quality of the games that can at all be achieved, but their method of delivery. Sure, none of these games is truly groundbreaking, but what's new is that instead of installing a program from a diskette or a CD written for a specific OS, I can simply click on a link and be playing it within seconds.
Furthermore, what's neat about JS, as opposed to Flash Actionscript, is its inherent open source nature. Think about it. A modern browser downloads JS source (as well as the source for enclosing DOM elements), just-in-time compiles it with native optimizations and then runs it at near-native speed. We definitely did not have this before.
Just because something is popular, doesn't imply it's popular on its creative merits. Britney Spears is a lot more popular than Sonic Youth, for example.
I think if someone wants to give a good introduction on programming, the goals should encompass a detailed, but high-level overview of what computers do, how they are architected, what the different styles of programming are, and how to play around with them. It does not need to be a single language that rules them all. It does not even need to be the best representative of each style. I'd say the focus should be on getting the message of what each programming paradigm stands for as quickly as possible.
I would say that easy-to-use tools are important here. And they don't have to always be traditional development environments with traditional assignments. To teach the concepts of modern computer architecture, I'd devise a game, where students play the roles of a controller, memory, and other parts. Only, to make it interesting, the controller operates on a set of simple "real world" instructions that can be used to write a program that causes the players in the game to bake a cake or solve some puzzle. This would also go a long way in explaining some concepts of imperative programming, what compiled and interpreted languages are all about, etc.
For functional stuff, how about let the students play with spreadsheets? I am biased on this subject, having developed a kind of programmer's spreadsheet app that I think is great for this sort of exercise, but it's not the only one. There are lots of extensible spreadsheets out-there that can teach one the same concepts. Then, to reiterate how programming is not always manifested in the same way, draw parallels to XSLT processing and have the students grasp some concepts from there as well. The goal here is to teach them to think, not teach them a specific skill, yes?
While I'm not a fan of putting my own documents into someone else's hands, even if I was running a small shop, there are use cases for this, particularly if the service can be hosted in-house. Wouldn't surprise me if Google came out with an enterprise version of their office suite in the near future.
That statement is simply untrue. Java's libraries have had their source available, but not the JVM. Now we have Java source redistributable under a true OSS license and most importantly the JVM source is as well.
Well, I wasn't so much talking about leaving because the work environment is not fun, but because certain things can be taken as indicators of a company's poor financial health. In other words, it's better to look for a dingy while you're still on the sinking ship as opposed to when you're already in the water.
What about maintainability? flexibility? What if the person had to mentor others when trying to deliver the product? What about managing priorities? providing useful and easy to maintain unit tests? documentation? What about team work and consensus in trying to achieve that working solution? What about raising issues early?
Those are the kinds of things that fall into the team leader's lap to worry about from the very beginning. It is their responsibility to speak up the moment they realize a deadline is unrealistic or ill-advised. If a developer sees the team lead keep their mouth shut about such issues and allows the team to take the blame, they should then speak up and start looking for a job, unless changes are made. That's real life for ya.
In the 12 years I've been in software development, I've never seen a team lead not step up to the plate and let the upper management know that they're asking for some serious compromises. Usually, if they're already aware of it, they acknowledge it and accept the fact that certain peripheral tasks won't be done (training, documentation, maintainability) and they'll have to incur additional time costs later; or if they weren't aware of it, they try to revise the deliverables somewhat. But if developers and team leaders don't talk to anyone outside their world, they have no one to blame but themselves. If upper management is forced to ask to defer peripheral tasks for later on a regular basis, it's a good sign the company is in trouble and you should be looking for a new job, because after a few rounds of compromises, the next step is downsizing the team in order to make payroll.
I've had several backup/maintenance schemes set up at home over the years, often spanning Windows and Mac machines. Being a Java guy, I found Apache Ant to be a really good tool in place of shell or batch scripts. It's cross-platform, and it's quite extensible. And of course Java has pretty comprehensive cryptography API. And it wouldn't be much to wrap it all in a decent GUI, if that strikes your fancy or you want to roll it out to someone else to use, who's not comfortable with the lower level stuff.
To be quite honest, I had never been more excited than when I managed to get a magenta dot to appear on my screen, by directly accessing video memory.
I can relate. I'm not very unique in having started with BASIC, Pascal, C/C++, and Perl. What might be a little more unique is that I started programming with roughly 1 hr of computer lab time per week. That was back in Russia in the early 1990's. At that time, reading a book, experimenting, writing some code to manipulate video memory or the like and seeing that stupid dot on the screen was definitely magic. But maybe not so much now for a modern kid growing up surrounded by mobile devices and other clever gadgets, who probably can't even imagine a computer not connected to the internet.
What made the dot on the screen magic to us was that something grabbed our fancy and drew us in resulting in an early self-motivated interest in learning to program. The principle I'm sure is still valid today, but maybe the initial stimulus might have to be fine tuned. I don't have kids, so I'm kind of guessing here, but what I like about the Javascript idea is that it could allow a teen to start messing around with things that can
be used to construct things like what is relevant now (interesting web pages, games, rich(er) web apps);
be easily shared, shown off, reused, and continuously maintained; and
serve as a gateway to learning about server-side programming, networking, and other facets of modern computing.
What I think is really needed is the ability to process JavaScript. Take Google's own WebKit -- a page it produces will contain next to no interesting static HTML to index, while all the real content gets loaded through JavaScript, well before any kind of user interaction. A page like that is invisible to most web crawlers as far as I know.
I think you're focusing on a single point, while ignoring others. You may not be able to tell if a prospective employee will "go postal" at some point, but you can usually tell how well they'll get along with the team, bounce some questions back and forth quickly, both of technical and non-technical nature. You can more or less assess their hygiene, their demeanor, and their ability to think on their feet. It's all important, and it's not ephemeral.
Hope you don't mind my chiming in. I think there is some confusion on the part of the computers-everywhere crowd (as well as those arguing against their point of view):
Confusion #1: adding embedded CPU's is not the same as making everything connected
We've been seeing additions of embedded CPU's for some time now: smart phones, electronic fuel injection, security systems, musical greeting cards -- the list goes on. But most run-of-the-mill geeks have not really been swept up by this digitization fever until they could do something with those systems beyond simply using them. And it wasn't until non-geeks could see the fruits of the geeks' messing around that it really became relevant. Most of that comes from making these devices somehow connected to something we have already accepted into our lives. There 2 ways to do it at the moment: make those embedded systems talk to the internet as a whole, or make them talk a more conventional device, such as a computer or a cell phone. But without this connectivity, there's still a revolution of "making stuff smart" going on and making your toaster have a web page is not really the most interesting aspect of it at all, which seems a lot of people miss. Most people, regular geeks included, don't understand all the consumer and industrial applications of embedded devices and instead seem think in narrow internet- and PC-relevant terms.
Confusion #2: more data does not better information or happiness make
Early on in the PC revolution, there was this notion that if "everyone" had a computer, then "everyone" would write code in user-friendly programming languages/environments to solve their specific problems. Well, in a way it did realize itself, but not at all in the way many people thought it would and not to the same extent. Not many accountants burn the midnight oil busting out some kick-ass BASIC subroutines to better parse data. But many do write programs in Excel. It is of course a form of coding. Spreadsheets are probably the most consumer facing programming environments to date. And even they don't really enjoy the kind of pervasiveness some envisioned. Even spreadsheets are considered an office tool used by professionals (doing a grocery list print-out from Excel doesn't count). Most people don't want to "think" about technology. Most people want to get on with their lives and pursue their form of happiness. And sure, there are some people, for whom that pursuit of happiness coincides with technology tinkering. But even the geeks usually have their comfort zone, out of which they don't particularly care to venture. I like to code, sure, but while figuring out how to parallelize a bit of logic usually makes me happy, learning how to configure a new kind of web app with a new kind of framework often makes me wanna put a gun to my head. In other words: making high technology ubiquitous is one thing, but making its presence undeniably known with streams of data most people won't know what to do with is not a recipe for happiness. Industrial revolution has already shortened and disturbed our sleep cycle and now we're getting buzzed by an onslaught of alerts from the computer and cell phone. Do we really want more of the same with no clear benefit?
They did use their early monopoly power (when they were the only OS for IBM PCs) to sign exclusionary deals with computer vendors to ensure that no other OS could compete.
This in itself is not illegal. It's a very common practice in many different verticals. A while ago I was involved in an online startup in the motorcycle industry. Twice a year, there is a dealer expo in Indianapolis, where everybody, who is anybody in the industry, goes to catch up with their existing partners and scope out new ones. If you're a new kid on the block, that's where you go to get your place on the distribution chain.
I was amazed at how close-knit the industry is. There are a few major catalogs. Any dealer that wants to carry products with good margins has to deal with these catalogs, which demand exclusive contracts. If you're not in one of these catalogs, you're not making money -- it's just that simple. We realized that what we were doing was revolutionary to the industry. We were coming in with minimal contacts, asking manufacturers to distribute via our distribution channel and go around their catalog partners. We made some deals, but it was incredibly difficult. In the end, our company became a piggy-back on top of an existing brick-and-mortar shop that already had the catalog deals necessary for us to get the products through the catalogs at dealer cost. In other words, we plugged ourselves into the existing network. The consumer still saw some discounts, but nothing like what could potentially be done if the good old boy clique were to be erased and people were put in a room and forced to make deals from scratch.
But you know what, it would eventually come down to the same thing we have now after some rehashing. And every industry I know of works this way. A huge percentage of what comes out of consumers' pockets goes towards paying a whole lot of middlemen that take their cut to ensure the dealers upstream don't have to worry about making deals closer to the consumer. It's one big inefficient rat race. It's stupid, but that's how it is. What MS did is nothing new and not an iota different than how business works. I swear, every time I install a commercial piece of software that supports something (printer/fax drivers, music players, anti-virus, etc.) I have to weed through and refuse to install a bunch of software that's bundled with the core offering. How is any of that different than what MS did with the browser?
This whole notion of attributing human characteristics to large corporations is ridiculous. Companies are neither good nor evil. They simply operate for their and their shareholders' best interest. That's all. You wanna know why company X does something? Look at their market position. You wanna know why a politician does something? Find out who lobbies them. Even individuals can act wholly in accord with their circumstances. There is a film Red by Krzysztof Kieslowski, in which an old retired judge confesses that he'd have probably done exactly the same thing as all the people he sentenced, given their life story.
10 years ago I would have wholeheartedly agreed with you. I used to think caring about your appearance was a sign of narcissism. I've come to realize it is in fact the opposite. Most people have some sense of aesthetics. Proclaiming they're wrong and should disregard your stained wrinkly clothes is in fact incredibly ignorant and self-centered, while spending a few minutes a day paying attention to how you look is a nice gesture for those around you. 2 important points to remember:
Caring about one's appearance does not and should not preclude one from caring about those other "more important" things.
Telling people they're stupid or ignorant because their world view doesn't align with yours is a sign of a closed mind at the very least.
Nice fairy tale. Before you start telling people how things are, keep in mind that there are other sources of information out-there (kinda ironic, given the context of this thread).
With all due respect, Bill and Melinda Gates are already doing quite a bit in that regard with their foundation (remember the funds coming in from Warren Buffet?). So, as fun as it is to poke fun at, mistrust, or even abhor Bill Gates and Microsoft (welcome to 1998), he's not just talking the talk.
IT has slowed in the last 20 years, yes but only compared to the 'boom' of aeronautics from about 1950, to 1980. It is still increasing, and pretty fast as well.
It has slowed, but it is still increasing pretty fast. Interesting...
Slashdot Mirror
GWT Java-to-JS compiler does not reproduce the entire Java emulation library (or even your own code) as JS. It only compiles the parts that are being used in your application.
JDBC is part of JSE.
every Mac application is an MDI application, only the outer "application" window is always maximized and always transparent, with its menu always at the top of the screen.
I'd have to disagree with that somewhat. Yes, it's true that the OSX application menu takes over the top of the desktop and only one app menu can be displayed at a time. In other words, you're always in an application context. And so, when we switch windows, we are potentially switching application contexts, which makes sense. However, one thing I can do on OSX, I can't do in an MDI UI is bring just one of many application windows to the foreground, then switch to another application's one of many windows without bringing all the other applications' windows with it. That's an important distinction.
As of late, I'm a 100% XP user and have gotten used to the various idiosyncrasies of the different applications I use. I'm not really bashing MDI at all. I think it's appropriate to have different UI paradigms for different kinds of applications. In general I see shortcomings of all the different paradigms. It seems, the main problem with MDI is that one cannot easily reference other applications running behind the one you're in. At the same time, the thing that irritated me about the OSX way is that I never knew if there were windows belonging to an application I just switched to that I wasn't seeing. I fully admit that this was on a much earlier version of OSX and I may have been missing some usability tricks that would have rectified that situation.
One curious thing is a kind of MDI hybrid idea, where you have a document-based application, that also needs to bring some support windows along with it. GIMP is a good example. There's no parent window containing the document windows, as would have been the case in the more traditional MDI approach, but as soon as you switch to a document window, you see other GIMP windows appear as well. I find that a pretty good balance. Still, when it gets crowded on the desktop, I find myself often firing up a desktop switcher, like Virtual Dimension. I guess as long as we're proficient at whatever tools we have, there's no one right way of doing things, is there?
And?
I'd say the point of this discussion is not the quality of the games that can at all be achieved, but their method of delivery. Sure, none of these games is truly groundbreaking, but what's new is that instead of installing a program from a diskette or a CD written for a specific OS, I can simply click on a link and be playing it within seconds.
Furthermore, what's neat about JS, as opposed to Flash Actionscript, is its inherent open source nature. Think about it. A modern browser downloads JS source (as well as the source for enclosing DOM elements), just-in-time compiles it with native optimizations and then runs it at near-native speed. We definitely did not have this before.
Just because something is popular, doesn't imply it's popular on its creative merits. Britney Spears is a lot more popular than Sonic Youth, for example.
I think if someone wants to give a good introduction on programming, the goals should encompass a detailed, but high-level overview of what computers do, how they are architected, what the different styles of programming are, and how to play around with them. It does not need to be a single language that rules them all. It does not even need to be the best representative of each style. I'd say the focus should be on getting the message of what each programming paradigm stands for as quickly as possible.
I would say that easy-to-use tools are important here. And they don't have to always be traditional development environments with traditional assignments. To teach the concepts of modern computer architecture, I'd devise a game, where students play the roles of a controller, memory, and other parts. Only, to make it interesting, the controller operates on a set of simple "real world" instructions that can be used to write a program that causes the players in the game to bake a cake or solve some puzzle. This would also go a long way in explaining some concepts of imperative programming, what compiled and interpreted languages are all about, etc.
For functional stuff, how about let the students play with spreadsheets? I am biased on this subject, having developed a kind of programmer's spreadsheet app that I think is great for this sort of exercise, but it's not the only one. There are lots of extensible spreadsheets out-there that can teach one the same concepts. Then, to reiterate how programming is not always manifested in the same way, draw parallels to XSLT processing and have the students grasp some concepts from there as well. The goal here is to teach them to think, not teach them a specific skill, yes?
While I'm not a fan of putting my own documents into someone else's hands, even if I was running a small shop, there are use cases for this, particularly if the service can be hosted in-house. Wouldn't surprise me if Google came out with an enterprise version of their office suite in the near future.
Do you use Google Maps? Do you find AJAX use in that situation unnecessary?
As a non-OS bundled app, yes. I really like Virtual Dimension.
That statement is simply untrue. Java's libraries have had their source available, but not the JVM. Now we have Java source redistributable under a true OSS license and most importantly the JVM source is as well.
Well, I wasn't so much talking about leaving because the work environment is not fun, but because certain things can be taken as indicators of a company's poor financial health. In other words, it's better to look for a dingy while you're still on the sinking ship as opposed to when you're already in the water.
What about maintainability? flexibility? What if the person had to mentor others when trying to deliver the product? What about managing priorities? providing useful and easy to maintain unit tests? documentation? What about team work and consensus in trying to achieve that working solution? What about raising issues early?
Those are the kinds of things that fall into the team leader's lap to worry about from the very beginning. It is their responsibility to speak up the moment they realize a deadline is unrealistic or ill-advised. If a developer sees the team lead keep their mouth shut about such issues and allows the team to take the blame, they should then speak up and start looking for a job, unless changes are made. That's real life for ya.
In the 12 years I've been in software development, I've never seen a team lead not step up to the plate and let the upper management know that they're asking for some serious compromises. Usually, if they're already aware of it, they acknowledge it and accept the fact that certain peripheral tasks won't be done (training, documentation, maintainability) and they'll have to incur additional time costs later; or if they weren't aware of it, they try to revise the deliverables somewhat. But if developers and team leaders don't talk to anyone outside their world, they have no one to blame but themselves. If upper management is forced to ask to defer peripheral tasks for later on a regular basis, it's a good sign the company is in trouble and you should be looking for a new job, because after a few rounds of compromises, the next step is downsizing the team in order to make payroll.
I've had several backup/maintenance schemes set up at home over the years, often spanning Windows and Mac machines. Being a Java guy, I found Apache Ant to be a really good tool in place of shell or batch scripts. It's cross-platform, and it's quite extensible. And of course Java has pretty comprehensive cryptography API. And it wouldn't be much to wrap it all in a decent GUI, if that strikes your fancy or you want to roll it out to someone else to use, who's not comfortable with the lower level stuff.
To be quite honest, I had never been more excited than when I managed to get a magenta dot to appear on my screen, by directly accessing video memory.
I can relate. I'm not very unique in having started with BASIC, Pascal, C/C++, and Perl. What might be a little more unique is that I started programming with roughly 1 hr of computer lab time per week. That was back in Russia in the early 1990's. At that time, reading a book, experimenting, writing some code to manipulate video memory or the like and seeing that stupid dot on the screen was definitely magic. But maybe not so much now for a modern kid growing up surrounded by mobile devices and other clever gadgets, who probably can't even imagine a computer not connected to the internet.
What made the dot on the screen magic to us was that something grabbed our fancy and drew us in resulting in an early self-motivated interest in learning to program. The principle I'm sure is still valid today, but maybe the initial stimulus might have to be fine tuned. I don't have kids, so I'm kind of guessing here, but what I like about the Javascript idea is that it could allow a teen to start messing around with things that can
What I think is really needed is the ability to process JavaScript. Take Google's own WebKit -- a page it produces will contain next to no interesting static HTML to index, while all the real content gets loaded through JavaScript, well before any kind of user interaction. A page like that is invisible to most web crawlers as far as I know.
I think you're focusing on a single point, while ignoring others. You may not be able to tell if a prospective employee will "go postal" at some point, but you can usually tell how well they'll get along with the team, bounce some questions back and forth quickly, both of technical and non-technical nature. You can more or less assess their hygiene, their demeanor, and their ability to think on their feet. It's all important, and it's not ephemeral.
Seems you don't know the difference between psychology and psychiatry. Might be worthwhile looking it up before talking about pills.
Hope you don't mind my chiming in. I think there is some confusion on the part of the computers-everywhere crowd (as well as those arguing against their point of view):
Confusion #1: adding embedded CPU's is not the same as making everything connected
We've been seeing additions of embedded CPU's for some time now: smart phones, electronic fuel injection, security systems, musical greeting cards -- the list goes on. But most run-of-the-mill geeks have not really been swept up by this digitization fever until they could do something with those systems beyond simply using them. And it wasn't until non-geeks could see the fruits of the geeks' messing around that it really became relevant. Most of that comes from making these devices somehow connected to something we have already accepted into our lives. There 2 ways to do it at the moment: make those embedded systems talk to the internet as a whole, or make them talk a more conventional device, such as a computer or a cell phone. But without this connectivity, there's still a revolution of "making stuff smart" going on and making your toaster have a web page is not really the most interesting aspect of it at all, which seems a lot of people miss. Most people, regular geeks included, don't understand all the consumer and industrial applications of embedded devices and instead seem think in narrow internet- and PC-relevant terms.
Confusion #2: more data does not better information or happiness make
Early on in the PC revolution, there was this notion that if "everyone" had a computer, then "everyone" would write code in user-friendly programming languages/environments to solve their specific problems. Well, in a way it did realize itself, but not at all in the way many people thought it would and not to the same extent. Not many accountants burn the midnight oil busting out some kick-ass BASIC subroutines to better parse data. But many do write programs in Excel. It is of course a form of coding. Spreadsheets are probably the most consumer facing programming environments to date. And even they don't really enjoy the kind of pervasiveness some envisioned. Even spreadsheets are considered an office tool used by professionals (doing a grocery list print-out from Excel doesn't count). Most people don't want to "think" about technology. Most people want to get on with their lives and pursue their form of happiness. And sure, there are some people, for whom that pursuit of happiness coincides with technology tinkering. But even the geeks usually have their comfort zone, out of which they don't particularly care to venture. I like to code, sure, but while figuring out how to parallelize a bit of logic usually makes me happy, learning how to configure a new kind of web app with a new kind of framework often makes me wanna put a gun to my head. In other words: making high technology ubiquitous is one thing, but making its presence undeniably known with streams of data most people won't know what to do with is not a recipe for happiness. Industrial revolution has already shortened and disturbed our sleep cycle and now we're getting buzzed by an onslaught of alerts from the computer and cell phone. Do we really want more of the same with no clear benefit?
This in itself is not illegal. It's a very common practice in many different verticals. A while ago I was involved in an online startup in the motorcycle industry. Twice a year, there is a dealer expo in Indianapolis, where everybody, who is anybody in the industry, goes to catch up with their existing partners and scope out new ones. If you're a new kid on the block, that's where you go to get your place on the distribution chain.
I was amazed at how close-knit the industry is. There are a few major catalogs. Any dealer that wants to carry products with good margins has to deal with these catalogs, which demand exclusive contracts. If you're not in one of these catalogs, you're not making money -- it's just that simple. We realized that what we were doing was revolutionary to the industry. We were coming in with minimal contacts, asking manufacturers to distribute via our distribution channel and go around their catalog partners. We made some deals, but it was incredibly difficult. In the end, our company became a piggy-back on top of an existing brick-and-mortar shop that already had the catalog deals necessary for us to get the products through the catalogs at dealer cost. In other words, we plugged ourselves into the existing network. The consumer still saw some discounts, but nothing like what could potentially be done if the good old boy clique were to be erased and people were put in a room and forced to make deals from scratch.
But you know what, it would eventually come down to the same thing we have now after some rehashing. And every industry I know of works this way. A huge percentage of what comes out of consumers' pockets goes towards paying a whole lot of middlemen that take their cut to ensure the dealers upstream don't have to worry about making deals closer to the consumer. It's one big inefficient rat race. It's stupid, but that's how it is. What MS did is nothing new and not an iota different than how business works. I swear, every time I install a commercial piece of software that supports something (printer/fax drivers, music players, anti-virus, etc.) I have to weed through and refuse to install a bunch of software that's bundled with the core offering. How is any of that different than what MS did with the browser?
This whole notion of attributing human characteristics to large corporations is ridiculous. Companies are neither good nor evil. They simply operate for their and their shareholders' best interest. That's all. You wanna know why company X does something? Look at their market position. You wanna know why a politician does something? Find out who lobbies them. Even individuals can act wholly in accord with their circumstances. There is a film Red by Krzysztof Kieslowski, in which an old retired judge confesses that he'd have probably done exactly the same thing as all the people he sentenced, given their life story.
Nice fairy tale. Before you start telling people how things are, keep in mind that there are other sources of information out-there (kinda ironic, given the context of this thread).
With all due respect, Bill and Melinda Gates are already doing quite a bit in that regard with their foundation (remember the funds coming in from Warren Buffet?). So, as fun as it is to poke fun at, mistrust, or even abhor Bill Gates and Microsoft (welcome to 1998), he's not just talking the talk.
Me too...