@arcfide yes I'd say I"m familiar with the basic APL syntax, what I'm unfamiliar with is certain operators, and how operators are used. I can read a train just fine. I just often don't know this operator or that operator, like how right tack is used, or the various quad operators are used.
What's more is that I don't understand number theory to the extent that it would seem required to write APL effectively, because as it appears from attempting to write "vector oriented" solutions, as opposed to functional, recursive, iterative, or object oriented solutions, one would need a firm grasp in number theory or some other form of category theory or linear algebra
@nathanrogers I suppose you by operator mean glyph (or in APL terms: primitive), and not APL's specific use of the word. Obviously, you'll have to get familiar with the most common primitives, but that comes fairly quickly for the most common ones. ⊢ Is actually the very simplest of all functions. It ignores any (though optional) left argument and returns its right argument; equivalent to {⍵}. It is use to access the right argument in a tacit function, and to separate arrays.
to add to the above - ⊢is equivalent to {⍵}. It is. There's nothing special about it (nor about {⍵}, it's a regular simple function). It is that simple
it's not the math that's slowing everything down. It's literally everything else that has to happen.
for each character it goes trough this while loop at least once (every other char twice I think), and each is call is this thing which goes trough the given string and inefficiently goes trough a LinkedList.
dyalog has "cmpx" (if I remember correctly) which can compare the performance of multiple expressions and it's smart - it increases the number of iterations exponentially until the time goes over a certain threshold
⎕io←1 ⍝ doesn't work with 0
(⎕NS⍬).⍎'⎕CY''salt''⋄⎕SE.UCMD''←box on -trains=tree''⊣enableSALT⋄⍬'
(⎕NS⍬).⍎'⎕SE.UCMD'']runtime -compare 1+1+1+1+1+1 10000⍴123456'''
@ngn an old version of my fds, JS APLifiying functions, a python program to transpile BF to C++, some tio links to stuff for homework, and more TIO links. I think that's really the only important thing there :p
@dzaima my point was about being able to intuit the relationship between numbers and their properties to solve problems by "vector oriented" as opposed to algorithmic means. The bracket balancing solution uses a lot of hokey math to accomplish the balancing. Things that I'd never have been able to intuit to arrive at that solution.
And if you look at the rover solution in the jugalbundi, it appears to be much the same. hokey relational number bunk that I would never have thought of because I don't know how to see problems through relationships between numbers
In mathematics, the Iverson bracket, named after Kenneth E. Iverson, is a notation that
generalises the Kronecker delta. It converts any logical proposition into a number that is 1 if the proposition is satisfied, and 0 otherwise, and is generally written
by putting the proposition inside square brackets:
[
P
]
=
{
1
if
P
...
@nathanrogers My father taught me f.g on two matrices using fingers on a paper, but that's a bit hard to do over chat. Let me know if APLX's rather extensive description doesn't work for you either, and I'll try to explain what to write on a paper and how you should move your fingers.
about this question of why +' is flip each as the projection never seem to be that useful for plus, i would say it is just consistency k is designed to know monad/dyad at parse time, not runtime
without parameters it's the dyad as i think that's more useful for adverbs like +/ and +\
it would be confusing to have a exception for a different adverb (')
Regarding the concern about intuiting "APL solutions" to problems, people should be patient with themselves. Remember that most people take years to develop a strong intuition for the construction of efficient, effective solutions in normal programming languages, often requiring years of learning to truly grasp the intricacies of the nature of control flow and process through University C.S. programs.
This intuition for process is not easy or common for the average person, and APL is accomplishing the same things with different techniques than is standard. They aren't hard, but they do take time to appreciate and learn to a sufficient level to intuit solutions using them.
2
Indeed, I feel that prior programming experience can even make the process of learning APL solutions more challenging.
furthermore, I'm finding that there are parts of K and J and APL that I think are much stronger than other parts of each respective language, and there is some synthesis of these languages which would be more succinct and expressive than either of them individually
@nathanrogers The world is filled with the mutated remnants and sometimes still extant half-solutions of people who thought they had understood how to "make a better APL" without truly understanding APL.
K and APL may appear to be similar, but they are in fact very different, and trying to cherry-pick from these languages is usually the first sign of trouble.
what I'm saying is that there are parts of K which are more intuitive than APL, parts of APL more intuitive than K, and parts of J which are more sensible than either
And I'm saying that the word intuitive and what it means to people can be very deceiving. I'm sure you find certain things easier to grasp initially in any given language, but that doesn't necessarily imply that a synthesis of these parts would lead to a better language, or a stronger one.
Indeed, this is perhaps more true within these languages than in others.
They are deeply holistic designs. It's a common historical problem, IMO, to see attempts to explain APL or K or other languages in terms of this feature or that, when in reality, I think that what they deliver is not a matter of their syntax or semantics, but in the particular emergent qualities that derive from the complex interplay between these features that in and of themselves are nothing special.
That's why I think the caution is warranted. It's easy to feel that the things you found more "sensible" in one language or another represent a strength of that language, which may or may not actually be so.
Indeed, talking about "parts" of any of these languages is very difficult.
I think that the designs of APL, K, and J are difficult to take "in part."
Sorry, I'll get off my soap box now.
I'll try to save the preaching for my blog.
@nathanrogers How long have you been playing with APL? Do you have a "favorite" so far?
i came to apl and have come back to apl through a strange series of circumstances, initially in an effort to create a syntax for common and simple array methods. then I found k, the attempted learning of which lead me to the full history of k, j and apl. I prefer J, but i found it's lack of support discouraging.
i recognized quickly that between iverson, whitney, and hui, I had no chance of designing anything more consistent or efficient than what was already available, but at the same time, bemoaning the fact that I'm not really gaining any marketable skills in my field, and indeed alienating myself from software engineering in general
I think it was morten kromberg that said that software types are often offended by the sensibilities of this trifecta of languages. and it has proven to be the case thus far in my experience
but that was the point of the language I was attempting to design, only to recognize that APL had already been around since the dawn of computing, had its golden age, and fell out of favor in the world of computer science
My reading of things is that it was popular with those tangential and related to the field of C.S., but the core C.S. departments never thought highly of it on the whole.
you see the code that some people write in explicit for loops, with all of its mutation, it's incredibly pathetic, because they don't teach pragmatism and languages often don't enforce, nary even encourage proper direct reasoning
I think that's a complaint we can have right now because of where we are with computing hardware, problems, and C.S. implementation theory. I don't feel that we would have had the luxury to complain about such things in the 80's with nearly as much strength.
it's directly as a result of the mode of teaching that computer science has adopted. Yes algorithmic design and analysis a.k.a. knuth is profoundly important, but algorithms can be further generalized and simplified by abstracting iteration into operations like APL has
in particular, I write most programs through lambdas and array methods
why bother having them at all. the same reduce by addition or boolean, the same filter by this = that, the same map by adding n
I think a lot of that comes from the lack of growth in C.S. education as a result of OOP retardation in the exploration of algorithmic expression during the 90's, leading to a deep period of recovery both in terms of hardware and pedagogy that has only recently (in the past 10 or 15 years) given us the opportunity to begin to realize a vision that was put on hold in the 80's.
why bother? why don't language designers come to recognize that the fundamental unit of operation in computers is done on lists and arrays, not on individual values!
which is where the weaknesses of the vector languages reveals itself, because in order to leave the vector space into other datatypes is completely unintuitive and often painful
In particular, that compiler is the research artifact (still in development) that will eventually be published under my dissertation, "A data-parallel compiler hosted on a GPU" or something like that.
In short, APL is an excellent language for trees.
It's a common misconception that APL and array languages in general are poor tree languages. However, I would instead assert that the way that we think about trees, particularly the insistence on isolated data abstraction and recursive iteration patterns that are neither conducive nor natural to execute on modern hardware, is in the same class of mistakes as is the emphasis on for loops and explicit iteration that you lamented above.
Indeed, the vocabulary for working with trees finds a nearly direct expression in APL coupled with a few simple to learn idioms and traditional array techniques, enabling short, concise, and direct expressions of tree algorithms directly in APL and other array language without any need for excessive data abstraction.