The boolean engine used is xcsg https://github.com/arnholm/xcsg based on Carve https://github.com/arnholm/carve
Documentation sections such as Datatypes in AngelScript, C++ Object handles to the application and Memory management are not features I want in a declarative language: accepted wisdom is to use the least powerful tool for the job. Edge cases should be dealt with as the exception, not burdensome as a rule which can be convention over configuration.
I would like to suggest something lighter. https://gist.github.com/globalcitizen/ded2ba77b48f75f2813f15...
This would be simpler, less keystrokes, shorter and more legible.
OK, but why?
Edit: Why not is because of the mentioned norm, ie. use the least powerful tool for the job. Alternatively stated, KISS. Asking programmers to delve in to a new set of assumptions, limitations and so on that could otherwise be avoided is creating friction. Unless there is an explicit reason for doing so, it does not seem wise.
Further edit: You make a good point about thought process, and I think graphviz is a clear example of a popular tool where the friction you mention between application-specific concerns and restrictive declarative syntax often lies, sometimes complicating an overall workflow.
Another thing is that I chose to use an existing language instead of creating a new one. I chose AngelScript because it was very easy to integrate with the implementation language (C++) and because it existed, was well documented and had all the features I wanted.
You could argue that one could choose another existing language (Python or whatever), and that is fair enough. The design is such that the language interpreter is entirely separate from the boolean engine (they are different executables), so all you have to do is implement the AngelCAD features in the scripting language you prefer and give it to the world. That is essentially what I did.
The point, ex comments, is that it removes all the crap about scenes and setup and output and memory and types. Nobody cares, human time has value, machine time is free, and it's 2020.
Also, it's more expressive (more meaning in less space), which is a great feature.
I disagree about types, it's great to actually know what you're dealing with and instantly know what operations you can do on objects without deep diving into layers of code and outdated documentation (the "ruby way"). Also I don't know if you have actual experience with CAD design but machine time is definitely not free there.
A declarative syntax seems better in theory but in practice if forces clunky syntax as soon as you are dealing with slightly deep hierarchies. Imperative syntax is just simpler, you can manipulate objects directly, pass them around to functions, the "object" paradigm makes sense here.
Heh, actually I run a robotics company. There are multiple people working for me full time doing CAD design. I would argue that delays due to tedious input in an industrial fabrication context are more expensive as you are not just using human time but also blocking on supply chain and 'machine time' scheduling, and ultimately potentially all business expenses. For this reason I do not understand your point.
AngelCAD does not try to impose a specific programming paradigm, it offers well known syntaxes and techniques for problems that can be complex. Of course, a user can choose to use only a subset of the language, this would be a typical starting point. Then with more experience and if the need arises, one can employ OO techniques with user defined scripting classes etc.
The user defines what is simple enough.
Edit1, reply to below comment. What is explained in AngelScript documentation is that the user does NOT have to worry about memory management. It is automatic.
You could have done scripting for STEP models.
STEP is an entirely different domain.
STEP is not an entirely different domain.