It's been said that a camel is a horse designed by a committee, a slur on committees. But it's also said that a camel is a highly efficient machine for its function and not merely a misshapen horse.
The author of the prior statement was simply not aware of the conditions a camel is best suited for - a desert.
Which was the state of a certain class of "just get it done without wasting programmer time" software support was - there was shell (later bash)...and hard to put together C (fortran and JCL/Cobol in one world), which is not that great for "just get me the answer" kinds of work - scripting, so there was a desert in the programming space. Either bash or C can do most of what perl can, with extra libraries in either case, and a lot more work and complexity on the part of the coder. Some people think newer scripting languages are in some way better or at least prettier, things like Python being the current fad.
All of them are simply incomplete copies of perl's basic design...Things that offended the author(s) of the newer languages were left out. There is legitimate controversy over per'ls TMTOWTDI (there's more than one way to do it) and other philosophies expressed in the design, and many find perl code hard to read when they are brought in to modify it.
This is in part because perl was the first general purpose language to support regular expressions as a built in - and those can give anyone a headache. They are now built in to almost all scripting languages, and available to compiled ones - but hmmm...no one points that out. There being more than one way to do it does allow overly-clever people to write tricksy code no one else can understand - there was even a perl poetry contest at one time - and perl would do what the poem was about (sort of). But those people are just bad programmers seeking sinecure job security, and that more than one way to do it feature can be used to make code very clear and easy to understand as well - rather than barring the entrance, and holding a shotgun on you, perl just expects you'll stay out of the place unless asked in. (hopefully my perl, often uploaded here and on my github, makes this obvious) Other languages try to enforce tight rules their authors and fans say eliminate programming errors. History has shown this is baloney - bad programmers can be bad in any language, and there is simply no way a tool can be created that's powerful and idiot proof simultaneously, and convenience tends to go out the window faster than steel rusts in salt spray. (Some will see what I did there).
It is of course, possible to take that idea too far and fail to have a big picture and plan - I give you PHP, a fractal of bad design, which is often misused to do big things, even code big websites with bulletin boards (like this one. The link above is a hilarious read for those into the topic). Of course, holy wars in software are more or less the norm, often partly justified, more damaging than needed, and unfair, just like any other holy war. On the other hand, they can be entertaining especially if one "was there", knows the context, and realizes the kids fighting just don't really have a clue about the shape of the landscape, or a realization of how little there was to work with then - we were still writing text editors and report generators! No one knew what this was all going to evolve into. A few early language designs made it to success and wide use, most didn't, and hindsight is a lot easier to get right.
An unobstructed view of the original mangy animal for those who haven't seen it. At one time it was hard to find anyone in the biz that hadn't read it, and most owned a copy.
- My photo background
