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?

Number four: #tcl #tcltk. Not as much hate as Perl gets, but a lot of misconceptions that I want to clear up for people who might hear about this for the first time:

1. Tcl != Tk. Although they’re released together nowadays, Tk is a standalone cross-platform widget toolkit. That’s where the Tk in Tkinter comes from. There are several bindings for Tk: Ada (TASH), Python (the aforementioned Tkinter), Perl (Tcl::Tk, Tkx and Perl/Tk if you want native Perl access to Tk structures), Lua (tclua and ltcltk), Haskell (HTk), Ruby, Scheme, Ksh (through dtksh), R (tcltk) and probably many others. The Python bindings even use Tcl as a bridge to Tk, same with Tcl::Tk and Tkx from Perl).

2. “Tk looks bad”. While it used to look like Motif on Unices, now it has (for quite some time) a native look and feel + theming support. Tkinter people sure don’t complain and probably neither do you realistically speaking.

3. “Tcl is a toy language”. On the contrary, it’s really powerful with the syntax it has (that and its syntax is defined by the Dekalogue, only 12 rules). In a way, it’s like Lisp and Forth (two of my crushes). I even tried a Forth-esque DSL in Tcl… and I could actually do it. I can implement if I wish try/catch, for..in, exceptions, classes, I can model it to my liking. This argument is genuinely more petty than even “Lisp has too many parentheses”. Additionally, it isn’t complex, which is a good thing (you can actually understand the whole language, implementation included). You can even redefine anything in Tcl using rename or have access to the Tcl interpreter using eval, uplevel and upvar for some metaprogramming if you so wish.

4. “Tcl has no types”. Yes, if you want to be strict about it, it only has strings (although that’s like saying that Lisp only has lists). You don’t need to perform conversions, however you aren’t likely to introduce bugs because the checks on the format of the strings are very strict. It’s a bit like Postel’s law: “be conservative in what you send, be liberal in what you accept”, but in reverse I think. Even better, you don’t need serialization because everything is a string already. You can even do stuff like sending a list through a TCP socket through puts $socket $mylist and on the other side set mylist [read $socket], it’s that easy. The central data structure is the list, not the string, and any Lisp programmers knows the implications of that.

5. “Tcl is slow”. This shares the same sentiment as in the Perl argument. Of course it isn’t gonna be a power house for sure in the runtime department, but it sure is quick to develop in. Heck, once you have some commands going on, you can start writing executable files that look like configuration (if you really tried, you could surely replicate #nginx syntax for example).

Besides that, there are a couple of other nice things about Tcl:

• you can have multiple paradigms: since the language is so flexible, you can add #oop, #functionalprogramming #fp programming, even throw some arrays for good measure (I have seen a code snippet somewhere in the Tcler’s wiki of someone doing vector arithmetic using just raw Tcl and some elbow grease).
• because code in Tcl is first class, it’s very simple to write functional language primitives that play well with the logic of the language (for examplem with stock Tcl you can do lmap i {1 2 3 4 5} { expr $i*$i} which prints 1 4 9 16 25.
• the Tcl source code is (in my humble opinion) one of the best written C programs you’ll find (please, look at it for yourself), the quality of the interpreter is amazing. It works exactly the same in different environment, including Tk).
• in a way, considering how it’s written, you can kinda think about it as an accessible Lisp with square brackets (it essentially works on the same sort of notation without the s-expr part).
• easy shelling? check. easily embeddable? check. easy sandboxable? check. reasonably rich standard library - check. high level abstractions - check. you can find all of these and more in Tcl. ;)
• Erlang’s author said in a tweet (http://web.archive.org/web/20190325110123/https://twitter.com/joeerl/status/1110126278953312256):
  “You know - TCL/TK8.6 is insanely great.

I stopped using TCL/wish in about 2004 - this was a BIG
mistake - I can now build GUIs in described by pure text.
Nothing is hidden it’s all text - I just need emacs and make.

Why oh why did I ever even click on a button to start Xcode”

The only people that are mad about Tcl/Tk at this point are RMS (because he’s still butthurt that #guile failed in face of Tcl and not even Emacs adopted, only Guix (Guile is good though), he even went so far as to call John Ousterhout a “parasite” (ironic coming from him, huh?)), MAYBE Larry Wall and people who didn’t bother checking up Tk (or looking at Tcl ever). And with that (for today, I think) I am done, although I could touch up on #forth, #php, #ada, #cobol, #smalltalk, #fortran… Even #ml #prolog. These languages deserve some love too, even though they aren’t particularly used. I truly believe that Tcl should become a more popular language, for me it was love at first sight (I like it so much that this is the language I chose to implement for my bachelor’s thesis on a Raspberry Pi Pico). Long live Tcl.

@alecui here's my actual critique of TCL, from having used it to write a couple of personal graphical applications:
every commandline interface is a bit too ad-hoc. every single interface has it's own unique syntax, and, annoyingly, the same thing in different contexts has different notations

@errante Tcl is unashamed in its DSL capabilities (Lisp is too, Forth is the crown jewel imo). When you don’t have a lot of syntax, it’s really malleable. I personally love this aspect of Tcl (because of Perl and Forth surprisingly, Lisp somehow doesn’t have the same feeling (Racket kinda does, you can do whatever language you want)).