Comment by graboid

4 months ago

I assume that in most array languages, you also create "words" or however you want to call functions, to reuse code. I wonder about a purely aesthetic issue: how does it look to interleave those symbols with user-defined words that by nature will be much, much longer, i.e. "create-log-entry" or "calculate-estimated-revenue".

10 comments

graboid

Reply
tailrecursion  4 months ago

I never did any real programming in APL, but I studied it over about 2 months. When you get used to the symbols, reading spelled-out words feels like reading in slow motion, or being stuck in molasses.

Most (not all) APL code I've seen uses very short names, often one letter names, for function names. And APL programmers are famous for cataloging "idiom" which are short phrases for common subroutines. In other words, it's best practice to repeat 3- or 4- symbol phrases instead of defining a subroutine.

Of course, there's nothing about an array language that requires using symbols; but for some reason most do.

  • ofalkaed  4 months ago

    >Of course, there's nothing about an array language that requires using symbols; but for some reason most do.

    The idioms become words and you read them like words, you don't step through each letter of a word when you read it, you recognize the shape. The same thing happens in APL and its ilk, any commonly used sequence is instantly understood as its function without having to parse each individual symbol and what it does.

kelas  4 months ago

> i assume that in most array languages, you also create "words" or however you want to call functions, to reuse code.

sure, that's a very useful feature, like elsewhere.

> I wonder about a purely aesthetic issue: how does it look to interleave those symbols with user-defined words that by nature will be much, much longer, i.e. "create-log-entry" or "calculate-estimated-revenue".

strictly speaking, dashes and underscores in k can't even be a part of identifier - they are core language primitives. it is very uncommon to see java-like identifiers like CalculateEstimatedRevenue, why would you want that?

to your question:

here's a bit of an oddity: all user-defined functions and core language operators can be called using functional notation:

  v:1 2 3        / some vector
    v+v          / usual infix notation, two operands: left and right
  2 4 6
   +[v;v]        / same as infix, but called as it were a function.
   2 4 6

  add:{x+y}      / a user-defined function: a lambda with a name and two operands.
  add[v;v]
   2 4 6

but there is an important distinction between the two. you can't use your `add` function infix, you must call it as a function, and there are good reasons for that:

  2 add 2         / that's not gonna work

that said, mixing language primitives with function calls looks and reads just fine:

  +/add[v;v]
 12

hope this helps!

  • kbelder  4 months ago

    How does that scale up to program that's thousands of lines? What if you have a hundred different vectors? You're not going to be calling them v1, v2, ...

    So does it end up as

        v_sepallength: 11 14 12
    v_sepallthickness: 1.3 1.5 1.2
    mul[v_sepallength;v_sepalthickness]

    Or, do you just not do that sort of stuff in these languages? I'm not very familiar with them, but I have ended up with some pretty long programs using Pandas in Python.

    • kelas  4 months ago

      > Or, do you just not do that sort of stuff in these languages?

      i tell you more. it is very much recommended to avoid doing this sort of stuff in all languages.

        v_sepallength: 11 14 12
  v_sepallthickness: 1.3 1.5 1.2
  mul[v_sepallength;v_sepalthickness]

      no:

         /sepal:lengths and stroke widths
   spl:[l:11 14 12;w:1.3 1.5 1.2]    /this is your "struct", if you will
  
   spl.w
  1.3 1.5 1.2    /proof

   */spl
  14.3 21. 14.4  /for mul, we don't even have to bother with field names

   */spl`l`w     /but if you insist, lets make it explicit
  14.3 21. 14.4

      to produce a "factory" for well-formed spl objects is a no-brainer as well.

      why we don't use v_ prefix:

        1. everything what can be a vector should be a vector.
  2. we can't use underscore anyway - it is an operator.

    • RodgerTheGreat  4 months ago

      very important things should have short names. locals you're immediately operating upon should have short names. short names should be used in a consistent way.

      less important things can have longer names. variables in a broader scope can have longer names.

      if you have a hundred different vectors, don't just dump them in a pile; put them in dictionaries, tables, namespaces, or scopes.

      1 reply →