The APL Orchard

@rak1507 the winning solutions are the most interesting

even the anonymity doesn't seem required, plenty of competition sites let you look at other people's answers afterwards

@rak1507 It was run by someone who is not a programmer.

@ngn yeah, so they should definitely not be anonymous, as for the rest, ¯\_(⍨)_/¯

@Adám ah...

@rak1507 the rest could remain unpublished

4:02 PM

@rak1507 anonymity doesn't give much here - you could easily correlate per-month scores

@dzaima I'm talking about the problem solving contest, not the code golf thing

@rak1507 ah

@rak1507 The 2016 year game has no connection to the programming competition anyway, and yes, the programming competition could have been automated earlier, but nobody did it. In principle, much of today's amazing technology could have been created long ago, if only people had had had the imagination/experience/knowledge.

it doesn't have to be automated to be transparent. just publish the winning solutions immediately after the deadline (assuming judging doesn't take too much time).

for the 2016 thing just publish the winning solutions, I don't think that really matters that much

4:05 PM

Isn't that what we did, though?

I have no idea, I haven't checked, I'm just assuming you haven't based on ngn's complaints

@Adám you didn't. you published an mix of winning solutions per problem, not per person.

Btw, I made a mistake, it wasn't the 2016 year game, it was the 2017 code golf challenge.

@ngn So you wanted the full set of everyone that won?

@Adám i won that one, so it's ok :D

@ngn You won the 2016 year game too?

4:08 PM

@Adám that's 2 people. or am i missing something?

No.

@Adám technically

Why technically?

@Adám shared 1st place

@ngn You had a shared 1st place in the 2016 year game? (Not talking the 2017 code golf competition, which is what you had complained about.)

4:12 PM

now i'm confused

2016 year game

2017 code golf challenge

@Adám yes, shared 1st place in the 2016 game. i've never complained about 2017's codegolf

I am confused

Jan 5 at 19:00, by ngn

https://www.dyalog.com/uploads/files/2017yeargame.txt

Week 9: as I wrote a year ago, "I've assumed that character scalars are not acceptable results - The Rules mention only character *vectors*. If scalars are ok, please don't count the leading glyph in the expression for 9."

Week 25: The first item of ⎕SD is not necessarily 25 - for example in the terminal I'm typing in right now ⎕SD is 39 151. The Rules say: "Expressions must not rely on local conditions, for example, the operating system, the exact date/time or specific input from the user."

oh crap, my bad

mixed up the years

Me too.

4:16 PM

and there was that codegolf thing by optima, to add to the confusion

two, actually.

4:32 PM

@rak1507 tradfns are actually good, because as far as i know they don't have the dfn return-after-non-assignment problem

overall i've seen adam's comment somewhere about !!fun!! bugs with dfns

but i don't remember where is it

@KamilaSzewczyk yes, that's one of the problems with dfns (there are more), but at least dfns get the principles right

"principles" = variables are local by default, and dfns never mess with the environment of the caller

tradfns are tradfns. Tradition. Backwards compatibility requires that they work the way they do. It's disingenuous to claim that they ought to be different than they are, or that they violate some "common sense" sacred cows of programming that were not yet religiously dogmatic at the time.

Dec 7 '20 at 17:32, by Adám

@voidhawk … ⊢{a←1 ⋄ }0 giving a value error; can't trace into a one-liner dfn; →0 in the session quits instead of resuming execution; plus←+ ⋄ a plus← and plus←+ ⋄ 1 plus a←2 overwriting plus; :: failing to catch ⎕SIGNAL etc.

Also forgot to mention during previous index origin discussions -- that new darling language Julia is also 1-origin based. I guess that should preclude it from use by anyone who knows better.

@ab5tract yes

4:38 PM

@ab5tract 0 > 1 >>>>>>>...insert many more arrows here...>>>> having a choice

@ab5tract let's leave those traditions in the 1950s where they belong, and move on

why can't we have 0.5 as the index origin, it's a good compromise between ⎕IO←0 and ⎕IO←1 people

lol

You don't get it -- using the index as a pointer offset was not something that people were doing in the 1960s. Just get over it.

@ngn i sort of agree with ngn on that one

APL seems like a steaming pile of legacy crap that is somehow still kept alive

BQN seems to ressurect it but the language would be much better if it was more modern

4:39 PM

@KamilaSzewczyk wow...

dfns have weird behavior, because legacy code, io because legacy code, tradfns because legacy code

i don't claim by any means that some language is perfect, but the only thing that keeps APL from being perfect is backwards compatibility

@KamilaSzewczyk Isn't that the case with every language?

well, not really

yay, finally someone get it :) well said, @KamilaSzewczyk

@KamilaSzewczyk In what way is BQN non-modern?

4:41 PM

it isn't the case for Rust

Rust is a brilliant, modern language with literally no legacy crap to it's name

Give it a decade

@KamilaSzewczyk It is only one decade old!

Has it even hit 2.0?

i'm glad you said that - we all seem to agree that time will sooner or later make a lot of legacy kludges

that's where I kind of like Whitney's model

of throwing the code away :)

@Adám my top 2 compaints: array model too complicated; and bqn requires messing with fonts&kbds

4:42 PM

Whitney's model keeps me from bothering to learn his latest iteration until he stops throwing it away

hahaha

well, i'm not a K expert, but i think that K doesn't change fundamentally across editions

the thing that stops me from wanting to learn K is to me a lack of use and a lack of documentation

overall, there are many existing codebases and if the core principles change then maintaining kdb and q would be quite sad

@ngn APL requires special characters either, the characters are a feature of the language, see Notation as a Tool of Thought

@KamilaSzewczyk One of the main contributors was Brendan Eich. He probably learned a lesson or two from experience with JS. Still, JS is way more popular than Rust, while truly having a lot of legacy quirks, and it cannot really discard anything, as that could break old websites.

4:43 PM

@KamilaSzewczyk K7/Shakti keeps changing fundamentally within the same version

@Adám I don't think anyone will argue that JS is the pinnacle of language design

@rak1507 compared to apl, it's used more and has better docs (k4 at least)

oh yeah, i think scrapping up the web just like we scrapped up flash would be a not bad idea.
Brendan Eich at first took a list of every design flaws in his past languages and put it in a single language just to see what happens

thankfully he didn't do this with Rust

There's nothing legacy in APL that can't be discarded in a new implementation, at its core APL is the most elegant way I know of to express array operations

@ngn when I google something related to APL, there's a 50% chance to land on Dyalog APL 15.0 documentation.

4:44 PM

@ngn Its goals include to explore exactly those two design spaces.

@ngn it has the same problem as APL that real life use cases are hidden away, I have no idea what a real world K project would look like, and the sort of real world things I might want to use a language for don't lend themselves to an array one anyway

i'll probably get eaten for that, but i just consider APL as a very good problem solving tool for smaller projects, and i don't see a business use for it

@KamilaSzewczyk And our plan is to amend all the old docs with links to the new ones…

@rak1507 It sounds like you don't need a vector language in that case

^ score+←1

4:47 PM

@Adám You could set no-index rules for search engines on the old doc pages

@phantomics yeah exactly

@Adám ah, awesome

i asked it here one day, i was curious what are the job opportunities of APL

@phantomics Oh, I didn't think of that (and probably nobody else did either).

but it seems like... nobody seems to be looking for APLers

@KamilaSzewczyk maintaining legacy code

4:48 PM

also i think i'd turn insane if i had to work with APL day to day

especially while maintaining legacy code lol

@rak1507 k has an additional problem: k developers don't like being seen, or their code being shared. they like to hide quietly in the shadows, in banks and hedge funds.

I think working with it day to day on newer projects would be fun, something like Martin was doing, but legacy code, ⎕ML stuff, tradfns... shudders

@Adám That can help you funnel users to the newer pages instead of people running into old docs

i'm happy in my c/java middleground between brainless react/js/any frontend and huge brain array/functional programming

@phantomics Though maybe it should be possible to search for docs for old versions?

4:49 PM

@ngn yeah exactly, it seems like a secretive cult of wizards that lurk in a cave hidden from the rest of society

@ngn i wonder why is it so

@Adám Of course, the old stuff would still be online, I would keep one indexable root page for the docs of each old version

@Adám That seems special-cased enough that providing a landing page with links to the old versions should be enough

We already have that.

So if someone went searching for version 15.0 docs, they would land on the home page for the 15.0 docs

@KamilaSzewczyk Vector langauges are easier than c/java IME, those languages are miserable with the amount of boilerplate and clumsy syntax required

4:51 PM

@KamilaSzewczyk With emphasis on the seems like :-) APLers and APL-using companies are notoriously bad a finding each other. Though Morten is trying to encourage the companies to monitor this room if they are looking for promising talent.

@KamilaSzewczyk fear of competition probably. in my experience, apl culture is somewhat closed too, but to a lesser extent. at least until dyalog decided to hire adam :)

@KamilaSzewczyk just spitballing, but maybe it could have something to do with the fact that sharing the code would instantly trigger a golfing crusade which could be crushing to one's ego .. ;)

hahaha

that's a lot of pings, let me read

With a vector lang you can implement an idea nearly as fast as you can think it

@phantomics idea: website ;)

4:52 PM

i don't think vector & functional langs like APL are simple, because they enforce a good code style and writing performant code in them seems a bit difficult

@rak1507 Vector languages aren't for generating HTML, that's what Lisp is for

if i had to do these streams I just did in C++, i'd probably do it much faster than in APL

but it was way more fun to do in APL

an idea*

* - idea must be in the set of problems suitable for a vector language

most of my ideas don't revolve around transposing boolean matrices

@rak1507 Why harp on what vector langs aren't suited for? If you're doing image processing, signal processing, statistics, anything like that APL will give a massive boost

signal processing with APL?

4:54 PM

@phantomics Marshall had to write parts of his signal processing in C because J was too slow

this might be slow

MFW no APL on gpus :c

co-dfns

ik about co dfns

but it'd be good it dyalog could do that natively

yeah

cpu computing for vector languages is kinda very busted

and very horrible

idk why nobody tried GPUs for so long

4:55 PM

@KamilaSzewczyk transferring data to/from gpus is slow, and the avg array length in real-world(TM) apps is between 1 and 2

@KamilaSzewczyk Have you tried using one? GPUs have tons of caveats

the only use case to perform vector computations on CPUs is wanting to ignore the PCI latency

idk, i think it'd be nice if we had something like gpu processing builtin

much wider use cases

@phantomics i did.

If you want the ultimate in speed use Fortran or ASM if not a GPU, but that takes orders of magnitude longer than writing APL. If your task only involves a few algos that must be as fast as possible, then the former options are the best way to go. If you're writing more algos and want to be done quickly, vector langs are better

well, now we wait until someone makes a gpu processing library for haskell (which already optimizes really well)

and a DSL for vector computations

and vector languages are basically legacy now

I think it would have been great if APL had taken some of the fortran market, but fortran is being modernised so that will probably never happen

5:02 PM

@KamilaSzewczyk That's the plan.

i'm really keeping thumbs up for dyalog

because only they have the power to keep apl still rolling

Is there a way to turn +/∘.= into an inner product?

@rak1507 What are your argument shapes?

two vectors of different lengths

No.

5:04 PM

@KamilaSzewczyk still.. standing (because backwards-compatibility) :)

that's what I thought

:(

@ngn velocity is relative

compared to what APL was a few years ago, APL may be close to it's second life

@KamilaSzewczyk maybe

@phantomics i hear the author moved to ascii later :)

5:21 PM

@ngn Due to the misery of supporting APL characters on mass-market computers in the 90s. By the time J released Unicode had solved the problem

I read that in the 80s there was a PC graphics card for APL with a physical switch on it that would toggle between displaying the regular DOS character code page and one with APL characters

@phantomics right. i wonder why j never went back.

J was designed around the G/G./G: triads.

@ngn drum roll ... legacy :P

@Adám it could have turned G. into a G with (for instance) an overbar, and G: into something else.. but a single char

@ab5tract j is not dyalog, the source is even under the gpl

@ngn that'd be a horrible idea

J builtins already make zero sense because of being restricted to ASCII, unlike APL glyphs

5:28 PM

@KamilaSzewczyk why is it a good idea for apl but horrible for j?

if you were to take this restriction and bring it back to unicode, it'd make as much sense as transcoding flac to mp3 128kbps and then back again to flac

@ngn J is required to serve it's previous users and documentation base. It's a weird position to take, acting like Dyalog is somehow nefarious for keeping backwards compatibility in a programming language.

Well, J does have some improvements over APL. (And some annoying quirks.)

@Adám agree

@Adám Presentation is unfortunately not one of them, at least to my eyes.

5:29 PM

@Adám absolutely

@ab5tract also true

after I learned APL and J to a certain extent, I prefer APL a lot

But isn't BQN basically the best of J and APL with a glyph set designed as a whole from the outset, and independently of 1960's printing tech?

mainly because APL has much better glyphs that make a whole lot of sense

@Adám "best" of j - boxed scalars? :)

@ngn Plus consistent leading axis orientation and agreement.

@ab5tract backwards compatibility at the expense of modernisation

5:33 PM

boxes complicate things unnecessarily

@rak1507 I don't get this at all. 18.0 introduced a whole heap of modernizations, and there have been plenty on the way to that version as well.

@ab5tract well yeah there are some modernisations, but there are still limitations imposed on what can be done based on legacy code

Go compare what coding in GNU APL feels like versus what Dyalog gives you.

@rak1507 That's the way it is for a programming language that has a legacy. I don't understand at all what you are trying to say. Name another example of a language which successfully broke with it's own past in terms of backwards compatibility to the extent that has been proposed here, I'd like to know.

@ab5tract k

I had a long talk with Geoff Streeter yesterday, and he was quite positive towards adding a ⎕EL that'd let code declare what Evolution Level of the language the code expects. This will allow fixing warts!

5:40 PM

@Adám what's the difference between that and ⎕ML

<moon-child> so now there will be four variables that influence interpreter behaviour?

<moon-child> that sounds ... ...

yeah, not a fan

moon-child: No, setting ⎕EL to a non-zero value would immediately disable all other variables that influence the language.

...including ⎕EL itself?

And ⎕EL would allow code using various versions of APL to call each other seamlessly, using a shared interpreter.

5:41 PM

that would be fun

So every library would begin by declaring language, much like HTML.

"this is a fix for the fix i made while fixing.."

No, it is basically equivalent to starting over from scratch with every version (AW style), while maintaining interoperability.

@Adám the first part of your sentence contradicts the second: "starting over from scratch" and "maintaining interoperability"

Nope, no contradiction there.

Every version of the language is free to break compatibility, but every version of the language can also call code using any other version.

You choose which language you want to use by setting ⎕EL at the top of your code.

@ngn How do I call a K4 function from K9?

5:49 PM

@Adám first of all, k9 is very different from other ks. i don't think it should even be called a k. second, why would you be paying for two different licences? just use the newer one.

it all comes down to the willingness to rewrite old code

k programs tend to be small and more easily rewritten than apl's notorious legacy

~~apl's~~ dyalog's

@ngn Your notion of that is completely unrealistic. Some places have tens of thousands of functions… The costs would be prohibitive.

@Adám unrealistic for apl (maybe), realistic for k

As it happens, I talking about APL here.

Of course, nobody is forcing you to use APL at all, and afaict, nobody is even suggesting that you do.

the more dyalog do this - religiously maintaining backwards compatibility instead of encouraging customers to fix their code - the more they sink into this trap

<moon-child> @ngn counterpoint: why should I waste my time rewriting older code just because atw decided to rewrite his language on a whim?

6:00 PM

@DyalogAPL <moon-child> Of course, nobody is forcing you to do that at all, and afaict, nobody is even suggesting that you do. :)

<moon-child> there should be a balance between kept and broken compatibility. Even c and perl have broken compat in the past

@DyalogAPL <moon-child> yes, there should (if you ask me)

again i agree with ngn, some features should start getting deprecated, dyalog should present clear and simple workaround for getting rid of them, and remove them in upcoming versions

this is like C++ and std::auto_ptr

and di/trigraphs

moon-child: So has Dyalog (and other APLs).

in modern C++ there is no auto_ptr, in modern C digraphs, trigraphs and implicit int don't work, simply

perl is a much more complex, in terms of arbitrary rules, language than APL

6:02 PM

@KamilaSzewczyk .. and c is an incomparably more popular programming language than apl

<moon-child> @KamilaSzewczyk the primary bits I was thinking of in c were vlas and k&r decls (as of c23)

@ngn yes, absolutely

Management even wanted to make a breaking change today, and I argued against it, instead suggesting making an additive change and deprecating the current stuff.

what kind of change?

also yes, the cycle you suggest is good

deprecate current stuff, leave it for a while longer, then remove it

look at how popular Java is, applets got yeeted, nashorn got yeeted, AWT will probably get yeeted soon

<moon-child> I've come to the conclusion that deprecation cycles aren't a great longterm solution, from watching how they play out in d. Small compat breaks are easy, but the big potatoes never get addressed

6:05 PM

@KamilaSzewczyk A very specific thing: changing the parent namespace of a namespace created by ⎕JSON from # to wherever ⎕JSON was called from.

i see

Actually there was another one today: Unicode file handling functions are not currently standards compliant when it comes to handling invalid byte sequences. We're discussing what to do, stay non-compliant or break backwards compatibility.

My position is that you should push as much as possible into libraries, so that if a library is seriously wrong you can switch to a new one. Large libraries can figure out versioning, but overall it's much less of a hassle than making changes to the whole language.

@Adám "stay non-compliant or break backwards compatibility" - to phrase it in more positive terms: "pro-compat or pro-spec" :)

Ah yes, the old pro-life vs pro-choice debate… Nobody wants to call themselves anti-choice or anti-life.

6:18 PM

exactly :)

Isn't it more honest to be upfront about the downsides?

@Adám not if you want to get a salary :)

I'm the only one who's salary could theoretically be affected, but I nevertheless chose to highlight the downsides.

in other words, are you pro-honesty or pro-pay? :)

Evidently pro-honesty.

6:21 PM

(to mirror what you did to one of my messages today) so you're anti-pay? :) joking, of course

7:12 PM

@Alexbries Hey there. Interested in APL?

7:25 PM

if I have two string matrices of different lengths, what's the easiest way to concatenate them so one is on top of the other?

Character matrices? Different "lengths"?

@rak1507 Different row lengths? If only the column lengths are different, then it's just ⍪ of course.

yeah different row lengths sorry

@rak1507 Same number of rows?

no

7:29 PM

Combining matrices with different row lengths is not really a natural operation to do. I think you want to find the common length and use Take to bring them both up to that length.

dimensions are 8, and 4 and 18

lol I just realised this is just problem 10 from phase 1 of the problem solving competition

8:15 PM

apparently java 16 has been out in early-access for a while, with vectors in incubator. On a simple isolated test I get a 1.5x boost on 32-bit int addition with overflow checking (just using the ((w^r)&(x^r)) < 0 check; 580ms→379ms for adding 65536-item arrays of 0…65535 10000 times. Dyalog's still of course much ahead at 280ms doing Smarter Things)

RGS

@rak1507 ↑⍤,⍥↓ ?

I ended up going with something like that yeah

RGS

Cool.

@dzaima Dyalog compares add to saturated add (a single SSE/AVX instruction) if I'm remembering right.

@Marshall doesn't seem there's a saturated add instruction :/

8:31 PM

@dzaima @Marshall PADDSB?

<moon-child> @ngn looks like only for 1 and 2 byte operands

@DyalogAPL <moon-child> yeah, right :(

@dzaima setting the first item in each arg to 1800000000 results in it still taking 150ms, which should be just the initial array allocating (which is immediately discarded)

@dzaima Ah, I thought I remembered having to do the bitwise version for something. I feel like I got it an instruction or so better than ((w^r)&(x^r)) < 0, but I don't remember how.

But it's also entirely possible Java's just compiling poorly.

8:47 PM

how do i juggle scope with eval?

if i use eval in dfn, then it seems like my variables are not accessible within it

heh, IotaShuffle

@KamilaSzewczyk wdym? {x←1 ⋄ ⍎'x+1'}0 works

in this code here, I get this error:

Undefined name: app, in {app ⍵}

so eval called app, and the app is delared, but for some reason it's not recognized>?

@dzaima Weird to include "shuffle" in the name. Shuffling like that is a good way to get fired from the casino.

Alex bries

@Adám i have no exp in APL, thought it was for codegolf in general.

9:08 PM

i think it's lost from scope after i recurse once?

what's interesting, after i remove the app omega part, and replace it with ⎕←⍵, then it prints the stuff

@Alexbries probably looking for chat.stackexchange.com/rooms/240/the-nineteenth-byte# maybe

so i think it's a problem with the scope

@KamilaSzewczyk i don't understand ⎕trap very well, but i know error guards (::) can forget variable bindings when triggered

maybe put ⎕trap after app←?

vec⊢←vec,⍵ can be vec,←⍵

9:26 PM

@KamilaSzewczyk Dfns use lexical scope, so they only see things that are defined where they are defined. As an experiment, try changing Stream into a tradfn to see if that makes it work.

9:39 PM

Is there a way to output to a file with ⎕NPUT without appending a newline at the end?

@dzaima I've now added some decent fill support to my BQN, and fill elements are finally specified. I haven't found any constraints that would be reasonable to specify, and I've kept the requirements down to things I think are easy to implement. But as usual I'm open to comments on the spec.

I should be adding tests for specified fills pretty soon as well.

Some fill examples, all working!

@KamilaSzewczyk why are you trapping specifically domain errors? and why cut back the stack with 'C'? documentation says with 'E' the trap should execute in the environment where the error occurred

@rak1507 No, that'd make a file that isn't valid as per POSIX. If you want to write raw bytes, you can use ⎕NAPPEND.

@Adám wow, didn't know that, weird

code_report

10:06 PM

@RikedyP re: APL event; i think a ton of great talks / things would be:
From Python (NumPy) to APL
Dyalog APL Major Additions (like what are the main things added in 18.0, 17.0, etc)
A History of APL (cover APL/360, APL2, MicroAPL, Dylalog, etc)
A (Very) Basic Introduction
(i.e. not the average fork or Conway's game of life, but just a walk through of very simple expressions)

this was a great talk that mentioned how "a generation of shape thinkers" was being lost - youtube.com/watch?v=ng-QNLdgQeY

10:21 PM

@dzaima it's definitely a bit broken though. With the same code, a function can consistently take 365ms, or >12000ms with no signs of improving. JIT ¯\_(ツ)_/¯

10:49 PM

ayy, this matches Dyalog in performance of sum with 7.5-8us per 65536 items (in the rare case when it doesn't take 400us avg, that is ಠ_ಠ):
https://dzaima.github.io/paste/#0jVLBauMwEL3nK@YoEyO6u0enhXTjZQ2GLQnkUkqR7UkiUCQjyak3Jf/ekUzbuCm0BzMevaenN09qu0rJGpwXnspGaqFgjbU3dtViLdHNCu1xi/YGijVcA3UDzFd3@e8iXz3eLfM/@XKZL7JJ@6VYafT2BsqgFH6/K6WIC67bE59J7e8foE/geQJnIqAOY9HKGtHUwnlWrlO4SjKiv7mH42iWI1rDivUHjqmIdOSiaQrdYM9@JFzoJhTXVVTGbAxsU3FtPIsQGQVJa1eh2RCDZdTPKEeujGlvTUdiPVeot36XEDa9jljsWTIMeH5CPfK8sWY/t1b8J@Mp9CnIeOpogBBJHU2b6gLFdxRf0RiiOoSZmTlwizQE2tain7uQrSNfl0y3sww/Z6fw6@ew5URfvEc7bLTYdDWWQqNjg6N/…

(I would definitely like to create a mini-language that either transpiles to java (or even straight to bytecode) to not have all that verboseness for vector operations)

@dzaima Oh, for reductions Dyalog just converts up from 16 to 32 bits immediately (adding adjacent pairs, maybe?) and adds about 2^16 of those at a time. That has the advantage that it's easy to support any bit width without extra overhead, but I'm not surprised your code is about the same speed.

@Marshall that was for already 32-bit int arrays

@dzaima Oh, "int" is so confusing. Not sure what I did for 32-bit arrays but I think it involved 64-bit sums in registers. If you care you should be able to watch Dyalog with perf top as you do a sum.

<moon-child> @Marshall that's ill eagle

@Marshall I barely can read regular assembly, reading dyalogs vector madness won't be particularly productive. (and i already match its performance here so it doesn't matter anyways)

I guess i'll leave more playing around tomorrow. Kinda sad I noticed java vectors this late :|

11:03 PM

moon-child: You're allowed to inspect the binary. It's a kind of reverse engineering.

I thought that was against the rules

<moon-child> @Marshall dyalog.com/uploads/documents/Developer_Software_Licence.pdf ‘You may not (except as may otherwise be permitted by any applicable Law) translate, adapt, vary, modify, disassemble, decompile or reverse engineer the Software’