...more than anyone else, you mean.
This kind of behaviour means we're all living under an implicit cloud of suspicion -- if we weren't suspect, what valid cause would there be for interference? My personal financial matters are my own personal financial matters, and why a transaction between myself and an entity I happen to contract with to keep my money has any business being audited by a government entity charged with "homeland security" -- well, it wants something by way of explanation.
Because he's hasn't committed copyright violation in the traditional sense. Trade secrets don't apply, traditional patents certainly don't (and the relevant untraditional type have never been tested in court).
If he's succesfully sued for using a set of possible historical facts in his texts... well, that makes it hard to write much of anything and be safe.
(That said, Dan Brown is a hack with no regard whatsoever for subject-matter accuracy in his novels. Don't believe me? Read Digital Fortress).
If stone or bricks had been better tradeoffs than paper, we would be using them already. If I were to draw a curve describing the tradeoff between ease-of-handling and the level of risk incurred due to such ease-of-handling, flash cards would be far on one side of the curve (exceedingly easy to handle; very substantial security risk incurred due to ease of handling); bricks would be far on the other (exceedingly hard to handle; minimal security risk incurred due to ease of handling); and paper would be a happy medium (reasonably easy-to-handle; managable level of security risk).
Just because someone believes paper should be used in place of flash cards due to security concerns, it does not follow that said person believes that bricks would be better than paper -- and making such a carciature of one's position adds nothing useful to the discussion.
much like hiring a CS PhD who can't tell me how many cycles it takes to strcmp( "apple", "apples" ).
Hmm. I could see someone generally having some clue getting that wrong off the top of their head.
Lessee... per character we've got two loads, two compares (to see if we've hit the nulls), an additional compare (to see which register's value is larger), and two increments per cycle. When we hit the nulls, we stop after... the second compare? So unless I missed something here -- which without writing it out I may well have -- I'm counting 37 instructions.
Do I need to know the relevant calling convention and tell you how many instructions we go through pulling parameters off the stack and (afterwards) putting the return value back on? I'm quite sure I couldn't tell you that off the top of my head. If you want pipelining taken into account in determining the timing, that's a whole additional set of complexity I'm not equipt to handle.
I'd like to think that I'm on par with your average CS PhD, but if you want an actual correct answer (rather than one that indicates the interviewee thought about all the right things), I don't have particularly high confidence on my ability to answer that one.
Tolerance goes a lot further than playing grammar and spelling Nazi.
Do you see me doing that? Little typos that a reasonably literate individual can make by mistake -- no, I don't have a problem with those. Casually making errors substantial enough to impact understanding and then defending such sloppiness? That's an entirely different kettle of fish.
I'm not asking everyone to be an English major; I'm asking people to pay attention to what they write, reread what they wrote before posting it somewhere thousands of people will see it, and generally act in a manner which is respectful towards their readers. This isn't rocket science, and it doesn't require a four-year degree -- just paying attention to English classes in even an American public high school ought to be good enough. What I see all too frequently is not people who lack the education to write well; rather, it's those who simply don't care enough about their image or their audiance to put forth the effort despite having the ability.
Heh. Don't be such a fucking prude about something as non-threatened as language.
I don't doubt that there's going to continue to be a subset of the populace able to write well -- but I think I'm acting reasonably in desiring that subset to be a large one. While there may be no threat to the continued existance of language as a whole, there is most assuredly a substantial threat to having a large populace able to write in a way which doesn't inherently limit their potential social stature. (To be sure, there are CEOs and such with limited literacy -- but there are also a great many places where being unskilled with the written word will indeed limit advancement and respect).
If that were true you wouldn't use English, you'd use mathematics, or a computer language.
That defeats the "so people can understand you" aspect. (Mathematics, computer languages and such are also obviously unsuited for communication outside their specialties).
English and just about every language in the world are by their very nature imprecise, open to multiple interpretations, and deeply entrenched in the culture of the day.
That's most assuredly so -- but a skilled author knows where these imprecisions are, and is able to leverage them advantageously when desired and minimize their impact when such is undesired. Adding new imprecision, unless done for a specific desired effect, is generally undesirable; doing it unknowingly (as when substituting "loose" for "lose" -- there are many times when both will make sense but have completely different meanings) is far worse; and defending those who add new imprecision unknowingly... well, it's a practice I find objectionable.
"Enlightened"?! It's merely apologizing for sloppyness, legitimizing the rationale that anything goes, so long as the point gets across.
This is by no means acceptable. A well-written message not only reflects well on the individual who wrote it (and the effort and thought that was put into its formulation), but also is easier and more enjoyable for the recipient to read. Writing well, thus, is being respectful and polite towards your audience. This is particularly true when one considers that most items which are written have more than one reader, and many items (mailing list postings and such) will be read hundreds or thousands of times; consequently, the positive benefit from a well-formulated message is amplified correspondingly.
Rationalizing a behaviour which is simultaniously selfish (inasmuch as it attempts to trade the reader's time and comfort for the author's) and self-destructive (inasmuch as it casts the author and the message which the author presumably seeks to promote in a bad light in the eyes of readers) as "enlightened" is simply wrongheaded.
Nobody's arguing programmers should be able to use their own personal style to decide what language to code in, or otherwise flaunt company-wide standardization needlessly.
People are arguing that programmers, when they make a strong argument as to the benefits of doing so, should be able to apply a language more appropriate than that which is by policy preferred (as opposed to mandated) towards a given problem.
... and often in the middle of code that you don't have a symbol table for, let alone the source.
Who the hell would use a non-source-available interpreted language for a commercial project, when there are so many good source-available ones?
I've seen quite a few commercial games embedding Python lately; I vaguely recall one a while back that embedded a Scheme; there are other Free (and non-copylefted) interpreterers that target Java bytecode for easy integration in Java-based projects... why would anyone ever use anything else?
Object orientation is a Good Thing. C++'s implementation is hideous. It's not that classes are bad -- it's that C++ is. (Also, just to point it out: C++ is far from the first object oriented language to exist. Indeed, C++ wasn't even the first object-oriented extension of C, and the other one -- Objective C -- is generally considered far superior among those few who know both).
(Not convinced? Try porting C++ code which uses all the fancy language features between compilers. The language spec is complex enough to have enough hidden corner cases [particularly in the interactions between features] that no two implementations will ever behave quite the same; this was particularly apparent for those of us who were around during or prior to the egcs phase. Contrast to languages like Scheme (which is powerful while being so simple that the language has no hidden corner cases -- "obviously unflawed" vs "no obvious flaws", despite being useless for practical work on account of lacking a complete runtime library available across implementations) or Python (not as simple as Scheme, but still several independent implementations which -- for the language versions they implement -- tend not to have the gotchas)).
C++ and C are two completely, totally different languages. Don't let your experiences with C++ color your opinion of C -- C is outstanding, in its place. (That said, it certainly has its place, and that place certainly isn't everywhere).
I have to disagree with this comment. While there is some merit in a division of teams and detailed skill sets, it has been my experience that teams which dive deeply into one subject area while avoiding all others are very near useless when it comes to resolving issues. I have done quite a bit of coding, but my primary area of expertise is Communications. In the groups I've worked with, the most benefitial resources are the ones who know a little coding, a little security, a little systems administration, a little communications, and then have a specialty or two.
I'm not arguing with you by any means, but that's not to say that it's necessarily feasible to have a team primarily consisting of generalists. Having a large team made up mostly of specialists with a few generalists thrown in the mix, and smaller teams with ancillary purposes being made up primarily of generalists, tends to work for my present employer: Specialists are much easier to find and recruit. The generalists can request advice from a specialist when need be; the specialists are heavily involved in overall design and sit in on reviews of component designs generated internally to the specialists' team; and things mostly tend to work out.
As an aside: I'm not really sure how someone could be focused on sysadmin work and not be able to handily do any of the tasks you mention. From our perspective, a remotely competant sysadmin can handle any of those tasks; a good one can also build a SCSI driver for the tape jukebox we just bought, rewrite the DSDT table on one of our servers where the PCI bus isn't being initialized correctly, rig up an Asterisk box, build tools to autoconfigure IP phones from $SUPPLIER_OF_THE_WEEK, repair a broken Oracle instance while the DBA's out of reach, modify OSS tools or come up with some scripts to populate the new CRM system's database based on our LDAP directory. All of these are things we've done in-house. That said, we have a lot of trouble finding good sysadmins.
Here, we have a large staff that knows Java and (in some cases) SQL. That's all they're expected to know, and they're expected to be good at it.
We have a much smaller subset of our staff that knows Java, Python, PHP, C, C++, SQL, POSIX shell, and a bunch of little special-purpose languages as well -- and if we needed to learn a few more, we could do that too, and quickly.
If you keep folks on staff (not your whole staff, just some subset -- perhaps a quite small one) who are flexible enough to handle whatever gets thrown at them, that's good enough to handle just 'bout anything. See my more extensive post elsewhere.
... and then what happens if you then want to put some of the functionality that you wrote in your flat text reader into your web service (for example)?
Then you come up with a clean interface between the two. XML-RPC libraries are available for almost every language in existance right now, and lighter-weight alternatives are also available. This is what we use for integration between our Python-based screen scrapers and Java-based web services. For more complex cases, any modern scripting language worth its salt (read: "not Perl") has a clean, simple and easy-to-use interface with C, CLR or Java bytecode as well.
You're right in that man-hour cost is typically given insufficient weight in decisions relating to software development -- but productivity can be dramatically increased (and thus those costs reduced) by using a language appropriate to the task at hand. I've seen studies (ask if you need references and I'll try to dredge them up) indicating that the number of finished, debugged lines of code stays generally constant regardless of the language used. This means, of course, that a language which allows a given project to be completed in 1/10 the number of LOCs as would be required in another (not unrealistic -- I've seen that ratio or better in comparing Python and C, and 1/3 to 1/5 in comparing Python to Java for projects which Python is appropriate for; however, there are projects for which Python simply isn't appropriate, and only C will do) can allow that project to be completed with a fraction of the number of man-hours which would otherwise be required.
I've also had projects (for my current employer) where what would otherwise have been a multi-month effort was literally finished overnight via use of 3rd-party code available only in C++ -- and we're a Java house.
Using multiple languages within a single project sometimes makes sense, as well. The use of embedded scripting in modern computer games has made it much easier to have one team develop high-level behaviour quickly using an interpreted language while another team focuses on low-level underpinnings -- not to mention increasing customers' replay value via allowing easier and more extensive modding.
Using different languages within commercial software development, particuarly when said languages are separated by clear product or functional boundaries, frequently makes sense.
If you don't trust your technical staff's ability to clearly communicate accurate answers to your technical questions, you need a better technical staff. (Correlary: If your managers don't trust your judgement, either you or they should be fired).
Yes, such environments exist. I'll admit, though, that they're rarities.
If that's all you're doing, and there's not a huge amount of variety between projects, and your sysadmins don't write in-house tools which might be covered by this policy, good for you. That said, I'm in an environment where there are good reasons to be heterogenous, and I would object strenuously if there were attempts by someone in management to make that change.
Our core (a large webapp) is written purely in Java. That makes sense -- it should be written purely in Java, and if some developer were to prefer to use Jython or a Java-bytecode-compilable Scheme variant, they'd need to have an exceedingly compelling reason. However, there's more to our company than just the one webapp, and that's where other languages come into play.
For the surrounding infrastructure that supports our code, we have bits written in POSIX shell (mostly related to integration with various components of the operating system -- these would be much more trouble to build and maintain in a different language, and the JVM's limited view of UNIX permissions means that some of their functionality couldn't be implemented in Java at all without writing a JNI module); bits written in Python (most particularly, our framework for using a fully OO inheritance model to build screen scrapers for 3rd-party terminal applications with which we need to integrate. This uses pexpect, a Python-focused variant of Expect [which is otherwise available for Tcl, and also has a Perl variant, but would be a PITA in either C or Java], for the screen scraping bits, and makes heavy use of Python's object model (including some things that Java won't do) to keep the code size and complexity for the actual screen scrapers (as opposed to the framework) at a minimum).
We maintain patches to some 3rd-party OS-level tools which are written in C. We maintain some win32-specific tools, including an installer (written in a custom language just for the purpose) for a package of items to be installed on our client systems. We've patched the DSDT tables used to initialize the PCI bus on our servers before (large systems which were given to us by a partner free-of-charge) and written our own SCSI drivers (to be able to use a tape jukebox which we picked up nearly for free). We couldn't conceivably do all this in one language.
If we'd been hamstrung to use Java for everything, the Windows installer would have been a pain. The screen scraper integration code would have been almost unthinkable to write in-house, and we would have licensed a (hard-to-use and expensive) API from a 3rd party. We wouldn't have been able to write the remote client support tool based on the UltraVNC SC client (the first version was literally put together overnight; the upstream code is C++). The system administration tools would have been written in shell in violation of the policy, because convincing sysadmins to write their tools in Java is pretty much unthinkable.
That said, things are still broken out. The core dev team, which is most of the coding staff, only needs to know Java (and in many cases SQL). The system administrators only need to know POSIX shell, Python, PHP, SQL and C (and the entry-level ones can get away with only POSIX shell). The integration developers only need to know Python, Java and SQL, with a little POSIX shell being helpful but not required. The deployment engineers need POSIX shell, Python and SQL, and the most senior of them need C. Just because we have a number of different languages in use somewhere in the company doesn't mean that everyone needs to know everything, and the strong majority of dev staff (the core team) knows only one. System administration, integration and deployment are much smaller groups, so training them is more reasonable. (Further, these requirements are of the form "someone in the department must know", rather than "everyone in the department must know", particularly for the latter-listed languages).
They signed Trademark agreements that aren't redistributable, making their software unfree even though the package has License: GPL in the.spec.
You can rebuild the packages, you can redistribute them. You can't claim that the resulting distribution is Red Hat Enterprise Linux -- which is fair, because it isn't. See the HOWTO on this topic.
One of the original tenants of the GPL is that when distributing modified copies, one must acknowledge that it is not the original work. Using trademark law to require folks to make it clear that their modified derivatives are not endorsed by the authors of the original software is an extension which is clearly in line with these principals.
How can we justify missions to Mars when kids are still going to bed hungry?
Because if we waited until no kids went to bed hungry, there'd never be missions to mars, and we as a society would be all the poorer for it. (Maybe we haven't profited much from the mars missions lately, except for a rekindling of public interest -- but look at all the advances in science the space program as a whole led to!)
If we waited until everyone was housed before providing wireless communications infrastructure (which is what these laptops do -- they set up massive-scale mesh networking even without cell towers available), the infrastructure would never get there.
Moreover, and more importantly, the communications infrastucture enables the folks who otherwise would be just recipients for handouts to better help themselves. Local businesses are easier to organize and run more efficiently with communication technology -- farmers and ranchers can run their affairs more profitably and effectively if they know where and when their products are needed -- and that in turn makes people better able to afford their own houses, infrastructure and so forth.
Finally, there's not a limited set of dollars and man-hours available for charity: People have their own causes they're interested in, and won't contribute as much or as effectively to others. Saying "why should anyone contribute to $FOO when there's still work for $BAR" overlooks this; both $FOO and $BAR can be done at once, and with more effective resource allocation than one would get if telling folks who would find $BAR interesting that they must contribute to/work on $FOO instead or do nothing at all.
Having computers will enable people to access information to educate themselves, and will allow them to establish communications necessary for a larger-scale economy (so that they can build their own infrastructure).
Think of it as a "give a man a fish" situation.
Medical equipment does nothing but increase the number of poor people. Schools are something, but people can teach anywhere, so long as they have knowledge to pass on and incentive to do so. Communications infrastructure, on the other hand -- that's useful.
It will end up like the tablet PC. A decent enough idea, but done poorly with bad software choices, and never achieve enough market to be effective.
There are niche markets (like doctors' offices) where tablet PCs make a very compelling value proposition. Are they ever going to compete with laptops? Of course not. Is there enough of a market to justify several companies (as opposed to "every company that does PCs and laptops") producing them? Absolutely.
The mini-PC phone may well end up in a similar position.
Slashdot Mirror
Because he's hasn't committed copyright violation in the traditional sense. Trade secrets don't apply, traditional patents certainly don't (and the relevant untraditional type have never been tested in court).
If he's succesfully sued for using a set of possible historical facts in his texts... well, that makes it hard to write much of anything and be safe.
(That said, Dan Brown is a hack with no regard whatsoever for subject-matter accuracy in his novels. Don't believe me? Read Digital Fortress).
I realized as much -- but just because it's a joke doesn't mean it isn't intended to carciature an opponent's position unfairly.
If stone or bricks had been better tradeoffs than paper, we would be using them already. If I were to draw a curve describing the tradeoff between ease-of-handling and the level of risk incurred due to such ease-of-handling, flash cards would be far on one side of the curve (exceedingly easy to handle; very substantial security risk incurred due to ease of handling); bricks would be far on the other (exceedingly hard to handle; minimal security risk incurred due to ease of handling); and paper would be a happy medium (reasonably easy-to-handle; managable level of security risk).
Just because someone believes paper should be used in place of flash cards due to security concerns, it does not follow that said person believes that bricks would be better than paper -- and making such a carciature of one's position adds nothing useful to the discussion.
much like hiring a CS PhD who can't tell me how many cycles it takes to strcmp( "apple", "apples" ).
Hmm. I could see someone generally having some clue getting that wrong off the top of their head.
Lessee... per character we've got two loads, two compares (to see if we've hit the nulls), an additional compare (to see which register's value is larger), and two increments per cycle. When we hit the nulls, we stop after... the second compare? So unless I missed something here -- which without writing it out I may well have -- I'm counting 37 instructions.
Do I need to know the relevant calling convention and tell you how many instructions we go through pulling parameters off the stack and (afterwards) putting the return value back on? I'm quite sure I couldn't tell you that off the top of my head. If you want pipelining taken into account in determining the timing, that's a whole additional set of complexity I'm not equipt to handle.
I'd like to think that I'm on par with your average CS PhD, but if you want an actual correct answer (rather than one that indicates the interviewee thought about all the right things), I don't have particularly high confidence on my ability to answer that one.
Do you see me doing that? Little typos that a reasonably literate individual can make by mistake -- no, I don't have a problem with those. Casually making errors substantial enough to impact understanding and then defending such sloppiness? That's an entirely different kettle of fish.
I'm not asking everyone to be an English major; I'm asking people to pay attention to what they write, reread what they wrote before posting it somewhere thousands of people will see it, and generally act in a manner which is respectful towards their readers. This isn't rocket science, and it doesn't require a four-year degree -- just paying attention to English classes in even an American public high school ought to be good enough. What I see all too frequently is not people who lack the education to write well; rather, it's those who simply don't care enough about their image or their audiance to put forth the effort despite having the ability.
By the way, if you haven't read Orwell's essay Politics and the English Language, I strongly recommend it.
That defeats the "so people can understand you" aspect. (Mathematics, computer languages and such are also obviously unsuited for communication outside their specialties).
That's most assuredly so -- but a skilled author knows where these imprecisions are, and is able to leverage them advantageously when desired and minimize their impact when such is undesired. Adding new imprecision, unless done for a specific desired effect, is generally undesirable; doing it unknowingly (as when substituting "loose" for "lose" -- there are many times when both will make sense but have completely different meanings) is far worse; and defending those who add new imprecision unknowingly... well, it's a practice I find objectionable.
"Enlightened"?! It's merely apologizing for sloppyness, legitimizing the rationale that anything goes, so long as the point gets across.
This is by no means acceptable. A well-written message not only reflects well on the individual who wrote it (and the effort and thought that was put into its formulation), but also is easier and more enjoyable for the recipient to read. Writing well, thus, is being respectful and polite towards your audience. This is particularly true when one considers that most items which are written have more than one reader, and many items (mailing list postings and such) will be read hundreds or thousands of times; consequently, the positive benefit from a well-formulated message is amplified correspondingly.
Rationalizing a behaviour which is simultaniously selfish (inasmuch as it attempts to trade the reader's time and comfort for the author's) and self-destructive (inasmuch as it casts the author and the message which the author presumably seeks to promote in a bad light in the eyes of readers) as "enlightened" is simply wrongheaded.
They're condemning the game, but not calling for a ban.
Nobody's arguing programmers should be able to use their own personal style to decide what language to code in, or otherwise flaunt company-wide standardization needlessly.
People are arguing that programmers, when they make a strong argument as to the benefits of doing so, should be able to apply a language more appropriate than that which is by policy preferred (as opposed to mandated) towards a given problem.
Who the hell would use a non-source-available interpreted language for a commercial project, when there are so many good source-available ones?
I've seen quite a few commercial games embedding Python lately; I vaguely recall one a while back that embedded a Scheme; there are other Free (and non-copylefted) interpreterers that target Java bytecode for easy integration in Java-based projects... why would anyone ever use anything else?
Object orientation is a Good Thing. C++'s implementation is hideous. It's not that classes are bad -- it's that C++ is. (Also, just to point it out: C++ is far from the first object oriented language to exist. Indeed, C++ wasn't even the first object-oriented extension of C, and the other one -- Objective C -- is generally considered far superior among those few who know both).
(Not convinced? Try porting C++ code which uses all the fancy language features between compilers. The language spec is complex enough to have enough hidden corner cases [particularly in the interactions between features] that no two implementations will ever behave quite the same; this was particularly apparent for those of us who were around during or prior to the egcs phase. Contrast to languages like Scheme (which is powerful while being so simple that the language has no hidden corner cases -- "obviously unflawed" vs "no obvious flaws", despite being useless for practical work on account of lacking a complete runtime library available across implementations) or Python (not as simple as Scheme, but still several independent implementations which -- for the language versions they implement -- tend not to have the gotchas)).
C++ and C are two completely, totally different languages. Don't let your experiences with C++ color your opinion of C -- C is outstanding, in its place. (That said, it certainly has its place, and that place certainly isn't everywhere).
I'm not arguing with you by any means, but that's not to say that it's necessarily feasible to have a team primarily consisting of generalists. Having a large team made up mostly of specialists with a few generalists thrown in the mix, and smaller teams with ancillary purposes being made up primarily of generalists, tends to work for my present employer: Specialists are much easier to find and recruit. The generalists can request advice from a specialist when need be; the specialists are heavily involved in overall design and sit in on reviews of component designs generated internally to the specialists' team; and things mostly tend to work out.
As an aside: I'm not really sure how someone could be focused on sysadmin work and not be able to handily do any of the tasks you mention. From our perspective, a remotely competant sysadmin can handle any of those tasks; a good one can also build a SCSI driver for the tape jukebox we just bought, rewrite the DSDT table on one of our servers where the PCI bus isn't being initialized correctly, rig up an Asterisk box, build tools to autoconfigure IP phones from $SUPPLIER_OF_THE_WEEK, repair a broken Oracle instance while the DBA's out of reach, modify OSS tools or come up with some scripts to populate the new CRM system's database based on our LDAP directory. All of these are things we've done in-house. That said, we have a lot of trouble finding good sysadmins.
Here, we have a large staff that knows Java and (in some cases) SQL. That's all they're expected to know, and they're expected to be good at it.
We have a much smaller subset of our staff that knows Java, Python, PHP, C, C++, SQL, POSIX shell, and a bunch of little special-purpose languages as well -- and if we needed to learn a few more, we could do that too, and quickly.
If you keep folks on staff (not your whole staff, just some subset -- perhaps a quite small one) who are flexible enough to handle whatever gets thrown at them, that's good enough to handle just 'bout anything. See my more extensive post elsewhere.
You're right in that man-hour cost is typically given insufficient weight in decisions relating to software development -- but productivity can be dramatically increased (and thus those costs reduced) by using a language appropriate to the task at hand. I've seen studies (ask if you need references and I'll try to dredge them up) indicating that the number of finished, debugged lines of code stays generally constant regardless of the language used. This means, of course, that a language which allows a given project to be completed in 1/10 the number of LOCs as would be required in another (not unrealistic -- I've seen that ratio or better in comparing Python and C, and 1/3 to 1/5 in comparing Python to Java for projects which Python is appropriate for; however, there are projects for which Python simply isn't appropriate, and only C will do) can allow that project to be completed with a fraction of the number of man-hours which would otherwise be required.
I've also had projects (for my current employer) where what would otherwise have been a multi-month effort was literally finished overnight via use of 3rd-party code available only in C++ -- and we're a Java house.
Using multiple languages within a single project sometimes makes sense, as well. The use of embedded scripting in modern computer games has made it much easier to have one team develop high-level behaviour quickly using an interpreted language while another team focuses on low-level underpinnings -- not to mention increasing customers' replay value via allowing easier and more extensive modding.
Using different languages within commercial software development, particuarly when said languages are separated by clear product or functional boundaries, frequently makes sense.
See my other post as well.
If you don't trust your technical staff's ability to clearly communicate accurate answers to your technical questions, you need a better technical staff. (Correlary: If your managers don't trust your judgement, either you or they should be fired).
Yes, such environments exist. I'll admit, though, that they're rarities.
If that's all you're doing, and there's not a huge amount of variety between projects, and your sysadmins don't write in-house tools which might be covered by this policy, good for you. That said, I'm in an environment where there are good reasons to be heterogenous, and I would object strenuously if there were attempts by someone in management to make that change.
Our core (a large webapp) is written purely in Java. That makes sense -- it should be written purely in Java, and if some developer were to prefer to use Jython or a Java-bytecode-compilable Scheme variant, they'd need to have an exceedingly compelling reason. However, there's more to our company than just the one webapp, and that's where other languages come into play.
For the surrounding infrastructure that supports our code, we have bits written in POSIX shell (mostly related to integration with various components of the operating system -- these would be much more trouble to build and maintain in a different language, and the JVM's limited view of UNIX permissions means that some of their functionality couldn't be implemented in Java at all without writing a JNI module); bits written in Python (most particularly, our framework for using a fully OO inheritance model to build screen scrapers for 3rd-party terminal applications with which we need to integrate. This uses pexpect, a Python-focused variant of Expect [which is otherwise available for Tcl, and also has a Perl variant, but would be a PITA in either C or Java], for the screen scraping bits, and makes heavy use of Python's object model (including some things that Java won't do) to keep the code size and complexity for the actual screen scrapers (as opposed to the framework) at a minimum).
We maintain patches to some 3rd-party OS-level tools which are written in C. We maintain some win32-specific tools, including an installer (written in a custom language just for the purpose) for a package of items to be installed on our client systems. We've patched the DSDT tables used to initialize the PCI bus on our servers before (large systems which were given to us by a partner free-of-charge) and written our own SCSI drivers (to be able to use a tape jukebox which we picked up nearly for free). We couldn't conceivably do all this in one language.
If we'd been hamstrung to use Java for everything, the Windows installer would have been a pain. The screen scraper integration code would have been almost unthinkable to write in-house, and we would have licensed a (hard-to-use and expensive) API from a 3rd party. We wouldn't have been able to write the remote client support tool based on the UltraVNC SC client (the first version was literally put together overnight; the upstream code is C++). The system administration tools would have been written in shell in violation of the policy, because convincing sysadmins to write their tools in Java is pretty much unthinkable.
That said, things are still broken out. The core dev team, which is most of the coding staff, only needs to know Java (and in many cases SQL). The system administrators only need to know POSIX shell, Python, PHP, SQL and C (and the entry-level ones can get away with only POSIX shell). The integration developers only need to know Python, Java and SQL, with a little POSIX shell being helpful but not required. The deployment engineers need POSIX shell, Python and SQL, and the most senior of them need C. Just because we have a number of different languages in use somewhere in the company doesn't mean that everyone needs to know everything, and the strong majority of dev staff (the core team) knows only one. System administration, integration and deployment are much smaller groups, so training them is more reasonable. (Further, these requirements are of the form "someone in the department must know", rather than "everyone in the department must know", particularly for the latter-listed languages).
Standardizing on
Didn't realize who you were. You obviously have more grounds to speak on this topic than I do. My apologies.
They signed Trademark agreements that aren't redistributable, making their software unfree even though the package has License: GPL in the .spec.
You can rebuild the packages, you can redistribute them. You can't claim that the resulting distribution is Red Hat Enterprise Linux -- which is fair, because it isn't. See the HOWTO on this topic.
One of the original tenants of the GPL is that when distributing modified copies, one must acknowledge that it is not the original work. Using trademark law to require folks to make it clear that their modified derivatives are not endorsed by the authors of the original software is an extension which is clearly in line with these principals.
How can we justify missions to Mars when kids are still going to bed hungry?
Because if we waited until no kids went to bed hungry, there'd never be missions to mars, and we as a society would be all the poorer for it. (Maybe we haven't profited much from the mars missions lately, except for a rekindling of public interest -- but look at all the advances in science the space program as a whole led to!)
If we waited until everyone was housed before providing wireless communications infrastructure (which is what these laptops do -- they set up massive-scale mesh networking even without cell towers available), the infrastructure would never get there.
Moreover, and more importantly, the communications infrastucture enables the folks who otherwise would be just recipients for handouts to better help themselves. Local businesses are easier to organize and run more efficiently with communication technology -- farmers and ranchers can run their affairs more profitably and effectively if they know where and when their products are needed -- and that in turn makes people better able to afford their own houses, infrastructure and so forth.
Finally, there's not a limited set of dollars and man-hours available for charity: People have their own causes they're interested in, and won't contribute as much or as effectively to others. Saying "why should anyone contribute to $FOO when there's still work for $BAR" overlooks this; both $FOO and $BAR can be done at once, and with more effective resource allocation than one would get if telling folks who would find $BAR interesting that they must contribute to/work on $FOO instead or do nothing at all.
Having computers will enable people to access information to educate themselves, and will allow them to establish communications necessary for a larger-scale economy (so that they can build their own infrastructure).
Think of it as a "give a man a fish" situation.
Medical equipment does nothing but increase the number of poor people. Schools are something, but people can teach anywhere, so long as they have knowledge to pass on and incentive to do so. Communications infrastructure, on the other hand -- that's useful.
It will end up like the tablet PC. A decent enough idea, but done poorly with bad software choices, and never achieve enough market to be effective.
There are niche markets (like doctors' offices) where tablet PCs make a very compelling value proposition. Are they ever going to compete with laptops? Of course not. Is there enough of a market to justify several companies (as opposed to "every company that does PCs and laptops") producing them? Absolutely.
The mini-PC phone may well end up in a similar position.