Slashdot Mirror

....they earn money from conferences and such and then turn that into grants and community hardware. Good times.

And yup, the grant PDF file is missing, I've emailed them about it.

> It's about the right time for a RoR book, since
> things have been moving so much of late,

Yup, and this book will last for a while since it focuses on how Rails uses Ruby to do the metaprogramming "magic". So if the APIs move on slightly the techniques in Dr. Black's book still apply.

For those who aren't on the Ruby lists, Dr. Black is a long-time Ruby user, a founder of the 501(c)(3) Ruby Central that organizes the Ruby conferences, and generally a Rubyist from way back. He's rather a guru but he still answers questions on the mailing lists and generally does a lot of grunt work.

Thanks to RubyCentral, RubyForge is getting new hardware and a nicer hosting location. Donations are appreciated and are tax deductible!

Perhaps more mentoring organizations will get a look in now? I know Ruby Central was turned down previouly by Google for alledgedly missing the application date.

Curses... thanks. Would that there was a post editing capability... ah well. Retry:

Thanks to Ruby Central for sponsoring RubyConf 2004!

....Ruby Central is a worthy recipient of your tax-deductible donation. They arrange and sponsor Ruby conferences and generally support the Ruby community in a variety of ways. There's a Paypal donation link on the front page of RubyForge.

Props to David Allen Black and Chad Fowler who are the prime movers behind RubyCentral!

Perl is emphatically not an object-oriented language. Perl's OO features were crudely hacked in after-the-fact. This unfortunate compromise is the equivalent of trying to bolt an internal-combustion engine onto a stagecoach instead of designing an automobile from the ground up.

Too many simple tasks are pointlessly complicated. Take the simple example of creating an array whose elements are arrays. Not only does the developer need to use additional inner brackets for each element, but they must also remember to use the unique @{$a[1]} syntax when referencing. Why all the extra steps? Who knows.

Perl is notoriously impossible read and maintain. Walk into any bar frequented after-hours by veteran developers and you'll hear story after story being swapped about having to decipher brain-crushing lines of text like :" (my @parsed =$URL =~ m@(\w+)://([^/:]+)(:\d*)?([^#]*)@) || return undef;". This unreadability is in part the result of the fact that:

Perl attempts to be all things to all people and ends up being second-rate at everything. Perl is widely known as the "duct tape of the internet", and it performs superbly in this role. However, just as you cannot build a house out of duct tape alone, so attempting to turn a language that was originally developed for scripting brief, handy utilities into a do-all, be-all programming language will only result in the buggy, bloated, "write-only" mess that Perl has become. It has been said that you only need to know 10% of Perl to do 90% of your job. It should be added that anyone trying you utilize 90% of Perl would have time enough to do 10% of their job.

Subroutine signatures, orthogonals, method access, data inheritance: this list could go on and on. But there is no real need. Its is now clear that Perl is doomed. At this very moment, Perl 6.0 is being cobbled together, with bulletins about the myriad upcoming features of the new version being issued with titles referring to the Biblical Book of the Apocalypse, the favorite text of messianic streetcorner lunatics. There is no better indicator of the deranged states of mind of the developers behind Perl than this unfortunate choice of imagery. Software developers with any interest in future employment/relevance should seize this opportunity to attain fluency in Ruby or Python and donate their Perl books to the History Department of their local University.

Perl is emphatically not an object-oriented language. Perl's OO features were crudely hacked in after-the-fact. This unfortunate compromise is the equivalent of trying to bolt an internal-combustion engine onto a stagecoach instead of designing an automobile from the ground up.

Too many simple tasks are pointlessly complicated. Take the simple example of creating an array whose elements are arrays. Not only does the developer need to use additional inner brackets for each element, but they must also remember to use the unique @{$a[1]} syntax when referencing. Why all the extra steps? Who knows.

Perl is notoriously impossible read and maintain. Walk into any bar frequented after-hours by veteran developers and you'll hear story after story being swapped about having to decipher brain-crushing lines of text like :" (my @parsed =$URL =~ m@(\w+)://([^/:]+)(:\d*)?([^#]*)@) || return undef;". This unreadability is in part the result of the fact that:

Perl attempts to be all things to all people and ends up being second-rate at everything. Perl is widely known as the "duct tape of the internet", and it performs superbly in this role. However, just as you cannot build a house out of duct tape alone, so attempting to turn a language that was originally developed for scripting brief, handy utilities into a do-all, be-all programming language will only result in the buggy, bloated, "write-only" mess that Perl has become. It has been said that you only need to know 10% of Perl to do 90% of your job. It should be added that anyone trying you utilize 90% of Perl would have time enough to do 10% of their job.

Subroutine signatures, orthogonals, method access, data inheritance: this list could go on and on. But there is no real need. Its is now clear that Perl is doomed. At this very moment, Perl 6.0 is being cobbled together, with bulletins about the myriad upcoming features of the new version being issued with titles referring to the Biblical Book of the Apocalypse, the favorite text of messianic streetcorner lunatics. There is no better indicator of the deranged states of mind of the developers behind Perl than this unfortunate choice of imagery. Software developers with any interest in future employment/relevance should seize this opportunity to attain fluency in Ruby or Python and donate their Perl books to the History Department of their local University.