NH
nop head
Thu, Dec 3, 2020 6:52 PM
Yes I have never needed to verbalise a programming language because I only
type it to computers. When I read computer code I don't verbalise it in my
mind. When programming I think in the language I am using, not English.
Sometimes I dream in OpenSCAD!
On Thu, 3 Dec 2020 at 18:42, Tim Hawkins tim.thawkins@gmail.com wrote:
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:
- 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
Yes I have never needed to verbalise a programming language because I only
type it to computers. When I read computer code I don't verbalise it in my
mind. When programming I think in the language I am using, not English.
Sometimes I dream in OpenSCAD!
On Thu, 3 Dec 2020 at 18:42, Tim Hawkins <tim.thawkins@gmail.com> wrote:
> 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
>>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
ER
Ezra Reynolds
Thu, Dec 3, 2020 7:12 PM
As a junior in college, I had to endure a semester of a computer science professor straight up reading (Java or C++) code. Every single punctuation mark was verbalized. Not just telling the logic what was happening, but reading every parentheses, every closing brace, every semicolon.
On Dec 3, 2020, at 1:53 PM, nop head nop.head@gmail.com wrote:
Yes I have never needed to verbalise a programming language because I only type it to computers. When I read computer code I don't verbalise it in my mind. When programming I think in the language I am using, not English.
Sometimes I dream in OpenSCAD!
On Thu, 3 Dec 2020 at 18:42, Tim Hawkins tim.thawkins@gmail.com wrote:
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
As a junior in college, I had to endure a semester of a computer science professor straight up reading (Java or C++) code. Every single punctuation mark was verbalized. Not just telling the logic what was happening, but reading every parentheses, every closing brace, every semicolon.
> On Dec 3, 2020, at 1:53 PM, nop head <nop.head@gmail.com> wrote:
>
>
> Yes I have never needed to verbalise a programming language because I only type it to computers. When I read computer code I don't verbalise it in my mind. When programming I think in the language I am using, not English.
>
> Sometimes I dream in OpenSCAD!
>
>> On Thu, 3 Dec 2020 at 18:42, Tim Hawkins <tim.thawkins@gmail.com> wrote:
>> 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
>> _______________________________________________
>> OpenSCAD mailing list
>> Discuss@lists.openscad.org
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
DM
Doug Moen
Thu, Dec 3, 2020 7:13 PM
On Thu, Dec 3, 2020, at 2:07 AM, Troberg wrote:
One of my favourite hate subjects is the ternary ? operator.
There is a long heritage of functional languages where the ternary operator 'a ? b : c' is written like this:
if a then b else c
In OpenSCAD, there are 3 different syntaxes for conditional expressions, depending on the context.
If you are working with shapes, then a conditional shape looks like this:
if (rounded)
sphere(10);
else
cube(10);
(Note presence of semicolons.)
If you are working with numbers, then a conditional number looks like this:
big ? 10 : 5
Unless you are inside a list constructor, in which case you have two different choices of syntax.
The following two expressions are equivalent:
[big ? 10 : 5]
[if (big) 10 else 5]
(Note absence of semicolons in the if-else expression.)
There's no good design reason to have 3 different conditional syntaxes, it's just history, following the initial decision to mimic C syntax.
Since you can write 'if (big) 10 else 5' inside a list, it wouldn't be a big stretch to allow this syntax outside a list as well. This would bring OpenSCAD closer to traditional functional languages, and provide more consistency for writing conditional expressions.
In Curv, there is only one syntax. You write
if (rounded) sphere(10) else cube(10)
if (big) 10 else 5
On Thu, Dec 3, 2020, at 2:07 AM, Troberg wrote:
> One of my favourite hate subjects is the ternary ? operator.
There is a long heritage of functional languages where the ternary operator 'a ? b : c' is written like this:
if a then b else c
In OpenSCAD, there are 3 different syntaxes for conditional expressions, depending on the context.
If you are working with shapes, then a conditional shape looks like this:
if (rounded)
sphere(10);
else
cube(10);
(Note presence of semicolons.)
If you are working with numbers, then a conditional number looks like this:
big ? 10 : 5
Unless you are inside a list constructor, in which case you have two different choices of syntax.
The following two expressions are equivalent:
[big ? 10 : 5]
[if (big) 10 else 5]
(Note absence of semicolons in the if-else expression.)
There's no good design reason to have 3 different conditional syntaxes, it's just history, following the initial decision to mimic C syntax.
Since you can write 'if (big) 10 else 5' inside a list, it wouldn't be a big stretch to allow this syntax outside a list as well. This would bring OpenSCAD closer to traditional functional languages, and provide more consistency for writing conditional expressions.
In Curv, there is only one syntax. You write
if (rounded) sphere(10) else cube(10)
if (big) 10 else 5
TH
Tim Hawkins
Thu, Dec 3, 2020 8:51 PM
Sometimes I dream in OpenSCAD
You need to seek help or put a lock on your computer :-)
On Fri, Dec 4, 2020, 02:53 nop head nop.head@gmail.com wrote:
Yes I have never needed to verbalise a programming language because I only
type it to computers. When I read computer code I don't verbalise it in my
mind. When programming I think in the language I am using, not English.
Sometimes I dream in OpenSCAD!
On Thu, 3 Dec 2020 at 18:42, Tim Hawkins tim.thawkins@gmail.com wrote:
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:
- 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
>> Sometimes I dream in OpenSCAD
You need to seek help or put a lock on your computer :-)
On Fri, Dec 4, 2020, 02:53 nop head <nop.head@gmail.com> wrote:
> Yes I have never needed to verbalise a programming language because I only
> type it to computers. When I read computer code I don't verbalise it in my
> mind. When programming I think in the language I am using, not English.
>
> Sometimes I dream in OpenSCAD!
>
> On Thu, 3 Dec 2020 at 18:42, Tim Hawkins <tim.thawkins@gmail.com> wrote:
>
>> 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
>>>
>> _______________________________________________
>> OpenSCAD mailing list
>> Discuss@lists.openscad.org
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
L
lar3ry@sasktel.net
Fri, Dec 4, 2020 12:32 AM
On 2 Dec 2020 at 23:03, Ray West wrote:
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.
Reminds me of the old "How to shoot yourself in the foot in many
languages."
APL: You hear a bang. There's a hole in your foot. But you don't know
enough about linear algebra to understand how it got there.
On 2 Dec 2020 at 23:03, Ray West wrote:
> 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.
Reminds me of the old "How to shoot yourself in the foot in many
languages."
APL: You hear a bang. There's a hole in your foot. But you don't know
enough about linear algebra to understand how it got there.
JB
Jordan Brown
Fri, Dec 4, 2020 2:27 AM
Reminds me of the old "How to shoot yourself in the foot in many
languages."
APL: You hear a bang. There's a hole in your foot. But you don't know
enough about linear algebra to understand how it got there.
OpenSCAD: You point the gun at your foot, and shoot twice. Since you
let the two bullet holes just barely touch, you get a CGAL error.
On 12/3/2020 4:32 PM, lar3ry@sasktel.net wrote:
> Reminds me of the old "How to shoot yourself in the foot in many
> languages."
>
> APL: You hear a bang. There's a hole in your foot. But you don't know
> enough about linear algebra to understand how it got there.
>
OpenSCAD: You point the gun at your foot, and shoot twice. Since you
let the two bullet holes just barely touch, you get a CGAL error.
JB
Jordan Brown
Fri, Dec 4, 2020 2:36 AM
On 12/3/2020 6:27 PM, Jordan Brown wrote:
OpenSCAD: You point the gun at your foot, and shoot twice. Since you
let the two bullet holes just barely touch, you get a CGAL error.
Having actually tried it and refreshed my memory on the behavior:
OpenSCAD: You point the gun at your foot, and shoot twice. Since you
let the two bullet holes just barely touch, you get a warning that your
foot may not be a valid 2-manifold and may need repair!
On 12/3/2020 6:27 PM, Jordan Brown wrote:
> OpenSCAD: You point the gun at your foot, and shoot twice. Since you
> let the two bullet holes just barely touch, you get a CGAL error.
Having actually tried it and refreshed my memory on the behavior:
OpenSCAD: You point the gun at your foot, and shoot twice. Since you
let the two bullet holes just barely touch, you get a warning that your
foot may not be a valid 2-manifold and may need repair!
RW
Ray West
Fri, Dec 4, 2020 1:54 PM
On 03/12/2020 18:42, Tim Hawkins wrote:
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.
So, is there a problem with encoding it as 'i to k by j' ? and, can the
j be i and k, do your list indexes start at 0?
This could be a rich source of detailed argument, similar to calculating
how many angels can sit on a pin head, etc.
On 03/12/2020 18:42, Tim Hawkins wrote:
> 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.
So, is there a problem with encoding it as 'i to k by j' ? and, can the
j be i and k, do your list indexes start at 0?
This could be a rich source of detailed argument, similar to calculating
how many angels can sit on a pin head, etc.
G
Gibbon
Mon, Dec 7, 2020 6:47 PM
Yes, please, your offer of a PyCharm / SolidPython setup tutorial would be
appreciated.
--
Sent from: http://forum.openscad.org/
Yes, please, your offer of a PyCharm / SolidPython setup tutorial would be
appreciated.
--
Sent from: http://forum.openscad.org/
