Vector themed issue: How to wear sheepskin

A message on the J Forum this morning refers to a familiar issue: how
to include (APL, J, K, q) components in a project implemented in other
languages without getting chased out by the IT shepherds?

For the technical issues the tools have never been better; a review of
the range of possibilities and some proven techniques would be
useful.

The most difficult issues are often not technical. Simplest and most
brutal is the knee-jerk "We don't know it, and you can't use it."
Subtler and harder problems arise from demands to comply with
corporate testing and project-management practices designed for a
development process two orders of magnitude slower.

Vector contemplates a themed issue on this subject, with articles on
the technical, political and/or methodological aspects of working with
corporate IT, most likely in Vector 24:2 in 2009Q1. If you think you
might have something to offer from your experience (even if not a
complete article) please contact me at editor@vector.org.uk.

"It's not enough to have sheepskin to mingle with the sheep; you need
to know how to wear it."

(Please repost to the J and q forums.)

Stephen Taylor
editor@vector.org.uk

http://www.vector.org.uk
http://aplwiki.aplteam.com

On Jul 31, 7:20*am, "Stephen Taylor <edi...@vector.org.uk>"
<StephenTaylorF...@googlemail.com> wrote:
> A message on the J Forum this morning refers to a familiar issue: how
> to include (APL, J, K, q) components in a project implemented in other
> languages without getting chased out by the IT shepherds?
>
> For the technical issues the tools have never been better; a review of
> the range of possibilities and some proven techniques would be
> useful.
>
> The most difficult issues are often not technical. Simplest and most
> brutal is the knee-jerk "We don't know it, and you can't use it."
> Subtler and harder problems arise from demands to comply with
> corporate testing and project-management practices designed for a
> development process two orders of magnitude slower.
>
> Vector contemplates a themed issue on this subject, with articles on
> the technical, political and/or methodological aspects of working with
> corporate IT, most likely in Vector 24:2 in 2009Q1. If you think you
> might have something to offer from your experience (even if not a
> complete article) please contact me at edi...@vector.org.uk.
>
> "It's not enough to have sheepskin to mingle with the sheep; you need
> to know how to wear it."
>
> (Please repost to the J and q forums.)
>
> Stephen Taylor
> edi...@vector.org.uk
>
> http://www.vector.org.ukhttp://aplwiki.aplteam.com

One way would be to write the system in a mix of Dyalog and J.
You can then compile the Dyalog to create an exe file and noone needs
to know what it is written in.
Who cares nowadays anyway as long as you get something executable that
does not fail.

On Jul 31, 3:20*am, "Stephen Taylor <edi...@vector.org.uk>"
<StephenTaylorF...@googlemail.com> wrote:
> A message on the J Forum this morning refers to a familiar issue: how
> to include (APL, J, K, q) components in a project implemented in other
> languages without getting chased out by the IT shepherds?
>
> "It's not enough to have sheepskin to mingle with the sheep; you need
> to know how to wear it."
>

No need to wear a sheepskin, especially with global warming! Instead
develop the module, application, etc. in VisualAPL which is fully-
integrated with Visual Studio 2005/2008 and interoperable with
any .Net language. Deploy the result anywhere, including Windows [XP,
Vista, Server 2000/2003/2008] or Unix/Linux/MacOS using Novell/Mono,
all fully-managed code, without any legacy Win32 APL interpreter.
VisualAPL has full APL functionality, plus the deployment options,
exception handling, container structure [.dll, .exe, etc.] and
compatibility with the entire C# codebase to satisfy the corporate IT
'professionals'. Contact sales@apl2000.com for details.

"A message on the J Forum this morning refers to a familiar issue: how
to include (APL, J, K, q) components in a project implemented in other
languages without getting chased out by the IT shepherds? "

If I understand this correctly, this is about non-apl tool/language
using an apl family product?

Therefore, the client is non-apl but the server [in-process or out-of-
process] is apl? Have I got it right so far?

If no, please ignore me, or better still, correct me.

If yes, then so far as I am aware, APL+Win is the only apl product
capable of being used in this manner; more precisely, as an out-of-
process server in this fashion.

On Aug 9, 8:28*pm, AAsk <AA2e...@lycos.co.uk> wrote:

> If I understand this correctly, this is about non-apl tool/language
> using an apl family product?

My understanding is that the issue of Vector that Stephen is proposing
will cover both the technical aspects of integration (which Gosi and
Joe have described two very different ways to address) AND the
organizational aspects of using APL/J/K within organizationa that have
cultures and adhere to procedures which are designed to manage work
done using fundamentally different tools.

How do you explain to the manager of a traditional software
development organization that using APL, J or K for part of a solution
might be the best solution? On the technical side, most APL systems
can now be integrated more or elss elegantly, but generally in
politically acceptable ways. The various computing platforms are
providing better and better (and more standardised!) frameworks for
integration, and many vendors are doing a lot of hard work to connect
to these, so it is no longer very difficult to provide satisfactory
integration at the technical level. At the same time, serious doubts
are starting to be voiced about traditional IT thinking, which has a
pretty poor track record wrt delivering solutions on time and on
budget.

It is a good time to talk about revolutionary, dynamic technologues
like APL. Since the technical issues are in the process of being
solved, we also need to spend some energy on the organizational and
political aspects of the argument.

> If yes, then so far as I am aware, APL+Win is the only apl product
> capable of being used in this manner; more precisely, as an out-of-
> process server in this fashion.

Encapsulating your APL application as an out-of-process COM/OLE server
is only one of very many different ways to expose an APL (or J/K)
based service. Microsoft would like us all to replace the use of COM
with the DotNet assemblies that Joe Blaze describes. Increasingly,
large organizations would like us to deliver "service oriented"
components, which present our our APL functions as modules which can
be placed anywhere in a network using "scalable" architecture. This
can be done using message queuing components like MSMQ or MQ Series,
"Enterprise Service Buses" like WebMethods, using "open" standards
like the "WebService" protocol (based on HTTP and XML), or using your
own TCP-based protocol (as I believe kdb provides as a standard
connection mechanism). Microsoft DotNet and other "frameworks" provide
tools to encapsulate components as local or remote services using most
of the above techniques.

I may be missing a point somewhere, but Dyalog APL components can also
be delivered as both in- and out-of-process COM servers, and using all
the DotNet infrastructure. We also have an experimental WebService
component which allows APL applications to provide and "consume"
simple web services without using any third party infrastructure.

Morten

As is becoming clearer, this thread should have been titled 'APL/J:
Multi-language programming'.

The constraints of the discussion are:

1. Existing Applications (with our with legacy APL applications)
2. Future developments - including APL/J.

A. COM

Whatever Microsoft's stated intentions, it is its user base which
determines the life cycle of Microsoft technologies to date. Microsoft
made claims about ODBC: this is still in widespread use and likely to
continue for a long time. A good chunk of Windows itself is based on
COM technology: regular expressions, file system object, XML parsers,
file compression, WMI, HTA. In spite of stated intentions, I see
Microsoft itself re-using CMD files (DOS batch files) and there is now
PowerShell (I can only describe this is DOS+). CHM which was not
supported by Vista originally, now is. Of course, the flagship product
C# still supports the creation of COM technology.

Therefore there can be little doubt that COM is going to be around for
a long while.

B. Existing applications

(i) non-apl legacy applications

I cannot believe that APL has any role to play here in so far as
handling the re-engineering of the GI of such applications is
concerned. Why? The GUI design technology of APL is simply not up to
scratch i.e inferior.

Therefore, the domain in which APL can be incorporated must be in the
next tier, the business tier.

Unless the application settles for its presention tier (GUI) and
business tier to be asynchronous, APL is seriously constrained with
the exception of APL+Win. With APL+Win, I can create a COM instance of
APL+Win from the GUI of an application, have it load workspaces and I
can instruct it to carry out processes with dynamically supplied
input.

I cannot do this with Dyalog or APLX. The best that is possible is to
start Dyalog as a separate process and have it carry out calcuations
by, say, reading a file created by the GUI. In this arrangement, the
GUI is completely unaware of what the state of play it. Practically
speaking, I think this is unworkable.

My conclusion(s):

APL+Win legacy applications can seamlessly benefit from re-engineering
that replaces its font end with a mre modern front end.

Equally, the COM capability of APL+Win (as a SERVER) means that APL
+Win is thae only APL that can benefit.

(ii) apl legacy applications

For reasons already discussed, the scope for replacing the
presentation tier of APL applications is severely restricted except
for APL+Win (which is capable of BEING deployed as COM).

However, there is a good deal of scope for APL in many other respects.
The replacement of APL component files and the adoption of relational
databases is a prime example and easily achieved by all APLs. This can
work bi-directionally: ie. for both acquisition and transfer of data.

Another context is for APL to use standard technologies such as HTML
or XML or proprietary packages like Crystal Reports for presenting it
down results. All APLs are capable of deploying COM.

My conclusion:

Although APL itself is more than capable, its user base is very
sceptical and highly resistant to any moves in thi direction.

C. New Applications

My very personal outlook is as follows: if I am developing a new
product with APL content, there is only one APL that I'd consider,
namely Visual APL. My reasons are quite clear: VA works from an IDE
that enables multi-language programming and abides by all the rules
that the future of personal computing is expected to be (current
thinking).

However, there is a need to be much more pragmatic.

Since a non-apl GUI and an APL business tier is unworkable (except for
APL+Win or Visual APL that shares the C# GUI builder), the quest must
be within the context of an APL GUI with non-apl content elsewhere.

In this respect, APL+Win simply cannot play but Dyalog and APLX
definitely can. The latter 2 APLS can access .NET in two ways: (a) in
a piecemeal fashion using [].NET (you know what I mean) or (b) by
accessiing .NET assemblies in the same way as, say, C#. APL+Win does
not have [].Net and can access the said assemblies only if re-compiles
as COM Interop DLLS.

I think [].NET is a nice feature, but much like []NA, it does not
catch the imagination of traditional APL people.

..NET Dlls have two roles to play: (a) as a replacement of Win32 API
(b) as common resource for all development tools.

The immediate questions are: Why would APL, an array processor,
use .NET Dlls (scalar based)?

For me, the answers are quite obvious and include such things as a
managed progression into the managed code world, the ability to share
the development cycle among people of a wider array of sills etc.

I do not think this is widely understood. Most people would like
simply to use .NET (hoping that this ius enough! It isn't!).

For Dyalog, and Visual APL, there is a very persuasive argument.
Although I have not done this with Dyalog for anything serious, it is
possible to package APL (arrays and all) as .NET assemblies usable
by .NET languages. The process is much more seamless with Visual APL.

Dyalog has had this capability for a long time.

So, who can make 'heroes happen'?

As is becoming clearer, this thread should have been titled 'APL/J:
Multi-language programming'.

The constraints of the discussion are:

1. Existing Applications (with our with legacy APL applications)
2. Future developments - including APL/J.

A. COM

Whatever Microsoft's stated intentions, it is its user base which
determines the life cycle of Microsoft technologies to date. Microsoft
made claims about ODBC: this is still in widespread use and likely to
continue for a long time. A good chunk of Windows itself is based on
COM technology: regular expressions, file system object, XML parsers,
file compression, WMI, HTA. In spite of stated intentions, I see
Microsoft itself re-using CMD files (DOS batch files) and there is now
PowerShell (I can only describe this is DOS+). CHM which was not
supported by Vista originally, now is. Of course, the flagship product
C# still supports the creation of COM technology.

Therefore there can be little doubt that COM is going to be around for
a long while.

B. Existing applications

(i) non-apl legacy applications

I cannot believe that APL has any role to play here in so far as
handling the re-engineering of the GI of such applications is
concerned. Why? The GUI design technology of APL is simply not up to
scratch i.e inferior.

Therefore, the domain in which APL can be incorporated must be in the
next tier, the business tier.

Unless the application settles for its presention tier (GUI) and
business tier to be asynchronous, APL is seriously constrained with
the exception of APL+Win. With APL+Win, I can create a COM instance of
APL+Win from the GUI of an application, have it load workspaces and I
can instruct it to carry out processes with dynamically supplied
input.

I cannot do this with Dyalog or APLX. The best that is possible is to
start Dyalog as a separate process and have it carry out calcuations
by, say, reading a file created by the GUI. In this arrangement, the
GUI is completely unaware of what the state of play it. Practically
speaking, I think this is unworkable.

My conclusion(s):

APL+Win legacy applications can seamlessly benefit from re-engineering
that replaces its font end with a mre modern front end.

Equally, the COM capability of APL+Win (as a SERVER) means that APL
+Win is thae only APL that can benefit.

(ii) apl legacy applications

For reasons already discussed, the scope for replacing the
presentation tier of APL applications is severely restricted except
for APL+Win (which is capable of BEING deployed as COM).

However, there is a good deal of scope for APL in many other respects.
The replacement of APL component files and the adoption of relational
databases is a prime example and easily achieved by all APLs. This can
work bi-directionally: ie. for both acquisition and transfer of data.

Another context is for APL to use standard technologies such as HTML
or XML or proprietary packages like Crystal Reports for presenting it
down results. All APLs are capable of deploying COM.

My conclusion:

Although APL itself is more than capable, its user base is very
sceptical and highly resistant to any moves in thi direction.

C. New Applications

My very personal outlook is as follows: if I am developing a new
product with APL content, there is only one APL that I'd consider,
namely Visual APL. My reasons are quite clear: VA works from an IDE
that enables multi-language programming and abides by all the rules
that the future of personal computing is expected to be (current
thinking).

However, there is a need to be much more pragmatic.

Since a non-apl GUI and an APL business tier is unworkable (except for
APL+Win or Visual APL that shares the C# GUI builder), the quest must
be within the context of an APL GUI with non-apl content elsewhere.

In this respect, APL+Win simply cannot play but Dyalog and APLX
definitely can. The latter 2 APLS can access .NET in two ways: (a) in
a piecemeal fashion using [].NET (you know what I mean) or (b) by
accessiing .NET assemblies in the same way as, say, C#. APL+Win does
not have [].Net and can access the said assemblies only if re-compiles
as COM Interop DLLS.

I think [].NET is a nice feature, but much like []NA, it does not
catch the imagination of traditional APL people.

..NET Dlls have two roles to play: (a) as a replacement of Win32 API
(b) as common resource for all development tools.

The immediate questions are: Why would APL, an array processor,
use .NET Dlls (scalar based)?

For me, the answers are quite obvious and include such things as a
managed progression into the managed code world, the ability to share
the development cycle among people of a wider array of sills etc.

I do not think this is widely understood. Most people would like
simply to use .NET (hoping that this ius enough! It isn't!).

For Dyalog, and Visual APL, there is a very persuasive argument.
Although I have not done this with Dyalog for anything serious, it is
possible to package APL (arrays and all) as .NET assemblies usable
by .NET languages. The process is much more seamless with Visual APL.

Dyalog has had this capability for a long time.

So, who can make 'heroes happen'?

With today's APLs, it is quite easy to write an application where APL
is "on top", that is, the application itself is in APL, its GUI is in
APL, yet it draws on services available from other areas and
technologies like, COM, Microsoft Office components, .Net, []NA, Java,
[]CMD, and so on.

However, to change this around so that .Net is "on top" and APL is
just another service is another matter. Arguably, the GUI should be
in .Net (or Java, or whatever the institutional favourite of the day
is) and should invoke services written in APL. In reality, this is
far from easy to do well, try automating Word from .Net (or Java).
Automating legacy COM objects from .Net appears to work at first
glance, but can be extremely miserable.

Everything was fine until .Net came along. Prior to this, you could
write your GUI in Visual Basic, then use COM to invoke either APL+Win
or Dyalog. Politically, this would sit well with some of the IT types
as the application appeared to be written in VB.

I believe that .Net (and Java) were designed never to truly
interoperate with anything else, and wrappers and shims to "lower"
interfaces (like ordinary DLLs and []CMD) are relatively reliable
mostly because they are really simple. When you invoke something like
a Word/Excel/VBA object model from .Net, in reality you have two
managed environments with two different garbage collection schemes,
two different ways of deallocating resources, and so on. Throw in APL
for good measure, and now you have three managed environments.
Anything else? Java? Matlab? One starts to feel sorry for all those
electrons. And the heat.

At least with .Net, I think the only way to build reliable, robust,
and (as much as I hate this) "politically correct" applications is not
to have too much application diversity. If the main part of the
application is written in .Net, then APL services should also be .Net,
that is, APL from Visual APL or C# from the Causeway APL compiler. I
haven't actually used these products, but it sure sounds like the way
to go.

With some arrangements, the connectivity problems far outweigh the
application complexity.
Specifically, I think automating COM from .Net is pretty buggy. The
other way around appears to be not as bad, though I have seen cases
where Word or Excel with a button to invoke some .Net code has
problems.

APL can "talk down" to .Net pretty well (as it rightly should).
Probably to Java too. But political demands, at least where I come
from, appear to be satisfied when the application is written in one of
these managed languages but some services are done with APL.

> I cannot believe that APL has any role to play here in so far as
> handling the re-engineering of the GI of such applications is
> concerned. Why? The GUI design technology of APL is simply not up to
> scratch i.e inferior.
>
> Therefore, the domain in which APL can be incorporated must be in the
> next tier, the business tier.
>
> Unless the application settles for its presention tier (GUI) and
> business tier to be asynchronous, APL is seriously constrained with
> the exception of APL+Win. With APL+Win, I can create a COM instance of
> APL+Win from the GUI of an application, have it load workspaces and I
> can instruct it to carry out processes with dynamically supplied
> input.

I think this is absolutely correct. Assuming the interop is working.

> I cannot do this with Dyalog or APLX. The best that is possible is to
> start Dyalog as a separate process and have it carry out calcuations
> by, say, reading a file created by the GUI. In this arrangement, the
> GUI is completely unaware of what the state of play it. Practically
> speaking, I think this is unworkable.

Dyalog has a different automation model which allows you to expose the
members of a namespace as a COM component or in-process DLL. It could
work as well as the APL2000 approach, although I would think that the
APL2000 automation model is easier to get started with. In the end,
both accomplish the same thing.

> My very personal outlook is as follows: if I am developing a new
> product with APL content, there is only one APL that I'd consider,
> namely Visual APL. My reasons are quite clear: VA works from an IDE
> that enables multi-language programming and abides by all the rules
> that the future of personal computing is expected to be (current
> thinking).

I think this is correct. .Net to .Net is the friendliest connectivity
model.

> So, who can make 'heroes happen'?

It is what a hero does that makes him or her a hero. They don't just
happen. This is just the silly Microsoft propaganda you see when you
fire up Visual Studio.

On Aug 11, 3:45*pm, Ibeam2000 <Ibeam2...@gmail.com> wrote:
> With today's APLs, it is quite easy to write an application where APL
> is "on top", that is, the application itself is in APL, its GUI is in
> APL, yet it draws on services available from other areas and
> technologies like, COM, Microsoft Office components, .Net, []NA, Java,
> []CMD, and so on.
>
> However, to change this around so that .Net is "on top" and APL is
> just another service is another matter. *Arguably, the GUI should be
> in .Net (or Java, or whatever the institutional favourite of the day
> is) and should invoke services written in APL. *In reality, this is
> far from easy to do well, try automating Word from .Net (or Java).
> Automating legacy COM objects from .Net appears to work at first
> glance, but can be extremely miserable.
>
> Everything was fine until .Net came along. *Prior to this, you could
> write your GUI in Visual Basic, then use COM to invoke either APL+Win
> or Dyalog. *Politically, this would sit well with some of the IT types
> as the application appeared to be written in VB.
>
> I believe that .Net (and Java) were designed never to truly
> interoperate with anything else, and wrappers and shims to "lower"
> interfaces (like ordinary DLLs and []CMD) are relatively reliable
> mostly because they are really simple. *When you invoke something like
> a Word/Excel/VBA object model from .Net, in reality you have two
> managed environments with two different garbage collection schemes,
> two different ways of deallocating resources, and so on. *Throw in APL
> for good measure, and now you have three managed environments.
> Anything else? *Java? *Matlab? *One starts to feel sorry for all those
> electrons. *And the heat.
>
> At least with .Net, I think the only way to build reliable, robust,
> and (as much as I hate this) "politically correct" applications is not
> to have too much application diversity. *If the main part of the
> application is written in .Net, then APL services should also be .Net,
> that is, APL from Visual APL or C# from the Causeway APL compiler. *I
> haven't actually used these products, but it sure sounds like the way
> to go.
>
> With some arrangements, the connectivity problems far outweigh the
> application complexity.
> Specifically, I think automating COM from .Net is pretty buggy. *The
> other way around appears to be not as bad, though I have seen cases
> where Word or Excel with a button to invoke some .Net code has
> problems.
>
> APL can "talk down" to .Net pretty well (as it rightly should).
> Probably to Java too. *But political demands, at least where I come
> from, appear to be satisfied when the application is written in one of
> these managed languages but some services are done with APL.
>
> > I cannot *believe that APL has any role to play here in so far as
> > handling the re-engineering of the GI of such applications is
> > concerned. Why? The GUI design technology of APL is simply not up to
> > scratch i.e inferior.
>
> > Therefore, the domain in which APL can be incorporated must be in the
> > next tier, the business tier.
>
> > Unless the application settles for its presention tier (GUI) and
> > business tier to be asynchronous, APL is seriously constrained with
> > the exception of APL+Win. With APL+Win, I can create a COM instance of
> > APL+Win from the GUI of an application, have it load workspaces and I
> > can instruct it to carry out processes with dynamically supplied
> > input.
>
> I think this is absolutely correct. *Assuming the interop is working.
>
> > I cannot do this with Dyalog or APLX. The best that is possible is to
> > start Dyalog as a separate process and have it carry out calcuations
> > by, say, reading a file created by the GUI. In this arrangement, the
> > GUI is completely unaware of what the state of play it. Practically
> > speaking, I think this is unworkable.
>
> Dyalog has a different automation model which allows you to expose the
> members of a namespace as a COM component or in-process DLL. *It could
> work as well as the APL2000 approach, although I would think that the
> APL2000 automation model is easier to get started with. *In the end,
> both accomplish the same thing.
>
> > My very personal outlook is as follows: if I am developing a new
> > product with APL content, there is only one APL that I'd consider,
> > namely Visual APL. My reasons are quite clear: VA works from an IDE
> > that enables multi-language programming and abides by all the rules
> > that the future of personal computing is expected to be (current
> > thinking).
>
> I think this is correct. *.Net to .Net is the friendliest connectivity
> model.
>
> > So, who can make 'heroes happen'?
>
> It is what a hero does that makes him or her a hero. *They don't just
> happen. *This is just the silly Microsoft propaganda you see when you
> fire up Visual Studio.

On Aug 11, 3:45*pm, Ibeam2000 <Ibeam2...@gmail.com> wrote:
> With today's APLs, it is quite easy to write an application where APL
> is "on top", that is, the application itself is in APL, its GUI is in
> APL, yet it draws on services available from other areas and
> technologies like, COM, Microsoft Office components, .Net, []NA, Java,
> []CMD, and so on.
>
> However, to change this around so that .Net is "on top" and APL is
> just another service is another matter. *Arguably, the GUI should be
> in .Net (or Java, or whatever the institutional favourite of the day
> is) and should invoke services written in APL. *In reality, this is
> far from easy to do well, try automating Word from .Net (or Java).
> Automating legacy COM objects from .Net appears to work at first
> glance, but can be extremely miserable.
>
> Everything was fine until .Net came along. *Prior to this, you could
> write your GUI in Visual Basic, then use COM to invoke either APL+Win
> or Dyalog. *Politically, this would sit well with some of the IT types
> as the application appeared to be written in VB.
>
> I believe that .Net (and Java) were designed never to truly
> interoperate with anything else, and wrappers and shims to "lower"
> interfaces (like ordinary DLLs and []CMD) are relatively reliable
> mostly because they are really simple. *When you invoke something like
> a Word/Excel/VBA object model from .Net, in reality you have two
> managed environments with two different garbage collection schemes,
> two different ways of deallocating resources, and so on. *Throw in APL
> for good measure, and now you have three managed environments.
> Anything else? *Java? *Matlab? *One starts to feel sorry for all those
> electrons. *And the heat.
>
> At least with .Net, I think the only way to build reliable, robust,
> and (as much as I hate this) "politically correct" applications is not
> to have too much application diversity. *If the main part of the
> application is written in .Net, then APL services should also be .Net,
> that is, APL from Visual APL or C# from the Causeway APL compiler. *I
> haven't actually used these products, but it sure sounds like the way
> to go.
>
> With some arrangements, the connectivity problems far outweigh the
> application complexity.
> Specifically, I think automating COM from .Net is pretty buggy. *The
> other way around appears to be not as bad, though I have seen cases
> where Word or Excel with a button to invoke some .Net code has
> problems.
>
> APL can "talk down" to .Net pretty well (as it rightly should).
> Probably to Java too. *But political demands, at least where I come
> from, appear to be satisfied when the application is written in one of
> these managed languages but some services are done with APL.
>
> > I cannot *believe that APL has any role to play here in so far as
> > handling the re-engineering of the GI of such applications is
> > concerned. Why? The GUI design technology of APL is simply not up to
> > scratch i.e inferior.
>
> > Therefore, the domain in which APL can be incorporated must be in the
> > next tier, the business tier.
>
> > Unless the application settles for its presention tier (GUI) and
> > business tier to be asynchronous, APL is seriously constrained with
> > the exception of APL+Win. With APL+Win, I can create a COM instance of
> > APL+Win from the GUI of an application, have it load workspaces and I
> > can instruct it to carry out processes with dynamically supplied
> > input.
>
> I think this is absolutely correct. *Assuming the interop is working.
>
> > I cannot do this with Dyalog or APLX. The best that is possible is to
> > start Dyalog as a separate process and have it carry out calcuations
> > by, say, reading a file created by the GUI. In this arrangement, the
> > GUI is completely unaware of what the state of play it. Practically
> > speaking, I think this is unworkable.
>
> Dyalog has a different automation model which allows you to expose the
> members of a namespace as a COM component or in-process DLL. *It could
> work as well as the APL2000 approach, although I would think that the
> APL2000 automation model is easier to get started with. *In the end,
> both accomplish the same thing.
>
> > My very personal outlook is as follows: if I am developing a new
> > product with APL content, there is only one APL that I'd consider,
> > namely Visual APL. My reasons are quite clear: VA works from an IDE
> > that enables multi-language programming and abides by all the rules
> > that the future of personal computing is expected to be (current
> > thinking).
>
> I think this is correct. *.Net to .Net is the friendliest connectivity
> model.
>
> > So, who can make 'heroes happen'?
>
> It is what a hero does that makes him or her a hero. *They don't just
> happen. *This is just the silly Microsoft propaganda you see when you
> fire up Visual Studio.

In my environment, it has always been risky to have our real-time
systems have anything to do with APL, since some people would always
be ready to blame APL whenever anything failed. I avoid this by doing
my development and offline testing in APL; when we decide that a given
algorithm should be put into our real-time system, we translate it to
C and integrate it. So our missile defense customer sees nothing but
C and C++.