Stephen, I agree that making libraries and argument conventions more accessible would take a significant step toward smoothing the J learning curve. However, there is just something elegant about Iverson's notation that attracts people, eases the learning curve, and keeps diehard programmers using the APL language. Ideally we should do both with J.
You mentioned your concern about the APL symbol set causing us to "shy away from embracing the potential of unifying similar notions with conventions such as inverse, stop, colon" Actually. I believe that the APL character set actually *enhances* the unification of similar notions. Look at APL's equal and not-equal, and compare that to J's equivalent equal and not-equal (nub sieve) symbols. It is much easier to see the relationship between the two APL symbols than the J symbols. In J, how is Box (<) related to floor (<.)?. There are many cases in J where stop and colon were added to an ASCII character to define a primitive which had no relation to the single-character primitive. In every case, similar APL symbols represent related functions. Wher APL characters really shine is in the ability to imply functionality from graphic cues. APL's take and drop (up and down arrows) are great mnemonics for the functions, when compared to J's curly braces. Look at APL's rotate and transpose, and compare them to the J equivalents. It would be hard to improve on APL's simple, single-glyph symbols that better represents these functions. APL's usage of traditional mathematical symbols when appropriate (multiply, divide, greater-than-or-equal, less-than-or-equal) also ease the transition from grade-school math notation to the single-glyph symbols. Most programmers have long-forgotten their confusion when first presented with the asterisk as a multiplication symbol, but that is an issue for every new programmer. Stephen Taylor said: It's a worthwhile experiment, but it definitely sounds like a fork in the road. Should we recognize this as such? I wouldn't call the ability to display J in a single-glyph form as a "fork in the road". Rather it is an alternate way to display/write J code, much like changing the font in a Word document. Programmers can choose to work in either environment, and display their code in either form. It will be obvious to anyone, which form is being shown. If one wants to see the other code form, just paste the code in the editor, and switch representations. So we don't have to force anyone to choose their favorite representation - we just enable a choice. I suspect that most people will be able to read code in either representation fairly easily. Skip On Tue, Apr 9, 2013 at 11:00 AM, Steven Taylor <[email protected]> wrote: > I still think making the libraries + argument conventions more navigable > would be a more productive and better received application of the VS IDE. > > I did enjoy seeing Mark Simpsons APL to J mappings. Visually things like > square root and not made more sense. > > With this symbol variation approach I'd think that there'd be a tendency to > shy away from embracing the potential of unifying similar notions with > conventions such as inverse, stop, colon should people use a visual APL > type bridge to J. It's a worthwhile experiment, but it definitely sounds > like a fork in the road. Should we recognise this as such? > > -- Skip Cave Cave Consulting LLC ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
