Slashdot Mirror

Why do you people insist on calling them 'virii'? Really? The term is viruses: http://www.perl.com/language/misc/virus.html has a full explanation.

Yeh i know we've all heard this before, "Virii is not the plural form of virus". But in case anyone is interested this site has a good explanation why.
Whats the plural of 'Virus'?

-j

PPT :-)

SiCE

System admin

web programming

standalone applications

quick and dirty scripts
In addition, it's a lot of fun !

You said that not all of the 128-bit checksum can be used. Wouldn't that mean that some files would have the same checksum, that is the checksum would not be unique now? I mean, when two files have checksum which have first 64 bits the same and the second 64 bits different and I use only the first 64 bits, then I have two files with the same conflicting checksum, am I right?

Well, yes and no. Yes, you're right that the 64-bit parts of MD5 digests are not unique, but so are the full 128-bit digests. Any n-bit digest, provided it's randomly distributed, will be the same statistically every 2^n times, since there are only 2^n different results. Now it's up to you if you think 281474976710656 (48 bits) different digests is enough for you, or you need 590295810358705651712 (69 bits) or full MD5 340282366920938463463374607431768211456 (128 bits).

You have to use enough bits to make sure (well, you never can be sure, like you can't be sure that you won't win a lottery 1000 times in a row -- you get the idea) that two files having the same digest is practically impossible (because it's always theoretically possible, however unlikely). It depends on the number of files you have. For n-bit digest and m files there are 2^nm different results and (2^n)!/(2^n - m)! good results (i.e. those results without collisions).

So, the probability of not having any collisions is (2^n)!/(2^nm (2^n - m)!) but since calculating (2^128)! is not what you want to do (trust me -- a 1000 teraflop supercomputer would need half a million times more time than the age of our universe, provided it would have so much RAM and could handle so long numbers, which I don't even dare estimating). You better write this from the command line, it's a little Perl one-liner I just hacked out of boredom -- yes, I know, I should take my medicine and get some sleep:

perl -le'($n,$m)=@ARGV; for($w=$z=2**$n,++$_;$m;--$m,--$z){$_*=$z/$w} print' n m

It will compute (2^n)!/(2^nm (2^n - m)!) (rounded to your floating point resolution) i.e. it will give you the probability of not having any collisions using n-bit digests with m files (-0 means it's impossible and 1 means it's sure or so possible that almost sure). If anyone asks how does it work -- it's magic. Copyright © 2002 alfaiomega. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. There is NO warranty; not even for MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE or READABILITY.

Other than that, thanks for your comment! I'm going to use your ideas in my project. Greetings.

Great, I thought no one would read my comment with Score:1. That's good to hear that someone liked it more than the moderators.

There's a Review of Komodo 2.0 (printer/human friendly version) by Simon Cozens on Perl.com from October 09, 2002:

"Every time I get a new copy of ActiveState's Komodo IDE, I do a review that invariably ends "this would be the perfect IDE for me if I were the sort of person who used IDEs". And every time I get the next release, I get closer to being persuaded I should be using IDEs. With Komodo 2.0, ActiveState is getting very, very close to persuading me - but it's not there yet. Let's see what it got right and got wrong this time. (...)"

Read the whole thing, it's more objective than the ActiveState's review. I personally don't use IDEs at all, like Simon Cozens, and I find his review much more interesting from my point of view. If I am to ever start using IDEs I have to know not if it's good for an IDE, but if it's good for people who prefered using Emacs/vi so far.

There's a Review of Komodo 2.0 (printer/human friendly version) by Simon Cozens on Perl.com from October 09, 2002:

"Every time I get a new copy of ActiveState's Komodo IDE, I do a review that invariably ends "this would be the perfect IDE for me if I were the sort of person who used IDEs". And every time I get the next release, I get closer to being persuaded I should be using IDEs. With Komodo 2.0, ActiveState is getting very, very close to persuading me - but it's not there yet. Let's see what it got right and got wrong this time. (...)"

Read the whole thing, it's more objective than the ActiveState's review. I personally don't use IDEs at all, like Simon Cozens, and I find his review much more interesting from my point of view. If I am to ever start using IDEs I have to know not if it's good for an IDE, but if it's good for people who prefered using Emacs/vi so far.

1. dselect is just an embarassment. When I first saw it, I almost quit right there. Ironically, what kept me going was the sheer shittiness, which (in my mind) was an assurance that it would have to be fixed soon. No luck so far, although aptitude looks promising.
2. The packages are seldom up-to-date. This is also a feature, since the stability is rock-solid. My system hasn't been hacked a single time since I switched from RedHat to Debian. But when new features matter (e.g. Perl, Samba, etc.), Debian is always several versions behind. This has been improving, and it wouldn't matter at all if the next problem was solved:
3. It's impossible to mix+match packages. Debian divides the world into three categories, roughly corresponding to "stable", "hackable", and "malfunctiony." Once in awhile the "malfunctiony" distribution will contain the newer version you want, but it's just there to tease you. If you try to install it, it will attempt to convert your whole system to "malfunctiony" mode. Instead you're supposed to recompile from the sources, but this has its own problems because it creates a missing dependency for other packages. That wouldn't matter, except:
4. The package system is not flexible. For example, suppose I compile my own Perl and install it, and now I want my custom version to satisfy the Perl dependency. The Debian answer? Create a fake package that provides "Perl" and install it. (Someone even has an automated utility for this stupid idea!) If you want to use the much superior -MCPAN, it becomes even more of a headache, because now you have lots of little fake packages like that. As far as I can tell, there is no equivalent of "provides" in rpmrc.
5. No support for chkconfig. Managing services in Debian means manipulating stupid symbolic links. This should be centralized.

• It's very stable.
• Upgrading packages is almost completely automatic, like Windows Update. This makes it easy to stay "current" and secure.
• It's easy to install without X-Windows (which I don't need, because my servers don't have keyboards or monitors)
• You can export a list of installed packages from one server, and then install this list on other server.
• The Debian people aren't conspicuously trying to make you their customer
• Debian is impossible for stupid people to use. This dramatically increases the ratio of smart people to stupid people on the newsgroups. :-)

Dicionary.com does though. As does my OED on CD, though they don't have a free version online I can link to.

"Virii", which is correct according to the rules of the english language

You are very much mistaken. I challenge you to find a dictionary or usage guide that supports you.

If you're going to play spelling nazi, you need to start checking your sources a little better.

Says the pot to the kettle. Even the most basic of research would have led you to a plethora of papers demonstrating your error, such as this one and this one.

Dude, by simply saying that something is not true does not make it true.
The Parrot calling convention POD was pulled a while back. I don't call saveall/restoreall a true calling convention. Prove me wrong - show me a doc with the new calling convention.
Where's Parrot's 64 bit integer type? If you hope to support Java and C# you will need it.
You *do* need some form of distributable bytecode library format - bytecodes alone do not cut it - all projects cannot be monolithicly compiled in a single bytecode file.
Threading issues *must* be considered from the very start - it affects every aspect of your design - from garbage collection to memory layout. Look at all the trouble Perl 5 had grafting threads to its design - they only "got it right" in Perl 5.8.
You're living in a dream world of denial. The project has to address these basic issues if it is to suceed.
It's history repeating itself all over again. Remember what happened to Topaz: Perl for the 22nd Century?

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goatse. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter .

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^H Perl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.

This has always been the case for compiling programs for Novell: a DOS/Windows box with compilers. This is nothing new or special with regard to Perl.

You're correct, but that's my point; no other enterprise NOS that I know of requires a completly different platform in order to compile and link its binaries.


Just to share blame, why not address the issue that a large portion of Perl modules that use native code aren't portable outside of UNIX (and even then...).

Funny, I've never had that problem with the more simple perl modules. With NetWare I'm talking about simple things such as rsync for perl, or even most of the tools as implemented in the Perl Power Tools.


Perl for NetWare is poorly supported, and does not support basic things such as fork(), chown, syscall, chroot, alarm, and about 20 other functions...
Ummm... Of course this is because NetWare itself doesn't have these functions.

Correct, NetWare does not have these functions. You made yet another point of mine. For example; NetWare has a cron binary (NLM) - it is not possible to run two cron jobs at the same time. For example: I have one job that starts at 8:55am, and takes about 5 hours to complete, and another that runs every hour on the hour. What happens is that the first job will start at 8:55, but the second job will be unable to run until the first one is complete. That's five hours later, not every hour on the hour...

Current operating systems? UNIX is *how* old? NetWare by your metric IS the current operating system.

Hmm, I must have confused you here. By current, I meant an OS that kept up with what EVERYONE else was doing (ie: implementing simple things such as fork()), not in regards to actual age.


As for network-wide security and administration, I'm sorry but Novell's offerings are superior and have been superior for years. NIS+? LDAP? Active Directory? Pshaw! NDS was already better than these years ago and eDirectory widens that margin.

Security, oh god you're one of those. I never mentioned security in my post, but all NetWare die-hards have to include this bit in their argument. Well, I bite: NetWare has a horrible track record for communicating with their customers regarding security issues. Novell needs to grow up, and stop acting like a two-year old when they have a security issue. Their security website (only a few months old I might add), is sketchy, and does not outline all of the security issues encountered with their products. For example, the buffer overflow in the GroupWise GWIA that was discovered back in June/July; Novell still has not noted the issue, or posted a specfic patch to the issue. This is not the only example, but I quite frankly dont want to dig up the others right now...

When I talk to Novell techs about when/why I should have to apply a patch, they basicaly tell me that they have poor change control and documentation procedures for their code, and many times, fixes for bugs and security issues get placed into production code, without it ever being documented. Oh great, now I, as the customer, have to guess when a security issue is going to bite me, and/or when a feature is changed - because Novell cant be bothered to tell me about them... The fact of the matter is, from an administrative standpoint, when you really take the time to look at it, NetWare is looking less and less secure.

Oh, and dont get me started on the security of NetWare itself - what idiot runs all of their processes at root-level on Unix systems. I sure dont, but with NetWare you dont get a choice, if an NLM crashes, it abends the server, if an NLM has a security issue (like the recent Apache one), youre server gets rooted. If the process crashes, the crash most likely shuts down the service that was running under the NLM, and very likely requires a reboot of the server in order to get that process/service back online (unlike Unix, where under 99.9% of the cases, you simply start the process again). I dont know about you, but I dont fully trust all of the software that comes from my software vendors, and I'd rather see it running at a level that is not likely to shutdown or takeover the entire server (ie: as "nobody", or a normal user with less-than root access to the server). On Unix this is dead simple to do, with NetWare I dont get that option...

While I'll agree that NDS is an excellent product, developers for it are as scarce as the products that integrate into it (ie: they are far and few between). Afterall, if Novell's GroupWise folks cant make GroupWise work with NDS natively, how can they expect anyone else to make their product work. The GroupWise folks have only been promising full NDS integration for around 4-6 years. Sure LDAP support is getting there, but it's not native NDS support, and not even the GroupWise folks have gotten LDAP support fully working yet.


Why does Novell need to update Perl? Because they bundle it? Why doesn't the Perl community maintain the port just like they do for every other operating system ? Or is Novell special on your shitlist? It's not like Novell controls the Perl source.

Yes, if they bundle it, they should update/maintain it, just like the other vendors do... I dont see Novell providing an enviroment where the perl developers can connect to a NetWare server and compile/update/patch/test the code (oops, you cant do that with NetWare, you need a seperate Windows/DOS system to do that...). Most of the other ports are written because the perl developers have access to a system they can test/develop on...

NetWare is an excellent file and print server. Novell is trying to make NetWare into an application server, something it has never done well at...

You're assuming that virus is masculine. All the dictionaries I've checked list it as neuter. And I think you mean second declension (or maybe fourth), but it's definitely not third.

Here's an interesting discussion regarding which declension is it?

No actually, it isn't a word =P
http://www.perl.com/language/misc/virus.html

And personally (this isn't directed to the poster), I don't think boxen is a word either. Someone took the plural of ox (oxen) and decided it would suit box too, the plural of box is boxes.

Grammar nazi mode.. off.

And the press release which includes a great interview with Larry and Guido.

(For those a little slow on the uptake, check the date on the press release before you run out and buy the book)

(and if you're thinking about modding me down, see the sig. This post contains so many contradictions that it should be a +1 Funny, anyway)

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goatse. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^H Perl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.

Unlike ILovYou-type viri,

A bit off-topic, I know, but here's an interesting link about the word "viri", the alleged plural of "virus": What 's the Plural of 'Virus'?

Maybe you want to checkout this article before claiming Perl is slow again:

http://www.perl.com/pub/a/2001/06/27/ctoperl.html>

Also in the Apache world mod_perl is known to be very fast, even compared to native CGI:s Did you even know that you can save a Perl program to a binary by a certain switch after the interpreter has done its job?

Perl Rules!

Starbar!

(Slaps forehead.)

You're right! What was I thinking! Call it Linux! I can't believe I never thought of this point before!

I get to rename Linux

Linux is a kernel. An operating system, in the same sense as Windows, consists of much more than a kernel. GUI, utilities, etc. (Yes, in another sense, an operating system means just a kernel.)

"Rename" is a misnomer, too. The first Linux distribution, Yggdrasil, billed itself as "Linux/X11/GNU" (check groups.google.com for the original announcement).

The point is this: the GNU project believed in software freedom and started writing a free OS. Someone who did not believe in software freedom provided a kernel that would work with that OS and complete it. Most people who come to that OS have never heard of software freedom. RMS is asking everyone who believes in software freedom to say "GNU/Linux" so that people who are using that OS will say, "Huh? What is GNU?" and provide an opportunity for someone to tell them about software freedom and try to point people back at GNU's original goals.

You probably don't believe in software freedom. Most people here don't. I thought it was a crackpot idea when I first heard it. (And about the next thirty times I heard it after that.) That's okay; no one is going to force you to call it "GNU/Linux." The FAQ even says that. (Stallman believes in free speech.) But some of us are going to go on saying GNU/Linux, and every so often, someone else will come on over to the software freedom bandwagon.

Meanwhile, if you don't believe in software freedom, it's those goals that allow you to take GNU's code and make a working OS in conjunction with the Linux kernel. Yes, you can use non-GNU utilities (ever heard of Perl power tools? Someday I'm going to try to build a system out of a kernel, Perl, and those. :) ), but not if those utilities don't give you the freedoms GNU believes in.

There is indeed a section on testing. Of course, there are lots of other resources online. :)

There is indeed a section on testing. Of course, there are lots of other resources online. :)

I don't have the money to pay for my own dedicated server. Is there anywhere that I can get access to mod_perl for $10-20/month?

I know what you are probably thinking, If my site is small enough to get by on a virtual hosting account, than I should probably just not worry about mod_perl. And maybe I should just leave it at that but here is what I am thinking...

I am not a mod_perl expert so I might be totally wrong about this but, hey, that's why I'm asking! If a host setup mod_perl with some basic modules preloaded users could then run their scripts under it. Not only would user's websites run faster but it would reduce system resources (overall) which should make the hosting company happy too.

Yes, I know that there would be some problems particularly with security but has anyone figured out a way to do this successfully?

REF: http://www.perl.com/pub/a/2002/05/22/mod_perl-isp. html

why don't you use a free perl binary and a free installer system?

Not to nit pick, but under no circumstances is the plural of "virus" spelled "virii". It is always "viruses". Making up the spelling of words does not help your argument, it just makes you look dumb.

http://www.perl.com/language/misc/virus.html

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goatse. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^H Perl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.

No, it's Sattelites, for the same reason Virii is incorrect (it's actually Viruses). Common mistake, though.

For what it's worth, the Latin-second-declension-singular-sounding word, virus , is in fact (probably) second declension neuter, and what's more has no [authentic Latin] plural... the correct word is viruses!

Amazing how those memes spread...

"Virii" isn't not a Latin plural of any known word. The most plausible latin nominative plural would be "viri", but some people don't buy that.

Better check out href="http://www.perl.com/language/misc/virus.html #English

RTFM. Perlfaq7

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goatse. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^H Perl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.

Having read some of the more recent Apocalypses, I have a question for you: are you crazy? The regexp changes you're talking about in Apocalypse 5 will make Perl 6 deeply incompatible with existing scripts and practice. In particular, I object to the conversion of [] to non-capturing grouping rather than character class. As a long-time user of Perl, I have to say this is insane. You're wrong when you say "we're really simplifying" -- you're making things more complex. Changing this breaks Perl and much more; why do you think you're immune from the negative side-effects of hubris? And it is hubris. We know this because you start page 2 of the Apocalypse by saying, "Regex culture has gone wrong in a variety of ways...." One of Issawi's Laws of Progress says that society (even Perl regexp culture) is a mule, not a car -- if pressed too hard, it will kick an throw off its rider. Something this radical and wrong will hurt Perl 6 adoption and will retard the acceptance of some very nifty features.

Having read some of the more recent Apocalypses, I have a question for you: are you crazy? The regexp changes you're talking about in Apocalypse 5 will make Perl 6 deeply incompatible with existing scripts and practice. In particular, I object to the conversion of [] to non-capturing grouping rather than character class. As a long-time user of Perl, I have to say this is insane. You're wrong when you say "we're really simplifying" -- you're making things more complex. Changing this breaks Perl and much more; why do you think you're immune from the negative side-effects of hubris? And it is hubris. We know this because you start page 2 of the Apocalypse by saying, "Regex culture has gone wrong in a variety of ways...." One of Issawi's Laws of Progress says that society (even Perl regexp culture) is a mule, not a car -- if pressed too hard, it will kick an throw off its rider. Something this radical and wrong will hurt Perl 6 adoption and will retard the acceptance of some very nifty features.

Having read some of the more recent Apocalypses, I have a question for you: are you crazy? The regexp changes you're talking about in Apocalypse 5 will make Perl 6 deeply incompatible with existing scripts and practice. In particular, I object to the conversion of [] to non-capturing grouping rather than character class. As a long-time user of Perl, I have to say this is insane. You're wrong when you say "we're really simplifying" -- you're making things more complex. Changing this breaks Perl and much more; why do you think you're immune from the negative side-effects of hubris? And it is hubris. We know this because you start page 2 of the Apocalypse by saying, "Regex culture has gone wrong in a variety of ways...." One of Issawi's Laws of Progress says that society (even Perl regexp culture) is a mule, not a car -- if pressed too hard, it will kick an throw off its rider. Something this radical and wrong will hurt Perl 6 adoption and will retard the acceptance of some very nifty features.

You might want to have a look at this article which highlights some of the ways in which Perl 6 is not changing.

This will be for modules, not programs. A Perl 5 module begins with 'package Acme::Foo;'. A Perl 6 module will begin with 'module Acme::Foo'. This is explained in Exegesis 4.

Ok, rant time. I'm big Vim fan. Every computer I own or use (well, every working computer) has it installed. The only editor that approaches EMACS's feature set, and nowhere near the great bloatware's klunkiness or unpredictability. But.

I'm rather disappointed that EMACS and Vi (and its clones, of which Vim is the best and mostly widely used) remain the most widely used text editors. Now each has strengths and weaknesses relative to the other, and it's no use rehashing those wars here. What's important is that both these editors are designed around constraints that are about 20 years out of date. Most especially, they were designed to be used by a text-mode terminal (very fancy ones, in the case of EMACS, very limited ones in the case of vi) over a relatively slow connection.

I won't comment on EMACS, since I lack the obsessiveness to be a serious user. But on vi, the big design decision was to build in a lot of modes to get around the limitations of the terminal. This allowed a lot of commands without function keys or complicated keystrokes. It also allowed the user to enter blocks of text without realtime update -- an essential feature on a 300 baud connection!

But, in a GUI environment, modes are a Bad Thing. Yeah yeah, some of you like being able to do complicated edits without moving your hands off the keyboard to grab the mouse. But most people have an easier time if they don't have to keep a state map current in their head.

Now Vim has impressive GUI support (platform-independent GUI support, which is the main reason I use it), but it still has all the modes of vi, plus 3 or 4 of its own. And its macro language is a kludgy extension of the simple-minded command language Bill Joy invented for the original ex/vi editor, itself a minor extension of the ed command language.

Various projects have tried to do all this over using modern design principles, but the EMACS and Vi user communities are just too entrenched. If I were a better programmer, I'd try it myself, maybe using the vim engine as a basis. But probably I'd be the only user!

I wonder whether they used perl...

Favorite quote: "The Quantum::Entanglement module attempts to port some of the functionality of the universe into Perl."

And of course my favorite, you can't beat using the CPAN shell to install new modules.

You need to read up on EToys (RIP):

http://www.perl.com/pub/a/2001/10/17/etoys.html

Java is *not the answer*! Besides, I thought discussion on Slashdot was limited to software libre . . . .

• http://www.phpbuilder.com - PHP, some real world examples.
• http://www.devshed.com - PHP, Perl, Python and more.
• http://www.php.net - PHP
• http://www.perl.com - Perl
• http://www.coveryourasp.com - ASP, all real world examples.
• http://www.builder.com - C, C++, Java, Perl, Python and more.
• http://www.devcentral.com - C, C++, Java, PHP, Perl and more.
• http://www.eskimo.com/~scs/C-faq/top.html - C FAQ.

• Programming Perl - Perl
• The C Programming Language - C
• The C++ Programming Language - C++
• PHP and MySQL Web Development - PHP and MySQL. All real world examples.

People

Richard Stallman -
Eric S. Raymond -
Larry Wall

Linux Programming

Unix

Programming Methodologies

C Programming

C++ Programming

Perl Programming

Network Programming

Open Source

not virii, see http://www.perl.com/language/misc/virus.html.

Well, that's the interesting part. A lot of the changes in the perl 5 regexps have the end result of moving toward perl 6. I mean, you can definitely see that there is a logical progression of ideas from the perl 5.6 and 5.8 RE extentions toward the perl 6 regexp system.

The things that the 5.x (?X) "extentions" did have now become deeply integrated parts of the perl 6 regexp engine: named subpatterns ("rules"), embedded code assertions, and the "::" abort are the most important part of the perl 6 extentions, and they all had clear descendents in the things that have been added to perlre since 5.005...

Now, if only i understood how to use them effectively.. :)

P.S.: Please note that if you want to try to wrap your head around this perl6re beast, in addition to asobola's link it may be good if you looked here and here. (The first is a summary/reference of the apocalypse changes, the second is some neat sample code in which an elegant XML validator is created using perl6re)

-- super ugly ultraman

Well, that's the interesting part. A lot of the changes in the perl 5 regexps have the end result of moving toward perl 6. I mean, you can definitely see that there is a logical progression of ideas from the perl 5.6 and 5.8 RE extentions toward the perl 6 regexp system.

The things that the 5.x (?X) "extentions" did have now become deeply integrated parts of the perl 6 regexp engine: named subpatterns ("rules"), embedded code assertions, and the "::" abort are the most important part of the perl 6 extentions, and they all had clear descendents in the things that have been added to perlre since 5.005...

Now, if only i understood how to use them effectively.. :)

P.S.: Please note that if you want to try to wrap your head around this perl6re beast, in addition to asobola's link it may be good if you looked here and here. (The first is a summary/reference of the apocalypse changes, the second is some neat sample code in which an elegant XML validator is created using perl6re)

-- super ugly ultraman

Fork() is for creating a new process. The Perl 5.8.0 threads uses the threads pragma to spawn threads. But Perl doesn't share all data by default, so variables must be declared shareable via variable attributes( $variable : attribute). Artur Bergman wrote a good synopsis.

Well, when Perl 6 is released (a while yet, I think) you'll find radical changes to the regexps. See Apocalypse 5 for more information.

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thankyou very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goatse. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^HPerl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.