Vector themed issue: How to wear sheepskin

"Jack" <jgrudd@comcast.net> wrote in message
news:ab270437-7088-4250-bac0-dab57599eeab@t1g2000pra.googlegroups.com...
On Aug 11, 3:45 pm, Ibeam2000 <Ibeam2...@gmail.com> wrote:
> With today's APLs, it is quite easy to write an application where APL
> is "on top", that is, the application itself is in APL, its GUI is in

[...]
> > So, who can make 'heroes happen'?
>
>> It is what a hero does that makes him or her a hero. They don't just
>> happen. This is just the silly Microsoft propaganda you see when you
>> fire up Visual Studio.

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

Jack, I thought I read from your DARPA paper that APL had officially
been announced as a spear-head environment?
Anyway, in my environment customers just saw a slick GUI application,
ready for use. They had no idea of all the additions, multiplications,
let alone cube roots or fractional exponents, &c &c.
They liked the results and took my magic for granted - the secret weapon
seems to remain APL ...

^/jk

PS: Another potentially politically correct way to build applications
is to use the functionality built into some (Firefox? Mozilla?)
internet browser. It's called XUL, evidently named after the thing
which was in the fridge in the film Ghostbusters.

A browser, however, is more like a full-blown APL interpreter with
integrated everything, network connectivity, session, language
(JavaScript, VB Script, etc.), garbage collection, memory management,
on-board nuclear reactor, celestial navigation, and so on. It's yet
another managed environment vying for limited resources on an
underpowered computer.

Then the question remains of how to call APL from JavaScript in a
civilised manner.

The browser is the ideal way to deliver applications to the user,
whether the internet is used or not. It would be nice, however, to
embed the language of your choice (in this case, probably J would be a
better choice than APL for obvious reasons) in the browser.

Interesting applications are certainly possible using the browser from
APL. My experience is with APL+Win. Microsoft have pushed HTA fairly
strongly of late. That is, all you need is NOTEPAD to build an HTA
application.

If you have a complicated application, you need to grab the DOM
(Document Object Model) from within APL or pass APL the DOM object. A
small JavaScript wrapper can pass all the intensive processing to
APL(+Win). To get an idea of what a DOM is, if you have Firefox, click
on Tools + DOM Inspector from the main menu while browsing any page on
the web.

On Aug 10, 3:38*pm, AAsk <AA2e...@lycos.co.uk> wrote:
> As is becoming clearer, this thread should have been titled 'APL/J:
> Multi-language programming'.
>
> The constraints of the discussion are:
>
> 1. Existing Applications (with our with legacy APL applications)
> 2. Future developments - including APL/J.

Morten is quite correct: the thread invites discussion of the
political and methodological aspects of 'wearing sheepskin' as much as
the technical issues.

Stephen Taylor
editor@vector.org.uk

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

Here's an article I found about the perils of .Net to COM interop...

http://www.developerdotstar.com/comm...e_excel_dotnet

I have personally experienced the following interop-related problems:

1. Excel fails, does not shut down, etc. when a .Net program is run
from within Excel.

2. When automating Excel with .Net, shutting down Excel appears to be
unpredictably slow. In my case, the network hadn't closed the file by
the time APL then .Net had invoked Excel a second time.

I believe that the problems stem from two or more managed environments
without any knowledge of what the other is doing with regards to
resources its partner consumes.

On APL 'wearing sheepskin':
If one is a supplier to a customer who desires a certain application
system, then identifying and satsifying the customer's needs is
paramount and that is the only option which will provide a sustainable
relationship between the customer and the supplier.

The above conjecture 'seems' reasonable.
If might be correct, but then what are the customer's 'needs'?

Being programmers, we might identify a customer's needs as the project
specifications, the deployment scenario, the profile of the intended
users, the time-line for delivery, the customer's budget, etc.

Certainly these 'technical' needs should be considered, but what about
the customer's psychological 'needs'.

APL is currently mostly a product - actually widely available, but not
widely used.
When does a programming language product, like APL [in any of its
implementations], become a solution?

Maybe, very occasionally I suspect, a customer has an aversion to APL.
More likely they have never seen APL used.
Often they are familiar with a more heavily advertized programming
language or one that more programmers are using, or that more
'experts' recommend.
No doubt there are anecdotes illustrating how some special requirement
prevents the use of APL, like a government agency mandate.

For APL to be psychologically acceptable as a programming language it
must be:
(a) More familiar to customers
(b) Taught to and Learned by more programmers
(c) Better advertised
(d) Available in component form which is suitable for a non-APL-
centric environment
(e) Less proprietary, less of a closed cult and more a welcoming,
desirable-to-join club that is open to other ideas and technologies
(f) More often identified as an element of successful application
systems
(g) Recommended more often by recognized 'experts' from beyond the
current APL 'distant planetoid'
(h) A commodity, readily available from a host of qualified, possibly-
credentialed practitioners
(i) Associated with success, wealth, 'progress' and other social
indicators

To achieve these goals, it seems that APL should never 'wear
sheepskin', instead it should wear neon, flashing 'APL successfully
used here'!

On advertising:
Microsoft's 'Heros happen here' campaign, in less than six months,
induced well over 50,000 programmers in the U.S. to attend a full day
Microsoft seminar on Visual Studio 2008 and SQL Server 2008. I'll take
that 'silly propaganda' any day, even though it is silly propaganda.

On programmer credentials:
Can the APL community establish the criteria for and perceived value
of an APL programmer competency credential? Can an established
educational entity be convinced to offer training towards this
credential? How about commercial entities such as Chubb Institute or
New Horizons Learning Centers? APL language vendors as a last resort?

On commodities:
Visual Studio and C# are fashionable, successful commodities. Why not
APL?

Joe Blaze

"(e) Less proprietary, less of a closed cult and more a welcoming,
desirable-to-join club that is open to other ideas and technologies"

I have no doubt whatsoever that if asked about APL, the present
advocates of the language will generally defend the case for APL in a
manner that conveys the language as "highly proprietary, a closed
circuit and, nonetheless, highly desirable to join". This sort of
message simply does not inspire credibility among non-apl people.

Rather than say APL can do .NET, the quest for APL expansion must be
show that .NET can do APL. That means less of workspaces, component
files etc and more of databases & incorporation of platform tools in
applications.

"Visual Studio and C# are fashionable, successful commodities." Indeed
so.

Therefore, there is a dual jeopardy: APL needs to unlearn the
proprietary ways of doing things (magical, quick or whatever they are)
and to learn industry standard ways of doing things (arduous, less
magical or whatever they are). No one thinks that learning an APL IDE
is a profitable long term asset but quite the reverse is true of
learning the VS IDE for .Net languages.

Put it another way: if you can convince a mere 1% of the bank of 15
million C# programmers in the world today, how many APL newcomers have
you just acquired?

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

Pardon me for jumping in on something unrelated,
but I can't let the opportunity pass by.

Mr Rudd, do you know where I could find some
APL code implementing a Kalman filter? (Either
one dimensional ideally, or two or more).

One of the papers you wrote is the ONLY one
I've found that contains some
well commented examples but
that was for a related but
different type of filter.

My background is mainly C/C++ though I left
the field professionally several years ago.

A search of ACM and IEEE had some suggestive
titles but nothing with explicit code
as well detailed, commented and explained
as was done in your paper, published in the early
1990's if I recall.

One of the ongoing problems with APL
which turned me away form it, was the lack
of a large body of easily obtainable
code, even uncommented, on things such as this
which are available in droves for other languages.
It's probably sitting in the core of some
mainframe in some rustheap somewhere

Thanks and again apologies for the diversion.

J.

So the advice is

- let's get rid of any special ways APL is using (component files,
dynamic (agile) approach, whatsoever...)
- let's integrate APL into Visual Studio
- ....

Let us introduce strong type checking as well. Let's remove the APL
characters. Let's compile APL. Let's be slow instead of fast. Let's
remove any magic that might still be left. Rename the product. Pretend
not to be APL. Choire: "We are all different!" Single voice: "I am
not!"

>Therefore, there is a dual jeopardy: APL needs to unlearn the proprietary ways of doing things (magical, quick or whatever they are) and to learn industry standard ways of ....

Very well. That leaves one single question:

Why should one APL then?

>Put it another way: if you can convince a mere 1% of the bank of 15 million C# programmers in the world today, how many APL newcomers have you just acquired?

I wonder why people still believe that it is possible to attract
ordinary IT guys to APL. I am absolutely certain that this is NOT
possible.
And there is no need to do this to be successful. Look at Ruby: these
guys ARE successfull although they do not integrate into Bill's way to
do IT in the slightest.

"Why should one APL then?"

This question

- a. could be coming from someone who does not know APL & is addressed
to someone who does.
- b. could be a rhetorical question asked by someone who knows APL and
does not want to contemplate how he/she will cope with changes well
outside his/her sphere of influence.

Take scenario a:

As the conversation gathers momentum, it moves to other questions like
"Where is the code?" "Where is the data stored?" "How does the
keyboard work, again?" ALL of the answers to these and similar
questions leave the interested party with a single impression 'There
is nothing "STANDARD" about this language; it is a closed-book." and
inevitably with a single conclusion "Why should I complicate my life
learning this APL: I've managed without it so far and so has the rest
of the world!".

Take scenario b:

Inevitably, the one thing that is outside the control of typical APL
people is the financial sponsorship for projects. APL (or anything
else) do not have any intrinsic meaning or worth: they are only as
useful as the extent to which they meet the needs of the sponsors.

Claims about how fast APL is, that it is a RAD, cheaper etc may be
crystal clear in the APL person's head but the sponsor sees anything
but these facets when confronted with answers such as "Well the code
is held in a bespoke format file, a workspace." or, "APL stores it
data in things called component files and nothing except APL can get
to it." No, you cannot use Visual Studio or anything else to look at
either the code or the data.

My answers to your question:

Use APL because, like all other tools, APL is very good (much better)
at some things and is just as good as competing tools at {most} other
things when it adopts the industry standard approach to problem
resolution {no need to re-invent the wheel, just because it is
possible or because you can do it better}.

BETTER:
Example 1: there is no environment that gives the options for
interactive mode runtime investigations that APL does.
Example 2: solution exploration is much more straightforward with APL
because there is absolutely no need to be wary of any machine
requirements.

JUST AS GOOD: APL can use databases as well as any other development
tool.

APL should comply.

My question:

"Do you use APL simply because it is non-compliant in almost every
respect with the industry's approach to the provision of IT
solutions?"

Bill has nothing to do with the plight of APL, however you end up
assessing it.