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)).

@alecui actual forth doesnt use DSLs as we define them all too much. dont call it a DSL. just a sequence of vocab

@errante I’ll still call it a DSL, especially after having tried it for 2-3 weeks straight to get my feet wet. It’s on the same level as saying “Tcl is just a bunch of strings that so happen to be keywords”

@alecui ive used forth for a while, DSL just feels utrerly misleading as to how you do it

@errante maybe we have different perspectives on what a DSL is (or should be, rather)

@alecui hide behind too much grammar and you end up losing sight of your aim

@errante honestly, this happens even if we’re not talking about DSLs, but just generally learning a programming language. Some languages (C++, Rust, I’d say Python to an extent) like to solve problems by syntax, others (Go, C by… actually solving them with the tools available. The latter group doesn’t change a whole lot while the former one has “hip” and “fresh” new “features” added.

Basically, don’t be a kitchen sink.

@alecui if you've read how moore writes forth, you'll notice that he doesnt do the accepted 'build layers od abstraction using words as your unit'
all the codw is high level and low level simultaneously

@alecui gosh. I had forgotten TCL existed

@tiphphin wait until you see what it can do ;)

@alecui gitk is written in TCL, isn't it?

@tiphphin yep, almost (if not) everything involving Tk also involves Tcl at some point

@alecui oh 🤦‍♂️. Gi tk... Obvious when you think about it. 😂

@alecui Lisp has had a compiler since before Lisp 1.0; it had a compiler BEFORE it had an interpreter (and before it had a REPL, which needed the interpreter).

The original notation for Lisp ('MEXPR', meta-exoression) did not use (many) parentheses; the SEXPR notation we now use was developed as a convenience, but before the release of Lisp 1.0 in the spring of 1960.

https://www.softwarepreservation.org/projects/LISP/MIT/AIM-001.pdf

@simon_brooke Do you think Lisp haters know that? But thanks for the link regardless. I am glad Lisp doesn’t have m-exprs now and history left that syntax to Wolfram language.

@alecui I implemented MEXPRS in Beowulf, but mainly for the shits and giggles.

https://github.com/simon-brooke/beowulf

@simon_brooke I’ll give you credit, you’re the first person I’ve seen attempt to use Lisp 1.5 seriously, is the parsing easier or harder than for s-exprs?

@alecui OK, so I wrote the MEXPR parser in instaparse, which is an absolutely beautiful parser generator, so it was really quite easy. It has the benefit that I was able to copy the MEXPR text from the #Lisp 1.5 Programmer's Manual straight into the REPL.

I agree there's no practical point in doing this; it was just for fun.

https://github.com/simon-brooke/beowulf/blob/master/src/beowulf/reader/parser.clj

@simon_brooke unrelated: I love how the first photo on your README makes a lambda, nice accidental touch

@alecui Aye, I wrote trace functions quite early in debugging the interpreter, and when I first traced RANGE and saw that screen emerge, is was just a surprising moment!

So obviously that had to become the logo for the project ;-)

@simon_brooke what improvements do you want to make in the future to this project? What are your TODOs and TBDs?

@alecui OK, well, at present it's on hiatus. I ran into a bug where Clojure's lazy evaluation was causing the interpreter to fail; and although that's almost certainly trivial I didn't track it down. Most of the thing works, but I'm not a great completer-finisher.

I've started work on re-implementing it in C, to compile down to ARM code, in order that it could run on a Raspberry Pi Pico; but I haven't (yet) got very far with that.

@simon_brooke you can always choose C++ and make it slightly less painful… Or uLisp. :)

@alecui I personally find C++ a lot harder to get my head around than C. BCPL was one of the first 'high' level languages I learned (because the runtime for Cambridge Lisp, a variant of Portable Standard Lisp, was written in BCPL) and consequently I tend to use C as a sort of glorified macro-assembler!

@alecui Getting the line editor in the REPL working fully would have been the next goal, but really the big one is compilation, and I don't really want to compile down to JVM, because I don't find it a congenial target.

The `develop` branch is quite a lot ahead of `master`, but as I say it has a flaky lazy-sequence bug that I haven't fixed.

https://github.com/simon-brooke/beowulf/issues

@alecui
counter-argument: Lisp as a language is identified by its readily identifiable community
https://www.nhplace.com/kent/PS/Lambda.html

Also
(loop (print (eval (read)))) ; in lisp pseudocode
In what way is this pseudocode? ;p

@screwtape @alecui i will admit i didn't really like lisp syntax. i liked basic

though i've seen surveys and the like and while pascal/algol/hypertalk is objectively correct (there was a research language where they had a rule all features had to be from citable studies, and they ended up with a pascal/dylan type syntax because the most people found this readable), lisp syntax hate is primarily just C programmers "its different so i hate it"'ing. non-programmers had no issues learning it, same as non-programmers have no issues with lua.

i put up with the parens now :ablobcatderpy:

@icedquinn @screwtape @alecui

> i didn't really like lisp syntax

what syntax? there's barely any. literally programming in the AST it's glorious

@roboneko @icedquinn @screwtape wait until you find out about Forth

@alecui @roboneko @icedquinn
, as a domain specific language in lisp https://letoverlambda.com/ !

@screwtape @roboneko @icedquinn I have no idea how I managed to skip that part when I was reading LoL

@alecui @roboneko @icedquinn
iirc the book kinda goes from

"what if we use unhygeinic macros to create a pandoric let over indirective lambda

to

by the way, eat your heart out lisp prolog implementors here's forth"

@screwtape @roboneko @icedquinn the McCarthy-Moore thesis

@screwtape it is pseudocode in the sense that in an actual Lisp implementation of this idea it’s a bit more nuanced than that.

@alecui Over 40 years even, for arrays. Interlisp 1974 had them.

There's also work for concurrent GCs being done.

@alecui I used to write tons of #Lisp on my #BBCMicro. Most enjoyable and logical. :-)

@alecui I just discovered VSI has Pascal for OpenVMS x86_64, so there must still be a userbase (cough..me cough) using it for them to port it. I have a soft spot for pascal

@praetor my soft spot for Pascal appeared when I tried it on DOS (Turbo + Delphi) and Amiga. Without Pascal I wouldn’t have tried Ada (I’m mad I can’t use it for my current project, but oh well…)

@alecui Also FL Studio (ex Fruity Loops) still uses Delphi and lots of people love it

@fperson@թութ.հայ I love it too.

sidenote: interesting domain, դու հայ ես?

@alecui Not an organized smear campaign, but over a *dis*organized decade-and-a-half of Osborning by Larry and #Perl6 developers that split the #Perl community and gave outsiders air cover to wave the shittiest of fragile novice spaghetti code as exemplars of how Perl inevitably leads to insecure unmaintainable crap

U A BITCH MADE NIGGA

@alecui As a long-time Perl user and currently employed to write it, I appreciate this thorough and fair assessment.

@Altreus I actually tried my best, now I can redirect people to this thread next time someone tries to claim Perl is bad.

@alecui Thanks for the kind words about #perl :) It's definitely a better language than people give it credit for. Unfortunately, it's so easy to use, that people who shouldn't be allowed near a keyboard use it all the time. The language gets blamed for their inability to program.

@ovid I’m not sure if that’s the case nowadays, it used to be true a couple of years ago (arguably, PHP has been more in that position and now JS)

@alecui In about 5 years working on perl it grew on me. The same could not be said about Java.

@alecui Your post just reminded me to continue learning #perl, thanks. Already got the latest version of #perl (5.38) installed via #perlbrew and my #emacs properly configured.

@not_null_p Wow, I missed the release of 5.38, I had my eyes on it for quite some time

@not_null_p also, you should use plenv, not perlbrew nowadays, it’s just like rbenv or pyenv