Great article, I was nodding my head with almost every point! Although I think you also have to consider that the author has a strong math background, which both improves and warps your view of programming. If you don't know any math, then this post is probably less relevant to you (e.g. learning a bit Haskell or ML is probably a good idea in that case).
------
As a nitpick about the theory of automata, I would draw a big red line between regular languages and context free grammars.
Regular languages have very useful engineering properties: they have predictable (linear) performance and give you "free" lookahead. (That is, nondeterminism is a math-y idea that many programmers are not comfortable with, but it's useful for engineering.)
They are better than Perl-style regexes for building reliable and understandable systems, which "blow up" on a regular basis.
In contrast, context-free grammars have almost no useful engineering properties by themselves. (There are subsets like LALR(1) that do, but they come with a bunch of tradeoffs.) As the article mentions, learning about recursive descent parsing first is probably more practical.
Also, you're MUCH more likely to encounter a regular expression in real code than a context free grammar. In 15 years of professional programming I probably dealt with regexes on a weekly or monthly basis, but had to write or modify a grammar exactly zero times. It does help to be more familiar with regexes and regular languages.
> If you don't know any math ... learning a bit Haskell or ML is probably a good idea
This is very much counter to the point I was making. I didn't find that learning haskell or ml was anything like learning math, especially the kind of math that I've seen people get use out of in day-to-day engineering, and I don't understand why this idea is so persistent.
If you don't know any math, it might be worth learning some of whatever kind of math is applicable in your field. It's probably not haskell.
> It does help to be more familiar with regexes and regular languages.
Regexes are certainly useful, but I don't think that learning a lot about automata theory is a particularly efficient way to get better at using regexes in practice, compared to eg doing a bunch of drills on https://www.executeprogram.com/courses/regexes
Hm reading this section again, I don't doubt that you had that experience, but I doubt it generalizes.
I think the "latin" claim is pretty close to true -- getting exposure to different languages helps your general programming ability (though I have no idea if it's true for Latin itself :) ) You get to see how other people solve problems, and play with different abstractions, and both of those are valuable things.
For my particular experience, I've written about 80% Python code, 15% C/C++, and 5% other languages for 10+ years. So thoroughly mainstream, and I agree that's the way to get work done. But I did do SICP as a freshman in college and I think that permanently changed my thinking about programming.
I also spent a few weeks with Real World OCaml in 2014, and hacked on some open source OCaml code. That experience directly helped me with implementing a language (Oil). That might not generalize either, but I'd still stand by the claim that people who don't know any math could benefit from learning a functional language.
It's a long argument that's been made many times elsewhere, but exhaustive case analysis, recursion, and various types of composition are second nature to some programmers but not others. I also think it helps with the "basic logic, sets, functions" areas you point out. There is A LOT of production code in the world that can use help with these things.
Like another commenter, I do think it's possible to swing too far in the other direction :) You probably internalized a lot of stuff a long time ago from either math or Haskell that helps in programming, but then you have "the curse of knowledge" -- it's hard to imagine what it's like not to know those things.
----
I also disagree about regexes -- the main problem is that the syntax varies so much in practice, and people hack or copy and paste until it works (the regex as lingua franca paper in my blog post above talks about this.) I think learning the simple mathematical concepts of alternation, repetition, etc. first is actually easier than doing drills for JavaScript regex syntax, and you can use that knowledge in practical contexts like the shell (where none of the common tools use JavaScript syntax).
If none of that convinced, I now remember that John Carmack (who you quoted!) has advocated functional programming as a way to improve the design of your programs (and he also used Racket for a VR project as far as I remember):
Probably everyone reading this has heard "functional programming" put forth as something that is supposed to bring benefits to software development, or even heard it touted as a silver bullet ...
It isn't immediately clear what that has to do with writing better software. My pragmatic summary: A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. In a multithreaded environment, the lack of understanding and the resulting problems are greatly amplified, almost to the point of panic if you are paying attention. Programming in a functional style makes the state presented to your code explicit, which makes it much easier to reason about, and, in a completely pure system, makes thread race conditions impossible.
> Also, you're MUCH more likely to encounter a regular expression in real code than a context free grammar. In 15 years of professional programming I probably dealt with regexes on a weekly or monthly basis, but had to write or modify a grammar exactly zero times. It does help to be more familiar with regexes and regular languages.
This massively depends on what you’re doing. I’ve been programming for 30+ years, 16 of them professionally and not gone near regular expressions beyond a general knowledge of their existence and uses. Mind you the same is also true of context free grammars which is something I dimly remember learning about at university.
------
As a nitpick about the theory of automata, I would draw a big red line between regular languages and context free grammars.
Regular languages have very useful engineering properties: they have predictable (linear) performance and give you "free" lookahead. (That is, nondeterminism is a math-y idea that many programmers are not comfortable with, but it's useful for engineering.)
They are better than Perl-style regexes for building reliable and understandable systems, which "blow up" on a regular basis.
In contrast, context-free grammars have almost no useful engineering properties by themselves. (There are subsets like LALR(1) that do, but they come with a bunch of tradeoffs.) As the article mentions, learning about recursive descent parsing first is probably more practical.
Also, you're MUCH more likely to encounter a regular expression in real code than a context free grammar. In 15 years of professional programming I probably dealt with regexes on a weekly or monthly basis, but had to write or modify a grammar exactly zero times. It does help to be more familiar with regexes and regular languages.
This post/sketch elaborates on related points:
Comments on Eggex and Regular Languages http://www.oilshell.org/blog/2020/07/eggex-theory.html