Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Perl?

bits.shutterstock.com

Post reply on HN
Print view View original

111–118 of 118 posts

Re: Why Perl?

#111

Post by jamesbritt »

kamaal wrote: post #96
jamesbritt wrote: post #51

Earlier quoted context omitted.

Larry Wall didn't care much about making a pretty language. This suggests that Larry Wall was happy to create a kludgey language for the sake of just getting things done. I don't have any references around to back this up, but given Wall's background in linguistics, and his demonstrated interest in language features, I have to believe he was interested in creating a coherent, thoughtful, as well as practical, languag…

>> This suggests that Larry Wall was happy to create a kludgey language for the sake of just getting things done. Don't really know what to reply to this. Is this your speculation, or do you have a citation to back this up. Have you had some programming experience in Perl? Perl is the only programming language(the other tool is emacs) I have learn't so far which gives exponential gains in productivity with a linear l…

Is this your speculation, or do you have a citation to back this up.

As I wrote, "I don't have any references around to back this up."

I used Perl for a few years about 10 years ago; was quite the perl evangelist at that job. Then I found Ruby, which won my heart. But I have a pick-cover copy of the book perl (yes, all lower case). And I've read the whole thing and liked Wall's jokes. :)

Python's glory is fading pretty quickly. The web crowd is going to the next cool framework. Ruby tends to be pretty famous these days.

Pure trolling.

Because whatever tries to replace them, ultimately ends up looking up very similar to them.

That's an amazing assertion for which I would like to see proof. FWIW, I don't think Haskell looks like any of those, a passing resemblance to Lisp notwithstanding.

Perl, et al may have been done right, but it's myopic to think they are some sort of end point of perfection, if only because we don't know all the things we want to do, so we don't know all the things we need to have, "done right" or otherwise.

"There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy."

Re: Why Perl?

#112

Post by chromatic »

jamesbritt wrote: post #111
kamaal wrote: post #96

Earlier quoted context omitted.

>> This suggests that Larry Wall was happy to create a kludgey language for the sake of just getting things done. Don't really know what to reply to this. Is this your speculation, or do you have a citation to back this up. Have you had some programming experience in Perl? Perl is the only programming language(the other tool is emacs) I have learn't so far which gives exponential gains in productivity with a linear l…

Is this your speculation, or do you have a citation to back this up. As I wrote, "I don't have any references around to back this up." I used Perl for a few years about 10 years ago; was quite the perl evangelist at that job. Then I found Ruby, which won my heart. But I have a pick-cover copy of the book perl (yes, all lower case). And I've read the whole thing and liked Wall's jokes. :) Python's glory is fading pret…

Perl, et al may have been done right, but it's myopic to think they are some sort of end point of perfection...

I'm not sure anyone will argue that seriously.

That's an amazing assertion for which I would like to see proof.

It's probably not true for Perl 5's concurrency and parallelism features, such as they are. (You get fork() and POSIX-style shared memory with IPC or a queue or RPC or whatever, and you like it.)

It's probably true for access to POSIX and other standards. (I can't remember the article here several months ago about how to write fast network code, but it's essentially "Embrace what Unix and Unix-like systems give you." It's not the article about the Varnish architecture.)

It's almost definitely true for module repositories, where it's not enough to track dependencies and mirror downloadable code bundles. Testing, change management, dependency resolution tracking, and documentation formats and presentation systems are essential. Not even CTAN gets it as right as CPAN.

Re: Why Perl?

#113

Post by chromatic »

buster wrote: post #102
buster wrote: post #98

Earlier quoted context omitted.

> That is a sample of one. Try visiting a YAPC and you'll see a sample of 1000+ that is opposite to your's. Sure, i never said that no one likes Perl. I'm well aware that many people like Perl. This may sound harsh, but here is my impressions of the people i've personally talked to that use Perl (please don't take that personal, i'm well aware that there are A LOT of good programmers out there): - Typically too lazy…

Regarding the "perl5 not in parrot" citation, i found some pretty good hints at this problem: From the Perl Wikipedia page: It is often said that "Only perl can parse Perl",[49] meaning that only the Perl interpreter (perl) can parse the Perl language (Perl), but even this is not, in general, true. Because the Perl interpreter can simulate a Turing machine during its compile phase, it would need to decide the Halting…

That's not completely true though; most of those analyses take the conclusion way past the point where it's accurate.

You cannot definitively produce a single canonical parse tree for every valid Perl 5 program without executing code in some cases, but you can produce a coherent and accurate parse tree without executing code if you allow nodes in the parse tree which express the two types of ambiguity (undeclared bareword interpretation and unknown arity).

Most of the time this doesn't come up.

Re: Why Perl?

#114

Post by bitcracker »

Mithaldu wrote: post #108
bitcracker wrote: post #105

Earlier quoted context omitted.

> marketing of perl core dev is terrible A link "Current Developments" in perl.org would be helpful. Thanks for the links but I'm not interested in minor changes of Perl 5 (Unicode etc.). I was very interested in the new features of Perl 6. No matter, I lost my patience and left Perl years before and returned into the Lisp and Scheme world where I was before. Sometimes I still use Perl 5 but merely for small scripts.…

I linked you to a repo where a meta object protocol for the perl core is being developed and you say you aren't interested in minor changes? Shine on you crazy diamond! :D

If you think that MOP for Perl is something big then I'm not surprised that Perl doesn't make real progress anymore.

Re: Why Perl?

#115

Post by kamaal »

jamesbritt wrote: post #111
kamaal wrote: post #96

Earlier quoted context omitted.

>> This suggests that Larry Wall was happy to create a kludgey language for the sake of just getting things done. Don't really know what to reply to this. Is this your speculation, or do you have a citation to back this up. Have you had some programming experience in Perl? Perl is the only programming language(the other tool is emacs) I have learn't so far which gives exponential gains in productivity with a linear l…

Is this your speculation, or do you have a citation to back this up. As I wrote, "I don't have any references around to back this up." I used Perl for a few years about 10 years ago; was quite the perl evangelist at that job. Then I found Ruby, which won my heart. But I have a pick-cover copy of the book perl (yes, all lower case). And I've read the whole thing and liked Wall's jokes. :) Python's glory is fading pret…

Pure trolling.

Call it whatever you like, but I have observed Python related posts/discussions experiencing a rapid decline. Clojure/Ruby et al are beginning to take more center stage now. In most discussions, which used to be generally a buzz with Python web frameworks these days doesn't even get a slight mention of Python.

Nothing wrong here, Python was the trend of the near past. There are newer trends these days. And there will other newer trends in the future. That's how it is, every couple of years. Something new comes to replace the famous. That's how technology works.

Now just because you don't like what you read, it doesn't automatically amount to trolling.

Re: Why Perl?

#116

Post by ccashell »

buster wrote: post #98
Mithaldu wrote: post #62

Earlier quoted context omitted.

Ok, more responses: > i can't say i love the language at all That is a sample of one. Try visiting a YAPC and you'll see a sample of 1000+ that is opposite to your's. >> often can find the core developers in charge of some code > i browsed a lot through CPAN and a huge part of modules hasn't been touched for years What you said has nothing to do with what you quoted. CPAN allows you to email those authors and the vas…

> That is a sample of one. Try visiting a YAPC and you'll see a sample of 1000+ that is opposite to your's. Sure, i never said that no one likes Perl. I'm well aware that many people like Perl. This may sound harsh, but here is my impressions of the people i've personally talked to that use Perl (please don't take that personal, i'm well aware that there are A LOT of good programmers out there): - Typically too lazy…

> A basic problem: Perl allows them to hack away all day and write hideous code that ensures they will never get fired. Due to their laziness the script will be undocumented, lack basic error checking, will have myriads of bugs and often fail, but no one except them will be able to fix it in a reasonable time frame.

Can you provide me with a link to any non-toy programming language for which this isn't the case? I've seen beautiful code in a lot of languages, and I've seen god-awful ugly code in a lot more. I don't think I've ever found a language that doesn't have some ugly code written in it, though.

> This is where you will be upset and think i am really unjust and a troll: I'm stating that Perl supports this behavior like no other language. (except maybe brainfuck ;) )

Well, when you offer up a statement that applies to essentially every programming language in existence, and then suggest that it only really applies to Perl, I can see where they might get that impression. A programming language is just a programming language. It's programmers that write it, and a poor programming can, and will, write piss-poor code in any language.

> My basic statement about Perl: It is possible to write readable, tested and maintainable code in Perl. BUT it is hard if not impossible with just the base language. It is by far easier to get it wrong then to get it right in Perl for the newcomer or average programmer.

No offense, but that's just flat out silly. First of, it's not at all hard to write readable, tested, and maintainable Perl in the "base" language.

Beyond that however, saying "just the base" language is very misleading and shows either ignorance or malice. Perl, by design, maintains a moderate "core". It doesn't ship with every module included. That doesn't make it hard to access additional functionality (such as Moose, Test::More, and thousands of others). That's a simple design decision, and isn't good or bad, it's simply a matter of trace-offs.

By your logic then, C is a horrible language, because it's almost impossible to write "readable, tested and maintainable" code with the base language, right? I mean, it has no object oriented functionality, no testing framework, and a very minimal standard library. What were they thinking? How is anyone supposed to get work done with C?

Oh, right. They get the libraries they need, and get stuff done. Just like in Perl. Only, in C you don't get CPAN to take 99% of the effort of finding and installing libraries out of the equation.

Re: Why Perl?

#117

Post by ccashell »

101000101 wrote: post #72

So if I compile a busybox-like crunched binary with a variety of "do one thing well" UNIX utilities, including sh itself, and then I write a shell function that only calls this single binary it its various incantations and uses pipes and temporary files residing on tmpfs or mfs (instead of reading entire files into memory the way perl does), and this binary used like this can do all that Perl can do, why should I use…

So, if I can build a wagon with a lawnmower engine from parts, and it is able to putter down the street (barely) faster than I can walk, why should I use a car?

That's my question.

I'm a sysadmin. I have been for years. My coworker calls me "the encyclopaedia of Linux", because I know all the command line tools, their functions and features, and how to tie them together. I write one-liners that are 5 lines long. And I like it. I love the Unix philosophy and design and tools.

But, that doesn't make it a perfect fit for anything. Shell scripts are very limited and painful for a lot of things. When I'm writing something I expect to be 50 lines or less, shell scripts and *nix utilities will usually (not always, but usually) get the job done (especially if you include sed/awk in there). For anything more than that, I break out Perl and I never regret it.

Complicated logic, non-trivial data structures, multiple chains of processing, these are things that just don't do well with shell scripts and tools. It's also a lot cleaner and simpler using a real data structure, instead of forcing everything into pipes and temporary files.

Note: Your comment of "instead of reading entire files into memory the way perl does" shows your ignorance. Perl is an immensely flexible tool, and it gives you the ability to process files line-by-line, stream-style, or by reading the entire file into memory. Both methods are trivial, and having the choice means you can use whichever method is appropriate for the task at hand (your comment suggests that reading the whole file is somehow "wrong", but for many tasks it's a faster and cleaner method).

Re: Why Perl?

#118

Post by ccashell »

101000101 wrote: post #88
chromatic wrote: post #85

Earlier quoted context omitted.

* [If] ... this binary used like this can do all that Perl can do...* If you can do that, great! Do it. That's a big job though, and it's not worth my time even to consider how much work it is. That's why I don't bother.

It's actually a very small job. The hard part I guess is learning to do things with the shell and UNIX utilities instead of Perl. And simplifying what you do and how you do it. If you choose to do complex things and do them in complex ways, or you can only see complex solutions where simple solutions exist, I guess a module-powered scripting language like Perl becomes irresistable and using the UNIX base utilities be…

> If you choose to do complex things and do them in complex ways, or you can only see complex solutions where simple solutions exist, I guess a module-powered scripting language like Perl becomes irresistable and using the UNIX base utilities becomes a prohibitively painful exercise.

Here again, your ignorance is showing, and you are projecting your own limitation onto others. You suggest that someone who uses Perl feels the need to use it everywhere, that it's more complex than shell tools, and that Perl somehow becomes a crack-like addiction, forcing you to never use command line tools again.

That's just plain silly. There are tons of people who make heavy use Unix tools and Perl. This isn't an either-or situation like you seem to be pushing. They're all just tools for solving problems. The smart thing is to recognize when each tool is appropriate, and then use them properly.

For example, the other day I was working with a log file. Initially, I was beating on it with command line tools: find, grep, cut, sed, sort, uniq, wc, etc. Eventually, I got what I needed out of it, but knew I was going to need something more to present to my team, so I pulled out awk, and I wrote a little script to extract the data and generate a simple report. A few days later, management saw the report, and liked it. But, they wanted some additional features added, and some changes to the processing. I could have hacked what they wanted into the awk script, but the processing had gotten complex enough that I knew I was better off making the jump to Perl. So, I rewrote it in Perl, and got everything they wanted. Additionally, it had the flexibility with Perl that the next two feature requests that management made were implemented in just a few minutes each.

Also, in case you weren't aware of it, Perl integrates and happily makes use of external commands. If there's a tool out there that will do some heavy lifting for you, Perl makes it trivial to call out to that command (just like backticks or $(/bin/foo) in bash).

If you really want to do complex scripting with Unix tools, then you're either limiting yourself to pretty trivial work, or you're making things a lot harder on yourself than they need to be. Perl was created for a reason, and it's a good one. Small scripts or glue to tie things together, use a shell script and Unix tools. Complex scripts, use a real scripting language, make things easier on yourself, and get more work done in a faster, better way.

Post reply on HN