4 ms·

I am the designer/developer of AngelCAD. It began from a desire of a fast Constructive Solid Geometry engine, based on a strongly typed scripting language. It i

by cacb 6y ago

I am the designer/developer of AngelCAD. It began from a desire of a fast Constructive Solid Geometry engine, based on a strongly typed scripting language. It is not a goal of the core AngelCAD package to develop a traditional CAD GUI, the emphasis is on scripting. The boolean engine used is xcsg https://github.com/arnholm/xcsg https://github.com/arnholm/xcsg based on Carve https://github.com/arnholm/carve https://github.com/arnholm/carve

contingencies 6y ago
Why is the syntax so heavy and C-esque? 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/ded2ba77b48f75f2813f156c84246e24 https://gist.github.com/globalcitizen/ded2ba77b48f75f2813f15... This would be simpler, less keystrokes, shorter and more legible.
- cacb 6y ago
  It is specifically not a 'declarative' language, it is a general purpose language. OpenSCAD uses a declarative language, AngelCAD does not. If you want a declarative language, use OpenSCAD or implement your favorite language on top of the AngelCAD boolean engine (xcsg).
  - contingencies 6y ago
    It is specifically not a 'declarative' language, it is a general purpose language. 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.
    - creato 6y ago
      Why not?
    - cacb 6y ago
      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 6y ago
        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 6y ago
        > 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.
rjsw 6y ago
The world doesn't need yet another CAD exchange format. You could have done scripting for STEP models.
- cacb 6y ago
  AngelCAD is not a "another CAD Exchange format". It is a scripting tool that creates existing standard formats such as STL, OBJ, OFF, DXF, SVG and more. It also reads some of those exchange formats. There is no new exchange format. STEP is an entirely different domain.
  - rjsw 6y ago
    I guess the .xcsg format is part of xcsg rather than AngelCAD, and the xcsg README.md doesn't mention being able to write out .xcgs files. Most CAD systems allow you to make multiple changes to a design, I don't see that with this system. STEP is not an entirely different domain.

by cacb 6y ago

contingencies 6y ago

Why is the syntax so heavy and C-esque? 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/ded2ba77b48f75f2813f156c84246e24 https://gist.github.com/globalcitizen/ded2ba77b48f75f2813f15... This would be simpler, less keystrokes, shorter and more legible.

cacb 6y ago
It is specifically not a 'declarative' language, it is a general purpose language. OpenSCAD uses a declarative language, AngelCAD does not. If you want a declarative language, use OpenSCAD or implement your favorite language on top of the AngelCAD boolean engine (xcsg).
- contingencies 6y ago
  It is specifically not a 'declarative' language, it is a general purpose language. 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.
  - creato 6y ago
    Why not?
  - cacb 6y ago
    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 6y ago
      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 6y ago
        > 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.

rjsw 6y ago

The world doesn't need yet another CAD exchange format. You could have done scripting for STEP models.

cacb 6y ago
AngelCAD is not a "another CAD Exchange format". It is a scripting tool that creates existing standard formats such as STL, OBJ, OFF, DXF, SVG and more. It also reads some of those exchange formats. There is no new exchange format. STEP is an entirely different domain.
- rjsw 6y ago
  I guess the .xcsg format is part of xcsg rather than AngelCAD, and the xcsg README.md doesn't mention being able to write out .xcgs files. Most CAD systems allow you to make multiple changes to a design, I don't see that with this system. STEP is not an entirely different domain.