APL Product Prices
Ken Iverson
On 10 May 1998 12:23:42 Greg Heil wrote:
>If there is a strong need for the APL character set, i am
>sure it would not take that much effort to put together an
>interface gloss...
One such "gloss" has been provided in the J system by a script
that assigns names to primitives. For example:
Transpose=: |:
Cut=: ;.
Word_formation=: ;:
Nub=: ~.
Rank=: "
Do=: ".
Format=: ":
Infinity=: _
Because of apparent lack of use (and of notice in discussions
such as this) this script has not been expanded since 1994.
I would appreciate comments on the utility of a revision.
Björn Gosi Helgason
From: Ken Iverson <k...@INTERLOG.COM>
>One such "gloss" has been provided in the J system by a script
>that assigns names to primitives. For example:
>
> Cut=3D: ;.
> Word_formation=3D: ;:
> Nub=3D: ~.
> Rank=3D: "
> Do=3D: ".
> Format=3D: ":
> Infinity=3D: _
>
>Because of apparent lack of use (and of notice in discussions
>such as this) this script has not been expanded since 1994.
>I would appreciate comments on the utility of a revision.
>
Like so many other good things in J - that simply work - they
suffer from lack of mentioning - not use.
I for one use these kind of things all the time. Some are my own=20
some from J utilities.=20
I find that the code becomes much more easily readable using=20
words. Mind you I very often use Icelandic variations of these=20
words so I am not sure how many others would benefit from=20
my dictionary or glosses.
Hlidrun=3D: |:
Skipta=3D: ;.
Ord=3D: ;:
An=3D: ~.
Gildi=3D: "
Gera=3D: ".
Forma=3D: ":
OENDANLEGT=3D: _
To me it does not matter if there is much code or little behind
those names. The primary intention is that they work and in=20
J the idioms and utilities they tend to work. Even my own
utilities seem to work most of the time.
A typical start of a session for me is to require a few utils
like:
0!:0 <'user/myutil/myutil.ijs'
0!:0 <'user/thyda/thyda1.ijs'
require'files'
US=3D:fread'c:\j401beta\user\thyda\axsysus.ald'
IS=3D:fread'c:\j401beta\user\thyda\axsysis.ald'
IFS=3D:fread 'c:\j401beta\user\thyda\axifs.ald'
require'convert'
require'misc'
USC=3D:(av 64) chop US
ISC=3D:(av 64) chop IS
IFSC=3D: chop IFS
out 0{ISC
So the utils fread, av, out and chop are the first=20
and most important utils when I start to look at something.
I do not care if there is one char or more behind the word
I use as long as it does what I want. I usually do not write
fancy one-liners unless I want to play with something. Once
I set it to work in a system I place the code into words or=20
glosses.
And looking at the subject title then the price of J has never
been a problem either.
/Gosi
Greg Heil
Ken Iverson wrote:
> On 10 May 1998 12:23:42 Greg Heil wrote:
> >If there is a strong need for the APL character set, i am
sure it would not take that much effort to put together an
interface gloss...
> One such "gloss" has been provided in the J system by a script
that assigns names to primitives. For example:
> Transpose=: |:
> Cut=: ;.
> Word_formation=: ;:
> Nub=: ~.
> Rank=: "
> Do=: ".
> Format=: ":
> Infinity=: _
> Because of apparent lack of use (and of notice in discussions
such as this) this script has not been expanded since 1994.
I would appreciate comments on the utility of a revision.
What i was actually suggesting (and which might raise the
comfort level more for those with the greek symbols hardwired
in their fingers, was a keyboard mapping - one which is hard to
illustrate with my meagre knowledge of how to manipulate ISO
character sets;) -- but here goes: instead of "transpose" i
meant {transpose} - the single character "o backspace /" etc.
The question, to me, is would folks want the new J
approximation or would they want the transliterated J
to work like the old APL, eg wrt using cells rather than
items... For myself i like the new meanings and would be
happy with simply the old symbols on the new meanings,
making this a purely cosmetic gloss.
Using unicode one presumably could mix many symbol sets freely.
Thus paving the way for many layers to suit many preferences.
<tangent scale=wild>
Personally i would like to see the end of the mechanical tyrany
imposed by the Gutenberg revolution and a return to a more
poetical hieroglyphic style. This will require more than just
unicode though, we will have to trash the keyboard too. That
tech is still not here, yet.
</tangent>
greg heil
mailto:gh...@acm.org or remove no-spam from reply-to...
http://www.scn.org/tl/anvil
David Ness
My fingers are able to reproduce the old APL keystrokes. My eyes even eventually got trained to
recognize the radical sign as rho and the capital-Gamma as small-iota. So, word `gloss' always
proves to me to be attractive for just about 15 mins. I think I am going to need it, but very
rapidly I fall into new habits and the need goes away.
It seems to me that the `problem' with J, if there is one, is making new users comfortable with it,
rather than accomodating old APLers. Given the rate at which new APLers are likely to be created
(vanishingly small?) the `conversion' market is likely to remain small, and time and effort spent
tackling new domains is likely to be of higher yield than time spent allowing my old fingers to
retain their old habits...
Björn Gosi Helgason
CLAB =3D. 300000
CPROG =3D. 100000
CDOC =3D. 200000
CTOT =3D. 10 * CLAB + CPROG + CDOC
SPRICE =3D. 1500
SCOPY =3D. 1000000
STOT =3D. SCOPY * SPRICE
STOT
1500000000
CTOT
6000000
STOT > CTOT
1
=20
/Gosi
David Liebtag
Bjorn,
For those of us who are dense, could you add some comments to explain
your formulas?
Thanks.
Regards,
David Liebtag
IBM APL Products and Services
Andrei Kondrashev
1. Pricing.
Lowering the price will not make any better for APL. Moreover, I would
pay 2-3 times more for a system that would allow REALLY compete with
C++. Currently DyalogAPL and APL2000 are both priced rigth.
2. Book.
Useless idea. People who make decision what software to use and how
much to pay for that don't read books, even if it is packed with CD
with transparent and virtual APL compilers and interpreters (see
Timo Laurmaa classification in QQ).
3. Promotion.
There is much more simple and effective way of promoting APL. It is
necessary to target the right people. It cost money, but it will
work (if will) much faster and more effective than any, even a very
good book. The algorithm:
- buy space in WSJ, Financial Times, PC Week, and so on: only publications
that IT managers are reading (money could be collected from APL
community - "APL promotion fund", or something like that);
- ask "Happy Eric" to write one of his success stories;
- buy a reporter to write "an independent" article on the same subject;
- do it often enough.
Examples of similar actions that successfully pushed useless products:
PowerBuilder, BPCS, Java.
4. Technical.
Good and maybe the only way to attract new people is distributing
something like TryAPL2. It was a nice try by IBM, but unfortunately
the system was so ugly, that many people said "Thanks. We tried.
No more APL, please." In fact, TryDyalogAPL or TryAPL2000 should be
BETTER looking and packed with more applications that a "normal"
version. Of course, it should not allow to deliver any commercial
applications, which can be achieved simply enough: it might be
enough just to limit the workspace size and cut off some system
features like []NA, for example. It could help to promote APL in
schools and univiersities. This is completely up to vendors.
If they don't want this, there is nothing that any third party even
should try to do. Distributing dead free software with limited functionality
will have an opposite effect.
AVK
Brent Rowell
Text is hardly something wonderful for typist illiterates ... like most
programmers
Brent
Ken Iverson wrote in message <19980511.1...@sol.sun.csd.unb.ca>...
Jan Karman
Andrei Kondrashev wrote in message <6j9v6n$cpc$1...@inet-1.pnu.com>...
>1. Pricing.
>2. Book.
>3. Promotion.
> There is much more simple and effective way of promoting APL. It is
> necessary to target the right people. It cost money, but it will
> work (if will) much faster and more effective than any, even a very
> good book. The algorithm:
>
>4. Technical.
All of the [snipped] agreed
+
5. (or rather 0.) Build a network with the people in charge, nestle in
their parties, design delies for their wifes in pink wrappings, and - if
they don't mind - solve their problems.
I'm just am amazed that "we" bother.
Why didn't we solve (or prevent) the millennium stuff? A really big
opportunity !!
(One could scan with a mere 20 APL lines tens of thousands of COBOL source
lines, including nasty REDEFINES, in just a few hours)
Do I see 64-point headings in the papers : APL-ers solved the Y2K?
Murray Eisenberg
Ken Iverson (k...@INTERLOG.COM) wrote:
: One such "gloss" has been provided in the J system by a script
: that assigns names to primitives. For example:
: Transpose=: |:
: Cut=: ;.
:
: ... Because of apparent lack of use (and of notice in discussions
: such as this) this script has not been expanded since 1994.
: I would appreciate comments on the utility of a revision.
I'm one of the guilty parties who simply forgot that that script was
provided, for otherwise I would have recommended it to my beginning J
students. As it is, I made up names for some primitives that my
students adopted, and they themselves made of names for others on
their own.
Where this script is mentioned in the documentation -- and right now I
cannot readily locate this mention -- I seem to recall a (strong?)
suggestion that the user would want to abandon the names defined
therein for the actual primitive spellings. I am curious about the
reason for that suggestion.
On a related note, this time teaching J I taught explicit definition
using the forms
vname=: verb define vname=: dyad define vname=: monad define
(and similarly for adverbs and conjunctions); I don't think I'll ever
again teach the primitive 3 : 0 form. Likewise, for the supplied verb
"names" verb, I taught the form
names verb
rather than names 3. My reasons: I dislike "magic numbers" in
programming. In these cases, I teach what (J) verbs are, so why not
call such a creature "verb" rather than "3"? And in my own
programming I find it much quicker to see, say, that an explicitly
defined verb is intended to be used dyadically by seeing "dyad" right
at the top of the definition -- instead of having to examine either
comments or scan the definition to find a colon. (What about
ambivalent verbs? For them I reserve the phrase "verb define".)
--
Murray Eisenberg Internet: mur...@math.umass.edu
Mathematics & Statistics Dept. Voice: 413-545-2859 (W)
University of Massachusetts 413-549-1020 (H)
Amherst, MA 01003 Fax: 413-545-1801
Björn Gosi Helgason
From: "Jan Karman" <kar...@knoware.nl>
> Why didn't we solve (or prevent) the millennium stuff? A really big
> opportunity !!
> Do I see 64-point headings in the papers : APL-ers solved the Y2K?
If you can show how to prevent the millennium BIOS problems with the PCs =
with
some simple APL programs then you will surely become very famous.
Björn Gosi Helgason
From: Andrei Kondrashev <ma...@some.net>
>=20
> 1. Pricing.
> Lowering the price will not make any better for APL. Moreover, I =
would
> pay 2-3 times more for a system that would allow REALLY compete =
with
> C++. Currently DyalogAPL and APL2000 are both priced rigth.
It is all a question of what you want to do.=20
J can effectively REALLY compete with C++ in very many cases.
There are a few cases when J can not compete with C++ but in those
cases a combination of J and C++ is the answer.
> 2. Book.
> Useless idea. People who make decision what software to use and =
how
> much to pay for that don't read books, even if it is packed with CD
> with transparent and virtual APL compilers and interpreters (see
> Timo Laurmaa classification in QQ).
That is too much of a generalization and to begin with then no idea is
useless. Writing books helps. Putting glossy covers on packages and
putting programs and utilities on CDs and making sure they look nice =
helps.
> 3. Promotion.
> There is much more simple and effective way of promoting APL. It =
is
> necessary to target the right people. It cost money, but it will
> work (if will) much faster and more effective than any, even a very
> good book. The algorithm:
> - buy space in WSJ, Financial Times, PC Week, and so on: only =
publications
> that IT managers are reading (money could be collected from APL
> community - "APL promotion fund", or something like that);
> - ask "Happy Eric" to write one of his success stories;
> - buy a reporter to write "an independent" article on the same =
subject;
> - do it often enough.
> Examples of similar actions that successfully pushed useless =
products:
> PowerBuilder, BPCS, Java.
Here you are a bit in contraction with your point 2.=20
> 4. Technical.
> Good and maybe the only way to attract new people is distributing
> something like TryAPL2. It was a nice try by IBM, but =
unfortunately
> the system was so ugly, that many people said "Thanks. We tried.
> No more APL, please." In fact, TryDyalogAPL or TryAPL2000 should =
be
> BETTER looking and packed with more applications that a "normal"
> version. Of course, it should not allow to deliver any commercial
> applications, which can be achieved simply enough: it might be
> enough just to limit the workspace size and cut off some system
> features like []NA, for example. It could help to promote APL in
> schools and univiersities. This is completely up to vendors.
> If they don't want this, there is nothing that any third party even
> should try to do. Distributing dead free software with limited =
functionality
> will have an opposite effect.
You are contradicting yourself in this point. First you are suggesting
that vendors should distribute stripped down free applications and
then you say that it does not work and will have the opposite effect.
J tried for a little while some years back to have separate runtime =
version
but now you get a complete version to distribute for free. All you need
is a code to make it active if you want to use the studio.
You even get a free trial code which works with the studio
for a few weeks. Then you can apply and pay a humble price to get a=20
full license. This scheme is working and working very well.
So instead of try to invent the wheel once again people might want to=20
look at J and see a really successful product in every sense and learn.
So the solution is there right in front of our eyes.
Look at www.jsoftware.com for the complete story.
/Gosi
charles...@invision.iip.com
In article <6j9v6n$cpc$1...@inet-1.pnu.com>,
Andrei Kondrashev <ma...@some.net> wrote:
> 3. Promotion.
. . .
> Examples of similar actions that successfully pushed useless products:
> PowerBuilder, BPCS, Java.
>
Careful.... I would guess you haven't actually used PowerBuilder. I have for
several years, and find it quite a powerful product. High level of
abstraction for database handling factilities, originating from the
"Datawindow" object (i.e. a killer app. idea). Cross platform and easily
portable between PC, Unix, Mac. Easy GUI painting for design. Interactive
debugging of object scripts, with examination of intermediate results
possible. Complete on-line manuals. Good marketing. $2,000 or so per seat,
no bothersome run-time or server licensing. Can interface easily with other
important commercial products: all commercially viable databases, source
code control systems, other GUI tools, etc. Easy to get started, can learn
more as you go. Hmm, ...interesting parallels with APL. But no accident
that this is a successful product.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
Jim Russell
Ken Iverson wrote:
>
> Because of apparent lack of use (and of notice in discussions
> such as this) this script has not been expanded since 1994.
> I would appreciate comments on the utility of a revision.
I, for one, for would love to see an updated (or the original, for that
matter) set of "official" name definitions. If possible, organized by
part of speech, and including duplicate definitions with unique names to
distinguish the monadic and dyadic cases.
Jim Russell
charles...@invision.iip.com wrote:
> ... High level of
> abstraction for database handling factilities, originating from the
> "Datawindow" object (i.e. a killer app. idea).
It seems you know something I missed completely. As of PB 4.0, my
biggest complaint was the almost obscene coupling between the datawindow
and the database. I had seen only promises about what might be done in
PB 5, but although it was promised, I could never see an obvious way to
decouple the gui from the database, e.g. with business objects in an
application tier.
Of course my other big complaint with PB (and VB and most other RAD
tools) is that until recently, OO techniques were reserved to the tool
designers (and objects were limited to gui widgets and such), but the
developer was unable to design or implement a real OO application.
Can you bring me up to speed re "high level of abstraction"?
charles...@invision.iip.com
I'm not sure what happened to my post from yesterday -- didn't make it into
the APL-L batch for last night 5/14, but a subsequent comment on my post did
make it in the batch.
(Did there used to be a way to send E-mail for the nightly batch instead of
going directly to everyone?)
Anyway, here is my post from yesterday again + comment + reply.
================
In article <6j9v6n$cpc$1...@inet-1.pnu.com>,
Andrei Kondrashev <ma...@some.net> wrote:
> 3. Promotion.
. . .
> Examples of similar actions that successfully pushed useless products:
> PowerBuilder, BPCS, Java.
>
Careful.... I would guess you haven't actually used PowerBuilder. I have for
several years, and find it quite a powerful product. High level of
abstraction for database handling factilities, originating from the
"Datawindow" object (i.e. a killer app. idea). Cross platform and easily
portable between PC, Unix, Mac. Easy GUI painting for design. Interactive
debugging of object scripts, with examination of intermediate results
possible. Complete on-line manuals. Good marketing. $2,000 or so per seat,
no bothersome run-time or server licensing. Can interface easily with other
important commercial products: all commercially viable databases, source
code control systems, other GUI tools, etc. Easy to get started, can learn
more as you go. Hmm, ...interesting parallels with APL. But no accident
that this is a successful product.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
===================
=====================
By abstraction I meant exactly what you call "almost obscene", which I see as
an advantage -- PB DataWindows let you deal with databases as objects, hiding
lots of messy details and adding functionality, analogous to APL array
operations hiding lots of messy looping. Alternatively or in addition, you
can imbed SQL in PB object scripts if you wish to perform particular database
mechanics. PB window objects let you design GUI windows w/o any database
coupling, i.e. you don't have to put DataWindow objects on Windows objects.
I'm not sure PB is suited by itself for a business objects style design. I
don't have much experience with that... I think that might involve a lot more
hand-coding or using a higher-end (and more expensive) tool such as Forte.
PB can make calls to external code and does offer some interfaces for
managing its objects. The PB scripting language (BASIC style) is indeed
oriented towards using objects and widgets rather than doing full-blown OO
itself. It can extend to manipulating other tools's objects, such as VB's.
But for GUI-database-cross-platform-RAD-client/server-other-buzzwords I have
found PB to be a super tool.
Greg Heil
David Ness wrote:
> My fingers are able to reproduce the old APL keystrokes. My eyes
even eventually got trained to recognize the radical sign as rho
and the capital-Gamma as small-iota. So, word `gloss' always
proves to me to be attractive for just about 15 mins. I think
I am going to need it, but very rapidly I fall into new habits
and the need goes away.
Quite true from a tactical perspective of getting the immediate
job done. But some languages eg
> PERL, TeX, PostScript, ... APL...<snipped to below>*
seem to be recognizing that the shape of the language and the
conciseness of expression and the ability to compose novel
expressions by juxtaposition can be an amplifier and focuser
for the mind.
> It seems to me that the `problem' with J, if there is one, is
making new users comfortable with it, rather than accommodating
old APLers. Given the rate at which new APLers are likely to be
created (vanishingly small?) the `conversion' market is likely
to remain small, and time and effort spent tackling new domains
is likely to be of higher yield than time spent allowing my old
fingers to retain their old habits...
New growth is indeed the best place to focus. what interests
me is the territory computing will be entering with the arrival
of essentially unlimited charactersets, the obsolescence of the
keyboard, and our growing understanding of compositional forms.
We live in a 3 dimensional world. Which, as we know from graph
theory, allows arbitrary connectivity. Yet our language models
are wedded to a 1 dimensional typology which leads to a natural
constraint of two arguments. Other arguments must be "parachuted"
in with references, boxing etc.
Can we design, finally, a language that really takes advantage of
our visual systems 2.5D understanding? Suppose we had some
conventions, in the form of macros (ala TeX), that created accented
characters from adverbial forms or that expanded conjunctival
forms to extra lineal associative patterns...
Past attempts at visual languages have been miserable failures
perhaps due to technology issues or perhaps due to chicken
and egg issues. Or perhaps they had nothing to say... Does APL?
>*... has the added burden that its underlying `model' (vectors,
matricies, ...) is intellectually challenging as well. It seems
to me that this is simultaneously the source of its strength and
its great weakness.
Compositional forms, manipulation of collections and notational
elegeance all take a toll on our cognitive abilities. This could
be a transitional problem, until the issues are fully understood
and resolved. Either way, it is a mountain that deserves climbing.
stevan apter
You can do paper and pencil experiments here, by adapting Peirce's
notational device for multivalent application.
Let f be a function of, say, four arguments. Write f applied to a, b,
c, d by writing "f" followed by four dots:
f . . . .
and then connect the a, b, c, d blobs (written anywhere on the "sheet")
to the f dots by "lines of identity". The dots have to be regarded as
part of the name.
You need an algoithm for evaluating the "sheet" -- the space containing
all canonical objects (e.g. f, 2, "abc") and all expressions (e.g. 2+2,
f a b c d). Evaluation consists of reducing all expressions to
canonical objects.
Order obviously matters, and the notation must be rich enough to express
the idea that e is evaluated before f.
Here's a reference: Don Roberts, _The Existential Graphs of Charles
Sanders Peirce_. I doubt it's still in print.
I agree that this is an interesting research topic.
Greg Heil
stevan apter wrote:
> You can do paper and pencil experiments here, by adapting Peirce's
notational device for multivalent application.
> Let f be a function of, say, four arguments. Write f applied to a, b,
c, d by writing "f" followed by four dots:
> f . . . .
> and then connect the a, b, c, d blobs (written anywhere on the "sheet")
to the f dots by "lines of identity". The dots have to be regarded as
part of the name.
and references, a...d, standing in in linearizations of the notation.
Developing a 1.5D notation (on the order of mathematical notations)
which can be lifted to 2-3D illustration with computer assistance
would seem a fruitful approach. Relying to heavily on ball and stick
models has been a problem with the visual languages i have seen.
Their linear forms have not had the density available in APL's.
> You need an algoithm for evaluating the "sheet" -- the space containing
all canonical objects (e.g. f, 2, "abc") and all expressions (e.g. 2+2,
f a b c d). Evaluation consists of reducing all expressions to
canonical objects.
> Order obviously matters, and the notation must be rich enough
to express the idea that e is evaluated before f.
in what frame of reference? Our understanding of the universe
itself has limitations there;) Was Pierce interested in computation,
or causality, or just logic? Is order of execution implementation
dependent in the APLs?
> Here's a reference: Don Roberts, _The Existential Graphs of
Charles Sanders Peirce_. I doubt it's still in print.
$36 at http://www.degruyter.de/catalog/8510.html
alternatively, from http://wwwcatsic.ucsc.edu/~ltam190c/sbquery.html
For information on Peirce's graphic logics see "The
Existential Graphs of Charles S. Peirce" by Don D. Roberts,
Mouton, Hague, 1973, and "The Existential Graphs" by Roberts,
in "Semantic Networks in Artificial Intelligence", Fritz
Lehmann, Ed., Pergamon Press, Oxford, 1992 or in "Computers
and Mathematics with Applications", v.23, no.s 2-9, 1992.
or getting closer to the source material, http://www.peirce.org/
> I agree that this is an interesting research topic.
greg heil
Randy MacDonald
In article <6jp78c$hd3$1...@newsd-143.iap.bryant.webtv.net>, ap...@webtv.net (stevan apter) wrote:
>You can do paper and pencil experiments here, by adapting Peirce's
>notational device for multivalent application.
>
>Let f be a function of, say, four arguments. Write f applied to a, b,
>c, d by writing "f" followed by four dots:
.. will these "experiments" tell us anything more significant than
the fact that a function which takes 4 arguments is equivalent to
a function that takes a single item, that item being a list of 4 elements?
--
|\/| Randy A MacDonald | I'm a boy, I want details.
|\\| ra...@godin.on.ca |
BSc(Math) UNBF '83 | APL: If you can say it, it's done.
Natural Born APL'er | *** GLi Info: in...@godin.on.ca ***
| Also http://www.godin.on.ca/randy
------------------------------------------------<-NTP>----{ gnat }-
Greg Heil
Randy MacDonald wrote:
> .. will these "experiments" tell us anything more significant than
the fact that a function which takes 4 arguments is equivalent to
a function that takes a single item, that item being a list of 4
elements?
Lisp is a fine language ... for computers.
Unfortunately it lacks something as a tool for expressing
metaphors. That we are programming ourselves is, at least,
as significant as that we are programming machines - unless
you do not mind being _Marooned in Realtime_.
Randy MacDonald
In article <6k1sfj$ca5$1...@gte1.gte.net>, NO-SPA...@acm.org wrote:
>Randy MacDonald wrote:
>> .. will these "experiments" tell us anything more significant than
> the fact that a function which takes 4 arguments is equivalent to
> a function that takes a single item, that item being a list of 4
> elements?
>
>Lisp is a fine language ... for computers.
Not that Lisp was being discussed...
>Unfortunately it lacks something as a tool for expressing
>metaphors.
Is _this_ what the experiments are for? To find a metaphor-producing
language?
>That we are programming ourselves is, at least,
>as significant as that we are programming machines - unless
>you do not mind being _Marooned in Realtime_.
I'm sorry, but I can't see the relation between your reply, and my
original posting. Please tell me there is none, or please elaborate
on what the relation is.