RD
Revar Desmera
Fri, Mar 19, 2021 9:26 PM
Okay, everyone remember when I proposed ripping the OpenSCAD language out of OpenSCAD and replacing it with Python?
Yeah, well Python isn’t easily embeddable, and has security implications.
Lua, however is easily embeddable, can be secure, and is easily extendable to handle a geometry data type. Lua is a well used and supported language. It has mutable variables, first class functions, tables(!), threads(!!), and multiple assignment(!!!). It lacks object orientation, but we never had that anyways. Even just having tables makes a number of algorithms far faster and easier to implement.
This could easily become a thing. It really should.
http://www.lua.org/pil/contents.html
-Revar
On Mar 19, 2021, at 10:48 AM, Carsten Fuchs carsten.fuchs@cafu.de wrote:
Please forgive me, but if it was ever considered to add imperative language support to OpenSCAD: Lua (http://www.lua.org/) would be a perfect fit! (And it would open OpenSCAD to folks who don't have a degree in CS…)
Okay, everyone remember when I proposed ripping the OpenSCAD language out of OpenSCAD and replacing it with Python?
Yeah, well Python isn’t easily embeddable, and has security implications.
Lua, however is easily embeddable, can be secure, and is easily extendable to handle a geometry data type. Lua is a well used and supported language. It has mutable variables, first class functions, tables(!), threads(!!), and multiple assignment(!!!). It lacks object orientation, but we never had that anyways. Even just having tables makes a number of algorithms far faster and easier to implement.
This could easily become a thing. It really should.
http://www.lua.org/pil/contents.html
-Revar
> On Mar 19, 2021, at 10:48 AM, Carsten Fuchs <carsten.fuchs@cafu.de> wrote:
>
> Please forgive me, but if it was ever considered to add imperative language support to OpenSCAD: Lua (http://www.lua.org/) would be a perfect fit! (And it would open OpenSCAD to folks who don't have a degree in CS…)
W
Whosawhatsis
Fri, Mar 19, 2021 9:58 PM
Changing OpenSCAD to use a different language is a terrible idea, because you would break compatibility with all of the existing OpenSCAD code, and force the people who know how to use it to re-learn it. The python 2.x to python 3.x changed enough to make existing projects and libraries incompatible, and it's taken over 10 years to get people to use the new system. Trying to rip out the core of the language syntax and replace it would be even worse.
https://www.openscad.org/about.html has a list of related projects, most of which are implementations of OpenSCAD-like functionality with other languages (and I can think of a few others that should be on that list off the top of my head). If you want OpenSCAD-like functionality in a different language, try one of those, or start another one. Maybe it will be better and eventually get more popular than OpenSCAD, but quit trying to break OpenSCAD by forcing it to be something it isn't.
If OpenSCAD had features like true variables and OOP capabilities, would I use them? Of course I would, but they would need to be added in a way that maintained backward-compatibility and didn't fundamentally change the structure of the language. Replacing the core of the language with Python, Lua, Javascript, Haskell, FORTRAN, or native american smoke signals isn't something you can do without breaking everything.
On Mar 19, 2021, 14:27 -0700, Revar Desmera revarbat@gmail.com, wrote:
Okay, everyone remember when I proposed ripping the OpenSCAD language out of OpenSCAD and replacing it with Python?
Yeah, well Python isn’t easily embeddable, and has security implications.
Lua, however is easily embeddable, can be secure, and is easily extendable to handle a geometry data type. Lua is a well used and supported language. It has mutable variables, first class functions, tables(!), threads(!!), and multiple assignment(!!!). It lacks object orientation, but we never had that anyways. Even just having tables makes a number of algorithms far faster and easier to implement.
This could easily become a thing. It really should.
http://www.lua.org/pil/contents.html
-Revar
On Mar 19, 2021, at 10:48 AM, Carsten Fuchs carsten.fuchs@cafu.de wrote:
Please forgive me, but if it was ever considered to add imperative language support to OpenSCAD: Lua (http://www.lua.org/) would be a perfect fit! (And it would open OpenSCAD to folks who don't have a degree in CS…)
Changing OpenSCAD to use a different language is a terrible idea, because you would break compatibility with all of the existing OpenSCAD code, and force the people who know how to use it to re-learn it. The python 2.x to python 3.x changed enough to make existing projects and libraries incompatible, and it's taken over 10 years to get people to use the new system. Trying to rip out the core of the language syntax and replace it would be even worse.
https://www.openscad.org/about.html has a list of related projects, most of which are implementations of OpenSCAD-like functionality with other languages (and I can think of a few others that should be on that list off the top of my head). If you want OpenSCAD-like functionality in a different language, try one of those, or start another one. Maybe it will be better and eventually get more popular than OpenSCAD, but quit trying to break OpenSCAD by forcing it to be something it isn't.
If OpenSCAD had features like true variables and OOP capabilities, would I use them? Of course I would, but they would need to be added in a way that maintained backward-compatibility and didn't fundamentally change the structure of the language. Replacing the core of the language with Python, Lua, Javascript, Haskell, FORTRAN, or native american smoke signals isn't something you can do without breaking everything.
On Mar 19, 2021, 14:27 -0700, Revar Desmera <revarbat@gmail.com>, wrote:
>
> Okay, everyone remember when I proposed ripping the OpenSCAD language out of OpenSCAD and replacing it with Python?
>
> Yeah, well Python isn’t easily embeddable, and has security implications.
>
> Lua, however is easily embeddable, can be secure, and is easily extendable to handle a geometry data type. Lua is a well used and supported language. It has mutable variables, first class functions, tables(!), threads(!!), and multiple assignment(!!!). It lacks object orientation, but we never had that anyways. Even just having tables makes a number of algorithms far faster and easier to implement.
>
> This could easily become a thing. It really should.
>
> http://www.lua.org/pil/contents.html
>
> -Revar
>
>
> > On Mar 19, 2021, at 10:48 AM, Carsten Fuchs <carsten.fuchs@cafu.de> wrote:
> >
> > Please forgive me, but if it was ever considered to add imperative language support to OpenSCAD: Lua (http://www.lua.org/) would be a perfect fit! (And it would open OpenSCAD to folks who don't have a degree in CS…)
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
JB
Jordan Brown
Fri, Mar 19, 2021 10:47 PM
On 3/19/2021 2:58 PM, Whosawhatsis wrote:
https://www.openscad.org/about.html
https://www.openscad.org/about.html has a list of related projects,
most of which are implementations of OpenSCAD-like functionality with
other languages (and I can think of a few others that should be on
that list off the top of my head). If you want OpenSCAD-like
functionality in a different language, try one of those, or start
another one. Maybe it will be better and eventually get more popular
than OpenSCAD, but quit trying to break OpenSCAD by forcing it to be
something it isn't.
I don't think anybody is trying to say that an OpenSCAD-like environment
based on another language would still be OpenSCAD. It wouldn't, or at
least it would need some major distinguisher in its name. It would be
PySCAD or LuaSCAD or OpenJSCAD or something. Maybe, but probably not,
OpenSCAD2.
So yes, if you view "the community" as being people who want to maintain
OpenSCAD compatibility, such an effort would be a non-starter. If, on
the other hand, you view "the community" as being people who want to
write simple programs to generate geometry, and for whom OpenSCAD is
simply the best answer currently available, then a transition to a
different base language would make perfect sense.
And yes, this is the "OpenSCAD general discussion" mailing list, not the
"3D geometry programming language" discussion list, so such discussions
here should be relatively limited.
On 3/19/2021 2:58 PM, Whosawhatsis wrote:
> https://www.openscad.org/about.html
> <https://www.openscad.org/about.html> has a list of related projects,
> most of which are implementations of OpenSCAD-like functionality with
> other languages (and I can think of a few others that should be on
> that list off the top of my head). If you want OpenSCAD-like
> functionality in a different language, try one of those, or start
> another one. Maybe it will be better and eventually get more popular
> than OpenSCAD, but quit trying to break OpenSCAD by forcing it to be
> something it isn't.
I don't think anybody is trying to say that an OpenSCAD-like environment
based on another language would still be OpenSCAD. It wouldn't, or at
least it would need some major distinguisher in its name. It would be
PySCAD or LuaSCAD or OpenJSCAD or something. Maybe, but probably not,
OpenSCAD2.
So yes, if you view "the community" as being people who want to maintain
OpenSCAD compatibility, such an effort would be a non-starter. If, on
the other hand, you view "the community" as being people who want to
write simple programs to generate geometry, and for whom OpenSCAD is
simply the best answer currently available, then a transition to a
different base language would make perfect sense.
And yes, this is the "OpenSCAD general discussion" mailing list, not the
"3D geometry programming language" discussion list, so such discussions
here should be relatively limited.
W
Whosawhatsis
Fri, Mar 19, 2021 10:55 PM
I'm fine with an "ideas for OpenSCAD-like things based on other languages" thread, but I'm sick of people talking about it as if "ripping the OpenSCAD language out of OpenSCAD and replacing it with" something else (a direct quote) made any sense at all.
On Mar 19, 2021, 15:47 -0700, Jordan Brown openscad@jordan.maileater.net, wrote:
On 3/19/2021 2:58 PM, Whosawhatsis wrote:
https://www.openscad.org/about.html has a list of related projects, most of which are implementations of OpenSCAD-like functionality with other languages (and I can think of a few others that should be on that list off the top of my head). If you want OpenSCAD-like functionality in a different language, try one of those, or start another one. Maybe it will be better and eventually get more popular than OpenSCAD, but quit trying to break OpenSCAD by forcing it to be something it isn't.
I don't think anybody is trying to say that an OpenSCAD-like environment based on another language would still be OpenSCAD. It wouldn't, or at least it would need some major distinguisher in its name. It would be PySCAD or LuaSCAD or OpenJSCAD or something. Maybe, but probably not, OpenSCAD2.
So yes, if you view "the community" as being people who want to maintain OpenSCAD compatibility, such an effort would be a non-starter. If, on the other hand, you view "the community" as being people who want to write simple programs to generate geometry, and for whom OpenSCAD is simply the best answer currently available, then a transition to a different base language would make perfect sense.
And yes, this is the "OpenSCAD general discussion" mailing list, not the "3D geometry programming language" discussion list, so such discussions here should be relatively limited.
I'm fine with an "ideas for OpenSCAD-like things based on other languages" thread, but I'm sick of people talking about it as if "ripping the OpenSCAD language out of OpenSCAD and replacing it with" something else (a direct quote) made any sense at all.
On Mar 19, 2021, 15:47 -0700, Jordan Brown <openscad@jordan.maileater.net>, wrote:
> On 3/19/2021 2:58 PM, Whosawhatsis wrote:
> > https://www.openscad.org/about.html has a list of related projects, most of which are implementations of OpenSCAD-like functionality with other languages (and I can think of a few others that should be on that list off the top of my head). If you want OpenSCAD-like functionality in a different language, try one of those, or start another one. Maybe it will be better and eventually get more popular than OpenSCAD, but quit trying to break OpenSCAD by forcing it to be something it isn't.
>
> I don't think anybody is trying to say that an OpenSCAD-like environment based on another language would still be OpenSCAD. It wouldn't, or at least it would need some major distinguisher in its name. It would be PySCAD or LuaSCAD or OpenJSCAD or something. Maybe, but probably not, OpenSCAD2.
>
> So yes, if you view "the community" as being people who want to maintain OpenSCAD compatibility, such an effort would be a non-starter. If, on the other hand, you view "the community" as being people who want to write simple programs to generate geometry, and for whom OpenSCAD is simply the best answer currently available, then a transition to a different base language would make perfect sense.
>
> And yes, this is the "OpenSCAD general discussion" mailing list, not the "3D geometry programming language" discussion list, so such discussions here should be relatively limited.
RD
Revar Desmera
Sat, Mar 20, 2021 12:33 AM
There’s very useful parts to OpenSCAD. The Editor. The general live GUI and rendering engine. The OpenSCAD language itself is reasonable for a display language, I suppose. You can do a lot with it. I really don’t care if it’s kept around for backwards compatibility, but it sucks for doing serious work. Writing more complex algorithms is rather difficult or extremely inefficient, given the lack of anything resembling proper data structures or a dictionary/hashtable data type. Trust me, I’ve written tens of thousands of lines of OpenSCAD code. It has harsh limitations that, are not apparently being addressed in any apparent way, except by people forking new projects.
For some reason, most project forks of OpenSCAD either drop the immediacy of the live GUI and editor, or they go developing their own domain specific language variant, or choose a really obscure language to expand on. And absolutely no-one has a good library management system. Something like how the Arduino app lets you search for, download, and use libraries. File IO is another big problem. Being able to read an external file, even if you have to put harsh limitations on what files you can read, or where you can read them from, would allow for a lot of useful things. Being able to write even just a BOM file would make a number of people rather happy.
I just want a programmatic parts development system with a good GUI, an actually well developed and supported language, and an expansive library management system. Things could be SO much better than they are right now. So much more professional. It’s frustrating. Right now, OpenSCAD really hovers at the edge of being a toy language, like Processing or Logo.
On Mar 19, 2021, at 3:55 PM, Whosawhatsis whosawhatsis@gmail.com wrote:
I'm fine with an "ideas for OpenSCAD-like things based on other languages" thread, but I'm sick of people talking about it as if "ripping the OpenSCAD language out of OpenSCAD and replacing it with" something else (a direct quote) made any sense at all.
On Mar 19, 2021, 15:47 -0700, Jordan Brown openscad@jordan.maileater.net, wrote:
On 3/19/2021 2:58 PM, Whosawhatsis wrote:
https://www.openscad.org/about.html https://www.openscad.org/about.html has a list of related projects, most of which are implementations of OpenSCAD-like functionality with other languages (and I can think of a few others that should be on that list off the top of my head). If you want OpenSCAD-like functionality in a different language, try one of those, or start another one. Maybe it will be better and eventually get more popular than OpenSCAD, but quit trying to break OpenSCAD by forcing it to be something it isn't.
I don't think anybody is trying to say that an OpenSCAD-like environment based on another language would still be OpenSCAD. It wouldn't, or at least it would need some major distinguisher in its name. It would be PySCAD or LuaSCAD or OpenJSCAD or something. Maybe, but probably not, OpenSCAD2.
So yes, if you view "the community" as being people who want to maintain OpenSCAD compatibility, such an effort would be a non-starter. If, on the other hand, you view "the community" as being people who want to write simple programs to generate geometry, and for whom OpenSCAD is simply the best answer currently available, then a transition to a different base language would make perfect sense.
And yes, this is the "OpenSCAD general discussion" mailing list, not the "3D geometry programming language" discussion list, so such discussions here should be relatively limited.
There’s very useful parts to OpenSCAD. The Editor. The general live GUI and rendering engine. The OpenSCAD language itself is reasonable for a display language, I suppose. You can do a lot with it. I really don’t care if it’s kept around for backwards compatibility, but it sucks for doing serious work. Writing more complex algorithms is rather difficult or extremely inefficient, given the lack of anything resembling proper data structures or a dictionary/hashtable data type. Trust me, I’ve written tens of thousands of lines of OpenSCAD code. It has harsh limitations that, are not apparently being addressed in any apparent way, except by people forking new projects.
For some reason, most project forks of OpenSCAD either drop the immediacy of the live GUI and editor, or they go developing their own domain specific language variant, or choose a really obscure language to expand on. And absolutely no-one has a good library management system. Something like how the Arduino app lets you search for, download, and use libraries. File IO is another big problem. Being able to read an external file, even if you have to put harsh limitations on what files you can read, or where you can read them from, would allow for a lot of useful things. Being able to write even just a BOM file would make a number of people rather happy.
I just want a programmatic parts development system with a good GUI, an actually well developed and supported language, and an expansive library management system. Things could be SO much better than they are right now. So much more professional. It’s frustrating. Right now, OpenSCAD really hovers at the edge of being a toy language, like Processing or Logo.
- Revar
> On Mar 19, 2021, at 3:55 PM, Whosawhatsis <whosawhatsis@gmail.com> wrote:
>
> I'm fine with an "ideas for OpenSCAD-like things based on other languages" thread, but I'm sick of people talking about it as if "ripping the OpenSCAD language out of OpenSCAD and replacing it with" something else (a direct quote) made any sense at all.
> On Mar 19, 2021, 15:47 -0700, Jordan Brown <openscad@jordan.maileater.net>, wrote:
>> On 3/19/2021 2:58 PM, Whosawhatsis wrote:
>>> https://www.openscad.org/about.html <https://www.openscad.org/about.html> has a list of related projects, most of which are implementations of OpenSCAD-like functionality with other languages (and I can think of a few others that should be on that list off the top of my head). If you want OpenSCAD-like functionality in a different language, try one of those, or start another one. Maybe it will be better and eventually get more popular than OpenSCAD, but quit trying to break OpenSCAD by forcing it to be something it isn't.
>>
>> I don't think anybody is trying to say that an OpenSCAD-like environment based on another language would still be OpenSCAD. It wouldn't, or at least it would need some major distinguisher in its name. It would be PySCAD or LuaSCAD or OpenJSCAD or something. Maybe, but probably not, OpenSCAD2.
>>
>> So yes, if you view "the community" as being people who want to maintain OpenSCAD compatibility, such an effort would be a non-starter. If, on the other hand, you view "the community" as being people who want to write simple programs to generate geometry, and for whom OpenSCAD is simply the best answer currently available, then a transition to a different base language would make perfect sense.
>>
>> And yes, this is the "OpenSCAD general discussion" mailing list, not the "3D geometry programming language" discussion list, so such discussions here should be relatively limited.
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
W
Whosawhatsis
Sat, Mar 20, 2021 1:01 AM
Another project that might interest you, and one that should be added to the "related projects" page, is https://github.com/zalo/CascadeStudio
On Mar 19, 2021, 17:34 -0700, Revar Desmera revarbat@gmail.com, wrote:
There’s very useful parts to OpenSCAD. The Editor. The general live GUI and rendering engine. The OpenSCAD language itself is reasonable for a display language, I suppose. You can do a lot with it. I really don’t care if it’s kept around for backwards compatibility, but it sucks for doing serious work. Writing more complex algorithms is rather difficult or extremely inefficient, given the lack of anything resembling proper data structures or a dictionary/hashtable data type. Trust me, I’ve written tens of thousands of lines of OpenSCAD code. It has harsh limitations that, are not apparently being addressed in any apparent way, except by people forking new projects.
For some reason, most project forks of OpenSCAD either drop the immediacy of the live GUI and editor, or they go developing their own domain specific language variant, or choose a really obscure language to expand on. And absolutely no-one has a good library management system. Something like how the Arduino app lets you search for, download, and use libraries. File IO is another big problem. Being able to read an external file, even if you have to put harsh limitations on what files you can read, or where you can read them from, would allow for a lot of useful things. Being able to write even just a BOM file would make a number of people rather happy.
I just want a programmatic parts development system with a good GUI, an actually well developed and supported language, and an expansive library management system. Things could be SO much better than they are right now. So much more professional. It’s frustrating. Right now, OpenSCAD really hovers at the edge of being a toy language, like Processing or Logo.
On Mar 19, 2021, at 3:55 PM, Whosawhatsis whosawhatsis@gmail.com wrote:
I'm fine with an "ideas for OpenSCAD-like things based on other languages" thread, but I'm sick of people talking about it as if "ripping the OpenSCAD language out of OpenSCAD and replacing it with" something else (a direct quote) made any sense at all.
On Mar 19, 2021, 15:47 -0700, Jordan Brown openscad@jordan.maileater.net, wrote:
On 3/19/2021 2:58 PM, Whosawhatsis wrote:
https://www.openscad.org/about.html has a list of related projects, most of which are implementations of OpenSCAD-like functionality with other languages (and I can think of a few others that should be on that list off the top of my head). If you want OpenSCAD-like functionality in a different language, try one of those, or start another one. Maybe it will be better and eventually get more popular than OpenSCAD, but quit trying to break OpenSCAD by forcing it to be something it isn't.
I don't think anybody is trying to say that an OpenSCAD-like environment based on another language would still be OpenSCAD. It wouldn't, or at least it would need some major distinguisher in its name. It would be PySCAD or LuaSCAD or OpenJSCAD or something. Maybe, but probably not, OpenSCAD2.
So yes, if you view "the community" as being people who want to maintain OpenSCAD compatibility, such an effort would be a non-starter. If, on the other hand, you view "the community" as being people who want to write simple programs to generate geometry, and for whom OpenSCAD is simply the best answer currently available, then a transition to a different base language would make perfect sense.
And yes, this is the "OpenSCAD general discussion" mailing list, not the "3D geometry programming language" discussion list, so such discussions here should be relatively limited.
Another project that might interest you, and one that should be added to the "related projects" page, is https://github.com/zalo/CascadeStudio
On Mar 19, 2021, 17:34 -0700, Revar Desmera <revarbat@gmail.com>, wrote:
> There’s very useful parts to OpenSCAD. The Editor. The general live GUI and rendering engine. The OpenSCAD language itself is reasonable for a display language, I suppose. You can do a lot with it. I really don’t care if it’s kept around for backwards compatibility, but it sucks for doing serious work. Writing more complex algorithms is rather difficult or extremely inefficient, given the lack of anything resembling proper data structures or a dictionary/hashtable data type. Trust me, I’ve written tens of thousands of lines of OpenSCAD code. It has harsh limitations that, are not apparently being addressed in any apparent way, except by people forking new projects.
>
> For some reason, most project forks of OpenSCAD either drop the immediacy of the live GUI and editor, or they go developing their own domain specific language variant, or choose a really obscure language to expand on. And absolutely no-one has a good library management system. Something like how the Arduino app lets you search for, download, and use libraries. File IO is another big problem. Being able to read an external file, even if you have to put harsh limitations on what files you can read, or where you can read them from, would allow for a lot of useful things. Being able to write even just a BOM file would make a number of people rather happy.
>
> I just want a programmatic parts development system with a good GUI, an actually well developed and supported language, and an expansive library management system. Things could be SO much better than they are right now. So much more professional. It’s frustrating. Right now, OpenSCAD really hovers at the edge of being a toy language, like Processing or Logo.
>
> - Revar
>
>
> > On Mar 19, 2021, at 3:55 PM, Whosawhatsis <whosawhatsis@gmail.com> wrote:
> >
> > I'm fine with an "ideas for OpenSCAD-like things based on other languages" thread, but I'm sick of people talking about it as if "ripping the OpenSCAD language out of OpenSCAD and replacing it with" something else (a direct quote) made any sense at all.
> > On Mar 19, 2021, 15:47 -0700, Jordan Brown <openscad@jordan.maileater.net>, wrote:
> > > On 3/19/2021 2:58 PM, Whosawhatsis wrote:
> > > > https://www.openscad.org/about.html has a list of related projects, most of which are implementations of OpenSCAD-like functionality with other languages (and I can think of a few others that should be on that list off the top of my head). If you want OpenSCAD-like functionality in a different language, try one of those, or start another one. Maybe it will be better and eventually get more popular than OpenSCAD, but quit trying to break OpenSCAD by forcing it to be something it isn't.
> > >
> > > I don't think anybody is trying to say that an OpenSCAD-like environment based on another language would still be OpenSCAD. It wouldn't, or at least it would need some major distinguisher in its name. It would be PySCAD or LuaSCAD or OpenJSCAD or something. Maybe, but probably not, OpenSCAD2.
> > >
> > > So yes, if you view "the community" as being people who want to maintain OpenSCAD compatibility, such an effort would be a non-starter. If, on the other hand, you view "the community" as being people who want to write simple programs to generate geometry, and for whom OpenSCAD is simply the best answer currently available, then a transition to a different base language would make perfect sense.
> > >
> > > And yes, this is the "OpenSCAD general discussion" mailing list, not the "3D geometry programming language" discussion list, so such discussions here should be relatively limited.
> > _______________________________________________
> > OpenSCAD mailing list
> > To unsubscribe send an email to discuss-leave@lists.openscad.org
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
DT
Damien Towning
Sat, Mar 20, 2021 1:10 AM
I've been here. I came in here years ago looking for a fight about this :)
When you start to take apart the code base unwinding the language from the
code isn't impossible. The grammar is clearly defined. But is not the best
way. Leave the OpenSCAD as it is.
I've got about 60% of the way through a paper on this. Covers the whole lot
all the way out to the clustering.
My code repository is here : https://gitlab.com/mixotricha/elixir-makertron
I've not updated my docs or put the paper up but in some sense Whosawwhatis
is quite right.
Don't break OpenSCAD. Write something else instead.
What one can do ( what I did ) is to write a secondary downstream source to
source generator. Lots of reasons to do this. In my particular instance to
do with performance. After I did this it was something of a break through
for me as I was able to apply to a whole lot of optimizations and pipe line
stuff. Parsing sits in the client. Hands out jobs to a cluster. At this
this point hand woven metal basically. I've got all sorts going on inside
FPGA. This path became fruitful and general for a lot of problems. Not just
OpenSCAD.
On Sat, Mar 20, 2021 at 11:34 AM Revar Desmera revarbat@gmail.com wrote:
There’s very useful parts to OpenSCAD. The Editor. The general live GUI
and rendering engine. The OpenSCAD language itself is reasonable for a
display language, I suppose. You can do a lot with it. I really don’t care
if it’s kept around for backwards compatibility, but it sucks for doing
serious work. Writing more complex algorithms is rather difficult or
extremely inefficient, given the lack of anything resembling proper data
structures or a dictionary/hashtable data type. Trust me, I’ve written
tens of thousands of lines of OpenSCAD code. It has harsh limitations that,
are not apparently being addressed in any apparent way, except by people
forking new projects.
For some reason, most project forks of OpenSCAD either drop the immediacy
of the live GUI and editor, or they go developing their own domain specific
language variant, or choose a really obscure language to expand on. And
absolutely no-one has a good library management system. Something like how
the Arduino app lets you search for, download, and use libraries. File IO
is another big problem. Being able to read an external file, even if you
have to put harsh limitations on what files you can read, or where you can
read them from, would allow for a lot of useful things. Being able to
write even just a BOM file would make a number of people rather happy.
I just want a programmatic parts development system with a good GUI, an
actually well developed and supported language, and an expansive library
management system. Things could be SO much better than they are right
now. So much more professional. It’s frustrating. Right now, OpenSCAD
really hovers at the edge of being a toy language, like Processing or Logo.
On Mar 19, 2021, at 3:55 PM, Whosawhatsis whosawhatsis@gmail.com wrote:
I'm fine with an "ideas for OpenSCAD-like things based on other languages"
thread, but I'm sick of people talking about it as if "ripping the OpenSCAD
language out of OpenSCAD and replacing it with" something else (a direct
quote) made any sense at all.
On Mar 19, 2021, 15:47 -0700, Jordan Brown openscad@jordan.maileater.net,
wrote:
On 3/19/2021 2:58 PM, Whosawhatsis wrote:
https://www.openscad.org/about.html has a list of related projects, most
of which are implementations of OpenSCAD-like functionality with other
languages (and I can think of a few others that should be on that list off
the top of my head). If you want OpenSCAD-like functionality in a different
language, try one of those, or start another one. Maybe it will be better
and eventually get more popular than OpenSCAD, but quit trying to break
OpenSCAD by forcing it to be something it isn't.
I don't think anybody is trying to say that an OpenSCAD-like environment
based on another language would still be OpenSCAD. It wouldn't, or at
least it would need some major distinguisher in its name. It would be
PySCAD or LuaSCAD or OpenJSCAD or something. Maybe, but probably not,
OpenSCAD2.
So yes, if you view "the community" as being people who want to maintain
OpenSCAD compatibility, such an effort would be a non-starter. If, on the
other hand, you view "the community" as being people who want to write
simple programs to generate geometry, and for whom OpenSCAD is simply the
best answer currently available, then a transition to a different base
language would make perfect sense.
And yes, this is the "OpenSCAD general discussion" mailing list, not the
"3D geometry programming language" discussion list, so such discussions
here should be relatively limited.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I've been here. I came in here years ago looking for a fight about this :)
When you start to take apart the code base unwinding the language from the
code isn't impossible. The grammar is clearly defined. But is not the best
way. Leave the OpenSCAD as it is.
I've got about 60% of the way through a paper on this. Covers the whole lot
all the way out to the clustering.
My code repository is here : https://gitlab.com/mixotricha/elixir-makertron
I've not updated my docs or put the paper up but in some sense Whosawwhatis
is quite right.
Don't break OpenSCAD. Write something else instead.
What one can do ( what I did ) is to write a secondary downstream source to
source generator. Lots of reasons to do this. In my particular instance to
do with performance. After I did this it was something of a break through
for me as I was able to apply to a whole lot of optimizations and pipe line
stuff. Parsing sits in the client. Hands out jobs to a cluster. At this
this point hand woven metal basically. I've got all sorts going on inside
FPGA. This path became fruitful and general for a lot of problems. Not just
OpenSCAD.
On Sat, Mar 20, 2021 at 11:34 AM Revar Desmera <revarbat@gmail.com> wrote:
> There’s very useful parts to OpenSCAD. The Editor. The general live GUI
> and rendering engine. The OpenSCAD language itself is reasonable for a
> display language, I suppose. You can do a lot with it. I really don’t care
> if it’s kept around for backwards compatibility, but it sucks for doing
> serious work. Writing more complex algorithms is rather difficult or
> extremely inefficient, given the lack of anything resembling proper data
> structures or a dictionary/hashtable data type. Trust me, I’ve written
> tens of thousands of lines of OpenSCAD code. It has harsh limitations that,
> are not apparently being addressed in any apparent way, except by people
> forking new projects.
>
> For some reason, most project forks of OpenSCAD either drop the immediacy
> of the live GUI and editor, or they go developing their own domain specific
> language variant, or choose a really obscure language to expand on. And
> absolutely no-one has a good library management system. Something like how
> the Arduino app lets you search for, download, and use libraries. File IO
> is another big problem. Being able to read an external file, even if you
> have to put harsh limitations on what files you can read, or where you can
> read them from, would allow for a lot of useful things. Being able to
> write even just a BOM file would make a number of people rather happy.
>
> I just want a programmatic parts development system with a good GUI, an
> actually well developed and supported language, and an expansive library
> management system. Things could be SO much better than they are right
> now. So much more professional. It’s frustrating. Right now, OpenSCAD
> really hovers at the edge of being a toy language, like Processing or Logo.
>
> - Revar
>
>
> On Mar 19, 2021, at 3:55 PM, Whosawhatsis <whosawhatsis@gmail.com> wrote:
>
> I'm fine with an "ideas for OpenSCAD-like things based on other languages"
> thread, but I'm sick of people talking about it as if "ripping the OpenSCAD
> language out of OpenSCAD and replacing it with" something else (a direct
> quote) made any sense at all.
> On Mar 19, 2021, 15:47 -0700, Jordan Brown <openscad@jordan.maileater.net>,
> wrote:
>
> On 3/19/2021 2:58 PM, Whosawhatsis wrote:
>
> https://www.openscad.org/about.html has a list of related projects, most
> of which are implementations of OpenSCAD-like functionality with other
> languages (and I can think of a few others that should be on that list off
> the top of my head). If you want OpenSCAD-like functionality in a different
> language, try one of those, or start another one. Maybe it will be better
> and eventually get more popular than OpenSCAD, but quit trying to break
> OpenSCAD by forcing it to be something it isn't.
>
>
> I don't think anybody is trying to say that an OpenSCAD-like environment
> based on another language would still be OpenSCAD. It wouldn't, or at
> least it would need some major distinguisher in its name. It would be
> PySCAD or LuaSCAD or OpenJSCAD or something. Maybe, but probably not,
> OpenSCAD2.
>
> So yes, if you view "the community" as being people who want to maintain
> OpenSCAD compatibility, such an effort would be a non-starter. If, on the
> other hand, you view "the community" as being people who want to write
> simple programs to generate geometry, and for whom OpenSCAD is simply the
> best answer currently available, then a transition to a different base
> language would make perfect sense.
>
> And yes, this is the "OpenSCAD general discussion" mailing list, not the
> "3D geometry programming language" discussion list, so such discussions
> here should be relatively limited.
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
--
Damien Towning
DT
Damien Towning
Sat, Mar 20, 2021 1:23 AM
I also want to say that OpenSCAD is not the Iranian Yogurt here. It isn't
the problem. Languages are languages. If you don't like the OpenSCAD
language do what I did and source to source it. To me the more important
problem ( and nothing to do with OpenSCAD ) is doing the Boolean at decent
speed and making really geometry. I've been quietly working away on what I
am calling the 'reverse' gold feather ....
On Sat, Mar 20, 2021 at 12:10 PM Damien Towning connolly.damien@gmail.com
wrote:
I've been here. I came in here years ago looking for a fight about this :)
When you start to take apart the code base unwinding the language from the
code isn't impossible. The grammar is clearly defined. But is not the best
way. Leave the OpenSCAD as it is.
I've got about 60% of the way through a paper on this. Covers the whole
lot all the way out to the clustering.
My code repository is here :
https://gitlab.com/mixotricha/elixir-makertron
I've not updated my docs or put the paper up but in some sense
Whosawwhatis is quite right.
Don't break OpenSCAD. Write something else instead.
What one can do ( what I did ) is to write a secondary downstream source
to source generator. Lots of reasons to do this. In my particular instance
to do with performance. After I did this it was something of a break
through for me as I was able to apply to a whole lot of optimizations and
pipe line stuff. Parsing sits in the client. Hands out jobs to a cluster.
At this this point hand woven metal basically. I've got all sorts going on
inside FPGA. This path became fruitful and general for a lot of problems.
Not just OpenSCAD.
On Sat, Mar 20, 2021 at 11:34 AM Revar Desmera revarbat@gmail.com wrote:
There’s very useful parts to OpenSCAD. The Editor. The general live GUI
and rendering engine. The OpenSCAD language itself is reasonable for a
display language, I suppose. You can do a lot with it. I really don’t care
if it’s kept around for backwards compatibility, but it sucks for doing
serious work. Writing more complex algorithms is rather difficult or
extremely inefficient, given the lack of anything resembling proper data
structures or a dictionary/hashtable data type. Trust me, I’ve written
tens of thousands of lines of OpenSCAD code. It has harsh limitations that,
are not apparently being addressed in any apparent way, except by people
forking new projects.
For some reason, most project forks of OpenSCAD either drop the immediacy
of the live GUI and editor, or they go developing their own domain specific
language variant, or choose a really obscure language to expand on. And
absolutely no-one has a good library management system. Something like how
the Arduino app lets you search for, download, and use libraries. File IO
is another big problem. Being able to read an external file, even if you
have to put harsh limitations on what files you can read, or where you can
read them from, would allow for a lot of useful things. Being able to
write even just a BOM file would make a number of people rather happy.
I just want a programmatic parts development system with a good GUI, an
actually well developed and supported language, and an expansive library
management system. Things could be SO much better than they are right
now. So much more professional. It’s frustrating. Right now, OpenSCAD
really hovers at the edge of being a toy language, like Processing or Logo.
On Mar 19, 2021, at 3:55 PM, Whosawhatsis whosawhatsis@gmail.com wrote:
I'm fine with an "ideas for OpenSCAD-like things based on other
languages" thread, but I'm sick of people talking about it as if "ripping
the OpenSCAD language out of OpenSCAD and replacing it with" something else
(a direct quote) made any sense at all.
On Mar 19, 2021, 15:47 -0700, Jordan Brown openscad@jordan.maileater.net,
wrote:
On 3/19/2021 2:58 PM, Whosawhatsis wrote:
https://www.openscad.org/about.html has a list of related projects, most
of which are implementations of OpenSCAD-like functionality with other
languages (and I can think of a few others that should be on that list off
the top of my head). If you want OpenSCAD-like functionality in a different
language, try one of those, or start another one. Maybe it will be better
and eventually get more popular than OpenSCAD, but quit trying to break
OpenSCAD by forcing it to be something it isn't.
I don't think anybody is trying to say that an OpenSCAD-like environment
based on another language would still be OpenSCAD. It wouldn't, or at
least it would need some major distinguisher in its name. It would be
PySCAD or LuaSCAD or OpenJSCAD or something. Maybe, but probably not,
OpenSCAD2.
So yes, if you view "the community" as being people who want to maintain
OpenSCAD compatibility, such an effort would be a non-starter. If, on the
other hand, you view "the community" as being people who want to write
simple programs to generate geometry, and for whom OpenSCAD is simply the
best answer currently available, then a transition to a different base
language would make perfect sense.
And yes, this is the "OpenSCAD general discussion" mailing list, not the
"3D geometry programming language" discussion list, so such discussions
here should be relatively limited.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I also want to say that OpenSCAD is not the Iranian Yogurt here. It isn't
the problem. Languages are languages. If you don't like the OpenSCAD
language do what I did and source to source it. To me the more important
problem ( and nothing to do with OpenSCAD ) is doing the Boolean at decent
speed and making really geometry. I've been quietly working away on what I
am calling the 'reverse' gold feather ....
On Sat, Mar 20, 2021 at 12:10 PM Damien Towning <connolly.damien@gmail.com>
wrote:
> I've been here. I came in here years ago looking for a fight about this :)
>
> When you start to take apart the code base unwinding the language from the
> code isn't impossible. The grammar is clearly defined. But is not the best
> way. Leave the OpenSCAD as it is.
>
> I've got about 60% of the way through a paper on this. Covers the whole
> lot all the way out to the clustering.
>
> My code repository is here :
> https://gitlab.com/mixotricha/elixir-makertron
>
> I've not updated my docs or put the paper up but in some sense
> Whosawwhatis is quite right.
>
> Don't break OpenSCAD. Write something else instead.
>
> What one can do ( what I did ) is to write a secondary downstream source
> to source generator. Lots of reasons to do this. In my particular instance
> to do with performance. After I did this it was something of a break
> through for me as I was able to apply to a whole lot of optimizations and
> pipe line stuff. Parsing sits in the client. Hands out jobs to a cluster.
> At this this point hand woven metal basically. I've got all sorts going on
> inside FPGA. This path became fruitful and general for a lot of problems.
> Not just OpenSCAD.
>
>
> On Sat, Mar 20, 2021 at 11:34 AM Revar Desmera <revarbat@gmail.com> wrote:
>
>> There’s very useful parts to OpenSCAD. The Editor. The general live GUI
>> and rendering engine. The OpenSCAD language itself is reasonable for a
>> display language, I suppose. You can do a lot with it. I really don’t care
>> if it’s kept around for backwards compatibility, but it sucks for doing
>> serious work. Writing more complex algorithms is rather difficult or
>> extremely inefficient, given the lack of anything resembling proper data
>> structures or a dictionary/hashtable data type. Trust me, I’ve written
>> tens of thousands of lines of OpenSCAD code. It has harsh limitations that,
>> are not apparently being addressed in any apparent way, except by people
>> forking new projects.
>>
>> For some reason, most project forks of OpenSCAD either drop the immediacy
>> of the live GUI and editor, or they go developing their own domain specific
>> language variant, or choose a really obscure language to expand on. And
>> absolutely no-one has a good library management system. Something like how
>> the Arduino app lets you search for, download, and use libraries. File IO
>> is another big problem. Being able to read an external file, even if you
>> have to put harsh limitations on what files you can read, or where you can
>> read them from, would allow for a lot of useful things. Being able to
>> write even just a BOM file would make a number of people rather happy.
>>
>> I just want a programmatic parts development system with a good GUI, an
>> actually well developed and supported language, and an expansive library
>> management system. Things could be SO much better than they are right
>> now. So much more professional. It’s frustrating. Right now, OpenSCAD
>> really hovers at the edge of being a toy language, like Processing or Logo.
>>
>> - Revar
>>
>>
>> On Mar 19, 2021, at 3:55 PM, Whosawhatsis <whosawhatsis@gmail.com> wrote:
>>
>> I'm fine with an "ideas for OpenSCAD-like things based on other
>> languages" thread, but I'm sick of people talking about it as if "ripping
>> the OpenSCAD language out of OpenSCAD and replacing it with" something else
>> (a direct quote) made any sense at all.
>> On Mar 19, 2021, 15:47 -0700, Jordan Brown <openscad@jordan.maileater.net>,
>> wrote:
>>
>> On 3/19/2021 2:58 PM, Whosawhatsis wrote:
>>
>> https://www.openscad.org/about.html has a list of related projects, most
>> of which are implementations of OpenSCAD-like functionality with other
>> languages (and I can think of a few others that should be on that list off
>> the top of my head). If you want OpenSCAD-like functionality in a different
>> language, try one of those, or start another one. Maybe it will be better
>> and eventually get more popular than OpenSCAD, but quit trying to break
>> OpenSCAD by forcing it to be something it isn't.
>>
>>
>> I don't think anybody is trying to say that an OpenSCAD-like environment
>> based on another language would still be OpenSCAD. It wouldn't, or at
>> least it would need some major distinguisher in its name. It would be
>> PySCAD or LuaSCAD or OpenJSCAD or something. Maybe, but probably not,
>> OpenSCAD2.
>>
>> So yes, if you view "the community" as being people who want to maintain
>> OpenSCAD compatibility, such an effort would be a non-starter. If, on the
>> other hand, you view "the community" as being people who want to write
>> simple programs to generate geometry, and for whom OpenSCAD is simply the
>> best answer currently available, then a transition to a different base
>> language would make perfect sense.
>>
>> And yes, this is the "OpenSCAD general discussion" mailing list, not the
>> "3D geometry programming language" discussion list, so such discussions
>> here should be relatively limited.
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>
>
>
> --
> Damien Towning
>
>
>
--
Damien Towning
NH
nop head
Sat, Mar 20, 2021 1:30 AM
Writing more complex algorithms is rather difficult or extremely
inefficient, given the lack of anything resembling proper data structures
or a dictionary/hashtable data type.
Yes but I use it to model parts, not code algorithms. I find it a good
language for describing objects I want to print or vitamins that
interface with them, like fasteners, fans, power supplies, etc. I don't
need mutable data structures for that.
On Sat, 20 Mar 2021 at 01:11, Damien Towning connolly.damien@gmail.com
wrote:
I've been here. I came in here years ago looking for a fight about this :)
When you start to take apart the code base unwinding the language from the
code isn't impossible. The grammar is clearly defined. But is not the best
way. Leave the OpenSCAD as it is.
I've got about 60% of the way through a paper on this. Covers the whole
lot all the way out to the clustering.
My code repository is here :
https://gitlab.com/mixotricha/elixir-makertron
I've not updated my docs or put the paper up but in some sense
Whosawwhatis is quite right.
Don't break OpenSCAD. Write something else instead.
What one can do ( what I did ) is to write a secondary downstream source
to source generator. Lots of reasons to do this. In my particular instance
to do with performance. After I did this it was something of a break
through for me as I was able to apply to a whole lot of optimizations and
pipe line stuff. Parsing sits in the client. Hands out jobs to a cluster.
At this this point hand woven metal basically. I've got all sorts going on
inside FPGA. This path became fruitful and general for a lot of problems.
Not just OpenSCAD.
On Sat, Mar 20, 2021 at 11:34 AM Revar Desmera revarbat@gmail.com wrote:
There’s very useful parts to OpenSCAD. The Editor. The general live GUI
and rendering engine. The OpenSCAD language itself is reasonable for a
display language, I suppose. You can do a lot with it. I really don’t care
if it’s kept around for backwards compatibility, but it sucks for doing
serious work. Writing more complex algorithms is rather difficult or
extremely inefficient, given the lack of anything resembling proper data
structures or a dictionary/hashtable data type. Trust me, I’ve written
tens of thousands of lines of OpenSCAD code. It has harsh limitations that,
are not apparently being addressed in any apparent way, except by people
forking new projects.
For some reason, most project forks of OpenSCAD either drop the immediacy
of the live GUI and editor, or they go developing their own domain specific
language variant, or choose a really obscure language to expand on. And
absolutely no-one has a good library management system. Something like how
the Arduino app lets you search for, download, and use libraries. File IO
is another big problem. Being able to read an external file, even if you
have to put harsh limitations on what files you can read, or where you can
read them from, would allow for a lot of useful things. Being able to
write even just a BOM file would make a number of people rather happy.
I just want a programmatic parts development system with a good GUI, an
actually well developed and supported language, and an expansive library
management system. Things could be SO much better than they are right
now. So much more professional. It’s frustrating. Right now, OpenSCAD
really hovers at the edge of being a toy language, like Processing or Logo.
On Mar 19, 2021, at 3:55 PM, Whosawhatsis whosawhatsis@gmail.com wrote:
I'm fine with an "ideas for OpenSCAD-like things based on other
languages" thread, but I'm sick of people talking about it as if "ripping
the OpenSCAD language out of OpenSCAD and replacing it with" something else
(a direct quote) made any sense at all.
On Mar 19, 2021, 15:47 -0700, Jordan Brown openscad@jordan.maileater.net,
wrote:
On 3/19/2021 2:58 PM, Whosawhatsis wrote:
https://www.openscad.org/about.html has a list of related projects, most
of which are implementations of OpenSCAD-like functionality with other
languages (and I can think of a few others that should be on that list off
the top of my head). If you want OpenSCAD-like functionality in a different
language, try one of those, or start another one. Maybe it will be better
and eventually get more popular than OpenSCAD, but quit trying to break
OpenSCAD by forcing it to be something it isn't.
I don't think anybody is trying to say that an OpenSCAD-like environment
based on another language would still be OpenSCAD. It wouldn't, or at
least it would need some major distinguisher in its name. It would be
PySCAD or LuaSCAD or OpenJSCAD or something. Maybe, but probably not,
OpenSCAD2.
So yes, if you view "the community" as being people who want to maintain
OpenSCAD compatibility, such an effort would be a non-starter. If, on the
other hand, you view "the community" as being people who want to write
simple programs to generate geometry, and for whom OpenSCAD is simply the
best answer currently available, then a transition to a different base
language would make perfect sense.
And yes, this is the "OpenSCAD general discussion" mailing list, not the
"3D geometry programming language" discussion list, so such discussions
here should be relatively limited.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
> Writing more complex algorithms is rather difficult or extremely
inefficient, given the lack of anything resembling proper data structures
or a dictionary/hashtable data type.
Yes but I use it to model parts, not code algorithms. I find it a good
language for describing objects I want to print or vitamins that
interface with them, like fasteners, fans, power supplies, etc. I don't
need mutable data structures for that.
On Sat, 20 Mar 2021 at 01:11, Damien Towning <connolly.damien@gmail.com>
wrote:
> I've been here. I came in here years ago looking for a fight about this :)
>
> When you start to take apart the code base unwinding the language from the
> code isn't impossible. The grammar is clearly defined. But is not the best
> way. Leave the OpenSCAD as it is.
>
> I've got about 60% of the way through a paper on this. Covers the whole
> lot all the way out to the clustering.
>
> My code repository is here :
> https://gitlab.com/mixotricha/elixir-makertron
>
> I've not updated my docs or put the paper up but in some sense
> Whosawwhatis is quite right.
>
> Don't break OpenSCAD. Write something else instead.
>
> What one can do ( what I did ) is to write a secondary downstream source
> to source generator. Lots of reasons to do this. In my particular instance
> to do with performance. After I did this it was something of a break
> through for me as I was able to apply to a whole lot of optimizations and
> pipe line stuff. Parsing sits in the client. Hands out jobs to a cluster.
> At this this point hand woven metal basically. I've got all sorts going on
> inside FPGA. This path became fruitful and general for a lot of problems.
> Not just OpenSCAD.
>
>
> On Sat, Mar 20, 2021 at 11:34 AM Revar Desmera <revarbat@gmail.com> wrote:
>
>> There’s very useful parts to OpenSCAD. The Editor. The general live GUI
>> and rendering engine. The OpenSCAD language itself is reasonable for a
>> display language, I suppose. You can do a lot with it. I really don’t care
>> if it’s kept around for backwards compatibility, but it sucks for doing
>> serious work. Writing more complex algorithms is rather difficult or
>> extremely inefficient, given the lack of anything resembling proper data
>> structures or a dictionary/hashtable data type. Trust me, I’ve written
>> tens of thousands of lines of OpenSCAD code. It has harsh limitations that,
>> are not apparently being addressed in any apparent way, except by people
>> forking new projects.
>>
>> For some reason, most project forks of OpenSCAD either drop the immediacy
>> of the live GUI and editor, or they go developing their own domain specific
>> language variant, or choose a really obscure language to expand on. And
>> absolutely no-one has a good library management system. Something like how
>> the Arduino app lets you search for, download, and use libraries. File IO
>> is another big problem. Being able to read an external file, even if you
>> have to put harsh limitations on what files you can read, or where you can
>> read them from, would allow for a lot of useful things. Being able to
>> write even just a BOM file would make a number of people rather happy.
>>
>> I just want a programmatic parts development system with a good GUI, an
>> actually well developed and supported language, and an expansive library
>> management system. Things could be SO much better than they are right
>> now. So much more professional. It’s frustrating. Right now, OpenSCAD
>> really hovers at the edge of being a toy language, like Processing or Logo.
>>
>> - Revar
>>
>>
>> On Mar 19, 2021, at 3:55 PM, Whosawhatsis <whosawhatsis@gmail.com> wrote:
>>
>> I'm fine with an "ideas for OpenSCAD-like things based on other
>> languages" thread, but I'm sick of people talking about it as if "ripping
>> the OpenSCAD language out of OpenSCAD and replacing it with" something else
>> (a direct quote) made any sense at all.
>> On Mar 19, 2021, 15:47 -0700, Jordan Brown <openscad@jordan.maileater.net>,
>> wrote:
>>
>> On 3/19/2021 2:58 PM, Whosawhatsis wrote:
>>
>> https://www.openscad.org/about.html has a list of related projects, most
>> of which are implementations of OpenSCAD-like functionality with other
>> languages (and I can think of a few others that should be on that list off
>> the top of my head). If you want OpenSCAD-like functionality in a different
>> language, try one of those, or start another one. Maybe it will be better
>> and eventually get more popular than OpenSCAD, but quit trying to break
>> OpenSCAD by forcing it to be something it isn't.
>>
>>
>> I don't think anybody is trying to say that an OpenSCAD-like environment
>> based on another language would still be OpenSCAD. It wouldn't, or at
>> least it would need some major distinguisher in its name. It would be
>> PySCAD or LuaSCAD or OpenJSCAD or something. Maybe, but probably not,
>> OpenSCAD2.
>>
>> So yes, if you view "the community" as being people who want to maintain
>> OpenSCAD compatibility, such an effort would be a non-starter. If, on the
>> other hand, you view "the community" as being people who want to write
>> simple programs to generate geometry, and for whom OpenSCAD is simply the
>> best answer currently available, then a transition to a different base
>> language would make perfect sense.
>>
>> And yes, this is the "OpenSCAD general discussion" mailing list, not the
>> "3D geometry programming language" discussion list, so such discussions
>> here should be relatively limited.
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>
>
>
> --
> Damien Towning
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
CF
Carsten Fuchs
Sat, Mar 20, 2021 7:01 AM
Am 20.03.21 um 02:30 schrieb nop head:
Yes but I use it to model parts, not code algorithms.
Until the parts get complicated… ;-)
Best regards,
Carsten
Am 20.03.21 um 02:30 schrieb nop head:
> Yes but I use it to model parts, not code algorithms.
Until the parts get complicated… ;-)
Best regards,
Carsten
