M
MichaelAtOz
Wed, Nov 25, 2020 5:48 AM
OpenSCAD Admin - email* me if you need anything, or if I've done something stupid...
- on the Forum, click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
--
Sent from: http://forum.openscad.org/
-----
OpenSCAD Admin - email* me if you need anything, or if I've done something stupid...
* on the Forum, click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
--
Sent from: http://forum.openscad.org/
M
MichaelAtOz
Wed, Nov 25, 2020 5:52 AM
Posts moved. Please reply to this to continue on this topic.
OpenSCAD Admin - email* me if you need anything, or if I've done something stupid...
- on the Forum, click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
--
Sent from: http://forum.openscad.org/
Posts moved. Please reply to this to continue on this topic.
-----
OpenSCAD Admin - email* me if you need anything, or if I've done something stupid...
* on the Forum, click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
--
Sent from: http://forum.openscad.org/
RD
Revar Desmera
Wed, Nov 25, 2020 6:08 AM
Actually, I’m trying to save the thousands of future hours of effort spent on working around this language. I’ve already spent hundreds of hours on that just by myself. I’m trying to fix most of the issues all at once by replacing the language with a well tested and designed language that is ANOTHER dedicated group’s responsibility to maintain. Frees devs on this project up to work on the editor and the GUI itself.
Now at this point I HAVEN’T put serious work into any BetterSCAD. I’ve written many thousands of lines of OpenSCAD code. I just keep getting so very frustrated that I start dreaming about something better, then have to reel myself back in because I have no interest in having to support another project for the next 20 years. I've written and submitted PRs to implement improvements in OpenSCAD. Not a single one has been accepted yet. All I can do at this point is TRY to convince devs to let logic prevail. PLEASE.
What I really want is for the OpenSCAD devs to FIX OpenSCAD. And I just haven’t been seeing that, and my attempts to help appear unwanted.
This is how forks happen. This is how forks have already happened to this project.
On Nov 24, 2020, at 9:13 PM, Torsten Paul Torsten.Paul@gmx.de wrote:
I don't think the language is the main issue.
The amount of developer time spend in the project
is.
You are trying to solve that problem by creating
another project dividing developer time?
If all that time spent on all those BetterSCADs
(https://github.com/albinoBandicoot/BetterSCAD)
could have been joined to improve on OpenSCAD
itself, most of the problems might not exist
anymore.
Now there is a place for new projects of course
and it's up to everyone to decide how to spend
their time.
I don't believe the OpenSCAD language is the best
thing invented. If I would start something like
that, I would likely do it quite differently too.
But is JavaScript the perfect language? It's
still used by a couple of people.
Time and time again in different variations I
have seen how people throw things away to create
something new based on "new technology" because
the existing stuff looks old and boring. Just
to find out a couple of years later they are the
legacy project now fighting the same issues
they thought to solve by starting from scratch.
Yes evolving an existing project used by many
people is much more complicated then just
changing doing something new, but at some point
that's going to happen (Python3, Perl6, ...?).
I'm massively impressed by C++ in that regard.
It was sort-of dead for decades, but started
moving and now evolves with massive and also
surprising pace while still keeping the legacy
working. Is it the neat modern lean language? No,
far from it. Can you write neat modern code? Yes,
well, maybe to 98% by using just the new style
and accepting a couple of warts that are there
due to backward compatibility reasons.
And OpenSCAD is not just the code, it's also the
documentation, the books, the people who do
packaging for various platforms and distros, the
people who help others and the not so small number
of people just using it for fun from time to time.
Well, coming back to the original topic of this
thread I think tools like the static code
analyzer can help with things like spotting code
that could be written in a newer style, a more
performant way or at some point maybe even point
to libraries that would help simplifying models.
It could be one puzzle piece for helping the
OpenSCAD language to evolve.
ciao,
Torsten.
Actually, I’m trying to save the thousands of future hours of effort spent on working around this language. I’ve already spent hundreds of hours on that just by myself. I’m trying to fix most of the issues all at once by replacing the language with a well tested and designed language that is ANOTHER dedicated group’s responsibility to maintain. Frees devs on this project up to work on the editor and the GUI itself.
Now at this point I HAVEN’T put serious work into any BetterSCAD. I’ve written many thousands of lines of OpenSCAD code. I just keep getting so very frustrated that I start dreaming about something better, then have to reel myself back in because I have no interest in having to support another project for the next 20 years. I've written and submitted PRs to implement improvements in OpenSCAD. Not a single one has been accepted yet. All I can do at this point is TRY to convince devs to let logic prevail. PLEASE.
What I really want is for the OpenSCAD devs to FIX OpenSCAD. And I just haven’t been seeing that, and my attempts to help appear unwanted.
This is how forks happen. This is how forks have already happened to this project.
- Revar
> On Nov 24, 2020, at 9:13 PM, Torsten Paul <Torsten.Paul@gmx.de> wrote:
>
> I don't think the language is the main issue.
> The amount of developer time spend in the project
> is.
>
> You are trying to solve that problem by creating
> another project dividing developer time?
>
> If all that time spent on all those BetterSCADs
> (https://github.com/albinoBandicoot/BetterSCAD)
> could have been joined to improve on OpenSCAD
> itself, most of the problems might not exist
> anymore.
>
> Now there is a place for new projects of course
> and it's up to everyone to decide how to spend
> their time.
>
> I don't believe the OpenSCAD language is the best
> thing invented. If I would start something like
> that, I would likely do it quite differently too.
> But is JavaScript the perfect language? It's
> still used by a couple of people.
>
> Time and time again in different variations I
> have seen how people throw things away to create
> something new based on "new technology" because
> the existing stuff looks old and boring. Just
> to find out a couple of years later they are the
> legacy project now fighting the same issues
> they thought to solve by starting from scratch.
>
> Yes evolving an existing project used by many
> people is much more complicated then just
> changing doing something new, but at some point
> that's going to happen (Python3, Perl6, ...?).
>
> I'm massively impressed by C++ in that regard.
> It was sort-of dead for decades, but started
> moving and now evolves with massive and also
> surprising pace while still keeping the legacy
> working. Is it the neat modern lean language? No,
> far from it. Can you write neat modern code? Yes,
> well, maybe to 98% by using just the new style
> and accepting a couple of warts that are there
> due to backward compatibility reasons.
>
> And OpenSCAD is not just the code, it's also the
> documentation, the books, the people who do
> packaging for various platforms and distros, the
> people who help others and the not so small number
> of people just using it for fun from time to time.
>
> Well, coming back to the original topic of this
> thread I think tools like the static code
> analyzer can help with things like spotting code
> that could be written in a newer style, a more
> performant way or at some point maybe even point
> to libraries that would help simplifying models.
> It could be one puzzle piece for helping the
> OpenSCAD language to evolve.
>
> ciao,
> Torsten.
>
>
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
CA
Carsten Arnholm
Wed, Nov 25, 2020 8:40 AM
On 25.11.2020 03:59, Revar Desmera wrote:
I have a semi-radical idea that I've been thinking of for a while now:
Rip the problematic OpenSCAD language out of OpenSCAD and replace it
with Python3.
Separating functionality from language interpreter is in my opinion a
good idea. Now, which language to replace the OpenSCAD language with is
a matter of preference. There are many good arguments in support of
using Python, but there are also many good arguments against it.
My advice to OpenSCAD would be to make an OpenSCAD API with the boolean
engine etc. (but no scripting language features) and implement the
OpenSCAD language by using the API. The test for true separation would
be if someone could implement a Python or other language interpreter
using the same API
Provide backwards compatibility with a translator written
in a Python parser.
The syntax would be different, but would not have to be very alien:
difference(
union(
translate([0,0,5]) (Sphere(d=10)),
Cube(10,CENTER).down(1).rotate(z=45)
),
Cylinder(d=5,h =5)
).show()
I guess the above is hypothetical. For comparison, in current OpenSCAD:
difference() {
union() {
translate([0,0,5]) sphere(d=10);
rotate([0,0,45])
translate([0,0,-1])
cube(size=10,center=true);
}
cylinder(d=5,h=5);
}
In non-hypothetical AngelCAD (using AngelScript) it could written in
different ways, for example
solid@ u =
translate(0,0,5)
*sphere(r:10./2)
+ rotate_z(deg:45)
*translate(0,0,-1)
*cube(size:10,center:true);
return u - cylinder(r:5./2,h:5);
Or alternatively
return
difference3d(
union3d(
translate(0,0,5)
*sphere(r:10./2),
rotate_z(deg:45)
*translate(0,0,-1)
*cube(size:10,center:true)
),
cylinder(r:5./2,h:5)
);
The benefits could be massive:
Yes, also true in AngelCAD
- You can store geometry in a variable.
- use/include gets replaced by import, which is less buggy.
You mean Python import. The main thing is using a standard language
feature. In AngelScript you have #include without the issues related to
include<> and use<> in OpenSCAD
- Efficient data structures like Dictionaries and Classes are
available.
Yes. Writing your own classes in the scripting language is very powerful.
- You can actually read and parse files from disk.
- You can import C and Fortran based geometry libraries like
ClipperLib and use them directly. (Via Cython if needed)
In theory. I have worked a lot with Fortran and developed a way to
interface it with C++. It is not trivial. I also worked with ClipperLib
and it has its quirks too. But I agree using a n existing language
supported by someone else opens up many new possibilities.
- You can use Cython for code speed-ups.
I use Boost.Python when interfacing python with C++
- There’s a massive pre-existing set of libraries available for all
kinds of things.
This is the best argument in favour of Python.
One argument against python is in my opinion that the language
interpreter is somewhere else on the system and not embedded in the
application like it is in today's OpenSCAD and also in AngelCAD. With
these applications you just install and run scripts. That is a good thing.
With Python you have to have a working Python installation separate from
the application and it has to be compatible with the expectations of the
application. I have managed to almost trash my entire windows and linux
installations, because I did things I should not be doing with Python
because I had issues getting things to work. Granted, most people can
use Python just fine but I think it is an extra hurdle for a lot of people.
Carsten Arnholm
On 25.11.2020 03:59, Revar Desmera wrote:
> I have a semi-radical idea that I've been thinking of for a while now:
> Rip the problematic OpenSCAD language out of OpenSCAD and replace it
> with Python3.
Separating functionality from language interpreter is in my opinion a
good idea. Now, which language to replace the OpenSCAD language with is
a matter of preference. There are many good arguments in support of
using Python, but there are also many good arguments against it.
My advice to OpenSCAD would be to make an OpenSCAD API with the boolean
engine etc. (but no scripting language features) and implement the
OpenSCAD language by using the API. The test for true separation would
be if someone could implement a Python or other language interpreter
using the same API
> Provide backwards compatibility with a translator written
> in a Python parser.
>
> The syntax would be different, but would not have to be very alien:
>
> difference(
> union(
> translate([0,0,5]) (Sphere(d=10)),
> Cube(10,CENTER).down(1).rotate(z=45)
> ),
> Cylinder(d=5,h =5)
> ).show()
I guess the above is hypothetical. For comparison, in current OpenSCAD:
difference() {
union() {
translate([0,0,5]) sphere(d=10);
rotate([0,0,45])
translate([0,0,-1])
cube(size=10,center=true);
}
cylinder(d=5,h=5);
}
In non-hypothetical AngelCAD (using AngelScript) it could written in
different ways, for example
solid@ u =
translate(0,0,5)
*sphere(r:10./2)
+ rotate_z(deg:45)
*translate(0,0,-1)
*cube(size:10,center:true);
return u - cylinder(r:5./2,h:5);
Or alternatively
return
difference3d(
union3d(
translate(0,0,5)
*sphere(r:10./2),
rotate_z(deg:45)
*translate(0,0,-1)
*cube(size:10,center:true)
),
cylinder(r:5./2,h:5)
);
> The benefits could be massive:
>
> * Variables are mutable.
Yes, also true in AngelCAD
> * You can store geometry in a variable.
Yes
> * use/include gets replaced by import, which is less buggy.
You mean Python import. The main thing is using a standard language
feature. In AngelScript you have #include without the issues related to
include<> and use<> in OpenSCAD
> * Efficient data structures like Dictionaries and Classes are
available.
Yes. Writing your own classes in the scripting language is very powerful.
> * You can actually read and parse files from disk.
Yes.
> * You can import C and Fortran based geometry libraries like
> ClipperLib and use them directly. (Via Cython if needed)
In theory. I have worked a lot with Fortran and developed a way to
interface it with C++. It is not trivial. I also worked with ClipperLib
and it has its quirks too. But I agree using a n existing language
supported by someone else opens up many new possibilities.
> * You can use Cython for code speed-ups.
I use Boost.Python when interfacing python with C++
> * There’s a massive pre-existing set of libraries available for all
> kinds of things.
This is the best argument in favour of Python.
One argument against python is in my opinion that the language
interpreter is somewhere else on the system and not embedded in the
application like it is in today's OpenSCAD and also in AngelCAD. With
these applications you just install and run scripts. That is a good thing.
With Python you have to have a working Python installation separate from
the application and it has to be compatible with the expectations of the
application. I have managed to almost trash my entire windows and linux
installations, because I did things I should not be doing with Python
because I had issues getting things to work. Granted, most people can
use Python just fine but I think it is an extra hurdle for a lot of people.
Carsten Arnholm
CA
Carsten Arnholm
Wed, Nov 25, 2020 8:50 AM
On 25.11.2020 07:08, Revar Desmera wrote:
Actually, I’m trying to save the thousands of future hours of effort spent on working around this language. I’ve already spent hundreds of hours on that just by myself. I’m trying to fix most of the issues all at once by replacing the language with a well tested and designed language that is ANOTHER dedicated group’s responsibility to maintain. Frees devs on this project up to work on the editor and the GUI itself.
I agree with this line of thinking.
Here is what I said in this forum 13. May 2015: "I think it is a mistake
that OpenSCAD spends time on defining the syntax of a language. All of
the resources should be spent on improving modelling features. I realise
this is much too late given the user base of the .scad files, but it
strikes me as odd anyway. "
Five years later the .scad language oddities still take a lot of focus.
If a third party language was used it would offer more flexibility,
easier recognition and would free up resources to focus on modelling
features.
Carsten Arnholm
On 25.11.2020 07:08, Revar Desmera wrote:
> Actually, I’m trying to save the thousands of future hours of effort spent on working around this language. I’ve already spent hundreds of hours on that just by myself. I’m trying to fix most of the issues all at once by replacing the language with a well tested and designed language that is ANOTHER dedicated group’s responsibility to maintain. Frees devs on this project up to work on the editor and the GUI itself.
>
I agree with this line of thinking.
Here is what I said in this forum 13. May 2015: "I think it is a mistake
that OpenSCAD spends time on defining the syntax of a language. All of
the resources should be spent on improving modelling features. I realise
this is much too late given the user base of the .scad files, but it
strikes me as odd anyway. "
Five years later the .scad language oddities still take a lot of focus.
If a third party language was used it would offer more flexibility,
easier recognition and would free up resources to focus on modelling
features.
Carsten Arnholm
NH
nop head
Wed, Nov 25, 2020 9:29 AM
OpenSCAD is a language for describing objects, not a programming language.
That makes it much simpler than Python and more concise for describing
geometry. It also means it doesn't need mutable variables as it is a static
description, not a program that runs, so no values need to change over time.
On Wed, 25 Nov 2020 at 08:51, Carsten Arnholm arnholm@arnholm.org wrote:
On 25.11.2020 07:08, Revar Desmera wrote:
Actually, I’m trying to save the thousands of future hours of effort
spent on working around this language. I’ve already spent hundreds of hours
on that just by myself. I’m trying to fix most of the issues all at once by
replacing the language with a well tested and designed language that is
ANOTHER dedicated group’s responsibility to maintain. Frees devs on this
project up to work on the editor and the GUI itself.
I agree with this line of thinking.
Here is what I said in this forum 13. May 2015: "I think it is a mistake
that OpenSCAD spends time on defining the syntax of a language. All of
the resources should be spent on improving modelling features. I realise
this is much too late given the user base of the .scad files, but it
strikes me as odd anyway. "
Five years later the .scad language oddities still take a lot of focus.
If a third party language was used it would offer more flexibility,
easier recognition and would free up resources to focus on modelling
features.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD is a language for describing objects, not a programming language.
That makes it much simpler than Python and more concise for describing
geometry. It also means it doesn't need mutable variables as it is a static
description, not a program that runs, so no values need to change over time.
On Wed, 25 Nov 2020 at 08:51, Carsten Arnholm <arnholm@arnholm.org> wrote:
> On 25.11.2020 07:08, Revar Desmera wrote:
> > Actually, I’m trying to save the thousands of future hours of effort
> spent on working around this language. I’ve already spent hundreds of hours
> on that just by myself. I’m trying to fix most of the issues all at once by
> replacing the language with a well tested and designed language that is
> ANOTHER dedicated group’s responsibility to maintain. Frees devs on this
> project up to work on the editor and the GUI itself.
> >
>
> I agree with this line of thinking.
>
> Here is what I said in this forum 13. May 2015: "I think it is a mistake
> that OpenSCAD spends time on defining the syntax of a language. All of
> the resources should be spent on improving modelling features. I realise
> this is much too late given the user base of the .scad files, but it
> strikes me as odd anyway. "
>
> Five years later the .scad language oddities still take a lot of focus.
> If a third party language was used it would offer more flexibility,
> easier recognition and would free up resources to focus on modelling
> features.
>
> Carsten Arnholm
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
RD
Revar Desmera
Wed, Nov 25, 2020 9:30 AM
The only reason I specify Python is my personal familiarity with it. Making an API for arbitrary languages to use would also be a great idea.
On the Mac you can embed the python interpreter libraries in the .app itself. Under windows you can install it with specific python DLLs. Under Linux it’s preferable to use the system python installation, but you can use a virtualenv instance.
On Nov 25, 2020, at 12:40 AM, Carsten Arnholm arnholm@arnholm.org wrote:
On 25.11.2020 03:59, Revar Desmera wrote:
I have a semi-radical idea that I've been thinking of for a while now:
Rip the problematic OpenSCAD language out of OpenSCAD and replace it
with Python3.
Separating functionality from language interpreter is in my opinion a good idea. Now, which language to replace the OpenSCAD language with is a matter of preference. There are many good arguments in support of using Python, but there are also many good arguments against it.
My advice to OpenSCAD would be to make an OpenSCAD API with the boolean engine etc. (but no scripting language features) and implement the OpenSCAD language by using the API. The test for true separation would be if someone could implement a Python or other language interpreter using the same API
Provide backwards compatibility with a translator written
in a Python parser.
The syntax would be different, but would not have to be very alien:
difference(
union(
translate([0,0,5]) (Sphere(d=10)),
Cube(10,CENTER).down(1).rotate(z=45)
),
Cylinder(d=5,h =5)
).show()
I guess the above is hypothetical. For comparison, in current OpenSCAD:
difference() {
union() {
translate([0,0,5]) sphere(d=10);
rotate([0,0,45])
translate([0,0,-1])
cube(size=10,center=true);
}
cylinder(d=5,h=5);
}
In non-hypothetical AngelCAD (using AngelScript) it could written in different ways, for example
solid@ u =
translate(0,0,5)
*sphere(r:10./2)
+ rotate_z(deg:45)
*translate(0,0,-1)
*cube(size:10,center:true);
return u - cylinder(r:5./2,h:5);
Or alternatively
return
difference3d(
union3d(
translate(0,0,5)
*sphere(r:10./2),
rotate_z(deg:45)
*translate(0,0,-1)
*cube(size:10,center:true)
),
cylinder(r:5./2,h:5)
);
The benefits could be massive:
Yes, also true in AngelCAD
- You can store geometry in a variable.
- use/include gets replaced by import, which is less buggy.
You mean Python import. The main thing is using a standard language feature. In AngelScript you have #include without the issues related to include<> and use<> in OpenSCAD
- Efficient data structures like Dictionaries and Classes are available.
Yes. Writing your own classes in the scripting language is very powerful.
- You can actually read and parse files from disk.
- You can import C and Fortran based geometry libraries like
ClipperLib and use them directly. (Via Cython if needed)
In theory. I have worked a lot with Fortran and developed a way to interface it with C++. It is not trivial. I also worked with ClipperLib and it has its quirks too. But I agree using a n existing language supported by someone else opens up many new possibilities.
- You can use Cython for code speed-ups.
I use Boost.Python when interfacing python with C++
- There’s a massive pre-existing set of libraries available for all
kinds of things.
This is the best argument in favour of Python.
One argument against python is in my opinion that the language interpreter is somewhere else on the system and not embedded in the application like it is in today's OpenSCAD and also in AngelCAD. With these applications you just install and run scripts. That is a good thing.
With Python you have to have a working Python installation separate from the application and it has to be compatible with the expectations of the application. I have managed to almost trash my entire windows and linux installations, because I did things I should not be doing with Python because I had issues getting things to work. Granted, most people can use Python just fine but I think it is an extra hurdle for a lot of people.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
The only reason I specify Python is my personal familiarity with it. Making an API for arbitrary languages to use would also be a great idea.
On the Mac you can embed the python interpreter libraries in the .app itself. Under windows you can install it with specific python DLLs. Under Linux it’s preferable to use the system python installation, but you can use a virtualenv instance.
- Revar
> On Nov 25, 2020, at 12:40 AM, Carsten Arnholm <arnholm@arnholm.org> wrote:
>
> On 25.11.2020 03:59, Revar Desmera wrote:
> > I have a semi-radical idea that I've been thinking of for a while now:
> > Rip the problematic OpenSCAD language out of OpenSCAD and replace it
> > with Python3.
>
> Separating functionality from language interpreter is in my opinion a good idea. Now, which language to replace the OpenSCAD language with is a matter of preference. There are many good arguments in support of using Python, but there are also many good arguments against it.
>
> My advice to OpenSCAD would be to make an OpenSCAD API with the boolean engine etc. (but no scripting language features) and implement the OpenSCAD language by using the API. The test for true separation would be if someone could implement a Python or other language interpreter using the same API
>
> > Provide backwards compatibility with a translator written
> > in a Python parser.
> >
> > The syntax would be different, but would not have to be very alien:
> >
> > difference(
> > union(
> > translate([0,0,5]) (Sphere(d=10)),
> > Cube(10,CENTER).down(1).rotate(z=45)
> > ),
> > Cylinder(d=5,h =5)
> > ).show()
>
>
> I guess the above is hypothetical. For comparison, in current OpenSCAD:
>
> difference() {
> union() {
> translate([0,0,5]) sphere(d=10);
> rotate([0,0,45])
> translate([0,0,-1])
> cube(size=10,center=true);
> }
> cylinder(d=5,h=5);
> }
>
> In non-hypothetical AngelCAD (using AngelScript) it could written in different ways, for example
>
> solid@ u =
> translate(0,0,5)
> *sphere(r:10./2)
> + rotate_z(deg:45)
> *translate(0,0,-1)
> *cube(size:10,center:true);
> return u - cylinder(r:5./2,h:5);
>
> Or alternatively
>
> return
> difference3d(
> union3d(
> translate(0,0,5)
> *sphere(r:10./2),
> rotate_z(deg:45)
> *translate(0,0,-1)
> *cube(size:10,center:true)
> ),
> cylinder(r:5./2,h:5)
> );
>
>
> > The benefits could be massive:
> >
> > * Variables are mutable.
>
> Yes, also true in AngelCAD
>
> > * You can store geometry in a variable.
>
> Yes
>
> > * use/include gets replaced by import, which is less buggy.
>
> You mean Python import. The main thing is using a standard language feature. In AngelScript you have #include without the issues related to include<> and use<> in OpenSCAD
>
> > * Efficient data structures like Dictionaries and Classes are available.
>
> Yes. Writing your own classes in the scripting language is very powerful.
>
> > * You can actually read and parse files from disk.
>
> Yes.
>
> > * You can import C and Fortran based geometry libraries like
> > ClipperLib and use them directly. (Via Cython if needed)
>
> In theory. I have worked a lot with Fortran and developed a way to interface it with C++. It is not trivial. I also worked with ClipperLib and it has its quirks too. But I agree using a n existing language supported by someone else opens up many new possibilities.
>
> > * You can use Cython for code speed-ups.
>
> I use Boost.Python when interfacing python with C++
>
> > * There’s a massive pre-existing set of libraries available for all
> > kinds of things.
>
> This is the best argument in favour of Python.
>
> One argument against python is in my opinion that the language interpreter is somewhere else on the system and not embedded in the application like it is in today's OpenSCAD and also in AngelCAD. With these applications you just install and run scripts. That is a good thing.
>
> With Python you have to have a working Python installation separate from the application and it has to be compatible with the expectations of the application. I have managed to almost trash my entire windows and linux installations, because I did things I should not be doing with Python because I had issues getting things to work. Granted, most people can use Python just fine but I think it is an extra hurdle for a lot of people.
>
> Carsten Arnholm
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
RD
Revar Desmera
Wed, Nov 25, 2020 9:37 AM
What I read from that comment is that OpenSCAD is not currently a proper language, and it should just be treated like Display Postscript. Which ironically is actually a more capable language, if a lot more of a pain to write in.
On Nov 25, 2020, at 1:30 AM, nop head nop.head@gmail.com wrote:
OpenSCAD is a language for describing objects, not a programming language. That makes it much simpler than Python and more concise for describing geometry. It also means it doesn't need mutable variables as it is a static description, not a program that runs, so no values need to change over time.
On Wed, 25 Nov 2020 at 08:51, Carsten Arnholm arnholm@arnholm.org wrote:
On 25.11.2020 07:08, Revar Desmera wrote:
Actually, I’m trying to save the thousands of future hours of effort spent on working around this language. I’ve already spent hundreds of hours on that just by myself. I’m trying to fix most of the issues all at once by replacing the language with a well tested and designed language that is ANOTHER dedicated group’s responsibility to maintain. Frees devs on this project up to work on the editor and the GUI itself.
I agree with this line of thinking.
Here is what I said in this forum 13. May 2015: "I think it is a mistake
that OpenSCAD spends time on defining the syntax of a language. All of
the resources should be spent on improving modelling features. I realise
this is much too late given the user base of the .scad files, but it
strikes me as odd anyway. "
Five years later the .scad language oddities still take a lot of focus.
If a third party language was used it would offer more flexibility,
easier recognition and would free up resources to focus on modelling
features.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
What I read from that comment is that OpenSCAD is not currently a proper language, and it should just be treated like Display Postscript. Which ironically is actually a more capable language, if a lot more of a pain to write in.
- Revar
> On Nov 25, 2020, at 1:30 AM, nop head <nop.head@gmail.com> wrote:
>
>
> OpenSCAD is a language for describing objects, not a programming language. That makes it much simpler than Python and more concise for describing geometry. It also means it doesn't need mutable variables as it is a static description, not a program that runs, so no values need to change over time.
>
>> On Wed, 25 Nov 2020 at 08:51, Carsten Arnholm <arnholm@arnholm.org> wrote:
>> On 25.11.2020 07:08, Revar Desmera wrote:
>> > Actually, I’m trying to save the thousands of future hours of effort spent on working around this language. I’ve already spent hundreds of hours on that just by myself. I’m trying to fix most of the issues all at once by replacing the language with a well tested and designed language that is ANOTHER dedicated group’s responsibility to maintain. Frees devs on this project up to work on the editor and the GUI itself.
>> >
>>
>> I agree with this line of thinking.
>>
>> Here is what I said in this forum 13. May 2015: "I think it is a mistake
>> that OpenSCAD spends time on defining the syntax of a language. All of
>> the resources should be spent on improving modelling features. I realise
>> this is much too late given the user base of the .scad files, but it
>> strikes me as odd anyway. "
>>
>> Five years later the .scad language oddities still take a lot of focus.
>> If a third party language was used it would offer more flexibility,
>> easier recognition and would free up resources to focus on modelling
>> features.
>>
>> Carsten Arnholm
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> Discuss@lists.openscad.org
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
CN
Csaba Nagy
Wed, Nov 25, 2020 9:43 AM
Have you checked out https://github.com/SolidCode/SolidPython ?
In my opinion Openscad is just OK as it is... solidpython is doing a
good job too, what might be needed is more libraries written for
solidpython, taking advantage of the power of python. Openscad
libraries can already be wrapped and addressed, but the results
returned by such a library are opaque (being calculated at OpenScad
run-time), while python funtions can return python objects useful for
further processing in the solidpython code. For example it's much
easier to write libraries for connecting objects if you actually have
encapsulated objects with known interfaces to address. It's a
completely different way of doing things than the OpenScad philosophy,
less precise and sloppier perhaps, but it comes down to the compromise
you want to take - have some immediately working code you can play
around with, or plan everything from the beginning and only have it
properly working at the end. With OpenScad you need proper planning,
python invites you to play, pick yours.
As environment I use IntelliJ PyCharm, which allows me to set up
shortcuts to run the solidpython code at the press of a button, then
the OpenScad widnow will refresh automatically. I'm perfectly happy
with that... From a speed perspective it seems workable too, have some
bigger models which run quite reasonably. At the moment solidpython
will generate code where lots of repetition of the same OpenScad code
can occur (if you re-use the same SolidPython object multiple times),
but that seems to not be a problem.
If it would be a help for anybody, I could create a tutorial on how to
set up PyCharm to comfortably work with SolidPython, anybody interested
?
Cheers,
Csaba
On Wed, 2020-11-25 at 09:40 +0100, Carsten Arnholm wrote:
On 25.11.2020 03:59, Revar Desmera wrote:
I have a semi-radical idea that I've been thinking of for a while
Rip the problematic OpenSCAD language out of OpenSCAD and replace
Separating functionality from language interpreter is in my opinion
a
good idea. Now, which language to replace the OpenSCAD language with
is
a matter of preference. There are many good arguments in support of
using Python, but there are also many good arguments against it.
My advice to OpenSCAD would be to make an OpenSCAD API with the
boolean
engine etc. (but no scripting language features) and implement the
OpenSCAD language by using the API. The test for true separation
would
be if someone could implement a Python or other language interpreter
using the same API
Provide backwards compatibility with a translator written
in a Python parser.
The syntax would be different, but would not have to be very
difference(
union(
translate([0,0,5]) (Sphere(d=10)),
Cube(10,CENTER).down(1).rotate(z=45)
),
Cylinder(d=5,h =5)
).show()
I guess the above is hypothetical. For comparison, in current
OpenSCAD:
difference() {
union() {
translate([0,0,5]) sphere(d=10);
rotate([0,0,45])
translate([0,0,-1])
cube(size=10,center=true);
}
cylinder(d=5,h=5);
}
In non-hypothetical AngelCAD (using AngelScript) it could written in
different ways, for example
solid@ u =
translate(0,0,5)
*sphere(r:10./2)
+ rotate_z(deg:45)
*translate(0,0,-1)
*cube(size:10,center:true);
return u - cylinder(r:5./2,h:5);
Or alternatively
return
difference3d(
union3d(
translate(0,0,5)
*sphere(r:10./2),
rotate_z(deg:45)
*translate(0,0,-1)
*cube(size:10,center:true)
),
cylinder(r:5./2,h:5)
);
The benefits could be massive:
Yes, also true in AngelCAD
- You can store geometry in a variable.
- use/include gets replaced by import, which is less buggy.
You mean Python import. The main thing is using a standard language
feature. In AngelScript you have #include without the issues related
to
include<> and use<> in OpenSCAD
- Efficient data structures like Dictionaries and Classes are
available.
Yes. Writing your own classes in the scripting language is very
powerful.
- You can actually read and parse files from disk.
- You can import C and Fortran based geometry libraries like
ClipperLib and use them directly. (Via Cython if needed)
In theory. I have worked a lot with Fortran and developed a way to
interface it with C++. It is not trivial. I also worked with
ClipperLib
and it has its quirks too. But I agree using a n existing language
supported by someone else opens up many new possibilities.
- You can use Cython for code speed-ups.
I use Boost.Python when interfacing python with C++
- There’s a massive pre-existing set of libraries available for
This is the best argument in favour of Python.
One argument against python is in my opinion that the language
interpreter is somewhere else on the system and not embedded in the
application like it is in today's OpenSCAD and also in AngelCAD.
With
these applications you just install and run scripts. That is a good
thing.
With Python you have to have a working Python installation separate
from
the application and it has to be compatible with the expectations of
the
application. I have managed to almost trash my entire windows and
linux
installations, because I did things I should not be doing with
Python
because I had issues getting things to work. Granted, most people
can
use Python just fine but I think it is an extra hurdle for a lot of
people.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Have you checked out https://github.com/SolidCode/SolidPython ?
In my opinion Openscad is just OK as it is... solidpython is doing a
good job too, what might be needed is more libraries written for
solidpython, taking advantage of the power of python. Openscad
libraries can already be wrapped and addressed, but the results
returned by such a library are opaque (being calculated at OpenScad
run-time), while python funtions can return python objects useful for
further processing in the solidpython code. For example it's much
easier to write libraries for connecting objects if you actually have
encapsulated objects with known interfaces to address. It's a
completely different way of doing things than the OpenScad philosophy,
less precise and sloppier perhaps, but it comes down to the compromise
you want to take - have some immediately working code you can play
around with, or plan everything from the beginning and only have it
properly working at the end. With OpenScad you need proper planning,
python invites you to play, pick yours.
As environment I use IntelliJ PyCharm, which allows me to set up
shortcuts to run the solidpython code at the press of a button, then
the OpenScad widnow will refresh automatically. I'm perfectly happy
with that... From a speed perspective it seems workable too, have some
bigger models which run quite reasonably. At the moment solidpython
will generate code where lots of repetition of the same OpenScad code
can occur (if you re-use the same SolidPython object multiple times),
but that seems to not be a problem.
If it would be a help for anybody, I could create a tutorial on how to
set up PyCharm to comfortably work with SolidPython, anybody interested
?
Cheers,
Csaba
On Wed, 2020-11-25 at 09:40 +0100, Carsten Arnholm wrote:
> On 25.11.2020 03:59, Revar Desmera wrote:
> > I have a semi-radical idea that I've been thinking of for a while
> now:
> > Rip the problematic OpenSCAD language out of OpenSCAD and replace
> it
> > with Python3.
>
> Separating functionality from language interpreter is in my opinion
> a
> good idea. Now, which language to replace the OpenSCAD language with
> is
> a matter of preference. There are many good arguments in support of
> using Python, but there are also many good arguments against it.
>
> My advice to OpenSCAD would be to make an OpenSCAD API with the
> boolean
> engine etc. (but no scripting language features) and implement the
> OpenSCAD language by using the API. The test for true separation
> would
> be if someone could implement a Python or other language interpreter
> using the same API
>
> > Provide backwards compatibility with a translator written
> > in a Python parser.
> >
> > The syntax would be different, but would not have to be very
> alien:
> >
> > difference(
> > union(
> > translate([0,0,5]) (Sphere(d=10)),
> > Cube(10,CENTER).down(1).rotate(z=45)
> > ),
> > Cylinder(d=5,h =5)
> > ).show()
>
>
> I guess the above is hypothetical. For comparison, in current
> OpenSCAD:
>
> difference() {
> union() {
> translate([0,0,5]) sphere(d=10);
> rotate([0,0,45])
> translate([0,0,-1])
> cube(size=10,center=true);
> }
> cylinder(d=5,h=5);
> }
>
> In non-hypothetical AngelCAD (using AngelScript) it could written in
> different ways, for example
>
> solid@ u =
> translate(0,0,5)
> *sphere(r:10./2)
> + rotate_z(deg:45)
> *translate(0,0,-1)
> *cube(size:10,center:true);
> return u - cylinder(r:5./2,h:5);
>
> Or alternatively
>
> return
> difference3d(
> union3d(
> translate(0,0,5)
> *sphere(r:10./2),
> rotate_z(deg:45)
> *translate(0,0,-1)
> *cube(size:10,center:true)
> ),
> cylinder(r:5./2,h:5)
> );
>
>
> > The benefits could be massive:
> >
> > * Variables are mutable.
>
> Yes, also true in AngelCAD
>
> > * You can store geometry in a variable.
>
> Yes
>
> > * use/include gets replaced by import, which is less buggy.
>
> You mean Python import. The main thing is using a standard language
> feature. In AngelScript you have #include without the issues related
> to
> include<> and use<> in OpenSCAD
>
> > * Efficient data structures like Dictionaries and Classes are
> available.
>
> Yes. Writing your own classes in the scripting language is very
> powerful.
>
> > * You can actually read and parse files from disk.
>
> Yes.
>
> > * You can import C and Fortran based geometry libraries like
> > ClipperLib and use them directly. (Via Cython if needed)
>
> In theory. I have worked a lot with Fortran and developed a way to
> interface it with C++. It is not trivial. I also worked with
> ClipperLib
> and it has its quirks too. But I agree using a n existing language
> supported by someone else opens up many new possibilities.
>
> > * You can use Cython for code speed-ups.
>
> I use Boost.Python when interfacing python with C++
>
> > * There’s a massive pre-existing set of libraries available for
> all
> > kinds of things.
>
> This is the best argument in favour of Python.
>
> One argument against python is in my opinion that the language
> interpreter is somewhere else on the system and not embedded in the
> application like it is in today's OpenSCAD and also in AngelCAD.
> With
> these applications you just install and run scripts. That is a good
> thing.
>
> With Python you have to have a working Python installation separate
> from
> the application and it has to be compatible with the expectations of
> the
> application. I have managed to almost trash my entire windows and
> linux
> installations, because I did things I should not be doing with
> Python
> because I had issues getting things to work. Granted, most people
> can
> use Python just fine but I think it is an extra hurdle for a lot of
> people.
>
> Carsten Arnholm
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
RD
Revar Desmera
Wed, Nov 25, 2020 9:49 AM
If you have to drop to the command line to install it, you’ve already declared that newbie users need not apply. That’s a losing position for a project that intends to ever expand.
On Nov 25, 2020, at 1:44 AM, Csaba Nagy ncsaba@javampire.com wrote:
Have you checked out https://github.com/SolidCode/SolidPython ?
In my opinion Openscad is just OK as it is... solidpython is doing a
good job too, what might be needed is more libraries written for
solidpython, taking advantage of the power of python. Openscad
libraries can already be wrapped and addressed, but the results
returned by such a library are opaque (being calculated at OpenScad
run-time), while python funtions can return python objects useful for
further processing in the solidpython code. For example it's much
easier to write libraries for connecting objects if you actually have
encapsulated objects with known interfaces to address. It's a
completely different way of doing things than the OpenScad philosophy,
less precise and sloppier perhaps, but it comes down to the compromise
you want to take - have some immediately working code you can play
around with, or plan everything from the beginning and only have it
properly working at the end. With OpenScad you need proper planning,
python invites you to play, pick yours.
As environment I use IntelliJ PyCharm, which allows me to set up
shortcuts to run the solidpython code at the press of a button, then
the OpenScad widnow will refresh automatically. I'm perfectly happy
with that... From a speed perspective it seems workable too, have some
bigger models which run quite reasonably. At the moment solidpython
will generate code where lots of repetition of the same OpenScad code
can occur (if you re-use the same SolidPython object multiple times),
but that seems to not be a problem.
If it would be a help for anybody, I could create a tutorial on how to
set up PyCharm to comfortably work with SolidPython, anybody interested
?
Cheers,
Csaba
On Wed, 2020-11-25 at 09:40 +0100, Carsten Arnholm wrote:
On 25.11.2020 03:59, Revar Desmera wrote:
I have a semi-radical idea that I've been thinking of for a while
Rip the problematic OpenSCAD language out of OpenSCAD and replace
Separating functionality from language interpreter is in my opinion
a
good idea. Now, which language to replace the OpenSCAD language with
is
a matter of preference. There are many good arguments in support of
using Python, but there are also many good arguments against it.
My advice to OpenSCAD would be to make an OpenSCAD API with the
boolean
engine etc. (but no scripting language features) and implement the
OpenSCAD language by using the API. The test for true separation
would
be if someone could implement a Python or other language interpreter
using the same API
Provide backwards compatibility with a translator written
in a Python parser.
The syntax would be different, but would not have to be very
difference(
union(
translate([0,0,5]) (Sphere(d=10)),
Cube(10,CENTER).down(1).rotate(z=45)
),
Cylinder(d=5,h =5)
).show()
I guess the above is hypothetical. For comparison, in current
OpenSCAD:
difference() {
union() {
translate([0,0,5]) sphere(d=10);
rotate([0,0,45])
translate([0,0,-1])
cube(size=10,center=true);
}
cylinder(d=5,h=5);
}
In non-hypothetical AngelCAD (using AngelScript) it could written in
different ways, for example
solid@ u =
translate(0,0,5)
*sphere(r:10./2)
+ rotate_z(deg:45)
*translate(0,0,-1)
*cube(size:10,center:true);
return u - cylinder(r:5./2,h:5);
Or alternatively
return
difference3d(
union3d(
translate(0,0,5)
*sphere(r:10./2),
rotate_z(deg:45)
*translate(0,0,-1)
*cube(size:10,center:true)
),
cylinder(r:5./2,h:5)
);
The benefits could be massive:
Yes, also true in AngelCAD
- You can store geometry in a variable.
- use/include gets replaced by import, which is less buggy.
You mean Python import. The main thing is using a standard language
feature. In AngelScript you have #include without the issues related
to
include<> and use<> in OpenSCAD
- Efficient data structures like Dictionaries and Classes are
available.
Yes. Writing your own classes in the scripting language is very
powerful.
- You can actually read and parse files from disk.
- You can import C and Fortran based geometry libraries like
ClipperLib and use them directly. (Via Cython if needed)
In theory. I have worked a lot with Fortran and developed a way to
interface it with C++. It is not trivial. I also worked with
ClipperLib
and it has its quirks too. But I agree using a n existing language
supported by someone else opens up many new possibilities.
- You can use Cython for code speed-ups.
I use Boost.Python when interfacing python with C++
- There’s a massive pre-existing set of libraries available for
This is the best argument in favour of Python.
One argument against python is in my opinion that the language
interpreter is somewhere else on the system and not embedded in the
application like it is in today's OpenSCAD and also in AngelCAD.
With
these applications you just install and run scripts. That is a good
thing.
With Python you have to have a working Python installation separate
from
the application and it has to be compatible with the expectations of
the
application. I have managed to almost trash my entire windows and
linux
installations, because I did things I should not be doing with
Python
because I had issues getting things to work. Granted, most people
can
use Python just fine but I think it is an extra hurdle for a lot of
people.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
If you have to drop to the command line to install it, you’ve already declared that newbie users need not apply. That’s a losing position for a project that intends to ever expand.
- Revar
> On Nov 25, 2020, at 1:44 AM, Csaba Nagy <ncsaba@javampire.com> wrote:
>
> Have you checked out https://github.com/SolidCode/SolidPython ?
>
> In my opinion Openscad is just OK as it is... solidpython is doing a
> good job too, what might be needed is more libraries written for
> solidpython, taking advantage of the power of python. Openscad
> libraries can already be wrapped and addressed, but the results
> returned by such a library are opaque (being calculated at OpenScad
> run-time), while python funtions can return python objects useful for
> further processing in the solidpython code. For example it's much
> easier to write libraries for connecting objects if you actually have
> encapsulated objects with known interfaces to address. It's a
> completely different way of doing things than the OpenScad philosophy,
> less precise and sloppier perhaps, but it comes down to the compromise
> you want to take - have some immediately working code you can play
> around with, or plan everything from the beginning and only have it
> properly working at the end. With OpenScad you need proper planning,
> python invites you to play, pick yours.
>
> As environment I use IntelliJ PyCharm, which allows me to set up
> shortcuts to run the solidpython code at the press of a button, then
> the OpenScad widnow will refresh automatically. I'm perfectly happy
> with that... From a speed perspective it seems workable too, have some
> bigger models which run quite reasonably. At the moment solidpython
> will generate code where lots of repetition of the same OpenScad code
> can occur (if you re-use the same SolidPython object multiple times),
> but that seems to not be a problem.
>
> If it would be a help for anybody, I could create a tutorial on how to
> set up PyCharm to comfortably work with SolidPython, anybody interested
> ?
>
> Cheers,
> Csaba
>
>> On Wed, 2020-11-25 at 09:40 +0100, Carsten Arnholm wrote:
>>> On 25.11.2020 03:59, Revar Desmera wrote:
>>> I have a semi-radical idea that I've been thinking of for a while
>> now:
>>> Rip the problematic OpenSCAD language out of OpenSCAD and replace
>> it
>>> with Python3.
>>
>> Separating functionality from language interpreter is in my opinion
>> a
>> good idea. Now, which language to replace the OpenSCAD language with
>> is
>> a matter of preference. There are many good arguments in support of
>> using Python, but there are also many good arguments against it.
>>
>> My advice to OpenSCAD would be to make an OpenSCAD API with the
>> boolean
>> engine etc. (but no scripting language features) and implement the
>> OpenSCAD language by using the API. The test for true separation
>> would
>> be if someone could implement a Python or other language interpreter
>> using the same API
>>
>>> Provide backwards compatibility with a translator written
>>> in a Python parser.
>>>
>>> The syntax would be different, but would not have to be very
>> alien:
>>>
>>> difference(
>>> union(
>>> translate([0,0,5]) (Sphere(d=10)),
>>> Cube(10,CENTER).down(1).rotate(z=45)
>>> ),
>>> Cylinder(d=5,h =5)
>>> ).show()
>>
>>
>> I guess the above is hypothetical. For comparison, in current
>> OpenSCAD:
>>
>> difference() {
>> union() {
>> translate([0,0,5]) sphere(d=10);
>> rotate([0,0,45])
>> translate([0,0,-1])
>> cube(size=10,center=true);
>> }
>> cylinder(d=5,h=5);
>> }
>>
>> In non-hypothetical AngelCAD (using AngelScript) it could written in
>> different ways, for example
>>
>> solid@ u =
>> translate(0,0,5)
>> *sphere(r:10./2)
>> + rotate_z(deg:45)
>> *translate(0,0,-1)
>> *cube(size:10,center:true);
>> return u - cylinder(r:5./2,h:5);
>>
>> Or alternatively
>>
>> return
>> difference3d(
>> union3d(
>> translate(0,0,5)
>> *sphere(r:10./2),
>> rotate_z(deg:45)
>> *translate(0,0,-1)
>> *cube(size:10,center:true)
>> ),
>> cylinder(r:5./2,h:5)
>> );
>>
>>
>>> The benefits could be massive:
>>>
>>> * Variables are mutable.
>>
>> Yes, also true in AngelCAD
>>
>>> * You can store geometry in a variable.
>>
>> Yes
>>
>>> * use/include gets replaced by import, which is less buggy.
>>
>> You mean Python import. The main thing is using a standard language
>> feature. In AngelScript you have #include without the issues related
>> to
>> include<> and use<> in OpenSCAD
>>
>>> * Efficient data structures like Dictionaries and Classes are
>> available.
>>
>> Yes. Writing your own classes in the scripting language is very
>> powerful.
>>
>>> * You can actually read and parse files from disk.
>>
>> Yes.
>>
>>> * You can import C and Fortran based geometry libraries like
>>> ClipperLib and use them directly. (Via Cython if needed)
>>
>> In theory. I have worked a lot with Fortran and developed a way to
>> interface it with C++. It is not trivial. I also worked with
>> ClipperLib
>> and it has its quirks too. But I agree using a n existing language
>> supported by someone else opens up many new possibilities.
>>
>>> * You can use Cython for code speed-ups.
>>
>> I use Boost.Python when interfacing python with C++
>>
>>> * There’s a massive pre-existing set of libraries available for
>> all
>>> kinds of things.
>>
>> This is the best argument in favour of Python.
>>
>> One argument against python is in my opinion that the language
>> interpreter is somewhere else on the system and not embedded in the
>> application like it is in today's OpenSCAD and also in AngelCAD.
>> With
>> these applications you just install and run scripts. That is a good
>> thing.
>>
>> With Python you have to have a working Python installation separate
>> from
>> the application and it has to be compatible with the expectations of
>> the
>> application. I have managed to almost trash my entire windows and
>> linux
>> installations, because I did things I should not be doing with
>> Python
>> because I had issues getting things to work. Granted, most people
>> can
>> use Python just fine but I think it is an extra hurdle for a lot of
>> people.
>>
>> Carsten Arnholm
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> Discuss@lists.openscad.org
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
