The Secret History of Perl 279
TimToady writes "Many otherwise intelligent people seem to think that Perl just sort of happened by accident. But Linux Magazine has just now put their October issue online, and it includes an article entitled Uncultured Perl: Perl's Creator Shares his Thoughts on a Subversive Lifecycle. It's basically the secret history of how Perl infested the world, intentionally subverting everything in its path including
the NSA, Unix, and the GPL. " Reading Larry Wall stuff has to rank as one of my favorite reading experiences.
Perl - a new mainstay in the world of unix (Score:1)
Its incredibly useful to know that like sed/awk/grep, perl is and will be available on nearly any useful OS you can install.
You can gripe about the syntax, bitch about "readability", but the fact is, once you learn it you'll be hard pressed to use much else. Perl is here to stay.
Re:Python Bigotry (Score:1)
Some with P*. Perl is older and more popular. Hence it has more users. It's userbase is a cross between Java's and Javascript's, the former generally know what they're doing, and the latter, um, don't. Put VB people in there too. You know some of these people would be happier with Python than Perl, but they use Perl all the same. I doubt even the most rabid advocates of either language would claim that either syntax is perfect for every mindset. Perl's syntax is very, very different and matches a specific type of programmer. In the same way, Windows is a good match for some people. But I seriously doubt they're good matches for everyone using them. There are some "programmers" using Perl who would be well-severed by a bit of enforced indentation.
Now I'm not pretending that all or even most advocates act this way. But in the ideal form...
Re:Interesting statement[s] (Score:1)
Re:Perl is *NOT* Hard for Beginners (Score:1)
Scalar/Reference problem also exists in many langs (Score:1)
$S_foo = "Plumber";
$FR_foo = \
Where "S" is for scalar, and "FR" is for function reference.
Even if you don't like this in particular, you get the drift.
And before you respond with - "what about type globs???" - simple - don't use them.
Re:Articles vs Comments (Score:1)
The bitch, of course, is the time it takes to read through all the comments to find the diamonds in the rough. Fortunately this article has been the veritable South Africa for such uncut diamonds; one doesn't have to look far for quality writing.
Kudos to you.
jeeze, won't you all just pipe down! (Score:1)
let's keep things to a low roar (as my father would say)...
/ k.d / earth trickle / Monkeys vs. Robots Films [xoom.com] /
Re:There *is* such a thing as too much flexibility (Score:1)
--
Re:Python Bigotry (Score:1)
--
Re:Crazy guy, crazy language (Score:1)
$S = "Plumber";
$S = \
$S = Plumber;
Now a good Perl programmer could tell you the difference, but give a non-Perl programmer a copy of "Programming Perl" and see how long it takes them to figure it out - quite a while I would expect. In contrast, Python has no such complications - the syntax is much cleaner (even if you only use the primitive metric of the number of %, $, @, and & characters in the average piece of code).
To say that all languages are like this is simply not true. I program in C, Java, C++, Python, ML, Prolog, and when I have no choice, Perl. Perl is the only one of these languages where I absolutely could not write a piece of code without a syntax-reference manual to-hand. In fact, I doubt if all but the most experienced Perl coders could write anything non-trivial without looking at a manual.
--
Re:Crazy guy, crazy language (Score:1)
--
There *is* such a thing as too much flexibility (Score:1)
Now when most people see angle-brackets in a conditional statement, they expect them to be greater than, or less than, this will (and does) lead to confusion, particularly in complex statements. You asked for an example, I have given you one. The problem with a language full of neat little short-cuts like Perl is, is that while you only need know some of the shortcuts to write Perl code, you must know all of them to understand it. I don't think there are many people, even among skilled Perl coders, who could claim to know all of the neat tricks available.
--
Re:Crazy guy, crazy language (Score:1)
--
Re:Legos kiddies and professional architects (Score:1)
--
Re:Crazy guy, crazy language (Score:1)
--
Crazy guy, crazy language (Score:2)
--
Re:Crazy guy, crazy language (Score:2)
But that's not really a good reason to decide what languages to learn.
If you are interested in human languages you should enjoy Perl. Perl has in my mind the distinction of being possibly the only language that is at once genuinely different and innovative and at the same time widely used and practical.
For me, learning Python would be like learning Esperanto. I don't like my languages clean, I like them clever and I like them useful.
You boss might have fits at the notion of a programming language with the capacity for slang, but once you're there, you're hooked.
Hmmmm. Perl - the thieves cant of the Internet
Re:Crazy guy, crazy language (Score:2)
Sure, Perl's syntax for dereferencing sucks:
@array{$listofarrays->[$element]}
But them Perl's syntax for interpolation rocks:
print "We had $start pounds, and bought $number apples for $price per apple.";
And as for Perl programmers needing a manual, yes, that is true, because Perl is a big language with a large number of builtins. So what - Unix is a big OS and most sysadmins will frequenty need to do a quick 'man' to check out flags and arguments and such. Same with Perl. It's not big deal.
Re:Articles vs Comments (Score:2)
--
Re:This argument is tired and untrue (Score:2)
It's true that two people can write two well-designed Perl scripts which achieve the job elegantly and correctly, and yet each use a feature of the language which the other has not encountered. Perl prides itself on the fact that you don't need to learn the whole of Perl in order to get stuff done -- and yet as a result, learning the whole of Perl becomes more difficult than learning the whole of other languages.
It's certainly possible to write large scale software projects in Perl (define some standards at the very beginning. Tell your coders what features of Perl they may not use.)
I keep meaning to learn Python. I like its philosophy. For the record, one the strengths Guido claims for Python is that it works excellently in 100k LOC programs: you prototype in Python, then profile, then replace the slow parts (which will be 5% of the code) with C. Python is friendly to that kind of approach.
--
Re:Perl and Y2K (Score:2)
Localtime() is inherited from C. Man localtime says "tm_year - The number of years since 1900". Arbitary, yes, programmer-unfriendly, yes, but a bug, no, and its behaviour is well documented.
Far worse, is the javascript year function I hear about (I've nver used Javascript personally) - where the function returns the last two digits of the year if the year is 2000, then from 2000 onwards, returns the whole four digits. I dread to think what fevered mind thought that one up.
--
Talk is Cheap (Score:2)
- Tom Christiansen is an author and lecturer...
And a damned fine one, I'll freely admit.Tom Christiansen is not someone who has planned, staffed, lead or coded a large, commercial software project at any time since the "e-commerce explosion" began in 1995 or so. Tom Christiansen is a zealot so blinded by his Perlcentrism, that he predicted that Java would be too complicated to catch on [perl.com] with "ordinary programmers." [LOL]. More humor at perl.org is a three-year-old rant [perl.com] about how some Perl vaporware is going to squash Java completely.
I find it endlessly hilarious and completely ironic that Tom repeatedly accuses people of not understanding the basic realities of the programming world. Utterly hilarious.
Re:Talk is Cheap (Score:2)
- [Who really uses Java for] their day-to-day automation tasks? Have Java overtaken Perl, or even C, for web-affilated tasks?
... [Java is] still a load on any browser running today...
Your point isn't exactly "wrong" but it is making some common mismatches.First of all, what's a "day-to-day automation task?" If it's munging a logfile and posting the results to a web page, you're a sysadmin and you do use Perl (you'd be silly not to). If it's supply chain management, you are an "enterprise user" and you are increasingly likely to use Java (you've never used Perl).
Second of all, people who jump into discussions about Java by talking about how crappy applets are, are missing the fact that Java is becoming the language of choice for server-side, distributed program. Of course, this pisses off a lot of Perl programmers who feel it's "their turf."
What we see here (repeatedly) are sysadmin's saying "I use Perl for everything." Well, duh.
Then we have people who clearly haven't done anything with Java since it first came out nor do they work in the realms where Java is being used widely. "I coded a site to sell frozen doo-doo balls over the web and we used Perl!" Big deal. Just be glad you didn't have to use ASP.
Finally, are the repeated claims that Perl is easier for "non-programmers" to learn than Java. Uh, who cares what "non-programmers" do? That's their business -- meanwhile, I've got work to do and I need progammers to do it. What Tom claimed in his essay was that only "ivory-tower" elite programmers could program in Java and that's just plain wrong. Wrong wrong wrong. WRONG. Wrong. Wrong wrong wrong (wrong) wrong. So there.
Re:Crazy guy, crazy language (Score:2)
This is why lots of Perl code is so horrible. But, look at what this means to C. C doesn't have this same problem, because the language is so feature poor that you can't write a large program without some design skills.
People with the design and programming skills can write maintainable software, large and small. With Perl they can do it with a whole lot less effort, because it frees them from the mundane, build-your-own-low-level-data-structure game. And that's why Perl is a nice language.
scottwimer
Re:Crazy guy, crazy language (Score:2)
I think Perl is the "right tool for the right job" - you just have to be sure you're doing the right job with it.
Perl is a godsend for CGIs and fills a role no other language does. It's:
I came to CGIs knowing C and tried hard to like it for that couldn't - the C programs were twice the length of the Perl examples and then I had to deal with new compiler environment, knowing the size of arrays at compile time and other memory issuses. All of these went away with the conversion to Perl.
Perl is exactly what the web needed but was created before it even really knew it needed it. It's like Java but good and useful. ;)
=tkk
Re:Perl - a new mainstay in the world of unix (Score:2)
I won't argue the goodness/badness of perl. But I will argue that for real software (code that is used more than once), if it isn't maintainable, it's crap.
You utterly missed my point. I agree, unmaintainability is bad. But maintainability is ONLY ONE OF MANY aspects of good software. As you so delicitly put it "if it isn't maintainable, it's crap." But it's also crap if it doesn't work, it's crap if it runs too slow, it's crap if it's not done yet, etc. etc.
Saying maintainability is the only thing that matters is very nearsighted. I'll bet Win98 has some pretty maintainable code in it, but that does not make it a good OS.
Re:Perl - a new mainstay in the world of unix (Score:2)
In some environments, this is true. If you are writing the code to control balistic missiles, maintianability will be very important (second, I hope, to correctness). However, in some cases, maintainability falls third or fourth on the list of prioirites. Sometimes its not a priority. I'll give an example from my personal life. I'm learning morse code, and I was going to go on a 5 hr flight. Since I only have 1hr battery, and I wanted to save that for working, I made a minidisc full of code and printed the answers on a piece of paper. How would you generate 100's of random characters, store them in seperate files, encode them to
You make argue that that is not a production environment, mere scripting. This is true, but I would argue that the line between scripting and programming is a fine one. Regardless, there are even cases of production environments where maintainability comes low on the list. cgi/database applications in which getting the damn thing working is more important than being able to maintain it. Just try to implement slash in C. Sure you can do it. Sure you can do it well, and maintainable. I'll see you in 3 months, and you won't have showered in weeks.
And, even if you accept the tenet that unmaintainable is bad, Perl is just as capable of clean code as any other language. In that way, perl can be of the dark side, it makes it easy and tempting to write unmaintainable code. But, on the other hand, writing clean code in perl is just as hard as writing code in any other language. So, assuming you want to write clean code, perl is just as good. Just cause it can make messy code does not mean you are obliged to do so.
In short, TMTOWTDI. This can never be bad. This is why open source is good. It all comes back to freedom. You can choose between GNOME and KDE, Linux and *BSD, Perl and Python. There is always another way, another value set. Perl is just looser about its value set.
--Nick
Re: It doesnt have to be this way (Score:2)
Then you wouldn't need to use idioms that look completely baffling to the novice. (Although to be fair the diamond operator is one of the first things you learn.) And it's easy for users to see what's going on by looking at the source, and easy to define your own version. You also keep the diamond operator in reserve so you could use it for something else.
Re: It doesnt have to be this way (Score:2)
But - again IMHO - reading lines from a file isn't really suitable for its own operator. Having
$filehandle = open('filename') or die;
$line = readline($filehandle);
is probably more understandable than
open(FILEHANDLE, 'filename') or die;
$line = ;
OTOH, doing the same with the + operator would make code less readable.
Re: It doesnt have to be this way (Score:2)
Re:Crazy guy, crazy language (Score:2)
Is this not true of most (if not all) languages? One would assume that if one is trying to maintain already-written code that one has some knowledge of the syntax and language constructs. Frankly, I think well-written Perl is easier to read (more natural) than a lot of other languages. Compare the two following code fragments:
C
Perl
foreach $thing (@array_of_things) {
print "$thing\n";
}
Alternatively (and a bit more obfuscated, yet easy to read by an experienced Perl programmer:
print join "\n", @array_of_things, "\n";
There, was that so bad? I can see how it might be confusing that those two snippets do the same thing, but that's flexibility, and there's power in flexibility. Either fragment is much easier to natural language flow than the C fragment.
--
A host is a host from coast to coast...
Well you claim to prefer both C and C++... (Score:2)
And you criticize Perl for providing that concept under a syntax you don't like? A concept that most programmers don't require, and which is worse or non-existent in many other languages? Besides which, in Perl what it gives is perfectly predictable if you understand references. (Which are easier than pointers - however unlike C you can actually get useful stuff done without using them.) You \ something to get a reference, and then you can use the reference as if it were that thing. What could be easier?
Yes, there is a lot of syntax to Perl. By and large though it follows a very predictable grammar. Sure, most experienced Perl programmers may not know you can do something like
@foo{'bar1', 'bar2'};
but anyone with who is familiar with the language will have little trouble guessing what that should do. (Return a list based on multiple hash lookups in a hash.)
Complaining that you can write obfuscated code in Perl is like complaining that it is hard to correctly parse the correct English sentence, "Buffalo buffalo buffalo buffalo buffalo" and punctuate it appropriately. (Trivia, the word "Buffalo", repeated an arbitrary number of times, can always be parsed as a grammatically correct English sentence. This relies on the fact that it can mean either the animal or "to bewilder and confuse".)
Yes, you can obfuscate any language. You can also write clearly. And you can do either in Perl. Well I can at least...
Sincerely,
Ben
That is obfuscated? (Score:2)
Now I grant that "Programming Perl" is not the easist way to learn the distinction between the three. Most Perl programmers don't need to use references (unlike, say, C and pointers), so the middle one is likely to leave a lot of them scratching heads, and is buried pretty well in Chapter 4.
However how many C programmers would have trouble with pointers to functions? And how long would it take the average non-C programmer to figure out what a piece of code that produced one was doing given a standard reference? More than that, how big is the gap between learning how pointers work in C and figuring out what the heck something like
(this->*(facts_supported[i].factfunc))();
means?
Regards,
Ben
Re:Legos kiddies and professional architects (Score:2)
Re:Interesting statement[s] (Score:2)
Of course, the Linux Kernel isn't developed by volunteers, for the most part. It's more like building a cathedral that isn't blocked off by big "construction zone" signs. Then people with the ability are free to step on in and see whats going on, and perhaps point out problems or help in various ways.
-BrentRe:Legos kiddies and professional architects (Score:2)
What is X? Depends on what needs to be accomplished. C is not the best tool for every task. Neither is Perl. Neither is FORTRAN or Lisp or Java or
"Honest people, if you want something better than perl, build your own camel. Or get in perlguts and start hacking it yourself. That's what open source is about, right? "
Right on, man. I should probably add the following caveat to my above statements: You aren't a good Perl programmer unless you are familiar with the perlguts.
Re:Perl and Y2K (Score:2)
And it's been in the docs forever.
What on earth did you think the year *was*? I mean, when you have a "year" in a system you're told is Y2K compliant, and it's under a hundred, doesn't this inspire you to check how you use it?
This is *NOT* a perl problem, nor a design flaw, nor anything of the sort. It's a reasonably plausible design decision that was made about 20 years ago, and everyone has been told about it.
19100? (Score:2)
Re:There *is* such a thing as too much flexibility (Score:2)
The fact of the matter is that I am in no better position to say that Perl is easier to learn than Python than you are in a better position to say that Python is easier to learn than Perl.
My evidence, however, is anecdotal in only the trivial sense that all evidence presented in this forum is anecdotal since it is accounted by someone else. My experience with Perl and its use far exceeds your 31337 K1dz implications. Not only do I make very good money as a developer, have years of experience with professional Perl development, but I have also taught Perl for a living, and have wide experience with the experiences of others who have learned and used Perl.
And I still stand beside the claim that Perl is easy to learn and powerful to use. Presumably so is Python. Wonderful. At least you being a rabid Python user ensures that I won't ever have to deal with your sorry ass on a project.
Re:Crazy guy, crazy language (Score:2)
Re:There *is* such a thing as too much flexibility (Score:2)
If you'll check what I wrote you'll find I didn't say I was still learning Perl syntax after 5 or 6 years (damn, man, I'm not so stubborn not to have given up on the language by then if that were true!). The syntax takes very little time at all. Familiarity with the functions and library suite don't really take all that long. Probably after a year I'd never seen any new functions, and very few new things on CPAN of use to me (well that might be stretching it a bit, since CPAN does keep improving to this day).
The things that one learns after 5 or 6 years with Perl are very advanced techniques -- an occasional idiom, advanced data structure manipulations, more and more perlguts (2 years ago I was embedding perl interpreters in C and C++ programs, and linking in libraries (including SUID PVM libraries) -- ever see a C++ module which instantiates a Perl interpreter which embeds more C modules? fun stuff), distributed objects (think Perl CORBA), etc.
I can't remember having that much trouble with Perl syntax, to tell the truth. Maybe it's harder for some than others. I have seen garbage code by junior programmers in all languages. And gurus are gurus. The nice ones use comments that say things like "deep wizardry. do not touch." and mean it. When you spend enough time to see why then you really appreciate their handiwork.
I don't really spend much time looking up syntax for Java applications. Java's syntax *is* simple. But the language is contorted. Additionally, Perl actually is portable where Java has purported to be (this is the subject of too many holy wars for me to want to rehash). I stopped using Java, not because the language is bad, but because the current implementations are horrible, and Sun's behavior over the past 2 years has been unforgiveable.
YMMV of course.
Re:There *is* such a thing as too much flexibility (Score:2)
If you don't know the language, either learn it, or don't expect to know it. Perl has a different syntax than [ pick your favorite non-Perl language ] that's why it's Perl and not some other language. If you read the first couple of chapters of "Learning Perl" (much less any of the excellent and more advanced O'Reilly books on the subject, on the front of which you might have even seen Tom's name were you not too busy trying to figure out why those idiots left the "a" out of "Pearl") you'll get a perfectly good introduction to the operators, syntax, types, and some of the basic idioms of perl programming.
Perl is non-trivial, easy to learn, and powerful. Since TMTOWTDI you can learn a subset of the language and be perfectly effective forever, but you can also continue learning more about the language and become a better programmer. I have been programming in Perl for 5-6 years now and am still learning new things (and my programs become more robust and more portable). There's no magic "Perl pill" to swallow, there's no book that will teach you Perl in 21 days or 24 hours, but you can be programming usefully in Perl in 24 hours without much of a problem.
It seems to me that you are an outsider/newbie to Perl who was dismayed at the differences between Perl and your current favorite languages. I don't know much about python (and yes I've actually written some programs in it), and have never really gotten keen on it and could probably post a comment like yours about Python in a similar forum, but I know that there are a lot of python users who write good programs (Zope being one of my favorites), so there's no point in me ignorantly knocking an apparently good product.
So why are you?
Re:There *is* such a thing as too much flexibility (Score:2)
Re:Crazy guy, crazy language (Score:2)
Perl is an easy language to use. Any given 5-person+ company probably has Perl-capable employees (the comment about Perl books being on Wall Street desks has a lot of truth to it because even non-technical people find Perl incredibly useful). To increase efficiency in the company, find places where math and paperwork is being needlessly done by hand, apply some Perl, and a limited amount of efficiency increase will probably arise. Hiring a programmer to do Perl will probably result in more efficiency increases. Having little idea of what a company needs and hiring a cadre of Perl programmers (or any language) is probably a recipe for disaster.
Given a company that knows where it wants to go technically, which has or hires people which actually design the software to fulfill those needs and has experienced programmers which write the software in Perl (the language under discussion, but this holds true for most languages):
There are reasons a company chooses Perl as an implementation language in a large project (such as the hypothetical one being described), and they hire experienced programmers to execute it [hopefully]. The guy arguing that he gets confused about the use of greater-than-signs in while loops should never be allowed to touch the code for this project, because he can only screw it up. This is assuming that (as it should be) the code is as well-documented and cleanly written as possible.
Yes, the company is now "locked in" to hiring good Perl programmers to maintain this code. If it is feared that there is a problem with obtaining these people (over and above the problems we all have obtaining good people in this market anyway) then they should use a different language which has more available programmers. The fact that the company is "locked in" to having to get good programmers is nothing unique to Perl -- it is a hallmark of a good system which, if it was truly needed, is generating some substantial benefit for its owners.
If the company did not need this quality product then they shouldn't pay for it. I happen to get paid for being one of the people that designs and helps write such products, and a number of these have been in Perl (and because of this more of them probably will be in the future). The companies pay good money for my work (as well as all the other people I work with) because they want sophisticated code that solves difficult problems. I am not trying to toot my own horn -- there are hundreds of thousands of people doing the same thing I am for the same reasons.
The bottom line is that companies need to evaluate their needs well before throwing money at technical problems. This is independent of a good language like Perl.
Re:Crazy guy, crazy language (Score:2)
I'm sorry that you don't understand this.
Re:There *is* such a thing as too much flexibility (Score:2)
I'm not going to spell out the list of all the people in the past I have seen learn and use Perl, their backgrounds, whether they maintained code written by what types of programmers, which books they might have read, whether they used Cyrillic as their alphabet of choice, etc., to make you understand what I have been trying to say in this now-tired-ass-thread:
- I have seen a wide range of perl users, programmers, and students, and my opinion (having at one point learned Perl myself, and having dealt with Perl in a number of different capacities) is that Perl is easy to learn, is very powerful, and very flexible.
- there is a big difference between hacking up some scripts and seriously using/maintaining/designing-in Perl (I even spent about 20 minutes somewhere in this thread pointing that out)
- Perl is not a panacea. Perl has its place and its uses. There is no panacea.
- It takes work to learn. There is no welfare state in technical education: you either put in the hours and learn (this is true for everything -- the fact that some languages are easier to cut-and-paste programs than others does not imply that the cut-and-paster is a programmer by any stretch of the imagination). It is my opinion that most of the Perl naysayers in this thread have been just such cut-and-paste "programmers".
Re:Crazy guy, crazy language (Score:2)
If by "languages for morons" you mean "Written so that even morons can do something useful", I disagree. Granted, I can take anyone with half a brain cell and teach them to make a cute little "Hello, World!" program within 30 minutes. Given another 30 minutes, I can have them designing fairly complex dialog boxes.
But have you ever tried to produce something truly useful out of VB? It is useless for everything except Windows programming, and it is useless in Windows unless you know how to use all the @*&$ing objects that come with it. The language itself is simple enough, I'll admit, which is about as relevant as saying the English alphabet is simple.
Written for morons? Not likely. Designed by morons? Apparently.
Re:Interesting statement[s] (Score:2)
Re:Crazy guy, crazy language (Score:2)
Re:Crazy guy, crazy language (Score:2)
Why is it that any thread on slashdot about Perl have people saying "use Python instead"? Or should I say, how come that Larry gets such an interview, and Guido doesn't? If Python is so much better, then why don't I see as many Python items on slashdot as I see Perl items?
Mind, I'm not saying Perl is better than Python. They are different. For some people, Perl works better than Python. For others, Pythons works better. I would never recommend Perl as a first language; I might recommend Python. But there are lots of people who no longer need a language with training wheels, although some never can part from the comfort of having them.
-- Abigail
Re:Crazy guy, crazy language (Score:2)
@array{$listofarrays->[$element]}
Maybe it does, but your words would have more effect if you actually used valid syntax. Your syntax is so hopelessly wrong, I can't even guess what you want to do.
A normal deference would be:
$arrayref -> [1]; # Or
${$arrayref} [1];
Is that so much harder, than say, C?
-- Abigail
Re:Crazy guy, crazy language (Score:2)
This is true to a certain extend. That's why childrens books use a small set of words, and are often repeatative. But great novels tend to use a much larger set of words, and people don't mind different constructs of sentences.
-- Abigail
Re:There *is* such a thing as too much flexibility (Score:2)
Can you point out a language where you can maintain code based on knowledge of only a subset of the language? Letting people maintain code who only know a subset of the language is a sure way of disaster - in any language.
because the syntax is so flexible, almost everybody is only aware of a subset of the language
And you back up your claim with... ?
-- Abigail
Re:Legos kiddies and professional architects (Score:2)
Natural languages aren't context free, and people have surprisingly few problems with that. Why shouldn't a computer language use context?
When you want to change the type of a value you do it explicitly.
And doing it explicitly and not implicitly is good because of...?
In a language with well-defined types, it's trivial to overload operators so they do the right thing polymorphically
True, but look what you are saying later:
Syntax is helpful when it distinguishes different semantic domains;
So, first you bash Perl from not treating strings and scalars are different semantic domains, but yet is applaud the fact that it's possible to overload operators to do semantically different things based on the types of their operands. That doesn't make any sense. Could you please make up your mind which of the two you like?
Argument list flattening. Again, there are ways around this, but they require fairly sophisticated understanding of the language.
That's like saying that using pointers requires a fairly sophisticated understanding of C.
In fact, much of Perl's syntax is just pointless complexity.
That's not a fact, that's an opinion.
Why are references to aggregates prefixed with a '$'?
Because references are scalars and not aggregates. I don't find that hard to understand.
How come packages and classes are defined with the same syntax?
Because a class is a package. Remember: Syntax is helpful when it distinguishes different semantic domains. In Perl, there are no semantic differences between packages and classes.
-- Abigail
Re:Crazy guy, crazy language (Score:2)
Now, if we only had a standard Java environment....
-- Abigail
Re:Perl and Y2K (Score:2)
It is a Perl problem in the sense that it effects Perl too - it is however not only a Perl problem. Perhaps it isn't a design flaw, but it certainly isn't the smartest decision made by the people making the C standard. Returning years since 1900 doesn't help the programmer at all - now he needs to do work regardless whether he needs 2 digit years or 4 digit years. Years since 1 BC (the year before 1 AD, or the year 0 for the astronomers under us) would have avoided a lot of problems.
While not reading the manual isn't an excuse, you can't get away with stupid decisions just because you've documented it. I think it was a very unfortunate decision. It is of course way to late to turn it back. When designing Perl, Larry could have choosen that localtime would return 4 digit years. He preferred to follow the C standard, which has merrit as well. Had Perl be designed 10 years later, he might have made another decision.
-- Abigail
Re:I have to agree. (Score:2)
Re:Crazy guy, crazy language (Score:2)
Well, that's your opinion, and you're certainly entitled to it. Personally, I love it. I do a lot of text processing (with log files and the like) and Perl's regular expression capabilities makes it damn simple to extract the little bits and pieces that I need and arrange them into a usable form. Compared to what I used to do (bastardized conglomerations of Bourne shell, sed, and awk) Perl is a godsend.
However, if you have ever tried to maintain a perl program, particularly someone else's, then believe me, the fun drains right out of the experience.
Maybe, but it's possible to write shitty code in any language. One of the big promises of COBOL is that it was supposed to be "self-documenting"; a person should be able to take somebody's code, sit down with it, and read it from beginning to end like a Zane Grey novel. Well, anybody who has had the dubious honor to sit down with 100,000 lines or so of a payroll system written by some antisocial mainframe guy with a basement office knows that even a "self-documenting" language can be used to write some pretty nightmarish code.
It's possible to write bad COBOL code. It's possible to write obfuscated C code. And yes, it's very possible to write hard-to-understand Perl code. But that doesn't mean that it's the fault of the language. A good developer can write well-commented, easy-to-follow code in any language
Re:Legos kiddies and professional architects (Score:2)
Think about the Unix sort(1) program. Notice how it does not attempt to infer the type of its input stream. That's because it's a generic program. If you want to interpret your data as numeric data, than you are free to use sort -n. It's like that with Perl. *You* are in charge.
Ah, and just whose fault is this? I say that the fault lies with that other program for expecting so much rigamarole. Didn't we learn that ioctl(2) was bad, and simple text-based interfaces to controlling devices were infinitely better than binary crud?If you expect to treat your data like a string of digits, feel free. If you don't know what you want to treat it as, then I suggest you make that decision yourself. If you can't figure out how to do regex tests, there are manpages to help you.
I'm not being intentionally dense. I honestly cannot see your problem! In my world, you see, that `problem' simply does not occur.
I feel like you keep complaining about problems that occur in a two-dimensional world to someone who lives in a three-dimensional world rather askew from your own 2D plane, intersecting in only a few places.
I don't run crying to the makers of Unix to have them `fix' their filesystem so that a file has a "I'm full of numbers" property in its inode just so that the sort program can know whether to assume a -n flag or not.
So, too, with Perl. It makes these things easier by not distinguishing them. You've simply defined easier to be "hard". Perhaps you shouldn't be doing that.
Re:_open source_ (Score:2)
Sure, there are places Larry keeps a tight control over--just try wedging a few more lines of C code in the inner interpreter loop, for example. But by and large, the Bazaar around the edges is a richly diverse free-for-all where all kinds of people do all kinds of things.
themself (Score:2)
In any event, it most certainly is, which means this is another annoying case of paradiorthosis. :-(
See the entry for "themself" in the 3rd Edition of Fowler. Make sure you also read both Steven Pinker [crossmyt.com] and this collection [crossmyt.com] by Henry Churchyard, which is replete with endless examples of singular they and its declensions from the 1300s to the present day.
And as for the "themself" versus "themselves" thing, we use "yourself" when the antecedent is singular. For example: "You're going by yourself, aren't you, Johnny?" Notice there's no "yourselves" there. English has always done this, so "themself" over "themselves" works just as well now as it did back in 1570 when Caxton wrote, "Each of them should make themself ready."
Now, wouldn't it be nice to get back to talking about Larry's article instead of make false corrections? :-(
Re:What's up with Perl and Compiling? (Score:2)
But this isn't want you want to look at for the CGI performance issue. You'll get an order of magnitude (10-40x) by using Apache's mod_perl to pre-load the pre-compiled programs directly into your httpd daemons. The amount of support for Apache in Perl is phenomenal. In the Apache directory alone on CPAN, we have all these:
There's also a great book from O'Reilly called Writing Apache Modules in Perl and C [modperl.com]. It's got an Eagle on the cover.Of course, eventually even this breaks down. I don't think you want to handle 100,000 hits per second this way. For that kind of situation, you need to look into much more sophisticated systems of redundant daemons, sometimes with highly clever dispatch mechanisms way down low, such as with TCP splicing. See the latest Usenix `USITS' symposium proceedings [usenix.org] for things in this realm.
themself (Score:2)
If you can bring yourself to say "yourself", and I certainly can, yet still use a plural verb with "you", then it requires no stretch of the imagination to do the same thing with "they" and all its forms. Mind you: "themself" was in use long before we discontinued the opposition of "thyself" versus "yourselves" and started "yourself" versus "yourselves".
You shouldn't say, "We already have a meaning for `they'." You lead one to believe that the plural sense is the only meaning. It isn't. Not only isn't it the only meaning now, it never has been. "They" has always taken the role of a pronoun for an unknown antecedent. In modern speech, we see other interesting things happening with it, where even when the gender is known, but the exact identity is not, "they" is sometimes employed.
You can't just "invent" a new word for so important a job as a personal pronoun--not if you expect it to take hold. This is far too important a job. You can always invent new words for new things (although it's best if there's some parental etymon to lend meaning), and you can often invent new words for old things. But we already have an old word for an old thing: one that everyone intuitively uses and recognizes, irrespective of whether they happen to notice the practice or just go on blindly communicating using the language of their ancestors and their peers. (As in fact, I just did in the previous sentence. Did you have a fatal heart attack? No? Good. If you did, well, that's a real shame, but I'll just assume you aren't reading this. :-)
You'll never overcome the inertia of a word in adequate production in a critical role. I'd like to see you change around "we" just because it suits your fancy, too.
It doesn't matter if you argue from an artificial, presciptivist point of view, because the evidence of continual and widespread use since well before Modern English even existed up though our current day illustrates that this is a meaning that has always existed. You can't just invent grammars and impose them on language. The real people know how it works, and don't need to try to fathom Latin rules applied to a non-Latin tongue in order to understand this.
BTW, you forgot to hit "post anonymously" this time. :-)
Re:There *is* such a thing as too much flexibility (Score:2)
Re:Why Perl programs are hard to debug (Score:2)
Posting Code to Slashdot (Score:2)
Re:Legos kiddies and professional architects (Score:2)
Re: It doesnt have to be this way (Score:2)
And Perl *was* designed for an easy learning curve, you know. The people is was written by and for find it extremely simple. My grandmother probably wouldn't, but that's no one's fault.
Even though the readline operator was the oddest thing to me when I first looked at Perl, that was all of five minutes back on December 18th 1997. That's something like one and quarter million times that initial five unsettled minutes. Shall we reverse it and make me pay 1,264,032 times for something just to make some neophytes first five minutes somehow easier? I think not.
It's already easy to do so. This wouldn't improve how easily a perl programmer could read your code. One again, go for it.Perl has plenty of other operators in it that the Assyrians and the Sumerians never heard of. Big deal. That's irrelevant. If you want to use English, go for it. If you don't want to use what Perl offers, especially its regular expressions, for fear of a new operator, then perhaps you would be happier with something else.
I've never understood why people have trouble with things like this. It's all so easy. Just look it up, and now you know it.
Here are Perl's operators. Notice how finite they are:
Most of those are already familiar. The few that aren't, you can always look up, and then they will be. Perl doesn't go adding new operators willy-nilly. We got the spaceship in 91 or before, and the arrow in 93. Not much really happens since then. And we got the angle operator in 87. You'd think people would've gotten used to it by now.Of course, the regexes have their own language. Here they are:
I think only the extensions are a bit tricky: Maybe it's just be, but I think the only nasty ones are the parenned bits, and again, you can look them up.I'm big on the "look it up thing". From the my earliest days, we always had dictionaries and encyclopedias around the house. My mom, a teacher, was always having us look things up. And of course, every time you go to the reference book, you come away with more than you bargained for.
Perhaps I have an encyclopedic memory that others don't have. Or maybe I use this stuff more. I still look up some of the funny parenned bits Ilya has added. I don't mind that -- too much. :-)
Re:Articles vs Comments (Score:2)
Re: It doesnt have to be this way (Score:2)
Remember how much Perl was originally used in a filter-type environment. It's nice to have a succinct was to get a common idiom encapsulated in simple syntax. You know, like backticks, which seem the same kind of issue.
In any event, it's about twelve years too late to argue about. :-)
Python Bigotry (Score:2)
Re:This argument is tired and untrue (Score:2)
On the other hand, it always provides an escape into turbo power. And a far, far nicer escape, I hold, than writing something like:
If you're going to use Python, just realize that it's not going to be all that fast. The program (a mere ten-liner) I use to format for slashdot code blocks like the one above runs 10x faster than the less-functional Python equivalent offered up by one of its anonymous zealots. Of course, it's easy to see that this sort of problem is precisely the kind of thing that Perl is very, very good at. The best artisans and architects use a variety of tools for a variety of tasks. The most reasonable of the language advocates understand that there is no single truth. I've seen tcl and python and java people (by which I mean strong advocates and frequent users) all use perl for areas in which it excels, such as the one I just used it for above.Re:And now for something even easier to read (Score:2)
The equivalent to your python code in Perl is as simple as the following:
But thanks for the compliment on clean code. I realize it wasn't mine you were complimenting, but Perl thanks you.I believe that it's easy to write beautiful code in Perl if you want to. I'm very sad that people don't want to. Here's one old example [perl.com] where I've made a stab at using indentation to make nice code. I could probably put a bit more work in it. I've many more recent examples as well, if you care. I believe seeing good examples of well-formatted code is critical for a beginner. We tried to do that in the Perl Cookbook, but there's always room for more.
Re:Crazy guy, crazy language (Score:2)
Re:Legos kiddies and professional architects (Score:2)
And yes, I'm aware of programming-by-contract, with language-support of pre- and post-conditions. This is, however, a run-time issue, unless you've solved the halting problem. :-) Meanwhile, I just use asserts.
Perhaps you mean static type analysis. Perl has some of that, or, rather, can. For example, it will automatic inline certain kind of functions that it deems safe, much like a good C compiler, and unlike languages like Python. Another example is that there are situations where you can make perl raise a compile type explosion if you access a mistyped data attribute name in an object field, a type of functionality present in C++ but absent in Python. However, this is the exception not the rule, for Perl is really not much into static analysis.
But if you content yourself with dynamic typing, Perl's actually quite good with this. All objects are strictly typed. You can't coerce them as you can in C++. If you call a method from class Y on an object of class X, and class X is not derived from class Y, then you'll raise a run-time explosion.
What you and so many others constantly harp on is that Perl allows a "string" and a "number" to be used interchangeably as need arises. And I tell you truthfully: I do not understand you! I'm quite serious. Then again, this might be evidence that Sapir-Whorf was right after all. :-)
Strangely, those who complain of this flexibility never seem to decry with equally strident voices the ability to interchange floats and ints, or single-character items with multi-character strings; and seldom do they complain of a variable's use as a boolean.
What they're missing is how convenient it is for input and output that strings and number go back and forth. I don't relish having to call something like readinteger or readchar or readstring, nor having to call something like writeinteger or writechar or writestring. I was burnt too often as a young child by coredumps and consternation from scanf(3), sprintf(3), and their brethren ever to go back to that misery. (Maybe someday I'll tell you about the atrocity of rpmfind(1) some day.)
Please, let me just write$n = <FH> (or, if you prefer, $n = readline(*FH) ), and be done with the matter. I've got better things to worry about.
Re:Possible /. interview? (Score:2)
seconded. larry wall's one of the most interesting people on the planet. he's got an uncanny ability to wrap his mind around *everything*, and spit it all back out in a clear, consise, and humorous manner. he'd be ubercool for a /. interview.
mikeRe:Legos kiddies and professional architects (Score:2)
The poster says, quite clearly, what he dislikes about perl;
While it's not a Doctoral Thesis, it does seem to me that the above qualifies, at least by Slashdot standards, as "substantiated reasoning".
Tom elides this substance and attacks an isolated statement - "Perl sucks" - to enter into a barrage of emotional attacks. Tom incidentally offends those who have a problem maintaining Perl code, suggesting the fault may lie with them, and goes on to suggest that those who know Visual Basic are "Weenies".
As far as I can see, Tom's post was pretty substance free. It's easy to assert that perl is without flaw when it comes to the often heard complaints about maintenance, it's more difficult to make substantive points showing where the common pitfalls of perl that might bite a would be maintainer are not really much of a problem.
I'm sure Tom wouldn't make the claim that maintenance of programs is just as easy in all computer programming languages and thus any such complaints are the fault of the maintainer or the author.
I happen to believe that Perl does lack attributes of a programming language that lends itself to high maintainability. I think this is probably a design tradeoff. Perl is not Ada, it's not Visual Basic and thankfully, it's not Cobol.
-Jordan Henderson
Re:Perl Rawks (Score:2)
I recently deployed a 70 channel temperature acquisition system written in Perl running on Linux in conjuction with Apache. This system was deployed at 500 ft of depth for over 3 months and was not physically accessible during this time. A BSOD would have cost 30k to access. Perl was a joy to work with and the project was developed in the space of 2 weeks.
Re:Legos kiddies and professional architects (Score:2)
Encouraged to learn a different language, that is, before they develop the bad habits of a lifetime.
By the way, it kind of looks silly when you get all sanctimonious about people who rip on Perl, and then give us an ALL CAPS yell about "Visual Basic Weenies!" (at the same time, demonstrating a mean touch with the HTML bold tag). What is this, a schoolyard bullying chain -- the C jocks beat on the Perl geeks who beat on the VB handicapped kids?
Visual Basic is another language which is dead easy for non-programmers to write horrendous code in -- why the hell should these hypothetical people who care enough to write a program, but not enough to learn how need to hack Perl before they get respect from you? Like it or not (and I don't), Microsoft ASP is showing up in a lot of places where you'd expect
People will always use the tools they can use to get the job done. And, hopefully, there will be gifted people like Larry Wall who care enough about them to help. But you needn't convince yourself that you're ever going to see Donald Knuth handing out one of his famous cheques for a really snappily written Perl script. If you care about that sort of thing.
jsm
Re:Perl - a new mainstay in the world of unix (Score:2)
I learned it, I like it. But I totally agree with Yoda (quoting funkster@midwinter.com):
EXTERIOR: DAGOBAH -- DAY
YODA: LUKE: YODA: LUKE: YODA:Perl and proof of the Open source model (Score:2)
Perl Rawks (Score:3)
This isn't CGI-scripting, this is applications development, stuff my peers do in C, C++, Smalltalk, or Java.
We work an order of magnitude or two faster than these other groups, just because Perl is so easy to pick up and work in - and because professionally written Perl is so easy to maintain.
Not to mention that every single deployed Perl application has it's source code _right there_. It is impossible to lose Perl source.
I would not be suprised to see Perl completely replace Java in the next few years, especially if Sun keeps acting the way they are.
Go Perl!
Re:Legos kiddies and professional architects (Score:3)
Please endeavour to express whatever sentiments lie behind that outburst using substantiating reasoning rather than emotive expletives. [...]Perl is not a rebellion against `good design'. In many senses, it is an expression of the same, where good design means something organic and adaptive, something tuned more to the wait people think than to the way computers operate.
Ok: I think Perl is a badly designed language that makes programming in it harder than it should be. Here's why.
First, the type system, or more precisely, the lack of one. Values are not type-safe, in the sense that they can change meaning based on the context they show up in (eg, strings and numbers).
Please note that I'm not talking about dynamic versus strong typing: I'm talking about the types of values. Common Lisp and Smalltalk are both dynamically typed, but a value in either language always has a well-defined type. When you want to change the type of a value you do it explicitly.
An example of how this problem complicated the design of Perl is the need for two sets of operators to distinguish whether you are treating a scalar as a string or a number. In a language with well-defined types, it's trivial to overload operators so they do the right thing polymorphically -- look at Cecil's generic function mechanism for an example of how this works.
Dynamic scoping. I'm aware of the existence of 'my', but having two different scoping mechanisms (one of which just shouldn't be used but is nonetheless the default) is an undeniable crock.
Argument list flattening. Again, there are ways around this, but they require fairly sophisticated understanding of the language. To add insult to injury, there's no simple way of naming the parameters of a function. Even Scheme has this -- and it's the sort of language that gives you sand and a fire if you want a wineglass!
The syntax. One of the persistent-but-wrong claims about Perl is that having lots of syntax is an indication of how the Perl culture values having more than one way to do things. In fact, much of Perl's syntax is just pointless complexity. Syntax is helpful when it distinguishes different semantic domains; it is a bad thing when dissimilar ideas are conflated or when there are similar ideas with wildly different spellings. (For example, see how Haskell and ML use syntax to distinguish type specifications from function definitions.)
For example, why is 'eval' used to denote exception handling? Why are references to aggregates prefixed with a '$'? How come packages and classes are defined with the same syntax? There are answers to all of these, but those answers are historical rather than meaningful. Cars used to have reins in the early 20th century, but no one would argue that they belong on a car for the 21st.
In order to properly support having an sophisticated syntax, the right thing to do is to have a facility for syntactic extension like Lisp macros. These can be extended to infix languages, btw -- see Dylan for an example of how.
One last bit: don't denigrate the accidental programmers who've had Perl thrust upon them, or who have turned to it from a starting point of zero knowledge. They're doing the best that they can, given the circumstances, and should be encouraged, not squelched.
I agree with this 100%, and am quoting it just so it will be repeated. The fact that Perl encouraged people to start automating grunt work means that it is a great benefit to humanity, no matter how imperfect it is from a CS standpoint. (The same could be said of Basic, for that matter.)
Larry Wall is a treasure (Score:3)
And then there is a tiny group of people, who could probably be counted with your fingers and toes, who just have that certain "it" that lets them understand their work, the needs it fills, and the larger context into which it all fits.
Larry Wall is close to the top of that list. Unlike most, he understands that what he produces means something in relation to the rest of the world and the community. Perl is the kind of tool that could only come from a mind like Larry's - and there aren't enough of those minds to go around.
Thanks for Perl, Larry - my sysadmins thank you too. Please - look both ways before you cross the street, and every other precaution we can think of. We can't afford to lose you...
- -Josh Turiel
I just LOVE this quote: (Score:3)
It's free-based Wall.
I nominate the above quote as the new open-source motto. Ha!
Re:Crazy guy, crazy language (Score:3)
It's much eaiser to do C-like things in a bug free manner in perl. Add to this that perl is a "scripting" tool, as opposed to a compiler (yes, the language is "compiled," but not in the same sense as with a true compiler) so you don't have (well, mostly don't have) the make complexities; editing code is also building code, so rapid toolmaking is facilitated.
Sure bad perl is hard to debug, but nowhere nearly as hard as debugging bad C.
There are "purer" languages that are very well designed. Java is certainly easier to write bug free programs in than any other language I personally use, but it isn't all that well suited to the kinds of applications I use perl for: what I lovingly call "suck and puke" applications.
I know that people use perl for end-user applications, but with the exception perhaps of CGI, I wouldn't ever do that.
I also would use Java to write a filter.
I get kind of tired of the search for the "one true language" or the "one true tool," or even "the one true design method."
A rich palette of tools, designs, and methodologies of managable complexity gives you the greatest ability to confront any situation.
Interesting statement[s] (Score:3)
"In particular, we really needed to have a commercially packaged version of Perl for the Windows folks, because many of them were (and still are) clueless about open source. It's almost like we're doing Windows users a favor by charging them money for something they could get for free, because they get confused otherwise."
This is a common misperception among Windows users; that you get what you pay for. Having to shell out some cash makes us think we're actually getting a better deal somehow. Go take a $40 tie from the Daytons place and put it in a Target for buy it. Not a bulletproof metaphor, I know, but illustrative nonetheless.$4.59: somehow people will be far less likely to
Speaking of bulletproof metaphors, I like Larry's comments about the Cathedral and the Bazaar. The Linux kernel is far more like a Cathedral built in full public view by a small crowd of highly skilled volunteers than a bazaar full of dirty tents and shouting people. Perhaps the users in the Linux community at large act as though they are in a bazaar, but the metaphor just doesn't fit, and LW points this out well.
Re: It doesnt have to be this way (Score:3)
Of course, there's an even briefer version of that pattern: the -n or -p command-line option, as seen in filter programs such as this one:
Life is too short, and too prone to error, to write all that out in longhand each and every time I care to employ that pattern.Articles vs Comments (Score:3)
That's really quite a shame, because the article is rather a good bit better than the comments are.
Re:Crazy guy, crazy language (Score:3)
Perl has a finite syntax, one that's infinitely easier (no, that's not hyperbole; it's true) than any natural language. The excuse that there are thinks you will not have time to learn in a ten-minute perusal of the language is no excuse whatsoever.
You'll have to work much harder than you have to justify your position.
Re:Legos kiddies and professional architects (Score:3)
Perl and Y2K (Score:3)
The solution?
printf("The year is %d\n", 1900 + localtime() -> year);
Thats fine by me, I don't have a problem doing that. I just get pissed off at how arrogantly all the literature on this subject treats the topic. "There is no Y2K problem in perl, you just suck"
Okay.. riigghht. That wasn't a coder problem.
"We are just using an entirely new way to represent the date that isn't more human readable, or more machine friendly, that just happens to look exactly like the standard 2 digit year format until the year 2000 occurs, at which point it still works exactly as planned."
Can you spell denial?
I dont mind putting in workarounds, *shrug* big deal. I just get a bit indignant when my intelligence is insulted this way.
http://language.perl.com/news/y2k.html
Were you correctly insulted? (Score:4)
The localtime() documentation has been part of Perl for years. You will find it repeated in books, Perl's Y2K statement, etc. If you read the documentation rather than use the "try and guess" approach you would have known what that function returned.
As the saying goes, Assume means "Make an Ass of U and Me."
And so, after not reading Perl's documentation, not reading Y2K statements, not testing your own code (despite hearing "Y2K" being chanted for months), you do not think that the existing problem was your fault?
Furthermore if you read the documentation, those Y2K statements, etc, you will find out that the decision was made not in the design of Perl, but in the design of C. Perl chose to imitate what C did a good 10 years ago, and C chose the format for that struct over 20 years ago. Personally I think that a 4 digit year would have made more sense than year-1900. But year-1900 makes a lot more sense than a 2 digit year! (Do you like coding in windowing logic to guess the century? Me neither!)
Oh, and a pointed question. Those scripts that began returning 19100? How many of them would have returned 1900 if the year was returned as a 2 digit year like you asked? Oh really? And you have cause to complain???
Sincerely,
Ben Tilly
PS Your proposed "solution" is not even correct Perl code. I leave conclusions as to your competence to the reader.
Re:Crazy guy, crazy language (Score:4)
Re:Legos kiddies and professional architects (Score:4)
y programmer to do y programming. That's your mantra? But it doesn't really make sense. Hire a good programmer is really what you want, don't you think? A good x programmer, will learn and create better y code than a bad y programmer.
The question really becomes, what languages are good programmers most likely to _want_ to program in?
Re:Legos kiddies and professional architects (Score:4)
I really do wish, however, that someone else would please write some lengthy and detailed perl apologia sometimes. Truly I do.
The first point is with respect to small changes in punctuation (not "control characters") making a large difference in semantics. This is, of course, completely true, and I saw no reason to dispute it. However, it is likewise also true in nearly every language that comes to mind, whether programming or natural.Consider the tremendous difference in choosing single or double quotes in a C string. Notice how quote choice makes a big difference in shell programming as well, and even more importantly, how this is not the same difference as C manifested! Notice how in C the presence or absence of an asterisk or an ampersand completely changes what happens, just as in Perl the presence of absence of a dollar sign or backslash (to choose corresponding construct) can have tremendous impact. Notice, too, how in C a spurious semicolon can completely change your world.
And of course, positioning of that ++ matters a lot, too.I could cite plenty of examples in English, too, such as:
- I dedicate this book to my parents, Mother Theresa and God.
- I dedicate this book to my parents, Mother Theresa, and God.
The place where Perl is particularly heavy on symbolic notation is in regular expressions. Modulo Icon, I don't know of any language or system currently in use that affords so much power. Regular expressions (ok, I know they're not truly regular by the proper language-theory definition) are an extremely compact but user-friendly interface to various sorts of FAs. Yes, of course interchanging, omitting, or deleting one single character completely changes the meaning, because each symbol carries a large amount of semantic content. This is equally true of any other language that uses regular expressions, whether it be from libc or in any other programming language. Consider how differently a circumflex can be interpreted in a call to regcomp(3) depending on whether it is the first thing in the string or not, as well as whether it's the first thing after the opening square bracket of a character class. It's subtle. You do have to be careful. Such is the nature of the beast. Then again, I haven't seen a Calculus book that eschewed symbolic notation, either, and I'm not certainly I'd care to.Let's consider the "do what I mean" effect. If you'd like another quote of mine on this matter which is also somewhat mixed in its connotation, then consider: " `Do what I mean' is really just `do what Larry means', and if you and Larry don't mean the same thing, then you may be in trouble." :-)
I guess the bottom line here is Perl's context-dependent behaviours. I have mixed feelings about this whole issue, and could probably work up a fairly substantial jeremiad in either direction. I'm talking about the fact that things like these two:
The first, being in "list context" by merit of being on the RHS of an array assignment, actually ends up being It seems pretty obvious that it's more fun to write it without that ugly split. A reasonable alternate approach would be the creation of two separately named functions to do this job. But that's not what happened.Of course, it's not as though C were free of issues of context dependence. Consider how the comma operator acts in "list context", such as when you construct an actual or formal parameter list to a function or when you create an aggregate data initialization, compared with the normal, "scalar context" comma operator. Or consider how sometimes c[] and *c are equivalent (parameter declarations), and how sometimes they are not (extern declarations). And for a real fun time, just try to explain to a neophyte why argv[0][0] is doing run-time pointer arithmetic (assuming the conventional declaration), but that data[i][j] would not be given a declaration like char data[MAX_X][MAX_Y] to create a proper two-dimensional array.
C has plenty of other "do what I mean" issues. For example:
- Letting multiplication bind more tightly than addition -- a secret, implicit rule
- Permitting but not requiring a trailing comma on aggregate data declarations
- Allowing int to be omitted in declarations involving extern, static, auto, unsigned, and volatile.
- Defaulting functions to have a return type of int.
- Assuming that for(;;) should mean while(1).
- Sign extension on some architectures.
- Freely coercing integral types
I imagine there are more of those, too, that I could come up with if I had. In fact, I'm quite sure that I could list a bunch of "do what I mean" issues for Python if necessary. Certainly the significance of whitespace and indentation is one glaring case. Another is the default nature of many libraries to raise an exception upon error, rather than returning an error status, even when that exception is, as K&P put it in Java's case, far from exceptional.So I didn't address these issues because I felt that they were largely true, but not particularly relevant. All symbolic encoding systems are subject to semantic shifts due to small changes in symbols. And many of them attempt to "do what you mean". Does Perl share these properties? Of course it does.
Finally, Jordan, you've stated that you feel that Perl lacks attributes of a programming language that lends itself to high maintainability. I don't know whether this is fair or not, because I do not know what your metric is. If you're looking for me to play the devil's advocate, I could point out things like
- minimal static analysis
- extremely late binding
- libertine autoextension of memory
- free, dynamic conversion between intrinsic types
- default mode is for fast-and-loose programming, not careful architecture with elaborate pre-declarations
However, our advocate's adversary would be quick to illustrate how easily these can be construed to be not bugs but features given the appropriate target environment. In this respect, you've probably hit the nail on the head when you mentioned trade-offs.But you haven't enumerated your criteria, so it's hard to judge what you're thinking.
Anyone can write bad code in any language (Score:4)
The problem with many languages such as LISP is that it's so _difficult_ to write good code! Perl is such a gem because it tries very hard to make your life easy. Of course, some people still do things the wrong way. It's not an issue of the language. It's a problem with the programmer.
Although I do admit that Python is an equally good language.
-Ted
Possible /. interview? (Score:5)
Legos kiddies and professional architects (Score:5)
Perl is not a rebellion against `good design'. In many senses, it is an expression of the same, where good design means something organic and adaptive, something tuned more to the wait people think than to the way computers operate. It is a kind of design which has proven itself time and again over the last several thousand -- if not in fact, billion -- years.
As for the common refrain, "I can't maintain other people's code!", this is just another bit of popular Perl FUD. Eschew such nonsense. The underlying inability may reflect on you. It may reflect on them. But it does not reflect on Perl.
What you hate is when the code to be maintained was written by an unskilled laborer, someone who doesn't understand the tenets of software design. It would be hell maintaining that code no matter what language it was written in. Another scenario for hating life is when the original coder was competent, but the person doing the maintenance is completely clueless. Here my plea:
You don't hire them for maintenance of C++ libraries, so stop hiring script kiddies (I mean nonprogrammers who can only cut and paste others' scripts) to maintain Perl. This is your fault for hiring the wrong people for the job.
I've had the pleasurable experience of maintaining a great deal of Perl code that was designed and implemented by competent, professional programmers. You cannot compare the work of the Legos kiddie with that of the professional architect. It's insulting to all three parties.
One last bit: don't denigrate the accidental programmers who've had Perl thrust upon them, or who have turned to it from a starting point of zero knowledge. They're doing the best that they can, given the circumstances, and should be encouraged, not squelched. Most programming is performed folks not trained in formal software engineering. You should compliment them for how much they were able to accomplish, not diss them for not knowing the precepts and subtleties of good design. Perl succeeds because it is available not just for professionals, but for casual programmers as well.
Re:Perl and Y2K (Score:5)
It's clearly documented. Always has been. You were just guessing how localtime(3) behaved instead of looking it up and reading the precise behaviour. A library API is a contract. If you sign up to using that library without reading the fine print, then you cannot complain when that fine print bites you in the ass. Stop guessing, and read!
You are incorrect in your assumption that this is somehow peculiar to Perl. Whether it's peculiar in general is another question entirely. :-) I wrote about this in a letter to Dan Gillmor [mercurycenter.com]. Essentially, you need to understand a struct tm [openbsd.org]. Apparently the situation is even worse in Java Script, where it appears that different implementations behave differently.
If you're on the cutting edge of Perl technology, please pay special attention to the new -DPERL_Y2KWARN configuration option. It produces an effect like this:
Interesting, eh? Another option is to use the D'oh::Year module [perl.com] by Michael Schwern. The author wrote about it here in Dej a News [deja.com]. Anyway, here's the README.Y2K file from the 5.005__63 release of Perl: We've known about this in C for about twenty years or so. So, let's not pretend you haven't been notified, ok?