APL in 2020 - Winners and Bandwagons
Dick Bowman
Future-gazing is fraught with problems, but can we get ourselves into a
better position by trying to make some intelligent guesses, or will going
with the flow cut it? One issue is that what might look like a hot topic
today could turn out to be an embarrassing failure tomorrow - the peril is
clambering onto a bandwagon just as the wheels fall off.
So, where might IT be headed, and what could we do to help APL set the
direction? Questions?
Which are going to be the hot application areas? And platforms?
What general (programming) tools are headed for growth?
Is there room for the "nimble team" or is programming headed toward the
"programming barn"?
If there are steep learning curves to be negotiated, can the APL world pull
together and help each other?
Phil Last
The years 2010-15 in the UK are likely to see the demise of
practically all government sponsored IT projects that can't be saved
on the we've-spent-so-much-already-it'd-be-a-shame-to-throw-it-all-
away-now principle.
This will leave much room for "Direct Development" if only
commissioners can be made aware of it.
Dick Bowman
my mind at present...
The "latest and greatest" approach to GUI design in the Windows world is -
I'm told - WPF (Windows Presentation Framework). Learning to use WPF
represents a substantial investment in time, so...
I don't keep very much in touch with latest trends in programming, which
I'd guess I have in common with a lot of APLers. So I don't know whether
WPF is already dropping out of favour in nerd-world. What I'd guess is
that WPF is a step along a well-trodden path where earlier steps are
labelled quote-quad, GDDM, quadWindow, quadWC and so forth - I'd expect
that by 2020 it will be as forgotten as most of its predecessors.
One thing I can do is learn about WPF and build myself a set of covers so
that my code at the application level doesn't need to concern itself
withthe sometimes labyrinthine contortions that WPF involves (there are
some discussions on the Dyalog forum which illustrate).
What would be better would be for several APLers to tackle this issue
(possibly in parallel) and build generally-accessible tools and documents
that translate what we find in places like MSDN. My take is that I'd be
more comfortable with this - and the prospect of a common interface
standard for APLs from different vendors - than a vandor-specific interface
which does it all for me, or having site-specific "WPF toolkits" made by
corporate users.
WPF is just one example of something happening in the world outside of APL
- where we need to form a view about whether it is worth putting effort in,
and whether we can direct this effort for our mutual benefit. My take, as
hinted above, is that we'll do better if we approach these issues through
open discussion and information-sharing rather than try to form any sort of
"official project".
That's WPF - what else is there out there that we can look at in a
nuts-and-bolts way>
AAsk
presentation tier (human interface) or layout and the business tier
(data processing) or logic.
Two different types of developers build the two tiers (human interface
by designers and data logic (complex procedural code) by programmers)
quite independently.
In theory, the designer can replace the presentation tier by
completely radical re-designs without any effect on the business tier
(and vice versa).
Win32 APL Problems:
1 - The designer and developer is ONE and the SAME person. The APL
mindset will NOT have it any other way.
2 - The APL workspace (basicaly a memory dump, very often a runtime
state memory dump does not permit the separation of the roles:
everything is held together from the outset.
Why XAML? XAML is highly portable (maintainable by any number of
tools) to any platform and greatly facilitates the unification of
desktop and internet human interfaces.
3 - Unless you program in Visual APL, i.e. use an IDE that easily
permits the separation (and subsequent re-integration) of designer &
developer roles/responsibilities, the concepts are irrelevant.
I do not believe that Workspace bound WPF is worth the effort: none of
the really tangible benefits materialise except the most trivial,
namely, the front end.
Richard Nabavi
>
>
> 3 - Unless you program in Visual APL, i.e. use an IDE that easily
> permits the separation (and subsequent re-integration) of designer &
> developer roles/responsibilities, the concepts are irrelevant.
>
You certainly don't need Visual APL for that. XAML integrates very
well in APLX and Dyalog, and in both cases you can separate the roles
as you describe:
http://aplwiki.com/UsingWPF_from_APLX
Our overall impression of WPF and XAML is very favourable. We
recommed APLers interested in user-interface programming to have a
play with it.
Richard Nabavi
MicroAPL
crishog
>
> Which are going to be the hot application areas? And platforms?
>
> What general (programming) tools are headed for growth?
>
> Is there room for the "nimble team" or is programming headed toward the
> "programming barn"?
>
> If there are steep learning curves to be negotiated, can the APL world pull
> together and help each other?
From a "high level" the trends one sees are Agile Development (trendy)
and Cloud Computing (very trendy) and Mobile Applications (uber
trendy).
I think off-shoring has hidden the "barns" somewhere in India. They
tend to crack the resulting problems of using such a ponderous
approach by throwing sheer numbers of staff at the problem. But these
aren't uneducated robots. Could we show them that APL & its ilk have
advantages even in their current situation?
"The Cloud" is an irritating phrase. some people use it to mean what
looks suspiciously like old fashioned time-sharing computing (so, hey,
APL ought to shine?) other use it merely to describe a way of managing
software - "cloud based" Word for Lord's sake. Still it's all under
the umbrella term "software as a service" I suppose.
The platforms seem to be smaller & more mobile - smart phones and the
(over) hyped iPad. A lot of "apps" are structured as client/server
tools, so APL need not be on the phone, though with Android for Linux
based APLs & Dyalog's Windows Mobile version that's possible. If it's
not on the phone itself, we're back to cloud computing - albeit with
some requirement for a client side.
Now that describes my view of the situation, but doesn't offer much
about where APL fits in, except its historic use as a time-sharing
platform. Maybe the tendency of APL to hide the operating system might
be an advantage? Simplifying the work of the client side app when it
communicates with the "cloud side"?
You can tell I'm waffling, I haven't thought it through yet. So I'd
better stop & think.
Chris
Ibeam2000
A couple of things to think about:
First, in the last few years, the hot growth area has been with
handheld and tablet computers. iPhone, iPad, iSore, etc. Often,
these are miniature browser applications which connect over a cellular
network. This is not to say that desktop computers will suddenly go
away, but more and more end-user computing which does not involve any
programming or interactive (Excel etc.) usage may work this way. I
don't see too much Microsoft here at this time.
From the server persepective, this represents a return to timesharing,
and is an area where APL could be used without too much of a paradigm
shift.
From the client perspective, writing applications which are not
browser-based may be a very high growth area. APL, from both the
licensing and software perspective, will need to "fit" on these small
computers.
Second, from around 1985 to just recently, 2005, we have experienced
substantial economic growth. The Dot Com bust was just a temporary
correction to weed out all of the absurdities like selling pet foods
over the internet and the end of the Y2K bonanza. This period of
growth is over. However, with growth, came wealth, waste, and
bureaucracy, and a style of doing IT which reflects a certain level of
opulence which no longer is the case. I imagine there will be a 3-5
or so year lag where a bureaucratic style of working will give way to
a more pragmatic one. Properly packaged, APL may have a chance.
AAsk
How?
- serially? i.e designer & developer work/test in the same workspace
in turn
- can Dyalog or APLX render a WPF form from its XAML?
Richard Nabavi
Those of us old enough to remember timesharing will also remember why
companies were desperate to get away from it. You get locked in to
ever-increasing charges and you have no control.
Worse, you are totally dependent on another company to hold your
data. No problem, you may think, as long as it is a large, reputable
and well-financed company which won't suddenly leave you in the lurch
- like Microsoft for example?
Well - here at MicroAPL we used Microsoft's accounting package and
payroll system. Last year they suddenly and with almost no warning
terminated the service, not even having the courtesy to keep it going
until the end of the payroll year. Thousands of businesses suddenly
had to scrabble around to move their existing live systems to another
supplier.
Moral: you can't trust even the largest companies to provide
continuity of service. Cloud computing puts you entirely at the mercy
of someone else, and they may suddenly disappear, get taken over, or
just (as Microsoft did) get bored and stop providing the service. I
cerainly won't make the mistake of trusting Microsoft again.
Richard Nabavi
MicroAPL
Richard Nabavi
> - can Dyalog or APLX render a WPF form from its XAML?
Yes.
AAsk
> of someone else, and they may suddenly disappear, get taken over, or
> just (as Microsoft did) get bored and stop providing the service.
A big plus of Cloud is about centralisation of data/application i.e.
the ease of managing updates and deployment without having to worry
about mundane things like backups & security.
The UK NHS have the SPINE which is a central repository of all NHS
Patient Medication Records. The vision is sound - its delivery is
suspect and beyond the control of consumers of this service/facility.
Hence, your comments about reliance on third party (and how
extortionate some of them can be) is well observed except in one
sense ... in contexts, isn't MicroAPL (or any provider) in the same
'third party' classification?
paulg
> The years 2010-15 in the UK are likely to see the demise of
> practically all government sponsored IT projects that can't be saved
> on the we've-spent-so-much-already-it'd-be-a-shame-to-throw-it-all-
> away-now principle.
>
I have just spent the last 2 hours at the Department of Health. Sure,
the world is changing and budgets are tight, 'Contractor' is a bad
word to use but collaboration is not. There are many opportunities
opening up and the key phrase is 'Business Benefit'. Those projects
(and some are very big) that have been, or are being, shut down can be
brought back to life. Now has never been a better time to offer
sometning new - fast, efficient, low cost and guaranteed delivery!
'The art of the possible in a changing world'
Paul
Richard Nabavi
> in contexts, isn't MicroAPL (or any provider) in the same
> 'third party' classification?
No. If you use a software product with a perpetual licence, you are
not dependent in the short term on the provider continuing to provide
a service. OK, if the supplier goes bust or stops stupporting the
product, you will want to migrate to a different product, but there's
no immediate urgency to do so and you don't lose your data.
In the Microsoft payroll example I gave, customers had only a few
weeks to move - an absolute nightmare for some companies, especially
in the middle of the payroll year. And there was absolutely nothing
they could do about it - Microsoft were completely uninterested.
PGilbert
is used for the GUI and 20% for the APL code itself. The main problem
for me is that the tools integrated with the APL interpreters to
develop the GUI are 'pixel' based, meaning that you are always
counting your pixels and if something changes at the end of the
project you need to start to replace everything and it's not a good
utilisation of your time doing that. With WPF you can still do it
that way or try to use some of their panels like DockPanel,
StackPanel, WrapPanel and the Grid to dispose your elements without
specifying exactly their positions. Also to have a program like
Microsoft Blend to help you do your GUI is an advantage for me, once
you have learned to use it, you can develop the GUI at an incredible
speed (Blend is free for student here at: www.dreamspark.com). A year
ago WPF was barely accepted by the programming community, now it seems
to be in a better position, but WPF is still young and will mature
some more. I think for the APL community it's a good opportunity to
join the WPF band wagon because we are not too late and it will give
us the tools to be more productive.
Pierre Gilbert
James J. Weinkam
...
> I
> cerainly won't make the mistake of trusting Microsoft again.
>
The question you should be asking yourself is what made you trust Microsoft in the first place.
AAsk
> I'm told - WPF (Windows Presentation Framework). Learning to use WPF
> represents a substantial investment in time, so...
A slight slip here ... WPF = Windows Presentation Foundation.
The GUI design standards change: new preferences emerge on the basis
of expectations and then get modified/discarded in the light of
experience.
It started with 'thick' clients, meaning the machine running/hosting
the GUI had to have (a lot of) files installed locally. This created a
scenario where deployment was deemed far too expensive. The real cost
was that the software provider had little control over when users
moved to the latest version with the implication that the provider
ended up supporting several 'legacy' versions.
This was superseded by 'thin' clients, meaning the machine running/
hosting the GUI did needed almost no files installed. Web
applications are deemed to be tin client applications - all you need
is the browser. Providers were in complete control of the version they
wanted users to use and they could deploy that version universally
from their end.
WPF (and Silverlight) sits in between 'thick' and 'thin' clients: it
produces 'rich' client GUIs that is, you need some files locally but
not as many as thick clients. Apart from being more versatile/richer,
WPF is also a bold and big step towards unifying the design standards
that applied to thick and thin clients. There is a big underlying
dividend: applications run on virtual machines and are not locked into
the architecture of the operating system.
At present, prevalent APLs are Win32 applications i.e. are locked into
the Windows Operating System. Visual APL runs on a .NET virtual
machine. Dyalog & APLX are Win32 applications with their .NET portions
supported by .NET virtual machines. Is this a double jeopardy? You can
make up your own mind!
Joe_Blaze
or any other GUI-building tool, consider instead the question, "Should
APL be used for building a GUI?".
An important trend in IT, which IMHO is here to stay, is that IT
solutions (application systems) are being built using multiple
programming languages. Each component of an application system has
special requirements and requires deep
expertise for professionial results.
Enterprises have adopted a team approach to application system
development. This team delegates the implementation of the application
system to individuals who are expert in GUI or business rules or
databases or web services, etc. No single programmer builds the entire
solution and no single programming language must be used to implement
the entire solution. The team approach permits the enterprise to
efficiently use its programmer resources.
Programming tools now reflect this trend. For example, the 'current'
Windows .Net application system development platform replaces the
previous Win32 platform which Microsoft has deprecated. The .Net
programming languages are all designed to emit CIL (common
intermediate language) which can be consumed by the CLR (common
language runtime). The CLR provides a fully-managed (safe) virtual
machine. All .Net programming languages conform to certain .Net
standards for exception handling, use of virtual memory, etc. so that
they are transparently interoperable.
The .Net development platform permits each programmer to select
the .Net language deemed suitable for their part of the work. Each of
the .Net programming languages have perceived advantages and their use
in a solution reflects programmer preferences and prejudices.
What place is there for the APL programmer in this team programming,
multi-language environment?
Some APL programmers will disdain this environment. Other APL
programmers will find themselves thrust into this environment and will
need to adapt to prosper within it.
Those APL programmers are probably 'domain experts' who are suited to
programming of the application system business rules so that complex
algorithms are incorporated into the solution in an efficient and
accurate manner.
Considering how expensive 'domain expert' time is to the enterprise,
the APL programmer should not be working on GUI, databases or other
'routine' programming tasks. These other tasks are 'routine' because a
large, international pool of
expert talent is available to perform them.
For the APL programmer who is not using a fully-managed .Net
implementation of APL, their team role may be prototyping the
application system business rules in APL, describing them to a .Net
language programmer and testing that the .Net version
of the business rules matches the APL prototype. The enterprise
project manager examining this situation may not deem this workflow to
be ideal.
For the APL programmer who is using a fully-managed .Net
implementation of APL, such as VisualAPL, their contribution to the
team effort can be much more efficient. The 'domain expert' using
VisualAPL can program the application system business rules in
VisualAPL, directly incorporate the fully-managed VisualAPL .Net
assembly into the solution and perform testing in the end-user format
of the solution.
What place is there for the APL programming language in this team
programming, multi-language environment?
The APL programming language with its functional syntax and large
contingent of mathematical operators is ideal for expressing the
complex algorithms of the application system business rules.
The compact and simply-documented core APL programming language is not
ideal for building enterprise-class GUI's because core APL was
intentionally limited to the precise expression of mathematical
concepts and GUI-building tools involve the verbose interaction of
computer and human that is subject to often-changing fashion.
Can the APL programming language be 'enhanced' to be an excellent tool
for GUI building? Vendors of APL continue to try to do this. The major
effect of this effort has been to bloat the APL language with obscure
quad functions, syntax and components which 'cover' the underlying
technology and attempt to simulate the features of the target GUI-
building tools.
The VisualAPL product avoids the bloating by including separate fully-
managed .Net assemblies for traditional []wi GUI building that a
programmer can reference in their project if desired, but the practice
is not recommended for enterprise-class solutions.
The Windows Presentation Foundation (WPF) GUI-building tools are much
more than a simple xml-format (XAML) file containing the specification
of the GUI. The Microsoft Visual Studio IDE includes a XAML editor
linked to an immediate mode session which displays and supports
testing of the WPF GUI as it is built. Event handling in WPF is quite
sophisticated with 'tunnelling' and 'bubbling' events and associated
handlers. These handlers can be specified in XAML code or in the
closely-linked, fully-managed 'code behind' file containing .Net
language source code. This is in contrast to 'loose' XAML which can be
exploited by Win32-based APL implementations, but which does not
produce fully-managed CIL. The full benefits of the WPF GUI-building
tools are readily available with purpose-built tools such as Microsoft
Visual Studio and Expression Blend. Microsoft Expression Blend is a
WPF environment which emphasizes the separate role of the GUI-building
programmer in the application system development team.
Morten Kromberg
> Stepping back a bit from the question of how APL should integrate WPF
> or any other GUI-building tool, consider instead the question, "Should
> APL be used for building a GUI?".
>
> An important trend in IT, which IMHO is here to stay, is that IT
> solutions (application systems) are being built using multiple
> programming languages. Each component of an application system has
> special requirements and requires deep
> expertise for professionial results.
Hi Joe,
I mostly agree with your observations... Just a couple of additional
comments:
1) While it makes good sense for an "enterprise" to split the work
between teams of "domain experts" and IT specialist teams (and many of
our large clients use or are moving towards this mode of operation),
APL is very often used by small entrepreneurial teams - often only one
or two people - who quickly need to get a new idea to market. In fact,
when we look where our revenue comes from at Dyalog, although most of
it comes from "enterprises" today, if we look at the history of the
big revenue-generating applications, 90% of them were started by one
or two domain experts in a garage. IT expertise was almost exclusively
added later in the game. Therefore, we believe that APL vendors MUST
continue to focus energy on making development of "complete marketable
prototypes" by individuals with limited IT skills, as effective as
possible - if we want to encourage the development of new APL
applications by people with bright ideas (which we believe is our main
purpose).
(but also enable the segmentation demanded by the larger customers).
2) I also agree that Windows Presentation Foundation is a major
milestone in the evolution of GUI frameworks, and we have started
recommending it to our customers as the most productive way to build
GUI applications using Dyalog APL. I don't know whether the use of WPF/
XAML is somehow limited from APL+Win, but we seem to be able to take
full advantage of all of the benefits that you mention, including
event tunneling/bubbling from Dyalog APL, which - despite being an
unmanaged application, like so many of Microsofts own tools - provides
tight integration with .NET object models. WPF forms can either be
edited using Visual Studio, Expression Blend etc or dynamically
generated and modified on the fly from APL - and WPF forms can also be
embedded within existing Dyalog GUI, in the same way as any other .NET
GUI controls can. I believe that APLX is also able to make pretty
complete use of WPF features. So while being "fully managed" may have
some benefits with respect to distribution of code via the web, it
certainly is not a requirement to tap in to the benefits of the
Microsoft.Net framework.
Morten
Simon Marsden
which prevents users from using WPF/XAML?
Bjorn
> No. If you use a software product with a perpetual licence, you are
> not dependent in the short term on the provider continuing to provide
> a service. OK, if the supplier goes bust or stops stupporting the
> product, you will want to migrate to a different product, but there's
> no immediate urgency to do so and you don't lose your data.
> In the Microsoft payroll example I gave, customers had only a few
> weeks to move - an absolute nightmare for some companies, especially
> in the middle of the payroll year. And there was absolutely nothing
> they could do about it - Microsoft were completely uninterested.
-----------------------------------------
This is probably the worst example of arrogance I have heard of in a
long time.
A big company like M$ is not immune to everything and behavior like
this is bound to make a dent in the customer base.
It is one thing to not continue supporting something and quite another
to demand that the customers move away from their applications.
I have never been a huge fan of M$ even if I did go in for using their
products 15 to 20 years ago because they had solutions they more or
less gave away.
I could never understand why most of the world has continued to buy M$
products long after they began to be way too expensive.
And then there is this question of cloud computing.
Once upon a time it used to be called using a server.
Over the years you watch applications going back and forth from
servers to PCs and back again.
APL has done the same. A mixture of both is the best option.
It is good to be able to do some things when off line and it is also
good to be able to have your application available on a server.
Locking into one has many disadvantages.
Having a mixture of both can cause problems of syncronisation but that
is easily solved.
I hate it when your customer has everything on a server and wants to
move data and/or application down to local site and the service
provider keeps everything hostage.
I have witnessed that happen several times in the past.
Sometimes the data is locked into some encryption and your customer
needs to pay to get the data moved out of the database.
M$ is just one more greedy service provider and with their arrogance
they will eventually lose.
I am more surprised it has not happened sooner.
J is working on two new directions regading using servers or cloud
computing if you like.
It is very interesting to participate in the beta of J7.
In J7 two completely different techniques are being developed.
One is using J from a server - the cloud - in a browser - JHS.
The other is using J locally in the GTK toolkit - JGTK.
They have both their niche uses and both are really interesting.
The old JGUI is obviously still around and available but the new GUIs
are totally different.
JHS is in a way practicing cloud computing and the GTK is exploiting
the open graphical world.
All the J development share the same J engine and there is a package
manager that helps with addons.
The addons come from the server - the cloud - and has been around for
awhile.
By going in these new directions J will be having the best of all
worlds.
There are cloud options, J can run on the handhelds that have
browsers.
J is going heavily into the world of open software.
I am writing this on the new JGTK because my computer is off line at
the moment but when I am connected it will be sent.
The new JGTK is so handy to use that I use it for most anything.
I even make grosery lists and take all kinds of notes.
PGilbert
wrote:
> Yes, I am also puzzled by that. Is there some limitation in APL+Win
> which prevents users from using WPF/XAML
No, APL+Win can't do XAML you have to switch to VisualAPL. You can
access .Net however via Eric Lescasse's NetAccess (www.lescasse.com).
Pierre Gilbert
AAsk
Really? Is APL, in the main, really for individuals with limmited IT
skills? I thought APL people were somewhat smarter than their
coounterparts using other language but the problem was that they
simply did not see the wider picture i.e. the benefits of adopting/
honing industry skills ... and in this, they were actively encoouraged
by vendors!
> No, APL+Win can't do XAML you have to switch to VisualAPL.
APL+Win can display any WPF form/control using []wi ...provided...
that the form/control were compiled as a user control; it can't build
a WPF GUI line by line.
Joe_Blaze
which prevents users from using WPF/XAML..."
A: No - see below.
Statement: "...No, APL+Win can't do XAML you have to switch to
VisualAPL..."
Test: Fortunately not correct - see below.
Actually an APL programmer can create and use WPF and XAML from APL
+Win, even versions as far back as APL+Win v3.x.
XAML is merely a variant of XML. Since 2007 APL+Win has included a
free comprehensive XML toolkit (See http://forum.apl2000.com/viewtopic.php?t=43).
Once the programmer has mastered creating XML strings, then with some
study of .Net 3.5+ it should be no problem creating XAML strings.
What to do with these XAML strings? - Turn them into a WPF control,
e.g. a form. To do this use the same tools that the other Win32-based
implementations of APL do, i.e. use .Net WPF components to convert
this 'loose' XAML to GUI controls. This is quite well documemented
here: http://aplwiki.com/UsingWPF_from_APLX. Using these .Net
components with APL+Win involves one more easy step and that is to
expose the .Net WPF components as ActiveX. Use the Lescasse NetAccess
tools included in APL+Win v8.x+ to do this.
The result, just like the result from any other Win32-based
implementation of APL, will be a WPF control which is based on Win32
code, so that it is not 'fully-managed'. Event handlers, for both
'bubbling' and 'tunnelling' events, are exposed by the NetAccess code
to APL+Win handler functions.
The performance of an Win32 APL, ActiveX and .Net ensemble is actually
quite good and even improved in .Net 4.0, but IMHO it's not pretty. No
Win32 APL and .Net interaction is pretty.
Why not think 'laterally' and consider that maybe this time, Microsoft
did it right with WPF GUI building tools? Consider using the Microsoft-
provided tools like Visual Studio with its immediate mode WPF session
(and a fully-managed, transparently inter-operable programming
language like C#, VB.Net or VisualAPL) or Expression Blend (A WPF GUI
building tool for designers rather than application programmers). By
all means, keep using APL for the application system's business rules.
That design paradigm will correspond to the multi-language application
system development trends of today.
Joe_Blaze
to distribution of code via the web, it certainly is not a requirement
This is a good point to keep in mind. APL implementations are in
transition. But right now, there are some benefits to using the non-
fully-managed capabilities of .Net. .Net itself is constantly in
transition and expanding too, so capturing it with APL 'cover'
functions is probably not going to be adequate. IMHO a .Net APL, such
as VisualAPL, is going to be necessary to be a peer of the other fully-
managed .Net programming languages like C#, VB.Net and F#.
Benefits of Fully-Managed Code:
Transparent inter-operation with any .Net programming language
Uses the CLR virtual machine exclusively so it is inherently 'safe'
In demand by certain government agencies and large enterprises
Certain application system deployment options are facilitated
Microsoft has deprecated Win32 and replaced it with .Net
Disadvantages of Fully-Managed Code (for APL):
.Net APL programming workflow changes to include a compile to CIL
step
.Net APL needs to support .Net programming language standards for
exception handling, object localization, available key strokes and
glyph associations, assignment by reference, etc.
.Net APL needs to support more of the vast array of .Net data types
than its traditional datatypes.
PGilbert
> Q: "...I am also puzzled by that. Is there some limitation in APL+Win
> which prevents users from using WPF/XAML..."
> A: No - see below.
>
> Statement: "...No, APL+Win can't do XAML you have to switch to
> VisualAPL..."
> Test: Fortunately not correct - see below.
>
> Actually an APL programmer can create and use WPF and XAML from APL
> +Win, even versions as far back as APL+Win v3.x.
>
> XAML is merely a variant of XML. Since 2007 APL+Win has included a
Thanks Joe for your clarification about doing XAML with APL+Win. One
problem I have with APL+Win is that you have declared it on the
APL2000 forum to be a 'legacy' mode from now on, and you encourage
vigorously your customers to switch their application to VisualAPL.
'Legacy' mode meaning it will not be supported aggressively anymore.
How can a user of APL+Win can entertain any discussions with APL2000
about XAML in a case like that ? Your attitude was more like 'if you
are not with me, than you are against me'. I think you have achieved
something unique with VisualAPL and I congratulate you for that but
the transition from APL+Win to VisualAPL may take longer than hoped
unfortunately for some reasons. If you are taking the time to explain
how to do XAML with APL+Win are you telling us that APL+Win is no more
in 'legacy' mode ?
Pierre Gilbert
AAsk
wherein APLs are caught i.e. Win32 & unmanaged code as distinguished
from the current
industry favoured architecture: virtual machine (.Net & Java) &
managed code (.Net)
'Legacy' does not describe APL+Win in terms of ongoing development;
nonetheless, some mud always sticks, doesn't it? ...
... see APL+Win's recent history from www.apl2000.com:
2010
•July 21, 2010: Join APL2000 at the APL2010 Berlin Conference
September 13 - 16, 2010.
•July 19, 2010: New APLNext VisualAPL Installer Version 1.5.8099 Now
Available.
•June 10, 2010: APL+Win Version 10 (79.6.03) Beta Available to
subscribers - via Software Downloads.
•May 28, 2010: APL+Win Version 10 (79.6.02) Beta Available to
subscribers - via Software Downloads.
•May 27, 2010: APL+Win Version 10 (79.6.01) Beta Available to
subscribers - via Software Downloads.
•April 28, 2010: Recently announced at the 2010 APL2000 User
Conference - In APL+Win 10, scalar and array operations will run
significantly faster, as much as 50% faster!
•April 26-27, 2010: 2010 APL2000 User Conference
•January 27, 2010: Exciting New Breakthroughs in APL+Win
2009
•October 27, 2009: APL+Win Version 9.2 Available to subscribers - via
Software Downloads.
•October 15, 2009: APL+Win Version 9.2 (89.2.05) Beta Available to
subscribers - via Software Downloads.
•October 13, 2009: APL+Win Version 9.2 (89.2.03) Beta Available to
subscribers - via Software Downloads.
•August 31, 2009: APL+Win Version 9.2 (89.2.01) Beta Available to
subscribers - via Software Downloads.
•June 8, 2009: APL+Win Version 9.1 Available to subscribers - via
Software Downloads.
•March 24, 2009: NetAccess 3.1 Available to subscribers - via Software
Downloads.
•March 20, 2009: New APLNext VisualAPL Installer Version 1.5.8060 Now
Available.
•March 13, 2009: New APLNext VisualAPL Installer Version 1.5.8050 Now
Available.
•March 11, 2009: New APLNext Application Server (APLWebServices)
Installer Version 1.4.
•March 1, 2009: APL+Win Version 9.0 Available to subscribers - via
Software Downloads.
•January 4, 2009: NetAccess 3.0 Available to subscribers - via
Software Downloads.
2008
•December 30, 2008: APL+Win Version 8.3 Available to subscribers - via
Software Downloads.
•November 17, 2008: APLNext APLWebServices Information Page.
•November 13, 2008: NetAccess 2.2 Available to subscribers - via
Software Downloads.
•September 16, 2008: APL+Win Version 8.2 Available to subscribers -
via Software Downloads.
•June 11, 2008: Zark APL Tutor An interactive tutorial for learning
APL.
•May 28, 2008: APL+Win Version 8.1 Available to subscribers - via
Software Downloads.
•May 8, 2008: Experimental APL+Win Release with Optimized Scalar
Functions (PDF file) Available to subscribers - via Software
Downloads.
•April 25, 2008: APL2000 User Conference: November 10-11, 2008
•VisualAPL 1.0 is Here!. View the Press Release.
•APLNext WebServices Commerce Server with HTTPS/SSL support.
Joe_Blaze
Thanks for the questions which give me another opportunity to stay
inside and out of the 100F+ heat wave in the eastern U.S. right now.
Pierre: ...One problem I have with APL+Win is that you have declared
it on the APL2000 forum to be a 'legacy' mode from now on...are you
telling us that APL+Win is no more in 'legacy' mode?...
Joe: The basis for the 'legacy' status of any Win32-based application
system including APL2000 APL+Win and Dyalog APL is entirely external
to APL2000 and me. My comments on the APL2000 Forum are merely
statements of the obvious. Microsoft and virtually the entire Windows
application development community have deemed the Win32 application
programming interface (API) deprecated and replaced by .Net. This
means that since roughly 1998, Microsoft has not made any enhancements
or bug fixes to the Win32 API. There continues to be a world-wide
transition of application system from Win32 to .Net and in some cases
to Java-based and web-server implementations.
That a particular implementation of APL is part of a legacy is not
new, e.g. APL for the MCM machine and APL+DOS. Application systems
built with those 'legacy' implmentations of APL which were deemed of
sufficient value were transitioned to more recent implementations of
APL.
The connotation of the word 'legacy' is in the 'eye of the beholder',
but for me it has a neutral connotation which is refined only by its
use in context. For example the legacy of science is only positive or
negative in context, "biological weapon" or "pennicillin". There is no
negative context to the legacy Win32 base of applications. It has
generated fabulous utility for Windows users and excellent revenue for
Win32 programmers.
Pierre: ... you encourage vigorously your customers to switch their
application to VisualAPL...
Joe: I do vigorously encourage customers to convert their application
systems to .Net and I consider it the responsible thing to do. I
know personally the considerable study and effort required to have a
successful transition from Win32 to the current Windows .Net API.
Knowing some of the strategic application systems that APL2000
customers have developed using APL+Win, starting the analysis, design
and
implementation of a transition to .Net should be done sooner rather
than later.
How the transition to .Net is performed can have significant
implications. From actual experience, I cannot recommend trying to
'cover'
.Net functionality from Win32. It produces code contortions, reduces
application system performance and delays the application system
programmer's understanding and full transition to .Net. Such an
approach can also quickly become obsolete, because the .Net
environment
rapidly changes. I recommend using .Net programming languages that
produce fully-managed CIL to run on the CLR, such a VisualAPL and C#
because using Win32-based 'cover' functions for .Net features now can
significantly increase the ultimate cost and effort for the full
transition to .Net.
IMHO it is mythology that there could be a magic version of APL which
could make the transition from Win32 to .Net transparent and seamless
for an APL programmer. There is good evidence for this in that
Microsoft itself has not found an easy way to seamlessly transition
the Win32-based Microsoft Office product to .Net. Note also that
Microsoft has developed several generations of Visual Studio
Tools for Office (VSTO) in an attempt to create a transparent bridge
between .Net and Win32-based Office. VSTO programming is far from
ideal and VSTO applications are often difficult to deploy.
It is appropriate to ask, what about the next API after .Net? The
answer is to adopt 'defensive' programming. Use the multi-tier and
often multi-programming-language development methodology which
implements separate modules for GUI, business rules and data. Use
VisualAPL for the business rules (either locally-installed or web-
server-based) and use interface functions to isolate and interact with
the GUI and data storage. This re-configuration of legacy APL
application systems is often the bulk of the transition effort. The
business rules of an application system are calculation- and logic-
oriented and so use 'pure' APL which is largely invariant from APL+Win
to VisualAPL. Using .Net languages for each of the components assures
transparent inter-operability among the modules for easier debugging
and subsequent maintenance.
Beyond transitioning pre-existing Win32 application systems to .Net,
certainly new Windows-based application systems should be developed
using the current tools like Microsoft Visual Studio and .Net
languages like C# and VisualAPL. To do otherwise would be to
needlessly
increase future transition effort and cost.
Pierre: "...'Legacy' mode meaning it will not be supported
aggressively anymore..."
Joe: APL+Win V10 is a major enhancement to the product, including very
significant performance improvements 50%+ speed increase for
heavily numeric application systems with no APL source code
modification required), multi-threading support for multi-processor/
core
hardware (using the APLNext Supervisor), important programmer session
enhancements, additional Unicode support, new control structures,
enhanced exception handling and reporting, etc. See here for some
details under "What's New" section: http://www.apl2000.com/. The
reasons for this significant upgrade to APL+Win is because a host
existing customers use APL+Win and some of them requested these
features. In addition the most recent APL2000 User Conference in
Bethesda, MD had a concentration on APL+Win topics. This appears to be
'aggressive' support of the APL+Win product.
Pierre: "...the transition from APL+Win to VisualAPL may take longer
than hoped..."
Joe: I did not 'hope' that there would be a transition from Win32
to .Net, rather I observe that transition and its pace and know that
it is caused by events that are external to APL2000. Being personally
more interested in the mathematics of applications, it is a digression
to learn about .Net and find a suitable pathway to utilize it instead
of what is familiar but deprecated. Accepting the need for the
transition and adopting efficient and rational transition practices
means that I can get back to my interests more quickly.
Pierre: "...How can a user of APL+Win can entertain any discussions
with APL2000 about XAML in a case like that?..."
Joe: I think that it is amazing that APL+Win V3.5+ can interact with
XAML and WPF at all. The methodology to do so is not ideal, but it
does work rather well. It is manifestly better to create XAML-based
WPF GUI's using purpose-built tools like Microsoft Visual Studio and
Expression Blend however.
Pierre: "...Your attitude was more like 'if you are not with me, than
you are against me'..."
Joe: Actually, I believe that you are confusing me with a former
president of the U.S. who has an older relative who was also once the
president of the U.S.
Morten Kromberg
> system including APL2000 APL+Win and Dyalog APL is entirely external
> to APL2000 and me. My comments on the APL2000 Forum are merely
> statements of the obvious.
I have not read the comments to which you refer, but as you know very
well, I STRONGLY resent your continued slippery comments which attempt
to tar Dyalog APL and other APL systems with the same “legacy” brush
that you, for reasons best known to yourself, wish to use to refer to
your main product, APL+Win. In general, it is our policy to co-operate
with APL vendors at the marketing and – when it is possible as it was
when we designed []XML together with MicroAPL – at the technical
level. We believe that we will all benefit from the spread of
“functional infix array languages” and that we all have more to gain
by co-operating in growing this market than we stand to potentially
lose fractions of market share within the community.
But you make this VERY difficult, Joe... I have asked you several
times, both in public and private, to stop using the word “legacy” to
refer to other APL products than your own. It appears that you cannot
resist continuing this negative marketing campaign. It is fine that
you tell people that you think .NET is a great platform and Visual
Studio is a fine development environment, but trying to scare everyone
onto your latest “single platform” APL system by claiming that anyone
not using Visual Studio is “legacy”, is simply BULL SHIT. I think it
is a shame that you think of APL+Win as “legacy”… Personally, I don’t
think VisualAPL looks like a solution to dig anyone out of a platform
dependency: This product seems rather tightly bound to particular
incarnations of Microsoft products (the C# compiler, Visual Studio and
other components). Therefore, it seems doomed to a fairly troublesome
and limited lifetime as Microsoft mutates and retires the pieces upon
which it is built. It is possibly already more than halfway to a
situation that you would describe as “legacy”, and is leading anyone
who uses it towards another set of expensive (or, given that the core
language is a blend of APL and C#, perhaps impossible) conversion
projects, 3-5 years down the road (maybe 8-10 if you are lucky).
Referring to Dyalog, APLX and APL2 (and NARS2000) as “Win32 systems”
can only be explained by a fundamental lack of knowledge about these
products. You seem to assume that these products have a similar
philosophy and architecture to APL+Win, but from the way you talk
about APL+Win, this seems not to be the case. The other APL products
that you refer to are in fact ALL cross-platform systems. Many of them
originated under other systems that Windows, provide GUI capabilities
on a variety of platforms, and in many cases 64-bit versions as well.
Win32 is only one of many APIs that they support. They provide
integration with the several object frameworks. Our own product
started its life as a character based 16-bit Unix interpreter. It has
supported character mode Unix, then DOS applications, became a 32-bit
product with support for the Win32 API and now a variety of ways to
produce user interfaces based on 32- and 64-bit Microsoft.Net –
protecting the investments of our customers through the ages. We are
currently in the process of developing a web frontend which will allow
you debug APL sessions and create web/cloud applications using
SilverLight frontends - on just about any client platform. This kind
of evolution is perfectly possible if you take a long term view, have
a good fundamental architecture and a skilled, enthusiastic
development team who really understand what makes APL interpreters
valuable.
As far as I know, there is only ONE commercial product which seems to
be tightly bound to the Win32 API, and that would be “APL+Win”. Thus,
you need to limit yourself to this product when you talk about “Legacy
Win32” systems, to avoid bending the truth. And in fact, besides APL
+Win, I know of only one other APL system that specifically targets a
single platform and “toolchain”, and that would be VisualAPL. You can
claim that .NET is a multi-platform system, but that is only true in a
limited sense.
For example, there is no guarantee that Microsoft.Net will be dominant
in either the cloud or the mobile arenas, which are the most exciting
new platforms that we should be thinking about writing applications
for today. It will probably be a “significant” player, but the
“mainstream” is rapidly tiring of complex, “bloated” frameworks.
Companies like Amazon and Google are promoting much simpler frameworks
for applications, which I think APL could fit into very nicely. So
yes, APL needs to work well with .NET - but it must also survive .NET,
and at the moment is it only the products that you brand as
“legacy” (or new systems, yet to be built) that will be able to do
this easily. You are welcome to continue to sing the praise of
Microsoft.Net (and I will join you in many of these songs – I agree
that WPF is excellent), but to imply that anyone who has not drunk the
koolaid has lost their way, is ridiculous. Swallowing .NET & Visual
Studio hook, line and sinker is not an example of “lateral thinking”,
it is in fact rather short-sighted.
At Dyalog, we generate APL systems for 32 and 64 bit Windows, AIX,
Solaris, Linux and Windows Mobile from the same source code. Our
“bridge” to Microsoft.Net is a managed component which makes it
possible for Dyalog APL to integrate seamlessly with the .NET
framework. I don’t know the details of how you do this under APL+Win,
but our interface is not a set of “cover functions”, it is an
interface layer which completely immerses APL within the .NET class
hierarchy. The fact that the APL engine is unmanaged does not
interfere with this, and using mixed modes is a technique that
Microsoft themselves do use for many of their applications. It isn't
"magic", but it has allowed most recent Dyalog-based applications
started under Windows to leverage .NET in one way or another - using
the same "dot notation" to access .Net components that you would use
from a managed APL system. Sometimes, APL is “completely immersed”
in .NET, as when Dyalog APL is used as an ASP.NET scripting language
or is called by frontends written in C# or other languages. Sometimes
APL drives .NET GUI, for example using WPF (just a few applications
starting up on WPF right now, nothing near production yet as far as I
know). Often, APL just uses GUI components from Developer Express
or .NET control, in an existing Win32 GUI forms (we added this
capability in version 12.1). Finally, many applications use utilities
from .NET like ADO.NET, file handlers, etc. But many customers want to
avoid .NET dependence, and use non-.NET web server/service frameworks.
We certainly DO have legacy/Win32 applications built in Dyalog APL,
but we provide a smooth transition path, allowing customers to write
new code or entire new applications using state-of-the-art components
and tools.
We firmly believe that it remains important to allow “subject matter
experts” to build “marketable prototypes”, to get new ideas to market
quickly. Writing multi-tier applications as you suggest is generally a
good software engineering practice, of course – but the cost can be
prohibitive and the skills required are often not available at the
start of a project. Successful applications will often subsequently be
enhanced by “professionals”, so our second priority is to make this
work well. Our most important challenge is to deliver interfaces to
emerging application-building tools in a form which makes both of the
above possible, in order to first secure the creation of new
applications written in APL, and then the maintenance. It is also
extremely important that APL applications do not need to be rewritten
each time a new technology becomes available. Our customer
applications are written quickly and tend to live for decades – but
they only become “legacy” applications if the customer fails to
refactor them to meet emerging requirements.
Morten
Joe_Blaze
Except for the tirade nature of your text, the discussion of these
issues is actually beneficial to APL because it brings out the
differing opinions and experience about how APL can adapt to and
possibly survive in a rapidly changing software development
environment.
There is no need for a point-by-point analysis of your claims here, as
I think that most readers can review both of our comments and perform
the analysis themselves, incorporating their own feelings and
experience and then hopefully commenting themselves.
My question to you about Dyalog APL and Win32 would be: "On the
Microsoft Windows platform, does Dyalog APL depend upon Win32
components?"
Some potential points of further, hopefully tirade free, discussion
might be:
Do current implementations of APL tend to be "Jacks of all trades and
masters of none"?
Does the invariant nature of 'pure' APL over time make it ideal for
implementing the business rules tier of an application system, but
noto for the GUI and data tiers of those application systems?
How well does a .Net-based application system run on Unix, Apple and
other platforms?
Can an application system be designed 'defensively' to avoid
excessive re-purposing?
Is Microsoft technology on the way out (despite the fact that 2010
will be one of its greatest revenue years)?
Does "Microsoft-hate" blind programmers to the opportunities
available?
When is 'fully-managed' code necessary?
How do the features of APL really 'stack-up' against other
programming language features today?
What do the various operating system platforms have to offer?
What place does APL have in a multi-programming language development
environment and what external standards might APL have to adopt to
provide transparent language inter-operation?
Why are so few of the millions of application system programmers
using APL?
Can there be a 'mass market' implementation of APL?
What is the best way to build application system prototypes?
Should an APL implementation be 'enhanced' with interfaces like
[]net, []cloud and []mobile?
Is 'infix' syntax necessary to enjoy the power of APL?
How should/can APL run on the virtual machines of the .Net CLR and
Java engines?
Should APL implementations be purpose-built for a specific operating
system platform?
What do APL programmers who are not building commercial application
systems need?
Can an APL implementation be developed for ultra-high-performance
computing and who would use it?
How many commercial application systems have been developed using a
non-Windows-based implementation of APL?
How does the traditional APL IDE compare to the Microsoft Visual
Studio IDE?
How many truly new application systems are being built, in whole or
in part, using APL?
Phil Last
Rewrite all the APL primitives as stand-alone C(?) routines. Ensure
each is capable of handling arrays from scalar to multi-dimensional.
Arrange, if you like, to have an aliasing system where each would be
invoked by a reference to a funny symbol.
Without infix notation it would bear only a superficial resemblance to
APL.
Remove all the funny symbols and add infix notation; et voilà! APL.
APL is array oriented infix notation.
WildHeart
> Morton:
Morton? Spell-checker in action?
--
Stefano
Bjorn
AAsk
Morten Kromberg
> Except for the tirade nature of your text, the discussion of these
> issues is actually beneficial to APL because it brings out the
> differing opinions and experience about how APL can adapt to and
> possibly survive in a rapidly changing software development
> environment.
It *was* a tirade - but I make no apology. From where I sit, it was no
more of a tirade than your endlessly repeated and entirely false
characterization of Dyalog APL as a "Legacy" system. This product is
very much alive and being developed at a faster rate than ever before.
It supports and promotes the use of the very latest development
methodologies for APL Application development - without forcing those
users who wish to follow a more conservative path from carrying on as
they prefer.
But let us agree to stop the tirades... You have posed some
interesting questions and, once I get to the other side of the
Atlantic, I will attempt to respond to them - probably only one or two
at a time, to keep this thread from getting too complex.
Regards,
Morten
PGilbert
> e.g. a form. To do this use the same tools that the other Win32-based
> implementations of APL do, i.e. use .Net WPF components to convert
> this 'loose' XAML to GUI controls. This is quite well documemented
> here:http://aplwiki.com/UsingWPF_from_APLX. Using these .Net
> components with APL+Win involves one more easy step and that is to
> expose the .Net WPF components as ActiveX. Use the Lescasse NetAccess
> tools included in APL+Win v8.x+ to do this.
Hello Joe, could you show me how to convert a XAML string to a form in
a APL+Win environment and post your solution to the APL Wiki that you
are referring to in the above paragraph. I propose to take the 3
round buttons XAML that you can find here http://learnwpf.com/Data/Images/roundgelbuttonStyle.xaml
has the XAML source for this exercise.
Thanks in advance,
Pierre Gilbert
Joe_Blaze
> On Jul 23, 5:51 pm, Joe_Blaze <joe.bl...@apl2000.com> wrote:
>
>
>
> > What to do with these XAML strings? - Turn them into a WPF control,
> > e.g. a form. To do this use the same tools that the other Win32-based
> > implementations of APL do, i.e. use .Net WPF components to convert
> > this 'loose' XAML to GUI controls. This is quite well documemented
> > here:http://aplwiki.com/UsingWPF_from_APLX. Using these .Net
> > components with APL+Win involves one more easy step and that is to
> > expose the .Net WPF components as ActiveX. Use the Lescasse NetAccess
> > tools included in APL+Win v8.x+ to do this.
>
> Hello Joe, could you show me how to convert a XAML string to a form in
> a APL+Win environment and post your solution to the APL Wiki that you
> are referring to in the above paragraph. I propose to take the 3
> has the XAML source for this exercise.
>
> Thanks in advance,
>
> Pierre Gilbert
Hi Pierre,
When the link is clicked, the page was re-directed and then nothing
but an html error displayed. I can find another button sample to
create an example on the APL2000 Forum when time permits.
Joe_Blaze
Morten,
Ok - sounds good.
Sorry for the name-spelling error. However I don't see how a spelling
checker would have found it, do you?
PGilbert
>
> - Show quoted text -
Hi Joe, you can go to this link:
http://learnwpf.com/Posts/PostsByCategory.aspx?categoryId=72d8bc82-6537-429a-b771-0e365a36d82e
and do SaveAs on the link of the second paragraph that is the buttons
in questions.
Pierre Gilbert
Phil Last
Is infix notation necessary for user-defined functions?
If you want to restrict yourself to only monadic functions then I
guess you can get away without infix at the top level but remember
that the definition of those functions will then suffer the same
paucity all the way down the tree.
Johannes Brahms made a brilliant piano transcription of Bach's
Chaconne for left hand while Ernest Vincent Wright apparently wrote
"Gadsby" without using the letter "e". Nevertheless, taking your
question in the wider context of functions and operators, deliberately
to dispense with all the additional subtlety, expressiveness and power
of being able to combine both primitive and user-defined functions
each with primitive and user-defined operators which presuppose infix
notation is perverse in the extreme.
Perhaps this is a clue to your continual denigration of APL. You don't
actually realise how marvellous it is.
AAsk
understand the issues before pronouncing your verdict. Actually, feel
free to pronounce regardless. Time will tell.
1 - the move to virtual machines & managed code is not an option, no
more an option than it was to move from DOS to Windows.
2 - why was it not viable to write yet another quad function to access
Windows and now it is right to do so to access .NET? As a transient
measure, yes, it is perfectly valid but it is not making strides
forward.
3 - APL as a blackbox - everything stored as a memory dump (workspace)
or in custom format files accessible only by the creator arouses
distrust and shows APL in very poor light. Without APL applications
sharing/re-using resources and cooperating with other applications, it
represents poor 'corporate' value for money. This is 'unfair' but
until APL users begin to think differently, nothing will change.
Before you write the response, consider the question: Why aren't there
many more APL programmers? Why isn't there wider support for this
language in the wider IT mainstream? The majority view of APL cannot
be wrong; even if it is, that must be fate.
The existing users who see APL as the <only> tool in the toolchest are
the biggest impediment to the success of this language. APL is just
one tool - it needs to learn to co-exist without coercion.
WildHeart
> Sorry for the name-spelling error. However I don't see how a spelling
> checker would have found it, do you?
Quite the opposite. Most spell-checkers will flag "Morten" as a
spelling mistake and suggest "Morton" as its proper spelling.
--
Stefano
Morten Kromberg
> You should take time to read the messages and even longer to
> understand the issues before pronouncing your verdict. Actually, feel
> free to pronounce regardless. Time will tell.
Ajay, telling people who don't agree with you that they are not
thinking about what they are writing is very very rude. Can YOU think
about that before you write something like the above again in this
forum?
> 1 - the move to virtual machines & managed code is not an option, no
> more an option than it was to move from DOS to Windows.
Sure - for most run-of-the-mill applications. But probably not for
"supercomputing" or other number-crunching applications, where APL may
have a very important role to play. So we'd better not make ALL our
interpreters require virtual machines. And even if you are completely
right, even Microsoft is only about halfway there (at best) with their
own tool chain, and taking some care to protect the investment of all
their customers.
> 2 - why was it not viable to write yet another quad function to access
> Windows and now it is right to do so to access .NET? As a transient
> measure, yes, it is perfectly valid but it is not making strides
> forward.
I can't quite understand what you are saying... Dyalog APL certainly
does not use a quad function to access .NET (other than "[]USING, but
that is equivalent to "Using" statements in other .NET programming
languages). Quad functions are fine for talking to API's like Win32.
But Microsoft.Net is a framework. A quad function would be a
ridiculously small hole through which to talk to it; In our view, you
have to integrate the framework completely with the language to allow
people to take full advantage of it. But I can't imagine that you
disagree with that, that is exactly what you get with a managed
interpreter?
> 3 - APL as a blackbox - everything stored as a memory dump (workspace)
> or in custom format files accessible only by the creator arouses
> distrust and shows APL in very poor light. Without APL applications
> sharing/re-using resources and cooperating with other applications, it
> represents poor 'corporate' value for money. This is 'unfair' but
> until APL users begin to think differently, nothing will change.
I don't know of anyone who disagrees with the latter part of the
above... What exactly is your point? Just about every APLer I talk to
(who is actually working on an application, rather than watching it
fade away), is busy sharing resources and data. This is pretty easy
now, from any APL you care to mention.
On the other hand, for personal computing applications, storing
everything in a custom format like .XLS is something that millions of
Excel users have found to be very useful. Were they all completely
wrong, too? They also need to tap in to corporate databases for some
apps, of course - but having your application state as a single file
is something extraordinarily handy.
> The majority view of APL cannot be wrong; even if it is, that must be fate.
Why? History is full of examples of the minority being right. If it
pains you so much to be part of a minority, perhaps you should be
somewhere else?
> The existing users who see APL as the <only> tool in the toolchest are
> the biggest impediment to the success of this language.
Only SOME APLers actually take that view, and many of those who DO
feel that way are correct in their view. They happen to be tapping in
to the main selling point of the language. This seems to be an
impossible idea for you, based on previous iterations of this
conversation, but you need to try and see if you can believe it:
Being able to solve problems using a computer, but without being a
software engineer, is going to be one of the most valuable skills in
the decades to come. Everyone else is very likely to be either
outsourced or automated, as they are performing "unskilled labour".
Can we please stop going round this loop now?
I will not buy this record, it is scratched.
Morten Kromberg
Win32 components?
Morten: This depends on what you mean by "depend" and exactly how much
of Windows you include when you say "Win32". I don't think Dyalog APL
"depends" on "Win32" to any greater extent than Visual Studio does.
And there is no hurry to remove these dependencies: Although the .NET
framework is richer and more attractive than Win32, there is no RISK
involved in continuing to call Win32 API functions, except for the
fact that you cannot build safe applications that can be downloaded
off the internet. The Win32 API can not really go away so long as
Windows continues to exist. Not even Microsoft could get away with
that. They may eventually be able to rewrite Office and Visual Studio,
but there would be no more Oracle for Windows, no more SAP, and not
even any more SQL Server for Windows - and I don't think that product
CAN be rewritten as managed code and remain a competitive with Oracle
and others. This isn't going to happen in any of our lifetimes, unless
Windows itself disappears in some unfathomably violent upheaval of the
market. The notion that we are heading for 100% managed code any time
soon is simply hype, and I don't even hear Microsoft spouting it any
more.
We certainly do CALL Win32 (or "Win64") under Windows. At the present
moment our Windows IDE is a Winxx GUI application (as are recent
versions of Visual Studio). We expect to have a WPF/SilverLight/
MoonLight based alternative for our next release (almost keeping pace
with VS 2010, I believe - although I'm not sure VS will run under
SilverLight). We don't expect the new IDE to replace the current one
immediately as it will take some time to build out all the
functionality, but some people will want to used the RIDE (Remote IDE)
1.0 release for cross-platform and remote debugging (sexy GUI to edit
& debug multi-threaded AIX and Solaris APL code, etc). At that point,
I don't think we will have any real dependencies on WIn32. The core
language (and file system) generally uses portable C library calls, at
the "Posix" level where we can get away with it. This code has to run
on a wide variety of platforms so it cannot be closely tied to any
particular API.
Morten Kromberg
> Ajay, telling people who don't agree with you that they are not
> thinking about what they are writing is very very rude. Can YOU think
> about that before you write something like the above again in this
> forum?
I am not living up to my own suggestion here. Ajay, I apologise. I
know that you only wish the best for APL and its users.
I hope that we can all continue these discussions in a constructive
light. The good news is that this passionate exchange of opinions
proves how much we care. I shall try to remember that as I phrase
future posts to the forum.
Morten
crishog
> 1 - the move to virtual machines & managed code is not an option, no
> more an option than it was to move from DOS to Windows.
Err.. I do 90% of my work in Linux. Microsoft Managed Code isn't even
relevant.
> 3 - APL as a blackbox - everything stored as a memory dump (workspace)
You store code & date in a workspace? Since the 70s my data has always
been in files (and component files have always been accessible to
anyone who could bother) and actually my code has been too, as I've
used function files since time-out-of-mind and normally my workspace
has a single function which loads everything from file. Maybe the code
wasn't readable by a C programmer, but putting APL code in Visual
Studio won't ensure an C programmer understand it either
A workspace is great as a "scratchpad", but I agree with you, I
wouldn't write any system around a workspace-based code system, let
alone one which actually holds data in it.
> The existing users who see APL as the <only> tool in the toolchest
Sadly most of my current work is in non-APL environments, I'd love to
do more APL. Which normally leaves me cursing & wishing for APL
functionality when the system I'm using falls short. That doesn't mean
APL is right, it merely means it delivers a lot which I cannot get
from other tools. My concern is what do they have to do to CATCH UP
with a 50 year old tool like APL?
Yes, APL-only developers have to accept that the world has moved on,
but punting for a single, limited alternative isn't my idea of the way
to go.
Bjorn
> Yes, APL-only developers have to accept that the world has moved on,
> but punting for a single, limited alternative isn't my idea of the way
> to go.
I do not think there is only one single alternative.
There are actually quite a few alternative, options and directions.
That in itself has both negative and positive sides.
I think that there are decades since most of us gave up on the vision
that it would be possible to get APL to go in one single direction.
cjl
I don't know if you noticed on my blog, but Mike Jenkins has stepped
up to the plate and will be contributing to the documentary.
Joe_Blaze
eventually be able to rewrite Office and Visual Studio
Joe: Certainly Microsoft Office is an application that cannot be
implemented in .Net without careful technical and business analysis.
The issue there is really not the Office application which might event
be improved by using .Net, but the magnitude of the VBA code developed
by end users which is not amenable to conversion to the .Net
equivalent.
The same with Visual Studio 2010. It appears to be largely written
in .Net as compared to Visual Studio 2008. Again the un-managed
programming languages it must support prevent complete conversion
to .Net.
Richard Nabavi
Yes, there are lots of reasons why particular pieces of software will
not be converted to managed code.
As Morten pointed out, in addition to Office and Visual Studio, that
includes Oracle, SAP, and SQL Server. He could have added DB2, Flash,
Acrobat, R, Ruby, and indeed the Java Virtual Machine, and many, many
others. A huge volume of software, perfectly mainstream in all large
organisations, which will remain in native code for the foreseeable
future. The fact that most APL interpreters are currently in the same
category as, say, Excel, is no big deal.
In fact, the problem of corporate acceptability of non-managed code
has not been a big issue in our experience, provided the code is
signed with a digital certificate.
What is important is to give APLers easy, natural access to all the
good stuff in .Net (and, we believe, other environments such as Java,
Ruby and R). We're agnostic about choosing 'winners'; we feel
decisions as to what APLers should be able to interface to should be
made by our customers, but we'll sometimes make something available on
our own initiative if it looks interesting.
Our intention is the exact opposite of wanting everything to be done
in APL itself; to the contrary, we want to make it as easy as possible
for the APLer to take advantage of all the other code, managed or
unmanaged, which is out there. We do that through generalised
interfaces which do not require us to create new system functions all
the time - that is a great step forward, made possible by the object-
oriented extensions to APL combined with the 'Reflection' feature of
modern systems like .Net and Java.
As for Win32, no, APLX is not specifically dependent on Win32 at all.
In fact you can run the front-end on one architecture (for example,
MacOS) and the interpreter itself on another (for example, Linux 64-
bit).
Richard Nabavi
MicroAPL Ltd