@Sherlock9 It's interesting they would say this as I think the paradigm and the symbols go hand in hand. I feel that using the English keyword replacements might just tempt you to use your old ways of thinking about programming. At least with the symbols, there's no illusion that you're using an entirely different paradigm

@Adám I'm reading the conversations at that link and it seems like robomartin is very down about the future of APL (maybe even the present)

It actually brings up a point I wanted to ask you about the use cases of APL in the professional world. Data analysis is a big one, but would it be at all suited for, say, game development, web development, or hardware design?

I'm not sure those are the Big Categories, but it's what comes to mind when considering commercial spaces for code

@JayW I told you I'd made a chart for most of my mnemonics:

@Adám Okay fair enough :D

It bugs me that I worry "why hasn't APL gained mainstream acceptance" when that's not the biggest criterion for good programming language

Still, when I work in ReactJS and JSX all the time, there is a little worry about whether APL is worth the trouble for anything more than golfing

But I suppose I should judge that after I get back to reading APL books instead of J books XD

@Sherlock9 There are probably a few reasons. One is in perceived value: A manager of 100 programmers appears "better" than a manager of 10, so minimising the need for programmers is considered bad. Also, productivity is measured in LOC… APL was also invented "too early" when the hardware was barely up to the task, so it got bad rep. The coffin nail was maybe important companies (IBM, Microsoft) choosing to bundle other languages for free…

The self-taught geeks of the early PC era couldn't afford (or obtain — there was no www) other interpreters/compilers, so they learned what they had, x86 assembler and QBASIC, leading to familiarity, and thus popularity, of similar languages going forward.

Also, APL requires more thinking on the part of the programmer. It is possibly easier to manage a "farm" of less gifted non-APLers.

Oh, and APL's simplicity led to less how-to publications, leading to less apparent popularity, causing people to stay away. This has happened to other software as well.

There's also the phenomenon of APLers being unwilling to rely on others' code. Maybe it is due to the ease or satisfaction of beginning from scratch? Either way, it meant less availability of/need for tools and libraries, and thus less resources to obtain them. Fast forward to today, and it is simply slower to get something done in APL because other languages already have a library for that.

@Adám You'd think there'd be more of a market for how-to publications given the lack of mainstream understanding, but I suppose that's me misunderstanding the need for all those how-to publications in the first place

@Adám Ah yes, all the libraries. I'm definitely concerned about how many libraries we use in our work just to get React itself "up and running" before adding on (an admittedly small number of) peripherals like GraphQL, testing libraries, and the like.

@Sherlock9 1) Yeah… 2) Creating a good APL implementation takes decades of dedicated work. Maybe the J source could be modified into a good SharpAPL-like dialect. Btw, in a few days, Dyalog will be freely downloadable…

@Adám Oh excellent!

Also I had completely forgotten that J is open source

@Sherlock9 I wonder what it would take to transform J into APL:

@Sherlock9 This year's competition winner apparently has had the same idea…

@Adám Oh yes this article. Which competition was this?

@Sherlock9 Dyalog's APL Problem Solving Competition

@Sherlock9 twitter.com/dyalogapl/status/1172056760422678528

@Adám That's neat. I like "all the way to the right" for right tack, that's creative.

@Sherlock9 I would say GNU APL is pretty good, if you use mostly APL dfns and don't want to take advantage of trains. I don't think it's as performant as Dyalog APL, but it fits the criteria of being a fairly complete open source implementation (and it has the ability to interface with e.g. R, iirc)

@Adám I've actually since grown to like the J ASCII primitives, they sort of make sense after a while. Though the ] symbol keeps annoying me, it just makes code look very unbalanced...

@JayW GNU dfns are dynamically scoped, do not allow multiple statements (though you could use ⊣), and have neither guards nor error guards.

@JayW Yeah, [ ] { } are not pleasant, but I have a very hard time parsing which dots belong where. Things like +./ .*. (compare to ∨.∧ or even ∨∙∧) makes me give up.

@Adám Oh that's unfortunate :( I only gave GNU APL a brief try and was happy to see it had dfns, but I guess they're not up to par with Dyalog dfns yet

@Adám I have the same problem with the dots and haven't really found a very good solution for it other than concentrating very hard when I'm reading J ;) Maybe font ligatures would make it better, so the dots/colons combined into a single glyph and it'd follow the roughly one-character-per-primitive rule of APL and you wouldn't have to change the underlying representation

If you use e.g. Fira Code with its font ligatures, reading Haskell and its operator spaghetti actually looks a bit nice(r) :P

> Ideally, all programming languages should be designed with full-fledged Unicode symbols for operators, but that’s not the case yet.

Welp, I think I've locked up my J interpreter XD

"embraceless loop programming" it is already a big fail...even if there would be one variable for exit the bug loop that would run infinite without to be thinking to be a infinite loops

Was trying to run (,(q:@>:@(*/)))^:10(2x) which should calculate the first 11 terms of the Euclid-Mullin sequence

Except of course q: calculates all prime factors, so now it's locked up trying to factor numbers that big

Ah, and I also forgot to take only the first prime factor

Okay next APL or J task: find the smallest prime factor and stop immediately