On 26. des. 2015 11:52, stonysmith wrote:

OpenSCAD is very nice indeed. However, I don't think it looks anything
like Java :-)

But the topic of the modeling language itself is an interesting one.
About 6 months ago I mentioned on this list "... I think it would have
been easier and better if an existing language had been adapted
(AngelScript is another example) instead of developing a new one."

It has taken me a while to find time to prototype this idea, but at
least I have now done something. If anyone is interested, you can read
about it here http://arnholm.org/angelscript-csg/

As mentioned it is a prototype, meaning the main purpose is to explore
the idea of using an existing object oriented language to express CSG
modelling.

Carsten Arnholm

There are a number of OpenSCAD-like projects that use an existing general
purpose procedural language to do CSG modelling. For example, OpenJSCAD
(javascript), IceSL (Lua), Antimony (Python), ShapeJS (javascript).

The benefit is that you get a more powerful language than what OpenSCAD
currently provides.

The main drawback is that the programming model is more complicated, and
you usually have to write more code to get the same effects. For example,
the AngelScript CSG examples are full of type declarations, and other
syntax that is more awkward than in OpenSCAD.

So, it's a tradeoff. Personally, I think that a well designed and easy to
use domain-specific language is the right choice for CSG modelling if your
main focus is designing models, while an embedding of CSG modelling in
general purpose language X is better if you are an experienced X
programmer, or if you are doing CSG in conjunction with something else that
is well supported by X.

On 26 December 2015 at 17:11, Carsten Arnholm arnholm@arnholm.org wrote:

On 26. des. 2015 23:43, doug moen wrote:

Thank you for the references to those projects, they are quite
interesting and advanced. To me it looks like they aim for more than I
had in mind for the AngelScript CSG prototype. For example, IceSL and
Antimony look more like inteactive tools.

To edit the scipt directly is more what I had in mind, that is the best
aspect of OpenSCAD also, IMHO.

Indeed. In a language like AngelScript you can either just use what is
there, just like in OpenSCAD, but you can also do more when you need to,
including designing your own script classes for example.

It does not have to be more complicated, and what is complicated can be
very subjective. The tiny example obviously benefits OpenSCAD because it
is so simple. However I think it starts to pay off once things get bigger.

I am going to try and use AngelScript namespaces and then remove the
"csg_" prefixes in the initial prototype. It will make it look much
cleaner. I agree simplicty is important ("As simple as possible, but no
simpler").

That is a fair personal assessment. I do think, however, that a language
like AngelScript is manageable by about the same people able to handle
the OpenSCAD language. Keep in mind that there are also features in
OpenSCAD that are not easy to grasp even for seasoned programmers ("list
comprehensions").

I am currently evaluating what i have learned so far and will write
about it on my blog when I have made a revised update.

Thanks for your feedback.

Carsten Arnholm