I like your idea of jconsole running scripts and exit automatically. I think this can be implemented using a new command line option like -bye or others.
On Mon, 21 Nov 2022 at 11:51 PM 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
