Just to extend the J story a little, I think that, so far as it goes, J is
just fine - but it isn't perfect (sorry, J fans) and I want to experience
diversity.
Here's the proposal (more or less, I'm making this up as I go along)...
(1) A personal-use licence for the full current APL interpreter product
(Windows 95/98/NT) for a price of GBP250 (or USD400) give or take say 10
percent.
(2) Access to service packs (or whatever) by electronic download to keep the
product current for 12 months.
(3) Use on client projects or development of a product for subsequent sale
is strictly prohibited. So no runtime interpreter or runtime licence in the
price above.
(4) No printed documentation (assuming that there is adequate electronic
documentation included).
(5) No vendor support by telephone, fax, email, etc.
I think that's it; hopefully I haven't forgotten anything because...
If any of the above three vendors makes their product available on this sort
of basis (we can negotiate here) before the end of June 1998 I will purchase
a copy. Two vendors, I buy both. Three vendors, I buy all three. I
already have J, thank you.
Would anyone else care to make the same committment?
We are talking about additional sales here, not substitution of potential
sales at higher prices; I cannot foresee my purchasing any of these products
on their current licence/price structure. I am happy to recommend all of
them (as appropriate) to clients and for development of for-sale application
packages at their current prices and will continue to do so.
Dick Bowman wrote:
>
><snip>
>
> Here's the proposal (more or less, I'm making this up as I go along)...
>
> (1) A personal-use licence for the full current APL interpreter product
> (Windows 95/98/NT) for a price of GBP250 (or USD400) give or take say 10
> percent.
>
><snip>
>
I don't know what IBM is doing about the APL2 for Windows but I
bought a copy of APL2 for OS/2 that was called an 'Entry Edition'
some
three years ago that mostly exceeds the expectations of the previous
poster
in the following way :
>
> (1) A personal-use licence for the full current APL interpreter product
> (Windows 95/98/NT) for a price of GBP250 (or USD400) give or take say 10
> percent.
Price was $370 if I recall correctly.
>
> (2) Access to service packs (or whatever) by electronic download to keep the
> product current for 12 months.
>
I'm still getting 'service packs' packs for it, for free, via ftp (or
disks by calling support.)
> (3) Use on client projects or development of a product for subsequent sale
> is strictly prohibited. So no runtime interpreter or runtime licence in the
> price above.
>
I don't know about the restriction on runtime ( I know it exists) but
all development
is in no way restricted.
> (4) No printed documentation (assuming that there is adequate electronic
> documentation included).
>
Got *excellent* printed documentation as well as on-line docs.
> (5) No vendor support by telephone, fax, email, etc.
>
Support is just as for the full product.
The distinguishing feature of the full product is ( was? ) that it
includes
extra AP's to support Cooperative ( Distributed ) Processing via TCP
and some C headers that facilitate the writing of AP's.
>(2) Access to service packs (or whatever) by electronic download to keep the
>product current for 12 months.
>
>(3) Use on client projects or development of a product for subsequent sale
>is strictly prohibited. So no runtime interpreter or runtime licence in the
>price above.
>(4) No printed documentation (assuming that there is adequate electronic
>documentation included).
>
>(5) No vendor support by telephone, fax, email, etc.
>
>I think that's it; hopefully I haven't forgotten anything because
I doubt that this will happen, at least as stated above. (Note, this is just
my opinion, I do *NOT* make pricing decisions for APL2000, much less any other
vendor)
Why not?
1) Many APL sales are to firms which use it to write in-house applications
which support their business, but are never sold or distributed. Such firms
are willing to pay full price, but would qualify for (and would demand) reduced
prices under a scheme described above. It would require hundreds of additional
licences guaranteed, up front, to replace this revenue and make such a scheme
break even. If 499 others join Dick in his pledge, then maybe (number of the
top of my head -- don't hold me to it.)
2) Producing the package you describe would mean supporting two different
products. This increases manufacturing costs (extra set up charged for CDs,
etc)
3) When Manugistics did charge extra for the runtime licence there were
widespread complaints about this practice. Now, in effect, you are complaining
that we are not charging extra for runtime.
I don't think that this proposal is realistic. If you want to debate it, send
email to Sa...@apl2000.com or talk to Eric Baelen personally -- he ultimately
makes these decisions.
-David E. Siegel
Sie...@ACM.ORG
Alex,
Continiue to use APL for fun. Don't bother to write anything unless,
again, for fun. Time for "portable APL which can be released in source
and free of charge but speed is not the primary concern" has gone and
will never come back. We have enough single-user languages around
already.
Regards,
Andrei
In the past, some vendors nicely finessed this for academic users by
setting up special academic partnerships or grants or other special
arrangements allowing a reduced price yet not overtly circumventing
the government's requirement.
--
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
> I believe one constraint on special pricing is the U.S. government's
> requirement that sales to it be at the lowest price the product is
> offered elsewhere. Is that still correct?
>=20
> In the past, some vendors nicely finessed this for academic users by
> setting up special academic partnerships or grants or other special
> arrangements allowing a reduced price yet not overtly circumventing
> the government's requirement.
Now that you mention it I remember this tactic being discussed.
Lets say the correct price being 50$ and the official price being 1500$
It is no problem to appear generous and sell one copy to an educational
institution and donate 29 copies at the same time.=20
Anyway it really would pay off to just let educational institutions get =
all=20
software for free. If they want to get diskettes, CDs or printed books=20
they should pay for the cost of the media.=20
Once people go away from the school they will want to continue using=20
what they used at school and then they should pay for it but only a =
reasonable
price.
Reading about Microsoft and their tactics then this is what they do.
It is a bit unfortunate that the major APL vendors have not done this=20
but this is what J does and it is also growing and picking up the slack.
Everyone can afford J. Not just the experts or the well off.
/Gosi
Björn Gosi Helgason wrote in message
<19980515.0...@sol.sun.csd.unb.ca>...
[snipped most of it]
The price my fellows is - in the end - determined by the market.
Some day you may find any of your darlings in the 1 $ store
But don't kill them!
Am I missing something here? IBM's APL2 for DOS contains a run time
system that may be combined with a WS to produce an .EXE file which may
be sold/given without royalties to IBM.
Ted
On Sat, 16 May 1998 15:21:43, Ted Edwards <Te...@bc.sympatico.ca>
wrote:
Change <APL> into <language> and Java or Perl would render it false it seems.
Why the pessimism about APL?
--
|\/| 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 }-
For having a product, the justification required to buy the same product again
is quite low, but that is true no matter what the product.
>> Marcelo Rodrigues wrote:
> > (3) Use on client projects or development of a product for subsequent sale
> > is strictly prohibited. So no runtime interpreter or runtime licence in the
> > price above.
> >
> ...
> Am I missing something here? IBM's APL2 for DOS contains a run time
> system that may be combined with a WS to produce an .EXE file which may
> be sold/given without royalties to IBM.
When you get a copy of J you can write your applications in J you can then
deliver your application together with whatever you want from J royalty free
as long as your application uses the switch /rt when calling J. So the product
you get downloaded for free allows you to use it for free as long as the /rt
switch is used.
When you want to use the studio you send for a licence key to ISI and
you can even try that for free for a few weeks.
This concept works very well. Needs little administration and is very popular.
It also spreads J to more places than any other APL dialect has ever had
the possibility to reach.
J is in this sense not competing with other APLs it is more competing with
the likes of Javas, Cs and Basics.
/Gosi
Yes, J is competing with Java (thanks to Bill) by its name. It also
competes with C being a single-letter language (cool language MUST
have one-character name). But, could you, please, explain in what
EXACTLY sense J is MORE competing with Basic than other APLs?
/AVK
>> J is in this sense not competing with other APLs it is more competing with
>> the likes of Javas, Cs and Basics.
> But, could you, please, explain in what
>EXACTLY sense J is MORE competing with Basic than other APLs?
You do not have the BURDEN of the APL characters in J.
You do have a full OOP in J.
You do have Grids in J.
You can write your J programs with ANY editor and you can
ship your programs to ANYONE without paying ANY royalties
to ANYONE.
These are some of the reasons why J is more like ordinary
languages than APL.
That surely does NOT mean that J does NOT have APL like features
and in that sense is also competing with other APLs.
What I find mostly great about J is that it has ALL the necessary
great features of APL and then more. Much more.
Those of you who have had the pleasures of experiencing J4.
Those of you who have seen how the genial developers of J have
with simplicity done the impossible. Those of you who have witnessed
a perfect product improve beyond belief. Those of you who have seen it
and EVERYONE can now try it on their own for free. Those of you who
have seen a demo. Those of you who have experienced OOP J style.
Those of you who have seen Grids being added to the power of J with
OOP techniques. Those of you who try will know what I mean.
This simplicity and conciseness has been the hallmark of Ken Iverson
and everyone around him for years.
Do NOT take my word for it.
Take a look at
www.jsoftware.com
Download a copy of J4 and you will see what I mean.
It does not cost you anything to try.
B U T R E M E M B E R
You will hooked if you do.
/Gosi
Spitalastig 4,IS-101 Reykjavik, tel: +354-5625441, go...@centrum.is
I think most of us readng this newsgroup will have tried J at some time
in the past. The problem is that some of us got hooked, while the rest
of us did not, hence the friction between some J and APL users.
(Otherwise you would be preaching to the converted.)
But I'll give it yet another go.
P.S. Every time I read one of these APL vs J threads, the term "Bjorn
Again Apl'ers" comes to mind. :-)
Ray Cannon
Computer Consultant and Webmaster of www.vector.org.uk
E-mail Ray_C...@compuserve.com
Compuserve account 100430,740
>I think most of us readng this newsgroup will have tried J at some time
>in the past. The problem is that some of us got hooked, while the rest
>of us did not, hence the friction between some J and APL users.
Which eerily mirrors the APL -- nonAPL friction... and why is that?
Why would those same people who were on the recieving end of
so much mythology and half-truth about the nature of APL, why
would they turn those same barbs on those who got hooked on J?
--
|\/| Randy A MacDonald | Do or do not, there is no try.
|\\| ra...@godin.on.ca | Yoda, Jedi Master
BSc(Math) UNBF '83 | APL: If you can say it, it's done.
Natural Born APL'er | *** GLi Info: in...@godin.on.ca ***
(CDN, leftie, b.1962) | Also http://www.godin.on.ca/randy
Perhaps it's not only that `People who live in glass houses shouldn't
throw stones'... it's maybe that they are also more likely to do so.
My experience is that the reasons are too often the same,
and I think this is reflected in this newsgroup. For
example, there is rarely any serious discussion of J vs APL,
for example by comparing algorithms to solve specific
problems. There are more comments on trivial matters such as
the spelling of J primitives.
Some while back, in response to a message that belittled J,
I posted a set of simple problems with solutions in J and
invited APL solutions - with zero response. I then followed
up a few weeks later with my own APL solutions - again zero
response.
Of course the J solutions were much simpler, as may be
expected. But why no response giving problems that are much
easier to solve in APL than in J, or else giving improved
APL algorithms?
It sure would be nice to have some of the pro-APL, anti-J
group come out with comments other than the "J is ugly"
variety, which we hear all the time when promoting APL.
And incidentally, as a long time APL and J programmer, there
is no doubt in my mind that J is easier to read than APL,
not least because the programs are much shorter - another
familiar argument we are used to from APL!
Pure speculation:
1. Developing skills in any programming language requires effort and
investment.
2. Acquiring competence in similar languages, expands productivity and
the original set of skills somewhat with very little effort. (e.g.,
Fortran, Cobol, Basic)
3. Acquiring competence in languages that add new features and tricks,
can expand productivity a good deal with very little effort. (AWK, Perl,
tcl)
3. Acquiring competence in languages that enforce some new paradigm,
increases productivity and skills, but with more effort and at the
expense of earlier skills that must be unlearned or discarded. (e.g.
Procedural (Basic) to block structured (Algol, PL/1, Pascal) to OO'ish
(C++, Object Pascal) to OO (Java, Smalltalk; Basic to ksh)
4. Acquiring competence in very different languages and paradigms
promises additional productivity and skills, but requires substantial
effort and risk of invalidating earlier skills. (e.g. scalar to array,
procedural to functional, Basic to APL, APL to J)
The above makes me agree that "APL positive, J negative" is very
analogous to "Conventional Language positive, APL negative", and for the
same reasons.
But I also fear, as it relates to programmers or system developers:
o It is unreasonable to expect Conventional Language (non APL) folks to
understand enough J to be willing to expend the effort to learn it.
o Those now earning a living with as APL programmers have no option nor
motivation to switch to J (in their work environment).
o A client sufficiently language neutral/tolerant to accept a J solution
is rare.
So I would conclude that J's future is with individual ad-hoc problem
solvers. However, (and possibly only due to my ignorance of math), I
can't imagine why the mathematicians of the world are not beating a path
to J's door to embrace J as a much more elegant and sensible tool of
math notation, investigation, and teaching.
BTW, I would think that those who want to contribute to J advocacy,
ought to flood the net with lots of J freeware/shareware applications.
Don't tell'em, show'em!
>. For
>example, there is rarely any serious discussion of J vs APL,
>for example by comparing algorithms to solve specific
>problems. There are more comments on trivial matters such as
>the spelling of J primitives.
>Some while back, in response to a message that belittled J,
>I posted a set of simple problems with solutions in J and
>invited APL solutions - with zero response. I then followed
>up a few weeks later with my own APL solutions - again zero
>response
I don't really think that such comparisions are useful except to those trying
to learn J who already know APL (or vice versa) or to those enganged in laguage
wars, which I for one try to eschew. If a particular feature (such as rank)
were being addressed, and they way J dealt with it vers the way APL did was
being discussed, then examples on point would be interesting, but not general
examples withoh no connection to a particular discussion -- of course this is
only my personaly opnion -- YMMV.
>Of course the J solutions were much simpler, as may be
>expected. But why no response giving problems that are much
>easier to solve in APL than in J, or else giving improved
>APL algorithms?
I presume that this is "of course" because you work in J mopre than APL
currently?
>It sure would be nice to have some of the pro-APL, anti-J
>group come out with comments other than the "J is ugly"
>variety, which we hear all the time when promoting APL.
>
I agree, agument by epithet is not productive for anyone.Personallty i am not
much interested in "J vs APL" discussion, even when conducted on a rational
non-insulting plane.
>And incidentally, as a long time APL and J programmer, there
>is no doubt in my mind that J is easier to read than APL,
>not least because the programs are much shorter - another
>familiar argument we are used to from APL!
I persoinally disagree, but I am NOT an experienced J user. I think that Dr.
Iverson should either have retained the special character primitaves (perhapsd
altering the set, but retaining the general concept) or else specified a set of
key-words for the built in language operations, rather than single letter
names, possibly followed by a period or a colon. I think that this makes
learning J harder than APL, not easier. Other aspects of J design seem like a
good idea to me, or at least an interesting varation on the APL theme. I am
not entirely convinced by the "item" concept (for example), but it is an
interesting and consistant idea, well worth trying.
-David E. Siegel
Sie...@ACM.ORG
D E Siegel wrote in message
<199805311926...@ladder01.news.aol.com>...
>>Of course the J solutions were much simpler, as may be
>>expected. But why no response giving problems that are much
>>easier to solve in APL than in J, or else giving improved
>>APL algorithms?
>
>I presume that this is "of course" because you work in J mopre than APL
>currently?
No. The "of course" is because J code is often much simpler than
the corresponding APL code, and the examples illustrated that. The
reverse is rarely the case.
I have met Ken I. on numerous occasions and had many long discussions
with him over the years (dating back to 1967). Since J is his third
kick at the can (A Programming Language, 1962; APL/360 ca 1966; J), I am
not surprised that it would represent a significant step forward.
I haven't used J as of yet and don't know if or when I will. I am a
heavy user of APL2 for my own continuing software development. It would
be a major effort to learn J and switch over to it. I'm not sure if
they could happily co-exist. Between my APL, house building, machine
shop, blacksmithing, horses, and training a new puppy, I don't seem to
have too much difficulty filling my days. Maybe next year. :-)
Ted
is there any problem or class of probs which i cannot/would not solve
w/apl(2) that j/k would permit me to solve?
if there are, (a) i havent come across it in the work i do; (b) i am limited
by my imagination; or (c) i dont know what i dont know (credit socrates).
one real huge benefit might be execution speed. i know k (cant say this
about j) simply is order of magnitudes faster than the pc apl's i/ve used.
no comparison. that alone might be reason to switch (fair's fair...i havent
tried dyalog and i havent upgraded manugistics since theyve been bot out).
my prior regarding coding speed is that its splitting hairs.
the only other reason to switch might be if one thinks the lang is headed
away from funny char apl to script based j''s and k' and one wants to keep
up.
net net. if i had a lot of time for intellectual masturbation, id spend the
summer learning k, otherwise, im not sure....dave
Ted Edwards wrote in message <357416...@bc.sympatico.ca>...
> I am a heavy user of APL2 for my own continuing software development.
> It would be a major effort to learn J and switch over to it. I'm not sure if
> they could happily co-exist.
APL2 are so vastly different that they can happily co-exist.
They solve completely different needs in the user community
so you do not need to be scizophrenic to use both.
There are obvious areas of overlap but for most practical purposes
they would not be aimed at the same customers or applications.