Perl is the Most Hated Programming Language, Developers Say (theregister.co.uk)
Thomas Claburn, writing for The Register: Developers really dislike Perl, and projects associated with Microsoft, at least among those who volunteer their views through Stack Overflow. The community coding site offers programmers a way to document their technical affinities on their developer story profile pages. Included therein is an input box for tech they'd prefer to avoid. For developers who have chosen to provide testaments of loathing, Perl tops the list of disliked programming languages, followed by Delphi and VBA. The yardstick here consists of the ratio of "likes" and "dislikes" listed in developer story profiles; to merit chart position, the topic or tag in question had to show up in at least 2,000 stories. Further down the down the list of unloved programming language comes PHP, Objective-C, CoffeeScript, and Ruby. In a blog post seen by The Register ahead of its publication today, Stack Overflow data scientist David Robinson said usually there's a relationship between how fast a particular tag is growing and how often it's disliked. "Almost everything disliked by more than 3 per cent of Stories mentioning it is shrinking in Stack Overflow traffic (except for the quite polarizing VBA, which is steady or slightly growing)," said Robinson. "And the least-disliked tags -- R, Rust, TypeScript and Kotlin -- are all among the fast-growing tags (TypeScript and Kotlin growing so quickly they had to be truncated in the plot)."
The original study is here I found the "polarization of technology" diagram at the bottom even more interesting.
Perl just looks like line noise because of the heavy use of regular expressions. Java actually sucks across multiple vectors, for example, everything is supposed to be an object. Oh yeah, except for all the built-in scalar types etc... STUPID. You also see huge amounts of boilerplate code in Java. Their garbage collection just makes the coder dumber and still eats memory (ie.. nothing reaps until it goes out of scope - which is often the source of memory being tied up just like a leak would do just via a different route). Java is also a sysadmin's most hated language because you are constantly dealing with clueless Indians and other folks on Java's level and they have no idea how to tune their app other than "Give me everything the system has." That usually includes any memory you were hoping to use for the OS caches and kernel. Finally, Java's "promise" of write once run everywhere is a total lie. It's more like write once run on the exact same version and rig as the developer and it'll work if you are really really freakin' lucky. News flash: C is actually the most portable language. You buy a devkit you can bet someone has a C compiler for that platform. A Java interpreter comes way later. C is everywhere, java is a poorly implemented pipe dream. Perl is just a utility language. If you write more than 500 lines of Perl you are probably doing it wrong.
If you look at the original article -- cobol is there, as the 3rd most hated "tag".
And once you want to move beyond some simple automation scripts, you find that Python doesn't have the performance to handle anything more taxing.
Just junk food for thought...
My experience with the Perl hate is it's usually from younger people (by which I mean anyone under about 40). It violates everything some may have been taught as part of their software engineering program: it's difficult to read, maintain, and support.
But, it exists for a reason and it's ridiculously good at that purpose. If I want to process lots of text, I do not use Python, I whip out perl. And usually it's fine, the little bits of perl here and there that glue the world together aren't usually that egregious to maintain (particularly in context of the overall mechanism it's being used to glue together, usually).
If I'm going to write serious code, code that may formulate the basis for my corporations revenue model or may seriously improve our cost structure, I use a serious language (C/C++, usually) and spend significant amounts of time architecting it properly. The problem is that more and more people are using scripting languages for this purpose, and it's becoming socially acceptable to do so. The slippery slope being loved by children and idiots alike, one might say "I know Perl, let's use that!" and countless innocents are harmed.
I *love* perl.
It is C for lazy programmers.
I tend to use it for four distinct problem domains:
* one-offs for data processing (file to file, file to stream, stream to file, stream to stream). When I'm done I don't need it any more
* glue code for complex build processes (think a preprocessor and puppetmaster for G/CMAKE)
* cgi scripts on websites. Taint is an amazing tool for dealing with untrusted user input. The heavy lifting may be done by a back end binary, but the perl script is what lives in the /cgi-bin dir.
* test applications. I do QA and Perl is a godsend for writing fuzzers and mutators. Since it's loosely typed and dynamically allocates/frees memory in a quite sane manner it is able to deal with the wacky data you want fuzzers to be working with.
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
There is no reason to hate Javascript unless you come from C++/Java "inherit everything and override everything" classes.
Sure there is. If you come from a Smalltalk or Self background, the lack of sane support for numbers is a good reason to hate JavaScript. Smalltalk had a rich set of integer and floating point types, and the default integer kind was automatically promoted to a BigInt object on overflow. In contrast, JavaScript has only one numeric type, a double-precision floating point value. Trying to efficiently represent a 64-bit integer in JavaScript is basically impossible, trying to support arbitrary-precision integers is horrible pain. Lisp and Smalltalk had these from the start.
Then there's the lack of portable support for sane forwarding until very recently. In Smalltalk, if you call a method that doesn't exist, then the invocation is wrapped in an object and passed to the doesNotUnderstand: method. This lets you do proxy things transparently and easily. In JavaScript, this used to be impossible.
Then there's the not-quite-pure-OO nature. Everything is an object, but some of the operations can't be modified and some objects (e.g. Number) can't be subclassed / used as a prototype. Or the fact that you have a single immutable prototype chain. Or the fact that the operators aren't methods (so can't be overloaded) but are weirdly defined for arbitrary types (what is object + object?). Or the weird type coercion that happens, so adding an integer to a string is well defined and has odd results, so 'foo' + 1 + 1 is 'foo11', but 1 + 1 + 'foo' is '2foo' (where, in a sane language, both of these would throw exceptions).
I am TheRaven on Soylent News