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."
It depends. I use Solidworks all the time but I think OpenSCAD was a great choice to make this part:
https://github.com/settinger/selectric_typeballs
A bit like how you can edit images in MS Paint, Python, or Photoshop. None of these is or should be a one size fits all solution.
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).
Version control?
Quite a few with their domain specific naming conditions, constraints and workflows.
For example Fusion 360 https://www.autodesk.com/products/fusion-360/blog/fusion-360...
Then there's stuff like "Tekla model sharing" https://www.tekla.com/products/tekla-model-sharing
Onshape https://cad.onshape.com/help/Content/versionmanager.htm
Etc
The requirement to a) collaborate b) version the work is quite old and well supported industrially. Depending on the application it may not "look or feel" that nice of course.
I guess the key thing is these are not "code first" offerings.
Their blog post about this subject is really good https://www.ondsel.com/blog/goodbye/
They chose maybe one of the toughest imaginable combinations for a business model. Viable open source businesses are hard (since you don’t own your ip in closed form, hard to explain to investors what the actual value is). 3D businesses are hard.
So it’s hard x hard.
Clearly their _tech_ worked. I guess there is a lesson here - better mousetrap is almost never enough for a viable business.
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.