Without shooting yourself in the foot, learning lacks motivation. Complexity without reason is really confusing.
At the Recurse Center Feb 2020: I watch a talk during presentations about someone optimizing a database engine. It was really complicated, and I remeber nothing about the talk itself. What I do remember is thinking to myself “this seems really complicated for no good reason.” Keep in mind, I had never made a web application at that time and when I needed to store data, I just used a csv file or a python pickle file on the disk. I thought that a filesystem was sufficient for storing data.
Fast forward a few months and I’m building my first web application. I don’t remember what it was for, but I remember using a csv file as the database. I had to load the file into memory every time I wanted to look something up and it was just a big pain. I now understood why using a database is (sometimes) a good idea.
Learning Rust, July 2020: I start learning about the borrow checker. It prevents you from keeping a pointer to an item of a vector (&vec[i]) if you pass the Vec<T> as a &mut. I don’t really get why this is necessary. I have never done low-level programming before, never used pointers, and now I am being told that following the borrow checker is ‘safe’. It is still very confusing to me.
Fast forward to when I am writing Zig code. I take &array_list.items[i], append to the array_list and then try to write to the stored pointer. I get a segfault. Ahh, now I get the problem Rust solves.
Learning Vue, July 2020: Why are there all of these complicated ways to represent state? Shouldn’t developing a web app be simpler than this?
After writing a bunch of vanilla JS, I can see why these frameworks could be useful. I have never made a very big web app, but I could see that keeping track of state and what is or isn’t rendered is hard and gets much harder with a bigger web app.
To fully understand a “best practice” or why something is necessary, it’s important to experience how things go wrong without it. When teaching programming, we should let people make these mistakes, and then show them the tools to correct them. Just giving someone a complicated tool without a salient reason to explain its complexity will just make them really confused.
Some opinions:
You should store stuff in csv files before using a database
You should learn Zig (or C) before you learn Rust
You should write a web app in vanilla JS before you learn a framework
You should write a game from scratch before using Unity
You should use
javacfrom the command line before using an IDE
This is a good and interesting point, but it definitely isn’t necessary for learning. As an example, I get why pointing even an unloaded gun at someone you do not intend to kill is generally a bad idea, despite never having had any gun accidents or close calls. I think it’s worth trying to become better at seeing the reasons for these sorts of things without having to go through first-hand experience. This is especially relevant when it comes to reasoning about the dangers of superintelligence, as we will very likely only get one chance.
I think the idea actually works pretty well with superintelligence (with one big exception if you assume we all die). Lots of people don’t understand how/why superintelligence could kill us all. They naively think that creating a superintelligence would be a great idea. If we all died, then they would understand why alignment is a necessary complexity. The only problem with this is that we are all dead.
https://blog.mrmeyer.com/2015/if-math-is-the-aspirin-then-how-do-you-create-the-headache/
I have built multiple websites with vanilla JS and I have yet to see any good reason to use a framework for the sorts of things I do. In fact, using a framework would make building something like, say, gwern.net considerably harder, as frameworks are heavily biased toward doing things the way most people do them, and make it very difficult to do anything really innovative and unusual.
Instead of “mistake” I would say “problem”. Do not teach solutions to people who have not experienced the problem yet. Do not tell answers to people who have not heard the question yet.
You don’t have to shoot yourself in the foot, but you need the experience of not knowing which direction to shoot at. That’s when you imagine the possibility of accidentally hitting yourself.
*
I would also adjust the timing for the opinions at the end of the article. For example, I think it is good to use IDE for writing a “hello world” program, because that is the thing you are learning at given moment. Syntax highlighting and instant error checking is great to have for a beginner. The moment to try it without the IDE is probably when you can write the “hello world” reliably—so that when the task is “write the hello-world program and compile it from command line”, you won’t get stuck at some stupid missing semicolon.
Don’t learn two things at the same time. Using javac without being able to write hello-world doesn’t make sense, so you either need to learn to write hello-world first, or you need to get the file from the teacher.
I strongly disagree with this.
When I learned C (my first programming language), we wrote a
.cfile in a text editor and compiled them withgccfrom a command line. This gave me a much better understanding of the process of writing (and using) a program than an IDE ever could have. I have, since then, learned other languages, and spoken to many people who were learning, or had learned, etc.; and I have noticed a definite pattern, that those who started with the basics (no IDE, no fancy tooling) ended up with a deeper understanding of what they were doing than those who started with the IDE and all that.You can learn the advanced tools later, but you absolutely should “learn two things at the same time”, if those two things are “the thing you’re trying to do” and “the simple, basic way to do that thing”.
We can also just teach them what mistakes are likely to happen and why, then show them the tools. Letting them actually make the mistakes will make them understand more deeply but I think it is usually not worth the extra time.