snapdangle
Joined 12 years ago
Joined 12 years ago
There were also no functional methods available, as related by the restriction to C-style for loops. (Array Iteration methods didn't appear in the spec until 2009, so I don't see how you could have map or select or anything else functional).
Your description and summary blocks have started me wondering... has there been much work done on converting APL statements to more verbose explanations?
The sigil-to-meaning mapping is likely automatic for seasoned APL programmers but it might make such one liners more effective for evangelist purposes by making them somewhat more self-documenting.
I've been looking for a good "diff" of the language differences between Dyalog APL and GNU APL, as much as to understand the extent of the progress since 'APL2' (or whatever the ISO standard name is considered equivalent to it) as any for any specific list of what GNU APL can't do relative to it's modern commercial compatriots.
(EDIT: Fixed final sentence to be a complete thought/sentence).
When dealing with high performance computing or real time processing of high volumes of data, any fetch to RAM for loading a function call to dispatch is going to have _some_ impact in a tight loop. Add that up for all the libraries you have loaded for your application verses a ground up implementation in K... Does that whole thing live in L3 along with the VM or intepreter + dependencies underneath it? It's doubtful.
My experience was simply using their Kx's free Developer IDE and experiencing the performance differential on datasets myself. YMMV but my (admittedly limited) experience leads me to believe that there is a serious case to be made for the performance advantages of having all your computational logic living as close to your computational cores as possible.
See also the PhD by author of the OP article where he presents language where:
"The entire source code to the compiler written in this method requires only 17 lines of simple code compared to roughly 1000 lines of equivalent code in the domain-specific compiler construction framework, Nanopass, and requires no domain specific techniques, libraries, or infrastructure support."
Linked from the article, available here: https://scholarworks.iu.edu/dspace/handle/2022/24749
EDIT: They also discuss how the upcoming convergence of .Net Framework and .Net Core is going to have a major impact on their cross-platform capabilities.
Meanwhile, the supposed collective knowledge in books is constantly second guessed and taken with grains of salt ("bronze age army sizes couldn't possibly be the size they write that they are", "the winner writes the history", etc).
Otherwise it comes off as more cheap shots. Thanks for adding your comment, though! It helps :)