Comment by fainpul

13 days ago

I'm with you. What I've learned from all those "programmatic CAD" threads is that some people just really prefer code over anything else. They also build only simple parts, so it's not an issue for them.

As the author says:

"I wanted to write my parts the way I write firmware. In Rust. With types. With version control."

Yeah, sometimes it seems there is a certain kind of devs who don't just like code for the sake of it, but have an active hostility against GUI tools and visualization in general, for whatever reasons.

I get the appeal of "change a number and regenerate everything" as well as "you can store everything in git" - but there is no reason why a decent visual CAD program couldn't do both of them just as well.

In contrast, the ability to actually see a part in front of me and not having to mentally visualize it the whole time seems substantial to me.

Even as some who would generally prefer graphical CAD software in most cases, sometimes for simple parts like the examples in the linked article code really is just easier.

Sometimes it’s the same when I’m working on texturing for 3D models and I want to combine some texture maps in a specific way, I really don’t want to open Photoshop or similar for something that could be expressed in just a few lines of code. ImageMagick can probably do it, whatever it is, but then I need to learn the incantation.

I agree with the OP:s statement

"With version control"

but there are 0 reasons you can't have that in a visual application as well.

It just needs good domain model design.

I mean it's _not_ trivial. To start with you have to first understand the relationships between your model entities, and how versioning strategy affects your model hierarchy (well, graph basically), and that potentially locks you down on a certain path. But it's totally doable as a hobby project (once you know CAD systems are built - so it's not suitable as ones first CAD project ofc).