Re: Lack of software abstractions

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
dydre-rieW9WUcm8FFJ04o6PK0Fg@xxxxxxxxxxxxxxxx

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