The more you stray from line-based text files that you can easily call things like awk and grep on, the more you'll alienate some people. I don't believe there's a version of awk or grep that handle XML-based records. This is pretty important to tool-minded people.
the latin word "virus"(which translates to venom) has a plural case of "viri." the English word "virus" (derived from the latin but not the same word) has a plural case "viruses"
Please supply a classical citation of your assertion. There is no neuter 2nd decl -us noun that goes to -i in the plural. They are all (four) of them irregular.
I have a classical citation that shows virus being invariant in the genitive. I challenge you to produce any classical instance of virus in the plural.
Nope: it was not a 2nd decl masculine. It was more like "vulgus", "pelagus", or "cetus", which were 2nd decl neuters. It may even have been a 4th decl neuter. See this article on the matter.
Virus is a second declension noun (-us, -i, -o, -um, -o; -i, -orum, -is, -os, -is), so technically, its Latin plural would be viri, not virii
Actually, it's rather more complicated than that. You're thinking of 2nd declension masculines. Virus was one of the rare 2nd decl neuters, like vulgus, cetus, and pelagus. These rarae aves did not inflect by changing -us to -i; they were irregular at best, and generally invariant. Virus was also not a count noun, but a mass noun.
It's even possible that virus pertained not to the second but to the fourth declension, which would change the matter as well.
The word becomes invariant in most modern languages, but for some reason, English elected these viruses rather than *these virus as one might otherwise expect from the modern Romance tongues.
I've had to deal with nasty CGI Perl code written by other people that I was barely able to read, much less figure out how to change without breaking the whole thing.
It's a shame that this is true, but you're right. Perl is so easy to use that people who have no experience in designing programs for long-term maintainability can just crank out any old thing. And most of the CGI world falls into that category. I don't know a solution beyond making a programming language too hard to use for people who don't know much about programming. And that won't win you any friends.
On the other hand, many of the mod_perl applications I've looked at have been sophisticated and clean. They've actually been designed and structured. They're a pleasure to read and to maintain. And they're written in the same language as those CGI scripts from hell that the script kiddies mutilate. Yet it seems like it's galaxies far removed.
Interesting, eh?
I believe this is saying more about the average CGI script kiddie versus Apache mod_perl hacker than it is saying about Perl. But yes, it's easy to write bad perl code. I guess it's easy to write bad C++ code too, but the barrier to entry is higher.
I don't know that there's ever been a language written in which it's been the least bit hard to write bad code. If you outlaw bad code, only outlaws will code badly.:-)
"At the time, there was no Internet, the term '24/7' had yet to be coined and it was unheard of to get proprietary information from the client's employer - an investment bank - piped into the home," Daniel Rowen, who designed the apartment with fellow architect Frank Lupo, told EE Times.
No internet in 88, eh? I suppose Bill Gates and Al Gore hadn't invented it yet.
Sigh.
I wonder what that thing I've been on since the very early 80s really is? I'd swear that it was the internet. Has the media truly forgotten where this all came from?
And by 1988, I certainly had internet from home, including a private link into my employer's inner sanctum of customer and engineering data. And I from there was able to tap into our clients' own private systems as needed when I was doing customer service. Now, it wasn't the clients' business info we were getting, but still.
Complaints are piling up from consumers forced to buy Windows 98 with their new computers. The Finance Ministry might put an end to this monopoly from Bill Gates's company.
DOMENICA STRAUSS-KAHN attacks Bill Gates! The Economy and Finance Minister has just ordered his "Fraud Squads" to check up on Microsoft, the company of the American billionaire. As in the States, where a lawsuit pits Microsoft against the American government, France will examine the situation of the multinational on its territory. Detractors of Bill Gates's company claim that it has "locked up" the market, thus "forcing" consumers to buy its software. "The customer no longer has any choice in this", summarizes Vincent Balat, a compsci researcher, who judges that Windows 98, the flagship product from Microsoft, is less efficient than its competitor, Linux, a program nevertheless available for free on Internet.
Forced to Buy Software in Duplicate
To confront these criticisms, the specialized services of Bercy must put gather up the procedures already begun across various departments in order to closely examine the various lawsuits. "If this investigation shows abnormal situations or obstacles with market rules, we'll be checking with the competition," Bercy was told. The essential point is that Microsoft would risk legal action and fines. One of the first to address the complaint folder on fraud control is a compsci teacher at some school in Paris, Roberto Di Cosmo. A computer enthusiast and the author of a vitriolic book against Microsoft, Roberto Di Cosmo thinks the multinational abuses its position as leader.
"When you buy a computer today," he explains, "you buy the box and the software accompanying it. And even if the latter represents some 20% of the price, this is never spelled out," he laments. On a computer costing five thousand francs, some one thousand francs would go toward software. One of these programs is Windows 98, Microsoft's operating system, which is essential for running the machine. "Because computers are sold already equipped with Windows, as soon as you change computers, you end up buying Windows again!" explains Roberto Di Cosmo. For months now, this computer expert has in vain demanded from his retailer refunds for several programs that he now has duplicates of, since he hasn't sold his used computers.
Promise of Compensation
"Indeed, this situation can appear abnormal ", comments Jérôme Franck, a lawyer specializing in consumer law. But to date, only one purchaser in France, a teacher from Montpellier, has been reimbursed by his retailer. On this matter, the Microsoft position seems to evolve. "We are ready to refund," we were told yesterday by Vahé Torossian, director at Microsoft France of divisions manufacturer and general public and therefore specialist in licensing questions. "We mislead no one," he adds. "When you buy a new car, you don't ask your manufacturer to install your old car's engine in the new car. Similarly, Windows 98 is the engine of each computer". That said, Vahé Torossian assures that his firm is ready with possible refunds. "If someone doesn't care to use Windows 98, they can bring back their computer to thier retailer, who will fill out a slip, then refund it", he states. That's good news for Microsoft's opponents, even if the amount of these "redunds" is still unknown.
What I really want to see is one of the metadata rating bits they send over the wire to be one that indicates whether you're currently viewing an advert. That way it can be blocked.
It might be possible to leverage off the "parental control" issue here. I know more than one family who has ditched the TV because they didn't want their children corrupted by the interminable advertspam. This is a real issue for some parents. It's just as much part of letting parents have a say in what kind of crap gets stuck in their kids' brains as the sex and violence and adult situations bits.
And it's a real issue to some non-parents, as well. I'd rather a Blue Screen of Death than the constant adverts.
But here's what I wish: I wish there was a GUI text editor that did perl/html/php3/etc. syntax highlighting (I use NEdit now, which rocks BTW), could run my scripts (if they're that kind of thing) or do a perl -cw on them (if they're not), that would integrate seamlessly with ftp and cvs (most of my work really lives on other servers anyway), and could give me some debugging functions of some sort.
I don't quite understand the ftp and cvs thing you mention. If you don't mind using a power editor, there are versions of vi that do some kind of syntax coloring for Perl. (I've never understood the need, personally.)
You might also look at pvdb . It gives you three xterms: one for the perl debugger, one for vi on whatever source file the debugger has break-pointed into, and one for stdin and stdout. As you hit breakpoints and step through, it controls vi for you to move you around.
After reading over 400 responses here, I decided that there were far too many to respond to individually, so I'll try to hit the major points. This article is in two parts: the first asks a lot of questions, and the second provides a few answers. However, part 2 doesn't try to answer part 1's questions. You'll have to do that thinking on your own.:-)
1. Questions
The most important issue, and one which surprisingly few posters have addressed, is to identify the properties that are desirable in a 1st programming language. Identify also which properties are considered undesirable in that same environment. Once you've done a thorough study of these issues, only then can you analyse existing programming languages for how well they fit these criteria, or to create a new one that better satisfies them than existing languages. But until you know against what metrics these languages are to be judged, you cannot objectively do so.
Is this ideal beginner-oriented programming language also a language that's good for other focused domains? Will the decisions you've made in designing or selecting this ideal beginner-oriented programming language render it less than optimal for programming that isn't oriented toward non-programmers? Or if you add in properties conducive to non-beginner programming, will this compromise your goals of creating something for beginners?
Can we leverage our natural cognitive strengths in learning natural languages to learn a programming language? Does this imply that we acquire language more readily when we have lots of easy, contextual examples than we would if presented with sets of rules and axioms? Does this mean learning by a usable subset of a language first, and only adding sophistication if and when it becomes necessary? If so, does this not engender dialectical subsets? Would a beginner (equivalent to a seven-year-old speaker of his native tongue) confronted by a complex piece in the language (say, equivalent to a doctoral thesis) find himself somewhat lost? Would it be better to throw out the language you'd learned until age seven and start a new one so this can't happen, or is it better to learn incrementally?
Does it make sense to expect the same language that is used for one domain to be equally applicable to an unrelated domain? Aren't domain-specific languages both more powerful and more user-friendly?
Are we talking about a particular age group, such as ages 9-12, 13-17, or 18-21? Does this affect our criteria? Should a university really be used as nothing but a high-classed tech school as feeders for industry? If so, shouldn't diverse core curricula emphasizing reading, writing, and effective skills get more attention?
Do we understand the differences between "IT" training and "CS" training? What's a business programmer, and how is that different than a programmer? Is the goal to teach programming, or is it to teach computer science? Or are we just talking about teaching computer use? Since when is a computer science degree required to use a computer, or even administrate it?
How do you define "readability"? Does resemblance to a natural language suffice? Is this a good thing? Remember one notorious attempt to create a programming language that even non-programmers could use cursed us with Cobol. Wouldn't it be nice to avoid that next time around?
Is readability culturally biased? Can a language designed to be easy for Unix users to learn be equally easy for non-Unix users? Can a language designed to be easy for non-Unix users to learn be equally easy for Unix users? Think of it this way: Does your knowledge of Greek help you learning Russian? Is it the character sets, or are there more important underlying similarities? Is a language designed to be used by people who know language XXX going to be different than one designed for those ignorant of XXX? Do semantics grow out of syntax (ordering, positioning), or should they be explicitly reinforced by inflection markers (singular vs plural, noun vs verb, etc)?
Should a programming language require a fancy, hand-holding IDE before it can be used effectively, or should a line editor suffice? How much hand-holding is useful to the beginner but annoying to the expert? Can you make a programming language that's designed to be completely learnable in a very short time that doesn't rule out its use later down the road? Is "user-friendly" well defined? Does "user-friendly" always denote "expert-hostile"? Will software that pleases one set also please the other set? Should it? Are languages designed for short-term use or long-term use? Where then should optimization occur?
That's certainly plenty to think about, and mostly what I just did is provide important questions that should be thought through. In many of the questions, there is no single right answer, but there are consequences. Try answering the questions in more than one way, and then compare the resulting trade-offs that arise depending on which path you took.
2. Answers
I certainly don't have all the answers to those questions. But I do have some comments on the Perl matters. The first is that Perl and Python are actually essentially the same language, and that there are a great deal of other sorts of languages out there that a computer scientist should be exposed to. Much like the warning to beware the man of one book, also be wary of the programmer of just one programming language.
And before you can begin to compare two languages, you actually have to know them both! Oh, not necessarily with equal fluency, but you actually have to have taken the time and energy to play with them, to sound them out in real situations. Superficial assessments based upon surface appearances are useless.
The "scripting language" versus "programming language" bigotry is nothing but cultural arrogance borne out of theoretic ignorance. I'm aware of Ousterhout's paper, and I have responded to it before. John is a very bright man, but like all of us, he carries with him his own historical baggage from the past and unfolding agenda for the future.
In this case, this a false dualism of "scripting" versus "programming" does nothing but harm. It has virtually no basis in theory, and little in practice. The assertion that byte-compiled Perl or Python can't handle certain tasks but that by merit of being compiled to machine language, C or Pascal or Ada or Modula automatically can--well, this is completely ludicrous.
Rob Kolstad long ago conjectured the following: "The success of a new programming language is directly proportionate to its resemblance to C." Perhaps a more accurate statement would be "The degree to which a new programming language will be embraced by C programmers is directly proportionate to its resemblance to C." And now you can swap in other programming languages in that equation.
As far as real-world programming goes, I assert that the majority of it gets done using C or a derivative of the same; and yes, I consider Awk, C++, Java, and Perl to be derivatives of C. Now, I'm not trying to claim that this is the best of all possible worlds. I'm simply stating that it's the reality. And given that reality, overcoming the inertia to get existing C-oriented programmers to jump to a completely different programming language, such as Smalltalk, Lisp, ML, or Prolog, is non-trivial at best.
There was some question of non-Unix support for Perl. As far as non-Unix ports go, Perl runs on so many diverse sorts of systems that it's easy to lose track of them. Not only that, but it also ships (or will ship in the next release) as part of the standard O/S release. Perl in some form ships with, or can ship, with at least some systems from these vendors: Apple, BSDI, Be, Compaq, Data General, Debian, FreeBSD, HP, IBM, Microsoft, Novell, OpenBSD, Red Hat, SCO, SGI, Sequent, Siemens-Nixdorf, Slackware, Stratus, and Sun. Those are just standard systems. The major workstation vendors like SGI, HP, Sun, IBM, and DEC/Compaq are all shipping Perl with their current or upcoming release. That means it's in the standard vendor configuration, which is important to many people.
On the matter of Microsoft compatabilty for you MIS and IT types, we CS types have tried very hard to make sure that standard Perl programs try very hard to run everywhere. That doesn't mean you can't get at the Unix getpwuid() function or the Microsoft Win32::Process module if you want, but that's not the same as basic functionality that is expected runs everywhere. This includes portable systems programming as well. Basic systems programming functions in Perl like rename() and flock() are not restricted to those systems that support rename(2) and flock(2) syscalls, i.e. kernel traps. We use whatever emulation is necessary to provide the same semantics using whatever your system's primitives provide.
And we don't stop there. The POSIX fork(2) syscall, that simple, elegant, and incredibly powerful feature that has long formed an essential keystone for systems programmers, and one which Mr Bill has never figured out how to do, will be supported on Microsoft's systems as well. This will show up in the 5.6 release of Perl, which is now in late alpha and imminently passing into beta. That means your traditional multitasking server that calls accept() on a socket and then fork()s off a clone to handle the incoming connection will work even if you're a Prisoner of Bill.
If you aren't familiar with the wealth of Perl modules out there, or how easy it is to build and install them, you should look at this search engine.
Perl has seriously different design goals than Python. One of these was to be easy for Unix programmers to learn and use, both simple sh programmers and sophisticated C programmers. Another was to support incremental learning and incremental growth of the language itself. Another was to provide good support for multiple different programming styles (procedural, object oriented, and functional), which goes along with avoiding moral judgments about programming style issues and letting people program the way that comes naturally to them. Python supports both procedural and object-oriented programming reasonably well, but its support for functional programming is clumsy and unsatisfying. Without the nested lexical scoping in anonymous that languages like Perl and Scheme provide, there's only so much you can do. This is not in practice an onerous restriction, however.
Another was speed of execution; as a result of this design requirement, Perl's compiler is remarkably more clever than Python's, because it does quite a few more optimizations and special-case detection at compile time, so that run-time is more streamlined. This includes string-related issues like pattern matching, but also simple base programming features, such as when identifiers are looked up in symbol tables. Python was never designed to run fast, and by and large, it doesn't.
Perl was designed to conform itself to the programmer, not to make the programmer conform themself to the language. This is seen in the "do what I mean" (DWIM) principle. Matters such as memory management and strong typing are largely there to help the computer not the programmer. Because of this, you'll see Perl and Python take divergent paths when it comes to these matters. For example, Perl will automatically allocate space for strings, indexed arrays, and associative arrays as they are needed, without requirements of pre-growing the way Python's lists need. Another example is that Perl doesn't distinguish between 3/2 and 3./2 the way Python does. In Perl, a number is just a number, and if the compiler or run-time library needs to perform some promotions behind the curtain to do what the programmer meant, it goes and does it.
Perl was also intended to support short-cuts for common programming tasks so that expert programmers wouldn't be forever bogged down by spelling things out the long way. In short, it was designed to be expert-friendly, by which I mean that it did not become tedious for those who actually knew how to use it. One example of this is the multiple assignment statement of
@array[1,5,2,9] = @array[3,2,8,1]; # or likewise, via indirection @idx1 = (1,5,2,9) @idx2 = (3,2,8,1); @array[@idx1] = @array[@idx2];
Some of Python's design properties were that explicit is better than implicit, that general cases are better than special ones, and that simple features are better than complicated ones--even when this makes the programmer to put the simple features together in complicated ways. But like any language that actually gets used, these goals are not always followed. Compromises happen. I'm not going to sit here and point out all the warts and knobs in either language. Rest assured that they are there.
Do not be distracted by Python's whitespace issue nor by Perl's type-markers. These are both red herrings that aren't related to the core of what the language can truly do. Interestingly, both of these features commonly cited as negatives were actually added to ameliorate not to exacerbate legibility.
Despite Perl and Python starting from different sets of design criteria, they are, in most of the senses that really matter, the same language, just as C and Pascal are really the same language. I strongly encourage anybody who only knows one of them to go out at learn the other as well as you can in a week or two's worth of playing around. Try to write equivalent programs. By and large, you'll find that the final program takes more lines of code in Python than it does in Perl, and that the Perl version runs faster than the Python one. But not usually by a large amount. Usually it's just 20% or 30%.
But if the problem domain happens to be text manipulation, (and not just sed and awk style either), then the difference can be far more dramatic. It is not at all unheard of to find that Perl requires just 1/3 the code that the Python does, and that the Perl version runs in just 1/10 the execution time. Perl is not just about text processing, and there is no tool that's best for all jobs. But if there's one place where Perl outshines all competitors, this is that place. Even people who are heavy users of Python often turn to Perl for these tasks.
In my nearly two decades of habitation upon the Arpanet and its descendents, never before have I ever had the misfortune to witness so distressing a thread of messages as these. This unspeakably sickening invective against so kind a man, a man whom most of you never even knew, can have no other effect than to boggle the mind, wound the heart, and taint the soul with a nauseous stench.
Rich was always gentleman: pleasant, helpful, and courteous. Despite his fame and his skill, no prima donna was he. He was never bitter nor spiteful, never arrogant nor condescending. His humor and his insights inspired many of us, and not merely in our programming.
In the last few years that I came to know Rich a bit better as we shared a meal at random conferences scattered about the globe, I was always impressed by his irrepentantly positive attitude. Whatever the tale he told, whether a personal one relating to his children or his delightful rediscovery of the piano, a professional one related to programming and computers, or simply some incidental anecdote, that tale he presented with a childlike delight and glee. Rich displayed a perpetually positive attitude rare in a man even half his age. He was uplifting merely to be around.
Never was I so honored as on that day when Rich lamented not bringing his Perl Cookbook with him so he could get my autograph on it. I was deeply touched and completely surprised. Rich is acknowledged in the credits for his indirect help in preparing that book from our discussions of troff and systems programming matters. Despite his good taste and obvious skill, he had been for some time using Perl for various daily jobs. It's true that Rich had minor issues with Perl's cleanliness, but these were subsumed by the practical concerns of simply getting a job done easily and quickly. In short, it worked and he used it, and he was thankful it saved him time. The very things that the HTML crowd find hardest with Perl -- its Unix roots and proclivities -- Rich found immediately familiar and obvious. I am proud that I had ever so small a part in helping out a man who had tremendously helped me and thousands of others.
It is with nothing less than complete shock and surpassing shame that I have read here what so many insensitive malcontents have cruelly and unjustly scrawled. Doubtless these are the same twisted perverts who torture kittens and kick pregnant mothers, a sickness upon this medium and this planet. I hope these sociopaths find help soon, or at least remove themselves from the company of men and the gene pool.
Forget not this one inescapable fact: that where Rich has gone, so too inexorably goes each and every one of you walking shadows, and tragically sooner than you dare fathom. May you be remembered in the same measure as have you remembered those who preceded you down that lonesome path to dusty death.
It does not take a particularly compassionate and sensitive person to be sickened and hurt by these inexpressibly horrible postings. It takes nothing but a decent and caring human being, the sort of which we seem to have so few of these days--and today, to our loss, one fewer.
Off topic my ass. The followup I was replying to off topic, but was it marked that way? No, it was marked up to "interesting" even though it was completely wrong. So I corrected it. What do I get for my trouble? Offtopic? I think not. Go back and zap the first guy, and then zap him again for posting the wrong answer. What do you want us to do, ignore things that are marked "interesting" when they're wrong?
You cad! You've just given away the ultimate secret of billennium! Microsoft's upcoming but still top-secret FreeBSD-derived operating system for Merced servers is internally called Virix, because it's bug-compatible with old Wintel exploits.
Hey dude, what are "plurls"? Something bad that happens to your lungs?:-) There's a saying that all spelling or grammar flames must themselves all contain a spelling or grammar error. Apparently you're no exception.
But you may have something there on vir versus virus. The former word has been more productive in English than the latter.
I guess we'd all better be careful not to commit viricide (the slaying of men or of husbands) when we're merely planning virucide (killing of viruses) eh?:-)
Virii is a word. Plural for Virus. But you're correct in that it's being wrongly used for the description of the singular.
Oh, please. Not this again. Don't people ever learn? And it's deeply offensive that some moderator has mis-moderated this completely incorrect statement to "informative". It's hardly informative. It's downright wrong.
Rather than repeat the entire discourse here, please see my article on What's the Plural of `Virus'? for the results of thorough research into both the English and the Latin forms.
And moderators, please consider fixing the cited article, which is overrated. It's not informative. It's simply, obviously, and provably completely wrong.
If the plural of "radius" is "radii", then the plural of "virus" (assuming you are using Latinish pluralization) should be "viri".
Actually, this doesn't necessarily follow in Latin. There are a lot of -us rules. It depends on which declension and gender you're speaking of. 2nd declension masculines are the most common, such as "radius", "filius", "focus", "locus", "fungus", and many other familiar words. But it's not always that way. The plural of "corpus" is "corpora", and "genus" goes to "genera". There's also the "status", "hiatus", and "apparatus" set, which just change the length of their final vowel, making something that sounds like "bus" start sounding like "boose". There are other issues, too, as in "rebus" or "ignoramus".
Washington DC - After more than two years in and out of the courts, The Supreme Court today upheld the lower courts' ruling that the viewing of a website in any other layout and format other than the one set-up by that site's authors.
The original suit was brought by a cartel of web business all over the country, initially sponsored by by the Direct Marketers Association (DMA). The defendants were Junkbusters Inc and thirty-four other businesses and individuals who had created software to let users by-pass blinking pictures, pop-ups advertisements, and intended controls on font, color, size, and backgrounds.
This means that the lower courts' previous award of seventeen billion dollars is due immediately. Upon hearing the ruling, Junkbusters immediately filed for bankruptcy, but it is widely believed that their the software authors and corporate directors will be personally liable. Furthermore, the text-based web browser, Lynx, is now illegal to use except on your own sites, as are any proxies that filter or rewrite incoming webpages in any way, including the suppression of blinking text. Both Microsoft and AOL Microsystems must immediately issue mandatory patches to their browser to disable the users from being able to disable automatic loading of images or moving GIFs.
A joint statement issued by the not-for-profit American Association for the Blind and the International Epileptics Support Center decried the decision as essentially barring their members from the web. The DMA praised the decision, stating that ``the needs of Commercial Enterprise would no longer be stymied by Communists and other PBS and NPR sympathizers.''
President Gore also weighed in with his pleasure at the decision, adding, ``This just blasted away the roadblocks in my Information Superhighway. Next term, we're going to the stars!'' This appeared to be an oblique reference to his constituents' efforts to gather re-election funds through click-through advertising fees. The president was in closed conference this afternoon with top members of Congress and with his InfoBahn Czar about how soon they could implement a new mandatory A-chip to be placed in televisions and VCRs so TV and video advertisements could no longer be avoided by consumers through editing, muting, fast-forwarding, or channel-surfing.
A hacker squad known only as the Spamvert Amnesty League (SAL) briefly seized control of the Whitehouse website, where they replaced the campaign advertisements with malicious notices of revenge against all spamvert supporters everywhere. At the same time, a digitized parody video of Clockwork Orange appeared on the Fox channel's satellite download in which consumers were held prisoner as commercial advertising was blasted into their propped-open eyes and ears. Credits on the video listed the SAL, and their choice of the European anthem, Beethoven's Ninth Symphony, has led authorities to look in Europe for their homebase, since as we all know, uncounted intellectuals, artists, anti-commercial socialist sympathizers, and other commie rats have long taken refuge there from the righteous wrath of invasive American Plutocracy.
``Contempt, rather than celebration, is the proper response to advertising and the system that makes it possible.''
It's all memory. All (all) users say "I'm out of memory" when their hard disks are full.
That's severely annoying to almost all of us. But it's common enough here that I did cover it in my geekspeak correspondence table. The sample program there reports: When I say memory, I mean what you would call RAM, but for you memory means what I would call disk space.
When we get enough contest entries, we'll have a nice translator tool that we can all use to talk to the um, regular people.:-) Send me mail with any suggestions or programs. Any language is ok.
Why aren't they using the standard Linux operating system, then? Why use this YellowDog thing instead of RedHat?
There is no such thing as a standard Linux OS, unless you're defining OS==kernel, as many of us do. The geek-to-luser translation table notes that When I say operating system, I mean what you would call kernel, but for you operating system means what I would call kernel + libraries + daemons + tools + GUI. I assume that you mean the latter definition. If so, there is no such "standard Linux operating system". As for the geek definition, yes, there are standard kernels with standard version numbers. But you'll find that many folks who bundle and sell Linux solutions have their own additional drivers and config tools, etc. And these include people whom nearly anyone would consider "the good guys", such as VA. Special kernel patches and/or drivers are not at all uncommon. But that's still a pretty standard kernel.
Guys, our only hope is to send Redhat mail about this nastiness. Right now, I can't read their site except using lynx, unless I use my hand-written proxy that strips out all the font changes and width stuff. I just sent webmaster@redhat.com mail explaining why I couldn't read their site. I also posted them at the admittedly Spartan but functional html design guidlines. I encourage you to do likewise, after your own fashion, of course.
Wow. That site really is bad. I suggest that folks all mail their webmaster about it. I can only read their site via lynx. I don't think they've read the site design guidelines. Alas.
Slashdot Mirror
The more you stray from line-based text files that you can easily call things like awk and grep on, the more you'll alienate some people. I don't believe there's a version of awk or grep that handle XML-based records. This is pretty important to tool-minded people.
As you see, it's so easy even a script kiddie could use it. And they do.
I have a classical citation that shows virus being invariant in the genitive. I challenge you to produce any classical instance of virus in the plural.
It's even possible that virus pertained not to the second but to the fourth declension, which would change the matter as well.
The word becomes invariant in most modern languages, but for some reason, English elected these viruses rather than *these virus as one might otherwise expect from the modern Romance tongues.
You can read Far More Than Everything You Ever Wanted to Know about The Plural of Viruses if you'd like.
On the other hand, many of the mod_perl applications I've looked at have been sophisticated and clean. They've actually been designed and structured. They're a pleasure to read and to maintain. And they're written in the same language as those CGI scripts from hell that the script kiddies mutilate. Yet it seems like it's galaxies far removed.
Interesting, eh?
I believe this is saying more about the average CGI script kiddie versus Apache mod_perl hacker than it is saying about Perl. But yes, it's easy to write bad perl code. I guess it's easy to write bad C++ code too, but the barrier to entry is higher.
I don't know that there's ever been a language written in which it's been the least bit hard to write bad code. If you outlaw bad code, only outlaws will code badly. :-)
Sigh.
I wonder what that thing I've been on since the very early 80s really is? I'd swear that it was the internet. Has the media truly forgotten where this all came from?
And by 1988, I certainly had internet from home, including a private link into my employer's inner sanctum of customer and engineering data. And I from there was able to tap into our clients' own private systems as needed when I was doing customer service. Now, it wasn't the clients' business info we were getting, but still.
Has the mass media ever gotten anything right?
Forced to Buy Software in Duplicate
To confront these criticisms, the specialized services of Bercy must put gather up the procedures already begun across various departments in order to closely examine the various lawsuits. "If this investigation shows abnormal situations or obstacles with market rules, we'll be checking with the competition," Bercy was told. The essential point is that Microsoft would risk legal action and fines. One of the first to address the complaint folder on fraud control is a compsci teacher at some school in Paris, Roberto Di Cosmo. A computer enthusiast and the author of a vitriolic book against Microsoft, Roberto Di Cosmo thinks the multinational abuses its position as leader.
"When you buy a computer today," he explains, "you buy the box and the software accompanying it. And even if the latter represents some 20% of the price, this is never spelled out," he laments. On a computer costing five thousand francs, some one thousand francs would go toward software. One of these programs is Windows 98, Microsoft's operating system, which is essential for running the machine. "Because computers are sold already equipped with Windows, as soon as you change computers, you end up buying Windows again!" explains Roberto Di Cosmo. For months now, this computer expert has in vain demanded from his retailer refunds for several programs that he now has duplicates of, since he hasn't sold his used computers.
Promise of Compensation
"Indeed, this situation can appear abnormal ", comments Jérôme Franck, a lawyer specializing in consumer law. But to date, only one purchaser in France, a teacher from Montpellier, has been reimbursed by his retailer. On this matter, the Microsoft position seems to evolve. "We are ready to refund," we were told yesterday by Vahé Torossian, director at Microsoft France of divisions manufacturer and general public and therefore specialist in licensing questions. "We mislead no one," he adds. "When you buy a new car, you don't ask your manufacturer to install your old car's engine in the new car. Similarly, Windows 98 is the engine of each computer". That said, Vahé Torossian assures that his firm is ready with possible refunds. "If someone doesn't care to use Windows 98, they can bring back their computer to thier retailer, who will fill out a slip, then refund it", he states. That's good news for Microsoft's opponents, even if the amount of these "redunds" is still unknown.
[End Translation]
It might be possible to leverage off the "parental control" issue here. I know more than one family who has ditched the TV because they didn't want their children corrupted by the interminable advertspam. This is a real issue for some parents. It's just as much part of letting parents have a say in what kind of crap gets stuck in their kids' brains as the sex and violence and adult situations bits.
And it's a real issue to some non-parents, as well. I'd rather a Blue Screen of Death than the constant adverts.
You might also look at pvdb . It gives you three xterms: one for the perl debugger, one for vi on whatever source file the debugger has break-pointed into, and one for stdin and stdout. As you hit breakpoints and step through, it controls vi for you to move you around.
1. Questions
The most important issue, and one which surprisingly few posters have addressed, is to identify the properties that are desirable in a 1st programming language. Identify also which properties are considered undesirable in that same environment. Once you've done a thorough study of these issues, only then can you analyse existing programming languages for how well they fit these criteria, or to create a new one that better satisfies them than existing languages. But until you know against what metrics these languages are to be judged, you cannot objectively do so.
Is this ideal beginner-oriented programming language also a language that's good for other focused domains? Will the decisions you've made in designing or selecting this ideal beginner-oriented programming language render it less than optimal for programming that isn't oriented toward non-programmers? Or if you add in properties conducive to non-beginner programming, will this compromise your goals of creating something for beginners?
Can we leverage our natural cognitive strengths in learning natural languages to learn a programming language? Does this imply that we acquire language more readily when we have lots of easy, contextual examples than we would if presented with sets of rules and axioms? Does this mean learning by a usable subset of a language first, and only adding sophistication if and when it becomes necessary? If so, does this not engender dialectical subsets? Would a beginner (equivalent to a seven-year-old speaker of his native tongue) confronted by a complex piece in the language (say, equivalent to a doctoral thesis) find himself somewhat lost? Would it be better to throw out the language you'd learned until age seven and start a new one so this can't happen, or is it better to learn incrementally?
Does it make sense to expect the same language that is used for one domain to be equally applicable to an unrelated domain? Aren't domain-specific languages both more powerful and more user-friendly?
Are we talking about a particular age group, such as ages 9-12, 13-17, or 18-21? Does this affect our criteria? Should a university really be used as nothing but a high-classed tech school as feeders for industry? If so, shouldn't diverse core curricula emphasizing reading, writing, and effective skills get more attention?
Do we understand the differences between "IT" training and "CS" training? What's a business programmer, and how is that different than a programmer? Is the goal to teach programming, or is it to teach computer science? Or are we just talking about teaching computer use? Since when is a computer science degree required to use a computer, or even administrate it?
How do you define "readability"? Does resemblance to a natural language suffice? Is this a good thing? Remember one notorious attempt to create a programming language that even non-programmers could use cursed us with Cobol. Wouldn't it be nice to avoid that next time around?
Is readability culturally biased? Can a language designed to be easy for Unix users to learn be equally easy for non-Unix users? Can a language designed to be easy for non-Unix users to learn be equally easy for Unix users? Think of it this way: Does your knowledge of Greek help you learning Russian? Is it the character sets, or are there more important underlying similarities? Is a language designed to be used by people who know language XXX going to be different than one designed for those ignorant of XXX? Do semantics grow out of syntax (ordering, positioning), or should they be explicitly reinforced by inflection markers (singular vs plural, noun vs verb, etc)?
Should a programming language require a fancy, hand-holding IDE before it can be used effectively, or should a line editor suffice? How much hand-holding is useful to the beginner but annoying to the expert? Can you make a programming language that's designed to be completely learnable in a very short time that doesn't rule out its use later down the road? Is "user-friendly" well defined? Does "user-friendly" always denote "expert-hostile"? Will software that pleases one set also please the other set? Should it? Are languages designed for short-term use or long-term use? Where then should optimization occur?
That's certainly plenty to think about, and mostly what I just did is provide important questions that should be thought through. In many of the questions, there is no single right answer, but there are consequences. Try answering the questions in more than one way, and then compare the resulting trade-offs that arise depending on which path you took.
2. Answers
I certainly don't have all the answers to those questions. But I do have some comments on the Perl matters. The first is that Perl and Python are actually essentially the same language, and that there are a great deal of other sorts of languages out there that a computer scientist should be exposed to. Much like the warning to beware the man of one book, also be wary of the programmer of just one programming language.
And before you can begin to compare two languages, you actually have to know them both! Oh, not necessarily with equal fluency, but you actually have to have taken the time and energy to play with them, to sound them out in real situations. Superficial assessments based upon surface appearances are useless.
The "scripting language" versus "programming language" bigotry is nothing but cultural arrogance borne out of theoretic ignorance. I'm aware of Ousterhout's paper, and I have responded to it before. John is a very bright man, but like all of us, he carries with him his own historical baggage from the past and unfolding agenda for the future.
In this case, this a false dualism of "scripting" versus "programming" does nothing but harm. It has virtually no basis in theory, and little in practice. The assertion that byte-compiled Perl or Python can't handle certain tasks but that by merit of being compiled to machine language, C or Pascal or Ada or Modula automatically can--well, this is completely ludicrous.
Rob Kolstad long ago conjectured the following: "The success of a new programming language is directly proportionate to its resemblance to C." Perhaps a more accurate statement would be "The degree to which a new programming language will be embraced by C programmers is directly proportionate to its resemblance to C." And now you can swap in other programming languages in that equation.
As far as real-world programming goes, I assert that the majority of it gets done using C or a derivative of the same; and yes, I consider Awk, C++, Java, and Perl to be derivatives of C. Now, I'm not trying to claim that this is the best of all possible worlds. I'm simply stating that it's the reality. And given that reality, overcoming the inertia to get existing C-oriented programmers to jump to a completely different programming language, such as Smalltalk, Lisp, ML, or Prolog, is non-trivial at best.
There was some question of non-Unix support for Perl. As far as non-Unix ports go, Perl runs on so many diverse sorts of systems that it's easy to lose track of them. Not only that, but it also ships (or will ship in the next release) as part of the standard O/S release. Perl in some form ships with, or can ship, with at least some systems from these vendors: Apple, BSDI, Be, Compaq, Data General, Debian, FreeBSD, HP, IBM, Microsoft, Novell, OpenBSD, Red Hat, SCO, SGI, Sequent, Siemens-Nixdorf, Slackware, Stratus, and Sun. Those are just standard systems. The major workstation vendors like SGI, HP, Sun, IBM, and DEC/Compaq are all shipping Perl with their current or upcoming release. That means it's in the standard vendor configuration, which is important to many people.
Of course, Perl I run on nearly anything, including: 3b1, aix, altos486, amigaos, apollo, aux, beos, bsdos, convexos, cxux, cygwin32, dcosx, dec_osf, dgux, dos_djgpp, dynix, dynixptx, epix, esix4, fps, freebsd, genix, gnu, greenhills, hpux, irix, isc, linux, lynxos, machten, mint, mips, mpc, mpeix, ncr_tower, netbsd, newsos4, next, openbsd, opus, os2, os390, posix-bc, powerux, qnx, rhapsody, sco, solaris, stellar, sunos, svr4, ti1500, titanos, ultrix, umips, unicos, unicosmk, unisysdynix, utekv, uts, uwin, and vmesa.
On the matter of Microsoft compatabilty for you MIS and IT types, we CS types have tried very hard to make sure that standard Perl programs try very hard to run everywhere. That doesn't mean you can't get at the Unix getpwuid() function or the Microsoft Win32::Process module if you want, but that's not the same as basic functionality that is expected runs everywhere. This includes portable systems programming as well. Basic systems programming functions in Perl like rename() and flock() are not restricted to those systems that support rename(2) and flock(2) syscalls, i.e. kernel traps. We use whatever emulation is necessary to provide the same semantics using whatever your system's primitives provide.
And we don't stop there. The POSIX fork(2) syscall, that simple, elegant, and incredibly powerful feature that has long formed an essential keystone for systems programmers, and one which Mr Bill has never figured out how to do, will be supported on Microsoft's systems as well. This will show up in the 5.6 release of Perl, which is now in late alpha and imminently passing into beta. That means your traditional multitasking server that calls accept() on a socket and then fork()s off a clone to handle the incoming connection will work even if you're a Prisoner of Bill.
If you aren't familiar with the wealth of Perl modules out there, or how easy it is to build and install them, you should look at this search engine.
Perl has seriously different design goals than Python. One of these was to be easy for Unix programmers to learn and use, both simple sh programmers and sophisticated C programmers. Another was to support incremental learning and incremental growth of the language itself. Another was to provide good support for multiple different programming styles (procedural, object oriented, and functional), which goes along with avoiding moral judgments about programming style issues and letting people program the way that comes naturally to them. Python supports both procedural and object-oriented programming reasonably well, but its support for functional programming is clumsy and unsatisfying. Without the nested lexical scoping in anonymous that languages like Perl and Scheme provide, there's only so much you can do. This is not in practice an onerous restriction, however.
Another was speed of execution; as a result of this design requirement, Perl's compiler is remarkably more clever than Python's, because it does quite a few more optimizations and special-case detection at compile time, so that run-time is more streamlined. This includes string-related issues like pattern matching, but also simple base programming features, such as when identifiers are looked up in symbol tables. Python was never designed to run fast, and by and large, it doesn't.
Perl was designed to conform itself to the programmer, not to make the programmer conform themself to the language. This is seen in the "do what I mean" (DWIM) principle. Matters such as memory management and strong typing are largely there to help the computer not the programmer. Because of this, you'll see Perl and Python take divergent paths when it comes to these matters. For example, Perl will automatically allocate space for strings, indexed arrays, and associative arrays as they are needed, without requirements of pre-growing the way Python's lists need. Another example is that Perl doesn't distinguish between 3/2 and 3./2 the way Python does. In Perl, a number is just a number, and if the compiler or run-time library needs to perform some promotions behind the curtain to do what the programmer meant, it goes and does it.
Perl was also intended to support short-cuts for common programming tasks so that expert programmers wouldn't be forever bogged down by spelling things out the long way. In short, it was designed to be expert-friendly, by which I mean that it did not become tedious for those who actually knew how to use it. One example of this is the multiple assignment statement of
Some of Python's design properties were that explicit is better than implicit, that general cases are better than special ones, and that simple features are better than complicated ones--even when this makes the programmer to put the simple features together in complicated ways. But like any language that actually gets used, these goals are not always followed. Compromises happen. I'm not going to sit here and point out all the warts and knobs in either language. Rest assured that they are there.
Do not be distracted by Python's whitespace issue nor by Perl's type-markers. These are both red herrings that aren't related to the core of what the language can truly do. Interestingly, both of these features commonly cited as negatives were actually added to ameliorate not to exacerbate legibility.
Despite Perl and Python starting from different sets of design criteria, they are, in most of the senses that really matter, the same language, just as C and Pascal are really the same language. I strongly encourage anybody who only knows one of them to go out at learn the other as well as you can in a week or two's worth of playing around. Try to write equivalent programs. By and large, you'll find that the final program takes more lines of code in Python than it does in Perl, and that the Perl version runs faster than the Python one. But not usually by a large amount. Usually it's just 20% or 30%.
But if the problem domain happens to be text manipulation, (and not just sed and awk style either), then the difference can be far more dramatic. It is not at all unheard of to find that Perl requires just 1/3 the code that the Python does, and that the Perl version runs in just 1/10 the execution time. Perl is not just about text processing, and there is no tool that's best for all jobs. But if there's one place where Perl outshines all competitors, this is that place. Even people who are heavy users of Python often turn to Perl for these tasks.
Learn as much as you can.
Rich was always gentleman: pleasant, helpful, and courteous. Despite his fame and his skill, no prima donna was he. He was never bitter nor spiteful, never arrogant nor condescending. His humor and his insights inspired many of us, and not merely in our programming.
In the last few years that I came to know Rich a bit better as we shared a meal at random conferences scattered about the globe, I was always impressed by his irrepentantly positive attitude. Whatever the tale he told, whether a personal one relating to his children or his delightful rediscovery of the piano, a professional one related to programming and computers, or simply some incidental anecdote, that tale he presented with a childlike delight and glee. Rich displayed a perpetually positive attitude rare in a man even half his age. He was uplifting merely to be around.
Never was I so honored as on that day when Rich lamented not bringing his Perl Cookbook with him so he could get my autograph on it. I was deeply touched and completely surprised. Rich is acknowledged in the credits for his indirect help in preparing that book from our discussions of troff and systems programming matters. Despite his good taste and obvious skill, he had been for some time using Perl for various daily jobs. It's true that Rich had minor issues with Perl's cleanliness, but these were subsumed by the practical concerns of simply getting a job done easily and quickly. In short, it worked and he used it, and he was thankful it saved him time. The very things that the HTML crowd find hardest with Perl -- its Unix roots and proclivities -- Rich found immediately familiar and obvious. I am proud that I had ever so small a part in helping out a man who had tremendously helped me and thousands of others.
It is with nothing less than complete shock and surpassing shame that I have read here what so many insensitive malcontents have cruelly and unjustly scrawled. Doubtless these are the same twisted perverts who torture kittens and kick pregnant mothers, a sickness upon this medium and this planet. I hope these sociopaths find help soon, or at least remove themselves from the company of men and the gene pool.
Forget not this one inescapable fact: that where Rich has gone, so too inexorably goes each and every one of you walking shadows, and tragically sooner than you dare fathom. May you be remembered in the same measure as have you remembered those who preceded you down that lonesome path to dusty death.
It does not take a particularly compassionate and sensitive person to be sickened and hurt by these inexpressibly horrible postings. It takes nothing but a decent and caring human being, the sort of which we seem to have so few of these days--and today, to our loss, one fewer.
Find a clue. Now, apply it.
But you may have something there on vir versus virus. The former word has been more productive in English than the latter.
virial viricide virid viridene viridescence viridescent viridian viridigenous viridine viridite viridity virific virify virile virilely virileness virilescence virilescent virilify viriliously virilism virilist virility viripotent viritrate
virucidal virucide viruela virulence virulency virulent virulented virulently virulentness viruliferous virus viruscidal viruscide virusemic viruses virus's
I guess we'd all better be careful not to commit viricide (the slaying of men or of husbands) when we're merely planning virucide (killing of viruses) eh? :-)
Rather than repeat the entire discourse here, please see my article on What's the Plural of `Virus'? for the results of thorough research into both the English and the Latin forms.
And moderators, please consider fixing the cited article, which is overrated. It's not informative. It's simply, obviously, and provably completely wrong.
You can read more about this in my article on What's the plural of virus?.
Washington DC - After more than two years in and out of the courts, The Supreme Court today upheld the lower courts' ruling that the viewing of a website in any other layout and format other than the one set-up by that site's authors.
The original suit was brought by a cartel of web business all over the country, initially sponsored by by the Direct Marketers Association (DMA). The defendants were Junkbusters Inc and thirty-four other businesses and individuals who had created software to let users by-pass blinking pictures, pop-ups advertisements, and intended controls on font, color, size, and backgrounds.
This means that the lower courts' previous award of seventeen billion dollars is due immediately. Upon hearing the ruling, Junkbusters immediately filed for bankruptcy, but it is widely believed that their the software authors and corporate directors will be personally liable. Furthermore, the text-based web browser, Lynx, is now illegal to use except on your own sites, as are any proxies that filter or rewrite incoming webpages in any way, including the suppression of blinking text. Both Microsoft and AOL Microsystems must immediately issue mandatory patches to their browser to disable the users from being able to disable automatic loading of images or moving GIFs.
A joint statement issued by the not-for-profit American Association for the Blind and the International Epileptics Support Center decried the decision as essentially barring their members from the web. The DMA praised the decision, stating that ``the needs of Commercial Enterprise would no longer be stymied by Communists and other PBS and NPR sympathizers.''
President Gore also weighed in with his pleasure at the decision, adding, ``This just blasted away the roadblocks in my Information Superhighway. Next term, we're going to the stars!'' This appeared to be an oblique reference to his constituents' efforts to gather re-election funds through click-through advertising fees. The president was in closed conference this afternoon with top members of Congress and with his InfoBahn Czar about how soon they could implement a new mandatory A-chip to be placed in televisions and VCRs so TV and video advertisements could no longer be avoided by consumers through editing, muting, fast-forwarding, or channel-surfing.
A hacker squad known only as the Spamvert Amnesty League (SAL) briefly seized control of the Whitehouse website, where they replaced the campaign advertisements with malicious notices of revenge against all spamvert supporters everywhere. At the same time, a digitized parody video of Clockwork Orange appeared on the Fox channel's satellite download in which consumers were held prisoner as commercial advertising was blasted into their propped-open eyes and ears. Credits on the video listed the SAL, and their choice of the European anthem, Beethoven's Ninth Symphony, has led authorities to look in Europe for their homebase, since as we all know, uncounted intellectuals, artists, anti-commercial socialist sympathizers, and other commie rats have long taken refuge there from the righteous wrath of invasive American Plutocracy.
When we get enough contest entries, we'll have a nice translator tool that we can all use to talk to the um, regular people. :-) Send me mail with any suggestions or programs. Any language is ok.
A drive has about as much to do with a disk as has a wheel with a tire. I wonder whether peecee weenies get flat wheels. :-)
Dan Gillmor's Messaging flap makes Microsoft, AOL instant hypocrites is great, and No truce in AOL, Microsoft war is also worth a read.
Guys, our only hope is to send Redhat mail about this nastiness. Right now, I can't read their site except using lynx, unless I use my hand-written proxy that strips out all the font changes and width stuff. I just sent webmaster@redhat.com mail explaining why I couldn't read their site. I also posted them at the admittedly Spartan but functional html design guidlines. I encourage you to do likewise, after your own fashion, of course.
Wow. That site really is bad. I suggest that folks all mail their webmaster about it. I can only read their site via lynx. I don't think they've read the site design guidelines. Alas.