Is LISP dying? 
Author Message
 Is LISP dying?


Quote:
> [Anyone not interested in this off-topic excursion please move down one
page]

> > The term was first used to refer to the colonists in the years just
prior to
> > the American Revolution. Before then (when it was used, which was
apparently
> > not common) it referred to the Native Americans.

> I was more aiming at the fact, that they were called "Europeans" when they
> did bad things, but probably "Americans" when they had done good things.

I haven't really seen that. During the Indian Wars in the West, I've always
seen them called Americans or (less often) Euro-Americans (which I think is
just to heighten the distinction from Native Americans). African-Americans
were more often associated with the Indians (i.e., runaway slaves), though
after the Civil War the U.S. Army did field some black regiments (both foot
and cavalry) under white officers.

Quote:
> > > They call us "Oh-Bei-Jin" = European-American-Person(s).

> > My understanding is that an accurate translation of that term is a bit
less
> > flattering than that...

> Your understanding is wrong then. The translation is literal:
> "Oh" for Europe, "Bei" for America and "Jin" for Person(s).

I must've been confusing it with another term, then.

Quote:
> The only flattening thing for you, perhaps is, that Europe comes first.
;-)

> BEI actually means Rice (in form of harvested crop) but has in this form
> turned into the meaning of America. This is because of the way you write
> America in chinese characters AH-MEI-LI-KA. The only distinctive character
> in there is MEI, BEI is a different pronounciation of that character (like
> multiple bindings for a variable in a programming language). The form
> nowadays used is short BEI-KOKU (Rice Country) for America. In China they
> use the character "Beautiful", pronounced MEI instead of "Rice", which
> also stems from AH-MEI-LI-KA, but this time the short form MEI-GUO means
> "Country of Beauty".

> When matching a foreign term to chinese characters the aim is always to
> find characters that do not only resemble the pronounciation but also have
> positive meanings. In Japan rice is a sacred commodity, the term rice
> country for America is an honour, not flattening at all. Characters chosen
> for other countries support this: England -> Brightness, Shining; France
> -> Religious, Buddha;

> Of particular interest in this context is the character for Germany. The
> original character, which is still being used in China means Morality,
> Virtue, Privilege. The new character used after a reform under American
> occupation means: bureaucratic, self righteous and dictatorial depending
> on context.

> As you can see the "flattening influence" here was american ;-) but you
> might perhaps argue that the Germans had deserved the loss of the
> character Morality in their country's name, having started two world wars
> and all the rest of it.

> This is not intended an offense. I myself would probably have left the
> Japanese their character for Germany, if just for the sake of
> compatibility with Chinese.

Thanks. Off-topic but very interesting.

Larry



Fri, 18 Jan 2002 03:00:00 GMT  
 Is LISP dying?


Quote:
> "English (Scotts, Welsh)"

[good points omitted]

AIUI, that should be Scots. Just the one 't'.

Quote:
> it's like writing "the Yankees (Canadians, Mexicans)..."

This is why I try to be very relaxed about technical issues. There's
enough _real_ politics to get hot under the collar about. For example,
the island that I live on may sometimes be (incorrectly) called
England, but to some it's also "the mainland". You don't get more
political than that! Until programmers start kneecaping each other,
I'm not going waste any time in language wars.

Lisp and Forth may be minority languages, but then so is any language
not called Cobol. ;) You mentioned Welsh but were you thinking of the
Welsh language? Is that dying? It's a contentious subject.
--
Please note: my email address is munged; You can never browse enough
         "There are no limits." -- tagline for Hellraiser



Fri, 18 Jan 2002 03:00:00 GMT  
 Is LISP dying?

Quote:
> > "English (Scotts, Welsh)"
> AIUI, that should be Scots. Just the one 't'.

Boy - what a lapsus :-) :-) :-) My apologies. Must have been late... ;-)

Quote:
> Lisp and Forth may be minority languages, but then so is any language
> not called Cobol. ;)

Very true (infortunately IMHO).

benjamin

--
As an anti-spam measure I have scrambled my email address here.
Remove "nospam-" and ROT13 to obtain my email address in clear text.



Fri, 18 Jan 2002 03:00:00 GMT  
 Is LISP dying?

Quote:
Benjamin Kowarsch wrote...

>> Lisp and Forth may be minority languages, but then so is any language
>> not called Cobol. ;)
>Very true (infortunately IMHO).

ok, this thread has lost it already so i don't
feel too bad about adding more OT stuff...

is this 'more lines of COBOL than all...' bit
actually still true?
ok, when the only competition was fortran,
LISP, ALGOL, PL/1, whatever, i'm sure it was
but in  1999?
naaa!
what do you think (or know)?



Fri, 18 Jan 2002 03:00:00 GMT  
 Is LISP dying?

Quote:

> Benjamin Kowarsch wrote...

> >> Lisp and Forth may be minority languages, but then so is any language
> >> not called Cobol. ;)
> >Very true (infortunately IMHO).

> ok, this thread has lost it already so i don't
> feel too bad about adding more OT stuff...

> is this 'more lines of COBOL than all...' bit
> actually still true?
> ok, when the only competition was FORTRAN,
> LISP, ALGOL, PL/1, whatever, i'm sure it was
> but in  1999?
> naaa!
> what do you think (or know)?

Old programs never die, never die, never die.
Old programs never die, they don't even* fade away.

*Remove "even" if you want it to scan.

I know a few programmers who have been working on Y2K issues for over a
year. Most of their HLL work has been on COBOL. Some of these programs
are so old that the documentation has been lost, and often nobody knows
all of their functions or interfaces. There are few enough COBOL
programmers left so that one of them came out of retirement to join the
fun. From this anecdotal evidence, I would say that COBOL is more alive
than Latin.

Jerry
--
Engineering is the art       |      Let's talk about what
of making what you want      |      you need; you may see
from things you can get.     |      how to do without it.
---------------------------------------------------------



Fri, 18 Jan 2002 03:00:00 GMT  
 Is LISP dying?

Quote:

>> > "English (Scotts, Welsh)"

>> AIUI, that should be Scots. Just the one 't'.

>Boy - what a lapsus :-) :-) :-) My apologies. Must have been late... ;-)

        Hey, yeah! Even if I parenthesised my ancestors incorrectly, I
spelled them good!
        I promise I won't tell anyone, though.

(
----------
Virtually,

Bruce McFarling, Newcastle,

)



Fri, 18 Jan 2002 03:00:00 GMT  
 Is LISP dying?

Quote:
> > is this 'more lines of COBOL than all...' bit
> > actually still true?
> > ok, when the only competition was FORTRAN,
> > LISP, ALGOL, PL/1, whatever, i'm sure it was but in  1999?

COBOL is *still* being used for new implementations of billing software
these days. Also, COBOL data structures and databases are being used
(CODASYL).

Take your phone bill or utilities bill as example. The chance is, that it
has been created by COBOL code. One strong incentive to use COBOL for
billing is the built in support of BCD (binary coded decimals), which
ensures there is no inaccurracy intruduced when converting numbers between
decimal and binary.

There is only very few languages who support that, such, that writing
arithmetic expressions can be done using infix notation. In many languages
there is no BCD at all and it would have to be bolted on and the libraries
rewritten from scratch. I was once taking part in the standardisation of
Modula-2 and had proposed BCDs to be specified in the standard so the
language could have been an alternative to using COBOL. Unfortunately, the
notion in the WG was such, that there would have been no infix expressions
with BCDs, so I withdrew my proposal, as it didn't make sense under these
circumstances.

LISP integers is about the only thing, that comes to my mind to offer
something to the needs of billing people in this regard (usually only two
decimal digits are required, so you just multiply everything by 100), also
ratios are helpful.

But unlike many LISP people, COBOL and billing software developers are
often people with an accounting background, they are not computer language
scientists. They are more likely to think in procedural ways than in OO
and they would have a severe problem with LISPs syntax. If someone would
write a language on top of LISP to take bookkeeper's accounting statements
as source, along with some features that make a transition from COBOL
easy, many people would embrace it.

Though I personally don't like it, I expect COBOL to continue a long life.

Quote:
> I know a few programmers who have been working on Y2K issues for over a
> year. Most of their HLL work has been on COBOL. Some of these programs
> are so old that the documentation has been lost, and often nobody knows
> all of their functions or interfaces. There are few enough COBOL
> programmers left so that one of them came out of retirement to join the
> fun.

All this is true. Even worse. For many programs there is no source code.
They have been maintained for decades by patching their executables.

However, the Y2K bug is not really COBOL's fault. You can define date
fields to accommodate more than two digits. But, remember who these COBOL
programmers were: Accounting people. They knew memory was expensive and
they heard the cash register ringing every time they declared a variable,
hence the notion to shorten that where it felt appropriate.

Quote:
> From this anecdotal evidence, I would say that COBOL is more alive than Latin.

You'd be surprised how alive Latin is. I remember math classes at
university, especially analytical geometry where our professors
recommended tons of books for us to read and the only one that was neither
in Ancient Greek nor in Latin would have been someting in French by Blaise
Pascal. Not a single recommendation for a book in English and many of
those books didn't have a publicly accessible translation at all. The
Greek ones all had translations into Latin, though. ;-)

Lingua latina vivanda est ;-)  -- no guarantees for grammatical correctness ;-)

benjamin

--
As an anti-spam measure I have scrambled my email address here.
Remove "nospam-" and ROT13 to obtain my email address in clear text.



Sat, 19 Jan 2002 03:00:00 GMT  
 Is LISP dying?
Quote:


> > Benjamin Kowarsch wrote...

> > >> Lisp and Forth may be minority languages, but then so is any language
> > >> not called Cobol. ;)
> > >Very true (infortunately IMHO).

> > ok, this thread has lost it already so i don't
> > feel too bad about adding more OT stuff...

> > is this 'more lines of COBOL than all...' bit
> > actually still true?
> > ok, when the only competition was FORTRAN,
> > LISP, ALGOL, PL/1, whatever, i'm sure it was
> > but in  1999?
> > naaa!
> > what do you think (or know)?

> Old programs never die, never die, never die.
> Old programs never die, they don't even* fade away.

> *Remove "even" if you want it to scan.

> I know a few programmers who have been working on Y2K issues for over a
> year. Most of their HLL work has been on COBOL. Some of these programs
> are so old that the documentation has been lost, and often nobody knows
> all of their functions or interfaces. There are few enough COBOL
> programmers left so that one of them came out of retirement to join the
> fun. From this anecdotal evidence, I would say that COBOL is more alive
> than Latin.

> Jerry

----------------------------------
Arma virumque cano Troiae qui primus ab oris
Italiam fato profugus Laviniaque venit
Litora multe ille et terris jactatus et alto
Qui superum saevae memorem Junonis ab iram

Nope, stil works...
-Steve
--

-Electronics Site!! 1000 Files/50 Dirs!! http://www.armory.com/~rstevew
Europe Naples Italy: http://ftp.unina.it/pub/electronics/ftp.armory.com



Sat, 19 Jan 2002 03:00:00 GMT  
 Is LISP dying?

Quote:

> However, the Y2K bug is not really COBOL's fault. You can define
> date fields to accommodate more than two digits.

There is a standard command to get the current date in COBOL.  This
command returned 2 digits for the year.  There is _no_ standard way of
getting the current century in COBOL.

There is a new ANSI COBOL standard in the works, which among other
things includes system support for four-digit years.  This standard
has an ETA of some time next year...  

I assume this is a standard which codifyies existing practice, so that
people can fix this already.  The timing is still ironic.  :-)

Stig Hemmer,
Jack of a Few Trades.

PS: I read a COBOL text book last revised in 1993.  It contained no
   mention of the Y2K problem anywhere.  Sigh.



Sat, 19 Jan 2002 03:00:00 GMT  
 Is LISP dying?

Quote:

> Take your phone bill or utilities bill as example. The chance is, that it
> has been created by COBOL code. One strong incentive to use COBOL for
> billing is the built in support of BCD (binary coded decimals), which
> ensures there is no inaccurracy intruduced when converting numbers between
> decimal and binary.

> There is only very few languages who support that, such, that writing
> arithmetic expressions can be done using infix notation. In many languages
> there is no BCD at all and it would have to be bolted on and the libraries
> rewritten from scratch. I was once taking part in the standardisation of
> Modula-2 and had proposed BCDs to be specified in the standard so the
> language could have been an alternative to using COBOL. Unfortunately, the
> notion in the WG was such, that there would have been no infix expressions
> with BCDs, so I withdrew my proposal, as it didn't make sense under these
> circumstances.

Ada has complete support for this type of thing, so you could have
stayed in the Pascal family ;-)

I find it odd Ada has not been more successfull for things like
accounting, billing systems, etc. It's practically designed for it.

--

If there are aliens, they play Go. -- Lasker



Sat, 19 Jan 2002 03:00:00 GMT  
 Is LISP dying?
Quote:

> > > is this 'more lines of COBOL than all...' bit
> > > actually still true?
> > > ok, when the only competition was FORTRAN,
> > > LISP, ALGOL, PL/1, whatever, i'm sure it was but in  1999?

> COBOL is *still* being used for new implementations of billing software
> these days. Also, COBOL data structures and databases are being used
> (CODASYL).

> Take your phone bill or utilities bill as example. The chance is, that it
> has been created by COBOL code. One strong incentive to use COBOL for
> billing is the built in support of BCD (binary coded decimals), which
> ensures there is no inaccurracy intruduced when converting numbers between
> decimal and binary.

[Interestinh text snipped.]

I'm confused about the need for BCD. Surely, there can be no ambiguity
when converting (scaled) integer values to and from decimal notation for
I/O. Making the scaling factor 1000 to keep track of mils still leaves
room for representing plenty of dollars in a 32-bit signed int. (Few
transactions exceed 2 million.) By using a double, Forth can represent
in a single number more money that the treasuries, budgets, or debts of
most countries. What's the problem?

Quote:

> benjamin

> --
> As an anti-spam measure I have scrambled my email address here.
> Remove "nospam-" and ROT13 to obtain my email address in clear text.

Please clue me in about ROT13.

Jerry
--
Engineering is the art       |      Let's talk about what
of making what you want      |      you need; you may see
from things you can get.     |      how to do without it.
---------------------------------------------------------
--
Engineering is the art       |      Let's talk about what
of making what you want      |      you need; you may see
from things you can get.     |      how to do without it.
---------------------------------------------------------



Sat, 19 Jan 2002 03:00:00 GMT  
 Is LISP dying?

Quote:


> Whoops.  In my prior post, I had forgotten about the utterly brain-dead (as
> far as I'm concerned, outright BUG) behavior of the WITHIN ANSI Forth word.
> Therefore, to make a CORRECT version of WITHIN, please prepend the following
> definition, like so:

> ( This definition inherits from the existing ANSI definition of WITHIN )
> : WITHIN (a b c -- f )          1+ WITHIN ;

> Alternatively, you could make the following adjustments to retain ANSI
> compatibility:

> >: LowercaseLetter? ( ch -- f )  [CHAR] a [CHAR] z WITHIN ;

> : LowercaseLetter? ( ch -- f)   [CHAR] a [CHAR] z 1+ WITHIN ;

> >: A..M? ( ch -- f )             ToUppercase [CHAR] A [CHAR] M WITHIN ;
> >: A..Z? ( ch -- f )             ToUppercase [CHAR] A [CHAR] Z WITHIN ;

> : A..M? ( ch -- f )             ToUppercase [CHAR] A [CHAR] M 1+ WITHIN ;
> : A..Z? ( ch -- f )             ToUppercase [CHAR] A [CHAR] Z 1+ WITHIN ;

> All other program code remains the same.  I apologize for any confusion this
> may have caused.

> ==========================================================================
>       KC5TJA/6     |                  -| TEAM DOLPHIN |-
>         DM13       |                  Samuel A. Falvo II
>     QRP-L #1447    |          http://www.dolphin.openprojects.net
>    Oceanside, CA   |......................................................

Thanks for the code, and particularly the algorithm. There was no
confusion, as I saw both posts at the same time.

I want to defend WITHIN as it stands. If it has a flaw, it is the name,
but I can't think of a better one. It works with signed and unsigned
numbers provided that you are consistent, and it executes much faster
(at least when assembly coded) than a more intuitive version would. Here
is my version in 69HC11 code for MAXforth, which lacked one:
CODE WITHIN ( n lo-limit hi-limit+1 -- f ) \ 101 cycles
 18EC , 00 C, \ LDD 0,Y  hi
 18A3 , 02 C, \ SUBD 2,Y sub lo
 18ED , 00 C, \ STD 0,Y  hi - lo
 18EC , 04 C, \ LDD 4,Y  n  
 18A3 , 02 C, \ SUBD 2,Y sub lo
 18A3 , 00 C, \ SUBD 0,Y sub hi - lo
 1808 ,       \ INY
 1808 ,       \ INY
 1808 ,       \ INY
 1808 ,       \ INY
 24 C, 06 C,  \ BCC no
 CC C, -1 ,   \ LDD -1
 7E C, FE47 , \ JMP NEXTSD
\ no
 CC C, 0 ,    \ LDD 0
 7E C, FE47 , \ JMP NEXTSD

It would take a few more cycles to replace "hi-limit+1" with "hi-limit"
in the stack comment. Since it is frequently used with constant
arguments, they can often be adjusted at compile time, and extra code so
isn't worth while.

Jerry
--
Engineering is the art       |      Let's talk about what
of making what you want      |      you need; you may see
from things you can get.     |      how to do without it.
---------------------------------------------------------



Sat, 19 Jan 2002 03:00:00 GMT  
 
 [ 433 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software