Larry, WASH YOUR MOUTH OUT WITH SOAP!!!

 David

On 12/1/20 1:41 PM, lar3ry@sasktel.net wrote:

Lets-eat-grandma

--
This email has been checked for viruses by AVG.
https://www.avg.com

The problem with this idea is that the used file can only see constants that are defined or included inside itself.  And if you do that, the redefinition bug shows up.

• Revar

Heh! What, you wouldn't want to write this?

SUBTRACT CYLINDER from CUBE giving HOLE

:-)

On 1 Dec 2020 at 16:47, David wrote:

Don't forget the pages of boilerplate code surrounding it...

On Wed, 2 Dec 2020, 00:09 , lar3ry@sasktel.net wrote:

On 12-02-2020 4:44 AM, A. Craig West wrote:

Of course!  When your performance review depends on the number of lines
of code you wrote last month, more is always better.

            - Michele

Michele Denber mdenber@gmx.com wrote:

Best ever response on that sort of thing:
https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt
William

Troberg wrote:

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.

On 2020-12-02 19:08, Doug Moen wrote:

In English perhaps, I don't think it applies to other languages,
certainly not no mine. By I don't buy the idea that pronounciation is a
goal, or that one should develop a new programming language to do
Constructive Solid Geometry.

Carsten Arnholm