Re: Vector themed issue: How to wear sheepskin

"> I strongly recommend our competitors to steal these ideas (Don't
worry, we've got plenty of other good ideas, so we don't mind.)"

Richard, any chance of a glimpse of what you are planning! I'd like to
see a means of JIT compilation of C# code (.NET Dlls) edited in the
APLX editor or held in a file and edited by, say, Notepad or Notepad+
+. In fact with unicode support, can the APLX system menu enable the
configuraton of an external editor like Notepad++?

"Agreed (and Thanks!). Whether or not these need to be System
Functions is an interesting discussion, of course."

I think []functions is the correct approach, especially for APLX which
is platform independent. On the downside, there is the possibility of
locking users into using dated technology like ODBC ([]sql) but I
suspect that MicroAPL can easily enhance []sql to support native
clients in a future version.

"We have limited resources and can easily become bottlenecks if
everyone waits for us to build everything."

Morten, this is a sound observation: does it not also lend support to
the argument for users to be a little more forward thinking in their
use of today's empowered APL. As you put it, this makes vendors play
catch up with technology trends whilst at the same time other
languages are striding forward at great pace.

Morten,

You wrote:

> After an uncomfortable pause while the community recoved from the loss of
> the mainframe,

I think our customers would be surprised to hear that the mainframe had been
lost. Where did it go? And when? It was up and running just fine last
time I checked.

BTW Here's a little story that I like to use to when people ask me about the
demise of mainframes. (It works best in North America where passenger
trains are not as common as in Europe.)

In the 19th century, if you wanted to travel further than your neighbor's,
you took a train. Everyone knew about trains. They were a part of everyday
life.

In the early twentieth century, Henry Ford started building the Model T and
people quickly started used cars for personal transportation. As the
century progressed, cars became more and more ubiquitous and except in big
cities with commuter rail lines, trains became a curiosity that were seldom
used for personal transportation.

But the fact is, trains still carry the majority of the over land freight.
The railroad industry is huge. But, trains aren't used for personal
transportation and so people aren't as aware of their contributions as they
used to be.

People now have personal computers and they're what most people are familiar
with, but that doesn't mean that mainframes aren't still out there running a
huge proportion of the businesses around the world. Try doing your banking,
or buying a plane ticket, or getting a weather report, or buying a car
(produced in a factory), or any of a thousand other every day things without
a mainframe. They're ubiquitous; it's just that their effect is so
ingrained in our lives, and they so realiable, that people simply don't know
that they're there.

David Liebtag
IBM APL Products and Services

On Aug 19, 11:24*pm, "David Liebtag" <DavidLieb...@vermontel.net>
wrote:
> Morten,
>
> You wrote:
> > After an uncomfortable pause while the community recoved from the loss of
> > the mainframe,
>
> I think our customers would be surprised to hear that the mainframe had been
> lost. *Where did it go? *And when? *It was up and running just finelast
> time I checked.
>
> BTW Here's a little story that I like to use to when people ask me about the
> demise of mainframes. *(It works best in North America where passenger
> trains are not as common as in Europe.)
>
> In the 19th century, if you wanted to travel further than your neighbor's,
> you took a train. *Everyone knew about trains. *They were a part of everyday
> life.
>
> In the early twentieth century, Henry Ford started building the Model T and
> people quickly started used cars for personal transportation. *As the
> century progressed, cars became more and more ubiquitous and except in big
> cities with commuter rail lines, trains became a curiosity that were seldom
> used for personal transportation.
>
> But the fact is, trains still carry the majority of the over land freight..
> The railroad industry is huge. *But, trains aren't used for personal
> transportation and so people aren't as aware of their contributions as they
> used to be.
>
> People now have personal computers and they're what most people are familiar
> with, but that doesn't mean that mainframes aren't still out there running a
> huge proportion of the businesses around the world. *Try doing your banking,
> or buying a plane ticket, or getting a weather report, or buying a car
> (produced in a factory), or any of a thousand other every day things without
> a mainframe. *They're ubiquitous; it's just that their effect is so
> ingrained in our lives, and they so realiable, that people simply don't know
> that they're there.
>
> David Liebtag
> IBM APL Products and Services

It would be interesting to know if APL on mainframe has grown in real
numbers over the years.
It would also be interesting to know how big a percentage of APL is on
mainframes.

It is a very interesting fact that PC operating systems are still
fighting to solve problems the mainframes solved decades ago.

Comparing trains, flights and cars is a very good analogy.

Consider how accidents are treated.

If you do have an incident in flights or trains it is investigated and
the results are talked about openly round the world.
The cause of the incident is reported and if there is a lesson to be
had from it then future constructions are permanently changed.

In cars the situation is very different and hardly anyone takes notice
when there are deadly problems every day.
Improvements are very slow and more or less incidental.

Regarding trains in Europe then the systems around trains have changed
a lot.
There used to be several persons serving each station.
Then over the years controlling the stations more or less has been
concentrated to a few centers and the stations are controled from a
distance.

The high prices of petrol has changed how the people use transport and
the use of trains has increased again and the cars become smaller.

The tax on petrol in Europe for a long time has speeded up the
process.
I am pretty sure it will happen all over.

I am sure that the reliability of the mainframe will eventually make
it to the PCs.

On 19 Aug, 20:33, AAsk <AA2e...@lycos.co.uk> wrote:
>
> Richard, any chance of a glimpse of what you are planning! I'd like to
> see a means of JIT compilation of C# code (.NET Dlls) edited in the
> APLX editor or held in a file and edited by, say, Notepad or Notepad+
> +. In fact with unicode support, can the APLX system menu enable the
> configuraton of an external editor like Notepad++?
>

The C# compilation idea is an interesting one, although I think you
can fairly easily already do this, by using ⎕HOST to invoke
Microsoft's command-line C# compiler (available free of charge, I
believe).

As for using an external editor, is there any big advantage over
running the external editor as a separate program?


> "Agreed (and Thanks!). Whether or not these need to be System
> Functions is an interesting discussion, of course."
>
> I think []functions is the correct approach, especially for APLX which
> is platform independent. On the downside, there is the possibility of
> locking users into using dated technology like ODBC ([]sql) but I
> suspect that MicroAPL can easily enhance []sql to support native
> clients in a future version.
>
> "We have limited resources and can easily become bottlenecks if
> everyone waits for us to build everything."
>

Morten is certainly right - the APL vendors cannot hope to provide
everything as system functions or build every possible feature into
the interpreter. That was a real problem in the past, for example in
our Mac version of APL.68000 in the 1990s. For that reason, providing
general interfaces (specifically to .Net and Java, and also ⎕NA) is
absolutely essential, since it means that the APL programmer has
access to all, or nearly all, of the libraries and operating-system
features which programmers in other languages have. However, using
such facilities is harder and more verbose than using system
functions, and often involves understanding a lot of documentation
which is written with the C# or Java programmer in mind. Not everyone
wants to do that. So providing easy-to-use, platform-neutral system
functions for common operations makes very good sense. You have the
best of both worlds - it's easy to do easy things, and possible to do
the harder things if you need to.

The correct analogy is something like Excel. You CAN interface
to .Net from Excel, and sometimes you may need to. But most of the
common things the typical Excel user needs are built-in. So it should
be with APL.

As for ⎕SQL specifically, it's not tied to ODBC; without changing the
syntax, we can extend it to other technologies 'under the hood' in the
future, thus preserving the APL programmer's investment in APL code.

Richard Nabavi
MicroAPL Ltd

>>> APL.68000 in the 1990s <<<

Now that was a nice product !
Especially the AP interface , as writing 68000 assembler was almost as
nice as using APL ! We used many APs in the days of 30 MHz processors,
with speed ups of normally between 10 to 100 times faster for
"specific case" APs.
( No criticism of APL68k here, simply writing assembler for specific
cases is obviously going to cut out the generality overhead that APL
enjoys )

In my years of using APL to make a living, with one actuarial
exception, every system I maintained or wrote, in that order, was to
be phased out in the forseeable (3-5 year) future. This was
especially true with timesharing, meaning a shorter replacement
horizon. Mainframe APL systems which were part of a larger overall
system often had the best staying power (in the days of Telenet, APL
programs were used to collect and validate input data, which was then
consolidated and batch printed by Cobol programs, for instance)

This was mixed-language programming - although no Cobol program called
an APL function or vice versa, these were batch jobs with JCL - APL
steps followed by Cobol steps.

On the other end of the scale, there were mainframe APL programs
written as temporary solutions (not necessarily "prototype") while
armies of Cobol developers were cranking out the real product.

From a management perspective, although I distinctly remember a call
from one or another data centre manager who was appalled at the very
existence of an APL application on "his" mainframe and his revulsion
at the very thought that it was going to be maintained instead of, um,
buried, APL applications (and their maintainer) came to be respected
once it was clear that they were trouble free, serving their purpose,
and worth the investment.

Thus back then, management acceptance criteria seemed to be:
1. The application works (and does not call attention to itself)
2. Is serving a niche (expensive to replace)
3. Is not expensive (and does not call attention to itself)

Mixed-language programming represented some respect for corporate
initiatives to use standard technology, while leaving the difficult
bits to the tool(s) that could do the job.

Generally this should not be any different today.

However, the thing which seems to scare corporate types boatless is
the notion of having a single point of failure. The notion of having
a very small development team, and the fact that it is economical to
operate, does not sit well with types who equate a small team to a
huge institutional risk. And in non-entrepreneurial situations, with
a large company, this forms the perfect excuse (reason) to use such
ball-and-chain-for-the-brain technologies as Java. Money is not the
issue. It is peace of mind. (Never mind that the application is a
piece of crap)

Gosi wrote:
>
> <snip>
>
> It is a very interesting fact that PC operating systems are still
> fighting to solve problems the mainframes solved decades ago.

and those solutions were taught to generations of computer science
students, so why did that knowledge never get applied, until it had been
rediscovered?

possibly because the design of PC operating systems was handed over to
cosmologists?

> Comparing trains, flights and cars is a very good analogy.
>
> Consider how accidents are treated.
>
> If you do have an incident in flights or trains it is investigated and
> the results are talked about openly round the world.
> The cause of the incident is reported and if there is a lesson to be
> had from it then future constructions are permanently changed.
>
> In cars the situation is very different and hardly anyone takes notice
> when there are deadly problems every day.
> Improvements are very slow and more or less incidental.

in keeping with your analogy, it is worth observing that, with cars, the
owner/driver decides what risk level is acceptable -- not so, with
trains and planes

this is often put forward as an explanation for the fact that seat-belts
and airbags have made no measurable difference to accident statistics
-- drivers accept the same level of risk to themselves, drive faster,
and sod the rest of the population

there again, accident statistics are not wholly reliable -- when I was
working on these numbers, a road death in the UK was one occurring
within 3 months of an accident, as a result of injuries sustained in
that accident -- in France, the period was 6 months -- in parts of
the EU, the police had a responsibility to reduce road deaths, and their
first action at the scene of an accident was to move (!!) the dying from
the road to the grass verge, so they became grass verge deaths, rather
than road deaths

but how that relates to PCs vs. mainframes, I have no idea

/phil

As for []SQL, I think this implementation fits the spirit of APL,
maybe early APL, which is to encapsulate solutions to make them very
usable, especially to beginners. IBM APL2's AP127 wasn't that bad,
reinventing the same thing with DAO then ADO and now ADO.Net is not a
bad learning experience. But there's nothing better than to be
released from the mindless tedium of low-level programming, especially
when it can be easily avoided.

[]SQL puts all that database functionality in easy reach. Especially
for a beginner.

I admire a lot of the older APs, like GDDM, for presenting the problem
of communicating to a substantial API much, much easier.

I would imagine "mainframes" relates to a well-organised organisation
operating some kind of transportation activity (railroad, airline) -
these activites need dispachers, air traffic controllers, and a fairly
massive support staff to keep running responsibly. I had a CMS
mainframe at my disposal for a number of years and doing ad-hoc
installations of products usually didn't work. As a user, I didn't
usually have the power to wreck anything substantial.

I would imagine "PC" relates to a more casual usage of cars - drivers
have varying degress of skill, knowledge of their vehicle, knowledge
of traffic law, content of alcohol in their blood, all which makes for
a lot of variability in their driving. Usage of cars is comparatively
unregulated.

The question is whether we want to take this analogy just further, or
too far.

Particularily in the US, the car culture has transformed newer living
places to a place where cars, but not people, live. Building codes,
land use, zoning, and so on are designed for gatherings of cars.
Public transportation is nearly extinct. It is slowly becoming
understood that the suburban sprawl lifestyle is not maintainable.

Have PCs done the same for computing? Microsoft?

On Aug 21, 10:55*am, Ibeam2000 <Ibeam2...@gmail.com> wrote:
> I would imagine "mainframes" relates to a well-organised organisation
> operating some kind of transportation activity (railroad, airline) -
> these activites need dispachers, air traffic controllers, and a fairly
> massive support staff to keep running responsibly. *I had a CMS
> mainframe at my disposal for a number of years and doing ad-hoc
> installations of products usually didn't work. *As a user, I didn't
> usually have the power to wreck anything substantial.
>
> I would imagine "PC" relates to a more casual usage of cars - drivers
> have varying degress of skill, knowledge of their vehicle, knowledge
> of traffic law, content of alcohol in their blood, all which makes for
> a lot of variability in their driving. *Usage of cars is comparatively
> unregulated.
>
> The question is whether we want to take this analogy just further, or
> too far.
>
> Particularily in the US, the car culture has transformed newer living
> places to a place where cars, but not people, live. *Building codes,
> land use, zoning, and so on are designed for gatherings of cars.
> Public transportation is nearly extinct. *It is slowly becoming
> understood that the suburban sprawl lifestyle is not maintainable.
>
> Have PCs done the same for computing? *Microsoft?

Before the PCs came along the APL users were a bit uncontrolable users
of the mainframe cycles.
Most non-APL jobs were sent in to the computer for a batch processing.
Each line of code did not do very much.

A casual APL user could type in one line and send the computer into a
limbo.
The technical department had no control over such users and later time
hate of APL can be offspring of such situations.

The PCs liberated the users from the controls of the mainframe people.
Somehow APL was not quick enough to pick up on that trend.

I guess it may be slowly adjusting.

So is there a difference between APL on the mainframe and APL on the
PC?

The web has done a lot to gather the PC users so they can easily
communicate with each other.

Do we have a good enough APL for the web?

I think we were late in the PC market and we seem to be somewhat
lacking in the web market.

I would love to see APL webservices, APL pc - mainframe - web
integration.
All the ingredients are available.

The last remaining item needed to communicate was Unicode.
It is more or less working for most APLs I believe.

What is missing?