OpenSCAD 3000

classic Classic list List threaded Threaded
144 messages Options
1234 ... 8
Reply | Threaded
Open this post in threaded view
|

OpenSCAD 3000

Mike Meyer
On Sun, Jun 15, 2014 at 12:03 PM, Marius Kintel <[hidden email]> wrote:
I’ve been thinking about embedding an external evaluation engine in place our own homegrown (as it should be unnecessary to maintain such a piece of software), but I’m pretty insistent on keeping it functional, especially free of any side effects. I’d also like to experiment with also keeping the grammar context free to exploit parallelization options. Right now, we eliminate context by evaluating all expressions before evaluating the geometry, but it could be interesting to keep the expressions for more involved use-cases like feedback from the geometry engine back to the evaluation engine. (I need to read up more on modern functional language paradigms, context free grammars; my terminology might be a bit off).

Is it to early to start discussing this? If so, I've swiped the Python idea of calling the "we're going to break the world" version 3000.

While I'm a big fan of functional languages and keeping things free of side effects, to get the full benefit of those features you really need a strongly (and preferably statically) typed language - especially since the OpenSCAD primitives have side effects. Your type system should capture that information, and throw an error if you do something that has side effect in a context that's supposed to be pure. Clojure does this with dynamic typing, and Haskell with static typing.

You might want to take a look at the (apparently abandoned) ImplicitCad project. It includes an OpenSCAD-like language (ExtoSCAD) as well as a Haskell library for the CAD primitives. ExtoSCAD has no module function, so presumably they expected anything that needed such to be done with Haskell functions.

Personally, I've been thinking creating a Haskell data structure describing the OpenSCAD primitives for creating and manipulating solids, then building an interpreter that spits out OpenSCAD primitves using the Free Monad plus interpreter pattern. See http://programmers.stackexchange.com/questions/242795/what-is-the-free-monad-interpreter-pattern for info on that.

Thanks,
Mike

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD 3000

nophead
Does anybody use Python 3 ?


On 15 June 2014 20:19, Mike Meyer <[hidden email]> wrote:
On Sun, Jun 15, 2014 at 12:03 PM, Marius Kintel <[hidden email]> wrote:
I’ve been thinking about embedding an external evaluation engine in place our own homegrown (as it should be unnecessary to maintain such a piece of software), but I’m pretty insistent on keeping it functional, especially free of any side effects. I’d also like to experiment with also keeping the grammar context free to exploit parallelization options. Right now, we eliminate context by evaluating all expressions before evaluating the geometry, but it could be interesting to keep the expressions for more involved use-cases like feedback from the geometry engine back to the evaluation engine. (I need to read up more on modern functional language paradigms, context free grammars; my terminology might be a bit off).

Is it to early to start discussing this? If so, I've swiped the Python idea of calling the "we're going to break the world" version 3000.

While I'm a big fan of functional languages and keeping things free of side effects, to get the full benefit of those features you really need a strongly (and preferably statically) typed language - especially since the OpenSCAD primitives have side effects. Your type system should capture that information, and throw an error if you do something that has side effect in a context that's supposed to be pure. Clojure does this with dynamic typing, and Haskell with static typing.

You might want to take a look at the (apparently abandoned) ImplicitCad project. It includes an OpenSCAD-like language (ExtoSCAD) as well as a Haskell library for the CAD primitives. ExtoSCAD has no module function, so presumably they expected anything that needed such to be done with Haskell functions.

Personally, I've been thinking creating a Haskell data structure describing the OpenSCAD primitives for creating and manipulating solids, then building an interpreter that spits out OpenSCAD primitves using the Free Monad plus interpreter pattern. See http://programmers.stackexchange.com/questions/242795/what-is-the-free-monad-interpreter-pattern for info on that.

Thanks,
Mike

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD 3000

Mike Meyer
On Sun, Jun 15, 2014 at 2:28 PM, nop head <[hidden email]> wrote:
Does anybody use Python 3 ?

Yes. It's the default Python on Arch Linux, and Debian (and it's derivatives) are migrating to it. However, it has divided the community. If you write Python 2, chances are most of the people you talk to about Python do the same. But if you write Python 3, that's what the people you talk to are writing.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD 3000

Steve Kelly
In reply to this post by nophead
Last summer I spent a good amount of time learning about serializing
objects in Python. I wrote a OpenSCAD wrapper that used serialized
JSON as a middle layer between Python and OpenSCAD.
https://github.com/textcad

On Sun, Jun 15, 2014 at 3:28 PM, nop head <[hidden email]> wrote:

> Does anybody use Python 3 ?
>
>
> On 15 June 2014 20:19, Mike Meyer <[hidden email]> wrote:
>>
>> On Sun, Jun 15, 2014 at 12:03 PM, Marius Kintel <[hidden email]> wrote:
>>>
>>> I’ve been thinking about embedding an external evaluation engine in place
>>> our own homegrown (as it should be unnecessary to maintain such a piece of
>>> software), but I’m pretty insistent on keeping it functional, especially
>>> free of any side effects. I’d also like to experiment with also keeping the
>>> grammar context free to exploit parallelization options. Right now, we
>>> eliminate context by evaluating all expressions before evaluating the
>>> geometry, but it could be interesting to keep the expressions for more
>>> involved use-cases like feedback from the geometry engine back to the
>>> evaluation engine. (I need to read up more on modern functional language
>>> paradigms, context free grammars; my terminology might be a bit off).
>>
>>
>> Is it to early to start discussing this? If so, I've swiped the Python
>> idea of calling the "we're going to break the world" version 3000.
>>
>> While I'm a big fan of functional languages and keeping things free of
>> side effects, to get the full benefit of those features you really need a
>> strongly (and preferably statically) typed language - especially since the
>> OpenSCAD primitives have side effects. Your type system should capture that
>> information, and throw an error if you do something that has side effect in
>> a context that's supposed to be pure. Clojure does this with dynamic typing,
>> and Haskell with static typing.
>>
>> You might want to take a look at the (apparently abandoned) ImplicitCad
>> project. It includes an OpenSCAD-like language (ExtoSCAD) as well as a
>> Haskell library for the CAD primitives. ExtoSCAD has no module function, so
>> presumably they expected anything that needed such to be done with Haskell
>> functions.
>>
>> Personally, I've been thinking creating a Haskell data structure
>> describing the OpenSCAD primitives for creating and manipulating solids,
>> then building an interpreter that spits out OpenSCAD primitves using the
>> Free Monad plus interpreter pattern. See
>> http://programmers.stackexchange.com/questions/242795/what-is-the-free-monad-interpreter-pattern
>> for info on that.
>>
>> Thanks,
>> Mike
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> [hidden email]
>> http://rocklinux.net/mailman/listinfo/openscad
>> http://openscad.org - https://flattr.com/thing/121566
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD 3000

nophead
It's more than 5 years old and quite similar to Python 2 but still a lot of people haven't switched. Imagine how long it would take for OpenScad 3000 to catch on if it was radically different.


On 15 June 2014 21:15, Steve Kelly <[hidden email]> wrote:
Last summer I spent a good amount of time learning about serializing
objects in Python. I wrote a OpenSCAD wrapper that used serialized
JSON as a middle layer between Python and OpenSCAD.
https://github.com/textcad

On Sun, Jun 15, 2014 at 3:28 PM, nop head <[hidden email]> wrote:
> Does anybody use Python 3 ?
>
>
> On 15 June 2014 20:19, Mike Meyer <[hidden email]> wrote:
>>
>> On Sun, Jun 15, 2014 at 12:03 PM, Marius Kintel <[hidden email]> wrote:
>>>
>>> I’ve been thinking about embedding an external evaluation engine in place
>>> our own homegrown (as it should be unnecessary to maintain such a piece of
>>> software), but I’m pretty insistent on keeping it functional, especially
>>> free of any side effects. I’d also like to experiment with also keeping the
>>> grammar context free to exploit parallelization options. Right now, we
>>> eliminate context by evaluating all expressions before evaluating the
>>> geometry, but it could be interesting to keep the expressions for more
>>> involved use-cases like feedback from the geometry engine back to the
>>> evaluation engine. (I need to read up more on modern functional language
>>> paradigms, context free grammars; my terminology might be a bit off).
>>
>>
>> Is it to early to start discussing this? If so, I've swiped the Python
>> idea of calling the "we're going to break the world" version 3000.
>>
>> While I'm a big fan of functional languages and keeping things free of
>> side effects, to get the full benefit of those features you really need a
>> strongly (and preferably statically) typed language - especially since the
>> OpenSCAD primitives have side effects. Your type system should capture that
>> information, and throw an error if you do something that has side effect in
>> a context that's supposed to be pure. Clojure does this with dynamic typing,
>> and Haskell with static typing.
>>
>> You might want to take a look at the (apparently abandoned) ImplicitCad
>> project. It includes an OpenSCAD-like language (ExtoSCAD) as well as a
>> Haskell library for the CAD primitives. ExtoSCAD has no module function, so
>> presumably they expected anything that needed such to be done with Haskell
>> functions.
>>
>> Personally, I've been thinking creating a Haskell data structure
>> describing the OpenSCAD primitives for creating and manipulating solids,
>> then building an interpreter that spits out OpenSCAD primitves using the
>> Free Monad plus interpreter pattern. See
>> http://programmers.stackexchange.com/questions/242795/what-is-the-free-monad-interpreter-pattern
>> for info on that.
>>
>> Thanks,
>> Mike
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> [hidden email]
>> http://rocklinux.net/mailman/listinfo/openscad
>> http://openscad.org - https://flattr.com/thing/121566
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD 3000

Mike Meyer
That's pretty much what was expected when they started the transition. After all, there are still people running applications on and libraries for Python 2.4, which is 10 years old. But they've only considered it production ready as of Python 3.3 - which is less than two years old. 

And part of the reason for they expect the transition to take so long is that it IS quite similar to Python, but just different enough to be a problem. And in order to make the transition as easy as possible, a lot of Python 3.x features were back ported to Python.  Further, they've promised to continue releasing bug fixes for Python 2.7 until 2020. So - unless you really need one of the things that caused the transition - there's not a lot of reason to switch.

Once it was decided that backwards compatibility had to go, they fixed as many warts as they could identify. But nothing that got fixed was as blatantly broken as OpenSCAD's include/use mechanisms, much less variable handling. The point of an "OpenSCAD 3000" should also be to get everything fixed - including that the OpenSCAD developers have to develop and maintain a language. A language that's "quite similar" to what's being used now would miss the point. So - unlike Python - there should be solid reasons for most people to switch.

On Sun, Jun 15, 2014 at 5:11 PM, nop head <[hidden email]> wrote:
It's more than 5 years old and quite similar to Python 2 but still a lot of people haven't switched. Imagine how long it would take for OpenScad 3000 to catch on if it was radically different.


On 15 June 2014 21:15, Steve Kelly <[hidden email]> wrote:
Last summer I spent a good amount of time learning about serializing
objects in Python. I wrote a OpenSCAD wrapper that used serialized
JSON as a middle layer between Python and OpenSCAD.
https://github.com/textcad

On Sun, Jun 15, 2014 at 3:28 PM, nop head <[hidden email]> wrote:
> Does anybody use Python 3 ?
>
>
> On 15 June 2014 20:19, Mike Meyer <[hidden email]> wrote:
>>
>> On Sun, Jun 15, 2014 at 12:03 PM, Marius Kintel <[hidden email]> wrote:
>>>
>>> I’ve been thinking about embedding an external evaluation engine in place
>>> our own homegrown (as it should be unnecessary to maintain such a piece of
>>> software), but I’m pretty insistent on keeping it functional, especially
>>> free of any side effects. I’d also like to experiment with also keeping the
>>> grammar context free to exploit parallelization options. Right now, we
>>> eliminate context by evaluating all expressions before evaluating the
>>> geometry, but it could be interesting to keep the expressions for more
>>> involved use-cases like feedback from the geometry engine back to the
>>> evaluation engine. (I need to read up more on modern functional language
>>> paradigms, context free grammars; my terminology might be a bit off).
>>
>>
>> Is it to early to start discussing this? If so, I've swiped the Python
>> idea of calling the "we're going to break the world" version 3000.
>>
>> While I'm a big fan of functional languages and keeping things free of
>> side effects, to get the full benefit of those features you really need a
>> strongly (and preferably statically) typed language - especially since the
>> OpenSCAD primitives have side effects. Your type system should capture that
>> information, and throw an error if you do something that has side effect in
>> a context that's supposed to be pure. Clojure does this with dynamic typing,
>> and Haskell with static typing.
>>
>> You might want to take a look at the (apparently abandoned) ImplicitCad
>> project. It includes an OpenSCAD-like language (ExtoSCAD) as well as a
>> Haskell library for the CAD primitives. ExtoSCAD has no module function, so
>> presumably they expected anything that needed such to be done with Haskell
>> functions.
>>
>> Personally, I've been thinking creating a Haskell data structure
>> describing the OpenSCAD primitives for creating and manipulating solids,
>> then building an interpreter that spits out OpenSCAD primitves using the
>> Free Monad plus interpreter pattern. See
>> http://programmers.stackexchange.com/questions/242795/what-is-the-free-monad-interpreter-pattern
>> for info on that.
>>
>> Thanks,
>> Mike
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> [hidden email]
>> http://rocklinux.net/mailman/listinfo/openscad
>> http://openscad.org - https://flattr.com/thing/121566
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD 3000

doug.moen
In reply to this post by Mike Meyer
If OpenSCAD 3000 had a Haskell-like type system, then I imagine it would be as wildly popular as ImplicitCad. I appreciate the benefits of the Haskell type system, but man was that a steep cliff to climb to learn how to use it.

If we are just talking about a new evaluation engine, then I think LLVM looks interesting.

I personally think that the OpenSCAD installed base, the large collection of scripts on Thingiverse, and the community of people who know and use the current language, are OpenSCADs most important assets. So backward compatibility is really important, and I suspect that what Python did was a mistake. If you want to fork the language, do it in a way that scripts written in the new dialect can use library files written in the old dialect, and vice versa. The compiler should be able to auto-detect which dialect is in use.

If "OpenSCAD 3000" is not backward compatible, then it needs to be more compelling than regular OpenSCAD, and be able to attract a new community that is larger than the current community. Otherwise, you just risk splitting the existing OpenSCAD community into two smaller communities.

So what are the compelling new features? Maybe OpenSCAD 3000 geometry computations can be embedded in web pages? Maybe instead of a text based programming interface, there is a GUI based direct manipulation programming interface. Maybe you can edit models by interacting directly with the rendered view. Maybe there is a GUI interface to the OpenSCAD library, so that you can browse through a set of graphical thumbnails of geometry modules.




On 15 June 2014 15:19, Mike Meyer <[hidden email]> wrote:
On Sun, Jun 15, 2014 at 12:03 PM, Marius Kintel <[hidden email]> wrote:
I’ve been thinking about embedding an external evaluation engine in place our own homegrown (as it should be unnecessary to maintain such a piece of software), but I’m pretty insistent on keeping it functional, especially free of any side effects. I’d also like to experiment with also keeping the grammar context free to exploit parallelization options. Right now, we eliminate context by evaluating all expressions before evaluating the geometry, but it could be interesting to keep the expressions for more involved use-cases like feedback from the geometry engine back to the evaluation engine. (I need to read up more on modern functional language paradigms, context free grammars; my terminology might be a bit off).

Is it to early to start discussing this? If so, I've swiped the Python idea of calling the "we're going to break the world" version 3000.

While I'm a big fan of functional languages and keeping things free of side effects, to get the full benefit of those features you really need a strongly (and preferably statically) typed language - especially since the OpenSCAD primitives have side effects. Your type system should capture that information, and throw an error if you do something that has side effect in a context that's supposed to be pure. Clojure does this with dynamic typing, and Haskell with static typing.

You might want to take a look at the (apparently abandoned) ImplicitCad project. It includes an OpenSCAD-like language (ExtoSCAD) as well as a Haskell library for the CAD primitives. ExtoSCAD has no module function, so presumably they expected anything that needed such to be done with Haskell functions.

Personally, I've been thinking creating a Haskell data structure describing the OpenSCAD primitives for creating and manipulating solids, then building an interpreter that spits out OpenSCAD primitves using the Free Monad plus interpreter pattern. See http://programmers.stackexchange.com/questions/242795/what-is-the-free-monad-interpreter-pattern for info on that.

Thanks,
Mike

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD 3000

nophead
I don't understand the logic that a strong type system is needed because OpenScad primitives have side effects. None of them have side effects in the programming sense, they are all pure.


On 16 June 2014 00:30, doug moen <[hidden email]> wrote:
If OpenSCAD 3000 had a Haskell-like type system, then I imagine it would be as wildly popular as ImplicitCad. I appreciate the benefits of the Haskell type system, but man was that a steep cliff to climb to learn how to use it.

If we are just talking about a new evaluation engine, then I think LLVM looks interesting.

I personally think that the OpenSCAD installed base, the large collection of scripts on Thingiverse, and the community of people who know and use the current language, are OpenSCADs most important assets. So backward compatibility is really important, and I suspect that what Python did was a mistake. If you want to fork the language, do it in a way that scripts written in the new dialect can use library files written in the old dialect, and vice versa. The compiler should be able to auto-detect which dialect is in use.

If "OpenSCAD 3000" is not backward compatible, then it needs to be more compelling than regular OpenSCAD, and be able to attract a new community that is larger than the current community. Otherwise, you just risk splitting the existing OpenSCAD community into two smaller communities.

So what are the compelling new features? Maybe OpenSCAD 3000 geometry computations can be embedded in web pages? Maybe instead of a text based programming interface, there is a GUI based direct manipulation programming interface. Maybe you can edit models by interacting directly with the rendered view. Maybe there is a GUI interface to the OpenSCAD library, so that you can browse through a set of graphical thumbnails of geometry modules.




On 15 June 2014 15:19, Mike Meyer <[hidden email]> wrote:
On Sun, Jun 15, 2014 at 12:03 PM, Marius Kintel <[hidden email]> wrote:
I’ve been thinking about embedding an external evaluation engine in place our own homegrown (as it should be unnecessary to maintain such a piece of software), but I’m pretty insistent on keeping it functional, especially free of any side effects. I’d also like to experiment with also keeping the grammar context free to exploit parallelization options. Right now, we eliminate context by evaluating all expressions before evaluating the geometry, but it could be interesting to keep the expressions for more involved use-cases like feedback from the geometry engine back to the evaluation engine. (I need to read up more on modern functional language paradigms, context free grammars; my terminology might be a bit off).

Is it to early to start discussing this? If so, I've swiped the Python idea of calling the "we're going to break the world" version 3000.

While I'm a big fan of functional languages and keeping things free of side effects, to get the full benefit of those features you really need a strongly (and preferably statically) typed language - especially since the OpenSCAD primitives have side effects. Your type system should capture that information, and throw an error if you do something that has side effect in a context that's supposed to be pure. Clojure does this with dynamic typing, and Haskell with static typing.

You might want to take a look at the (apparently abandoned) ImplicitCad project. It includes an OpenSCAD-like language (ExtoSCAD) as well as a Haskell library for the CAD primitives. ExtoSCAD has no module function, so presumably they expected anything that needed such to be done with Haskell functions.

Personally, I've been thinking creating a Haskell data structure describing the OpenSCAD primitives for creating and manipulating solids, then building an interpreter that spits out OpenSCAD primitves using the Free Monad plus interpreter pattern. See http://programmers.stackexchange.com/questions/242795/what-is-the-free-monad-interpreter-pattern for info on that.

Thanks,
Mike

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD 3000

ednisley
In reply to this post by doug.moen
On 06/15/2014 07:30 PM, doug moen wrote:
> So what are the compelling new features?

I'm barely qualified to carry the water for you folks, so what scares me
witless is that you're coming up with a *wonderful* language with *all*
the features, but that will be basically unusable for the stuff I'm doing.

What's absolutely compelling about OpenSCAD, right now, is that I can
sketch out a doodad, make a few measurements, define a few constants,
bang out some code, and *build* something. There is *nothing* else like
it out there, at least in the range that I can afford, period.

I'm building more-or-less trivial one-off parts for my projects: a few
hundred lines of code, tops, two or three iterations to get the fit
nailed down, and it's hot off my Makergear's platform. Unlike, say,
nophead, I'm not doing production runs, don't need an integrated BOM,
don't need fancy models with precisely located washers, and will never
build that thing again.

Heck, there aren't any reusable parts and the next time around I'd do it
differently anyway.

Some of what I do shows up in magazine columns, where there's a premium
on *simple* code that does pretty much what it says. A program that
depends on complex manipulations, vast libraries, and other overhead
that can't be explained simply isn't practical; there's a premium on an
explanation that fits in a 2500 word column, not the first installment
of a year's worth of writing about a program that will produce a bracket.

So, please, please, *please* don't turn OpenSCAD into something that
requires advanced math and l33t programming skillz just to make a
bracket. Yes, I'd like a "real" programming language and I'm even
willing endure a language discontinuity, but don't make the simple
things complex in order to make the complex things possible.

Now I'll return to my bracket, which is already in progress ... [grin]

--
Ed
softsolder.com
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
 --
Ed
softsolder.com
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD 3000

kintel
Administrator
In reply to this post by Mike Meyer
On Jun 15, 2014, at 15:19 PM, Mike Meyer <[hidden email]> wrote:
>
> Is it to early to start discussing this? If so, I've swiped the Python idea of calling the "we're going to break the world" version 3000.
>
It’s not too early - I’d say it a pretty good point in time.

The upcoming OpenSCAD version has refactored a bunch of the geometry internals to a bit more flexible. This has resulted in some very long sought after optimizations and has also spawned some activities to replace/supplement CGAL as the main computational geometry engine.
This has also opened for some new features which are currently in master or in the pipeline, ready to reach release quality; text, offset, svg import. Then there are list comprehensions, path extrusion etc..

Once that’s out, the next big push might very well be a language upgrade or a front-end update. There are many factors to take in to account (apart from how much work and who is going to do it), and Doug pretty much nails it from my point of view: Backwards compatibility or upgrade path, expansion of user-base by adding more interactive features (without making code less readable or writable), library management, publishing options. I can go on.. This is something I’m putting some thought into. Right now, OpenSCAD survives because it fits the bill for its very forgiving users. Until we repair the most grave weaknesses, there is no need to try and expand the user-base too much..

Cheers,

 -Marius





_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD 3000

doug.moen
In reply to this post by ednisley
Hi Ed. I'm using OpenSCAD in a relatively simple way to algorithmically generate models for 3D printing, and that's about it. I don't want to tell other people what to do, but I think breaking backward compatibility is a bad idea unless it is done correctly, and produces a big enough payoff. OpenSCAD can be extended in a lot of ways to make it more powerful, without breaking backward compatibility. If there's a compelling argument for breaking backward compatibility, I think it would involve making the system easier to use. Better scoping rules will help, but there needs to be much more than that to justify a complete break, which is why I was talking about a much better GUI as maybe providing a compelling enough reason.

I'm not actually saying we should run off and do all the speculative things that were in that last message. I'm just trying to put the "break backward compatibility" idea into perspective.


On 15 June 2014 21:17, Ed Nisley <[hidden email]> wrote:
On 06/15/2014 07:30 PM, doug moen wrote:
> So what are the compelling new features?

I'm barely qualified to carry the water for you folks, so what scares me
witless is that you're coming up with a *wonderful* language with *all*
the features, but that will be basically unusable for the stuff I'm doing.

What's absolutely compelling about OpenSCAD, right now, is that I can
sketch out a doodad, make a few measurements, define a few constants,
bang out some code, and *build* something. There is *nothing* else like
it out there, at least in the range that I can afford, period.

I'm building more-or-less trivial one-off parts for my projects: a few
hundred lines of code, tops, two or three iterations to get the fit
nailed down, and it's hot off my Makergear's platform. Unlike, say,
nophead, I'm not doing production runs, don't need an integrated BOM,
don't need fancy models with precisely located washers, and will never
build that thing again.

Heck, there aren't any reusable parts and the next time around I'd do it
differently anyway.

Some of what I do shows up in magazine columns, where there's a premium
on *simple* code that does pretty much what it says. A program that
depends on complex manipulations, vast libraries, and other overhead
that can't be explained simply isn't practical; there's a premium on an
explanation that fits in a 2500 word column, not the first installment
of a year's worth of writing about a program that will produce a bracket.

So, please, please, *please* don't turn OpenSCAD into something that
requires advanced math and l33t programming skillz just to make a
bracket. Yes, I'd like a "real" programming language and I'm even
willing endure a language discontinuity, but don't make the simple
things complex in order to make the complex things possible.

Now I'll return to my bracket, which is already in progress ... [grin]

--
Ed
softsolder.com
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD 3000

Mike Meyer
In reply to this post by doug.moen
On Sun, Jun 15, 2014 at 6:30 PM, doug moen <[hidden email]> wrote:
> If OpenSCAD 3000 had a Haskell-like type system, then I imagine it would be as wildly popular as ImplicitCad. I appreciate the benefits of the Haskell type system, but man was that a steep cliff to climb to learn how to use it.

Having spent the last year helping software developers move from blub
languages to Haskell, I agree 100%. However, if you want to use an
existing language and also want immutable values (or is it
variables?), you're sort of stuck. Once you get past the functional
language with algebraic type systems, you get into languages where
values being immutable is a convention, not enforced by the
language. Of course, if what you want is named constants and not
variables holding immutable values, none of them do that. Or maybe
there's a language I don't know about that fits the bill.

Given that, you might as well go with Python. There's an appropriate
immutable type for each of the types used by OpenSCAD. But there are
lots of choices that would improve things.

> If we are just talking about a new evaluation engine, then I think LLVM looks interesting.

No, I'm talking about a new interpreter. Running on LLVM - or JVM,
.NET, or whatever - would be an implementation detail. I think we'd be
a lot better of if the OpenSCAD language were something with years if
not decades of use in the real world as a general purpose language,
that is designed, developed, maintained and documented by some a group
that's being doing it for that long. Along with an extension module
for generating models.
current language.

While that means such a language won't be compatible with the current
one, it doesn't mean that OpenSCAD has to be incompatible with the
current language, though.

> I personally think that the OpenSCAD installed base, the large collection of scripts on Thingiverse, and the community of people who know and use the current language, are OpenSCADs most important assets. So backward compatibility is really important, and I suspect that what Python did was a mistake. If you want to fork the language, do it in a way that scripts written in the new dialect can use library files written in the old dialect, and vice versa. The compiler should be able to auto-detect which dialect is in use.

Don't worry, I have no intention of forking OpenSCAD. While Python 3
may have been a mistake (that we'll see in time, but I'm convinced
that the developers chose the right path if Python was going to
survive in the modern world), OpenSCAD has other options.

> If "OpenSCAD 3000" is not backward compatible, then it needs to be more compelling than regular OpenSCAD, and be able to attract a new community that is larger than the current community. Otherwise, you just risk splitting the existing OpenSCAD community into two smaller communities.

Is there any reason that OpenSCAD (the application) can't ship with
two (or more) languages? You want autodetection of type - use the
extension on the file name. After all, if we're going with an existing
language, might as well use the same extension as it currently does so
all the tools for working with it keep right on working.

> So what are the compelling new features? Maybe OpenSCAD 3000 geometry computations can be embedded in web pages? Maybe instead of a text based programming interface, there is a GUI based direct manipulation programming interface. Maybe you can edit models by interacting directly with the rendered view. Maybe there is a GUI interface to the OpenSCAD library, so that you can browse through a set of graphical thumbnails of geometry modules.

How about a modern import system? Variables that behave in a sane
manner? Error handling mechanisms that give you more informative
messages that "Syntax Error" (the last thing I saw that primitive was
v6 C!)? Access to a large *programming* library, as opposed to
libraries of modules? Proper Unicode support so people can work in
languages other than English? Etc...

As for the other things, properly splitting the primitives from the
language would make it easier to add things like a GUI for invoking
the primitives. And having some other group doing language design &
support would free up more time to work on them :-).

        <mike


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD 3000

Mike Meyer
In reply to this post by ednisley
On Sun, Jun 15, 2014 at 8:17 PM, Ed Nisley <[hidden email]> wrote:
> What's absolutely compelling about OpenSCAD, right now, is that I can
> sketch out a doodad, make a few measurements, define a few constants,
> bang out some code, and *build* something. There is *nothing* else like
> it out there, at least in the range that I can afford, period.
> I'm building more-or-less trivial one-off parts for my projects: a few
> hundred lines of code, tops, two or three iterations to get the fit
> nailed down, and it's hot off my Makergear's platform. Unlike, say,
> nophead, I'm not doing production runs, don't need an integrated BOM,
> don't need fancy models with precisely located washers, and will never
> build that thing again.

As the only one making suggestions for changes on this thread, let me
say that preserving that is also high on my list. That's why I'd pick
Python (but that choice is clearly not mine). Using
Python-embedded-in-OpenSCAD would mostly be syntactic changes:
translate([1, 1, 1], objects ...) instead of translate([1, 1, 1]) {
objects ... }. The biggest difference (with P-E-O) would be using ':'
and indentation for blocks instead of { }. While I consider that one
of Python's best features, enough people hate it that it might not
make a good choice. Maybe Ruby - with "code blocks" - would be a
better choice.

       <mike


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD 3000

Mike Meyer
In reply to this post by nophead
On Sun, Jun 15, 2014 at 6:37 PM, nop head <[hidden email]> wrote:
> I don't understand the logic that a strong type system is needed because OpenScad primitives have side effects. None of them have side effects in the programming sense, they are all pure.

Um, no.  A "side effect" of a function is something other than the
return value that "modifies some state or has an observable
interaction with the calling functions or the outside world." Since
the OpenSCAD primitives don't have return values, they couldn't do
anything if they didn't have side effects. For that matter, if I call
"sphere(10) ;", I can clearly observe its effects in the OpenSCAD
view pane.

The reason people care about pure functions is because they are easier
to reason about (you don't have to worry about any state outside the
function) and they free the optimizer to do lots of interesting things
- like skip function calls completely. Doing the latter to OpenSCAD
primitives would be a disaster.

      <mike


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD 3000

kintel
Administrator
On Jun 15, 2014, at 23:03 PM, Mike Meyer <[hidden email]> wrote:

> Sincethe OpenSCAD primitives don't have return values, they couldn't do
> anything if they didn't have side effects. For that matter, if I call
> "sphere(10) ;", I can clearly observe its effects in the OpenSCAD
> view pane.

Actually, each OpenSCAD module returns geometry. There are no side effects (except echo which instead writes to the console; which is the only module really causing problems in this respect).
This is conceptually not different from what Wikipedia tries to bring across with the definition you quoted.
e.g. “skipping function calls” is equivalent to _not_ returning any geometry (which we actually do if someone tries to do this; e.g. intersect two non-intersecting objects).

To comment on the programming language discussion: Instead of embedding a standard full-fledged programming language into OpenSCAD (which likely would include allowing for all user-space libraries available for that language as well), I’d rather let people develop their own ways of making OpenSCAD functionality available to programmers of those languages. There are already multiple projects doing this for python, ruby, c++, javascript. Most of these would output a “pure CSG” description; a hierarchical file format which is the subset of OpenSCAD without user-space modules, functions or variables. Alternatively, let these language bindings use a common geometry API. This was attempted by one of the python bindings, but it’s too much work to maintain this against a moving target.

That said, if we find good ways of sandboxing this and provide mechanisms for module developers to package “intelligent” modules with a clear interface, I don’t see why it shouldn’t be allowed. This would be part of a discussion on how to separate OpenSCAD into multiple “tiers”, where users could isolate themselves from the details while still being able to use external modules utilizing more advanced functionality.

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD 3000

MichaelAtOz
Administrator
In reply to this post by ednisley
Ed Nisley-2 wrote
So, please, please, *please* don't turn OpenSCAD into something that
requires advanced math and l33t programming skillz just to make a
bracket.
+1. But from what I read this is not likely, in the near term. Need a close eye on it tho...
Admin - email* me if you need anything,
or if I've done something stupid...
* 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.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD 3000

Mike Meyer
In reply to this post by kintel
On Sun, Jun 15, 2014 at 11:57 PM, Marius Kintel <[hidden email]> wrote:
> On Jun 15, 2014, at 23:03 PM, Mike Meyer <[hidden email]> wrote:
> > Sincethe OpenSCAD primitives don't have return values, they couldn't do
> > anything if they didn't have side effects. For that matter, if I call
> > "sphere(10) ;", I can clearly observe its effects in the OpenSCAD
> > view pane.
> Actually, each OpenSCAD module returns geometry. There are no side effects (except echo which instead writes to the console; which is the only module really causing problems in this respect).

Are we talking about the same set of primitives? Because if I try and
assign the result of calling "sphere" to a value in OpenSCAD, I get an
error message about "Ignoring unknown function 'sphere'". Maybe you're
talking about an as yet unreleased version?

> This is conceptually not different from what Wikipedia tries to bring across with the definition you quoted.
> e.g. “skipping function calls” is equivalent to _not_ returning any geometry (which we actually do if someone tries to do this; e.g. intersect two non-intersecting objects).

No, "skipping function calls" is *not* equivalent to "not returning
any geometry". "Skipping function calls" is part of the process of
evaluation for the lambda calculus, whence the notion of "pure
functions" comes from. It means you can substitute the value returned
by a pure function for the function anywhere it occurs without
changing the program's behavior, so that these two two-line functions
have the same semantics:
     
     sphere(10) ;
     translate([10, 10, 10]) sphere(10) ;

     x = sphere(10) ;
     translate([10, 10, 10]) x ;

So is that the case in your version of OpenSCAD where the statement "x
= sphere(10) ;" runs the sphere primitive, instead trying to run the
function sphere?

> To comment on the programming language discussion: Instead of embedding a standard full-fledged programming language into OpenSCAD (which likely would include allowing for all user-space libraries available for that language as well), I’d rather let people develop their own ways of making OpenSCAD functionality available to programmers of those languages. There are already multiple projects doing this for python, ruby, c++, javascript. Most of these would output a “pure CSG” description; a hierarchical file format which is the subset of OpenSCAD without user-space modules, functions or variables. Alternatively, let these language bindings use a common geometry API. This was attempted by one of the python bindings, but it’s too much work to maintain this against a moving target.

Well, yes, providing access to all the user-space libraries for those
languages is one of the benefits of embedding a full language. Being
able to do vector calculations with NumPY, for instance.

And yes, I'll probably start using one of those bindings (though as
stated previously, this makes an excellent excuse to experiment with
the free monad + interpreter pattern in Haskell). However, the problem
with letting external groups maintain *all* such bindings is that it
1) doesn't make those tools available to the OpenSCAD community at
large, and 2) it doesn't leverage the decades of experience and
testing that are available in those languages.

The first of these issues could be solved if OpenSCAD shipped one of
those bindings (not that that's what I'd propose). One of my proposals
- provide SWIG bindings for the primitives and then ship one - would
solve the second.


> That said, if we find good ways of sandboxing this and provide mechanisms for module developers to package “intelligent” modules with a clear interface, I don’t see why it shouldn’t be allowed. This would be part of a discussion on how to separate OpenSCAD into multiple “tiers”, where users could isolate themselves from the details while still being able to use external modules utilizing more advanced functionality.

Really? You want to use the OpenSCAD language as a research vehicle
for looking at failed, decades-old ideas in language design? While I
can see why there would be an interest and possibly even some benefit
in reopening some of those things, it's not at all clear that using
the OpenSCAD language as the test platform is good for OpenSCAD.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD 3000

MichaelAtOz
Administrator
I think there is a big misunderstanding out there.
OpenSCAD is a descriptive language to produce geometry, and other language features are ancillary to producing the geometry tree.
Each branch of the tree is pure.
So for example a for loop [for (i=...) ] does produce various iterations of 'i=' it is generating a sequence of branches of the tree, each pure with it's own immutable value of 'i'.

The result of any openscad module (except echo) is geometry. The rest is just sugar to make the description easier.
Admin - email* me if you need anything,
or if I've done something stupid...
* 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.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD 3000

MichaelAtOz
Administrator
Make that "does NOT produce various iterations"
Admin - email* me if you need anything,
or if I've done something stupid...
* 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.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD 3000

nophead
Because there are no mutable variables OpenScad can be sure that if it sees a module invocation with the same value arguments as another one it can simply re-use the geometry it made before. Similarly if it sees a function call with the same values it can just return the same result.

Also because modules and functions have no side effects programmatically, I.e. they don't change the state of the program, they can be run in parallel on hardware with multiple processors.

None of this requires a strict type system. That would only be needed if there were mutable variables.

Not having mutable variables make code easier to read and is of no detriment to describing physical objects. Nothing  needs to change during a description. Iteration can be replaced by recursive functions and modules, for loops and list comprehensions.


On 16 June 2014 09:16, MichaelAtOz <[hidden email]> wrote:
Make that "does NOT produce various iterations"



--
View this message in context: http://forum.openscad.org/OpenSCAD-3000-tp8431p8473.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
1234 ... 8