After all those messages, one that's on original topic!
I pointed out this lament by Mr. Robinson to highlight an area where J is particularly effective: software abstractions, particularly in iterations and substitutes for iterations. Having just re-visited some of Cliff Reiter's material from his "Fractals, Visualizations and J" book, I was impressed by his neat expression for calculating a Hurst exponent. He defines the basic elements of a solution, then applies them to a vector using "cut" - in the form ";._3" - to arrive at such a neat solution that I dug up my old solution for this and threw it away. It's ideas like this, "cut" and the more general notion of adverbs, that give J such expressive power as well as obviating clumsy, looping equivalents. In this case, Cliff's expression removed unnecessary complexity from my calculation by getting rid of an explicit loop. On 1/28/07, dly <[EMAIL PROTECTED]> wrote:
This topic began with a reference to this article by Paul Robinson http://catless.ncl.ac.uk/Risks/24.54.html > which referred to APL and the comment that [abstraction] > is something J is good at. Though, in a way, it's too good: it seems > when people encounter real abstraction, they start talking about > how hard it is to > understand. However, at some point this is an irreducible problem: > even when you simplify complex > things as much as possible, they are often still complex. Paul Robinson lamented that the means of describing software in currently available programing languages lacks adequate abstraction to reduce the work of software development. General-purpose programming languages are equivalent with respect to what they can describe—by definition they can express anything that is computable. The properties of general purpose languages that do vary, are how they affect human efficiency in both writing and reading computer applications or the implementation efficiency in deploying applications. Discussing whether there is adequate abstraction in J notation thus might include such things as: - J attributes that make it more easy or more difficult for people to write computer applications - J attributes that make it more easy or more difficult for J notation to be widely read by people - Improving J IDE - Persisting session names (workspaces) - Distributing J applications - Is J comparable to Java and JVM in being write once run anywhere? - To what degree are performance semantics of J predictable or are you required to understand optimization of the underlying platform protocol - Does J provide solutions to the complexity of distributed data and message passing? - Is J handled by another common IDE such as eclipse the way Python, ruby on rails or Perl scripts can? A discussion of this nature is neither a complaint nor a Request for Change. Donna [EMAIL PROTECTED] On 27-Jan-07, at 8:58 PM, Chris Burke wrote: > I think the original question was of the form "I have problem X and > the > solution is Y". Sometimes, the proper response is "problem X is solved > by doing Z", where Y and Z are quite different. This just seems to > me to > be the core of the workspace/script issue, and I responded > accordingly. > > But you should know that we take the issues that were discussed > seriously. For example, a lot of work has been done recently on > packaging and distributing addons (user contributions) and the base > library. A few months ago, getting any addons or library updates was a > tedious process, for both developer and end user. Now, the whole > process > is largely automated. You can access your addon in Project Manager, > make > changes, click a button in the new SVN dialog in PM to commit, the > addon > is built automatically on the server, and is immediately available to > the end user. > > In general, PM and its updates/replacements etc, is an important > part of > the IDE. There are lots of improvements we can make, in particular to > make building a simple application completely trivial - an issue that > you raised earlier, and which I believe is your main concern. > > Chris ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
-- Devon McCormick ^me^ at acm. org is my preferred e-mail ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
