Good point, you’re absolutely right. I totally neglected that. And it does matter.
Am 14.04.21 um 16:28 schrieb Marshall Lochbaum: > 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 > -- ---------------------- mail written using NEO neo-layout.org ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
