On May 3, 8:27=A0pm, AAsk <AA2e...@[EMAIL PROTECTED]
> wrote:
> In my mind, I have no doubt whatsoever
> that APL by itself is not enough;
I think that for this kind of discussion to be fruitful, we need to be
more specific about what we are trying to achieve when we make
sweeping statements like the above. Obviously, there are many
situations where APL by itself IS enough. A lot of simple mathematical
applications have no requirements beyond what APL has to offer.
My understanding is that the issues you are discussing are related
either to the production of shrink-wrapped software, or writing
applications which must inhabit certain restrictive cor****ate
computing environments, or perhaps bidding on projects which are being
viewed by buyers with an emphasis on being in the "main stream" - i.e.
selling APL to software engineers. There is a fundamental problem
here: Many people use APL exactly because they are "problem solvers"
and not Software Engineers. If we REQUIRED that all these people be
"literate" in all this technology and infrastructure, it would be
lethal to most of the people who find APL really useful. Many who are
comfortable with multiple technologies quickly forget just how
intimidating the "mixed solution" is to those who do not have
experience or training in "software development".
So: Although many of your points are valid, at least if you need to
"market" your solutions, APL system designers have to weigh the
direction carefully: Too much emphasis on "engineering" can easily
remove the "unique selling proposition" of the product. APL is not
just "VB with Array Capabilities", it is a tool of thought which has
fundamentally different characteristics from typical "programming
languages", and offers a different approach to the construction of
executable solutions to problems, which atatracts people who place
different emphasis on various aspects of the development process than
those who typically look for "mainstream" solutions.
Obviously, as APL vendors, we should (and do) spend most of our time
interfacing APL to other tools. This is how it should be - but we need
to take care that the interfaces are suited to the mindsets of the
people who enjoy APL. Making APL look less surprising to C# or Java
programmers might be nice, but trying to make APL more acceptable to
the majority of programmers in this way is a VERY dangerous guideline
for the design of APL system components.
Morten
P.S. You can access ADO (and ADO.NET) from APL, but few APL users find
any significant advantage in using these interfaces. While ADO itself
was fairly array oriented, ADO.NET seems to be a step in a more
"collection oriented" direction and thus somehow less attractive to
the APL user. Anyway, most APL applications would want to hide the SQL
interface inside a set of higher-level utilities, so the underlying
technology is not very "interesting". I would suggest that you do not
want to expose ODBC- or ADO- specific code directly in your APL
"application code". Also, I believe that most APL applications make
little use of the "editable rowsets" which seem to be the most valued
features of these interfaces.
|
