Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Revisiting the old clichés of programming languages

by citromatik (Curate)
on Jan 26, 2009 at 14:43 UTC ( [id://738946]=perlmeditation: print w/replies, xml ) Need Help??

Hi all,

In a recent post to an OCaml mailing list, someone asked why Perl performed better than OCaml in a specific text oriented task. To my surprise, in his answer, an OCaml guru defined Perl as a "domain specific language for string munging".

It is surprising how this old fashioned cliché remains alive as time goes along.

If you think about it, there are plenty of similar concepts enveloping programming languages. For example, the Perl's motto "there is more than one way to do it (TIMTOWDI©)" is a fantastic marketing phrase that, indeed, can be applied to almost any modern high level programming language.

Here are some other clichés, please, help me to find which one are valid, old-fashioned or simply fallacies:

  • Java:
    • Java is the paradigm of portability. Are Java programs more portable than Perl, Python or Ruby ones? Even my OCaml programs can be compiled in Windows, Unix and MacOSX without changes.
    • Java is ineficient and produces memory leaks: Is this real? I have heard of (very) long running programs written in Java that exhaust the RAM memory. BTW, many others programming languages (including Perl), produces memory leaks in some circumstances, specially when dealing with circular data structures. Probably this can be applied to almost all programming languages with garbage collection, am I wrong?
  • OCaml
    • OCaml code runs nearly as fast as C code: Well, my experience is that, most of the times, only OCaml programs written with an imperative style can run that fast.
  • Perl:
    • Perl is slow:Well, it is interpreted, but, in my own experience, I found that it runs extremely fast doing some tasks (simple example, although I haven't compared the execution time with others programming languages).
    • Perl is prone to obfuscation: There is too much to argue here, maybe it is a matter of taste. In my opinion, you can write pretty obfuscated or very readable code in Perl.
  • Haskell:
  • PHP:
    • PHP is for web development: Well, it was originally designed for web development, but I have seen full applications (not web related) written in PHP.

Any additions, corrections and comments are welcome

citromatik

Replies are listed 'Best First'.
Re: Revisiting the old clichés of programming languages
by Jenda (Abbot) on Jan 26, 2009 at 16:20 UTC

    TIMTOWTDI is not (just a) marketing phrase. It's a design principle. And while almost any modern high level programming language happens to give you more than one way to do something, it's not always intentional nor appreciated. Some language designers believe rather in "the one true way" and some language designers strive for a minimal design. Which goes directly against Perl's TIMTOWTDIness and its love for shortcuts. It's not necessarily a bad thing, it's just different.

Re: Revisiting the old clichés of programming languages
by JavaFan (Canon) on Jan 26, 2009 at 16:06 UTC
    Perl is slow:Well, it is interpreted
    Well, Perl is slow compared to languages like C, but the impact its "interpretedness" has isn't great. (For the record, Perl isn't interpreted. When you run a Perl program, it first gets compiled into bytecode. Then the bytecode gets run). Even if you was a compiler that turned Perl code into a native binary, Perl would still be slow. The slowness is the price you have to pay for the flexibility you get.

    For instance, from a programmers point of view, a scalar can hold a number or a string. That's convenient. But if you want to add two (integer) variables, in C you have the addresses of the variables, so it's just FETCH, FETCH, ADD. Not so in Perl. You first FETCH the meta data (SV), which is a struct. Then you test whether the variable holds an integer value (check a bit in one of the structs fields). If it has an integer value, do you a FETCH of that (add offset to pointer stored in the SV struct). If not, fetch the string value (follow two pointers from the SV), turn the string value into a pointer, store the integer value (which may require upgrading the PV hanging off the SV into an PVIV), and flip the bit in the SV. Repeat this for the other value. Then you add the two values, giving you a new value. Said new value need to be stored into an PV, which needs an SV as well, so you've two calls to malloc to get you memory for the structs. Which you have to fill in. Of course, this assumes no magic has been attached to the values. Which you have to check for.

    Compared to C, this makes Perl slow. Now, this is a price we all pay gladly; but that doesn't make Perl fast.

    Perl is prone to obfuscation:
    It's hard to create a useful language where it's hard to do obfuscation.
    PHP is for web development
    Many people consider Perl to be for web development as well. And it's hard to deny. The sharp increase of the usage of Perl in the mid nineties coincided with the general public discovering the "web".
    but I have seen full applications (not web related) written in PHP
    Well, people use regular expressions to find prime numbers, but that doesn't mean regular expressions are for numerical calculations.
      When you run a Perl program, it first gets compiled into bytecode.

      Calling Perl optrees "bytecode" stretches the definition of "bytecode". If it weren't for the separate passes between compilation and execution, Perl 5's model would be much closer to interpretation.

        Calling Perl optrees "bytecode" stretches the definition of "bytecode".
        Yet, it is what man perlhack say happens:
        The work of the interpreter has two main stages: compiling the code into the internal representation, or bytecode, and then executing it.
Re: Revisiting the old clichés of programming languages (natural languages)
by kyle (Abbot) on Jan 26, 2009 at 16:42 UTC

    There are similar things said about natural languages. German is good for engineering. Greek is good for philosophy. French is good for foreplay. If I knew any of those languages, I might not say that about them.

    As long as I'm musing on things of questionable relevance, I find a good interview question to be, "what kind of project would you rather write in this other language you know rather than in Perl?" Someone asked me that about Python, and I said, "I'd never write anything in Python over Perl because I know Perl so much better." The discussion in Don't Write That In Perl! is interesting along these lines.

      Were I an interviewer I would not like that answer. No matter how much better you know Perl, there are generic valid reasons to write in Python instead that you can give that interviewer:
      1. A personal project to help you learn Python, some Python library, etc. (Note, learning how a framework in another language does something is an excellent way to open your mind to new ways to do it in Perl.)
      2. An existing Python project has a lot of the functionality you need, and extending it looks easier than rewriting it.
      3. The team that will have to support and maintain it are Python developers rather than Perl developers.
      4. A client is willing to pay you to write in Python, and is willing to accept your reduced productivity.
      What you're trying to demonstrate with these answers are that you are open to working with others, fitting yourself to an organization's needs, and learning. The answer you gave instead could leave the impression that you have none of those traits.

      The only time I would want to leave an interviewer with those types of negative impressions of me is if working with a particular language was so distasteful that I really don't want a job where I have to do that. The only language that I feel that way about is VB. Certainly I don't feel that way about Python. Furthermore Python has some good features that I wish were in Perl. For instance Perl has nothing equivalent to Python's list comprehensions and generators.

        As it happens, most of what I know about Python comes from three out of four of the motivations you list. I wanted to add a feature to an existing (open source) Python project (maintained by Python programmers, natch), in part because I wanted to learn about the language. I also discussed that in the same interview, just not in answer to that question.

      "what kind of project would you rather write in this other language you know rather than in Perl?"
      I can think of the following reasons to not use Perl. All of them have been reasons for me in the past to not use Perl.
      • The environment it has to work on doesn't have the resources to have Perl. I've worked on Linux systems that only had 25 Mb of disk space, 8 Mb of RAM, and where installed from a single floppy disk. No way to cram Perl in there.
      • Speed or memory usage is an issue. In such cases, I use C.
      • There's a domain specific language much more suitable to solve the problem. SQL being an obvious example.
      • Lack of enough Perl knowledge (or willingness to use it) in the rest of the team.
      • Program needs to be distributed in an environment that may not have Perl. Hasn't been a reason for me in the last 10 years, but was before.
      • Low level enough that it's easier to do in C than it would be in Perl.
      Note that most of the reason have not much to do with the project itself, but more with the environment. But then, I've always said that most of the time you shouldn't pick a language based on the project you want to solve, but you should pick a language based on the people you want to do the project with.

      Didn't one of the Fredericks of Germany once say something to the effect of "I speak English to my wife, French to my ministers, Italian to my mistress, and German to my horse?"


      Information about American English usage here and here. Floating point issues? Please read this before posting. — emc

Re: Revisiting the old clichés of programming languages
by ELISHEVA (Prior) on Jan 27, 2009 at 05:47 UTC
    I've been working in Perl recently precisely because of its maintainability. It seems to me that the culture surrounding a language is as important, maybe more important, than the language itself.

    To write good maintainable code requires repeated reflection on the structure of the code you are writing, appropriateness of testing apparatus, the possible maintenance issues, not to mention long term readability. All of these things go well beyond the rules of thumb so popular with programming pundits (e.g. rules like "NO function should be more than X lines; NEVER use language feature foo, etc).

    In short they require judgment. What the perl community and especially PerlMonks excels at is helping people develop good programming judgment. Testing isn't just a nice to do - it is symbolically and practically raised to a cultural icon via CPAN testers and rich support for testing modules (over 300 testing distributions at my last count).

    Or take the idea of rewarding people for voting or simply having logged into a Meditations or Monastery Gate page in the last 24 hours. That encourages people to read and reflect on each others words.

    I love Java, C/C++, Lisp, even the uglies DOS, Bash, Awk, Sed, and the pedagogues - Pascal - and the cute - Tcl and the crass - PHP, VB. But of all these langauges, the only one I see with such a rich culture of learning is Perl.

    Best, beth
Re: Revisiting the old clichés of programming languages
by marto (Cardinal) on Jan 26, 2009 at 15:42 UTC

    "Perl is prone to obfuscation: There is too much to argue here, maybe it is a matter of taste. In my opinion, you can write pretty obfuscated or very readable code in Perl."

    The easier something is to use, the easier it is for people to abuse :P

    On a serious note, I hear that from time to time when speaking to php/.net programmers. My usual argument to this point is that individuals can write ugly code in most languages, but to me that says more about the individual than the language. Your code is well document and commented right? :P

    IMHO this Perl myth is covered particularly well in Perl Best Practices.

    Cheers,

    Martin

      The easier something is to use, the easier it is for people to abuse :P

      Could this be why PHP has such a bad wrap? The plethora of pompous PHP pupils perfect the pestiferous pinhead pattern pronounced prevalently perceived by prime programmers (primarily at PerlMonks).

      I am not really sure where I was going with this post <.<

      And you didn't even know bears could type.

        Yes and no. The badness of PHP wasn't limited to the code of some individuals. There are serious problems with PHP itself. For example, there were no local variables until recently. See http://www.tnx.nl/php.html for more.

Re: Revisiting the old clichés of programming languages
by sundialsvc4 (Abbot) on Jan 26, 2009 at 17:41 UTC

    Personally, I conclude that “clichés are just that ... clichés.” They're vast oversimplifications, good for baiting the occasional “troll” but frankly not worth the time of day. (C'mon, how many times has any statement featuring the word “all,” really turned out to be worthwhile?)

    We are lucky to be a part of a hair-pulling profession that changes sometimes by the month. Technologies that spring to life with much fanfare (and many O'Reilly books...) are sometimes “dead” within a year.

    (Of course, those “dead” artifacts are now in production and will have to be maintained ... forever.)

    I do believe, therefore, that it is very significant that “Perl is still here.” Since we typically don't have a huge marketing-engine selling “a piping hot cup of Perl”   :-D   to the bigwigs in the ivory tower, this demand must be coming from the field, where “the soldiers themselves” are fighting the battles, and, to the extent that they can, are choosing their weapons. It must be they, and their field-commanders, who are choosing Perl ... and who keep choosing it.

    I think that distinction is hugely important. “Don't watch what people say. Watch what they do.” If you observe any tool that has been in-use for more than ten years, and that still attracts the attention and dedication (and the volunteered time) of a very large group of professional programmers, pay attention to that tool. Perl is one.

      Personally, I conclude that “clichés are just that ... clichés.” They're vast oversimplifications, good for baiting the occasional “troll” but frankly not worth the time of day.

      Funny. "They're vast oversimplifications" is exactly the failing of cliches in general, but it's also the failing of your statement :)

      I think you'd have a very hard time making "all perl programmers are green-haired chinchillas" into a widely-accepted cliche. Ditto for "SQL is used for low-level programming close to the metal". The reason cliches become cliches is that they have (or at least had at the time they became widespread) some level of truth about them. The reason cliches are disparaged (if it weren't disparaged, it wouldn't be called cliche) is that the truth is generally one-sided or outdated.

      The problem with cliches only comes when you accept them as the whole story, or as eternal verities. A completely false cliche, with no actual justification or germ of truth behind it, is a rather rare species.

        But all Perl programmers are green-haired chinchillas! ...

      C'mon, how many times has any statement featuring the word “all,” really turned out to be worthwhile?
      All dogma is false.


      holli

      When you're up to your ass in alligators, it's difficult to remember that your original purpose was to drain the swamp.
Re: Revisiting the old clichés of programming languages
by grinder (Bishop) on Jan 26, 2009 at 15:27 UTC

    I thought the canonical Perl cliché was Perl is line noise.

    • another intruder with the mooring in the heart of the Perl

Re: Revisiting the old clichés of programming languages
by Porculus (Hermit) on Jan 27, 2009 at 00:35 UTC
    To my surprise, in his answer, an OCaml guru defined Perl as a "domain specific language for string munging".

    Why did this surprise you? It's really just a shorter way of saying

    Perl is a language optimized for scanning arbitrary text files, extracting information from those text files, and printing reports based on that information.

    ...I assume you recognise the source of that quotation? :)

    There's a grain of truth in all the other clichés you cite. Java can be considered more portable than C, even though C can be compiled on more platforms than the JVM: Java is more portable in the sense that a single JAR file can run on any supported architecture. OCaml can be considered nearly as fast as C, even though idiomatic OCaml is usually much slower than C: OCaml is fast in the sense that you can rewrite speed-critical sections in an imperative style without having to switch to a different language. And so forth.

    Remember that you are a monk, and instead of accepting or rejecting each cliché at face value, meditate on the words and find the nugget of truth within.

Re: Revisiting the old clichés of programming languages
by shmem (Chancellor) on Jan 26, 2009 at 20:37 UTC

    All of those clichés are facts; and talking about facts, nothing of what you or I think about their validity really matters.

    All those clichés are screwed premature judgments based on half-knowledge, hear-say and prejudices of some sort, and as such, aren't really interesting.

    Both of these sentences are as true as they are wrong (or should I say 'false'?). I could add to the first: what matters is the context in which those facts appear; and to the second: what's really interesting is the reason why people are contented with results of reasoning that poor. Which doesn't add much wrongness, and little truth. We get our experiences in a context we don't fully grasp. Okay, that's true for me, and I shouldn't say 'we' here. I stop then.

    Everything you know is wrong (for you) anyways, if it isn't yourself... ;-)

Re: Revisiting the old clichés of programming languages
by DaWolf (Curate) on Jan 27, 2009 at 04:13 UTC
    citromatik++ It's truly nice to see a node like this.
    I always say that one of the saddest things about the IT market nowadays is that a segment that should be formed by specialists shouldn't be so susceptible to rumors and stereotypes.
    Different languages solve different problems in different ways. True wisdom, IMHO, is to acknowledge that and know when to apply this or that language, leaving all bias and personal favoritism behind.


    Er Galvão Abbott
    www.galvao.eti.br
Re: Revisiting the old clichés of programming languages
by weismat (Friar) on Jan 27, 2009 at 12:31 UTC
    The main issue with Java is that the different platforms are available at different timelines and there are a lot of different Virtual machines out there.
    The memory problems occur because the Garbage collectors are sometimes very slow in reacting, then the memory usage goes to the roof and the application hangs for several seconds.
    I know an x-rated and very politically term which makes a fun about Java"s claim to run the same on every platform.
    It does definely have more problems than Perl on various platforms.
    I am missing any cliches on .NET/Mono in the list.

      What can we say, but that “Java was obviously designed by a very big committee?”

      Perhaps my biggest overall objection to Java is simply that it is ponderously slow and unnecessarily bulky, vis-a-vis other languages that are quite-readily available. It has never been my “tool of choice” for that reason.

      However, I have some good friends and colleagues who are extremely pleased with it. (I worry about them sometimes...) ;-)

Re: Revisiting the old clichés of programming languages
by swampyankee (Parson) on Jan 27, 2009 at 13:09 UTC

    There are a couple of lists with the negative clichés about Fortran. See, for example here or here.


    Information about American English usage here and here. Floating point issues? Please read this before posting. — emc

Re: Revisiting the old clichés of programming languages
by explorer (Chaplain) on Jan 26, 2009 at 18:01 UTC

    What is the more costly today?

    The programmer or the computer? The programmer, of course.

    So, we need languages with big speed of development.

      The programmer or the computer? The programmer, of course.
      Yeah, but who cares about the computer? What is important however is the user. How long do you want to wait for a website to bring up its home page? How much stuttering do you accept from the movie player? How slow can a plane respond to a command from its pilot?
      So, we need languages with big speed of development.
      The majority of the users doesn't care one iota in which language the application is written in. And even the computer savvy don't really care for the majority of the applications they use in what language it's written. But they don't want to wait too long.
        Just a remark here : in the case of the respond of the plane,

        the speed of the development is totally secondary,

        I just want to be sure the pilot can drive the plane in total safety.

        especially if I'm IN the plane ;-)

        So it means : correctness (of algorithms) and speed (of execution)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://738946]
Approved by Corion
Front-paged by Old_Gray_Bear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others meditating upon the Monastery: (6)
As of 2024-03-19 11:07 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found