Well, look… some first principles here.
You know, it’s really not terribly serious to talk about what is straightforward and usable (transparent is the word you use, but it amounts to the same thing, no?) in this kind of flippant way. The major company that comes to mind that has always taken useability (user-friendliness, they might say) very seriously is obviously Apple. My understanding is that Apple has a whole human factors research center where they really test empirically the useability of human interfaces.
I mean to say: nobody who is serious about these issues allows the engineers themselves to define what is user-friendly and what is not. It is an empirical question that must actually be put to the test!
Now, granted, we don’t have the resources of Apple (or Microsoft or even IBM…) but still we can focus the question somewhat empirically. At various points, I have tried to scan over the various projects that use JavaCC and figure out how it’s being used – what the typical usage patterns are. A few months ago, I was wondering how many of the projects that use JavaCC also make use of JJTree. I used various strategies of googling to try to get a rough sense of this.
Without going too much into boring detail of how I came to this estimate, I concluded that it’s about 50-50. About 50% of the projects that use JavaCC out there use JJTree and the other half do not. It is something like that. Now, 50% might seem like a lot, but my strong belief is that this kind of tree building (combined with the visitor pattern tree-walking) is the typical usage pattern of this sort of tool, so, one could expect that something like 90% of JavaCC users would also be JJTree users. But that is far from being the case. So, this tends to reinforce my view that JJTree has some very major useability issues.
And this all kind of forms a whole in my mind. I also recall quite distinctly that, when I was simply an end-user of JavaCC, at a few points, I pondered whether to use JJTree, and always ended up rejecting the idea. The basic idea was okay, of course, but it just had these severe useability issues. Once I started working on the code, one of the first things I set out to do was to address these problems with JJTree. (I have to admit that I barely ever even looked at JTB, but… most people didn’t…) But all of that is the origin of the
I would add also that I am pretty confident that, as we move forward and the JavaCC 21 user base grows and we have enough of a sample size to draw some conclusions, we will see that the vast majority of JavaCC 21 users (90% or more, I would venture the guess) will use the automatic tree building. (This is a conjecture an remains to be seen but I think it is a cinch bet.)
(By the way, I think it’s also a cinch bet that any new users (I.e. with no previous JavaCC experience) will opt to use the newer streamlined syntax, probably at something like the 99.9% level!)
So, when tree-building is the normal usage pattern but about half the users of a tool opt not to use the tree-building facility that is part of the package, this surely says some things about the tool’s usability.
Now, you do make a valid point (as far as it goes) that tooling can make quite a significant difference in useability. Well, it depends on the case, of course. Typically, tooling, like your Eclipse plugin, say, can mitigate some of the existing useability problems but probably not eliminate the problems completely.
But, okay, I certainly don’t dispute that it can make quite a big difference. So I grant that… (Of course, other useability issues can only be addressed in the core code, however. For example, all of the relatively recent work I did towards making the whole LOOKAHEAD construct more useable is work that can only be done in the core codebase. For example: https://javacc.com/2020/07/31/new-feature-for-scan-up-to-here/)
But the question of tooling leads us to a rather delicate (maybe even embarassing) sort of question now.
I mean, I assume that when you talk about creating a .jjt or .jtb file “in an IDE”, you mean in Eclipse, with your JavaCC plugin enabled. (Correct me if I’m wrong.)
Well, fine, but surely you understand that this discussion forum that I am trying to develop here exists for the purpose of discussing the latest version of JavaCC, i.e. JavaCC 21. It really seems that, unless you are going to make some clear commitment to supporting the up-to-date feature set of JavaCC 21 in your plugin, it is really rather pointless and possibly in dubious taste to be going on about your plugin.
People who want to use JavaCC 21 presumably want a plugin, tooling generally, that supports the up-to-date feature set. A JavaCC plugin that does not support the improved streamlined syntax, or even the things I added over a decade ago, like
INCLUDE, this is simply not useful to somebody who is trying to get going with JavaCC 21.
Now, Rome was not built in a day, so it is quite understandable if it takes a while for your plugin to be updated to supporting the latest feature set. However, I think there has to be the understanding that this is a goal you have.
So, could you clarify your position on this?