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
