Legacy
Phil Last
"legacy APL" on the net.
This appears, contrary to expectation, not to be engendered by people
antagonistic to APL but within the APL community itself.
The main culprits appear to be "SmartArrays" and "VisualAPL".
Here's a contribution from SmartArrays:
------------------------
> Struggling with Legacy APL?
>
> * Critical applications that nobody understands?
> * Unable to find developers to maintain or enhance them?
> * Need to put the functionality into modern web-based solutions?
>
> We can help!
--------------------
There can be a legacy application in any language however new if the
means to maintain it disappears. This is definitely not the case with
APL.
* The first point is either nonsense or applies equally to all
applications in any language; I should have trouble understanding a C#
application never having seen one; or an APL one where the function &
variable names were in Deutsch for that matter.
* Plenty of APL programmers are available for anyone who cares to
look.
* Modern, web-based solutions are available in most APLs.
Here's VisualAPL:
--------------------------------
> While VisualAPL incorporates most of the features of legacy APL implementations, the VisualAPL language extends legacy APL to be .Net-compliant. VisualAPL is hosted in the standard Microsoft Visual Studio IDE and as such, invokes compilation in a manner identical to that of other .Net languages.
--------------------------------
At least the former is talking about applications and not
implementations. All vendors could reasonably categorise all others as
"standard" in contrast to their own enhancements. But to call all
others "legacy" is somewhat less than constructive.
Those writing this stuff are deliberately or inadvertently giving the
impression that APL is dead; that their competitors are providing a
now redundant product. Unfortunately they seem not to see that to
denigrate APL is unlikely to produce interest in their own products
but rather to lose present & potential customers to the APL market in
general, not excluding their own, and to perpetuate the myths about
APL's failings.
I have started an attempt to correct this by replacing the phrase
"legacy APL", particularly where it's used in this latter derogatory
context with the phrase "standard APL"; wherever I can, in wikis, for
example; and if I can't, at least to attempt to post a comment
challenging the presumption.
Phil
joe_blaze
since otherwise it might suggest that different viewpoints are not
welcome in the APL community.
Similarly the phrase '...started an attempt to correct...' might
erroneously suggest that there is an absolute authority vested in an
individual which can discern exactly what is 'standard' from 'non-
standard'.
As a point of general information, there are no non-'standard'
elements of VisualAPL. In fact, it satisfies all [relatively ancient]
ISO and ECMA standards available for the APL programming language.
This illustrates that the word 'standard' is not sufficient to
indicate the difference between various APL implementations.
The 'legacy' terminology in the context of VisualAPL is used to
indicate the heritage of prior APL implementations which have provided
the incentive for the development of VisualAPL as an alternative.
Negative connotations, if any, of the word 'legacy' are in the eyes of
a reader.
The invariant elements of APL make it possible for APL code I wrote on
an IBM mainframe in the late 1960s to be run in VisualAPL, APL+Win or
IBM APL2. Invariant elements of APL do not necessarily include the
character glyphs associated with APL operators, workspace storage
structure, memory organization, GUI-building tools and other
connection methods (quad-this and quad-that) to the world of
programming beyond APL. These are features of specific APL
implementations and there is nothing standard about them. Being non-
standard they should come and go with the fashions which affect
programming just like any human activity.
Implementations have inherent assumptions and legacy APL has had an
inherent assumption of APL-centric programming. Certainly legacy APL
implementations have been 'improved', but mainly from the point of
view of existing APL programmers.
Evidently legacy APL implementations provide few if any incentives for
a non-APL programmer to adopt APL, because they seem to be about
adding 'stuff' to APL, potentially creating bloated bloat-ware. Of
course, the mainstream programming world is not immune from this
tendency either. Virtually all such additions to APL represent
valuable resources expended to duplicate, in possibly diluted form,
mainstream programming technology already available with mimimal cost
to a programmer willing to do a bit of research and study beyond APL.
So why is VisualAPL not a legacy APL implementation? Naturally it is
based on a set of development assumptions too:
+ It identified, potentially controversially, the invariant elements
of APL and implemented those in a high-performance manner, e.g. with a
compiled APL option and that compiler is a mainstream, free compiler
from Microsoft the same as that used by C# and VB.Net. VisualAPL
concentrates on the deemed invariant and beneficial elements of APL
and directly makes available the commodity mainstream programming
tools, like those for GUI building.
+ It transparently inter-operates with its targent domain on the terms
of its target domain, i.e. Microsoft .Net. Other APL implemlentations
seem to be considering this development direction now.
+ VisualAPL includes an implementation which can be directly
incorporated into .Net C# code bringing all the benefits of APL array-
based features into a C# program without traditional APL operator
glyphs which are alien to mainstream programmers. This feature extends
APL beyond merely calling an APL program from another language.
+ It is fully-integrated with Visual Studio, so productive APL
programming can be done in an environment already familiar to millions
of .Net programmers.
+ It rejects APL-centric concepts by avoiding duplicative, diluted
coverings of programming technology already done better outside of the
APL programming world. VisualAPL is about less not more APL special
'features'.
+ It directly exposes the underlying programming environment, so that
when the underlying environment is enhanced, its immediately available
to a VisualAPL programmer. This also means that mainstream programming
'jargon' is used rather than APL-centric 'jargon' which has little or
no meaning outside of APL.
+ It provides most of the features of legacy APL, except those which
have malware potential, e.g. direct access to real memory. If desired
a VisualAPL programmer can use mainstream methods or the legacy APL
methods.
+ It packages APL source code in an open-source way, e.g. in Unicode
text files not proprietary and obscure-format workspace files mixing
functions, execution state and data.
To some, the above information will be deemed 'advertising', but it is
recommended instead to consider how successfully legacy APL
implementations have (not!) penetrated the ranks of programmers in the
last n-years. Adding more 'stuff' to APL is not the answer, instead
seamlessly interacting with the mainstream seems a better way. That
sometimes means modifying some of the non-invariant elements of legacy
APL, but doing so for a good purpose and to good effect.
The traditional areas of APL programming, e.g. that done by domain
experts such as engineers, actuaries and scientists, have been
significantly penetrated by mainstream programming tools like Excel.
This is certainly not due to any 'superiority' of this mainstream
programming tool itself, but to the ubiquitous nature of Excel and its
inherent accessibility by those who need to interact with the domain
experts. Making APL more accessible to the mainstream is what
VisualAPL attempts. A domain expert can develop the prototype in
VisualAPL, certify its results from a professional/expert point of
view and then compile it into a fully-managed .Net assembly for
immediate and transparent inclusion into the IT department's
mainstream solution. That mainstream solution probably utilized
commodity programming methods and personnel to implement the GUI and
the data store, rather than the valuable time and effort of the domain
expert using APL.
From a commercial point of view, it is essential to maintain and
improve legacy APL implementations, so that gradually, enhancements
can be applied to existing APL-based application systems of customers
in an orderly and economical way. For that reason APL2000 will
continue to maintain and enhance the APL+Win product. In 2003
VisualAPL was in the pre-natal stage, in 2005 it reached the infancy
stage, it will develop into adulthood over time and might become as
popular among APL programmers as its illustrious parent, APL+Win.
Stan Clitherdawes
> [... deleted ...]
> Negative connotations, if any, of the word 'legacy' are in the eyes of
> a reader.
> [... deleted ...]
There has long been a derogatory implication associated with the word
"legacy" in the whole IT business - as such it seems sensible to keep as
much distance between it and "APL" when we're trying to send positive
messages.
I think Phil's thrust is broadly correct. Readers are not always as
sophisticated as we might hope.
Stephen Taylor, editor@vector.org.uk
I should have liked to have received a legacy from someone; I should
like to leave a legacy to the future.
But, irrational as it might be, Stan is right: among programmers
'legacy' has negative connotations.
Richard Nabavi
Blaze has posted that long advert, I think it is reasonable to put the
other side of the case.
1) VisualAPL throws away what is to my mind the most important and
distinctive feature of APL, namely the workspace/interactive session
concept and the associated session (and, in modern implementations,
integrated development environment). I realise that there is a sort-
of session available, but essentially the VisualAPL model is 'compile-
and-run', like all the other Visual Studio languages.
2) Because it doesn't have its own development environment, but relies
on Microsoft's proprietary Visual Studio (which is certainly not to
everyone's taste), you lose the fantastic interactive experience of a
modern APL. For example, in APLX (and I think Dyalog), you can just
click on a variable and bring up a graph of the data in two clicks.
That sort of feature - superb for exploring data sets and for 'APL as
a tool of thought', and closely integrated with the APL way of doing
things - is lost in the VisualAPL approach of relying on someone
else's development platform.
3) VisualAPL effectively requires programming in a C# style. That
makes for a rather messy hybrid - if you want that, why not just
program in C# in the first place? You can always add some array-
handling classes to get most of the benefit of VisualAPL from pure
C#.
Now, there may be pros and cons in this approach, but it's certainly
not the case that throwing away the 'legacy' is an automatic win.
A lot depends, I think, on why you would want to use APL in the first
place. To my mind, superb interactivity, ease of data exploration,
and making it very easy to test sub-sets of a program, are the most
important factors.
Richard Nabavi
MicroAPL
AAsk
only be possible in interactive mode APL: Are you suggesting that APL
should only be used in interactive/calculator mode?
2. "closely integrated with the APL way of doing things - is lost in
the VisualAPL approach of relying on someone else's development
platform." Whichever way you look at it, APL (no APL) does not exist
in a vacuum that is independent of its platform. Why is it any less
acceptable to use a standard, widely used IDE like VS2008 and
perfectly acceptable to use a retro-fitted customised language syntax
to access Windows GUI, files, etc?
3. "That makes for a rather messy hybrid - if you want that, why not
just program in C# in the first place?" Quite. This might just be what
people must be thinking about APL when faced with all its quad
functions, including []net, []sql, etc.
I think 'legacy' simply means that the very valuable investment in APL
applications is at risk of a serious erosion of return on investment
in the future.
It is the APL programmers who taking exception (are protecting a
vested interest) to this term. Organisations which pay for the
development have a completely different viewpoint. You need to see the
issues from the development sponsors' point of view rather than the
developers point of view. From this standpoint, the tags 'ahead of its
time', 'agile', 'direct', 'compliant' are just as meaningless as
'legacy' - had it not been so, APL will have made greater strides
forward: the net effect has no bearing on the assessment of return on
investment.
If you are disposed to think otherwise, perhaps you can ponder this
question "Why is it that APL in 2009, after all the improvements of
the last two decades (namely, 16 bit to 32 bit, GUI, API Support,
Networks, COM, DOT NET, WEB, etc. etc.) available in the workspace, is
still way behind in viability as seen in terms of its 1980's level of
visibility in the number of vacancies, big companies using it, etc."
Richard Nabavi
>
> If you are disposed to think otherwise, perhaps you can ponder this
> question "Why is it that APL in 2009, after all the improvements of
> the last two decades (namely, 16 bit to 32 bit, GUI, API Support,
> Networks, COM, DOT NET, WEB, etc. etc.) available in the workspace, is
> still way behind in viability as seen in terms of its 1980's level of
> visibility in the number of vacancies, big companies using it, etc."
Well, that is a big discussion.
But you can also turn it round the other way:
Why is it that new (or newish) languages like Python and Ruby are so
successful? They don't fit into the conventional compiled code model,
and they have their own class libraries (effectively language-specific
interfaces to databases, GUIs etc, and in that sense very like quad-
functions). That hasn't stopped them being extremely successful - and
part of the reason, I would submit, is precisely because they have
some of the APL-like features of immediacy/interactivity.
Richard Nabavi
MicroAPL
AAsk
therefore, I am inclined to agree that they are "extremely
successful".
So, what accounts for the difference:
1. Marketing, perhaps? Vendors have included just about everything
possible improvement in the language - users have probably avoided all
of it until it begins to make some financial difference to them.
2. Or is it APL's reluctance to abide by the industry standards: for
example, (a trivial example) it has to be pointed out/explained that
File | Load means the same thing as File | Open and until it is
pointed out, a user's accummulated experience to date (with every
other Windows application) is completely denied.
3. APL's unequalled (unchallenged) strength is its interactive mode; I
fully agree. It is just a coincidence that the popularity of APL began
to decline at about the same time (the introduction of nested arrays)
as APL vendors started to become different?
Nothing wrong with being different - the inside of ORACLE or SQL
SERVER databases could not be more different but they have SQL in
common and allow open access from other applications - but with APL,
the difference has created a proprietary 'black box' for every APL
application - both data and code. You cannot read a component file or
workspace using any application except the APL that created it.
APL is but one tool in the toolbox; whether it is the sharpest or not
is not as relevant as whether it abides by the standards of the day,
which includes an assessment of its viability in terms of both costs
and future returns.
Richard Nabavi
> So, what accounts for the difference:
>
> 1. Marketing, perhaps? Vendors have included just about everything
> possible improvement in the language - users have probably avoided all
> of it until it begins to make some financial difference to them.
No, there was little or no marketing or Ruby or Python initially.
They were however open source/free, but then so are zillions of other
languages and products which have had little impact.
>
> 2. Or is it APL's reluctance to abide by the industry standards: for
> example, (a trivial example) it has to be pointed out/explained that
> File | Load means the same thing as File | Open and until it is
> pointed out, a user's accummulated experience to date (with every
> other Windows application) is completely denied.
I know what you mean, but the example's not a good one (APLX at least
uses the standard terminology). In general, abiding by the host
platform's conventions is (or should be) a key design objective.
>
> 3. APL's unequalled (unchallenged) strength is its interactive mode; I
> fully agree. It is just a coincidence that the popularity of APL began
> to decline at about the same time (the introduction of nested arrays)
> as APL vendors started to become different?
I tend to agree. The APL world wasted a decade arguing about
relatively unimportant language differences, when there were far more
important things to worry about.
>
> Nothing wrong with being different - the inside of ORACLE or SQL
> SERVER databases could not be more different but they have SQL in
> common and allow open access from other applications - but with APL,
> the difference has created a proprietary 'black box' for every APL
> application - both data and code. You cannot read a component file or
> workspace using any application except the APL that created it.
I'm not sure that's very important. You can't read an Oracle database
without installing Oracle. You can't access a Word 2003 document
without either installing Word, or software from someone who has gone
to the trouble of reverse-engineering the file layout. On the other
hand, you can write all your APL data in databases or native files if
you want to, and it's easy to export data.
And let's not be too negative - the component files themselves may not
be binary-compatible, but the syntax for accessing component files is
the same in most APLs.
>
> APL is but one tool in the toolbox; whether it is the sharpest or not
> is not as relevant as whether it abides by the standards of the day,
> which includes an assessment of its viability in terms of both costs
> and future returns.
True, which is why we and the other vendors put so much effort into
ensuring that the so-called 'legacy' APLs can interface with other
technologies; for example, APLX can interface seamlessly to SQL
databases, COM, shared libraries (32-bit and 64-bit simultaneously in
APLX64), .Net classes, Java classes, Ruby, R, TCP/IP sockets, HTTP,
XML, SVG graphics, etc, etc, and indeed do this cross-platform with
little or no code change.
Richard Nabavi
MicroAPL Ltd
kai
> * Critical applications that nobody understands?
I used to work for many years for major banks. Traders used to use
applications their, some of some written in APL and some are written
in other lanuages, without much understanding, if any. I wonder how
SmartArrays can promise a solution to this.
> * Unable to find developers to maintain or enhance them?
> * Need to put the functionality into modern web-based solutions?
Ahh, now we know! It's marketing crap!
> While VisualAPL incorporates most of the features of legacy APL implementations, the VisualAPL language extends legacy APL to be .Net-compliant. VisualAPL is hosted in the standard Microsoft Visual Studio IDE and as such, invokes compilation in a manner identical to that of other .Net languages.
Standard MS Visual Studio? Sorry? This is not a standard at all. Ask
any Java/Eclispe programmer what they have to say about this, let
alone the Mac and Linux and Mainfraime guys.
To use the word standard here is simply rubbish I'm afraid.
Kai
AAsk
from someone who has gone to the trouble of reverse-engineering the
With a fresh install of Windows and just APL+Win or APLX, it is
possible to create, read, and write proprietary format files such as
XLS and MDB. This is not true of APL component files or workspaces.
Equally, if your credentials are valid, you can access ORACLE
databases from the same machine without installing ORACLE or the
ORACLE provided drivers, providers, or native clients.
I know, first-hand, that APLX, as APL+Win, can access other
technologies seamlessly and this is particularly valuable for a cross
platform interpreter such as APLX. APL is much more viable with this
(seamless access) ability. 100% of a small number (the APL market) is
still a small number and 1% of a very large number (the 'mainstream'
market) is likely to be much bigger: that is the potential reward
somewhere in the future of APL.
The word legacy keeps coming up: a legacy application is one that its
users still find useful in carrying out their function but one which
an organisation finds too expensive to maintain or enhance. Neither
maintenance nor enhancements are completely internal decisions - these
are driven by legislation and technology changes. Organisations will
replace such applications: Visual Basic 6.0, with a huge developer and
application base, is almost not heard of today.
More to the point, the application belongs to the organisation and not
the developer(s); it can be re-written (possibly better) in another
language or afresh in the same APL by another developer.
If I had a crystal ball, I would not need to ask this question: I am
sure that other vendors have a manage code version of their
interpreter in their technology plans: I wonder, what IDE will such a
product have? I believe Visual APL got it right in using Visual Studio
2008.
Richard Nabavi
> If I had a crystal ball, I would not need to ask this question: I am
> sure that other vendors have a manage code version of their
> interpreter in their technology plans: I wonder, what IDE will such a
> product have? I believe Visual APL got it right in using Visual Studio
> 2008.
We have no current plans to do this, but it would technically be
straightforward to use C# to write an APL which looked almost exactly
like APLX (or indeed Dyalog or APL+Win) - i.e. an APL interpreter and
development environment running entirely as managed code. It wouldn't
have to be a compiler producing compiled managed code.
In other words, the choice of managed versus unmanaged code is
completely separate from the question of the IDE. It is also
completely separate from the question of interpreted versus compiled
code.
Richard Nabavi
MicroAPL Ltd
AAsk
with the approach of writing a bespoke IDE for a managed code APLX.
Purely from the point of view of producing managed code assemblies; in
my experience, the immediate mode of APLX or APL+Win 'as is' is quite
adequate for that purpose: requires some understanding of the Dot Net
SDK.
There are more Visual Studio for .NET users than any other IDE in the
world (some 12 million plus users) and this IDE is not just a code
editor - it accomplishes a thousand things in the background like
source code management, create setup assemblies, registry & GAC
chores, documentation from in line comments etc and it is programmable
in its own right.
However, as you say, it is one option for ,anged/compiled code as all
the costs of its enhancements are borne externally i.e by Microsoft.
Kerry Liles
news:4b9e41e3-ac76-421f...@t2g2000yqn.googlegroups.com...
Kai
Well, Bill Clinton was perhaps the most famous person (at least recently) to
rely on the definition of a word, but his case notwithstanding, I think
considering MS Visual Studio a "standard" ought to be taken as the casual
use of the word "standard".
Perhaps there are better choices - even without resorting to a thesaurus -
to convey what can only be considered as "market share". Many of us are old
enough to remember IBM as a "standard" despite the fact that there were many
competent mainframe vendors even during those times...
joe_blaze
> 1) VisualAPL throws away what is to my mind the most important and
> distinctive feature of APL, namely the workspace/interactive session
> concept and the associated session (and, in modern implementations,
> integrated development environment). I realise that there is a sort-
> of session available, but essentially the VisualAPL model is 'compile-
> and-run', like all the other Visual Studio languages.
>
> 2) Because it doesn't have its own development environment, but relies
> on Microsoft's proprietary Visual Studio (which is certainly not to
> everyone's taste), you lose the fantastic interactive experience of a
> modern APL. For example, in APLX (and I think Dyalog), you can just
> click on a variable and bring up a graph of the data in two clicks.
> That sort of feature - superb for exploring data sets and for 'APL as
> a tool of thought', and closely integrated with the APL way of doing
> things - is lost in the VisualAPL approach of relying on someone
> else's development platform.
>
> 3) VisualAPL effectively requires programming in a C# style. That
> makes for a rather messy hybrid - if you want that, why not just
> program in C# in the first place? You can always add some array-
> handling classes to get most of the benefit of VisualAPL from pure
> C#.
Richard, unfortunately your statements are in serious error and do not
reflect the facts about VisualAPL
VisualAPL provides five (5) development environments, one of which is
the Visual Studio write/build/run scenario familiar and desired by
millions of .Net programmers.
VisualAPL also provides a fully interactive environment whereby
traditional APL (or for those with a taste for it, C#) can be entered
by the programmer to receive immediately feedback and if desired
visual results. There is no 'write/build/run' workflow to this option.
It is just like legacy APL, because we also believe that this
interactive feature is one of the great things about APL which should
remain invariant in all implementations. Viewing arrays, scalars,
results of calculations can be done by expliciting displaying them as
a result of a statement, merely hovering over the object name will
also display their properties and right clicking the variable gives
even more properties of the object. This mode we call the Cielo
Explorer, mainly to avoid the negative connotations that .Net
programmers have for legacy APL, because as you may know disdain works
both ways. The Cielo Explorer is unique to VisualAPL and provides a
programmers with a powerful tool to do APL programming as well as
explore the .Net universe.
VisualAPL does not require programming in C# style, though that is an
option which many deem desirable, especially in the Cielo Explorer
interactive session.
For the facts about VisualAPL please review: http://forum.apl2000.com/viewtopic.php?t=518
MichaelHughes
>
> - Show quoted text -
Rather than leave this discussion to the vendors I thought I would
weigh in with an independent "customers" point of view. I am an
independent APL consultant of more years experience than I'd care to
admit too.
I have happily used APL+Win since version 1.0 and am now on version
8.3 with some clients of mine.
I helped with the beta testing of the original version of Visual APL
so have some experience.
I have also used Dyalog APL with other clients
Unfortunately I have not had the pleasure of using APLX but hope to in
the future :-)
Consultants don't normally get to choose which APL they use with a
client, as this choice is usualy made before they arrive. They only
get to choose one for personal use. However I am currently involved
in a choice now so I thought I'd share some of our decision making
with you. Something I wouldn't normally share but I couldn't let some
things in this thread pass without comment.
There are many reasons for choosing the APL you use. However, the
greatest still tends to be habit, human nature still likes what it is
familiar with. When massive change comes along this has to be
questioned of course but as a general rule the current supplier
usually has the advantage.
In my experience, clients want the new things like .Net, Object
Orientation and good interoperability with the rest of IT but the
savvi ones also remember why they choose APL in the first place. They
want to maintain this advantage that APL gave them in the first
place. This is why they choose APL over languages like C#.
The only reason they strayed off the mainstream is this advantage but
they still like stability and cooperation.
There is no advantage in being just like the others, as the "big boys"
like C#, will always win. We need that extra advantage.
I have been very impressed that most vendors seem to be working
together to promote APL as a language. I accept there are differences
and that this is just healthy competition but this infighting is NOT
healthy and gives the wrong impression. I was really pleased recently
to see the cooperation between several vendors on []xml for example.
As to choice, my clients are weighing up the options they have.
They are considering the new features all the interpreters are
offering
They are considering how the vendors seem to be moving their
interpreters forward
They are considering the support given to them while they make this
descision.
Although work hasn't started on the new project yet I believe they
have decided not to move to Visual APL from APL+Win because;
the leap is just too great.
APL2000 seem to be out on a limb by themselves.
Evolution seems to be a better option than a complete change.
APL "thinking" seems to have taken a back seat
The apparent isolationist view of APL2000 has also contributed to this
view.
The current thread is reinforcing this.
Also from a personal point of view, I am also in the process of
converting my personal APL+Win code to another vendor. This was a
major and difficult decision for me but I believe that APL2000 have
left a brilliant product high and dry and are giving their clients
nowhere to jump to that the clients believe they can reach in one
jump.
ALL of my clients view "legacy" as bad and IT departments leap on this
terminology, leading to political battles with powerful people who do
not understand the advantage of APL. This increases the risk that the
system will be rewritten in something other than APL whether Visual
APL or a competitor's APL. This then reduces the pool of APL systems
- which is bad for everyone who values APL - please refrain from using
it.
paulgrosvenor
Michael and Phil.
We are are a consulting company who just so happen to use APL, often
combined with many other tools. When marketing or selling to our
customers we never use the terms 'legacy', 'old code', or
'traditional' etc. thay are all associated with poor understanding
from the listener and misunderstood messages.
We sell 'solutions' simple as that. The fact that we might do it
faster, better, neater, is not a very good diferrentiator because
every supplier (goods or services) says the same. Most of our clients
wouldn't know a piece of C# from VB or APL for that matter - and they
probably don't care. Thay can all use Excel, Word and Powerpoint
however.
Of course we need protection and a helping hand from our suppliers as
we navigate through an ever changing IT world but it must be derived
from a robust and functionally rich product. Well done to all the
vendors for bringing new ideas and tools to the table for us to use -
long may it continue but please don't think that that our (Optima's)
customers have any real interest at all. Our customers want to know we
can solve the problem, deliver it on time (often no time) and within
the budget available (sadly, often no budget either).
I suspect readers of this had exactly the same challenges 30 years
ago.
So, please keep innovating but please do not provide 'legacy'
solutions.
Phil Last
In sum, and giving you the benefit of the doubt regarding intentions,
Joe, can I ask you to bear in mind what has been said about other
peoples' understanding of words rather than their author's meaning,
something I probably need to do myself, and try to use either
"traditional", as you did above, or "standard", which, avoiding
derogation, tends to mean "not enhanced" in comparisonal contexts,
instead of "legacy" which does neither.
crishog
> Are you suggesting that APL should only be used in interactive/calculator mode?
No, but deliberately losing something which (and I quote you) "APL's
unequalled (unchallenged) strength is its interactive mode; I fully
agree." seems illogical.
> Whichever way you look at it, APL (no APL) does not exist in a vacuum that is independent of its platform.
Did you never use Sharp APL back in the days of time-sharing?
I too do no consider the word "legacy" to be free of symantic loading
- it has a very specific meaning to IT managers - an old system in
which no new investment is to made & which is to be replaced - to
suggest otherwise is disingenuous.
This also answers the question of why APL hasn't gained in popularity
despite the multitude of steps the vendors have taken - too many
people think of it as a "legacy" language & simply refuse to look at
new developments.
> It is just a coincidence that the popularity of APL began to decline at about the same time (the introduction of nested arrays)
> as APL vendors started to become different?
And VisualAPL wants to be very different from the other APLs.
Visual Studio is not an industry standard, it just happens to be
currently a popular development environment, with its own "source code
management, create setup assemblies, registry & GAC chores", but
surely your argument can't be that we should change from what you see
as a closed environment (because that's a bad thing) to another,
proprietary, closed environment.(because that's a good thing)?
Causeway developed an APL to C# converter ages ago - why not use APLs
"IDE" & distribute C# is that's what bothers you? Why neuter APL in
order to achieve some spurious idea of "standards"? Running with the
herd is not what has made Ruby so popular.
It is the Visual Studio / C# style which is being pushed in VisualAPL,
not the APL session - Frankly it annoys me. APL does not need a ";" to
terminate a statement, so why make the programmer add one? To match
C#? "A foolish consistency is the hobgoblin of little minds"
AAsk
better than anything else) APL mindset:
- the APL base has started to shrink since the 1980s and I don't see
any change in this trend, <externally> observable by the number of new
entrants, the number of educational faculties using APL, the number of
open vacancies for APL positions, the number of recruiters who have
heard of let alone know about the language, the number of APL courses
offerred by third party training estabishments etc etc
- the whole industry cannot be wrong in adopting, promoting, and
moving away from the cottage industry APL development style
Exactly what is is that makes this programming language that is so
much better than any other so unpopular outside the (dare I state,
ageing) circle of veteran programmers? In the minds of organisations,
their project managers, training providers, recruiters, ...
The answer cannot be that the rest of the world has 'little minds'
except in ...
AAsk
of conclusion.
I find crishogs's comment rather inciting and provocative, achieving
nothing in particular.
On my invitation to reflect on why APL (I too am one of those who
think it is better than most other languages) loses ground, you might
want to ponder this:
if APL is the preferred language of so called 'domain experts', why
does the language not have the endorsement of any professional body
although it is proven to be eminenty suitable for actuarial and
finance applications, to name but two.
My own answer is this: APL is not an end in itself (except for
hobbyist who see it as the colution to every problem) but a means to
an end; as it is a prrofessional programming language, it needs to
abide by the standards more widely adopted in the industry - there is
nothing to lose in doing so.
Phil Last
"I thought Phil Last's final post had brought the thread to some sort
of conclusion."
Because I used the phrase "In sum"? Let's call it a running total if
you like.
"I find crishogs's comment rather inciting and provocative,"
I applauded (silently) Chris' use of "disingenuous" which must be what
"incited" or "provoked" you to continue, though I decided against
using the word earlier, temporarily wanting to try a more placating
approach.
But Ajay, can I make another request?
Please stop asking us to ponder this and ponder that. I get enough of
that from the Hovey Joveys at my door.
kai
> nothing in particular.
Do you?
Going over the postings pro VisualAPL (there are only two
contributors) it seems to me that all these contributions are inciting
and provocative, achieving nothing in particular. And the both of you
are in trouble, because literally everybody else has taken a contrary
position, not only in this thread but in all threads we enjoyed
clashing with you and Joe over the last two weeks or so.
Jet all the contrary statements made no impact whatsoever.
Kai
AAsk
without reading what is said, all the other veiws are from 'dedicated'
or 'new' Dyalog users. Of course I would not dare suguest that this as
well as any material on the aplwiki is anything but sound. I would not
date sugguest "Ahh, now we know! It's marketing crap!"
The one exception (in terms of who uses what) is Richard and I firmly
believed that he had turned round the discussion by stating that
neither compiles APL not managed code APL needed Visual APL - to which
I agree. No one picked up on this - nothing to do with your pet apl?
Joe's original reference as "standard Microsoft Visual Studio IDE"
nothing about the IDE being standard - yet everyone picked up on
'standard' and debated yes/no even adding "rubbish". Does Microsoft
have any other IDE for any of its languages C#, C++, VB. J#, F#,
AP.NET (to name but a few)? No? So how is it NOT the "standard
Microsoft Visual Studio IDE". Visual APL just happens to share the
same IDE. Where is the point of contention? In the mind!
I could but I won't say anything about any of the APL's IDE's. That is
historical and, given what Richard said, it will change and for the
better in the future.
I took care to define what legacy implies (where its negative
connotations arise from): users find applications useful, critical to
theor daily ability to deliver their daily function but organisations
do not because those applications are deemed to be NOT cost
justifiable. Why was the positive connotation 'users find such
application useful' not seen as one point of leveraging APL into wider
acceprtance?
Hence, the organisations - the ones with the purse strings - term
applications that they see as cost unjustifiable as 'legacy'. It does
NOT applt to just APL applications. What happened? Instead of pausing
to think/workout how the visbility of APL applications can be
enhanced, this got tuened into a play on words, with Stephen wishing
someone would leave him a legacy as in inheritance.
On 'legacy', remember that anything of values always has one. APL was
very valuable until the 80's - it was the only thing that fulfilled
the promise that was visualised with personal computing. Everything
that APL did was in place and absulutely vital to the 'core' language
- including quad functions for accessing/managinf the filing system, a
quad function for everything as was said, its own GUI, no ODBC
databases, therefore component files made absolute sense. But APL.
like anything else, is subject to technology trends: if you have
doubt, pause and think what happened to Lotus-123.
The core language remains unequalled, the 2nd generation extensions
ie. APL2 compatibility is the GOLD STANDARD standard (well done APLX
outright, and APL+Win by default). This much is not negotiable in any
APL. The rest is. Why?
Everything else that is demanded by the industry or technology
innovation is retro-fitted to APL, including the APL syntax for
Windows GUI (all APLs). Why does APL have to do its own thing IN
RETROSPECT like []NET, its own memory management, its own threading
management etc. etc. The opportunity is there right at the outset -
take it!
Funny, I thought, NOT ONE opinion expressed had anything to say about
why the APL market has shrunk in terms of its visibility in the job
market, its profile in organisations, why no faculty (where domain
experts arise from) have prominently adopted APL, why no professional
body has endorsed APL as the desirable technology.
APL remains the language of choice. The mindset of its present
custodians? Well, make up your own minds.
The fight is not about the tiny, shrinking APL market: it is about the
APL share of the wider software development market. Not only can APL
can take it on but it can also win (vindicate its present reputation):
regretaby, I do not see this happenning with its present mindset: APL
needs to cease, gradually, to be a black box that shuts out everyone
except the APL programmer of the particular APL dialect.
If you prove me wrong- I will know that has happened when I begin to
see job vacancies being filled by the myriad recruitment agencies
instead of via patronage in the inner circle of APL- I will be
ecstatic.
joe_blaze
It is evidently wishful thinking on the part of some commentators on
this thread that APL2000 is abandoning APL+Win. Suggestions of this
nature border on the scurrilous.
Consider two commonly mentioned 'innovations' of other vendors
'traditional' APL products: []net and []xml.
In the Fall of 2008 all current APL+Win customers were provided the
NetAccess tools which made it easy for an APL+Win programmer to access
all of .Net 1.1, 2.0 and 3.5 from APL+Win. This was possible because
of the skillful programming of a premier APL programmer, Eric
Lescasse, and the pre-existing and robust external interfaces already
available in the APL+Win product. See the APL2000 announcement at:
http://www.apl2000.com/netaccess.php.
In 2004, 2005 and 2007 all current APL+Win customers were provided
with a comprehensive set of XML manipulation tools which treat XML
documents as APL array objects. This was possible because of the
excellent work of another premier APL programmer, Davin Church. See
the APL+Win forum area: http://forum.apl2000.com/viewtopic.php?t=43.
Both of these APL+Win enhancements did not require a new version of APL
+Win and they are compatible with version 5.x of APL+Win to the
current version 9.x. Both of these APL+Win enhancements were provided
to APL2000 customers in an open source way, rather than in a closed
quad-function format, so that APL+Win programmers could better
understand how they worked and extend them as desired.
The VisualAPL product is not a replacement for APL+Win, but an
alternative when an APL+Win programmer needs to delve more deeply
into .Net, wants a fully OOP/Unicode/mainstream environment and
certainly when it is necessary to produce fully-managed .Net code.
VisualAPL targets the Microsoft Windows operating system platform. The
mainstream programming environment for that platform is .Net and
Visual Studio. The fact that a program written in VisualAPL, C# or
VB.Net can also run in all the 'other' environments (http://
aplwiki.com/System/SupportedPlatforms) is a nice bonus. That bonus is
possible because the developers of the 'other' environments recognized
the benefits of .Net and provided .Net implementations for their own
operating system environments.
VisualAPL does not require a programmer to use any C# statement if
that is their desire and a semi-colon is not required after any
statement in VisualAPL, but is can be optionally used in a manner
analogous to the APL diamond statement separator.
It seems obvious that the phrase 'success breeds contempt' certainly
applies in the case of Microsoft's success and to a degree in the case
of the APL+Win product success.
The APL-centric view that the innovations of the wider programming
world don't exist or are not significant or should be disdainfully
duplicated in an APL-ish way has not worked to increase or even
stabilize the ranks of APL programmers. In the case of APL-ish
duplication of such innovations, serious resources have been
(needlessly) expended both in developing the (often diluted) APL
version of the mainstream innovation and in the efforts of the APL
programmer to learn proprietary APL syntax instead of mainstream
syntax.
MichaelHughes
As far as the APL market expanding or contracting I think that is an
interesting thread on its own.
APL has always been a niche market, it was in the 70's, 80's as well
as now in the 00's.
Problems come in all shapes and sizes, most shapes are fairly dull and
can easily be solved using mundane transactional processes. This has
always been the case and probably always will. This is a large market
both for suppliers of interpreters, compilers and off the shelp
software systems, as well as for recruiters. It will always be a
large market. APL has no place in it other than to talk and to
interact with it.
Alongside this are the interesting problems, which tend to attract
interesting people (not necessarily sane :-D ), but interesting.
These interesting problems are harder to solve. The reason I like APL
and why all my clients like APL is that it makes it easier to solve
these intereting problems. I actively search out people with
interesting problems.
With my clients I am one of their oldest programmers/developers. I am
currently training two new recruits from scratch with one customer and
will be acting as a type of mentor for another beginner. I have
already trained another APLer at another client.
Paul Grosvenor is right, the best use of APL is not just to use APL
per se, but in wanting to find the best solution to interesting
problems. APL will never be mainstream as it is interesting,
interesting problems are rarer in the world, therefore by definition
it wlll never be mainstream.
Several of my clients had been actively considering moving away from
APL as it was prerceived to be legacy and old fashioned but have
eventually chosen to return and develop in the language because they
realised the avantage it gave them. One has just received a
government grant because their work was perceived to be unique and
interesting.
One now has a modern Web like frontend running on their desktop, it is
identical to their website, even uses the same html code, but the menu
click events trigger APL code in a workspace rather than back to a web
server. This is all run in the APL workspace. This replaced a
standard APL GUI. Soon we will have all of the application using this
type of interface removing the need for the APL GUI. Putting power
where it is needed is where APL will grow. Not as an APL in sheep's
clothing, but as an APL honest enough to say we are better in this
area but we are also not too proud to work with others in areas where
they are better.
I find the references to "grey haired APLers' as derogatory as
"legacy". It doesnt matter your age, it is your outlook that
matters. Those of us who wish to keep the advantage going (and I'd
swap from APL if there was proven to be a better tool) - must train
and enthuse others whenever we get the chance.
So I add to my previous email - please refrain from using legacy but
ALSO refrain from using "grey haired programmers" - a grey haired
attiude can exist in a 21 year old just as easily as a bright excited
attitude can exist in a physically older person who just happens to
have grey hair.
Please can ALL the vendors work together constructively, promoting a
great way to solve problems that has allowed me to enjoy my entire
working life (so far :-D)
Morten Kromberg
> The fight is not about the tiny, shrinking APL market: it is about the
> APL share of the wider software development market. Not only can APL
> can take it on but it can also win (vindicate its present reputation):
> regretaby, I do not see this happenning with its present mindset: APL
> needs to cease, gradually, to be a black box that shuts out everyone
> except the APL programmer of the particular APL dialect.
First of all, modern APL systems are not the black boxes that you
describe, nor do all users have the mindset that you accuse us of.
Damaging the reputation of APL by insisting that they are is NOT
increasing your chances of getting a job writing APL.
I hear your pain, but I am also happy to report that the APL market
that I see is NOT shrinking. We (Dyalog) are one of the leading APL
vendors, we are experiencing solid growth, and signs are that this
will accelerate. Our customers are hiring and training new APLers.
There are more and more production .NET based applications based on
integration of APL with standard components (even using Visual Studio
to edit source code in some cases). But we also have large
applications running on platforms like AIX. Linux is growing too.
We are seeing a steady trickle of "new" users who had abandoned APL a
decade ago return to the fold - and with the new Tutorials that we are
about to publish (an 800 page book and an interactive Web Tutorial),
we are poised to really start marketing APL again.
I'm sorry if the market seems to bleak to you, perhaps you are
pursuing the wrong strategy?
> Funny, I thought, NOT ONE opinion expressed had anything to say about
> why the APL market has shrunk in terms of its visibility in the job
> market, its profile in organisations, why no faculty (where domain
> experts arise from) have prominently adopted APL, why no professional
> body has endorsed APL as the desirable technology.
I seem to remember we had a lengthy discussion about this, not long
ago. The fact that we're generally sticking to our opinions doesn't
mean we're not thinking hard... You can find a summary of my arguments
from that time at http://www.vector.org.uk/archive/v233/kromberg.htm.
It will take a little time, but hang in there: I firmly believe that
the real golden age of APL is ahead of us..
Morten
crishog
> I thought Phil Last's final post had brought the thread to some sort of conclusion.
Well, I replied from a digest before I read Phil's posting & I didn't
realise that one had to have permission to comment...
> I find crishogs's comment rather inciting and provocative, achieving nothing in particular.
Nor do I find the harping on about "Legacy APL" as being anything
other than "provocative" - and I'm not from another vendor.
> It is evidently wishful thinking on the part of some commentators on this thread that APL2000 is abandoning APL+Win. Suggestions of this nature border on the scurrilous.
But all you ever talk about is VisualAPL, the only demonstration at
the recent BAA conference was, in essence, all about VisualAPL. If we
have that impression, maybe it's because of what we read & hear.
> In the Fall of 2008 all current APL+Win customers were provided the NetAccess tools which made it easy for an APL+Win programmer to access all of .Net 1.1, 2.0 and 3.5 from APL+Win.
Well done (no sarcasm intended) - so why not publicize this aspect
rather than keep on banging on about an IDE?
> In 2004, 2005 and 2007 all current APL+Win customers were provided with a comprehensive set of XML manipulation tools which treat XML documents as APL array objects.
Again, news to me.
>
> Both of these APL+Win enhancements did not require a new version of APL+Win and they are compatible with version 5.x of APL+Win to the current version 9.x. Both of these APL+Win enhancements were providedto APL2000 customers in an open source way, rather than in a closed> quad-function format
The idea of bolt-ons which don't require a change to the interpreter
is a nice it - but does it mean that these are the same as auxiliary
processors? They sit outside APL. Is the choice of quad-function or
external calls more to do with style and performance than "open
source"? I assume the main effort was in translation to and fro form
APL arrays? If it was a simpler interface it could be done directly.
SO I guess it's linked to the APL+Win internal data representation &
is just as closed as a quad function? You could use it with APLX or
Dyalog?
That having been said, I'm not a great fans of "stuffing" APL
interpreters with quad functions of every little purpose.
> The APL-centric view
When using APL I certainly feel that I require an APL-centric view, or
else I'm going to end up writing inappropriate solutions. A problem
i've often encountered is programmers writing APL in the style of
fortran/cobol/assembler (fill in your favourite) rather than writing
in an APL style. All the inconveniences which worry you, but none of
the advantages.
But this year I've only worked on 2 full APL applications (one APL
+Win), so I can't quite be accused of being locked into an APL-only
world view, nor do I see it as the answer to every problem.
> an alternative when an APL+Win programmer needs to delve more deeply into .Net, wants a fully OOP/Unicode/mainstream environment
Mainstream? Ah, now possibly there's my problem. Outside APL most of
my work has been Linux & web based, so I don't see Visual Studio as
being "mainstream" at all. Why do I want to employ a Windows
originated environment when the system is deployed on Linux? As I said
I don't want to exchange one particular environment for another if I
loose benefits in doing so.
Is it just me or do some of these posts sound more like adverts than
discussion? Perhaps that's why Kai responded with "marketing crap".
> It seems obvious that the phrase 'success breeds contempt' certainly applies in the case of Microsoft's success and to a degree in the case of the APL+Win product success.
You know I always thought it meant those who were successful were
contemptuous of those around them...
If someone pokes me with a stick I'm liable to poke back, which is who
I see this thread.