I've pretty much concluded after a few decades that "learning" programming languages are a bad idea. If your language doesn't give students all the tools necess

I've pretty much concluded after a few decades that "learning" programming languages are a bad idea. If your language doesn't give students all the tools necessary to build a production program, you're sending them down a path that ends in a dead end. Sure, you can learn loops/ifs/functions in whatever language, but those concepts are a means to an end. Students don't start learning a programming language because they want to learn loops/ifs/functions, they start learning a programming language because they want to build something--a website, a video game, a tool that spams their friends' emails with fart jokes. If your language can't do all those things, it's not empowering students to do the things that got them into programming in the first place. Multilingual programming is a great idea, but it needs to be a feature in a production-quality general-purpose programming language, not in a learning language. I've been working on a programming language interpreter for a while, and I'm thinking about how I'd implement this. Here are my thoughts on a rough design: All the keywords in the language should be in a "language pack" for each of the supported natural languages. These should map one-to-one to some central language. When you write your code, you write it in your native language, and then run a tool that translates the code into the central language. The central language code, not your native language code, is what you commit to git. When a programmer checks out the repository, the first thing they do is run a tool which translates the code into their native language using the language pack. This is why it's important that the mappings be one-to-one. The tricky part here is variable names also need to be translated. This is an easier problem than translation of natural language usually is, because variables are going to mostly nouns, but it does mean that you can't have the typical /[A-Za-z_][A-Za-z_\d]*/ variable names--variable names need to be limited in some way to words which exist in the language pack. This creates a mess for language maintainers, but it's similar to maintaining time zone information in a standard library. One upside to the central language design is that bad translations don't have to be forever. The central language has to be reverse-compatible, but the translations don't, because when the user updates their language pack all they have to do is re-generate their native langauge source to get the better translations. The central language doesn't have to be human-readable, but it's not terrible if it is a natural language. However, I think it should not be English: English developers of the language should be dogfooding the translation system. Ideally you'd want your editor to display code in your natural language, translating to the central language in real time and only ever writing to disk in the central language, because we don't want be keeping natural language and central language files in sync. Vim/emacs/atom/etc. could do this with a plugin, but this definitely is not a trivial problem. Language packs should contain some standard formatting rules that make sense for the language, similar to `go format`, but there's no reason users couldn't configure the translation tools to use their preferred formatting.