7 ms·

I think the J examples at the bottom illustrate perfectly _why_ it’s preferable to force this type of array syntax into a language like Python, rather than jump

I think the J examples at the bottom illustrate perfectly _why_ it’s preferable to force this type of array syntax into a language like Python, rather than jumping ship for APL: The J is inscrutable! But the Python is intuitive. Analytics code I’m writing for work needs to not only operate on arrays, but also get the hell out of the way! Understanding and communicating numerical routines is hard enough without obfuscating basic procedures.

vmchale 6y ago
> The J is inscrutable It's understandable after a time, like all else.
eesmith 6y ago
There are common arguments the other way. Do you remember how hard it was to memorize, or at least become familiar with, all of the API function names? Or with various language syntax, like generator comprehensions and decorators? Over the years, and with practice, it's much easier to remember the details. The same is true with the terse notations of the APL-like languages - once you learn them, they are not hard. And there aren't all that many symbols. Some of what you see are composeable combinations of basic symbols. Or, think of shorthand, which takes time to learn, but makes it possible to, for example, take dictation at a speed that longhand cannot manage. While I don't think most programming is limited by typing speed, I do think that for some sorts of exploratory research it is. For a related essay, see https://steve-yegge.blogspot.com/2008/09/programmings-dirtiest-little-secret.html https://steve-yegge.blogspot.com/2008/09/programmings-dirtie... . Finally, APL fans will (correctly, IMO) point out that (in)visibility is part of what makes something hard. That is, code which fits on the screen is easier to read than code which flows over several pages. Thus, the effort of learning a more concise language may pay off in the long-run. (Note that I don't work with numeric arrays and have little experience even with NumPy - I've just read about this debate often.)
agumonkey 6y ago
oh man if you find that inscrutable, I suggest not to watch Aaron Hsu videos on the matter :) I'm not for overcryptic nor making people suffer.. I simply believe that people are underestimating how short syntax + repl + operators can be memorized and enjoyable.
tosh 6y ago
jeremy howard in one of the fastai lectures comments on what helped him to be less scared of reading (the math parts) of papers: learning the names of the greek and latin symbols (because then you can pronounce them in your head!) I have to admit this was not obvious to me before I heard it a few days ago but it makes so much sense. Code we can read (as in pronounce) seems less intimidating and if there are words we might be familiar with can help (and hurt) because we associate ideas with them. Now I think this just underlines the beauty of APL, J, k and so on and why they both seem so un-approachable and loved by those who immersed themselves. obligatory link to Notation as a Tool of Thought https://www.eecg.utoronto.ca/~jzhu/csc326/readings/iverson.pdf https://www.eecg.utoronto.ca/~jzhu/csc326/readings/iverson.p...
- tosh 6y ago
  + - % * > < = Σ ∈ if you are not familiar with the symbols and their meaning they might as well come from a dusty old book hidden away in the depths of a dungeon guarded by tiny dragons yet if you are familiar with them they are not intimidating nor inscrutable (anymore)
- mumblemumble 6y ago
  Somewhat relatedly, it would be nice to have a language with custom operators that also requires you to annotate them with an actual word for a name. I'm guessing it would be a boon to anyone who uses a screen reader to read code, but would also really help others to just be able to talk about code more easily, using more standardized language.
  - tosh 6y ago
    great idea!
jrott 6y ago
The learning curve on J feels like a wall everytime I try and use it I end up bouncing off pretty quickly because it's so dense.
Jhsto 6y ago
I refactored some scikit functions to APL and I found Python inscrutable in its own way: call flow bouncing from a file to another, from Python to Cython, method shadowing, and explicit parallelization. From a productivity standpoint Python must be great as it has bunch of libraries etc., but from actually understanding what is going on, I found it frustrating to work as a OOP-investigator. Even IDEs debuggers don't help once you mix in Cython.
- ljw1001 6y ago
  The hardest code I ever had to read was Python that repeatedly called out to c++ whenever something had to run fast.
robomartin 6y ago
> The J is inscrutable! J is an abomination. I have written about this before on HN and won't repeat myself too much here. J came out of Iverson's failure to understand that the hardware limitations imposed by personal computers of the time would go away as platforms evolved. While he understood the value of notation (hence the famous paper and presentation I got to see live), he succumbed to wanting to come up with a way to make APL accessible to all those IBM PC users without having to resort to hardware tricks nobody would believe today (install a custom character ROM on your graphics card with a toggle switch on the case to switch between APL and standard character sets, etc.). The result was J, a transliteration of APL symbols into combinations of standard ASCII characters found on any keyboard of the time. The result was a complete loss of one of the most valuable aspects of APL, and, as I said above, an abomination.
- rscho 6y ago
  I think your hate is misplaced. J was and is fertile ground for new array language features. In my opinion, not having to come up with a new symbol every time someone wants to try something new has its value. J is much more in flux than APL.
  - robomartin 6y ago
    It's not hatred, it's an objective opinion. I worked with APL professionally for about ten years, starting back in the early 80's. I used both mainframes and desktop computers. I was very involved in the community, attended annual conferences, presented a paper in one of them, admired Iverson and some of the other luminaries of the era, I even have a very dorky looking picture of myself with Iverson. I think that I can say that it is because of this that I was very aware of what was going on with APL in a commercial sense. It was very difficult to evangelize the language when, in the 80's, the friction points to adoption were many --the character set being one of them. It took a major effort on my part to convince a biotech company of the era to adopt APL for analysis of human DNA sequencing data. All of this to say I believe I fully understand the decision to remove one of the impediments by discarding custom symbols and coming up with whatever could replace them that was present in computers of that era. This meant ASCII characters that could be typed by anyone on any machine. Almost anyone desperate enough to make the language gain a foothold in the market would have considered such a solution. That was the driving force behind J. Nothing else. I never heard Iverson say "We moved away from notation because this is better". Never. Because it wasn't. It took a wrecking ball to what he had been teaching and talking about for decades, the foundation of his career, really. They needed market (and financial) success and made the wrong choice. It wasn't long until custom character sets were a non-issue. Anyone who stopped to think about this a bit would have understood that transition was imminent. APL had the same problem that, say, Japanese had. IBM PC's required altered character ROMs and keyboards to be able to use Japanese. If you had to work with both English and Japanese you likely ended-up with a solution similar to early APL, a modified graphics card with a toggle switch mounted in front of the computer to change character sets. And so the pressure to build computers that could do non-ASCII character sets with ease was there and it was very real. Remember that IBM never thought the PC would go anywhere. The machines only became more than the sum of their parts once mass adoption took place and clones got faster, cheaper and better. Had Iverson stuck with APL as it was he would have been able to see it flourish on new more capable hardware. By doing what he did with J he likely bifurcated (or more, because there were other pure APL factions already, like IBM APL2) the community and likely contributed to the language languishing. It only makes me angry in the sense that all of this has caused a situation where modern software engineers will likely never experience what notation can bring to the domain. APL used to be taught at a number of universities. I don't know if any even bothers to mention it yet.
mint2 6y ago
Come on! You don’t like the readable and pronounceable J operators like “+/ . “ for the matrix product? # numpy - matrix product np.dot(a, b) NB. J - matrix product a +/ . b

vmchale 6y ago

> The J is inscrutable It's understandable after a time, like all else.

eesmith 6y ago

There are common arguments the other way. Do you remember how hard it was to memorize, or at least become familiar with, all of the API function names? Or with various language syntax, like generator comprehensions and decorators? Over the years, and with practice, it's much easier to remember the details. The same is true with the terse notations of the APL-like languages - once you learn them, they are not hard. And there aren't all that many symbols. Some of what you see are composeable combinations of basic symbols. Or, think of shorthand, which takes time to learn, but makes it possible to, for example, take dictation at a speed that longhand cannot manage. While I don't think most programming is limited by typing speed, I do think that for some sorts of exploratory research it is. For a related essay, see https://steve-yegge.blogspot.com/2008/09/programmings-dirtiest-little-secret.html https://steve-yegge.blogspot.com/2008/09/programmings-dirtie... . Finally, APL fans will (correctly, IMO) point out that (in)visibility is part of what makes something hard. That is, code which fits on the screen is easier to read than code which flows over several pages. Thus, the effort of learning a more concise language may pay off in the long-run. (Note that I don't work with numeric arrays and have little experience even with NumPy - I've just read about this debate often.)

agumonkey 6y ago

oh man if you find that inscrutable, I suggest not to watch Aaron Hsu videos on the matter :) I'm not for overcryptic nor making people suffer.. I simply believe that people are underestimating how short syntax + repl + operators can be memorized and enjoyable.

tosh 6y ago

jeremy howard in one of the fastai lectures comments on what helped him to be less scared of reading (the math parts) of papers: learning the names of the greek and latin symbols (because then you can pronounce them in your head!) I have to admit this was not obvious to me before I heard it a few days ago but it makes so much sense. Code we can read (as in pronounce) seems less intimidating and if there are words we might be familiar with can help (and hurt) because we associate ideas with them. Now I think this just underlines the beauty of APL, J, k and so on and why they both seem so un-approachable and loved by those who immersed themselves. obligatory link to Notation as a Tool of Thought https://www.eecg.utoronto.ca/~jzhu/csc326/readings/iverson.pdf https://www.eecg.utoronto.ca/~jzhu/csc326/readings/iverson.p...

tosh 6y ago
+ - % * > < = Σ ∈ if you are not familiar with the symbols and their meaning they might as well come from a dusty old book hidden away in the depths of a dungeon guarded by tiny dragons yet if you are familiar with them they are not intimidating nor inscrutable (anymore)
mumblemumble 6y ago
Somewhat relatedly, it would be nice to have a language with custom operators that also requires you to annotate them with an actual word for a name. I'm guessing it would be a boon to anyone who uses a screen reader to read code, but would also really help others to just be able to talk about code more easily, using more standardized language.
- tosh 6y ago
  great idea!

jrott 6y ago

The learning curve on J feels like a wall everytime I try and use it I end up bouncing off pretty quickly because it's so dense.

Jhsto 6y ago

I refactored some scikit functions to APL and I found Python inscrutable in its own way: call flow bouncing from a file to another, from Python to Cython, method shadowing, and explicit parallelization. From a productivity standpoint Python must be great as it has bunch of libraries etc., but from actually understanding what is going on, I found it frustrating to work as a OOP-investigator. Even IDEs debuggers don't help once you mix in Cython.

ljw1001 6y ago
The hardest code I ever had to read was Python that repeatedly called out to c++ whenever something had to run fast.

robomartin 6y ago

> The J is inscrutable! J is an abomination. I have written about this before on HN and won't repeat myself too much here. J came out of Iverson's failure to understand that the hardware limitations imposed by personal computers of the time would go away as platforms evolved. While he understood the value of notation (hence the famous paper and presentation I got to see live), he succumbed to wanting to come up with a way to make APL accessible to all those IBM PC users without having to resort to hardware tricks nobody would believe today (install a custom character ROM on your graphics card with a toggle switch on the case to switch between APL and standard character sets, etc.). The result was J, a transliteration of APL symbols into combinations of standard ASCII characters found on any keyboard of the time. The result was a complete loss of one of the most valuable aspects of APL, and, as I said above, an abomination.

rscho 6y ago
I think your hate is misplaced. J was and is fertile ground for new array language features. In my opinion, not having to come up with a new symbol every time someone wants to try something new has its value. J is much more in flux than APL.
- robomartin 6y ago
  It's not hatred, it's an objective opinion. I worked with APL professionally for about ten years, starting back in the early 80's. I used both mainframes and desktop computers. I was very involved in the community, attended annual conferences, presented a paper in one of them, admired Iverson and some of the other luminaries of the era, I even have a very dorky looking picture of myself with Iverson. I think that I can say that it is because of this that I was very aware of what was going on with APL in a commercial sense. It was very difficult to evangelize the language when, in the 80's, the friction points to adoption were many --the character set being one of them. It took a major effort on my part to convince a biotech company of the era to adopt APL for analysis of human DNA sequencing data. All of this to say I believe I fully understand the decision to remove one of the impediments by discarding custom symbols and coming up with whatever could replace them that was present in computers of that era. This meant ASCII characters that could be typed by anyone on any machine. Almost anyone desperate enough to make the language gain a foothold in the market would have considered such a solution. That was the driving force behind J. Nothing else. I never heard Iverson say "We moved away from notation because this is better". Never. Because it wasn't. It took a wrecking ball to what he had been teaching and talking about for decades, the foundation of his career, really. They needed market (and financial) success and made the wrong choice. It wasn't long until custom character sets were a non-issue. Anyone who stopped to think about this a bit would have understood that transition was imminent. APL had the same problem that, say, Japanese had. IBM PC's required altered character ROMs and keyboards to be able to use Japanese. If you had to work with both English and Japanese you likely ended-up with a solution similar to early APL, a modified graphics card with a toggle switch mounted in front of the computer to change character sets. And so the pressure to build computers that could do non-ASCII character sets with ease was there and it was very real. Remember that IBM never thought the PC would go anywhere. The machines only became more than the sum of their parts once mass adoption took place and clones got faster, cheaper and better. Had Iverson stuck with APL as it was he would have been able to see it flourish on new more capable hardware. By doing what he did with J he likely bifurcated (or more, because there were other pure APL factions already, like IBM APL2) the community and likely contributed to the language languishing. It only makes me angry in the sense that all of this has caused a situation where modern software engineers will likely never experience what notation can bring to the domain. APL used to be taught at a number of universities. I don't know if any even bothers to mention it yet.

mint2 6y ago

Come on! You don’t like the readable and pronounceable J operators like “+/ . “ for the matrix product? # numpy - matrix product np.dot(a, b) NB. J - matrix product a +/ . b