Is APLNext/Visual APL alive?
Bob Cain
2008. This does not bode well for the project. Anybody know the product status?
Thanks,
Bob
--
"Things should be described as simply as possible, but no simpler."
A. Einstein
AAsk
- 1. a new version was released 3 days ago 2. look at the forum link
for Visual APL; to which, access is open.
Stephen Taylor, editor@vector.org.uk
> You must be looking atwww.aplnext.com;instead, look atwww.apl2000.com
> - 1. a new version was released 3 days ago 2. look at the forum link
> for Visual APL; to which, access is open.
Plenty of views on the forum but almost all posts are by Joe and
Ajay.
Anyone know of new systems written in Visual APL, or old systems
migrated into it? It's been out two years – I’d like to publish
something in Vector.
Stephen Taylor
edi...@vector.org.uk
joe_blaze
This is an excellent question that can serve to illuminate the design
philosophy of VisualAPL.
VisualAPL is fundamentally different from traditional APL
implementations in that is not an APL-centric implementation. Although
it is certainly possible to 'write' a new or old system entirely in
VisualAPL, it would be anomalous to do so. VisualAPL is an
implementation of APL which designed to be used in a multi-programming
language environment to produce mainstream (fully-managed) solutions.
For example, no matter what implementation of APL is considered, there
are better languages and tools available for GUI development. The
inter-operability of VisualAPL with components developed in other
programming languages means that the best programming language tool
for the job can be utilized. So, even though one could write an
application system entirely in VisualAPL, it may not yield the best
result. Essentially, VisualAPL is 'pure' APL, designed to support
algorighmic and potentially array-based calculations and business
rules, with the application system's GUI, data storage, etc. developed
using other component programming languages better suited to that sort
of effort.
APL2000, the distributor of VisualAPL, does not ask customers what
application systems they have constructed with APL2000 products such
as VisualAPL, APL+Win and APL WebServices. It would be up to the
individual customers to disclose this to the public if they so choose.
Most APL2000 customers are commercially oriented and don't seem to
spend much time posting messages to forums and mailing lists. That is
not ideal for exposing APL2000 products, but is the realiity. The
VisualAPL FAQ at http://forum.apl2000.com/viewtopic.php?t=518 does
mention some application systems which included components developed
using VisualAPL including actuarial calculations, stochastic
modelling, time series analysis and finite-element analysis, form-
based access to corporate and government data bases supported by web
services and point-of-sale systems for commercial use. These were
listed in the FAQ because APL2000 was aware of, and somewhat involved
in, their development.
Morten Kromberg
> VisualAPL is fundamentally different from traditional APL
> implementations in that is not an APL-centric implementation. Although
> it is certainly possible to 'write' a new or old system entirely in
> VisualAPL, it would be anomalous to do so. VisualAPL is an
> implementation of APL which designed to be used in a multi-programming
> language environment to produce mainstream (fully-managed) solutions.
> For example, no matter what implementation of APL is considered, there
> are better languages and tools available for GUI development. The
> inter-operability of VisualAPL with components developed in other
> programming languages means that the best programming language tool
> for the job can be utilized. So, even though one could write an
> application system entirely in VisualAPL, it may not yield the best
> result. Essentially, VisualAPL is 'pure' APL, designed to support
> algorighmic and potentially array-based calculations and business
> rules, with the application system's GUI, data storage, etc. developed
> using other component programming languages better suited to that sort
> of effort.
Joe,
I'm not sure which APL systems you are thinking of when you refer to
the "traditional" APL systems that VisualAPL is supposed to be
fundamentally different from. Certainly, the above philosophy applies
to most of the recent projects that I have seen people work on in
Dyalog APL - and when I go to APL conferences I see people from IBM
and MicroAPL demonstrating solutions constructed with APL as a
computational frontend, embedded with a variety of other technologies.
APL components can be delivered as COM libraries, DotNet assemblies,
web services, web servers (using ASP.NET or "native" solutions using
stand-alone APL), WCF or MSMQ components, etc etc (today, APL
components can be deployed in the same way as components built using
any other technology). You may not be aware of this, but other vendors
have done a lot of work to make it possible to build applications in
the way that you describe, which I would agree is the only way to
approach the construction of "professional" applications for
commercial use and distribution.
The fact that some APL products still aim to provide a fertile
breeding ground for applications built by "Domain Experts" who do not
have the expertise to pull together "multi-programming" solutions does
not mean that you cannot easily build robust, high-performance, easily
deployable "embedded" applications using other APL systems than
VisualAPL.
If you take a quick look at the presentations at the Dyalog'09
conference next week (http://www.dyalog.com/
dyalog_09_conference_programme.html), you will see:
- Two presentations on using APL as a scripting language for ASP.NET
applications
- One on building an ODBC data source in APL
- One on writing Bluetooth applications for Windows Mobile devices
... and there are many others working on similar types of projects.
The design philosophy for APL applications that you describe is the
one that is being pursued by most APL vendors today, and used by more
and more APL-based development shops across the globe.
Regards,
Morten Kromberg
Dyalog Ltd.
Morten Kromberg
> ....solutions constructed with APL as a computational frontend
Oops - cut&paste got me. I mean "backend", of course. Though that does
perhaps depend on your point of view :-)
Stephen Taylor, editor@vector.org.uk
> On Sep 7, 3:42 am, "Stephen Taylor, edi...@vector.org.uk"
>
> <stephentaylorf...@googlemail.com> wrote:
> > On Sep 6, 7:59 am, AAsk <AA2e...@lycos.co.uk> wrote:
> > Anyone know of new systems written in Visual APL, or old systems
> > migrated into it? It's been out two years – I’d like to publish
> > something in Vector.
>
>
> APL2000, the distributor of VisualAPL, does not ask customers what
> application systems they have constructed with APL2000 products such
> as VisualAPL, APL+Win and APL WebServices. It would be up to the
> individual customers to disclose this to the public if they so choose.
> Most APL2000 customers are commercially oriented and don't seem to
> spend much time posting messages to forums and mailing lists. That is
> not ideal for exposing APL2000 products, but is the realiity. The
> VisualAPL FAQ athttp://forum.apl2000.com/viewtopic.php?t=518does
> mention some application systems which included components developed
> using VisualAPL including actuarial calculations, stochastic
> modelling, time series analysis and finite-element analysis, form-
> based access to corporate and government data bases supported by web
> services and point-of-sale systems for commercial use. These were
> listed in the FAQ because APL2000 was aware of, and somewhat involved
> in, their development.
It's your call, of course, how you market Visual APL. If you ever
choose, as vendors often do, to investigate what your product has been
used for and to showcase some encouraging examples, Vector would be
keen to publish it. It would be particularly interesting to hear how
your target market of non-APL programmers got on.
(Probably, as Vector editor, I should just post this question on the
Visual APL board.)
Stephen
joe_blaze
vendors have pursued and will continue to pursue compatibility of APL
programms with the rest of the programming world. In addition, vendors
should and do review the results achieved by other similar software.
What was available in VisualAPL in 2005 is now becoming available in
other vendors' products and that is great for their respective
customers.
An APL-centric programming outlook and legacy notions of what
constitutes an APL 'implementation' such as:
- Workspaces incorporating state and data besides functions
- Proprietary file systems and memory management
- APL 'quad' functions to 'candy-coat' and potentially dilute
underlying operating system features
- A proprietary workspace format itself
are very different matters. These are areas where VisualAPL has taken
bold steps to identify the essential nature of APL and eliminate from
an APL implementation that which should be directly accessed from the
underlying operating system platform. That process required judgement
which some may question in hindsight. Probably other vendors are
looking at these concepts too and may do a better job with the
benefits of that hindsight, but these advances were implemented in
VisualAPL in 2005 and are available in a production environment now.