Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re: What's it with Perl Syntax ?!

by ELISHEVA (Prior)
on Feb 14, 2011 at 20:54 UTC ( [id://888063]=note: print w/replies, xml ) Need Help??


in reply to What's it with Perl Syntax ?!

Perl is a very supple language, but it has its quirks. For instance, it isn't at all obvious that scalar keys %$some_hash returns the number of hash elements in constant time. (We had quite a thread on that one, complete with BrowserUK benchmarking). Nor is it obvious that die; (without any parameters) rethrows an exception. Somebody thought that $#some_array was an intuitive way of specifying the last index of an array, but it wasn't me. Nor do I think scalar @some_array is a particularly obvious way of saying "I want the size of the array". I could come up with quite a list of these oddities.

So perhaps the starting point is to say, "yes, there are parts that are difficult" and then maybe ask them to explain further. Once someone names specifics it is much easier to say "yeah, but that's bad practice and no longer recommended to new programmers". Or if they are talking about something that is hard but powerful, like regexes, one could say: "yes, that is hard, but it allows so much power in just a few keystrokes". And if they are in fact talking about some of the more arcane syntax, well, just agree, but point out that those are just one small part of a language. Every language has its awkwardness. Why, for example, in Java do I have to declare a whole class using boilerplate code just to have a closure?

The other part of their response "Perl only exists as long as Bio data is in text files" completely misses the point as to why Perl is the tool of choice. It isn't the file format that makes bio data text like - it is the gene sequences themselves. As long as RNA and DNA comes in chains, you will need regexes and as long as Perl is the regex processor of choice, it will have a use.

Replies are listed 'Best First'.
Re^2: What's it with Perl Syntax ?!
by raybies (Chaplain) on Feb 16, 2011 at 13:36 UTC
    Good comment... Though you do dance around an obvious weakness of Perl. There's no GUI--nor are there visual tools for perl of any sort. And let's face it, a lot of programmers of the C# and Java ilk, tend to build guis first, and then plug into those and think they've done something amazingly sophisticated--not realizing at all that these tools they use, really aren't a reflection upon the underlying programming language at all.

    Why did Perl enjoy such a spike in productivity ten years ago? Because of the web. It is inherently visual, but it required text manipulation. Where are the quick strides now being made in that arena? Perl's doing some stuff, but it simply doesn't stand out as much... because a lot of tools have made simpler languages a whole lot more easy to do the easy stuff quickly.

    That and many people are inherently VISUAL. Perl leaves behind a large portion of the human being by neglecting graphics and visualization the way it does. Heck, there are computer architecture trends that are exploiting the graphics card as the next great source for computer power.

    sorry it's an old worn-out soapbox, but honestly, I think that without some visual tools, I can't help but think that we'll always be the red-headed stepchild of the computer world... cuz the people who make the decisions in my places of employment don't understand much beyond powerpoint slides and the occasional (if I force them) excel spreadsheet. Heck, They freak out when I suggest we do all our documentation on a wiki, rather than using something like Microsoft word... sigh... My kid just made a powerpoint presentation for school for homework. She should've done it in Perl. Heheh... Gah.

      I agree with this particular soap-box. The role of technology has changed profoundly in the last 25 years. Not only are human beings visual, but the entire process of marketing technology has gone visual, starting perhaps when Steve Jobs realized that you could sell computers the same way you could sell stereo sets and piano - as cool furniture.

      Or consider the buzz two or three years ago about mash-ups. To someone who understands the algorithms they were little more than glorified report writers that drew data from REST and JSON feeds rather than databases. However, the visual excitement of seeing boring data found one place on the web dressed up in snazzy graphics and geolocation software made people think that suddenly programming had turned into sport anyone could play. The selling point on the IPod-touch and IPhone are great visuals and high usability - not technical wizardry. No matter how much wizardry there actually is, that is not what is selling it. I could go on. We are no more in the days of software=technology than we are in the days of autos=mechanics.

      There will always be hard core engineers and artists who will immediately connect to Perl (or so I hope). However, without an avenue into the world of the visual I think Perl is likely to increasingly become a niche product relegated to scientific research and backend systems administration. That's an important niche that will guarantee jobs, but it is important to remember that it is at the bottom of the financial food chain. Sysadmin and research are cost centers, not revenue and market builders.

      I see symptoms of that already. If you look at CPAN, the vast majority of modules are for programmers by programmers. There are very few modules written for the end user, non-technical web-site owner or non-programmer.

      I see a vicious cycle here and GUI/distribution/mod_perl are at the heart of it. If I don't have good visual tools, I can't even think of writing a package for the end user. If most cheap webhosting companies charge extra to use Perl, I can't write to the low end web-site owner market either. If there is no push-button always-works distribution system (the modern standard), even the best package will be left with a limited audience.

      The absence of end-user software and distribution systems reinforces the idea that we are still in a programmer-to-programmer world. That fantasy makes things like make-less builds, skinnable GUIs with modern event loop processing or a binary distribution depo seem like something nice to have or even silly. If they are nice to have or silly, why build them? They remain absent and hence the cycle begins again.

      Freight locomotives do not have a GUI.

      Nevertheless:   Not a single railroad on this planet could possibly exist without one.

      And... in (for example) the case of “the Web,” where, exactly, does the software begin and then cease to be “graphic?” Is Perlmonks “graphic?”   Amazon.com?   eBay?   Perl programs all!   Are they “graphic,” or not?   Here we have passed beyond the realm of creating “gooey programs” on single-user desktop and hand-held computers.   We might have stumbled into the warehouse, where “10,000 outgoing packages must be loaded on that truck by 4:45 PM, or there will be no money to pay anyone to come to work in the morning.”   Perl is there.   What is the true significance of a “graphical IDE in this setting?”   (Beyond what is provided, for example, by Eclipse?)

      I clearly do not mean to be provocative here, but in a most friendly way I suggest that I really don’t think that your argument is sustained...   There is both a place and a value for both types of languages & tools.   It would be impractical to write a GUI program without a good GUI-oriented SDK, but there is a vast world of useful computing beyond that realm.

        The issue that concerns me is that those Gui-less jobs are almost always back-end jobs that are cost-centers. Although back-end systems are almost always mission critical, in nearly any corporation there is very significant pressure to keep cost-center budgets down. This has one of two effects on programmers:

        First, if it is easy to find workers (because there are lots of Perl experts out there), it pushes salaries down. Managers bargain harder for a lower salary. If they don't get that lower salary from one candidate they like, they will be more willing to trade time for money and search for one they like as much but who is less pushy about pay. Since workers are plentiful it won't be that much extra time. Alternatively, if there is a second cheaper candidate who can do the job adequately but not as well, they will trade expectations for money and accept the less qualified but cheaper candidate.

        Second, if it is not easy to find competent workers, salaries will remain high. In fact, they may even be higher than average, a situation developing with COBOL. According to payscale.com, the average COBOL salary in NYC is US $87,623. The average Perl salary is US $79,480. Ruby, Php, and Python for all their sex-appeal are also lower than COBOL.

        However, the pressure to keep costs down will still remain. If salaries can't go lower, then the only other option is to reduce the dependence on such a high cost language. New projects will only use Perl if there is no other viable choice. There aren't a lot of projects where Perl would be the only possible choice. Better and more elegant doesn't cut it when team and long term maintenance costs are 10-30% higher than for that other less perfect language. Further, since the high salaries are due to the difficulty of finding good people, managers might well turn away from Perl simply because it is much less hassle to find good people in that other less perfect language.

        If salaries and search costs for good people are high, there will also be significant pressure to replace legacy Perl systems so the installed base of Perl (and the jobs they supply) will also eventually dwindle. Just as businesses today are eager to get rid of COBOL systems whenever practical, they will start looking to replace their Perl systems as well. When business needs change they will lean towards rewrites/enhancements in a new cheaper language rather than make choices that further lock them into Perl for the long term. That warehouse distribution system (and Perl) is there, but for how long?

        Don't get me wrong. There is a lot of money to be made at the bottom of the food chain supporting legacy systems. Some companies have been very successful at it. However, it is a niche market and the successful people know they are taking advantage of the dying and will have to move onto the next generation of legacy languages when the COBOL market shrinks too much.

        It is taking COBOL a long time to die out, maybe even a (human) generation or two. For our lifetime and our careers there will be plenty of Perl jobs, but for Perl as a language, being relegated to the backend either means lower salaries or lower lifespan. Take your pick.

        Freight locomotives do not have a GUI. Nevertheless: Not a single railroad on this planet could possibly exist without one.

        They have had GUIs for the last 20 years. The Dispatcher's signaling systems are also GUIs on monitors today with vector graphics. Airplanes without GUIs are unmarketable today ("Glass Cockpit"). Cars have GUIs (GPS navigator/whatever) now.

        The history of Perl came from a time when GUIs were novelties for human interest publications like Time and Popular Mechanics, not a serious tool (1980s). Today products are unsellable without the screenshot looking "awesome" in a powerpoint on a projector at a meeting or conference. The GUI of the product today is also supposed to have a zero learning curve, on paper.

        The biggest GUI in use today, is the web. The worse problem today (2010s) is, when the function of the GUI takes a back seat to art and eye candy of the GUI, and the GUI is designed to be a static piece of art, rather than a tool. Compare Google's website GUIs (a tool) to, lets say, Bing (static art).

        "And... in (for example) the case of “the Web,” where, exactly, does the software begin and then cease to be “graphic?” Is Perlmonks “graphic?” Amazon.com? eBay? Perl programs all! Are they “graphic,” or not?"

        No, they aren't. At least they are not good examples of visual design whether or not you separate form from function. In fact Amazon.com is a perfect example. I've been a member for years and still have a hard time finding account information. As for the form of the site, it hasn't exactly been placed in the same category as Apple or BMW for style.

        So if that's what we're going to consider "graphic" simply because they chose a font and one or two colors the relevancy issue becomes more pronounced. Other languages have a culture that, at least somewhat, embrace visual design. There is no reason why Perl couldn't do the same and prosper from it as it has in from it's other accomplishments

Re^2: What's it with Perl Syntax ?!
by ikegami (Patriarch) on Feb 20, 2011 at 06:49 UTC
    So you're saying the following is unclear, even to someone who knows but the very basics?
    if (!@clients) { ... } for (0..$#clients) { ... } if (!keys(%tasks)) { ... }

    I would say those are rather readable, even without the "..." populated. They should be crystal clear with the "..." populated. Whether the parts are meaningful in isolation is not very interesting.

    For instance, it isn't at all obvious that scalar keys %$some_hash returns the number of hash elements in constant time.

    That's got nothing to do with readability. You wouldn't say hash.num_keys is unreadable, yet we know nothing of the efficiency of num_keys.

      Perhaps a small seemingly off topic diversion might make my point clearer. Consider the beginning of Louis Carroll's "The Jabberwocky":

      Twas brillig, and the slithy toves
        Did gyre and gimble in the wabe:
      All mimsy were the borogoves,
        And the mome raths outgrabe.
      

      Even though almost none of the words will ever be found in the dictionary, my guess is that you know that "brillig" is an adjective, "toves" are some sort of animal or animate being, and "outgrabe" is a verb. You know all this because as a skilled English speaker your brain can use the structure of the sentence and the morphology of a word to guess its approximate meaning.

      In the same way, an experienced programmer who has never read Perl before in their life might well guess that at the meaning of $#foo when he or she sees for (0..$#foo). He or she knows that "for" clauses generally have starting and ending boundary conditions. 0 looks like a starting condition. ".." is a common symbol for a series in both mathematics and English. By process of elimination $#foo is likely to be the final boundary condition.

      However the ability to guess at the meaning is not quite the same thing as $#foo having inherent meaning on its own. Were one to encounter my $x=$#foo one would be lacking the structural hints and $#foo would be opaque in meaning if you didn't have prior knowledge. The # suggests it might have something to do with numbers, but there is nothing that says what number it refers to: first index, last index, count, or something else entirely? You'd have to look it up.

      That same programming background can also trip people up if they assume too much. !@somearray only makes sense once you've got the notion of context determining data type. For someone coming from a computer language where that doesn't exist as a concept !@somearray just looks like nonsense or an always false statement. Negating an array makes no sense at all to someone coming from a VB background. For someone coming from C/C++ or Java, it would likely be interpreted as always false. @somearray is an array rather than a reference so presumably it "exists", i.e. already has an address reserved. If it has an address, how can it be "not" even if the array itself is completely empty? Zero-length is not the same as non-existent or null. Even if you argue that every piece of that chain of logic is completely wrong in Perl or even in C, you are only driving the point home further: for !@somearray to make sense you first have to think in a Perlish way. If you don't you are left confused trying to shoehorn it (unsuccessfully) into the concepts of other languages.

      On the other hand, once you do understand Perl, the language holds together well and has good mnemonics. The "#" in $# is a good mnemonic for that "number thing" associated with an array, but it only helps once you already know the meaning and just need a little memory jog.

        In the same way, an experienced programmer who has never read Perl before in their life might well guess that at the meaning of $#foo when he or she sees for (0..$#foo). He or she knows that "for" clauses generally have starting and ending boundary conditions. 0 looks like a starting condition. ".." is a common symbol for a series in both mathematics and English. By process of elimination $#foo is likely to be the final boundary condition.

        If I were to define readability, I'd say it's the measure of ease of doing this is, deducing the function of code from contextual clues.

        However the ability to guess at the meaning is not quite the same thing as $#foo having inherent meaning on its own

        Correct, but it won't be found on its own, so it's irrelevant to the question of readability as far as I'm concerned.

        !@somearray only makes sense once you've got the notion of context determining data type

        I believe otherwise.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://888063]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others perusing the Monastery: (3)
As of 2024-03-29 14:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found