[OpenSCAD] feedback on "C-style for"

Jamie_K vector76 at gmail.com
Thu Jun 2 00:04:34 EDT 2016

When it comes to mutable variables, it comes down to the deep question of
pure functional or not.  I disagree that pure functional is a dead-end road,
but the choice is a fork in the road where you need to decisively pick one
or the other.

If the answer is pure functional, then do{} introduces internal
inconsistency, and the "proper" (meaning internally coherent) way to support
mutation is via first-class functions, closures, and monads.  If OpenSCAD
does grow in this direction, then in a functional future looking /back/ at
do{}, it's going to be even more clumsy to retain coherence and work around
all the implications of backward compatibility and funky interactions.

I won't argue about whether functional or imperative is "better" or more
elegant, but I will argue that pure functional thinking is much more
/specialized/ than sequential style thinking.  I have heard it said that
functional programming is more like mathematics and less like programming,
and I would agree.  Yet I still believe that this mathematical style of
thinking is less common and less accessible to non-specialists, beginner or
not!  Anybody can bang out a bit of procedural code, but not everyone can
wrap their heads around closures, continuations, tail-recursion, or monads.

If the choice is to loosen the pure-functional requirement and forgo strict
referential transparency then I would /still/ suggest that do{} blocks are
not as good as if mutation were adopted as part of a more coherent
imperative language.

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

More information about the Discuss mailing list