Home > Archive > APL > December 2006 > "UnSpun" ranking of Best Programming Language
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
"UnSpun" ranking of Best Programming Language
|
|
| Morten Kromberg 2006-12-01, 3:56 am |
| This posting on the J forum already bumped J up to 19, and after I
posted it to the Dyalog User forum, APL has jumped to 6th(!) This is
your chance to increase the Buzz surrounding APL by clicking a couple
of times!
Note that there is a parallel ranking for "Best Programming Language -
Ever", where APL is still only 14th.
-----Original Message-----
From: chat-bounces@jsoftware.com [mailto:chat-bounces@jsoftware.com] On
Behalf Of June Kim
Sent: 30. november 2006 17:46
To: Chat forum
Subject: [Jchat] Amazon's Best Programming Language rank
Amazon has recently launched a new web service, unspun. Ruby crowd is
happily welcoming it; unspun is written in Ruby on Rails.
unspun is a service for ranking anything. There is a ranking for Best
Programming Language.
http://unspun.amazon.com/list/show/1045
I was glad to see J in the list. Currently, J ranks at 32nd. Quite high
compared to its user size.
| |
| Mike Kent 2006-12-01, 6:56 pm |
| Morten Kromberg wrote:
> This posting on the J forum already bumped J up to 19, and after I
> posted it to the Dyalog User forum, APL has jumped to 6th(!) This is
> your chance to increase the Buzz surrounding APL by clicking a couple
> of times!
Dumb poll. There is no "best programming language".
What this measures is the number of fanatical-to-point-of-deranged
advocates a language currently engages. Evidence? The vote for Ruby
is about 7x the vote for #2 Java, and in fact is close to the total for
/all/ other languages combined.
"Unspun" is a misnomer. "NotSpunByAmazon" is closer.
| |
| Morten Kromberg 2006-12-02, 7:56 am |
| Mike Kent <m...@acm.org> wrote:
> Dumb poll. There is no "best programming language".
Well, "obviously" :-)
Still, that doesn't make it any less fun to be in 3rd place, behind
only Ruby and Java. Or make this less of an opportunity to remind the
world that APL is beatiful and loved by many people. It is important in
this age of Dynamic Languages and Agile Programming to remind people
who once used APL and believed it dead, that there are modern APL
systems which can hold their own against Ruby and Python.
The links to Dyalog, MicrosAPL and Vector which are now at the top of
this page will also show that APL is alive and well, and as young as
elegant as ever at 40!
I believe you are right that the poll IS a good measure of how
passionate developers who use a particular language are. Is that a bad
thing?
To anyone who has not yet voted: There is still time to help keep APL
near the top of the list.
| |
| Ibeam2000 2006-12-02, 6:56 pm |
| I don't think this poll is a measure of anything.
However, it is still interesting to see APL as far up as it is.
It would be also interesting to start a poll to see what the "worst"
language is. (I would expect it to be the worst language with which an
individual never programmed)
| |
| Jane Sullivan 2006-12-02, 6:56 pm |
| In message <1165097983.661801.154490@79g2000cws.googlegroups.com>,
Ibeam2000 <Ibeam2000@gmail.com> writes
>I don't think this poll is a measure of anything.
>
>However, it is still interesting to see APL as far up as it is.
>
>It would be also interesting to start a poll to see what the "worst"
>language is. (I would expect it to be the worst language with which an
>individual never programmed)
>
In my not-so-humble opinion, which I must admit is only spot-on, the
worst programming language is ... <pause for absolutely ages, like they
do so annoyingly on those "reality" TV shows>
BASIC
--
Jane
| |
| Ted Edwards 2006-12-03, 3:59 am |
| Ibeam2000 wrote:
> It would be also interesting to start a poll to see what the "worst"
> language is. (I would expect it to be the worst language with which an
> individual never programmed)
It would probably be APL. Of all the languages I have encountered, I
have not heard of one yet that was more maligned than APL. This is
invariably by people who have never used it or at best only briefly
looked at it and decided, "It looks too much like math" or "It must be
slow because it's interpreted" or some other such nonsense.
Ted
| |
|
| try Phil Benkard's SUMROUND in Fortran e.g.;
there's a double SORT in it, which means you have
to sort the positions - try that in Fortran or BASIC, or
any other ...
If you have a dataset of, say 10000, you can not
only drink your coffee - you have time to grow the
beans, burn them, make 'coffee' of it and drink it, hot
or otherwise.
So, "best language" - for the purpose, that is ...
Jan Karman
"AA2e72E" <AA2e72E@lycos.co.uk> wrote in message
news:1165138596.849456.309080@j72g2000cwa.googlegroups.com...
> It takes but 30 minutes to be able to talk about BASIC; the vocabulary
> includes '.NET', 'COMPILED', 'Microsoft','off-the shelf components'
> etc. In the same duration, it is not even possible to mumble about
> APL. This is not a reflection on the quality of the languages or
> specifically on APL per se: APL is just harder and general
> documentation on APL is very rare. It must also be hardest to recruit
> an APL developer than one in any other language.
>
> The 'compiled vs interpreted' debate has come round full circle; as far
> as I can see, interpreted is now preferred ... you cannot seriously say
> that even the .NET languages are compiled in the original sense of that
> word.
>
| |
| AA2e72E 2006-12-03, 7:56 am |
|
jk wrote:
> try Phil Benkard's SUMROUND in Fortran e.g.; there's a double SORT in it, which means you have to sort the positions - try that in Fortran or BASIC, or any other ...
"or any other ..."
If I have to sort data, I'd use SQL: I'd simply write this:
SELECT * FROM MYTABLE ORDER BY DEPT, NAME, SEX, DATEOFBIRTH, SALARY
to sort all the data in MYTABLE in ascending order, where DEPT,NAME,
SEX are []DR 82, DATEOF BIRTH is a date (no []dr], and SALARY is []dr
645 ... (APL+Win's []dr)
I would not have to worry about neither the internals of the algorithms
nor about how many columns or rows are involved, 10 or 1 million.
With APL, you will have time to drink the coffee .... after the several
days you spent writing the code, you'll need the coffee but with SQL
you won't have time to make the coffee, let alone make it and drink it.
If only vendors were as eager to embrace emerging technology then (as
they are today, with .Net) i.e in 1978 when the relational database
model was emerging .....
| |
| Jane Sullivan 2006-12-03, 7:56 am |
| In message <1165146050.277482.145310@j44g2000cwa.googlegroups.com>,
AA2e72E <AA2e72E@lycos.co.uk> writes
>
>jk wrote:
>
>
>"or any other ..."
>
>If I have to sort data, I'd use SQL: I'd simply write this:
>
>SELECT * FROM MYTABLE ORDER BY DEPT, NAME, SEX, DATEOFBIRTH, SALARY
>
>to sort all the data in MYTABLE in ascending order, where DEPT,NAME,
>SEX are []DR 82, DATEOF BIRTH is a date (no []dr], and SALARY is []dr
>645 ... (APL+Win's []dr)
>
>I would not have to worry about neither the internals of the algorithms
>nor about how many columns or rows are involved, 10 or 1 million.
Oh yeah? Have you tried doing this sort of thing on an unindexed field?
The reason SQL appears to be so quick is because the database maintains
indexes which effectively are the data already sorted.
>
>With APL, you will have time to drink the coffee .... after the several
>days you spent writing the code, you'll need the coffee but with SQL
>you won't have time to make the coffee, let alone make it and drink it.
>
>If only vendors were as eager to embrace emerging technology then (as
>they are today, with .Net) i.e in 1978 when the relational database
>model was emerging .....
>
--
Jane
| |
|
| ok, take 1.000.000 numbers at random, divide by seven, then round them off
nearby at 2, 3, 4, &c. digits at your choice, make sure that the sum of the
rounded-off amounts equals the rounded-off sum of the original amounts
in practice: calculate the VAT on 1.000.000 amounts of sales and satisfy
your accountant (happy christmas)
(with SORT in APL I meant just {grade up} or {grade down} - one character)
(and in the meantime read Dan King's article on Arthur Withney's demo on
SQL to an afterwards desperate manager ... once upon a time ...)
jk
"AA2e72E" <AA2e72E@lycos.co.uk> wrote in message
news:1165146050.277482.145310@j44g2000cwa.googlegroups.com...
>
> jk wrote:
>
>
> "or any other ..."
>
> If I have to sort data, I'd use SQL: I'd simply write this:
>
> SELECT * FROM MYTABLE ORDER BY DEPT, NAME, SEX, DATEOFBIRTH, SALARY
>
> to sort all the data in MYTABLE in ascending order, where DEPT,NAME,
> SEX are []DR 82, DATEOF BIRTH is a date (no []dr], and SALARY is []dr
> 645 ... (APL+Win's []dr)
>
> I would not have to worry about neither the internals of the algorithms
> nor about how many columns or rows are involved, 10 or 1 million.
>
> With APL, you will have time to drink the coffee .... after the several
> days you spent writing the code, you'll need the coffee but with SQL
> you won't have time to make the coffee, let alone make it and drink it.
>
> If only vendors were as eager to embrace emerging technology then (as
> they are today, with .Net) i.e in 1978 when the relational database
> model was emerging .....
>
| |
| AA2e72E 2006-12-03, 7:56 am |
| > Oh yeah? Have you tried doing this sort of thing on an unindexed field? The reason SQL appears to be so quick is because the database maintains indexes which effectively are the data already sorted.
Should a table without an index exist,
1. fire the DBA and hire one that maintains the database optimally
2. in the interim, submit a "CREATE INDEX " SQL to create it for you,
all from within your own host application that can be APL.
It is not just the speed but the ease with with you can deal with data
stored in DB using SQL
| |
| AA2e72E 2006-12-03, 7:56 am |
|
jk wrote:
> ok, take 1.000.000 numbers at random, divide by seven, then round them off
> nearby at 2, 3, 4, &c. digits at your choice, make sure that the sum of the
> rounded-off amounts equals the rounded-off sum of the original amounts
>
> in practice: calculate the VAT on 1.000.000 amounts of sales and satisfy
> your accountant (happy christmas)
Absolute nonsense!
For every context that you might elicit APL as being the perfect
language, there are counter instances where APL is simply hopeless.
Nonetheless, you can achieve anything with APL that can be achieved by
other languages but that does not mean that APL is the only language to
use...... APL is but one tool in the toolbox.
| |
|
| what's nonsense - this example?
or the million amounts?
or the desperate manager?
"AA2e72E" <AA2e72E@lycos.co.uk> wrote in message
news:1165151991.152108.188800@73g2000cwn.googlegroups.com...
>
> jk wrote:
>
>
> Absolute nonsense!
>
> For every context that you might elicit APL as being the perfect
> language, there are counter instances where APL is simply hopeless.
> Nonetheless, you can achieve anything with APL that can be achieved by
> other languages but that does not mean that APL is the only language to
> use...... APL is but one tool in the toolbox.
>
| |
| AA2e72E 2006-12-03, 6:56 pm |
|
jk wrote:
> what's nonsense - this example?
> or the million amounts?
> or the desperate manager?
Try taking the APL visor off & see whether it helps to see the answer.
| |
| Ted Edwards 2006-12-03, 6:56 pm |
| AA2e72E wrote:
> It takes but 30 minutes to be able to talk about BASIC; the vocabulary
> includes '.NET', 'COMPILED', 'Microsoft','off-the shelf components'
> etc. In the same duration, it is not even possible to mumble about
> APL.
I taught a night school intro to APL - one hour a w . I also taught a
one semester credit course in BASIC - three hours a w. By the end of
the courses the APL students could do far more practical computing than
the BASIC ones.
Ted
| |
| AA2e72E 2006-12-03, 6:56 pm |
|
Ted Edwards wrote:
> I taught a night school intro to APL - one hour a w. I also taught a one semester credit course in BASIC - three hours a w. By the end of the courses the APL students could do far more practical computing than the BASIC ones.
I could not agree with you more; this is my experience and no doubt the
daily experience of other multi-language developers whose skill
includes APL; however, what I said originally was
"It takes but 30 minutes to be able to talk about BASIC ...."
i.e "talk about" and not "use or deploy".
For example, the VB ByRef and ByVal roughly (very roughly) equate to
the APL local and global variables. It is easy to learn to talk about
the scope of variables in VB and very nearly impossible to do so in APL
by simply, say, searching on Google.
The software industry ignores APL and the shrinking APL community
ignores the software industry with more determination; unfortunately,
the software industry is bigger and stronger (survival of the fittest
etc!).
Besides the need for documentation aimed at recruiting newcomers, my
plea is simply for APL developers to see what is outside the workspace;
there is a lot that APL can use without effort and in a simpler, more
robust way. APL, if it choses to play by the rules of the industry,
will be more acceptable. Unlike developers, vendors are way ahead in
showing the way:
1. APL+Win showed the way by making COM available seamlessly; recently,
APL2 has done the same.
2. APLX does exactly the same thing with SQL.
3. APL/W does the same with .NET.
4. APLNext shows exactly how APL is a native .NET language on the same
footing as any of the Microsoft .Net languages.
APL as the "Best programming language" is meaningless. APL as a tool
capable of sharing its data tier with other unknown applications,
hooking into live stock market feeds, able to use all the resources
that exist on its platform etc. etc. make it a language of choice,
given its RAD credentials.
As things stand, it is the talkers rather than the doers who make the
decisions that continue to be so detrimental to APL.
| |
| Bob Cain 2006-12-03, 6:56 pm |
| AA2e72E wrote:
> 4. APLNext shows exactly how APL is a native .NET language on the same
> footing as any of the Microsoft .Net languages.
I think this is the most exciting thing to have ever happened to APL.
I hope they recognize the need for a very low cost "personal" license
to lure new users. The documentation sucks, however. How applicable
is your book to APLNext? Any chance of an edition specific to that
product?
Bob
--
"Things should be described as simply as possible, but no simpler."
A. Einstein
| |
| AA2e72E 2006-12-03, 6:56 pm |
|
Bob Cain wrote:
> I think this is the most exciting thing to have ever happened to APL. I hope they recognize the need for a very low cost "personal" license to lure new users. The documentation sucks, however.
Perhaps I was a little too enthusiastic in stating that "the APL
vendors are showing the way"; undoubtedly they are in bringing the
technology to the desktop BUT the documentation has been and continues
to be consistently poor from the point of view of 'new users'. APLNext
is no exception. What exists serves as a source of reference not as
something to learn from.
Pricing is another issue. APL is expensive as a tool for developing
commercial applications: the software is expensive, developers are
expensive and there is no community learning resource. Other languages
thrive because it is possible to search for solutions, copy and paste
(adapt) the code into one's own project; nothing like this exists for
APL and it is much poorer as a consequence.
APLNext requires VS2005 (does not work with the free Express versions);
initial indications are that its price will be a determining factor in
its success.
>How applicable is your book to APLNext? Any chance of an edition specific to that product?
Your question suggests that you have not got a copy! The book has
nothing to do with APLNext except that it shows how to build COM DLLs
using C# for use with any COM compliant language, including APL. A
version of roughly the same material (published in Quote Quad) was/is
available here:
http://delivery.acm.org/10.1145/116...CFTOKEN=6184618
APLNext is a NEW language; core APL is but a subset of what needs to be
mastered for proficiency and that has many (.Net) surprises. For
example, all variables are local by default (as opposed to global by
default in APL) and index origin is 0 by default. Simple things are
quite different too, e.g.
'c:\myfile.ext' []ncreate {negative}1
becomes
(@"c:\myfile.ext') []ncreate {negative}1
or "c:\\myfile.ext" []ncreate {negative}1
(note \\).
Also, the component file system is different from APL+Win (whose comp
files cannot be read by the corresponding [] functions in APLNext). I
seems to be that migration to APLNext is not going to be simple and it
does not appear that APLNext is intended for porting legacy APL
applications.
I am using RC3.0 and I agree that is a great product. Now is absolutely
the right time for a book on APLNext from an independent writer. At
present, I am still learning APLNext and cannot contemplate such a
venture just yet, if at all.
An ideal scenario would be one where several APLNext beta testors
pooled resources and wrote about their own topics with a view to
spanning the whole of the APLNext spectrum. If you see the APLNext
forum, there are some brilliant people involved in the beta programme.
Such a book will save so much time for the community at large and
APLNext, if willing/able, can provide a (cut-down/restricted/personal)
version of APLNext to accompany the book (as a means of establishing
market presence). Perhaps I am dreaming .....again....
For now, the best available resource for APLNext are the excellent
wly webcasts available on the APLNext web site.
| |
| TaliesinSoft 2006-12-03, 9:56 pm |
| On Sun, 3 Dec 2006 11:34:06 -0600, Ted Edwards wrote
(in article <iUDch.24173$rv4.18476@edtnps90> ):
> I taught a night school intro to APL - one hour a w. I also taught a
> one semester credit course in BASIC - three hours a w. By the end of
> the courses the APL students could do far more practical computing than
> the BASIC ones.
Years ago, in the mid 70s, I gave a two hour presentation of APL to a class
of computing students at Glassboro State College, now Rowan University, in
New Jersey. The programming language used in the course was Fortran. A w
or so prior to the presentation I had been given a list of ten problems from
which a student could select a single one as their end of the term project.
During my presentation I showed that each of those ten problems could be
almost trivially solved in APL. After the presentation the instructor stated
to me, my paraphrasing, "APL is very interesting but it is NOT programming!"
--
James Leo Ryan ..... Austin, Texas ..... taliesinsoft@mac.com
| |
| Paul Mansour 2006-12-03, 9:56 pm |
| AA2e72E wrote:
> APL as the "Best programming language" is meaningless. APL as a tool
> capable of sharing its data tier with other unknown applications,
> hooking into live stock market feeds, able to use all the resources
> that exist on its platform etc. etc. make it a language of choice,
> given its RAD credentials.
Other languages have RAD credentials. If it is a "language of choice,"
you must choose it because you think it is better than the
alternatives, no?(certainly you don't choose it because that's where
the jobs are). If it is better than the alternatives, why is it
meaningless to discuss it as "one of the best", if not "the best". ;)
| |
| AA2e72E 2006-12-04, 3:56 am |
|
Paul Mansour wrote:
> If it is better than the alternatives, why is it meaningless to discuss it as "one of the best", if not "the best". ;)
In what way is APL better? What does it have that other languages do
not have or cannot achieve?
Is it the fastest? No.
Is it nested arrays? VB, even VBA and VBScript have this.
Is it conditional assignment? VB, even VBA has this.
Is it array processing? Easily achieved with VB; Excel has this, of
sorts.
etc.
etc.
What APL has exclusively are:
1. interactive mode that permits code to be tested and ported into
application code.
2. (one line) idioms (corresponding to multi line algorithms in other
languages, sometimes)
On 1. see the post from James Ryan below, in particular:
"APL is very interesting but it is NOT programming!"
On 2. APL developers do not use them, preferring to reinvent solutions
or to leave working code alone.
APL needs to embrace industry trends: tier design (including
databases), platform resources (COM and APIs), and use the industry
rather than the APL jargon and techniques; e.g. "component files" means
nothing outside APL.
| |
|
| > Is it the fastest? No.
> Is it nested arrays? VB, even VBA and VBScript have this.
> Is it conditional assignment? VB, even VBA has this.
> Is it array processing? Easily achieved with VB; Excel has this, of
> sorts.
as long as you have no more than ten records, that is
jk
| |
| Randy MacDonald 2006-12-04, 7:56 am |
| "AA2e72E" <AA2e72E@lycos.co.uk> wrote in news:1165138596.849456.309080
@j72g2000cwa.googlegroups.com:
> It takes but 30 minutes to be able to talk about BASIC; the vocabulary
> includes '.NET', 'COMPILED', 'Microsoft','off-the shelf components'
> etc. In the same duration, it is not even possible to mumble about
> APL. This is not a reflection on the quality of the languages or
> specifically on APL per se: APL is just harder and general
> documentation on APL is very rare. It must also be hardest to recruit
> an APL developer than one in any other language.
>
> The 'compiled vs interpreted' debate has come round full circle; as far
> as I can see, interpreted is now preferred ... you cannot seriously say
> that even the .NET languages are compiled in the original sense of that
> word.
>
>
It took my 12 year old cousin less than a minute to get what {times}/X
was, based on what +/X came back with. APL is only hard if you make it
hard.
--
------------------------------------------------------------------------
|\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram)
|/\| ramacd@nbnet.nb.ca |
|\ | | The only real problem with APL is that
BSc(Math) UNBF'83 | it is "still ahead of its time."
Sapere Aude | - Morten Kromberg
Natural Born APL'er | Demo website: http://156.34.89.236/
-----------------------------------------------------(INTP)----{ gnat }-
| |
| Randy MacDonald 2006-12-04, 6:56 pm |
| "AA2e72E" <AA2e72E@lycos.co.uk> wrote in
news:1165146050.277482.145310@j44g2000cwa.googlegroups.com:
>
> jk wrote:
>
>
> "or any other ..."
>
> If I have to sort data, I'd use SQL: I'd simply write this:
>
> SELECT * FROM MYTABLE ORDER BY DEPT, NAME, SEX, DATEOFBIRTH, SALARY
>
> to sort all the data in MYTABLE in ascending order, where DEPT,NAME,
> SEX are []DR 82, DATEOF BIRTH is a date (no []dr], and SALARY is []dr
> 645 ... (APL+Win's []dr)
>
> I would not have to worry about neither the internals of the
> algorithms nor about how many columns or rows are involved, 10 or 1
> million.
>
> With APL, you will have time to drink the coffee .... after the
> several days you spent writing the code, you'll need the coffee but
> with SQL you won't have time to make the coffee, let alone make it and
> drink it.
>
> If only vendors were as eager to embrace emerging technology then (as
> they are today, with .Net) i.e in 1978 when the relational database
> model was emerging .....
>
>
MMV:
TABLE[{upgrade}TABLE[;DEPT,NAME,SEX,DATE
OFBIRTH,SALARY]
or
t {<-} 'TABLE' new 'dbTABLE'
s {<-} 'DEPT' NAME' 'SEX' 'DATEOFBIRTH' 'SALARY' 'upgrade' to t
Personally, I've ruined many keyboards with coffee because I had no time
to leave them.
I've never considered SQL to be a language, more of a protocol.
--
------------------------------------------------------------------------
|\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram)
|/\| ramacd@nbnet.nb.ca |
|\ | | The only real problem with APL is that
BSc(Math) UNBF'83 | it is "still ahead of its time."
Sapere Aude | - Morten Kromberg
Natural Born APL'er | Demo website: http://156.34.89.236/
-----------------------------------------------------(INTP)----{ gnat }-
| |
| AA2e72E 2006-12-04, 6:56 pm |
|
Randy MacDonald wrote:
> It took my 12 year old cousin less than a minute to get what {times}/X was, based on what +/X came back with. APL is only hard if you make it hard.
Your cousin is very smart or perhaps just lucky; have you tried things
like:
-/X
2+/X
etc.
I wonder what a 12 year old who masters the APL IDIOMS (Finn & IBM)
would manage to produce in a year or two; must be magical.
| |
|
|
"Randy MacDonald" <ramacd@nbnet.nb.ca> wrote in message
news:Xns988F671CAA1A7ramacd@198.164.200.20...
> "AA2e72E" <AA2e72E@lycos.co.uk> wrote in
>
>
> I've never considered SQL to be a language, more of a protocol.
Well said. Neither is Excel - and if at all, it is the worst thinkable of;
it's a tricky, unreliable and dangerous tool. We once fired somebody
who was using it for reports. It's fine for your home-budget, but still
then ...
I remember once trying to write 40.000 records or so - it refused:
it's limit appeared to be 32000+ (2^16) ... !!!
jk
| |
| phil chastney 2006-12-04, 6:56 pm |
| AA2e72E wrote:
> <snip>
>
> What APL has exclusively are:
>
> 1. interactive mode that permits code to be tested and ported into
> application code.
Python has this
> <snip again>
> e.g. "component files" means nothing outside APL.
but all programming languages encounter difficulties when they need to
share persistent data with other applications, environments, etc
regards . . . /phil
| |
| AA2e72E 2006-12-04, 6:56 pm |
|
jk wrote:
> Well said. Neither is Excel - and if at all, it is the worst thinkable of;
> it's a tricky, unreliable and dangerous tool. We once fired somebody
> who was using it for reports. It's fine for your home-budget, but still
> then ... I remember once trying to write 40.000 records or so - it refused:
> it's limit appeared to be 32000+ (2^16) ... !!!
SQL is indeed not a language, it is a means of describing the view of
the existing data that is sought/required (which may include basic
calculations), no knowledge of programming whatsoever is required: the
phrase data to information/intelligence comes to mind. SQL works in the
ultimate spirit of the APL language, namely the ability to resolve your
problem without any awareness of machine constraints or the internal
workings of any algorithms used.
Excel is "fine for your home budget": if you seriously believe that
then there is nothing more to say!!!
"it's limit appeared to be 32000+ (2^16) ..." and what do you conclude
from this? That APL does not have limits? Everything on a desktop is
ultimately bound by the resources of the computer it is running on.
Excel 2000 (since 6 years ago) can accommodate 65,536 rows on a single
worksheet and it can have as many worksheets as available resources
allow. Excel 2007 has 1M rows. Try that with APL!
| |
|
|
"AA2e72E" <AA2e72E@lycos.co.uk> wrote in message
news:1165264519.552908.272270@n67g2000cwd.googlegroups.com...
>
> jk wrote:
>
>
> SQL is indeed not a language, it is a means of describing the view of
> the existing data that is sought/required (which may include basic
> calculations), no knowledge of programming whatsoever is required: the
> phrase data to information/intelligence comes to mind. SQL works in the
> ultimate spirit of the APL language, namely the ability to resolve your
> problem without any awareness of machine constraints or the internal
> workings of any algorithms used.
>
> Excel is "fine for your home budget": if you seriously believe that
> then there is nothing more to say!!!
>
> "it's limit appeared to be 32000+ (2^16) ..." and what do you conclude
> from this? That APL does not have limits? Everything on a desktop is
> ultimately bound by the resources of the computer it is running on.
> Excel 2000 (since 6 years ago) can accommodate 65,536 rows on a single
> worksheet and it can have as many worksheets as available resources
> allow. Excel 2007 has 1M rows. Try that with APL!
>
K(db) handles 1 Terabyte ... in a second ...
| |
| Ibeam2000 2006-12-04, 6:56 pm |
| Here the author claims that C should be un-learned and die. I have no
strong opinions about that statement, only that perhaps the C language
was designed for a very different audience than the audience who wound
up using it.
see http://blogs.zdnet.com/Burnette/?p=208&tag=nl.e622
The author goes on to cite five reasons to un-learn C. His closing
paragraph is:
I could go on, but 5 is enough for now; I feel better already. C was
wonderful... in 1984. It amazes me that new code is being written in C,
even today. C++ is only marginally better if you ask me. If you want to
learn something old, try Forth, Lisp, or APL. At least those can teach
you some different and elegant ways of thinking about programming.
| |
|
|
"AA2e72E" <AA2e72E@lycos.co.uk> wrote in message
news:1165264519.552908.272270@n67g2000cwd.googlegroups.com...
>
> allow. Excel 2007 has 1M rows. Try that with APL!
>
well, they came a long way ...!
1 M rows is really nothing at NYSE, Telecom, Insurance Cies, Petrochemistry,
Meteorology, Defense, &c.
.... apart from that it is highly unreliable and totally disfunctional for
serious
business applications
My questions to you is: "Are you serious yourself?"
(if so, dream on ...)
jk
| |
|
|
"phil chastney" <phil.hates.spam@amadeus-info.munged.freeserve.co.uk>
wrote in message
news:TV_ch.263888$c42.111079@fe02.news.easynews.com...
| AA2e72E wrote:
| > <snip>
| >
| > What APL has exclusively are:
| >
| > 1. interactive mode that permits code to be tested and ported into
| > application code.
|
| Python has this
|
| > <snip again>
| > e.g. "component files" means nothing outside APL.
|
| but all programming languages encounter difficulties when they need
to
| share persistent data with other applications, environments, etc
|
| regards . . . /phil
I have to draw the line on this last point.
The fundamental reason for a relational database is that different
programs and applications can easily share persistent data with each
program provided with the logical view that is optimum for that
programs needs. These capabilities apply across almost all
languages, COBOL, Fortran, Java, C, C++, ...
Languages such as APL and Lisp that have unique internal data
representations that force them to rely on some special import /
export process to access these "shared variables" are the exception.
Most other languages represent data internally in a form that is close
or identical to the external format provided in the I/O buffers of the
file system or the SQL database.
Some vendors are moving to minimize this "impedance mismatch" across
languages (see APL/NEXT and other .NET developments) where the linkage
interface has been expanded to include a full object type definition
which allows APL to directly call or be called by other languages
without a lot of parameter manipulation specific to the source /
target language.
Mike Sicilian
| |
| Paul Mansour 2006-12-04, 6:56 pm |
| AA2e72E wrote:
> What APL has exclusively are:
>
> 1. interactive mode that permits code to be tested and ported into
> application code.
> 2. (one line) idioms (corresponding to multi line algorithms in other
> languages, sometimes)
I don't think either one is true, certainly not #1.
But really, then, why do you use APL, if as you claim, other languages
meet or exceed it on every front? It is just because it's what you
know? Or because it is what you get paid to do, but you would rather be
programming something else? Some other reason? Why do you use APL? If
you like it, why do you like it?
| |
| AA2e72E 2006-12-05, 3:57 am |
|
Paul Mansour wrote:
> But really, then, why do you use APL, if as you claim, other languages meet or exceed it on every front? It is just because it's what you know? Or because it is what you get paid to do, but you would rather be programming something else? Some other rea
son? Why do you use APL? If you like it, why do you like it?
There is no question that I like APL nor is there any doubt in my mind
that APL, as a development language, is superior to virtually every
other language that I have used (VB, VBA, VBScript, JavaScript, VB.Net,
C#, Forth & C) for one simple reason: APL readily provides answers to
most questions I can ask in coding the business tier of any
application; however, this is not the case when it comes to the user
and data tiers where it is severely lacking.
Equally, it is true that APL, like other languages, leaves a lot that
is wanting:
APL does not handle dates {at all} as well as other languages, it does
not handle volumes of data as well as databases, it does not present
its data as well as Excel etc.
What is very clear to me is that there is NO need coerce APL to do
everything and neither is there any need to build every functionality
possible into APL. There is an arrogant belief among APL developers
that if it is not achievable in APL, then it is not required.
Today's APL is more than capable of using resources outside of the
workspace, and do so like any other language if not better.
All that is needed is for APL developers to look outside of the once
cosy world of the workspace. It is the determined reluctance to do this
that explains a lot of what has happened to APL.
I find it very irritating (derisible) to read that Excel is "fine for
the home budget": allegedly, 13 million individuals across the world
rely on Excel to put the daily bread on the table. This does not
include casual/occassional/non-critical usage. It has supplanted APL as
the tool of choice for Actuaries: these are people smarter than the
average and those who rely heavily on vectors and mathematics.
jk also mentioned the accounting problem of rounding: there is not one
accounting package that relies on APL.
If speed is the issue, I think nothing solves the problem better than
the acquisition of faster hardware.
APL needs to be a team player to be acceptable; it has a very
legitimate role in multi-language developments. To be a team player, it
needs to be more open i.e stop hiding its data in component files and
the workspace and it needs to stop re-inventing the wheel at every
turn.
Perhaps APLNext will show the way for APL in a multi-language
development environment, where APL shares rather than impose its
strengths.
| |
| AA2e72E 2006-12-05, 3:57 am |
|
jk wrote:
> K(db) handles 1 Terabyte ... in a second ...
More nonsense?
1. With today's fastest hardware, it is NOT physically possible to READ
every byte of one terabyte of data in one second, let alone find every
byte and do something with it. What does 'handle' actually mean? As far
as I know, any file on Windows cannot exceed 4GB. So K(db) is using a
(custom) database? If so, where does that leave your argument about APL
handling more records than 32000?
2. K(db) is not APL; it might have its root in APL but it is not
something that APL (APL+Win, APL/W, APL2, APLX) can just deploy.
| |
| Jane Sullivan 2006-12-05, 3:57 am |
| In message <1165279888.753203.64400@73g2000cwn.googlegroups.com>, Paul
Mansour <paul@carlislegroup.com> writes
>AA2e72E wrote:
>
>
>I don't think either one is true, certainly not #1.
>
>But really, then, why do you use APL, if as you claim, other languages
>meet or exceed it on every front? It is just because it's what you
>know? Or because it is what you get paid to do, but you would rather be
>programming something else? Some other reason? Why do you use APL? If
>you like it, why do you like it?
>
I am paid to use an APL language. I am one of a team of three people
whose job is to support a legacy application until the team of many more
C (++ and #) and Java programmers can replace it. There is a prohibition
from IT management on writing new stuff in the legacy language. However
-- Our customers (stock traders) insist on enhancements being made to
the legacy system on a daily basis. Their requirements overrule the
IT prohibition.
-- Our little team of three people can write, test and implement the
enhancements faster than the huge team of C/Java people can go
through their usual development cycle for the same enhancements. At
the rate they are going, they will never catch up. I hope this does
not continue for too long, because I am due to retire in three
years' time, but it would be nice to carry on working for a while
after retirement.
--
Jane
| |
|
| I can't see anybody who's pleading for Excel or VB as a serious
developer, apart from the fact that in those environments 1st of
March 1900 is the 60th day since January 1 (inherited from IBM,
who inherited it from Multi Plan, just by blindly "cutting & pasting").
That's a long time ago but still relevant for insurance companies,
pensionfunds, notary-offices and the like, thus useless for a major
branch in the financial industry, and a huge problem when one stores
dates in a serial format.
Since you mentioned in your earlier post the round-off problem - this
is not imaginary. Just a few examples: try in Excel or any other environment
you mentioned, e.g. a geometrical average, or the price of bonds, results in
a stock portfolio or a simple amortization scheme of an annuity loan - every
day practice. I haven't seen a decent routine for the latter in all of the 8
bln
websites on the net. Neither by the banks, nor by the consultants.
Except one: mine!
They're good in smooth & slick presentations.
Finally, the J-algorithm for finding leapyears:
(2|+/0=4 100 400|/ arg) # arg
(although since 1582 - long before the existence of Excel - after the munks
had spend a few hundred years for asserting the date for Eastern)
Please, tell Microsoft ...
(but I'm wasting my time)
jk
"AA2e72E" <AA2e72E@lycos.co.uk> wrote in message
news:1165303578.493592.173550@j72g2000cwa.googlegroups.com...
>
> jk wrote:
>
> More nonsense?
>
> 1. With today's fastest hardware, it is NOT physically possible to READ
> every byte of one terabyte of data in one second, let alone find every
> byte and do something with it. What does 'handle' actually mean? As far
> as I know, any file on Windows cannot exceed 4GB. So K(db) is using a
> (custom) database? If so, where does that leave your argument about APL
> handling more records than 32000?
>
> 2. K(db) is not APL; it might have its root in APL but it is not
> something that APL (APL+Win, APL/W, APL2, APLX) can just deploy.
>
| |
| AA2e72E 2006-12-05, 3:57 am |
| jk wrote:
> I can't see anybody who's pleading for Excel or VB as a serious developer, apart from the fact that in those environments 1st of March 1900 is the 60th day since January 1
Not 'pleading' simply making you aware that APL is just one of many
tools and the others like Excel and VB have their particular strengths,
sometimes these are also the weaknesses in APL.
How is being a 'serious developer' (or not) have any bearing on the
central argument, namely, 'APL is just one tool in the toolbox and it
needs to learn to share its strengths'?
>A built-in function calculates 1 Mar 1900 as day 60 ...
yes: it can be overridden by setting the base year to 1/1/1904. That's
what is called (bad) legacy; the lesson to learn is not to create a
legacy that becomes binding and prevents future enhancements. APL does
not have any built-in date functionality at all but does possess the
potential for creating unsupportable legacy as its 40 year history
testifies.
> Finally, the J-algorithm for finding leapyears:
As you are peddling algorithms to make a feeble point, here are a
couple for you:
=DOLLAR(("4/"&A1)/7+MOD(19*MOD(A1,19)-7,30)*14%,)*7-6
This formula (not mine!), in a cell (formatted as a date) will
calculate Easter Sunday for the year specified in cell A1 as CCYY; try
it in APL!
I hasten to add, it does not make Excel better or APL worse.
I don't know what APL you use, but try this (APL+Win code) in your APL
also:
[]wcall 'MakeSureDirectoryPathExists'
'c:\one\two\three\four\five\six\seven'
or, VB's equivalent,
Declare Function MakeSureDirectoryPathExists Lib "imagehlp.dll" (ByVal
lpPath As String) As Long
Your code should return 1 for success (whole directory path has been
created, or existed already) or 0 for failure and you cannot make any
assumptions about the directory tree, i.e all or any at its given depth
may exist.
>Except one: mine!
There is no (self or APL) glory in this: the whole point is being able
to produce an application that does what users want, today and
tomorrow; they care little about what was used to produce the
application or how elegant the internal code is. You obviously got it
right in that particular instance; the trick is to repeat that
achievement, using anything or a number of things and not just APL. If
users want to see the data from your APL (or any other) application, so
be it: that is the purpose of the application (give the users what they
want) and the users are the ones paying for it in hard cash.
> (but I'm wasting my time)
I could not agree with you more.
| |
| Jane Sullivan 2006-12-05, 3:57 am |
| In message <45752e09$0$13604$ba620dc5@text.nova.planet.nl>, jk
<gotcha@honey.com> writes
>
>Finally, the J-algorithm for finding leapyears:
>
>(2|+/0=4 100 400|/ arg) # arg
What about 4000: Is it going to be a leapyear or not? :-)
>
>(although since 1582
Only in countries influenced by the pope. England (and hence the US)
changed in 1752, with a consequent loss of 11 days in September. Russia
(or was it the USSR by then?) did not change until some time in the
1920s.
> - long before the existence of Excel - after the munks
>had spend a few hundred years for asserting the date for Eastern)
>Please, tell Microsoft ...
>(but I'm wasting my time)
>jk
>
--
Jane
| |
|
|
"AA2e72E" <AA2e72E@lycos.co.uk> wrote in message
news:1165309729.213204.102460@l12g2000cwl.googlegroups.com...
> jk wrote:
>
you're not merely "Reply"-ing - you're editing too ...
typically Excel practice
[color=darkred]
>
> yes: it can be overridden by setting the base year to 1/1/1904. That's
> what is called (bad) legacy; the lesson to learn is not to create a
maybe they have records of people born before January, 1 1900 ????
(they definitely had in 1980)
"It's not about the will of people, but about their world"
| |
|
|
"Jane Sullivan" <jane@yddraiggoch.demon.co.uk> wrote in message
news:yCFA3fEOYTdFFAAp@yddraiggoch.demon.co.uk...
> In message <45752e09$0$13604$ba620dc5@text.nova.planet.nl>, jk
> <gotcha@honey.com> writes
>
> What about 4000: Is it going to be a leapyear or not? :-)
>
I have no idea ...
>
> Only in countries influenced by the pope. England (and hence the US)
> changed in 1752, with a consequent loss of 11 days in September. Russia
> (or was it the USSR by then?) did not change until some time in the 1920s.
>
(Jane, you should revisite Ray Cannon's article in Vector a couple of years
ago and add this knowledge to his and publish!)
jk
>
> --
> Jane
| |
| AA2e72E 2006-12-05, 3:57 am |
|
Jane Sullivan wrote:
> -- Our little team of three people can write, test and implement the
> enhancements faster than the huge team of C/Java people can go
> through their usual development cycle for the same enhancements.
> Jane
This must be a very common experience. I had the same experience
working on a pensions claims system written in APL2 on the mainframe
(1980's): the PL/1 people could not keep up inspite of having the APL
system to debug their application. As it turned out, the APL system is
still ahead in 2006 (I'm told, I left the company in 1990) and was
never got rid of (users are what counts, I think).
I never got round to answering the questions:
1. Are the APL people just better or the PL/1 people just mediocre? I
prefer yes to the first alternative but it is difficult to prove.
2. The resources it took to give 4/5 people access to the 2MB APL
application would permit a department of 50+ to use the PL/1
application. Which option would (should) the finance manager prefer?
| |
| phil chastney 2006-12-05, 7:56 am |
| mike wrote:
> "phil chastney" <phil.hates.spam@amadeus-info.munged.freeserve.co.uk>
> wrote in message
> news:TV_ch.263888$c42.111079@fe02.news.easynews.com...
> | AA2e72E wrote:
> | > <snip>
> | >
> | > What APL has exclusively are:
> | >
> | > 1. interactive mode that permits code to be tested and ported into
> | > application code.
> |
> | Python has this
> |
> | > <snip again>
> | > e.g. "component files" means nothing outside APL.
> |
> | but all programming languages encounter difficulties when they need
> to
> | share persistent data with other applications, environments, etc
> |
> | regards . . . /phil
>
>
> I have to draw the line on this last point.
>
> The fundamental reason for a relational database is that different
> programs and applications can easily share persistent data with each
> program provided with the logical view that is optimum for that
> programs needs. These capabilities apply across almost all
> languages, COBOL, Fortran, Java, C, C++, ...
>
> Languages such as APL and Lisp that have unique internal data
> representations that force them to rely on some special import /
> export process to access these "shared variables" are the exception.
> Most other languages represent data internally in a form that is close
> or identical to the external format provided in the I/O buffers of the
> file system or the SQL database.
>
> Some vendors are moving to minimize this "impedance mismatch" across
> languages (see APL/NEXT and other .NET developments) where the linkage
> interface has been expanded to include a full object type definition
> which allows APL to directly call or be called by other languages
> without a lot of parameter manipulation specific to the source /
> target language.
fine -- I think I would differ with you only on tenses
one very good reason for using a relational database is to enable
different programs and applications to share persistent data
right now, that is possible, but is not yet easy
for large data volumes, it is necessary to separate the parse, bind and
read operations -- when the subset has been identified, what happens
next? either it goes to disk or main memory
if the main dataset is local, then maybe setting up a view is quick and
convenient -- if the main dataset is remote, it may be desirable to
create a local table -- in either case, you still have to get the data
into memory
reading a table one row at a time is inefficient, and few of us can
accomodate gigabytes of data in main memory, so it is usual to loop
through the data in chunks -- the size of these chunks often requires tuning
then there is the problem of representing that data in structures
acceptable to the processing language (and COBOL, Fortran, Java, C, C++,
etc, cannot process the same set of structures) -- indexing
information is lost, data compression is lost, and there may be a
mismatch of types (if the original data was a smallint, don't assume you
can store it in an int, double it, and then write it back to the db)
OK, so vendors are moving to minimize this "impedance mismatch" across
languages, but I stand by my original assertion that, at this point in
time, there are difficulties
I would also opine that these difficulties are going to be with us for
some time . . . /phil
| |
| phil chastney 2006-12-05, 7:56 am |
| Jane Sullivan wrote:
> In message <45752e09$0$13604$ba620dc5@text.nova.planet.nl>, jk
> <gotcha@honey.com> writes
>
>
>
> What about 4000: Is it going to be a leapyear or not? :-)
I doubt it
item 1: we change calendars every few hundred years anyway
item 2: extrapolating from history, there is a good chance that we shall
be overrun by some culture which (a) introduces a new base date, (b)
moves New Year's Day (to the vernal equinox, say) and/or (c) switches to
the lunar calendar
item 3: failing all that, those clever chaps at the National Physical
will have judiciously added in leap seconds to synchronize atomic time
with astronomic time, sufficient to avoid any need to stray from the
familiar formula
well, that's my guess, and I'm prepared to put money on it
all the best . . . /phil
| |
|
|
| Jane Sullivan 2006-12-05, 6:56 pm |
| In message <1165312518.595406.245390@l12g2000cwl.googlegroups.com>,
AA2e72E <AA2e72E@lycos.co.uk> writes
>
>Jane Sullivan wrote:
>
>This must be a very common experience. I had the same experience
>working on a pensions claims system written in APL2 on the mainframe
>(1980's): the PL/1 people could not keep up inspite of having the APL
>system to debug their application. As it turned out, the APL system is
>still ahead in 2006 (I'm told, I left the company in 1990) and was
>never got rid of (users are what counts, I think).
>
>I never got round to answering the questions:
>
>1. Are the APL people just better or the PL/1 people just mediocre? I
>prefer yes to the first alternative but it is difficult to prove.
I think the answer to that is that neither is better nor worse than the
other. It's just that APL is better than PL/I (or any other language for
that matter) for the tasks in hand.
>2. The resources it took to give 4/5 people access to the 2MB APL
>application would permit a department of 50+ to use the PL/1
>application. Which option would (should) the finance manager prefer?
>
The one that makes the most money for the company. There's always the
salaries of those extra 45 PL/I programmers that won't need paying to
take into account.
--
Jane
| |
| Randy MacDonald 2006-12-05, 6:56 pm |
| Jane Sullivan <jane@yddraiggoch.demon.co.uk> wrote in
news:7SeCD1DjrSdFFAwb@yddraiggoch.demon.co.uk:
....
>
> I am paid to use an APL language. I am one of a team of three people
> whose job is to support a legacy application until the team of many
> more C (++ and #) and Java programmers can replace it. There is a
> prohibition from IT management on writing new stuff in the legacy
> language. However
> -- Our customers (stock traders) insist on enhancements being made
> to
> the legacy system on a daily basis. Their requirements overrule
> the IT prohibition.
> -- Our little team of three people can write, test and implement the
> enhancements faster than the huge team of C/Java people can go
> through their usual development cycle for the same enhancements.
> At the rate they are going, they will never catch up. I hope this
> does not continue for too long, because I am due to retire in
> three years' time, but it would be nice to carry on working for a
> while after retirement.
>
This strikes me as the typical situation: a few APL developers
outperforming a host of FOTM developers, yet the powerful minority is
still targeted for termination. Furthermore, the cry that "we cannot
find APL developers!" leaves silent the faulty assumption that these
developers need to come in batches of dozens or more.
One thing I do find problematic about APL is that it really is too good
to be real, but it is real nonetheless. It is easy to become won over by
it, but it is a hard thing to sell. --
------------------------------------------------------------------------
|\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram)
|/\| ramacd@nbnet.nb.ca |
|\ | | The only real problem with APL is that
BSc(Math) UNBF'83 | it is "still ahead of its time."
Sapere Aude | - Morten Kromberg
Natural Born APL'er | Demo website: http://156.34.74.172/
-----------------------------------------------------(INTP)----{ gnat }-
| |
|
| Jane Sullivan wrote:
> In message <1165146050.277482.145310@j44g2000cwa.googlegroups.com>,
> AA2e72E <AA2e72E@lycos.co.uk> writes
>
> Oh yeah? Have you tried doing this sort of thing on an unindexed field?
> The reason SQL appears to be so quick is because the database maintains
> indexes which effectively are the data already sorted.
I believe that only one field per SQL table can be a clustered index,
and only the clustered index is ordered (and typically it's the primary
key). Indexes, if any, on other columns are not sorted. They do, of
course, make sorting on those fields much faster, but not because
they're already sorted, but because the data doesn't have to be
extracted from the records themselves. Someone please correct me if I'm
wrong here (I'm not a SQL expert but this is what I've been led to
understand).
--
Posted via a free Usenet account from http://www.teranews.com
| |
|
| AA2e72E wrote:
>
> Should a table without an index exist,
>
> 1. fire the DBA and hire one that maintains the database optimally
> 2. in the interim, submit a "CREATE INDEX " SQL to create it for you,
> all from within your own host application that can be APL.
>
> It is not just the speed but the ease with with you can deal with data
> stored in DB using SQL
>
I hope you mean without /at least one/ index (by default, the PK), not
that any field that might possibly ever be sorted on should have an
index. There's a trade-off between adding more indexes and slowing the
system down in general (because all those indexes have to be updated
every time records are added, modified, and deleted). We add indexes to
the most-often-used fields, but there are many that users infrequently
search and sort on that we don't index.
--
Posted via a free Usenet account from http://www.teranews.com
| |
| AA2e72E 2006-12-05, 6:56 pm |
|
RAV, my fleeting understanding of the SQL issues coincides with yours;
I think you are tight (or we are both wrong!).
The real benefit of databases/SQL is that as an application developer I
simply use the available data and all the overhead of ensuring that it
is available, its integrity, backup etc is someone else's (the DBA'a)
problem.
| |
|
| RAV wrote:
> Jane Sullivan wrote:
>
> I believe that only one field per SQL table can be a clustered index,
> and only the clustered index is ordered (and typically it's the primary
> key). Indexes, if any, on other columns are not sorted. They do, of
> course, make sorting on those fields much faster, but not because
> they're already sorted, but because the data doesn't have to be
> extracted from the records themselves. Someone please correct me if I'm
> wrong here (I'm not a SQL expert but this is what I've been led to
> understand).
>
My mistake. I've now been told that even non-clustered indexes are
stored sorted. Sorry for the mis-information.
--
Posted via a free Usenet account from http://www.teranews.com
| |
| Paul Mansour 2006-12-05, 6:56 pm |
| AA2e72E wrote:
>In what way is APL better? What does it have that other languages do
>not have or cannot achieve?
>Is it the fastest? No.
>Is it nested arrays? VB, even VBA and VBScript have this.
>Is it conditional assignment? VB, even VBA has this.
>Is it array processing? Easily achieved with VB; Excel has this, of
>sorts.
>etc.
>etc.
and then:
> There is no question that I like APL nor is there any doubt in my mind
> that APL, as a development language, is superior to virtually every
> other language that I have used (VB, VBA, VBScript, JavaScript, VB.Net,
> C#, Forth & C)
It's really hard to see you as much more than trolling for an argument.
| |
|
| The guy I mentioned a few posts back, who was fired, had four things
in common with AA2e72E:
- he worked in a pension claims dept
- he used Excel for his reports
- he left the company in 1990 (in his case forced, that is), because
- he was editing the system's feedback
(maybe he had the intention to check the figures with his pocket calculator;
I remember a story from Richard Nabavo in his MicroAPL periodical - long
time ago - which tells us about a salesman of VisiCalc ... "you can easily
check these figures [...]" &c&c - got his Casio and started typing ...)
AA2e72E is fooling us and should be fired.
jk
"Paul Mansour" <paul@carlislegroup.com> wrote in message
news:1165341279.466392.200140@16g2000cwy.googlegroups.com...
> AA2e72E wrote:
>
>
> and then:
>
>
> It's really hard to see you as much more than trolling for an argument.
>
| |
| AA2e72E 2006-12-05, 6:56 pm |
| jk wrote:
> AA2e72E is fooling us and should be fired.
jk, if you believe that I would recount my life history in these
threads, you are perhaps more naive than is credible .... "fired" from
what?
And for what? For not agreeing with you that APL is the best thing and
all else should be obliterated? Read the posts again, all I have
maintained is that APL is but one tool in the toolbox and it is out of
sight (so far as the IT industry is concerned) at the bottom: APL can
re-surface again if developers learn to accept all that is around the
workspace. Those like you who are guarding the workspace bastion are
doomed, look around you:
APLX has built in charting and SQL support from within the workspace.
APL/W offers .NET integration from within the workspace.
Need I go on about APL+Win, APL2 and Visual APL?
See the trend? APL is learning to play by the rules: my point is that
APL developers are not and it is time they did.
The comfort zone of the workspace and a quad function for every need is
crumbling from underneath your feet.
I take it you not only tried the Easter Sunday formula and the
MakeSureDirectoryPathExistsAPI and then found that APL is not always
that much superior? Of course your did, you would not be so enraged
unless you found your firm belief shattered.
Calm down now. I have nothing more to say.
| |
| AA2e72E 2006-12-05, 6:56 pm |
|
Paul Mansour wrote:
> It's really hard to see you as much more than trolling for an argument.
I would have preferred you to conclude "It's really hard to see you as
much more than being COERCED into an argument." but you did not inspite
of reading a statement like "Excel is fine for the home budget" as a
defense of APL. No harm done.
However, I am sure that you understand the need for APL to use
databases, after all, you wrote flibDB for that purpose. On your
website, you have described APL/W as the best APL: I can only assume
that is because Dyalog are very innovative. Part of the innovation
includes nampaces, direct definition, full support for the Wndows GUI,
[]na for external (API) calls, and .NET integration etc. All this has
left the APL/W user base well behind: on the Yahoo forum I have asked
for specific examples on the newer features of APL/W several times but
have never had a response; I can only imagine that is the case because
the user base has still not got round to using the new features. I know
I am behind too as I have yet to get to grips with classes in V11 (the
APL mindset does not help!).
Neither pretending that APL is successful nor wishing APL success will
change APL's standing in the IT industry. My point is that APL
developers must take up the challenge and fight back to make APL
succcessful and that can only be done in accordance with industry
rules.
What bothers me a great deal is this:
The design of APL, some 40+ years old, is such that it permits it to
evolve and integrate features that were unheard of at its inception,
seamlessly. Why is it that applications written in APL are not equally
receptive to latter day software innovations? Why is it preferable to
scrap APL applications and rewrite them in other languages? Is it
because developers in other languages are more receptive to new ideas?
Is it because re-inventing everything in APL is an unacceptable
overhead?
| |
|
| for the remaining: you're putting APL and JavaScript (e.g.) in one line
if I had to compose in JavaScript one single promillle of what I did in APL,
I rather die - in other words I'd refuse! If someone would force me to, I'd
take my coat ...
You told us you were working at a pension claims dept., so apparently not
at your neighbour's - the actuarial dept. The claims dept is just "in & out"
administration, to be detached to the ASAP - so that's what you've been
doing? Chapeau!
jk
"AA2e72E" <AA2e72E@lycos.co.uk> wrote in message
news:1165349896.610797.248630@f1g2000cwa.googlegroups.com...
> jk wrote:
>
> jk, if you believe that I would recount my life history in these
> threads, you are perhaps more naive than is credible .... "fired" from
> what?
>
> And for what? For not agreeing with you that APL is the best thing and
> all else should be obliterated? Read the posts again, all I have
> maintained is that APL is but one tool in the toolbox and it is out of
> sight (so far as the IT industry is concerned) at the bottom: APL can
> re-surface again if developers learn to accept all that is around the
> workspace. Those like you who are guarding the workspace bastion are
> doomed, look around you:
>
> APLX has built in charting and SQL support from within the workspace.
> APL/W offers .NET integration from within the workspace.
> Need I go on about APL+Win, APL2 and Visual APL?
>
> See the trend? APL is learning to play by the rules: my point is that
> APL developers are not and it is time they did.
>
> The comfort zone of the workspace and a quad function for every need is
> crumbling from underneath your feet.
>
> I take it you not only tried the Easter Sunday formula and the
> MakeSureDirectoryPathExistsAPI and then found that APL is not always
> that much superior? Of course your did, you would not be so enraged
> unless you found your firm belief shattered.
>
> Calm down now. I have nothing more to say.
>
| |
| AA2e72E 2006-12-05, 6:56 pm |
|
jk wrote:
> for the remaining: you're putting APL and JavaScript (e.g.) in one line
> if I had to compose in JavaScript one single promillle of what I did in APL,
> I rather die - in other words I'd refuse! If someone would force me to, I'd
> take my coat ...
> You told us you were working at a pension claims dept., so apparently not
> at your neighbour's - the actuarial dept. The claims dept is just "in & out"
> administration, to be detached to the ASAP - so that's what you've been
> doing? Chapeau!
> jk
It must be nice you have the option to walk out; I don't have that
option.
By the way, what I actually said was "I had the same experience working
on a pensions claims system written in APL2 on the mainframe" --nothing
about any department, actuarial or otherwise, or where or what country,
nor whether as a contractor or employee.
It is doubtful you will be able to replicate your APL application in
JavaScript as the latter was not designed for application development
i.e. does not have facilities for a GUI. However, you might want to
investigate JavaScript's Array object and compare that with APL's
handling of arrays. If you do, go on to write a WSC component using
JavaScript and use it with APL (possible with APL+Win, APLX and APL/W,
don't know about APL2): it is nothing short of fascinating to see how
the two can exchange array data seamlessly. PS: If you are running
Windows, you already have JavaScript on your PC.
| |
|
| ok, let's make a fair deal; here's my K-script on amortization
of an annuity loan - now you give me your JavaScript version:
(you're being excused if it is more than 30000 lines)
========================================
========
/ Amortization scheme for annuity
/ Variables: amount(bd), duration(d), interest rate(i), marg IRS(IB)
\m f courier new-9
/ \m l arial-8
\m c 0 -1 808080
\p 16
\c 0
/Global functions
f:{100*((1+0.01*x%y)^y)-1} / real interest
vn:{(1+0.01*z%y)^-x*y} / present value
an:{(1-vn[x;y;z])%0.01*z%y} / annuity
sumrnd:{x*(*t)-':t:_.5++\y%x}
/ Dictionaries
\d .k.B
bd: 1.0*120000; bd..l:""; bd..f:12.2$
incbd:"bd+:1000"; decbd:"bd-:1000"
incbd..c:decbd..c:`button
incbd..l:"+"; decbd..l:"-"
incbd..f:16.2$
..k.B..l:"Amount of annuity loan"
..k.B..a:(`bd;`incbd`decbd)
\d .k.nR
nbd: 1.0*0; nbd..l:""; nbd..f:12.2$
incnbd:"nbd+:1000"; decnbd:"nbd-:1000"
incnbd..c:decnbd..c:`button
incnbd..l:"+"; decnbd..l:"-"
..k.nR..l:"Non Repayable"
..k.nR.[`x]:12
..k.nR..a:(`nbd;`incnbd`decnbd)
\d .k.D
d: 30; d..f:4$; d..l:""
incd:"d+:1"; decd:"d-:1"
incd..c:decd..c:`button
incd..l:"+"; decd..l:"-"
..k.D..l:"Duration"
..k.D..a:(`d;`incd`decd)
\d .k.I
i:4.50; i..f:5.2$; i..l:""
inci:"i+:0.01"; deci:"i-:0.01"
inci..c:deci..c:`button
inci..l:"+"; deci..l:"-"
..k.I..l:"Interest rate"
..k.I..a:(`i;`inci`deci)
/In some countries interest paid on a (mortgage) loan is deductable
/from income for IRS;
\d .k.IB
ib:40; ib..f:4$; ib..l:""
incib:"ib+:1"; decib:"ib-:1"
incib..c:decib..c:`button
incib..l:"+"; decib..l:"-"
..k.IB..l:"Marg IRS %"
..k.IB..a:(`ib;`incib`decib)
\d ^
eff..e:ann..e:0
eff..l:" Effective interest rate "
ann..l:" Periodical payment"
Yearly:1; Half_yearly:2; Quarterly:4; Monthly:12
term:`Monthly
term..l:"Frequency of payments"
term..c:`radio
term..o:(`Yearly `Half_yearly `Quarterly `Monthly)
term..x:18
t..d:".$term"
eff..d:"f[I.i;t]"
eff..f:5.2$
ann..d:"B.bd*%an[D.d;t;I.i]"
ann..f:8.2$
tm..d:"!D.d*t"
at..d:"sumrnd[0.01;(ann-B.bd*0.01*I.i%t)*(1+0.01*I.i%t)^!D.d*t]"
it..d:"(nR.nbd*0.01*I.i%t)+ann-at"
ml..d:"at+(1-0.01*IB.ib)*it"
rs..d:"nR.nbd+B.bd-+\\0,-1 _ at"
/ Survey
hdr:`Period`Repayment`Interest`NetPaymen
t`Balance
fs:("6$.k.tm";"13.2$.k.at";"13.2$.k.it";"13.2$.k.ml";"15.2$.k.rs")
comp:{[x;y;z]
a:.,(`e;0)
t:.+(x;y;a)
.[t;(~x;`d);:;z]}
Survey:comp[hdr;&#hdr;fs]
Survey..l:"Survey amortization schedule"
..k..l:"Amortization of Annuity"
..k.. a:((`B`D`I`IB);(`nR;`term;`eff`ann);`Sur
vey) / rearrange display
`show$`.k
========================================
===============
?
jk
"AA2e72E" <AA2e72E@lycos.co.uk> wrote in message
news:1165353477.432125.106450@n67g2000cwd.googlegroups.com...
>
> jk wrote:
>
>
> It must be nice you have the option to walk out; I don't have that
> option.
>
> By the way, what I actually said was "I had the same experience working
> on a pensions claims system written in APL2 on the mainframe" --nothing
> about any department, actuarial or otherwise, or where or what country,
> nor whether as a contractor or employee.
>
> It is doubtful you will be able to replicate your APL application in
> JavaScript as the latter was not designed for application development
> i.e. does not have facilities for a GUI. However, you might want to
> investigate JavaScript's Array object and compare that with APL's
> handling of arrays. If you do, go on to write a WSC component using
> JavaScript and use it with APL (possible with APL+Win, APLX and APL/W,
> don't know about APL2): it is nothing short of fascinating to see how
> the two can exchange array data seamlessly. PS: If you are running
> Windows, you already have JavaScript on your PC.
>
| |
|
|
"phil chastney" <phil.hates.spam@amadeus-info.munged.freeserve.co.uk>
wrote in message news:qzcdh.275465$c42.51184@fe02.news.easynews.com...
| mike wrote:
| > "phil chastney"
<phil.hates.spam@amadeus-info.munged.freeserve.co.uk>
| > wrote in message
| > news:TV_ch.263888$c42.111079@fe02.news.easynews.com...
| > | AA2e72E wrote:
| > | > <snip>
| > | >
| > | > What APL has exclusively are:
| > | >
| > | > 1. interactive mode that permits code to be tested and ported
into
| > | > application code.
| > |
| > | Python has this
| > |
| > | > <snip again>
| > | > e.g. "component files" means nothing outside APL.
| > |
| > | but all programming languages encounter difficulties when they
need
| > to
| > | share persistent data with other applications, environments, etc
| > |
| > | regards . . . /phil
| >
| >
| > I have to draw the line on this last point.
| >
| > The fundamental reason for a relational database is that different
| > programs and applications can easily share persistent data with
each
| > program provided with the logical view that is optimum for that
| > programs needs. These capabilities apply across almost all
| > languages, COBOL, Fortran, Java, C, C++, ...
| >
| > Languages such as APL and Lisp that have unique internal data
| > representations that force them to rely on some special import /
| > export process to access these "shared variables" are the
exception.
| > Most other languages represent data internally in a form that is
close
| > or identical to the external format provided in the I/O buffers of
the
| > file system or the SQL database.
| >
| > Some vendors are moving to minimize this "impedance mismatch"
across
| > languages (see APL/NEXT and other .NET developments) where the
linkage
| > interface has been expanded to include a full object type
definition
| > which allows APL to directly call or be called by other languages
| > without a lot of parameter manipulation specific to the source /
| > target language.
|
| fine -- I think I would differ with you only on tenses
|
| one very good reason for using a relational database is to enable
| different programs and applications to share persistent data
|
| right now, that is possible, but is not yet easy
|
| for large data volumes, it is necessary to separate the parse, bind
and
| read operations -- when the subset has been identified, what happens
| next? either it goes to disk or main memory
|
| if the main dataset is local, then maybe setting up a view is quick
and
| convenient -- if the main dataset is remote, it may be desirable to
| create a local table -- in either case, you still have to get the
data
| into memory
|
| reading a table one row at a time is inefficient, and few of us can
| accomodate gigabytes of data in main memory, so it is usual to loop
| through the data in chunks -- the size of these chunks often
requires tuning
|
| then there is the problem of representing that data in structures
| acceptable to the processing language (and COBOL, Fortran, Java, C,
C++,
| etc, cannot process the same set of structures) -- indexing
| information is lost, data compression is lost, and there may be a
| mismatch of types (if the original data was a smallint, don't assume
you
| can store it in an int, double it, and then write it back to the db)
|
| OK, so vendors are moving to minimize this "impedance mismatch"
across
| languages, but I stand by my original assertion that, at this point
in
| time, there are difficulties
|
| I would also opine that these difficulties are going to be with us
for
| some time . . . /phil
I agree with all of your points.
The issue I would add is that while there is still work involved in
sharing large datasets across languages, that amount of work is not
language independent. Further, historically APL and Lisp are
outliers in this respect needing more work to share data and several
of the other languages I mentioned could more easily work together.
(The example of small integers not holding large numbers is not the
problem here. Any variable must be defined to store all possible
values in its domain or you will have overflow problems. This does
not only apply to numbers and the use of big-num packages but to
character strings that can be far too large or any other data type.
For these reasons that is not a language dependent issue but a
database design issue.)
In an ideal world, we could use several different languages, either
because we inherited legacy code or because the different needs and
algorithms could be better expressed in different languages and then
implement systems with all the pieces working together with no
impediments from cross language issues. In practice we are far from
these goals and this is one of the contributing forces that cause IT
managers to mandate language standards which in turn discriminates
against esoteric and elegant but less popular languages.
Mike Sicilian
| |
| AA2e72E 2006-12-05, 6:56 pm |
|
jk wrote:
> ok, let's make a fair deal; here's my K-script on amortization
> of an annuity loan - now you give me your JavaScript version:
> (you're being excused if it is more than 30000 lines)
You are so gracious or perhaps I misunderstand 'fair deal' as my first
language is French. I have no knowledge of K (nor wish to) and cannot
understand why you might want to pit K against JavaScript, let alone
JavaScript coming from me.
Perhaps you want to find another Actuary who has a mastery of
JavaScript. Better still, you might wonder how the umpteen AVC/pensions
modellers on the internet are producing their answers ... none of them
are using APL as APL cannot be used directly on WEB pages; granted that
APL can generate the html code for other languages but then it is just
producing text strings.
| |
|
|
"AA2e72E" <AA2e72E@lycos.co.uk> wrote in message news:1165355085.410828.91650@73g2000cwn.googlegroups.com...
>
> jk wrote:
>
what a lovely example. it took me about 3 seconds to inspect
the running program: i grabbed a console, started k, cut the
text of the program from the message, and pasted it into the
k session. bingo! (trans: voila!)
do you think it's possible to cut 30,000 lines of anything?
and if so, what would you do with them?
[color=darkred]
>
> You are so gracious or perhaps I misunderstand 'fair deal' as my first
> language is French. I have no knowledge of K (nor wish to) and cannot
> understand why you might want to pit K against JavaScript, let alone
> JavaScript coming from me.
>
> Perhaps you want to find another Actuary who has a mastery of
> JavaScript. Better still, you might wonder how the umpteen AVC/pensions
> modellers on the internet are producing their answers ... none of them
> are using APL as APL cannot be used directly on WEB pages; granted that
> APL can generate the html code for other languages but then it is just
> producing text strings.
>
| |
|
| | I am paid to use an APL language. I am one of a team of three people
| whose job is to support a legacy application until the team of many
more
| C (++ and #) and Java programmers can replace it. There is a
prohibition
| from IT management on writing new stuff in the legacy language.
However
| -- Our customers (stock traders) insist on enhancements being made
to
| the legacy system on a daily basis. Their requirements overrule
the
| IT prohibition.
| -- Our little team of three people can write, test and implement
the
| enhancements faster than the huge team of C/Java people can go
| through their usual development cycle for the same enhancements.
At
| the rate they are going, they will never catch up. I hope this
does
| not continue for too long, because I am due to retire in three
| years' time, but it would be nice to carry on working for a
while
| after retirement.
| Jane
This is a fascinating but often repeated story that is not unique to
APL.
Many, indeed most, new system projects fail. I am inclined to think
this is primarily because of poor specifications and poor design
rather than because of chosen language.
If APL is a major reason for your success, I expect it is because the
language supported development of a good original design by some one
or small group with a real and deep understanding of the problem to be
solved and of likely future needs. Without this understanding
reflected in an application design, it is bound to fail. I would not
be surprised if the original designers of your application were not
programmers but "subject matter experts" and that almost everyone on
the C/Java team is a pure programmer with little knowledge of your
business.
This is not to say that classic IT disciplines have nothing to
contribute and that users should learn APL and just roll their own
systems. Far from it. As I said, most projects fail. Many of those
failures are because systems do not reflect the underlying business
logic but many others fail because they are not scalable or do not
interface with corporate systems. I would bet that most participants
in this group have seen systems implemented in MS-access and or
MS-excel that worked acceptably in a small department but just could
not be deployed in a larger context and had to be totally redesigned.
I think system failures will continue to plague us until we develop
tools that better support the integration of knowledge from both sides
of this equation.
Mike Sicilian
| |
|
| AA2e72E <AA2e72E@lycos.co.uk> produced:
>
> Perhaps you want to find another Actuary who has a mastery of
> JavaScript. Better still, you might wonder how the umpteen AVC/pensions
> modellers on the internet are producing their answers ... none of them
> are using APL as APL cannot be used directly on WEB pages; granted that
> APL can generate the html code for other languages but then it is just
> producing text strings.
>
Actuaries are usually not interested in all the crap on the web
The web is amazing, but actuaries are using their time for
solving problems in the field of risk management in an extremely
sophisticated and solid way. Sometimes they use APL,
sometimes K or J, whatever, but always a high level language and
NEVER HTML, JavaScript, VB or Excel or other kidstuff.
Actuaries do MATH. Math is not popular. Nowadays I see books in
the library on learning math on the computer: well, you can't learn
math on a computer - you learn math with pencil & paper.
So, when can I expect your JavaScript version on amortization of an
annuity loan? Or, better, let me do you a favor. Give me the JavaScript
routine of the algorithm for the leapyear (splitting in two peaces is ok,
in case it wouldn't fit in one email).
(A consolation might be that the decay is omnipresent ,,,
"I could write a book" ).
So don't worry. The web is 8 bln websites
with 99.99**% trash (please fill out the 9's as you prefer). You know what
that leaves worth looking up?
| |
| Mike Kent 2006-12-06, 3:57 am |
| jk wrote:
> K(db) handles 1 Terabyte ... in a second ...
On what hardware? Certainly not on anything as mundane
as a quad-core 3.2GHz Intel box -- even it had a full
TB of RAM.
| |
| AA2e72E 2006-12-06, 3:57 am |
|
jk wrote:
> Actuaries are usually not interested in all the crap on the web
> The web is amazing, but actuaries are using their time for
> solving problems in the field of risk management in an extremely
> sophisticated and solid way. Sometimes they use APL,
> sometimes K or J, whatever, but always a high level language and
> NEVER HTML, JavaScript, VB or Excel or other kidstuff.
Ah!, but that crap (relating to AVC and personal pensions, loan
calculators etc) is designed and approved by Actuaries. See
www.actuary.org to learn what tool actuaries use these days.
> Actuaries do MATH. Math is not popular. Nowadays I see books in
> the library on learning math on the computer: well, you can't learn
> math on a computer - you learn math with pencil & paper.
So, all copies of Maples, MathCAD, Mathematica should be burnt along
with their perpetrators? Besides:
1. MATH is not difficult, no more than any other subject. The problem
with MATH is as you progress deeper into the subject, you may run out
of steam and if that happens when you are not too far in, you also run
out of a career.
2. Successful actuaries do not do MATH, they earn much more money
moving into other domains like management. Only the ones with no other
potential or aptitude carry on doing MATH.
> So, when can I expect your JavaScript version on amortization of an
> annuity loan? Or, better, let me do you a favor. Give me the JavaScript
> routine of the algorithm for the leapyear (splitting in two peaces is ok,
> in case it wouldn't fit in one email).
If you expect me to say that other languages cannot do this, you are
wrong. My 30 year old HP calculator can do the amortisation
calculation: I don't need a computer and software costing tens of
thousand of pounds. Here's the leap year check(from
http://www.hscripts.com/scripts/Jav.../isLeapYear.php):
function checkleapyear(datea)
{
datea = parseInt(datea);
if(datea%4 == 0)
{
if(datea%100 != 0)
{
return true;
}
else
{
if(datea%400 == 0)
return true;
else
return false;
}
}
return false;
}
It corresponds directly with your J version and not only is it readable
but can be supported by a hundred-fold more people than can support J.
Of course you will now post your APL version of the Easter Sunday
calculation, won't you? You have one as every APL person has one!
> (A consolation might be that the decay is omnipresent ,,,
> "I could write a book" ).
> So don't worry. The web is 8 bln websites
> with 99.99**% trash (please fill out the 9's as you prefer). You know what
> that leaves worth looking up?
I don't understand this bit; perhaps that's because my life's not
filled with mortality, morbidity, or persistency.
| |
|
|
"AA2e72E" <AA2e72E@lycos.co.uk> wrote in message
news:1165386856.077902.74480@16g2000cwy.googlegroups.com...
>
[...]
thanks!
> Of course you will now post your APL version of the Easter Sunday
> calculation, won't you? You have one as every APL person has one!
>
No, I don't have one. I never broke my head on that - the munks did.
In stead I'd rather finish this endless, re-chewing with two URLs,
one for serious, one for fun (still pretty serious)
http://www.kx.com
http://www.pandd.demon.nl/
Happy Christmas to all of you!
jk
| |
| AA2e72E 2006-12-06, 3:57 am |
|
jk wrote:
> No, I don't have one. I never broke my head on that - the munks did.
Well, the message is clear.
> Happy Christmas to all of you!
And to you too. During the break you might want to ponder how all the
sophisticated calculations (with or without APL or K or J) ended up in
the fiasco leading to the epidemic of endowment shortfalls, the
billions shortfall in the funds of defined benefit schemes, insurance
companies having to default on their annuity guarantees, the severe
anomalies in the loading of life policies for dread diseases (post
HIV/AIDS), the innacurate assumptions regarding future investment
returns leading to the shrinking of the actuarial reserves of so many
life and pensions offices ..... etc.
I guess, it is sophistication to the tune of terabytes that counts and
nothing else.
| |
| Stefano Lanzavecchia 2006-12-06, 3:57 am |
|
"jk" <gotcha@honey.com> wrote in message
news:45752e09$0$13604$ba620dc5@text.nova.planet.nl...
>I can't see anybody who's pleading for Excel or VB as a serious
> developer, apart from the fact that in those environments 1st of
> March 1900 is the 60th day since January 1 (inherited from IBM,
> who inherited it from Multi Plan, just by blindly "cutting & pasting").
The bug has been fixed long ago. In the more recent versions of Excel
there's even a configuration flag to make it behave in the old buggy way
(for compatibility, otherwise all the dates after February the 29th 1900 in
the legacy spreadsheets would be shifted by one!) or in the correct way.
-- Stefano
| |
| Stefano Lanzavecchia 2006-12-06, 3:57 am |
|
"jk" <gotcha@honey.com> wrote in message
news:4575dd34$0$29567$ba620dc5@text.nova.planet.nl...
> for the remaining: you're putting APL and JavaScript (e.g.) in one line
> if I had to compose in JavaScript one single promillle of what I did in
> APL,
JavaScript is a very powerful and extensible language.
Before you jump on me, please realise that: I make my living by writing APL
code for one of the largest European software houses based almost
exclusively on APL (for any practical point of view you could say "based
exclusively").
Nevertheless, talking purely about the language, I stand with what I just
wrote: JavaScript, as a language, is a very good language. In fact, one of
its problems is that some of the features required by the language make it
hard to implement efficiently. And I do wish the APL had some of JavaScript
distinguishing features, like proper lexical closures and functions as first
class citizens (that means: functions can be passed as arguments to other
functions). I know K has functions as first class citizens. Unfortunately K
does not properly optimize tail recursion, which somewhat limits their
usage. You might say that there's no practical use for any of these
features... well...
-- Stefano
| |
| Stefano Lanzavecchia 2006-12-06, 3:57 am |
| > what a lovely example. it took me about 3 seconds to inspect
> the running program: i grabbed a console, started k, cut the
> text of the program from the message, and pasted it into the
> k session. bingo! (trans: voila!)
>
> do you think it's possible to cut 30,000 lines of anything?
> and if so, what would you do with them?
As far as I know it is now impossible to get a K interpreter from kx.com. I
am afraid that screenful of very concise code must remain for everybody who
wasn't a K fan before today, as opaque as 30000 lines of Javascript which
can be readily run on any Microsoft OS with the wsh installed (almost the
default since IE4 was released).
Don't misunderstand me, Steven: you know how much I admire you and your
proficiency. I am sure you could write wonderful programs in just about any
language, if you felt the desire (more than the need) to do so, and you
rightly chose the language which you thought was the best for your work as
well as your experiments. This said, I am sure you realise that reading a
program and understanding its behaviour is all a matter of practice and
experience. I consider myself (maybe unjustly) a decent APL developer but I
find most of the J samples I read (I am subscribed to the 3 mai | | |