I am very interested in programming languages- their expressiveness and the tools each offers-, and looking at Perl from that perspective there is one interesting thing that I came across- the object system. As far as I can tell, an object is simply a reference that can be tagged as an object (blessed) such that, when referenced, will allow methods in the module it was tagged to be called with it as the first parameter. The interesting thing here is that the reference may be to anything. It looks like it is often a Hash because of their versatility, but it does not have to be- it could be any value.
The reason this is interesting is that it adds a little something to the concept of an object. I'm not sure what the implications are, but I like that its a little different and gives Perl's objects some personality. They need the extra boost, because otherwise they have a bit of an identity crisis I think- are very implicit and ad-hoc (there is no explicit syntax even) and its a little hard to see what they even are. Interestingly it is useful for the reference to be to a closure, and we can get some information hiding (important in OOP) from this.
If you're going to be doing work in Perl, there's one book I can't recommend highly enough: "Perl Best Practices", by Damian Conway. Indeed, I'd recommend that book highly to a programmer in *any* language, as it presents an excellent approach to software development.
ReplyDeleteThe main philosophy of Perl can be summed up by the motto TMTOWTDI: "There's More Than One Way To Do It". This is the language's greatest strength, and it's greatest weakness; it's strength is its power and flexibility, and it's weakness is that the language enforces do disciple at all, of any kind, so a disciplined, skilled programmer can write very readable, reliable, modifiable code - but the word is filled with a great many undisciplined programmers.
When it comes to objects, I also suggest you look into Moose, an object creation system written in Perl, one which allows you to create and manipulate objects without having to resort to the horribly kludgey (IMO) mechanisms used in native Perl... but, given your comments, you're probably going to want to "roll your own" object paradigms.
I'll be very interested in hearing about your work, and about how your experiences work out in Perl. What sort of applications are you planning on writing? At one time, I was considering doing AI research in Perl, but came to decide the language was just too awkward for me for the sort of work I wanted to do.
Another book I think you'd find interesting is "Higher Order Perl", by Mark Jason Dominus. It covers topics such as (from the TOC):
ReplyDelete* Recursion and Callbacks
* Dispatch Tables
* Caching and Memoization
* Iterators
* Infinite Streams
* Higher-Order Functions and Currying
* Parsing
* Declarative Programming
It contains a lot of interesting programming paradigms in one book, and all implemented in Perl (but applicable to other languages).
I have looked a little at Higher Order Perl, and I hope I find time to read at least parts of it, as well as look into Moose. I don't plan on using Perl for more than a small program to document other Perl (not a personal project obviously). I'm finding it hard to be interested in languages that lack any sort of formalism- which I will post about soon.
ReplyDeleteThe object tag applies to the referenced entity, not to the reference itself.
ReplyDeleteAs with most languages, if you take it for what it is, you might like it, but if you see it as a broken version of some other language, you will hate it.
I may be a bit harsh on Perl- it does seem very good at what it seems to have been intended for. I really believe that mathematical formalism provides immensely powerful tools for programming, however, and pure functional languages (among other paradigms, but I'm a fan of functional programming) provide a very nice setting for such mechanisms.
ReplyDeleteThanks for commenting, by the way!