Re: Lua

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Lua

stonysmith

I can agree with taking a look at LUA, I found it to be generic enough that I could "get something productive done" without a huge learning curve, and the interpreter seems to be fairly small in size.

For my own two cents, just give me real variables such as N=N+1 and I will be happy, but that is because I'm an old-school programmer.

This talk of scrapping the system... ignore it. You've got something good and unique here.. don't give up on it.


_______________________________________________
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: Lua

Taylor Alexander

I never intended to disparage the system when suggesting we look towards a next generation openscad version. I'm talking about a major upgrade (which might include merging with another CAD package), not "scrapping" anything. OpenSCAD is great but as discussed at length, there's areas where it can improve.

On Apr 17, 2013 1:30 AM, "Stony Smith" <[hidden email]> wrote:

I can agree with taking a look at LUA, I found it to be generic enough that I could "get something productive done" without a huge learning curve, and the interpreter seems to be fairly small in size.

For my own two cents, just give me real variables such as N=N+1 and I will be happy, but that is because I'm an old-school programmer.

This talk of scrapping the system... ignore it. You've got something good and unique here.. don't give up on it.


_______________________________________________
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: Lua

nophead
Please don't add variables. They are unnecessary and make code harder to read. Instead please add vector concatenation and slicing so lists can be be build using recursive functions. There is then no need for variables as nothing needs to change during the generation of an object. Anything you would compute with a loop can be done with recursion. It just needs a few examples to educate people.

Rename the existing variables "constants", to stop people thinking they should be mutable.


On 17 April 2013 09:41, Taylor Alexander <[hidden email]> wrote:

I never intended to disparage the system when suggesting we look towards a next generation openscad version. I'm talking about a major upgrade (which might include merging with another CAD package), not "scrapping" anything. OpenSCAD is great but as discussed at length, there's areas where it can improve.

On Apr 17, 2013 1:30 AM, "Stony Smith" <[hidden email]> wrote:

I can agree with taking a look at LUA, I found it to be generic enough that I could "get something productive done" without a huge learning curve, and the interpreter seems to be fairly small in size.

For my own two cents, just give me real variables such as N=N+1 and I will be happy, but that is because I'm an old-school programmer.

This talk of scrapping the system... ignore it. You've got something good and unique here.. don't give up on it.


_______________________________________________
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: Lua

Taylor Alexander

I feel like that's not a feature we should just assume out... has anyone tried it before? Its like the single most requested feature. If the people requesting the feature are wrong, we should examine why they misunderstood the solution and try to fix the system so the users stop being confused.

On Apr 17, 2013 2:11 AM, "nop head" <[hidden email]> wrote:
Please don't add variables. They are unnecessary and make code harder to read. Instead please add vector concatenation and slicing so lists can be be build using recursive functions. There is then no need for variables as nothing needs to change during the generation of an object. Anything you would compute with a loop can be done with recursion. It just needs a few examples to educate people.

Rename the existing variables "constants", to stop people thinking they should be mutable.


On 17 April 2013 09:41, Taylor Alexander <[hidden email]> wrote:

I never intended to disparage the system when suggesting we look towards a next generation openscad version. I'm talking about a major upgrade (which might include merging with another CAD package), not "scrapping" anything. OpenSCAD is great but as discussed at length, there's areas where it can improve.

On Apr 17, 2013 1:30 AM, "Stony Smith" <[hidden email]> wrote:

I can agree with taking a look at LUA, I found it to be generic enough that I could "get something productive done" without a huge learning curve, and the interpreter seems to be fairly small in size.

For my own two cents, just give me real variables such as N=N+1 and I will be happy, but that is because I'm an old-school programmer.

This talk of scrapping the system... ignore it. You've got something good and unique here.. don't give up on it.


_______________________________________________
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: Lua

nophead
Functional languages don't have variables so clearly they are not necessary in a general programming language let alone a simple declarative scripting language like OpenScad. The problem is must people are brought up on imperative languages and get used to iterating with loops, rather than recursion. 

If you have ever done any C++ template metaprogramming then you see there are no variables at compile time there as well but types (which are constant) and recursion allow almost anything to be done at compile time.


On 17 April 2013 10:16, Taylor Alexander <[hidden email]> wrote:

I feel like that's not a feature we should just assume out... has anyone tried it before? Its like the single most requested feature. If the people requesting the feature are wrong, we should examine why they misunderstood the solution and try to fix the system so the users stop being confused.

On Apr 17, 2013 2:11 AM, "nop head" <[hidden email]> wrote:
Please don't add variables. They are unnecessary and make code harder to read. Instead please add vector concatenation and slicing so lists can be be build using recursive functions. There is then no need for variables as nothing needs to change during the generation of an object. Anything you would compute with a loop can be done with recursion. It just needs a few examples to educate people.

Rename the existing variables "constants", to stop people thinking they should be mutable.


On 17 April 2013 09:41, Taylor Alexander <[hidden email]> wrote:

I never intended to disparage the system when suggesting we look towards a next generation openscad version. I'm talking about a major upgrade (which might include merging with another CAD package), not "scrapping" anything. OpenSCAD is great but as discussed at length, there's areas where it can improve.

On Apr 17, 2013 1:30 AM, "Stony Smith" <[hidden email]> wrote:

I can agree with taking a look at LUA, I found it to be generic enough that I could "get something productive done" without a huge learning curve, and the interpreter seems to be fairly small in size.

For my own two cents, just give me real variables such as N=N+1 and I will be happy, but that is because I'm an old-school programmer.

This talk of scrapping the system... ignore it. You've got something good and unique here.. don't give up on it.


_______________________________________________
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: Lua

Taylor Alexander

Well, I don't know enough about functional programming to comment on its utility here, I just know OpenSCADs odd syntax was hard for me to learn, so I had a hard time and eventually gave up, frustrated. I don't think keeping strange or unfamiliar syntax is the best idea, unless it really seriously has a major advantage. You know this stuff back and forth obviously, but how hard was it at the beginning?

I was actually just reading about functional programming (Haskell) compared to Python (looking at implicitcad which is Haskell), and they mentioned the steep learning curve there too.

On Apr 17, 2013 2:25 AM, "nop head" <[hidden email]> wrote:
Functional languages don't have variables so clearly they are not necessary in a general programming language let alone a simple declarative scripting language like OpenScad. The problem is must people are brought up on imperative languages and get used to iterating with loops, rather than recursion. 

If you have ever done any C++ template metaprogramming then you see there are no variables at compile time there as well but types (which are constant) and recursion allow almost anything to be done at compile time.


On 17 April 2013 10:16, Taylor Alexander <[hidden email]> wrote:

I feel like that's not a feature we should just assume out... has anyone tried it before? Its like the single most requested feature. If the people requesting the feature are wrong, we should examine why they misunderstood the solution and try to fix the system so the users stop being confused.

On Apr 17, 2013 2:11 AM, "nop head" <[hidden email]> wrote:
Please don't add variables. They are unnecessary and make code harder to read. Instead please add vector concatenation and slicing so lists can be be build using recursive functions. There is then no need for variables as nothing needs to change during the generation of an object. Anything you would compute with a loop can be done with recursion. It just needs a few examples to educate people.

Rename the existing variables "constants", to stop people thinking they should be mutable.


On 17 April 2013 09:41, Taylor Alexander <[hidden email]> wrote:

I never intended to disparage the system when suggesting we look towards a next generation openscad version. I'm talking about a major upgrade (which might include merging with another CAD package), not "scrapping" anything. OpenSCAD is great but as discussed at length, there's areas where it can improve.

On Apr 17, 2013 1:30 AM, "Stony Smith" <[hidden email]> wrote:

I can agree with taking a look at LUA, I found it to be generic enough that I could "get something productive done" without a huge learning curve, and the interpreter seems to be fairly small in size.

For my own two cents, just give me real variables such as N=N+1 and I will be happy, but that is because I'm an old-school programmer.

This talk of scrapping the system... ignore it. You've got something good and unique here.. don't give up on it.


_______________________________________________
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

_______________________________________________
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: Lua

Taylor Alexander

And also... again... library support I think could be amazing. Python can do a *lot* with all the libraries that exist for it.

One could always write Python that generates scad code, but then you still have to learn how scad code works, killing one benefit: the learning curve.

On Apr 17, 2013 2:35 AM, "Taylor Alexander" <[hidden email]> wrote:

Well, I don't know enough about functional programming to comment on its utility here, I just know OpenSCADs odd syntax was hard for me to learn, so I had a hard time and eventually gave up, frustrated. I don't think keeping strange or unfamiliar syntax is the best idea, unless it really seriously has a major advantage. You know this stuff back and forth obviously, but how hard was it at the beginning?

I was actually just reading about functional programming (Haskell) compared to Python (looking at implicitcad which is Haskell), and they mentioned the steep learning curve there too.

On Apr 17, 2013 2:25 AM, "nop head" <[hidden email]> wrote:
Functional languages don't have variables so clearly they are not necessary in a general programming language let alone a simple declarative scripting language like OpenScad. The problem is must people are brought up on imperative languages and get used to iterating with loops, rather than recursion. 

If you have ever done any C++ template metaprogramming then you see there are no variables at compile time there as well but types (which are constant) and recursion allow almost anything to be done at compile time.


On 17 April 2013 10:16, Taylor Alexander <[hidden email]> wrote:

I feel like that's not a feature we should just assume out... has anyone tried it before? Its like the single most requested feature. If the people requesting the feature are wrong, we should examine why they misunderstood the solution and try to fix the system so the users stop being confused.

On Apr 17, 2013 2:11 AM, "nop head" <[hidden email]> wrote:
Please don't add variables. They are unnecessary and make code harder to read. Instead please add vector concatenation and slicing so lists can be be build using recursive functions. There is then no need for variables as nothing needs to change during the generation of an object. Anything you would compute with a loop can be done with recursion. It just needs a few examples to educate people.

Rename the existing variables "constants", to stop people thinking they should be mutable.


On 17 April 2013 09:41, Taylor Alexander <[hidden email]> wrote:

I never intended to disparage the system when suggesting we look towards a next generation openscad version. I'm talking about a major upgrade (which might include merging with another CAD package), not "scrapping" anything. OpenSCAD is great but as discussed at length, there's areas where it can improve.

On Apr 17, 2013 1:30 AM, "Stony Smith" <[hidden email]> wrote:

I can agree with taking a look at LUA, I found it to be generic enough that I could "get something productive done" without a huge learning curve, and the interpreter seems to be fairly small in size.

For my own two cents, just give me real variables such as N=N+1 and I will be happy, but that is because I'm an old-school programmer.

This talk of scrapping the system... ignore it. You've got something good and unique here.. don't give up on it.


_______________________________________________
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

_______________________________________________
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: Lua

nophead
I don't understand why you find the syntax odd. The syntax is almost identical to a subset of C. Are you sure you don't mean the semantics, which are declarative / functional rather than imperative?

I prefer Python syntax myself but quite happy with C style syntax.

I never had any problems with learning OpenScad but then I have 35 years experience in programming in various languages. I have never used a pure functional language but I have done some C++ template meta programming (which is a massive hack in my opinion). If you don't like openscad you will hate that.

I also created a declarative language myself so I am used to using declarative script to describe things in a tree structure.


On 17 April 2013 10:37, Taylor Alexander <[hidden email]> wrote:

And also... again... library support I think could be amazing. Python can do a *lot* with all the libraries that exist for it.

One could always write Python that generates scad code, but then you still have to learn how scad code works, killing one benefit: the learning curve.

On Apr 17, 2013 2:35 AM, "Taylor Alexander" <[hidden email]> wrote:

Well, I don't know enough about functional programming to comment on its utility here, I just know OpenSCADs odd syntax was hard for me to learn, so I had a hard time and eventually gave up, frustrated. I don't think keeping strange or unfamiliar syntax is the best idea, unless it really seriously has a major advantage. You know this stuff back and forth obviously, but how hard was it at the beginning?

I was actually just reading about functional programming (Haskell) compared to Python (looking at implicitcad which is Haskell), and they mentioned the steep learning curve there too.

On Apr 17, 2013 2:25 AM, "nop head" <[hidden email]> wrote:
Functional languages don't have variables so clearly they are not necessary in a general programming language let alone a simple declarative scripting language like OpenScad. The problem is must people are brought up on imperative languages and get used to iterating with loops, rather than recursion. 

If you have ever done any C++ template metaprogramming then you see there are no variables at compile time there as well but types (which are constant) and recursion allow almost anything to be done at compile time.


On 17 April 2013 10:16, Taylor Alexander <[hidden email]> wrote:

I feel like that's not a feature we should just assume out... has anyone tried it before? Its like the single most requested feature. If the people requesting the feature are wrong, we should examine why they misunderstood the solution and try to fix the system so the users stop being confused.

On Apr 17, 2013 2:11 AM, "nop head" <[hidden email]> wrote:
Please don't add variables. They are unnecessary and make code harder to read. Instead please add vector concatenation and slicing so lists can be be build using recursive functions. There is then no need for variables as nothing needs to change during the generation of an object. Anything you would compute with a loop can be done with recursion. It just needs a few examples to educate people.

Rename the existing variables "constants", to stop people thinking they should be mutable.


On 17 April 2013 09:41, Taylor Alexander <[hidden email]> wrote:

I never intended to disparage the system when suggesting we look towards a next generation openscad version. I'm talking about a major upgrade (which might include merging with another CAD package), not "scrapping" anything. OpenSCAD is great but as discussed at length, there's areas where it can improve.

On Apr 17, 2013 1:30 AM, "Stony Smith" <[hidden email]> wrote:

I can agree with taking a look at LUA, I found it to be generic enough that I could "get something productive done" without a huge learning curve, and the interpreter seems to be fairly small in size.

For my own two cents, just give me real variables such as N=N+1 and I will be happy, but that is because I'm an old-school programmer.

This talk of scrapping the system... ignore it. You've got something good and unique here.. don't give up on it.


_______________________________________________
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

_______________________________________________
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: Lua

Tom Cook
In reply to this post by nophead
While everything you say is true, it's a pretty clear fallacy; after
all, people built buildings hundreds of feet tall without cranes so
clearly they are not necessary in a building project.  The problem is
most people are brought up on cranes and get used to lifting things
with electricity instead of ropes and pulleys.

I'm not clear why people being brought up on imperative languages _is_
a problem anyway.  The vast majority of useful software is written in
them; sounds like a useful skill to learn.  Listening to you, it seems
that iteration is somehow inherently evil; I'm not clear why.  In 99
cases out of 100 it is better than recursion in every way; more
readable, using less memory, less CPU cycles and more predictable
branching.  What's not to like?  While almost anything can be done at
compile time with C++ template metaprogramming, you would have to be
insane to attempt any serious software project solely using it.

My $0.02
Tom

On 17 Apr 2013 10:25, "nop head" <[hidden email]> wrote:

>
> Functional languages don't have variables so clearly they are not necessary in a general programming language let alone a simple declarative scripting language like OpenScad. The problem is must people are brought up on imperative languages and get used to iterating with loops, rather than recursion.
>
> If you have ever done any C++ template metaprogramming then you see there are no variables at compile time there as well but types (which are constant) and recursion allow almost anything to be done at compile time.
>
>
> On 17 April 2013 10:16, Taylor Alexander <[hidden email]> wrote:
>>
>> I feel like that's not a feature we should just assume out... has anyone tried it before? Its like the single most requested feature. If the people requesting the feature are wrong, we should examine why they misunderstood the solution and try to fix the system so the users stop being confused.
>>
>> On Apr 17, 2013 2:11 AM, "nop head" <[hidden email]> wrote:
>>>
>>> Please don't add variables. They are unnecessary and make code harder to read. Instead please add vector concatenation and slicing so lists can be be build using recursive functions. There is then no need for variables as nothing needs to change during the generation of an object. Anything you would compute with a loop can be done with recursion. It just needs a few examples to educate people.
>>>
>>> Rename the existing variables "constants", to stop people thinking they should be mutable.
>>>
>>>
>>> On 17 April 2013 09:41, Taylor Alexander <[hidden email]> wrote:
>>>>
>>>> I never intended to disparage the system when suggesting we look towards a next generation openscad version. I'm talking about a major upgrade (which might include merging with another CAD package), not "scrapping" anything. OpenSCAD is great but as discussed at length, there's areas where it can improve.
>>>>
>>>> On Apr 17, 2013 1:30 AM, "Stony Smith" <[hidden email]> wrote:
>>>>>
>>>>> I can agree with taking a look at LUA, I found it to be generic enough that I could "get something productive done" without a huge learning curve, and the interpreter seems to be fairly small in size.
>>>>>
>>>>> For my own two cents, just give me real variables such as N=N+1 and I will be happy, but that is because I'm an old-school programmer.
>>>>>
>>>>> This talk of scrapping the system... ignore it. You've got something good and unique here.. don't give up on it.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
_______________________________________________
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: Lua

Tom Cook
In reply to this post by nophead
On Wed, Apr 17, 2013 at 11:36 AM, nop head <[hidden email]> wrote:
> I don't understand why you find the syntax odd. The syntax is almost
> identical to a subset of C. Are you sure you don't mean the semantics, which
> are declarative / functional rather than imperative?

The oddness is precisely that the syntax is fairly close to C, so you
might expect the semantics to resemble it, too.  Taking the syntax
from one language and the semantics from another and mashing them
together is just a (declarative?) recipe for confusing people.
_______________________________________________
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: Lua

nophead
In reply to this post by Tom Cook
On 17 April 2013 11:42, Tom Cook <[hidden email]> wrote:
I'm not clear why people being brought up on imperative languages _is_
a problem anyway.  The vast majority of useful software is written in
them; sounds like a useful skill to learn.  
 
It isn't a problem in itself but it is why people constantly demand variables in OpenScad. If they had used a functional language before they would realise they are needed to describe something that isn't changing. The only real variable in OpenScad is $t used for animation. Everything else about the object you want rendered is known before openscad runs, therefore constant. 
 
Listening to you, it seems
that iteration is somehow inherently evil; I'm not clear why.

Iteration isn't evil but mutable variables make programs harder to follow due to lack of <a href="http://referential transparency">referential transparency.

A simple example occurred in this list a while ago. Somebody wanted to do something like

length = 100;

...

length = length - 5;

Here length is used to mean two different things in different places in the script. The second line should have been offset_length = length - 5; making it much easier to follow. It is good that OpenScad forced the script be more readable.


 In 99
cases out of 100 it is better than recursion in every way; more
readable, using less memory, less CPU cycles and more predictable
branching.  

In this case the cycles used to compute the model parameters should be insignificant compared to the cycles needed to compute and render the geometry. In other languages I think the compiler can translate tail recursion into a loop for efficiency. Also, I think I am right in saying OpenScad can cache geometry because it knows modules can't have side effects, so calling a module with a certain set of arguments always produces the same object.

I don't agree recursion is any less readable in a lot of cases it is more readable and more concise. E.g.

function vector_sum(vector) = len(vector) ? vector[0] + vector_sum(vector[1:]) : 0;

Needs vector slicing though, currently has to be done with an extra parameter to iterate through the vector.
 
 
What's not to like?  While almost anything can be done at
compile time with C++ template metaprogramming, you would have to be
insane to attempt any serious software project solely using it.

OpenScad scripts are different in that they describe something fixed rather than compute something. Most C++ programs are not like that.

You have to somewhat insane to do template metaprogramming, nevertheless boost is very useful.
 

My $0.02
Tom

On 17 Apr 2013 10:25, "nop head" <[hidden email]> wrote:
>
> Functional languages don't have variables so clearly they are not necessary in a general programming language let alone a simple declarative scripting language like OpenScad. The problem is must people are brought up on imperative languages and get used to iterating with loops, rather than recursion.
>
> If you have ever done any C++ template metaprogramming then you see there are no variables at compile time there as well but types (which are constant) and recursion allow almost anything to be done at compile time.
>
>
> On 17 April 2013 10:16, Taylor Alexander <[hidden email]> wrote:
>>
>> I feel like that's not a feature we should just assume out... has anyone tried it before? Its like the single most requested feature. If the people requesting the feature are wrong, we should examine why they misunderstood the solution and try to fix the system so the users stop being confused.
>>
>> On Apr 17, 2013 2:11 AM, "nop head" <[hidden email]> wrote:
>>>
>>> Please don't add variables. They are unnecessary and make code harder to read. Instead please add vector concatenation and slicing so lists can be be build using recursive functions. There is then no need for variables as nothing needs to change during the generation of an object. Anything you would compute with a loop can be done with recursion. It just needs a few examples to educate people.
>>>
>>> Rename the existing variables "constants", to stop people thinking they should be mutable.
>>>
>>>
>>> On 17 April 2013 09:41, Taylor Alexander <[hidden email]> wrote:
>>>>
>>>> I never intended to disparage the system when suggesting we look towards a next generation openscad version. I'm talking about a major upgrade (which might include merging with another CAD package), not "scrapping" anything. OpenSCAD is great but as discussed at length, there's areas where it can improve.
>>>>
>>>> On Apr 17, 2013 1:30 AM, "Stony Smith" <[hidden email]> wrote:
>>>>>
>>>>> I can agree with taking a look at LUA, I found it to be generic enough that I could "get something productive done" without a huge learning curve, and the interpreter seems to be fairly small in size.
>>>>>
>>>>> For my own two cents, just give me real variables such as N=N+1 and I will be happy, but that is because I'm an old-school programmer.
>>>>>
>>>>> This talk of scrapping the system... ignore it. You've got something good and unique here.. don't give up on it.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
_______________________________________________
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: Lua

nophead
In reply to this post by Tom Cook



On 17 April 2013 11:44, Tom Cook <[hidden email]> wrote:
The oddness is precisely that the syntax is fairly close to C, so you
might expect the semantics to resemble it, too.  Taking the syntax
from one language and the semantics from another and mashing them
together is just a (declarative?) recipe for confusing people.

Maybe but one could equally argue that a familiar syntax makes it easier to learn because you don't need to learn that part, only the semantics.

_______________________________________________
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: Lua

Alan Cox
In reply to this post by Tom Cook
> I'm not clear why people being brought up on imperative languages _is_
> a problem anyway.  The vast majority of useful software is written in
> them; sounds like a useful skill to learn.  Listening to you, it seems

Its like the dark side of the force. Easy to get into, easy to get
results but forever limiting ;-)

More importantly its a "dark side of the force" to a lot of programmers,
but *not* to people in general. Imperative programming is a highly
artificial computer science specific beast. For the rest of the world

                i = i + 1

is nonsense.

> that iteration is somehow inherently evil; I'm not clear why.  In 99
> cases out of 100 it is better than recursion in every way; more
> readable, using less memory, less CPU cycles and more predictable
> branching.  What's not to like?  While almost anything can be done at
> compile time with C++ template metaprogramming, you would have to be
> insane to attempt any serious software project solely using it.

An OpenSCAD "program" is not a program in the usual "executes through
time, accepts and responds to external time oriented events" manner. It's
a data structure. Being a data structure is also very powerful because if
you ever want to do parallelism its implicit in the structure, while in
an imperative language its hard to extract. Processors are not getting
much faster, just more threaded, so that will matter a lot eventually.

And if you must have variables in an openscad type language you can use
implicitcad, which supports them. No need to use OpenSCAD if it doesn't
have the feature you want !

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