@ Emir U: Does anything-at-all fit your 4 requirements? Or is on its way to doing so?
This is not meant as a put-downer. I'd really like to know. I'm in the same situation myself (I'll go into details – on Chat – if anyone dares me to) – and maybe you've asked exactly the right questions for some generalized problems facing not only J-ers, but all coders working with >1 platform and >1 language. For this I thank you. Take FFI for instance. Apple, whose key USP is drawing simplicity out of complexity, owns both Objective-C and Swift. Yet IMHO they have completely fouled-up the FFI of interfacing code written in these two languages – not to mention porting an app between macOS and iOS. And - hell! haven't they tried! If Apple can't even do it for languages and platforms they totally own, what hope for the rest of the world? You wrote: > a formal system for the packing, versioning, deployment, and dependency management of code That's a commercial battleground. Who has the motivation to develop such a formal system? Except as a fighting machine – to trash the competition? I've yet to see a good formal system for nothing but cross-platform GUI development – and that particular dependency problem is at least 30 years old (…I remember the conference.) The most promising line was watched variables: which strips out of the host language (APL then, J now) anything like (wd) or indeed any representation of screen furniture. The result? NO GUI dependencies. You also wrote: > This is a show stopper because so many problems are easier to reason about and to solve by picking a more suitable data structure. Most of us learn to reason about optimization, monte-carlo methods, AI and data mining by deep experience of one programming language. If it's J or APL, that alas shows one's age. Today's whiz-kiddies seem drawn into the vortex of Python and Anaconda – why? I don't want to go into it here, but it's not because Python is any advance on J. But, inevitably, making headway with fashionable problems gets one addicted to dated tech. And – dare I say it – dated data structures. We'd laugh at someone rejecting J in the 21-cent because it has no support for TSO, interfaces badly with Lisp, Prolog and SNOBOL, and makes a meal of accessing an IMS database. Yet these were serious considerations for using APL (J's forerunner) in academia in the 1970s and 1980s (…and yes, I do speak from experience. Harsh experience). 40 years on, and *plus ça change, plus c'est la même chose.* You've laid out a shopping list that could have been demanded by someone trained up from scratch in the Anaconda world (…I'm only using it as an example: maybe you have, maybe you haven't) – with experience of little else. How many of these requirements are genuinely timeless, and how many reflect the (transitional) technology you've grown accustomed to? To crystallize what I mean by "timeless", how many of them will survive the impact of QC? It's a question I ask myself concerning J, having played with IBM's QE lab …something I'd commend to anyone with 50 hours to spare like you've had. I've seen J / APL touted as having unique advantages over C-type languages on contemporary multiprocessing platforms. But will J enter the world of quantum parallelism with any advantage over C? I conclude: no. Nothing prepares today's parallelism experts, who juggle with threads and semaphores, for the replacement concepts of decoherence and CNOT. Which brings me back to my opening question. Ian Clark. On Mon, 12 Apr 2021 at 10:06, Emir U <[email protected]> wrote: > I've invested something around 50 hours in J, I tried to write half a > dozen serious algorithms, and to bind some external libraries. I've > concluded thereafter that J just doesn't fit my workload. Here are my main > reasons for giving up on J for now in hope that it helps with future > direction: > > * Package management and batteries. The addon eco-system is tiny and the > packages in it are barebones at best. This is scary because it takes no > time at all to find things you need that you can't implement yourself > quickly. E.g. loading an Avro/Parquet/ORC file, run simulated annealing, > fit a Bayesian model using hamiltonian multi carlo, write a linear > programming optimisation, call Neo4J, and so on. I'm use to being able to > expect that what I need will have a package for it already. Other languages > get around this a bit by either using a common VM as more established > language (e.g. Clojure) or by having very ergonomic FFI (e.g. Julia with > Python). Further, I think there needs to be a formal system for the > packing, versioning, deployment, and dependency management of code, else > people will revert to literally copy pasting all dependencies into a > directory to make sure their code works on another environment. > > * FFI. When the function in question takes a C struct or an otherwise > complicated data structure then you can't easily call the function from J. > It seems you have to write a bunch of C to convert the target interface > into something that can be called more easily from J. Contrast this to > Julia's Python FFI interface as an example, or Rcpp in R. > > * 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. In the Wiki, Dan Bron > says: One of J's primary advantages is that it makes (array) programming > easy. If its notation is inapplicable to your problem (more or less), > there is not much reason left to use it. This lead me to dismay. > > * No parallelism. This is a show stopper. I work on large data and hard > problems which cannot be crunched quickly on a single processor. J > seemingly has no multi-threading, multi-processing or GPU support. > Parallelism for me is almost always more complicated than just splitting > the data and running the same thing many times, so J offers no way to solve > problems needing parallelism that can't be emulated at an OS level by > running many copies of a script. > > So its farewell for now, but I'll keep an eye on developments in hope for > the future! > > Emir > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
