Slashdot Mirror
23 Years of Culture Hacking With Perl
Modern Perl writes "Larry Wall, the creator of Perl, reflects on Perl's history of hacking its culture, from subverting the reductionist culture of Unix to reinventing the ideas of programming language and culture in Perl 6 and the verbal aikido used to encourage honest detractors to become valuable contributors. Perl turned 23 years old last week, and Perl 6 is available."
The only requirement is that you know how to be nice to all kinds of people (and butterflies)
Reading the Perl 6 page - either they are REAL programmers, or they use emacs.
(Hiring ~4 OO software engineers to do Perl. Forgive the inane outsourced hiring-management site. Merry Christmas.)
The World Wide Web is dying. Soon, we shall have only the Internet.
The only language that looks the same before and after RSA encryption.
I use perl on occasion, I prefer it over php, python, ruby, whatever the language of the day is. But perl 6? Should have called it perl vista. Cleaning up some of the cruft and inconsistencies in perl was a good idea. It has 23 years of features added on. Instead, they managed to make it worse. Good job, guys.
The thing that kills me about the Perl culture is that the delusions of what things mean to the non-Perl world.
This article is yet another example of that. Larry writes about Camelia representing so many points, which sound fantastic but are complete bollocks. Perl6.org, and specifically Camelia, do not say "fun", or anything about sterile environments or anything about clarity.
What it says is that in 23 years, the old Perl guard still hasn't figured out that making something that looks completely stupid makes people think you are completely stupid.
Everything looks completely stupid that comes out of Perl6.
Nobody really even knows what Perl6 is (even O'Reilly) and then randomly people point out Rakudo Star. This looks like the community is fractured (which it isn't, but it looks that way at a glance, which is all people are getting.)
I'm saying all this as a Perl hacker. I do love Perl, I think it's great, but all of this is basically turning Perl into something like Furries. The people involved seem to not think there is anything wrong, but every other person in the world makes faces at them.
I can't imagine being involved in that good thing Scala really is all those things Larry wishes Camelia represents.
I suppose I learned a lot about the Perl community though.
My recent experience is that discussions of Perl quickly turn to discussions of Python, after people make statements like, "If it weren't for CPAN, Perl would be dead."
"There's more than one way to do it." translates to, quoting from Wikipedia, "This makes it easy to write extremely messy programs..."
This is a quote from the Moose page to which you linked: "The main goal of Moose is to make Perl 5 Object Oriented programming easier, more consistent and less tedious. With Moose you can to think more about what you want to do and less about the mechanics of OOP."
The implication is that, without Moose, Perl 5 is difficult, inconsistent, and tedious.
Is this mistake, "... you can to think more...", indicative of the quality control for Moose?
That /. is written in Perl.
you had me at #!
Perl is still alive and well on BSD systems :-)
That inference may go too far. Perl 5's default OO is flexible and powerful, but it goes too far in allowing flexibility and it doesn't promote an obvious best way for most projects. As with any abstraction which offers and takes advantage of defaults, Moose reduces complexity and makes it easier to write consistent and concise code.
I'm certain many CPAN contributors will welcome an automated testing system to find non-spelling documentation typos. That'll be a very nice addition to the extensive test suites for Moose and other important CPAN distributions.
Thanks for reporting the typo, though. I'm fixing it in the repository right now.
how to invest, a novice's guide
My experience has been largely:
-if working on existing progress, continue in language it is already in
-if working on new project, what's the language most comfortable for the most developers available
Frequently, the answer continues to be perl, sometimes python, sometimes ruby. Usually, I can't be bothered to care. If it comes down to my call, currently I prefer:
-If planning to use across many OS updates, perl5. Nice and stagnant, not screwing around with how it does things, perl6 threatens this.
-If not expecting a lot of churn on the runtime but active development across random developers coming and going as available, python as it forces readability.
-If expected to work in a barebones as possible generic windows, vbscript, but please no.
-If wanting to work with as few prereqs as possible on Windows server 2008r2/7, then powershell.
-Have gone along with ruby, but have not personally found the magic situation I personally prefer it for above all other possibilities.
XML is like violence. If it doesn't solve the problem, use more.
A little unfair.
Without using a framework like Moose (or Mouse even), Perl OO is less consistent (TMTOWTDI) and a bit harder. Moose automates and simplifies things like class accessors etc. so one could say Perl OO is also (potentially) more tedious without it.
Just noticing that perl is half my age. I imagine some perl hackers may be younger than perl.
What I appreciate most about Perl and C is the stability and culture. It is not just a hype which _might_ be around in 10 years. It is one of the languages, which will persist, it is a language I can rely on, just because experience has shown me that. In a rapidly evolving time, it is good to have some things which persist.
My recent experience is that discussions of Perl quickly turn to discussions of Python, after people make statements like, "If it weren't for CPAN, Perl would be dead."
That's not too far from the truth, if you understand that statement to be analogous to "If it weren't for the US dollar, the American economy would be dead." It may only be one thing, but it's a pretty big thing.
"There's more than one way to do it." translates to, quoting from Wikipedia, "This makes it easy to write extremely messy programs..."
No grasshopper, you fundamentally misunderstand the implications of that statement. Show me a problem in which there isn't more than one way to do it, and I'll show you a problem you haven't grokked properly yet. Perl is a language without ideology. If programming languages were religions, perl would be closer to atheism (sorry Larry) than to anything else. Yes, it sometimes does cast people adrift because they're forced to accept that there is no final arbiter, that sometimes choices do come down to indulging one's biases. The difference here is that we recognise that, and that you have no one to blame for the biases except yourself.
For a good programmer, this is one of the paths to enlightenment.
To abuse the ideology metaphor a little further, perl is democratic (and borderline anarchic) because it does not criminalise stupidity. Likewise, it doesn't always protect you from yourself. If you really want to do things a certain way, the language probably won't stop you, and might even help you.
And if you still don't get the freedom that perl provides, feel free to vacate the green space in front of my domicile. I'm not going to force you off, but I might laugh at you if you stay.
Crumb's Corollary: Never bring a knife to a bun fight.
So I looked at the Perl5To6 Manual, and it gave me a headache. Really, I had to get some medicine just now. There used to be 10 ways to do anything in Perl 5, and in Perl 6 there's 20. And operators are approaching APL in obscureness and number. It has ways of being even more terse at the expense of the maintainer's head possibly exploding. Some changes are very nice and clean up some weirdness, but they compensated for it with a vengeance.
There's macros, and more contexts (where function returns different things depending on how its value is getting used), and meta-operators, and operator overloading on never-before-seen scale, and weird variant types, and ways to embed an enum into any object, even more complicated regular expressions, and so on ...
!#//bin/local/perl
Perl 6 spec is still in development, not done yet. Rakudo is an implementation of something that is not done yet, and pugs even less so. Anyone who uses this for any remotely production related is insane. Face it folks, Larry killed Perl.
I think Ruby beats Python in features only in rare cornercases, which aren't that hard to do Python either. When you already know Python there's not much motivation to learn Ruby. They're too similar.
Go ahead and whine all you want. We'll be right over here using the language you pretend doesn't exist.
!#//bin/local/perl
Unless I missed the funny part of your message, that line is actually interpreted by the shell.
Slashdot, fix the reply notifications... You won't get away with it...
If you don't know what perl golf is, time to treat yourself to some mind blowing perl. Perl golf is a challenge to complete a give set of algorithms in the fewest (key) strokes. Consider the Buroughs Wheeler algorithm, which is what bzip uses. How many keystrokes should that take to write? how about 55?
http://perlgolf.sourceforge.net/cgi-bin/PGAS/post_mortem.cgi?id=11
Mind blowing. Also informative as well.
I love perl. It has it's problems but I love how it's such a mutable language and how simple the core language is. It has one of the thinnest O-reily guides for a language that has Regex, Databases, and hashes built into it.
I never actually understood how objects actually work or the difference between a column and row database stucturce till I wrote in perl objects. The mind blowing thing to me is that to go from non-onject oriented perl to objected oriented perl, only two changes were made to the language: bless() and @ISA. it's uncanny that that's actually true for all languages. add those and your object oriented. This means for example, that you can start tommorrow writing object oriented fortran 77 just by implementing those two functions. If you don't believe me then you are like I was: you don't understand how object oriented programming actually works. And For those of you wondering: a row data base is the same as a perl object based on a blessed hash (how python does it behind the scenes) and a column database is a perl object based on a blessed scalar.
Some drink at the fountain of knowledge. Others just gargle.
Perl 6 spec is still in development, not done yet. Rakudo is an implementation of something that is not done yet, and pugs even less so. Anyone who uses this for any remotely production related is insane. Face it folks, Larry killed Perl.
I usually do not use the very latest version of anything on a critical project. The only reason to do this is if the new version has a feature you absolutely cannot do without. Even then, you should be aware that you're taking a big risk. I'd wait for it to age a bit, and maybe use the last known stable version, while other people try out the new stuff. That being said, I find your comment to be a bit on the panicky side. It's a bit early for an obit on Perl.
Great men are almost always bad men--Lord Acton's Corollary
You could say that about any language. Seriously, who would use Java if it didn't have a huge wealth of useful libraries like apache commons?
In some circles. I *like* Perl. I work non-coding with experienced C/C++/Javascript/OoP developers. These are desktop/UI programmers mainly with some server side. They use and expect fluency in Python, which I don't know much. Perl OTOH I know quite well. The head programmer knows no Perl. Mentioning that I like and know Perl is like ... well it's just totally irrelevant. Those on the team that know Perl keep quiet about it. Perl seems to be politically incorrect and by default and without trial held to be wrong for it "unreadability". Besides it's not Python is it.
Dumbass.
Ruby has all the mindshare these days.
I think I've heard of Ruby. Wasn't that popular around 2005?
Seriously, all the mindshare? Really?
This is my experience as well. However, in my case the definition of project is a bit loose:
- Someone wrote a script in perl and left the company.
- Someone else needs to make Improvements to this code but they dont know perl. Even though the original code is written in as clear and readable perl as possible, they automatically think perl is hard. This is in fact company policy now. They write a python script and make a system call to it from the perl code. Soon there are two, three... seven python calls in the perl code.
- Someone now wants to break the perl code up, so now there are python calls in the perl code and perl calls in the python code.
- Someone wraps this up in a shell script.
- Someone else learnt bash and not sh so they make bash calls in this code and it no longer works on non linux architectures.
- Someone who knew the original developer calls him and they enjoy a wry laugh.
Even putting aside 'legacy' interop, I see people writing perl call sed via backticks to do some substitution or similar thing, seemingly forgetting they are already in a rich language and that backticks are relatively expensive.
Also, ditto on the perl readability. While it's possible to write hard to read code, it's also possible to write perl code as readable as any other language. It's just harder in python to write hard to read code (though not impossible).
Tips for perl programmer sanity:
-Avoid the use of $_ in most cases. You can spare the keystrokes for the sake of readability, there is a high chance at some point your loop will get nested/long and $_ becomes hard to follow. Similarly, get captured variables into recognizably named variables ASAP.
-Be consistent about code indentations and be generous with line breaks.
-If your sub is going to take more than one argument, use named arguments as the means to interface.
-Beware of some perl conveniences like 'map'. I generally avoid it in favor of more generally understood loops, though I think map would be an interesting operation for automatic parallelization. If the latter is possible or map is otherwise more efficient, then comment those with how it would look as a loop.
No one will read, but I thought I'd toss that in.
The language that was better than awk+shell. Didn't have much more going for it than that.
TMTOWTDI is a big problem for perl. And I'll explain why.
1) Any problem of much sophistication has more than one way to solve it, in terms of algorithm. These differences are essential, and worthwhile. Then there are the differences introduced by perl, just because the designers had a "sure, if you want" attitude to almost everything. These differences are a pointless way of adding complication for complication's sake.
2) Perl is like 10 languages rolled up into one (as a direct consequence of TMTOWTDI). When you write perl, you can use any of the 10, and you'll be fine. But if you're working on code that's had more than one contributor, you're going to get a mishmash of the 10 that require you to learn and relearn the same things, pointlessly.
It also seems to make people load frameworks rather than learn the language. I've fixed a few libraries I found that were using Moose by removing the framework and replacing it with 30 lines of OO code. They loaded another 35 files just to avoid a couple ISA statements and do some input validation. If people bothered to learn the language they could make their code even faster and cleaner. This problem is even worse in PHP. And java seems to require every project to write their own. :/
Midget Tosser
oh, it exists all right. But unusable for serious work, no one is going to hire me to develop in Perl 6.
Not whining, I've done plenty of Perl 5 development over the last 20 years. Sorry to see Larry try to turn Perl 6 into mutant Swiss Army Knife with fold-out condom and umbrella and eggbeater and cuckcoo clock.
the guts of a thousand whales fed through a wood chipper....
Well i think you are absolutely right. But my friend be calm down. Don't take it much serious. Be coooolllll.