RE: Lack of software abstractions

This is a multi-part message in MIME format.
Now you're talking Chris.  Possible new changes to the IDE along the lines you 
have suggested are very exciting.  I'm not very good when it comes to using J 
in (what I consider) complex ways (so what is trivial for Randy,  may not be so 
trivial for the average J user) and  so I salute (and thank) other J users that 
are (and that have been so generous in sharing their expertise with the greater 
J community).  My goal has been to monitor their messages and studiously write 
down the little gems that seem to flow out of this forum and the online J wiki.
 
But changes to the IDE are a different matter.  That's my barometer on 
productivity and that's where the excitement is for me when it comes to new 
changes in J (and what determines for me which tool is best for any data 
processing jobs that I may face).  The J wizards (expert users) won't benefit 
as much, but the majority of common everyday J programmers (like me) will 
benefit from new IDE improvements designed to require less typing, less 
remembering, less organizing, less effort, improved application packaging, 
improved debugging, improved script integration.
 
/Joe
 
 
-----Original Message----- 
From: general-bounces@xxxxxxxxxxxxx on behalf of Chris Burke 
Sent: Fri 26/01/2007 10:51 PM 
To: General forum 
Cc: 
Subject: Re: [Jgeneral] Lack of software abstractions



        Dan Bron wrote:
        > I think I understand his point now, and I think you may have 
misunderstood it.
        >
        > Have you ever used the Dyalog IDE?  It's breathtaking.  Gorgeous.  
Sublime. 
        >
        > I think what Joe (and many of the rest of us!) want is something akin 
to that, and he does not care about how it actually stores
        > code.  Imagine a J IDE similar to Dyalog's, but which writes 
functions to script files.  Not as big, ugly blobs, but in properly
        > formatted, nicely laid-out script files. 
        >
        > The scripts would not be any different than they are now.  In 
particular, they could be edited by any editor, shared via email,
        > cut, copied, pasted, rearranged, reloaded, etc.  A J script edited by 
Magic J IDE v2.0 would be indistinguishable from one edited
        > in notepad, or in the current J IDE.
        >
        > The difference would be in the IDE.  For example, if I typed a 
function name into the session, and double clicked it, or put my
        > cursor over it and pressed SHIFT+Enter, a small window could pop up 
with the function's definition, which I could edit.  Then I'd
        > press Esc and the new definition would be loaded into the session and 
simultaneously written (nicely) into the proper place in a
        > script file. 
        >
        > Alternatively, Shift+Enter could do some of the magic that CTRL+F1 
and  edit_z_  do:  find the script which defined the cursor'd
        > name, open it in a new script window, and put the cursor on the first 
line of its definition.  Then I could edit-edit-edit, CTRL+W
        > (or some version of CTRL+W which puts focus back in the session 
window, like F12 does), and merrrily go on my way with the new
        > version of the name.
        >
        > ...
        
        No problem with the better IDE - what we have can always be improved. I
        am not a big fan of Dyalog's, but perhaps I am too used to our own.
        
        I do like your key idea of pointing to a definition and clicking to
        bring up its definition for editing, and this is worth exploring
        further. The edit verb was originally designed for this, but I no longer
        use it since the connection between the definition and the original
        script is lost when an application is built. If we could track this
        easily, then it would be simple to add some edit magic. Perhaps
        something like:
        
         - when a script is built by PM, it inserts comment tags that would
        enable magic to trace back the original source script. Whether this is
        enabled would be part of the project configuration.
        
         - if no such tags are in the script, magic opens the script like the
        current edit.
        
        Your suggestion for a smarter script editor is much along the lines of
        the form editor. This reads a script, and parses it so it can be edited
        in a GUI, and then writes out the nicely formatted definitions
        afterwards. The only real drawback is that scripts are free-form, and it
        is not always obvious exactly where a name gets defined; but this is a
        minor problem.
        
        I don't see us moving away from scripts, and I think improvements to the
        IDE will largely be improvements to the way we handle scripts, such as
        text folding, name cross-referencing, better syntax highlighting,
        formatting, version comparison etc. There is a lot that can be done in
        this area (and much can be contributed by the user group). We have done
        some work on rewriting the script window editor (e.g. so we can have
        color coding in Java), but this is currently on the back burner.
        
        
        ----------------------------------------------------------------------
        For information about J forums see http://www.jsoftware.com/forums.htm