[OpenSCAD] eval( ) ???

G. Wade Johnson gwadej at anomaly.org
Sun May 17 17:50:35 EDT 2015


On Sun, 17 May 2015 23:34:21 +0200
Carsten Arnholm <arnholm at arnholm.org> wrote:

> 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.

Hi Carsten,

Sorry to butt in here, but after reading your comments, I think part of
the context you may not have seen is another ongoing topic of discussion
about OpenSCAD.

A really strong argument for the declarative nature of OpenSCAD versus
a more traditional language is the fact that there is no _time_ in the
OpenSCAD output. Almost all programming languages execute over a period
of time, this gives rise to assumptions about mutability and cause and
effect relationships.

OpenSCAD /programs/ (I'll use the term loosely) are not executing. They
are describing a physical shape. The result of the program is static,
there is no real concept of time in the code. If OpenSCAD were designed
as a more traditional language, the programmer would likely make
assumptions based on their understanding of how programs execute in
time. This causes a fairly significant disconnect in the mental model
of how the code works.

The declarative, immutable nature of OpenSCAD code mirrors the mental
model of a description of a static object better (in my opinion).

G. Wade

> > 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 
> features.
> 
> > 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
> 
> _______________________________________________
> OpenSCAD mailing list
> Discuss at lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


-- 
There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies and the
other way is to make it so complicated that there are no obvious
deficiencies. -- C. A. R. Hoare




More information about the Discuss mailing list