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 <adrien.lc.math...@gmail.com> 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
