For sure, its a big benefit of using language, it is comparatively very fast and easy to define custom relationships of component values, trace widths etc that would quickly become untenable in a point and click tool. We think the path forward is to be able to encode the governing equations that you would get in say a buck controllers data sheet directly into our source code. That way from a user perspective you can define your circuit simply by importing modules, defining them (for example input voltage, output voltage and current) we can then solve the component values and pick them from our component database for you. One of our early users wrote a plugin to do LED arrays in an afternoon. Our compiler is all open so its pretty easy to add on custom scripts for whatever you might be wanting to do.

look at OpenSCAD, it's a scripting language to generate models. I used this a lot to generate subpieces and build off of that. easy as saying Bolt("M5", 1.5) or something

As a regular OpenSCAD user, I wouldn't bring it up as a good solution for anything. It exists, you can solve problems with it, but it isn't a good design. It should just be a library in a real language.

> It should just be a library in a real language

The last thing I want to worry about is having malware in an M5 bolt.

From a security perspective, it does help that ato is not executable!

I've found CadQuery to be a pretty good replacement for my purposes, but I haven't done anything complicated with it yet, just designing 3D printed/laser cut electronics enclosures.

Ya OpenSCAD is great for in/cross project re-usable components.

The only issues I've had is how it outputs circular things for cutting - it does a series of polygons (configurable number), rather than an arc/circular - places like send-cut-send won't accept it, claiming it causes issues with their machines.

Old issue, but annoying nonetheless. Less of a problem when outputting STL files (for printing) which only support polylines and not arcs/circles. Funnily enough, 3D printers nowadays support arcs natively in G-code, so some slicers support detecting rounded polylines and converting them back into circles or arcs.

Found a script[0] that does this for DXFs in a github issue[1].

[0]: https://github.com/nophead/Mendel90/blob/master/dxf.py [1]: https://github.com/openscad/openscad/issues/4605

I actually opened that issue - I'm ukd1 on github too. I looked at fixing it at some point, but it tbh didn't seem that easy or like they had time to help, I should probably revisit. The script I couldn't get working right last time I tried, but I should give it a re-look!

I found OpenSCAD's 3d model representation to be very challenging for anything complicated. I used FreeCAD, which is scriptable, but also uses a brep representation instead of CSG, which IME works a jillion times better.

I have used it, I think its great. I am excited to see whole products defined in code.