Here's an anecdote. I have two friends who decided to take advantage of some COVID downtime to learn to code. I suggested they start by doing some HTDP, and they did. Now one is doing a bootcamp and the other is building his own apps. Both are doing Javascript, React, Ruby, a bunch of popular stuff.
I've interviewed and hired dozens of junior devs in my career, many of whom had already been on the job for a couple years. Most had only gone through a bootcamp. My two friends are far surpassing what any of those folks were capable of. They are able to understand these modern tools on a deeper level, not just copy-pasting or memorizing parts of an API.
I recommend it to anyone who wants to learn to code. Once you know fundamentally how to design functions, you can learn any of the trending technologies that might snag you a job. And you'll probably end up with higher quality, higher output, fewer bugs than your peers.
My question is, in your opinion what makes HTDP so good to make your friends learn unrelated things quicker than others? Do you think that is only a matter of designing functions or there's some other transferable skills too?
What I see from many people (especially coming out of bootcamps) is that they learn one tool. They make one or two apps with it, the apps work fine, and so they believe they can do anything. That works great until they come up against something they haven't seen before. Once they do, they have no framework in their mind as to how they can move forward in solving the problem. All they know are those one or two tools. So if they can't find a plugin or something to copy/paste into those tools, they become lost.
HTDP is genius because it shows you how simple the fundamental process really is. They literally call it a "design recipe". It's basically understanding the shape of your data, defining inputs and outputs, and writing tests. With those ideas and some practice with that methodology, you can handle any situation that comes your way, forever.
It's not the junior engineers' fault, though. A lot of people in the industry speak in terms of tools. "We're looking for React people", etc. The idea that your skills are defined solely by the tools you know is widely accepted in startup circles. It's no wonder that bootcamps operate the way they do.
From what I have seen, the mythical "10x" programmers really do exist, and they're the ones who are really great at keeping it simple. They're not necessarily FP-oriented, just focused on writing simple code to accomplish a goal (and very good at it). HTDP is a great way to start down that path.
That really motivated me to check HTDP out!
Logic and software are fundamentally complex. Djikstra said that software is “radical novelty.” It exists at a scale beyond anything the human race has ever built before, that’s fairly inarguable. He was also very fond of imperative programming, and was able to formally verify his imperative programs. Check out his book, A Discipline of Programming, where he goes over the mathematical theory of a simple imperative language.
There’s nothing more “mathematically correct” about the lambda calculus vs. Turing machines. Both are equivalent models. Whether or not state is implicit or explicit, state and time are a part of computation.
I like FP for the simplicity of it, the problem with OO is overemphasis on structural design and frequent indirections to name every entity as a noun with its own set of Data structures and state maintenance routines.
To answer your question if Industry is operating less efficiently? Maybe but there is no empirical evidence for it.
Considering all things equal software is inherently complex and OO is a real world abstraction to solve the complexity, but we end up introducing more complexity than we start out to solve, which is why i consider going back to roots and try a different approach as OO didnt actually deliver on the promise.
Also thanks for the Book suggestion.
Long Answer : Design Patterns are useful only in an OO Setting, its utility is gone if you look at Functional Languages. In FP you would have to consider more fundamental things than trying to cosmetically map a classical model to a domain, and then write bunch of code to retrofit that model.