Differences between version 15 and previous revision of WhyIHatePerl.
Other diffs: Previous Major Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 15 | Last edited on Friday, November 21, 2003 1:59:40 am | by AristotlePagaltzis | Revert |
| Older page: | version 14 | Last edited on Friday, November 21, 2003 1:55:11 am | by AristotlePagaltzis | Revert |
@@ -85,23 +85,23 @@
----
!!! AristotlePagaltzis and his soapbox
-[Perl] has weaknesses (more on that later)
, but it follows the principle of [Mutt]: all [ProgrammingLanguage]s suck, this one just sucks less.
+[Perl] has weaknesses, but it follows the principle of [Mutt]: all [ProgrammingLanguage]s suck, this one just sucks less.
If you read this page from a [Perl] hacker's view, you will continuously stumble over three things:
-# The original author is unwilling to learn references, which are the sole key and foundation to complexity and power in [Perl]. You may argue that you don't want to do so; fine, then [Perl] is not for you. But that the language separates the reference from the referee
can in no way be construed as a weakness. Au contraire, it gives you control.
+# The original author is unwilling to learn references, which are the sole key and foundation to complexity and power in [Perl]. You may argue that you don't want to do so; fine, then [Perl] is not for you. But that the language separates the reference from the referent
can in no way be construed as a weakness. Au contraire, it gives you control.
# Most of the people say "well I couldn't be bothered to learn [Perl] thoroughly" often followed by something along the lines "things didn't seem how I expected them". Well, [Perl] is [Perl]. If you wanted to learn a variation of some language you know, then why did you try [Perl] in the first place? If you're approaching something new with preconceived notions, you're going to return to your old ways pretty soon.
# The argument that "you ''can'' write clean [Perl] -- but people don't!!" comes up often. To that I say "real programmers can write [Fortran] in any language."
!! Keys to [Perl]
The first I have to say is that [Perl] is ''hard'' to learn. It is optimized for ease of ''use'' rather than ease of learning - a concept that seems to be foreign to modern computing (cf [GUI]s). It is not a language I would give a programming beginner to learn with, either, for exactly that reason. You don't put a greenhorn who just got his driver's license in a 200 HP sports car either, nor on the wheel of a 50 ton Mack truck. In that sense, [Python] fills an important gap - many people only write a few lines of code occasionally, and they're better off with a tool that guides them. If you only want to write a few lines of code occasionally, don't learn [Perl]. You'll only end up hurting yourself. A lot of people have, and the result is literally hundreds of thousands of awful scripts floating around on the web.
-Secondly, although its [C]-like syntax and (surprisingly small)
[C] heritage may have you thinking otherwise, [Perl] is a list oriented language. It understands arrays as a type natively - in contrast, arrays in [C] are syntactically glorified pointers that, as far as the language is concerned, point to a single value. All variables in [C] represent only a single value; it has no notion of a list. [Perl] is much closer in spirit to [LISP] than [C], and indeed there's a lot of crossbreeding between [LISP] and [Perl] hackers. (I love [LISP] as well, myself.)
+Secondly, although its [C]-like syntax and [C] heritage may have you thinking otherwise, [Perl] is a list oriented language. It understands arrays as a type natively - in contrast, arrays in [C] are syntactically glorified pointers that, as far as the language is concerned, point to a single value. All variables in [C] represent only a single value; it has no notion of a list. [Perl] is much closer in spirit to [LISP] than [C], and indeed there's a lot of crossbreeding between [LISP] and [Perl] hackers. (I love [LISP] as well, myself.)
-Lastly, there's the issue of references I mentioned before. Any high level language builds complex nested structures out of simpler ones. [Perl] is no exception, it just makes this process explicity
and in that way also lets you distinguish between the referee
and the reference, where other languages conceal the latter. That said, in simple cases, [Perl] lets you pretend the reference isn't there, and my experience is that with a certain fluence in data structure layout for [Perl] code, the simple cases account for 60-95% of all uses, depending on what you are doing. The derefencing syntax for more complex cases is rather ugly and not something even [Perl] hackers cherish, though. ([Perl]6 promises to relieve this.) All that said, it isn't very difficult. With a bit of thought you should achieve any kind of manipulation you wish, something lanugages which hide the reference from you can't always offer. If you want to learn [Perl], take your time to understand how (de)referencing, it is the sole key and mechanism to complexity management in [Perl] - it might be inconvenient to learn, but ''all'' advanced mechanisms in the language hinge on references. Once you master them, all of the language is at your command.
+Lastly, there's the issue of references I mentioned before. Any high level language builds complex nested structures out of simpler ones. [Perl] is no exception, it just makes this process explicit
and in that way also lets you distinguish between the referent
and the reference, where other languages conceal the latter. That said, in simple cases, [Perl] lets you pretend the reference isn't there, and my experience is that with a certain fluence in data structure layout for [Perl] code, the simple cases account for 60-95% of all uses, depending on what you are doing. The derefencing syntax for more complex cases is rather ugly and not something even [Perl] hackers cherish, though. ([Perl]6 promises to relieve this.) All that said, it isn't very difficult. With a bit of thought you should achieve any kind of manipulation you wish, something lanugages which hide the reference from you can't always offer. If you want to learn [Perl], take your time to understand how (de)referencing, it is the sole key and mechanism to complexity management in [Perl] - it might be inconvenient to learn, but ''all'' advanced mechanisms in the language hinge on references. Once you master them, all of the language is at your command.
!! Why shortcuts are good
From command line switches to the infamous ''$_'' variable to file operations, you can let [Perl] do a lot of your work when you can't be bothered to spell it all out. This does not mean you always should, but makes development a lot easier. I rarely know beforehand exactly how I am going to implement a program; being able to take shortcuts while I work on it until the final form crystalizes is very convenient. These shortcuts also improve maintainability if used in appropriate places, as well - the reader of a piece of code does not have to parse a lot of explicit red tape to come to the conclusion that it's just red tape and can be ignored in the greater scheme of things. The actually meaningful bits make up more of the code and so get more attention. O.c., abusing abbrvs mks anything < rd'able; I often go back once I have settled on a certain structure and remove or add shortcuts in order to make the coder clearer.
