And they did offer it for download for a LONG time. Many people, myself included, were posting links to the kernel source RPM on their ftp site for the first 6 months or so of the suits, here on Slashdot. I have a downloaded copy of it.
It was the 2.4.13 kernel with some patches, so if AND ONLY IF, SCO has a problem with code that was added after 2.4.13, can they really mount a case that that code was not put under the GPL by SCO after the suit began.
You're wrong, but it's easy to get confused on this point.
The article in front of a proper name is capitalized if the article and the name together are the title of something else, and the article comes first or if the article is formally part of the name. In the case of the Internet, the article is not actually part of the name "Internet", we're just using the article to indicate that there is only one Internet in this context (while there are many internets).
Otherwise, you don't capitalize the article (at least in American English).
Thus, you would say, the National Highway System, but if you were talking about a Web site, you might say, "The National Highway System". The difference is subtle, so easy to get confused. And of course, there's your example: The Crown Plaza, in which I presume the "The" is actually part of the name.
A URL is a type of URI as defined by the W3C. URLs specifically reference an object via a means of accessing it. URNs are the other half of the namespace where you specify a sort of unique name for an object, regardless of how you might go about getting access to it.
This distinction is fuzzy though (for example, no one really knows why mailto: is considered a URL scheme other than the fact that the RFCs call it that), and the important thing to remember is that if you're speaking generically of anything that starts with a "protocol:", you say "URI", and if you're speaking of something more specific that really is a URL, like an http link, then you call it a "URL". When you want to sound nerdy you say "URN";-)
Yes, we do. I was refering to redundancy at a higher level, essentially treating the current optical encoding strategies (which I assume any such device would scale up to its form-factor) as raw physical media. Why? Because, terabytes of data are not going to be as harmlessly lost as a 700MB CD or even a several gigabyte DVD, so I would think you would want large-scale redundancy as well as block-level checksums.
Thus, you might have parity located on an inner ring and data located in several sectors throughout the rest of the disk. If you really want to waste space, you might even duplicate information wholesale throughout the media.
Simply interlacing data with a recovery margin of 2 defects per block isn't really going to cut it for that large a dataset.
The Web is a short way of saying, the World Wide Web, which is the set of all things which can be addressed through the W3C's standardized URI naming scheme. URIs are tightly coupled with -- though not a propper superset or subset of -- the Internet, the Domain Name System (DNS) and several other technologies.
You could create your own web of URI-addressable objects, seperate from the Web. In fact, a recent security bug revealed in Microsoft-based programs incluing Word and Mozilla was the result of such a web, which used a non-W3C-standard protocol identifier "shell". That web has some association with the Web, but is not the same thing. That distinction is usually lost on the media, however, and the use of a non-proper version of web has never been common usage.
If someone wishes to start refering to the Internet as the internet and the World Wide Web as the web, they certainly can, but they're wrong.
We're certainly getting to the level where we're going to require some redundancy in order to maintain data integrity, but I'm ok with buying three of these things to store my data that many times... or you could have redundant sectors on the media, perhaps fully duplicated or just maintain parity.
Python is quickly becoming something that is indeed considered acceptable for real programming tasks (Perl never did to the same extent).
I disagree. Python is still in the same ghetto that Perl was always in. Those who take the time to learn it and understand it will use it for the tasks to which it's suited, but the mainstream (no, Paul Ghramm is NOT the mainstream) don't understand why anyone is wasting their time.
The corporate world will never truly accept Python because there's no giant marketting machine like there is for Java and C#. Sadly, that matters.
Who would really want to spread Perl's scalar ambiguity?
Perl has no scalar ambiguity; scalars are.
Look, it was an off-hand comment about the language at the beginning of a rather long analysis of the reasons that popular languages become "bad languages" in the eyes of many.... let's not nit-pick ok?
You list Coneheads and Blues Brothers 2000.... while neither of those captured the box office, both had positive qualities. Sit through Manos and tell me that the cinematography in Coneheads was worse. Tell me the costuming in BB2000 was worse. Tell me that either movie had worse acting (relative to each other, not to the skits and/or movies).
Personally, I liked Coneheads, but just objectively there are FAR worse movies out there. BB2000 I have only seen trailers for, but the trailers alone run circles around Monster-A-Go-Go or Plan 9.
When you have a hundred years of movies to draw on, picking recent box office dissapointments is likely to yield useless results on this particular list. Same goes for good movies. You might feel really good about AVP (just an example) and think it's the best thing ever, but looking back 10 years from now, you'll have to admit that it had nothing on dozens of movies from all the way back to the beginning of movie making.
Correct. Unless someone else can demonstrate that they were using the term as a trademark before Google was, and in the business sector that Google was using it, they can't register it in that sector. It might be that Google can't either (being second in line), but that doesn't mean someone else can. It's different from, but similar to prior art, and is the whole reason that "Open Source" was not considered trademarkable.
I'll be willing to buy his theory that python hackers are better than java hackers.....so long as he buys my theory that lisp hackers are better than python hackers.
You're both WAY off base. I've known some AWFUL programmers who programmed in LISP and/or Python. I've also known some great programmers who prefered assembly, C, C++, Smalltalk, Perl, bourne shell, Python, Modula-2 (well, ok, no one good liked Modula-2) and a wide variety of other languages.
I've also noticed that there are a lot of metrics by which to judge a good programmer, and sometimes they're mutually exclusive.
In the end, I think it's the quality of your logic, your problem solving skills and your ability to understand the ENTIRE domain in which your code must exist and be maintained, not your choice of dialect that matters. Your statement is a bit like saying "French speakers are better at public speaking," which is pure nonsense.
First off, let me be clear: I like Python. I think the throw-back to the yesteryear of line-oriented programming with enforced indentation style is quaint, bordering on painful and that the ultra-dynamic typing without dynamic conversion is kind of a strange choice, but I like Python, and I intend to use it quite a bit.
However, back in the "old days" (late 80s, early 90s), Perl too was a bastion of those who wanted to throw off the shackles of scripting (I hate when that word is mis-used to refer to interpreted languages). Perl was the way to start giving some real structure to all of those tasks like report printing and systems toolsmithing that had traditionally involved totally unmaintainable "scripts" which eventually had to be re-written in a low-level language.
So what happened? Nothing really. Perl developed some nice features, but ultimately LOTS of bad programmers learned it and in a language that makes it easy for people to write programs, you quickly develop a robust collection of REALLY bad code (along with the really good). Just look at C for confirmation of that.
Python is where Perl was in the early 90s now. Lots of folks who know bad code from good are using it, and it looks like the next great island to swim to. It's easy to look back at Perl and say "it was the dollar-signs that FORCED people to be bad coders," or to look at Java and say, "the low-level types are what SEDUCED people into writing crappy code."
In reality it was the popularity and subsequent influx of bad programmers. Python is becoming popular and I guarantee that in about 5 years Python programmers will be listening to, "[Span, Ruby, something else] is so much better than Python... just look at how much cleaner the code is."
I wonder if we'll ever figure out that joe blow who barely understands what programming is will always produce unmaintainable shlock, no matter what language he writes in and no matter what book on abstract modeling he's just read.
[You don't know how your biometric scan is being used at the Statue of Liberty] "The same way you don't know that when you purchase something with a credit card, they don't go and scan your prints off the receipt you just signed and run that against the FBI database."
I submit to you that those are wildly different and incomparable situations. Do I know that my fingerprints aren't lifted from [insert random place] and my actions tracked? Of course, I don't, but I worry about the things that I KNOW are happening. I KNOW that folks coming into the country are being printed. I KNOW that people going to the Statue are being printed. I KNOW that that federal government wants to step up information gathering and tracking.
I see no reason to assume that what would be seen as "valuable law enforcement data" such as fingerprint scans at a major landmark would be thrown away. What's more, I don't see any way to prevent a future change in policy on how old information is used (don't even try to tell me that there are no logs generated by these machines).
Freedom is dangerous. Freedom makes it hard to enforce laws. Freedom makes it hard to "protect our children". Freedom makes government clumsy.
These are all true, and exactly none of them is a good reason to curtail such freedom. We must be ever vigilant for efforts to make the job of government and law enforcement easier at the expense of our liberty.
"I don't get it. Just like many other places, a reasonable, non-intrusive technology is being used to compare visitors to a list of known problem people."
The problem is that non-intrusive techniques, applied on a regular basis are, in fact, intrusive. Here's an example: You are headed in to work and a cop asks you your name and where you're going. No big deal, non-intrusive, etc. Now, you go another block and the cop on that corner asks you the same thing. On the next block the same... all of a sudden, this isn't just interfering with your day, but there's a continuous profile being built up on who you are and where you go.
In this country we believe (and by we, I mean those who agree with such documents as the Declaration of Independance and the Constitution of the United States, which while ultimately flawed, serve as two of the best starting points for any discourse on modern civil liberties) that unreasonable searches must not be performed. I submit to you that fingerprinting at the Statue of Liberty is unreasonable searching. You know the primary forms of attack on the statue: explosive deivce, ranged munitions, etc. There's really no sense in killing anyone there vs. killing them in downtown Manhatten (the target is the symbol itself), but you post guards just in case. You place a checkpoint at the boat drop-off and have people go through a bomb-sniffer. These are reasonable searches.
What's unreasonable is going past that and identifying people according to biometrics so that you can cross-check the innocent and guilty against a database of... of what, exactly? Do you put "troublemakers" in the database? Are young people who go to the statue without family likely to be "too idealistic"? If you wrote a program that told you that women who go to the statue on week-days are more vulnerable to being brought in on the plans of terrorists would you start screening such women? What if you see a member of a radical political party going to the statue and the Empire State in the same day? Do you search his bags?
As someone pointed out earlier (by way of cut-and-paste) totalitarian regimes don't spring up over night. The slowly gain popular support due to fear or desperation. Only when the mechanisms of control are so deeply rooted that no opposition can be mounted can the regime show its true nature (e.g. as happened in Argentina or Iraq). In 2001 the US saw its enemies. Contrary to the teachings of the professed major religion of the country, we did not embrace that enemy. Contrary to the teachings of our most learned scholars we did not attempt to understand our enemy. Contrary to the requests of most of the developed world, we did not hesitate to engage what we percieved to be that enemy.
In so doing, we have taken those first, tentative steps toward becoming our enemy. Welcome, my friends, to the new century....
in the current implementation [forms] compleatly screw up layouts.
And that statement alone desribes the problem. Currently the Web is a content-driven medium which is straining at the seams to become a presentation-driven medium. The PROMISE of XHTML and XForms is that it will allow both to exist in harmony, but in reality the "I will present the way I want to present, dammit" crowd is already rushing to use these features to locate "layover" ads in front of content, make text move, and otherwise slowly mutate HTML into Flash.
Ok, there may be a few non-techies that write html by hand
You're way off base here. I wasn't taking about by-hand vs. automatic generation or techie vs non-techie at all. I was simply describing a World Wide Web where the content takes control of the presentation to a degree not yet seen outside of poorly behaved plug-ins like Flash (mind you, Flash is not a bad IDEA, it's just that the default viewer/plugin for it is horribly unrestricted by the platform on which it exists -- I hope the SVG project for Mozilla makes a better run of it, since client-side rendering of visual information is VERY important).
What you're saying (though you're being too specific) is that separation of semantics from presentation provides arbitrary mapping of the semantics into new problem spaces. For example, the form that you use on the Web to manage your bank account can be the EXACT SAME form that you use at the ATM. Even though those two have wildly different UI needs (touch screen and limited keyboard vs general purpose computer), the semantics of the operations are mostly the same.
This sort of "presentation of requirements" is key in producing the next generation of Web-as-infrastrucutre.
Unfortunately, it also destroys much of what the current World Wide Web is all about. I dread to think of some of the things that will happen to the Web in the next 10 years as a result of technologies like this, but let's not under-play their value.
[...] my compoany has invested a lot of training time and development in a terminal based solution that works for our needs [...] Why is it better? Why does it cost less? Why does it cost us nothing to replace existing apps? Why will we be able to use it in 10 years from now? Why will our staff be more productive?
Ok, let's take those one at a time (I'm assuming that by "terminal based" you are refering to something even more archaic than ActiveX-based form builders):
Why is it better? Well, for starters, it's portable. Portability always sounds a tad useless because you can't see yourself moving to a different hardware or OS platform, but while that kind of portability is more important than it often sounds, portability is rarely considered in terms of moving between software platforms. Why is it better? Because you can take your forms, defined for application A and move them over to application B for the same purpose (new vendor) or for a similar purpose (say, an inventory control form that you modify only slightly and input into your POS system).
Why does it cost less? Code is cheap. Cost to maintain code (or markup for that matter) is high. Maintaining something that has a public specification and thousands of vendors rushing to support it is cheaper than than maintaining something that is proprietary.
Why does it cost us nothing to replace existing apps? It doesn't. See above (and factor in the change in lead-time to add new features) and perform your own cost analysis. My estimate is that most medium-to-large shops will amortize the cost of such a technology move over proprietary, terminal-based solutions within a couple of years, but that's just off-the-cuff. Talk to accounting, they'll understand what inputs you need for such a calculation quite well.
Why will we be able to use it in 10 years from now? Because XML is extensible, so in 10 years, many new features will have been added, but the old features that you rely on will still be available (though, perhaps some of them will be available in a compatibility mode provided in response to your use of a archaic schema). I'm no XML fan, but I have to admit that this capability is one of its MAJOR advantages over many other alternatives.
Why will our staff be more productive? That one's easy because there are so many answers: 1) Because there is less ramp-up time in learning your environment; 2) because dozens of companies are going to be competing to produce better and better editors and front-ends for such systems; 3) because the fact that you don't lock in your employees to a proprietary system means that they won't be looking to escape from your cul-de-sac and you will be able to retain a higher calibur of employee without having to over-compensate them for their rare, niche knowledge; 4) because, being a modern tool, it will interface well (or be built into systems that interface well) with other modern, high-level tools (e.g. encrypting form access is a trivial after-thought with SSL).
I don't like the IDEA of XHTML and XForms because of the way it changes the character of the Internet, but I do have to admit that for a certain class of business, it's the best option on the immediate horizon.
As a big fan of MySQL, and long-time user, I just want to say congrats to the PG folks on this release! PG is a great database, and an excellent contribution to the world of open source databases. It does the open source world a great service to have so many high-quality options out there.
So, I submitted this story yesterday, and was looking to see if it showed up today. Turns out it showed up yesterday, but not on the homepage... at least not for me. I wonder if it's because it doesn't have a topic? I put it under Perl as it was about Parrot, and until Parrot has its own topic, Perl seems most apropos. Perhaps they meant to change it to Python, but made a mistake?
You're right, and it had absolutely nothing to do with language comparisons (most of which are anatomy-waving competitions in the first place).
The contest was about the value of a JITed VM vs the CPython (or Perl 5, for that matter) style of syntax-tree / bytecode walking. It was Dan's claim that Parrot would be faster at running Python bytecode than CPython and he was basing that on early data from Perl 5 running on Parrot. Since Perl 5 had been shown to execute faster than Python (on top of CPython) for certain operations and since Parrot ran that Perl 5 code faster than Perl 5, the assumption was that, at least in some cases, Parrot would be faster than CPython.
Clearly there was a lot of room for Dan to lose on the merits of really being wrong, but IMHO equally as much of a chance to be right. We'll know someday when Parrot's Python front-end and Python-required back-end bits are at a state that this is more practical for the comparison.
These languages make certain assumptions about typing and binding that Python and Perl do not.
And which Parrot allows you to if you wish. You're discussing languages, not VMs, but responding to a comment about VMs.
Additionally, Java's class structure is much *much* more time-efficient [...] than Python's memory-efficient proto-based object structure.
Well, again you're comparing language features not VM features, and in this particular case, you're going to be dissapointed, because even in pure Python you can have non-prototype class definitions.
It's why they're SCRIPTING languages.
Actually no, the term "scripting" comes from the days when you would place a series of program names in order in a file and the OS could run them. It was like a script for a play, you write it down and it happens in that order.
The term has blurred so much since then that at this point there is no actual reason. The ability to eval strings is often cited, but no one is calling Common Lisp a "scripting language" as far as I can tell. Speed if often cited, but speed trade-offs are being mitigated by increasingly powerful language features for specifying critical optimization information and by more powerful compilation tactics.
No, "scripting" is a null word these days, which low-level languages use to dismiss high-level languages such as Python, Ruby and Perl. Java, C# and other "mid-level" language camps stand around watching this in what I can only guess is bemused smugness, but even that distinction is ending with the advent of Parrot. Running under Parrot, I see no reason for a Perl 6 program to be slower executing code than a Java program executing logically the same code. Typing and low-level behavior can be specified. Native types can be accessed. Classes need not be computed at run-time (though they can be). In general, I see Perl 6, and whatever the first versions of Python, Ruby and the rest are that truly take advantage of Parrot as being the first languages since Common Lisp that will manage to bridge the gap between mid-level and high-level languages completely.
RMS did not take leave of his senses in the NINETYS
Yeah, he did. In the 80s and early 90s he was eccentric and a bit flighty, but I know a lot of people like that. In the mid-90s he began to develop an ego that precluded anyone else's input except as the seed on which to begin a discussion about one of RMS' favorite pet topics. I was totally convinced of this when I heard him talking informally to ESR over a conference dinner one night. He was almost in tears, he was so frustrated by ESR's unwillingness to accept his points, but every effort to explain ESR's position (by ESR or others) was brushed aside without so much as a glimmer of consideration.
Several years before I'd had a disucssion with him over how to manage configuration files like/etc/passwd in Hurd and while we disagreed, he was accepting my points, considering them and THEN disageeing.
It's too bad. He was a bright guy whose future could have out-shown his gigantic accomplishments in the 80s and early 90s.
Oh, and about the reasonable vs. unreasonable thing... I think you'll find I've at no point discussed his being either. Those are subjective terms, and I wasn't about to get into that particular rhetorical bog.
Slashdot Mirror
And they did offer it for download for a LONG time. Many people, myself included, were posting links to the kernel source RPM on their ftp site for the first 6 months or so of the suits, here on Slashdot. I have a downloaded copy of it.
It was the 2.4.13 kernel with some patches, so if AND ONLY IF, SCO has a problem with code that was added after 2.4.13, can they really mount a case that that code was not put under the GPL by SCO after the suit began.
You're wrong, but it's easy to get confused on this point.
The article in front of a proper name is capitalized if the article and the name together are the title of something else, and the article comes first or if the article is formally part of the name. In the case of the Internet, the article is not actually part of the name "Internet", we're just using the article to indicate that there is only one Internet in this context (while there are many internets).
Otherwise, you don't capitalize the article (at least in American English).
Thus, you would say, the National Highway System, but if you were talking about a Web site, you might say, "The National Highway System". The difference is subtle, so easy to get confused. And of course, there's your example: The Crown Plaza, in which I presume the "The" is actually part of the name.
A URL is a type of URI as defined by the W3C. URLs specifically reference an object via a means of accessing it. URNs are the other half of the namespace where you specify a sort of unique name for an object, regardless of how you might go about getting access to it.
;-)
This distinction is fuzzy though (for example, no one really knows why mailto: is considered a URL scheme other than the fact that the RFCs call it that), and the important thing to remember is that if you're speaking generically of anything that starts with a " protocol:", you say "URI", and if you're speaking of something more specific that really is a URL, like an http link, then you call it a "URL". When you want to sound nerdy you say "URN"
Yes, we do. I was refering to redundancy at a higher level, essentially treating the current optical encoding strategies (which I assume any such device would scale up to its form-factor) as raw physical media. Why? Because, terabytes of data are not going to be as harmlessly lost as a 700MB CD or even a several gigabyte DVD, so I would think you would want large-scale redundancy as well as block-level checksums.
Thus, you might have parity located on an inner ring and data located in several sectors throughout the rest of the disk. If you really want to waste space, you might even duplicate information wholesale throughout the media.
Simply interlacing data with a recovery margin of 2 defects per block isn't really going to cut it for that large a dataset.
Correct, and to take that one step further:
The Web is a short way of saying, the World Wide Web, which is the set of all things which can be addressed through the W3C's standardized URI naming scheme. URIs are tightly coupled with -- though not a propper superset or subset of -- the Internet, the Domain Name System (DNS) and several other technologies.
You could create your own web of URI-addressable objects, seperate from the Web. In fact, a recent security bug revealed in Microsoft-based programs incluing Word and Mozilla was the result of such a web, which used a non-W3C-standard protocol identifier "shell". That web has some association with the Web, but is not the same thing. That distinction is usually lost on the media, however, and the use of a non-proper version of web has never been common usage.
If someone wishes to start refering to the Internet as the internet and the World Wide Web as the web, they certainly can, but they're wrong.
We're certainly getting to the level where we're going to require some redundancy in order to maintain data integrity, but I'm ok with buying three of these things to store my data that many times... or you could have redundant sectors on the media, perhaps fully duplicated or just maintain parity.
50 cents per terabyte, huh? I guess that's ok, but it still seems a bit pricy ;-)
Does anyone else remember full-height 20MB drives for home computers that cost $700? I feel like I'm in a Virginia Slims ad....
Python is quickly becoming something that is indeed considered acceptable for real programming tasks (Perl never did to the same extent).
I disagree. Python is still in the same ghetto that Perl was always in. Those who take the time to learn it and understand it will use it for the tasks to which it's suited, but the mainstream (no, Paul Ghramm is NOT the mainstream) don't understand why anyone is wasting their time.
The corporate world will never truly accept Python because there's no giant marketting machine like there is for Java and C#. Sadly, that matters.
Who would really want to spread Perl's scalar ambiguity?
Perl has no scalar ambiguity; scalars are.
Look, it was an off-hand comment about the language at the beginning of a rather long analysis of the reasons that popular languages become "bad languages" in the eyes of many.... let's not nit-pick ok?
Ooops, I left out "skits and/or movies on which they were based"... makes a rather large difference ;-)
You list Coneheads and Blues Brothers 2000.... while neither of those captured the box office, both had positive qualities. Sit through Manos and tell me that the cinematography in Coneheads was worse. Tell me the costuming in BB2000 was worse. Tell me that either movie had worse acting (relative to each other, not to the skits and/or movies).
Personally, I liked Coneheads, but just objectively there are FAR worse movies out there. BB2000 I have only seen trailers for, but the trailers alone run circles around Monster-A-Go-Go or Plan 9.
When you have a hundred years of movies to draw on, picking recent box office dissapointments is likely to yield useless results on this particular list. Same goes for good movies. You might feel really good about AVP (just an example) and think it's the best thing ever, but looking back 10 years from now, you'll have to admit that it had nothing on dozens of movies from all the way back to the beginning of movie making.
Correct. Unless someone else can demonstrate that they were using the term as a trademark before Google was, and in the business sector that Google was using it, they can't register it in that sector. It might be that Google can't either (being second in line), but that doesn't mean someone else can. It's different from, but similar to prior art, and is the whole reason that "Open Source" was not considered trademarkable.
I'll be willing to buy his theory that python hackers are better than java hackers... ..so long as he buys my theory that lisp hackers are better than python hackers.
You're both WAY off base. I've known some AWFUL programmers who programmed in LISP and/or Python. I've also known some great programmers who prefered assembly, C, C++, Smalltalk, Perl, bourne shell, Python, Modula-2 (well, ok, no one good liked Modula-2) and a wide variety of other languages.
I've also noticed that there are a lot of metrics by which to judge a good programmer, and sometimes they're mutually exclusive.
In the end, I think it's the quality of your logic, your problem solving skills and your ability to understand the ENTIRE domain in which your code must exist and be maintained, not your choice of dialect that matters. Your statement is a bit like saying "French speakers are better at public speaking," which is pure nonsense.
First off, let me be clear: I like Python. I think the throw-back to the yesteryear of line-oriented programming with enforced indentation style is quaint, bordering on painful and that the ultra-dynamic typing without dynamic conversion is kind of a strange choice, but I like Python, and I intend to use it quite a bit.
However, back in the "old days" (late 80s, early 90s), Perl too was a bastion of those who wanted to throw off the shackles of scripting (I hate when that word is mis-used to refer to interpreted languages). Perl was the way to start giving some real structure to all of those tasks like report printing and systems toolsmithing that had traditionally involved totally unmaintainable "scripts" which eventually had to be re-written in a low-level language.
So what happened? Nothing really. Perl developed some nice features, but ultimately LOTS of bad programmers learned it and in a language that makes it easy for people to write programs, you quickly develop a robust collection of REALLY bad code (along with the really good). Just look at C for confirmation of that.
Python is where Perl was in the early 90s now. Lots of folks who know bad code from good are using it, and it looks like the next great island to swim to. It's easy to look back at Perl and say "it was the dollar-signs that FORCED people to be bad coders," or to look at Java and say, "the low-level types are what SEDUCED people into writing crappy code."
In reality it was the popularity and subsequent influx of bad programmers. Python is becoming popular and I guarantee that in about 5 years Python programmers will be listening to, "[Span, Ruby, something else] is so much better than Python... just look at how much cleaner the code is."
I wonder if we'll ever figure out that joe blow who barely understands what programming is will always produce unmaintainable shlock, no matter what language he writes in and no matter what book on abstract modeling he's just read.
[You don't know how your biometric scan is being used at the Statue of Liberty] "The same way you don't know that when you purchase something with a credit card, they don't go and scan your prints off the receipt you just signed and run that against the FBI database."
I submit to you that those are wildly different and incomparable situations. Do I know that my fingerprints aren't lifted from [insert random place] and my actions tracked? Of course, I don't, but I worry about the things that I KNOW are happening. I KNOW that folks coming into the country are being printed. I KNOW that people going to the Statue are being printed. I KNOW that that federal government wants to step up information gathering and tracking.
I see no reason to assume that what would be seen as "valuable law enforcement data" such as fingerprint scans at a major landmark would be thrown away. What's more, I don't see any way to prevent a future change in policy on how old information is used (don't even try to tell me that there are no logs generated by these machines).
Freedom is dangerous. Freedom makes it hard to enforce laws. Freedom makes it hard to "protect our children". Freedom makes government clumsy.
These are all true, and exactly none of them is a good reason to curtail such freedom. We must be ever vigilant for efforts to make the job of government and law enforcement easier at the expense of our liberty.
"I don't get it. Just like many other places, a reasonable, non-intrusive technology is being used to compare visitors to a list of known problem people."
... of what, exactly? Do you put "troublemakers" in the database? Are young people who go to the statue without family likely to be "too idealistic"? If you wrote a program that told you that women who go to the statue on week-days are more vulnerable to being brought in on the plans of terrorists would you start screening such women? What if you see a member of a radical political party going to the statue and the Empire State in the same day? Do you search his bags?
The problem is that non-intrusive techniques, applied on a regular basis are, in fact, intrusive. Here's an example: You are headed in to work and a cop asks you your name and where you're going. No big deal, non-intrusive, etc. Now, you go another block and the cop on that corner asks you the same thing. On the next block the same... all of a sudden, this isn't just interfering with your day, but there's a continuous profile being built up on who you are and where you go.
In this country we believe (and by we, I mean those who agree with such documents as the Declaration of Independance and the Constitution of the United States, which while ultimately flawed, serve as two of the best starting points for any discourse on modern civil liberties) that unreasonable searches must not be performed. I submit to you that fingerprinting at the Statue of Liberty is unreasonable searching. You know the primary forms of attack on the statue: explosive deivce, ranged munitions, etc. There's really no sense in killing anyone there vs. killing them in downtown Manhatten (the target is the symbol itself), but you post guards just in case. You place a checkpoint at the boat drop-off and have people go through a bomb-sniffer. These are reasonable searches.
What's unreasonable is going past that and identifying people according to biometrics so that you can cross-check the innocent and guilty against a database of
As someone pointed out earlier (by way of cut-and-paste) totalitarian regimes don't spring up over night. The slowly gain popular support due to fear or desperation. Only when the mechanisms of control are so deeply rooted that no opposition can be mounted can the regime show its true nature (e.g. as happened in Argentina or Iraq). In 2001 the US saw its enemies. Contrary to the teachings of the professed major religion of the country, we did not embrace that enemy. Contrary to the teachings of our most learned scholars we did not attempt to understand our enemy. Contrary to the requests of most of the developed world, we did not hesitate to engage what we percieved to be that enemy.
In so doing, we have taken those first, tentative steps toward becoming our enemy. Welcome, my friends, to the new century....
in the current implementation [forms] compleatly screw up layouts.
And that statement alone desribes the problem. Currently the Web is a content-driven medium which is straining at the seams to become a presentation-driven medium. The PROMISE of XHTML and XForms is that it will allow both to exist in harmony, but in reality the "I will present the way I want to present, dammit" crowd is already rushing to use these features to locate "layover" ads in front of content, make text move, and otherwise slowly mutate HTML into Flash.
Ok, there may be a few non-techies that write html by hand
You're way off base here. I wasn't taking about by-hand vs. automatic generation or techie vs non-techie at all. I was simply describing a World Wide Web where the content takes control of the presentation to a degree not yet seen outside of poorly behaved plug-ins like Flash (mind you, Flash is not a bad IDEA, it's just that the default viewer/plugin for it is horribly unrestricted by the platform on which it exists -- I hope the SVG project for Mozilla makes a better run of it, since client-side rendering of visual information is VERY important).
nuclear (nuk-you-lar) war
;-)
Good lord, can't you f'rn'rs get it right?! It's pronounced, newk-ler or newk-ya-ler. Barbarians, the lot of ya!
What you're saying (though you're being too specific) is that separation of semantics from presentation provides arbitrary mapping of the semantics into new problem spaces. For example, the form that you use on the Web to manage your bank account can be the EXACT SAME form that you use at the ATM. Even though those two have wildly different UI needs (touch screen and limited keyboard vs general purpose computer), the semantics of the operations are mostly the same.
This sort of "presentation of requirements" is key in producing the next generation of Web-as-infrastrucutre.
Unfortunately, it also destroys much of what the current World Wide Web is all about. I dread to think of some of the things that will happen to the Web in the next 10 years as a result of technologies like this, but let's not under-play their value.
[...] my compoany has invested a lot of training time and development in a terminal based solution that works for our needs [...] Why is it better? Why does it cost less? Why does it cost us nothing to replace existing apps? Why will we be able to use it in 10 years from now? Why will our staff be more productive?
Ok, let's take those one at a time (I'm assuming that by "terminal based" you are refering to something even more archaic than ActiveX-based form builders):
Why is it better? Well, for starters, it's portable. Portability always sounds a tad useless because you can't see yourself moving to a different hardware or OS platform, but while that kind of portability is more important than it often sounds, portability is rarely considered in terms of moving between software platforms. Why is it better? Because you can take your forms, defined for application A and move them over to application B for the same purpose (new vendor) or for a similar purpose (say, an inventory control form that you modify only slightly and input into your POS system).
Why does it cost less? Code is cheap. Cost to maintain code (or markup for that matter) is high. Maintaining something that has a public specification and thousands of vendors rushing to support it is cheaper than than maintaining something that is proprietary.
Why does it cost us nothing to replace existing apps? It doesn't. See above (and factor in the change in lead-time to add new features) and perform your own cost analysis. My estimate is that most medium-to-large shops will amortize the cost of such a technology move over proprietary, terminal-based solutions within a couple of years, but that's just off-the-cuff. Talk to accounting, they'll understand what inputs you need for such a calculation quite well.
Why will we be able to use it in 10 years from now? Because XML is extensible, so in 10 years, many new features will have been added, but the old features that you rely on will still be available (though, perhaps some of them will be available in a compatibility mode provided in response to your use of a archaic schema). I'm no XML fan, but I have to admit that this capability is one of its MAJOR advantages over many other alternatives.
Why will our staff be more productive? That one's easy because there are so many answers: 1) Because there is less ramp-up time in learning your environment; 2) because dozens of companies are going to be competing to produce better and better editors and front-ends for such systems; 3) because the fact that you don't lock in your employees to a proprietary system means that they won't be looking to escape from your cul-de-sac and you will be able to retain a higher calibur of employee without having to over-compensate them for their rare, niche knowledge; 4) because, being a modern tool, it will interface well (or be built into systems that interface well) with other modern, high-level tools (e.g. encrypting form access is a trivial after-thought with SSL).
I don't like the IDEA of XHTML and XForms because of the way it changes the character of the Internet, but I do have to admit that for a certain class of business, it's the best option on the immediate horizon.
As a big fan of MySQL, and long-time user, I just want to say congrats to the PG folks on this release! PG is a great database, and an excellent contribution to the world of open source databases. It does the open source world a great service to have so many high-quality options out there.
So, I submitted this story yesterday, and was looking to see if it showed up today. Turns out it showed up yesterday, but not on the homepage... at least not for me. I wonder if it's because it doesn't have a topic? I put it under Perl as it was about Parrot, and until Parrot has its own topic, Perl seems most apropos. Perhaps they meant to change it to Python, but made a mistake?
Just guessing.
You're right, and it had absolutely nothing to do with language comparisons (most of which are anatomy-waving competitions in the first place).
The contest was about the value of a JITed VM vs the CPython (or Perl 5, for that matter) style of syntax-tree / bytecode walking. It was Dan's claim that Parrot would be faster at running Python bytecode than CPython and he was basing that on early data from Perl 5 running on Parrot. Since Perl 5 had been shown to execute faster than Python (on top of CPython) for certain operations and since Parrot ran that Perl 5 code faster than Perl 5, the assumption was that, at least in some cases, Parrot would be faster than CPython.
Clearly there was a lot of room for Dan to lose on the merits of really being wrong, but IMHO equally as much of a chance to be right. We'll know someday when Parrot's Python front-end and Python-required back-end bits are at a state that this is more practical for the comparison.
These languages make certain assumptions about typing and binding that Python and Perl do not.
And which Parrot allows you to if you wish. You're discussing languages, not VMs, but responding to a comment about VMs.
Additionally, Java's class structure is much *much* more time-efficient [...] than Python's memory-efficient proto-based object structure.
Well, again you're comparing language features not VM features, and in this particular case, you're going to be dissapointed, because even in pure Python you can have non-prototype class definitions.
It's why they're SCRIPTING languages.
Actually no, the term "scripting" comes from the days when you would place a series of program names in order in a file and the OS could run them. It was like a script for a play, you write it down and it happens in that order.
The term has blurred so much since then that at this point there is no actual reason. The ability to eval strings is often cited, but no one is calling Common Lisp a "scripting language" as far as I can tell. Speed if often cited, but speed trade-offs are being mitigated by increasingly powerful language features for specifying critical optimization information and by more powerful compilation tactics.
No, "scripting" is a null word these days, which low-level languages use to dismiss high-level languages such as Python, Ruby and Perl. Java, C# and other "mid-level" language camps stand around watching this in what I can only guess is bemused smugness, but even that distinction is ending with the advent of Parrot. Running under Parrot, I see no reason for a Perl 6 program to be slower executing code than a Java program executing logically the same code. Typing and low-level behavior can be specified. Native types can be accessed. Classes need not be computed at run-time (though they can be). In general, I see Perl 6, and whatever the first versions of Python, Ruby and the rest are that truly take advantage of Parrot as being the first languages since Common Lisp that will manage to bridge the gap between mid-level and high-level languages completely.
My dear boy
/etc/passwd in Hurd and while we disagreed, he was accepting my points, considering them and THEN disageeing.
I'm not your dear boy, son.
RMS did not take leave of his senses in the NINETYS
Yeah, he did. In the 80s and early 90s he was eccentric and a bit flighty, but I know a lot of people like that. In the mid-90s he began to develop an ego that precluded anyone else's input except as the seed on which to begin a discussion about one of RMS' favorite pet topics. I was totally convinced of this when I heard him talking informally to ESR over a conference dinner one night. He was almost in tears, he was so frustrated by ESR's unwillingness to accept his points, but every effort to explain ESR's position (by ESR or others) was brushed aside without so much as a glimmer of consideration.
Several years before I'd had a disucssion with him over how to manage configuration files like
It's too bad. He was a bright guy whose future could have out-shown his gigantic accomplishments in the 80s and early 90s.
Oh, and about the reasonable vs. unreasonable thing... I think you'll find I've at no point discussed his being either. Those are subjective terms, and I wasn't about to get into that particular rhetorical bog.