[OpenSCAD] feedback on "C-style for"
oz.at.michael at gmail.com
Wed Jun 1 21:51:31 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.
I disagree here.
> 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 issue.
Worth considering. Really need to solve the overriding of 'identifiers'
(currently called variables) set in an include<> tho. Also fix command line
> 2. introduce genuine variables (==mutable constants), as pointed out in
Still not for Frankenstein... also IMO "parallel, pattern matching
assignment statement" is just another head bolted on. I'm sure we all have
"gee, it would be nice to" have's, then suddenly the language explodes like
a multi-tool with everything open...
> 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.
Yes, keep OpenSCAD easy for beginners; while I'm an experienced coder and
can read most languages, I found the transition to OpenSCAD very easy and
hope it stays relatively uncomplicated for future newcomers.
> 4. The for loop should take the form
> for i:=1 to <
>> step <
> 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) variables.
> 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.
Admin - PM me if you need anything, or if I've done something stupid...
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!
View this message in context: http://forum.openscad.org/feedback-on-C-style-for-tp17512p17517.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
More information about the Discuss