[OpenSCAD] eval( ) ???

Carsten Arnholm arnholm at arnholm.org
Sun May 17 17:34:21 EDT 2015

Hello Doug,

Interesting discussion! Please understand that if you find I present 
alternative viewpoints I very much respect the work being done. I just 
want to add my perspective.

On 2015-05-17 01:35, doug moen wrote:
> One of my top goals for "OpenSCAD 2" is to stay true to the goals and
> philosophy of OpenSCAD. I've tried to figure out what these are by
> talking to Marius and reading forum posts for the last few years.

I have followed the posts for only a few months, so I do not have the 
full picture. I apologise if I repeat important discussions you may have 
had already. I have noted the stated goal of "functional language", but 
I have yet to see a truly convincing explanation of why that is a good 
thing as seen from the user point of view. More on that below.

> Some OpenSCAD users are computer programmers like you and me, but many
> are not.

On the top of the front page of http://www.openscad.org/ it says "The 
Programmers Solid 3D CAD Modeller". Programmers are the stated primary 
target for OpenSCAD. There are many CAD packages around, most target 
non-programmers first and foremost. OpenSCAD targets programmers and 
that should influence the way capabilities are improved. This is not in 
conflict with accommodating also users with a different background, in 
my opinion.

The unique thing about OpenSCAD is its capability to express unambiguous 
models in a programming language, a very powerful capability. I believe 
the challenge is to make the language sufficiently expressive: As simple 
as possible, but no simpler.

> If OpenSCAD is your first experience with computer
> programming, then how many new concepts do you need to learn before
> you can be productive?

See above. If I had no experience in programming, I would use a 
different modelling tool than OpenSCAD, there are many. I disagree if 
the idea is to discard universally accepted programming idioms in order 
to accommodate people with no programming background. Note I explicitly 
do not mean to suggest making OpenSCAD a large language like e.g. C++. 
On the contrary, I think you might be running the risk of creating a 
large language precisely because the most common and most expressive 
idioms are left out.

 > OpenSCAD seems to have a low barrier to entry,
> and we want to keep it this way.

I would challenge anyone to define what "low barrier to entry" really 
means. What I indicated explicitly accommodated current idioms ("If you 
want to express things as it is currently being done, you can, but you 
also have other possibilities.").

If you can't express what you think, or only with difficulty because of 
limitations in the language, the barrier is high, not low.

 > One philosophical principle I've learned from the community is that
 > OpenSCAD is intended to be a purely declarative or 'functional'
 > language, except that it should also be much easier to learn than
 > serious functional languages such as Haskell. This means that there is
 > no state. You can't increment a variable or modify a data structure
 > in-place.

I think an important goal of OpenSCAD is to provide a language giving 
the average programmer an efficient way to express 3d models. Such a 
goal does not, in my opinion, automatically imply that common idioms 
known from other languages should be discarded.

As you say, in OpenSCAD you are not allowed to modify the value of 
variable. As seen from a user point of view, this is not a 
simplification, it is a constraint that makes things harder for the 
user. It is as if you tell a C++ programmer to use ONLY template code, 
where everything must be defined at compile time. Of course, this 
constraint makes life easer for the implementer, no doubt about that, 
but I don't think that is the argument presented.

> Traditional OOP languages are based on the idea of objects with state,
> and there is a lot of additional heavy weight machinery that you need
> to learn before you can be productive.

I do not agree with that, see my previous simple example.

> But we don't want this: we'll
> end up with a language that is easy to use once you have learned
> object oriented programming, but it with a higher barrier to entry for
> beginners.

See above notes on target audience.

> In your first example (class lollipop), you defined a class, you
> defined a constructor inside the class, you declared data members then
> separately assigned them initial values within the constructor, and
> you have an assignment to the special variable 'this'. You used a lot
> of machinery to accomplish something very simple.

Yes, I did use an over-simplified example that could be solved using 
other techniques. However, the idea was to convey the idea of a very 
simple object model that could be used for much more complicated 
examples that would be difficult to express with the current language 

> In your second example (module example_module), you create a mutable
> object and modify its state, in these lines:
>>      table_plate = cube(size=[100,100,5],center=true);
>>      // union the lollipops with the table plate and return it
>>      table_plate.union(lolA);
>>      table_plate.union(lolB);
>>      // be explicit about what the module returns
>>      return table_plate;
> But we want OpenSCAD to be purely declarative, without state mutation semantics.

As noted above, I have come across this statement several times, I am 
fully aware it exists. I just have not seen arguments that have 
convinced me it is consistent with how I perceive OpenSCADs overall goals.

> When I have more time, maybe I'll try and rewrite your code in
> OpenSCAD 2, to demonstrate that the same things can be accomplished in
> a simpler way, without all the heavy machinery of OOP.

I think it would be useful to see alternative code, indeed. It makes it 
easier to get a factual impression of what it is.

I will consider also some alternatives to what we have discussed. I need 
to understand a few more things in OpenSCAD as it currently stands, I am 
still learning here.

I would like to thank you for a thought provoking debate and for the 
work done!

Carsten Arnholm

More information about the Discuss mailing list