Amen brother :-)
On Tue, Apr 9, 2013 at 12:55 PM, Skip Cave <[email protected]> wrote: > 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
