The difference is that in the languages you list, an associative array is mutable. A mutable object can be shared, and changes to one copy are reflected in others. Immutable data is easier to reason about, making it a better default, but mutability is essentially required to implement many algorithms efficiently: Dijkstra's algorithm is probably an example. Languages that have only immutable data structures might provide mutability using lexical closures, but J doesn't have these: its only non-local variables are locale-scoped. This means that locales are the only mutable thing that J offers, and these aren't first class as they can only be referred to by strings or numbers.
In J the only two ways to create mutable objects that can be passed around and updated efficiently are to (0) pass references that refer to global data, which must be stored in only one place so it can be updated in place, and (1) use numbered locales as objects. These are both very unpleasant from a syntax perspective, 0 becomes much more difficult with more structured data. Much worse, both of them require the programmer to do their own memory management or write a garbage collector to avoid leaking everything. This need for garbage collection is inescapable: J manages memory with reference counts, meaning that if there are two values so that either one can be used to "find" the other, each must have a reference count of one and can never be freed, even if the pair isn't reachable from the rest of the program. Marshall On Wed, Apr 14, 2021 at 03:00:42PM +0200, Hauke Rehr wrote: > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
