Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Revelation (4242)

Revelation
  (email not shown publicly)

Journal of Revelation (4242)

Sunday November 23, 2003
04:38 PM

Slick Rick: Free!

Since I haven't posted in a while, I figured I post some news for my fellow use.perl-ers. Rap artist Slick Rick is free, once again!

A lot of people won't remember or know his old school story telling, some may remember the hit "la di da di" (we like to party), but Ricky D remains a living legend in my book. I can't wait for a concert in the tri-state area; I'll definately be there.

Anybody want to meet me at a future Slick Rick concert? :)

Monday June 23, 2003
09:43 PM

Beware Of The Sigil:

Some more thought about the development of Perl 6- in relation to Perl 5. I consider myself an avid Perl user, who has become better and better at the language as time has gone on. I consider the sigil in Perl 5 to be one of the nicest and most natural constructs, because it gives me an immediate idea of what type of data I’m dealing with. However, as Perl 6 continues to steamroll its way along, I’ve become to fear what’s most natural to me- the sigil! That precious $, @, and % is lashing out at me, and why? Why is because I’ve accrued a lot of knowledge about clean OO programming with ruby (Perl’s OO system is a smokes and mirrors kludge that does its job admirably) and I love the elegance of its constructs. It has always made sense to me to hierarchicallize my data- in auction scripts or other scripts I’ve freelanced for it’s always made things so much simpler to find- and as such I love doing the same even with datatypes.

Perl’s evolution is with me: Perl 6 is doing essentially this- hierarchicalizing datatypes. So much so that, from what I understand from Apoc, and Exegis, I believe sigils will not really mean that much (they'll be the standard definitions, which will be a lot less loosely enforced). Furthermore, there will now be opaque objects, which are basically what I want. If they're implemented as I wish (we'll see- they hopefully will be!), you can consider this a justification of them- otherwise, you can consider this a personal warning. However, it continues with the basic three datatypes that it has always had. Coming from a Perl background this makes sense, arrays, hashes, and scalars (which encompass closures, references, etc.) are all I’ve ever needed and used. Unfortunately, coming from a linguistic background, this pisses me off: I expected to be able to subclass “Arrayâ€, and make my own datatypes, without using the sometimes-wonderful ruby construct obj.instance_eval(). I wanted my own defined datatype to be no different from the basic three datatypes- it would be nice if my own “Pseudo-array†class, for instance, would have the same basic look and implementation as the array class- although it wouldn’t be adopted by so many programmers (I think), it’d be possible for not a massive revision to take place, if it was somehow adopted as a basic datatype, or an important datatype.

This would be, to me, the ultimate proof that Perl 6 was the community’s rewrite instead of Larry’s. The community would be able to contribute to what was considered even a basic datatype- such that a basic array could even be modified, if the community thought it should be different. This is the type of revolutionary thought that made perl the asset to the programming community it initially was. Yes… I know that I could probably write code resembling my @item is PseudoArray, but the first thing people are going to think is “that’s an arrayâ€- and as such its default behavior would have to resemble an array rather than a hash. What if I wanted to have its default behavior resemble neither? Would I be able to do my item is PseudoArray, and if so will people test to see its superclass or just get incredibly confused as to why the item has a sigil? I’d prefer my hypothetical pseudo-array class just had a little bit more weight against the titans of Array, Hash, and Scalar. Regardless of whether this suggestion is taken into account, I’ll use Perl 6- probably more avidly than I’ve used Perl 5, but sigils just continue to scare me.

NB: One thing that I’m really hoping is that strings will act like both an array of letters, and a single string (even stronger implicit conversion, which is what makes Perl such a great language for me- actually this conversion isn’t all that implicit, since we’re telling it to return an array- however it’d be great if it was implicit- so that .string.letters would hold $.string (held by scalar, or string) @.string ( held by array or letters ) and %.string (held by some third field- hash?). It’d be nice to be able to do:

foreach $letter (letters $.string) { print char(ord($letter) + 1);}
which would translate to:
foreach $letter ( (.string.letters) ) { print char(ord($letter) + 1 }

and the same would be true of a pseudo-array:
foreach $letter( .item_which_actually_hold_a_pseudo_array.letters ) { }
At least Larry could consider disallowing IO and other things to go by the external label ‘item’, so that instead a superobject of some sort could go there instead for those of us who wanted all datatypes to be equal. If the superobject exhisted, arrays, hashes and everything else wouldn't be allowed for that symbol. Or if they were allowed, they wouldn't be decared, only used as references to the superobject's method.

Monday June 16, 2003
12:10 AM

Method Chaining (Regarding A Recent Perlmonks Discussion)

I'd like to discuss why method chaining is bad for widely distributed modules in response to this discussion. I've decided to put it in its own node, because I believe that the topic of why NOT to use it could be very important. I hope that if I share my rationale of the use of method chaining and how it hurts large packages, people will reconsider their belief in that technique. To begin with, it'd be nice to define method chaining- my current definition is chaining a series of methods that work off of a single object. It's used most often for attributes to an object, but I guess it could be used to actually call methods. It's major advantage is that it allows for great brevity, and demonstrates the interconnectedness of the attributes, as well as puts them in a single place.

All of these are good things, and as demerphq said, it seems to make sense to write:

print Data::Dumper->new([$foo],[qw(foo)])->Indent(2)->Purity(2)->Dump();

instead of:

print do{my $d=Data::Dumper->new([$foo],[qw(foo)]); $d->Indent(2); $d->Purity(2); $d->Dump()};

however, this is a rather short sighted consideration, when one looks at the cons of method chaining. If our criteria is as said "easy things should be easy, and hard things possible," we must adopt some sort of standard to make maintanance programming (one of those easy things) and extending packages (another one of those easy things) easy. Method chaining betrays the later, and even makes the former rather hard.

Consider even the previous example. A perl programmer, who is familiar with Data::Dumper, would automatically assume that you're modifying multiple attributes of the dumper object. However, a maintanance programmer, or basically anybody not familiar with it, would infer that the programmer is changing the purity of the indent, not the greater object. This is because programming standards (think of them as extended but unenforced grammer, the degree of scrictness after use strict;,) would dictate that as we go further from the left, we get more and more specific, that we are modifying the attribute.

But who cares about standards? One shouldn't have to contort oneself to fit into some arbitrary coding scheme when there is no reason to. We're basically selecting a design that isn't common. The problem with that is twofold, first that the majority of people would not consult a reference for such a small item of concern and they would further probably assume that the common standard is being used, and second that the very standard used is used for a reason...

It's the sad truth that method chaining leads to problems for people who don't read the documentation, but that it also leads to inflexibility and problems for maintanance programmers. The inflexibility is that of being forced to have seperate accessors and mutators, because accessors have to return the data accessed, wheras mutators are now returning the object modified. This can be delt with by just checking if $_[1] is defined and sending $self if it isn't, so I don't see much of a problem with it. However, method chaining at that moment makes even less intuitive sense, because I'm using the same method with completely differant results, one of which is the parent object, and the other of which is an internal part of that object.

But I can cope with that. No big deal. The second problem, however, is something I can't deal with. Consider, from perldoc:

$object->fullname('thadeus');

# But my system's gotten more complicated.
# so now I'm going to make fullname into an
# object of its own.

$object->fullname('Thadeus Barton')->christian('Thadusky');
$object->fullname('Frankeus Muss')->hobbessian('fransko');


You've created the maintanance/extensibility nightmare of all nightmares! Now it's necessary to document what is a chained method and what isn't. You've also made it possible to do: $object->size('large')->fullname('Frankeus Muss')->hobbessian('fransko');

It's a sad day for whoever has to work with that code. So we have to make a decision between the two? If there's a good chance we won't need to extend our work, why do so? Although being able to transparently extend objects (change how it's implemented) without changes usage is one of the major reasons people encapsulate data, it can be sacraficed for DWIM. To me, getting rid of that layer for a few silly strokes is futile. Especially when there's a perfectly valid alternative- all of this, because you were to lazy as a programmer to just have a single set method, which would be the only thing needing documentation:

print my $d=Data::Dumper->new([$foo],[qw(foo)])->set(Indent => 2, Purity => 2)->dump(); # If brevity is all too necessary.

my $d=Data::Dumper->new([$foo],[qw(foo)]); $d->set(Indent => 2, Purity => 2); print $d->dump();


At least this way you're not tredding on OO dogma.
Gyan Kapur
gkapur@myrealbox.com
Monday May 26, 2003
01:58 AM

Ruby And Perl

Having taken a brief hiatus from Perl, I've discovered a new comfort with Ruby. Most programmers who use Perl religiously :)rather than as a tool are probably pretty comfortable with what Perl has to offer, but for those of you who want to know more about Ruby and Perl here's my examination.

deprecated got part of it right when he said a younger, fresher, prettier language. However, that statement should be qualified: Yukihiro "Matz" Matsumoto has created a programming language that has evolved beyond respectable. He has a created a language that is theoretically cleaner and more pure than its predecessors, including Perl. He has designed a language that makes writing consistent, concise, and flexible code easy. Furthermore, flexibility to Matz is extensibility, which comes from the deep object-oriented nature of his language. That nature has made Ruby code a joy to work with, and easy to interpret, regardless of who wrote the original code. It has made Ruby code transparent .

This all attests to the power of Ruby in the appropriate framework. Unfortunately, by creating a language that makes code maintainable, Matz has made 'ruby hacking' extremely ugly, and gotten rid of some neat idioms (that's only a bad thing to those of us who like to code 'cool' programs). Ruby has become almost too systematic or boring for users who aren't using the language to program professionally, and therefore it has hindered its own growth.

Although it looks to be rather successful in Japan, Ruby's success in America has been limited to knowledgeable programmers. That would seem like a good thing initially, but it has proved to be hurtful to the language. Ruby has not needed to combat bad programming styles like Perl has (that need for Perl has been expressed by one 'Andy Roonie' style critique of Perl), but it has also been unable to gain the mass appeal and audience of and to unknowledgeable programmers possessed by Perl.

So a novice go to Perl before Ruby (I was initially attracted by Peril’s code for that reason compared to even C), and because of the sheer volume of Perl users code gets published at a faster pace. This means that Perl libraries will constantly be ahead of Ruby, and all those programmers that are in love with CPAN will never get comparable results with RAA. The musings laid are part of the greater implications:

The Greater Implications Of Ruby's Successes For Perl:
Perl has a wealth of features it can (and will) draw from Ruby in Perl 6. To me, what Perl needs to draw most from Ruby is its organization. If Perl can make organizing programs as easy as Ruby, it will be a much stronger language. However, the language cannot loose its flexibility and hacking nature. When it comes to programming, in the end it's all about popularity, not theory. From what I've read, this is exactly what's going to happen. People who want Perl to be clean will get clean Perl.

Perl has already decreed its drawing of syntax from Ruby (I expect OO syntax to be very similar to Ruby's, which has proved exceptional.) However, to me, allowing an array of a certain object, hash of a certain object, and scalar value for a certain object is natural. The same is true for Damian and Larry, which is evidenced by the decision to let go of typeglobs. Instead, the symbol table will now be full of $package::'@symbol' or $symbols, depending on whether the item is an array, hash, or scalar, etc. However, I'm skeptical as to how one could accomplish the combination of this new symbol table with the idea of @Array is Array. Doesn't that create objects with immutable types at the most basic level? Isn't that exactly what Ruby's 'an object is an object is an object' mentality tries to prevent? How will the two mesh? I fear the solution could be rather verbose I trust in Larry and Damian to design a system, which blends the two. There decision may be one of implementing objects internally, and making an externally arbitrary difference between arrays and hash in the symbol table.

The Greater Implications Of Ruby's Failures For Ruby:
For Ruby to grow further, it has to create a repository and resource of code that rivals Perl's. Ruby, as a language, provides tools for development that Perl doesn't have, but Perl has CPAN. Therefore Ruby's ease of use is offset many times by Perl's libraries, many of which one has to create on his or her own with Ruby. I'm not sure how possible this is to fix, because my previous outlining of Ruby vs. Perl has attempted to show, that CPAN is a result of Perl as a language, its flexibility and hackability of novice users contributes to a great archive of code as those users progress. However, if Ruby puts a valid initiative into building an archive of Ruby (or possible of all languages) that has the features of CPAN, and eminent Ruby programmers come out of the woodwork, Ruby should be able to make a valid repository, one which would make Ruby a much more viable alternative to Perl.