|Perl Monk, Perl Meditation|
There's Only One Way To Do Itby jdporter (Canon)
|on Apr 06, 2004 at 14:54 UTC||Need Help??|
I was pondering the question "Why do some people think they enjoy programming in Java?" Software engineers who use Java will tell you that they revel in the expressive power of the that language, which enables their craft and creativity to flourish.
But wait! Java isn't like that, because Perl is like that... and they can't both be. Right? I think they can, because it happens at a different level.
In Perl, we feel liberated by the fact that (for example) Perl already has an auto-sizing array type built in; we don't have to invent that wheel yet again. Perl has approximately 3.2 jillion distinct features built in. Perl programmers can "focus on the application itself", on its high-level structures and algorithms, and not worry about, for example, how to iterate over a list of heterogeneous objects.
But in Java (and most other languages) the programmer needs to think not only about those higher-level issues, but also about the lower-level structures and algorithms, and to implement them — or at least to choose the desired ones from libraries of such things. This is why it takes 5 days and 1000 lines of code to write a "hello, world" CGI in Java. Or whatever.
So, in many critical respects, Perl is the language of Only One Way. There is only one way to implement a sequence: an array. There is only one way to implement an associative array: a hash. There is only one way to search for patterns in a string (setting aside the trivial index function). And so on. Of course, if you really wanted to, you could do any of these things another way. You could choose to ignore the power of the constructs perl gives you for free. You may decide that a singly-linked list is appropriate for your application, or maybe a b-tree. People do this with some regularity.
For example, there is only one way to do classes in Perl. That is, there is one intrinsic way, which uses namespaces, @ISA, the special semantics of the -> operator, and so on. But some folks have felt this style too limiting, or not limiting enough, or too arcane, or just simply not OO enough. Thus we now have Moose, and the plethora of modules in the Class:: namespace, as well as basic techniques such as "inside-out objects", message-based object protocols, etc. etc. Java, of course, gives you no choice at all about how to do OO.
So, while Perl goes to great lengths to permit more than one approach to any problem, there are certain questions for which Perl hands you a "no-brainer" answer on a silver platter. In these cases, we're pretty close to Only One Way.
Previous node on similar topic: TOOWTDI (There's Only One Way To Do It)