I'm a software developer, but I'm also a 3D print designer and a woodworker. OpenSCAD is really unfriendly once you want to get past "I have a box and the box needs to connect to another box"; cadquery and especially build123d are more promising for sure, but the environment and the affordances are clumsy compared to "draw a sketch with a mouse and extrude a thing" in Fusion. Maybe if my alternative was FreeCAD (thankfully it's not) code-based CAD would feel like a better alternative, but it's not, and like--if I have to contort myself to make a fillet work, I would simply not bother. And if I have to sit there, squint, and change a variable and wait for a recompute, rather than dragging the thing to where I want it, I'm also probably not gonna bother with that, either. I tried; it doesn't work for me, and sweeping universal statements about this stuff are Pretty Weird.

On the other hand, having access to a kernel like Fusion's, plus their Python scripting environment, is pretty nice for me, and I enjoy building tools to manipulate that. But those tools don't take center stage; the visuals and the chain of features do that.

I'm happy that you have found the tool you like. I would be vary to be so categorical about something which is fundamentally a preference on your part. I'm not here to tell you that your choice of tool is wrong, and I expect the same courtesy back.

When I'm designing I'm creating 2d drawings and 3d bodies. Seeing those things and directly manipulating them is a big benefit for me.

This orrery is the most complicated 3d object I ever designed: https://www.youtube.com/watch?v=FGdjk5fY87s In particular the roundish bent shape which fixes the upper bevel gears together and holds the reducer gear train at the right depths while also holding the planet's shaft at the right angle. I have no idea how I could have designed that without graphical feedback.

Same reason people use Adobe Illustrator or Inkscape to create SVGs: when you're creating a visual end product it's often easier to use a visual workflow. You already have in your mind what you want it to look like, so you just need to draw it and you're done.

When it comes to specific dimensions it's often more convenient to use parametric modeling and integrated repeat features. Automate the repetitive and precise stuff, freeform draw the rest.

I think the holy grail would be a GUI-based CAD that stores your design history as a text-based editable script written in a very readable programming language.

I think with the growth of AI-assisted design, algorithmic engineering, and topology optimization, we will eventually get there. It practically requires it...you need to be able to specify the boundaries and constraints of what you need and let the system do its work, but you also need to be able to iterate off of the results and refine your boundaries and constraints to get to what you want.

My latest query in to the OpenSCAD mailing list is:

>How does one represent a 3 dimensional Bézier curve in OpenSCAD? How would that be extended so as to create an entire surface/object?

and my current project is wending its way down to doing wood joinery which seems to require conic sections (suggestions for texts to read for formulae which will calculate more quickly than the chained trigonometric calculations which only got me half-way or so?)

Define geometry with code, but insert references using the mouse to select features.

I wonder what non programmers think about it though. It’s hard to see past the bias

OpenSCAD was invaluable to me for getting started with CAD. I always considered myself somewhat "3D-impaired" when it came to software applications, but I wanted to make stuff, and OpenSCAD helped me get started and to explore some very basic concepts that gave me confidence (revolves, cuts etc.)

It gave me confidence I would be able to make my own things, however basic. But it is very simplistic and fundamentally limited.

For example, since it is not bRep, it cannot work with STEP, which limits its utility with existing components or exporting to manufacturing in other than 3D printing. And as it is declarative and lacks constraints or reflection capabilities you cannot measure models, loft generated faces, etc., and you end up doing endless, endless expression calculations to make parts that fit together, where parametrics and reflection would allow you to make one part based only on the final form measurements of another.

(If code-CAD appeals and Python is OK, look at Build123D as others have recommended. It is everything OpenSCAD should be, still lets you work with CSG operations, and can import your STLs. But it also gets you into a bRep world and that is, pun not intended, a step-change, as you can start to reason about and build on points and faces.)

So my next step was to look at CadQuery (which I don't recommend), and about three hours of that convinced me that I shouldn't get stuck in the mesh-modelling world. CadQuery led me to FreeCAD, and Mango Jelly Solutions videos and a free book got me started.

FreeCAD can work with OpenSCAD files (and it has a deprecated CadQuery 1.x workbench). It's also fundamentally parametric. You can write code to generate objects, or you can use expressions and spreadsheets with GUI tools; it's still wholly possible to make designs that are based on reasoning about measurements.

From there, I decided, if I hate FreeCAD at least I have liberated myself from the limitations and frustrations of OpenSCAD, and I can use other CAD packages as soon as I decide I have to. But I've never needed to.

I've been able to quickly make complex items, but also refine my designs to the point that they are more professional.

I would also caution you not to assume that it's "plainly obvious" code-CAD is better at all. It is great for simple objects and some programmatic generation, but relies on external files and tools for complex vector shapes, which is a usability/project management issue right from the start for a whole bunch of users. And then there's the frustrating handling of co-planar surfaces in the preview (though that may be mitigated? I gather there are speedups on the way too)

For the vast majority of users I would have thought it equally likely a constraints-and-sketches workflow is better, not least where implementing existing engineering sketches is concerned.

Since they're "just variables", not some funky CAD abstraction of variables (like you get with Fusion 360 I think?), you can do any level of arithmetic you want with them, and you can very easily define variables in terms of other variables and add conditionals.

Personally I absolutely hate measuring stuff, measuring stuff is my least favorite part of the entire 3d printing process. What I love about SCAD is I can just define my variables with dummy placeholder values, get a design that more or less looks right, and then measure everything right before I print, and everything will automatically readjust because it was all defined as variables.

This of course isn't specific just to OpenSCAD, but any code-based CAD program. I have no desire to try and go back to vanilla GUI programs.

OpenSCAD does have some limitations, in that you will never really hit "perfect" tolerances in the output files either. However, the guess->print->measure->correct->repeat workflow is usually as good as it gets after a few cycles.

It can be more convenient than manually coding g-code macros, but OpenSCAD does certainly make 3D printing practical for actual parts.

Cheers =)

This pattern repeats again and again[1] every time someone tries to push a DSL for complicated problems. DSLs are a great way to address the boilerplate and copying and tedium of working with bad frameworks in imperative languages. But they don't work once you really get rolling, and you end up in some kind of imperative hell anyway.

Declarative programming as an API design style is hugely valuable and great. Declarative programming languages as an implementation choice are IMHO a bad smell.

[1] If you think about it, this is really just another corrolary of Greenspun's Tenth Rule.

You don't like fluent APIs, which is your right. I think they have a place, and are a good DRY trick for grouping a bunch of things that would normally be "sequential" and making them look "declarative".

On the other hand I don't much like voodoo, and in my very limited experience with build123d it's sort of full of it. The very first "box" example looks like this:

    with BuildPart() as ex1:
        Box(length, width, thickness)

I mean, is that fatal? No. I'm sure it's reasonably easy to explain. But everyone has tastes, and mine (informed by decades of scars from APIs like this) run hard toward the "make things explicit" side of the theater.

[1] Because if they didn't they wouldn't have much value. There are OpenCascade python bindings already, after all. But they don't match the use case of "write a simple script to emit your object" and are more aimed at "build a CAD tool".