Try APL

It's very APL specific. Keys were APL symbols, operators in one keystroke. So if the sum key wasn't available, you'd decode base 1. That sort of thing...

My grandfather had to drop out of high school, after his dad died from an infection. He unloaded trains for the A&P grocery chain, and proposed that they reorder shipments to save money. He retired in charge of half of New England. His computer center was a bank of women at fancy adding machines.

Fresh out of college, my father helped a senior programmer at Kodak automate testing for their film developing chemical baths. This replaced dozens of people. Kodak found them other positions, and moved my dad to the research labs. He used computers from the beginning, and told me many stories. On a family night in the 1960's I got to play the original "space wars".

In 1974 he came up with the color sensor pattern now used in nearly all digital cameras.

Read that as "We took classes in observatory building". Imagining the prof explaining how to grind a mirror, how revolvers can be used to make a very high resolution angular positioning system, and so on.

I love Lisp and Scheme too. Though like sex at 19, nothing has ever felt quite like the first months with APL.

For "production" math research, nothing comes close to Haskell for me. Every time I consider straying, the ease of parallelism draws me back.

I have written a fair bit of Scheme, using my own preprocessor that avoids most parentheses. I stay clear of that loaded debate, this is for personal use. The code is poetic, though not as dense as APL or Haskell. As Bill Joy once opined, what you can fit on a screen matters.

My own favorite Haskell code is a very terse implementation of monadic parsing. Typed trees are not far off from strings, and then one has algebraic data types as parsing. (Pattern matching is parsing a bit at a time, without reifying the activity for program control.)

APL gets unexpected mileage from a core of array handling. I dream of a Lisp-like language tuned to parse algebraic data types as its core activity, with macros as its "middle of the plate" pitch rather than as a strapped-on afterthought. (I'm not trolling here, this is my honest opinion. In 10,000 runs of the simulation, I doubt Lisp macros would be this clumsy in most runs.)

Ultimately we all long for better language tools to express pattern as code. My electric guitar never sounded like what's in my head, and for code I'm still reaching too. Though APL was wonderful in its day.

> Thanks for sharing, I love these types of stories. Really makes me pine for the "old" days, and wonder if there's a parallel universe where technology took a very different route such that languages like APL, Lisp, and Smalltalk are used instead of JavaScript, Java, and C#, and what that world looks like.

Easy, here is some time travel,

"Alan Kay's tribute to Ted Nelson at "Intertwingled" Festival"

https://www.youtube.com/watch?v=AnrlSqtpOkw

"Eric Bier Demonstrates Cedar"

https://www.youtube.com/watch?v=z_dt7NG38V4

"Yesterday's Computer of Tomorrow: The Xerox Alto │Smalltalk-76 Demo"

https://www.youtube.com/watch?v=NqKyHEJe9_w

However to be fair, Java, C# and Swift alongside their IDEs are the closest in mainstream languages to that experience, unless you get to use Allegro, LispWorks or Pharo.

Yes [fixed]. And in an interpreted language, moving the work to a single operation was a big win.

Constant factors, heuristics, memory usage, etc...

There was a discussion on array programming languages here recently where someone proudly showed off a K language solution to a simple problem, stating that the K solution was efficient because it could solve it in 1.2 microseconds. I used Rust to solve it in 5.5 nanoseconds, which is nearly 200x faster. Both used "brute force" with no cleverness, but there's "bad" brute force and "good" brute force.

I've had a similar experience at university while using Haskell. It's a very elegant lazy pure functional language, but it's glacially slow. The natural, low-friction path is very inefficient. The efficient path is unidiomatic and verbose.

I hear people making similar observations about F# also. It's fast to program in, but if you also need performance then it is no better than more mainstream languages -- in fact worse in some ways because you're "going against the grain".

I think that quiet vs verbal mind personality difference is really what separates whether people like which languages.

I personally can't stand languages that are "spoken description". I understand the appeal to others but the languages just don't mesh with my way of thought. When I'm programming or building a system I'm thinking in the sense of abstract transformations and structures not in any spoken structure. Often times for me it's easier to draw out what I'm thinking of rather than explain it since there's not necessarily a verbal representation behind what I'm thinking of until I sit down and try to come up with one.

There was study of Harvard undergraduates that demonstrated Greek letters made math harder.

I tell my students that Columbia undergraduates are of course smarter, but still...

Interesting. I was under the impression that Iversion intended APL to also read almost like English, provided you knew the names of operators and idioms.

Aaron Hsu has some talks showing this off about his co-dfns compiler.

GNU APL is mostly a reimplementation of APL2 from the 80s, with some additions that in my opinion do nothing to get it out of the 80s. Dyalog has namespaces, but scripting support is only due to be released in the next version, 18.1.

So I don't know of any APL that allows module-defining scripts. This is really unfortunate since there's no technical reason to prevent it. With lexical scoping (Dyalog has it, GNU doesn't), it's easy to define a module system and I did this in my APL reboot called BQN: https://mlochbaum.github.io/BQN/doc/namespace.html .

various interpreters have ways to make external calls via com/web/etc. APL is basically python calling C++/C#/Java/etc.

Seeing pure APL for XML parsing is.. interesting. Most interpreters support saved/read of functions in a more procedural way.

> Not being able to speak, read or write Chinese does not make it a bad language.

Well that's the problem. Not being able to read or write APL makes it more fun to learn.

Thanks for posting this intriguing link. A glance at the Jupyter notebook on this site will bring a smile to a Julia user who grew up on (or has somehow encountered) APL.

What an incredibly concise, elegant implementation.

> I lament that I cannot use something regex-like to match general sequences, e.g. a sequence of tokens

You can. It's not typically built into a programming language's standard library. But there are plenty of general-purpose automata-building libraries out there, and some of them do provide DSLs. At least to the extent that the regular expressions you're using are actually regular (many aren't), all a regex is is a domain-specific specialization of nondeterministic finite automata.

I sometimes lament that I don't see them, or hand-coded automata, more often. This was CS101-level stuff when I was in college, and it's pretty easy to code your own even if you don't have a good library available in your language. And, for problems where they're appropriate, using them typically yields a result that's simpler and easier to maintain than whatever ad-hoc alternative you might see instead.

> using a regex DSL to match a sequence of strings, where you might want to define a string class (analogous to a character class) as a regex itself.

http://p3rl.org/retut#Defining-named-patterns

https://docs.raku.org/language/grammar_tutorial#The_technica...

If you want a demo, reply with a concrete example I can implement.

The now defunct Viewpoints Research org chased an idea similar to this. It was a meta language that was based around PEGs, intended to allow the easy creation of DSLs. I imagine the papers are still up somewhere. It was called OMeta.

There are a few, here's one: https://clojure.org/guides/spec#_sequences

I'm not sure of the need to do that. Not for parsing anyway.

A well designed regex system is enough without tokenization.

The parser for the Raku language, for example, is a collection of regexes composed into grammars. (A grammar is a type of class where the methods are regexes.)

We could probably do the token thing with multi functions, if we had to.

    multi parse ( 'if',  $ where /\s+/, …, '{', *@_ ) {…}
    multi parse ( 'for', $ where /\s+/, …, '{', *@_ ) {…}
    …

(Note that `if` and `for` etc are keywords only when they are followed immediately by whitespace.)

I'm not sure how well that would work in practice; as hypothetically Raku doesn't start with any keywords or operators. They are supposed to seem like they are added the same way keywords and operators are added by module authors. (In order to bootstrap it we of course need to actually have keywords and operators there to build upon.)

Since modules can add new things, we would need to update the list of known tokens as we are parsing. Which means that even if Raku did the tokenization thing, it would have to happen at the same time as the other steps.

Tokenization seems like an antiquated way to create compilers. It was needed as there wasn't enough memory to have all of the stages loaded at the same time.

---

Here is an example parser for JSON files using regexes in a grammar to show the simplicity and power of parsing things this way.

    grammar JSON::Parser::Example {

        token TOP       { \s* <value> \s* }

        rule object     { '{' ~ '}' <pairlist>  }
        rule pairlist   { <pair> * % ','        }
        rule pair       { <string> ':' <value>  }

        rule array      { '[' ~ ']' <arraylist> }
        rule arraylist  {  <value> * % ','      }

        proto token value {*}

        token value:sym<number> {
            '-'?                          # optional negation
            [ 0 | <[1..9]> <[0..9]>* ]    # no leading 0 allowed
            [ '.' <[0..9]>+ ]?            # optional decimal point
            [ <[eE]> <[+-]>? <[0..9]>+ ]? # optional exponent
        }

        token value:sym<true>    { <sym>    }
        token value:sym<false>   { <sym>    }
        token value:sym<null>    { <sym>    }

        token value:sym<object>  { <object> }
        token value:sym<array>   { <array>  }
        token value:sym<string>  { <string> }

        token string {
            ｢"｣ ~ ｢"｣ [ <str> | ｢\｣ <str=.str_escape> ]*
        }

        token str { <-["\\\t\x[0A]]>+ }
        token str_escape { <["\\/bfnrt]> }
    }

The only one of those that really looks anything like traditional regexes is the `value:sym<number>` token. (Raku replaced non capturing grouping `(?:…)` with `[…]`, and character classes `[eE]` with `<[eE]>`)

This code was copied from https://github.com/moritz/json/blob/master/lib/JSON/Tiny/Gra... but some parts were simplified to be slightly easier to understand. Mainly I removed the Unicode handling capabilities.

It will generate a tree based structure when you use it.

    my $json = Q:to/END/;
    {
      "foo": ["bar", "baz"],
      "ultimate-answer": 42
    }
    END
    my $result = JSON::Parser::Example.parse($json);
    say $result;

    ｢{
      "foo": ["bar", "baz"],
      "ultimate-answer": 42
    }
    ｣
     value => ｢{
      "foo": ["bar", "baz"],
      "ultimate-answer": 42
    }
    ｣
      object => ｢{
      "foo": ["bar", "baz"],
      "ultimate-answer": 42
    }
    ｣
       pairlist => ｢"foo": ["bar", "baz"],
      "ultimate-answer": 42
    ｣
        pair => ｢"foo": ["bar", "baz"]｣
         string => ｢"foo"｣
          str => ｢foo｣
         value => ｢["bar", "baz"]｣
          array => ｢["bar", "baz"]｣
           arraylist => ｢"bar", "baz"｣
            value => ｢"bar"｣
             string => ｢"bar"｣
              str => ｢bar｣
            value => ｢"baz"｣
             string => ｢"baz"｣
              str => ｢baz｣
        pair => ｢"ultimate-answer": 42
    ｣
         string => ｢"ultimate-answer"｣
          str => ｢ultimate-answer｣
         value => ｢42｣

    my @pairs = $result<value><object><pairlist><pair>;

    my @keys = @pairs.map( *.<string>.substr(1,*-1) );
    my @values = @pairs.map( *.<value> );

    say @pairs.first( *.<string><str> eq 'ultimate-answer' )<value>;
    # ｢42｣

See https://github.com/moritz/json/blob/master/lib/JSON/Tiny/Act... for an example of an actions class.

---

Note that things which you would historically talk about as a token such as `true`, `false`, and `null` are written using `token`. This is a useful association as it will naturally cause you to write shorter, more composable regexes.

Since they are composable, we could do things like extend the grammar to add the ability to have non string keys. Or perhaps add `Inf`, `-Inf`, and `NaN` as values.

    grammar Extended::JSON::Example is JSON::Parser::Example {
        rule pair { <key=.value> ':' <value>  } # replaces existing rule

        # adds to the existing set of value tokens.
        token value:sym<Inf>    { <sym> }
        token value:sym<-Inf>   { <sym> }
        token value:sym<NaN>    { <sym> }
    }

One past thread:

APL Since 1978 [pdf] - https://news.ycombinator.com/item?id=23510433 - June 2020 (21 comments)

You can also set it as an altlayout on your keyboard. I'm on linux so I set it to holding Winkey switches to APL.

I've been meaning to write 'bullshitting the technical interview' where I neither know how to solve the problem nor APL but end up convincing the interviewer that I know both.

When I was more regularly doing coding interviews, I would pick a problem suited for the strengths of the candidate's self-identified strongest language, but basically go "use whatever language you want, but beware that if it's not one of <short list>, I will have to transcribe your code and run it for the final assessment".

I had Haskell, OCAML, and Ruby thrown at me (no, none of those were on the list). None actually ran on the first try, but I could rehab the Ruby to working (it was a silly mistake, only a small amount of score knocked off), but I could not rehab the Haskell nor the OCAML, so that ended up with a "recommend no-hire".

Bit of a shame, had they chosen the Python that the CV indicated they preferred, it may well have been a "strong hire" (but, failure to produce runnable code, that can't be easily fixed, in a language explicitly recommended against indicates that there are some possible red flags).