Slashdot Mirror
Why Corporates Hate Perl
Anti-Globalism recommends a posting up at O'Reilly's ONLamp on reasons that some companies are turning away from Perl. "[In one company] [m]anagement have started to refer to Perl-based systems as 'legacy' and to generally disparage it. This attitude has seeped through to non-technical business users who have started to worry if developers mention a system that is written in Perl. Business users, of course, don't want nasty old, broken Perl code. They want the shiny new technologies. I don't deny at all that this company (like many others) has a large amount of badly written and hard-to-maintain Perl code. But I maintain that this isn't directly due to the code being written in Perl. Its because the Perl code has developed piecemeal over the last ten or so years in an environment where there was no design authority.. Many of these systems date back to this company's first steps onto the Internet and were made by separate departments who had no interaction with each other. Its not really a surprise that the systems don't interact well and a lot of the code is hard to maintain."
... that it's because it's too complex for them. There's no pointy-clicky visual perl, and absolutely no correlation between code size and complexity. So they can neither hire a $35k/year H1Ber to do it, nor count lines of codes to measure complexity.
Oh, and without taking special measures, others get to see the code. Including sysadmins, who may laugh at the stupidity of the $35k programmers. Which doesn't make management look good.
Perl is the enfant terrible of the programming world. A very smart one, but requiring the same smartness of its users.
It's simple why businesses don't like Perl. Slashdot is written in Perl. Whenever a business is mentioned on slashdot, their website goes down. Ergo, Perl is bad for business.
Regular expressions are by no means a perl-only feature.
Possibly not the best example of why perl is shunned.
Perl is simply not winning the marketing war.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
The problem is, Perl is just a programming language, not a conceptual system. Arguably it is the antithesis of a conceptual system. Many teams then create their own application frameworks atop it (e.g. Mason, POE), and it's rare for these frameworks to be compatible since Perl offers so many variations in the construction of even standard programming artifacts like classes & objects.
In addition, the level of expression (i.e. TMTOWTDI) means in practice that highly varying programming styles occur throughout large, long-lived bodies of code.
As a result, significant Perl-based business applications tend to become hard-to-maintain hairballs of divergent style and subtly variegated concept.
The root cause: as I started with; the absence of a standard conceptual framework for Perl means that during the early phases of a project, it's much harder to reason meaningfully about the eventual form of the system than it is with, say, Java or .NET where many of the design patterns are explicitly standardised.
I wouldn't say that "Corporates Hate Perl". It's just the Perl as an application language doesn't suit the formal design & architecture process we're seeing increasingly as IT departments start to grow up and realise that they're not the most important people in the company.
That doesn't disqualify Perl from being a useful tool, and it'll always have a place in data transformation, but it does mean that Perl isn't going to be one of the general-purpose application programming languages of the future.
You have to migrate your badly written and hard-to-maintain Perl code into badly written and hard-to-maintain Java code as soon as possible.
Genesis 1:32 And God typed
Very simple:
* the user has deep knowledge of perl but not of pythong
* the program needs certain libs that are easy available for perl but not for python
* the user is not very keen on the syntax of python
* there already exists a lot of perl code & libs that can be re-used and would need to be re-written to python
whenever you start something from scratch in a different language you have to see if it pays off. If you already have tons of libs & classes and knowledge in one language there is no need to write it in another again.
That's why I code my scripts still in perl, because I know what I am doing, I am fast, I get it done and I have classes that help me do the things I want to do. I see no reason why I should start again in python. I really don't have the time to re-do everything from scratch ...
"Freiheit ist immer auch die Freiheit des Andersdenkenden" - Rosa Luxemburg, 1871 - 1919
Hell I've seen developers say C/C++ are "dead" and that shiny_language_x is going to take over.
That may be not so much fadism as well-informed wishful thinking.
OK, plain C is not _that_ bad, but you do need to fight its innate spirit in order to implement sane coding practices.
But I recently had to return to C++ on a recent project, and although I was expecting some tedium, it was way worse that I remembered. MY GOD how painful it makes a lot of really trivial things. Even the nasty hack known as PHP starts looking well planned in this light.
It may be better than alernatives if you really need the performance and low-level capabilities, but if you don't (or only a small part of your project does), you're paying a huge price for wizard points you don't need.
Glitzy clicky interfaces do not a good product make, but a platform where _some_ thought has been given to workflow really is something we should start to expect in this day and age.
sudo ergo sum
-- Larry Wall, author of Perl
I rest my case.
My signature is in the cloud.
For example look at this s!(?:^|\w*/|\.\./|\./)[^\s,@;:]*(?<=/)([^\s,@;:]+?)(?=[\s,@;:]|$)!$1!g;
But this "Perl" code is really a regular expression which is also used in PCRE and PHP and so on. Copied because it was the best there was.
To improve readability of a regex use best practise and use /x (with whitespace and comments) and stop confusing Perl and regex.
>IMHO, a syntax where you have to prefix a variable with a special character ($ in Perl's case) is a bad syntax.
The argument isn't really about syntax; it is rather the strong-typing versus weak-typing argument,
and that is worthy of far more investigation than simply declaring it "bad".
-fb Everything not expressly forbidden is now mandatory.
s!(?:^|\w*/|\.\./|\./)[^\s,@;:]*(? Interesting? Thats a one line regexp which does something which appears to be very very simple to do, but actually isnt.
That looks really simple? Sorry but it doesn't look to me. Perl may be a a very very powerful language, but that alone does not make it a language of choice.
Well that is a regular expression, not Perl. It's a different language, and is the standard way of handling strings in most programming languages. To be honest, I first learned about them in a formal language class in college, years before I picked up Perl.
If you don't like regular expressions, that's your choice, but it really has nothing to do with Perl, and you should try to understand them, as they are very useful, even outside programming.
As a software manager what i'm interested in is developing quality applications. The biggest cost in software is maintenance. If a language is difficult to read by the original author it will be impossible to maintain by anyone else.
I would consider Python because it encourages good design and readable code. Professionally I use Java because I can easily hire people who use it, and it also encourages good design and readable code, if a tad verbose.
Perl is very consise, but also difficult to read. It turns into a maintenance nightmare, and there are far fewer developer who know Perl.
Python is far better; it is more consise than Java, has similar OO features, is readable. It isn't quite up to replacing Java, but has impressed me and many other Java coders.
Oh, and I have no sympathy for coders who think they are so cool being able to code in ways nobody else understands. I would rather see a slightly slower algorithm thats clear than a fast one that is unmaintainable.
Complex code is the enemy of quality, as is premature optimization.
Perl 1.0 was released in 1987, four years before Python. How old is your dad - and more to the point, how old are you?
The problem here is that small != mean efficient.
Parsing the code is not what makes a program slow, and
we don't code for 1K or RAM anymore.
"impressive" oneliners completely fail to impress me.
Lines are cheap.
Time is not.
And bugs are expensive as hell.
I'm sure if you wrote code that walked through the
steps in what you are trying to achieve, all the
following would be quicker:
* for me to see the point of what you're doing
* for me to correctly change what it does.
* for you to get it working right in the first place.
If you feel it is childish to write code like
"find A"
"find B based on A"
"generate C based on B"
"silently fail for some values of C"
"replace B with C"
-rather than one giant, brittle regex-replace, I submit that you are the childish one.
sudo ergo sum
Yes, it is.
It's like saying "Most Basic & VB Code is Verbose, is it really fair to blame the language?"
YES!!
Every language has a unique idiom. And the best languages use this idiom to painlessly guide the developer to best practices.
For exammple, lots of devs consider Java to be over-engineered and overly-complex. You've probably heard a dev talk about building something in, say, RoR in a week that would've taken 4 weeks in Java.
That's probably true, because Java is a tool best designed for large applications and when you're using Java, it's idiom guides you into building multi-tiered architecture.
Python's idiom guides devs into producing well formatted code and it's a great language for web apps because it puts powerful data structures right in the developers face.
C# is a FANTASTIC language for teaching OOD to procedural developers. It's HARD for a procedural developer to think in terms of object hierarchies. The mechanics are easy to pick up. The ability to deconstruct a problem into an object hierarchy is hard.
But you put them in front of a new project in C# and the language -- entirely OO itself -- just guides a developer to the right thing. It's very hard to shoe-horn a procedural architecture into an OO-only language.
JavaScript makes it insanely easy to create an event-driven application. Anonymous functions, LAMBDAs, etc, guide a developer into producing code in an event/event-handler model.
Any developer can do nearly anything with any language. But a language itself can make it easy and obvious when you're doing things right, and painful for you when you're doing them wrong. And a good IDE will reinforce both of these behaviors.
How long would it take you to debug that problem?
About 12 seconds. Run Python with the -tt option and it will tell you about lines with inconsistent use of tabs and spaces.
this sig intentionally left blank