Slashdot Mirror

I think that the GNU Y2K readiness list is a bit disturbing. CVS-1.8 and 1.9 are not ready, and no newer version is listed as having been tested. Groff is not ready... ouch...


I also fully expect that there will be major and expensive breakdowns of computer systems. There is far too much stupid code out there being relied on. I had the same reflex as nearly every programmer... 'Ahh, it won't matter except for silly things like sorting your checkbook by date.' I still don't really know -why- it matters, but when people have done readiness-testing (setting the date to Dec. 31, 1999 and watching it rollover) computer equipment has done things like stop a power plant from working. Why? Probably some linkage between database functions and power functions. Or a failure in a cron-like system. Who knows.


As programmers we think it's 'obvious' that it isn't 'really' a problem. But it is a problem. It's just like when it's 'obvious' that it can't be -your- code that introduced the bug... until you step through it with a debugger and realize that it is. You can argue until you're blue in the face about why it shouldn't be a problem, but the empirical evidence disagrees.


Well, Lawyers, Liars and Perl gives a better explanation of why there are Y2K issues even in modern code better than I can do.

--Parity

There is an online Python/Perl phrasebook if you want to compare the two languages in action. A lot of the information is based on Tom Christiansen's Perl Data Structures Cookbook, as well as help from the two languages' respective creators, Larry Wall and Guido van Rossum. It shows how you'd accomplish a wide array of pretty common tasks in each languages. It's ample fodder for clear-headed analysis of all-out flameage...it's your pick.

I'll have to agree with the site's author: Python wins for readability, approach to OOP, the blessed absence of $, @ and % characters in front of variables (never liked 'em in Basic) and the homage to a great comedy act (and the convention of using "eggs" and "spam" instead of "foo" and "bar" in code examples). Perl wins for its better handling of regular expressions, quoting and having lots of people who know it. They're quite similar and becoming more so, especially since the re module in Python has been changed to be quite similar to Perl's regular expression functions. Performance is pretty close.

It may boil down to the language the alpha geek prefers or the project already uses, if you drain religion from the argument...but what fun would that be?

• Your only limit is your knowledge.
• Everything is Open Source.
• Most of the hard work is already done and wrapped up in free modules written in Perl (with source).
• Perl regular expressions are a secret weapon that you can use to slain many ugly monster problems.
• Many nifty features are being added to Perl, without making it much bigger or slower.
• Is very portable (Microsoft gave money to enhance Perl in Windows).
• With Perl, it is easy to generate code in any other programming language.

If your CGI follows a Parse-Calculate-Print pattern as opposed to a Parse-Fetch-Print pattern, you can use Perl where it makes sense to (ie the "parse" and "print" parts) and C where speed is important (ie the "calculate" part)

Herein lies the beauty of XSUBs.

http://www.perl.com/pub/ doc/manual/html/pod/perlxstut.html

This is how many of the most useful CPAN modules are written. The "high level", perl code calls your C routines to do the heavy lifting.

Plus this approach forces you to componentize your software in a smart way, making it easier to give back to the community by publishing your work on CPAN :-)

This is not quite the same procedure, but you might be interested in the diary kept by Larry Wall Author of Perl Busy Man last year about his cornea transplant.

In some of the later entries, Larry writes that he might consider LASIK in the future, but evidently that hasn't happened so far.

You're referring to Perl Power Tools: The Unix Reconstruction Project.

On related note, ActivePerl (Perl for Win32) 5.6, which is due out next month will have support for fork(), so one of the biggest portability hurdles in moving your scripts from Unix to Win32 should disappear.

Cheers,
ZicoKnows@hotmail.com

You're probably thinking of Tom C's perl power tools, http://language.perl.com/ppt/.

James

Isn't perl written in perl, currently?

No, Perl is interpreted, so it's not possible for it to interpret itself. How would the interpreter run, if it were in Perl? (Actually, Perl compiles to bytecode - but that needs interpreting by a C program.)

As perlfaq1(1) says:

You'll notice that perl is not itself written in Perl.

Before I was at all versed in the Ext2 filesystem I noticed this issue because of Perl. All anyone really needs to do it put the 'problem' in the proper perspective.

The short of it is that, yes, you should be able to delete a file that you cannot modify. Since I'm no Guru, check out this link from the Perl docs.

Hope that helps!

Gregg

Strictly speaking it would be viri..

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

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.

The plural for "virus" is viruses.

Yes, take a look at tchrist's explanation, What's the Plural of `Virus'?.

Perl/DBI are full GPL

If you know perl allready !! ... Juste take the DBI.

" The Database Interface. The Perl DBI initiative has standardized the interface to a number of commercial database engines, so that you can move from, say, Oracle to Sybase with a minimum of effort. You'll find DBD::DB2, DBD::Informix, DBD::Oracle, DBD::QBase, DBD::Sybase, and DBD:mSQL inside the DBD module set. If you're looking for a database manager instead of an angine, see the AnyDBM_File module. "

more info: http://www.perl.com/CPAN/modules/by-module/DBI/

I think that "windows only geeks" (an oxymoron?) would benefit more from a Win32 port of perl than from some random VB application.

This will also help wean them from the GUI nipple.

Or, on the other hand, they could just use their Y2k-compliant PowerPads and render the binary into hexadecimal/octal and then into letters by looking up the ASCII values. Which is obviously the most geeky way to do it, and will earn them massive karma points.

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.

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.

The case is air-tight:

JavaScript is the fastest growing programming language (see table below).

The product of JavaScript's market share times its growth rate is the highest of any language. (see table below).

JavaScript source code is inherently "open" for "Everyone" browsing the web. "Everyone" can learn by example at will.

JavaScript is the most widely deployed interpreter. "Everyone" has a web browser.

JavaScript's dynamic features, including functions as first class objects with slots, put it in the same level of power as systems like CLOS. CLOS is, arguably, at least as powerful and general as Python. The fact that an appropriate, CLOS-like framework has not yet been widely deployed for JavaScript merely indicates developers are too distracted by immediate profit opportunities to think straight about JavaScript. This is a temporary stupor.

Back sometime in June, Randall J. Burns took Ted Shieh's figures, later reported by Larry Wall and computed growth rate in demand. We get an interesting picture:

C++.....Java......VB....Cobol....Perl...JavaScript ...Smalltalk...Python
-14%....+17%......-4%...-43%.....+18....+51%...... ...+1%.........+23%

When multiplied by the approximate market share:
C++.....Java......VB....Cobol....Perl...JavaScript ...Smalltalk...Python
40%.....25%.......10%...3 1/2%...+10....+10%.........1%..........1/2%

We get an interesting future dominance metric:
C++.....Java......VB....Cobol....Perl...JavaScript ...Smalltalk...Python
-560....340.......-40...-111.....180....510....... ...1...........12

I've always wondered how difficult it would be to embed the Perl engine into the Linux kernel. Then people could use people to write their device drivers. Most device drivers just slice and dice data streams, which is exactly what Perl is great at doing!

While not quite a PerlOS, some Perl Mongers are rewriting the classic Unix commands in Perl. It's called the Perl Power Tools:
The Unix Reconstruction Project. Many Unix commands, like more, ls, grep... use C to dangerously reimplement functionality that is already in Perl. Using Perl would put an end to buffer overruns and other accidents in Unix commands, improving security.

There are only a few IDEs for both Perl/Tk and Perl/Gtk at this time, though it appears that more and more commercial tool developers are at least making Perl sensitive code editors these days. However, in reading through the comments this question brought forth I noticed that noone gave the CPAN directory for Perl/Gtk which is either: $CPAN/authors/Kenneth_Albanowski/
or $CPAN/modules/by-module/Gtk/ Which I hope will prove useful to some folks.

Don't be a fool. First of all, radius is a 2nd declension masculine noun. Its stem is "radi-". You change "-us" to "-i" in the plural, and get "radii", because "radi-" + "-i" gives you that. Now, look at "virus". Let's pretend it's a 2nd declension masculine. It's not, but I'll humor you. If it were, its stem would be "vir-", because the ending is "-us", not "-s". There are no "-s" endings. Now, if you were to take the rule of stem + "-i", that would give you "viri", not "virii". But you don't do that either. That's because virus is not 2nd declension masculine. It's 2nd declension *NEUTER*. That means it gets a completely different set of inflections. Now, 2nd declension neuters in -us were very very rare. Most are in -um. There are only four or so in -us. Go read Tom's report. I'm tired of giving you a Latin lesson. Read it, top to bottom, and you'll know a lot more. And you might even stop talking about "geni and specieses" by then, and maybe people will stop confusing you for a k3w1t0kkin script kiddie. Maybe.

You can't get virii. They don't exist. Are you thinking of memes? Pheromones? Science-Fantasy nanotechnology?

There are no "genetically engineered virii" because, you see, there are no virii. Thank you for playing, and please try again next year after you've successfully passed English 101. For extra credit, take Latin 101 immediately thereafter so you can effect an educated air without in fact blathering pseudo-English k3w1t0k.

Don't assume "virii" is correct. It's just plain wrong.

You will never have custom virii. That's because virii is not a word.

I'm sorry that you're wrong, but there are no virii.

There is no such word as virii. The only English plural is viruses, and Latin didn't even have one. Danged script kiddies and their k3w1t0k.

Virii is a word. Plural for Virus. But you're correct in that it's being wrongly used for the description of the singular.

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.

No, Chris. There are no virii.

Wrong. The plural of virus is simply viruses. Why is it that script kiddies manage to flunk both English and Latin?

You can't make `virii', because it's not a word.

If the plural of "radius" is "radii", then the plural of "virus" (assuming you are using Latinish pluralization) should be "viri".

You can read more about this in my article on What's the plural of virus?.

Please, please, please get a proofreader. I can't tell what you're even saying. Through the manipulation of what?

And hasn't that tchrist article from the last time we went through this smacked around the script kiddies and their k3w1t0k yet? It's bad enough when the followups k3w1t0k, but to see it in a feature article, ARGGGH!

It's all memory. All (all) users say "I'm out of memory" when their hard disks are full.

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?

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.

That's why I wrote the diversity guidelines for HTML creation. I talk about how evil absolute pixels are, and also these epileptic pages.

1. controller = hard drive
2. disk = hard drive
3. disk controller = hard drive
4. disk drive = hard drive
5. drive = hard drive
6. file system = hard drive
7. logical disk = hard drive
8. mount point = hard drive
9. partition = hard drive
10. physical disk = hard drive

The geek translation of "marketing" is "lying".

"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."

Prisoners of Bill should read about MS-ASCII. There's a link to an improved demoroniser there, too.

For details, see Tom Christiansen's site.

multi threading though? Why?

Certainly there exists a class of problems that lends itself to more than one PC (program counter; it means program counter damn it) executing simultaneously in the same text and data. Personally, I prefer everything unshared unless I say otherwise, not the other way around.

But it's pretty scary stuff for all but the most rigorous of seasoned programmers. To my mind, handing a script kiddie multithreading is like handing a six year old a loaded Uzi. That's not to say that in the hands of a trained professional, these aren't useful. But in the wrong hands, they're more like a sneaky murder-suicide device.

It's getting a bit dated, and certainly carries its own agenda, but several years ago, John Ousterhout gave a talk on Why Threads Are A Bad Idea (for most purposes) that you might like to check out.

If you're curious about threading in Perl, the best place to start is probably the perlthrtut manpage. Some low-level documentation is also available.

I'll be giving a half-day talk on multitasking (both forking processes and spawning threads) in August at the Perl Conference in Monterey. I've got about 100 slides for 3 hours of talk, which should be, um, brisk. :-)

"In short, just as the Multics mentality of careful access controls shows up throughout Unix, the cretinous CP/M mentality of uncontrolled havoc shows up in DOS and all its mutant children." --tchrist

multi threading though? Why?

Certainly there exists a class of problems that lends itself to more than one PC (program counter; it means program counter damn it) executing simultaneously in the same text and data. Personally, I prefer everything unshared unless I say otherwise, not the other way around.

But it's pretty scary stuff for all but the most rigorous of seasoned programmers. To my mind, handing a script kiddie multithreading is like handing a six year old a loaded Uzi. That's not to say that in the hands of a trained professional, these aren't useful. But in the wrong hands, they're more like a sneaky murder-suicide device.

It's getting a bit dated, and certainly carries its own agenda, but several years ago, John Ousterhout gave a talk on Why Threads Are A Bad Idea (for most purposes) that you might like to check out.

If you're curious about threading in Perl, the best place to start is probably the perlthrtut manpage. Some low-level documentation is also available.

I'll be giving a half-day talk on multitasking (both forking processes and spawning threads) in August at the Perl Conference in Monterey. I've got about 100 slides for 3 hours of talk, which should be, um, brisk. :-)

"In short, just as the Multics mentality of careful access controls shows up throughout Unix, the cretinous CP/M mentality of uncontrolled havoc shows up in DOS and all its mutant children." --tchrist

Didn't Tom Christensen already prove that there are no virii? Or does this belong to the illiteracy thread?

Or you could take the separation-of-processes approach the way BSD's bc program does. That's the same kind of approach taken by my freed version of getline().

Then again, was there some reason you had to use the GPL?

I suppose we could be clever and make the binding between application and interpreter looser (say, consider spawning an interpreter task to which one pipes commands, and from which one reads output)

interesting claims about virii on Unix

Using that system, the pronunciation I'm most familiar with as spoken by anglophones would be /'su z@/, although folks from Germany of course say something that seems more to the English ear to be /'zu z@/ or even /'zu zE/ instead.

Hackish OO features are a strange brickbat to throw at Perl, because Perl5's OO-features were strongly influenced by Python's

When it came time for the object design, he rejected much of the C++ model. That's probably just as well, since C++ has so many oddities not found in any other language with object support. Python's model seemed sufficiently clean and appealing that, as with so many other tools and languages where Larry "cherry-picked" the coolest property from eclectic sources, he took most of the object stuff from Python.

For example, the object's self reference (the "this" pointer) coming in as the initial argument in a method call rather than as a formally defined variable comes right from Python.

Of course, we weren't really content to stop there. One difference from Python is that the class itself can serve as something of a meta-object. This has some rather nifty ramifications to this. If you're filling out a check-list of features, you'll find that Perl OO programming supports classes and objects, single and multiple inheritance, instance methods and class methods, access to overridden methods (a virtual SUPER class), constructors and destructors, operator overloading, proxy methods via autoloading, delegation, a rooted hierarchy for all objects (class UNIVERSAL), and two different levels of garbage collection.

Before you diss it too much, you should know what Perl OO is actually about. If you're looking for more information or examples on Perl OO, here are some suggestions:

• The perltootc manpage, for managing class (and sometimes instance data) in Perl.
• The perltoot manpage, a tutorial for OO in Perl
• The perlobj manpage, a rather dry but essential page.
• The overload manpage, to see how operator overloading works with Perl objects.

• The Perl Cookbook (yes, my name is on the cover) has a chapter on objects. You can download the source through the Examples link there (either normal gzip or else Wintel zip format).
• A new book (that yes, I tech-edited, but no, which I don't get royalties on) is coming out by Damian Conway, called simply enough Object Oriented Perl. Damian is our Melville. :-) We've accepted three of this prolific fellow's papers in the refereed track at the next Perl Conference. One of them is even a technical paper that's written completely in a certain kind of poetry.

I don't mean to pretend that Perl's OO doesn't have its host of issues. The biggest one is that unless you're careful in your design, one class needs to get unnaturally chummy with its parent class to avoid accidentally overriding or interfering with not just functional members (methods) but also data members (attributes).

But as Larry has said: `Concentrate on Perl's strengths, not its weaknesses.'

Hackish OO features are a strange brickbat to throw at Perl, because Perl5's OO-features were strongly influenced by Python's

When it came time for the object design, he rejected much of the C++ model. That's probably just as well, since C++ has so many oddities not found in any other language with object support. Python's model seemed sufficiently clean and appealing that, as with so many other tools and languages where Larry "cherry-picked" the coolest property from eclectic sources, he took most of the object stuff from Python.

For example, the object's self reference (the "this" pointer) coming in as the initial argument in a method call rather than as a formally defined variable comes right from Python.

Of course, we weren't really content to stop there. One difference from Python is that the class itself can serve as something of a meta-object. This has some rather nifty ramifications to this. If you're filling out a check-list of features, you'll find that Perl OO programming supports classes and objects, single and multiple inheritance, instance methods and class methods, access to overridden methods (a virtual SUPER class), constructors and destructors, operator overloading, proxy methods via autoloading, delegation, a rooted hierarchy for all objects (class UNIVERSAL), and two different levels of garbage collection.

Before you diss it too much, you should know what Perl OO is actually about. If you're looking for more information or examples on Perl OO, here are some suggestions:

• The perltootc manpage, for managing class (and sometimes instance data) in Perl.
• The perltoot manpage, a tutorial for OO in Perl
• The perlobj manpage, a rather dry but essential page.
• The overload manpage, to see how operator overloading works with Perl objects.

• The Perl Cookbook (yes, my name is on the cover) has a chapter on objects. You can download the source through the Examples link there (either normal gzip or else Wintel zip format).
• A new book (that yes, I tech-edited, but no, which I don't get royalties on) is coming out by Damian Conway, called simply enough Object Oriented Perl. Damian is our Melville. :-) We've accepted three of this prolific fellow's papers in the refereed track at the next Perl Conference. One of them is even a technical paper that's written completely in a certain kind of poetry.

I don't mean to pretend that Perl's OO doesn't have its host of issues. The biggest one is that unless you're careful in your design, one class needs to get unnaturally chummy with its parent class to avoid accidentally overriding or interfering with not just functional members (methods) but also data members (attributes).

But as Larry has said: `Concentrate on Perl's strengths, not its weaknesses.'