September 20, 2004
Why PHP still stinks
Yoz just wrote an excellent counter-point to my PHP overtaking Perl doesn't matter post and argues that the Perl community should be bothered about PHP taking away their market share. Yet I'm still not convinced, and here's why.
Let's take a look at what made PHP so wildly popular:
-
Executable PHP scripts in any folder, not just inside your
cgi-binor whatever directory you manually arm for scripting. - The possibility to shuffle PHP code within HTML.
- No modularity, no namespace separation, 3079 functions in the core namespace.
- "No nonsense" procedural-style API with few hints of encapsulation or abstraction of concepts.
Every single point in this list is evidence of a bad design decision, and for any serious developer a valid reason to flush PHP down the toilet and never look back. For the Average Web Grunt, however, priorities are different. He wants to know how to display shit in the browser. He wants to know how to get shit in and out of his database. He wants to get his shit done regardless of the collateral damage involved. And for this purpose PHP's design decisions work like a charm.
The reason for PHP's success? The Average Web Grunt gets away with it. Future-proofing his code is not on the top of his agenda, or that of his clients. He doesn't develop in teams. And for the most part his applications are simple enough that the PHP school of doing development doesn't yet rear its ugly head.
In my previous post about PHP I claimed that "PHP's crudeness is actually by design in order to lower the barrier of entry for people who struggle with other things than programming in their day job.", to which Duncan replied with a trace of cynism:
Yes, I'm sure all the 'amateur' PHP 'kids' are pleased to be writing code in a language whose 'crudeness' is there to benefit them and make sure they get their projects done on time.
So you're going to tell the Average Web Grunt that it's much nicer having to include libraries for any functionality that doesn't belong in the core? You're going to tell him that he's much better off having layers of abstraction between him and his data? That handlers are so 1985 and namespace pollution is a bad thing? That he should learn to work with objects and divide his application into tiers? YEAH, RIGHT.
For thousands of people, PHP is just what they need. Easy to learn, easy to copy & paste and no hard concepts which they must wrap their brains around before they can get shit done. Side effects like awfully designed and unmaintainable applications don't matter for them because due to the the nature of their projects, design, maintainability and complexity are rarely an issue.
Does that mean that other languages are already the holy grail we're looking for? Certainly not. Perl in particular has many grave deficiencies, like the weirdness that Larry Wall calls OOP in Perl, or the difficulty of installing stuff when you're on a $5/month shared server account. What I'm saying is that different user groups have different ideas of what constitutes a good language, and you're not going to take away PHP's pie without doing away with all the best practices that only pay off further down the way.
Life is too short
One pathetic loser accidently mistook this site as a billboard for his filthy poker site, so I switched comments to approval-only. I understand that this is the tactical nuke of comment spam prevention, but life is too short to waste it dealing with assholes.
About another kind of digital assholery, Phil Ringnalda writes:
I've been noticing that Wired has a new sex column. I know they do because I subscribe to their RSS feed, and they've been swapping the entry announcing it between the author's real name, Regina Lynn Preciado, and her pen name (or, benefit of the doubt, perhaps her coincidental nickname), Gina Lynn, apparently nearly every time Bloglines re-reads the feed. As a result, pretty much every time I've checked my aggregator the last couple of days, I've seen that entry again. And again. And again.
I suppose this stunt is going to cost them more subscriptions than Phil's, and now mine.
AppRocket offered at half price
Candy Labs currently offers AppRocket (their Windows clone of the Mac-only LaunchBar) for the ridiculous sum of $8:
Over the past few months we have had a LOT of great feedback from people using AppRocket. To show our utmost appreciation we have decided to offer AppRocket to you all at half price! Thank you so much and please keep sending in that feedback.
AppRocket might be the most useful Windows utility ever, so go seize this oppurtunity.
September 15, 2004
Looking forward to Ruby
I actually might get the chance to redo Netalive.org in Ruby. This is very exciting news as (save Python) Ruby is probably the only well-designed popular scripting language out there.
The reason why I didn't make the switch earlier is that Netalive is currently hosted on a shared server, where I only get somewhat lackluster for the Little Language From Japan That Could. Now the option has opened to move the site over to a dedicated machine which I could tune for Ruby to my heart's desire.
Happy!
Comments feed available
I'm having such a blast brawling with duncan over my PHP overtaking Perl post that I set up a comments feed for you to enjoy.
The frustration of aliasing Long::Package::Names in Perl
A huge annoyance of Perl is that it doesn't distinguish between namespaces and class names. Instead of having a class Student in a namespace Entitiy::Human, you can only declare a package named Entitity::Human::Student, cramming both parts into one huge, ugly... thing.
This design flaw truly begins to rear its ugly head farther down the code, when you must use the gruesomely long Entity::Human::Student whenever you need to instantiate the class, or want to call a static function.
In Java, C#, Ruby or Python you could have a piece of code simply import the namespace Entity::Human and then work with the class name Student. So I thought it would be nice for the next version of Reformed Perl to allow something like this:
package Class; import Entity::Human; my $student = Student->new(); Student->show_all();
Implementing this however has turned out to be a rather frustrating affair.
Attempt 1: Naively aliasing package names
My first idea was to alias the package name Entity::Human::Student to the short Student, using the method employed by Joshua Keroes's Package::Alias or Michael King's import pragma:
*{'Student::'} = *{'Entity::Human::Student::'}
The fatal disadvantage of this method is that package aliases created this way are global. Not only the current package can refer to Entity::Human::Student as Student, but every package in your project.
Given a second package List::Sorter::Student and two spots in your project importing the namespaces Entitity::Human and List::Sorter respectively, no one knows what the alias Student would resolve to. In any case one place in your project is now getting the wrong package.
Attempt 2: Don't alias, catch errors
My next hack was to not alias anything at all, and catch the error message through $SIG{__DIE__}. If a piece of code would die crying Can't locate object method "foo" via package "Student"' I could simply redirect the request for Student->foo to it's correct home at Entity::Human::Student->foo, right?
Redirecting the call isn't a problem, but there doesn't seem to be a way to prevent the script from dying anyway afterwards.
Attempt 3: Alias through constants
The third approach was to alias the package names through constants, as in:
use constant Student => 'Entity::Human::Student';
This way Student->foo() would equal Entity::Human::Student->foo() and the alias would be local to a given package! But my delight didn't last long: Because constants in Perl are really just subroutines with constant return values it isn't possible to define a constant at runtime! Thus, if you created your alias at runtime, Student->foo() wouldn't resolve to anything else. You could write Student()->foo(), but that's all but inacceptable.
Excuse me while I shoot myself in the head.
September 14, 2004
Registering namespaces on CPAN: What's the point?
With some help from Randal Schwartz Reformed Perl is now available on CPAN.
Now I wonder if I'm supposed to fight for the namespace that the Reformed Perl's modules occupy. The PAUSE FAQ is a little vague about it, and only promises some nasty things that might happen to you if you skip this step.
Countless modules of high quality are occupying CPAN without a namespace registration. Which doesn't come as a surprise, as the benefits of registration seem few: Inclusion in the big module list that hasn't been updated for more than two years big module list, and an entry in CPAN's category tree which no one uses anymore. When you're looking for a module these days, you simply search for it.
For the sake of form I submitted a request for registration of the reform namespace, but was immediately asked to discuss my proposal on the perl5-porters list beforehand. I can understand the request, but should I really invest the time given that claiming a rootlevel namespace in the CPAN hierarchy is not going to get me much love?
Update: I was wrong, there actually is an actively maintained module list on CPAN. Still, does anyone find their packages this way?
September 13, 2004
Triskweline available as TrueType .TTF
My ultimate programmer's font Triskweline is finally available in a TrueType .TTF version!
Thanks to Vicki Brown for the conversion. Now go get Triskweline for your programming editor of choice.
September 11, 2004
Reformed Perl - Third millenium syntax for Perl 5 OOP
One day I looked at all the hacks and detours necessary to have Perl perform the most basic OOP, and decided that I'm not going to take it anymore.
Enter Reformed Perl, a pragma that pulls Perl 5 OOP syntax into the year 2004. Here is a rundown of the things it does:
Shorthand inheritance
Rather than using the cumbersome use base 'Parent' you may write:
package Child < Parent;
Shorthand parameters
It is no longer necessary to fish method parameters out of @_:
sub method($foo, $bar)
{
print "First param: $foo";
print "Second param: $bar";
}
Implicit self, class and base
References to the instance, the class (package) and the base class
are implicitely provided as self, class and base:
sub method
{
self->instance_method();
class->static_method();
base->super_class_method();
}
Pretty field accessors
You may omit the curly brackets in self->{foo} if you declare
your field names using fields:
fields foo, bar;
sub method {
self->foo = "some value";
print self->foo;
}
You may intercept read and write access to instance fields by overwriting getter and setter methods:
fields foo;
sub get_foo
{
print "Getting foo!";
return self->{foo};
}
sub set_foo($value)
{
print "Setting foo!";
self->{foo} = $value;
}
Clean constructors
All reformed packages inherit a basic constructor new from the Class package.
When you need custom contructors, don't overwrite new - overwrite initialize:
use reform;
package Amy;
fields foo,
bar;
sub initialize($foo)
{
self->foo = $foo;
}
You may call the constructor of a base class by calling base->initialize().
PHP overtaking Perl, and why it doesn't matter
Joe Johnston talks about PHP overtaking mod_perl in popularity:
Now, it's not that mod_perl suck (it doesn't) or that it's not useful in some situations (it is), is just that MOST PEOPLE ARE SIMPLY DOING CGI CRAP.
...and this is exactly why PHP's popularity shouldn't concern anyone developing in a real language. So what if there are three billion kids on the planet hacking PHP? For the largest part, PHP's userbase is operating on a level where you shouldn't consider it a boon if this sort of people suddenly decided to turn over to Camp Camel.
PHP was created for one reason: To provide easy access to quick CGI hacks for amateur programmers (certainly there are people developing serious applications using PHP as well, but these aren't responsible for PHP's massive rate of growth). PHP's crudeness is actually by design in order to lower the barrier of entry for people who struggle with other things than programming in their day job.
Don't compete with PHP for these kinds of people. They don't want nor need something more sophisticated.
September 10, 2004
Welcome to Software will save us
Now that Real World Semantics has been on hiatus for a while, I'm giving this weblog thing one more try. Welcome to Software will save us.
