I've got a CS related degree, but I'm a mostly self-taught dev, and not understanding 90% of the code really makes me reevaluate my career choices. Where and how can I learn this stuff?
Do you want to learn it because it looks interesting, or because you think it's important for a Real Programmer to know?
If it's the former, go for it.
If it's the latter, don't worry about it. I have a CS degree, did 6 years on a team writing C++ at Microsoft, and only briefly flirted with understanding this stuff. A couple of the wizard devs on the (very large) team could do it, but they also knew that code needed to be simple above all else, so it was effectively banned in our code base.
There are 2 components here. One is the "type metaprogramming" - (mis)use of the type system to implement to do compile-time computation, mainly by using parametrized types as kinda-functions + type inference for kinda-pattern-matching.
The other is building up basic "data types" by pretty standard lambda calculus > LISP route.
"Understanding Computation" book has a great chapter 6 on that, which is available in blog & video forms on https://computationbook.com/extras
- Here, Church numerals were used to represent numbers.
- booleans & conditionals here didn't resort to the lambda representation you'll see in the book, but relied on type conditionals builtin to TypeScript.
- The names "Cons" & "nil" are a ringer for LISP-like building of lists, and recursive processing of lists, from a "pair" data type.
Sorry, i misspoke about "Church numerals". The book uses them to represent non-negative integers by lambdas but here that wasn't necessary, TypeScript allowed a simpler representation of N as a the type of an N-deep nested list.
What's common to both approaches to building arithmetic is starting from zero + a "successor" function T. That approach is called "Peano arithmetic".
I still recommend that post/video (and the book in general) but I have to admit there is no 1:1 correspondence to the TypeScript going on here.
Still, it'll teach you some general maneuvers for bootstrapping computation out of almost nothing , qnd once you're comfortable with those, you can read things like this TypeScript post, or aphyr's original Haskell post, which bootstrap computation out of sjighly different" almost nothings" and without following the details still have a high-level idea of where it's going (like the poor interviewer in the story ;-)
Yes it's mostly because it looks interesting and fun. I definitely agree these type-golf-esque solutions are not ideal in an enterprise project especially where we have juniors and fullstack devs committing a lot of FE code.
Don't worry. I assure you that many senior devs can't follow this article either without some further digging. This is a puzzle interview task, not something that matters in most peoples daily work.
