Sandler: I'm sorry everybody, I'm too preoccupied to do anything but stuffing my face with twinkies while I work all day and night. I don't want to spend time with my parents, Julie Kavner and Henry Winkler, or my wife and kids. My son will never notice if I show up late to his swim meet. But hey - my dog likes humping things! IT'S FUNNY! Also, I need a universal remote control because I'm a feeb. I have a great idea, I'll buy one at Bed, Bath, and... BEYOND!
(And the cat's in the cradle and the silver spoon...)
Walken: Before you take this I have some very grave warnings. Sandler: Uh-huh, yeah. I'm gonna fast-forward through this part. Oh, no! I'm missing my own life!
(...little boy blue and the man in the moon...)
Sandler: Oh my god! I'm fat! I'm old! I'm divorced! Chris Walken is really mean! My dog died and they got another dog who also humps things! It's still funny! I guess being fat is automatically funny, too! I mean, fat suits are always funny. It was funny in Mrs. Doubtfire and in the Eddie Murphy version of "The Nutty Professor" and so this will be every bit as funny. But the remote keeps fast-forwarding past stuff even though I don't want it to! How come rewind doesn't let me do-over, but fast-forward puts the remote in control of all my life decisions? Isn't that a little bit of a disparity? Oh, I know, it's a metaphor for my life, wrapped up in a tidy plot device that lets me explore difficult concepts without having to really face them in the story.
(...when ya comin' home dad? I don't know when, we'll be together then...)
Sandler: And as I hung up the phone, it occurred to me, he'd grown up just like me! My boy was just like me! I want to take it all back! Jacob Marley, you were right! Clarence, it is a wonderful life! Son, don't be a douche like your dad! Spirit, assure me that I yet may change these shadows you have shown me, by an altered life!
(dooblie-dooblie-dooblie...)
Sandler: It was all a dream... OR WAS IT? Young man, what day is it today? Kid: Why, it's Christmas day, sir! Sander: Oh, joy of joys. Buy a big fat turkey. "Click", perhaps! It'll be on DVD before you know it. My dog is still humping things! AND IT'S STILL FUNNY! I'm going to yell at my wife so I can pull a switcheroo! It's heartwarming, except that I'm still basically yelling at my wife... I'm going to pile up all the lessons I've learned into an incoherent ball and throw them at everybody I see so they think I'm a mental case! I'm gonna call Julie Kavner and Henry Winkler! Henry's coin trick will continue to be the core of our father-son relationship!
All I can say is that almost all of the text of the joke is from various online Klingon phrasebooks - so Google is your friend.
It's pretty much the kind of "Klingons on Uranus" joke one would expect, though. The kind that probably doesn't make sense unless you translate it to English first.:)
OK, let's suppose you were to have a standard "date" and didn't pay. You might think this is just dandy, perfectly fine business but in fact the hooker probably has some associates who would be willing to break your kneecaps for that money. So from that perspective, paying hookers is definitely good for business.
Money for Nothing would be outstanding. One of the great 80s rock songs, with an excellent guitar riff. Makes me think of the (now cheesy) video. Who wouldn't want to play that on Guitar Hero? That video was always cheesy. Cheesiness isn't measured on an inverse relative scale of technical merit, it's based on effect...
'Would be cool to have that big dude from the video as an unlockable character, though, for sure - all 20 polygons of him.
There's one example of real world evidence I know of: Japan.
Pornography in Japan really doesn't have many limits except simply the censoring of genetalia. While fringe, there is easily available and obtained media of simulated rape, public exposure & sexual activity, sexualized streaking. In the fiction world there are lots of animated and printed works that very obviously depict additional rape, child sex (consentual and non), incest, disfiguring and nonconsentual S&M and human bondage. Hell, just look through Somethingawful's articles on hentai games and you'll see japanese interactive games that let you live out fantasies of banging your younger underage sister. And another one where you literally stalk and rape victims from a train.
And yet, Japan enjoys the lowest rates of sex crimes of all 1st world countries. I'd say the ability for an individual to safely vicariously explore deeper and more sinister fictional sexual practices (as defined by society-at-large) definitely prevents a significant number of real crimes with real victims. Well, see, that's because all the new Hentai videos now have a disclaimer at the end - after your 40 minutes of being entertained by animated rape, you're told that "rape is bad, don't rape people". That clears everything up.
Though, I'm not sure you've accounted for the Densha Chikan types - groping on a crowded train is a real problem in Japan.
Darth Xenu (Warrior Princess) has got nothin' on good ol' Archangel Foster. Fosterites don't need no stinkin' California Law to protect them - the "Spirit In Action League" is ready to come to town and bust some heads...
I brought it up to show a double standard. Burning a flag that has Allah inscribed on it is a crime. Burning a Bible is not. Dropping a koran in a toilet is a "hate crime". Dropping a cross in urine is not. Giving Muslim students a ham sandwich is a hate crime (reprehensible, sure. But a crime?), making a video game where the object is to kill as many "Jesuses" as possible is OK in the state of California, that has this law.
See my point here? Point being, you want to play the victim?:) "There, there. Poor you. You and your religion are treated so badly and no one cares at all."
Don't worry about it. Christians are much more holy when they're being persecuted. Just remember the wise lessons the Amish teach us: "A local boy kicked me in the butt last week - I just smiled at him, and I turned the other cheek. I really don't care, in fact I wish him well - 'cause I'll be laughing my head off when he's burning in hell."
Well, most religions don't require you to pay to learn the religious texts. Donations and the like are "heavily encouraged" but not required. Well, the marks won't pay attention if it's free...
What if you need to call 911, and some strange app crashes your phone? See, that's Apple's excuse - the reason they give so that customers will feel the decision makes sense for them. The actual reason they don't want the platform to be open is because they want to retain control. They don't want, for instance, users to install some video player that would reduce iPhone users' dependence on iTunes video service.
And, you know what, I have a Treo. I don't need "some strange app" to crash my phone, the built-in Treo software does a pretty good job of that already. It sucks how that happens. But you know what the answer is? When your phone crashes, you wait for it to reboot (about 15-20 seconds) and you call again. Sure, you don't want that happening in a real emergency situation, but if it did, there are effective ways of dealing with the problem.
In space, no one can hear bacteria scream Yeah, real funny - but think of the poor Xenomorphs, would ya? How is a facehugger supposed to latch on to a bunch of bacteria, huh?
Reminds me of the time when Luke Skywalker destroyed the Death Star, when he was asked if he wanted a new droid to replace the busted R2D2, he outright refused! (Actually, he was offered the replacement droid before he sortied... When R2 was still functional but "banged up".)
What the techs didn't tell Luke was that this repair required replacing much of R2's outer casing, as well as fused logic and memory units, with parts from a similar droid. They basically murdered someone else's droid so they could resurrect Luke's.
And then, there was the subtler matter of whether this "new" R2-D2 was even the same droid. It's kind of a philosophical question. They retrieved as much of R2-D2's data store as they could from the original modules, of course, and according to the specs the replacement parts they used should be equivalent to the parts that were damaged. And, of course, they did simple things like make sure that after the repair R2 still recognized the same designation, as well as his established relationships with others - property of Luke, partner of C-3PO, etc. But it'd really be more accurate to call the repaired R2-D2 a new droid, created from parts of a wrecked droid and a scrapped droid.
As for Luke - R2-D2 could be considered stolen property (the fact that this property stole itself, or that they assumed the Jawas weren't selling them stolen goods - and perhaps even the fact that his owner was killed by Vader, and that any heirs may likely have been killed when Alderaan was destroyed - changes little) - but assuming no relations of Captain Antilles were interested in making such a claim, R2-D2 was Luke's property by virtue of the transaction with the Jawas. So it's not as though R2-D2 was the property of the rebel alliance to begin with. The X-Wing fighter Luke left at Cloud City may be another matter, however...
Dude, you totally rock. I love your response. It's a perfect criticism and I love the delivery - with just a hint of sarcasm at the end to drive the point home. It's a pity you posted anonymously - but I don't hold that against you.
The person I was replying to suggested that there was no "universally agreed syntax for objects" - which is true. The point I was trying to make (and not making well) was that such a format doesn't need to be "universally agreed" upon, standardized, or pre-existing. If we want progress and have a good idea of what form we want that progress to take, we can build new systems as necessary.
As for creating a new format - if none of the existing ones are really suitable it's the way to go. The plan for the format is based on three key features. First is the ability to wrap established data types for identification. Second is the provision of an adequate set of data types (numbers, text, lists, tables, structures, and objects) to allow information to be expressed in a generic manner. Third is versatile streaming order of data, to allow more versatile pipelines. A metaformat that provides significantly more than that is overkill. A specific format that provides less than that is inadequate.
As for my assertion that no existing formats meet my needs - well, it's an assumption, really. I'm trying to be sure that it's the right conclusion. This means research. But defining a new and compact format that I know is well-suited to what I'm trying to do may be more productive than hunting for one that might be well-suited to what I'm trying to do.
It's quite possible that I could accomplish what I want in some binary encoding of XML - or, rather, use the assumption of an XML encoding as the outermost "layer" of the data as a way to reliably communicate the fact that the contents are in this new format I want to produce - that would have the advantage of playing nicely with all the code out there that looks for XML, at least. It's sort of like going to China knowing no phrases in Mandarin or Cantonese other than "the rest of what I am about to say is in Esperanto." - but that is the whole idea here - tell whoever's listening what language the speaker is speaking - whether that language is PDF, XML, MP3, whatever. I'm not sure if I would want to go that specific route, however.
Access the gui? Why, did somebody strand a bunch of functionality in "the gui" where scripts can't access it?
Nah, nobody would ever be that stupid.
Heh. Actually, I think almost everybody was "that stupid".
MacOS started out as a system that was built from the ground-up with the assumptions of their GUI (hence, filesystem supporting things like forks and resources and a formal notion of type IDs for files) - it has since switched to a more hybrid approach - retaining some of that (including the HFS filesystem) but mostly for backward compatibility - new Mac stuff is designed for lesser assumptions about the filesystem so that the OS will work on HFS but also play nice with other filesystems.
Windows doesn't really have a distinct notion of what defines the "GUI environment" and what defines the "Command-line environment" - the whole system is built around the assumption that the GUI is running on a display somewhere. The underpinnings are reasonably modern and getting better - though filename extensions are still used to infer types, and if you were to consider Windows versions of bash or cmd.exe to be the "Windows command-line environment" then the separation in terms of concepts and functionality is pretty severe. But then you've got powershell, of course, which is like a somewhat Unix-ish shell (mainly in the general concepts of the prompt, the PATH, the filesystem, and command structures like piping) but deeply rooted in Windows technology and style - perhaps the system with the least "split personality disorder" between the text interface and the graphical one, surprisingly.
And then there's Linux. The GUI is being built up as a sort of mimicry of Mac and Windows, with a few old-school X-isms thrown in for good measure - Gnome and KDE each include their respective scripting interfaces (ORBit and dcop, currently) but the components that make up Gnome or KDE are often considered separate from the system - people still write X apps that aren't integrated into or compliant with either environment, and I think many people don't like to incur those dependencies for fear of over-complicating their program or limiting it to just the people who use that particular environment to begin with - so neither system is treated like an assumption, it's strictly an add-on and largely self-contained within its community. Straight X apps and console apps tend to make very few assumptions beyond the POSIX-like system call environment and filesystem, the standard C library, and the terminal or X server. Few projects outside of GNOME or KDE projects assume the presence of an object broker or any particular RPC or IPC mechanism, let alone the more advanced concepts these frameworks implement, such as scriptable application interfaces, data exchange, and so on.
Put simply, it's my contention that on Linux, the GUI frameworks are creating an environment which, from the point of view of the command shell, is fiction - an elaborate facade built on top of machinery that is adequate for the task, but not well tailored to it. What I advocate is not necessarily that these technologies be embraced to create a more specialized shell environment (after all, the changes in Gnome and KDE are a little unsettling if it's stability you're after - KDE dumping CORBA in favor of their dcop system - Gnome possibly dumping CORBA in favor of Mono in the future - apart from the fact that people often don't want these technologies to be a part of the basic assumptions on their system, the technologies simply haven't settled to the point that this is practical...) - but rather a shell environment with sufficient powers of expression and representation to be able to interact well with these technologies. What's missing is the ability for the shell to host and exchange "objects" (meaning, pieces of data - not even necessarily in an OO sense) that have specific requirements for managing their "lifetime" (code to be called when the data is copied or deleted, for instance) Beyond that, wha
The "repeating pattern" is that as people encounter specific problem domains, they devise tools that are particularly suited to solving the problems. LISP could possibly encapsulate everything everywhere - maybe - but as a language LISP isn't as nice for interactive shell sessions as bash, it's not as efficient for expressing text processing problems as Perl, it's not as well suited to exploring and expressing a wide variety of object concepts as Python, etc.
The problem is, LISP can't nicely encapsulate all these different, domain-specific data formats. That's why domain-specific solutions exist in the first place. But, maybe more to the point, it doesn't. Even if it could, it doesn't. There's a big difference between something being possible and something existing as a readily-available solution. Yes, it's possible that a modern system could be built entirely around LISP. It might not be a bad idea. But unless such a system exists, that's meaningless. So who cares? Either write this environment, and prove its greatness, or else kindly acknowledge that while you think a system revolving all around LISP would be dandy, you have nothing more than idle speculation to base that on.
Did LISP in 1958 unify data transfer between digital audio applications, 3-D mesh editors, bitmap and vector graphics editors, word processors, video codecs, and spreadsheets? Of course not. Maybe things have gone downhill since then - if you prefer to think of it that way - and we're just now starting to reintroduce common communication formats back into computing. Whatever - I wasn't even born in 1958. Object-oriented command shells are, as far as I'm concerned, a nice improvement over command shells I've used in the last fourteen years since I started using PCs, so even if you somehow consider this thing a reinvention of LISP (seems like more than a bit of a stretch to me) it's still progress over the current state of affairs.
Anyone else wonder what this means? I guess the question is, where do those leave you unsatisfied? To my knowledge, these (cygwin, active perl, etc) integrate with all features of windows...including, but not limited to, native features like COM objects.
So what basis in fact does this statement have, if any? Sounds like Microsoft-funded propoganda. From my perspective, the limit is in the extent to which the shell works to support data exchange between programs.
Why does the shell need to support data exchange between programs? Well, that's the whole idea between Unix pipes. Bash supports text streams (or rather, byte streams commonly assumed to be textual) between processes, and that's it. And that could be enough - given a universally respected set of conventions on how to format and identify datatypes. So if ActivePerl gets some nice chunk of data out of a running GUI application, and at bash you're trying to pipe that data output into something else - there's a rather cumbersome process of turning that Perl data into a raw bytestream and turning it back into useful data again. The complexity of this problem depends on the complexity of the data - and bash's willful ignorance of the significance of the data that goes between processes means that it can't help in any way.
What's specifically missing is shell-level support for interacting with GUI applications at the same level that ActivePerl is capable of. Bash's support for datatypes isn't sufficient to make it a good way to interface with scriptable applications.
A statement like "but those only get you so far" is a bit vauge - but I think I can see the point.
Well, that's good to know: the thing is, the versatility of the shell in approaching different problems is of more interest than the specific operations that are made convenient. You've demonstrated that changing the extensions of files is a bad example - because the "ren" command provides a convenient means of doing that. Whether Bash's flexibility is compensation for insufficient specialization for common operations - or whether cmd's specializations are compensation for insufficient power in the command language is kind of debatable, and largely a matter of opinion.
But the power and versatility demonstrated in the Bash example - the ability to evaluate a substitution inline, mainly - I think that was the point of that post. We want to know what the equivalent to that is. There's bound to be some other case where an inline substitution would be handy - a case in which maybe CMD doesn't offer any specialized tool for the job.
Too complicated and confusing, you have to made up all the "common language" and the interface between programming languages becomes more complex than the code for the problem you are actually trying to solve.
This is the reality of the world - if you want a meaningful, useful interface to your C or C++ module it's going to be a bit of work. Unless, of course, an automated tool like SWIG can do the job nicely for you. I've written Python and Guile bindings for C++ modules I've written in the past - it's a pain in the ass. But what you get for your effort is a version of your module that's transparent, interactive, and self-documenting. Very helpful for fiddling around and testing. Binding to something like CORBA or.NET is roughly the same idea. Languages like C#, Java, and others are designed to make this kind of thing easier by formally adopting ideas of what constitutes a module and how function definitions are exported.
Uh, so yeah. Sometimes doing things is hard. But that doesn't automatically make them bad ideas.
Text is easy to parse and backwards compatible, and if you organize it cleverly, it can represent objects (XML!)
I have a co-worker who would certainly take exception to the assertion that "Text is easy to parse". His primary job around here is writing and maintaining... a parser.:) There are programs that do nothing but attempt to make the job of parsing text easier (lex and yacc, for instance) and still it's a difficult problem.
Text can be easy to parse - if it's that way by design. The same could as easily be true of binary formats, however. Text is a lot easier to handle in current shells, however, because current shells were designed for dealing in text. It's a bit of a self-fulfilling premise. We have less, grep, awk, sed, perl, emacs, and so on - those are the tools that are making text such a convenient format to work with. It's not naturally easy to work with, we've just designed our shell environment around it, thus making it easy. A well-designed environment based on the idea of structured data would also be "easy" once implemented - but it would also be more powerful.
XML could certainly be a candidate for an interchange format between processes - though maybe not the best one. Consider, for instance, Unix pipes. One of their nice features is that the first command in the pipe need only generate as much data as the second command in the pipe is willing to read. For instance:
> primes | head -100 | tail -10
will not run forever. Most likely the "primes" process will generate more primes than "head" is looking for - but it won't run forever (or even until it hits the largest prime number it's capable of calculating) - once it is known that "head" is finished processing its input, "primes" will stop generating new values.
Now, this also applies if you're feeding XML data over the pipe, naturally. But suppose you had a process that was generating two sequences of values - and you wanted to stop processing after the first 100 of each sequence. I don't know enough about XML to know if there are established ways of representing that kind of operation - but there's no communication from the second command about what values it's waiting for from the first command, so the first command will most likely just generate the whole first sequence, then the whole second sequence - processing can't be finished until the first process has generated the entire first sequence.
Add to that the fact that XML (In my opinion, anyway) basically negates one of the main claimed advantages of text formats - the ease of (human) reading/writing, and processing them - it's a basic consequence of a non-trivial data format, really. XML can be edited in a program like Emacs, of course, but Emacs isn't necessarily the best tool for the job. Often, it'd be more preferable
Slashdot Mirror
Sandler: I'm sorry everybody, I'm too preoccupied to do anything but stuffing my face with twinkies while I work all day and night. I don't want to spend time with my parents, Julie Kavner and Henry Winkler, or my wife and kids. My son will never notice if I show up late to his swim meet. But hey - my dog likes humping things! IT'S FUNNY! Also, I need a universal remote control because I'm a feeb. I have a great idea, I'll buy one at Bed, Bath, and... BEYOND!
(And the cat's in the cradle and the silver spoon...)
Walken: Before you take this I have some very grave warnings.
Sandler: Uh-huh, yeah. I'm gonna fast-forward through this part. Oh, no! I'm missing my own life!
(...little boy blue and the man in the moon...)
Sandler: Oh my god! I'm fat! I'm old! I'm divorced! Chris Walken is really mean! My dog died and they got another dog who also humps things! It's still funny! I guess being fat is automatically funny, too! I mean, fat suits are always funny. It was funny in Mrs. Doubtfire and in the Eddie Murphy version of "The Nutty Professor" and so this will be every bit as funny. But the remote keeps fast-forwarding past stuff even though I don't want it to! How come rewind doesn't let me do-over, but fast-forward puts the remote in control of all my life decisions? Isn't that a little bit of a disparity? Oh, I know, it's a metaphor for my life, wrapped up in a tidy plot device that lets me explore difficult concepts without having to really face them in the story.
(...when ya comin' home dad? I don't know when, we'll be together then...)
Sandler: And as I hung up the phone, it occurred to me, he'd grown up just like me! My boy was just like me! I want to take it all back! Jacob Marley, you were right! Clarence, it is a wonderful life! Son, don't be a douche like your dad! Spirit, assure me that I yet may change these shadows you have shown me, by an altered life!
(dooblie-dooblie-dooblie...)
Sandler: It was all a dream... OR WAS IT? Young man, what day is it today?
Kid: Why, it's Christmas day, sir!
Sander: Oh, joy of joys. Buy a big fat turkey. "Click", perhaps! It'll be on DVD before you know it. My dog is still humping things! AND IT'S STILL FUNNY! I'm going to yell at my wife so I can pull a switcheroo! It's heartwarming, except that I'm still basically yelling at my wife... I'm going to pile up all the lessons I've learned into an incoherent ball and throw them at everybody I see so they think I'm a mental case! I'm gonna call Julie Kavner and Henry Winkler! Henry's coin trick will continue to be the core of our father-son relationship!
The End.
All I can say is that almost all of the text of the joke is from various online Klingon phrasebooks - so Google is your friend.
:)
It's pretty much the kind of "Klingons on Uranus" joke one would expect, though. The kind that probably doesn't make sense unless you translate it to English first.
I prefer the lovely Knights of Head, myself. Got that lovely conformal armor, with the cushy knee pads...
KANG: De-lak DOH! Bosh-ta-jah Uranus!
KODOS: jIyajbe'! Uranus-ghor tlhInganpu' tagh'a'?
KANG: yIDoghQo'!
(My Klingonese is better than most people's Swahili...)
Come on, damnit, no whammies!
OK, let's suppose you were to have a standard "date" and didn't pay. You might think this is just dandy, perfectly fine business but in fact the hooker probably has some associates who would be willing to break your kneecaps for that money. So from that perspective, paying hookers is definitely good for business.
'Would be cool to have that big dude from the video as an unlockable character, though, for sure - all 20 polygons of him.
Pornography in Japan really doesn't have many limits except simply the censoring of genetalia. While fringe, there is easily available and obtained media of simulated rape, public exposure & sexual activity, sexualized streaking. In the fiction world there are lots of animated and printed works that very obviously depict additional rape, child sex (consentual and non), incest, disfiguring and nonconsentual S&M and human bondage. Hell, just look through Somethingawful's articles on hentai games and you'll see japanese interactive games that let you live out fantasies of banging your younger underage sister. And another one where you literally stalk and rape victims from a train.
And yet, Japan enjoys the lowest rates of sex crimes of all 1st world countries. I'd say the ability for an individual to safely vicariously explore deeper and more sinister fictional sexual practices (as defined by society-at-large) definitely prevents a significant number of real crimes with real victims. Well, see, that's because all the new Hentai videos now have a disclaimer at the end - after your 40 minutes of being entertained by animated rape, you're told that "rape is bad, don't rape people". That clears everything up.
Though, I'm not sure you've accounted for the Densha Chikan types - groping on a crowded train is a real problem in Japan.
Darth Xenu (Warrior Princess) has got nothin' on good ol' Archangel Foster. Fosterites don't need no stinkin' California Law to protect them - the "Spirit In Action League" is ready to come to town and bust some heads...
See my point here? Point being, you want to play the victim?
Don't worry about it. Christians are much more holy when they're being persecuted. Just remember the wise lessons the Amish teach us: "A local boy kicked me in the butt last week - I just smiled at him, and I turned the other cheek. I really don't care, in fact I wish him well - 'cause I'll be laughing my head off when he's burning in hell."
Terminator V: The Robots Strike Back
Terminator VI: The Return of the Terminator Better than:
Terminator 4: The Scorched Home
Terminator 5: The Final Battlefield
Terminator 6: The Undiscovered War
But in Latin, "Jehovah" begins with an 'I'!
And, you know what, I have a Treo. I don't need "some strange app" to crash my phone, the built-in Treo software does a pretty good job of that already. It sucks how that happens. But you know what the answer is? When your phone crashes, you wait for it to reboot (about 15-20 seconds) and you call again. Sure, you don't want that happening in a real emergency situation, but if it did, there are effective ways of dealing with the problem.
You ready for it? It's great stuff. Here you go...
The secret is, not everyone here - not even all the Linux fans around here - is a pretentious prick.
Really a wild idea, isn't it?
What the techs didn't tell Luke was that this repair required replacing much of R2's outer casing, as well as fused logic and memory units, with parts from a similar droid. They basically murdered someone else's droid so they could resurrect Luke's.
And then, there was the subtler matter of whether this "new" R2-D2 was even the same droid. It's kind of a philosophical question. They retrieved as much of R2-D2's data store as they could from the original modules, of course, and according to the specs the replacement parts they used should be equivalent to the parts that were damaged. And, of course, they did simple things like make sure that after the repair R2 still recognized the same designation, as well as his established relationships with others - property of Luke, partner of C-3PO, etc. But it'd really be more accurate to call the repaired R2-D2 a new droid, created from parts of a wrecked droid and a scrapped droid.
As for Luke - R2-D2 could be considered stolen property (the fact that this property stole itself, or that they assumed the Jawas weren't selling them stolen goods - and perhaps even the fact that his owner was killed by Vader, and that any heirs may likely have been killed when Alderaan was destroyed - changes little) - but assuming no relations of Captain Antilles were interested in making such a claim, R2-D2 was Luke's property by virtue of the transaction with the Jawas. So it's not as though R2-D2 was the property of the rebel alliance to begin with. The X-Wing fighter Luke left at Cloud City may be another matter, however...
...On other platforms it's strictly a dot-note.
:) )
(Yours was funnier
Dude, you totally rock. I love your response. It's a perfect criticism and I love the delivery - with just a hint of sarcasm at the end to drive the point home. It's a pity you posted anonymously - but I don't hold that against you.
The person I was replying to suggested that there was no "universally agreed syntax for objects" - which is true. The point I was trying to make (and not making well) was that such a format doesn't need to be "universally agreed" upon, standardized, or pre-existing. If we want progress and have a good idea of what form we want that progress to take, we can build new systems as necessary.
As for creating a new format - if none of the existing ones are really suitable it's the way to go. The plan for the format is based on three key features. First is the ability to wrap established data types for identification. Second is the provision of an adequate set of data types (numbers, text, lists, tables, structures, and objects) to allow information to be expressed in a generic manner. Third is versatile streaming order of data, to allow more versatile pipelines. A metaformat that provides significantly more than that is overkill. A specific format that provides less than that is inadequate.
As for my assertion that no existing formats meet my needs - well, it's an assumption, really. I'm trying to be sure that it's the right conclusion. This means research. But defining a new and compact format that I know is well-suited to what I'm trying to do may be more productive than hunting for one that might be well-suited to what I'm trying to do.
It's quite possible that I could accomplish what I want in some binary encoding of XML - or, rather, use the assumption of an XML encoding as the outermost "layer" of the data as a way to reliably communicate the fact that the contents are in this new format I want to produce - that would have the advantage of playing nicely with all the code out there that looks for XML, at least. It's sort of like going to China knowing no phrases in Mandarin or Cantonese other than "the rest of what I am about to say is in Esperanto." - but that is the whole idea here - tell whoever's listening what language the speaker is speaking - whether that language is PDF, XML, MP3, whatever. I'm not sure if I would want to go that specific route, however.
Access the gui? Why, did somebody strand a bunch of functionality in "the gui" where scripts can't access it?
Nah, nobody would ever be that stupid.
Heh. Actually, I think almost everybody was "that stupid".
MacOS started out as a system that was built from the ground-up with the assumptions of their GUI (hence, filesystem supporting things like forks and resources and a formal notion of type IDs for files) - it has since switched to a more hybrid approach - retaining some of that (including the HFS filesystem) but mostly for backward compatibility - new Mac stuff is designed for lesser assumptions about the filesystem so that the OS will work on HFS but also play nice with other filesystems.
Windows doesn't really have a distinct notion of what defines the "GUI environment" and what defines the "Command-line environment" - the whole system is built around the assumption that the GUI is running on a display somewhere. The underpinnings are reasonably modern and getting better - though filename extensions are still used to infer types, and if you were to consider Windows versions of bash or cmd.exe to be the "Windows command-line environment" then the separation in terms of concepts and functionality is pretty severe. But then you've got powershell, of course, which is like a somewhat Unix-ish shell (mainly in the general concepts of the prompt, the PATH, the filesystem, and command structures like piping) but deeply rooted in Windows technology and style - perhaps the system with the least "split personality disorder" between the text interface and the graphical one, surprisingly.
And then there's Linux. The GUI is being built up as a sort of mimicry of Mac and Windows, with a few old-school X-isms thrown in for good measure - Gnome and KDE each include their respective scripting interfaces (ORBit and dcop, currently) but the components that make up Gnome or KDE are often considered separate from the system - people still write X apps that aren't integrated into or compliant with either environment, and I think many people don't like to incur those dependencies for fear of over-complicating their program or limiting it to just the people who use that particular environment to begin with - so neither system is treated like an assumption, it's strictly an add-on and largely self-contained within its community. Straight X apps and console apps tend to make very few assumptions beyond the POSIX-like system call environment and filesystem, the standard C library, and the terminal or X server. Few projects outside of GNOME or KDE projects assume the presence of an object broker or any particular RPC or IPC mechanism, let alone the more advanced concepts these frameworks implement, such as scriptable application interfaces, data exchange, and so on.
Put simply, it's my contention that on Linux, the GUI frameworks are creating an environment which, from the point of view of the command shell, is fiction - an elaborate facade built on top of machinery that is adequate for the task, but not well tailored to it. What I advocate is not necessarily that these technologies be embraced to create a more specialized shell environment (after all, the changes in Gnome and KDE are a little unsettling if it's stability you're after - KDE dumping CORBA in favor of their dcop system - Gnome possibly dumping CORBA in favor of Mono in the future - apart from the fact that people often don't want these technologies to be a part of the basic assumptions on their system, the technologies simply haven't settled to the point that this is practical...) - but rather a shell environment with sufficient powers of expression and representation to be able to interact well with these technologies. What's missing is the ability for the shell to host and exchange "objects" (meaning, pieces of data - not even necessarily in an OO sense) that have specific requirements for managing their "lifetime" (code to be called when the data is copied or deleted, for instance) Beyond that, wha
The "repeating pattern" is that as people encounter specific problem domains, they devise tools that are particularly suited to solving the problems. LISP could possibly encapsulate everything everywhere - maybe - but as a language LISP isn't as nice for interactive shell sessions as bash, it's not as efficient for expressing text processing problems as Perl, it's not as well suited to exploring and expressing a wide variety of object concepts as Python, etc.
The problem is, LISP can't nicely encapsulate all these different, domain-specific data formats. That's why domain-specific solutions exist in the first place. But, maybe more to the point, it doesn't. Even if it could, it doesn't. There's a big difference between something being possible and something existing as a readily-available solution. Yes, it's possible that a modern system could be built entirely around LISP. It might not be a bad idea. But unless such a system exists, that's meaningless. So who cares? Either write this environment, and prove its greatness, or else kindly acknowledge that while you think a system revolving all around LISP would be dandy, you have nothing more than idle speculation to base that on.
Did LISP in 1958 unify data transfer between digital audio applications, 3-D mesh editors, bitmap and vector graphics editors, word processors, video codecs, and spreadsheets? Of course not. Maybe things have gone downhill since then - if you prefer to think of it that way - and we're just now starting to reintroduce common communication formats back into computing. Whatever - I wasn't even born in 1958. Object-oriented command shells are, as far as I'm concerned, a nice improvement over command shells I've used in the last fourteen years since I started using PCs, so even if you somehow consider this thing a reinvention of LISP (seems like more than a bit of a stretch to me) it's still progress over the current state of affairs.
Anyone else wonder what this means? I guess the question is, where do those leave you unsatisfied? To my knowledge, these (cygwin, active perl, etc) integrate with all features of windows...including, but not limited to, native features like COM objects.
So what basis in fact does this statement have, if any? Sounds like Microsoft-funded propoganda. From my perspective, the limit is in the extent to which the shell works to support data exchange between programs.
Why does the shell need to support data exchange between programs? Well, that's the whole idea between Unix pipes. Bash supports text streams (or rather, byte streams commonly assumed to be textual) between processes, and that's it. And that could be enough - given a universally respected set of conventions on how to format and identify datatypes. So if ActivePerl gets some nice chunk of data out of a running GUI application, and at bash you're trying to pipe that data output into something else - there's a rather cumbersome process of turning that Perl data into a raw bytestream and turning it back into useful data again. The complexity of this problem depends on the complexity of the data - and bash's willful ignorance of the significance of the data that goes between processes means that it can't help in any way.
What's specifically missing is shell-level support for interacting with GUI applications at the same level that ActivePerl is capable of. Bash's support for datatypes isn't sufficient to make it a good way to interface with scriptable applications.
A statement like "but those only get you so far" is a bit vauge - but I think I can see the point.
Well, that's good to know: the thing is, the versatility of the shell in approaching different problems is of more interest than the specific operations that are made convenient. You've demonstrated that changing the extensions of files is a bad example - because the "ren" command provides a convenient means of doing that. Whether Bash's flexibility is compensation for insufficient specialization for common operations - or whether cmd's specializations are compensation for insufficient power in the command language is kind of debatable, and largely a matter of opinion.
But the power and versatility demonstrated in the Bash example - the ability to evaluate a substitution inline, mainly - I think that was the point of that post. We want to know what the equivalent to that is. There's bound to be some other case where an inline substitution would be handy - a case in which maybe CMD doesn't offer any specialized tool for the job.
Let me tell you something: it did not work.
Too complicated and confusing, you have to made up all the "common language" and the interface between programming languages becomes more complex than the code for the problem you are actually trying to solve.
This is the reality of the world - if you want a meaningful, useful interface to your C or C++ module it's going to be a bit of work. Unless, of course, an automated tool like SWIG can do the job nicely for you. I've written Python and Guile bindings for C++ modules I've written in the past - it's a pain in the ass. But what you get for your effort is a version of your module that's transparent, interactive, and self-documenting. Very helpful for fiddling around and testing. Binding to something like CORBA or .NET is roughly the same idea. Languages like C#, Java, and others are designed to make this kind of thing easier by formally adopting ideas of what constitutes a module and how function definitions are exported.
Uh, so yeah. Sometimes doing things is hard. But that doesn't automatically make them bad ideas.
Text is easy to parse and backwards compatible, and if you organize it cleverly, it can represent objects (XML!)
I have a co-worker who would certainly take exception to the assertion that "Text is easy to parse". His primary job around here is writing and maintaining... a parser. :) There are programs that do nothing but attempt to make the job of parsing text easier (lex and yacc, for instance) and still it's a difficult problem.
Text can be easy to parse - if it's that way by design. The same could as easily be true of binary formats, however. Text is a lot easier to handle in current shells, however, because current shells were designed for dealing in text. It's a bit of a self-fulfilling premise. We have less, grep, awk, sed, perl, emacs, and so on - those are the tools that are making text such a convenient format to work with. It's not naturally easy to work with, we've just designed our shell environment around it, thus making it easy. A well-designed environment based on the idea of structured data would also be "easy" once implemented - but it would also be more powerful.
XML could certainly be a candidate for an interchange format between processes - though maybe not the best one. Consider, for instance, Unix pipes. One of their nice features is that the first command in the pipe need only generate as much data as the second command in the pipe is willing to read. For instance:
> primes | head -100 | tail -10
will not run forever. Most likely the "primes" process will generate more primes than "head" is looking for - but it won't run forever (or even until it hits the largest prime number it's capable of calculating) - once it is known that "head" is finished processing its input, "primes" will stop generating new values.
Now, this also applies if you're feeding XML data over the pipe, naturally. But suppose you had a process that was generating two sequences of values - and you wanted to stop processing after the first 100 of each sequence. I don't know enough about XML to know if there are established ways of representing that kind of operation - but there's no communication from the second command about what values it's waiting for from the first command, so the first command will most likely just generate the whole first sequence, then the whole second sequence - processing can't be finished until the first process has generated the entire first sequence.
Add to that the fact that XML (In my opinion, anyway) basically negates one of the main claimed advantages of text formats - the ease of (human) reading/writing, and processing them - it's a basic consequence of a non-trivial data format, really. XML can be edited in a program like Emacs, of course, but Emacs isn't necessarily the best tool for the job. Often, it'd be more preferable