Date: 2008-07-25 10:12:51
(Author: trav)
Link:
http://travis.kroh.net/archives/005055.php
It's a class war, stupid
This is why you need to pay careful attention when you hear about John McCain claiming that he's going to "look at entitlement program" waste as a means of solving the budget crisis, or when you tune into the debate about the "death tax." We are in the midst of a political movement to concentrate private wealth into fewer and fewer hands while at the same time placing more and more of the burden for public expenditures on working people. If that sounds like half-baked Marxian analysis... well, shit, what can I say? That's what's happening. Repealing the estate tax (the proposal to phase it out by the year 2010 would save the Walton family alone $30 billion) and targeting "entitlement" programs for cuts while continually funneling an ever-expanding treasure trove of military appropriations down the befouled anus of pointless war profiteering, government waste and North Virginia McMansions — this is all part of a conversation we should be having about who gets what share of the national pie. But we're not going to have that conversation, because we're going to spend this fall mesmerized by the typical media-generated distractions, yammering about whether or not Michelle Obama's voice is too annoying, about flag lapel pins, about Jeremiah Wright and other such idiotic bullshit.
Just a touch on the sensationalistic side, and certainly a biased, albeit accurate, essay, this kind of critique will most certainly be ignored by anyone who has influence necessary to correct the outlined problems. The bit about our country's insolvency is particularly urgent, in my opinion, but is currently either ignored or completely unknown to the public in general. It's entirely possible that within my lifetime we'll have a significant number of American economic refugees to other countries as the government moves well into the realm of a working capital deficit (based on the GDP). Seriously! Our GDP is about $13.86 trillion and our current national debt is about $9.53 trillion. Our current debt is damn near 70% of our GDP. That's some scary shit. Meanwhile, people cast votes for national office based on trivialities like stem cell research.
Date: 2008-07-22 09:41:23
(Author: trav)
Link:
http://travis.kroh.net/archives/005054.php
Dear Parallels,
We've been together for a long time, but I think we both know that inertia is the only thing keeping us going now, and has been for a while. You were really nice at first, and I enjoyed how special you were. You enabled me to do things I hadn't ever been able to do before. At first, I was really excited to have you since you had a great reputation and my friends liked you so much. We were a great couple, but there are some things that novelty can't mask forever, and it's about time we face our differences.
First and foremost, you don't feel right for me. I ignored it at first, but your behavior is just too different from the rest of my applications. None of my other apps are so needy as to abandon me if I don't constantly have an active window open. They understand that just because they don't have my complete attention doesn't mean I won't want to talk to them at all. Sometimes I just want to access menu options without you starting a huge VM instance.
And options are another thing. It's fine if you want to start a VM as soon as it's opened. And it's okay if you want to close a VM as soon as it's stopped. I'm okay with that if we've agreed on that configuration beforehand. But if it's going to be like that, you can't tell me that our "configuration cannot be changed" once we've already started. You can't expect me to have the same thing all the time every time. Sometimes I want to do something different, but I can't talk about configuration before, and I can't talk about it during, and then when we're done you just leave! And don't even give me that crap about your memories not being big enough--it's not always about that. Sometimes I want to try a new device, or...
I just wish you were more flexible about my needs, okay?
I know you've been with a lot of Windows users before, but I'm different, and it's time you faced that. You need to decide if you can deal with my interface idioms or not, and you need to do it soon, because I'm not going to wait around forever while you spend all your time oogling that server market. Either you start concentrating more on me, or maybe I won't be so fast to dismiss VMware when she flashes her pretty hypervisor at me. I'll have you know that I've seen VirtualBox around quite a bit, too! What do you think of that? And she doesn't even expect me to pay for licensing!
I'm sorry if this seems sudden, but I've been denying these feelings for over a year now, and it's time you woke up and took a good look at my host OS, because if you don't, you just might find yourself uninstalled.
Sincerely,
trav
Date: 2008-07-19 22:21:41
(Author: trav)
Link:
http://travis.kroh.net/archives/005052.php
Recently, I wanted to play a short .aiff file as a little alarm every 15 minutes. On the Mac, however, there isn't a built-in analog to the play command that ships with most Linux distros. I did a quick search and came up mostly empty, except for a little app called PlayBufferedSoundFile written by Kurt Revis, an apple engineer, intended as a code example for using CoreAudio. Unfortunately, the API has changed such that the technique used in the code example is deprecated, and the code doesn't even compile anymore.
Fortunately, Kurt turned me on to a code example that's included with the new version of Xcode that does exactly this.
The dev tools come with sample code for a tool called "afplay" that can probably do what you want.
Open this in Xcode:
/Developer/Examples/CoreAudio/Services/AudioFileTools/AudioFileTools.xcodeproj
Build the "afplay" target and there you go.
"There you go" indeed. Thanks, Kurt.
Date: 2008-07-17 12:27:27
(Author: trav)
Link:
http://travis.kroh.net/archives/005051.php
I was installing Zend Platform on our development server today, and got an error for which I couldn't find very much information.
Our development server's configuration matches our production server's config as much as possible (as it should), and I've locked down our production server pretty hard, which includes a disable_functions directive of "dl, shell_exec, exec, system, passthru, popen" in php.ini in order to prevent PHP scripts from running external executables or making system calls.
Evidently this doesn't jive well with Zend Platform, but there's no documentation about why.
So, for the benefit of the intarwebs, the following functions are not to be included in the disable_functions directive if you wish to use Zend Platform:
The other directives I was using are apparently okay (not that Zend bothers to mention it anywhere).
Date: 2008-07-15 13:54:55
(Author: trav)
Link:
http://travis.kroh.net/archives/005050.php
Microsoft's Ballmer Opens Up to Partners
Will we encourage people who want to do open-source development to do it on top of Windows? Yes, we're proud that the best PHP system in the world is actually the one that runs on Windows today, not the one that runs on Linux.
WTF is he talking about?
No, really; I can't at all figure out what he's talking about. I don't really know what would constitute a "PHP system", and I certainly can't offhand guess what the "best [one] in the world" is.
Date: 2008-07-11 10:26:44
(Author: trav)
Link:
http://travis.kroh.net/archives/005048.php
Critics Say Army Recruiters Using Technology To Target Adolescents
According to army recruiters the technology creates a life-sized combat zone.
The experience takes approximately a half-hour and participants can drive vehicles and shoot machine guns on their mission.
Up to 50 players can use the simulator at one time.
"They get an actual like pre-convoy briefing just like anybody in the Army would be getting prior to going out on a mission. Once the mission is done, then they also get a post briefing," explained David Boe, Director of Public Relations for the Duluth Air and Aviation Expo.
Awesome. I wanna play.
Date: 2008-07-07 09:27:55
(Author: trav)
Link:
http://travis.kroh.net/archives/005047.php
The Grand Negus of The Osmosian Order of Plain English Programmers speaks.
I received the following message a few days ago...
Dear Travis,
Was that you who recently wrote the following about our site?
[quoted blog post]
If so, and if you're interested, I'd like to try to clear up some of your misunderstandings about our work. Write me.
Sincerely,
Gerry Rzeppa
Grand Negus, The Osmosian Order of Plain English Programmers
Curiosity and unwillingness to let such an opportunity slip by, I offered for him to fire away, as long as everything said was fair game for publishing. To be fair, I did give him a heads-up that he was facing an uphill climb. I dutifully reminded him "that you engaged me in this conversation, so it's on you to convince me that your philosophy isn't naïve and the resulting programming language/environment isn't useless for practical purposes; this is my current opinion."
Round 1
Our work is important for two reasons.
(1) It presents a credible challenge to a number of preconceived and virtually unassailable notions that, we believe, need questioning. The program works - conveniently and efficiently - without icons, radio buttons, scroll bars, dialog boxes, tear-off palettes, objects, nested ifs, nested loops, artificial syntax, and a variety of other commonplace gadgets and constructs. At worst, that should rank it in the "surprising" category. At best, "an example to emulate." We, in our typically modest way, usually say something like, "thought provoking" or "worthy of study."
(2) It parses language as, we believe, humans do. Chomsky spent years investigating rigid syntax definitions for natural languages and, in the end, gave up. The reason for his failure, we believe, is that natural languages have no rigid syntax, nor do they need one -- if the approach one takes to "understanding" a sentence is not based primarily on the meaning of the words in that sentence, but on whether or not a "precompiled routine" for handling that kind of sentence exists or can be quickly assembled in the listener's mind.
Consider. A six month old knows what a bottle is, and knows how to suck on one; in other words, he has a noun in his head by his left ear (attached to an appropriate but sketchy picture on the other side of his brain), and a compiled routine near the back of his neck labeled "suck bottle." Now when daddy says, "Hey, Chuckles, want to suck on your bottle a bit?" the child hears only "blah, blah, blah, blah, suck, blah, blah, bottle, blah, blah" but responds, properly, by executing the only routine in his head that comes close to "matching" that sentence. Had daddy said, "Bottle suck" the same result would follow, since word order isn't important to a six-month-old, and even "Bottle" or "Suck" all by themselves would probably work -- because there's only one routine with either of those words available. But as he is taught new sentences -- note that I say taught, not "as he learns" -- his discrimination increases; not because anything structural has changed, but because he simply has more nouns and more routines to choose from. It's slightly more complicated than this, of course, but I think it illustrates the major differences in our approach: (a) we consider a sentence "understood" when it is matched to an appropriate, pre-compiled routine, and (b) we'll settle for a "sloppy" match when a better one can't be found.
Our compiler implements this algorithm - with extensions, type reductions, and a handful of keyword markers (articles, prepositions, conjunctions) to allow for recursive, phrase-by-phrase substitutions - to match sentences with the intended routines. It has proven itself in practice to be a simple, efficient, and remarkably (some would say, suprisingly) reliable approach.
Now I know we're not talking "genius" like Einstein here; but I do think we are talking genius in the style of Henry Ford -- genius that, instead of attempting to calculate how many gallons an oddly-shaped fuel tank might hold, simply fills it with water and then empties the water into gallon jugs while counting (with small integers). It's not magic, but it is a different, simpler, and -- from what we've seen and done -- very effective way of thinking.
And so, as you examine our work, please keep three things in mind:
(1) The product is NOT intended for isolated self-study. Both the program and the documentation are designed to provoke questions and discussion. So when anything strikes you as unusual, strange, or just plain stupid, ask: help@osmosian.com. We have at least three good reasons for everything that we put in there, and we're more than happy to tell you what they are.
(2) The product is intentionally different -- iconoclastic is the term we use. It is designed to make the programmer question almost every preconceived notion a modern practitioner might have. Are installation programs necessary? Can a high-level language like English be used to conveniently write low-level programs like compilers? Can a workable interface be designed without icons, scroll bars, radio buttons, and a wide variety of other widgets? Can complex programs be clearly and concisely written without nested ifs and loops? Can a polymorphic drawing program be effectively programmed without objects? And so forth.
(3) The product is serious stuff, in spite of our tongue-in-cheek presentation. We really believe in our unique and deceptively simple approach to natural language parsing. And we really do think this approach will provide a firm foundation for computers like the HAL 9000 sometime in the not-too-distant future. Our next step is to install the compiler on a dedicated machine where all previously compiled code will be resident at all times. We will then extend that machine's compiler to accept and rank additional and even alternative defintions and routines submitted by a group of dedicated Plain English programmers who will continue to "teach" it new things over a period of years. Our hope is to recruit 100 such teachers who will each explain 10 things to the machine every day, so that at the end of just three years, our "apparently intelligent"(tm) machine will understand and properly respond to more than a million natural language sentences. There's more to it, of course, but that's the gist. And yes, it's a bit of a "brute force" approach. But very much like the one we all use with our human children!
You can get the most recent Plain English compiler here: www.osmosian.com. Less than a megabyte. Note that. Just download and unzip it. This is the complete product. No further installation is required. Note that too. Start with the PDF in the "documentation" directory and before you go ten pages you'll be reading the instructions using the built-in page editor and recompiling the thing in itself. In less than three seconds. Note that as well.
If you're serious, it really helps if you take the time to print off the first 54 pages of the manual, and actually type in the sample program. I know this sounds tedious and even childish, but it is the best way to get a feel for Plain English programming and our spartanly simple development environment.
The Meek and Patient Negus of the Osmosian Order of Plain English Programmers
And I countered.
1) There are a great many things about contemporary interface design
that need work. What you're trying to do was described fairly well by
Donald Norman in his book "The Psychology of Everyday Things" where he
described the difference between "knowledge in the head" and
"knowledge in the world". A problem faced by any sufficiently complex
system is how to make the available complexity accessible. Immediate
options are:
A) Invent metaphors and teach others how to use them (knowledge in
the head). This is the approach taken by most enterprise software
which typically is sold with instructional documentation and on-site
training bundled in with the product. It is also the easiest cop-out
for the developer.
B) Utilize as many assumed-existing metaphors as you can (knowledge in
the world). If you create something that utilizes the same metaphors
people use in day-to-day life, they should be able to recognize them,
and begin using the system intuitively. This is more difficult, but is
generally regarded as the ideal.
C) Reduce complexity. No need to make the complexity easy to use if
the system isn't sufficiently complex.
Your approach appears to primarily use option C with acknowledgment of
awareness of option B. The usability still needs a great deal of work
(due mostly to interface bugs) but essentially relies on the lack of
any advanced features in order to make the system approachable. Keep
in mind that there's nothing wrong with that--there are a great many
software titles that flourish under the "do one thing and do it well"
mantra--just as long as there aren't claims that the product is trying
to be something it isn't. Unfortunately, you refer (in your manifesto)
to your compiler as an integrated development environment--which it is
not. It provides significantly less functionality than, say, TextPad,
which makes no claim to be an IDE, and would face a serious uphill
battle to try to argue otherwise. If the lack of functionality is due
to it being a work in progress, then (in addition to the question of
charging $100 for an incomplete product) you are sure to find the the
trade-off between complexity and usability to become more and more
strained.
After listing various interface widgets you also tack on several
language constructs and structures that your product finds no use for.
Among these are objects, nested ifs and nested loops. I refer you to
the myriad of procedural languages that live without objects (I assume
you're well aware that COBOL tried the "close to natural language" bit
in the 60s) and functional languages that eschew straight iteration in
favor of recursion.
So, my summarized response to item 1 below is that while your ideas
are "worthy of study," they are neither "surprising" nor "worthy of
emulation" due to your being about about fifty years late to the
party.
With respect to your comment on parsing: natural language processing
is one of the most difficult problems facing computer science. Your
approach is neither novel nor appropriate for this problem area. One
of the inescapable first things one must learn prior to really
understanding any science is the idea of ambiguity. Until artificial
intelligence surpasses our own intelligence (at which time there will
be no need for us to write software anyway), ambiguity will not be
correctly tolerated by machines. The fact that your philosophy tries
to "brute force" a faked tolerance of ambiguity by pre-programming a
preferred interpretation of it is self-defeating in that respect.
Natural languages do not need a rigid syntax because people tolerate
this ambiguity (with often costly results when the ambiguity is
incorrectly resolved) in favor of expressiveness. This feature forms
the basis of jokes: amusing variations in parsing the ambiguity of
language. What forms jokes in natural language is what forms
incorrectness in software. Any effort to overcome this without first
disproving Turing's groundwork is naively wasted effort. The goal of
more recent prgramming languages is to increase expressiveness while
maintaining precise expression; Python and Ruby are making feeble
inroads to this end, but almost everyone has their own subjective
opinion on which language is most "expressive."
All in all, your language is a trivially amusing esoteric
implementation, but it is betrayed by your delusions of grandeur. My
unsolicited advice to you is to stop taking yourself so seriously, and
you might be taken more seriously. (LOLCODE enjoys a fairly decent
mind share in this way.)
In closing, you've demonstrated enough that I am forced to assume
you're at least mildly aware of the work that has come before you, but
either your literature review was drastically incomplete, or you are
willfully ignorant of it. I look forward to your reply to find which
of those two fit.
-trav
Unfortunately, the Grand Negus turned out to be more meek than patient.
Round 2
Travis,
I'm thinking the gulf between us is too wide to bridge. It is apparent that our journalistic standards, our programming principles, our short- and long-term goals, our way of doing business, and even our sense of humor are all quite foreign to you. It's also quite clear that you're not at all impressed with our "proof of concept" product. So I strongly suspect that pursuing the matter further, especially in this polemic style, will not be fruitful.
Thank you for your time and effort.
The Old and Weary Negus of the Osmosian Order of Plain English Programmers
Pity. I would have expected him to have more spirit than that, considering he's had some experience trying to defend his ideas to a tough crowd.
Date: 2008-07-02 13:26:02
(Author: trav)
Link:
http://travis.kroh.net/archives/005046.php
Scott Brown's Nostalgorithm for Pop-Culture Sensations
According to our formula, the proper release date for this X-Files movie is 2018 — not 2008.
Interesting, but what he overlooks is that an early release and an optimal release are not mutually exclusive. Aside from the fact that you can just wait ten years to watch the movie, it makes sense from a studio's financial POV as well. Most of the profits on a movie are from post-theatrical release (currently, this means DVD) properties, which means the financial take of the X-Files movies will be less influenced by poor performance at the box office as long as the DVD sales are strong (either now, or ten years from now). What they have now that they won't have ten years from now are actors. Probability of the interest (and ability) of Duchovney/Anderson to participate in this movie decreases rapidly with age. So, we have a high urgency to make the movie for logistical reasons, and the financial incentive is compatible with an earlier-than-optimal release. By these powers combined, we have the movie now.
