The small dots used in J symbols are only one of several problems with the current J symbol set. Here's a short list of the problems with the current J symbol set.
1. The small dots used for modifying the base ASCII characters in J are hard to read, and can cause confusion. Making the characters bold can help, but only on a computer. When writing J on paper or on a blackboard, the small dots still often get lost in the mix. Having to darken each dot as you write it, tells me that you need a better symbol set for writing J. This may not be an issue for J programmers, but it is an issue for J teachers. 2. Unlike most APL symbols, many J symbols don't have any graphical cue to their function. That is one of the reasons the J learning curve is so steep. Compare the J symbols for rotate and transpose to the APL symbols for the same functions, to get an idea what I mean. J newbies have to memorize 120-some symbols, most of which don't provide much of a clue as to their underlying functionality. This is one of the trade-offs that Ken & Roger made, to deal with the limited input/output options available in the 1980s 3. Groups of J primitives which have graphical similarity, don't necessarily have similar functionality ($ $. $:). So this makes it doubly-hard to remember what each symbol does. 4. Using ASCII characters for primitives is handy for typing on a standard ASCII keyboard. However, overloading the meanings of the already-overloaded ASCII character set to specify language primitives, is just asking for trouble. Having primitives use one set of glyphs, with named functions and variables using a different set of glyphs (ASCII characters), provides for much more readable programs. 5. J's reliance on spaces to separate certain parse objects works well, but spaces can be a problem in hand-written formulas. A slight gap in a written formula or variable name can cause a drastic miscommunication. All this negativity isn't meant to imply that Ken & Roger did a bad job of picking the J symbol set. They did a marvelous job, given the limited options for entering symbols, and the ASCII characters they had to work with, in the 1980s. They gave up the elegance of single-glyph APL, for the pragmatic rationale of cross-platform support. The main point now, is that the limitations they faced back then that forced their choice, are now fading away. Various suggestions have been proposed in this forum to address one or two of these issues, but I haven't seen much to address all of them. We simply need to take fresh look at the symbols J uses, realizing that the limitations that caused those 1-2 character ASCII symbols to be there, have gone away. My current cellphone, a Galaxy Note 2, has a high-res graphics touchscreen, graphic pen (with case insert), multiple soft keyboards, handwriting recognition, built-in mike and speaker, GPS, inertial sensors, and on and on. All the physical pieces are there to support all kinds of input mechanisms and displays, for all kinds of characters. There is even an Android OS option for selecting default soft keyboards for each specific application, from a list of soft keyboards. With the advent of ubiquitous graphical touch screens and soft keyboards, along with handwriting and speech recognition functionality, the hardware limitations that caused Ken & Roger to move away from APL's single-glyph symbol set have been removed. So the time has probably come to revisit that choice, given our new reality. Skip On Wed, Apr 10, 2013 at 10:34 PM, David Porter <[email protected]> wrote: > I sent this in yesterday, but didn't see it. My apologies if I have > posted it twice. I have made dots bigger by diddling the font. As long we > are talking of new fonts, this is what I reported in 2009: > > As we teach ourselves to read without consciously noticing the > punctuation, it initially bothered me that J relied on easily confused > punctuation characters to perform vastly different functions. > > I got around this by downloading a free trial version of Font Creator. > http:\\www.high-logic.com > > I then replaced the punctuation characters in Courier New with the same > characters from Courier New Bold. A few characters like curly braces. > exclamation point, apostrophe, and double quotes were widened to make them > more prominent. I saved the new font as J Courier New. It takes a little > getting used to, but I rarely mistake a semicolon for a colon anymore. > Technically, doing this violates the copyright statement, but I figure > that as long as you have both fonts on your computer anyway and you don't > sell, or exchange the font with anyone, there seems to be little harm. Win > XP had no problem, but Vista doesn't want to recognize the font. YMMV. > > Dave Porter > > > > On 4/10/2013 8:09 PM, William Tanksley, Jr wrote: > >> Tracy Harms <[email protected]> wrote: >> >>> Making the dots bigger might help a lot. Here's an idea that might be >>> relatively simple: have a J tokenizer active during typing, and every >>> inflected graphic primary gets changed so that the dots are both enlarged >>> and overlaid on the graphic. By "overlaid" I mean the result is a single >>> character with an appearance of the graphic and its (enlarged) >>> inflections >>> squished together. >>> >> This is what I was referring to by mentioning Unicode overstrike; some >> fonts actually include many of the graphemes we'd need (and perhaps >> ALL of them), written in a way that hundreds of years of experience >> proves is human-readable, and when J or your editor emits the base >> character, the overstrike character, and then the inflection >> character, the Unicode renderer that's part of your OS will >> automatically pick the human-designed font character that deliberately >> combines the two. >> >> If we can find the right font, then, the coding task should be very >> simple, at least for 90% of the problem (which is fine for a >> proof-of-concept). >> >> Oh, I see that someone asked whether I meant that people should have >> to type an overstrike character (like in APL). Oops, no. I meant that >> people would only type normal J, and the editor would automatically >> render the result. >> >> Again, this would probably be nothing more than a proof-of-concept. >> I'm sure we'd find that some J tokens would wind up being best >> represented by glyphs other than the simple overstrike, and some won't >> have a Unicode representation (and so we'd HAVE to think of another >> solution). >> >> Fun! >> >> -Wm >> > -- Skip Cave Cave Consulting LLC Phone: 214-460-4861 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
