On Fri, Nov 8, 2019 at 5:40 AM Martin Euredjian via Python-ideas python-ideas@python.org 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 PC era took hold most of APL was done with either a card you'd place in front of your keyboard or stickers you'd add to the front of the then thick keycaps.
Here's reality: It isn't that difficult at all to mentally map a bunch of symbols to a standard keyboard. It's a bit clunky at first but you learn very, very quickly, I would venture to guess that one could reach for the most common APL symbols with ease within a day.
Here's another very VERY important reality: once you've done something for multiple years, you are usually *terrible* at estimating how difficult it truly is. Your brain understands what you're doing and has no difficulty with it, so you think that it's an easy thing to do. Is it? Maybe; maybe not. But unless you have watched a brand new APL programmer, you can't see how hard it actually is. Or in this case, perhaps not a brand-new APL programmer, but someone who has (say) six months of experience.
How do we learn to touch-type? By typing. At first you look at the keyboard all the time. I never do any more. I am typing this by looking at the screen, I haven't looked at the keyboard even once this entire time. You can do that with APL just fine, it's easy.
When I was actively using the language every day I touch typed APL, didn't even think about it. Which is also another powerful thing. Once you get to that point expressing ideas computationally is not unlike playing music on a piano, it just flows.
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?
It is my opinion that this is so because we are still typing words into text editors. I do not, by any means, imply that programming graphically is the solution. I do a lot of FPGA work, mostly designing complex high speed real time image processing hardware. I have tried graphical tools for FPGA work and they have never really worked well at all. In this case my go-to tool ends-up being Verilog or even lower register-level hardware description. I can't tell you what form this "next generation" approach to programming should take other than having the believe, due to my experience with APL, that the introduction of symbols would be of potentially great value.
Oh you're absolutely right that graphical programming is not the solution. We're still typing words *because typing words is still the best way to do things*. There have been many MANY point-and-click programming tools developed (the first one I ever met was back in the 90s, a codegen tool in VX-REXX), and while they are spectacular tools for bringing a smidgen of programming to a non-programmer (say, giving an artist the ability to drag and drop instruction blocks around to create a complex animation sequence), they are *not* a replacement for text-based coding.
A simple example of this might be a state machine driving the menu system of an embedded system with a simple multi-line LCD display and a few buttons and knobs for a control panel. I've done control panels with two dozen displays, a couple hundred buttons and to dozen encoder/knobs. Once you start looking at what it takes to design something like that, code it and then support it through iterations, feature changes and general code maintenance it becomes VERY obvious that typing words on a text editor is absolutely the worst way to do it. And yet we insist on being stuck inside an ASCII text editor for our work. From my perspective, in 2019, it's just crazy.
No actually, it's not so obvious to me. Convince me. Show me that typing words is "absolutely the worst".
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 I mean real-time operations where every clock cycle counts. One of the most critical aspects of this for me is the documentation of what one si doing and thinking. And yet, because we insist on programming in ASCII we are limited to text-based comments that don't always work well at all. In my work I would insert a comment directing the reader to access a PDF file I placed in the same directory often containing an annotated image of a waveform with notes. It would be amazing if we could move away from text-only programming and integrate a rich environment where such documentation could exist and move with the code.
Ehh, if you want to use Markdown in your comments, then sure. You could even have an editor that shows them nicely. But the code itself isn't a PDF.
The productivity gain comes from operating at a higher cognitive level while translating your thoughts into code for the machine to execute. The famous one-liner solutions are not neat because they are on-liners, they are interesting because they become idioms, words, with a meaning. Your brain sees that and knows what that line is doing. Again, this isn't what happens to a newbie, of course.
So with APL, you expect that multi-token one-liners become "words" of a sort, yet you decry ":=" in Python as "ASCII soup". Please, what *is* the difference? Define what is and isn't a token. Define what does and doesn't sit within your brain. I am unable to distinguish them. In both cases, you start with primitives and combine them, and your brain learns the combinations as new primitives. The only difference is that Python's notation can be typed on (pretty much) any keyboard, whereas APL's notation needs to be mapped specifically to each keyboard, and you need a dedicated editor that understands things. (See earlier in the thread where it was pointed out that some non-English keyboards use the Alt key to type "[", making the key combination Alt-[ impractical or impossible.)
ChrisA