On 11/11/2019 17:10:40, C. Titus Brown wrote:
Hi folks,
moderator here. I’d (strongly) suggest no further replies, unless there’s
something Python specific to discuss. I’ll put the list into emergency
moderation for a bit.
thanks,
—titus
Agreed.
The OP used APL for a number of years, and f
On 06/11/2019 17:05:21, Martin Euredjian via Python-ideas wrote:
One has to use APL for real work and for at least a year or two in
order for your brain to make the mental switch necessary to understand
it. Just messing with it casually isn't good enough. Lots of
inquisitive people have m
Yeah. Maybe I should replace regex ' *:=' rather than just ':='. That's
easy enough with the plugin
On Tue, Nov 12, 2019, 12:12 PM Mike Miller
wrote:
>
> On 2019-11-11 16:13, David Mertz wrote:
> > I implemented this discussed arrow operator in vim with conceal plugin.
> This is
> > an example g
On 2019-11-11 16:13, David Mertz wrote:
I implemented this discussed arrow operator in vim with conceal plugin. This is
an example given in PEP 572. It looks perfectly fine. It also does not require
ANY change to Python-the-language. It just means that I can type ':' followed
by '=' to get
Hi,
> I mean, as shown in this example and a previous one I posted a screenshot
> of, I think it's cute and geeky to use a few math symbols in the same way
> in my editor. I've been doing that for a few years, and it never got
> beyond "slightly cute."
>
I would second this. I find it actually
On 12/11/19 4:10 am, Random832 wrote:
well *of course* the goal was not to slow down
actual production of text, but this does not imply the method by which
"speeding up by preventing jams" was to be achieved was not by slowing down
the physical process of pressing keys.
That wasn't the method,
On Mon, Nov 11, 2019 at 4:16 PM David Mertz wrote:
> I really, really don't get how it's supposed to "transform my thinking
> about coding" to have a slightly different glyph on screen.
>
I agree here. This thread got really caught up in issues like "how do I
type that?", but I don't think that
I implemented this discussed arrow operator in vim with conceal plugin.
This is an example given in PEP 572. It looks perfectly fine. It also
does not require ANY change to Python-the-language. It just means that I
can type ':' followed by '=' to get that, rather than type 'Alt+Shift',
'2', '1',
On 2019-11-10 12:50, Martin Euredjian via Python-ideas wrote:
I have found that trying to explain the value of true notation to people who
lack the experience and training is always a losing proposition. I'm already
regretting having started this thread, simply because I know how this works.
Hi folks,
moderator here. I’d (strongly) suggest no further replies, unless there’s
something Python specific to discuss. I’ll put the list into emergency
moderation for a bit.
thanks,
—titus
> On Nov 11, 2019, at 9:05 AM, Ricky Teachey wrote:
>
>
> I have found that trying to explain the
> I have found that trying to explain the value of true notation to people
> who lack the experience and training is always a losing proposition. I'm
> already regretting having started this thread, simply because I know how
> this works. Frankly, it's almost like trying to engage with a religiou
> These thousands of words of repeating claims with weird non sequitur
> digressions seem to amount to
I am done with this thread. It has received nothing but close-minded
hostility. Which is fine. I understand. That's the way the world works.
I've seen this kind of thing happen in many
> On 11 Nov 2019, at 17:05, Richard Damon wrote:
>
> On 11/11/19 10:10 AM, Random832 wrote:
>>> On Mon, Nov 11, 2019, at 03:22, Greg Ewing wrote:
>>> On 11/11/19, 12:41 PM, Richard Damon wrote:
it was DESIGNED to be inefficient (that was one of its design goals, to
slow typesetters d
On 11/11/19 10:10 AM, Random832 wrote:
> On Mon, Nov 11, 2019, at 03:22, Greg Ewing wrote:
>> On 11/11/19, 12:41 PM, Richard Damon wrote:
>>> it was DESIGNED to be inefficient (that was one of its design goals, to
>>> slow typesetters down to be slower than the machine they were working
>>> on).
>>
> On 11 Nov 2019, at 15:26, Rhodri James wrote:
>
> On 10/11/2019 20:50, Martin Euredjian via Python-ideas wrote:
>> It does, it's an extension of the reality that, after so many
>> decades, we are still typing words on a text editor. In other words,
>> my comment isn't so much about the mech
On Mon, Nov 11, 2019, at 03:22, Greg Ewing wrote:
> On 11/11/19, 12:41 PM, Richard Damon wrote:
> > it was DESIGNED to be inefficient (that was one of its design goals, to
> > slow typesetters down to be slower than the machine they were working
> > on).
>
> This is most likely a myth, see https:/
On 10/11/2019 20:50, Martin Euredjian via Python-ideas wrote:
It does, it's an extension of the reality that, after so many
decades, we are still typing words on a text editor. In other words,
my comment isn't so much about the mechanics and editors that are
available as much as the fact that th
On 11/11/19, 12:41 PM, Richard Damon wrote:
it was DESIGNED to be inefficient (that was one of its design goals, to
slow typesetters down to be slower than the machine they were working
on).
This is most likely a myth, see https://en.wikipedia.org/wiki/QWERTY
--
Greg
__
These thousands of words of repeating claims with weird non sequitur
digressions seem to amount to "I wish Python used hard-to-enter unicode
characters instead of words on normal keyboards" as far as I can tell
because human brains, apparently, cannot make sense of the two character
symbol `:=`
On Nov 10, 2019, at 20:50, Martin Euredjian via Python-ideas
wrote:
>
> > This has nothing to do with representation or input via text
>
> It does, it's an extension of the reality that, after so many decades, we are
> still typing words on a text editor.
And how else would you want to enter
Martin,
I think one thing you need to realize that just being a better idea
doesn't make it easy to get implemented. There is a LOT of inertia in
infrastructure, and overcoming it can be nearly impossible.
A great example of that is look at your typical keyboard, if you were to
create a new keybo
> This has nothing to do with representation or input via text
It does, it's an extension of the reality that, after so many decades, we are
still typing words on a text editor. In other words, my comment isn't so much
about the mechanics and editors that are available as much as the fact that
On Nov 10, 2019, at 08:23, Stephen J. Turnbull
wrote:
>
> Martin Euredjian via Python-ideas writes:
>
>> Another interesting example is had in some of my work with real
>> time embedded systems. There are plenty of cases where you are
>> doing things that are very tightly related to, for examp
On Nov 10, 2019, at 08:00, Stephen J. Turnbull
wrote:
>
> Andrew Barnert via Python-ideas writes:
>>> On Nov 7, 2019, at 19:59, Chris Angelico wrote:
>>>
>>> And I do the same with the operators that you disparagingly call
>>> "ASCII soup". I touch type them. What's the difference, other than
Martin Euredjian via Python-ideas writes:
> Another interesting example is had in some of my work with real
> time embedded systems. There are plenty of cases where you are
> doing things that are very tightly related to, for example, signals
> coming into the processor though a pin; by this
Andrew Barnert via Python-ideas writes:
> On Nov 7, 2019, at 19:59, Chris Angelico wrote:
> >
> > And I do the same with the operators that you disparagingly call
> > "ASCII soup". I touch type them. What's the difference, other than
> > that I can transfer my knowledge of typing English?
>
On Fri, Nov 8, 2019 at 11:16 AM Andrew Barnert via Python-ideas
wrote:
>
> On Nov 7, 2019, at 19:59, Chris Angelico wrote:
> >
> > And I do the same with the operators that you disparagingly call
> > "ASCII soup". I touch type them. What's the difference, other than
> > that I can transfer my kno
On Nov 7, 2019, at 19:59, Chris Angelico wrote:
>
> And I do the same with the operators that you disparagingly call
> "ASCII soup". I touch type them. What's the difference, other than
> that I can transfer my knowledge of typing English?
Well, there’s also the fact that you can touch type them
Abe Dillon wrote:
I don't disagree that infix notation is more readable because humans
have trouble balancing brackets visually.
I don't think it's just about brackets, it's more about
keeping related things together. An expression such as
b**2 - 4*a*c
can be written unambiguously without
On Nov 7, 2019, at 22:35, MRAB wrote:
>>
> There was a version of APL on the Sinclair QL, which, IIRC, replaced the
> symbols with keywords. I don't know how well it did.
The OP started the thread complaining about J, which is a much more systematic
ASCIIfication of APL carefully designed by h
On 2019-11-07 20:30, Paul Moore wrote:
On Thu, 7 Nov 2019 at 18:59, Chris Angelico wrote:
On Fri, Nov 8, 2019 at 5:40 AM Martin Euredjian via Python-ideas
wrote:
>
> > Was your use of APL on a machine with a dedicated APL keyboard?
>
> I've done both. In the early '80's it was not uncommon t
On Thu, 7 Nov 2019 at 18:59, Chris Angelico wrote:
>
> On Fri, Nov 8, 2019 at 5:40 AM Martin Euredjian via Python-ideas
> wrote:
> >
> > > Was your use of APL on a machine with a dedicated APL keyboard?
> >
> > I've done both. In the early '80's it was not uncommon to find terminals
> > with AP
>
> > Why not use a more consistent notation like add(x, y) instead of x +
> > y when we know addition is a function and all other functions (usually)
> > follow the f(x, y) notation?
> > Because math is old.
> No, it's because infix notation is *more readable* than function
> notation when formula
On Fri, Nov 8, 2019 at 5:40 AM Martin Euredjian via Python-ideas
wrote:
>
> > Was your use of APL on a machine with a dedicated APL keyboard?
>
> I've done both. In the early '80's it was not uncommon to find terminals
> with APL keyboards. IBM, DEC, Tektronix and other made them. Once the IBM
> Was your use of APL on a machine with a dedicated APL keyboard?
I've done both. In the early '80's it was not uncommon to find terminals with
APL keyboards. IBM, DEC, Tektronix and other made them. Once the IBM PC era
took hold most of APL was done with either a card you'd place in front of
On Thu, 7 Nov 2019 at 00:16, Martin Euredjian via Python-ideas
wrote:
> Sorry, notation is far more powerful. As I said in one of my other notes,
> people who have not had the unique experience of using something like APL for
> non-trivial development work simply don't get it.
Was your use of
Abe Dillon wrote:
Why not use a more consistent notation like add(x, y) instead of x +
y when we know addition is a function and all other functions (usually)
follow the f(x, y) notation?
Because math is old.
No, it's because infix notation is *more readable* than function
notation when formu
Mike Miller wrote:
There is:
U+2B32 ⬲ LEFT ARROW WITH CIRCLED PLUS
But there would need to be more.
At this point you're creating a mini-language by combining symbols,
which the OP seems to be against, since he describes things like
":=" and "<-" condescendingly as "ascii soup".
-
>
> In that context something like the Conway Game of Life in APL demo should
> inspire an interested party in exploring further. None of the tools he
> uses in the demo are difficult to comprehend, particularly if you have a
> background in basic Linear Algebra (another foundational element of AP
On Thu, Nov 7, 2019 at 12:35 PM Martin Euredjian via Python-ideas
wrote:
> >> Another example of ASCII soup is regex.
> > That's interesting, I feel the same way. I can read most code pretty
> > quickly, but as soon as I hit a regex it takes me 50x as long to read
>
> That's it! You got it! The
> This distinction between notation and soup seems pretty subjective.
Yes and no. Math looks like hieroglyphics to most people. We are talking
about professional programmers here. In that context something like the Conway
Game of Life in APL demo should inspire an interested party in explorin
On Nov 7, 2019, at 01:04, Martin Euredjian via Python-ideas
wrote:
>
> >> No professional thinks that "a = some_object" results in a bucket being
> >> filled with whatever the object might contain.
> > That's exactly how variables work in many common languages like C
>
> Nope, not true. Byte
On Thu, Nov 7, 2019 at 11:15 AM Martin Euredjian via Python-ideas
wrote:
> Anyhow, I'll repeat, I am nobody and I am certainly not going to change the
> Python world. Sleep well knowing this is just another random moron saying
> something he probably should not have said.
>
You keep saying tha
>
> Nope, not true.
Yes indeed. It is true.
Bytes, words, integers and that's about it.
All the primary data types and structs and enums and typedefs. That leaves
pointers, arrays, and... function pointers if you don't count those as
pointers. All of which misses the point completely.
In C, y
>
> > The fact that I can enter Python code as plain text is even more useful
> than music and math.
> Sure, because you speak English. Go talk to a kid who has to learn this
> in, I don't know, Egypt or China.
The same process that made mathematical notation standard across the world
is happeni
On 2019-11-06 12:05 p.m., Martin Euredjian via Python-ideas wrote:
Typing these symbols isn't a problem at all. For example, in
NARS2000, a free APL interpreter I use, the assignment operator "←" is
entered simply with "Alt + [". It takes seconds to internalize this
and never think about it
> Really? Because I’ve been using ABC notation for music for decades
Try writing an orchestral suite in ASCII and see how well it goes. C'mon. I
know people use tablature and similar ideas. Sure. So what?
> The fact that I can enter Python code as plain text is even more useful than
> music
>
> No, using "<--" is going in the wrong direction. We want notation, not
> ASCII soup.
This distinction between notation and soup seems pretty subjective. What is
the difference between soup and notation? In my mind it has a lot to do
with familiarity. I watched that video about programming Con
On Nov 6, 2019, at 21:53, Martin Euredjian via Python-ideas
wrote:
>
> I've had this kind of a conversation with many people in the 30+ years since
> I learned APL and 20+ years since I stopped using it professionally. It has
> been my experience that people who have not had the experience ra
>> No professional thinks that "a = some_object" results in a bucket being
>>filled with whatever the object might contain. > That's exactly how
>>variables work in many common languages like C
Nope, not true. Bytes, words, integers and that's about it. Anything else is
a pointer to a relev
On Nov 6, 2019, at 19:52, Mike Miller wrote:
>
>> On 2019-11-06 05:40, Andrew Barnert via Python-ideas wrote:
>> While we’re at it, when you replace both = and := with an arrow, what do you
>> do with += and the other augmented assignments? I can’t think of a
>> single-character symbol that vis
On Thu, Nov 7, 2019 at 8:47 AM Greg Ewing wrote:
>
> Andrew Barnert via Python-ideas wrote:
> > On Nov 6, 2019, at 08:59, Chris Angelico wrote:
> >
> >> No, because "x <-- y" is already legal syntax
> >
> > You could handle that by making the grammar more complicated.
>
> Or just have the tokenis
>
> Question: Where did APL's "←" operator come from?
>
Doesn't matter. If your notation can't stand on its own without a history
lesson, then it's not great.
> A number of APL's elements came from a notation developed to describe the
> operation of IBM processors back in the 1960's. In many w
Andrew Barnert via Python-ideas wrote:
On Nov 6, 2019, at 08:59, Chris Angelico wrote:
No, because "x <-- y" is already legal syntax
You could handle that by making the grammar more complicated.
Or just have the tokeniser treat "<--" as a single token, the
same way that it treats "<=" as a
On Thu, Nov 7, 2019 at 7:21 AM Abe Dillon wrote:
>> None of your objections ring true. A simple example is had from
>> mathematics. The integral symbol conveys and represents a concept. Once
>> the practitioner is introduced to the definition of that symbol, what it
>> means, he or she uses
> I don't think you understood the point about APL's arrow assignment operator
>being counterintuitive in Python.
I understood this just fine. I happen to think your argument in this regard is
neither sound nor valid.
Question: Where did APL's "←" operator come from?
A number of APL's elem
>
> I used APL professionally for about ten years.
Yes, you've stated that already.
None of your objections ring true. A simple example is had from
> mathematics. The integral symbol conveys and represents a concept. Once
> the practitioner is introduced to the definition of that symbol, what
On Thu, Nov 7, 2019 at 4:05 AM Martin Euredjian via Python-ideas
wrote:
> I used APL professionally for about ten years. None of your objections ring
> true. A simple example is had from mathematics. The integral symbol conveys
> and represents a concept. Once the practitioner is introduced
Unfortunately, my device dors not display LEFT ARROW WITH CIRCLED PLUS.
Nor, obviously, write I have any way to enter it easily.
On Wed, Nov 6, 2019, 2:05 PM Mike Miller wrote:
>
> On 2019-11-06 05:40, Andrew Barnert via Python-ideas wrote:
> > While we’re at it, when you replace both = and := w
On 2019-11-06 05:40, Andrew Barnert via Python-ideas wrote:
While we’re at it, when you replace both = and := with an arrow, what do you do
with += and the other augmented assignments? I can’t think of a
single-character symbol that visually represents that meaning. If you leave it
as + follo
It's too late for this one, but I'd be open to allowing Unicode operators. It
is always poo-poo'd here but there are numerous input solutions:
- I enabled AltGr and a Compose key on my US keyboard, I can type symbols like
©, —, …, ø, ə, with two or three keystrokes, diacritics too: café.
I
Thanks for your feedback. A few comments:
> I do not consider these two things conceptually equivalent. In Python the
>identifier ('a' in this case) is just label to the value
I used APL professionally for about ten years. None of your objections ring
true. A simple example is had from mathem
On Nov 6, 2019, at 08:59, Chris Angelico wrote:
>
> No, because "x <-- y" is already legal syntax (it applies unary minus
> to y twice, then checks whether x is less than the result).
You could handle that by making the grammar more complicated. I don’t think
it’s a good idea at all, but I thin
On Nov 6, 2019, at 01:46, martin_05--- via Python-ideas
wrote:
>
>
> Still, the idea of two assignment operators just didn't sit well with me.
> That's when I realized I had seen this kind of a problem nearly thirty years
> ago, with the introduction of "J". I won't get into the details unles
On Wed, Nov 6, 2019 at 6:57 PM Richard Musil wrote:
> Second point, I can write := in two keystrokes, but I do not have a dedicated
> key for the arrow on my keyboard. Should '<--' also be an acceptable syntax?
No, because "x <-- y" is already legal syntax (it applies unary minus
to y twice, the
On Wed, Nov 6, 2019 at 5:32 AM martin_05--- via Python-ideas <
python-ideas@python.org> wrote:
> In other words, these two things would have been equivalent in Python:
>
> a ← 23
>
> a = 23
>
I do not consider these two things conceptually equivalent. In Python the
identifier ('a' in this
The arrow ...which I will not copy and paste to really hammer home the point
that its not on my fairly standard US keyboard... doesn't look like assignment,
it looks like a comparison operator.
> -Original Message-
> From: martin_05--- via Python-ideas
> Sent: Tuesday, November 5, 2019
martin_05--- via Python-ideas wrote:
The transition to only allowing "←" (and
perhaps other symbols) could be planned for Python 4.
Requiring non-ascii characters in the core language would be a
very big change, especially for something as ubiquitous as
assignment. Much more justification than
On Wed, Nov 6, 2019 at 3:28 PM martin_05--- via Python-ideas
wrote:
> Back to Python.
>
> This entire mess could have been avoided by making one simple change that
> would have possibly nudged the language towards a very interesting era, one
> where a specialized programming notation could be ev
69 matches
Mail list logo
