[HN Gopher] Why APL is worth knowing
       ___________________________________________________________________
        
       Why APL is worth knowing
        
       Author : tosh
       Score  : 71 points
       Date   : 2022-03-31 18:47 UTC (4 hours ago)
        
 (HTM) web link (mathspp.com)
 (TXT) w3m dump (mathspp.com)
        
       | rbanffy wrote:
       | At the bare minimum, it'll teach you the value of good code
       | comments.
        
       | 1vuio0pswjnm7 wrote:
       | I would like to see something about "Why Python is worth knowing"
       | from someone who knows APL. For whatever reason I can spend time
       | playing around APL but I cannot force myself to spend time
       | playing around with Python.
        
         | metadat wrote:
         | It's okay to not know it. If it doesn't vibe with you, don't
         | fight it! Learn to accept it and don't force. Oftentimes it's
         | the way things should be.
        
         | mlochbaum wrote:
         | My first language was J, and I also struggled to work with
         | Python at first. However, I'm glad I did have to work with
         | Python and particularly Javascript. The big things I think an
         | APLer can benefit from are first-class functions, code
         | organized in namespaces (possible but not common in Dyalog),
         | and mutable data structures, objects and dicts in particular.
         | Interestingly you can now encounter these in the APL family. I
         | developed BQN largely to incorporate these modern ideas, and
         | compared it with APL at [0]. It's still missing dicts, which
         | are incorporated well in the K language. I don't know if you'd
         | end up learning the concepts as deeply though. Particularly
         | objects are somewhat peripheral in BQN, while they're more
         | central in Python.
         | 
         | APLers have some tendency to be indifferent or even hostile
         | towards abstraction. By abstraction I mean that you write a
         | portion of your program, remember what it does, forget about
         | how it does it, and go on to write other parts. Making a clean
         | "what it does" interface introduces some overhead (in lines of
         | code, thinking, and performance), and languages like Java or
         | Haskell make it easy to go overboard and waste more time on
         | building your abstractions than writing the program. However,
         | the idea that you should avoid abstraction entirely is a huge
         | mistake in my opinion, and I think APL programmers that do this
         | could improve their programs a lot by breaking off a few
         | pieces. Features like objects make abstraction a lot easier and
         | can teach you intuition for where the program naturally splits
         | apart.
         | 
         | (You might be thinking "but I already know this!" The NumPy
         | programmers think this about arrays too. You probably don't
         | know it as well as you could.)
         | 
         | [0] https://mlochbaum.github.io/BQN/commentary/why.html
        
           | moonchild wrote:
           | I am very wary of taking too much from (python, js, et al).
           | Referential transparency is of great value, and it is a shame
           | to lose it. As a colleague is fond of saying, mutation (et
           | al) is an implementation issue, not a language issue.
           | 
           | Also: python does not scale well. If you pursue python (or
           | its ilk), you will converge on common lisp (or similar),
           | which is, ideologically, diametrically opposed to apl. The
           | conflict should be clear. Conceptual integrity and coherence
           | will be lost at any point in between (this is not to imply
           | that common lisp is a bad thing).
           | 
           | And, by nature, common lisp can subsume apl (see april), but
           | the reverse is not true.
        
           | gmfawcett wrote:
           | For many of us who learned J, it was a sixth or maybe a
           | sixteenth language: an interesting rabbit-hole, among many
           | explored rabbit-holes. :) I'm sincerely interested in knowing
           | how you came into programming with J as your first language!
        
             | mlochbaum wrote:
             | I learned it from a teacher at my high school, Henry Rich,
             | who was an APL programmer for a while and a J early
             | adopter: https://aplwiki.com/wiki/Henry_Rich
        
               | gmfawcett wrote:
               | Cool! I've read Henry's book -- a great intro to the
               | language. I didn't know he had been a teacher!
        
         | jayd16 wrote:
         | Python has some pretty neat metaprogramming features that are
         | worth knowing about.
        
         | rodgerd wrote:
         | I saw a meme last week which sums up Python's appeal perfectly:
         | "I keep writing pseudocode and it keeps working!"
        
           | KerrAvon wrote:
           | Yeah, but that only works for small code fragments. There's a
           | lot in Python that doesn't hit that sweet spot. Anything with
           | double underscores or list comprehensions, for example, which
           | is any complex Python program. Arguably anytime you have to
           | `import` anything.
           | 
           | edit: I suspect the poster was asking from the perspective of
           | someone who does APL and wants to know what benefits Python
           | would have in that space.
        
       | jll29 wrote:
       | Prolog is a good language to study in order to expose yourself to
       | a "new way" of algorithmic thinking, although I could not see
       | myself building large systems in it (it has a lot of merit as an
       | embedded language for certain tasks).
       | 
       | Python, as useful as it is, in contrast, when I first saw it
       | reminded me of BASIC , after which PASCAL, Modula-2 felt like
       | seeing the light back in the days.
        
       ___________________________________________________________________
       (page generated 2022-03-31 23:00 UTC)