Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Re^2: What's it with Perl Syntax ?!

by raybies (Chaplain)
on Feb 16, 2011 at 13:36 UTC ( #888504=note: print w/replies, xml ) Need Help??

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

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.

Replies are listed 'Best First'.
Re^3: What's it with Perl Syntax ?!
by ELISHEVA (Prior) on Feb 16, 2011 at 15:09 UTC

    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.

Re^3: What's it with Perl Syntax ?!
by sundialsvc4 (Abbot) on Feb 16, 2011 at 20:28 UTC

    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?”   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, 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.

        Perl's amazing at eliminating busywork. We find things we commonly do, over and over again, and we reduce it down to three letter function names, or a punctuation mark EXCEPT FOR GRAPHICS and graphical interfaces. Perhaps this is because noone can settle down and decide upon one thing, or because its too hardware dependent, or because it's too tied to a single OS, or maybe it is a complex task that has never been done simply ever--no matter the technology or language-- but at some point, some languages bridged (or are attempting to) this gap--regardless. Perl hasn't. Other languages, like Java or C# have visual tools that enable them to create components, hide the details, and generate sources that Perl doesn't. Perhaps the developers don't even know what their code is doing, because it's all generated, but do you think that matters to them? Probably not much.

        For a language that more or less DEFINED automation, I find it regretable that there's no serious visual tools that automate things like gui creation in Perl... but I'm probably just being selfish--cuz I know I'd use such a tool.

        Perhaps the problem is that Gui's are too machine dependent--too specific, and Perl's need to do everything 40 different ways (most of which are bad form, or no longer acceptable, btw) fails the closer it gets to hardware. Perhaps we're all such huge fans of GetOpt::Long that we're afraid of hurting commandline interface's feelings... ;)

        One thing I do wonder. Suppose that the Perl 6 people decided to create a standard visual control inherent linguistically into Perl6... How long would it take Perl 5 to find a way to make it happen?

        Perhaps the reason there's no visual tool for Perl is that Perl's just so darn easy at getting the job done quick and dirty that no one's ever seen the need to make the job any easier.

        But I think ultimately we're missing out. We need some fluffy stuff too--some panache' or something to attract the trivial programmers too... because like it or not, they give a language momentum. Sometimes I think Perl's like the smart kid with the personal hygeine problems in the back of the computer lab, who thinks that because we can prove the teacher's no computer expert, we'll get the babes. Ultimately to be relevant mainstream, and thus able to propagate our genetically superior brains through the next generation, we need the whole package, including a few seemingly nonsensical social skills. (Okay that's a stupid painful analogy... I'm going to stop now... before I realize what a loser I am... and go code something in a truly tawdry/socially promiscuous language like C#...)

      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?” 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 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

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://888504]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (4)
As of 2017-12-11 05:32 GMT
Find Nodes?
    Voting Booth?
    What programming language do you hate the most?

    Results (286 votes). Check out past polls.