This also applies to interviewing. Google for instance generally doesn't include anything PL theory related in their interviews, even though it would often be more relevant to the work than random dynamic programming problems. As a result of this they produced languages and frameworks like Go, Dart, Angular and Tensorflow, which display ignorance if not outright contempt for modern programming language theory. This led to the latter two being mostly replaced by React and Pytorch, which are more influenced by language design best practices, to Dart being mostly ignored, and to Go being violently rejected by a significant subset of the programming community.

> As a result of this they produced languages and frameworks like Go, Dart, Angular and Tensorflow, which display ignorance if not outright contempt for modern programming language theory.

This is a non-sequitor. Google hires a lot of PL PhDs (I'm one of them). And for relevant teams there is a "Domain Expertise" portion of the interview. And many of the people working on the languages and frameworks you mention have such background.

You don't like these systems. That's fine. But "Google would do it all differently if they just hired some PL PhDs" is just false.

I really dislike Go, but its creator(s) is more than familiar with language theory, and it is absurd to say otherwise.

I didn't read the GP as making a statement about the _creators_ of Go, but rather about its target users. And Go is explicitly targeted at "Programmers working at Google [who usually] are early in their careers and are most familiar with procedural languages, particularly from the C family."[0] If Google's interviews gateted on the sort of programming language questions the GP mentioned, then Go's target users would have been very different, and Go would likely be a different (better? Worse?) language.

[0]:https://talks.golang.org/2012/splash.article

I know someone that was on the Dart team. He's a PLT expert. In fact that's rather understating it. Don't mistake some pragmatic choices in language designs targeted for business use with ignorance.

What are the best ways to fill in those gaps? I bet many of us never enjoyed those classes in school, or even had a traditional computing education.

For me learning Haskell has been a great way to expose myself to things that were previously "unknown unknowns". I do a mix of coding, for intuition, and reading papers, for theoretical context. The papers written by SPJ et al in the 1990-2000s give a remarkably clear history of how certain functional programming concepts jumped the gap from CS theory to practical implementation in Haskell.

Just as assembly gives as close to a "bare metal" view of hardware as many of us will ever come, languages like Haskell and Lisp give a "bare metal" view of CS theory.

Seeing SPJ refreshed very fond memories for me :-).

I accidentally stumbled onto Haskell in my masters course. On the first day at university I attended a trial class of functional programming[1] course and instantly liked the way professor taught. However, I didn't take the course then and forgot all about it. The next semester I took compilers course and approached that professor for my masters thesis. During a meeting he gave me couple of options one of which was in functional programming domain. This time I took the plunge and went all in. Took the FP course and the professor who taught FP became my thesis advisor. The next two years were the most intense and intellectually satisfying years of my life. Not only did I learn Haskell but also built a compiler for it. I still get goosebumps remembering the rollercoaster ride I had in those two years.

During all that, the book by SPJ [2] became my constant companion. The book was actually out of print but my advisor had a book that was signed by SPJ himself :-). And I promptly photocopied it so I have it with me even to this day.

Suffice to say Haskell, lambda calculus along with SPJ and my advisor have had a lasting (and continue to) influence my life.

[1] https://www.cse.iitb.ac.in/~as/fpcourse/fpcourse.html

[2] https://www.microsoft.com/en-us/research/wp-content/uploads/...

Thanks! this looks really good. The fact that you did your programming class in IIT Bombay further motivates to work hard for my "dreams".

Reading the textbooks that people use in those classes is pretty helpful.

Dan Grossman has a great set of courses on Coursera, and a good number of resources are in those discussion boards.

https://www.coursera.org/learn/programming-languages

I suggest a combination of theory (videos/books/papers) and practice.

For practice; I highly recommend learning Haskell. If you are new to functional programming then learning Haskell is challenging and frustrating but as with any new topic the key is to not give up but keep probing. A good recent development is lot of mainstream languages are beginning to include functional paradigms such as lambda, closures etc., For example Java introduced lambda expressions, Javascript has had them for a while now. But from a first-principles stand point Haskell is as good as it gets so please do learn and code in Haskell if not at work then at least side projects.

For theory I've found following material super useful.

0. This[0] is an incredibly awesome lecture where Phil Wadler takes us on a whirlwind tour of computer science. He talks us through different foundational structures on which almost everything (hardware and software) about computer science is built. I watch this lecture once every few months :-). It helps you build up context and ground various topics.

1. The one and only SICP. Book[1] and lectures[2].

2. Automata theory[3]. This isn't an easy course but gets to the heart of the matter i.e., the meaning of "function" and what how can it be mechanically "computed".

3. Category Theory is where lot of active research is happening in CS theory. This is a very good lecture series[4]. The pace may seem a bit meandering but don't be put off. Bartosz is a gifted teacher and works incredibly hard to disseminate knowledge. For evidence just look at a recent post on HN[5] about an article he published.

[0] https://www.youtube.com/watch?v=aeRVdYN6fE8

[1] https://mitpress.mit.edu/sites/default/files/sicp/full-text/...

[2] https://www.youtube.com/watch?v=-J_xL4IGhJA&list=PLE18841CAB...

[3] http://ce.sharif.edu/courses/94-95/1/ce414-2/resources/root/...

[4] https://www.youtube.com/watch?v=I8LbkfSSR58&list=PLbgaMIhjbm...

[5] https://news.ycombinator.com/item?id=26991300

> For evidence just look at a recent post on HN[5] about an article he published. > [5] https://news.ycombinator.com/item?id=26991300

Ignore this part because the one I referred to is a different person! Though they are both terrific :-)

That post is by a completely different Bartosz.

Darn! All these days I thought they were the same! Thanks for correcting me!

You could find a MOOC (Massive open online course) for pretty much any programming language you want. Here's a pretty good one for Haskell.

https://haskell.mooc.fi

I personally feel the pain of this when trying to hire someone who understands core concepts in PL theory and can help maintain a framework. It's also not the sort of thing I can teach to my Sr devs on the job in under a year when they've never even touched anything like forth or lisp, or even tried to write a parser by hand.

I feel an analogous pain on the flip side of interviewing! I would kill for a job that lets me exercise some of these skills, rather than the brain rot of a typical software job which doesn't demand that one thinks too deeply about things.

I think the only way to do this might be founding your own company and building your own product in Forth and Lisp.

React re-rendering logic requires one to think plenty deep.

Of course, there's interesting work to be done at all levels of the stack. However, not every company will allocate time for solving frequently-encountered problems with creative solutions. Often, it's "ok, what's the minimum amount of time we can spend to fix this problem *right now*?", rather than "how can we make sure we don't have to re-solve this problem again ten more times in the future?"

Not me, but a friend described a whole team of engineers at his company hired to put out the fires caused by using database software that is a poor fit for the application, rather than biting the bullet and either 1) performing a migration or 2) rolling their own solution.

I wish my colleagues would appreciate the beauty of abstraction and PL theory as much as you do. It seems they actively resist any effort in that direction.

Relevant: https://steve-yegge.blogspot.com/2007/06/rich-programmer-foo...