I really love this point: https://yoyo-code.com/programming-breakthroughs-we-need/#program-is-not-a-text https://yoyo-code.com/programming-breakthroughs-we-need

I really love this point: https://yoyo-code.com/programming-breakthroughs-we-need/#program-is-not-a-text https://yoyo-code.com/programming-breakthroughs-we-need/#pro... In my day-to-day JavaScript programming adventures, I typically encounter issues around paths and how they're imported. There has been so much energy devoted to parsing a string and reading the file it (probably) points to, and we just assume that what we're importing from that file is actually what is in it. Maintaining all of my static imports in JavaScript feels like I'm doing something that a compiler or bundler should be doing, not a human being. Go has the right idea, it considers every file in the current directory to be part of the same package. This is really useful because you basically don't have to think about file importing anymore. I love being able to compartmentalize my Go programs without having to worry about updating a bunch of path imports all over the place. It lets me just focus on the code and sort out the organization later on when the project gets bigger. Of course, when the project _does_ get bigger, that's when you start having to grok how packages work and how they're built. This isn't a huge problem but it's definitely a learning curve that you don't necessarily need to overcome when you're first starting out, so it's a bit of a skill jump. I feel like there should be a programming language where the module system is deeply integrated with the package management system, and they are both baked into the language using syntax. This way, you can optimize those systems without disturbing how programs work, and the programs can specify what stuff they need from each package. Rather than deciding on some kind of folder/file convention for what a "module" is in your language, this one would put that responsibility on the programmer. A package would be defined by specifying its unique name, and the code that can be imported out of it. export package "fs" { export module File { export function read(path: string) { // ... } } } And then the `read()` function can be imported like this in your own app: import { File } from "fs" export package "my-app" { export module App export function start() { File.read("README.md") } } } You'd run this function on the command line by specifying it as your "entry point" like lang --run 'my-app#App.start()' Or, you can compile it into a program with lang --compile 'my-app#App.start()' --output ./app I don't know if a "registry" is really needed for these packages, as that might unnecessarily centralize the whole thing. Technically, since the language doesn't care at all about file paths, you can store packages however you want in your system. Literally `wget "https://github.com/some/pkg/releases/latest https://github.com/some/pkg/releases/latest" | gunzip` should be enough to start using the package, but of course having a CLI for managing this stuff will also be table stakes.