long ago iKe and another project of mine, Octo, used github's anonymous Gist API to store programs. Then Github broke those APIs and started demanding auth tokens, like everybody does now, so I had to furnish a replacement
hyperbolic tangent is really useful for doing sort of a "fisheye lens" distortion on coordinates, atan2 is useful for converting polar->cartesian coordinates, and most of the rest I included for the sake of completeness
I was kinda shocked to discover that q doesn't have atan2
if you've never implemented a platformer before you're in for a wild ride. the special case stuff that is necessary to make such a game feel good and responsive involves lots of things that are not physically plausible
one thing I am curious about is the behavior of each on empty lists. why have #'"" return !0 when #'("";"") returns 0 0 and #"" returns 0? I guess the difference would be treating () as ,() when it's being each'd over
well, the only difference is that the fill value is specified (vs. being " " for strings and 0N for integer arrays; i.e. what you get by indexing out of bounds)
but I think i$y has always been restricted to strings in the various k's
(I feel that x$y and x#y have a surprising amount of overlap given the paucity of ASCII symbols)
Which APL/J/K variant makes it the simplest to write a network server (which implements some API) that's simple to deploy on Linux?
Also, which APL/J/K variant is the most stable and backwards-compatible? It seems like APL and J win out over K here if you take K as a series and don't freeze the language at individual versions like K6 or K9.
(can't even freeze K9 yet, b/c it's still in development…)
@JohnE not sure what you mean. if you have an old bug, you have two choices: either fix it (including docs) or deliberate ignore it to protect existing code that may be relying on it (the dyalog way). in either case documentation should be reflecting reality as clearly as possible.
What I'm getting at is that the documentation for users of your language is not just the official reference docs (which should obviously be kept up to date) but also materials created by the broader community. The more aggressively you break things, the less surrounding material remains useful
I mean, a not insignificant number of people learned K through either the materials at NSL, the Kona wiki, or my oK docs, none of which are remotely official
I guess it's a question of where the users are at. if there are millions of lines of legacy code that are (mostly) happily humming away, breaking changes are anathema. if the domain is fresh/undefined enough, you have javascript-framework-of-the-week (which I believe has died down a lot in the past few years, but was quite hectic circa 2015)
then there's how well the transition is handled; with I guess deprecation warnings far ahead of time, what happened with python 2 => 3, or I guess the various updates to the C standard (C89/C99/C11)
right, bugs in popular software like browser bugs take a long time to disappear. but in apl's case we're talking about a hundred (hundreds?) active users worldwide. practically, they all know each other.
@coltim they changed a bunch of stuff in the spirit of making python a more "mature" language, completely forgetting that the appeal at the time was python's supposed beginner-friendliness. (imo python is a terrible language for beginners, but that's a separate rant entirely.) Modern python continues to fester and grow more and more special-cased sugar features while still being fundamentally hamstrung by poor decisions early in its life
in a few decades I am fairly confident that at best python will be regarded like R: a nutty, half-baked mess that is strangely blessed with a desirable library ecosystem. At worst, it is how many people today view COBOL: highly arbitrary legacy code which is unpleasant to modify
it introduced a generation of programmers to a whole pile of terrible ideas like semantic indentation and it cannot die soon enough
shakti is actually a departure from first-class functions too. see @chrispsn's write-up from earlier today. sections 1 and 2 essentially describe that. sad to read.
e.g. 123_x removes 123 from x, but (mod)_x doesn't remove the function mod from a list that could potentially contain it. it does something completely different.
@chrispsn something that only recently "clicked" for me was the behavior of grade up/down and where on a dictionary; sure, the result of returning the keys of the dictionary was useful but it wasn't until I figured out that built-ins that return indices (grade up/down, where, find) instead return the dictionary keys (which play the role of the array "indices")
it makes the rationale for !list returning !#list stronger, as a parallel for !dict returning the keys