Slashdot Mirror
The Secret History of Perl
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.
VB weanies are so sensitive to being weaned from their VB! :-)
To be quite honest, it boggles the mind to imagine that anyone would use any function without reading up on how it worked! That's just not the way you program.
Here's a cluepon: You are offtopic. You deserve to be moderated down. Stop wanking off about Python is the best lube and how Perl killed your puppy and made you cry. We don't care. It's irrelevant to this article. See a shrink.
How come you don't have the balls to sign your name to that short message?
The GPL doesn't force anyone to give away their changes unless they are distributing binaries. Unless Company A is trying to sell or give away their modified Perl without source, there's no problem. They can use it in-house all they want.
But their zealotry has convinced me never to even try to learn python
oooohhhh. that'll show them to mess with you.
What a little faggot you are.
Actually, the person who needs to be sacked is the project manager who commits the project to a language that results in the hiring manager being forced to hire more expensive, less-easy-to-locate/replace perl gurus to develop and maintain (long term, mind you) the project's code.
Silly? Maybe, but I thought he was funny.
competent perl programmer != perl guru
I don't want to keep my job because my employer is "locked" into a language I happen to be familiar with, I want to keep it because I am a good programmer!
There you go again, picking on both Perl and Visual Basic in a single comment. Stop that now! It would be unfair if Microsoft were the only enterprise able to lock users into their product base. Perl should be able to do so as well.
[Snip much stuff by Tom about Pascal, compile-time type checking, design-by-contract, and other things I explicitly stated I wasn't talking about.]
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. :-)
Tom, I think you are acting intentionally dense and I find it irritating. Smart people should act smart, since there's a shortage of that in the world.
The problem is precisely that Perl's deliberate obfuscation of the distinction between numbers and strings makes it harder to do polymorphic overloading, because strings and numbers /aren't/ the same thing and the coercions that Perl automatically invokes are not always the ones you want to use.
For example, suppose you need to serialize values to send it to some other application, and that this serialization format is not plain text, and has different conventions for strings and numbers.
What you want to be able to do is write some generic function serialize(object) that has a different method body for each different type that it receives. The problem is that in Perl there isn't any simple way to tell if the value you just received is the integer 123 or the string "123"; this makes it impossible to cleanly dispatch on the type of the argument.
Obviously this is possible for Perl itself, or the '++' operator couldn't do what it does, but I don't know of a way for a plain Perl program to tell.
Bolted-on Object Oriented accessories are a sign of Object envy. It's a malady that infects those who wish they had OO tools, but since they can't have them (with the accompanying enforcement of good program structure) they bolt on little chrome placed wingie things to what they do have so they can pretend.
- At least 100x as many people use Perl as who use Python
- Perl is used by some three million CGI script kiddies
- Perl code runs zillions of internet websites, including Slashdot itself
- and because Perl is for many many reasons much more associated with Unix than Python is, and Slashdot really is, when all is said and done, a Unix geek site, even if you tend to spell Unix with a leading "L".
:-)
As to why every mention of Perl tends to draw out all the scandalously flaming pythonexuals and their attendant cadre of perl bashers, that part I really can't rightly tell you, but one notable observation is that the opposite situation (flaming perlers bashing on python each time the latter should have the temerity show its face in public) does not occur. If I must guess, I think perhaps it's the standard oppressed minority syndrome.Think about how the losers in any conflict carry their loss forever, but the winners forget all about it. Consider the American Civil War. In the South of the United States of America, residents have a special word for those from the other side: Yankee, typically enunciated with a sneer and prefaced with various pejoratives. By way contrast, notice how in the North, no corresponding term, full of bile and revenge and spite and anger and denigration (do be careful with that last one :-), happens to exists.
But just as everyone should spend time in another's culture, including the North and South, or Anglophonia versus la francophonie or what have you, all Perl and Python programmers should spend they own wanderjahr in one another's lands.
`Enforcement of good program structure'? I've never heard of successfully legislating away wrong thoughts. Not even the Nazis managed that.
Or, you could ask Roblimo for that interview, since he's the one that actually sets these things up...
What a stupid thing to say. You never learn, do you?
Let me guess. You make Kias.
"Mu," replied the sage, enigmatically. "Until you learn to unask your question, true enlightenment will always be beyond your grasp."
"But master!" came the retort. "That cannot be. I know that these are different."
"Yes, my child. That is your problem." The master closed his eyes and returned to sleep.
How many times does it need to be pointed out to you that this problem is independent of the language???
please note that I have answered this point several times in this thread already
No, you've offered the same lame excuse a number of times.
In fact, I recall that my first impression when I ran the script was, Gee this has got to be the easiest language to write ever! I was genuinely shocked at how easy it was to create a functioning program, on the fly (as i learned) with no prior experience. Praise Perl (and good on Larry!)
One note, is that I had access to the camel book the first night (didnt use it second night).
tonight: bash scripting!
* a BLOCK statement was failing to exit because I forgot to account for the random selection of words with more than 5 syllables (a possibility on line 2, which has 7 syllables), of which I had not provided any. So I moved my syllable-counting code outside the BLOCK, and it worked! The very fact that I was able to find this marginally hidden bug struck me as evidence of how well perl is constructed; I guess all that linguistics pays off. I have some experience with basic C++, I am an able coder but by nooo means a guru. Perl kicks azz!
The totally gutless, and completely anonymous, Coward
random haiku script/it was so easy to write/thank you Larry Wall
curious... I understand why it is a great example of a successful free software project, but why is it a successful demonstration of open source?
It seems that larry wall and people (of his choice) have done all of the development. The only thing I can think of is that it has been ported to so many platforms.
Let's have that fight some other time, okay?
(i.e. just about any time the GPL is mentioned)
What do I care what Tommy O'Toole in Timbuktu uses as a naming convention?
Come on, guys. He made a mistake. Saying he hard-coded "19" into is implausible.
... one of the previews went a little screwy
@mydate = localtime(time);
$twodigityear = $mydate[5]; # Wrong, of course
$century = ( $twodigityear
If you think that $twodigityear REALLY is a two-
digit year, this might be expected to produce
something like 2000. But it doesn't; the 100
values produces 19 as a prefix.
P.S. Sorry if this posted twice
Metaphores bleed? Oh, wait--OK, I get it. ha-ha
I don't mean this as a braggart, but I found nothing difficult about learning Perl. I mean come on, when compared to learning about pointer arithmetic in C++, its a cake walk. The only two points I believe a newbie must be a little more patient is dealing with hashes (basically keyed records), and regular expressions. However, most of the usage of regular expressions within Perl is not Perl specific, but specific to the definition of regular expressions. And how much easier could string manipulation be than in Perl???
That's why we call it *code*... perl had the foresight to include the # character as a comment marker... It's not Perl's fault if the scripts yer maintaining don't make use of it ;)
PS I'm sure that you, sir, are much more experienced than I, being only a lowly undergrad, but c'mon, man! Code is for compilers/interpreters, comments are for people! Even decently schooled undergrads know that! %^]
PPS I wrote my first perl script 2 days ago and it's gotta be the neatest language I've ever seen. You're right, I've never maintained a script in Perl. I hope that when I do, I am lucky enough to recieve comments with the code. You're right though, a screen full of pure perl can be reeeally scary to look at. Maybe we should start teaching Perl in 1st grade? Then our descendants could read it directly as we do novels today.
No one who doesn't understand slices merits being called an "experienced perl programmer".
patch is way more important than PERL. Its just that PERL is more neato, so it gets more press. Patch made Linux what it is today.
If you think that Java has `caught on' with the casual programmers of BASIC and sh scripts who so often turn to Perl, then you're lying to yourself before you even spout your vitriol at the world.
PERL is quite useful, and can be fun to write. But it should NEVER be someone's first programming language. Learned habits are learned early, and god knows what a self-taught PERL-only programmer will come up with.
Bondage and Disciple languages have their place. I suggest everyone start with one, even if its only so they appreciate a language that gets the fuck outta their way.
"Staffed a large commercial software project since 1995". So the fuck what?
You're offtopic. This has nothing to do with the article.
Its not that cloistered over there in perltown - Larry is neither the chief maintainer for perl5 or the chief developer of perl6. Thankfully, those people have an excellent role model...
I program in Perl because it's fun.
And that's what counts.
You're just as bad as the Python flamers.
Just prove rigorously that he doesn't exist and be done with it.
hahahahaha. thank you for showing what a fucknut Tom really is. I knew he was a dumb bitch.
Then learn it and shutup.
A crappy programmer is crappy in any language. Even Java will slap you down if you don't know some of the intracacies of how the language works. There's no free ride in programming...you're going to have to earn your million.
However, if you have ever tried to maintain a perl program
Yawn...maintaining crappy code in any language is a hassle. Once again, its hard to read any language you don't know how to use. Even Java won't solve this problem for you.
Perl's design is not just a rebellion against established thinking, it is a rebellion against good software design and it shows
Most perl coders aren't trying to write large applications with the language. Obviously it isn't well suited for writing 100k LOC programs - neither is Python (both are too slow at this size), so programming in the large is irrelevant. Its about getting things done. Until you really need to get something done in a short amount of time, you'll probably have no use for, or ever understand the motivation for perl.
With it, you can do normal shell-like operations, but load in perl packages, and do perlish stuff right there on the command line.
I'm excited by this and I really hope it one day kills off sh,csh, etc, all of which are showing their age and are really, really painful to program in.
The notion of simply combining the most powerful scripting language with interactive shell operations is just to powerful to ignore.
This is a command line program, but GUI-ing it or web-ifying it is trivial.
The mission: Given a name, search an LDAP directory for matches, and return phone numbers and e-mail addresses:
#!/usr/bin/perl
use Mozilla::LDAP::Conn;
die "No connection\n" unless
($conn = Mozilla::LDAP::Conn->new('my_server));
@attrs = ('cn', 'mail, 'telephonenumber');
$entry = $conn->search('my_searchbase', 'sub', "cn=$ARGV[0]", \@attrs);
die "No match\n" unless ($entry);
$entry->printLDIF();
while ($conn->nextEntry()) {
print "\n-----------\n";
$entry->printLDIF;
}
$conn->close();
See? Simple, easy to understand, and easy to debug - and done from memory off the top of my head.
Try THAT in C, C++, or (shudder) Java.
And as for Python - syntactically signifigant whitespace? Ewwwww!
Good show (XML/perl issues) :-)
Python is a mental constrictor.
The one exception is API changes. In a statically typed language like Java, if you change an interface you can recompile everything else and use compiler errors to find out what the dependencies are. In PERL, you have to try to run it through full coverage and see what breaks at runtime, which can be a major headache.
Note that this is a static typing issue, not a specifically PERL issue.
-Bram
(Anonymous Coward #23408972134)
Link: 10&article=uncultured">http://www.linux-mag.com/cg i-bin/printer.pl?issue=1999-10&article=u ncultured
The printer friendly version has the whole article on one page, rather than balkanizing the thing into five sections. (Why do websites do that? Chance to show more ads to readers?)
Right - because if you aren't using perl, you'll still be developing the project. I imagine the code will be even more fresh in your mind if you're using a totally handicapped-approved language like Java, which is even more verbose.
I'm not picking on Python - its a great language, and most perl folks would do well to learn it and use it where applicable.
How can this be off-topic in a story posted by someone calling themselves "Tim Toady" ?
Tom's right. I'm really sick and tired of the python people shitting all over perl. Maybe they were shit on by script kiddies as children. I don't know. But their zealotry has convinced me never to even try to learn python. They should take they flames elsewhere. Everytime perl comes up, they spray us with flamewars. Screw it. That guy is being offtopic, flamebaiting, and trollish. It's not related to the main article. It's just religious fervour. Screw him.
WHAT LANGUAGE DOESN'T???
Programming is hard work. Language syntax is the least of it. If you can't handle some minor issues of learning the syntax of a language, you should have very low expectations for your performance as a programmer.
I know this is starting to sound like a flame, but your general argument that its all so confusing is simply starting to sound like the type of bitching I hear from people who haven't read Programming Perl or made a real effort to learn Perl in some meaningful way.
Take a language like Java - most people think it helps bad programmers become mediocore programmers, but since bad programmers never bother learning about heap vs. stack, object churn, object reuse, and serialization, they'll never be much use to anyone as Java programmers in any case.
No one anywhere needs crappy coders. Dicussing their plight is a waste of time.
Argue with his ideas, but insult him ad hominem for reasons of greed and you become slimier than anything you could thrown on someone else.
We listen to what Tom says about Perl because of his experience. Should we just get idiots in here who've never written any Perl? Does writing a book mean you're suddenly not an expert? Should we stop listening to Rich Stevens and Dennis Ritchie and Larry Wall for the same reason?
What a horrible thought!
That these people have written books makes them more credible, not less so. Shame on you!
On that question, what about knowing every little semantics of the two dozen C libraries used to write Enlightenment? That's far harder than learning what angle brackets do it Perl.
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?
;)
*laugh* moderate this guy up!
Come on Tom, you can make better arguments then that
Also, if some of your dates are showing as 19100, then I'm assuming you are doing the following:
printf("The year is 19%d\n", localtime() -> year);
Now how the hell is Perl, or any language for that matter, supposed to make your code Y2K compliant when you have hardcoded a 19 in there? Hardcoding a 19 should have been your first clue that your code wasn't Y2K compliant. Yes, your code, not perl. Also, I suggest you read the Perl Y2K statement again, as it clearly says that it is possible to make your perl programs non-Y2K compliant if you really want to, which is just what you did.
No, just you. Everyone else is learning how to use their tools properly instead of bitching about them.
I have never seen Tom lie, or even twist the truth
LOL, this sounds like HAL -
"Tom has never made a mistake, or distorted information"
How come you don't have the balls to sign your name to that long message?
Python equivalent to your first version is
The equivalent of your second version is
While yours is the cleanest perl I have seen in a long time, it should be obvious that python eins on readability.
No one wants you to take it from Reimann Sums, just justify what you mean about "too much flexibility". Its pretty simple - what flexibility is bad?
I don't think there are many people, even among skilled Perl coders, who could claim to know all of the neat tricks available.
The same can be said for any language. C++ is full of bugbears that most programmers aren't aware of, nor need to be aware of. You're propping up all your own programming inadequacies on the notion that perl's syntax is somehow too difficult to comprehend. What you've really demonstrated is that you are unwilling or unable to grasp the tools that millions of other programmers (who have "done their homework") have few problems wielding usefully.
There is no language that gives you something for nothing.
Please take your offtopic, trolling, flamebait Python zealotry out of here, Ian. We're tired of listening to you. Didn't you do enough damage already back in USENET? Please stop polluting slashdot with your crud. When there's a Python thread, fine, but please stop your irrational proselytizing every time Perl is mentioned. It's a good reason to keep people away from Python.
If Tom has a monthly cron job that personally sends you or anyone spam mail, then that's pretty wicked. Is it true? Still, it's certainly slow. :-)
Ian, my lad. This isn't the "WHY WE HATE TOM CHRISTIANSON" thread. That's down the hall three doors on your left. See ya!
You have a strange definition of "harder". Most people who like Perl seem to find it easier than it should be. :-)
It's not possible to make programming too easy, because each thing you make easy opens up a new class of problems that used to be impossible and now are just hard. IME Perl makes me work harder to create a less general solution than something like Lisp or Smalltalk does. I'll cheerfully admit that if you are used to C or Java then Perl is a revelation -- but not all of us grew up on crippleware. :)
So? By and large that's an undesirable feature. Any language that forces the programmer to overload the commonly used operators forces the reader of the program to disambiguate those overloaded operators.
You feel Perl would be improved if it had separate operators to add floating point numbers and integers, like assembly languages do, and that removing ties from Perl would make it a better language? No? I didn't think so. What's good for the language designer is good for the hacker, IMO.
To make the mechanism fully general and programmer-extensible requires type-safety. Perl doesn't have that, and I count it a flaw. The fact that most other languages lack it makes them flawed, too.
You seem to assume that Perl is the way it is out of ignorance of the typical tenets of computer science. That's not generally true in the ways you seem to think it's true.
Not out of ignorance or from lack of intelligence; most of the people on the Perl mailing list seem pretty sharp, technically speaking. What's wrong with Perl is just a consequence of the fact that greedy optimization doesn't lead to good designs for computer languages. Each misfeature in Perl was 'fixed' with a minimal-change hack, and the misfeatures created by the hack were fixed by a new hack, and so on until we have the modern Perl, an elephantine and exception-ridden kludge. It's the RPG of the Unix world. (RPG because C++ is the PL/I of the Unix world.)
From all these folks pissed off by Tom's use of the term "visual basic weanies," you get the feeling that there are a whole lot of them around to feel sleighted. :-)
STOP HIRING VISUAL BASIC WEENIES TO MAINTAIN PERL CODE!
Also, stop hiring Java weenies, C++ weenies, Graphic Artist weenies (I'm not really a programmer, I'm a creative-type - ugh), and, dare I say it, Perl weenies.
I take some offense at your characterization of Visual Basic programmers. I write Client/Server database software in a business (read: Wintel) environment. I have no qualms about VB being the best tool for the job. I actually enjoy it much of the time - and the IDE rocks. Just as I find Perl to be the best tool for automating NT Server administration tasks, and generally for creating tools for myself.
I am NOT a Visual Basic weenie, on the other hand, and can't stand having to maintain (read: rewrite) code that has been written by weenies.
VB code suffers from the same plague that affects Perl code, and code in any other language. We have a shortage of qualified programmers in the world, largely because of
1) The stereotype that programmers are boring, geeky, unpleasant people to be;
2) The complete lack of Software Engineering programs at Universities; and
3) The inability of management to distinguish between qualified programmers and unqualified programmers, and/or unwillingness to train the latter into the former -- or at least buy them a copy of "Code Complete".
That having been said: Tom, thank you for your book "Learning Perl on Win32 Systems". It was a great help to me when I started learning Perl (now if I could only find a magic book that will help me finish learning Perl).
Chris
>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. --LW
And it's so true! Most Windows users really do think you get what you pay for. I know, I used to think like that.
And the notion, however misguided, is not without supporting evidence. Much of the free software available for Windows really is worth what you pay for it, if not less. I'm talking about shareware and freeware - the closed-source variety. Sheesh, what a crock. Why would anyone release software for free but hoard the source? The result is software that is only as good as the original author needed, no better. Which is almost guaranteed to be worth zilch to most everyone else because there is no means to improve it outside of offering the author money.
Just had to get that off my chest
Ian, give it a break. Apparently Perl hurt you. Please stop taking your personal problems out on others, whether Perl the language, this thread, or on tchrist. None of them deserve the abuse. Solve your own problems, by yourself, and get over it.
> The problem with many languages such as LISP is that it's so _difficult_ to write good code!
Lisp is a programmer amplifier. Bad programmers
will get worse - but good programmers will be
really productive writing beautiful code.
Hmm, let's see: -Perl is faster than Java for any text manipulating which encompasses the majority of business applications. -Perl has a huge module library. It actually delivers on the promise of reusable objects. -Perl provides true platform independence: it runs on nearly every known os. -Perl is used in many of the major sites such as Yahoo, IMDB, Deja, Amazon, Slashdot, etc. -Perl is easier to learn and truly open source. Your arguments for java were? Perl is not going to replace Java because it doesn't have to. They both have their strengths but in many areas Perl kicks Java's ass (especially in the web domain). It simply fulfills the promises that Sun spent big bucks on to promote but never delivered. That's why Perl is well-loved and will continue to thrive.
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.
A lot of cocky, hotshot programmers will wipe the Mountain Dew from their lips at 2:00am and try to tell you otherwise. But don't listen to them -- they're just rationalizing.
Anonymous Kev
Ian. GO AWAY. You are offtopic.
What about the Perl Cookbook, that I've read reviews of? Is it more of a reference or tutorial? Can you dispence with either of those other two if you get that one? Let's assume I want to save money.
make that: printe r-friendly version
Here are the RocketAware.com links to early versions of PERL (like versions 1 and 2) in the comp.sources.unix archives.
You have to be one of the silliest people I've seen in these forums. The fact that some people respect you comes as a shock to me. I guess geeks aren't immune to the unwarranted idolization that goes on in other facets of life. I put more weight in you the person than I do on your self-promoted technical ability. To paraphrase you, YOU ARE A WEENIE.
Hates people who have stupid little sigs
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.
While you're right in a way (this isn't the best story for Python advocacy), it's understandable (disclaimer: when I'm more alert, I guess I'd say I'm a Python advocate). The motivations are a lot like Linux advocacy done right: You know there are people using NT because it's the only thing they've heard of or because it's popular, not for technical reasons. You know some of these people would be better off running some UNIX. Not all, but some. Meanwhile you're sitting there with your Linux and you want to share. You point out the flaws in NT. Some switch over. Everyone's happy.
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...
$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.
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.
MAC | A polar bear is a cartesian bear after a coordinate transform.
let's keep things to a low roar (as my father would say)...
/ k.d / earth trickle / Monkeys vs. Robots Films /
Large print giveth, and the small print taketh away
--
--
$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.
--
--
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.
--
--
--
--
--
--
$@ && ($@ =~ s/\(eval \d+\) $$ (\d+)/0;
The problem is that it is much more difficult to find out what a particular syntax means unless you already have a vague idea (ie. ooh, that is a regular expression, go to the regexp chapter) but even then it can be difficult. You don't need to have any idea what "fgrep" does, or "System.out.println" if Java is your language, in order to look it up.
--
--
--
--
--
You only think that because in English there is no word for "The mental entity made up of the intersection of two individual minds.".
Zooko
Tom, it seems to me that you are excusing some of Perl's syntactic trickiness by comparing it favorably to things that are even more tricky, such as C, shell languages, Leibniz's calculus notation, regular expressions, English, etc. This seems unnecessary. Surely we can acknowledge Perl's weaknesses while still valuing the language, and the culture surrounding it, in its full context. Being aware of these problems will help everyone to use Perl more effectively and to learn from its mistakes.
I'd like to try to contrast Perl with Python in regards to "syntactic density". I haven't studied Perl and Python very deeply as languages, but I've hacked in each of them enough to have the following intuitive belief:
If you take two programs which accomplish the same fairly complex task, each written by a suitably proficient coder, one in Perl and one in Python, then there will be a lot more syntactically correct variants of the Perl program which differ from the original Perl program by a small syntactic change (which could easily be miswritten or misread), than there are syntactically correct variants of the Python program which differ from the original Python program by a comparably small syntactic change. Note that the metric that I am using to measure the "smallness" of a syntactic change is precisely the measure that we all care about: how easy it is to misread or miswrite.
If you imagine the programming language as a space with a point for each syntactially-correct program then I think Perl has a denser distribution of syntactically correct programs -- it is "syntactically dense". I hypothesize that Python is "syntactically sparse".
You gave lots of great examples of syntactically small and semantically large differences for English, C, Bourne shell, etc.. I can think of plenty of examples for Perl as well, but I can come up with only one in Python. Namely, that it is easy to miswrite (or more commonly to misedit)
for i in range(10):\n\tdoSomething()\r\tdoSomethingElse()when you meant
for i in range(10):\n\tdoSomething()\rdoSomethingElse()
. I would be curious if anyone can come up with any more.
(Your example of exception versus return value is, I think, semantic rather than syntactic, but as long as we're on the subject, I further hypothesize that the typical syntactic-variant Perl program will run normally although with different behavior, while a syntactic-variant Python program is more likely to stop with a diagnostic message. I gather by second-hand quotes originally from you, Tom, that this is actually a desideratum in Perl.)
I had become quite a Python bigot last year, and I was enthusiastic enough in my praise for Python's "lack of gotchas" compared to Perl that some friends of mine actually undertook the experiment of rewriting a few non-trivial Perl scripts of theirs in Python. The conclusion was quite a shocker for me: they went back to Perl. Since then I've been trying to develop a theory of why some intelligent, competent people like Perl and others don't. (Leaving aside the obvious bias of learning, and of translating, that favors the old language over the new one.)
I think it might have to do with how good you are at rigorous symbolic manipulation, as distinct from linguistic processing. I am a very good programmer, but I am really bad at syntax. Give me a couple of weeks away from C and I'll promptly forget whether its "int[] foo;" or "int foo[];". (In fact, now that I think about it, I have forgotten the answer to that one! No wait -- the former is Java, the latter is C. Java syntax is "fresh in my mind" right now.) When I wrote the Python examples above, I had to go look up the online docs at python.org just to double-check that I wasn't embarassing myself with incorrect punctuation.
Interestingly, I am also really bad at mathematical notation, but good at natural language. I've noticed that when I'm reading a book that has equations (which I do fairly often), the words flow easily past and reveal their meaning to me, but the equations are all opaque blobs that offer no information other than how much space they take up on the page. It requires a deliberate effort and a mental "shift of gears" to stop "reading" and start dissecting the equation.
Neither of these things worry me too much. I get by just fine at programming by relying on automated tools (like verbose compilers and interpreters, and syntax-highlighting and auto-indentation in an editor) and references (like the handy little Perl summary card). I get by okay at my mathematical hobbies by reasoning in words (out loud or with my internal voice) and by building spatial models and graphs (on paper/whiteboard or in my imagination).
Hm. I wonder if someone shouldn't do a controlled experiment to see if there is a high correlation between Perl-haters and symbolically-challenged folks such as myself. Could be a paper here. :-) It also ties in with the debate in linguistics and pegagogy about how much people read natural language by using the phonological part of the words and to how much they map straight from the written symbol to the meaning.
(By the way, even though I am good at English and at Python, I can't think of anything about natural language that I would like to see in a programming language: context sensitivity? ambiguity? syntactic density? No thanks to all of it!)
Regards,
Zooko
Dude, if you're too damned lazy to read the manual, don't blame perl for your errors.
perldoc -f localtime is plain on how perl counts years.
I'm sorry you assumed localtime behaved other than it does.
Perl went out of the way to PREVENT a Y2K issue. You abused the language. But, hell, we all make mistakes.
i looked at the pages you cited, and they seem to cite two main justifications of 'themself': famous writers have used the construction, and our language lacks a gender-neutral singular personal pronoun. neither of these suggests we should condone use forms of 'they' (which already has a position) for such a pronoun. i agree that we need one, and i agree that it has long been natural usage in casual conversation (which may well be the context in which most of those famous writers used it), but i would still like to see a new word, rather than muddling an old one. if you have any further links, though, that would be great! all language is beautiful.. ryan
i never said "there are few examples", i said "found examples aren't any settlement". good point about 'you' in english. and never in an eon would i endeavour or expect to have an invented word replace 'they'. i said i'd like to see it; but the momentum has been too strong the other way for that to happen. i'm sure i will continue to use 'they' in conversation and feel a bit awkward no matter what i use when writing. 8) by the way, i am no anonymouse here
I agree wholeheartedly. But I would suggest that Larry Wall's contributions to both Perl and the open source world depend at least as much on his writing of English as his writing of code. I'm a working scientist. I use Perl. I love Perl. I use Python, Java, C, Fortran, Scheme, Awk, shell, and others I can't recall. They are all great languages. (Well, Fortran is fast.) There Is More Than One Way To Do It and There Is More Than One Language To Do It In.
What sets Perl apart are the beautiful books by Larry Wall, Tom Christiansen, Randal Schwartz, etc., that set an early and very high standard for documentation of free software. Good writing depends on the same clear thinking that good coding requires, but individuals aren't always good at both. As demonstrated again in this article, Wall is.
I think the lasting lesson Wall has taught us is that while adequate documentation (e.g., the GNU Emacs manual) can serve the open source community itself well, documentation (and advocacy) that rises above mere adequacy can pave the way towards world domination.
Here's a scenerio:
Company A is worried about looking stupid on 1/1/00, because they're afraid their webpage will say the year is 19100. So they change the Perl source to not run any script that doesn't add 1900 to any variable that gets assigned the year. Company A put some pocket change towards this "fix"; they are unenlightened and insulted by the idea that they would give away their changes for free. If their lawyers told them they were legally forced to give away their changes, Company A would stop using Perl fairly quickly.
--
Why can't I moderate something "Wrong" or at least "Grossly Misinformed"?
Obfuscated maybe but CPAN gives perlpossibly the most reusable collection of code in use. This is one of the features that makes perl so enduring. Download a perl CPAN package, read some POD documentation and within mintues you can saving hours of work.
Perl is then maybe the most reused language on the planet.
If I had to pick only one Perl book to refer to for the rest of my life, it would be the Camel Book (Programming Perl).
- The Llama Book (Learning Perl) was marginally helpful for me because it has lots of dumb little exercises to introduce the reader to Perl's way of doing things. I had CS programming classes to draw on for concepts, though.
- The Ram Book (Perl Cookbook) has lots of solutions to typical programming problems with code snippets.
- The Camel Book is the Perl bible. My life would be a lot harder if I didn't have this thing to refer to when I forget how pack() works, for example.
You can get most of this info through perldoc -f function_name , but I like dead tree versions of documentation. Plus, there's all kinds of info on stuff like object design, IPC, socket programming, etc.In short, buy Programming Perl first, then see if you really need Learning Perl. I suspect that if you're really strapped for cash you can do well enough to find online tutorials and code examples to figure things out for yourself.
--
A host is a host from coast to coast...
A host is a host from coast to coast...
Unless it's down, or slow, or fails to POST!
Re: finding bugs in Perl... If you're not using -w and strict, you really should be. Even for quickie one-off scripts, take the time to program the script properly, using locally-scoped variables. It builds character, or something... I started off programming in C, but do systems administration now and use Perl all the time. Most of what I program still looks mostly like C (which earns me ridicule from the Perl-hacking webmonkeys here), but it works and is easily read and maintained by people other than myself. As far as weak typing in Perl goes, I think it's just a matter of shifting one's thinking. It's usually pretty obvious what the 'thingies' (scalars) are being used for if the programmer has taken the time to document and write unobfuscated code.
Which leads to the comment about software design... Again and again I see people complaining about how awful Perl is to read and maintain. When I see that, I have to think that either they're digging their heels in and don't want to learn something new (I was there), or else they've only really seen nightmare scripts written by people with less than a clue about good software design. As many other people have pointed out, it's possible to program badly in any language. Some make it harder than others (java, smalltalk for examples), but there are always tradeoffs to be made.
In short, don't write off (npi) Perl without at least trying it out first. If you do systems administration or large amounts of text monkeying, you will not be sorry you tried it.
--
A host is a host from coast to coast...
A host is a host from coast to coast...
Unless it's down, or slow, or fails to POST!
d'oh... wasn't done editing. sometimes i wish there was a "Are you sure you're ready to submit?" option for those times when i hit submit instead of preview. *sigh* Oh, well.
--
A host is a host from coast to coast...
A host is a host from coast to coast...
Unless it's down, or slow, or fails to POST!
Or to write a database? (insert your own examples here)
I don't think most people will argue with your contention that Perl isn't the best language for everything (I certainly won't). However, for people like me who do systems administration or for companies like mine which use Perl for allowing web pages to talk to databases, it's great. As our company grows and we add more logic to the system, we'll probably think about moving that logic from Perl to something compiled, but for now most of what we do is presentation, and this is where Perl shines.
Of course I wouldn't want to write a database (or compiler, or productivity app) in Perl. I also wouldn't want to write it in Java, or SmallTalk, or (insert lots of other languages here)... Perl is a good thing to have in a well-rounded toolbox, though. Sorta like an adjustable crescent wrench/hammer/screwdriver all rolled into one. Sure, that socket driver might work better for a certain situation, so it might save time to use it instead, but a lot of times the multi-tool will work just as well or better (faster since you've already got it).
Carrying the metaphor to an extreme, one could make the case that a good programmer should have a large toolbox of specialized tools. However, lugging around all of those tools is not practical, and it's much easier to have a multi-tool that fits in one's pocket, and the specialized tools are only pulled off of the shelf when the multi-tool doesn't work well enough. The key is recognizing when one is beginning to waste time by futzing with the multi-tool when the specialized tool would work better.
--
A host is a host from coast to coast...
A host is a host from coast to coast...
Unless it's down, or slow, or fails to POST!
I say what I mean and I mean what I say.
Most of the time.
Depending on your definition of "experienced", what I said is correct. While slices are great, some people don't use them much, and people who do use them are far more likely to take array slices than they are hash slices.
At least in my experience.
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
Most people who call themselves Perl programmers don't deserve to be called programmers.
Place your bar appropriately...
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
Started off with modula 2, and hated its guts. Now the newbies are starting on java... Suddenly modula2 doesn't look so bad for a start.
My scripts didn't break.
No further comment.
No matter how cynical you become, it's never enough to keep up.
To anyone trying to learn Latin, all Latin is obfuscated to an extent. "Paginarium Fulvinarium" anyone? (Watch me misspell it and prove my point.) I'm not aware of any programming languages which don't have some commonly used idioms that might confuse neophytes.
Why would you hire a non-Perl programmer to maintain existing Perl code? Are you suggesting that one measure of the 'suckiness' of a language is the ease with which someone ignorant of the language can perform code maintenance?
--
how to invest, a novice's guide
rotfl :)
i had the opportunity to maintain perl code at cobalt. whether it was the startup (hectic) environment or the startup (harried) people, the result was some pretty funky looking software artifacts. i think the image of "teenager puking on a mural" described it. hopefully things have changed since then.
--thi, (just another perl lacker)
This analogy is like blaming the rake for your broken nose because you stepped on it!
How can you honestly stand by anything you posted as anything other than a "it's not my fault" fit for your boss?
you screwed up, you assumed, and you are to be punished. please fess up to your errors and dont blame the language...
"Officer, it's not my fault she was offended I was using the english language!"
get real man, and quit looking for excuses.
Do not look at laser with remaining good eye.
So? By and large that's an undesirable feature. Any language that forces the programmer to overload the commonly used operators forces the reader of the program to disambiguate those overloaded operators.
Man, where were you my freshman year when I took C++? When we learned about operator overloading, I said that that's the stupidest thing I'd ever heard of. Everyone thought I was crazy.
5 + 7 = 57
Perl replacing Java ? ..
Dream on dude
I third the notion.
;)
Wall is awesome. Let's get an interview with him and watch the (camel) fur fly! (Just watch out for the python guys
----- if ($anyone_cares) {print "Just Another Perl Newbie"}
warn "Just Another Perl User" if $anyone_cares;
Good programmers write in C.
Good CS grads write in C++.
Good sysadmins write in perl.
I am a programmer. I have been unfortunately thrust into the position of a sysadmin. This is not an unusual situation, however. I thank $diety every day for perl, as I'm sure many others do. It is the tool I need to get the job done. I use it so much I sometimes THINK in perl.
Therefore, please refrain from smacking this dromedary.
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?
Shut up and show them YOUR code.
----- if ($anyone_cares) {print "Just Another Perl Newbie"}
warn "Just Another Perl User" if $anyone_cares;
This reminds me of a passage in Heinlein's Stranger in a Strange Land. Mike (the main character, a human raised my Martians) has started a church to teach people the Martian Way (basically, Peace, Love, and Understanding). When Jubal (his human mentor) asks him why Mike takes a collection, when Mike has more money than ghod, Mike gives an answer along the lines of, "If you don't make the rubes pay, they don't pay attention." (Maybe someone else can get the quote right, haven't read it in years.)
Weblogging Considered Harmful:
Agreed. I love reading his writings, they always make me laugh and think. In fact, I think it was cos I read one of his speeches which got me to learning perl. Sorta, what kinda language can a man with this kind of mind produce?
Oh, I do. The topic is an interview of Larry, not an interview of Guido. Discussing Python is off-topic.
-- Abigail
Perl is good because of the flexability. Perl, for me, is GREAT because of the huge number of modules that allow you to do things that normally would take C/C++ API calls. It's slower that the API call, obviously, but you can't beat it for prototyping and problem-solving.
:) Seriously, a lot of modules use it exclusivly now, and I personally prefer OO syntax to "standard" Perl syntax in many cases (using CGI.pm, for instance). And, save for those modules and the tie functionalty, you don't have to use OO if you don't want to. There's more than one what to do it!
Don't believe me? Check out http://www.perl.com/CPAN/ and scroll through the vast listing. The strength of Perl in the number of appplications it's been applied to is, indeed, a strenght of the language. For example, I recently had need of a dirt-simple SMTP server. I could have written it in Perl, C, any number of languages that allow socket programming. But Perl had an easy to use, OO-based module that allowed me to setup and accept messages from clients in less than 10 lines of code.
Nothing fancy, but I didn't need fancy. If I had wanted a "real" SMTP server, I would have found/built it in C, or used an external program. But Perl has, so far as I can tell, the greatest number of easy-to-use modules for a variety of tasks I've ever seen.
As for OO, Perl got it because it helps solve certain problems well, and it's a cool buzzword.
You don't need to go buy a book at all. Look in the Perl online docs for perlre, perlvar, and perlop, for starters. But, few would use such a construct. And, I think it unfair to ask a programming language to explain syntax on the same level of a standard UNIX command. Perl is NOT ls, or even sed. But, at the same time, you can build nightmarish constructs using sed, awk, csh, bash, etc., in any combination or alone.
I was going to leave this alone. That is what Tom said -- only in part, not in the whole. And he's right -- how many people use Java to do their day-to-day automation tasks? Have Java overtaken Perl, or even C, for web-affilated tasks? This is NOT to say that Java is bad. But it's still a load on any browser running today, one that stalls the download of a site. I don't use Java on my site because of that -- studies have shown that the short attention spans of modern people apply all too well to the web, and I prefer a quick download for my site, even if I lack some of the tools I'd like to see. I don't use Flash for the same reason.
Java kicks butt for Intranet sites, where it's relativly easy GUI-building skills come in handy, and your bandwidth is high. For certain focused applications on the Net, it works as well. But I'd not call it the backbone of the Internet in the way that Perl is, or that PHP is becoming.
In that light, Tom's comments make a great deal of sense. Java is _not_ a simple language to learn for the non-programmers out there. Perl is easier, does much of the same work, but lacks a pleasant front end, easy-to-use IDEs, and the marketing push from Sun.
As noted, the code itself returns exactly what it says it will upon them turn to the year 2000. The assumption of others that the code must, for some reason, generate a 2-digit number is odd, at best. Think this way; given that you have a eventual rollover to 2000, or even, say, 1900, or 1800, or any 4-digit time, what would _you_ do to solve the problem? This solution gives a small number (>255), is highly flexable, and did not break when the century changes. Code that makes assumptions based upon not reading documentation is, sometimes, asking for failure.
Alt. solutions? You could have it return seperate times for pre and post 2K, or even have two seperate functions. This is similar to what is occuring now, and some would say is no different, after all, people are changing code left and right. The 1900 + solution, however, gives one set of numbers that will work indefinitly, given that you add correctly.
Or, you could have the function simply return the 4 digit year. Actually, localtime, when called in scalar context, does exactly that. They could have simply said, "We'll find a better soluation later", and gave out the last two digits. But, that solution also goes aganist the other date/time code in Unix, which is based upon a running count of time. Instead, they found a solution that would work over a longer span of time, if the programmer looked to his code properly at the beginning.
It is a reasonable mistake -- if you have not read the localtime information. You list the page http://language.perl.com/news/y2k.html -- did you read it before you coded? Or the man page for localtime? Or the listing for localtime in _Programming Perl_, _Perl in a Nutshell_, etc? All of these mention the 1900 + issue. And that page tells you how to fix the very problem you refer to. If you refer to Usenet/Mailing list messages, then you might have a point. But I find it hard to believe that the localtime issue was not mentioned. There's even a contest about it!
In short, Y2K issues in Perl come from assuming, and not reading the basic info about the functions in use -- information that comes with the program, and is not hidden away in a dark corner of the documentation. In fact, you must read this info in order to use the function at all! Adding numbers to 1900 makes sense in the context of the majority of uses for such a function, does not break upon transition to a new century, and can be easily switch from 1900 to 2000 and back, used in 2 digit or 4 digit mode without loss of information, while you work with less data all the while. What could be better?
To my mind a "Visual Basic Weenie" is somebody who knows VB, does not know any other languages, is not interested in learning any other languages, and believes, based solely on his own ignorance and the propoganda that he has digested from his own peers, that VB is the best language ever.
Feel free to substitute other languages (perl, tcl, c, lisp, java, javascript, even by beloved python) into this definition as appropriate.
The only problem I've had with Perl is that when I started learning it there was no starting point. "Ten Most Used Perl Phrases" is needed as a starting point, but I couldn't find it. I had to resort to translating a few simple awk and sed scripts to see what the equivalents were.
Freshmeat Editorial, 25 Dec 1999:
Coding Standards - Good Idea or Subtle Evil?
I'd agree with Theorem 2 posited therein.
--
I'd rather have a bottle in front of me than a frontal lobotomy
$year4 = ($year < 70) ? "20$year" : "19$year";
As usual, I caught the error about 0.1 seconds after hitting "Submit" ...
-- The subject is just a saying, I'm not really calling anyone stupid!
;)
Larry Wall is a good writer, he is funny, and he holds your attention well. Unfortunately humour doesn't help with language design.
Actually I believe that a good programmer is good in any language. I never complain about a language for bad code. Although I do believe that different languages are better for different things, and there is no "end all" of languages. As for perl, I think it's great. As a heavy C programmer, I picked it up in a day, and started writing lots of useful code. But I only did it with small scripts. Later, I started using it for larger scripts, and found that I needed to document the code (lots of comments) to have a good idea of what is going on. I find that good documentation allows for the most cryptic code.
I also met Mr. Wall at Linux World Expo back in March. To paraphrase you I would have to say Larry Wall is a good writer, he is funny, and he holds your attention well. Unfortunately humour doesn't help with understanding language After thanking Mr. Wall for the great language that he created, I continued to criticize his book "Programming perl". Because I found that it jumped around a lot, and took a few reads to understand what he was trying to say. He answered me with "Yeah, I know, that's why I added all those jokes". We both laughed. Although I think it was those jokes that made things confusing in the first place
----
Larry Wall: China has now adapted perl as its National programming language.
Linus Torvalds: Yeah, that's because the are use to incomprehensible characters.
Steven Rostedt
Steven Rostedt
-- Nevermind
Perl is one that I usually bring up, along with Apache, SendMail, and BIND.
+-- (Score:-1, Moderator on Power Trip)
Easy on the bold, tiger ;-)
What exactly is a "Visual Basic Weenie", anyway? Is anyone who knows VB automatically a "weenie", or is there some qualifying characteristic?
Note that the figures are botched at the beginning. The first figure is supposed to be about combining Linguistics, Computer Science, Common Sense, and Art.
You have a strange definition of "harder". Most people who like Perl seem to find it easier than it should be. :-)
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).
Perl is typesafe where it's important, and not typesafe where it's not important. Perl is actually quite picky about structural type issues, but purposefully mushes together the types that most people want to mush together. This is a feature. Most people don't want to think about whether a number happens to be represented as a byte or a short or a long or a float or a string. Most people just want to get their work done.
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.
Sometimes this is a feature, and sometimes it's not. Perl is about balancing computer science with a bit of common sense.
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.
So? By and large that's an undesirable feature. Any language that forces the programmer to overload the commonly used operators forces the reader of the program to disambiguate those overloaded operators. This is an area where Perl is more readable than the typical language. Things that are different should look different, and Perl just applies this to operators as well as to data structures.
You seem to assume that Perl is the way it is out of ignorance of the typical tenets of computer science. That's not generally true in the ways you seem to think it's true.
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.
But it's a very small crock. It's trivial to make lexical scoping the default when you want it to be.
Argument list flattening. Again, there are ways around this, but they require fairly sophisticated understanding of the language.
It's just another form of interpolation, which is a very powerful feature. And doing lists of lists in any language requires a fairly sophisticated understanding of that language, and of computer science in general. Computer scientists love their trees, but lose sight of the fact that most ordinary folks prefer flat data structures most of the time.
To add insult to injury, there's no simple way of naming the parameters of a function.
You mean there's no required way. It's certainly possible to name your parameters in Perl, and not particularly complicated. In fact, parameter passing in Perl is very easy to explain precisely because you don't have to name your parameters if you don't want to. The fact is, compared to other languages, Perl's parameter passing scheme is rather orthogonal, relying as it does on the existing notion of arrays, rather than introducing extra syntax.
Even Scheme has this -- and it's the sort of language that gives you sand and a fire if you want a wineglass!
So you're complaining that Perl is more orthogonal here than Scheme. Cool!
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.
Pointless to some people who don't optimize for the same things other people do...
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.
Can't disagree with the platitude. However, people have the durndest ideas about which ideas are similar and which ones are different. Perl conflates the things it thinks most people want conflated, and doesn't stress about the others.
For example, why is 'eval' used to denote exception handling?
Why not? Doesn't the English word "evaluate" indicate some degree of suspicion as to the results?
Why are references to aggregates prefixed with a '$'?
Because what is really being referred to isn't the aggregate.
How come packages and classes are defined with the same syntax?
Seems like another place where Perl is being orthogonal and economical.
There are answers to all of these, but those answers are historical rather than meaningful.
Really? You think that history is not meaningful? You think that if someone thought something out ten years ago, the logic is no longer valid? What exactly do you mean by that?
Cars used to have reins in the early 20th century, but no one would argue that they belong on a car for the 21st.
And indeed nobody is arguing for reins. Perl left out a lot of reins to begin with, but kept the wheels. We're currently arguing about whether the clutch pedal should be mandatory or optional. :-)
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.
That's probably the right way for you. TMTOWTDI.
The main problem boils down to this: the Perl program print x; compiles and runs without an error message. The equivalent program in Python, Java, C, or C++ produces a compiler error. I have a hunch that a lot of programmers have torn out a lot of their hair while debugging Perl programs because of this.
--
No. A good (lazy) perl programmer installs the XML Parser and lets it do all of the hard work!
Bingo! But you missed my point, I think. Sure, now that someone invented XML, it's best to use it. I'm suggesting that it wasn't a Perl programmer who invented it, for the reasons I hopefully made clear.
First, make it work, then make it right, then make it fast, then, make it bloated!
Your example brings to mind an image of two ugly demons at the bottom of a pit competing to see which is less ugly.
Try comparing Perl to a syntactically friendly and well-designed language, and
use an example other than one dealing with string manipulation, where Perl is great, no one denies.
If all you had to do was string manipulation (like outputting HTML), then you're golden with perl. But would you choose to use Perl as a language for developing business logic?
Or to write a database?
(insert your own examples here)
First, make it work, then make it right, then make it fast, then, make it bloated!
I agree entirely. I wish I could mesh languages together so that I could use the best of them all at different points in my programmin tasks.
However, a lot of Perl advocates seem to want to do a lot more with Perl than is good for it. Why did Perl get OO stuff added on, for example? Is that really the direction Perl should be going?
First, make it work, then make it right, then make it fast, then, make it bloated!
A lot of people argue thusly:
a bad programmer can create bad code in any language
Can't be denied. However, this does not mean that the language you choose has no effect on the way you see and approach problem solving. Someone who's been primarily using Perl (and likes it) vs. someone who primarily uses Java (and likes it) will approach the same problem differently. I'd guess that it depends on the problem as to which approach is better.
Also, even more subtle, the choice of which problems are interesting will be influenced by your choice of programming language. Frankly, I'm bemused by all the glorying of Perl regarding the ability to manipulate text. So? To you Perl programmers, do you recognize the point in your life when text manipulation became all-important to you? Do you recognize the influence Perl has had on your thinking?
I've been trying to think of an example (and it's hard). Here's my attempt:
XML. Why was XML developed? To create a universal way of formatting data? To create a standard for data transfer so that two disparate systems can easily exchange information? Ok. Why was Perl developed? Initially, wasn't Perl developed to parse bizarre logging formats for report generation? This is where it got it's great text manipulation abilities, wasn't it? The use of speedy regular expressions really helps to parse logs of all different formats.
A Java developer looks at all those formats and thinks, yuck! Shouldn't we have a standard so I can read them all without so much work?
A Perl developer looks at all those formats and thinks, with just 10 or so lines of code for each format, I can decipher them all. Look how superior Perl is!
So the Perl programmer starts coding all those regular expressions to decipher an infinite number of different text formats.
The Java programmer writes a standard, writes the code that will read any data formatted to that standard and says to the world, "if you guys do it like this, we'll all be set cause I've written this tool that creates a tree from you data, and anyone can use this other tool to walk that tree and get what you want from the data".
Now, we can all argue which is the better approach, butI feel better knowing both are around, to be honest.
Yes, Virginia, your choice of programming language will have an effect on your thinking, and your coding. Not good or bad, but true.
First, make it work, then make it right, then make it fast, then, make it bloated!
Saying that Perl sucks is acceptable in the context of the previous poster's comment. He prefaced his statement accordingly so it didn't just come out of nowhere.
You seem to imply that "competent, professional programmers" can write Perl programs and leave them in good state for future maintainers. I assume you mean programmers who are true CS people and not some accountant who took a course in programming at night school. I don't see where a formal CS education can prepare anyone for the syntactical mess that Perl is. Intelligent people, regardless of background, have been successful programmers. I believe there are some languages that are more suitable for learning and quite frankly, Perl isn't one of them.
You obviously have a vested interest in stating otherwise. The more people you can convince that Perl is easy to learn and work with, the more books you sell. Perl can't be everything to everyone, but please stop denigrating people for either complaining about Perl or for being "an unskilled laborer". You sound elitist and actually contradict yourself when you do that.
Hates people who have stupid little sigs
Take a deep breath and count from 1 to 10. Feel better?
The fact that you interpreted my comments as slanderous says more about you than me. Tom Christiansen is a Perl evangelist. Tom Christiansen is an author of Perl books. Tom Christiansen stands to benefit from the proliferation of Perl.
It's also amusing that you ask me not to "attack" Tom when that seems to be his favorite MO. Maybe you need to give Tom a pep talk about that.
Hates people who have stupid little sigs
I have to agree. I was more or less forced to learn Perl when I started serious support of web sites, and at that stage (about four years ago) it was maybe my 20th programming language (I started with Algol 60 in 1967...).
:-)It's a great hacking language which has got too big for its boots.
Crazy syntax. The fact that Wall's stated aim was to have almost any string "mean something" in Perl did NOT help an experienced programmer trying to learn exactly what the damned stuff DID mean. Object-oriented programming? I have studied OO languages starting with SmallTalk in 1974, and while you can get object-oriented concepts working in Perl the ideas involved are certainly not intuitive or obvious.
Perl is a fine example of what happens when a good idea is twisted WAY too far in an attempt to achieve world domination (really: to widen its range of applicability beyond what is sensible
Wall is a way-above-average programmer who needs to take a step back and come up with another very good idea.
"If computing ever stops being fun, I'll stop doing it"
I will admit that if you know Perl well, then yes, you can write powerful programs quickly ithin particular domains (notibly cgi scripting), some might even enjoy this.
isn't this a rather important feature? certainly it's possible to write utterly incomprehensable code in perl. that's possible in any language. the beauty of perl is the fact that buried in all that potental confusion is a truly powerful and intuitive solution to just about whatever problem one faces. not many languages can claim to be as diverse as perl, and the languages that do encompass the same broad spectrum don't (in my experience) do it nearly as cleanly. *shrug* perl's not for everyone, but it's invaluable to those who don't like learning new syntax every time they face a new problem.
mikecan't say i completely disagree with the sentiment in the original post. perl's not the most intuitive language, and it certainly can be difficult to grasp some of it's more esoteric features. one of the amazing things about the language, however, is that one doesn't *have* to grasp it's totality to do astounding things in short periods of time. perl's just damn good at what it does, and once you've figured out the basics, you can do just about anything, do it well, and do it quickly.
the first perl book i picked up was the camel book, and it's served me well.. got my second copy last week actually. the first one didn't hold up to my repeated perusings, and apparently decided to run away. i can't imagine a better investment though. there's more information packed into those few hundred pages then i'd have thought possible.
mikeAny language can be written incomprehensibly (C even has the obfuscated C contest to prove it), PERL just makes it easier. However, having worked in a company that made extensive use of PERL, I can say that maintence of that code was just as difficult (no more, no less) than maintenence of other code.
Software maintence all comes down to design standards and code review. In a good system there are agreed upon coding standards that all developers are familiar with, and code gets a peer revier before going into production. This review stage tends to lead to confusing bits of code getting commented heavily. As always, YMMV
You might be a Visual Basic Weenie.
You might be a Visual Basic Weenie.
You might be a Visual Basic Weenie.
You might be a Visual Basic Weenie.
...with apologies to Jeff Foxworthy.
Interesting footnote; my last boss was the source of all of these VBWeeinie tests. I guess he should be called an ActiveVB Weenie(tm)...
Jedi Hacker (Apprentice) and Code Poet
censorship is a form of noise, which actively seeks to drown out content with silence - Crash Culligan
That is exactly what happened here, I either didn't read or pay enough attention to the documentation available on the subject. Had I read the documentation, there would have been no problem, I am aware of that. That aside, the cat is out of the bag. The issue that I am refering to now, is 'why is it that way?' why not just return a 4 digit year? What would lead you to decide to subtract 1900 from the year before returning it?
I can't imagine the purpose for that, and since I can't imagine why you would do such a thing and I ASSUME that its a 2 digit year. To me this is a somewhat reasonable error to make, why would I look up the documentation on something if its use seems to be completely obvious? I have nothing against reading documentation, I -like- man pages, I just never had any reason to do so in this case, and I got burned. No excuses though, its my fault and I know it. I'm still terribly curious as to the where and why behind this particular design decision.
Sigs are awesome huh?
It was the result of a cut-paste and some hasty editing. Blah.. sorry.
Sigs are awesome huh?
Why though? Why return the year minus 1900 if the intent is NOT to get a 2 digit year? And if the intent is to get a 2 digit year then clearly the code has a Y2K issue as it no longer does so. If the intent is NOT to get a 2 digit year, what is the intent? The function returns 'the year minus 1900' then we have to 'add 1900' to get the correct year.. how does this make sense?
Given all of that information, I think it would be a reasonable mistake, and as such not treated so.. hrm.. arrogantly?
Sigs are awesome huh?
Well, I can appreciate your point, but take some responsibility here. If you had written:
printf("The year is 19%d\n", localtime() -> year);
How would you have expected that to work? Would the phrase "Perl is Y2K compliant" magically make that 19 turn to a 20?
Or did you do it a different way? Give me an example of how you wrote your script, and how you expected it to work in 2000.
---
Let's have that fight some other time, okay?
Works for me. I wasn't intending to start a holy war. I was genuinely curious.
Larry Wall mentions in the article that just having the GPL prevented people from using Perl, and that's why he added the Artistic License.
What are the limitations with the GPL that he was concerned with?
That's the point isn't though? Despite it's "design", human language is expressive and powerful. It's evolved that way. And so it is, and will be, with Perl. Like LW said :
"A camel is a horse designed by a committee. Or at least it looks like one. But appearances can be deceiving, and a camel is well adapted to its ecological niche. So is Perl. Despite the fact that it is designed by a committee."
Plus, from the Camel book,
"Camel's weren't designed to smell good. Neither was Perl."
Also, thank LW for patch, surely his second best contribution to the programming world.
Metaphores are like scabs. If you pick at them, they bleed. :-)
// TODO: fix sig
I started programming in Perl mere six months ago. I don't know, maybe I was just lucky to be guided at the most important resource of Perl right in the beginning: the online documentation packaged in the Perl distribution.
/usr/lib/perl5/pod/perlfaq4.pod
I remember reading about Perl's y2k compliance in the docs. From there, it was a no-brainer:
[blade@leela ~]$ perldoc -q 2000
=head1 Found in
[clip]
The year returned by these functions [gmtime and localtime] when used in an array context is the year minus 1900. For years between 1910 and 1999 this happens to be a 2-digit decimal number. To avoid the year 2000 problem simply do not treat the year as a 2-digit number. It isn't.
I have the habit to get indignant when my intelligence is insulted, also. It helps to learn just the right amount of humility to consult the documentation first to avoid the need to blush later. YMMV.
No. A good (lazy) perl programmer installs the XML Parser and lets it do all of the hard work!
I love writing code, but I'm not dumb enough to rewrite the world. There are tons of modules in Perl that make a lot of the hard things easy.
-- Freedom means letting other people do things you don't like.
I guess I don't understand why it is so wrong to read the manual. Whenever a newbie asks a question is seems that the first response is always along the lines of "rtfm". If you follow comp.lang.perl.misc at all you will quickly learn that reading the manual is a "Good Thing". Linux has a similar culture around it. That's why all those HOWTO's are included with every distro.
I use Perl a lot and I'm not thumbing through the manual all the time. However, when I switch to C, C++, or Java I do look stuff up because I'm used to the Perl way of doing things.
My point is that when you only use a language occasionally (and especially when you only use it when you "have no other choice"), it might be difficult to remember all of the intricate details of the syntax. I'm just guessing that it is the intricate details because the if() blocks and the for() loops can be made to look exactly like C (but they don't have to). Also, most of the operators I use are exactly like every other language I use.
Perl is unquestionably a powerful language. There is a lot of obfuscated syntax (but all of that syntax is well documented). Even when you are writing "non-trivial" applications, Perl doesn't force you use all of the syntax of the language.
-- Freedom means letting other people do things you don't like.
With apologies to J.R.R. Tolkien:
Three Scripts for the Programmer-Kings past deadline,
Seven for the SysAds wandering the halls alone,
Nine for the Windows-Men doomed to die,
One for Larry Wall whence it has grown,
In the land of Internet where scripts are CGI.
One Perl to rule them all, One Perl to find them,
One Perl to bring them all and across The Web BIND them,
In the land of Internet where scripts are CGI.
"These laws they're passing won't even compile anymore, let alone execute." - anon
I learn some stuff from the man pages (perlfunc) and from looking at other scripts, but I still haven't find a decent tutorial on the net (unlike other languajes, like php, C, etc..). I'm still clieless when I find a line like:
$var = ~~^*)(*|^**?^#(8...&(#&|^}[;
or something..
--
--
Stay tuned for some shock and awe coming right up after this messages!
I agree; I have rapidly coded and debugged many great Perl scripts because of its interpreted nature. However, after using Perl for a couple of years now, and finally working on web sites where Perl scripts have to handle complex search queries from thousands of users a day (and having the server come to a crawl because of it) I'm beginning to question whether Perl scripts shouldn't be compiled into executables for production use. In other words, the intepreter/compiler used now is excellent for platform portability and rapid development, but perhaps the Perl code should be made into executable code to make it faster before production deployment. Can this be done? Wouldn't it increase the speed? Why isn't it the normal habit? (Or is it and I just didn't realize?)
I expect you might say, "You're just using the wrong tool... use C instead of Perl", but that just seems like a cop out, because CGI scripting and all the activities of CGIs are so much more elegantly handled by Perl.
Tom, please keep your own foaming at the mouth to yourself. It is a constant nuisance, and has no place anywhere.
-- "This is the Space Age, and we are Here To Go" - W.S.Burroughs
Perl is not THE solution for everything, but for a lot of things. It is really great for system management and web stuff. Its also good for small programs doing just one special thing (see "rapid prototyping"). Because these are the things i do (i do not write huge ...-applications), Perl is my language.
Of course, its not easy to learn, but OReilly books help alot :-). I wish i will get only a quarter as skillfull as Larry or Tom.
See ya !
wumpie
So sysadmin Bob is walking across a bridge when he sees a guy about to jump to his death. Being a good sysadmin he couldn't care less, but he notices the poor soul is wearing a "#!/usr/bin/perl" t-shirt. The jumper protests as Bob approaches, but Bob mentions the t-shirt.
"I happen to use perl myself, are you a sysadmin?"
"Why, yes I am." says the jumper.
"Cool, Unix or Windows?" asks Bob.
"Linux." says jumper.
"Hey! Me too. Compiled or interpreted?" says Bob.
"Compiled."
"All right!! Easy or hard to maintain?" says Bob.
"Oooo, very hard." says the jumper.
"HERETIC!" and Bob pushes him off the bridge.
Stolen from Emo Phillips.
There's a spider on your shoulder.
I dont think anyone is arguing that perl is not a very useful language.
But, like java, the thing that makes it the most useful, are its extensive collection of functions and libraries.
The *language itself* is what most people detest.
The most ugly thing in my mind being the
while(<>)
type of construct. It is synonymous with all that is bad about perl syntax. Saving a few characters does not in anyway make it a more powerful language. It just caters to people who are too lazy to write readable code.
THIS is the problem with perl.
Yes, "a bad programmer can write bad code in any language".
But with perl, a moderate programmer is likely to write unreadable code too, because it seems to be common practice to write perl to be with as few chars as possible.
Perl seems to encourage that behaviour, from a presumably mistaken assumption, "short code, is efficient code".
However,
for(i=0;i < 19;i++) doit(i);
is NOT MORE EFFICIENT THAN
/* This is where we handle evaluation of args*/
for(acount=0;acount < MAXARGS;acount++){
evaluate_arguments(acount);
}
[sigh. what am I thinking... posting about clean coding practice on slashdot? oh well...]
Thrid that. I vote (if I get a vote) to get Mr. Larry Wall over on slashdot for an interview.
"`Ford, you're turning into a penguin. Stop it.'" -THHGTTG
I disagree, yes perl can be hard to follow
sometimes, but the same is true of any language.
I for one find perl easy to use and code
in. its easy for me to look at other peoples code
and see why they set up sub routine A. instead of
sub B. but show me a chunk of C or java and I get
confused. Saying a language sucks because you
have a problem with it is pointless.
Use whatever works for you.
Gentleman, you can't fight in here, this is the war room..
who sez death can't be funny....www.endlesssorrow.com
I don't know, but considering how much you seem to read the manuals, I'm guessing you have one more bug in your code: all your months must be off by 1 :-)
Coming up with a way to represent date data type is one that is subject to whoever is building a language. There is no standard or common thread. Just taking a look at a handful of languages you'll find differences... (i.e. Java and C do dates differently, etc.) Why would Perl be any different?
If anything Perl handles dates very similarly to C, therefore its more standardized (if you wish to call it that) than others....
Accept the fact that you made an assumption that was wrong and move on, don't blame Perl...
-- A computer without COBOL and Fortran is like a piece of chocolate cake without ketchup and mustard
--
Tom, you've hung around Slashdot long enough to know that's /always/ what happens. Maybe it stings more when it's about Perl...
--
That's a common mistake, and it was discussed a *lot* in Perl circles in the run up to Y2K, but it is most certainly not a bug in Perl. The polite way to say "you just suck" is "you didn't read the documentation, you just guessed how locatime worked" -- which is no way to use an API.
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.
--
- 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 with "ordinary programmers." [LOL]. More humor at perl.org is a three-year-old rant 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.
My point still stands. Most programmers would have little trouble learning what 2 of the 3 do. The last one is a concept that most people don't need whose equivalent in other languages winds up with substantially worse syntax. In fact Python actually does not support an equivalent. Its scoping rules are simply not sufficient to the task of defining true closures.
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
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
At issue is the difference between a string, a reference to a function, and calling a function.
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
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
just one little stupid correction: Sapir and Whorf were two people, not one.
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.
-BrentGood programmers write in X.
... Do you really think "programmers" never have to do text processing? You will never find a C library that does text processing as well as Perl.
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.
Not Perl's Fault. C does the same thing. POSIX *requires* the same thing.
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.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
Can anyone show me a code fragment which outputs a '19100' date, and which would have worked correctly with a true 2-digit time format? A function which outputs '100' instead of a two-digit year might be based on a reasonable, if incorrect, assumption. I can even imagine a wrong-headed attempt to handle post-1999 dates producing the year '20100'. However, hard-coding a '19' is asking for trouble no matter what date format you think you're getting.
Weblogging Considered Harmful:
That was the version Larry was talking about. He started that ball rolling. He was talknig about how they decided to have someone make a commercial version.
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
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
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.
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 and this collection 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? :-(
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. :-)
Well, thanks. I'm glad we could be of service. Some of the better postings weren't even highly scored.
Ian, please keep your frothing python bigotry to yourself. It has no place here.
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.
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.
mikeThe 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
I work for Department of the Navy and we also use Perl for mission critical applications.
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.
They're doing the best that they can, given the circumstances, and should be encouraged, not squelched.
.pl.
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
I think that we should really point to perl when people start talking about free software not catching on. This is a program that has been around and is still going strong.
----- When it is dark enough, men see stars.
I work for a major American automotive manufacturer, and we use Perl every day to write mission-critical applications. As in "if this doesn't work, we don't make cars"
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!
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.)
In the whole community, there are a large number of talented programmers, and a smaller number of truly elite hackers who can do most anything.
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
-- Josh Turiel
"2. Do not eat iPod Shuffle."
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. --LW
It's free-based Wall.
I nominate the above quote as the new open-source motto. Ha!
-- What you do today will cost you a day of your life.
"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.
That's really quite a shame, because the article is rather a good bit better than the comments are.
Let me just say, ack! I read the Y2K info on perl and was assured that Perl was compliant. When the rollover happened several of my scripts started printing the year as 100 or 19100. I blame myself for not having looked into the problem deeper, I just read the popular opinion information on the net about how Perl is Y2K compliant. Well it turns out it is compliant, but only if you use it 'right'. Here is an example. If you use the localtime class it will return a year in what appears to be a 2 digit format. I say 'appears' to be because it turns out that localtime isn't returning a 2 digit format at all, its actually returning a number which is the number of years elapsed since 1900, which just happens to look like the familiar 2 digit format we all know and love right up until the Y2K rollover happens. Here is what I mean, a month ago the year portion of localtime returned '99', now it returns '100'. According to many perl sites, however, this is Y2K compliant. They would have me believe that everyone has been using it wrong and that if people would have wrote their code correctly in the first place this wouldn't happen.
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
Sigs are awesome huh?
Let me see.
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.
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
Hire x programmer to do x programming, and hire
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?
First, make it work, then make it right, then make it fast, then, make it bloated!
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. It takes good programmers to write good code. But it also takes a good language, and perl is one such language.
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
Hey, Hemos & Taco, can we get Mr. Wall for a /. interview? He would be most entertaining.
+-- (Score:-1, Moderator on Power Trip)
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.