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
