[OpenSCAD] feedback on "C-style for"

wolf wv99999 at gmail.com
Wed Jun 1 20:33:37 EDT 2016

"Bei dem ist 'ne Schraube locker" (literally "He has a loose screw", more
idiomatic "NUTS") and "Daar lê 'n slang in die gras" (literally" "There
hides a snake in the grass", more idiomatic "that's very buggy code") were
my first impressions when I read doug.moen's proposal.

But let me quote someone else: <github.com/doug-moen/openscad2>

"OpenSCAD2 is a backward compatible redesign of the OpenSCAD language. The
goals are:

    to make OpenSCAD easier to use;
    to make OpenSCAD more expressive and powerful, not by adding complexity
and piling on features, but by making the core language simpler and more
uniform, and by removing restrictions on how language elements can be
composed together to create larger components."

I am not going to dig up here what OpenSCAD developers have written on this
forum about "C-style programming". Simply put, for non-C programmers,
C-style programming is very difficult to read. "barely readable" it was
called in the tutorial I used to learn OpenSCAD. Rather consider how many
new users have problems with conditionals, or with polygon(), or are
actually using list comprehension. 
On the latter, from what I can gather from this forum, only its creator
actually uses it, for everyone else it's too complicated. Or why would we
hear complaints about long render times? Look at the code samples provided,
and it soon becomes obvious that long render times arise from people
stuffing the renderer with work that is not truly needed for the creation of
the shape they are after. If they had but understood list comprehension, and
how lists can eliminate unused corners and faces before CGAL gets hold of
them, they could have saved themselves a lot of frustration . . .

If you live in a country where only a single language is spoken, your
thinking gets limited by the capabilities of that language. That's why
translating the initial quotes is so unsatisfactory and why they inevitably
loose their wittiness in translation. As doug.moen has pointed out in
another thread
and https://github.com/openscad/openscad/wiki/Mutable-Variables), functional
programming is actually a dead end road, imperative-type programming had to
be introduced to achieve universality.

And that's why I object to "C-style for". Proper coding style should be
modelled as close to English language semantics as is possible. Conciseness
should not be an objective - easy learning should. And that means 
1. rewrite all manuals and replace the word "variable" with "constant". Have
that courage, and admit to yourself that when values are assigned at compile
time they become constants - calling them variables is fudging/evading the
2. introduce genuine variables (==mutable constants), as pointed out in
3. forget about "C-style programming" as its use implies the OpenSCAD user
is already familiar with C, before he/she can consider learning OpenSCAD.
"C-style" constructs are admittedly easy for C-programmers, but mostly are
"barely readable" for people not familiar with C.
4. The for loop should take the form
for i:=1 to </endval/> step </stepval/>
because that is English, and thus accessible to everyone capable of reading
the OpenSCAD manual.

Consider that functional languages came about as a response to the ease with
which the (mis)use of pointers in C can generate buggy code. List
Comprehension (array or *struct in C) is just one way to get around the
potential trouble lurking here. Resist the objections raised by functional
language zealots, and keep the OpenSCAD language simple and readable,
without requiring a background in C. Introduce genuine (==mutable)

OpenSCAD2 is the way forward, not "C-style". Treat a function as a pointer
to a value, or a list of values. Whether these values were obtained at
compile time or at run time is important only the the developer, it is
immaterial to the user.

View this message in context: http://forum.openscad.org/feedback-on-C-style-for-tp17512p17516.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

More information about the Discuss mailing list