Re: Vector themed issue: How to wear sheepskin

"Gosi" <gosinn@gmail.com> wrote in message
news:84bb8318-38cb-483d-a3a9-df6882dced0a@k13g2000hse.googlegroups.com...
On Aug 21, 10:55 am, Ibeam2000 <Ibeam2...@gmail.com> wrote:

[...]
> So is there a difference between APL on the mainframe and APL on the
> PC?
[...]
> What is missing?

Yeah, what's missing. What's missing is the awareness of what APL
actually is. APL has nothing to do with IT (except IT needs to deliver
the sources & the services). APL == algorithms.
The PC provided the liberation from the mainframe to the APL-er.
APL, what is it? APL == a notation that runs on a computer. Let's not
forget. I now see again all those QUAD-suggestions. Why? (They don't
understand quite!).
(Ok, I had a spring chicken tonight, drowned in the red wine - but
nevertheless, I mean it).

> 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.

Most of the sites where I worked had rather overloaded mainframes,
usually TSO. Overloaded simply means that the management didn't think
it was important enough to get the most performant model for the
situation or upgrade accordingly. (All sites had current hardware,
some just didn't opt budget more memory, disk, or the next higher
model when they should) In one case management responded by
systematic (and very successful) attacks on well-known widely used
programs which consumed excess resources - this had the positive
effect of deferring purchase of a new mainframe model while keeping
performance within limits.

In those days, the IT department (owner/operators of the mainframe)
did not hate APL, they hated all interactive users.

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

The very first relevant microcomputer was the MCM computer, which came
out around 1969 (?). It featured APL. The first hobbyist
microcomputer appeared in February 1975. It was the 8008 Altair
computer, and the plans and board layout appeared in Popular
Electronics magazine. An industry quickly sprung up and there were
stores (at least in the US) everywhere. Problem was, computers then
were rather underpowered for any real business applications, 4K
memory, etc. There were a few APLs which sprang up before 1980, but
you could not migrate any decent sized application.

The hobbyist PC market collapsed around 1979, possibly because
computers were still pretty much toys. The IBM PC, much more oriented
to business, came out in 1982 and the hardware was still a bit on the
small size to migrate some larger applications. However, with STSC's
APL*Plus/PC, you could already get started with smaller things. It
was not until the 386 that you could start taking applications off the
mainframe.

APL was ported to some very small machines, but only until the 386 was
large scale migration practical to do. This came 15 years after the
first microcomputers came on the market. From the early 1980s on,
there were some candidate UNIX machines which could provide some small
scale timesharing, but these were not inexpensive.

The point of all this: APL was always constrained by the hardware.
Until the right hardware came along, APL was not effective.

> 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?

The short answer is yes. But maybe the question really is whether the
web is good enough for APL.

The web, as we know it today, was designed initially to deliver large
volumes of data, huge compared to timesharing days, to browser users -
mostly static data, pictures and html documents, to be formatted
locally into a pleasing display. I may be wrong or hopelessly behind,
but most web servers do not deliver significant computation. The
thing which makes the browser pleasant to use is that your results are
sent to you almost instantaneously. The internet has more to do with
nearly free communications than with computation.

Considering the widespread use of low-performance languages like Java,
there is no real reason APL could not be used in its place. However,
being in widespread use has its advantages - much of the code to do
all of the interesting stuff, like compose html, handle sockets,
databases, and so on, has been written, so all you have to do is glue
the stuff together. At least that's what the rest of the industry
thinks.

Many things are out there for free. Bulletin board software.
Databases, The daily grind. APL makes more sense when there is some
real competitive advantage, generally difficult calculations which
change or grow or are incomplete.

> 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.

Unicode wasn't necessary, it just made communication less unpleasant.
Communicating with the mainframe also required numbers which varied in
one or another detail (big endian, floats, etc.)

> What is missing?

Someone like Google to have an enormously successful (but difficult to
implement) application, and to generate publicity regarding the non-
standard technology used to make it happen.

Often, the entire world has the wrong opinion about something (Man
can't fly, the world is flat, etc.) and needs to be shown otherwise.

On Aug 23, 1:20 pm, Ibeam2000 <Ibeam2...@gmail.com> wrote:
> ...
> The very first relevant microcomputer was the MCM computer, which came
> out around 1969 (?). It featured APL.
....
The MCM/70 actually came out a little later.

from http://www.cse.yorku.ca/museum/collections/MCM/MCM.htm
here's a summary, probably written by Zbigniew Stachniak:

"The MCM/70 computer, designed by a Canadian company Micro Computer
Machines Inc. (MCM) in the period between 1972 and 73, is the earliest
example of a microcomputer manufactured specifically for personal use.
MCM was among the first companies to fully recognize, articulate, and
act upon the immense potential of microprocessor technology for the
development of a new generation of cost effective computing systems. "

On Aug 21, 9:18 pm, Gosi <gos...@gmail.com> wrote:
> ...
> Before the PCs came along the APL users were a bit uncontrolable users
> of the mainframe cycles.
> ...
> The PCs liberated the users from the controls of the mainframe people.

Gosi,
Do you remember VSPC? It stood for something like "virtual systems
PERSONAL computing" in days not long before IBM announced the PC. It
included APL. Curtis

On Aug 24, 7:22*pm, "Curtis A. Jones" <curtis_jo...@ieee.org> wrote:
> On Aug 21, 9:18 pm, Gosi <gos...@gmail.com> wrote:
>
> > ...
> > Before the PCs came along the APL users were a bit uncontrolable users
> > of the mainframe cycles.
> > ...
> > The PCs liberated the users from the controls of the mainframe people.
>
> Gosi,
> Do you remember VSPC? *It stood for something like "virtual systems
> PERSONAL computing" in days not long before IBM announced the PC. *It
> included APL. *Curtis

I-Perhaps I’m out of order here. I may be going off in another
direction, but I feel it is important to be said. This is quite a
discussion in how to merger APL into the rest of the computing world.
I’d like to back up a bit and ask where are the APL knowledgeable folk
upon whom you wish to put a sheepskin? If you don’t have APL
knowledgeable people coming along, I won’t worry much about
integrating APL into anything. Who is training the next generation of
APL knowledgeable people? I would like to elaborate more on this
point. First, by “APL knowledgeable” I mean more than someone who has
heard of it and has gone to Wikipedia to read about it. Rather I mean
those who have interacted with it, understand the array orientation of
it, explored the rich set of functions and operators, and done some
problem solving with it.
In order to make my point I need to call your attention to an essay
entitled “Calculemus!” by Brian Hayes in the most recent issue of the
American Scientist volume 96 n0. 5 Sept.-Oct 2008. He makes a very
interesting distinction in programming and the use of computers that I
believe relates to APL. He splits programming into software
development and inquisitive Programming. In Software development the
end product is a program or package to be used by others. That is
what most of the “sheepskin” discussion has been all about. However,
in inquisitive programming the product is achieving a personal result
from running a program. As Hayes defines it, inquisitive programming
is basically personal problem solving. Here you don’t build
monolithic programs, but rather you interact with the program language
incrementally and interactively. His dream is to have an environment
where “programming is for everyone” with a programming language for
the masses, a programming language more suitable for inquiry than for
software development. It strikes me that people coming into the
programming activity should first start out in an inquisitive mode.
Today too much early programming training goes into talking about
details more related to system development than into inquisitive
programming. Yet, I believe that there will always be many more
people on a personal basis interested in problem solving than in
system development. Yes, I know many of you will say we cannot get a
good return on our investment on personal use of APL. But where do
you get your base?
The part of Hayes’ essay that I found especially interesting is his
wish list to create a good inquisitive environment. He wants a
programming language more suited to inquiry than development. Rather
than paraphrase him I will quote him directly.
“….”programming for everyone” (is) based on the conviction that
getting answers out of a computer should be seen as an essential skill
in a technological society. But the standard apparatus of software
development is far from ideal for teaching or learning this kind of
programming. … Here’s my wish-list for a programming environment:
It should be self-contained, easily installed (and uninstalled), well-
documented, internally consistent, bug-free and foolproof. ….I don’t
want just to write programs; I want to have a dialogue with the
computer. I need to know the answer to one question before I can
decide what to ask next. Thus the typical unit of interaction should
be a single statement or expression. This kind of incremental
computing can’t work if a language requires a lot of scaffolding –
header files, a ‘main’ procedure – just to run a fragment of code.
I should be able to think in terms of the problem at hand, not the
innards of the machine. I don’t want to worry about the encoding of
characters or whether binary numbers come big end or last end first.
I want to be insulated from annoyances such as allocating and
reclaiming memory. Data-type declarations should be optional. I want
a system that’s mathematically well behaved. ….I want a rich selection
of ready-made functions and data structures. I shouldn’t have to build
list or trees or queues out of lower-level constructs such as
pointers. ……. I want a thriving community of enthusiasts, who
contribute to the system, share code and knowledge, and keep us all
feeling young. For this to happen, the software needs to be free, or
close to it.”
Well that is the gist of his wish-list. It seems to me that the APL
language fits rather well. He is aware of APL but he dismisses it as
a niche language that is having a hard time keeping up with changes in
technology and attracting investment. He feels a smarter bet is
Python. He also mentions a project called Sage out of the University
of Washington. Now If any of you wish to contact him his e-mail id
is brian@bit-player.org. Also his full article may be on his Weblog,
http://bit-player.org. Perhaps, after reading his article the APL
community might update him a bit.
Let me return to the issue of initial APL training. Most of the needs
for merging APL into the software development environment really is in
what I refer to as the APL system which surrounds the core APL
programming language. I suspect that it is impossible to get APL into
a standard curriculum anywhere. Only the latest “hot” or is it “cool”
language is promoted. Perhaps there are other ways. Has anyone taken
on a young person in a one-to-one situation? Has anyone interacted
with local school computer clubs? Dyalog is promoting a student
contest for their next conference. That’s great! In my recent APL
class I was able to have an extra young college bound student too. I
will be interested to see if having this extra tool will help him in
his technical college work. Has anyone done something similar? I
would be interested to hear of your successes or failures. Perhaps we
need to open a new blog on promoting APL.
I have taught and worked with APL for many years. Yet, even today I
continue to find a certain excitement in interacting with APL. If
only we can show that excitement to others, then we can have bodies
over which to throw sheepskins. Ray Polivka

On Aug 23, 3:20*pm, Ibeam2000 <Ibeam2...@gmail.com> wrote:
...
>
> Most of the sites where I worked had rather overloaded mainframes,
> usually TSO. *Overloaded simply means that the management didn't think
> it was important enough to get the most performant model for the
> situation or upgrade accordingly. *(All sites had current hardware,
> some just didn't opt budget more memory, disk, or the next higher
> model when they should) *In one case management responded by
> systematic (and very successful) attacks on well-known widely used
> programs which consumed excess resources - this had the positive
> effect of deferring purchase of a new mainframe model while keeping
> performance within limits.
>
> In those days, the IT department (owner/operators of the mainframe)
> did not hate APL, they hated all interactive users.
>

I totally agree with IBEAM's assesment. I found most traditional IT
types feared APL programmers and painted them (us) as witch doctors.
I think Ibeam is referring to the 60-70's, but I found this to be the
case at our shop until about 1990.

Bonjour je possède encore un MCM700 mon premier calculateur portable
en APL a votre avis ce genre de relique peut il de nos jours
présenter un intérêt bien sur il est en France Normandie.
J'ai utilisé MCM800 le luxe a l'époque avec des disquettes 8 pouces
Pourquoi j'en suis venu à l'APL ? C'est suite a une conférence de
Motorola sur le (8080 je crois) ou ce langage a été évoqué suite a
quoi une connaissance universitaire de Jussieu ma indiquer que ce
langage me permettais d'être autonome je me suis investi dans le
langage le matériel provenant de la société SOFREMI a Puteaux.
Bonne semaine a tous papy

Hello I have a MCM700 my first portable computer in your opinion APL
has this kind of relic it can nowadays be of interest of course it
is in France Normandy.
I used MCM800 luxury al'époque with 8-inch floppies
Why I came to the PLA? It is continuation of a conference on the
Motorola (8080 I believe) or what language was raised following a
quoi knowledge my Jussieu university indicate that this language
permettais me to be autonomous I invested in language materials from
society SOFREMI a Puteaux.
Good week all papy
"Curtis A. Jones" <curtis_jones@ieee.org> a écrit dans le message
de news:
098a118e-ced5-4538-8a08-31c9b6b53ce7...oglegroups.com...
On Aug 23, 1:20 pm, Ibeam2000 <Ibeam2...@gmail.com> wrote:
> ...
> The very first relevant microcomputer was the MCM computer,
which came
> out around 1969 (?). It featured APL.
...
The MCM/70 actually came out a little later.

from http://www.cse.yorku.ca/museum/collections/MCM/MCM.htm
here's a summary, probably written by Zbigniew Stachniak:

"The MCM/70 computer, designed by a Canadian company Micro
Computer
Machines Inc. (MCM) in the period between 1972 and 73, is the
earliest
example of a microcomputer manufactured specifically for personal
use.
MCM was among the first companies to fully recognize, articulate,
and
act upon the immense potential of microprocessor technology for
the
development of a new generation of cost effective computing
systems. "

On Aug 20, 1:24*am, "David Liebtag" <DavidLieb...@vermontel.net>
wrote:

> 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.

David,

I apologize - you made this point at least once before, and while I
did intend to reply, I never got round to it. You are right that the
mainframe is FAR from dead. However, while your points are all valid,
I would still claim that the large market for mainframe-based
timesharing which fuelled most of the APL development in the past, and
the lucrative consultancy business which went with helping people do
"personal computing" on the very expensive hardware which supported
most of the APL businesses in the 70's and 80's, IS all but dead.

There are numerous exceptions, but in general the mainframes of today
are indeed used to run the kind of systems that you mention:
Production applications that have extreme reliability requirements and
change (relatively) little from day to day. The less they change, the
more they are likely to stay on the platform where they are already
running very reliably, and the less likely APL is to be involved (the
benefits of APL are most obvious when you frequently need to adapt the
software to new situations).

APL can definitely be a valuable tool for some of these systems, but
few APL vendors other than IBM are able to sell APL into this market
right now (we don't have the added motivation of selling the
hardware). Most of the people who want to develop really new APL
applications have moved off the mainframe onto "workstations".

The interesting and growing market that we now see for workstation APL
systems is in many respects the same one we had a long time ago on the
mainframe. Today, workstations provide the individual user with far
more memory and more CPU power for personal use than he or she can
easily get on a mainframe. The market for new, dynamic applications
where businesses gain significant competitive advantage by involving
domain experts directly in rapidly prototyping solutions currently
seems to inhabit Windows and Unix or Linux systems. Our most rapidly
growing customers are those who use our product to build software
packages which they sell to run on the desktops of large corporations
all over the world.

Mainframes may perform back-end services for these systems, but the
systems generally need to make use of rich user interfaces which are
still only available on desktops, and also need to make use of the
cheap processing power of the desktop systems.

Writing so-called thin client applications is still a bit too hard.
For the average APL user, it is still a LOT too hard. And whether
"inside the browser" or "on the server" is the right place to crunch
gigabytes of data is a VERY interesting question. I read recently that
one of the latest buzzwords in the OLAP business is something they
call "in memory OLAP", which means extracting data into something like
a workspace and doing analysis on a powerful workstation. What an
idea! :-)

(Aside: Isn't it funny that the browser you need to run a "thin
client" is an order of magnitude bigger than the APL system required
to run the so-called fat client - Internet Explorer is current using
147Mb of memory to render a page of HTML on my machine.)

At the same time, "Intel-based" systems are also getting better at
competing with "mainframes" for a variety of applications (one might
even say they are "becoming mainframes"). And of course, the re-re-re-
invention of the Virtual Machine will probably blur the distinction so
much that we will all lose track of it in the near future. People will
soon use mainframes to run VMs running peoples desktops. Then we may
be a bit closer to having reliable transportation again ;-)

I'm not sure how to express this using the trains vs cars analogy, but
I don't THINK we'll be seeing railway tracks to everyones back yard
any time soon, and I think trains would be a lot less useful if we
did. I did read that engineers have ideas about having cars link up on
the highway to save lots of fuel - is this similar to using VM on a
mainframe to run desktop applications?

Morten

Morten,

You and a couple of other folks have hinted this week at what I think gave
APL a bad reputation in the early days:

APL was providing personal computing long before anyone ever heard of a PC.
Just like people do today with spreadsheets, APL was letting non-programmers
sling around data and test out ideas. This was great for the end users but
hell for the IT staff. Without any notice, a casual user could suddenly
bring any size machine to its knees. For some reason, the IT guys didn't
like that. :-)

And when you write Morten that this kind of APL use on mainframes is
virtually dead, I agree, and good riddance. That is no longer a reasonable
way to use big hardware.

But lots of the other stuff is still happening regularly on mainframes.
Including apps that change regularly and tools used by domain experts. The
difference today is that experiments and development usually happen on
workstations and only finished components get deployed to the mainframe.

David Liebtag
IBM APL Products and Services



"Morten Kromberg" <mkrom@dyalog.com> wrote in message
news:3f630ad8-27e9-4a31-9077-0b0c9ffb24b7@f63g2000hsf.googlegroups.com...
On Aug 20, 1:24 am, "David Liebtag" <DavidLieb...@vermontel.net>
wrote:

> 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.

David,

I apologize - you made this point at least once before, and while I
did intend to reply, I never got round to it. You are right that the
mainframe is FAR from dead. However, while your points are all valid,
I would still claim that the large market for mainframe-based
timesharing which fuelled most of the APL development in the past, and
the lucrative consultancy business which went with helping people do
"personal computing" on the very expensive hardware which supported
most of the APL businesses in the 70's and 80's, IS all but dead.

There are numerous exceptions, but in general the mainframes of today
are indeed used to run the kind of systems that you mention:
Production applications that have extreme reliability requirements and
change (relatively) little from day to day. The less they change, the
more they are likely to stay on the platform where they are already
running very reliably, and the less likely APL is to be involved (the
benefits of APL are most obvious when you frequently need to adapt the
software to new situations).

APL can definitely be a valuable tool for some of these systems, but
few APL vendors other than IBM are able to sell APL into this market
right now (we don't have the added motivation of selling the
hardware). Most of the people who want to develop really new APL
applications have moved off the mainframe onto "workstations".

The interesting and growing market that we now see for workstation APL
systems is in many respects the same one we had a long time ago on the
mainframe. Today, workstations provide the individual user with far
more memory and more CPU power for personal use than he or she can
easily get on a mainframe. The market for new, dynamic applications
where businesses gain significant competitive advantage by involving
domain experts directly in rapidly prototyping solutions currently
seems to inhabit Windows and Unix or Linux systems. Our most rapidly
growing customers are those who use our product to build software
packages which they sell to run on the desktops of large corporations
all over the world.

Mainframes may perform back-end services for these systems, but the
systems generally need to make use of rich user interfaces which are
still only available on desktops, and also need to make use of the
cheap processing power of the desktop systems.

Writing so-called thin client applications is still a bit too hard.
For the average APL user, it is still a LOT too hard. And whether
"inside the browser" or "on the server" is the right place to crunch
gigabytes of data is a VERY interesting question. I read recently that
one of the latest buzzwords in the OLAP business is something they
call "in memory OLAP", which means extracting data into something like
a workspace and doing analysis on a powerful workstation. What an
idea! :-)

(Aside: Isn't it funny that the browser you need to run a "thin
client" is an order of magnitude bigger than the APL system required
to run the so-called fat client - Internet Explorer is current using
147Mb of memory to render a page of HTML on my machine.)

At the same time, "Intel-based" systems are also getting better at
competing with "mainframes" for a variety of applications (one might
even say they are "becoming mainframes"). And of course, the re-re-re-
invention of the Virtual Machine will probably blur the distinction so
much that we will all lose track of it in the near future. People will
soon use mainframes to run VMs running peoples desktops. Then we may
be a bit closer to having reliable transportation again ;-)

I'm not sure how to express this using the trains vs cars analogy, but
I don't THINK we'll be seeing railway tracks to everyones back yard
any time soon, and I think trains would be a lot less useful if we
did. I did read that engineers have ideas about having cars link up on
the highway to save lots of fuel - is this similar to using VM on a
mainframe to run desktop applications?

Morten

>There are plenty of APL users who work on components that become part of
>proprietary systems which will never be marketed. They typically like APL's
>productivity and ability to express complicated algorithms and want
>increased performance and connectivity, but are not terribly interested in
>tools for building shrink wrapped retail products.

Certainly true and a credit to APL and APL programmers for making this
possible.

Politically and economically within such an organization it may be
beneficial to have the domain experts using APL consider themselves as
vendors and their users as customers. There may not be a license
agreement or a formal installation tool, but users are customers and
programmers are vendors of their output.

Sometimes an internally-developed technical application can be
enhanced with a GUI so that its use can be delegated to less expensive
technicians for production work, so that the expensive technicians can
enhance the program or work on other more pressing problems.

Sometimes an APL function is used to prototype a solution to a
corporate need and when it is deemed perfected to whatever degree is
acceptable, it is given to 'professional' IT people to incorporate
into a widely-used application system using mainstream programming
tools.

In these situations, rather than translate the APL code to some other
language, in the current APL environment it is now possible to package
the APL into a component which can be directly used by the
'professional' IT area. The degree to which this APL packaged
component interoperates with the target 'production' environment
varies. The options include ActiveX interfaces, WebService interfaces,
Unix/Linux APL, mainframe APL, unmanaged Win32 code in a .Net cover or
even a .Net version of APL.

Rather than talking up the (supposed) superiority of APL, IMHO its
better to talk up the talent of the APL programmers and get more APL
components integrated into mainstream application systems, whether in
sheep's clothing or not.