Perl irks me. I enjoy programming Perl immensely, but there is one niggling little thing that worries away at my peace of mind while I am programming in it.

"Have I got it right?". All the while I'm coding I'm asking myself this question, and I'm not getting the answer I want to hear. My programs work, sometimes even for more than a few seconds (grin). But I'm constantly wondering, "How can I make it better?". Should I have used an array instead of a hash? Was storing my variables in a separate namespace better than creating an object to manage them? On and on and on. I barely have enough attention to program, what with thinking about the stuff I have already programmed.

This contrasts with my work in more established languages like C where I know that there is no way I could be doing it better. Partially because in C there is a sort of recipe list. A lot of problems have well known "best ways to do it" answers that are known to the community. When I sit back and look at a C program I wrote, I get a feeling of satisfaction and completeness. I run the program and mentally I go "Yes!".

But in Perl, there are so many ways to do it and they all change depending on so many different aspects of your program, the data structures you choose, the user interface you are using, the storage methods available. I don't get a feeling of satisfaction when I've finished a program. I sit in front of my screen, turning bits of the code around in my mind, because I'm not sure I've done it the best way. Even when it's finished, it's still not done.

I enjoy all the Perl code I write (except maybe CGI thesedays), but I just wish I could get a feeling of satisfaction and that warm inner glow of a job that's done, well or not.

And that is why Perl irks me.

____________________
Jeremy
I didn't believe in evil until I dated it.

I think that hit the nail on the head. The more difficult a task is, the more satisfaction you get out of completing it. Perl, however, makes most tasks relatively easy. It's not hard to write in one day the Perl equivalent to what might take a C programmer a week. The end result is that sometimes it seems too easy, particularly if you have a lot of experience in a language like C.

At some point you just have to accept your solution no matter how little effort it took. If it passes your test cases and runs within an acceptable amount of time, you can probably let it stand. One idea would be to focus that leftover energy on, for example, writing better documentation or improving your installation package.

You might still be able to get that feeling of satisfaction from completing the project instead of just the program.

Trouble is, my projects are never completed. There's always one more thing to do...

Your point about documentation and packaging is good though. I am getting into doing good doco for my proggies, and it does feel good to sit back and look at a good page of documentation. Still, I have to write code to document, and then I'm back to the same old situation. Not that I'm going to stop or anything :)

____________________
Jeremy
I didn't believe in evil until I dated it.

Still, I have to write code to document, and then I'm back to the same old situation.

Try writing the documentation first, then the code. Now, you're allowed to go back and change the documentation if you discover a better way of doing it while coding, but go change the doc as these cases are being discovered.

Then, you won't have the documentation hanging over you at the "end" of a project.

Better yet, stop thinking about projects having an "end". Most programs are changed over time. There are just relatively active periods of development followed by relatively inactive periods of development.

Note that the above is all speculative on my part as I, myself, usually put off documentation until after I'm "done" with coding. This is all just do what I say, not as I do... Better to be a hypocrite who proclaims the truth rather than a silent person who has nothing good to say, I guess. Maybe someday, I'll actually catch myself following my own good advice. :-)

How much experience do you have with C? My guess is that the difference you feel between the two languages has more to do with your level of familiarity than with anything inherent in the language itself.

Personally, I often experience the sensation you describe while programming in C. I'm always wondering if I'm managing my pointers correctly or if I'm opening up a huge memory leak. Every time I start getting into pointer arithmetic I have to haul out a notepad to get it straight.

But with Perl, my first move is often my last. It's not that there aren't other ways to do it but I know my ways and I know they work.

Bottom line: stick with it and pretty soon you'll be babbling fluently in a dialect of Perl all your own.

I have been writing C code lately for my two graduate
courses and the one thing i can say with certainty is that
C code in general takes more time to write and test than
Perl code that solves the same task (on average). When i sit
back and look at C code that i wrote, i get a feeling of
relief as well, but is more a feeling of relief that stems
from running the Boston Marathon. (Hehe, if you like that,
imagine how much satisfaction you could get from writing
assembly code!)

Personally, i really get more satisfaction from the fact
that i wrote a client/server pair tonight in Perl in the
time that it took my fellow students to write 1/10 of that
in C. Now, did i learn as much as they did? No. But that's
ok. I still have plenty of time to port my programs over to
C. The point is that you shouldn't blame a car for getting
you from point A to point Z in the time it would take for
you to walk to point B, you should be thankful for having
a car and a take a nice stroll when you need more
satisfaction.

jeffa

When I'm drivin' in my car
and that man comes on the radio
and he's tellin' me more and more
about some useless information
supposed to fire my imagination.
I can't get no, oh no no no.
Hey hey hey, that's what I say.

As it turns out, I love programming assembler. The sweet feel of optimising the code. Some of my earliest stuff was writing a polygon fill library in assembler so I could do three-d stuff (this was after I saw doom). It was fun, but I wouldn't do it again. Way too hard to maintain, and not cross platform enough.

I'm definately with you on the doing it easier bit. Perl was, as some have said, a breath of fresh air that revived my wilting enthusiasm for programming.

____________________
Jeremy
I didn't believe in evil until I dated it.

I'm sometimes a little set back by how much C I've forgotten since taking up perl a couple of years ago. I get over it by thinking of how much fun I'm having.

The big splashy palette of Ways to Do It does indeed give me the uneasy feeling that I'm missing something. I make a point of trying offbeat functions, tailoring data structures, and trying 'impossible' tasks, and that helps me keep learning.

One impossible thing I tried was a pure-perl user-space Linux device driver, talking directly to a kernel module through ioctl. Fun! Not terrifically successful, but it taught me pack and unpack - not to mention the exotic ioctl itself.

One thing I most appreciate about Perl is its similarity to C. It's not just the syntax, though that's important. but also the deep structure of its interaction with the OS. A system call does not return till it's done. The deferred operations like file write-behind behave the same as in C. The concept of sequence points, where side effects can be known to be complete, is similar, allowing reliable serialization. IPC, network applications, file locking, process forking and, increasingly, threading are all convenient and reliable. No other language I know matches the combination of depth, comfort, and effectiveness that Perl offers.

I think it's a great plus that you can do things in more than one way with perl. This feature of perl leaves a lot of creativity and flexibility to the programmer. I don't think any two programmers would approach a problem in exactly the same way and perl allows each to tackle the problem according to how he views it.

Additionally, the person doesn't have to know everything about perl to code a program to solve the task at hand. As Larry Wall puts it, "Have the appropriate amount of fun.". The fun I get from perl programming depends on how adept I'm at using it - and fun is relative. As long the task gets done, most of the times I'm satisfied. As we continue to expose ourselves to more perl programs, we'll eventually learn the finer art of perl programming.

I do not think the language makes a difference in this case except personally. I have asked these questions in some form or another with any language I have used. I am inclined to think that this is a good habit for learning purposes and I intend to continue. But, for practical purposes, if it works and I am not currently trying to improve it then I try my best to be content with it. Of course this is easier said than done. ;-)

This contrasts with my work in more established languages like C where I know that there is no way I could be doing it better.

Are you certain that there is no better way to do it in C? Maybe there's just no better way that's easy. For instance, in C you have to make the decision whether to use an array or a hash table, just like you do in Perl. Using an array is easy in C, because they're built into the language. Using a hash table is hard, because you have to either write all the hash table code yourself, or find someone else's code and figure out how to use it.

Sometimes, using a hash table is the better solution. They're extremely useful in many situations, so it seems that a language should make it easy to use them. And Perl, as we all know, makes easy things easy.

I sit in front of my screen, turning bits of the code around in my mind, because I'm not sure I've done it the best way. Even when it's finished, it's still not done.

Well now are we talking about writing code like monkeys. Which language do i like to speak.
I rather think in terms of design. What is the best solution for that project. Don't want to jump in and drown...
Language is just the tool to do something done, the satisfaction comes from the problem i solved...

I must agree that Perl is fun, but hardly satisfying. The Perl I write is used to assist me in managing a WAN that hosts a number of Data Warehouses. I can add users, groups, audit file permissions, web logs, event logs, search newsgroups, and filter my email all with perl. My sense of satisfaction comes from writing a program that does yet another of my many repetitive tasks. I code, run, occasionally refactor after reading a Perlmonks post that shows me "yet another way to do it", and derive my satisfaction from knowing that I'm getting lazier and lazier every day. My code is full of commented out lines that bear testimony to having found a better way, (or just sometimes a way that works), and I find that less than satisfying. I want to clean it up, but maybe I'll have to write "yet another program" to do just that.Now that is satisfying.

"Have I got it right?". All the while I'm coding I'm asking myself this question, and I'm not getting the answer I want to hear. My programs work, sometimes even for more than a few seconds (grin). But I'm constantly wondering, "How can I make it better?". Should I have used an array instead of a hash? Was storing my variables in a separate namespace better than creating an object to manage them? On and on and on.

To some degree, these types of design issues are independent of the programming language. Maybe reading some general OOP or data structures texts would be helpful. (Regarding data structures: Mastering Algorithms with Perl has lots of good info about using data stuctures in Perl effectively.)

But in Perl, there are so many ways to do it and they all change depending on so many different aspects of your program, the data structures you choose, the user interface you are using, the storage methods available. I don't get a feeling of satisfaction when I've finished a program. I sit in front of my screen, turning bits of the code around in my mind, because I'm not sure I've done it the best way. Even when it's finished, it's still not done.

Learning the Perl idioms and the tradeoffs among the WTDI should help resolve some of those nagging doubts. I would highly recommend The Perl Cookbook and Effective Perl Programming. A careful study of these books (not just cut-n-pasting :-) will give you a great feel for what good advanced perl looks like and why.

I do not know how many times I felt elated after coding a
solution to a problem for the first time, especially if I
had to work hard at it or had many failed attempts.
I can tell that, how many ever times it was, every single
time I felt that a better solution existed a while later.

For me, the satisfaction comes in figuring out a solution
and not in the end result. I need to make a conscious decision
to either pursue those solutions or not. Will the thrill of
the hunt be as exciting? Will I run into more or less tangent
problems? There are many more factors that influence that decision than
the ones I listed, but ultimately, I need to assess for myself
if it is worth the effort.

You sound to be a purist like me. I want everything to boil
down to its core with all pollutants gone. I do not know if this
will help you, but here are some things I do to add to the satisfaction
of my programming (Perl or otherwise). How long before it is completed, how efficient should it be, how much
functionality should it have? I ask those questions and give realistic answers, then I raise the bar - just a little.

I'll write a program and it works, but parts of it are inelegent or slow or whatever. So I tweak it around, get stuff to work better or look better, or just give it better hack value. I play around with it until the thing is a work of art.

Now, if I need to quickly write something that works, I can. And yes, parts of it will suck. But as soon as I have some time to play around with it I get to tinker to my heart's content. That's the beauty, in my opinion, of Perl: TMTOWTDI covers not only the idea that there's more than one valid way to recurse through an array, but also that it's okay to create quick fixes where necessary and to tinker endlessly where you want.

And it has to be said that once you've gotten a working model and the stress of "Deadline" has turned into the frustration of "Performance Testing", that is the time to tinker with minutiae. And when you are that point is when you post a really cool SoPW and take advantage of the wisdom of the same community that gave you Perl in the first place. After all, it's great that Perl is fast and fun and powerful, but perhaps its biggest strength is the huge open source community tickled pink to give you scalar(@members)+1 opinions on whether you've "got it right" and how you can make it better. Eventually you learn to recognize all those patterns yourself and you get that feeling of satisfaction you mentioned.

Then you think of a way you can tweak your program some more, and the hacking and tinkering continues. Maybe I'm unusual in liking the idea that even though something's "finished" in the sense that it has all the features in the spec plus it reads email and the speed of the program is 10 or 20% above the projected "best case scenario", I can still work on it and improve it. Or just work on it.

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other