The fact that the load and save verbs as demonstrated are so small, they can be used without needing the implementors to redo the interpreter.
For that matter, the default profile already adds so many goodies to the system, I'm actually surprised no one has shown any "J session hacks." Perhaps they have. If not... so few weekends... ------------------------------------------------------------------------ |\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram) |/\| [EMAIL PROTECTED] | |\ | | The only real problem with APL is that BSc(Math) UNBF'83 | it is "still ahead of its time." Sapere Aude | - Morten Kromberg Natural Born APL'er | Demo website: http://156.34.66.254/ -----------------------------------------------------(INTP)----{ gnat }- ----- Original Message ----- From: "Joe Tibollo" <[EMAIL PROTECTED]> To: "General forum" <[email protected]> Sent: Friday, January 26, 2007 8:03 PM Subject: RE: [Jgeneral] Lack of software abstractions I like working with script files just fine. In fact, when I use VB, the debugger is so attuned to working with script files that I never give it a second thought. J is different. It has a different pedigree. It has scripts like VB but it has workspaces and debugs in a manner more nearly akin to APL. It's that pedigree that makes J so powerful. But, with power comes responsibility. What results is an explosion of names. Both in the workspace and in the form of files on disk. This can result in greater complexity and therefore more work and a steeper learning curve. Now, I suppose this is a matter of personal preference, so we can't really agree on this. But part of the reason for this thread has to do with why new people to J might be a bit put off with J given that the interpreter and the language is so powerful. Well, in my opinion, it has to do with taking care of, keeping track of, packaging, etc. what amounts to thousands of names. I just seem to have fewer names to keep track of in other environments. Does this put me off J. Emphatically not. However, it does represent a hurdle for me, and at times, other languages that help me keep track of this complexity better than J, as a result, seem easier to use (i.e. less time consuming). Also, a question for Chris - I know that APL workspaces store the binary representations of the functions and variables to disk. However, why can't we have our scripts and eat it too (sort of)? Why can't we store the textual form of all the functions and variables (similar to the solutions provided by Dan and Roger)? I haven't had a chance to completely test out the solutions for saving and storing that have been provided, but assuming they work, why not build that in to J. This does not mean eliminating the loading of scripts - just something more. Wouldn't it be nice to be able to load text scripts as you need them (with all the advantages that has) and then when the workspace is working the way you want - simply press a button or type save and your work is preserved. No problem distributing your work. Whey does it have to be 100% either way? Wouldn't that make the J environment more productive? It would for me... /Joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Burke Sent: Friday, January 26, 2007 4:40 PM To: General forum Subject: Re: [Jgeneral] Lack of software abstractions Joe Tibollo wrote: > I don't think it is all that trivial. > > Ideally, it would be nice to save everything in the workspace and reload > it with a simple > ")save" and ")load" . Having to write a function to query all locales > and package all objects to a single file is a serious undertaking - > perhaps that is why it still has yet to be done... The bottom line is that J code is saved in scripts, and not in workspaces. If you want to use J, you must learn to work with scripts. If instead you want to duplicate your APL workspaces in J, good luck to you, but you will get no sympathy from the J team. Very early versions of J had saved workspaces, but they were removed when it was realized that scripts work better. Once you become familiar with the J IDE, you won't miss the workspace. There are serious drawbacks to saving source in an internal binary format like the APL workspace. Examples: you need special editors and the appropriate interpreter otherwise the source is unreadable, and need explicit )LOAD and )SAVE. It is awkward to update definitions stored in more than one workspace. It needs custom source code managers - APL is the only language where experienced programmers put a lot of effort into writing their own. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
