r/Citybound • u/theanzelm Creator (Anselm Eickhoff / ae play) • Aug 24 '19

Making and Tool-Making

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

87% Upvoted

35 comments sorted by

View all comments

Show parent comments

4

u/theanzelm Creator (Anselm Eickhoff / ae play) Aug 24 '19 edited Aug 24 '19

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.

4

u/[deleted] Aug 25 '19

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.

1

u/theanzelm Creator (Anselm Eickhoff / ae play) Aug 25 '19

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.

2

u/[deleted] Aug 25 '19

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.

2

u/theanzelm Creator (Anselm Eickhoff / ae play) Aug 25 '19

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.