Re: Vector themed issue: How to wear sheepskin

On Aug 26, 8:59*pm, Joe_Blaze <joe.bl...@apl2000.com> wrote:

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

I love the line that APL helps us smart programmers to exploit our
smarts and deliver more value. I even think it's true.

But it's also the opposite of 'wearing sheepskin'. The world of
industrialised software development and Visual Studio aims to arrange
the work so it can be carried out by plug-compatible MSCEs. (This
might not work well, but it's neither wicked nor stupid; it's just the
standard strategy of industrialisation since Adam Smith described how
to make pins.) The last thing the IT shepherds think they want is
elite programmers working in their own language.

That doesn't mean there isn't mileage in the concept. I do think it's
salable to business managers (and perhaps a few IT managers) in the
context of a 'special forces' software SWAT team to tackle high-
priority projects. There's a whole vocabulary and conversation to be
developed to support this, akin to the vocabulary Beck, Cunningham et
al. developed around "Extreme Programming". I do think there's an
opportunity to get business managers demanding something like "Direct
Development" from their IT divisions. Grasping the opportunity takes
marketing work.

This thread keeps getting drawn into two well-worn grooves: "How We
Fell From Grace" and "How To Pitch APL And To Whom". Both of these
bones are still worth gnawing. And: I'm still interested in answers to
the original question. Leaving aside our honour-roll of projects in
which we ran rings around the sheep and shepherds, are there any
reports to be had of (a) delivering APL components in a polyglot
project or (b) integrating APL applications with existing corporate
infrastructure? What lessons are to be drawn from this experience:
what works, what fails? (I've already noted the dangers of relying on
components to be developed by internal teams working on geological
time.)

The challenge facing us: to see APL taken up more widely, we need to
describe in organisational terms how that works to people who assume
it doesn't.

SJT

On Aug 27, 1:48*pm, "Stephen Taylor <edi...@vector.org.uk>"
<StephenTaylorF...@googlemail.com> wrote:
> On Aug 26, 8:59*pm, Joe_Blaze <joe.bl...@apl2000.com> wrote:
>
> > 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.
>
> I love the line that APL helps us smart programmers to exploit our
> smarts and deliver more value. I even think it's true.
>
> But it's also the opposite of 'wearing sheepskin'. The world of
> industrialised software development and Visual Studio aims to arrange
> the work so it can be carried out by plug-compatible MSCEs. (This
> might not work well, but it's neither wicked nor stupid; it's just the
> standard strategy of industrialisation since Adam Smith described how
> to make pins.) The last thing the IT shepherds think they want is
> elite programmers working in their own language.
>
> That doesn't mean there isn't mileage in the concept. I do think it's
> salable to business managers (and perhaps a few IT managers) in the
> context of a 'special forces' software SWAT team to tackle high-
> priority projects. There's a whole vocabulary and conversation to be
> developed to support this, akin to the vocabulary Beck, Cunningham et
> al. developed around "Extreme Programming". I do think there's an
> opportunity to get business managers demanding something like "Direct
> Development" from their IT divisions. Grasping the opportunity takes
> marketing work.
>
> This thread keeps getting drawn into two well-worn grooves: "How We
> Fell From Grace" and "How To Pitch APL And To Whom". Both of these
> bones are still worth gnawing. And: I'm still interested in answers to
> the original question. Leaving aside our honour-roll of projects in
> which we ran rings around the sheep and shepherds, are there any
> reports to be had of (a) delivering APL components in a polyglot
> project or (b) integrating APL applications with existing corporate
> infrastructure? What lessons are to be drawn from this experience:
> what works, what fails? (I've already noted the dangers of relying on
> components to be developed by internal teams working on geological
> time.)
>
> The challenge facing us: to see APL taken up more widely, we need to
> describe in organisational terms how that works to people who assume
> it doesn't.
>
> SJT

If you think about it then many of the other programming languages
have a cover which hides what the system is written in.

All you see is an executable file or shortcut to it and that is it.

Even some of the more modern APLs can also create executable files and
nobody needs to know what the system is written in.

So why bother tell people about what it is written in if they do not
care.

Not so many years ago, I was coding an application in Smalltalk (an
interactive, interpreted language, in a few ways like APL, but with a
much steeper growth and decay curve). One of the upper managers,
several levels above the project leader, proudly exclaimed to me "I
can understand your code!"

Hmm.

It later occurred to me that this is one of the most dangerous things
there is, when someone who is quite distant from the actual work now
has the idea that he is in a position to make decisions, based on his
supposed "knowledge". He thinks he can understand the code, or worse
yet, He thinks he can understand the code because he recognizes some
of the words. But in the end, the manager felt good.

I suppose real-life decision making isn't much better. Management
will choose products which they think they understand, and the vendors
(Microsoft, Sun, etc. - in the end, regardsless of what they think
they are, they are vendors).

On Aug 27, 10:35 pm, Gosi <gos...@gmail.com> wrote:

> So why bother tell people about what it is written in if they do not
> care.

No problem (most of the time) if you run your own company and you just
ship a product. Until you want to recruit developers and have to
explain to them why you want them to learn APL. Or if you want to
market APL as a technology to a development team, or do consulting for
a large organization which has to assume (some degree of)
responsibility when you are done. In these cases, you will need to
explain why APL is a good tool for the work in question, AND how its
use is compatible with relevant "best practices" in software
engineering.

I'm looking forward to a couple of presentations on these topics at
Dyalog'08 (Elsinore, Denmark, October 12-16). See for example the
abstract of "Herding Cats for Fun and Profit" at
http://www.dyalog.com/dyalog_08_conf...programme.html. There's
still a couple of days until the "Early Bird" deadline for
registration expires :-).

On Aug 25, 1:39 am, "Poli...@acm.org" <Poli...@acm.org> wrote:

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

Ray,

Excellent points - and thank you very much for the link to Brain Hayes
article, which is very interesting reading. I think that understanding
the distinction between "inquisitive programming" and "software
development" - and the necessary interaction between the two - is key
to the successful use (and marketing) of APL.

I think we all agree that APL supports the inquisitive programmer very
well. When discussing "how to market APL", I think we often confuse
two problems. The first is arguing (like Brian Hayes) that there is a
place for inquisitive programming, and that some people (the so-called
"Domain Experts") should be allowed to do it. The second problem is
that sometimes, when the inquisitive bit is done and it has resulted
in something valuable, we need to be able to deploy the solution in a
professional manner, crossing over into the domain of "software
development".

In this forum, there has been some argument about which of the two
problems it is we face, but I believe the reality is that - as a group
- we need to address both issues. To be able to wear the sheepskin
("be recognized as valued colleages by software developers"), we need
to solve some technical problems (interfacing to .Net and such), but
equally importantly we need to learn a suitable vocabulary to allow us
to argue in favour of including inquisitive programming as a natural
part of many kinds of software projects - and we need to solve
organizational issues so that the "inquisitive programmers"/domain
experts learn how to interact productively with professional software
developers in projects.

Now... As you point out, there is no point learning how to wear the
sheepskin if we ARE all sheep already: Someone needs to find and hone
the hunting skills of some wolves that others can dress up in
sheepskin if and when this is necessary. This is hard work, but it CAN
be done! I think there is a good chance that we can in fact get APL
back into a standard curriculum. There is a growing maturity in the
software development community, an understanding that there is a place
for tools like Python, Ruby and ... if we produce the right
materials ... APL. However, I'm not convinced that the computer
science dept is necessarily the right place to promote APL: Even in
the past, more good APLers came out of electrical engineering and
similar departments than CS - and APL arguably has more to offer
engineers than computer scientists.

I also think the link to other skills (domain knowledge) is important.
Many of our customers are recruiting many people each year to write
APL - they generally find that they get the best results by hiring
smart kids who know the business (finance, chemistry, whatever) and
quickly teaching them APL. You can teach an actuary APL in rather less
time than you can teach a most programmers statistics. This generally
gives you someone who is a good inquisitive programmer, and the team
then needs to be seeded with a small number of people who can sew up
the sheepskin: People who understand APL (and how the APLers think),
but are stronger on the software engineering side. This recipe seems
to work well for a number of our customers and one of the things we
need to do is describe to managers "how to run a professional software
development unit which includes APL developers". But the number of
domain experts required is generally an order of magnitude greater
than the number of "APLers who are also software engineers".

We hope that we will be able to engage computer clubs and schools in
the future. However, our current feeling is that a complete set of
modern training materials which address the interests of a new
generation of potential APLers must be developed, before there is much
chance that we can attract people via the internet. We have a new APL
Tutorial (700 pages!) written by Bernard Legrand in the works, it will
become available in the next few months, and we will continue to
invest in materials steadily in the years to come.

With luck, we'll be able to help continue to generate excitement in
the years to come!

Morten

Hello,

Morten Kromberg <mkrom@dyalog.com> wrote:
> We hope that we will be able to engage computer clubs and schools in
> the future. However, our current feeling is that a complete set of
> modern training materials which address the interests of a new
> generation of potential APLers must be developed, before there is much
> chance that we can attract people via the internet. We have a new APL
> Tutorial (700 pages!) written by Bernard Legrand in the works, it will
> become available in the next few months, and we will continue to
> invest in materials steadily in the years to come.

I've been lurking here a long time, with the occasional posts a long
time ago when I was learning APL to write tic-tac-toe and I got very
nice help from the people in this group. The reason I looked at APL in
the first place was because I am interested in iconographic programming
languages--pretty esoteric, to say the least.

However, I also happen to reasonably fall into the category of the type
of people you want to learn APL, I'm in my early 30's and interested in
cool stuff.

I basically live outside of the APL culture looking in, and I have some
observations about why people think (and indeed it might be that) APL
is in decline. My opinion is just that, and probably wrong, but if you
want to figure out a way to get APL more acceptance, you folks probably
have to understand why I think the way I do instead of discounting it.

First: the applications one traditionally writes in APL are not really
interesting to the mainstream programmer. I know, I know, sacrilege and
all that, but the fact is that APL has a horrible stigma associated with
it that it seems only useful for esoteric bank software or accounting
systems--and who wants to write that?

Second: APL is extraordinarily dense and the syntax occludes the
semantics. To the developed programmer, this is a feature, but to someone
who runs across it, it is a train wreck. Take a look at the Wikipedia
page for APL, which is basically the first thing someone finds when they
query what is APL in google:

http://en.wikipedia.org/wiki/APL_(programming_language)

Notice the examples....they are dense pieces of code that look nothing
like how other languages implement those algorithms from a symbolic point
of view. The thing about imperative languages is that they are like
romance languages--you know one, you can easily puzzle out the others. APL
is like coming across Chinese in between Spanish, French, and Italian--one
of these four is not like the others and doesn't even use a cyrillic
character set! This is one of the biggest things the APL culture has to
understand how to overcome in getting APL mass acceptance--reconciling
code density with the attainment of understanding. Making the characters
ascii doesn't fix the problem, it is that the characters *mean* much
more than similar length characters in other languages.

Third: there are no popular applications that want to draw people to
learn how to use APL. For example, write some stupid, but fun, little
game with graphics, that uses a seriously cool and complete physics
engine written in 100 characters of APL. Open source it, and DOCUMENT
THE HELL OUT OF IT. Produce many examples of little pieces of cookbook-y
software that do cool things with high quality documentation.

The flip side of this coin is how easy is it to get APL on a popular
OS like Linux _using the package manager that comes with it_? On my old
fedora core 7 box, I can get aplus using yum. I, in fact, did so just now
(along with the required other rpms like the font and whatnot), ran the a+
command, then got stuck as it seems I couldn't produce any APL characters
to test it. A problem with aplus was that after ten minutes of looking
online--a very generous amount of time, I couldn't figure out how to enter
the characters properly or what the GUI was I was supposed to use. Fail.

A contrary example is once I asked a room full of people "How do I do X in
perl?", the response was "Look in CPAN for X and install it". With just
that information--and not knowing what CPAN was those many years ago,
I was able to find instructions on the web in what was and how to use
CPAN and install the module in like 45 seconds of looking and it just
worked. APL needs the fast informational reference off the web that
other languages have.

Fourth: the average programmer wanting to write space invaders is
going to ask the question "So, uh, how do I call the OpenGL API inside
of APL?" Most popular languages these days either have very extensive
libraries associated with them with a well documented API, or a foreign
function interface to C so one may write wrappers around an already well
known library. If you search for "APL C bindings" in google, you get
NOTHING, and so people will say "If I can't even use the libraries I
want to use, then screw APL, I'll write my thing in some other language."

Fifth: how do you write a hash table in APL? Programmers in the entry
stages of their education learn to write the basic algorithms they
will come to know and love throughout their career in the usual
imperative languages. The first question from someone trying to
do the above is how do they make an aggregate type like C's struct
and use them effectively. There should be a page somewhere possibly
showing the common algorithms, or maybe even all of the ones found in
"Introduction to Algorithms" by Thomas H. Cormen, Charles E. Leiserson,
Ronald L. Rivest. It should be documented heavily. An extension to this
topic is how do you do symbolic processing in APL--the mainstream think
APL is only good enough for implementing linear algebra algorithms. I
could write tens of thousands of lines of code in something like C before
ever having to multiply a matrix together, if at all.... So show me what
else APL can do.

Sixth: APL suffers from a similar problem as, say, Scheme. Many
interpreters each with their own little dialect and a medium sized
community around each one. APL needs unity. Pick an implementation,
open source it, make it work everywhere, document everything about the
APL dialect it implements, slash and burn the rest. This way, the pool of
APL programmers would be larger and be more powerful as they have shared
knowledge about the dialect, talk about it at large, and more importantly,
write web pages describing cool things they've done or essays about it,
from which others can read and learn, thereby increasing the knowledge
base. I realize that this unification will probably never happen,
as is the nature of humans and business. However, compare the popularity of
monoculture languages and languages with many diverse dialects--you will
see a direct effect in the popularity and community structure.

Seventh: Hold APL programming contests with some kind of prize money, like
$10,000 dollars and promote it to colleges. See who joins, maybe it'll
increase the popularity of the language. You need to find smart people
at a young age, and money is a serious motivator to learn something that
is different and powerful--both elements of why a geek learns something.

It is not my intention to incite flamewar or provide anything other
than a single person's opinion on a language that I also wish to see be
more popular.

Thank you.

-pete

Pete,

Many thanks for your considered and very interesting post. I am going
to print it out and ponder more on what, as APL vendors, we can learn
from it.

Richard Nabavi
MicroAPL Ltd

On Aug 29, 5:06*am, Peter Keller <psil...@merlin.cs.wisc.edu> wrote:
> Hello,
>
> Morten Kromberg <mk...@dyalog.com> wrote:
> > We hope that we will be able to engage computer clubs and schools in
> > the future. However, our current feeling is that a complete set of
> > modern training materials which address the interests of a new
> > generation of potential APLers must be developed, before there is much
> > chance that we can attract people via the internet. We have a new APL
> > Tutorial (700 pages!) written by Bernard Legrand in the works, it will
> > become available in the next few months, and we will continue to
> > invest in materials steadily in the years to come.
>
> I've been lurking here a long time, with the occasional posts a long
> time ago when I was learning APL to write tic-tac-toe and I got very
> nice help from the people in this group. The reason I looked at APL in
> the first place was because I am interested in iconographic programming
> languages--pretty esoteric, to say the least.
>
> However, I also happen to reasonably fall into the category of the type
> of people you want to learn APL, I'm in my early 30's and interested in
> cool stuff.
>
> I basically live outside of the APL culture looking in, and I have some
> observations about why people think (and indeed it might be that) APL
> is in decline. My opinion is just that, and probably wrong, but if you
> want to figure out a way to get APL more acceptance, you folks probably
> have to understand why I think the way I do instead of discounting it.
>
> First: the applications one traditionally writes in APL are not really
> interesting to the mainstream programmer. I know, I know, sacrilege and
> all that, but the fact is that APL has a horrible stigma associated with
> it that it seems only useful for esoteric bank software or accounting
> systems--and who wants to write that?
>
> Second: APL is extraordinarily dense and the syntax occludes the
> semantics. *To the developed programmer, this is a feature, but to someone
> who runs across it, it is a train wreck. *Take a look at the Wikipedia
> page for APL, which is basically the first thing someone finds when they
> query what is APL in google:
>
> http://en.wikipedia.org/wiki/APL_(programming_language)
>
> Notice the examples....they are dense pieces of code that look nothing
> like how other languages implement those algorithms from a symbolic point
> of view. *The thing about imperative languages is that they are like
> romance languages--you know one, you can easily puzzle out the others. APL
> is like coming across Chinese in between Spanish, French, and Italian--one
> of these four is not like the others and doesn't even use a cyrillic
> character set! This is one of the biggest things the APL culture has to
> understand how to overcome in getting APL mass acceptance--reconciling
> code density with the attainment of understanding. Making the characters
> ascii doesn't fix the problem, it is that the characters *mean* much
> more than similar length characters in other languages.
>
> Third: there are no popular applications that want to draw people to
> learn how to use APL. For example, write some stupid, but fun, little
> game with graphics, that uses a seriously cool and complete physics
> engine written in 100 characters of APL. Open source it, and DOCUMENT
> THE HELL OUT OF IT. *Produce many examples of little pieces of cookbook-y
> software that do cool things with high quality documentation.
>
> The flip side of this coin is how easy is it to get APL on a popular
> OS like Linux _using the package manager that comes with it_? On my old
> fedora core 7 box, I can get aplus using yum. I, in fact, did so just now
> (along with the required other rpms like the font and whatnot), ran the a+
> command, then got stuck as it seems I couldn't produce any APL characters
> to test it. A problem with aplus was that after ten minutes of looking
> online--a very generous amount of time, I couldn't figure out how to enter
> the characters properly or what the GUI was I was supposed to use. Fail.
>
> A contrary example is once I asked a room full of people "How do I do X in
> perl?", the response was "Look in CPAN for X and install it". With just
> that information--and not knowing what CPAN was those many years ago,
> I was able to find instructions on the web in what was and how to use
> CPAN and install the module in like 45 seconds of looking and it just
> worked. APL needs the fast informational reference off the web that
> other languages have.
>
> Fourth: the average programmer wanting to write space invaders is
> going to ask the question "So, uh, how do I call the OpenGL API inside
> of APL?" Most popular languages these days either have very extensive
> libraries associated with them with a well documented API, or a foreign
> function interface to C so one may write wrappers around an already well
> known library. *If you search for "APL C bindings" in google, you get
> NOTHING, and so people will say "If I can't even use the libraries I
> want to use, then screw APL, I'll write my thing in some other language."
>
> Fifth: how do you write a hash table in APL? Programmers in the entry
> stages of their education learn to write the basic algorithms they
> will come to know and love throughout their career in the usual
> imperative languages. *The first question from someone trying to
> do the above is how do they make an aggregate type like C's struct
> and use them effectively. There should be a page somewhere possibly
> showing the common algorithms, or maybe even all of the ones found in
> "Introduction to Algorithms" by Thomas H. Cormen, Charles E. Leiserson,
> Ronald L. Rivest. It should be documented heavily. An extension to this
> topic is how do you do symbolic processing in APL--the mainstream think
> APL is only good enough for implementing linear algebra algorithms. I
> could write tens of thousands of lines of code in something like C before
> ever having to multiply a matrix together, if at all.... So show me what
> else APL can do.
>
> Sixth: APL suffers from a similar problem as, say, Scheme. Many
> interpreters each with their own little dialect and a medium sized
> community around each one. APL needs unity. Pick an implementation,
> open source it, make it work everywhere, document everything about the
> APL dialect it implements, slash and burn the rest. This way, the pool of
> APL programmers would be larger and be more powerful as they have shared
> knowledge about the dialect, talk about it at large, and more importantly,
> write web pages describing cool things they've done or essays about it,
> from which others can read and learn, thereby increasing the knowledge
> base. *I realize that this unification will probably never happen,
> as is the nature of humans and business. However, compare the popularity of
> monoculture languages and languages with many diverse dialects--you will
> see a direct effect in the popularity and community structure.
>
> Seventh: Hold APL programming contests with some kind of prize money, like
> $10,000 dollars and promote it to colleges. See who joins, maybe it'll
> increase the popularity of the language. You need to find smart people
> at a young age, and money is a serious motivator to learn something that
> is different and powerful--both elements of why a geek learns something.
>
> It is not my intention to incite flamewar or provide anything other
> than a single person's opinion on a language that I also wish to see be
> more popular.
>
> Thank you.
>
> -pete

I guess that these comments would be different in the case of
individual APLs.
They are too different to apply everything to all of them.
As a whole it is very good to get the views from newcomers and what
they experience.
The lack of good documentation has always been a consideration.
Highly technical for existing APLers is no problem but the simple
things to attract the masses has been missing.

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

Hello,

microapl@microapl.demon.co.uk wrote:
> Many thanks for your considered and very interesting post. I am going
> to print it out and ponder more on what, as APL vendors, we can learn
> from it.

Thank you for the kind words.

Scheme, a language I'm familiar with and member of the community, tried to
solve the many dialects problem in two ways:

1. The scheme compiler vendors (ompanies and individuals) got together and
fought over a document which described the common subset of scheme that they
all implemented. Over the years, this document gets revised and is now on
it's 6th revision. Occasionally there is dispute about how something should
act, but most times the vendors converge to a document.

This still allowed lots of compilers/IDEs with proprietary extensions
to be built, but if a user was careful and kept the the "official scheme
language definition", thie code would be extremely portable with almost
no changes.

2. The community had been upset due to lack of portability of scheme code,
so they created something called "Scheme Requests for Implementation",
or SRFI, documents. Each SRFI detailed either an API (like vector math,
string handling, unicode support) or a compiler feature (like condition
compilation, record types, etc) and went through a vetting process
through a panel of well known scheme people. If they were finalized, it was
the agreement among the vendors that they would implement as many of them as
they resonably could.

This happened to a pretty decent success, in the end, lots of SRFIs were made
and supported and code got more portable.


In the end, Scheme--along with budding standard library, is slowly
being standardized and there can be as many compilers as you want, but
they all implement larger and larger subsets of standard functionality,
resulting in code being more portable. In my experience, the portability
of code seemed very important to the scheme community. So much so that
there was great debate over how to define a library in the standard that
left some apparently bitter blood in its wake. Still though, the vendors
of the language knew that Scheme had to evolve (records (think structs
in C), library definitions, standard library included with the language,
etc--these were not present in the previous definiton of scheme so each
vendor had proprietary extensions) in order to stay relevant, this being
the key point for APL.

I looked around, and I simply couldn't find a document which basically
says "This is the definition of APL" which described a dialect and
functionality that would work (as agreed upon by the vendors) on any
popular APL interpreter. Hence, I think that APL probably has a subset
of commonality, but I won't know until I wrote a bunch of code in one
dialect, then try to make it work on another and things blow up.

Maybe I'll write more later. I have a bus to catch.

Thank you.

-pete

Peter Keller <psilord@merlin.cs.wisc.edu> wrote in
news:48b85fe2$0$9898$80265adb@spool.cs.wisc.edu:

> [... deleted ...]
>
> I looked around, and I simply couldn't find a document which basically
> says "This is the definition of APL" which described a dialect and
> functionality that would work (as agreed upon by the vendors) on any
> popular APL interpreter. [... deleted ...]

There is an ISO Standard, but it was produced more than 20 years ago and
reactively rather than proactively. As a consequence, the APL it
describes/defines is a rather small subset of the functionality of current
interpreters. I don't know whether there is any ongoing effort to produce
anything more current.