Uses and Abuses of PERL

[enigmae]

Greetings,
In talking to other programmers out there, there seem to be two camps, people who use perl and those who don't. Everyone has reasons, but i just thought i would share my meditations on this matter.

I think most would agree that there are always those programmers who make languages do things that the inventor of the language never intended, and this applies to PERL and many other languages as well, but is this a good thing?
I have heard that good programmers are good programmers and the language doesn't matter, and i am sure everyone knows if they are reading the code of a good programmer, but in my experience this is subjective as well, because good can mean that the programs run efficiently and are small, or that they are well documented and are easy to understand but sometimes when PERL is used it is efficent but the syntax allows layzness, and disorganization.
What i want to ask is what makes good programmers good? Is it about documentation, efficency, organization, using OOP, the algorithm, or some mysterious aura of having a logical mind and a heart of silicon?
All too many times i have heard of programmers that didn't write the code having to manage 2000 lines PERL scripts that are cryptic and don't use strict or warnings, and almost always are surprised that the code even works.
Another part of me likes this feature of PERL in that it keeps out the Riff-Raff, simply because you are forcing the people after you to share your technical talents and engage you in the game of decrypting your code etc..., what are your thoughts on this type of Abuse or Use of PERL and do you think it is related to the programmer more then the language. I am sure that a crytic programmer can always find a way to write cryptic code. In c++ it could always be using the terenery operator over if/else, and this also ties into code obfuscation.
Well enough ranting and raving, just thought i would share my meditations even if they are disorganized mumblings. Enigmae

[valdez]

From a signature:

Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language.

From Larry Wall interview on slashdot:

1) I've been using perl for a very long time, but primarily as a scripting language. I indeed mostly use it for extraction and reporting. With the recent developments in perl, however, there seems to be the trend that perl is able to do much, much more (while retaining compatibility to be "just" a scripting language).

What do you think about how people are using Perl today? Are you satisfied that most people use it for simple tasks like log parsing? Would you like to see more advanced applications being built with Perl verses a compiled language?

A: I am perfectly happy for Perl to continue parsing logfiles. Perl has always been, and always will be (I hope), a humble language. When I am 80 years old, even if everyone in the whole world puts me on a pedestal and thinks I'm the renaissanciest man that ever lived, I still intend to take out the trash when my wife asks me to. Just because I'm learning Japanese doesn't mean I have to stop speaking English. (...)

6.5) What are your thoughts on the comments made by people that Perl is not designed for projects that require more than one programmer? Many people have stated over and over again that Perl code can not be managed by more than one person ... what are your thoughts on that statement? How would you manage a large Perl project? Do you think Perl should be used for large projects? (or should it be used strictly as a "quick and dirty" programming language?) BTW: I love your work (someone had to say it)

A: I do not manage any large projects, appearances to the contrary notwithstanding. I haven't an executive bone in my body. All my managerial skills are delegated. Ask anyone I've delegated to...

However, those who claim that Perl code cannot be managed by more than one person are obviously smoking something worse than crack. They're simply ignoring the many examples of people who have done just that. But you wouldn't expect to hire random people off the street to come in and collaborate on writing a novel. You can do it by hiring a few good novelists who already know how to figure out how to work together, or at least how to fight with each other productively. In the absence of that level of expertise, you can also do it by setting up policies under which random people can work, rather like the rules for writing about the world of Liavek, in which, for instance, every story has to mention a camel.

That being said, there are things we can do to make Perl 6 better at helping managers and architects set up such policies for programming in the large. Having a standardized opaque object type will help there as well. Nobody is going to claim that Perl 6's OO is "bolted on". Well, except maybe for certain Slashdotters who don't know the difference between rational discussion and cheerleading...

Ciao, Valerio

[Phemur]

I work with an awful lot of talented (and real crappy) programmers, and I've been observing them to try to learn what makes them so good (and so bad). I've come to the conclusion that there is no magic answer. It's a combination of things, and different programmers have different combinations. Here are three examples of gifted programmers, with very different skill sets.

Programmer A
This first programmer is only a few years out of school, but he's quickly become one of the company's top engineers (and we have about 800 of them). He has an incredible ability to research and learn (he's like a sponge), but what sets him apart is his creativity in applying what he's learned.

Programmer B
He's a more senior engineer. He's an "old-school" C programmer, and so his C++ code has a lot of globals and pointer arithmetic, but he doesn't make many mistakes (if any). In addition, he has a lot of vision and an uncanny ability to predict the future. His code reflects this, by leaving a lot of flexibility for future development.

Programmer C
In terms of experience, he sits somewhere between programmer A and B. His key to success is simplicity. He doesn't use fancy code or technologies to get work done. He relies on tools he knows well, always picks the right tool for the right job, and makes sure his code is as simple as possible. It may not be flexible or fancy, but it's so easy to read that anyone can understand it. It's quickly modified, and there are rarely any bugs in the code.

Each of these programmers has his own strengths, and I could go on for a while about what makes them so good.

Documentation, efficiency, and all of the other traits you mentioned are all good qualities for a programmer to have, but in the end, knowledge, and the ability to apply it, is what sets them apart. You can be the most organized, efficient, creative person on the planet, but if you don't know the tools and technologies you're using, and you don't know what problem you're trying to solve, your code will be crap.

Read, learn, apply. Often. That's the key to becoming a wicked engineer (IMHO).

Phemur

[BUU]

Perl. Not PERL.
That is all.

(cowers from the wave of downvotes)

[LD2]

heh. Ironic I was going to post something similar.. especially considering the title of the node.. Uses and Abuses of PERL - one is abusing it right now by the grammer/capitalization of it. But, it's hard to be flamish about this issue - due to so many others who make the same mistake on the Web today. I don't mean those seeking Perl answers - but actual articles written by people for informative websites or whatnot. It's crazy how many capitalize it - I'm assuming they do it due to it being an acronym. An interesting node to view - PERL should change it's name.

Update: Alright.. not an acronym..so don't capitalize it ;)

[kelan]

Actually, it's not an acronym. See the answer in the FAQ (especially the last sentence).

kelan

---

Yak it up with Fullscreen ChatterBox