Adrien, thanks for your insights. It's helpful to have fresh eyes looking at J.
I agree with much of what Raul says though I think number 4 misses Adrien's point. I think he is referring to options specific to jconsole that would trigger different behaviors, like showing some basic help text or a version number, not to user-processed arguments which are found in ARGV as Raul says. I personally default to spaces as a prompt whenever I have the option to set it as I think the benefit of being able to pull code out of a session without having to remove prompts is most important to me but it would be fine to make this customizable. There is a lot of organizational work that needs to be done with addons and such though I am unsure of what distinguishes a library from an addon. Also, I see no harm in changing J's behavior when supplied a script to make it more like other interpreters. Some of what Adrien says is *nix-specific but it should be fine to follow those conventions more closely for those platforms. On Mon, Nov 21, 2022 at 1:01 PM Raul Miller <[email protected]> wrote: > Here's my take on the issues you raised; > > (1) *.j refers to java source files > > (2) On some systems, jconsole is instead named /usr/bin/ijconsole > > (3) J's default script error behavior is somewhat analogous to > dropping into a debugger on error. This is probably about right for > casual scripts. But, of course, it does allow other possibilities. > Consider, for example: > https://rosettacode.org/wiki/Multiline_shebang#J > > (4) J's ARGV holds the command line arguments. > > (5) I suspect that colorizing (or some applying some other style > difference to) command lines in a fashion which is different from > output lines would be more ideal than a prompt change. That said, > implementing this might take more effort than changing the prompt > itself (there's a variety of subtle issues here). > > (6) I routinely install J in a location other than my home directory. > I agree that packaging J with a script would be an issue. > > (7) We do need to think more about addons and libraries (including > github hosted addons). > > (8) CLI editing tends to be highly personalized. It might be nice to > re-implement readline using native J. > > (9) We have wiki talk pages. There's also an active APL discord (with > a Matrix bridge) which has a J channel. > > Hopefully I have not been too conservative, here. > > Thanks, > > -- > Raul > > > > On Mon, Nov 21, 2022 at 10:51 AM Adrien Mathieu > <[email protected]> wrote: > > > > Hello, > > > > I have been learning J for quite a while now, so I start feeling > > comfortable with it. However, I'm not using it in my everyday life as > > much as other programming languages for reasons that, I feel, are pretty > > dumb: the language in itself is great, but IMO the naming convention of > > the tools around it are bad; and compared to other interpreted > > languages, J's interpreter has a very poor interface / default behavior. > > I though about simply patching what I feel like is poor behavior, but > > I'm not even sure my PR would be accepted, so this is why I am writing > > on the forum. Am I the only one who feels this way, or would the J > > community be happy about such changes? > > > > To do so, I will list here some major issues I have in my workflow with > > J, and I will try to provide some comparison examples with other > > programming languages that. Feel free to comment on whether any of these > > feel relevant, or utter nonsense, or anything else. I enough people seem > > to like any of these changes, I'll try to implement them; however, since > > I am not very familiar with C, and I am not familiar at all with J's > > sources, it might take a while: if you are inspired, don't hesitate to > > implement these changes yourself. > > > > The issues aren't given in a particular order, some are more impactful > > than others. > > > > * The `ijs` extension. As far as I know, J used to have a `js` > > extension (which stood for J Script), but for obvious reasons this > > had to change, so it now uses `ijs` (which stands for Interactive J > > Script). I don't understand why J's extension is not simply `j`. > > After all, several programming languages whose name is a single > > letter have that letter as their extension (C, C's headers, Q, B, D, > > ...). Furthermore, I don't think a script is an appropriate name for > > a library, and it's even less appropriate to say it's "interactive". > > Finally, as far as I know, the `j` extension isn't used for anything > > else (in an impactful way). This change can be made in a > > backward-compatible manner (continue to accept `.ijs` files, maybe > > issue a warning about that extension being deprecated, and change > > the documentation so that `.j` becomes the official way to name J > > files). > > * `jconsole`. Similarly as before, there has been a name conflict with > > a Java debugger thing, and since Java won by popularity, it is now > > sometimes shipped as `ijconsole`. All the interpreted programming > > languages I can think of simply have the name of their language as > > the shell command to invoke their repl, why not J? Incidentally, > > this would bury the Java clash thing once and for all, which is > > quite problematic for packagers who can't rely on the name of the J > > interpreter being jconsole or ijconsole [for instance, in the Linux > > distribution I use, the REPL was shipped as jconsole, but the J > > plugin for my text editor tried to invoke it as ijconsole]. Some may > > say that a single-letter command is not a good thing. I did some > > research about that, I couldn't find any other command that is > > simply `j` and, furthermore, I found that Q's [a programming > > language similar to J] REPL was simply named `q`. Other alternatives > > could be `jl` (as in J Lang, which is also the naming convention of > > Clang, whose command is `cl` — and many programming languages append > > "Lang" to their name to clarify what they are [see julialang.org for > > Julia, rust-lang.org for Rust, Clang for C]), `ji` for J Interpreter > > (as opposed to the J compiler [see > > https://github.com/mattjquinn/jcompiler]). This change can be made > > in a backward-compatible manner, just distribute the REPL under the > > two names, optionally making it issue a warning when using > `jconsole`. > > * Jconsole does not automatically exit when launched with a script in > > argument. I understand why this works like that: it's easy to debug > > a program, and it's easy to load a local library. However, this goes > > against the behavior of every other interpreted language: when you > > run a script, you don't expect it to additionally hang waiting for > > the `exit` instruction. Conversely, adding `exit''` at the end of > > your scripts make it impossible to load them as-is from within the J > > REPL. The behavior that I expect is that, if Jconsole is fed a > > single positional argument, then it must be a J script, which it > > runs, and then simply halts (as Python, Ruby, Scheme, Racket, Perl, > > Awk and all the others do). Otherwise, the REPL is started. If you > > want to load some scripts in your Jconsole session, use a named > > argument, like `jconsole --load myscript.ijs --load > > somethingelse.ijs`. This change would not be backward-compatible, > > but I don't feel it would be too bad, since I don't think any > > automated tool relies on the fact that you enter an interactive mode > > after having executed a J script, if it didn't call `exit` somewhere. > > * Jconsole doesn't have arguments. I know this can be a bit of a pain > > to implement at first, but nowadays it's really not that hard > > anymore to parse cli arguments in a proper way, and it's almost > > mandatory to at least have a `--help` with a brief description of > > *at the very least* what the command is, and a `--version`, which > > indicates which version of the software is installed. In addition, > > having arguments would allow the command to be a bit more flexible > > (see the issue above for an instance where arguments would be > > helpful). All the (decent) commands on my machine, or that I've ever > > tested, comply to this simple convention. This would obviously be > > backward-compatible. > > * Jconsole's prompt is spaces. This is usually not an issue and, in > > fact, is pretty nice once you get used to it. However, sometimes > > (when you are otherwise printing a lot of stuff), it makes sense to > > have the prompt stand out a little more. Currently, I'm not aware of > > any way to change it (besides patching the source code). Other > > prompts that would not be confusing would be alphabetical characters > > followed by a dot, since that would otherwise be parsed as a > > reserved keyword / builtin anyways. For instance, the prompt could > > be `J. `, `j. ` or `repl. `. Note that Q has a similar problem, and > > their prompt is `q)`, because that couldn't be code, but I > > personally don't really like it [see xkcd.com/859]. This change > > would be backward-compatible, because no (sane) automated tool > > relies on the prompt of an interactive command which has a > > non-interactive mode. > > * J's directories. J is the only language I know that occupies my home > > directory (with stuff like j903-user). On a Linux computer, that > > should definitively go into `~/.local/share/j` and `~/.config/j`, or > > maybe something like `~/.jrc`. > > Also, J's installation directories are a bit messed up. I'm not > > exactly sure what J expects, but when the binary wants a file named > > `profile.ijs` in the same directory, which in turn instructs J to > > find a directory named `system` in the parent directory. This is > > clearly not compliant with the FHS, because I expect the binary to > > be in `/usr/bin/jconsole`, the file `profile.ijs` (which looks like > > configuration) to be somewhere like `/etc/j/profile.ijs` and the > > `system/` directory, as with the `addons/` library, to be in > > `/usr/share/j/` (or maybe in `/lib/`). This kind of issues then > > hinder the packaging of J, which in turn make it hard to use it in > > my everyday life. > > * Packaging of add-ons. (Some) add-ons are, in fact, libraries. As > > such, their packaging should be left to the user, who should > > delegate this task to their favorite package manager. For instance, > > Python resolves finding libraries using the directories in > > `sys.path`. `sys.path` is populated, in turn, by: > > - the current directory; > > - directories in `PYTHONPATH`; > > - the default directories provided by the installation. > > This means it's easy to make installed libraries available, no > > matter who or what installed them, it's reliable and it's easy to > > understand what happens, and what to look for if a library is not > > found. Furthermore, Python ships with a minimalist package manager. > > If you want to use it, fine, it works. Otherwise, use whatever tool > > you want. J could still provide a package manager, as it currently > > does, but it would be great if J didn't assume every package was > > installed by it, or otherwise installed by mimicking by hand the > > behavior of its package manager. This issue, as well as the previous > > one, make it really hard to properly install and tweak J. > > * Jconsole doesn't have many (quite) standard shortcuts. Most > > word-skipping shortcuts that are usually available in a cli > > application (such as Alt-F to move forward of one word) will only > > trigger a newline in jconsole. This happens so often to me that I've > > stopped trying to edit a wrong expression, I just rewrite it > > entirely in fear that a shortcut would actually trigger an > > evaluation of the expression. Most modern cli applications support > > these, including python (and all its improved REPLs), racket, but > > not scheme, which just inserts the escaped version of the shortcut. > > * (this is not directly related to the implementation of J) Mailing > > lists are a good thing, but more modern solutions actually exist. > > Since J has a website, whose development seems to be quite active > > (the online IDE for instance is quite impressive), I think it would > > make sense to have a web forum. Free and open-source software for > > this kind of purposes, like Discourse, exist, and allow the > > integration of a mailing list: the forum offers the possibility to > > produce a digest like in a mailing list, or simply to receive > > messages and to answer through mails, completely transparently (that > > is, without any difference from a user who would simply use the web > > interface). > > > > I am open for any remark on this list, including addendums or criticism. > > It's because I enjoy a lot coding in J that improving its ecosystem is > > important to me, so anything that goes in that direction is welcome. > > > > Sincerely, > > > > Adrien > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > -- Devon McCormick, CFA Quantitative Consultant ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
