Hierarchy is easy in the physical world.
But what is crazy is since the dawn of computing we can store data however we want and project it however we want…and yet we still use hierarchy for file storage…like we still just have a filing cabinet of manilla folders.
To me it seems obvious that code should be stored in a database rather than a hierarchical, text-based format.The main way we navigate and organize code is by folder hierarchies. Everyone has a different approach: by feature, by module, by file type (template, component, etc.), by environment (backend/frontend).Rather than folders and file names, everything could just be tagged in different...
We should peel off SQL and get access to the underlying layers.
We are visualizing things in our head already. And any explanation of anything in computing is a diagram. But we have zero diagrams when coding.
Just dynamically instrument all code to send messages to a GUI.
So much time spent mentally remembering what is in what variable based on the naming.
I often find myself adding “// e.g. foo, bar” to show example cases for some lines of code…like recedes for example. Wallaby.js is a godsend for this though.
There should be an editor toggle to inline functions temporarily.
No more bouncing.
File names, folder names/hierarchies, function names, class names are all _arbitrary_. You could randomize them all and your code would still run.
What is not arbitrary is: the call graph, and the data flow/dependecy graph.
Every line/block of code could be wrapped in a function.
And classes...your class methods are just functions with an implicit parameter of an object of a certain type...and practically, not the entire object, just the parts it that it actually uses in the function body.
So if you just focus on what your functions do, the boundaries and groupings of your code will become self-evident.
What are the major difficulties you see? Is this estimate for supporting all existing TS code...or as the OC said, a new language with only newly written code.
The way I naively think about it is to imagine transpiling TypeScript code to Zig code. How far could that take you?
And if you restricted how much dynamic-y stuff you could do...maybe with a linter. I always get the feeling that 90% of the business logic (sequence, selection, iteration) is that same between languages whether they are interpreted or compiled, with just some memory management stuff added on top - which can be abstracted anyway.
It would also scaffold out the project structure for each language.
The idea would be not to allow all code, but focus on high-level intent as simply as possible using primarily builtin language and platform primitives.
Could even use the name of a function and some comments to express the intent, which then gets transpiled in the other language, without even looking at the implementation in TypeScript. Could probably lean on AI a lot.
I’d love to have “one obvious way” to do certain things in each language. This Pythonic rule is violated so often in every language. A lot of programming is the same thing but we all do it slightly differently. Just take a look at some stack overflow answers for really simple stuff.
When I look at a foreign piece of code I want to see all the runtime values inline in my editor and a time-travel debug session with a slider and a stack trace of the function under my cursor, and a trace of the _value_ under my cursor showing every transform that happened to it, and all common data structures and their algorithms visualized and animated in appropriate diagrams. And available in all our tools instantly - like when viewing code on Github.com.
I really think you could figure out what is going on with most code if you simply move a slider back and forth and watch everything that changes. And it would be much more fun with a physical knob to turn (e.g. https://www.tourboxtech.com/ or https://www.binepad.com/product-page/bnr1-v2). Knob-driven development :D
Awesome link! How did you find that link btw? I feel like I scoured the web so many times on this topic and missed all of this stuff.
> I can't wait fast enough for these ideas to reshape how we deal with programs and build stuff.
Same here. I feel like we can't leave plain text completely behind though. There has to be some two-way sync to the structured model.
We really shouldn't ever have to think about where to put things.
Each function should be stored in its own text file.
Then these files are indexed in a database.
Then they can be tagged: manually or by parsing its AST / types.
Then using the tags you can organize the code any way you want.
Better yet, maintain a dependency graph to see all callers and callees, and view code like that.
Even better yet, instrument your code, and at runtime let the stack trace determine the organization of your code in your editor.
Some problems I can see though is that humans seem to like things to belong in one place. That's why folders win over tags usually. But...your existing folder/file structure of code is simply one "view" from the database. Some people use module names, some people use file types (components, helpers, etc.)
Existing IDE's and text editors (and runtimes) are holding us back!
Prior art: SmallTalk Browser, Intentional Programming, Literal Programming.
I've been researching these kind of things for ages...and this is the first time I find out about this.
Code as a database.
Sums it up well!
Also, I think code should be written so that it can be easily visualized. Nothing else! Code is for humans to read, not machines - that's what compilers are for.
Code instrumentation is usually for code coverage...but for debugging it can be great too.
"Omniscient debugging" as seen in https://pernos.co/ is the holy grail. Time-travel debugging would also be great.
People are far too obsessed with static type checking. A lot of this time would be better spent invested in live debugging tools.
When I'm editing my code I want to see exactly what _value_ each variable contains, the type really doesn't matter so much. Wallaby.js/Console.ninja is a great example of this.
Good debugging, especially deterministic record/replay is usually complicated by the OS. I often wonder what an OS would look like if designed with debugging as a top priority.