It’s very hard to do tags in the physical world. You need to stick different colored post-its to things and do a full table scan (with your eyes) any time you want to process all docs of one tag. Or you cluster things together depending on similar colors.
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.
Something cool however is you can actually build the open-source WebKit browser engine yourself and make closed-source Safari use your locally built version.
Interesting read. It’s amazing more people don’t use runtime variable value annotation tools like Wallaby.js, or a debugger.
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.
The real issue is plain text, and files and folders.
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.
Code should generate diagrams automatically as you write it. Then you can see the complexity increase as you go, instead of looking back on a tangled mess.
I thought about building a transpiler from TypeScript to other languages as a learning tool.
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.