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.
Could it be that, as well as being from an era of more ad-hoc approaches, the code is simply showing its age? System tend to get modified over time, and such modification is often done by multiple people under multiple managers.
I would also dispute the idea that the simplicity of newer code is necessarily a good thing. Maybe they are yet to find all the bugs that require inelegant solutions...
If we can put a man on the moon, why can't we shoot people for Apollo-related non-sequiturs?
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.
Shiny.
New.
Perfect.
Can use it without knowing anything.
They'll start complaining about the new stuff as soon as they realize it only gives them a new untested set of problems and work-arounds. If you want to keep working there, you'll change yet again when enough of the 'decision makers' can't take it anymore.
I have a client with a very workable multi-platform enterprise calendaring/scheduling system. Two people out of 15 in the organization want to use Outlook. It's a fair bet the company will migrate to Microsoft Exchange within the next 6 months and if I want to keep making money from them, I will be training these two users and their colleagues on how to share calendars in Exchange/Outlook. Will life be any better for them? I think the learning curve for sophisticated use of Outlook/Exchange is a bit higher than for MeetingMaker... but we shall see.
Particularly perl, even with coding standards, reasonable indentation, comments etc.
I stopped writing the stuff years ago because I realised that I was only making things worse. Perl encourages big ball of mud development. It's specifically designed as a "glue" language which lets you stick things together, in fact it's a sticking plaster language which allows you to paper over cracks which would be far better filled in another way.
Now if I see myself or others considering Perl to accomplish something, I'm pretty sure there's a problem with the entire approach.
Deleted
I see the same thing with developers in general. Nobody wants to use Perl anymore, PHP was the new thing, and now Ruby is eclipsing that. Now I'm not talking about cases where the new language legitimately makes something much easier, I'm talking about a good deal of fanboy-ish "Oh I do all my code in Ruby now because it's way better!"
It isn't just PHBs, programmers themselves seem to fall victim to fads in development. They want to use the new shiny stuff, simply because it is new and shiny. Hell I've seen developers say C/C++ are "dead" and that shiny_language_x is going to take over.
python seems to be the new perl - ie. a general purpose, scripting glue language. its small number of keywords and simple layout make it easier for the less technical minded to learn quickly.
of course, many people will prefer to use perl because of its larger amount of add-ons and clever tricks.
at work I use PHP a lot for many of my simulations and quick fixes, its really good for processing 2M line data files (try doing that with excel). I know its not what it was originally designed for, but it works for me.
look on the bright side, perl will no longer be learnt by many people and in a few years legacy "perl coders" can command higher wages to work on "legacy system" - much like COBOL programmer do now (though there are less of them every year).
I think this is the way it will always be, there will always be a simpler language to replace the old standards, and a new shiny technology that those who have managerial power but less technical knowledge can mandate from on high.
so, what happened to java? I liked it, it never went away but seems to hover on the edge.
There is not now, and never will be, a language in which it is the least bit difficult to write bad programs.
Perl is WRITE-ONLY language.
You have to be a well-disciplined person an write the comments for every line of Perl code otherwise
it's hard to decrypt the flow. Such things happens
rarely in other languages (C++/Java/Python).
IMHO, a syntax where you have to prefix a variable with a special character ($ in Perl's case) is a bad syntax.
At the risk of starting a programming language holy war, can someone explain to me why someone would choose to start a new project in Perl instead of Python? From what I've seen, they both do essentially the same things in the same ways, and they're both (roughly) the same as far as language overhead (from language interpretation) is concerned. But from a readability perspective, there's no question that Python is miles ahead. (Perl's readability, or lack thereof, is literally the source of jokes) In the long run, this translates into lower total development budgets, which is something businesses like to hear. So, why would anyone choose Perl over Python?
To make laws that man cannot, and will not obey, serves to bring all law into contempt.
--E.C. Stanton
If we forget the conspiracy theories for a while, there are other reasons too.
A 100K/year good programmer can also have difficulties understanding perl code.
If you look at the most efficient perl code, it will be very small, and do a lot. But it will also mean that nobody else can understand the code
Heck I have difficulty in understanding a couple own scripts if I look at them after a year, and that too when I add comments.
Perl is a very very powerful language. A small change can make the code do something completely different, hence the fear.
For example look at this
s!(?:^|\w*/|\.\./|\./)[^\s,@;:]*(?<=/)([^\s,@;:]+?)(?=[\s,@;:]|$)!$1!g;
Interesting?
Thats a one line regexp which does something which appears to be very very simple to do, but actually isnt.
My Aurora : http://www.youtube.com/watch?v=o91ZsGwJYyg
FB : https://www.facebook.com/TanveersPhotography
Setting aside obvious reasons why corporate hats would hate anything they don't dig (tip: it is matter of control. Yes, they want to have possibility to fire you any moment without hesitation), Perl is powerful, but really hard language. Specially when it is written in hurry to complete some task. Without any shred of doc or help it is almost impossible to maintain for thirty party.
Also, in broader picture, it is common problem with IT everywhere - nondocumented stuff which does system critical stuff is big no no. I know, lot of people see it as job security, but it is the same variation as terrorist has job security when it has hostages.
If you want real job security, do your job properly, and you will get rewarded. And if there will be firings, they will happen in any case.
user@ubuntubox:~$ stfu This server is going down for shutdown NOW!
If you can't write proper code with Perl, I'm really sorry, but it's your problem.
Hmm let me think:
- Few Perl Developers
- Difficult (or impossible) to maintain
- There are better alternatives
- Easy to write badly difficult to write well (e.g. Language doesn't lend its self to good practices)
Perl is a dying language and frankly it is easy to see why. The real question is what does Perl do better than the competition other than being older than my Dad and having a bunch of essentially pointless libraries?
People keep telling me that Perl is less readable than other languages, but i disagree. It's only less readable when you dont know the language specific semantics used - surely everyone remembers when they saw floor((float)i + 0.5) in C for the first time? It's no different to a perl programmer who uses @array = map { s/something/better/g } @data;
While I must admit that if you code in perl like a one-liner guru, you're not going to make particularly managable code but not coding in perl has significient RAD drawbacks. In Perl I worry about one thing: variable tainting. In C and C++ I have to worry about tainted variables, constant index-off-by-one errors, the possibility of null pointers and null reference handling, libraries and linking.
Some Perl programmers could do with more non perl experience to make their style managable. Perl 5 oop is a joke, and perl 6 is trollbait - but these aren't reasons why programmers shouldn't apply wider programming skills as a C/Jaava programmer uses their ADT knowledge and skill between langages.
Matt
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.
Corporations hate perl because it takes too much restraint to write maintainable programs in it. You can totally write beautiful systems in perl, but face it there are simply too many ways to skin the same cat syntax-wise and "clever" programmers seem to gravitate to the syntax and language constructs which are least readable. Yes I understand you can write hard to read programs in any language, my point is that perl seems to make it easy.
People who don't work with perl all the time don't want to open up a code base after some time and spend a pile of time researching WTF $_#&->!] means again.
No I'm not talking about regexps, and that wasn't meant to be real perl.
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
While it's possible to write readable code in any language (well, maybe not Brainfuck), and just as possible to write horrible spaghetti code in the same, Perl does not encourage clean, readable code like python or ruby (my preference.) As a result, nearly all of the perl code I've seen has been virtually indecipherable to anybody not a perl veteran. More modern scripting languages like ruby and python not only have "syntactical sugar" that allows complexities to be expressed more simply (and therefore, more readably) but in general discourage things like the perl super variables that radically decrease readability. Additionally, their object-oriented structure allows for more clear code organization, making 100,000+ line programs possible to understand (look at rails, for example; hundreds of thousands of lines of code, but readable for someone without great knowledge of the codebase).
In the beginning the universe was created. This made a lot of people very angry and is widely considered as a bad move.
This is an insult to associate us Perl-Haters with corporate types.
now we need to go OSS in diesel cars
Management are blaming Perl for the problems when really they should be blaming the management and design procedures that were in place (or, more likely, werenâ(TM)t in place) when the code was originally written.
I think this is the key paragraph. Everyone knows that management can't blame management that would imply they were in the wrong
The latter may be true but you have to realise that it probably always will be.
You can dream of an improved development environment, you can even take steps towards one, however the simple fact is that in 99% of the situations there are real development pressures that make "piecemeal development", inadequate attention to design, poor attention to coding standards and countless other problems an inevitability.
Once you accept that sad reality the decision to avoid Perl for something less impenetrable makes sense.
Perl may not be the cause of the problem but it can certainly compound it.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
There is absolutely _NOTHING_ wrong with perl, and compared to shell scripts it is natively cleaner.
You can write good, and bad programs in any language, which is why academic language development, eg Worth, has been such a waste of time. Perl, in contrast, was designed by a group of exceptionally capable programmers and mostly does the right thing by default.
Like any language, perl can be mis-used but so can C++, Java and Python. Indeed the more complicated the language, frame-work or toolkits become the more they are prone to mis-use and the more duct tape eg design patterns aka example/template solutions seem to be required to get anything done. The extream of this is where the language/framework requires so much boilerplate code that you need an IDE to generate it. Think Java J2EE.
Any dynamic language faces this problem . They're good for glueing apps or writing quick scripts, but for enterprise applications of any significant size it's kind of a joke to have something in php or perl, ruby. For small web 2.0 or text prcessing web sites I can the benefit on the small scale, but...the dangers of dynamic lanuages when you're sharing code in an enterprise, particularly doing calculations, is just too great.
As many others have pointed out, you can write bad code in any language. Perl makes it very easy to write terrible code, just as Perl makes it very easy to write just about anything else. There are other languages that place obstacles between you and the bad code you're trying to write - for example, Python won't let you not indent correctly, and Java won't let you not use OOP.
When coding large applications, it is critical that certain coding standards are followed. Everybody has to play by the rules, and do things in a standardized way. Perl doesn't impose any of these rules for you automatically. If you choose not to self-impose any rules, your code will wind up being an unmaintainable mess. But no language can save you from that - if you write terrible code in Python, it's guaranteed to be nicely indented, but that doesn't mean it'll be maintainable. And, if you want to self-impose some rules to help keep your code clean, Perl Best Practices will point you in the right direction.
I highly recommend The Daily WTF?. Perl does NOT get a disproportionally large representation there.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Re:Perl IS /your/ the problem
Perfect example of perl syntax!
I think his point is that Perl doesn't encourage nor enforce good coding practices.
[asbestos hat on]
If you take Java for instance, _everything_ from the main method to the kitchen sink is inside objects (with very few, controlled and necessary exceptions), which conform to the OO paradigm.
Tell me, what kind of structure does perl enforce or even encourage?
Don't get me wrong, Perl is EXCELLENT in what it can do -- quickly manipulate large amounts of data. But it wasn't designed to do much else. Perl (like PHP) is a far, far cry from a enterprise programming language, and frankly, I'd like it to stay that way.
[asbestos hat off]
Change is inevitable, except from a vending machine -- Robert C. Gallagher
they're called for or not, and too little in clarity, modularity and maintainability
I've been around the block long enough to know that what this often is an excuse for corporate environments to hold better developers back to try and force a levelling of a pay scale. If you paid developers based on their ability to produce working systems, you would find that some developers produce far more than others. But.... now we have to riddle our code with wrapped access methods, ultra long symbol names, case sensitivity and standards made by morons for morons, and all of it adds -ZERO- features to the finished product. Sure, you can argue that it makes "better" code, but that "better" code has NO MORE EXTRA FEATURES. It only allows retards to work on it. And really, is that a feature?
This is my sig.
It appears that you are yet another Perl fanboy who refuses to acknowledge that there really is an issue with the spaghetti code that Perl coders tend to produce. These types of situations don't occur nearly as often when using PHP or Java. It may be that Perl tends to attract the types of programmers who just like to get the application working and go home, while Java tends to attract the types of programmers that care more about architecture and maintainability. From my experience, 4 out of 5 Perl coders haven't read Design Patterns while 4 out of 5 Java coders have. It should be no surprise that Perl coders (most of which don't have a CS degree) tend to write unmaintainable code with no type of architecture in mind.
Or, to put it another way, correlation is not causation.
Perl has been around long enough (and, more to the point, was pretty much the only choice if you wanted a half-decent scripting language 10 years ago) that there's a strong chance in any business that badly-designed hard to maintain systems that have been around for 10 years or more include a fair chunk of Perl.
That's not because of Perl, that's because they were badly done in the first place. I'm willing to bet that there's just as much code which is written in Perl and does a perfectly good job but nobody really knows about it because it's been sitting in the background doing a perfectly good job for so long.
-- Larry Wall, author of Perl
I rest my case.
My signature is in the cloud.
So, you are saying that someone, who is not specified, wants to move away from some program, which is not specified and written in Perl, to a solution based on a different language, which is not specified. You then speculate that this or might not be due to the grown & evolved nature of the unspecified program.
How is this news? What do you actually want to tell us?
Don't get me wrong, I love Perl. I simply do not understand why you would submit this to /. or why it would get approved. I am seriously confused.
I hate most programming languages with weak types, vaguely defined variables and ambiguous functions like "chomp"
"the spaghetti code that Perl coders tend to produce."
that's not Perl, that's the coder. Make them write in C# and it will be spaghetti code. Does that mean C# is a terrible language?
No.
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..
That's fantastic. Given your assertion is 100% correct, and you cannot change the practice of companies ALWAYS developing code piecemeal over a number of years with no single consistent design authority - what variable is left to alter?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
(or rather: should be)
Let me explain:
First, and foremost, perl encourages via its programming culture (does the acronym TIMTOWDI strike terror in your head?) and through its design obscure programming. Thus, the risk of resulting unmaintainable code is very high.
Second, perl is technically a hybrid of different programming paradigms. This does not only add to the complexity and the before mentioned risky "TIMTOWDI" behaviour, but it more often than not gives perl coders who need/want to work in an existing perl environment a huge headache. The colleagues do it differently, they have been, for years.
Third, perl is highly deficient in what i would call "semantic integrity". It is like speaking a language with an unusual high percentage of phrases, lexical and grammatic exceptions.
Fourth, perl has a huge history. A history so large and moved that it carries a lot of weight of past programming paradigms, do's and dont's, hacks and "boobytraps". No business decision can be based upon that.
Fifth, perl is slower, bigger and consumes more memory, and does not offer bytecode by default. This, again, is not the fault of the perl maintainers, but the of the dead freight perl is still carrying for compatibility purposes and the lack of "one" way to do things.
Sixth, perl has a weird typing concept, which encourages misuse. (Hey, no other scripting language i know uses a library-include to render typing useable...)
Seventh, and this is nourished by my own experience, there is the phenomenon that you get much better (in terms of maintainability) perl code if you hire programmers who do not primarily program perl. This is weird, but my observation suggested, that this is because they don't tend to give in to certain sugar perl offers and use paradigms like OO more straight forward. The perl-enthusiasts I met as job applicants, who were altogether very capable programmers, were kind of proud of their obfuscated perl code. So proud that a lot of them even put it in their application (which was of course rejected prematurely).
Perl has done great, and I mean really GREAT things for the internet, for script language evolution and for businesses.
But it is time to let go, really.
Of course this is the reason that Lisp has died as a web-app tool. It requires a clue. :-)
Add:
Yup, it's the language's fault that our boring, me-too web application sucks:-)
Seriously, the whole Perl 6 thing has been a bigger problem: the brighest and best have been playing "Perl the Game" rather than making the language more useful. Consider XML/Xpath processing: the existing CPAN modules are "somewhat behind the cutting edge". To put it kindly! And comparisons between the web frameworks for Perl vs The Others is even less flattering.
-- Butlerian Jihad NOW!
PHP is shiny. Perl is not.
People like shiny things.
(and I love Perl :)
I work at a company (right now!) that developed it's own in-house framework on Perl. It's written in Chinese for all I know, there are portions of the system the IT head tells me not to look into. It's a black box. It works, so we don't touch it, we don't look at it. We don't think about it, in case something snaps and sends the system crashing.
I was code surfing once and came across 2-d arrays. I asked my boss, and he's like, oh, yeah, it gets even better: there are 3-d arrays in there.
The system is currently a black box. The business poured significant amount of money back in 2001 when the system was designed, and the company's been milking the productivity it gets out of the system. As new projects come up with new features and functionalities, the system is more strained, and we do more workaround and hacks, until we forget where the system ends and the hacks begin.
From a business standpoint, the management won't invest in a new system, Perl or otherwise, because that's additional costs for a system that *was* designed, they thought, back in 2001. They're not interested in listening to strange terms like "architecture" and "design." They hold the keys to the safe, so here we are, working on a project on a crumbling old system not designed to do anything like what we need it to do.
Boy, oh boy, I'm sending this article to my boss. And bro... I hear you. I love Perl, what a damn beautiful language to code in. Sure, you need to set the ground rules or people will run amok or write one-way code, but it's such an absolute pleasure to work with. But the language, nor the programmers who love working with it, get much respect.
You see this process all the time in companies that have a lot of old code. Companies start associating problems related to these systems and their age with technologies underneath.
It does not matter if it was written in perl, COBOL, common-lisp or C++ ... it has happened countles ammount of times - you slowly start relating problems of a particular application with programming language or a framework and then thinking that you can't fix the problems without changing that part without throwing out the baby with the bath water.
If you want to keep the language alive - the most devious solution would be associating problems with some innocent but old perl libraries, or making your company switch web frameworks, so they would have something to blame for the old problems. Because making them realise that problems are induced by age of the application, might be just too difficult, and even then you would either have to prove that fixing old stuff is better than rewriting or that they should stick to perl for the rewrite. And all of these are social problems - not thecnical ones.
Perl advocates nowadays might deny this, but at least in the beginning Perl was never intended to be used for anything more than providing quick scripting solutions for text processing tasks to the lazy programmer. And there is nothing wrong with that, it's better than awk. When a language becomes popular, people start using it for purposes it was never intended for, and it's only fair that the mindless corporate drones don't want to encourage that. Moreover, the average manager type can barely understand a line of Perl, but is probably convinced that he could do Python programming better than professional programmers. Then, of course, Perl will be discouraged.
Personally, I stopped using Perl 10 years ago, so I don't mind.
Obligatory language flame part: By the way, Python sucks, too. I mean, "duck" typing", that's just crap. Use mzscheme instead.
Its because Perl has developed piecemeal over the last ten or so years in an environment where there was no design authority.
There, fixed that for you.
Media that can be recorded and distributed can be recorded and distributed.
-kfg
Corporates don't hate PERL,
I mean they never have to code it, so why do they care?
Programmers on the other hand, may hate PERL.
Programmers are the ones who have to deliver on corporate demand.
Programmers will always try to use the best tools available at the time to fulfill the demand.
IMHO corporates hate losing money more than they hate PERL,
..and will blame anything and everything when they do..
..even when they approved the budget to start coding in PERL in the first place. :-/
My 2c Hypocrisy.
One thing that really disappoints me about C++ is the direction that it's been heading for the past 5 or 6 years - "template programming". In fact it's about as bad as perl in terms of readability and maintainability, but much worse for debuggability. I can't think of any programming "language" worse than C++ template programming. I stay away from Boost and really hate what it's doing to C++.
I respectfully disagree. The direction C++ is heading, with C++0x, is awesome. With the next standard, error messages from compilation of templated code will become comprehensible, thanks to concepts. This will mean using complex stl classes will be as easy as using java generics. Of course, designing the STL will still be hard, but I for one do not have to do that.
Also C++ will become viable for functional programming (which is possible but horrible nowadays) thanks to lambdas and closures.
Suppose you write in Perl or Python and you use a lot of 3rd-party libraries. My personal experience is that the modules available for Perl are at a lower, more geekful level than those for Python. In Perl one gets four or five modules off CPAN and spends a painful few days bashing them together into a solution. In Python, one more often gets a canned solution that works immediately.
If that carries over into the corperate domain - and it's a big if - then it makes Perl look expensive. And poorly-trained developers will do better with the canned solutions than with the low-level stuff.
Disclaimer: my experience is coding for scientists with FOSS and may not translate to the corporate domain. And I haven't written very much Python. :-/
I can't believe so few \. readers can write in Perl. That's the only explanation of the comments I read.
I use Perl everydays. For example 30 minutes ago, a user has found an error in data (a bunch of text files with strange structure) and asked me how many times this error occured and if there was a systematic way to fix it. Less than 10 minutes and 20 lines latter, I gave the report.
There is always a natural way to express your thinking in Perl. For me, a bad Perl program means that the programmer did not have a clear mind.
For me, the problem with Perl is that instead of forcing rigid rules on input data, process, users, like we would do with most langages, it is easier to adapt the code to handle every cases. It is so easy and nice to code in perl.
The result is that the users are happy, but it is very difficult to migrate to another langage (except Python, Ruby, OCAML and GHC but I dot want to start a troll)
[joke]
The best way to edit a Perl program is to delete it and start over.
[/joke]
Yeah, maintainability is the problem. In the early days of web (post-static only HTML pages), I wrote a large internal web site using Perl (remember those days). The problem was in maintaining it. And this was just some "Friday work" project while I did my real VHDL engineering work for the group.
The maintainability problem was worse for the Engineering IT guys who had years of Perl and bash wrapper scripts around incompatible tools to make them interoperate. That was a thankless job. Where you were not allowed to touch anything when it worked, but when it didn't you do anything you wanted. But as soon as it worked, no touching it (even for code clean up). And, since it was all ad hoc, there was no version control. After all it wasn't software design, it was just IT work.
But the problem was after 1 rotation of the IT team no one knew what the F' was going on. So wrapper scripts around the wrapper scripts. (This environment did produce great version of hierarchal RCS, back before CVS, SVN, etc systems).
The Perl/bash/tcsh was impossible to read. It was all informal hacks that had become fossilized.
So, while that environment is bad for many reasons. I see why managment may want to move to an inherrently more readable language.
I like perl it is a cool language but the mistake of perl is the massive rewrite of perl 6 that is taking years, it is as the windows vista that took 7 years to develop?. That is the biggest mistake of perl and with the years is loosing field, lost the battle, Now new languages
as Python and Ruby are taking over Perl.
If I have to move to another language it will be Python it is a compact and fast language, Ruby is slow as hell, It have some of perl magic but it is not perl it is like a bad version of smalltalk.
2c.
I thought Perl is considered duct tape if the internet. It is ugly but it works.
Whenever you think of a clever programming trick: forget it !
Non-Linux Penguins ?
As such, one of the hardest problems with Perl is education of new techniques. Too many systems still use CGI.pm when they could use Catalyst. They use some home-grown system of objects, when they could be using Moose. They put up with outdated techniques when Perl::Critic would find them in a heartbeat.
So, if everyone learnt the new techniques, we'd be fine, right? Unfortunately, it's not that simple. I teach Perl for a job, it's still an incredibly popular language here in Australia. But because that old code still works, I still need to teach people how to understand it, even if I then proceed to teach them better ways so they can avoid it. That increases cognitive workload, and there's only so much one can fit into a fresh brain during its first contact with a language.
Perl still remains the language of choice for writing minesweeper bots.
I don't know why others don't use it, but my personal reason has little to do with whether it is a good language or not. I simply got to dislike it from the very beginning - it seemed to be somebody's personal statement about things that have nothing to do with programming.
It's been a long time now, but as far as I remember there is a command or statement in perl called 'bless'; when I finally found some tutorial it went on about 'Christian names' of variables, or something like that - OK, so maybe the guy was religious or something, but it was a real turn-off for me. I mean, I have certain political views which I am perfectly willing to share with the world, but I don't bloody make the programs I write a forum for propaganda.
Ah well, maybe I am way off the mark. Wouldn't be the first time either :-)
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.
Or it could be that humans are smart enough to notice things and connect the dots, even if they don't fully understand the subtleties of what they're connecting. They notice that smashing two flintstones together makes sparks, and sparks can light a fire, and all of a sudden the whole tribe has fire. Even if they don't fully understand what fire is or why those stones create sparks. Or they put their finger in the candle flame once, it hurts, they don't do it again. Or maybe if they want to be really sure and scientific about it, they put their finger in it a couple more times. It hurt again, so they stop doing it. They don't wonder exactly what happened there and what nerve endings fired that signal, but they stop doing it anyway.
In this case, the summary already tells you what you need to know: " 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."
Ah-ha. Maybe _that_ is why management is trying to steer off it? My understanding of Occam's Razor say it might just be the right explanation.
And in the end that's what they're supposed to do. If all those many projects and departments (again, TFA spells it out), and indeed many other companies too, produced unmaintainable code in Perl, maybe it's time to try something else than Perl. It's that simple. And if you can hire 3 new kids fresh off university who are already good in Java and/or Python instead of 1 mythical uber-coder who can user Perl right, then it's even more of a no-brainer. That's the kind of thing management is supposed to do.
You _could_ say that it's not Perl's fault, it's the humans who don't use it right. But then they said the same thing about Communism in the USSR. Let's face it, the smart way to do anything is to figure out how to use the resources you actually have, not to try to pretend they're something else. We have plenty of examples of people who tried to idealize humans as having to be anything but what they actually had, and lost. The USSR is one example. Napoleon III and the silly French notion that they should just have "elan" and overcome any odds or equipment disadvantages, is another. I'm sure that while he was capitulating at Sedan he had time to think about it.
The same applies here. If the humans you have (H1Bers or anything else) are bad at Perl, then maybe it's time to try something else.
And while you may laugh at "pointy-clicky" tools and trying to use cheap incompetents, well, that's the history of human civilization. That's why we built tools in the first place. So some ape who's too much of a wimp to bite a gazelle's neck off, can still hunt as well as the lions. Then so some wimp who can barely lift 20 kilos of rocks, can use ropes and inclines to move 20 ton blocks up a pyramid. Then so some half-educated merchant who can barely do maths up to 20, can use an abacus to do maths up to tens of thousands. Etc.
There's no failure, management or otherwise, to try to use better tools. Even if it's instead of wishing for that uber-guru who can do the same job without tools, at only 10x the price. If we waited for the uber-workers who can lift 20 ton stones, we wouldn't have pyramids yet. And if in the process you enlarge the potential pool of workers a bit, well, even better. Society on the whole then can use more of them and achieve more.
Yes, maybe you can program without "pointy-clicky" tools. And some people still can weave without mechanized looms. Guess what? The industrial revolution happened when we figured out a tool (that mechanized loom) which let masses of drooling retards weave just as well as those l33t weaving gurus did without tools. And even faster at that. And guess what? We all ended up better off for it.
A polar bear is a cartesian bear after a coordinate transform.
1. look at php vs perl sample code/docs in their respective sites. Php not only looks better, but has more info, yet perl as usual is too minimalistic in both its english texts and its code samples and combination samples. Even MSDN docs are better put together.
2. I am being picky here but even the colors chosen on those websites is so minimal it reminds me of 1996 websites. Are perl programmers so cheap they only still use 8bit desktops on 28k modems? Put some more bulk in the content.
OT - I think personally the whole concept of IDEs should be taken to the next level, to the photoshop scale. Why do we still work with "files" and "functions". We need no 'files' concept but have classes/functions in one 'application'. The ide can hide it all even if it has to self create auto filenames or keep it in one giant .zip with one function per 'file'.
Todays programs are more complex than 3 source files and a makefile. Why waste time managing a file structure, lets abstract it and let the IDE do it. We are past the vi days.
Liberty freedom are no1, not dicks in suits.
Besides, don't underestimate the importance of clarity and modularity in architecture
I've seen so many systems that were expensive to build because they offered so many degrees of freedom for future expansion, that they stayed expensive to maintain because of all of those degrees of freedom. Conversely, the badly designed terrible little programs that aren't all broken out seem to be the ones that really succeed and it makes me wonder if today's software, is, in fact, over-engineered. There's all of these layers and these layers -never- really deliver the economic benefit to which they were supposed to deliver.
This is my sig.
It appears that you are yet another Java/PHP fanboy who refuses to acknowledge that there really is an issue with the spaghetti code that Java/PHP coders tend to produce. These types of situations don't occur nearly as often when using Perl. It may be that Java/PHP tends to attract the types of programmers who just like to get the application working and go home, while Perl tends to attract the types of programmers that care more about architecture and maintainability. From my experience, 4 out of 5 Java coders haven't read Design Patterns (err..m.. as if Design patterns are some magic :) .. another design pattern obsessed guy! :) ) while 5 out of 5 Perl coders have. It should be no surprise that Java coders (most of which don't understand CS even if they have a CS degree) tend to write unmaintainable code with no type of architecture in mind.
Hmm ... I guess it's fixed now! :)
I only recently started a rant on the SlimDevices forums regarding the fact that they wrote their complete media streaming code in Perl. Sure it's very portable, but because it sucks up 150MB and more when run, it also make is *less* portable as you require heaps of memory to run it, so embedded devices are out.
Somebody ought to hang the people who try to write whole applications in it. Each tool has its uses.
Awk: clean, C-like language, with NO dollar-signs or semicolons on the end.
Awk is comparable to JavaScript.
And no OO, either!
I've always understood that Perl has never been sold as a technology to build complete systems with (although it can be done), but as a multi-purpose toolkit with the emphasis on systems administration and systems integration. It's unsurprising if code has developed on an ad-hoc basis.
... 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
And I maintain that it is precisely because it was written in Perl, which by its very nature encourages the writing of unreadable (and therefore hard to maintain) code, that you find your code badly written and hard to maintain.
Serious developers only use Perl as a last resort (like when BASH, sed, and AWK aren't available).
Twiddle fingers who masterbate over their Perl code are really only interested in ensuring they're unreplaceable.
P.S. I also agree with the sentiments of another poster who comments upon the failure of Larry Wall to control his evangelical urges. I don't go around peppering my code with satanic verse, or Zionistic clap-trap, and I don't really want to be asaulted by it in other peoples code either.
The article talks about PHP and Java as the alternatives that these companies are talking about, not python. Why is this tagged as "python" when it has nothing to do with the article? Why not tag it "c" or "ruby" "cobol"? Smells of fanboy to me, and that isn't a good smell.
I hear a common ocean theme there.
Perhaps he should have stuck to more C standards when creating that oyster.
Why in hell didnt he copy at least Cs array declaration of , int var[];
Was he that short on harddisk space that he thought two chars of [] were more cryptic/space using than a @.
Sure [] is more cryptic, but more people knew what it meant, so why reinvent a definition. Even pascal was ok.
A cmd line interpreted javascript, could be well useful as perl or more so.
Is there a cmd line js 'vm' ? Technically perl is a vm.
Liberty freedom are no1, not dicks in suits.
Perl is an amazing language. It allowed me to design applications without mastering their models. Perl is the language of choice for the explorers. I'm going to buy a Java-based environment for my company. Which includes a *lot* of lines written in... Python. Java is often presented as the kernel language but is finally only an extremely expensive glue in numerous pro applications. To programmers, seriously : please code in Python or other productive languages. We are in 2008. Look at web2py, rails etc. The Javanese begins to tire the managers. Relieve us, you got the tools. Moreover who said that Java was fun ?
I've never seen any other language in which so much good is done by so much bad code.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Design patterns are horribly mis- and over-used by Java coders. In practice, they add verbosity and obfuscation of intent with any increase in clarity or elegance.
Which is probably why Java coders love them, because these are the same effects most of the language's 'features' have (shoehorning every problem into an object solution, if/switch statements considered bad, etc).
speaking of VB, I was talking with a guy the other day who had to repair a point of sale system in a deli written in VB with Access on the back end. When he disconnected a router temporarily, the whole system crashed! It was out through the lunch rush. Every cash register had to be rebooted one at a time.
no big sig
I love all of this bashing business for not using Perl as if somehow not using a technology that some geeks think is cool matters to business.
What matters to business is the cost of maintaining a system, and Perl software is generally way too complex to maintain. And that means costly.
The combined with the fact that companies are moving away from maintaing custom software at all, it is not surprising Perl is on the downswing.
This can be one or more of the following:
- They don't have anyone with those skills
- They want you to pay them to learn a different language, for their own reasons
- being free, they can't add on huge charges for compilers/tools
- the competition is hot on that language
- it would be too easy (if they get paid by the day
- they are reflecting the biases of your decision maker - in the hope of getting some work
None of these mean any particular language is bad, just that they have political reasons for bad-mouthing it. Now, if you want a true legacy language try basic and all it's MS "visual" variants"
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
Please place all "Perl is dying" trolls below this note.
2 dashes and a space, or just 2 dashes?
Into simple words: Any code needs to be easy readable by anyone on team (not just the super-duper "the chosen one" coding guru of ). For example, yours maybe hate BASIC, but anyone can understand what a BASIC-written code does.
P.S: I really hate regular expressions. Works? Yes, but how to explain what a hell one crazy regular expression line does on your code?
Religion: The greatest weapon of mass destruction of all time
The difficulty with perl is it's not a main language such as JAVA or C. It's most often used for scripts and task automation. Where it previously reigned in web application development, Java, PHP and ASP has taken over those spot.
In my environment perl coders are as rare as JCL and Assembly coders.
someone need to write a killer perl application. When you look at some scripts it looks like someone tried to win the obfuscation contests and failed.
As someone who has both written and read _alot_ of perl, in particular in Bioperl and Ensembl, in bioinformatics I have a rather love/hate relationship with Perl.
I love: the low learning curve for people coming from biology, with alot of forgiving behaviour (in particular I think the auto-creation of datastructures as you use notation to fill in complex anonymous - think pointer based - structures). This is probably the critical one which means we can hire a much broader group of people with a much better understanding of biology and for them to be productive far earlier
I love: the large and robust libraries accessing nearly every sort of database, web-app and other things you need
I love: the consistency of behaviour between systems (don't get me started on Java or porting C++ code between compilers/library systems. Ugh! unbelievable pain as one starts using those languages and move between high end systems. Its C for the fast stuff and Perl for anything else for portability in my book).
I love/hate: The (huge) amount of robust existing Perl code that we have in Ensembl and that works day in, day out on multiple outings
I hate: The lack of clean objects. Why, oh why, oh why?
I hate: The inability to switch on strong typing and bigger checking optionally in libraries - I know you can do more these days, but it is still clunky.
I hate: switching the word "continue" (in C) to "next" (it gets me every time)
I hate: having to always brace if statements
I hate: operators designed for one-liners that gets in the way of good readable code - grep and map in complex lines are pet hate of mine.
I hate: the tortorous cross-language capabilities - compare python's jython and other C-level compilers. Soooo much better.
Interestingly I coded in python for about 6 months in the late 90s - very early on python - and lots python appeals to me. But then Perl came along, and lots of bioinformaticians were using it, and systems people were installing it by default on systems...
Roll on Parrot. I want Parrot to be able to run
Perl5 syntax code, Perl6 and Python/Java syntax
all together, with easy ways to load in C level or compiled down libraries. That's what Perl needs to save it.
My problem with Perl is it started out as a replacement for AWK, and became an ungainly monster. As a sysadmin sometimes I find useful utilities that use Perl but then I can spend a LONG time trying to find and [attempt to] compile all the associated libraries (and the depenencies of the associated libraries, etc...). MY GOD, ALL THE STINK'N LIBRARIES...
And yes, let's not forget all the obfuscated perl code contests (although there are also obfuscated C contests as well).
I liked perl at first, but it morphed from a scripting language to a programming language and didn't do it all that well. It's a good example of scope creep.
It isn't directly linked to perl only, you can mess up and write hard to maintain code in ANY language. The points he brings up are valid points for a lot of projects that have been maintained over a long period, mostly it starts out as a proper designed project (for that point of time), but later because of a lot of wanted 'features' and with the 'pressure' of having it ready yesterday it has gone stray.. I see it in a lot of projects, and mostly I have to say that it isn't really a bad thing (yeah for some it's a horror), but with current events/managers the software has to be ready by yesterday if you want to stay ahead of your competition.. The advantage ofcourse is that after a while the system has about everything you'll ever need, and especially these days, by that time there's already a new fab/programming system, so you can port(/redesign) it for that new platofrm.. At this moment .NET is the fab (yes I say fab, because everything you ever want to do can still be done perfectly in say Visual studio 6), and we all know that .NET has already had some incarnations...
When i'm a development manager for a huge spiffy company, my employees will have a choice: Perl or Intercal Take your pick.
I'm almost sorry I participated in this thread; that is one beauty of a post.
Good to see someone couple design pattens and languages too. Many really frequently used patterns are IMO really just symptoms of a weaknesses in the language. In fact many of the famous ones were born as emulations of features in smalltalk, but that is a different discussion...
The meme of 'syntactic sugar' has done untold damage to the progress and productivity of computer languages, but it seems at least parts of the world are now slowly coming to its senses. The entire point of a programming language is to express the logic in a fashion that is readable and understandable by both people and the machine, goddammit!
sudo ergo sum
Corporates hate perl for the same reason why terrorists hate America: It's free!
God bless America! God bless Perl!
But Larry Wall also says that Perl 5 is old, and, in places, nasty, and there are some aspects that I'd describe as broken.
Take UTF handling, for example - check out the chapter in the camel book for how simple it isn't. Only this week I fixed an encoding issue by adding 'use bytes' to get UTF8 to render correctly - that is not the sign of mature unicode support. For one project, I taught myself tcl/tk from scratch simply because I knew the unicode would work, where getting unicode to work consistently with perl/tk has Holy Grail status.
Worse, perl 5 is due to be replaced by perl 6, but who knows when if ever perl 6 will ship in a production-ready form. In the meantime, it would be madness to rework perl 5 code in a more elegant version of perl 5.
If Larry Wall either shipped perl 6 or said "only joking", perl would become a serious long-term strategy again.
Virtually serving coffee
New O'Reily book: "Python for Unix and Linux System Administration" should be out September 2, 2008.
http://www.amazon.com/Python-Unix-Linux-System-Administration/dp/0596515820/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1219235379&sr=8-1
Just thought I'd mention it.
perl is the language of choice for server scripting on linux.
its not only gonna be here for a looooong time, it will be almost mandatory if any company chooses to do anything with linux webservers.
"managers always want the shiny new technologies" - yes, because they dont know any better.
Read radical news here
Anything over a 100 lines (and much under) can be incredibly hard to read for non-authors of the code. Especially if depreciated stuff is being used.
It's probably why a LOT of people and biz are going to python instead. Reading it does not make your eyes hurt.
according to your logic, cheesy layout, animated gifs and smileys dominate the web, but I would hardly want to do a big enterprise project using that technology.
I am surprised there is not an object-oriented extension to the bash shell.
It seems to me that languages often start out with a simple purpose, but as time goes on, the developers of the language try to make that language "all things to all people."
I don't think perl was originally intended to be an object-oriented application language. I think it was designed as more of a UNIX shell on steroids.
I wonder if tacked on object-oriented is a good idea in any language?
Today, you can do sysadmin stuff with php at the cli, but is it a good idea?
Only sissies code in Perl. Real men write only in machine code. If you need more than 10 buttons on your keyboard, you're not doing it properly.
Seriously, Perl is not the most readable computer language on the planet. Maybe it's better than ... oh well, I can't think of a less readable language at the moment, but I'm sure one exists.
I love these religous debates on the merits of this or that programming language, O/S, code editor. They're all so much fun.
I am a Perl fan and have written and maintained plenty of Perl in my day, but I find it to be too "free form" for large scale projects (those with more than say 3 developers, with new people joining the project frequently). This isn't a problem with Perl per se, or even actually a problem per se, but it makes it difficult to maintain consistency as the different styles of coding can conflict.
rooooar
Perl had a brief period where it was relatively popular in the mid nineties before php came along and later things like ruby on rails happened. Basically it filled a void between the moment cgi scripting started to get supported on web servers and the moment the first web development oriented tools and languages started to appear (servlets 1997, asp a bit earlier, etc.)
After that, it has remained relatively impopular/obscure language with few/no obvious advantages over other languages and quite a bit of problems. Awkward syntax (yes it's an opinion but one shared by a lot of people who don't use perl), messy language semantics and unimpressive interpreter performance don't help of course. In all fairness, most scripting languages suffer from the last two problems.
So, I don't think it would make sense to pick it as a language for a new web application project unless you happen to have legacy perl code to integrate. That makes it a legacy language.
Jilles
Perl has no mainstream, normal, people yelling and screaming for it. There's just the older, gruffer programmers and, more likely, sysadmins. Remember how you thought about the 'awk' people 15 years ago? "We have seen the enemy and he is us."
"Newer" is always better to executives. Python, PHP, and even Ruby are new, hot, better - er. I have to admit, I'd rather create something new in ruby than perl. Obviously, forget asp, flash, silver-something or other.
The job market sucks people towards newer technologies. Would you want a new job writing perl or ruby code? Which do you think is more likely to help with your next position in 2 years?
PHP and Python have millions of web sites running. Perl just has a few well known sites (amazon, /., sabre) - although those few probably handle more transactions than all the php and python sites of the world combined.
The Ruby On Rails guys seem to have the right mix of technology, tools, KISS, training, and front men, if you ask me. The system is the power. Eventually, RoR will scale better and support huge transaction rates within smaller memory footprints, but not yet. The smallest memory I've gotten a Rails/Gem server working will under is 256MB - virtual hosting costs will be higher due to that memory requirement. When I need to upgrade my gems, I have to increase the memory for that VM to 512MB or it gets stuck.
So, is anyone willing to hire an old perl guy to work on RoR projects? I can learn quickly and I have an interest in the technology. Only $100/hr. -- that's the kicker. I figure some H1-B visa holder will get that job instead of me for $30/hr - I have 20 years of experience writing bulletproof code, not a fresh Associates Degree from India.
You're way cool shiny new L33t uber toy is yesterday's news? Sorry man, you got old.
Development Language choice is almost NEVER for rational reasons. Those few choices that are rational do it for financial reasons.
Financially speaking there's no good reason to have chosen perl in the first place. It doesn't do anything other
tools don't do and you have to pay for the learning curve or get locked in to those developers that know it.
Either way it costs your business money.
Get over it and learn what people want to pay you to program in. Or fade away. Your choice
-- Programming with boost is like building a house with lego. It's a cool but I wouldn't want to live in it
I learned long ago not to listen to corporate types if I wanted insight into something technical. It's not Perl that's the problem, it's the corporate types who make decisions with incomplete information and without the qualifications, experience, and knowledge to make informed decisions. They're in over their heads and look for any way to make a decision that makes them look smarter and gives them more influence, while hiding the fact that they haven't a clue.
I've seen many cases where one influential corporate type who is viewed by other, higher, corporate types as having a clue, will be the one who plants the bug that $language is legacy, inefficient, or otherwise bad. Usually that's not because that person knows his or her stuff, but rather because said person doesn't know anything about $language and wants to promote something he or she knows.
I've been involved in projects to replace perfectly maintainable code on well-maintained servers that's been running for many, many years with code that runs on somewhat more closed systems and will inevitably need to be upgraded in a never-ending cycle whenever the system vendor changes their paradigm and architecture. All because one corporate type had undue influence and the people higher in the chain, who won't be around for the next 10 years, want to show they're doing something and justifying their multi-million dollar IT budgets.
As others have pointed out, I too have seen plenty of unmaintainable code in every language. It's not the language that's at fault, and I might even argue that sometimes it's not even the individual programmer's fault but rather the fault of someone or some process that called for the program to be written in 3 hours just so that a project manager could hit their deliverable date. In the corporate world, my experience is that bad code comes more from bad processes than it does from bad programmers.
yep, that does sound like the solution to the problem Re-write the code in PHP or Java. They can't be written poorly due to their supperior design. NOT!
Sheesh... Perl a good language, I like it. I dread writting another web page in it myself.
Php is no better. It is just the cat gutted from the other direction.
Java is maybe, if it wasn't such a anal language.
I've been playing with WT (http://www.webtoolkit.eu/wt) which is C++ based. With it I get to write almost entirely in C++, it generates the Javascript, HTML and CSS. I need to only know a little HTLM, CSS and Javascript (if any) to make a nice AJAX page.
-- Many men would appreciate a woman's mind more if they could fondle it
I am so done with all scripting languages. The old advantages of Perl - regex and quick development no longer hold true. Every major language has regex and any decent ide allows for quick development turn around. If it is worth doing it is worth compiling.
Pretty much any language can be obfuscated, pretty much any program can be badly written. However it's harder to write really obfuscated code in some languages.
It's very easy for people who don't know much Perl to write really complicated code, doing the same thing in a more structured language(php, c, java) is much harder.
You can create some pretty awful code, but making code which is really difficult to understand involves either a really large program or a really skilled programmer.
"Hey, wait! Business people now think our language/tool is old and crappy because developers who only know the 'new and shiny language/tool' (or just need to sell some of it to make their quota) have gotten the business users to call our language 'old and crappy'. Our language/tool is not old or crappy. Why do business users think they know better?"
Welcome to the club! This has been happening to Lotus Notes for years and it has been caused by many many developers, some of which hang out on this site.
Lotus Notes is not email, it is a development environment and one that is still unequaled today for the combination of rapid development, reliability, functionality, cost, standards support and security. The problem is it is so easy to use that it gets used like a toy and badly coded/architected solutions get produced and, thus, its reputation gets tarnished not by the product, but by the developers who do no think they need to be professional. Sound familiar?
However, I have heard from absolutely non-technical people that Lotus Notes is 'old and crappy'. Gee, I wonder where they got that idea from? (Hint: Take a good look at the posts that will follow mine.)
In my opinion Perl is still too often listed on Monster and other job sites. It's an ugly, messy language designed by a linguist with an unfortunate idea that the fact that you call something a "programming language" means it should work like a human language.
Unfortunately the popular alternatives are not a whole lot better. But it's probably best if I stopped now, lest I be here all day.
... is Perl6.
"Corporates" hate investing in technology that appears to be on the verge of being made obsolete. Obsolescence means rewrites, and rewrites cost money. They would prefer to wait for the new version and just build with that.
Usually this isn't a problem since the wait between announcement of a new version and release is a couple years at most. But Perl6 has been threatening to obsolete Perl 5 for nearly a decade now, without actually ever materializing. That's scary for "corporates" because they can't plan their Perl6 migration. All they know is that at some undefined point in the future, they're going to have to do it, or move to another language altogether -- and in the meantime, every line of Perl they pay for is just adding to the potential future liability.
I know we'll hear from Perlistas that Perl6 is awesome, and for all I know it may turn out that way. But for years now all it has done is inject uncertainty into the case for using Perl, and uncertainty is something "corporates" try to minimize, for good reasons.
Read my blog.
If you're giving the situation of trying to deal with older code, I'd also recommend Perl Medic: Transforming Legacy Code by Peter J. Scott. It has advice for dealing with existing code of questionable quality, rather than the case of writing good code from the beginning. (in the case of dealing with existing code, I'd actually recommend it before Higher Order Perl and possibly Perl Best Practices -- I've never read the other two you mentioned, so can't gauge their relative usefulness).
Another book that might be useful is Perl Testing: A Developer's Notebook by Ian Langworth and chromatic, so that you can write better test suites to determine what you're breaking as you update the code.
Build it, and they will come^Hplain.
He describes quite succinctly why he moved away from Perl back around 2000:
The rest of the essay can be found here.
Its easier to blame the language that it is to hold people accountable for writing good code. There are two reasons for this:
1) Business types don't seem to know there is a difference between good code or bad code.
2) It would cost more to hire people to write good code. Better to switch to new language every 5 to 10 years and blame the old one for problems that could be solved with better hiring practices and code development over sight.
Think Deeply.
Perl -- The write-only language
If that's really your main problem, then it's very simply solved: just get a formatting tool, there are plenty out there - some are even quite good. However, all they'll do is give you pretty-printable files. The underlying structure of the code and the writer's thought process can still be messy and no language will solve that problem.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
And if you put bad coders on a project, or even if you give reasonably good coders insufficient support and have a poor process, you will likely get bad code as a result. It matters not if the code is written in Perl, Python, PHP, Ruby, or whatever your language de jour happens to be.
Perl is a perfectly good programming language. Personally I've written/been lead developer for several multi-hundred-thousand line perl web apps. Our code was perfectly clean and intelligible and quite maintainable.
CPAN is also a great resource, and frankly I haven't seen where any of the other dynamic scripting languages has anything similar that provides the breadth and depth of library functionality.
Some may say perl is 'dead', but it is sure alive and well in this neck of the woods and doing just fine, and nobody around here sees any pressing need to replace it with anything else. I can't think of a single language feature perl lacks or any other issue that would make me want to switch in particular. My feeling is it is a crying shame the scripting language community has balkanized itself so much, and a real crying shame we got that turkey javascript foisted on us. Far better would it have been if Netscape had just embedded perl instead of believing they could (and failing to) do better.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
As a manager, if he opts to get the IT systems developed in Perl, he is one of the stupidest guy. Perl is best suited for in-house test Automation [Microsoft Visual Studio Compilers Use this Env] + Many Other Vendors in the Industry where I have worked.
Other than that I have seen only Sys Admins using it. It is not true any more that mason or Perl is being used @ Amazon as they have more of C++ and Java code for their core operations.
I use gawk (Gnu Awk) for that job. It's the best tool I've found for rapidly re-writing hundreds of source code files on a running production system.
Arnold Robbins: "AWK is a language similar to PERL, only considerably more elegant."
Larry Wall, from audience: "Hey!"
find \corp\perl -type f -name \*.pl -exec fixbug.awk {} \;
Better be sure you know what you're doing before you press the button, though! I recommend building a cloned test environment.
If you blame your lousy code on the language, then you don't understand software engineering.
There are just as many crappy programs written in PHP, Python, etc as there are in perl, and you can make just as big a mess in any of them, trust me, I've seen it all in 25 years in this business.
Perl is actually a very elegantly designed language. Any decent team of programmers should have no more trouble designing and building a solution using perl than they would in any other scripting language.
The funniest thing about the perl bashing is that practically every concept now in vogue existed in perl LONG before it was adopted elsewhere.
CPAN, built in unit test and install harnesses, standardized embedded documentation. Show me a repository of libraries that is overall as consistently and well documented as CPAN, or anything near as comprehensive. Every other language out there has imitated perl and its related facilities.
Personally I have nothing against other scripting languages, but IMHO it is just redundancy. They aren't any better than their grandpappy The Camel!
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
You can write good code in pretty much any language, and you can write bad code in pretty much any language. Perl makes it hard to write good code and easy to write bad code.
Worse, Perl has so many syntactical features and shortcuts that aside from the experts, no two people know the same Perl language. People know enough of a subset of Perl to write what they need to, but when they have to read other people's code the syntax is tough to decipher. In a simpler language like Java were the tricks are in the libraries rather than the syntax. This makes some behaviors less elegant to program, but the new person can easily look up the class or function name. Syntax can be much harder to look up, particularly when it is one of the "assumed" values like $_ which you can't look up because it doesn't even appear!
Perl is a great tool for short scripts, particularly if the script will be thrown away after use. It's not a good choice for a large project. If you get the right mix of people, you could make the project succeed with Perl - that's true of most languages - but that doesn't make it a good choice in general.
I often don't like the choices people make, but I like the fact that people make choices. That's why I'm a conservative.
Oh "Perl"! We thought you said "peril" so we opted out, just to be safe.
Interesting to see Perl comparisons to C# or other languages that I would not consider to be replacements. I have always thought about software languages like tools in the toolbox and perl has always been a good language for processing text. If people are trying to use it for cad or who knows what else I have no sympathy for them. I have seen poorly written programs in every language and perl's text processing power puts it on par with doing stupid things in ANSI c pointers if you don't know what you are doing. You are never going to have power and idiot proof coding in the same language without sacrificing speed, leaky abstractions (look that up) or something else.
I don't think they hate Perl. And business people don't really care what technology was used to create the apps they are using. Companies just prefer to stay away from it for a number of reasons:
;-)
1) Perl is a write-only-language! Granted, it is powerful. You can build complex constructs in an elegant (to the sophisticated mind) and concise way, that's true. However it's powerful syntax is also its demise. It is extremely ugly and difficult to read, therefore it is very hard to support. Only the original developer (provided he/she is a real guru) can support a large system written in Perl. And we all know that the original developer is never there when you need him
2) There has been a significant shift over the last 20 years from UNIX-based development to Windows-based development. In search of productivity people started to use tool-based dev environments, visual IDEs, etc. Perl is associated with UNIX and it is perceived as something from the past by the new generation of IT people (that came out in the 90s and later).
3) Because of (1) and (2) not many people nowadays bother to learn Perl. It is hard to find people with ANY Perl knowledge, and real experts are even harder to find. So if you are a business man, and you have to make a decision on the tech platform for your next big project, would you choose Perl knowing that it will be extremely difficult to find workers with the appropriate skill set? I think not.
(I don't think it matters whether you're conversant in Perl, C, or whatever.)
:-D
CUR ALLOC 20195.....5804M
The problem is not PERL but the 'legacy' attitude that PERL was a Golden Hammer capable of solving every problem for the company, now the company has a new Golden Hammer and it will suffer with the same problem again in the future, probably well before it's replace all that PERL.
However that same 'legacy' attitude shows clearly in the blogger's mind as much as the original company; which is why he is upset that his hammer is getting tarnished.
The real legacy issue here is the language wars, dogma and rhetoric and the 'legacy' attitude that there is one tool for all jobs.
Of course Perl isn't dead.
so what if some bozo in a suit calls something "legacy"
"legacy" is simply any application that's in pure maintenance mode. hell, in some cases, legacy is simply a reference to an application that's no longer sporting that new code smell. Legacy is also simply a term to disparage, based on nothing other than the speakers opinions.
Lets see management CHANGE that code. that costs money. and working legacy code is much cheaper than writing a new system.
At my company, a VERY large one with an IT shop of thousands....the Python dudes won a culture war against the Perl dudes (and VB dumbasses, Korn dudes and others) and mandated that no more new Perl would be written, as Python was the new Grail. Lets see, that was about 5 years ago, and that same group begrudgingly had to approve Komodo purchases to "do perl" about 3 months ago.
yeah, they whined, they stonewalled, they demanded, but in the end, we just kept writing in Perl. with full management support.
because when the rubber hits the road, most front line IT managers are not complete idiots, and when presented with a whopping estimate to do essentially "busy work", even the most determined IT suit will capitulate to reason.
They may as well dictate the friggin' Weather as mandate all code in X be rewritten in Y (especially when X works perfectly fine)
Hear hear!
I used to rarely use "use strict" when I first began writing Perl years ago. Then, as I got to where the scripts got larger and used for more complex tasks, "use strict" got to be a habit. Nowadays I have a standard Perl skeleton that includes the shebang line, a header that I fill in describing what the script is used for (along with the RCS log, etc.), and "use strict". I might skip that directive for a quick-n-dirty script that I don't expect to use for more than a one-off task but it's funny how those scripts tend to get kept and reused. Once that happens, a "use strict" get inserted and I clean up the errors before doing anything else with it.
Writing obfuscated Perl (or any programming language for that matter) is a choice, not a requirement. If the code isn't easy to understand, I think it reflects more on the programmer than the language s/he used.
CUR ALLOC 20195.....5804M
Post dot-com-boom, companies wanted IT people to wear more hats: "We can get the same work done with fewer people! Wanted: Senior Oracle DBA; must know VBScript and Cisco VPN concentrators."
It mostly worked. The people running the infrastructure, who had intimate knowledge of the technology, were able to deliver applications & services that not only worked, but worked well. No committees & no politics; things just got done.
Code was written by people who understood the fundamentals of what needed to happen. Not by I-have-this-friend contractors, or my-friends-son-needs-a-job software developers, but by smart & deeply technical people.
These people weren't software developers. They wrote code using the tools at hand. By necessity: free tools. The code was developed in production. The phrase "But it worked on my desktop!" was never heard.
I'm not defending the practice, or suggesting that it's better. These people are writing code that someone else should have written, or to replace code that should have written vastly better. If you haven't done it; you've been sorely tempted.
Development can't use the tools the "hackers" used. They don't even want to discuss it; they're on their way to a meeting to try out some new buzzwords. They have budgets to justify and friends & relative to employ.
When my company needed an ISAPI to support a new architecture, I wrote it in C, in 2 days, and it's been running flawlessly for 4 years on 600+ servers. Now there's a need for another, similar, ISAPI, but this time we're going to do it "properly". Development has been working on it for 3 months, mumbles a lot about ".NET", and uses the phrase "But it worked on my desktop!" even more.
"Its because the Perl code has developed piecemeal over the last ten or so years in an environment where there was no design authority"
Who cares why? Perl sucks. Most newer coders aren't learning it because it's a PITA all around. From setting it up cgi-binish, to no nice frameworks. Every time I have to deal with something in perl it's jacked up - every time, every single time.
I wish it would go away, there are so many better options in this day and age.
Perl _led_ way to some great things, but now it's time for it to just go away. There is little gain, and lots of headache to the language these days.
Learn Ruby or Python and come along into the 21st century.
The parent post is genius.
He only forgot the part about how when the bridge is halfway built, they come back and say:
"We need the bridge to be at a different location on the river (enen though we didn't specify one in the first place)."
OR
"We see you're building a suspension bridge - we need it to be an arch bridge."
"Oh, and by the way, your materials budget and deadline haven't changed."
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
Edsger W. Dijkstra nailed it long ago with his assertion that a line of code is a liability, not an asset. (paraphrased from the original essay)
Gates has also been quoted as saying, "There's only really one metric to me for future software development, which is - do you write less code to get the same thing done?"
This is probably the only thing Gates and I will ever agree upon.
you had me at #!
It's Occam's razor for Pete's sake
William of Ockham (1287-1347) lived well before the standardization of spelling, although he did indeed hie from the town of Ockham.
"Entia non sunt multiplicanda sine necessitate."
Fact that there is to much f*cked up perl code, shows that it is an inferior language.
How did this garbage ever get modded up.
you had me at #!
That's simply being in a state of denial. Yes, it is possible to right relatively maintainable and legible code in Perl--but that's relative to other Perl code. And yes, the best Perl will be better than the worst PHP or Java (but that's mostly because PHP is like Perl, and Java is in many respects worse).
The worst Perl is worse than the worst of any other language with the possible exception of APL. That's fairly undeniable; anyone who has seen one of the four-line RSA engine .sigs knows what I mean. TMTOWTDI looks like a great idea until one realises that it often means that one man's idiomata are unrecognisable to another. The assumed values mean that data can be operated on without even being mentioned.
Middle-grade Perl is not bad, but it is simply not as clean and legible as, say, Python, Lisp, Ruby or in some cases perhaps Java (although modern Java is trying very hard to be uglier than Perl).
Perl was a great language when we were all used to awk and ksh. There's really no non-legacy (and I include the wonderful CPAN under that heading) reason to use it nowadays though.
I think Ruby has some of Perl's problems, but it seems to be in other ways pretty decent. Right now my favourite scripting/web language is Python and my favourite language in general is Lisp.
I suspect these truly are legacy systems, and the real issue is the programmers. There are a lot of sysadmin types that know perl inside and out, but don't understand how to make a user-friendly web interface (I work with a couple of these folks).
Perl can be used to make visually snazzy, up-to-date web systems just as well as any other language - you just have to understand the web end as well as you understand perl.
#DeleteChrome
In fact it is quite an elegant implementation which can provide practically any imaginable OO feature anyone could ever want.
bless($self,$package);
The ENTIRETY of perl OO syntax and it manages to encompass all the hoohaa that requires a bizillion tons of features in other languages.
The beauty of perl OO is you are NOT put into a straightjacket by it, and things like reflection, introspection, AOP, etc are just plain dirt simple. Just check out Conway's book if you doubt.
Beyond that there are simply things you can do with OO perl you would be hard pressed at best to do in other scripting languages. I'll take perl's implementation of OO any time. It rocks.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Tcl! Tcl! Tcl!
I wonder if tacked on object-oriented is a good idea in any language?
Like Javascript, you mean?
Today, you can do sysadmin stuff with php at the cli, but is it a good idea?
Not really.
Is Corporates a real word?
I'm primarily a Java developer for a large Corp and wouldn't you know it that after 5 years and some 200 + developers touching the code it is...... hard to maintain and a big_ball_of_mud.
Perhaps the mentality of the developers at the time of the project creation are to be considered? Perl typically is used as the excellent Swiss Army Knife that it is to do scripting and then wouldn't you know it the app gets more and more requirements. So the original developer didn't know, didn't care about, didn't need to know about good programming principles to get the job done and then people bitch in retrospect.
Chances are the original design fit the need for what the business was willing to pay for and provide requirements for at the time.
The problem isn't really Perl. The problem is that Perl was used to create applications that aren't maintainable. That combined with the fact that Perl allows any programmer to do anything and you end up with a confused mess. This is not to say I haven't seen some decently coded Perl applications, but they are few and far between. That goes for most any language but even more so with Perl as people have consistently tried to do things in Perl it wasn't meant for.
You end up with codebases that try for OO in syntax alone, poorly and wildly differing formatted code, race conditions, etc etc. Part of this is design but the bigger issue is that Perl wasn't designed originally for that space.
Unless you have a team dedicated explicitly to X version of Perl with X modules and classes and that have a strong structure and background in best programming practices. Any Perl application will turn into a nightmare; more quickly than any other language.
All of the above combined with the fact that web frameworks in general are non existent for Perl. As it was used literally as glue language (a space between Shell and C), and if you needed a framework; you built your own, which is usually a mistake because you NEED strong OO in a web framework. After going through that exercise it's obvious why all of the strongly based OO languages picked up frameworks much faster than Perl.
They have to have it explained in costs.
You have to defend why the use of the existing Perl code, is cheaper to maintain, then rewriting everything in the new language of the month.
I am Bennett Haselton! I am Bennett Haselton!
Indeed its code is such a macro hell, and so complex and so huge that "almost" nobody dares to clean its code base. But if there is a bug, BOOM!
C and only C for GNU/Linux or die
You can infer from the low UID of my account that I've seen one or two of these "perl sucks" kinds of articles. There's a flamewar. There's mention of python or ruby or C or java. There's the old saw "perl is too complex", "perl doesn't have an IDE", "perl is line noise". But it takes awhile before someone just calls it right: there's a lot of bad perl code because there's a lot of bad perl programmers.
That's not a knock on Perl.
Perl is powerful enough that even crappy programmers can do useful work. That's saying something positive about the design of Perl. That Perl allows bad code also says something positive about the design: it's not a fascist regime.
Now, if you need your language design to prevent the creation of unmanageable code, you'll be looking for the language for a very long time.
So next time we start this thread about Perl being bad, let's just skip to lambasting the crappy coders and leave Perl out of it please.
Your corporate bosses need to be educated about the maintainability of Perl code versus other languages. So show them the winner of one year's obfuscated C code contest and tell them this language is the latest rage in the software community. Then show them an equally short snippet of Perl code that is written for visual attractiveness and ease of maintenance and explain that this is Perl. It doesn't take a great genius, or even a programmer, to see than clean Perl code is more maintainable than obfuscated C code. Clearly, the Perl is better because it is more readable and maintainable than some obfuscated C code. Once they agree, show them the winner of the obfuscated Perl contest. Then explain once again that the language is not related in any way to how good or bad the code is. It has everything to do with the programmer and nothing to do with the language. So if the latest rage is language X, you can turn that into a nightmare, too.
O'Reilly is selling zillions of Perl programming books. Every bookstore with one shelf of computer books has something about Perl. Obviously, it's not a long-lost forgotten language.
McCain/Palin '08. Now THAT's hope and change!
Somebody needs to say it short and simple: Python, for the win!
I highly recommend The Daily WTF?. Perl does NOT get a disproportionally large representation there.
An incomprehensible Perl program is a "dog bites man" story.
What's the matter, bored with arguing why emacs is better than vi or vice versa? See August 1999 on python-list's archives for your exact question. If only you folks could have waited one more year, this could have been a commemoration of the 10 year anniversary. Actually, if you do go look up that thread, read this one instead, it's not nearly so stupid, just the opposite: Tom Christiansen compares Perl and Python
I'm fortunate enough to work somewhere that is still very happy with Perl. Yes, there are reams of very old, very poor quality Perl code, as described by the Fine Article, but there are also a few nuggets of newer, shinier Perl, and we've added two really good Perl developers to staff recently.
It's amusing that the excuses not use Perl go from "There are no developers" to "It's old technology" -- Perl developers may be hard to find, but in this market (Toronto) it appears it's because they're valuable. And old technology doesn't mean 'out of date' -- to my mind, it means 'seasoned' or 'proven'.
Perl is still a viable development tool -- the community and the language are alive and healthy, whether or not the suits like it. And you can write bad, out-dated code in any language, including Perl. Sometimes the suits and the HR department don't get that.
Perl has been notorious for being hard to maintain since its creation. The thousands of cute syntax features, which any given developer might know about 50, are the cause of this problem.
If you want to use a junky weakly typed language, where you can write the same block of code ten million ways... use PHP. Do not be surprised when that is thrown in the junk pile also.
Spend some extra 50 hours of your life learning an enterprise oriented language such as java, M$ .NET if you are concerned about job security.
I think if I show someone perl code, and then show them python code, they're going to feel a lot more comfortable with python. Perl's $, %, and @ variable prefixes, file i/o weirdness (print $_) and other way-too-shorthands are seriously intimidating and foreign looking as compared to python. Python's regular, sensible indentation makes an impression of regularity and comprehensibility as well. Python's just a cleaner technology by nature. You can make Perl look pretty good, but you have to work at it.
I know I'm a lot more comfortable with Python, and I wrote in Perl for many years. Basically until I discovered Python, then that was the end of Perl for me. :)
Just a thought.
I've fallen off your lawn, and I can't get up.
I think there are four kinds of developers: *Ones that are good at design *Ones that are good at implementation *Ones that are good at both *And college kids (no offense college kids). I think the trouble comes in when corporations don't consider the consequences of matching work to skill set, or putting too much responsibility in the hands of the inexperienced. IMHO with all of it's issues, bad Perl code is really just a symptom of bad management.
It's dangerous for managers to cling to buzzwords, and assume that making the buzzwords go away will fix things.
Reaching this point with Perl speaks of a development culture that will recreate the same problem in a few years with [insert cool new language here]. They didn't understand (or perhaps didn't listen to those telling them) that code maintenance and understanding are even more important than having the code written in the first place.
It is possibly to write maintainable Perl; they aren't doing it, and that is the "legacy" they need to get rid of.
"Microsoft killed my company, I hold a personal grudge. I don't use Microsoft products and neither should you."-JWZ
Nobody is obliged to write obsfucated perl code.
When comparing "normal" perl code to normal C++ or Ada or Java code, the perl code is more concise.
As a result, one line of perl take more time to write or to read.
But the real thing is that the equivalent perl code takes far less time to write even if it takes the same time to read.
It is so easy to code in perl that people do a lot of error checking that are omited in other languages. I have always less bugs in my perl programs than in programs in C/C++ (in Ada, most of the bugs are found during compilation).
The benefits of perl are mainly time and bugs. You can't attack Perl on these.
In perl we use often regexp. Most of them are simple regexp. Some are complicated and are difficult to read (not to write).
Add a comment to explain the regexp and stop complaining.
The program using regexp is generally a lot more robust than the algorithm we would use in another language without regexp.
Fewer bugs, better error checking, less code to maintain.
The only drawback is can imagine is that perl requires to have good bases in computer science and is old-fashioned.
I would love to use a new language in the hype that would be as effective, but it remains to be invented.
"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."
This is the problem, not Perl. Unless this is fixed, whatever shiny new technology you use now will be in the same state as the perl code ten years from now.
I can stay away from it for a year, and immediately write in it without having to look at a reference.
I use bash every day, and for anything requiring a logic operator or comparison, I have to look for an example.
I have several scripts that depend on another guy's (poorly implemented) 'database'. He has a bunch of bash scripts to parse it. We are going to move to a real database. I wrote a module for the (current) method. On the new system, I'll change one module, and all of my stuff will continue to work. Bash guy not so lucky. Not to mention parsing that stuff is a lot easier with a lot less overhead in perl vs. a crapload of calls to cat | grep | cut.
here I am reading this article in a classroom... in a class "Introduction to Perl Programming" ..... how ironic.
PERL lends it's self to bad code practice.
Unreadable piles of crap is not good for business.
I've written my share of Perl, but sometime I think I am the only person who writes it in a way that anyone can read it. Leaning matchstick issues are bad.
Perl is good, I like it. I've just seen too many people trying to use it in the most obscure way possible.
The Kruger Dunning explains most post on
The same kind of arguments were made in support of C: that hard-to-maintain spaghetti code is not the language's fault, it's the developer's. But the bottom line is this: if the language fails to enforce some basic good coding practices, then the code won't be easy to maintain. It's difficult, if not impossible, to find and hire the kind of talent across your organization that can keep the code maintainable and readable. It's just as hard to review all the code to ensure it meets your development standards, and train junior engineers on how to do it properly. Therefore, just having Perl or C code to maintain means you are almost guaranteed to have harder-to-maintain code, that has to be worked by more-senior developers. Those very developers are who you need plugged into new projects that require senior developers and out-of-the-box thinking. If they are tied up cleaning up the spaghetti that other engineers produce, you lose productivity across your organization, and your senior guys want to quit.
Java, .NET and other shiny new languages help in significant ways in making software products easier to develop and maintain. So Even though I can code nice C code, and I can handle pointer arithmetic and memory allocation well, doesn't mean I can find all the resources I need to ensure that same level of development in all my products.
Anything serious, production-kind software should *not* be written in Perl. Perl was never designed as a production quality languages. It went through rather radical change of syntax several times. It allows to accomplish the same task with gazillion different ways, no doubt members of Church of St. Larry Wall rejoice, but those who are to maintain the obfuscated and obsoleted Perl code do not. I had that experience maintaining set of tools written in Perl for First-Tier Internet provider.
My revenge: I re-wrote large chunks of code using *my* idioms and then completely bailed out from the project, and subsequently from the company. Let someone else maintain my code and cry.
I think Perl blew it by the inordinate amount of time Perl 6 is taking. I am surprised nobody mentions this. Pythona and Ruby on the other hand have good roadmaps (especially Python). They make releases like clockwork, they're always in the news about new frameworks and some cool stuff. Perl usually is in the news for the wrong reasons, mainly about why Perl 6 is so delayed. Perl has simply lost mindshare. Oh, I know Perl has not really stagnated. Perl 5.x series has been making steady progress but that only appeals to people who're already using Perl. For newer people taking up a scripting language, Perl seems like it's past it's prime. Besides, let's admit it - the language is arcane; especially the OO stuff in Perl 5. I even find OO interfaces in perl modules unintuitive. If someone likes Perl and wants something more "clean", modern and shiny, I'd recommend Ruby though I personally prefer Python.
Don't mistake me. I was (and still am) a big fan of Perl - mainly Perl 4 though. It's one of the most powerful languages that I've used. Even today, I usually start writing something in shell (because I am throwing together a bunch of programs to get my job done). Then I hit the limitations in shell and usually port the program to perl. That said, I have mostly switched to Python, especially when I am starting to write something from scratch.
The problem is that perl encourages bad programming because of it's language constructs, as well as it's low barrier to payback.
I've worked with perl for years, and I despise it. The people whose systems I've had to maintain are despicable, and they do stuff like:
$a[$a]
which confounded me at first. It's because they used two variables, each named "a", however, one was a hash and one was a scalar. This is because perl has two separate namespaces between hashes and scalars which to me as a programmer is unfathomable.
Most perl programmers are sysadmins or lesser-talented programmers, that don't know anything about engineering code. The problem with perl is that the barrier to actually seeing results is very low, which could be a good thing, but it encourages people who can't really program to program.
Up until recently I'd had a similar opinion. Then I started work on a new project and began noticing all these interesting technologies.
Some exciting technology is being developed using Java. Check the trove.
Quack, quack.
Anti-Globalism recommends a posting up at O'Reilly's ONLamp on reasons that some companies are turning away from COBOL.
"[In one company] [m]anagement have started to refer to COBOL-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 COBOL. Business users, of course, don't want nasty old, broken COBOL 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 COBOL code. But I maintain that this isn't directly due to the code being written in COBOL. Its because the COBOL 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."
+5, Funny
I work for a company where there is a lot of Perl. The issue we keep seeing is that all the newly minted, out of school 'programmers' only know Java and are afraid to work on Perl because they've been led to believe that there is no future in it. On top of that, their Java background tends reduce their exposure to many important programming concepts (which makes them less hireable)
Meanwhile, from the corporate managers' point of view, there are lot more Java programmers out there and they are cheap worker bees. Good Perl programmers are becoming increasingly rare end expensive. The truly talented ones don't need to look for work.
All of that makes Java people easier to find and afford.
Businesses should make their decisions based on technical reasons in order to be the most efficient machine and provide the most, most efficiently ( with least cost ) to their customers while charging their customers what the market will bear. But that is totally not what happens unless the software IS the business. Even then it doesn't always happen.
So software produced by businesses is crappy, badly designed, hard to maintain, and gets moreso the longer the piece of software exists. Eventually, it becomes so inflexible and expensive to maintain that it makes sense to replace it. Switching languages makes it easier to justify replacing the software rather than incrementally changing it. The real reason the software is being replaced is that it is crap, but trash-talking the language it was written in is a good way to sell the idea of replacement with something that will be worse, probably sooner rather than later.
...
I'm primarily a Perl programmer, though I do some Java and Ruby.
Someone mentioned Damian Conway's book 'Perl Best Practices' and all I can say is that if Perl had had that book 10 years ago it would have a better reputation than it does now. In my 15 or so years of experience with Perl I think that its worst problem is the Cowboy Coders, who often mistake obfuscation for genius. It sure seems like the early days of Perl were also the days of Cowboy Coders. Books like 'Perl Best Practices' try to salvage the best of Perl from the worst practices of the Cowboy Coders.
On the other hand I have no sympathy with those who don't like what Perl looks like. I may be fearful of sharp knives too. But if they get the job done better than a blunt one then the thing to do is learn how to use them. Perl's brevity can lead to difficult to read and maintain code but it also makes it very powerful. Much can be done in a small space. Using Perl, along with the guidelines of Damian Conway, I think anyone can write very good, powerful, legible and maintainable code. It is not a bad language.
However there are times when trying to hold in my mind exactly what some 4-5 level deep dereferencing variable in Perl really refers to that I prefer the more verbose but easier understood style of Java. Perl is full of shortcuts. They are very powerful, but sometimes do require a lot of concentration before their meaning can be understood. For someone who uses Perl everyday the shortcuts probably make perfect sense. For everyone else it can take a long amount of staring before any of it makes sense. Does this make it bad? I don't think so. It's just that it's not as immediately comprehensible as some languages. On the other hand imagine a Perl programmer faced with the verbiage of Java. The same type of blank look sometimes comes over my face when I switch from Perl to Java: I think, my God, there's a lot of verbiage here. Why does it have to be so big. Why do I need to declare the type of the variable not once but TWICE? What could be worse than that?
The one thing I can say about Java is that rarely do I run across a surprise because something is in a scalar rather than a list context. Java is pretty straightforward. Perl has a lot of things, like context, that aren't straightforward.
Finally I have to wonder about Groovy, Ruby and other popular scripting languages. Why in the world does Java need Groovy (about which I confess I know little)? From what I can see some people are seeing the virtues of scripting languages, especially dynamically typed languages. So it looks like Java users are a bit jealous of the ease of scripting languages of Perl, even with all of their possible problems.
To me it's understandable: a scripting language can be great for getting something done quickly. It's just that if very good coding practices aren't followed the code can either have hidden bugs and/or be difficult to maintain.
To conclude I think that the very presence of languages like Groovy show that there is always a demand for scripting languages. Perl is among the best. It's just got an awfully dirty history and a lot of bad habits that may need to be overcome to make it as popular as it should be.
Perl is just plain hard to maintain.
Very few people know how not to use all the things that obfuscate a perl program.
Even good perl programmers have trouble understanding perl code written by other good perl programmers who use different idiomatic constructs.
And not many people are learning Perl as deeply as they did when it was newer, which makes it even worse as a maintenance problem, and a drag on developing your entry-level maintainers into good programmers.
And perl 6 is supposed to use Parsing Expression Grammars which are even cooler. If you think translating a regular expression into hand-coded crap that is probably wrong then you're an idiot. That's why people use things like yacc/bison for writing parsers. That kind of coding is hella tedious and hella error-prone without useful abstractions like regexes. And all the other languages have regexes now because they are a very useful tool including ( insert your favorite ). Sorry, but when parsing something I'm gonna use them whatever language is foisted on me. And you can use some simple rules to paste regexes together in ways that make sense. You can translate ( mostly ) the entire URI rfc for instance into regular expressions using the bnf. There's only one funny ambiguity that requires a special rule. The regex is frikken huge, but the small parts it's built of are easily understandable. Try doing that without a tool like regexes in a way that is *CORRECT* and *COMPLETE* allowing you to parse out all the bits in the rfc and you will fail. Remeber with regexes you can paste them together build them up with (?:) my $parta = '(?:..)'; my $partb = '(?:...)'; my $whole = '(?:' . $parta . '|' . $partb . ')';
...
Perl has several problems compared to other development environments. First, Perl has weak data types. Second, Perl is not so easily scalable than Java. Third, Perl-code is hard to maintain, because of its history. Fourth, modern programming concepts, like OO, components, packages etc. have been added at a later date with several shortcomings compared to modern languages.
Strong data types are important in today software development, because it allows to find errors at compile and even write time compared to run time. Run time errors are more complicated to find, reproduce and fix than compile time errors. Also run time errors might not occur for month, but then corrupt your database and crash the system. This can be really costly.
The second argument, is about scalability. While for EJB and other such component based systems, there exist working (which means stable) replication and distribution systems, which allow adding nodes at run time (or at least with zero system down time), Perl does not have comparable environments.
Another scalability problem is based in the used coding styles. While Java (but you can use C# as well) enforces certain programming principles and support transparent use of RMI (RPC), Perl lacks this ability. Java code therefore easy to read, even though you have to read a lot of syntactic sugar. But thanks to modern development tools, the talkative nature of Java can be dealt with using programming environments, which can create most of the class, method and package bodies. This is not elegant. No. But it is effective.
The next point is maintainability. Perl has a well
earned reputation as write only language. Contest where people wrote "squarish programs" (who can write the smallest program in form of a rectangle, which does something useful?) helped building this reputation. However, today other features of a language are more important. And therefore Perl becomes obsolete in major business applications. This does not mean that there is not a place for Perl-programs. But in these modern SOA and BPEL-based software systems, using Grid- and Cloud-computing (sorry for the little buzzword collection) Perl is not the right choice.
If you look at the way technical academic papers are written, there are mathematical expressions that those outside the discipline don't understand. The text surrounding the mathematical expressions is there to make the intent of the math transparent. But no one in their right mind would try to get technical academic papers to use formalisms that weren't succinct just because it would make the math more "readable". On the contrary -- it is the job of the reader to learn the new formalisms with the assumption that the author introduces them only when necessary (profitable in more succinctly describing the model of the world expressed).
Yes, bad scholars will behave the way bad coders behave and create new symbols and/or new constructs rather than reusing existing -- well established and widely understood -- ones. This is frequently due to a lack of intelligence (leading to ignorance of prior symbols).
The goal of coders should be first to come up with the right formalisms -- the most succinct "math" if you will. If necessary, they should relate this form to previously accepted optimal forms -- and make a damn good argument for the new forms where introduced. They should then make their succinct formalisms intelligible by surrounding them with explanatory prose, the way an academic paper explains its succinct formalisms -- and provides cites to the relevant prior works.
There was some move in this direction with something called "literate programming".
Most Perl constructs that frustrate readers are no more onerous nor less useful than highly used formalisms in academic papers that make expressing things in a rigorously precise, and ultimately more intelligible, manner practical. The annoyances attributable to the Perl4 -> Perl5 transition are relatively minor compared to the unintelligible things that appear in the code of most programmers in any language.
Seastead this.
Amen! The importance of GOOD organization, thinking, planning, conventions, etc. are by far a bigger issue than specific language or tool. The difference between say Perl and Python are not near enough to override the difference between thoughtful coding and hack-a-crap coding.
Good coders like to see their clean and thoughtful designs pay off in adaptability, features, and productivity. Bad coders hop from fad to fad to get bigger bucks and padded resumes.
Table-ized A.I.
Have you actually seen the Perl syntax? It's a horrifying mess designed for people who like twisted grammar puzzles and cryptic codes (and cyptics like RMS who think that recursive acronyms are cool). To express anything clearly in Perl requires a frontal lobotomy and a C-section at the same time (yeah, even if you're male).
It's such a freakish language that it's got syntax for syntax rather than a very clear simple syntactic idea like LISP or Smalltalk or Self or, fuck, even C is easier to comprehend than Perl.
There's an article over here that covers some points why Perl sucks the big one and doesn't even suck well at it! When a language sucks at least I want a good blow job!
http://smalltalk.org/articles/article_20040914_a1.html
Basically Perl sucks because you need this to figure it out:
http://www.ozonehouse.com/mark/blog/code/PeriodicTable.pdf
Professional systems people want their systems to be clear and as easy to grasp as possible, Perl provides the opposite. We ONLY use it when the existing system is using it, and then we only do maintenance bug fixes (lots of those) and do not under any circumstances add new features to programs written in it!
The above are a few reasons that Perl is ostracized from the corporate space and should be excised from your brain.
If you want to hack your way through life, fine, be cryptic and use Perl. If you want excellent systems that perform and get results use a language that helps in that regard: Smalltalk, Lisp, C. Avoid Java, C++. Heck use Assembly Language before Perl!
Spoken like someone who believes that writing unmaintainable code is the best form of job security
No, I'm arguing that the practice of layering code in particular, and data hiding in general, makes code more expensive to maintain. If you want to have a good program code, rather than try and write a bazillion layers, write as simple as possible and then have lots of code to test it. Given the same overall number of lines of code, your approach gets you a system that looks good on paper, but is completely unproven, but I'll have a completely automated testing regime to go with mine. Which is better?
This is my sig.
I still use Perl for quick-and-dirty stuff, small scripts that I will use once and then throw away. Often it's a one-liner, like "cat out.txt | perl -ne 'if (/\s{3}(\w+)\s/){print $1}'", or something like that. But for a really clear to understand and maintain software, I think Python is *much* better than Ruby.
Ruby fans hate me for this, but I sometimes say that Ruby is Perl++. Or, in other words, "it's the syntax, stupid". Although I don't really like the forced indentation in Python (what if someone else used tab characters, for instance?), I think Python has the best syntax of any language when it comes to readability. Oh, sure, people can still write 600 line functions in Python, but they are easy to read lines.
Ruby, OTOH, doesn't have a coherent syntax. Code blocks sometimes are declared between curly braces, but in other cases they have a generic "end" statement (does anybody here remember Fortran?). And too many of those funny characters you get when you press shift plus a number key. And many other details, each one not so important by itself, but in the end it all adds up into code that's significantly harder to read than Python code.
.. and yet hate the abomination that perl is.
IANAL but write like a drunk one.
One way to mitigate all the nuttiness that lazy developers put into Perl is to take the suggestions from a script called 'perlcritic' on the -harsh setting.
Doc for Perl::Critic
On our team, we have developers that are hackers to college interns. This stops the hackers from writing illegible punctuation explosion code and stops interns from making common mistakes.
You got it wrong, it's not only corporates that hate perl. A lot of programmers hate it too. Duh.
What a bunch of hokey reasoning. There is no special or sinister reason "Corporates hate perl".
The programming world just needs to move from Perl as soon as possible so that more programmers can keep their hair.
I recommend pearl beads in my asscunt. Huge ones. Like >3 inch a piece!
Shove them all up until i have to vomit from the pressure, and then rip them out, nearly ripping me apart.
That would be fine.
Your regexp example isn't awfully good - any language that has regexp support will have lines like that. These days, PHP has regexp support (possibly always has), C has regexp support, C++ has it, Java has it, and I expect that even C# has regexp libraries.
That's quite true. And in many cases, regexp support comes from this regexp library.
Perl is UNIX's Visual Basic. Give a money a perl interpretter and they'll manage to make some cryptic script that gets the job done, but would never be useful to another scripter.
While perl might actually not suck in itself, the overwhelming perl user base often does. I strongly believe that the same goes for PHP.
Hello?
Most of you missed to real point: all those languages and frameworks are huge and most of the time insanely complex pieces of software. And that's really bad (just have a look at perl code, openjdk code or mono code). We are talking about millions of complex line of code, most of the time requiring the complexity of an optimizing C++ compiler... that's sick...
The most reasonable option is to take into account the whole software stack and reduce to the maximum its size and complexity. Then I stick to C and only C and keep in mind all the time maintainability. As far as I'm concern the upper threshold of complexity and size is (linux+optimizing C toolchain). Then I build everything on top of this software stack and no more.
Judging from the various animosities expressed in the postings on this topic, it seems apparent there are two types of Slashdot posters on this topic:
(A) Those that actually DO program in Perl
(B) and those that don't
Whether OO is being fixed in Perl 6 is very much a matter of opinion. It's certainly being changed, but it was reading the planned directions for Perl 6 OO that made me learn Ruby. method doit (::?CLASS $self: $a, $b, $c) { ... } and $locator = -> $root, $x, $y { $root.[$x]{$y}[3] } ? No thanks.
Sure, you can adopt best practices and write readable Perl code. The problem is, eventually you have to use someone else's Perl code. My experience is that I'm much more likely to be able to understand someone's Java or Ruby code than anything on CPAN. That holds true even for bad Java code that throws up a zillion warnings in Eclipse/PMD.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Replying to myself: there is of course a good reason for declaring the type of a Java variable twice. I wasn't thinking when I wrote that. Still it does make Java seem very complicated compared to the straightforward 'x="anythinganytime"' of Perl.
"Business users, of course, donâ(TM)t want nasty old, broken Perl code. They want the shiny new technologies."
Java and PHP aren't "shiny new technologies", duh...
"Itâ(TM)s because the Perl code has developed piecemeal over the last ten or so years in an environment where there was no design authority which encouraged developers to think beyond getting their immediate task done."
Duh... remember Larry Wall and his stated philosophy wrt Perl?!?
"Many organisations are in the same situation, with large amounts of unwieldy Perl code..."
Errr... yes. Exactly why you would want to staty away from Perl as much as possible.
"can rewrite our systems to take account of everything that weâ(TM)ve learned in the last ten years..."
Yep in a better language than Perl...
Okay the trouble here is that you guys keep thinking this is a technical issue, but it just isn't
First of all, it's debatable whether "corporate" types in general "hate perl" -- no doubt some of them do, but you can also find many companies with successful perl-based businesses who aren't going to switch to the language-of-the-month just to keep up with the Joneses.
If there's been a shift away from perl (and I have my doubts there really has been), it's almost solely because a lot of people who like to pose as uber-geeks have been talking trash about it, and the reason they've been talking trash about it is almost solely because they feel insulted by Larry Wall. Over the years Larry Wall hasn't been shy about explaining his design philosophy, which is essentially that computer science nerds have an irrational addiction to ideas like "mathematical elegance", when computer languages are tools for human beings to use -- so he looked to linguistics for inspiration.
Now, if you want proof that this is essentially just talking-trash and not anything like a reasoned debate, consider the situation with PHP. Until recently it didn't even have namespaces. By any objective standard, you would expect a CS geek to regard PHP as a piece of garbage compared to perl -- and yet, the uber-geek hit squad is rather silent on the subject, no?
On the plus side: I find it somewhat encouraging that if you look at the actual market penetration of things like Ruby on Rails, essentially no one is using it, despite years of intense hype from many quarters -- it could be that the suits are finally making technical decisions based on something besides nerd-chatter.
Well, yes, it really is true. And further, plug-ins are apparently a severe pain to implement in a cross-platform way -- I use AMD64 boxes myself, and there's still no native flash plug-in, for example. And if firefox extensions are any guide, we can also look forward to plug-ins breaking when you do browser upgrades.
Further, the entire premise (what the web needs is more languages!) is fundamentally flawed, because it obsesses about the technical characteristics of languages, and ignores the social aspects -- as you get more languages in play, you sub-divide the community of developers and complicate the sharing of techniques and so on.
Much easier to daemonise communists^Wterrorists^Wforeigners^Wperl than to admit a management failure that allowed business critical systems to get into such a poor state.
I am genuinely greatful to you for replying for providing me with the first well written response to one of my Slashdot posting. After a long time of posting on this site, the frustration of receiving unjustified flames has driven me to write most of my postings in a model that invites flames.
Your response has provided me with at least a little faith in the direction that there are in fact rational people participating on this site.
While I also avoided the web early on, seeing it as little more than glorified desktop publishing, I can see parallels in my experiences to nearly everything you said.
With every popular platform of development there will always be some language or tool which appeals to the general masses whom will utilize the "simplest" and cheapest technology to accomplish their goals. After all, for the most part, many of these people desire to get their projects up and running, they themselves don't actually know the difference between clean and sloppy coding styles.
Now that I think of it, during my lifetime, there was an obvious trend towards BASIC derivatives (GWBASIC, QuickBasic, Visual Basic) until recently when languages like Perl, PHP, server side JavaScript, and C derivatives took over.
Being a chronic C++/Assember coder through and through I will say that since the beginning of the web, I have classically insisted on the use of interpretted languages (or environments such as virtual machines) for web based applications since I have long believed that even superb C++ programmers could not possibly reliably produce compiled code securely. A quality interpretted language will throw exceptions when memory boundaries are violated where compiled languages require the developer to provide that functionality explicitly.
Well off I go to work on my current project, which today requires me to track memory leaks and to perform bounds checking on a code base of 1.2 million lines across 400 modules written by 20 in-house developers and 100 open source guys. Sometimes I really like interpretted languages.
>RoR in a week that would've taken 4 weeks in Java.
Well NO SHIZ SHERLOCK
Try comparing RoR and Trails or Ruby and JAVA, not RoR and JAVA
[to me]
I have never studied Russian. Others who have studied Russian, but only briefly, will surely agree that Russian is not readable. [to them]
All reasonable, intelligent people will find vacuous the argument that "Russian is not readable" when spewed from those not literate in Russian. Why is it, then, that in discussions of computer programming languages, the very same argument is so widely considered valid?