Why Corporates Hate Perl 963
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."
Age (Score:4, Insightful)
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...
Give the yahoos what they want (Score:3, Insightful)
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.
To be fair to the corporates (Score:5, Insightful)
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.
Re:Ockham's Razor tells me.... (Score:5, Insightful)
What makes me laugh (and cry at times) is these same businesses, who insist that programmers and administrators are hard to come by, turn to ridiculous metrics like "how many lines of code do you write per day", and require x number of years of experience with technologies which just came out this year (and have yet to be proven.)
Let them have their H1-Bs, and the deadwood with the inflated resumes. Good riddance.
Face it, Perl IS hard (Score:4, Insightful)
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.
Re:Sometimes the correct answer is the simplest (Score:5, Insightful)
Possibly not the best example of why perl is shunned.
Perl is simply not winning the marketing war.
Why Corp. hate Perl? (Score:5, Insightful)
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?
"Hate" isn't the right word. (Score:5, Insightful)
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.
Software or line noise? (Score:1, Insightful)
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.
Re:Why not Python? (Score:3, Insightful)
Python's syntax pisses me off.
I primarially program in Perl, PHP and C/C++ which all share virtually identical syntax.
Makes it a lot easier mentally and you can still use the right tool for the job.
This isn't just about "new and shiny" (Score:4, Insightful)
Re:Why not Python? (Score:5, Insightful)
Very simple:
* the user has deep knowledge of perl but not of pythong
* the program needs certain libs that are easy available for perl but not for python
* the user is not very keen on the syntax of python
* there already exists a lot of perl code & libs that can be re-used and would need to be re-written to python
whenever you start something from scratch in a different language you have to see if it pays off. If you already have tons of libs & classes and knowledge in one language there is no need to write it in another again.
That's why I code my scripts still in perl, because I know what I am doing, I am fast, I get it done and I have classes that help me do the things I want to do. I see no reason why I should start again in python. I really don't have the time to re-do everything from scratch ...
Re:Sometimes the correct answer is the simplest (Score:5, Insightful)
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.
The alternative to a regular expression is usually a very convoluted parser that's a lot of effort to support.
Re:To be fair to the corporates (Score:5, Insightful)
Hell I've seen developers say C/C++ are "dead" and that shiny_language_x is going to take over.
That may be not so much fadism as well-informed wishful thinking.
OK, plain C is not _that_ bad, but you do need to fight its innate spirit in order to implement sane coding practices.
But I recently had to return to C++ on a recent project, and although I was expecting some tedium, it was way worse that I remembered. MY GOD how painful it makes a lot of really trivial things. Even the nasty hack known as PHP starts looking well planned in this light.
It may be better than alernatives if you really need the performance and low-level capabilities, but if you don't (or only a small part of your project does), you're paying a huge price for wizard points you don't need.
Glitzy clicky interfaces do not a good product make, but a platform where _some_ thought has been given to workflow really is something we should start to expect in this day and age.
Re:Ockham's Razor tells me.... (Score:4, Insightful)
How many internal/script-driven systems have you seen
over "a few" years old
maintained by at least "a couple" different people,
that don't end up a train wreck?
The need to revamp a system is often more a question of when.
So, you get to that point, and the question becomes:
do we keep this funky old perl,
or start from scratch with something relatively tidy and
popular from a staffing perspective?
Re:Perl too readable (Score:5, Insightful)
I respectfully disagree. Which languages are easier to read and which ones are harder is of course obviously subjective. So maybe for YOU perl is easy to read. However, I myself have never, ever read or written (or written and then later read) perl code that was easy to read. There are lots and lots of very very small symbols which have very large effects on Perl code. Single characters can completely change the meaning of statements in perl. Sure that's true in many languages, but perl takes this problem to a whole new level.
Perl will die if people in general find it to be too troublesome to write and maintain. I personally have been in that camp for years and years. This article suggests that this is a global trend, and I say, good riddance.
C++ and perl are such different languages, that it's not really useful to compare them. They live in completely different parts of the programming language space. So it's not very useful for me to say that I find it much easier to write maintainable C++ code than perl code, even though it's true.
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++.
Re:Perl IS the problem (Score:5, Insightful)
Is it really fair to blame the language? I think the reason perl is the centre of so many big balls of mud is that it is easy to do prototypes in it. If people choose to take those prototypes and turn them into big balls of mud, then that is their own fault. If you start with a clean sheet of paper, do a good design and then decide to implement it in perl you won't end up with a big ball of mud.
Re:Sometimes the correct answer is the simplest (Score:3, Insightful)
s!(?:^|\w*/|\.\./|\./)[^\s,@;:]*(? Interesting? Thats a one line regexp which does something which appears to be very very simple to do, but actually isnt.
That looks really simple? Sorry but it doesn't look to me. Perl may be a a very very powerful language, but that alone does not make it a language of choice.
For a company to choose a language, one should not only consider the power, but also the maintainability. One should not only consider how a strong programmer would perform in it, but also how a beginner can screw it up, and how a beginner can understand a powerful program.
These considerations make Perl generally a bad choice. As a simple test, download 50 perl programs at random, download 50 python programs at random, compare the quality. Fact that there is to much f*cked up perl code, shows that it is an inferior language.
Re:heyho, python - the new perl. (Score:4, Insightful)
so, what happened to java? I liked it, it never went away but seems to hover on the edge.
On the edge of what? Java is the biggest programming language in the world today. It dominates the web and mobile phones, and although it's not quite as popular for desktop programs, it's not uncommon there either.
It's not a scripting language like Perl, however, so if your world looks like Perl, you may not notice Java that much.
Your assertion that Java 'dominates the web' is laughable, as applets have been a near-total failure, replaced wholesale by Flash- and AJAX-based systems, while on the backend PHP, Perl and more recently Python and Ruby have eaten Java's lunch. Where Java has succeeded is on big iron and with corporate accountingware (it is the new COBOL, much as C# is the new VB), and on mobile phones (as you stated), with some moderate success on the desktop.
How about the right tool for the job? (Score:5, Insightful)
-- Larry Wall, author of Perl
I rest my case.
I don't get it (Score:3, Insightful)
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.
Re:To be fair to the corporates (Score:3, Insightful)
It's true that programmers fall victim to fad-ism, but the fact is that the learning curve of Perl is quite steep compared to that of PHP. PHP (and, arguably ASP) brought something to the table that Perl lacks -- readability, comprehensibility, expandability.
As far as RoR is concerned, it's nothing new -- it's simply a framework (a very young, immature one, at that, in terms of software maturity) that could have been written in ANY language (PHP on Rails, anyone?). This is why we're seeing RoR developers get frustrated and go back [oreillynet.com] to PHP!
I haven't heard many PHP developers going back to Perl.
Re:Sometimes the correct answer is the simplest (Score:5, Insightful)
For example look at this s!(?:^|\w*/|\.\./|\./)[^\s,@;:]*(?<=/)([^\s,@;:]+?)(?=[\s,@;:]|$)!$1!g;
But this "Perl" code is really a regular expression which is also used in PCRE and PHP and so on. Copied because it was the best there was.
To improve readability of a regex use best practise and use /x (with whitespace and comments) and stop confusing Perl and regex.
Re:Ockham's Razor tells me.... (Score:4, Insightful)
"So they might try to have it reprogrammed in something popular (Visual Basic? *evil grin*) only to find out that a change of programming language will not magically cure their woes."
1. It's their money.
2. If it's not (#1), then it means you are in a position of decision making authority and can rectify the situation in a suitable manner.
Seriously, as long as your work environment involves calling decision makers "THEY" you really don't have a dog in the fight.
Why aren't you in an authoritative role by now, if you're so experienced, talented, knowledgeable and skilled?
It's no different from the other 10,000 slashdot posts where a decision maker was a "them", and somebody else's money was at risk.
Re:Ockham's Razor tells me.... (Score:5, Insightful)
There may be some architecture and best practices you have to meet in carrying out your implementation which is what this article is about I suppose. Perhaps integrating with other systems forces you to use a particular tool or language. However, in general you can do whatever you want as long as you fulfill the user and business requirements.
That could mean perl but usually we think of that as being a fancy bash script with perhaps a bit of database interaction rather than a platform for writing server-side (or even client-side?) apps.
Re:Clarity and whatnot is for retards. (Score:5, Insightful)
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.
Re:Perl IS the problem (Score:2, Insightful)
Perl doesn't help but its not the problem. The problem falls on the people writing the code and the demands made on them.
My current berth is typical of this. We've been given a 'system' that requires a degree of scripting to be done to glue the various discrete parts together. A combination of Perl and Ksh has been chosen to do this. Why? No idea, those choices were made before I joined the project. Looking at the people writing the code, none of them have any sort of development background. Add to this the demands from the business that the 'system' has to work yesterday, means that a lot of hacking together of scripts has gone on.
The result is that some of the code is practically unmaintainable by anyone but the person that wrote it. This isn't the fault of the language though, its the fault of the developers. With a framework of modules in place the newer code is readable and easy to maintain. Its the older stuff that we just poke with a stick. No Perl doesn't stop you writing bad code, it doesn't make you write it either though.
Getting back to the original topic. A lot of Perl code was written around the time of the dotcom bubble, when there was a shortage of IT staff. The result was that if you could spell Unix and Perl you could get a job. Everything was fast paced, had to be first to market. Corners were, frequently, cut. The result was people with inappropriate skills developed systems without spending the necessary time spent in the design phase. Corporates have had to deal with the fallout from this when people have said "I can't fix that, I'll have to rewrite it". Instead of looking at the bad practice that generated the code they are blaming the language. Other languages may protect, somewhat, against these bad practices, I doubt that they instantly make code maintainable though. I can write bad code in any language, its experience and professionalism that means that I chose not to.
Re:heyho, python - the new perl. (Score:3, Insightful)
There's one big diifference, however: python is a well-designed, highly structured language. Perl sort of grew organically from a couple of scripting languages, and had OO pasted on later.
You can argue that Perl's OO is pasted on, which is somewhat true, but that doesn't mean that it isn't powerfull. Try Moose [cpan.org]. Certainly OO is a thing being fixed in Perl6. Until that is available use Moose or try to realize that OOP isn't the only form of programming.
Saying indirectly that Perl5 isn't well designed, just pisses me off. It grew organically, but changed during these years and got refined. If you keep to best practises, Perl code can be as readable as any language and even better as it is more powerfull.
Re:Perl is WRITE-ONLY language. (Score:5, Insightful)
>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".
Re:Ockham's Razor tells me.... (Score:1, Insightful)
.
Further, the external impression for over 5 years now is that Perl/Parrot is a dead project. There are no iterative improvements, it's a build-from-scratch restart with completely new foundations. Now the apologists will say that the 5.x series receives new software on CPAN and so they don't need feature X. I mean really, listen to yourselves. If you didn't love Perl you be elsewhere -- the apologists explain exactly why Perl is dead. It might do a Firefox/Phoenix and rise from the ashes in 5 years but -- unlike Firefox -- Perl isn't filling a hole. Other languages have shown they are more than capable at pulling up the slack. Perl/Parrot suffers from exceptionally poor project management.
.
And to be honest I'm happy with syntax problems, a dead project and a public impression of decay. Unlike 10 years ago the language doesn't deserve your praise anymore -- it's not earning your respect and you should acknowledge that. Nostalgia is a good reason to like Perl or to think fondly of Pluto as planet, but the world has moved on and you should too.
.
Perl is deprecated. Python and Ruby are where it's at.
Re:heyho, python - the new perl. (Score:4, Insightful)
On the edge of what? Java is the biggest programming language in the world today. It dominates the web and mobile phones, and although it's not quite as popular for desktop programs, it's not uncommon there either.
It's not a scripting language like Perl, however, so if your world looks like Perl, you may not notice Java that much.
Your assertion that Java 'dominates the web' is laughable,
No, it's your suggestion that applets are even relevant to this discussion that's laughable.
Have you ever heard of servlets? Have you head of the dozens of web frameworks that run in them?
You're living 10 years in the past. Right now, Java does dominate the web backend. PHP and Perl are hasbeens, and simply not suitable for the large scale web applications of today. Ruby is deifintely up and coming, but is still a long way from eating Java's lunch (though I'm sure that will happen someday -- I hope it will, because Java kinda sucks).
Re:Ockham's Razor tells me.... (Score:3, Insightful)
I've tried to 'repair' a broken perl app and indeed it was much quicker to toss it and rewrite.
Perl is worse than 'mumps' and that's saying something.
(mumps anecdote: What, you've reset that string ? Oh, great that was the systemwide editor...)
Programming tricks (Score:4, Insightful)
Whenever you think of a clever programming trick: forget it !
Re:Sometimes the correct answer is the simplest (Score:4, Insightful)
s!(?:^|\w*/|\.\./|\./)[^\s,@;:]*(?<=/)([^\s,@;:]+?)(?=[\s,@;:]|$)!$1!g;
"You have a problem, and you discover you can solve it by using regular expressions.
Well, now you have another problem"
I read this in the opening of a regular expression chapter of a Python book by Tim Peters (though the quote is certainly not exact); so I am unsure whether he was quoting somebody, or not. Anyway, the point stands.
Re:Sometimes the correct answer is the simplest (Score:5, Insightful)
s!(?:^|\w*/|\.\./|\./)[^\s,@;:]*(? Interesting? Thats a one line regexp which does something which appears to be very very simple to do, but actually isnt.
That looks really simple? Sorry but it doesn't look to me. Perl may be a a very very powerful language, but that alone does not make it a language of choice.
Well that is a regular expression, not Perl. It's a different language, and is the standard way of handling strings in most programming languages. To be honest, I first learned about them in a formal language [wikipedia.org] class in college, years before I picked up Perl.
If you don't like regular expressions, that's your choice, but it really has nothing to do with Perl, and you should try to understand them, as they are very useful, even outside programming.
Quality vs Complexity (Score:5, Insightful)
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.
Re:Perl IS the problem (Score:3, Insightful)
A good worker picks his tools carefully so he doesn't have to blame them. If you're forced to maintain a bunch of code and you can choose the language would you prefer to maintain a batch of perl code or a batch of python or C code ?
I've done all three and I really *much* prefer C over both python and perl and python over perl.
I'm sure that you can write very beautiful code in Perl the first time out, but that goes for any language, the real acid test is what you get after 10 coders have touched your poetry over the course of a few years maintaining a project and adding new functionality.
Or it could be that humans connect dots (Score:3, Insightful)
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.
Re:Ockham's Razor tells me.... (Score:3, Insightful)
to me the biggest issue is maintainability, some languages help you in that department, some hinder.
Perl makes it easier than even C to write obfuscated bits of code that even the author has a hard time understanding a few months later.
I've seen perl used to create job security for it's coders, in that respect it is the new assembly language.
Yes, it's not just Perl code that has developed piecemeal over the last 10 years or so, it's Perl itself, with things like OO being rather clunkily bolted on. It does feel to me like a language that was great in its time but has had it's day and needs to stand aside. No doubt Perl experts will continue to produce useful scripts as they always have done, but more modern technologies make it easier (including easier to get right). And that will turn into a maintenance issue for even well-written Perl code: when finding Perl maintainers gets to be as hard as finding COBOL maintainers, and for the same reason.
Re:Why not Python? (Score:3, Insightful)
What lack of readability? All my Perl stuff is very readable, and it's easy to follow what's going on.
Myself I almost never have a problem reading my own code. It is generally other people's code that are hard to read. You will only have an honest idea of how readable your code is when somebody else has to start maintaining it.
Re:Perl IS the problem (Score:5, Insightful)
The language itself is not the problem, but the 'community' and their promotion of it may be. I have seen good Perl written by good corporate developers, but that's despite the available Perl tutorial and examples.
I can't recall seeing a Perl learning resource that presents code that is well structured, commented, and tolerant of bad inputs. That leads me to suspect that Perl attracts developers who take pride in hacking together "Works For Me" code in the shortest possible time using the fewest, tersest lines. Yes, you can do that in a C-like language, but Perl lets you get your "good enough" result faster.
When Perl is promoted by impatient, sloppy bodgers, it's no mystery why it would attractd similarly minded developers. It doesn't have to be that way, but that does seem to be the de facto situation.
Re:Perl IS /your/ the problem (Score:1, Insightful)
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! :)
Re:Ockham's Razor tells me.... (Score:5, Insightful)
Lines per day is frequently proposed and sometimes implemented. But it's also easy to kill, just do that little refactoring job you've been putting off and put in a report of minus two thousand lines.
They tend to get the message after that.
Re:Ockham's Razor tells me.... (Score:4, Insightful)
I can only speak for investment banking but "lines per day" is not a metric which I've ever seen people actually use.
Some people use it, but on its own it's a really bad metric. A top quality developer will do the same task in far fewer lines of code, with better reliability, than a poor quality developer. That means metrics based on lines per day alone may identify the worst programmers rather than the best.
Re:Sometimes the correct answer is the simplest (Score:4, Insightful)
So your argument boils down to "perl is unmaintainable, but that's ok, because you can just replace code instead of maintaining it".
You must write bug-free code if you never have to make small changes to existing code. My hat is off to you sir.
Re:Ockham's Razor tells me.... (Score:5, Insightful)
At my last job, I wrote a perfectly good perl loader for a large data file we'd bring in every night. They decided to kill it off and go with BusinessWorks instead. BW took 45 times longer (I shit you not -- 45 minutes instead of 1 minute) and broke every week. We finally got sick of the support issues and went back to perl.
Fact is that shiny pointy clicky just introduces complexity and additional points of failure into the infrastructure. If you want the latest buzzwords, then by all means, go with shiny pointy clicky. If you want your system to work, keep it with tried and true.
This has been said ad nauseum: There's nothing inherent about perl that makes its programs unmaintainable or broken. It's all about getting programmers who know how to write maintainable, well-designed code. A bad programmer can make an abortion of any programming language or fancy pointy clicky system.
Re:Sometimes the correct answer is the simplest (Score:3, Insightful)
Fact that there is to much f*cked up perl code, shows that it is an inferior language.
I'd say it shows that there is a lot of perl code out there. There was a time when Perl was one of the only scripting languages that people wrote crappy code in, but now people are free to choose from Python, Ruby, PHP, Java, or other languages to write crappy code in. However, since Perl is older, more crappy code has been written for it.
I challenge you to take a random sampling of code written in the last five years, in different languages. When you exclude code written more than five years ago, you might find that Perl fares rather better, comparatively.
Re:Sometimes the correct answer is the simplest (Score:5, Insightful)
Interesting that you got modded so high, despite failing to understand what the GP was saying.
I'm not positive what that regexp is doing, but the presence of / and ../ or ./ matches suggests it's manipulating a directory path in some way. After a few tests I think it may be intending to return the filename portion from a path, but if so it's a little buggy (and a good example of why reinventing the wheel isn't a great idea; just use basename).
You do make a point, but I feel your method of comparison is a bit questionable. While Python is a fairly old language, it's only seen general use for a very short period of time compared to Perl. That means that a) there's likely to be a lot more Perl code around than Python code, and b) a lot of the Python code that's around will be of high quality.
The main reason for this is that when a language first begins to be noticed, it's usually going to be embraced by people who want to show how good it is. They'll take extra care to make sure it's well written and easy to understand, because they're evangelizing the language. As a language ages, people will be using it who really don't give a crap about the quality of the code, and that will "pollute" your sample set.
Accessibility will also have a lot to do with it. Even when PHP was a pretty new language, a random sample of code would reveal it to be vastly inferior to just about every other language you could possibly think of. A lot of this is simply because PHP became so widespread that virtually every cheap (and many free) web hosts supported it, so every newbie who wanted to learn to program started with PHP.
A new programmer -- or a bad programmer -- can write terrible Python code just as easily as they can write terrible Perl code. But at least it will have proper indentation. I would be very hesitant to base too much of my assessment of a language on its "newbie safety factor". Else we'd all be using BASIC and Logo.
Re:Perl is WRITE-ONLY language. (Score:4, Insightful)
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.
Re:Clarity and whatnot is for retards. (Score:4, Insightful)
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.
Re:Ockham's Razor tells me.... (Score:4, Insightful)
Re:Perl IS the problem (Score:2, Insightful)
I think the reason perl is the centre of so many big balls of mud is that it is easy to do prototypes in it.
You're very right with that, but there's more.
In many cases, Perl allows you to reach your programming goal easily, without much effort. But this unfortunately also means that it encourages quick & dirty programming. Just scribble down your code and the job is done; it just works. In other languages that are less powerful/flexible in their syntax (that does not mean restricted in their possibilities!), like C, C++ or Java, you normally have to write a lot more lines of code. This not only makes the code more readable in many cases, it also urges you to think more about what you are doing. If your programming task will take a lot of time to implement, you will try to find an optimal (or at least, good) approach, a better solution to it, make it reusable, use a design pattern - you will just think more. And the time you invest in the design is well spent, as it may save you unnecessary effort in the coding and debugging phases.
Okay, so a C/C++/Java/whatever programmer will need more time to design and implement. Perhaps. But that's not all: primarily, you must be able to design your software. You must know your design patterns, your algorithms, your best practices. Without that knowledge, most languages will give you a hard time to create working code. Heck, with many languages you will not even make it to "Hello, world" without compiler warnings if you don't understand how it works.
But not with Perl. It makes your start quite smooth. You don't have to declare your variables, care about strange #includes or imports, just write print "Hello, world!" and it will compile and execute (and you will not even see these different steps). And unfortunately, this also means -- and that is also my experience with a lot of beginners in different Perl forums and on the Usenet -- that Perl is more attractive to those who do not have a formal education in software engineering. They do not have to wade through thick volumes about "C++ in $smallint days", just to find out how to convert a string into a number, split an input line at commas, or grab a page from the Web. They will soon find a quick&dirty, one-line solution in an online tutorial or a forum that can be pasted into their code without even breaking the rest of it or make the compiler scream (no beginner will use strict or warnings pragmas unless urged to). It will not be the most efficient solution. It will probably break when the input data vary a bit. It will likely be full of security flaws (but at least no buffer overflows!). But it will do the job and give even the hobby coder a (false) feeling of competence and aptitude.
PHP has even more of that "easy for beginners" nimbus (sorry, folks), but Perl does not stand much behind. You can see the results most obviously in a lot of the CGI code that can be found on the Net. (Anyone think of "Matt's script archive"?)
So, is it the fault of a programming language that it is attractive to non-programmers? Perhaps. I'm not the one to judge.
If people choose to take those prototypes and turn them into big balls of mud, then that is their own fault. If you start with a clean sheet of paper, do a good design and then decide to implement it in perl you won't end up with a big ball of mud.
YES, absolutely! But it is just so easy to get persuaded by Perl to do it quick, sufficiently working, and dirty. *sigh*
I took the bait myself far too often.
Re:heyho, python - the new perl. (Score:3, Insightful)
Right now, Java does dominate the web backend.
In what context? PHP/Perl and to a growing extent Ruby have scads of hosting options for public projects to fit every budget, which means companies and individuals of every budget can write or use web apps and make them available publically at a domain name. This doesn't require any sort of weird mod_rewrite hacks or anything of the sort.
Website hosting for Java-based apps is abysmal (and more expensive) by comparison. It's far more complicated to set up and maintain, hence fewer orgs offering it, less competition, fewer innovations, and more expensive service. It's also far more memory hungry than typical PHP (and perl, etc) apps.
There are dozens of web frameworks to run Java apps. So what? There are dozens of web frameworks for PHP. And you can deploy most of them in a couple of minutes on almost any shared web host out there.
It may 'dominate' the 'web backend' in certain vertical markets in internal usage at many companies. But that's defining the 'web' pretty narrowly.
Re:Sometimes the correct answer is the simplest (Score:5, Insightful)
The problem here is that small != mean efficient.
Parsing the code is not what makes a program slow, and
we don't code for 1K or RAM anymore.
"impressive" oneliners completely fail to impress me.
Lines are cheap.
Time is not.
And bugs are expensive as hell.
I'm sure if you wrote code that walked through the
steps in what you are trying to achieve, all the
following would be quicker:
* for me to see the point of what you're doing
* for me to correctly change what it does.
* for you to get it working right in the first place.
If you feel it is childish to write code like
"find A"
"find B based on A"
"generate C based on B"
"silently fail for some values of C"
"replace B with C"
-rather than one giant, brittle regex-replace, I submit that you are the childish one.
Re:Ockham's Razor tells me.... (Score:5, Insightful)
Good grief, how is "deliverables" a stupid metric. Either you deliver a working solution/program on time or you don't. Thats the deliverable. Bascially your saying that having and goal and having to deliver anything is stupid.
Re:To be fair to the corporates (Score:3, Insightful)
Sometimes I get the impression that the prophets for the Cs' demise might keep being wrong from quite a while, this has been predicted even since the nineties and the Cs are still around, I think that more dynamic languages focused in easy to use and fast development of mediocre apps are good things, however they are more likely to replace each other than to replace the Cs which are meant for another kind of application.
I mean, python's all right as a language, but even if python took over - someone will have to code the interpreter...
Re:Perl IS the problem (Score:5, Insightful)
Perl attracts developers who take pride in hacking together "Works For Me" code in the shortest possible time using the fewest, tersest lines. Yes, you can do that in a C-like language, but Perl lets you get your "good enough" result faster.
For me, that's the strength of Perl. I don't use it for anything other than works-for-me type small tidbits of code. Will it require maintenance, or extending, or support by other people? Then I don't use Perl, because it's complex enough to warrant a strict language. In essence, text parsing and one-off scripts are fantastic, other stuff I stay away from.
Re:heyho, python - the new perl. (Score:3, Insightful)
Sorry, "hasbeens" is a strong word for a language (PHP) that can run that behemoth we call Facebook. I don't know exactly how much code is behind it, but it can't be small for the stuff they're doing.
Re:Sometimes the correct answer is the simplest (Score:3, Insightful)
You don't have to understand how to read it, beyond grepping for comments and function names.
This has to be the single most retarded thing ever to be said in the context of software development.
Re:Perl IS the problem (Score:4, Insightful)
People on this board blame VB all the time for bad programs. Perl doesn't get a pass.
(That said, I agree with you, I don't think you can blame the language for bad code; I *do* believe a language can contain features that encourage bad code.)
Re:Ockham's Razor tells me.... (Score:3, Insightful)
I can only speak to the reasons for going with PHP and JAVA in our company. For one, PHP is really maturing as a development language, JAVA is well supported, and maybe over the years I kept running into some of that poorly designed PERL and it left a bad taste.
I keep hearing this comment about PHP, but every time I look at the language I come away unimpressed. A typical PHP install can have as many as 4000 functions in the global namespace, and there's not even a clear naming convention to be found.
Really: addcslashes, count_chars, str_getcsv, str_shuffle, strlen, chunk_split -- this is just a small selection of the functions dealing with strings.
A brief aside: I used to live near Pittsburgh, PA. It's a great city, with great people. But it has bridges. LOTS of bridges. 446, to be exact. More bridges than Venice, Italy. I used to joke that it was like we built a small town at the center of three rivers when rivers were a primary means of transporting goods, then were taken completely by surprise when it grew.
I only mention this because that's kind of how I think of PHP. A good community, with a ton of nice people who have nothing but the best of intentions. Yet, when I compare PHP to something like Perl or Ruby, I always come away feeling like PHP just kept tossing up bridges as it grew, without taking a step back and looking at the big picture.
Re:Ockham's Razor tells me.... (Score:3, Insightful)
Oh, please.
First, let me ask, are you a professional software developer or project manager? (I'm not being arrogant, I'm just curious).
I've got more than a few years under my belt.
A developer gets a spec. He designs a solution and quotes the spec. Assuming he's given the green light, he schedules the projects start date and sets some milestones.
I've worked for DOZENS of companies, large and small, in all economic sectors, as both a contractor and a FTE, and invariably it's some variation on this theme.
The developer designs a solution and sets the schedule.
"Deliverables" means nothing more than the developer hitting the milestones/delivering the artifacts that he set for himself.
In smaller projects, this could be the entire application. In large projects, it's just a single function point.
You can bash the vernacular of the business all you want, but you don't offer any better solution.
If I'm being paid $50/hr to tap a keyboard, shouldn't I be held accountable for results?
Re:Perl too readable (Score:2, Insightful)
You are making the common ignorant statement made by many people and are assuming that Perl is all regex.
I've actually have written many Perl programs that make no use of regex.
If you are ever writing stuff you don't understand later, what it means is your skills as a programmer as severely in question. That is what comments are for. In fact Perl makes documentation a breeze with POD.
Re:This isn't just about "new and shiny" (Score:3, Insightful)
Python, I can agree with, but Ruby? It effectively looks the same as Perl when it's all said and done. It encourages the same use of odd characters, shortcuts, whitespace issues, and poorly managed namespaces that Perl does.
Disclaimer: I'm a Perl developer.
Re:Sometimes the correct answer is the simplest (Score:4, Insightful)
A new programmer -- or a bad programmer -- can write terrible Python code just as easily as they can write terrible Perl code. But at least it will have proper indentation.
And we all know that proper indentation will never break anything.
TAB Code
TAB Code
SPACETAB Code
TAB Code
TAB Code
How long would it take you to debug that problem? It took me two hours the first time I tried to learn Python (reading someone else's code) and that's why there hasn't been a second time.
Re:Perl IS the problem (Score:5, Insightful)
Yes, it is.
It's like saying "Most Basic & VB Code is Verbose, is it really fair to blame the language?"
YES!!
Every language has a unique idiom. And the best languages use this idiom to painlessly guide the developer to best practices.
For exammple, lots of devs consider Java to be over-engineered and overly-complex. You've probably heard a dev talk about building something in, say, RoR in a week that would've taken 4 weeks in Java.
That's probably true, because Java is a tool best designed for large applications and when you're using Java, it's idiom guides you into building multi-tiered architecture.
Python's idiom guides devs into producing well formatted code and it's a great language for web apps because it puts powerful data structures right in the developers face.
C# is a FANTASTIC language for teaching OOD to procedural developers. It's HARD for a procedural developer to think in terms of object hierarchies. The mechanics are easy to pick up. The ability to deconstruct a problem into an object hierarchy is hard.
But you put them in front of a new project in C# and the language -- entirely OO itself -- just guides a developer to the right thing. It's very hard to shoe-horn a procedural architecture into an OO-only language.
JavaScript makes it insanely easy to create an event-driven application. Anonymous functions, LAMBDAs, etc, guide a developer into producing code in an event/event-handler model.
Any developer can do nearly anything with any language. But a language itself can make it easy and obvious when you're doing things right, and painful for you when you're doing them wrong. And a good IDE will reinforce both of these behaviors.
Re:Ockham's Razor tells me.... (Score:3, Insightful)
I'm a developer, not a manager. I have been lobbying for the use of Ruby or Python for all new development (we used to do it all in Perl). The simple reason? Perl is a write-only language. Larry Wall knows this, and that's why he's spent so many years trying to make Perl6 a clone of Ruby.
I realize that with enough time and discipline, Perl code can be written in a more maintainable form. But that's swimming against the current in the busy business world.
Ruby is taking hold, and most of the new apps being developed are in that language. Perl is quickly become "legacy" around here.
[oh yeah, and Perl's terrible object model and use of POINTERS for complex datastructures (FFS!) are pretty embarrassing]
The Real Reason (Score:3, Insightful)
... 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.
Re:Sometimes the correct answer is the simplest (Score:5, Insightful)
So true.
I switched to Python because I could not market Perl to anybody including myself.
I was using it from time to time and would try to convince coworkers to use it too.
But the readability issues and the lack of keywords made it more difficult to look for documentation etc.
As a result I could not market it to my coworkers and started having serious doubts myself. So I switched to Python.
Suddenly, I could convince my coworkers easily as it looked good, readable, easy to learn by example etc.
Also Perl and Python are very similar in what they offer (regexps, hashtables, string parsing, networking, modules). But Python usually offers a language construct to support important software engineering concepts (e.g. objects are native and not reimplemented every time as in Perl).
Just my 2 cents. I tried to love Perl and market it around me. But I couldn't. PHP, Python, Linux, Wikis are easy sells but Perl is not.
Re:Why not Python? (Score:3, Insightful)
no, but I really don't feel a need to go back to the seventies when 'significant whitespace' was all the fashion.
Especially the fact that tabs and whitespace are visually indistinguishable and will cause your code to suddenly not work is a real hoot. Similar gripes apply to makefiles and DNS configuration files that need significant tabs in some places. Utterly ridiculous.
Try switching editors, importing a chunk of code using cut-and-paste with a non-python aware tool and so on.
IMNSHO this was the biggest possible stumbling block that they could have installed to avoid large scale python adoption, it seems to have worked admirably so.
I'll give you this though, perl is worse :)
Re:Ockham's Razor tells me.... (Score:4, Insightful)
For some subjective metric of "better"...
Re:Ockham's Razor tells me.... (Score:5, Insightful)
Sometimes. Sometimes, management gives you a deadline with the spec, and you don't have the ability to set your own schedule.
And sometimes, the spec is something like "Somewhere in the jungle is a river. Build a suspension bridge over it."
"Do you have a map of the jungle?"
"No, it's unexplored."
"Do you know how wide the river is?"
"No. I told you, the jungle is unexplored."
"Is there a road through the jungle to the river?"
"No. The jungle is unexplored. But look, you've built dozens on bridges, just tell me how long it will take to build this one! Give me a schedule with some deliverables."
Re:Perl IS the problem (Score:3, Insightful)
The funny thing is, all of your comments are equally applicable to C++. It's incredibly easy to abuse the language in a myriad of ways if you really want to, with many weird little edges and corners, and multiple possible styles available. And different programmers have a range of skill and discipline levels, producing code that widely ranges in terms of quality. But you don't see people blaming the language (well, okay, some do, but the industry uses it heavily anyway). Instead, we have things like coding guidelines and general corporate culture, code reviews, etc, to ensure that the output from poor to mediocre programmers is up-to-snuff.
Re:Ockham's Razor tells me.... (Score:2, Insightful)
Yes, it's not just Perl code that has developed piecemeal over the last 10 years or so, it's Perl itself, with things like OO being rather clunkily bolted on. It does feel to me like a language that was great in its time but has had it's day and needs to stand aside. No doubt Perl experts will continue to produce useful scripts as they always have done, but more modern technologies make it easier (including easier to get right). And that will turn into a maintenance issue for even well-written Perl code: when finding Perl maintainers gets to be as hard as finding COBOL maintainers, and for the same reason.
This is all true. The time it's taking Perl 6 to materialize is at least somewhat indicative of Perl itself. It's not a complete argument but I don't know too many people that don't think Perl is hard to maintain, usually.
I'm not sure where all the languagism comes from. Perl has a bad rap, period, though. It seems like everyone has seem some lousy perl code somewhere. Does that make perl bad? Not really, it just seems like perl really lends itself well to it. Perl, C, C++, all languages really but these in particular require a lot of discipline from the developers to avoid building crappy code; much like C++, read the mozilla guidelines about all of the language features they don't use, it's an interesting concept. There are perl scripts I rely on on a daily basis, it's a very powerful tool. Piecemeal design or not, terse code isn't always good code, terse code often requires more documentation because of subtlety. The same thing is happening with Ruby, it will rapidly become the new perl, there are some butt ugly pieces of ruby out there that people in the moment think are beautiful and elegant pieces of code, let's just wait 10 years and see when someone has to re-read that closure 500 times because of an assumption about the list it's being applied to that isn't documented anywhere but is fundamental to the code working properly. (but hey, if it fits on one line then you can *see* the whole program at once in vi!!!)
I think part of it is the learning nature a lot of developers take to to development, they learn as they go. A language like perl, by nature and design, allows a developer to do a task numerous different ways and I've seen more than a few perl programs where developers were trying to do different things in different places to further learn the language. This probably says more about the current state of the industry than it does about any language though.
Re:Ockham's Razor tells me.... (Score:3, Insightful)
I've always liked Bill Gates' perspective on this one:
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
Re:heyho, python - the new perl. (Score:1, Insightful)
Suitability aside, there's nothing that can be written in Java that can't be run at the same scale written in Perl or PHP. This is just ignorance passed around as "common wisdom". As is often the case, this "common wisdom" is completely lacking in any wisdom at all.
Ruby is definitely the shiny buzz of the day, but it will likely end up going nowhere because there's no rational basis for its present popularity and this will be realized soon enough. Expect Java to stick around until something we have yet to see takes over.
Re:Ockham's Razor tells me.... (Score:2, Insightful)
how is "deliverables" a stupid metric. Either you deliver a working solution/program on time or you don't. Thats the deliverable.
Let's see, what is the deliverable again? a working solution? What about maintainability? flexibility? What if the person had to mentor others when trying to deliver the product? What about managing priorities? providing useful and easy to maintain unit tests? documentation? What about team work and consensus in trying to achieve that working solution? What about raising issues early?
What ever the metric you use, it might be a fine tool to measure progress of the project. Just don't use it to measure productivity of individuals or you'll end up with programmers that meet their objectives and only their objectives.
Re:Perl IS the problem (Score:3, Insightful)
When Perl is promoted by impatient, sloppy bodgers, it's no mystery why it would attractd similarly minded developers. It doesn't have to be that way, but that does seem to be the de facto situation.
Oh, you nailed that one. When I was hacking Perl in the late 90s, it was fun and exciting and elite. The Perl culture was that we were special and cool and not like the corporate drones writing RPG in their cubicles. The problem was that it actively pushed you to do stuff as un-drone-like as possible as an ends to itself. If you did stuff in a clear, maintainable manner then you were just like one of "them", and that would have been missing the whole point of Perl.
Blame the coders, not the language (Score:3, Insightful)
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.
Re:Ockham's Razor tells me.... (Score:5, Insightful)
Lord, I thought the bless thing was a pain, and now you're telling me that there's at least FIVE different CPAN thingys that give me a way to do object-oriented Perl development? Perl's been on my "avoid" list for years now, and what you've revealed to me scares me to my very core, and only further cements my desire to continue avoiding it. It was great in the early-mid 90s as a way to make interactive web apps, and it fit really nicely into that "need more power than a shell script, but C is overkill" niche, but now? Perl sounds like the MCP from Tron, absorbing all functions into it. :-)
Since there are at least five of them, something tells me that the odds are decent that at a given Perl shop, some genius thought they all sucked and rolled his own all-singing, all-dancing object model. The net result is basically nobody can now claim to be truly knowledgeable about object-oriented development in Perl.
Re:Ockham's Razor tells me.... (Score:4, Insightful)
Right on. This is the real problem with Perl. Everyone rolls their own and we end up with multiple reimplementations of the same concept done in sometimes subtly different ways.
CPAN is one of my worst nightmares. There's no peer review so one ends up looking at several different libraries that do the same thing, only they all do it differently and have varying levels of feature complexity. I just want to get work done, not evaluate libraries.
Re:Why Corp. hate Perl? (Score:3, Insightful)
People have been saying Perl's dying since 1999, almost ten years but I still get lots of recruiters calling me. Not sure what to say except:
http://lui.arbingersys.com/ [arbingersys.com]
which shows Perl ahead of all scripting languages except PHP, which has been the case for many, many years already. The numbers I see are pretty stable. Ruby had a bump last years when RoR was the new hotness, but it's back down to a more expected growth curve.
Re:Ockham's Razor tells me.... (Score:3, Insightful)
Re:Ockham's Razor tells me.... (Score:5, Insightful)
what's not obvious in that line ?
Re:Ockham's Razor tells me.... (Score:4, Insightful)
my %hash = ( [ 1, 2, 3 ], [ 4, 5, 6 ] );
My, that's awfully ugly, isn't it?
Cowboy Perl, Rise of Scripting and Fear of Brevity (Score:3, Insightful)
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.
It's hard to maintain because Perl is. (Score:3, Insightful)
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.
Re:Writing bad code (Score:3, Insightful)
I wholeheartedly agree with your post, but this is where the point gets missed. Perl, along with MS Access and VB, is responsible for some huge, nasty, unmaintainable systems that nonetheless are entrusted with critical functions in large companies. This is not because they are bad platforms. You touch on it by saying that "Perl makes it very easy to write terrible code, just as Perl makes it very easy to write just about anything else."
Almost every large system started out as a small system, just as almost every large company started out as a small company. When you're a 50 man company, with a single network engineer, you don't need (and can't afford) an Enterprise IP Address Management Solution, but your engineer does need a way to manage or track addresses. So he discovers, that as a non-programmer, having never even heard of most programming best practices he is able to throw together some tools with Perl/VB/Access in a couple days. These tools work 95% of the time, and make it vastly easier for him to do his job. Some important things to realize:
1. He would never have built these tools if his only option was to set up J2EE and follow coding best practices with source control.
2. He is better off having built these tools than not having them.
3. Any "real" programmer will scoff at his tools and say they are horribly written amateur code, and the programmer will be correct, but irrelevant.
With luck, the business grows, and so do these tools/systems. Features get added. Staff gets added. Scope increases. It turns into a nasty homegrown kludge monstrosity, any starts having problems. Often around the same time that "works 95% of the time" is no longer an acceptable standard. Management will start to roll their eyes and call it a "legacy system" and suggest that HPCs come in to build a proper (aka expensive) version, or purchase some sort of industry standard version of the system and adapt that. They will usually be correct.
It's important to understand that nobody is stupid here, and none of these tools are bad. This is just a natural evolution and you'll see this story play out over and over again.
1. Easily accessible platforms like Perl, VB, and Access enable non-programmers (whether it's a network engineer like my example, or a PM, or accountant, or security auditor, etc) to create very useful tools that improve their productivity.
2. If those tools work, and the company prospers, it is natural for them to expand.
3. At some point, that expansion will scale past its proper limits and become unmaintainable, especially if its admins move on, or it starts having to integrate with other systems.
4. The right thing at this point is to replace it with a more scalable system, or at least have professional coders drastically overhaul the original system, but this does not mean the original was a bad idea or a bad system or a bad platform. It served its purpose very well.
Re:Writing bad code (Score:3, Insightful)
One of the tenets in Perl's design was to keep it somehow like a human language.
Now, consider the snippets you submitted. I will argue that the variability makes it easy to remember the code. Why? Because you are basically retaining the functionality of the code. That is to say, do people remember code per se or do they remember the functionality of the code? They remember the functionality of the code.
Now, I have no empirical data to support this - and this is one aspect of programming that I find deeply aggravating, i.e., nobody seems to research the human factor, the psychological factor. There's very little empirical data and there's just too much opinion. It fucking looks like the social sciences, sometimes.
But if we look at some surrounding evidence, mathematical writing, we will see that there's not a single book where Mathematics itself was not described in a human language. There's no book with Theorem/Proof Theorem/Proof/Corollary, etc. ad infinitum without a written descripition of the Mathematics.
Of course, as you mature, you move towards heavy notation. Likewise, in Perl, as you progress you move to operators, etc, to the point where sigils abstract very nicely what you want to say (contexts in Perl are important).
To say it differently, there cannot be pure Logos.