Conceptually this reminds me of how in the QBasic (DOS 5+) docs there was a section indicating "this is an intentionally hobbled product, and you should expect

Conceptually this reminds me of how in the QBasic (DOS 5+) docs there was a section indicating "this is an intentionally hobbled product, and you should expect to graduate to QuickBasic for more professional stuff." For educational purposes, being able to say "we've eliminated a bunch of tarpits" is a good thing. On the other hand, I wouldn't discount the syntax differences as a real pain point, once you've walked past the 200-level CS class that shows "look, here's LISP and Prolog and Assembler and they're all Turing complete and can solve the same problem." We get it, the syntax doesn't matter, but familiarity does. There's no doubt a lot of friction and productivity cost when you take a experienced programmer who's worked on language A and drop them in language B-- even if they know what they want algorithmically, they're going to spend a lot of time stubbing their toe over syntactic differences. In the worst case, I could see them making worse code because they choose the easiest/most documented approaches rather than having to figure out how to express exactly what they want. It's interesting there's little tooling to support that use case. Given that (originally, who knows now?) C# and VB.NET were supposed to be more or less isomorphic, I could imagine an IDE extension that dynamically transpiled either language to the other for display and editing, and then converting the changes back to the "official" project language when ready to share the code. It could be used as anything from a training tool (flip back and forth to see how this construct maps between the languages) to a crutch (I don't know how to express XYZ in C#, transpile it for me)