Just before Christmas I was working late on one of the few excuses I have for using Perl in a project-related capacity, when I noticed something about the way I write Perl, and how it differs from how I write other languages.

I was hacking away at what was once a a simplistic, quick-and-dirty text munger but which has, over the months, got completely out of hand and turned into an gargantuan online documentation and batch file generator with a distinct hint of the diabolic in the depths of its code. It is, in short, a crawling horror.

This fact doesn't bother me much; in about a fortnight it will become unnecessary and be retired to a dark corner of the development server, where it can devise its foul machinations in peace.

The bolt from the blue, however, was realising just how different its evolution had been from practically every other program I've written. I've had a fairly conventional training in classical software design and usually when I start a project it seems perfectly natural to go through an analysis, design, prototype, analysis, re-design, code, test, maintain cycle. So natural, in fact, that I don't even have to think about it. With Perl, though, it's always been different.

Looking at the contents of my hard drive, there are three different methods represented. Firstly, the quick-and-dirty one-liners and almost-one-liners that I write half-a-dozen of every day, use once and then append to 1linegraveyard.txt in case I ever need them again. The second kind are the quick-and-dirty one-liners that grew while I wasn't looking, like the above example.

The final variety, the kind that interest me most of all, came about as a result of knowing that I was going to want to use the thing more than once. But instead of analysing the problem, as I would do prior to cutting even a single line of code in another language, I've always got straight down to the prototyping stage, improving my understanding of the problem seemingly with nothing more than an intuitive feeling for what the answer might look like, then refining it into its final form.

Once I actually realised what I was doing, I paid attention to it. I sometimes get through three or four generations of prototypes in a day. The nice thing is, this way is a lot more enjoyable (what would you rather do? twiddle with diagrams or write code?) and doesn't seem to result in worse code, and thanks to pod it's a lot better documented than most of the stuff I do.

The question is (yes, I have got a point to make here), why does this way of working seem natural in Perl, yet unnatural in any other language? I tried it with a small Visual Basic app I had to write and came unstuck in no time at all.

Has anyone else had a similar experience? Is it just that Perl is a good fit with hackerly intuition? Do most people here stick by the traditional methods, or is a more flexible (ad-hoc?), go-with-what-works approach more popular?

-- 
Tom Waddington

Replies are listed 'Best First'.
(jeffa) Re: How formal are Iyour/I methods?
by jeffa (Bishop) on Feb 07, 2001 at 02:34 UTC
    Sounds like you have been practicing improvisation. :)

    Check out explorations of consciousness and symbolic references... for some more meditations on strict structure versus loose interpretation.

    But to answer the question of while Perl seems to lend itself to this style of controlled 'hacking' - I think that has to with the fact that Perl was written by programmers FOR programmers.

    Jeff

    HMWDYWTDIT
    "How Many Ways Do You Want To Do It Today?"

[reply]
Re: How formal are Iyour/I methods?
by McD (Chaplain) on Feb 07, 2001 at 03:09 UTC
    The question is (yes, I have got a point to make here), why does this way of working seem natural in Perl, yet unnatural in any other language?

    I think the reason I find myself falling into the same patterns is that Perl is often such a natural fit to the problem set. In particular, scalars, arrays, and hashes all map very naturally to a great many data processing tasks, so when I visualize the soloution, I'm already very close to Perl code.

    Combine that with the rapid code-test-lather-rinse-repeat cycle afforded by an interpretive language, the wealth of shortcuts available to the fluent, and the shoulders of the CPAN giants to stand on, and the temptation to just go DO it is overwhelming.

    Incidentally, I love the "1linegraveyard.txt" file idea.

    Peace,
    -McD

[reply]
(jcwren) Re: How formal are Iyour/I methods?
by jcwren (Prior) on Feb 07, 2001 at 02:53 UTC

    I've been writing code for many years, in more programming langauges than comfortably fit on a resume.

    In my opinion, it's a function of how comfortable you are with a langauge. I just about always write middle-out, be it in Perl, forth, assembly, C, FORTRAN, whatever.

    I think it's more a matter of how you approach problem solving, and how you use a language is influenced by your approach.

    --Chris

    e-mail jcwren
[reply]
Lack of dress code in Perl
by gryng (Hermit) on Feb 07, 2001 at 03:41 UTC
    Perl encourages this style because there is little cost to changing your mind. In other languages you must decide what you want beforehand, because it costs alot just to move a few code segments around or change the return result's type -- let alone change the fundamental flow or structure of the whole program.

    As an additional note, Perl comes out quickly from the keyboard to the computer -- quick enough that you can even have time to do a complete rewrite when the first becomes your colliquial 'crawling horror' (nice :) ).

    Of course, this doesn't make other languages bad, it just makes Perl easy :) .

    Ciao,
    Gryn

    p.s. I think it should be mentioned that this feature of Perl is best used with a little bit of conciousness. It is too easy to program badly even without Perl to help you :) .

[reply]
Re: How formal are Iyour/I methods?
by mikfire (Deacon) on Feb 07, 2001 at 02:54 UTC
    Without going way over the top, of all the languages I have used, Perl allows the Tao to flow most freely within me. What you have noticed I would call a manifestation of the Tao.

    mikfire

[reply]

      I bought the Tao Of Programming book when it first came out (and thanks, mikfire, for pointing out an online copy. Mine is buried in the warehouse somewhere), and one of my favorite quotes is this:

      A master was explaining the nature of Tao of to one of his novices. ``The Tao is embodied in all software - regardless of how insignificant,'' said the master.

      ``Is the Tao in a hand-held calculator?'' asked the novice.

      ``It is,'' came the reply.

      ``Is the Tao in a video game?'' continued the novice.

      ``It is even in a video game,'' said the master.

      ``And is the Tao in the DOS for a personal computer?''

      The master coughed and shifted his position slightly. ``The lesson is over for today,'' he said.

      --Chris

      e-mail jcwren
[reply]
      Reading your Tao link - Awesome!!!
      _______________________________________________
      "Intelligence is a tool used achieve goals, however goals are not always chosen wisely..."
[reply]
Re: How formal are Iyour/I methods?
by clemburg (Curate) on Feb 07, 2001 at 13:55 UTC

    Has anyone else had a similar experience? Is it just that Perl is a good fit with hackerly intuition? Do most people here stick by the traditional methods, or is a more flexible (ad-hoc?), go-with-what-works approach more popular?

    IMHO, it all depends on the complexity of the problem vs. your solving ability for this problem (knowledge of similar solutions, the programming language's library, knowledge of general problem solving methods, creative fits, ...).

    The ratio (well, why not a ratio) of these two factors is what I would call the "perceived complexity" of a problem. This is what determines the approach for me. If it is very high, I go and ask other people. If it is just high, I usually start to paint pictures of it, and unnerve other people by forcing the problem on them, allowing me to gain understanding by talking about it. If it is middle, I usually start some kind of prototyping operation. If it is low, I just write the program.

    In Perl, a lot of things are simpler because there are so many pre-solved problems. If you know Perl (and its module library) well, you know very many solutions to very many problems. This is not true to this degree for any other language I know of.

    Doing really conceptual thinking in Perl is sometimes hard for me, because the syntax interferes too much with the thinking. I really like programming in Scheme for those purely conceptual things.

    Christian Lemburg
    Brainbench MVP for Perl
    http://www.brainbench.com

[reply]
Re: How formal are Iyour/I methods?
by mothra (Hermit) on Feb 07, 2001 at 04:43 UTC
    Unfortunately, I don't have the luxury of working in Perl at my day job, but I still think I can offer my perspective on this Meditation. :)

    I'm one of the people that writes the applications (end-user) that automate the criminal justice system. My approach to solving the task at hand depends on many factors including the complexity of the problem, likelihood of affecting other parts of the program, and how fast it needs to be done.

    If it's fairly simplistic, I won't waste any time trying to figure out the algorithm in my head before starting to hack out the code. I'll just let the solution come to me as I write it.

    But I do often try to think out the problem beforehand. I jot things down on a notepad. Normally at the top of the page is "Problem: <description>", to remind me not to get to lost in the details and remember what I'm trying to solve. Then I write down the "Solution: <description>" detailing (well, ok, generalizing) the steps that need to be taken to solve the problem. For example, yesterday I worked on a problem where the solution was:

    • Build the linked list
    • Populate the linked list
    • Colour in the calendar control with the results

    If I'm at the point where I can generalize the steps that need to be taken to solve the problem, that's when I write my best code (that which fits well with the rest of the app).

[reply]
Re: How formal are Iyour/I methods?
by ColonelPanic (Friar) on Feb 07, 2001 at 04:56 UTC
    I find that I code that way on any small job (about 200 lines or less, I would say), regardless of the language. The difference is, in Perl almost everything is a small job.

    When's the last time you used duct tape on a duct? --Larry Wall
[reply]
Re: How formal are Iyour/I methods?
by readey (Sexton) on Feb 08, 2001 at 19:51 UTC
    Funny how Perl seems to make you want to stay up late at night eh?
[reply]

Back to Meditations