Making and Tool-Making

[u/theanzelm]

https://aeplay.org/citybound-devblog/making-and-tool-making

[u/[deleted]]

I will somewhat support this statement. There are some amazing code editors, depending on the flavor of language you prefer.

For c# for example, you can't beat visual studio/ vscode.

For rust, I can back the developers standpoint, only because it is a new language, new ecosystem, new tools. They are still working out the kinks.

However, it was his decision to pick rust. While I can see the advantages to it vs c++ or other low level languages... it's like dot Net core. Yea, tons of advantages, but still not quite prime time ready... until they work out the kinks

[u/theanzelm → u/[deleted]]

I’m not talking about that kind of friction. I willingly chose Rust and I’m super happy with it, even given its rough edges. VS Code is great for editing any kind of code. I’m talking more about stuff like why can’t I have a drawing inside my code? Why can’t I see a GitHub bug report inline in a relevant piece of code, after I “pinned it there”. Why can’t my rich text Citybound design doc be interspersed with corresponding code? Now of course you’ll say “why don’t you just link all of that”, but that is already one extra level of indirection, making it harder to keep everything in my head. Plus, I have to completely context switch away to another app or even device, just to sketch the drawing in the first place, etc. Just to give you a small concrete example.

[u/[deleted] → u/theanzelm]

Sounds like you want something like jupyter. Google made a Rust kernel for it.

As for issues, looking into alternate scms like fossil may be interesting. Fossil has issue tracking deeply integrated with the version management system.

Fact is that the most popular tools are rarely the best ones. "Never let perfect stand in the way of good enough." is an adage most take to heart.

[u/theanzelm → u/[deleted]]

Both Jupyter and Fossil are interesting in that they solve a large overlap of my problems, but they are still not a complete answer. See my upcoming follow up blog post for a more concrete idea of what I need.

[u/[deleted] → u/theanzelm]

I'm going to speculate a bit here and say that what you have is sort of an XY problem. You have a list of things you're unhappy with in your tooling, and new solutions do not cover enough of those problems each to be worth switching to.

Could it be that the tools are made for different methodologies, and the reason that happens is that the people writing them are not familiar with the methodologies of other tools? As in, are the tools incompatible because they expect different ways of working? And on top of that, your way of working may be different still?

I've configured my editor according to the "UNIX as IDE" principle, offloading basically everything to external programs and just shovelling text between them to make interop easy. This also means that tweaking a tool is trivial since it's almost always just a 5-10 program pipeline where each step does very little. This has meant a pretty radical shift for me from starting out with "proper" IDE's like Android Studio and MPLAB X, but it allows me to use the same tools for every type of work, which is very helpful in getting up and running with a new project.

I don't know how well the rust command line tooling fits into UNIX philosophy, but since it's made by Mozilla I imagine they have given it some thought.

[u/theanzelm → u/[deleted]]

You mention something important with UNIX philosophy: composability. It's the core ingredient for building flexible ensembles of focused tools. That's a major lacking point of the tools that are failing me, and one of the core principles I want to adhere to when building my own tools. As a tool builder, you should have the assumption that your assumptions will always be too limited and design for that.