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.
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!
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.
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
Dim Perl As String.WriteOnly
If You = Well.Disciplined.Person And Write.Comments(UBound(Perl.Lines) = True Then
If Decrypt(Flow) Then
Such Things Happen
Elseif Other.Languages = (C++ Or Java Or Python)
Decrypt.Method += Hard
End If
End If
If Syntax.Contains("$") Then
Return Format(My.Opinion, Humble) & "Bad Syntax"
Else
Return Format("", Opinions.Null)
End If
Ok, so the code sucks (in VB no less)... but, I just found the way you wrote your comment kinda weird...
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;
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.
From a manager's point of view, yes. Because it makes it easier for the company to find someone who is capable of maintaining it once the 133t haX0r has moved on to another job.
Besides, don't underestimate the importance of clarity and modularity in architecture. Which is not the same as "coding standards" that enforce things like naming schemes for variables. The latter is rather low-level and understandable to a PHB, the former is still more of an art and not easily measurable.
C - the footgun of programming languages
I worked in a shop that replaced a really complicated process that had been written in COBOL, with :-)
a really efficient, compact, regex-based, DBI-enabled perl program. I'll let you explain to them
why that's inappropriate for their enterprise scope...
-fb Everything not expressly forbidden is now mandatory.
>IMHO, a syntax where you have to prefix a variable with a special character ($ in Perl's case) is a bad syntax.
The argument isn't really about syntax; it is rather the strong-typing versus weak-typing argument,
and that is worthy of far more investigation than simply declaring it "bad".
-fb Everything not expressly forbidden is now mandatory.
chomp is not ambiguous. RTFM and stop crying.
http://perldoc.perl.org/functions/chomp.html
This safer version of "chop" removes any trailing string that corresponds to the current value of $/ (also known as $INPUT_RECORD_SEPARATOR in the English module). It returns the total number of characters removed from all its arguments. It's often used to remove the newline from the end of an input record when you're worried that the final record may be missing its newline. When in paragraph mode ($/ = "" ), it removes all trailing newlines from the string. When in slurp mode ($/ = undef ) or fixed-length record mode ($/ is a reference to an integer or the like, see perlvar) chomp() won't remove anything. If VARIABLE is omitted, it chomps $_ . Example:
If anything I'm crying harder after reading that.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
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.
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.
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.
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.
Sometimes it is a matter of not being able to deliver due to lack of architecture. Read, the side effects in the non-architectured spaghetti code finally reached the point of overwhelming the programmers.
If you managed to avoid this situation with sufficient foresight, it is not always obvious. After all, maybe a simpler system would have done the job too?
Besides, the point of not being able to deliver due to lack of architecture usually comes later in the lifecycle, and the first versions may be quite successful. So in some cases, the badly designed terrible little programs win by being first and becoming the "industry standard".
Now the obligatory dig at Microsoft... ;-)
As far as I can tell from the user perspective, Windows seems to fall in this category. For the second time:
-First time, Windows 9x was quite successful for a while but ended in disgrace with Windows Millennium. Fortunately for Microsoft, they had developed the much more solid Windows NT line in parallel, on which they then built Windows 2000 and XP.
-Now, it seems Microsoft has managed to overextend its architecture again with Vista. This time I don't see a better product line in the background that could take over. Let's see what happens over the next five years
C - the footgun of programming languages
If you give your variables/functions meaningful names (ie: $StoredPrice instead of $st, savePrice() instead of sv()) then half of your reading problems is fixed already.
I'm truly tired of that laziness. Well written codes should need the minimum of comment. Oh...And by the way, tabulation and don't play the genius coder while trying to put as much as instructions per line. Split them wisely. Then everybody is happy, whatever the language is...It will be readable.
My main concern with Perl is the object oriented feature, for the rest, it works like a charm. The synthax isn't that hard, the problem is the lambda Perl coder bad habits IMHO (trying to be the most cryptic possible), it is purely cultural and it has nothing to do with the language as far as I know.
None of the things you mention improve clarity, modularity and maintainability.
Well possibly wrapped accessors, but only when called for.
What i meant was avoid clever-but-stupid shit like displaying
how much crap you can get done with a bodyless for-loop,
deep if-trees that might save you a superflous comparison or
two, but take all day to read correctly and correctly implement
a really simple change in the underlying rule.
If you do database access, data representation, transformations
and file output, please don't do them all all over the place.
You don't need to amake a plugin architecture, but it really
doesn't cost much to design a simple output module API so it might
be switched with a completely different output engine later.
And guess what: it will make your code clearer and better even if
you never make that second output module.
sudo ergo sum
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.
... 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.
He describes quite succinctly why he moved away from Perl back around 2000:
The rest of the essay can be found here.
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.
Perl has no mainstream, normal, people yelling and screaming for it. There's just the older, gruffer programmers and, more likely, sysadmins.
Yeah, the same sorts of idiots who still use UNIX, Emacs, C and Usenet (with that whole snipping and bottom-posting weirdness). Some of them probably even grok Lisp and wasted their time learning prehistoric nonsense like assembly language. Don't even get them started on documentation, or designing code before writing it; if you even mention unit tests, they'll just mumble something about understanding how code works before changing it. What have people like that ever done for the world, anyway?
You know, one day it would be really funny if these dinosaurs decided to take a sabbatical for a couple of months, all at the same time, and let the younger generation and their high-tech advances run the show for a while. Then management would see how much more effective you can be with a 3D GUI in your OS, a visual IDE, web application frameworks and wikis!
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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
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.
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 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.
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.
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!