Vector themed issue: How to wear sheepskin

On Aug 14, 10:59 am, "Stephen Taylor <edi...@vector.org.uk>"
<StephenTaylorF...@googlemail.com> wrote:
>
> On a related note, our project nearly died when a crucial interface to
> an internal mainframe took six months to appear instead of the
> scheduled six weeks, a delay no one in IT or management thought
> remarkable. (We had estimated three weeks as the longest we could
> imagine, then doubled it. The programmer who coded it confirmed later
> it had been less than a week's work.)

I do not understand why the project nearly died and why it took six
months if it only took one week to do.

As it appears here either the person coding it did not start until
after nearly six months an then did id in a week or finished it early
and did not deliver it until six months leater,

No reason to kill off a project it should rather have been used as a
good example of good programming but not specially good planning and
delivering

On Aug 15, 1:47 am, APL Enthusiast <a...@swbell.net> wrote:
> Some of the digression topics reminded me about the summer I worked at
> IBM internally while in College.
>
> I spent a couple of weeks learning about the implementation of APL
> installed and most of the Summer trying to figure out what these folks
> needed in a specific business application.
>
> And then I spent about two weeks building a tracking application in APL
> for someone else.
>
> In retrospect: In discussion, one needs to separate how much time is
> spent on coding vs. the business side of application development and
> waiting around for other systems.
>
> (That place was weird anyway. They pulled me aside near the end of the
> Summer and told me this was not typical IBM and not to hold it against
> them when considering a job.

IBM seems to have a strange relationship to APL.
A lot of good people inside IBM use it.
IBM has a good implementation of APL.
They used to sell APL actively.

There also seem to be a lot of people say like you say that it is not
typical IBM.

IBM used to have similar relationship with VM.
IBM used it and many people favored VM.
Regrettably APL did not get as well integrated with REXX as it should
have been.
REXX and APL2 would be a really good combination.
If IBM would actively combine REXX and APL2 as well as market it
actively with VM I am sure it would be very favorable to the whole APL
community.

I guess APL2 REXX and VM is much bigger than .net and far better even
in current condition.


----------------
Björn Helgason
http://groups.google.com/group/J-Programming

IBM used to be a big user of APL.
An IBM friend of mine ( actually the chief system programmer) in ca.
1970 was telling me about how they used APL to manage their mainframe
assembler code whilst designing OS 2.2 (mainframe ). They built a sort
of intelligent macroassembler using APL.
I read an IBM internal paper in the late '70s which was put together
by the IBM APL lobby. They were effectively complaining why top
management doesn't market APL to their customers ! They gave countless
examples of how much time many projects had saved by using APL rather
than std development practices of the time.

FWIW




> IBM seems to have a strange relationship to APL.
> A lot of good people inside IBM use it.
> IBM has a good implementation of APL.
> They used to sell APL actively.
>
> There also seem to be a lot of people say like you say that it is not
> typical IBM.
>
> IBM used to have similar relationship with VM.
> IBM used it and many people favored VM.
> Regrettably APL did not get as well integrated with REXX as it should
> have been.
> REXX and APL2 would be a really good combination.
> If IBM would actively combine REXX and APL2 as well as market it
> actively with VM I am sure it would be very favorable to the whole APL
> community.
>
> I guess APL2 REXX and VM is much bigger than .net and far better even
> in current condition.
>
> ----------------
> Björn Helgasonhttp://groups.google.com/group/J-Programming

On Aug 16, 10:37 am, aleph0 <apl68...@tiscali.co.uk> wrote:
> IBM used to be a big user of APL.
> An IBM friend of mine ( actually the chief system programmer) in ca.
> 1970 was telling me about how they used APL to manage their mainframe
> assembler code whilst designing OS 2.2 (mainframe ). They built a sort
> of intelligent macroassembler using APL.
> I read an IBM internal paper in the late '70s which was put together
> by the IBM APL lobby. They were effectively complaining why top
> management doesn't market APL to their customers !

Similar reasons as why they did not effectively sell VM to their
customers.
They kept it for themselves for internal use mostly.

IBM was such a big company with so many good products and a lot of
politics.
Any other company with only VM REXX and APL2 would have actively
promoted it.

VM was not promoted because of MVS
Only a handful of people had developed VM
Same as with APL2 and REXX

Literally thousands of manyears behind MVS and it sold for a lot more
money than VM.
Often all development internally done in VM and then thrown over to
MVS to be sold.

When the PC came out the profit for 1 million PCs did not make up for
the profit they made on a single machine running MVS.

They obviously still use VM REXX and APL2 internally and they are
highly regarded products by the users.

Unfortunately they still consider it cannibalisation to sell that
combination to the customers actively because there are more
profitable alternatives.

For a long time it was difficult to get AIX if the customer was hooked
on AS400.
Similar politics there.

My internal knowledge is obviously dated but the external signs are
still ther for everyone to see.
One of the biggest is their lack of external commitments to promote
APL2

As they used to say "we want to sell many products for a high margin
each. We are not in the fingers and toes business. Selling low margin
products or a handful of something is just not our business."

> They gave countless
> examples of how much time many projects had saved by using APL rather
> than std development practices of the time.
>

So for internal use that is quite ok.
Selling it to customers actively is just not mainstream.

> FWIW
>
> > IBM seems to have a strange relationship to APL.
> > A lot of good people inside IBM use it.
> > IBM has a good implementation of APL.
> > They used to sell APL actively.
>
> > There also seem to be a lot of people say like you say that it is not
> > typical IBM.
>
> > IBM used to have similar relationship with VM.
> > IBM used it and many people favored VM.
> > Regrettably APL did not get as well integrated with REXX as it should
> > have been.
> > REXX and APL2 would be a really good combination.
> > If IBM would actively combine REXX and APL2 as well as market it
> > actively with VM I am sure it would be very favorable to the whole APL
> > community.
>
> > I guess APL2 REXX and VM is much bigger than .net and far better even
> > in current condition.
>
> > ----------------
> > Björn Helgasonhttp://groups.google.com/group/J-Programming

I was looking up new info on Rexx

http://en.wikipedia.org/wiki/REXX

Saw an example of using Rexx and decided to see how I would do the
same in J
It is actually pretty similar


http://groups.google.com/group/J-Pro...09a39f7605bf15

On Aug 12, 12:21*am, "jk" <aq...@planet.nl (remove the q's)> wrote:
> "Jack" <jgr...@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
In 1990 DARPA was trying to establish a standard prototyping language
for DoD. IBM proposed APL2 for this purpose. We didn't win, but
then DARPA's initiative didn't go anywhere. In retrospect I think
it's a bad idea to mandate a language, or a methodology.

On Aug 16, 3:57*am, Gosi <gos...@gmail.com> wrote:
> On Aug 12, 4:30 am, Jack <jgr...@comcast.net> wrote:
>
>
>
> > 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.
>
> How and why would they blame APL?
>
> I guess that was the attitude some decades ago but it is hardly
> relevant today.
>
> > 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++.
>
> So you are not giving them any chance of judging any APL and as far as
> your message goes you do use APl but you will not let anyone know how
> you came up with your solution.
>
> I think it is time to drop the old idea that APL is just for certain
> people and some people are dead against it.
>
> I think this thread is basically based on the old idea that APL code
> can blow up with APL errors displayed on the screen.
>
> There are error handlings in all new modern APLs and no need for the
> user to know other than the solution was done in APL and it works.
>
> The reason for the solution was done in APL was because it was easier
> and faster.
>
> ----------------
> Björn Helgasonhttp://groups.google.com/group/J-Programming

There are several reasons that real-time missile defense applications
should not be implemented in APL. One of them is that you don't want
to lose cycles to garbage collection in the midst of trying to shoot
down a missile.

On Aug 18, 2:29 am, Jack <jgr...@comcast.net> wrote:
> On Aug 16, 3:57 am, Gosi <gos...@gmail.com> wrote:
>
>
>
> > On Aug 12, 4:30 am, Jack <jgr...@comcast.net> wrote:
>
> > > 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.
>
> > How and why would they blame APL?
>
> > I guess that was the attitude some decades ago but it is hardly
> > relevant today.
>
> > > 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++.
>
> > So you are not giving them any chance of judging any APL and as far as
> > your message goes you do use APl but you will not let anyone know how
> > you came up with your solution.
>
> > I think it is time to drop the old idea that APL is just for certain
> > people and some people are dead against it.
>
> > I think this thread is basically based on the old idea that APL code
> > can blow up with APL errors displayed on the screen.
>
> > There are error handlings in all new modern APLs and no need for the
> > user to know other than the solution was done in APL and it works.
>
> > The reason for the solution was done in APL was because it was easier
> > and faster.
>
> > ----------------
> > Björn Helgasonhttp://groups.google.com/group/J-Programming
>
> There are several reasons that real-time missile defense applications
> should not be implemented in APL. One of them is that you don't want
> to lose cycles to garbage collection in the midst of trying to shoot
> down a missile.

There are surely 1000 reasons why real-time missile defense
application should not be implemented in any language.

If you look at all the possible problems with any language i am sure
you can find something wrong.

People have been making mistakes in various programs and the more
lines you write the more likely it is to make mistakes.

It is more a question of attitude if you look for positive or
negative.

If you look for positive you will find it.
If you look for negative you will find it.

Will you look for positive and add on it and eliminate any problems
encountered or will you look for negative and not give it a try?

It looks like many concentrate on the negative in APL and do not even
try to fix it.

Many who say this and that is not good enough in APL think the same is
ok in other languages.

I have recently looked closely at Rexx again.

Rexx seems to be positively accepted for many of the things people
have complained about in APL

Gosi wrote:
>
> I do not understand why the project nearly died and why it took six
> months if it only took one week to do.

are you, perhaps, confusing the end-to-end delivery time for a project
with the completion time for an APL module?

I have been in a similar situation when Oracle promised SQLForms for
3270 (a conversion from the version running on DEC), and it arrived 13
months late

it was a huge embarrassment, and the loss of credibility it created
caused all my other decisions to come under addition (unskilled) scrutiny

not a happy time

/phil

On Aug 18, 9:16*am, phil chastney
<phil.hates.s...@amadeus.munged.eclipse.co.uk> wrote:
> Gosi wrote:
>
> > I do not understand why the project nearly died and why it took six
> > months if it only took one week to do.
>
> are you, perhaps, confusing the end-to-end delivery time for a project
> with the completion time for an APL module?
>
> I have been in a similar situation when Oracle promised SQLForms for
> 3270 (a conversion from the version running on DEC), and it arrived 13
> months late
>
> it was a huge embarrassment, and the loss of credibility it created
> caused all my other decisions to come under addition (unskilled) scrutiny
>
> not a happy time
>
> /phil

Phil is closer to the mark. I should have been clearer. The IT dept
had persuaded us to use a mainframe interface that they would write,
rather than let us hack our own way through. This was economical with
programming time, and it turned out in the end to require less than a
week's work from one of their programmers.

I recall hesitating nonetheless, wary of depending on resources we
didn't control. My nervousness turned out to be entirely justified.
The interface became overdue and the IT project manager responsible
(is this the word I want?) couldn't tell us when we would get it, or
even who was coding it. We eventually defied the prohibitions about
crossing 'internal lines of communication' and tracked down the
programming task to a man in a remote city, in a department the
'project manager' did not even know existed.

We coached the programmer through what we needed, interpreting the
points of his specification that he found puzzling. (He had no access
to the analyst who had written it.) We had our code not long
afterwards. He thanked us profusely for getting in touch, saying how
rare it was to get any idea about how his work was used.

Lessons to draw? When wearing sheepskin remember the sheep move a
_lot_ slower. (I'm reminded of an Eric Frank Russell SF story called,
I think, "The Waitabits".) No one in the client company thought it
remarkable for a 1-week programming task to get allocated a 6-week
slot and then run 4½ months late. Next time I'll be more alert to the
single point of failure and do the 'APL thing' – reinvent the wheel,
as Ajay would say — and let the IT solution arrive in its own time.

This doesn't argue for or against using conventional IT components.
The point is rather that relativistic effects (ie relative development
speeds) make some otherwise strange choices rational. In this case we
should have written two interfaces and discarded one. (Probably ours,
but who knows?)

There's a strong analogy with the criticism that programs in array
languages habitually 'overcompute', using short expressions that
process entire arrays when longer expressions would do less work. The
standard answer is that, when time-to-solution takes priority over
execution time, overcomputing is often a very acceptable way to reduce
it. Similarly, 'overdeveloping' can reduce time to delivery.

In our project, programming a solution two or three times was
generally faster than analysis, specification, coding and correcting.
Eventually our end users grasped that we expected to rewrite programs,
did not expect accurate and adequate 'requirements', and never
justified an inadequate solution as 'according to specification'. When
they got that we were their partners in finding workable solutions,
they became a _lot_ more communicative, and less guarded against
making mistakes.

One of the most satisfying aspects of the project for me was seeing
the end users emerge from a context in which failure was usual. In
this context, any problem for which they could not be held responsible
was promoted as a disaster that precluded results. With us, they came
to expect success, and got in the habit of overcoming obstacles or
brushing them aside.

We wore sheepskin, but we also enrolled them in the company of
wolves.

Stephen Taylor

editor@vector.org.uk
http://www.vector.org.uk