Smalltalk dispenses with text files; the language and the environment are inseparable. This allows for some of the really interesting features of the language, as it's always runtime, and you're working on live objects. Pharo is a nice version to try.
People don't listen to sad songs because it makes them sad; people enjoy sad songs. Tragic plays don't make you feel as if the tragedy had befallen you. And whether a war game is fun has nothing to do with whether war is fun.
Words are placeholders for concepts generally. The difference between using "fun" with Six Days in Fallujah and "fun" with Pac-Man is not a matter of the experience, but expedience.
You need a treatment or you'll die. How much are you willing to pay to stay alive? I'd pay everything that I have, because it does me no good when I'm dead. This doesn't depend on how much I have. In fact, I'd be willing to pay money I don't even have yet. This is why so many people go into debt to stay alive in the USA.
Assuming that there's only one person able to save my life, sure. Of course, that's not much of a market.
That one person is going to make a lot of money... so much that other people are going to want to be able to do what he does. Once there are a suitable number of people willing to save my life, I have choices, and the price will drop. We won't stay alive without food, either... and most of us would have difficulty doing so without housing. Markets are about supply and demand.
This glosses over a lot of important details, but so does the point being addressed. Possibly a good argument can be made that markets don't regulate health care well... but this isn't it. This argument doesn't address the most obvious free market predictions.
By the way, if there really is only one person who has the cure for your disease... be thankful he's there, and that you do have the choice to give him everything you have in return for saving you. You can still decide not to.
Tyrrany! The government of California is mandating things to... the government of California. One can only weep for those agile, efficient state agencies, hamstrung in their efforts to serve the public by the state legislature's document format demands.
Seriously, California's government is supposed to let each of its agencies choose (or not choose) its own standard for documents, so that one part of the government can't communicate with another? Talk about mediocrity.
As the article notes: "Clearly, jobs offshoring is not creating jobs in computers and information technology." Leaving aside that a great many jobs are (obviously) being created in other countries... why would we think offshoring IT jobs would create more IT jobs in the U.S.?
Those of us who herd bits for a living would do well to remember: we're an expense of someone else's business, whether that someone is buying our software or paying us to fix a database. At best, we help them be be more efficient, so we're worth the cost... but like everyone, we tend see what we do as an end, rather than as a means. If what we do becomes unnecessary, or if our customers can get a better deal on it from someone else, we're going to have to find something else to do... besides lamenting how horribly ungrateful and greedy our customers are.
Having reduced their expenses, a stable company might indeed be more profitable for a time. They might use the additional resources to grow, or their competitors, who have also seen their cost of doing business drop, might decide to push in on their market share, forcing them to drop their prices. Generally, windfalls don't last long. Meanwhile, a struggling company may become solvent, or we may pass the tipping point where a new venture becomes feasible.
Looking back, it's easy to see that people didn't need potters, they needed pottery. When we began to mass-produce tableware, it benefitted everyone but potters... why should we expect things to be different for coders, or other IT folk?
Jobs will be created in the U.S. because, in the aggregate, our non-IT firms become efficient, and because people wind up with more money to spend on other things. Just like when we stopped spending so much money fixing our Chryslers.
They just don't care because the current system minimizes their financial losses by transfering those losses to the individual who has his/her identity "stolen".
That's largely not the case. With credit cards in the USA, for instance: "By law, once you report the loss
or theft, you have no further responsibility for unauthorized charges. In any event, your maximum liability
under federal law is $50 per card." (Source).
While credit card fraud is not the only cause of finanical loss in cases of identity theft, it's certainly one of the biggest. That cost is, by my understanding, borne by the credit card companies, who pass it along to credit card users generally in the form of absurdly high interest rates. It's still a case where fixing the system would hurt revenue (in the short term, at least), but that's because credit cards are, to most people, such an important means of doing business that the interest rates are still not high enough to deter them.
In the case of debit cards, however, the cost is borne by the defrauded customer directly. Debit cards should, in theory, be more secure, as they have an associated private key; however the demand to have them function in the same capacity as credit cards has resulted in a situation where you don't need the PIN for many transactions, and you don't have the protection of a $50 liability cap either.
I don't think that seeing this as a winner-takes-all decision between formality and informality, on all levels, is helpful.
There is more to having an individual voice than preserving the mistakes in your writing... and, while I'm not suggesting
a copy editor is what's needed, a good copy editor should certainly distinguish between informal or incorrect usages
which express character and simple, distracting mistakes.
I don't think many of us would appreciate having the place become more formal, in substance, either. But to me, the tone
of the site is established by what you have to say, not by the artifacts of the typing process. It's less that I can't see
the meaning through a grammatical error, than that I don't see the value you seem to see in the grammatical error.
Taking these sorts of uninteresting mistakes as a major part of the character of the place seems, to me, unflattering to
what Slashdot really is.
As you say, though, "You are welcome to disagree.":-)
Likewise some submissions are simply a URL and a single sentence. Since I want my articles to be around the same size, this
is my chance to put in my own words. I'll try to add a joke or opinion. Or just a fact that I thought was worth sharing from
the article itself. It's often these phrases that comment posters get most up in arms about: irate readers commenting that
I should not be allowed to post my views.
It's not your only chance, though, to put in your own words. There's the discussion forum, too. For my part, I don't have
a problem with an editor editorializing, but the more it seems like a one-way line of communication, the worse it's likely
to be received. When I add my $0.02 to the forum, and someone offers thoughtful criticism, I often reply... either to defend,
or to stand corrected, or even to say that I regret that I don't have time to pursue the matter. This sort of interaction is
what makes a community.
The problem is the perceived attitude that we should be interested in the editors' opinions, while they have no interest in
ours. I don't think that's the actual attitude; editing is time-consuming as it is, and being an active participant in
the forum for each story you post isn't realistic. But if people come to expect that there will never be a
follow-up, they will have as little sympathy for the editors as people as they do for the talking heads on the evening news.
For this reason, I was particularly glad to see you begin this series of articles. I'd like to see Slashdot's culture change
for the better, and I think there's a good deal of potential for that to happen... but it'll require more interaction like
this. When the editors don't participate, they seem high-handed and aloof; when the users grow cynical about the editors,
they treat them harshly, and, to judge by appearances, create a siege mentality where the editors are even less likely to post.
I think that this touches upon a similar issue:
But back to the topic at hand, You are welcome to disagree with me on matters of grammar and spelling. And many of
you do, very vocally in the forums. I would hope moderators would see such commentary as offtopic. A story about a
new motherboard chipset has nothing to do with the proper use of "Its" and "It's".
Discussing spelling is often rather trivial (though really bad spelling errors can be hard to ignore), but it's a
particular case of something more interesting: discussing the article itself, and Slashdot, rather than the topic
of the article. People hold off-topic discussions about Slashdot because there's no actual forum for it... again,
creating the perception that the folks running the site don't care what the users think. I think this perception
is the single most damaging social problem, here; if it's not true, more's the pity.
Incidentally, while it's not a matter of great importance, I, for one, appreciate good grammar and spelling; it shows
that someone took some care. Perhaps it would be worthwhile to divide the tasks you're already performing: have some
people sifting the submissions, and choosing the stories, and have someone else editing the chosen submissions. The
person editing would deal with a much smaller volume of material, and could not only be a bit more careful, but also be
in a better position to recognize duplicates which got past the first person.
While I agree with your general reasoning, I think you miss an important point, also: we're already spending large amounts of money on putting things in space. Even leaving out the very practical things, like communications satellites, a good deal is spent on research. We'd be getting a heck of a lot more out of the money we're already spending if we had a permanent, effective human presence in space (or on the moon, et cetera).
The way I see it, your argument makes the most sense if we're considering whether to conduct this sort of research at all. Similarly, whether it's economically effective to keep humans in space to gather raw materials depends very much on whether those raw materials will be used on earth or in space. In the latter case, we need to compare the costs (including in-space manufacturing costs) to those of lifting manufactured goods from earth into space. From there, it's a matter of scale; putting people in space for the purpose has greater up-front costs and lower continuing costs, so (in theory) we'd eventually reach a break-even point, after which we'd save money.
That still may not be worth it. There are a lot of factors to consider, including, as you point out, the potential for technological advances in other fields to lower the up-front cost. There is also the potential to sell services to companies and other nations. It's a difficult question, and I suspect it's hard to answer without actually running numbers (which I am not knowledgeable enough to do).
Americans are giving $16.2 billion to NASA in 2005. Your post speaks very directly to whether that's a good idea or not, given the goal of eventually colonizing space. I don't think it's very applicable to the current situation, however, where we are supporting many short-to-mid term projects at what may be unnecessary expense. If the question is how to spend that $16.2B, putting the focus on a permanent presence may make sense.
"Children are playing a game that encourages them to have sex with prostitutes and then murder them," she said in a statement on the issue. "For that matter, we can't get Ted to stop playing, either."
A lack of standard configuration layout is another thing: why should people have to learn hundreds of config file formats? Yes, comments help, but it'd be nice if they weren't needed. Why not come up with one standard text-based config format/filesystem layout and get everyone to use it? This would also save programming time, as you could create a library (with a name like libconfig or something similar) and not have to worry about parsing configuration settings.
Splendid... I knew I could count on others to
make my favorite complaints for me.:-)
However let me suggest that much better than
a config format would be a config
API. This would have several
advantages, foremost of which would be allowing
us to avoid the nigh-impossible (and possibly
undesireable) task of getting everyone to agree to a single format. If you could drop in a config
file library of your choice, you could choose
XML, PropList, etc.
Or you could drop in something more esoteric,
like a PostgreSQL interface. Or a networking
library to make remote config access transparent.
Or something brilliant which hasn't occured
to me... the door is left open.
So long as the API is well-defined, it shouldn't
be any trouble to automatically translate from
one format to another, as well, when you decide
that you prefer something different. This would
again lower the barrier to innovation, since
it would be easy for users to try new things.
And, of course, you should be able to configure
where your config files reside, as well
as setting a naming convention for them. This
would be a nice step towards fixing the
filesystem layout problem, as well, since the config files would suddenly be much more mobile.
Not to mention that it'd allow me to
address a long-standing peeve of mine: dotfiles.
I really loathe having a home directory full of unsorted files which are, by default, invisible.
An ~/etc/ directory would be lovely.
Well, He is a candidate. Don't you think he should be in the debates?
I think you could make a reasonable libertarian argument that the answer to that question is 'no'.
After all, what are 'the debates'? An event which the Democrats and Republicans have agreed to hold. What obligation have they to invite other people? When Badnarik and Cobb agree to debate (as they have four times this campaign), can they not choose what others may participate?
Granted, this is a fairly shallow look at the question. Possibly what they're unhappy about is some direct government sponsorship of the Bush-Kerry debates; this would change matters, as seen from within the conceptual framework the Libertarians espouse. If this is their case, however, they seem not to be communicating it very well.
More a problem for the Libertarians than the Greens, in any case; I don't know of a Green principle which would bear directly on this question.
If Japanese (who is the largest majority foreign owner of US debt), and a bunch of other foreign investors asked for their money back, USA will collapse overnight.
No, it certainly wouldn't. First, not all debt can be called in at once; in fact, a lot of it can't at any given time. Nor, by the way, can most of it be paid at any given time, even if that were desired. Other forms of debt have early redemption penalties; assuming a great many Japanese investors simultaneously lost all confidence in their US Savings Bonds, they could indeed cash them, but they'd lose a significant amount of the interest calculated as part of our debt.
Second, why would the US choose to collapse over this? While the US government has never defaulted on a loan before, other governments certainly have, without collapsing. And defaulting certainly isn't the only option; the US could try to call in debt from other countries (of which there's quite a lot), or it could, in part or in whole, monetize the debt (ie. print more money).
Now, while these options all range from serious to dire, they're still far short of the collapse of the government.
Unlike the olden (is this even a word?:) ) days, the govt cannot give you anything of value for your money. Modern currencies are nothing more than paper with some trust attached to it. Once you lose the trust, it is worth nothing.
This is a half truth. Yes, people's confidence is basic to the value of money. But it always has been. There never were olden days where currency was backed on a 1:1 basis with physical commodities (though there were very (bad) olden days where physical commodities were used for currency). Even Great Britain, in the heyday of the gold standard, held a small amount of gold in reserve, relative to the currency it issued. Which means that if investor confidence failed, there could be a run on the banks.
In short, credit is a necessary part of a modern economy. Digging up gold over here, only to bury it again in vaults over there, and restricting the money supply to the amount that you've managed to dig, is just a bad idea. As is pinning your currency to the questionable worth of a particular metal.
From now on, when ever I want to know something about gecko feet, I'm coming to Slashdot. Maybe this should be a category.;-) (perhaps along with the various stories such as this one prophesying the coming of the übermice.
Unfortunately, none of the links work anymore... but if I recall correctly, one of the articles speculated about using the discovery for this kind of thing. So it's cool to see this actually pan out. Of course, they also speculated about armies of fire-fighting robot geckos...
Sure, Microsoft is doing this because they think
it's in their best interests to do so. They're
giving software to corporations which aren't a
big source of revenue for them anyway. Though
the article doesn't mention it, yes, they're
probably writing it off on their taxes. They're
also keeping a bunch of people on Windows who
might otherwise move to a free OS, which helps
keep their user base under them. And they look
good.
Do I doubt the motives of their largesse? Not
really... they're pretty clear. But what are
we trying to accomplish, here? In criticizing
this, the (free|open source) software world
simply looks bad.
Generally, society tends to be happy enough
when charitable contributions are made;
scrutinizing the donors for their motives
is just puritannical. If non-profits benefit,
according to their own definition of 'benefit',
that's good. Complaining about it allows writers
to lead articles with lines like "Even when
the Microsoft Corporation attempts to do good,
its critics distrust its motives," and discount
open source people as too partisan to be
taken seriously. "Michelle Murrain, a member
of the Nonprofit Open Source Initiative in
Amherst, Mass., says that if Microsoft gives
away Windows for a few years, nonprofit
groups may be less likely to use free,
open-source software." Great. We're
complaining about charity because it doesn't
benefit us.
On top of which, none of the arguments put forth
are particularly convincing. Murrain says, "Microsoft could throw in all this software for the next two years and then just stop and people will be hooked." Hooked. Okay. As if none
of these people had used Windows before.
Or as if companies with tight budgets will,
in two years' time, be willing to cough up
more than they are now, because they've become
hopeless Microsoft junkies in the interim.
And Michael Gilbert says, "As a monopoly, Microsoft's below-market-price distribution of software might very well be a form of illegal competition for a particular market."
Presumably he's indulging in a bit of
theoretical speculation, and doesn't really
lack the sense to foresee such a legal claim
promptly going down in a ball of flames.
Sometimes it seems that open source people
aren't satisfied with the prospect of beating
Microsoft... they're offended that Microsoft
isn't willing to simply roll over and die.
Or at least to provide a stationary target.
Better to pick our battles, and keep the focus
on all the good software being developed except
when there's really something to complain about.
On another note, is Perl 6 even going to be relevant with next-generation languages like Ruby and Python already fairly mature?;-)
If Perl6 goes according to plan, absolutely. In fact, it'll be particularly relevant to Ruby and Python.
More than any other thing, in my opinion, Perl has CPAN going for it. Other languages have tried similar code sharing projects, and none of them have come close to matching CPAN's breadth and (despite the occasional wonky module) usefulness.
More than any other thing, in my opinion, Java has the JVM going for it. Not that it's the only virtual machine out there, but it's the only one which really has broad distribution. The ability to distribute compiled bytecode, and to run it in a "sandbox", are two of Java's biggest selling points.
If Perl6 succeeds, neither of these languages will keep their greatest advantages. Perl6 is merely to be a Parrot compiler... and where Sun has actively tried to keep other languages off of the JVM, the Parrot developers want to entice other languages onto the Parrot. Any languages rewritten to target the Parrot, then, should (given some hooks, perhaps) be able to take advantage of the CPAN modules which are the wealth of the enormous Perl community.
To the extent that Perl6 succeeds, Python, Ruby, Scheme, O'Caml, and who-knows-what other languages stand to find themselves able to "write once, and run anywhere". Potentially, this could lower the bar for new and interesting languages to compete, since they'd primarily be competing as languages, with the runtime environment issues (more or less) abstracted away. In the same way that Mozilla allowed for today's proliferation of browsers, Parrot could be a very good thing for languages.
But while Perl6's progress will certainly be relevant, in the long term it risks obsolescence by virtue of its own ambitions. Frankly, if that were the case, I don't think it'd bother Larry all that much... however the Perl community doesn't seem to be ready to go gentle into that good night. A lot of Perl6's remarkably ambitious agenda seems to me an effort to stave off the possibility of the danger that Perl will become a victim of its own, and Parrot's, success.
When you hit a key on a keyboard, you generate
a scancode. A scancode isn't a tilde, or a
scroll lock, it's a smidgin of data... where
a smidgin is often equal to one byte, but
sometimes not. There's a passel of details
about the particulars, where a passel is
equal to way too damned much for such an
apparently simple tool, but they're not
directly important to this discussion.
Which is good, because I only ever knew
a dollop of details, and I've forgotten
several smidgins of that.
The thing is, given a capable operating system,
those scancodes can mean what you want them
to mean. Vi guys, for example, often remap
Caps Lock to mean Esc. Caps Lock, then, can
be remapped to someplace where it belongs...
a footpedal locked in a closet, for instance.
Linux is capable. Mostly. Configuring keys
in Linux isn't much fun, in my opinion. The
files are obscure, things are handled
differently in X than they are at the console,
and different users can't have different
keymaps (correct me... please! I'd love to be
wrong). You can also botch things up, if
you're not careful, and find the changes
difficult to undo since you tend to want
to use the keyboard to undo them.
Configuration under OSX is easy, as
you'd expect, and I don't know about other
Unixen or Windows.
Anyway, keyboards don't need to change so
far as this goes. It's a software issue.
It would be nice if the software changed,
and it became easier for the average user
to remap as he saw fit. It would be nice
as well if keyboards weren't so damned
cheap, these days, and came with real
keycaps like the
classics did. You know, the little
plastic key covers, which can either be
rearranged or replaced with unusual or
custom-printed ones.
My guess is, keyboard layouts aren't going to
change much for a good, long time. For the
great majority of users, there's no reason
to change them.
What I personally wish we'd see,
and what I'm confident we won't see, in
the 21st century, are keyboards with more
keys. Real keys, generating real
scancodes... the
programmable ones with extra keys
generally just use the extra keys to send
sequences of scancodes normally generated
by the other keys. That's very handy if
you're unable to to configure things on
the computer side... but the computer always
should be the flexible, configurable
part of a setup. Ultimately, having more
scancodes at your fingertips is a better
solution (unless you're one of those Happy
Hacker minimalists).
And the smallest errors cause the greatest confusion,
when unsound reason yields the best conclusion.
The consequences of legislation to require
government agencies to purchase (Open Source|Free) software may
be good or bad; I don't wish to make a case for either at the moment.
I do think, however, that both Mr. O'Reilly's reasoning, and that of
his correspondent, are flawed, and that both characterize the
issue badly.
Government agencies are not individuals, with freedoms we regard
as inherently worth protecting. Nor do they spend their own
money; they spend the money of the people they serve, which in
most cases is provided for them by the legislature representing
those people.
When the mystery correspondent characterizes these laws as
"criminalizing an official' s decision to buy commercial software",
and when Mr. O'Reilly characterizes them as the "deprivation of
the user's right to choose", they suggest that the people entrusted
with the administration of these agencies have some right to spend
tax money in the way that they see fit. They do not. Nor is having
the legislature hand down policies on what goods agencies acquire
anything like having the legislature forbid individuals to write
or use P2P software (a comparison made by O'Reilly in the discussion
forum). This is not about whether, how, and to what extent the
government should regulate the software industry. This is about
one way in which the Legislative branch checks
the Executive branch.
O'Reilly's pragmatic points, though underdeveloped, are more
interesting. Perhaps this is a matter of legislative
micro-(mis)management. Perhaps these constraints would
seriously impede the ability of many agencies to fulfil their
responsibilities. Perhaps this would open up a fight with
software corporations that we don't want, or can't win.
I'd much rather Mr. O'Reilly had developed these, as I think
his argument from principle falls down flat. If we took it
seriously, we'd have Congress able to give money to agencies,
without any say in how the money was spent. Unelected officials
without constraints on their spending isn't what most people
mean by 'political freedom'.
In the interests of helping to spare our
beloved Monastery further merciless
Slashdotting, here is the whole of tilly's
post:
This post is somewhat long, so I would like to start
by saying that this is very much relevant to PerlMonks
even though it is not about Perl or programming. It
is also very relevant to CPAN, perl, and the broader
open source community. This is about aspects of being
an employee which generally get ignored, and really,
really, really shouldn't be.
I will talk about New York State's laws, since that is
what I know best. However in discussions with legal
types it appears that New York's provisions are not
unusual, and therefore what I say is applicable in some
way to most of the US, and likely in many other countries
as well. I should also disclaim at this point that I am
not a lawyer, nor is this legal advice. But
the general outline of what I am saying has been verified
to me by both lawyers, and people who are merely
interested in the legal profession. I have also been
told that this is bound to become a huge issue for the
open source world.
Enough advertising.
In New York State there are three basic classes of
employee:
Hourly employee: If you show
up at work, punch a clock, and are paid overtime, then
you are an hourly employee. Factory workers are commonly
hourly employees. As an hourly employee the company owns
the hours you are at work, and has no other claim on you.
I believe it is uncommon for programmers to be hourly
employees.
Contract worker: In this case you are working
per defined contracts. The work you do on that contract
is (barring specific contract provisions saying otherwise)
owned by the company that has hired you. They have no
claim on your time or energy when you are not working on
the contract. Many programmers work this way. But if you
are (for instance) hired by a consulting company to work at
clients, then your employment with that consulting company
is not contract work, see the next option.
Professional employee: This is the rest of us.
Professional employees have employment that is not defined
by a clock or by a contract. In fact under the law their
productive output belongs to their employer, 24x7, 365 days
a year (366 on leap years). It is customary for these terms
to also be spelled out in employment contracts very clearly,
though truth be told most people read these, sign them, and
have never given the contents of those contracts much in the
way of thought.
This brings me to intellectual property law. Intellectual
property law in general assigns the rights to intellectual
property to the creator of an idea, work, or implementation.
That creator gains delimited control of their creation. In
theory the reason for this is to encourage potential
creators to create new things, and for them to pass into
the public domain. Or at least this was the reasoning that
Thomas Jefferson used (and he got it from French thought on
copyrights), though the reality in this century has not
matched theory very well.
But who is the creator?
One would think that the creator of a work is the author,
the person who actually produces it. But the realities of
life are not so simple. What if one person conceives of an
idea, and then gets multiple people to implement it? Is it
owned by the implementers, or the person who thought it
possible and paid for it to be done?
The legal resolution is the doctrine of a work for hire.
A work for hire is a work that you produced for someone else,
and they own all rights to any potential intellectual property
that might arise from that work. (Including, obviously, both
copyrights and patents.)
Now what happens if you combine these two legal areas?
The answer is unambiguous both in theory and practice. All
work covered under your employment terms belongs to your
employer. In the case of professional employees, this is
everything. If you go home and write something on the
weekend, you do not own it. You might be unaware of this
issue and naively put a copyright notice on it, then
distribute it. That was your mistake.
Now let me make this personal.
I am a professional employee. I signed a routine employment
contract while I was still pretty much of a novice as both a
programmer and an employee. As is common, 6 months later I
had completely forgotten about the terms of the contract and
was blissfully unaware of the laws I live under.
My bad.
Over the course of this job I have slowly become more and
more involved in open source work. I write software for fun
and release it. I have put code into posts here, released
stuff on CPAN, and even contributed a core perl module. All
of which I thought I had the right to do, but as it turns
out none of which I did. There isn't even a legal issue to
contest, I simply didn't know better.
My very bad.
As of today here is the status. This came up from an
incidental issue about a month ago. I have been told that
if I wish to continue being employed, I cannot post code.
If I continue being employed, then I will be admonished for
the code I have released so far. If I leave my employment
then the decision about what happens with any and all of the
code of mine that people here have seen is not mine.
(Stupid comment removed.)
I live in NYC. It seems likely that my wife is going to have
no option about moving any significant distance for at least
a year. I am carefully considering my employment options. I
have a likely job prospect near Philadelphia which
would allow me to work on open source stuff. That is farther
than I want to commute, and the pay cut would be painful,
plus it does not resolve the other issues. I have not
seriously searched for any potential jobs which are closer.
Now my food for thought for everyone is this. How many more
people are in the same position I am, and are not aware of it?
How much open source software has been put out there by
authors who thought they owned rights that they do not? If
you are an employee, are you one of them?
These are, as I have just learned, extremely non-hypothetical
questions.
UPDATE
There is, considering the circumstances, only one choice for
me to make which is not abysmally moronic. Do not expect to
hear much from me in the future.
But, regardless, stick to criticizing features, not attitudes.
Rather ironic, don't you think? The bulk of your post concerns itself with criticizing an attitude.
For my own part, I don't hold with your views. Running free software is important to me, and to others; to some people, that sort of criticism is interesting. By all means, choose according to your values. Even criticize other people's attitudes; as long as things remain civil, that's what public debate is about.
But stick to criticizing attitudes, not criticizing people for criticizing attitudes.
You don't really need a programming language to do this... nor do I see that the existence of such a language would help all that much. Now a markup language... that's a different story. I still don't think the barrier's that great, but it'd be good to have the capability. And XML fits the bill here. Declare the right character set, and you're off and running.
Of course, browsers really aren't there yet... but things do look promising. Mozilla supports XML -- to a certain, rather limited, extent -- and I'm told that IE does too. CSS is not implemented in Unicode, however, so you'd have a heck of a time adding presentation information to Chinese markup, particularly in Chinese. But then there's XSL. Which is not there yet either, but seems like it will be in time. If not quickly, in much less time than it'll take for a significant portion of a billion Chinese folks to get PCs.
While on the topic, though, a localized mainstream programming language would be nice, too. We wouldn't want to keep people from leveraging their micro-marketed e-commerce solutions with the data warehousing of feedback from dynamic interactive e-communities just because they write Sanskrit, would we?
To do this, you'd really need to have a language with native unicode support. You'd want to be able to change operators and keywords to native glyphs, mutating their syntax along the way. The language itself might be more useful as well if you could overload or override the builtins, as well as define your own operators, subs, and what-have-you.
Overall, sounds like Perl6.
Which can be a good or a bad thing, depending on your perspective... oddly, not everybody likes chaos and mayhem... but it fits the bill. After all, Larry continually jokes about turning Perl into APL...:-)
It has been pointed out more than once in the replies to this question that those who write free software often do so to "scratch an itch". There's a lot of truth in this. But it's not such a valid reason for a paucity of free software for the disabled.
Jouke Vissier's pVoice is an outstanding example of creative itch scratching. pVoice allows people who cannot speak to synthesize speech by means of a grapical interface. It's written in Perl, free for personal use, and runs on both Windows and Unix systems.
And, interestingly, it's entirely the work of one dedicated hacker, written primarily for the benefit of his own daughter.
Slashdot Mirror
Smalltalk dispenses with text files; the language and the environment are inseparable. This allows for some of the really interesting features of the language, as it's always runtime, and you're working on live objects. Pharo is a nice version to try.
People don't listen to sad songs because it makes them sad; people enjoy sad songs. Tragic plays don't make you feel as if the tragedy had befallen you. And whether a war game is fun has nothing to do with whether war is fun.
Words are placeholders for concepts generally. The difference between using "fun" with Six Days in Fallujah and "fun" with Pac-Man is not a matter of the experience, but expedience.
Moral hazard.
Assuming that there's only one person able to save my life, sure. Of course, that's not much of a market.
That one person is going to make a lot of money... so much that other people are going to want to be able to do what he does. Once there are a suitable number of people willing to save my life, I have choices, and the price will drop. We won't stay alive without food, either... and most of us would have difficulty doing so without housing. Markets are about supply and demand.
This glosses over a lot of important details, but so does the point being addressed. Possibly a good argument can be made that markets don't regulate health care well... but this isn't it. This argument doesn't address the most obvious free market predictions.
By the way, if there really is only one person who has the cure for your disease... be thankful he's there, and that you do have the choice to give him everything you have in return for saving you. You can still decide not to.
Tyrrany! The government of California is mandating things to... the government of California. One can only weep for those agile, efficient state agencies, hamstrung in their efforts to serve the public by the state legislature's document format demands.
Seriously, California's government is supposed to let each of its agencies choose (or not choose) its own standard for documents, so that one part of the government can't communicate with another? Talk about mediocrity.
As the article notes: "Clearly, jobs offshoring is not creating jobs in computers and information technology." Leaving aside that a great many jobs are (obviously) being created in other countries... why would we think offshoring IT jobs would create more IT jobs in the U.S.?
Those of us who herd bits for a living would do well to remember: we're an expense of someone else's business, whether that someone is buying our software or paying us to fix a database. At best, we help them be be more efficient, so we're worth the cost... but like everyone, we tend see what we do as an end, rather than as a means. If what we do becomes unnecessary, or if our customers can get a better deal on it from someone else, we're going to have to find something else to do... besides lamenting how horribly ungrateful and greedy our customers are.
Having reduced their expenses, a stable company might indeed be more profitable for a time. They might use the additional resources to grow, or their competitors, who have also seen their cost of doing business drop, might decide to push in on their market share, forcing them to drop their prices. Generally, windfalls don't last long. Meanwhile, a struggling company may become solvent, or we may pass the tipping point where a new venture becomes feasible.
Looking back, it's easy to see that people didn't need potters, they needed pottery. When we began to mass-produce tableware, it benefitted everyone but potters... why should we expect things to be different for coders, or other IT folk?
Jobs will be created in the U.S. because, in the aggregate, our non-IT firms become efficient, and because people wind up with more money to spend on other things. Just like when we stopped spending so much money fixing our Chryslers.
While credit card fraud is not the only cause of finanical loss in cases of identity theft, it's certainly one of the biggest. That cost is, by my understanding, borne by the credit card companies, who pass it along to credit card users generally in the form of absurdly high interest rates. It's still a case where fixing the system would hurt revenue (in the short term, at least), but that's because credit cards are, to most people, such an important means of doing business that the interest rates are still not high enough to deter them.
In the case of debit cards, however, the cost is borne by the defrauded customer directly. Debit cards should, in theory, be more secure, as they have an associated private key; however the demand to have them function in the same capacity as credit cards has resulted in a situation where you don't need the PIN for many transactions, and you don't have the protection of a $50 liability cap either.
I don't think many of us would appreciate having the place become more formal, in substance, either. But to me, the tone of the site is established by what you have to say, not by the artifacts of the typing process. It's less that I can't see the meaning through a grammatical error, than that I don't see the value you seem to see in the grammatical error. Taking these sorts of uninteresting mistakes as a major part of the character of the place seems, to me, unflattering to what Slashdot really is.
As you say, though, "You are welcome to disagree." :-)
It's not your only chance, though, to put in your own words. There's the discussion forum, too. For my part, I don't have a problem with an editor editorializing, but the more it seems like a one-way line of communication, the worse it's likely to be received. When I add my $0.02 to the forum, and someone offers thoughtful criticism, I often reply... either to defend, or to stand corrected, or even to say that I regret that I don't have time to pursue the matter. This sort of interaction is what makes a community.
The problem is the perceived attitude that we should be interested in the editors' opinions, while they have no interest in ours. I don't think that's the actual attitude; editing is time-consuming as it is, and being an active participant in the forum for each story you post isn't realistic. But if people come to expect that there will never be a follow-up, they will have as little sympathy for the editors as people as they do for the talking heads on the evening news.
For this reason, I was particularly glad to see you begin this series of articles. I'd like to see Slashdot's culture change for the better, and I think there's a good deal of potential for that to happen... but it'll require more interaction like this. When the editors don't participate, they seem high-handed and aloof; when the users grow cynical about the editors, they treat them harshly, and, to judge by appearances, create a siege mentality where the editors are even less likely to post.
I think that this touches upon a similar issue:
Discussing spelling is often rather trivial (though really bad spelling errors can be hard to ignore), but it's a particular case of something more interesting: discussing the article itself, and Slashdot, rather than the topic of the article. People hold off-topic discussions about Slashdot because there's no actual forum for it... again, creating the perception that the folks running the site don't care what the users think. I think this perception is the single most damaging social problem, here; if it's not true, more's the pity.
Incidentally, while it's not a matter of great importance, I, for one, appreciate good grammar and spelling; it shows that someone took some care. Perhaps it would be worthwhile to divide the tasks you're already performing: have some people sifting the submissions, and choosing the stories, and have someone else editing the chosen submissions. The person editing would deal with a much smaller volume of material, and could not only be a bit more careful, but also be in a better position to recognize duplicates which got past the first person.
As a token of gratitude for such fine charitable work, I think it'd be nice to put a link to Penny Arcade itself in the story. :-)
The way I see it, your argument makes the most sense if we're considering whether to conduct this sort of research at all. Similarly, whether it's economically effective to keep humans in space to gather raw materials depends very much on whether those raw materials will be used on earth or in space. In the latter case, we need to compare the costs (including in-space manufacturing costs) to those of lifting manufactured goods from earth into space. From there, it's a matter of scale; putting people in space for the purpose has greater up-front costs and lower continuing costs, so (in theory) we'd eventually reach a break-even point, after which we'd save money.
That still may not be worth it. There are a lot of factors to consider, including, as you point out, the potential for technological advances in other fields to lower the up-front cost. There is also the potential to sell services to companies and other nations. It's a difficult question, and I suspect it's hard to answer without actually running numbers (which I am not knowledgeable enough to do).
Americans are giving $16.2 billion to NASA in 2005. Your post speaks very directly to whether that's a good idea or not, given the goal of eventually colonizing space. I don't think it's very applicable to the current situation, however, where we are supporting many short-to-mid term projects at what may be unnecessary expense. If the question is how to spend that $16.2B, putting the focus on a permanent presence may make sense.
"Children are playing a game that encourages them to have sex with prostitutes and then murder them," she said in a statement on the issue. "For that matter, we can't get Ted to stop playing, either."
However let me suggest that much better than a config format would be a config API. This would have several advantages, foremost of which would be allowing us to avoid the nigh-impossible (and possibly undesireable) task of getting everyone to agree to a single format. If you could drop in a config file library of your choice, you could choose XML, PropList, etc.
Or you could drop in something more esoteric, like a PostgreSQL interface. Or a networking library to make remote config access transparent. Or something brilliant which hasn't occured to me... the door is left open.
So long as the API is well-defined, it shouldn't be any trouble to automatically translate from one format to another, as well, when you decide that you prefer something different. This would again lower the barrier to innovation, since it would be easy for users to try new things.
And, of course, you should be able to configure where your config files reside, as well as setting a naming convention for them. This would be a nice step towards fixing the filesystem layout problem, as well, since the config files would suddenly be much more mobile. Not to mention that it'd allow me to address a long-standing peeve of mine: dotfiles. I really loathe having a home directory full of unsorted files which are, by default, invisible. An ~/etc/ directory would be lovely.
I think you could make a reasonable libertarian argument that the answer to that question is 'no'.
After all, what are 'the debates'? An event which the Democrats and Republicans have agreed to hold. What obligation have they to invite other people? When Badnarik and Cobb agree to debate (as they have four times this campaign), can they not choose what others may participate?
Granted, this is a fairly shallow look at the question. Possibly what they're unhappy about is some direct government sponsorship of the Bush-Kerry debates; this would change matters, as seen from within the conceptual framework the Libertarians espouse. If this is their case, however, they seem not to be communicating it very well.
More a problem for the Libertarians than the Greens, in any case; I don't know of a Green principle which would bear directly on this question.
No, it certainly wouldn't. First, not all debt can be called in at once; in fact, a lot of it can't at any given time. Nor, by the way, can most of it be paid at any given time, even if that were desired. Other forms of debt have early redemption penalties; assuming a great many Japanese investors simultaneously lost all confidence in their US Savings Bonds, they could indeed cash them, but they'd lose a significant amount of the interest calculated as part of our debt.
Second, why would the US choose to collapse over this? While the US government has never defaulted on a loan before, other governments certainly have, without collapsing. And defaulting certainly isn't the only option; the US could try to call in debt from other countries (of which there's quite a lot), or it could, in part or in whole, monetize the debt (ie. print more money).
Now, while these options all range from serious to dire, they're still far short of the collapse of the government.
Unlike the olden (is this even a word?
This is a half truth. Yes, people's confidence is basic to the value of money. But it always has been. There never were olden days where currency was backed on a 1:1 basis with physical commodities (though there were very (bad) olden days where physical commodities were used for currency). Even Great Britain, in the heyday of the gold standard, held a small amount of gold in reserve, relative to the currency it issued. Which means that if investor confidence failed, there could be a run on the banks.
In short, credit is a necessary part of a modern economy. Digging up gold over here, only to bury it again in vaults over there, and restricting the money supply to the amount that you've managed to dig, is just a bad idea. As is pinning your currency to the questionable worth of a particular metal.
Unfortunately, none of the links work anymore... but if I recall correctly, one of the articles speculated about using the discovery for this kind of thing. So it's cool to see this actually pan out. Of course, they also speculated about armies of fire-fighting robot geckos...
Do I doubt the motives of their largesse? Not really... they're pretty clear. But what are we trying to accomplish, here? In criticizing this, the (free|open source) software world simply looks bad.
Generally, society tends to be happy enough when charitable contributions are made; scrutinizing the donors for their motives is just puritannical. If non-profits benefit, according to their own definition of 'benefit', that's good. Complaining about it allows writers to lead articles with lines like "Even when the Microsoft Corporation attempts to do good, its critics distrust its motives," and discount open source people as too partisan to be taken seriously. "Michelle Murrain, a member of the Nonprofit Open Source Initiative in Amherst, Mass., says that if Microsoft gives away Windows for a few years, nonprofit groups may be less likely to use free, open-source software." Great. We're complaining about charity because it doesn't benefit us.
On top of which, none of the arguments put forth are particularly convincing. Murrain says, "Microsoft could throw in all this software for the next two years and then just stop and people will be hooked." Hooked. Okay. As if none of these people had used Windows before. Or as if companies with tight budgets will, in two years' time, be willing to cough up more than they are now, because they've become hopeless Microsoft junkies in the interim.
And Michael Gilbert says, "As a monopoly, Microsoft's below-market-price distribution of software might very well be a form of illegal competition for a particular market." Presumably he's indulging in a bit of theoretical speculation, and doesn't really lack the sense to foresee such a legal claim promptly going down in a ball of flames.
Sometimes it seems that open source people aren't satisfied with the prospect of beating Microsoft... they're offended that Microsoft isn't willing to simply roll over and die. Or at least to provide a stationary target. Better to pick our battles, and keep the focus on all the good software being developed except when there's really something to complain about.
If Perl6 goes according to plan, absolutely. In fact, it'll be particularly relevant to Ruby and Python.
More than any other thing, in my opinion, Perl has CPAN going for it. Other languages have tried similar code sharing projects, and none of them have come close to matching CPAN's breadth and (despite the occasional wonky module) usefulness.
More than any other thing, in my opinion, Java has the JVM going for it. Not that it's the only virtual machine out there, but it's the only one which really has broad distribution. The ability to distribute compiled bytecode, and to run it in a "sandbox", are two of Java's biggest selling points.
If Perl6 succeeds, neither of these languages will keep their greatest advantages. Perl6 is merely to be a Parrot compiler... and where Sun has actively tried to keep other languages off of the JVM, the Parrot developers want to entice other languages onto the Parrot. Any languages rewritten to target the Parrot, then, should (given some hooks, perhaps) be able to take advantage of the CPAN modules which are the wealth of the enormous Perl community.
To the extent that Perl6 succeeds, Python, Ruby, Scheme, O'Caml, and who-knows-what other languages stand to find themselves able to "write once, and run anywhere". Potentially, this could lower the bar for new and interesting languages to compete, since they'd primarily be competing as languages, with the runtime environment issues (more or less) abstracted away. In the same way that Mozilla allowed for today's proliferation of browsers, Parrot could be a very good thing for languages.
But while Perl6's progress will certainly be relevant, in the long term it risks obsolescence by virtue of its own ambitions. Frankly, if that were the case, I don't think it'd bother Larry all that much... however the Perl community doesn't seem to be ready to go gentle into that good night. A lot of Perl6's remarkably ambitious agenda seems to me an effort to stave off the possibility of the danger that Perl will become a victim of its own, and Parrot's, success.
When you hit a key on a keyboard, you generate a scancode. A scancode isn't a tilde, or a scroll lock, it's a smidgin of data... where a smidgin is often equal to one byte, but sometimes not. There's a passel of details about the particulars, where a passel is equal to way too damned much for such an apparently simple tool, but they're not directly important to this discussion. Which is good, because I only ever knew a dollop of details, and I've forgotten several smidgins of that.
The thing is, given a capable operating system, those scancodes can mean what you want them to mean. Vi guys, for example, often remap Caps Lock to mean Esc. Caps Lock, then, can be remapped to someplace where it belongs... a footpedal locked in a closet, for instance.
Linux is capable. Mostly. Configuring keys in Linux isn't much fun, in my opinion. The files are obscure, things are handled differently in X than they are at the console, and different users can't have different keymaps (correct me... please! I'd love to be wrong). You can also botch things up, if you're not careful, and find the changes difficult to undo since you tend to want to use the keyboard to undo them. Configuration under OSX is easy, as you'd expect, and I don't know about other Unixen or Windows.
Anyway, keyboards don't need to change so far as this goes. It's a software issue. It would be nice if the software changed, and it became easier for the average user to remap as he saw fit. It would be nice as well if keyboards weren't so damned cheap, these days, and came with real keycaps like the classics did. You know, the little plastic key covers, which can either be rearranged or replaced with unusual or custom-printed ones.
My guess is, keyboard layouts aren't going to change much for a good, long time. For the great majority of users, there's no reason to change them.
What I personally wish we'd see, and what I'm confident we won't see, in the 21st century, are keyboards with more keys. Real keys, generating real scancodes... the programmable ones with extra keys generally just use the extra keys to send sequences of scancodes normally generated by the other keys. That's very handy if you're unable to to configure things on the computer side... but the computer always should be the flexible, configurable part of a setup. Ultimately, having more scancodes at your fingertips is a better solution (unless you're one of those Happy Hacker minimalists).
when unsound reason yields the best conclusion.
The consequences of legislation to require government agencies to purchase (Open Source|Free) software may be good or bad; I don't wish to make a case for either at the moment. I do think, however, that both Mr. O'Reilly's reasoning, and that of his correspondent, are flawed, and that both characterize the issue badly.
Government agencies are not individuals, with freedoms we regard as inherently worth protecting. Nor do they spend their own money; they spend the money of the people they serve, which in most cases is provided for them by the legislature representing those people.
When the mystery correspondent characterizes these laws as "criminalizing an official' s decision to buy commercial software", and when Mr. O'Reilly characterizes them as the "deprivation of the user's right to choose", they suggest that the people entrusted with the administration of these agencies have some right to spend tax money in the way that they see fit. They do not. Nor is having the legislature hand down policies on what goods agencies acquire anything like having the legislature forbid individuals to write or use P2P software (a comparison made by O'Reilly in the discussion forum). This is not about whether, how, and to what extent the government should regulate the software industry. This is about one way in which the Legislative branch checks the Executive branch.
O'Reilly's pragmatic points, though underdeveloped, are more interesting. Perhaps this is a matter of legislative micro-(mis)management. Perhaps these constraints would seriously impede the ability of many agencies to fulfil their responsibilities. Perhaps this would open up a fight with software corporations that we don't want, or can't win.
I'd much rather Mr. O'Reilly had developed these, as I think his argument from principle falls down flat. If we took it seriously, we'd have Congress able to give money to agencies, without any say in how the money was spent. Unelected officials without constraints on their spending isn't what most people mean by 'political freedom'.
In the interests of helping to spare our beloved Monastery further merciless Slashdotting, here is the whole of tilly's post:
This post is somewhat long, so I would like to start by saying that this is very much relevant to PerlMonks even though it is not about Perl or programming. It is also very relevant to CPAN, perl, and the broader open source community. This is about aspects of being an employee which generally get ignored, and really, really, really shouldn't be.
I will talk about New York State's laws, since that is what I know best. However in discussions with legal types it appears that New York's provisions are not unusual, and therefore what I say is applicable in some way to most of the US, and likely in many other countries as well. I should also disclaim at this point that I am not a lawyer, nor is this legal advice. But the general outline of what I am saying has been verified to me by both lawyers, and people who are merely interested in the legal profession. I have also been told that this is bound to become a huge issue for the open source world.
Enough advertising.
In New York State there are three basic classes of employee:
- Hourly employee: If you show
up at work, punch a clock, and are paid overtime, then
you are an hourly employee. Factory workers are commonly
hourly employees. As an hourly employee the company owns
the hours you are at work, and has no other claim on you.
I believe it is uncommon for programmers to be hourly
employees.
- Contract worker: In this case you are working
per defined contracts. The work you do on that contract
is (barring specific contract provisions saying otherwise)
owned by the company that has hired you. They have no
claim on your time or energy when you are not working on
the contract. Many programmers work this way. But if you
are (for instance) hired by a consulting company to work at
clients, then your employment with that consulting company
is not contract work, see the next option.
- Professional employee: This is the rest of us.
Professional employees have employment that is not defined
by a clock or by a contract. In fact under the law their
productive output belongs to their employer, 24x7, 365 days
a year (366 on leap years). It is customary for these terms
to also be spelled out in employment contracts very clearly,
though truth be told most people read these, sign them, and
have never given the contents of those contracts much in the
way of thought.
This brings me to intellectual property law. Intellectual property law in general assigns the rights to intellectual property to the creator of an idea, work, or implementation. That creator gains delimited control of their creation. In theory the reason for this is to encourage potential creators to create new things, and for them to pass into the public domain. Or at least this was the reasoning that Thomas Jefferson used (and he got it from French thought on copyrights), though the reality in this century has not matched theory very well.But who is the creator?
One would think that the creator of a work is the author, the person who actually produces it. But the realities of life are not so simple. What if one person conceives of an idea, and then gets multiple people to implement it? Is it owned by the implementers, or the person who thought it possible and paid for it to be done?
The legal resolution is the doctrine of a work for hire. A work for hire is a work that you produced for someone else, and they own all rights to any potential intellectual property that might arise from that work. (Including, obviously, both copyrights and patents.)
Now what happens if you combine these two legal areas?
The answer is unambiguous both in theory and practice. All work covered under your employment terms belongs to your employer. In the case of professional employees, this is everything. If you go home and write something on the weekend, you do not own it. You might be unaware of this issue and naively put a copyright notice on it, then distribute it. That was your mistake.
Now let me make this personal.
I am a professional employee. I signed a routine employment contract while I was still pretty much of a novice as both a programmer and an employee. As is common, 6 months later I had completely forgotten about the terms of the contract and was blissfully unaware of the laws I live under.
My bad.
Over the course of this job I have slowly become more and more involved in open source work. I write software for fun and release it. I have put code into posts here, released stuff on CPAN, and even contributed a core perl module. All of which I thought I had the right to do, but as it turns out none of which I did. There isn't even a legal issue to contest, I simply didn't know better.
My very bad.
As of today here is the status. This came up from an incidental issue about a month ago. I have been told that if I wish to continue being employed, I cannot post code. If I continue being employed, then I will be admonished for the code I have released so far. If I leave my employment then the decision about what happens with any and all of the code of mine that people here have seen is not mine. (Stupid comment removed.)
I live in NYC. It seems likely that my wife is going to have no option about moving any significant distance for at least a year. I am carefully considering my employment options. I have a likely job prospect near Philadelphia which would allow me to work on open source stuff. That is farther than I want to commute, and the pay cut would be painful, plus it does not resolve the other issues. I have not seriously searched for any potential jobs which are closer.
Now my food for thought for everyone is this. How many more people are in the same position I am, and are not aware of it? How much open source software has been put out there by authors who thought they owned rights that they do not? If you are an employee, are you one of them?
These are, as I have just learned, extremely non-hypothetical questions.
UPDATE
There is, considering the circumstances, only one choice for me to make which is not abysmally moronic. Do not expect to hear much from me in the future.
Rather ironic, don't you think? The bulk of your post concerns itself with criticizing an attitude.
For my own part, I don't hold with your views. Running free software is important to me, and to others; to some people, that sort of criticism is interesting. By all means, choose according to your values. Even criticize other people's attitudes; as long as things remain civil, that's what public debate is about.
But stick to criticizing attitudes, not criticizing people for criticizing attitudes.
Of course, browsers really aren't there yet... but things do look promising. Mozilla supports XML -- to a certain, rather limited, extent -- and I'm told that IE does too. CSS is not implemented in Unicode, however, so you'd have a heck of a time adding presentation information to Chinese markup, particularly in Chinese. But then there's XSL. Which is not there yet either, but seems like it will be in time. If not quickly, in much less time than it'll take for a significant portion of a billion Chinese folks to get PCs.
While on the topic, though, a localized mainstream programming language would be nice, too. We wouldn't want to keep people from leveraging their micro-marketed e-commerce solutions with the data warehousing of feedback from dynamic interactive e-communities just because they write Sanskrit, would we?
To do this, you'd really need to have a language with native unicode support. You'd want to be able to change operators and keywords to native glyphs, mutating their syntax along the way. The language itself might be more useful as well if you could overload or override the builtins, as well as define your own operators, subs, and what-have-you.
Overall, sounds like Perl6.
Which can be a good or a bad thing, depending on your perspective... oddly, not everybody likes chaos and mayhem... but it fits the bill. After all, Larry continually jokes about turning Perl into APL...
Jouke Vissier's pVoice is an outstanding example of creative itch scratching. pVoice allows people who cannot speak to synthesize speech by means of a grapical interface. It's written in Perl, free for personal use, and runs on both Windows and Unix systems.
And, interestingly, it's entirely the work of one dedicated hacker, written primarily for the benefit of his own daughter.