[cacb]

Why should it be a 'declarative' language? There is no inherent benefit in that IMHO. I want the full set of capabilities that a general purpose language can offer, and still be scriptable. What is easier or more legible is very subjective. Your example does not seem easier to me.

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.

[contingencies]

Your example does not seem easier to me.

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.

[ajnin]

> Nobody cares, human time has value, machine time is free, and it's 2020.

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.

[contingencies]

I don't know if you have actual experience with CAD design but machine time is definitely not free there.

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.