In J, there’s a single compound data structure (henceforth, CSD): the rectangular homogeneous array of arbitrari dimension. What’s so bad about having only a single CSD?
Many languages start with the associative array (henceforth, AA). In D, for example, you have types T[S] where T and S are types. [Oftentimes, AAs are implemented as hash tables, best known AA flavor.] They usually provide custom syntax and specialized implementation for, in the D syntax example, T[int] with indices starting from min ℕ, for whatever that means to the language (usually, 0 or 1). Those are called arrays. Many other languages start with nothing but arrays and AAs, as well (cf. Perl sigils @ and %, for example [yes, I don’t raku yet]). I’ve never heard as harsh complaints about, for another example, lua having only a hash-table-array-hybrid – let’s call it a hash table: you can imagine the array part of it as syntactic sugar with good performance. No, it doesn’t hurt a language to have been built with a single CDS at its core. Am 14.04.21 um 13:45 schrieb Julian Fondren: > The complaint isn't "a program like that can't be written", or the > argument would be that J isn't even Turing complete. The complaint > is "I can't write a program like that in the manner I'd like." > > Quotes: > > * No non-array data structures: hash tables, trie, graphs, etc. This > is a show stopper because so many problems are easier to reason about > and to solve by picking a more suitable data structure. > > I reason about those things in terms of mathematics and abstract > structures: I'd venture to say that's par for the course because its > easiest. > > Suppose you want to translate a program you've written in a non-APL > language into J. Much of the program can simply be transliterated, > page-into-sentence, without much concern for the overall design > of either program... unless a non-array data structure is very > important. Now you have to think about how precisely the original > program is using the data structure and how you can do that in some > other way in J. > > The same speedbump shows up if you're following a tutorial, or trying > to implement an algorithm according to a book or paper's description: > as soon as a non-array data structure's properties become important, > there's an abrupt increase in the difficulty of your task and of > the depth of understanding of the problem domain that's required of > you. > > The abruptness is off-putting all by itself. Imagine a language where > + - * are all available but % isn't and the response to wanting it is > 1. have you considered solving your problem without division? It's > very expensive! With a constant denominator and fixed-width integers > it's even possible to divide *with* multiplication by a magic number. > 2. you can implement it yourself (with unusually bad performance) > 3. you can get it from the FFI > 4. is this so weird? ARM processors don't have % instructions. > > Yeah, it's pretty weird. Not having hash tables has also become weird. > > On 2021-04-14 05:25, ethiejiesa via Programming wrote: >> It's not J, but FWIW Dyalog APL apparently can boast this realistic, >> immersive simulation of some piece of Finnish coastline. The 3D >> engine is an external dependency, but supposedly everything else is >> straight APL: >> >> https://www.dyalog.com/case-studies/simulation.htm >> >> Since the core of that project is taking large amounts of data, >> scattered in lots of non-uniform formats, and munging it into a >> concrete realtime visualization, you might find it >> interesting/inspiring/helpful/whatever. > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm -- ---------------------- mail written using NEO neo-layout.org ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
