vaughan

For me this is the perfect timing. Just this week I was fed up with my iPhone (and most of the Apple ecosystem) and bought a Google Pixel 10 Pro.

We need this for TypeScript.

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.

Best solution to date?

.beat time or Swatch Internet Time is way better.

https://en.wikipedia.org/wiki/Swatch_Internet_Time

> As for SQL

We should peel off SQL and get access to the underlying layers.

My dream is to make everything visualizable at runtime. I think all of computing becomes very simple and much less complex if we can do this.

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.

I haven’t seen my desktop in years…

Meanwhile Windows still struggles with getting files to the bin.

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.

This is why we need better tools like projectional code editors.

There should be an editor toggle to inline functions temporarily.

No more bouncing.

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.

I wish they would have one IDE for everything - what IntelliJ used to be.

> I think it’s a project that’d take 5+ years

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.

Parse all the code with tree-sitter[1].

[1]: https://tree-sitter.github.io/tree-sitter/

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.

Local simulation + deterministic record-replay.

Code should be more like a children's popup book with little tabs to pull on to make things move around.

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

> There's many more akin projects listed in https://github.com/yairchu/awesome-structure-editors/blob/ma...

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.

I think we need to liberate ourselves from the "folders of files of text" way of coding.

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 wish it was open-source.

Whoa this is incredible. The things you find on HN!

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.

> The whole chain is where we are working; the whole chain should be the first-class citizen of the language/tool.

Sums it up well!

I had an idea to trace all usages of values. So you can see the entire history of how a value came to be. All the places it went. All the transformations too.

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.

SmallTalk was so visionary. Someone needs to do a modern take on it.

Someone needs to design a programming language and an IDE (and possibly a new OS too) with great debugging as the primary goal. Debugger and IDE support is always just thrown on later in every new language these days.

"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.

Vertically, like Github's Pull Request changed files.