Re: Vector themed issue: How to wear sheepskin

On Aug 15, 6:07*pm, AAsk <AA2e...@lycos.co.uk> wrote:

> 2) APL people ought to make a big effort in learning more about everything other than APL to be
> effective.

One really big problem with this is that for a very large portion of
the people who currently get REAL VALUE from the use of APL, this
requirement would in fact remove most of that value. APL provides them
with a tool which allows them to produce running code easily, without
having to become software engineers. If the solution they have come up
with becomes valuable, these APLers may need to ally themselves with
software experts who can provide wrappings / interfaces between APL
code and the outside world.

I agree that your requirement is reasonable for anyone who wants to
use APL to compete in the open or general-purpose IT marketplace - if
you want to sell projects to software engineers. It would be good if
we can end up in a situation where more people want to do this, but
the way IT works today, if you really have to adhere to all the rules
that these people insist upon, the added value of APL is (as you say
yourself) "marginal". Currently, most profitable use of APL seems to
be by people who use it to solve problems they know something about,
and then build products which they sell. They need to build interfaces
to relational databases and other components but they don't have to
satisfy software engineers that they are following ALL the rules. I
expect this will change and APL-based "consultancy" (as opposed to
"products") will become more common again, partly as the APL community
grows younger and has more people with some IT schooling in addition
to whatever other skills they have - but also because the software
engineering community must (surely?) eventually mature and understand
that many of the things we do in the APL community actually make a lot
of sense if you want to deliver software on time and on budget
(something which they seem to find extraordinarly difficult).

We DO need a bunch of increasingly savvy people who can help the
people who have domain knowledge and can express things in APL, to
deliver components which can be used in other applications. And the
vendors need to keep working on providing better infrastructure to
make it easier for this work to be done - and help spread the word
about how to wear sheepskin, etc.

However, we must NEVER insist that ALL "APL People" need to (for
example) become experts in Object Orientation, or learn how to use
Visual Studio, or absorb the entire contents of the .Net Framework and
associated libraries. To do so is to ignore the enormous value that
APL and similar languages provide to a large number of people around
the world today - people who have no desire to learn such skills. We
would also be walking away from a potential high value market(!)

Seriously, this discussion needs to be much more balanced to avoid
going round in circles (again). How can one reasonably argue that
people who are experts in (say) Finance and have learned to write
enough APL to analyze financial data, but resist learning an entire
new profession (Software Engineering) are "lazy"? Obviously, I would
agree that anyone who is able to understand (say) finance, write good
APL AND be an expert software engineer has an incredible advantage
(expecially if they also know how to do sales and marketing). But I
can't EXPECT everyone to want to do all that, even if they could.

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.

David Liebtag
IBM APL Products and Services

"Morten Kromberg" <mkrom@dyalog.com> wrote in message
news:d8977141-83b4-4b15-a19c-da8267e0b69d@r66g2000hsg.googlegroups.com...
On Aug 15, 6:07 pm, AAsk <AA2e...@lycos.co.uk> wrote:

> 2) APL people ought to make a big effort in learning more about
> everything other than APL to be
> effective.
>>>>>>>>>>>>>
One really big problem with this is that for a very large portion of
the people who currently get REAL VALUE from the use of APL, this
requirement would in fact remove most of that value. APL provides them
with a tool which allows them to produce running code easily, without
having to become software engineers.
[...]
Seriously, this discussion needs to be much more balanced to avoid
going round in circles (again). How can one reasonably argue that
people who are experts in (say) Finance and have learned to write
enough APL to analyze financial data, but resist learning an entire
new profession (Software Engineering) are "lazy"? Obviously, I would
agree that anyone who is able to understand (say) finance, write good
APL AND be an expert software engineer has an incredible advantage
(expecially if they also know how to do sales and marketing). But I
can't EXPECT everyone to want to do all that, even if they could.
>>>>>>>>>>>>>>

Morton is saying very diplomatically (he's supposed to) what I've always
been trying to say - maybe more bluntly.
When I started "playing" with the computer I did a four days course in
BASIC and composed the entire valuation administration of a small
insurance company on time sharing (the consulting actuary was very
proud!). Later I learned some of APL, and I felt right away that I could
solve many of all my problems - actuarial and financial in the broadest
sense.
Because of my function (head IT Dept.) I felt I was supposed to bend
forwards & backwards to the rest of the family. I started with a course
COBOL (six weeks), read a book on VMS of DEC, and started seriously
reading Art Lew's Computer Science - A Mathematical introduction. A very
interesting and instructive book, but my attention was pulled to Gilman
& Rose, and I soon found Lew's book waste of my time (although I kept it
at hand).
It appeared a waste of time - sort of, because there's no need for a
formal or profound study in computer engeneering for an expert in an
other field. He usually has the education to pick up things he needs on
the fly very fast, learning from other people the necessary things to
communicate. And that will do - although in my case.
Maybe I've been lucky, not having been urged to wear a sheepskin, I
always could openly practice my (APL-) profession - with some of succes,
I think.
However, I had not been able to "infect" enough other people in order to
secure APL for the company when I left.
Jan K.

"David Liebtag" <DavidLiebtag@vermontel.net> wrote in message
news:1219096160.786861@r2d2.vermontel.net...
> 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.
>
> David Liebtag
> IBM APL Products and Services

That's right! With one the largest insurance companies (world rank top
ten - the Dutch & Swiss together have five or six in that bracket)
they're recruting exclusively enrolled actuaries for their actuarial
research dept, "preferably with knowledge of APL or willingness to learn
it". They're not selling or marketing anything, they're just using it as
their Comptometers, Sumlocks or Monroematics in the old days:
computation. They're not visiting APL-conferences (they couldn't care
less) or reading Vectors (they probably don't know of the existence).
This has in my view always been the majority of the APL-users.
On the other hand, when visiting GenRe (Greenwich, NY) there was a whole
battery of actuaries in an endless office-room doing the same thing in
BASIC (early 80-ies).
Further, making a product differs day & night from making an
application, in the described environments, often for a single time use.

On Aug 18, 8:27 pm, Morten Kromberg <mk...@dyalog.com> wrote:
> On Aug 15, 6:07 pm, AAsk <AA2e...@lycos.co.uk> wrote:
>
> [...] - but also because the software
> engineering community must (surely?) eventually mature and understand
> that many of the things we do in the APL community actually make a lot
> of sense if you want to deliver software on time and on budget
> (something which they seem to find extraordinarly difficult).

It is a good time to take some control of the conversation about
software development. Since the emergence of a professional 'software
engineering' orthodoxy, APL has consistently been characterised as the
wrong way to write software. Note that I say "wrong way" rather than
"wrong language". The opposition I have encountered while using APL
has been focused on methods and practices rather than the language.
Conversely, a large part of the value in the language lies in the
development practices it enables.

For a quarter of a century our lightweight practices have been widely
deprecated. I propose that the fortunes of the language have depended
more on views about development practices than on views about
programming-language design.

The agile movement in general and XP in particular has done a lot to
reclaim respect for lightweight software development. Morten, Gitte &
I have made pilgrimages to XP conferences, hoping to find open ears,
but attention there is focused on agile vs waterfall, and challenges
to the Java/C++ hegemony were received largely as unwelcome
distractions. (To be fair, the movement's leaders are a great deal
more receptive than the rank and file. I told Kent Beck my first
reaction to XP was astonishment so much agility could be squeezed from
Java: he grinned wolfishly and spoke wistfully of being able to
develop again in Smalltalk.)

APL users have a large fund of stories about lightweight APL
development outperforming conventional heavy practices. We should all
be clear by now that those good results are trumped by 'methodology'.
A record of good results mysteriously obtained is a source of worry to
managers unable to explain how or whether such results can be
sustained. Managers intervene to replace high-performing APL groups
with orthodox groups whose inferior performance is at least
predictable. (The cynical will add: and which does not invite awkward
comparisons.) This is rational, especially in a management culture
where project failure is common and survivable. If an orthodox project
fails, a defence is available: we did everything we were supposed to.
Without theory you can be judged only on results.

So APL has flourished where results trump theory: in financial markets
IT and, as Morten points out, among the 'gentlemen amateurs'. These
are the domain experts who program: actuaries, scientists like Beau
Webber (see Vector 23:3) and the original authors of the software
underlying Cognos, Sim-Corp, the Carlisle Group, APL Italiana and
others.

Over the next decade the widely-advertised economic contraction now
starting will make project failure less survivable. Our record of good
results will receive more attention than it has. And we can help
ourselves by taking control of the conversation. (George Lakoff
describes this process in politics very well in his book "Don't Think
of an Elephant: Know your values and frame the debate".)

What would this look like? It would replace conversation about
'documented methodologies', 'specifications' and 'sign-offs' with
terms such as 'direct development' (thank you, Gitte), 'lightweight
methods' and 'fast feedback loops'.

In other words: instead of defending ourselves against orthodoxy,
counter-attack. Produce an alternative canon for software development,
in which APL's advantages are well lit.

Coming back to this thread and 'wearing sheepskin': an organisational
strategy would be to establish a lightweight development group with
its own practices (at least initially) as a complement to conventional
heavy development. A useful analogy would be the relationship of
special forces to the regular army. Both are military, but deployment,
training and discipline vary considerably. Time would tell how best to
split development between light and heavy groups.

Stephen Taylor

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

>>> This is rational, especially in a management culture
where project failure is common and survivable. If an orthodox
project
fails, a defence is available: we did everything we were supposed to.
Without theory you can be judged only on results.
<<<

Nicely put !

On Aug 19, 9:53*am, "Stephen Taylor <edi...@vector.org.uk>"
<StephenTaylorF...@googlemail.com> wrote:
> On Aug 18, 8:27 pm, Morten Kromberg <mk...@dyalog.com> wrote:
>
> > On Aug 15, 6:07 pm, AAsk <AA2e...@lycos.co.uk> wrote:
>
> > [...] - but also because the software
> > engineering community must (surely?) eventually mature and understand
> > that many of the things we do in the APL community actually make a lot
> > of sense if you want to deliver software on time and on budget
> > (something which they seem to find extraordinarly difficult).
>
> It is a good time to take some control of the conversation about
> software development. Since the emergence of a professional 'software
> engineering' orthodoxy, APL has consistently been characterised as the
> wrong way to write software. Note that I say "wrong way" rather than
> "wrong language". The opposition I have encountered while using APL
> has been focused on methods and practices rather than the language.
> Conversely, a large part of the value in the language lies in the
> development practices it enables.
>
> For a quarter of a century our lightweight practices have been widely
> deprecated. I propose that the fortunes of the language have depended
> more on views about development practices than on views about
> programming-language design.
>
> The agile movement in general and XP in particular has done a lot to
> reclaim respect for lightweight software development. Morten, Gitte &
> I have made pilgrimages to XP conferences, hoping to find open ears,
> but attention there is focused on agile vs waterfall, and challenges
> to the Java/C++ hegemony were received largely as unwelcome
> distractions. (To be fair, the movement's leaders are a great deal
> more receptive than the rank and file. I told Kent Beck my first
> reaction to XP was astonishment so much agility could be squeezed from
> Java: he grinned wolfishly and spoke wistfully of being able to
> develop again in Smalltalk.)
>
> APL users have a large fund of stories about lightweight APL
> development outperforming conventional heavy practices. We should all
> be clear by now that those good results are trumped by 'methodology'.
> A record of good results mysteriously obtained is a source of worry to
> managers unable to explain how or whether such results can be
> sustained. Managers intervene to replace high-performing APL groups
> with orthodox groups whose inferior performance is at least
> predictable. (The cynical will add: and which does not invite awkward
> comparisons.) This is rational, especially in a management culture
> where project failure is common and survivable. If an orthodox project
> fails, a defence is available: we did everything we were supposed to.
> Without theory you can be judged only on results.
>
> So APL has flourished where results trump theory: in financial markets
> IT and, as Morten points out, among the 'gentlemen amateurs'. These
> are the domain experts who program: actuaries, scientists like Beau
> Webber (see Vector 23:3) and the original authors of the software
> underlying Cognos, Sim-Corp, the Carlisle Group, APL Italiana and
> others.
>
> Over the next decade the widely-advertised economic contraction now
> starting will make project failure less survivable. Our record of good
> results will receive more attention than it has. And we can help
> ourselves by taking control of the conversation. (George Lakoff
> describes this process in politics very well in his book "Don't Think
> of an Elephant: Know your values and frame the debate".)
>
> What would this look like? It would replace conversation about
> 'documented methodologies', 'specifications' and 'sign-offs' with
> terms such as 'direct development' (thank you, Gitte), 'lightweight
> methods' and 'fast feedback loops'.
>
> In other words: instead of defending ourselves against orthodoxy,
> counter-attack. Produce an alternative canon for software development,
> in which APL's advantages are well lit.
>
> Coming back to this thread and 'wearing sheepskin': an organisational
> strategy would be to establish a lightweight development group with
> its own practices (at least initially) as a complement to conventional
> heavy development. A useful analogy would be the relationship of
> special forces to the regular army. Both are military, but deployment,
> training and discipline vary considerably. Time would tell how best to
> split development between light and heavy groups.
>
> Stephen Taylor
>
> edi...@vector.org.ukhttp://www.vector.org.uk

One of the problems with APL is that we tend to talk about and show
examples with data already in the ws.

Most potential new APLers want to use data already in the computer in
some form.
What they want to do is read that data process it and write it out
again.

In C they do that one line or on char at a time.

In APL you in general need to do some processing to get it into APL in
a form that APL likes.

Then after performing some magic on the data these almost leaving
former potential APLers would like to get the data out in a form that
can be printed, stored or processed with other means.

I know there are a lot of utilities etc but we generally do not think
those steps important and way to often the demos and utils are not
updated and simple do not work properly.

So our new potential APLer leaves and never comes back.

On 19 Aug, 12:18, Gosi <gos...@gmail.com> wrote:
>
> In APL you in general need to do some processing to get it into APL in
> a form that APL likes.
>
> Then after performing some magic on the data these almost leaving
> former potential APLers would like to get the data out in a form that
> can be printed, stored or processed with other means.
>
>

Absolutely correct. That is exactly why in APLX we introduced ⎕IMPORT
and ⎕EXPORT (not to mention ⎕CHART and ⎕SQL). The mystery is why APL
vendors haven't done this kind of thing before. It's all about making
things easy for the APL user.

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 Nabavi
MicroAPL Ltd

On 19 Aug., 16:39, micro...@microapl.demon.co.uk wrote:

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

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

In favour of the system function is the fact that APL users are much
better at adopting anything "library function" which a vendor has
given its stamp of approval in this way. As APL users are often not
technology-focused (to be diplomatic again), they would ideally like
to ignore technology issues until the vendor says it's time to go;
they count on vendors to decide when a particular technology or data
format (etc) is sufficiently important for them to bother about it.

Some would argue that these people are very lazy, and in a sense this
is correct. These people are working flat out to stay ahead of the
latest advances in Chemistry, Finance, Electrical Engineering, Data
Mining, or what have you. If we can live up to their expectations and
allow them to be a bit lazy on the Software Engineering side, we are
delivering very real value for their money.

On the downside, APL vendors often don't have enough dirt on their
fingers to know what APL users *really* need. We have limited
resources and can easily become bottlenecks if everyone waits for us
to build everything. Fortunately, with platforms like .Net, we have
more and more components of higher and higher quality - and often
surprisingly "array oriented" - that we can tap into.

We need to strike the right balance between vendors building new
functions, finding and recommending external tools (and making sure
interfaces to them work well), and more users doing as Ajay would
insist that they do: Foray into the IT World, learn about tools, and
then teach other APLers about them and put pressure on the vendors to
support new tools and technologies.

I'm have to say that I am very encouraged by current trends in the APL
community. After an uncomfortable pause while the community recoved
from the loss of the mainframe, we are starting to see a new community
gain a firm footing on "modern" computing platforms. We have more and
more savvy users, and quite a few vendors who are trying to take their
responsibility seriously. None of us are perfect, but there is a lot
of very good work going on at the moment.

Morten

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