Re: Newsreaders (Was: Response to 1NT with K7532 Q8743 J5 5)
Charles Brenner
> On Dec 22, 3:45 pm, Charles Brenner <cbren...@berkeley.edu> wrote:
> > I'll stick my neck out and admit to being vintage 1958, re computer
> > programming etc. All I claim that entitles me to is immunity from
> > condescension about google groups. Ok, enough old geezer act from me.
>
> > Charles
>
> You have me by 9 years - Fortran G on a standalone punchcard writer/
> reader and remote mainframe. Later in '70 COBOL/ALGOL/FORTRAN[WATFOR],
> later APL, then...
APL? Do tell.
Charles
Derek Broughton
Horrible "write-only" language. I'm glad I have no surviving instances of
anything I wrote in it (there was quite a lot of it, actually).
--
derek
Jane Sullivan
>
> Horrible "write-only" language. I'm glad I have no surviving
> instances of
> anything I wrote in it (there was quite a lot of it, actually).
>
> --
> derek
Here we go again. "Where ignorance is bliss, 'tis folly to be wise" :-)
--
Jane
KWSchneider
APL [from "A Programming Language"]. We used it off of our IBM 360 and
370 mainframes in 1971-73. Very powerful notational language with
specialized characters. Especially strong in vector and array
mathematics. Very cryptic to read [symbols looked like hieroglyphics -
ie asterisk inside of an "o" - arrows in all directions].
It was fun though...
Kurt
Charles Brenner
Thanks. I should have mentioned that I cross-posted to comp.lang.apl.
I wrongly assumed that you mentioned APL because you knew I use it.
All those funny symbols still exist (and in extended and modernized
packages). My initial experience with APL was participating in system
development at IBM research, possibly on the system you used.
Charles
Derek Broughton
They were actually Greek. Not very hieroglyphic.
--
derek
KWSchneider
Derek, Derek, Derek...
Knoweth whence you speak. Although many are Greek symbols, many more
were/are not ASCII. Arrows in four directions, an asterisk inside of
an "o", a box with 2 dots is NOT Greek. We needed a special APL
keyboard set...
From WikiPedia:
"In the mid 1970s, the IBM mainframe interpreter was even adapted for
use on the IBM 5100 desktop computer [which I used...], which had a
small CRT and AN APL KEYBOARD [emphasis mine], when most other small
computers of the time only offered BASIC."
Furthermore, my reference to hieroglyphics is particularly germane
considering the article written in 1991 in the IBM Systems Journal by
DBMcIntyre entitled "Language as an Intellectual Tool: From
Hieroglyphics to APL"
Kurt
Derek Broughton
> On Dec 23, 3:41 pm, Derek Broughton <de...@pointerstop.ca> wrote:
>> KWSchneider wrote:
>> > APL [from "A Programming Language"]. We used it off of our IBM 360 and
>> > 370 mainframes in 1971-73. Very powerful notational language with
>> > specialized characters. Especially strong in vector and array
>> > mathematics. Very cryptic to read [symbols looked like hieroglyphics -
>> > ie asterisk inside of an "o" - arrows in all directions].
>>
>> They were actually Greek. Not very hieroglyphic.
>> --
>> derek
>
> Derek, Derek, Derek...
>
> Knoweth whence you speak. Although many are Greek symbols, many more
> were/are not ASCII. Arrows in four directions, an asterisk inside of
> an "o", a box with 2 dots is NOT Greek. We needed a special APL
> keyboard set...
>
> From WikiPedia:
> "In the mid 1970s, the IBM mainframe interpreter was even adapted for
> use on the IBM 5100 desktop computer [which I used...], which had a
> small CRT and AN APL KEYBOARD [emphasis mine], when most other small
> computers of the time only offered BASIC."
Well, I confess to not having _touched_ an APL keyboard in 29 years, so I
may misremember, but I'm fairly certain there were no symbols on the IBM
Selectrics I was using that were not Greek. Yes, we had special APL
keyboards (more fun was actually trying to write C programs on an APL
keyboard), but I don't remember any of those.
--
derek
Charles Brenner
Half true, as many of the APL symbols were composed as overstrikes.
For example the circle that can be overstruck by any of \ | - * might
be called an omicron (though we never did). However, there are two
equilateral triangles, point up and point down, only one of which is a
Greek letter. The selectric type ball characters also must have
included the little T-character, upside down as well as rightside up,
a rectangle, and as Kurt mentioned four arrows.
Charles
Curtis A. Jones
...
> equilateral triangles, point up and point down, only one of which is a
> Greek letter. The selectric type ball characters also must have
> included the little T-character, upside down as well as rightside up,
> a rectangle, and as Kurt mentioned four arrows.
APL is great for reading, writing and thinking, but it's sure a pain
to dictate on the phone!
Curtis
Björn Helgason, j-programming
J has all the power of APL but it can easily be dictated over SMS or e-
mail.
Björn Helgason
wrote:
And while we are talking about bridge then I really like Wolfbridge.
It is totally free and it has great graphics and I like to be able to
sometimes show all the hands and replay.
AAsk
But,
- I don't know of any self-explanatory language nor of any language
that is 'seamingly' readable like prose ... and I program in VB, C#,
VBA etc
- the hyroglyphics are the keywords of APL just like "switch", "for",
"case" etc in other languages. Unlike other languages, APL allows you
to use any word as a variable or function name.
APL is a powerful language with its own unique features, just like any
other language - one tool in a chest of tools.
The one let down perhaps is that the APL keywords or hyroglyphics are
not visible/accessible any more -- in the good old days of IBM APL's,
the terminals had the APL symbols engraved on the keyboard. PC APL
vendors just seem to assume that every newcomer just knows where the
symbols are ... that assumption is wrong!
Morten Kromberg
> PC APL vendors just seem to assume that every newcomer just
> knows where the symbols are ... that assumption is wrong!
There is good news from anyone who agrees with Ajay: "Physical" APL
keyboards for US, UK and Danish keyboards will soon be available from
Dyalog (we're just ironing out some final production issues). The
price is not yet finalized, but it will be marginally more than a
normal "Cherry" keyboard. To pre-order, write to sa...@dyalog.com. We
need an order for about ten units to fire up another languages than
the three that we have already put into production.
Morten
P.S. The interest in these keyboards has so far been lukewarm at best.
This isn't just about "the vendors", there must be other other reasons
why most people don't seem to need the symbols engraved. Most modern
APL systems now come with various ways to help you locate the symbols
and most people don't really look at keyboards when they type,
anyway...
Björn Helgason, j-programming
In the land of the Unicode the APL symbols are just a tiny blimp in
the whole lot.
Doug White
c43c72...@k19g2000yqc.googlegroups.com:
I learned to touch type in APL a long time ago, at least for most of the
common characters. The folks who would find them useful are the
newcomers. I suspect it just points out the age-old problem that we need
more newcomers.
Also, I don't know how universal the key mapping is. I've always used
STSC/Manugistics/APL2000's APL. I'm trying to get my youngest daughter
interested in APL, and a keyboard would help. I'm starting her off with
APLSE, and I'd have to study the mapping to make sure it won't just make
things more confusing.
Doug White
Kenny McCormack
Doug White <gwh...@alum.mit.edu> wrote:
...
>Also, I don't know how universal the key mapping is. I've always used
>STSC/Manugistics/APL2000's APL. I'm trying to get my youngest daughter
>interested in APL, and a keyboard would help. I'm starting her off with
>APLSE, and I'd have to study the mapping to make sure it won't just make
>things more confusing.
Subject line fixed. Please try to do so yourselves in future.
Björn Helgason, j-programming
Curtis A. Jones
> APL: "write only" language with "hyroglyphics". Perhaps.
>
> But,
Ajay (& Björn),
I guess I needed more emphasis on the "APL is great for reading,
writing and thinking" in my note. What I saw in Charles Brenner's
struggle to identify the glyphs was a sign that he thinks visually.
He probably does math/APL in a part of his brain that might be a
little way from its verbal parts.
Curtis
AAsk
> writing and thinking" in my note.
No problem, Curtis.
The statement 'APL is unreadable' is just as true/untrue as 'APL is
the best language' etc.
The problem with readability is that it is directly related to one's
literacy and it is quite tempting to conclude that APL is unreadable
if one's literacy is limited. The hallmark of literacy is the ability
to translate: my own view is that I write better code in VB when
thinking in APL. Equally, it is possible to enrich APL when thinking
in C# etc.
First generation APL was probably the most readable of all programming
languages
- it denied the comfort of seeing familiar words like 'for', 'next'
etc (all of which had different meanings in programming than in their
English labguage context)
- the APL symbols transcends (spoken/written) language barriers.
Readability is also a function of what is acceptabale - for instance,
LINQ to Objects is perfectly acceptable/readable by the Dot Net
community.
Have a look at
http://www.scribd.com/doc/19525586/Linq-to-Objects101Samples-C-to-AplWin
If you do not have time to trawl through the whole article, it might
be worthwhile re-contemplating APL readability by looking at just one
LINQ example - LINQ98 Custom Sequence Operators.
APL fares rather badly: in my opinion, this is simply because it is
promoted as the #best# language by those who know it (all too often on
it) very well. This leaves everyone way, way behind.
APL is just one of the contemporary languages - in the right hands, it
has very strong credentials - capable of competing and winning.
Isn't it strange that none of the trends in programming - tier design,
oop etc or programming paradigms like agile, waterfall - are actually
objectively measurable? Is there a tool that can analyse code in any
language and conclude that it is n% OOP? I don't know of one. Is is
not an opportunity to propose APL as a language that is 'compliant'
with contemporary standards?
Fred.
In my opinion *no* programming language is readable. This is simply
because it is designed, as is appropriate, to instruct the computer
rather than describe the problem being solved. It adresses "how"
without ever touching on "what" or "why". All programs require
comments and external documentation if they are to be understood
rather than deciphered and reverse-engineered.
I'm on my soapbox because I'm currently trying to deal with a number
of systems where their implementers and documenters seem to think that
object property and method names are actually English nouns and verbs.
Fred.
Björn Helgason, j-programming
> The problem with readability is that it is directly related to one's
> literacy and it is quite tempting to conclude that APL is unreadable
> if one's literacy is limited.
If you get some code you do not understand it is often best to run it
in debug and then see what happens to or with the data going in and
out.
I find it important in any utility code that is often highly
specialized to do asserts on the data coming in so the functionality
will work correctly.
The real beauty of APL is the option to develop code in real time and
see what happens directly and then create one utility after the other
and with only a few lines in each do a lot.
If the code you write is very compact it helps to write some comments
and be sure to sprinkle some asserts around.
Morten Kromberg
> In my opinion *no* programming language is readable. This is simply
> because it is designed, as is appropriate, to instruct the computer
> rather than describe the problem being solved. It adresses "how"
> without ever touching on "what" or "why".
As it happens, this is not the case for APL... Despite the name, it
was "designed" as a rationalised mathematical notation for
communication between humans - describing sequences of algebraic
operations on arrays ("programming" in the mind of a mathematician,
not a software engineer). As far as I know, it was only implemented as
a "computer language" after several years of use on blackboards and in
academic papers. Of course, that adaptation did push APL a little way
in the direction of other programming languages... But the focus on
the "what" remains the reaon why those of us who consider ourselves
"APL Literate" find that APL code is FAR more readable and mantainable
than other programming languages: The APL code is often an order of
magnitude closer to the "what" than the "why" than you tend to see in
languages which were (essentially) designed to allow the efficient
implementation of compilers.
Of course, this depends on the "domain": One could describe APL as a
"domain specific notation" that happens to have a rather broad domain
(the "algebraic" manipulation of arrays, which is a "technique" which
happens to be applicable to a very wide variety of problems). But it
is an approach which is completely focused on the "what" - at least
until a shortage of memory or CPU cycles forces you to think about
practical issues.
The feeling that APL is "write only" is a sentiment that seems to be
expressed by people who have what I would call a "computer science"
focus, and have come to expect solutions to be expressed in terms of
"how". Early APL had no control structures, and this really did NOT
help people write readable code. I occasionally have to look at code
written in this style - a lot of it is still working - and it does
make me shudder. For about 20 years now, APL has had control
structures and for 5-10 years, some APL interpreters allow object
orientation. These additions allow good separation of the "problem-
oriented" code (where the array/algebra paradigm is superior) and what
I would call the "organizational" code (where a traditional
programming paradigm is sometimes more useful).
Also, some APL code probably suffers a bit from the fact that APL
naturally appeals to people with no formal software engineering
background - and that this sometimes leads to the writing of code of,
ah, questionable quality. But unreadable code can be written in any
language, and the fact that APL allows people with no formal IT
background to implement competitive applications is a STRENGTH, not a
weakness. Some successful APL-based companies have a "SWAT Team" to
help the domain experts beat important code into shape, to fully reap
the benefits of rapid (and correct) development.
Morten
P.S. The fact that APL focuses on the what doesn't mean that you don't
still need comments in the code - some things STILL need to be
explained :-)
Morten Kromberg
> The folks who would find them useful are the newcomers.
> I suspect it just points out the age-old problem that we need
> more newcomers.
No, there ARE quite a few newcomers, and even those of our customers
who regularly hire new APL developers have shown little interest in
the pysical keyboards. I think it may have something to do with
laptops, the fact that APL developers are now all over the world so
you need to combine APL with Russian and Chinese rather than simply
making do with a US keyboard, but also the fact that modern APL
systems come with all sorts of typing aids to help you locate APL
symbols or pick them off "palettes". See for example
http://www.dyalog.com/help/12.0/index.html
Morten
Fred.
What I said was with no intention of disparging APL where I have no
direct experience.
But, I still think my comment is accurate. A domain expert might
look at an application of Runge-Kutta, recognize the set of partial
differential equations behind the matrix manipulation, and thus figure
out the class of queing systems the progam was intended to analyse.
And that expert might even be able to do this quite quickly given the
way array operations map onto APL. But, this is not just reading.
This is very rapid reverse engineering.
And, where a problem is solvable by array manipulation, but not
normally accomplished that way, such as, say, compilation of code, the
solution would probably be baffling to most domain experts without a
fair amount of documentation.
Fred.
phil chastney
> On 26 Dec., 16:12, Doug White <gwh...@alum.mit.edu> wrote:
>
>> The folks who would find them useful are the newcomers.
>> I suspect it just points out the age-old problem that we need
>> more newcomers.
>
> No, there ARE quite a few newcomers, and even those of our customers
> who regularly hire new APL developers have shown little interest in
> laptops, the fact that APL developers are now all over the world so
> you need to combine APL with Russian and Chinese rather than simply
> making do with a US keyboard
even without that, making do with a US keyboard was never an ideal
solution -- some compromise is necessary between the traditional IBM
keyboard, and the keyboard engravings, and I prefer a mapping which
leaves all the engravings consistent with the keystroke seen by the
operating system -- this problem starts early with plus and minus
remapping a keyboard is not a big deal, and long ago, on my machine,
the Q was paired with quad, allowing L to be paired with lambda
I imagine it's an irritation to newcomers, much as fonts are, but try
recompiling an interpreter on a Windows machine, but without using the
Visual Studio library, and suddenly keyboards and fonts seem less
overwhelming
/phil
N.B: the bridge players have been removed from the address list
Morten Kromberg
<phil.hates.s...@amadeus.munged.eclipse.co.uk> wrote:
> even without that, making do with a US keyboard was never an ideal
> solution -- some compromise is necessary between the traditional IBM
> keyboard, and the keyboard engravings, and I prefer a mapping which
> leaves all the engravings consistent with the keystroke seen by the
> operating system -- this problem starts early with plus and minus
Indeed - the default keyboard for Dyalog APL is what has become known
as a "Unified" keyboard, where all the symbols that you see on a
"normal" keyboard give the symbol that "a user would expect" (I think
most APL systems adopted this type of keyboard layout 15-20 years
ago). So there is no longer a conflict between APL and the operating
system keyboard (the conflicts are now all with operating system and
application shortcuts like CTRL+A for "select all" versus "alpha").
AltGr (Ctrl+Alt) can be used as an alternative for CTRL, but the %#¤&
apps are starting to use AltGr-based shortcuts, too. Aaaaargh! :-)
Each of the engraved keyboards that we will be producing have all the
usual UK/US/DK keys in the usual place, plus additional APL symbols.
Morten Kromberg
> But, I still think my comment is accurate. A domain expert might
> look at an application of Runge-Kutta, recognize the set of partial
> differential equations behind the matrix manipulation, and thus figure
> out the class of queing systems the progam was intended to analyse.
> And that expert might even be able to do this quite quickly given the
> way array operations map onto APL. But, this is not just reading.
> This is very rapid reverse engineering.
I'm sorry, I don't understand this argument - in my mind, the
"traditional" code, consisting of lots of nested loops manipulating
scalars, which "build up to" the same array manipulation, requires
much more "reverse engineering". Surely, the code which is closer to
the mathematical statement of the problem can simply be "read" by
someone familiar with the domain? Perhaps I simply don't understand
the difference between "reading" and "reverse engineering" - perhaps
you can define it?
Would you consider reading a proof written in traditional mathematical
notation as an exercise in "reverse engineering"?
> And, where a problem is solvable by array manipulation, but not
> normally accomplished that way, such as, say, compilation of code, the
> solution would probably be baffling to most domain experts without a
> fair amount of documentation.
I'm not sure I understand this example, but of course APL programs
require documentation. In fact, they generally require far more
documentation "per line of code" than something written in a
traditional language, becuase you need far less code to solve problems
which fit well into the domain. Perhaps this is what you mean? But is
still seems like an advantage to me :-). To me, the fact that most
lines of code in a traditional language require no comment, is due to
the fact each individual line of code doesn't really DO anything...
AAsk
materialize, and there is no sign of it materializing soon) is that
APL is the language for domain experts. This is based on a completely
fictional/delusional premise.
Had it been true, there would today be
- market leading products for accountants, lawyers, engineers,
doctors, pharmacists etc; there are NONE.
The appeal of APL is that APL is the one language that is eminently
suitable for personal computing: you can code for results without any
knowledge or regard for machine requirements such as the processor,
memory allocation, threading, multi-tasking etc. etc.
Cost {becomes} quantity {times} price
irrespective of
- whether 'cost' is already in use
- price/quantity is a vector, scalar, or matrix
provided that price and quantity are of a dimension that makes the
{times} operation conformable.
Users learn what 'conformable' means as soon as they understand RANK
ERROR, LENGTH ERROR etc.
If I am not an APL coder, and I am not (or do not understand what that
means} a domain expert, with this claim, I will definitely be loathe
to even consider APL. On the other hand, if APL is one of the
contemporary languages, I would be foolish to eliminate APL without
giving it due consideration.
APL has enough stacked against it without piling on 'domain
espertise' (whatever it means) as a prerequisite.
Phil Last
I've never read anything in which it is used consistently.
There seem to be three different meanings:
* the vocabulary used in the business for which an application is
written
* a computer application which is written using that vocabulary
* a computer system which is capable of being used to write such an
application
More often than not two or all three meanings are confounded in the
one article.
I suspect that Ajay has noted the same inconsistency and has
transferred his disquiet to the apparently related term "domain
expert" which can hardly be more than an inflationary form of
"expert". If one is an expert ones expertise is presumably in some
domain or other.
Having denied that APL is the language for "domain experts" for the
unrelated reason that he can identify no "market leading products for
accountants, lawyers, engineers, doctors, pharmacists etc" he goes on
to show that APL is the ideal language for domain experts because it
is eminently suited to personal computing. That is, an accountant, a
lawyer, an engineer, a doctor, a pharmacist etc. can just sit down and
write his own system. He doesn't need a market leading product.
My first three posts in computing; all three in APL; were in
departments where the "boss" was a well qualified expert in his own
field. He was NOT an IT professional. Nevertheless the business of the
IT team was to maintain and enhance a bunch of systems originated in
APL by that very expert.
And I think you'll find it's still going on.
Morten Kromberg
> The ultimate, self-fulfilling claim (that has so far failed to
> materialize, and there is no sign of it materializing soon) is that
> APL is the language for domain experts. This is based on a completely
> fictional/delusional premise.
>
> Had it been true, there would today be
>
> - market leading products for accountants, lawyers, engineers,
> doctors, pharmacists etc; there are NONE.
"DOMAIN EXPERT" seems to be a label created by software engineers to
identify someone who is involved in a software project, but whose
primary expertise is not the construction of software. "Domain Expert"
is a convenient way to label these "project participants who are not
professional software developers". If you haven't noticed that
something like half the people who use APL are in this category (or at
least WERE in that category before they got involved in software
development), I don't know what part of the community you have been
inhabiting. Certainly, claiming that the recognition of this fact is
"delusional" is a pretty far out :-)
Since virtually all software products are created by professional
programmers, and virtually all the literature and training available
to domain experts trying to learn how to do their own development is
created by the same people, I can't quite see why the fact that most
of this work is done using "traditional tools" really says anything
about the nature of APL (other than that APL vendors have work to
do :-).
In fact, products like the ones you mention do exist for a variety of
technical and engineering problems, and various financial
applications, where teams have been skilled and fortunate enough to
build competitive businesses around ideas prototyped in APL. But as
companies grow, the number and influence of "domain
experts" (typically the founders of the company) fades, and by the
time you have a few dozen professional software engineers and
marketing folks on board, holding on to APL becomes increasingly
difficult. In fact, as the ability to build innovative products takes
a back seat to the normal pressures of running a successful /
competive business, the organization comes to view reliance on the
domain experts as a threat to the stability of the company rather than
a benefit. In some areas, typically in finance, the ability to
innovate remains obviously critical to key decisionmakers. Only a few
companies are able to successfully manage these stresses, but these
company tend to be VERY competitive and we are certainly very proud to
be involved with them at Dyalog.
As markets generally get more competitive and more industries
recognize the value of having the so-called domain experts involved in
the development process in more fields (this is one of the key ideas
in the "Agile" development methodology), we think that the use of APL
is going to grow (if APL developers and vendors play their cards
right).
The APL vendors definitely have work to do... Making APL appeal to
"professional programmers" or at least "decision makers" is an
important part of this work. In particular, APL needs to integrate
better with other tools. But at the core, it has to remain a tool
which allows the "person whose expertise lies in a different domain
than software engineering" to solve problems effectively.
AAsk
> The APL vendors definitely have work to do...
I agree with the above statement.
I am far from convinced that casting a 'domain expertise' shadow (or
glow if you prefer) over APL is tantamount to taking steps in the
right direction. After all, APL is the one language where you can code
solutions without even remotely being 'a software engineering' domain
expert albeit such solutions are rarely sustainable beyond the
timespan when the original coder(s) is/are actively involved ...
unless some software engineering principles are adhered to. That is,
unless a non-domain expert (or mere programmer) can maintain/enhance
the original application, it is dead.
Morten Kromberg
> I am far from convinced that casting a 'domain expertise' shadow (or
> glow if you prefer) over APL is tantamount to taking steps in the
> right direction. After all, APL is the one language where you can code
> solutions without even remotely being 'a software engineering' domain
> expert
This is precisely why it allows experts from "other" domains to become
programmers. You have me totally confused now, you seem to be agreeing
with me(?). If your point is that you don't think it is good marketing
to cast APL as a language for "domain experts", that is a different
question. Based on my experience, I happen to think that it is: Trying
to sell APL as a general tool for software engineers is very hard, as
they have been trained for a decade to believe that many of the key
ideas in APL are wrong, and only a tiny fraction of them are
sufficiently open-minded to break free. Show APL to "domain experts"
and they tend to love it. We need to help them address the various
practical and organizational problems that they face.
> albeit such solutions are rarely sustainable beyond the
> timespan when the original coder(s) is/are actively involved ...
> unless some software engineering principles are adhered to. That is,
> unless a non-domain expert (or mere programmer) can maintain/enhance
> the original application, it is dead.
There is some truth in this - but when I look at our customer base,
the average age of APL-based applications (which are still actively
maintained) is typically measured in decades. One of the significant
problems that our customers face is precisely that the original coders
want to retire and they need to keep ancient applications running.
After decades where one or two people have kept an application alive
without the full support of the organization, it becomes a problem to
replace them (insufficient documentation, no apprentices). This leads
some organizations to identify APL as the cause of the problem and
replace it by technologies which are an order of magnitude more
expensive and very much less capable, when in fact the problem is a
rather simple organizational issue and could have been solved by
adding a small amount of additional resource. In fact, professional
maintenence of APL applications is simple and cheap, but requires
commitment both by the organization AND the original authors. Most
current organizations lack the insight to do this, but it isn't hard.
In practice, applications written in APL seems to be some of the
longest-lived pieces of software. They often started on mainframes,
were ported to Unix and then to Windows, where they are still actively
developed because they are business critical. So in reality, APL
applications appear to be some of the most "maintainable" applications
around. I believe that this has a lot to do with 1) the readability
(to the people who matter) of the code and 2) the level of
abstraction / decoupling from any particular hardware of software
paradigm. These features are often used AGAINST APL by "software
engineers", but in practice, they often deliver ENORMOUS value.
So much for the notion that APL is a "write only" language :-)
AAsk
> You have me totally confused now, you seem to be agreeing with me(?).
I wonder! Is this a case of 'fools seldom differ' or 'birds of a
feather flock together'!
Perhaps, this sort of things simply happens.
> Trying to sell APL as a general tool for software engineers is very hard, as
> they have been trained for a decade to believe that many of the key ideas in APL are wrong,
> and only a tiny fraction of them are sufficiently open-minded to break free. Show APL to "domain experts"
> and they tend to love it. We need to help them address the various
> practical and organizational problems that they face.
APL *IS* not only a general tool for software engineers but is also
just one of many tools that are much better supported and more
visible.
Why do domain experts love APL? Historically, with a personal computer
with APL on their desk, these experts produced solutions. Good. But
how did they do that? Mostly, they took great delight in taking
control, removing bottlenecks and they also ignored all the other
disciplines relating to software development/maintenance. They forgot
that they are replaceable, that it is someone else that is holding the
purse strings and failed to notice those they antagonised in the
process. In order to untie the knots, others (decision makers or in
APL jargon, 'free riders') need to be involved: this is not an option.
Why? Because domain experts, indispensible as they are do move on -
they are promoted or retire or fall ill, or die or simply leave the
organisation. The organisation can replace the expertise but not the
mindset of the leaver. A sustainable application is one that can be
maintained by a mere developer, un-endowed by any expertise except
those relating to software engineering.
> In practice, applications written in APL seems to be some of the longest-lived pieces of software. They often started on mainframes,
> were ported to Unix and then to Windows, where they are still actively developed because they are business critical.
I have witnessed this precise scenario very very often. Another
outlook is that it is precisely because such applications are business
critical that they catch the attention of 'higher' managers. No one
wants to risk everything to the single point of failure that closely
guarded (mysterious) applications entail. APL applications need to
demonstrate that they can not only observe but implement the software
development/maintenance rules that other tools *appear* to abide by.
> So much for the notion that APL is a "write only" language
I think this is more a reflection of the reader than of what they are
reading and APL is just a unreadable as Visual Basic or C#: being able
to see English like words and then prematurely concluding that code is
readable is just folly but reality, nonetheless.
APL & its vendors must abide/collaborate to reap success.
Björn Helgason, j-programming
In a way it is a bit so that you do agree on most aspect of why APL is
a good tool for the person making the application and that it is good
at solving problems.
What happens with that application afterwards is where it differs.
It is the famous half glass of water.
Do you see it as half full or half empty.
It is a fact that for the people who like APL then it is very powerful
and a very good tool.
It is also a fact that quite a few of computerpeople do see APL as a
problem.
We can probably most of us agree that we do not understand why some
people do not like APL or as it seems hate APL intensely.
I have seen many instances where APL and APL products have solved
problems and with marginal effort been the solution to situations
where computerpeople had been spending a lot of effort trying to
solve.
The people using languages other than APL have felt humiliated and
become APL haters rather than embracing APL as their tool.
Why that is I have no idea even if I suspect that it may have to
jealousy and similar feelings.
Lack of possibility to understand APL etc.
I learnt and started to use APL long before PC and Lotus and such
tools.
I would have loved to see APL get similar attention and interest as
the spreadsheets got on the PC.
APL is great at solving problems and manipulating matrixes in
multidimensions.
Doing simple things in two dimension like in a spreadsheet APL can
also do of course but APL has never been as simple to get input to and
present the results as most spreadsheets.
On the other hand APL is compared to computerlanguages taking one
character at a time and doing something trivial with it.
So we are constantly comparing apples and oranges as well as bananas
and always when people ask can you do this or that then proponents of
APL (me included) we always answer yes we can do that.
We say that we can let APL mix with other languages and communicate
with spreadsheets.
Factum is that APL should be a platform for spreadsheets and the most
succesful spreadsheet in the world used by millions of people should
be written in APL.
There are a lot of spreadsheet programs written in APL but they are
not the most succesful spreadsheets in the world.
I bet most of use have written a spreadsheet or two or many but they
never made it in the big time.
It is really amazing to be interested in APL and still be wondering
about the success or not of APL after 37 years.
It is similar to the success of *nix against other systems.
I am always amazed that *nix systems are not considered "better" by a
lot of PC users.
I look at the statistics of c.l.a and think maybe next year will be
the year that APL takes off and possibly *nix will become the
operating system of choice.
Another thing besides the spreadsheet is how APL was not participating
enough in/on the web.
Unicode is another area that APL will benefit from.
Lets hope that APL will get a boost next year and years to come from
utilizing the web,wiki,Unicode and be the spreadsheet of choice.
J is coming on strong with web applications and has excelent grid
facilities and many other APL dialects have the potential to becoming
the product of the year (or years to come) next year.
So happy new APL year.
Stephen Taylor <editor@vector.org.uk>
> The ultimate, self-fulfilling claim (that has so far failed to
> materialize, and there is no sign of it materializing soon) is that
> APL is the language for domain experts. This is based on a completely
> fictional/delusional premise.
>
> Had it been true, there would today be
>
> - market leading products for accountants, lawyers, engineers,
> doctors, pharmacists etc; there are NONE.
>
> The appeal of APL is that APL is the one language that is eminently
> suitable for personal computing: you can code for results without any
> knowledge or regard for machine requirements such as the processor,
> memory allocation, threading, multi-tasking etc. etc.
Goodness me. For a moment I thought I was reading about Excel.
Stephen
Björn Helgason, j-programming
It is really amazing that we do not have a good APL spreadsheet with
Excel like inputs and outputs of results like reports and graphs.
AAsk
>
> > Stephen
You might have been! Excel is one of the other tools i.e. one that APL
has to compete with.
Incidentally, Excel makes no claim for domain experise as any kind of
prerequisite but caters for mathematicians, accountants etc with the
added advantage that it beats APL hands down when it comes to data
presentation.
> It is really amazing that we do not have a good APL spreadsheet with
> Excel like inputs and outputs of results like reports and graphs.
>
Classic hallmark of the APL mindset (let's re-invent it in APL): why
do it all in APL? No one else (non APL person) will be convinced
simply because of the pedigree of Excel.
ALL of the Excel functionality is available to APL,(APLX, Dyalog and
especially APL+Win - I have no experience of APL2) via COM today, now.
APLX has built-in graphs, without the overhead of COM.
Ibeam2000
> I've never read anything in which it is used consistently.
> There seem to be three different meanings:
> * the vocabulary used in the business for which an application is
> written
> * a computer application which is written using that vocabulary
> * a computer system which is capable of being used to write such an
> application
One of my clients, who until recently used APL heavily in an area
where it was historically strong, is committed to and is migrating to
Java. Corporate mandate, just do it. Watching from a distance, it
looked to me that nine women really can produce one baby in a month.
Well, maybe a few more than nine.
See http://despair.com/achievement.html
Be that as it may, the vast bulk of the code dealt with the usual
stuff, GUIs, reporting, data base access, and so on. But in
anticipation of an eventual migration to a less hospitable language
and environment, the computational kernel of the application had been
rewritten earlier in a simple single assignment and scalar style. The
idea was that the code could be easily, if not mechanically, rewritten
to work in the target language.
At first, it didn't quite work that way. The Java technologists,
having studied object orientation, proceeded to rewrite it in an
object oriented manner. The end result was a code base which was no
longer simple to verify and debug - previously, one could step through
the procedure and at least view the intermediate results of the
calculations. Now the individual calculations were strewn through
countless objects and interfaces and classes and things, where code
navigation was far more difficult than the problem itself.
Later, the computational code became the basis for a "Domain Specific
Language", definition #2 above, with the added requirement that Java
code be generated. This approach is far more promising, at least we
get the right answer.
From what I have seen, this Domain Specific stuff, be it modeling or
languages, is a clear admission that Java, C#, etc. are not exactly
tools of thought. I'm not sure whether this means anything at all for
the APL community. It seems that we have been doing domain specific
languages for over 40 years now, without any fanfare or moniker.
As for the "Domain Expert", I would think this is also an inflationary
form of "Analyst". Back in the 1970s, newspaper job postings were
often for a "Programmer" or "Analyst". Remember also that the
language back then was usually COBOL or PL/I. Until fairly recently
there was far more diversity in computing, where one would see job
postings for "Programmer/Analyst". Java changed all that, an
immersion in Java for a developer is so deep that there can be no
reason, time, or opportunity to acquire much domain knowledge. In our
group, most of the chatter is about low level details of Java coding
(exception handling, data base persistency, etc), and little having to
do with domain knowledge. We've had our level of abstraction lowered
and see we are back in the stone age.
Domain Specific Modeling, to me, albeit quite imprecise, albeit faint,
is a breath of fresh air.
Ted Edwards
> APL is great for reading, writing and thinking, but it's sure a pain
> to dictate on the phone!
> Curtis
Not so. Back in the 70's we wanted to use some of my packages to test
out a new APL system which did not yet have comunications. I sat in one
city and read from function displays (over the phone) to a colleague
(who could touch type APL) sitting at one of our computers in another
city. I didn't even need to speak particularly slowly.
Ted