Inspired by @uncanny_kate’s discussion, I thought it was about time to rant about one phenomenon:

People shitting on “old” or “legacy” languages. It’s a long subject and I’d probably get close to the 65K limit my instance provides (nobody wants to read 65K chars anyway) so in the replies to this I’ll describe each such language that I’ve gotten hate for. I’ll try to make them as self contained as possible.

Number one: #perl. Oh Perl, my joy. At this point I am convinced there was an actual organized smear campaign against it and Larry Wall.

I’ll begin this by a quote from Bjarne Stroustrup, the designer of C++:
“There are only two kinds of languages: the ones people complain about and the ones nobody uses.”

Let’s address some common complaints:

1. The syntax (usually complaints about sigils). This is extremely subjective, I don’t see these people hating on Java or JavaScript or Rust or Swift even though they’re all part of the same C family of languages or on Bash even though it shares the same dollar sign.
   Perl uses more of the ASCII character set to its benefit and its iconography takes advantage of that. It assigns simple mnemonics to each prefix (e.g. $ = value as in show me the money, @ = array (you can see the little a in there, plus it’s surrounded by an O/0 which means that @ contianers contain things located “at” 0-based indices), % = hash (Object/Object pairs). Alternatively, $ looks like an I overlapped with an S (it can either stand as an Item or a Scalar containing an Item),
   I prefer to treat these as maybe noun inflections, in a way, so I interpret $ as “the”, @ as “these”, % as “map of”. Heck, Larry Wall was a linguist, so he definitely was inspired by that to make Perl more like a natural language. It’s a reason why Perl has my and our in the language too. Read http://www.wall.org/%7Elarry/natural.html for the natural language principles in Perl.
   When I see $, I immediately know it has to return one value, a scalar, @ for a bunch of values, % for a hashmap. It also makes it easy to interpolate variables (no snprintf/std::format/f-strings/… tomfoolery) and it follows the language design rules of “different things look different”. #raku made this sigil system a bit more uniform.
   One bonus: Sigils allow even a dumb text editor to accurately color highlight code while also giving different types different colors.
   You see, it’s perfectly possible to write programs in Perl that are absolutely crystal clear, shining examples of the art of programming and show off your clever algorithms in all their beauty. But Perl isn’t going to make you. It’s up to you. Perl doesn’t write illegible Perl, people do (a complaint shared with PHP too).

2. “Perl is old”. No? It still receives updates with plenty of features (this year’s Perl update is expected to have NATIVE! (no Moose) classes, for instance). It has a lot of CPAN libraries (and thankfully avoiding npm/pip-levels of bloat). Also, the active and welcoming community of mature developers for which I am insanely grateful makes me feel like I am standing on the shoulders of giants, I am actually learning from seasoned programmers unlike in Python or Rust or JS where it genuinely feels like I am learning from people my age (the JS veterans are the one that have actively used jQuery (it’s still a fine library, by the way) and have been there before TS and all the billion frameworks that exist today).
   The documentation is plenty, it hasn’t changed completely in like 20 years because Perl developers care about backwards compatibility, it feels like C in a way where C99 is still fine to use or Common Lisp or Forth).
   Perl is a beast when it comes to text processing which is one of the places where it shines, and a part of that has to do with regexes. We have a motto: “There’s more than one way to do it”. We don’t force any particular style on you, so you can express your intentions in a way that reflects how you think about programming.

3. Regex. People cope hard about us being able to just… write regex. It allows me to write really concise expressions that would otherwise be verbose in other languages. Perl’s regex parser is so great that other languages have either ported Perl’s parser over or just reimplemented them to handle regexes the way Perl does all the way down to the syntax. Perl’s regexes are ubiquitous because so many Perl idioms revolve around them, which means they’re fast. Insanely fast. Additionally, I need a module/library to use regex in other languages while even raw Perl 5.6 can do regex. If used carefully (and explained), they can make your code readable and clean. Your Perl regex code is as clean as the regex you’re using is. I can grep, map, split, trim etc. using only regex, even substitute (yeah, s/this/that/ isn’t something special in Perl, we can just replace strings without anyone noticing).
   Here’s a concrete example based on something I had to do yesterday: let’s say you have a 500K line file where you have two columns delimited by a comma (CSV file in my case) and you have to swap them. The way I thought about it was (I have to do them one line, since my instance apparently doesn’t support multiline code blocks:

   while (<>) { s/(.*),(.*)/$2,$1/; print; }

   On the command line (which took me literally 10 seconds, empty head no thought): perl -p -e 's/(.*):(.*)/$2:$1/'.
   Another valid way is:

   while (<>) { chomp; ($first, $second) = split /,/; print $second, ",", $first, "\n"; }

   which is what I’d use in an actual full-blown script.

4. “Perl is just for one liners” (I’ve heard this one several times, actually). Wanna play the same game? Here is one Python oneliner I found on dev.to: cleanString = lambda s,countPound=0 : ''.join(filter(lambda char : not isinstance(char, int), [(countPound := countPound + 1) if c == '#' else c if countPound == 0 else (countPound := countPound - 1) for c in s[::-1]]))[::-1]. If I want to golf it: A=lambda s,p=0:''.join(filter(lambda C:not isinstance(char,int),[(A:=A+1)if B=='#'else B if A==0 else(A:=A-1)for B in s[::-1]]))[::-1]. Python ain’t so elegant now, huh? Any language is as ugly as you want to make it out to be. I’ve seen gorgeous Perl code and horrible Python code and viceversa. The people doing one liners in Perl most likely are either 1. too lazy or 2. doing it in the shell so you can run it using perl -e 'source'. Additionally, you can extend Perl to get at any C libraries you can do in Perl, so I could do bindings for Fortran and do the same number crunching as Numpy.

5. It’s too slow. Okay, slow in what aspect? It can be pretty slow sometimes when it comes to runtime speed, but people don’t consider development time. I can crunch out a one liner in Perl that does the job I want instead of banging my head hacking the same job in C (where I have to think char by char instead of at a string level). This is the reason why people choose Python or Ruby or even JS, they shine in the development time department.

6. Perl is insecure. What the hell does that mean? Just like the readability of your code and the wonderful Y2K bug (or soon to be Epochalypse), it’s not Perl’s fault that you programmed your script in an insecure manner. If you try to hide away all of the deficiencies in your code, you’re pulling a Microsoft right there. Security by obscurity isn’t secure at all and Perl doesn’t do that.

That was a lot and it doesn’t end here, oh no, I got more languages ahead.

Number two: #pascal (and #delphi). Going raw on this one.

1. “Pascal is just for teaching”. As if a language that’s easy to learn for beginners is bad. #python and #js are used a lot in teaching too and I don’t see them get shit for this. I pity people who start with #c because that’s an unreadable mess. Additionally, it came I think 2 years earlier than C, so it had to deal with the same constraints that C had. It has a lot of low level capabilities and plenty of compiler directives to choose from in case you’re a control freak. We even have asm blocks which, unlike C, aren’t (excuse my Spanish) dogshit to use, we can just reference variables inside them and it works as expected (you have to do some weird stuff in C to get that). We have pointers too and use them decently frequently. Pascal, along with ALGOL-60, was designed as a language for formal specification and teaching of algorithms, but contrary to ALGOL-68, emphasis was put on simplicity (imagine a world in which ALGOL-W was ALGOL-68…).

2. “Pascal is slow”. What? Pascal was fast even back when Turbo Pascal was all the rage, a direct competitor to C. #apple sure had their reasons to choose Object Pascal (basis for Delphi) when they did the Apple ][ and Apple ///). There also existed UCSD Pascal which ran on the UCSD p-System, popular at that time (it ran actual Pascal p-code, which means it was the Pascal equivalent of the #lisp Machine, really powerful). Free Pascal is on par sometimes with even GCC.

3. “Pascal is outdated”. News flash for people who’ve only tried Turbo Pascal: we have interfaces, generics, lambdas, Unicode support, database support through a common interface, dynamic arrays, abstract and sealed classes, for..in, operator overloading, static methods/properties, RTTI, type inference and so, so, so much more. We’re more than able to meet modern demands with the amount of libraries at our disposal. It runs on more platforms than it ever has before (I beg you to find me a more portable language than Pascal (and Free Pascal specifically) that’s not C, it’s gonna be a rough realization). I have actual enums that work like symbols, I can have negative indices, character indices, enum indices, whatever. That allows me a lot of freedom (for example, it’s a pain to iterate over enums in C, something I have to deal with in #cpp in my compiler). It’s fast, performant, easy to understand and still has room for improvement.

4. “Pascal’s syntax is too verbose”. It is verbose in a readable way, unlike some other public, static and void of any elegance main languages that are both terse and verbose in the most cursed way. The syntax is well structured and strict, which is good for not just beginners, but also parsers. In C, a function is 1. its signature and 2. the declaration of variables.. and definition of function which may be mixed up. In Pascal, it’s clear: 1. function/procedure signature, 2. declaration of variables, 3. definition of function/procedure/program. Simple as that, it follows a predictable structure. Don’t even get me started on C’s = vs == (which can BOTH be used as valid Boolean expressions), unlike Pascal where we have := for assignment and = for comparison (they’re mutually exclusive, as in assignment isn’t Boolean and comparison isn’t an assignment). We also have <> which is really different from != in C. I don’t need to insert break everywhere in my Case … Of section in Pascal because the syntax is strict and so it knows where to stop. There’s a strict difference between a pointer and a string (we have native strings too, btw, unlike C). We also have native set operators (and sets, obviously); we can check if an element is in a set via in, we can include/exclude elements, compare sets ((symmetric) difference), combine and intersect them). This is all in the language, no extra units needed.

5. You Pascal and Delphi haters (usually ones that never even attempted to try these languages, as always, the grapes sure are sour) aren’t grateful enough for these languages existing. For one, it’s the first widely used implementation of a bytecode (if you want to put it that way, it’s also the first VM). The chief designer of Delphi went on to create C# (which you don’t seem to have a problem with, mostly, although the Delphi influence is clear as the night sky in the mountains). Also, have you heard of these irrelevant programs named Skype and InnoSetup? Yeah, those ones. News flash: they’re in Pascal (I think Delphi specifically). Delphi essentially pioneered the concept of RAD (rapid application development) in an IDE form which is why it evolved to fit so nicely with GUI development in mind, unlike its C++ sibling in RAD Studio. It’s still hard to beat Delphi in the GUI department (too bad Embarcadero realized a bit too late that they needed a Community Edition… or Linux support). Visual Basic, Visual FoxPro, VB.NET, C#… it all started with Delphi.

Number three: #lisp. This is spicy enough, so:

1. Lisp syntax is painful (and the classical Lots of Irritating Small Parentheses stab). For those who don’t know (and why I put this at #0), what other languages might write as 5*a+3 is (+ (* 5 a) 3). However, in spite of the fact that it may look initially a little funny to the unaccustomed, there are some sound technical reasons why Lisp syntax exists:
   • Easy to teach: grouping of operators and associativity is obvious. 5 * a + 3 is (+ (* 5 a) 3), while 5 * (a + 3) is (* 5 (+ a 3));
   • Easy to parse: you don’t have to bend the language to understand your new function, everything works the same;
   • Maps nicely to an underlying data structure: Lisp is a living and breathing AST. Having this syntax makes macros possible. When you teach someone about macros, it’s obvious what the internal representation of a Lisp expression is because it looks just like Lisp program data. You can thus fit Lisp to anything you want. Lisp programmers focus on the content, Lisp haters focus on the parentheses.

2. Lisp is old. No? There are modern dialects of Lisp such as #Clojure, #Racket and the myriad of R{5,6,7}RS #scheme implementations. We’re still going strong, thank you. If anything else, #AutoCAD is still a thing and that has AutoLISP, so it definitely lives on.

3. Lisp is slow. I have actually heard this from a teacher live (along with the Lots of Irritating Small Parentheses stab). I asked them when was the last time they’ve tried Lisp. He tried it 30 years ago. Before doing his PhD in #Haskell 98 (which was fresh in #Romania, nobody has heard of it, I still have great respect for him). When all datatypes are appropriately declared, a typical commercial (and even some non-commercial) Lisp compilers produce native machine code on par with C++. It was true back when Lisp ran on the IBM 704 because they could barely handle the GC, but over times the compilers improved a lot. To equate 1960s (or even 1980s) Lisps to modern Lisp compilers is like claiming C is slow because the only time you’ve tried it is with a C compiler on the PDP-11.

4. Lisp is big. First of all, I find this really funny because Scheme (a branch of the Lisp family) is minimalist yet powerful in its nature. This myth started around the 1980s when Lisp was indeed big (because it packed a lot of useful functionality and there was a limit to how small that functionality could be made). Lisp vendors noticed that and nowadays Lisp is one of the few programming languages in recent years that has not been allowed to grow in size by leaps and bounds with every release. At this point, this point is (excuse my Chinese) fucking bullshit, people are happily running Electron-apps and they don’t care at all about resource usages because they’re all running the latest and greatest hardware anyway. Languages are getting more and more bloated (ahemc++ahem) and so Lisp actually ends up looking like a compact alternative.

5. Lisp has no arrays. This is also BS, we’ve had an array datatype for at least 30 years. Even though the Lis of Lisp is from, shocking, List, it doesn’t mean that it’s the only data type. Lisp offers powerful support for single and multi-dimensional arrays, arrays of varying element type, and array access that provides transparent access to fixed size arrays, arrays displaced to other arrays, and arrays whose size is expected to dynamically grow and shrink.

6. Lisp has no compiler. It… does? Since its earliest days Lisp implementations have been variously interpreted or compiled, and often both. Much important work in the theory of program compilation has been done using Lisp and so Lisp benefited from that. All modern Lisps have a compiler (and also a REPL which allows for interactive debugging, thank us for that and much more at the end of this post).

7. Lisp is not standard. Let me present ANSI X3.226/1994 (first ANSI standard for any OO language btw) and RnRS (5 <= n <= 7 nowadays). The Common Lisp HyperSpec (CLHS) is a webbed adaptation of the ANSI Common Lisp standard made by LispWorks, heavily cross-indexed with a lot of indices.

8. Lisp doesn’t talk to other programs… Um, most serious Lisp dialects and implementations definitely have FFI, most even have easy access to TCP, CORBA, COM, databases etc. This is a really weird point that I’ve actually heard, people think Lisp is isolated from everything.

9. Lisp GC is slow. It may have been true in the past when computers could barely handle GC, but a lot of progress has been made since then and it’s now on par with other popular GC languages.

Lisp haters should give Lisp more credit. It pioneered a lot of features that people take for granted such as REPLs (which are trivial in Lisp, literally (loop (print (eval (read)))) (in Lisp-ish pseudocode), GC with mark-and-sweep, AST as a tree structure, if (yes, not even FORTRAN had conditionals), a function type, recursion, programs composed of expressions, a symbol type, a notation for code using trees of symbols and constants, and the concept of having the whole language there all the time. What I mean by the last point is that there’s no real distinction between read-time, compile-time, and runtime. You can compile or run code while reading, read or run code while compiling, and read or compile code at runtime). This lets you reprogram Lisp’s syntax; running code at compile-time is the basis of macros; compiling at runtime is the basis of Lisp’s use as an extension language in programs like Emacs; and reading at runtime enables programs to communicate using s-expressions, an idea reinvented as XML.

Lisp is pretty nifty after all, huh?