OpenSCAD language - replace it with Python3
On 02/12/2020 18:08, Doug Moen wrote:
This is pronounced "i to k by j". This pronounciation has the structure of natural language, and it tells you the meaning of each argument.
What's wrong with 'For j = i to k', or why not have done with it, and go
to apl - code today, spend the next week trying to understand what you
wrote.
Best wishes,
Ray
Michele Denber mdenber@gmx.com wrote:
Of course! When your performance review depends on the number of lines
of code you wrote last month, more is always better.
Although never got paid that much, but 50 or so years ago, it worked out
at £5.00 per line of fortran But then an IBM 1130 with 8k of memory was
£100,000 (but that most likely included an air conditioned room, two
punch card machines, and probably a tame ibm engineer on call.)
I had a tame IBM VP on call for one project, but that was much later, a
Java project
On Wed, 2 Dec 2020, 18:11 Ray West, raywest@raywest.com wrote:
Michele Denber mdenber@gmx.com wrote:
Of course! When your performance review depends on the number of lines
of code you wrote last month, more is always better.
Although never got paid that much, but 50 or so years ago, it worked out
at £5.00 per line of fortran But then an IBM 1130 with 8k of memory was
£100,000 (but that most likely included an air conditioned room, two
punch card machines, and probably a tame ibm engineer on call.)
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Or for( i in j..k){}. JavaScript kotlin etc. Speaking of which kotlin is
interesting, it has a built in mechanism for creating and embedding data
specific languages, search for kotlin DSL
On Thu, Dec 3, 2020, 07:04 Ray West raywest@raywest.com wrote:
On 02/12/2020 18:08, Doug Moen wrote:
This is pronounced "i to k by j". This pronounciation has the structure
of natural language, and it tells you the meaning of each argument.
What's wrong with 'For j = i to k', or why not have done with it, and go
to apl - code today, spend the next week trying to understand what you
wrote.
Best wishes,
Ray
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
If I did that with C code, as long as the people around me are also C
guys, all is well. However, if they are normal people (the implication
is correct - C coders are NOT normal people) then they will soon be
calling those nice men in their clean white coats to come and take me
away hoho haha hehe.
David
On 12/2/20 12:08 PM, Doug Moen wrote:
Troberg wrote:
- As close to natural human language as possible.
There is a good idea here, but it needs to be unpacked.
I've been working on a "next generation OpenSCAD-like language" for a few years now. One requirement is to be friendly to novice programmers. Part of that is the design of the syntax. But how do you design a novice friendly syntax? I'd prefer to base the design on empirical scientific research, rather than my own guesses and intuition. There are a number of researchers working in this area. The research I've found most helpful is by Felienne Hermans, and she calls her research-based approach "pronounceable programming".
When a person is learning their first programming language, mastering the syntax is initially the biggest challenge. This is called "the syntax cliff". One very common strategy used by first time programmers for reading code is to verbalize it, which means pronouncing it out loud, but in your head. This is the underlying cause of a number of problems and stumbling blocks. Punctuation characters that look just like non-semantic "noise" are not pronounced, and then they get left out of the person's internal mental representation of the code, leading to further problems. Homophones (two tokens that are pronounced the same but typed differently) cause problems, especially for non-English speakers.
So, a language syntax is more beginner friendly if there is a more high fidelity way of pronouncing code out loud, so that the spoken version of the code is mentally meaningful, and so that the spoken version can be converted back into syntactically correct code.
This leads to the idea of "pronounceable programming". It doesn't mean you can't use symbols. "2+2" can be pronounced "two plus two" and doesn't cause a problem, for example. People think that Python has a beginner-friendly syntax, but this research shows there are actually some problems. For example, the ":" at the end of some statements (such as if, while, etc) is a pitfall for novice programmers, for reasons relating to pronounceable programming.
So I'm trying to figure out how to apply this research to Curv. I'm not saying I have all the answers, but I'll give one example of syntax design that I think is a success story.
In OpenSCAD, a numeric range is written [i:j:k]. How do you pronounce that? One you have spoken it out loud, how does the pronounciation help you to figure out which number is the beginning of the range, which is the step value, and which is the end of the range? In Curv, the same range is written as
i .. k by j
This is pronounced "i to k by j". This pronounciation has the structure of natural language, and it tells you the meaning of each argument.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
doug.moen wrote
Troberg wrote:
- As close to natural human language as possible.
There is a good idea here, but it needs to be unpacked.
I've been working on a "next generation OpenSCAD-like language" for a few
years now. One requirement is to be friendly to novice programmers. Part
of that is the design of the syntax. But how do you design a novice
friendly syntax? I'd prefer to base the design on empirical scientific
research, rather than my own guesses and intuition. There are a number of
researchers working in this area. The research I've found most helpful is
by Felienne Hermans, and she calls her research-based approach
"pronounceable programming".
When a person is learning their first programming language, mastering the
syntax is initially the biggest challenge. This is called "the syntax
cliff". One very common strategy used by first time programmers for
reading code is to verbalize it, which means pronouncing it out loud, but
in your head. This is the underlying cause of a number of problems and
stumbling blocks. Punctuation characters that look just like non-semantic
"noise" are not pronounced, and then they get left out of the person's
internal mental representation of the code, leading to further problems.
Homophones (two tokens that are pronounced the same but typed differently)
cause problems, especially for non-English speakers.
One of my favourite hate subjects is the ternary ? operator. In a typical
situation, you end up with something like this, and if you nest them, it
quickly gets horrible:
x=y>z?10+xoffset:10-xoffset;
x=y>z?10+$t>0.5t?xoffset:0:10-$t<0.5?xoffset:0;
Sure, it's syntactically clear for the compiler, but it looks like a well
mixed alphabet soup. In this case, the Basic iif (inline if) is clearer
(though it could be even better).
x=iif(y>z,10+xoffset,10-xoffset)
x=iif(y>z,10+iif($t>0.5t,xoffset,0),10-iif($t<0.5t,xoffset,0))
Sure, the iif also becomes a bit messy when nested, but at least you have
editor bracket matching to help.
Likewise, keywords should be what makes sense to the programmer, not the
compiler. For example, C# "abstract" is much less intuitive than the VB.Net
"mustinherit".
One thing I've seen make programmers loose feeling for what makes an
operation "expensive" in CPU time is the modern language tendency to have {
} as structural elements. For example, there is a huge difference in CPU
time for the } ending a for loop and the } ending an if. If you are just
going to execute that code a few times, it doesn't matter, but if you are
going to do it billions of times in a tiny loop, then you need to know the
difference. (Sometimes, I'd like an IDE where you could colorcode each line
depending on how much time the CPU spends executing that line in the last
run...)
Another important thing is that if something has a meaning, it must bee
seen. That's why I dislike Python giving semantic meaning to whitespace.
Also, related to what you say, "strange" characters like three different
kind of brackets, $, @, |, &, ^, ~, #, %, ; and so on does create a mental
hurdle for newbies. I've taught some programming, and this creates a first
impression of "Shit, this looks hard!" among the students, and that creates
an initial hurdle that some never get over. It takes a lot more experience
and knowledge for them to understand, for example, why they use a specific
bracket in a certain situation, to actually grasp the deeper structure of
the syntax, and it takes a long time before they get past the "monkey see,
monkey do" stage of just following examples.
I once had a teacher who said that it would have been much easier for new
users if the \ (or /, depending on OS) in file names was replaced by the
word "contains". So, instead of c:\documents\work\cv.doc would be "c:
contains documents contains work contains cv.doc". Of course that wouldn't
be practical, but it gives an insight into the things newbies stumble on,
which most of us has already forgot we've gone through.
--
Sent from: http://forum.openscad.org/
One of my favourite hate subjects is the ternary ? operator. In a typical
situation, you end up with something like this, and if you nest them, it
quickly gets horrible:
x=y>z?10+xoffset:10-xoffset;
x=y>z?10+$t>0.5t?xoffset:0:10-$t<0.5?xoffset:0;
Sure, it's syntactically clear for the compiler, but it looks like a well
mixed alphabet soup.
Too lazy to format it like an if/else?
function s2d(h="0",base=10,i=-1) =
// converts a string of hexa/or/decimal digits into a decimal
// integers only
(i == -1)
? s2d(h,base,i=len(h)-1)
: (i == 0)
? _chkBase(_d2n(h[0]),base)
: _chkBase(_d2n(h[i]),base) + base*s2d(h,base,i-1);
--
This email has been checked for viruses by AVG.
https://www.avg.com
MichaelAtOz' wrote
One of my favourite hate subjects is the ternary ? operator. In a typical
situation, you end up with something like this, and if you nest them, it
quickly gets horrible:
x=y>z?10+xoffset:10-xoffset;
x=y>z?10+$t>0.5t?xoffset:0:10-$t<0.5?xoffset:0;
Sure, it's syntactically clear for the compiler, but it looks like a well
mixed alphabet soup.
Too lazy to format it like an if/else?
Not at all, that's what I do if it's a non-trivial case (I'm pretty much a
purist when it comes to readable code, I want code which I'll understand
just as good when I look at it ten years later)..., but for a newbie, that's
above their head, they are struggling to make it work, not to make it look
nice.
--
Sent from: http://forum.openscad.org/
but for a newbie, that's
above their head, they are struggling to make it work, not to make it look
nice.
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Conditional_and_Iterator_Functions#Formatting_co
mplex_usage
Anyone can clarify things in the wiki BTW.
--
This email has been checked for viruses by AVG.
https://www.avg.com
Completely disagree with this, I think people are assigning too much
weight to the term "language".
Computer languages are very different to human ones, they have to be
unambiguous, human languages are very definition of ambiguity. Computer
languages are formalized codifications of largly mathmatical instructions,
and math formelea are not designed to be conversational in the human sense.
On Thu, Dec 3, 2020, 02:09 Doug Moen doug@moens.org wrote:
Troberg wrote:
- As close to natural human language as possible.
There is a good idea here, but it needs to be unpacked.
I've been working on a "next generation OpenSCAD-like language" for a few
years now. One requirement is to be friendly to novice programmers. Part of
that is the design of the syntax. But how do you design a novice friendly
syntax? I'd prefer to base the design on empirical scientific research,
rather than my own guesses and intuition. There are a number of researchers
working in this area. The research I've found most helpful is by Felienne
Hermans, and she calls her research-based approach "pronounceable
programming".
When a person is learning their first programming language, mastering the
syntax is initially the biggest challenge. This is called "the syntax
cliff". One very common strategy used by first time programmers for reading
code is to verbalize it, which means pronouncing it out loud, but in your
head. This is the underlying cause of a number of problems and stumbling
blocks. Punctuation characters that look just like non-semantic "noise" are
not pronounced, and then they get left out of the person's internal mental
representation of the code, leading to further problems. Homophones (two
tokens that are pronounced the same but typed differently) cause problems,
especially for non-English speakers.
So, a language syntax is more beginner friendly if there is a more high
fidelity way of pronouncing code out loud, so that the spoken version of
the code is mentally meaningful, and so that the spoken version can be
converted back into syntactically correct code.
This leads to the idea of "pronounceable programming". It doesn't mean you
can't use symbols. "2+2" can be pronounced "two plus two" and doesn't cause
a problem, for example. People think that Python has a beginner-friendly
syntax, but this research shows there are actually some problems. For
example, the ":" at the end of some statements (such as if, while, etc) is
a pitfall for novice programmers, for reasons relating to pronounceable
programming.
So I'm trying to figure out how to apply this research to Curv. I'm not
saying I have all the answers, but I'll give one example of syntax design
that I think is a success story.
In OpenSCAD, a numeric range is written [i:j:k]. How do you pronounce
that? One you have spoken it out loud, how does the pronounciation help you
to figure out which number is the beginning of the range, which is the step
value, and which is the end of the range? In Curv, the same range is
written as
i .. k by j
This is pronounced "i to k by j". This pronounciation has the structure of
natural language, and it tells you the meaning of each argument.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org