Logs for ShadowRN and Associated Mailing Lists

From:	Michael Orion Jackson <orion@****.CC.UTEXAS.EDU>
Subject:	[semi-OT] programming languages' evolution
Date:	Thu, 28 Jan 1999 16:20:57 -0600

Message no. 1 I can't remember if this has been discussed on the SR list (well,
recently anyway, I seem to recall seeing something similar but I've been
on since fall of 94 and things kinda blur together farther back), but has
anyone thought about what languages our decker characters and other
assorted computer folk will be using 60 years from now? What directions
do you think computer languages will take in that time? (Similar to
languages shifting from functional to object-oriented in terms of focus of
new development (even languages that were not previously OO are beginning
to gain OO functionality (the one example that springs to mind is perl))).
Or, do you think that the same languages might still be in common use?
(Like VC++ version 60.0 or something.) The talk of the SR-III program got
me thinkning about this. BTW, what language are y'all using? I was
thinking of trying to do something simple in perl/Tk but I don't have much
free time at all, what with CH 354... (quantum mechanics)
Anyhow, happy coding!
mike

*****************Michael Orion Jackson******************
***********TAMS Class of 96/UT Class of 2000************
*********************Random Quote:**********************
*****Technology is not for wimps. Member: DNRC (iS)*****
********************************************************

From:	Paul Gettle <RunnerPaul@*****.COM>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Thu, 28 Jan 1999 17:31:54 -0500

Message no. 2 -----BEGIN PGP SIGNED MESSAGE-----

At 04:20 PM 1/28/99 -0600, Mike wrote:
> I can't remember if this has been discussed on the SR list
(well,
>recently anyway, I seem to recall seeing something similar but I've
been
>on since fall of 94 and things kinda blur together farther back), but
has
>anyone thought about what languages our decker characters and other
>assorted computer folk will be using 60 years from now?

BBB3, p. 295:
"Common programming languages in the Sixth World include HoloLISP,
InterMod, MATCom, and Oblong."

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.0.2

iQCVAwUBNrDlSqPbvUVI86rNAQHMGQP7ByFVItDB1JEUKCrFVPEHNdqZvj2iZLD4
cTKktQIEj25QKHCgqWFTGOW8koMAVALKRIymCKaeqOhtTTuOFdyMyeurONV+gQ7/
qzlfHDwBBz9lU+Y0kg4MEhdzqjAt1vDzbY7ZqyQqlfdyfsoAv0AGB3rTNlmgvKI/
m6YTDKf7ZlM=
=ewX7
-----END PGP SIGNATURE-----

--
-- Paul Gettle, #970 of 1000 (RunnerPaul@*****.com)
PGP Fingerprint, Key ID:0x48F3AACD (RSA 1024, created 98/06/26)
C260 94B3 6722 6A25 63F8 0690 9EA2 3344

From:	Adam J <adamj@*********.HTML.COM>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Thu, 28 Jan 1999 15:44:36 -0700

Message no. 3 At 16:20 1/28/99 -0600, Michael Orion Jackson wrote:
> I can't remember if this has been discussed on the SR list (well,
>recently anyway, I seem to recall seeing something similar but I've been
>on since fall of 94 and things kinda blur together farther back), but has
>anyone thought about what languages our decker characters and other
>assorted computer folk will be using 60 years from now? What directions
>do you think computer languages will take in that time? (Similar to
>languages shifting from functional to object-oriented in terms of focus of
>new development (even languages that were not previously OO are beginning
>to gain OO functionality (the one example that springs to mind is perl))).
>Or, do you think that the same languages might still be in common use?
>(Like VC++ version 60.0 or something.)

Ack. I had a couple paragraphs written here, but I couldn't express my
thoughts clearly. Except a decking/computer net.book from me sometime this
year. (Yes, I know that gives me 11 months. ;-)

>The talk of the SR-III program got
>me thinkning about this. BTW, what language are y'all using?

The core of PS '98 and the modules that I'm doing are VB5. Modules can be
written in any language that can create ActiveX DLLs.

I'm installing linux sometime within the next couple weeks (Depending on
when my CDs arrive (No, I'm not downloading 300+ megs)), and once I get
comfortable with it I want to do a Open Source linux version, but that's a
long ways away.

-Adam J
--
< http://shadowrun.html.com/tss / adamj@*********.html.com >
< ShadowRN Assistant Fearless Leader / TSA Co-Admin / ICQ# 2350330 >
< FreeRPG & Shadowrun Webring Co-Admin / The Shadowrun Supplemental >
< ShadowFAQ: http://shadowrun.html.com/shadowfaq >
< "I know one thing, it's about damn time I got new entrance music.">
< -Mankind, 01/10/99 RAW is WAR. >

From:	Penta <cpenta@*****.COM>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Thu, 28 Jan 1999 17:48:29 -0800

Message no. 4 Adam J wrote:<kersnip>

> Ack. I had a couple paragraphs written here, but I couldn't express my
> thoughts clearly. Except a decking/computer net.book from me sometime this
> year. (Yes, I know that gives me 11 months. ;-)

<snip 2>

> The core of PS '98 and the modules that I'm doing are VB5. Modules can be
> written in any language that can create ActiveX DLLs.
>
> I'm installing linux sometime within the next couple weeks (Depending on
> when my CDs arrive (No, I'm not downloading 300+ megs)), and once I get
> comfortable with it I want to do a Open Source linux version, but that's a
> long ways away.
>
> -Adam J

<snip sig>

OK. Adam, a plea:When ya post PS 98, PLEASE post the files we'll need to run it
(the VB5 files) along with it. I know from experience the various VB files can
be PAINFULLY hard to find.

JCP

From:	Adam J <adamj@*********.HTML.COM>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Thu, 28 Jan 1999 16:11:09 -0700

Message no. 5 At 17:48 1/28/99 -0800, Penta wrote:

>OK. Adam, a plea:When ya post PS 98, PLEASE post the files we'll need to
run it
>(the VB5 files) along with it. I know from experience the various VB files can
>be PAINFULLY hard to find.

Of course. I'm still not entirely sure how I'm going to do the setup (An
install from the web that installs only the needed files is tempting, but
it can't be the only install method.), but rest assured you won't be
getting "MSVBVM50.dll is missing" errors.

BTW, all VB runtime files can be found here:
http://www.softseek.com/Utilities/VBRUN_Files/

Beta testing (private) commences this weekend, I hope.

In other news, TSS-09 should be out tommorrow, at least the DOC/PDF versions.

-Adam
--
< http://shadowrun.html.com/tss / adamj@*********.html.com >
< ShadowRN Assistant Fearless Leader / TSA Co-Admin / ICQ# 2350330 >
< FreeRPG & Shadowrun Webring Co-Admin / The Shadowrun Supplemental >
< ShadowFAQ: http://shadowrun.html.com/shadowfaq >
< "I know one thing, it's about damn time I got new entrance music.">
< -Mankind, 01/10/99 RAW is WAR. >

From:	Robert Watkins <robert.watkins@******.COM>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Fri, 29 Jan 1999 09:13:14 +1000

Message no. 6 Adam J writes:
> I'm installing linux sometime within the next couple weeks (Depending on
> when my CDs arrive (No, I'm not downloading 300+ megs)), and once I get
> comfortable with it I want to do a Open Source linux version, but that's a
> long ways away.

Hmmm... expect to get comfortable with a new scripting language... unless
you want to be a proper programmer and rewrite it in C/C++. :)

(Personally, I'd recommend TCL/TK, with maybe some C++ backbone code, but
that's just me... I like the TK widget set)

As for the person who wanted Adam to post the VB runtime DLLs... you can
download them from the Microsoft web site fairly readily. But Adam may hit
redistribution problems if he posts them (Microsoft's redistribution
agreements can be incredibly wierd sometimes).

--
Duct tape is like the Force: There's a Light side, a Dark side, and it
binds the Universe together.
Robert Watkins -- robert.watkins@******.com

From:	"D. Ghost" <dghost@****.COM>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Thu, 28 Jan 1999 21:41:46 -0600

Message no. 7 On Thu, 28 Jan 1999 17:31:54 -0500 Paul Gettle <RunnerPaul@*****.COM>
writes:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>At 04:20 PM 1/28/99 -0600, Mike wrote:
>> I can't remember if this has been discussed on the SR list
(well,
>>recently anyway, I seem to recall seeing something similar but I've
been
>>on since fall of 94 and things kinda blur together farther back), but
has
>>anyone thought about what languages our decker characters and other
>>assorted computer folk will be using 60 years from now?

>BBB3, p. 295:
>"Common programming languages in the Sixth World include HoloLISP,
>InterMod, MATCom, and Oblong."

And COBOL... You *know* COBOL just can not and will not die ... ;)

Actually, I kind of wish SR had done what Cyberspace did: detailed a few
programming languages and the benefits/penalties for using those. (My
favorite was, of course, machine language...+30 bonus to the programming
task and -25% to job-time of tasks performed by the program ... However,
they should say that you should square the time to write the damn thing
... ;)

--
D. Ghost
(aka Pixel, Tantrum, RuPixel)
"We called him Mother Superior because of the length of his habit" --
Trainspotting
"A magician is always 'touching' himself" --Page 123, Grimoire (2nd
Edition)

___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]

From:	K in the Shadows <Ereskanti@***.COM>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Thu, 28 Jan 1999 23:45:33 EST

Message no. 8 In a message dated 1/28/1999 10:54:20 PM US Eastern Standard Time,
dghost@****.COM writes:

>
> >BBB3, p. 295:
> >"Common programming languages in the Sixth World include HoloLISP,
> >InterMod, MATCom, and Oblong."
>
> And COBOL... You *know* COBOL just can not and will not die ... ;)
>
> Actually, I kind of wish SR had done what Cyberspace did: detailed a few
> programming languages and the benefits/penalties for using those. (My
> favorite was, of course, machine language...+30 bonus to the programming
> task and -25% to job-time of tasks performed by the program ... However,
> they should say that you should square the time to write the damn thing

You know something D. Ghost, I think I can help us all out a *Bit* in that
department. Give me time though of course (I am concentrating on HHH like
nobody's biz ATM).

-K

From:	Mark A Shieh <SHODAN+@***.EDU>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Fri, 29 Jan 1999 00:48:44 -0500

Message no. 9 Michael Orion Jackson <orion@****.CC.UTEXAS.EDU> writes:
> I can't remember if this has been discussed on the SR list (well,
> recently anyway, I seem to recall seeing something similar but I've been
> on since fall of 94 and things kinda blur together farther back), but has
> anyone thought about what languages our decker characters and other
> assorted computer folk will be using 60 years from now? What directions
> do you think computer languages will take in that time? (Similar to
> languages shifting from functional to object-oriented in terms of focus of
> new development (even languages that were not previously OO are beginning
> to gain OO functionality (the one example that springs to mind is perl))).

Maybe I've missed something, but I thought that being
object-oriented had nothing to do with whether a language was
functional or iterative. C, with the addition of C++, and LISP, with
the addition of CLOS, are both OO.

> BTW, what language are y'all using? I was
> thinking of trying to do something simple in perl/Tk but I don't have much
> free time at all, what with CH 354... (quantum mechanics)

My job involves working with a LISP scheduler and a Java front
end (and PERL for build and distribution scripts, if you count that).
Development is happening under Solaris, but we're also porting to
WinNT. I'd rather not talk about the details, as it gives me a
headache.

Free coding happens in PERL or C/C++, whichever is clearly
applicable. Usually, I write in ANSI C, or as close to system
independent code as I can manage. I've been making an exception on my
latest project to try to learn MFC.

Needless to say, I'm absolutely convinced that if a language
becomes viable enough that coding is done in it on a regular basis,
the language will always turn up in unexpected places. I fully expect
Fastjack to pull out some absurd Cobol code, if only for the reason
that the system will attempt to analyze the program and fail
completely. According to some of my undergrad friends, SML is making
a revival in the classes at CMU due to the damn theorists getting
ahead in the political games. They're even making converts among the
naive.

Mark

From:	K in the Shadows <Ereskanti@***.COM>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Fri, 29 Jan 1999 08:08:02 EST

Message no. 10 In a message dated 1/29/1999 12:51:58 AM US Eastern Standard Time,
SHODAN+@***.EDU writes:

>
> Maybe I've missed something, but I thought that being
> object-oriented had nothing to do with whether a language was
> functional or iterative. C, with the addition of C++, and LISP, with
> the addition of CLOS, are both OO.

Mark, you mention "LISP". One of the known comp languages of SR Matrix is
"HoloLISP". So somewhere along the lines they get changed over. If we knew
what LISP was better at doing than say, "C++", perhaps we could formulate what
taking a specific language would be good for doing>

-K

From:	"Ojaste,James [NCR]" <James.Ojaste@**.GC.CA>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Fri, 29 Jan 1999 09:54:09 -0500

Message no. 11 K in the Shadows wrote:
> > Maybe I've missed something, but I thought that being
> > object-oriented had nothing to do with whether a language was
> > functional or iterative. C, with the addition of C++, and LISP, with
> > the addition of CLOS, are both OO.
>
> Mark, you mention "LISP". One of the known comp languages of SR Matrix is
> "HoloLISP". So somewhere along the lines they get changed over. If we
> knew
> what LISP was better at doing than say, "C++", perhaps we could formulate
> what
> taking a specific language would be good for doing>
>
LISP is better at a) recursion and b) list handling. Or rather, LISP
can only do a) recursion and b) list handling, so it's damned good at
them. :-) LISP is a functional language.

C is better at raw math, iterative loops, raw data processing -
basically low level stuff (C is basically a pretty wrapper for
assembly). C is a procedural language.

C++? Which C++? There's no C++ standard yet... C++ is a pretty
(well it's *supposed* to be pretty) wrapper for C ("just pretend that
this word 'object' means 'struct' and you'll be fine").

Procedural languages basically make the world go round. They're
basically "do a, then do b, then do c" stuff. Functional languages
get to do cool stuff like rewrite themselves, but they're harder to
write and slower to run. Functional languages are like "do this
(based on this info (which is based on this info (which in turn...)))".
Counting brackets can get tedious. :-)

James Ojaste

From:	A Halliwell <u5a77@*****.CS.KEELE.AC.UK>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Fri, 29 Jan 1999 17:21:01 +0000

Message no. 12 And verily, did Adam J hastily scribble thusly...
|I'm installing linux sometime within the next couple weeks (Depending on
|when my CDs arrive (No, I'm not downloading 300+ megs)),

Ahhhhh... Another one saved...
:)

and once I get
|comfortable with it I want to do a Open Source linux version, but that's a
|long ways away.

Which distro are you getting?

--
-----------------------------------------------------------------------------
|u5a77@*****.cs.keele.ac.uk| Windows95 (noun): 32 bit extensions and a |
| | graphical shell for a 16 bit patch to an 8 bit |
| Andrew Halliwell | operating system originally coded for a 4 bit |
| Finalist in:- |microprocessor, written by a 2 bit company, that|
| Computer Science | can't stand 1 bit of competition. |
-----------------------------------------------------------------------------
|GCv3.1 GCS/EL>$ d---(dpu) s+/- a- C++ U N++ o+ K- w-- M+/++ PS+++ PE- Y t+ |
|5++ X+/++ R+ tv+ b+ D G e>PhD h/h+ !r! !y-|I can't say F**K either now! :( |

From:	A Halliwell <u5a77@*****.CS.KEELE.AC.UK>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Fri, 29 Jan 1999 17:26:59 +0000

Message no. 13 And verily, did Robert Watkins hastily scribble thusly...
|
|Adam J writes:
|> I'm installing linux sometime within the next couple weeks (Depending on
|> when my CDs arrive (No, I'm not downloading 300+ megs)), and once I get
|> comfortable with it I want to do a Open Source linux version, but that's a
|> long ways away.
|
|Hmmm... expect to get comfortable with a new scripting language... unless
|you want to be a proper programmer and rewrite it in C/C++. :)
|
|(Personally, I'd recommend TCL/TK, with maybe some C++ backbone code, but
|that's just me... I like the TK widget set)

Sod C++. Stick with plain old fashioned C.
Object Orientation is overrated as it is, and C++ is not a good example of
how it should be done in the first place.

|As for the person who wanted Adam to post the VB runtime DLLs... you can
|download them from the Microsoft web site fairly readily. But Adam may hit
|redistribution problems if he posts them (Microsoft's redistribution
|agreements can be incredibly wierd sometimes).

Tough tities to them.
I'm curious why the damned thing has to be written in VB in the first
place. It's not exactly a portable language, is it?
--
-----------------------------------------------------------------------------
|u5a77@*****.cs.keele.ac.uk| Windows95 (noun): 32 bit extensions and a |
| | graphical shell for a 16 bit patch to an 8 bit |
| Andrew Halliwell | operating system originally coded for a 4 bit |
| Finalist in:- |microprocessor, written by a 2 bit company, that|
| Computer Science | can't stand 1 bit of competition. |
-----------------------------------------------------------------------------
|GCv3.1 GCS/EL>$ d---(dpu) s+/- a- C++ U N++ o+ K- w-- M+/++ PS+++ PE- Y t+ |
|5++ X+/++ R+ tv+ b+ D G e>PhD h/h+ !r! !y-|I can't say F**K either now! :( |

From:	John E Pederson <pedersje@******.ROSE-HULMAN.EDU>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Fri, 29 Jan 1999 11:27:16 -0500

Message no. 14 K in the Shadows wrote:
>
> In a message dated 1/29/1999 12:51:58 AM US Eastern Standard Time,
> SHODAN+@***.EDU writes:
>
> >
> > Maybe I've missed something, but I thought that being
> > object-oriented had nothing to do with whether a language was
> > functional or iterative. C, with the addition of C++, and LISP, with
> > the addition of CLOS, are both OO.
>
> Mark, you mention "LISP". One of the known comp languages of SR Matrix is
> "HoloLISP". So somewhere along the lines they get changed over. If we
knew
> what LISP was better at doing than say, "C++", perhaps we could formulate
what
> taking a specific language would be good for doing>
>
> -K

C++ is a superset of C which attempts to be an object-oriented
language (it's really more of a hybrid of procedural/object-oriented
stuff, IMO). _Java_ is an object-oriented language (to the point of
absurdity, in fact). LISP (_L_ots of _I_significant _S_uperfluous
_P_arentheses) is (as has already been mentioned) a functional
language. In C, you do stuff with variables. In C++, you do stuff with
variables and objects. In Java, you do stuff with objects. Those are
all iterative languages. LISP, is really different in that respect,
and I've *no* experience with it. If it's any indication, however,
LISP was the language the CS Department here taught the AI course
until this year. Now they're using Scheme (a LISP derivative).

And I don't know that COBOL would still be around, but there will
almost certainly be a language called FORTRAN (whether it bears any
real resemblance to the current language by that name or not:). And
the deckers will probably still make jokes about it:)

Canthros (who really needs to get his .sigfile fixed)
Useless Trivia: with the exception of Fortran, LISP is the oldest
computer programming language to still be in use.

From:	A Halliwell <u5a77@*****.CS.KEELE.AC.UK>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Fri, 29 Jan 1999 17:46:51 +0000

Message no. 15 And verily, did John E Pederson hastily scribble thusly...
|all iterative languages. LISP, is really different in that respect,
|and I've *no* experience with it. If it's any indication, however,
|LISP was the language the CS Department here taught the AI course
|until this year. Now they're using Scheme (a LISP derivative).

Really? We're still using PROLOG!

*gack*

|And I don't know that COBOL would still be around, but there will
|almost certainly be a language called FORTRAN (whether it bears any
|real resemblance to the current language by that name or not:). And
|the deckers will probably still make jokes about it:)
|
|Canthros (who really needs to get his .sigfile fixed)
|Useless Trivia: with the exception of Fortran, LISP is the oldest
|computer programming language to still be in use.

Assembly Language? (Assuming any processors survived from the '60s)

:)
--
-----------------------------------------------------------------------------
|u5a77@*****.cs.keele.ac.uk| Windows95 (noun): 32 bit extensions and a |
| | graphical shell for a 16 bit patch to an 8 bit |
| Andrew Halliwell | operating system originally coded for a 4 bit |
| Finalist in:- |microprocessor, written by a 2 bit company, that|
| Computer Science | can't stand 1 bit of competition. |
-----------------------------------------------------------------------------
|GCv3.1 GCS/EL>$ d---(dpu) s+/- a- C++ U N++ o+ K- w-- M+/++ PS+++ PE- Y t+ |
|5++ X+/++ R+ tv+ b+ D G e>PhD h/h+ !r! !y-|I can't say F**K either now! :( |

From:	Mark A Shieh <SHODAN+@***.EDU>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Fri, 29 Jan 1999 15:12:45 -0500

Message no. 16 James Ojaste wrote:
K in the Shadows wrote:
>> > Maybe I've missed something, but I thought that being
>> > object-oriented had nothing to do with whether a language was
>> > functional or iterative. C, with the addition of C++, and LISP, with
>> > the addition of CLOS, are both OO.
>>
>> Mark, you mention "LISP". One of the known comp languages of SR Matrix
is
>> "HoloLISP". So somewhere along the lines they get changed over.

Yeah, and somewhere along the lines, they added a few features
to a language known as "Fortran" and marketed it as "C". :)

>> If we knew
>> what LISP was better at doing than say, "C++", perhaps we could
formulate
>> what taking a specific language would be good for doing>

Sounds like no one else has used LISP since a mandatory
graduation requirement, so I'll give it a shot. :) Keep in mind that
this is coming on the fly, but here's my first attempt at HoloLISP
development rules:

-25% to smart frame development time +
-40% to smart frame program size +
-20% to all other program sizes ++

Programs stored in source code form are 1/2 the size of the
compiled code, but the deck loses all additional initiative dice if
any uncompiled HoloLISP code is loaded. *
Repair programs written in HoloLISP receive 2 extra dice when
attempting to fix other HoloLISP programs. **
Upgrading a HoloLISP program is done at a -1TN. **
Programs written in HoloLISP automatically come with source
code, due to the ease of compilation and decompilation. ***

If a HoloLISP program is running, the HoloLISP interpreter
must also be running. The HoloLISP interpreter is the size of a large
rating 6 program. (what's that, rating^2*4?) ***
HoloLISP development environments are +4/+1 week availability,
+0.5 Street Index, and 2x cost. The dev environment comes with a
Rating 6 HoloLISP Interpreter. ****
A Rating 10 HoloLISP interpreter is also available and
provides +1d6 initiative if all programs in active memory are written
in HoloLISP. It is the size of a large rating 10 program (what is
that, rating^2*4? I have no books with me today.) ++, and based on
the Real Life LISP interpreter that researchers have written.
HoloLISP Interpreters can be found separately as a rating 6
utility, but cannot uncompile compiled code or develop. ***
Deckers are limited in their ability to deck by their
knowledge of HoloLISP, if they have to deal with a HoloLISP process.
If a HoloLISP program is running or being developed, their Computer
and Computer Theory skills are effectively capped at twice their
rating in the Background skill, HoloLISP. (Forex, Computer 6 and
HoloLISP 2 means that all tests are done as if the decker only had a
Computer rating of 4.) Learning or improving the HoloLISP skill
requires access to a HoloLISP development environment. ****

+ LISP is good at AI work.
++ LISP has massive standard libraries build into the interpreter.
* LISP can run uncompiled source code.
** LISP is easy to modify on the fly.
*** LISP is an interpreted language.
**** LISP is a less common language.

>LISP is better at a) recursion and b) list handling. Or rather, LISP
>can only do a) recursion and b) list handling, so it's damned good at
>them. :-) LISP is a functional language.

:P LISP was originally a functional language. Then, people
decided that being able to store a value in a variable would be nice,
and LISP lost the holy "purity" that the theorists talk about and
became a viable programming language, mostly functional in nature.
My favorite feature though, is the ability to easily hot swap
in some new code. If a function is being buggy, and the error gets
trapped, I can load in a new version of the code, compile it, and test
it, without having to rebuild. This does wonderful things to my dev
time.
LISP is actually pretty good at everything else as well.
Researchers at CMU wrote a LISP environment that is able to outperform
optimized C code, at the cost of the interpreter being truly large.
(I don't know if this is still the case, as the figure I heard may
have been something like 64 megs, but 4-5 years ago)

>C is better at raw math, iterative loops, raw data processing -
>basically "do a, then do b, then do c" stuff.

It's probably easier to code, however, LISP isn't exactly bad
at this. It's in the same ballpark as C, slower at some things and
faster at other, but still similar no matter what. Don't forget
though, that you tend to do a bunch of C optimizations out of habit.
Odds are, you haven't seen optimized LISP code. I didn't learn how to
optimize LISP code as an undergrad, that's for sure.
The big reason you see lots of C is because there are many
mroe prebuild libraries available in C, and most of industry work is
done in C, both of which are self-propagating trends.

>Counting brackets can get tedious. :-)

Really, it's not any worse than the ()[]{} you'll find in C.
I suspect that you consider it tedious because you've spend one
semester or two coding in LISP, but the majority of your life being
proficient in C. It's all just silly notation, and they're about the
same. I found that it helps to break them apart like C, and to take
advantage of the indentation that emacs offers, so the last lines of a
function might look like
(do-something-to this :time now :priority dammit)
)
)
)
)

Mark

From:	John E Pederson <pedersje@******.ROSE-HULMAN.EDU>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Fri, 29 Jan 1999 15:52:47 -0500

Message no. 17 A Halliwell wrote:
>
> And verily, did John E Pederson hastily scribble thusly...
> |all iterative languages. LISP, is really different in that respect,
> |and I've *no* experience with it. If it's any indication, however,
> |LISP was the language the CS Department here taught the AI course
> |until this year. Now they're using Scheme (a LISP derivative).
>
> Really? We're still using PROLOG!
>
> *gack*

Hmmm.... Not really familiar with that one (I've heard of it,
though... just can't remember where:/) The Data Structures course I'm
taking now is being taught in Java, but it used to be taught in Ada
(about two or three years ago). They gave us C++ via MS Visual C++
(*twitch*) in a couple of previous courses...

> |Canthros (who really needs to get his .sigfile fixed)
> |Useless Trivia: with the exception of Fortran, LISP is the oldest
> |computer programming language to still be in use.
>
> Assembly Language? (Assuming any processors survived from the '60s)
>
> :)

I can't think of any processors that survived that long to remain in
even remotely common use (the selling point on LISP).

But Fortran doesn't count for that trivia statement anyway:) Fortran
90 != Fortran 77 != Fortran 4, etc., etc.

Canthros
"I don't know what language the MEs will be using in 20 years, but
they'll call it Fortran."
--CS Prof. (name withheld in the interest of not pissing people off)

From:	Scott Harrison <Scott_Harrison@*****.COM>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Fri, 29 Jan 1999 15:55:20 -0500

Message no. 18 A Halliwell <u5a77@*****.CS.KEELE.AC.UK> made my mailer see:
-> And verily, did Robert Watkins hastily scribble thusly...
-> |
-> |Adam J writes:
-> |> I'm installing linux sometime within the next couple weeks =
(Depending on
-> |> when my CDs arrive (No, I'm not downloading 300+ megs)), and once I =
get
-> |> comfortable with it I want to do a Open Source linux version, but =
that's a
-> |> long ways away.
-> |
-> |Hmmm... expect to get comfortable with a new scripting language... =
unless
-> |you want to be a proper programmer and rewrite it in C/C++. :)
-> |
-> |(Personally, I'd recommend TCL/TK, with maybe some C++ backbone code, =
but
-> |that's just me... I like the TK widget set)
->
-> Sod C++. Stick with plain old fashioned C.

I hearily agree with the C++ comment. It is a pain to learn, as its
syntax is difficult. It is also limited in its design as it is a =
statically
typed language. If one were to venture into a language with C++-like =
syntax
one might as well do Java. C is a good language to learn as it is the =
basis
for a few languages, is portable, and is in great demand in the =
programming
world.

-> Object Orientation is overrated as it is, and C++ is not a good example =
of
-> how it should be done in the first place.
->

I disagree with the comment about object-orientation. C++ is =
definitely
not a good example of an object-oriented language. It was never designed =
to
be an object oriented language. It was designed to be a better C. =
Eventually
enough things were grafted on to it to make it qualify as an =
object-oriented
language.

Object-orientation is hyped a lot in the media. However, most people
probably do not make real use of it. I have been in the field for the =
past
decade and have seen quite good use of it. It is a very good thing if =
used
properly. In fact, I would imagine that the world of SR decking would be
programmed in an object-oriented language since it naturally falls into a
pattern of object interaction. By the way, I wish the rules for the =
matrix
were different since I actually program stuff like this and the rules do =
not
match what I would refer to as reality.

-> |As for the person who wanted Adam to post the VB runtime DLLs... you =
can
-> |download them from the Microsoft web site fairly readily. But Adam may =
hit
-> |redistribution problems if he posts them (Microsoft's redistribution
-> |agreements can be incredibly wierd sometimes).
->
-> Tough tities to them.
-> I'm curious why the damned thing has to be written in VB in the first
-> place. It's not exactly a portable language, is it?
-> --

VB is definitely not portable. But ActiveX is also not portable. And
neither is the Access database serving as the backend. So, it really =
doesn't
matter what language is used as long as the product is cool and can be run =
by
people.

Note the the stuff I am writing uses Objective-C as the programming
language. It is more portable than Visual Basic. My stuff will run on =
Win32
systems as well as MacOS X. However, my stuff requires the Yellow Box =
DLLs
and environment. Therefore, my stuff is not portable in one sense either. =
I
could attempt to write a straight C version of everything but then I lose =
out
on all the object technology on which I am building. When my stuff is =
done,
there will be no comparing it to anything else because of that object
technology.

-> =
---------------------------------------------------------------------------=
--
-> |u5a77@*****.cs.keele.ac.uk| Windows95 (noun): 32 bit extensions and =
a |
-> | | graphical shell for a 16 bit patch to an 8 =
bit |
-> | Andrew Halliwell | operating system originally coded for a 4 =
bit |
-> | Finalist in:- |microprocessor, written by a 2 bit company, =
that|
-> | Computer Science | can't stand 1 bit of competition. =
|
-> =
---------------------------------------------------------------------------=
--
-> |GCv3.1 GCS/EL>$ d---(dpu) s+/- a- C++ U N++ o+ K- w-- M+/++ PS+++ PE- =
Y t+ |
-> |5++ X+/++ R+ tv+ b+ D G e>PhD h/h+ !r! !y-|I can't say F**K either =
now! :( |

--Scott

From:	Lehlan Decker <DeckerL@******.COM>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Fri, 29 Jan 1999 16:16:29 -0500

Message no. 19 >Yeah, and somewhere along the lines, they added a few features
>to a language known as "Fortran" and marketed it as "C". :)

Those are fighting words!!! :)

From:	Lehlan Decker <DeckerL@******.COM>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Fri, 29 Jan 1999 16:23:45 -0500

Message no. 20 >Hmmm.... Not really familiar with that one (I've heard of it,
>though... just can't remember where:/) The Data Structures course I'm
>taking now is being taught in Java, but it used to be taught in Ada
>(about two or three years ago). They gave us C++ via MS Visual C++
>(*twitch*) in a couple of previous courses...

Ouch. I took data structures not that long ago, and they were teaching it
in C++, but the semester afterwards they had started using Java, and as
far as I know still are. (This is at FSU).
They had actually used Ada as a starting computer 2000 level class, but
it didn't go over very well.

From:	"Shaun E. Gilroy" <shaung@**********.NET>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Fri, 29 Jan 1999 16:42:40 -0500

Message no. 21 At 04:16 PM 1/29/99 -0500, you wrote:
>>Yeah, and somewhere along the lines, they added a few features
>>to a language known as "Fortran" and marketed it as "C". :)
>
>Those are fighting words!!! :)
>

What I wanna know is how LISP survived to 205x-6x, but not Perl? In an age
where you really can't access a terminal legally without a terminal, I
would expect things like today's perl community to thrive among deckers.

Perl and JAVA aren't languages, they are a lifestyle, a way of looking at
things, a culture that you get paid to keep up on.

Not that I'm biased. -:)

Shaun Gilroy [shaung@**********.net]
Online Technologies Corp.

From:	Stefan <casanova@***.PASSAGEN.SE>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Fri, 29 Jan 1999 22:54:37 +0000

Message no. 22 > What I wanna know is how LISP survived to 205x-6x, but not Perl? In an age
> where you really can't access a terminal legally without a terminal, I
> would expect things like today's perl community to thrive among deckers.

How the heck did Fortran and LISP survive ? Perl died .. well that is
sad. But what the heck happended to Assembler ? I don't wanna sit
there in the future being the only one still pain in the butt
programming in ASM ...

If it ain't ASM it ain't programming ...

Visual (whatever) bah ....

/Stefan

------------------------------------------------------------------------
"Frag you and the datastream you came on!" - Sinjin the decker
------------------------------------------------------------------------
... E-Mail .............................. casanova@***.passagen.se ...
... HomePage .............................. http://hsl.home.ml.org ...
... HomePage ................... http://www.bugsoft.hik.se/sl11ls/ ...
... ICQ ....................................[UIN changed!]. 793828 ...
------------------------------------------------------------------------

From:	K in the Shadows <Ereskanti@***.COM>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Fri, 29 Jan 1999 22:19:41 EST

Message no. 23 In a message dated 1/29/1999 9:55:01 AM US Eastern Standard Time,
James.Ojaste@**.GC.CA writes:

>
> Procedural languages basically make the world go round. They're
> basically "do a, then do b, then do c" stuff. Functional languages
> get to do cool stuff like rewrite themselves, but they're harder to
> write and slower to run. Functional languages are like "do this
> (based on this info (which is based on this info (which in turn...)))".
> Counting brackets can get tedious. :-)

Okay, so if I am following all of this correctly, "HoloLISP" might easily be
the better language to write programs that do "Search", "Browse",
"Analyze"
(search engine type operations on a server or host).

What would the others be then?

-K

From:	K in the Shadows <Ereskanti@***.COM>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Fri, 29 Jan 1999 22:23:23 EST

Message no. 24 In a message dated 1/29/1999 12:31:53 PM US Eastern Standard Time,
pedersje@******.ROSE-HULMAN.EDU writes:

>
> Canthros (who really needs to get his .sigfile fixed)
> Useless Trivia: with the exception of Fortran, LISP is the oldest
> computer programming language to still be in use.

Really? And here I thought that COBOL (Certifiably Objective BOnehead
Language) is actually still in use in some places.

-K

From:	John E Pederson <pedersje@******.ROSE-HULMAN.EDU>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Fri, 29 Jan 1999 22:59:20 -0500

Message no. 25 K in the Shadows wrote:
>
> In a message dated 1/29/1999 12:31:53 PM US Eastern Standard Time,
> pedersje@******.ROSE-HULMAN.EDU writes:
>
> >
> > Canthros (who really needs to get his .sigfile fixed)
> > Useless Trivia: with the exception of Fortran, LISP is the oldest
> > computer programming language to still be in use.
>
> Really? And here I thought that COBOL (Certifiably Objective BOnehead
> Language) is actually still in use in some places.
>
> -K

Actually, I managed to leave out the qualifier 'common' on use. Though
I'm not sure how far back the individual languages date, so I can't
make any comparisons.

Canthros

From:	Josh Munn <barnack@*******.COM>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Sat, 30 Jan 1999 00:26:04 EST

Message no. 26 >K in the Shadows wrote:
>>
>> In a message dated 1/29/1999 12:31:53 PM US Eastern Standard Time,
>> pedersje@******.ROSE-HULMAN.EDU writes:
>>
>> >
>> > Canthros (who really needs to get his .sigfile fixed)
>> > Useless Trivia: with the exception of Fortran, LISP is the oldest
>> > computer programming language to still be in use.
>>
>> Really? And here I thought that COBOL (Certifiably Objective
BOnehead
>> Language) is actually still in use in some places.
>>
>> -K
>
>Actually, I managed to leave out the qualifier 'common' on use. Though
>I'm not sure how far back the individual languages date, so I can't
>make any comparisons.
>
>Canthros

COBOL is in "comon" use. Why do you think we are having such a problem
with the Y2K bug. Cobol is used in most large companies for data
processing (which it is very good at). They have even come up with a
visual COBOL for use with Win 95. COBOL is probably the most common
language in use in the busisness world.

".o' 'b^'""'b -'b
,'.'o' t. = -'b -'t.
; d o' ___ _.--.. 8 - 'b ='b
dooo8< .o:':__;o. ,;;o88%%8bb - = 'b ='b
|^88^88=. .,x88/::/ | \\'::::::d%%%%%88%88888/%x88888
:-88ˆ%%L8'%'|::|_>-<-||%;;%;8%%=;:::=%8;;\%%%%\8888
|ˆ 88%%|HHHH|::| >-< |||;%;;8%%=;:::=%8;;;%%%%+|]88
| 88-88%%LL.%.%b::Y_|_Y/%|;;;;'%8%%oo88%;o%.;;;;+|]88
Yx88o88^^'"'^^%8boooood..-\H_Hd%P%%88%P^%%^'\;;;/%%88
'"\^\ ~"""""' d%P """^"
; = '+' - P
'.'.b :<%%> . : - d' - P
.'.b '788 ,'- = d' =.'
''.b. :..- :' P
'q.>b '^^^:::::,'
""^^
There are very few personal problems that cannot be solved
through a suitable application of high explosives.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From:	Micheal Feeney <Starrngr@***.COM>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Sat, 30 Jan 1999 03:26:35 EST

Message no. 27 In a message dated 99-01-29 22:24:31 EST, you write:

>
> Really? And here I thought that COBOL (Certifiably Objective BOnehead
> Language) is actually still in use in some places.
>
> -K
>
>

It is K. Especially in large legacy systems. It would take to much time and
money to re-write the suckers now adays so they just keep what they have and
patch the heck out of it.

From:	Gurth <gurth@******.NL>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Sat, 30 Jan 1999 13:20:17 +0100

Message no. 28 According to Mark A Shieh, at 15:12 on 29 Jan 99, the word on
the street was...

> Sounds like no one else has used LISP since a mandatory
> graduation requirement, so I'll give it a shot. :)

I don't suppose you'd want to write up an article about programmin
languages for NERPS, would you?

--
Gurth@******.nl - http://www.xs4all.nl/~gurth/index.html
And that's as far as the conversation went.
-> NERPS Project Leader * ShadowRN GridSec * Unofficial Shadowrun Guru <-
->The Plastic Warriors Page: http://shadowrun.html.com/plasticwarriors/<-
-> The New Character Mortuary: http://www.electricferret.com/mortuary/ <-

GC3.1: GAT/! d-(dpu) s:- !a>? C+(++)@ U P L E? W(++) N o? K- w+ O V? PS+
PE Y PGP- t(+) 5++ X++ R+++>$ tv+(++) b++@ DI? D+ G(++) e h! !r(---) y?
Incubated into the First Church of the Sqooshy Ball, 21-05-1998

From:	A Halliwell <u5a77@*****.CS.KEELE.AC.UK>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Sat, 30 Jan 1999 13:54:21 +0000

Message no. 29 And verily, did K in the Shadows hastily scribble thusly...
|Okay, so if I am following all of this correctly, "HoloLISP" might easily be
|the better language to write programs that do "Search", "Browse",
"Analyze"
|(search engine type operations on a server or host).
|
|What would the others be then?

Probably procedural languages optimised for writing the operating systems
and GUI front ends that make the matrix what it is....

The same way that C made Linux and X (and a lot of games on the PC what they
are)

--
-----------------------------------------------------------------------------
|u5a77@*****.cs.keele.ac.uk| Windows95 (noun): 32 bit extensions and a |
| | graphical shell for a 16 bit patch to an 8 bit |
| Andrew Halliwell | operating system originally coded for a 4 bit |
| Finalist in:- |microprocessor, written by a 2 bit company, that|
| Computer Science | can't stand 1 bit of competition. |
-----------------------------------------------------------------------------
|GCv3.1 GCS/EL>$ d---(dpu) s+/- a- C++ U N++ o+ K- w-- M+/++ PS+++ PE- Y t+ |
|5++ X+/++ R+ tv+ b+ D G e>PhD h/h+ !r! !y-|I can't say F**K either now! :( |

From:	Mongoose <m0ng005e@*********.COM>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Sat, 30 Jan 1999 14:06:14 -0600

Message no. 30 :>BBB3, p. 295:
:>"Common programming languages in the Sixth World include HoloLISP,
:>InterMod, MATCom, and Oblong."
:
:And COBOL... You *know* COBOL just can not and will not die ... ;)
:
:Actually, I kind of wish SR had done what Cyberspace did: detailed a few
:programming languages and the benefits/penalties for using those.

Perhaps the programming options listed DO reflect (partly) the
language the program is coded in. Adding radical options on top of that
is likely to make for to extreme a variation in utilities, or even in the
basics of how a deck works. That messes with "game balance", but also
doesn't make much sense in the mega-multi-platform environment of the
matrix. (I could be wrong, but wouldn't machine language kinda SUCK in
such an environment?)

Mongoose

From:	Mark A Shieh <SHODAN+@***.EDU>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Sat, 30 Jan 1999 18:22:47 -0500

Message no. 31 "Shaun E. Gilroy" <shaung@**********.net> writes:
> At 04:16 PM 1/29/99 -0500, you wrote:
> >>Yeah, and somewhere along the lines, they added a few features
> >>to a language known as "Fortran" and marketed it as "C".
:)
> >
> >Those are fighting words!!! :)

Yeah, bring it. I'm a LISP coder, I'm used to putting up with
abuse. There just aren't that many of us left, but we still know how
to recognize a good language. :)

> What I wanna know is how LISP survived to 205x-6x, but not Perl? In an age
> where you really can't access a terminal legally without a terminal, I
> would expect things like today's perl community to thrive among deckers.

Same reason Java didn't make it. The caption that listed a
few programming languages comes from, IIRC, VR1 a 6-7 year old book?
PERL and Java weren't as popular as they are now that the WWW plague
has managed to infect national television, billboards, and magazines.

Mark

From:	Paul Gettle <RunnerPaul@*****.COM>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Sun, 31 Jan 1999 16:23:25 -0500

Message no. 32 -----BEGIN PGP SIGNED MESSAGE-----

At 06:22 PM 1/30/99 -0500, Mark wrote:
>> What I wanna know is how LISP survived to 205x-6x, but not Perl?
In an age
>> where you really can't access a terminal legally without a
terminal, I
>> would expect things like today's perl community to thrive among
deckers.
>
> Same reason Java didn't make it. The caption that listed a
>few programming languages comes from, IIRC, VR1 a 6-7 year old book?
>PERL and Java weren't as popular as they are now that the WWW plague
>has managed to infect national television, billboards, and magazines.

Um, if you're talking about the quote I posted with a listing of some
of SR's common programming languages, that's from Shadowrun Third
Edition, a book that's only 6-7 months old. :)

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.0.2

iQCVAwUBNrTJwaPbvUVI86rNAQHAkQP9G4b17VbMUYTdyyL9F4HvYxmur2rdOuEN
DEFOigZ8/r8KMkMI/fxSqrfkb43+jgFBggDToAmTN06sUpOI1/Kmzdn1b9bfBxyE
RNNEW+asm7G9NHxRwk1m1hKWX8qHVsQdZhCEIuNSNmGihHSmZuKV7svEBEHw8pSI
ArXs33WSKs8=
=ssme
-----END PGP SIGNATURE-----
--
-- Paul Gettle, #970 of 1000 (RunnerPaul@*****.com)
PGP Fingerprint, Key ID:0x48F3AACD (RSA 1024, created 98/06/26)
C260 94B3 6722 6A25 63F8 0690 9EA2 3344

From:	Robert Watkins <robert.watkins@******.COM>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Mon, 1 Feb 1999 08:46:39 +1000

Message no. 33 Paul Gettle writes:
> Um, if you're talking about the quote I posted with a listing of some
> of SR's common programming languages, that's from Shadowrun Third
> Edition, a book that's only 6-7 months old. :)

Which is taken verbatim from VR1... a book that's more like 8 years old.

--
Duct tape is like the Force: There's a Light side, a Dark side, and it
binds the Universe together.
Robert Watkins -- robert.watkins@******.com

From:	Paul Gettle <RunnerPaul@*****.COM>
Subject:	Re: [semi-OT] programming languages' evolution
Date:	Sun, 31 Jan 1999 20:57:18 -0500

Message no. 34 -----BEGIN PGP SIGNED MESSAGE-----

At 08:46 AM 2/1/99 +1000, Robert wrote:
>Paul Gettle writes:
>> Um, if you're talking about the quote I posted with a listing of
some
>> of SR's common programming languages, that's from Shadowrun Third
>> Edition, a book that's only 6-7 months old. :)
>
>Which is taken verbatim from VR1... a book that's more like 8 years
old.

That quote is in VR1? I'm going to have to go back and re-read that
one again.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.0.2

iQCVAwUBNrUJ9aPbvUVI86rNAQHCPAP/Xop/SrYwQZd/CMuKtMsWfxZwJHGHiynK
IFnHWgD7k9UgvpNZ4M3QU56NmPsDr/cnLywKeX4/lsW7dGZA54ARTRM35nvj9xi1
zQ5zfqbG9FZA1LmzScXhr8UBoX/l7sqUbt5ebk/fybWRt63EPNvjkEvZZqvxURSX
Y3OlOyeSxBk=
=r/Kn
-----END PGP SIGNATURE-----

--
-- Paul Gettle, #970 of 1000 (RunnerPaul@*****.com)
PGP Fingerprint, Key ID:0x48F3AACD (RSA 1024, created 98/06/26)
C260 94B3 6722 6A25 63F8 0690 9EA2 3344

From:	Shaun E. Gilroy shaung@**********.net
Subject:	[semi-OT] programming languages' evolution
Date:	Fri, 29 Jan 1999 16:42:40 -0500

Message no. 35 At 04:16 PM 1/29/99 -0500, you wrote:
>>Yeah, and somewhere along the lines, they added a few features
>>to a language known as "Fortran" and marketed it as "C". :)
>
>Those are fighting words!!! :)
>

What I wanna know is how LISP survived to 205x-6x, but not Perl? In an age
where you really can't access a terminal legally without a terminal, I
would expect things like today's perl community to thrive among deckers.

Perl and JAVA aren't languages, they are a lifestyle, a way of looking at
things, a culture that you get paid to keep up on.

Not that I'm biased. -:)

Shaun Gilroy [shaung@**********.net]
Online Technologies Corp.

From:	dghost@**.com dghost@**.com
Subject:	[semi-OT] programming languages' evolution
Date:	Fri, 29 Jan 1999 21:11:58 -0600

Message no. 36 On Fri, 29 Jan 1999 16:42:40 -0500 "Shaun E. Gilroy"
<shaung@**********.net> writes:
<SNIP>
>What I wanna know is how LISP survived to 205x-6x, but not Perl? In an
age
>where you really can't access a terminal legally without a terminal, I
>would expect things like today's perl community to thrive among deckers.
<SNIP>

The caption said SOME of the languages ... not the only languages...
There may very well be a version of Perl in 205x but it just wasn't
mentioned in that section. If you want to know why, compile a list of
all the programming languages in use today and see how much space that
takes up. The list of 205x languages is probably comparable.

--
D. Ghost
(aka Pixel, Tantrum, RuPixel)
"We called him Mother Superior because of the length of his habit" --
Trainspotting
"A magician is always 'touching' himself" --Page 123, Grimoire (2nd
Edition)

___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]

From:	Mark A Shieh SHODAN+@***.EDU
Subject:	[semi-OT] programming languages' evolution
Date:	Sat, 30 Jan 1999 18:22:47 -0500 (EST)

Message no. 37 "Shaun E. Gilroy" <shaung@**********.net> writes:
> At 04:16 PM 1/29/99 -0500, you wrote:
> >>Yeah, and somewhere along the lines, they added a few features
> >>to a language known as "Fortran" and marketed it as "C".
:)
> >
> >Those are fighting words!!! :)

Yeah, bring it. I'm a LISP coder, I'm used to putting up with
abuse. There just aren't that many of us left, but we still know how
to recognize a good language. :)

> What I wanna know is how LISP survived to 205x-6x, but not Perl? In an age
> where you really can't access a terminal legally without a terminal, I
> would expect things like today's perl community to thrive among deckers.

Same reason Java didn't make it. The caption that listed a
few programming languages comes from, IIRC, VR1 a 6-7 year old book?
PERL and Java weren't as popular as they are now that the WWW plague
has managed to infect national television, billboards, and magazines.

Mark

From:	Ojaste,James [NCR] James.Ojaste@**.GC.CA
Subject:	[semi-OT] programming languages' evolution
Date:	Mon, 1 Feb 1999 15:55:19 -0500

Message no. 38 Mark A Shieh wrote (on the old server):
> >> Mark, you mention "LISP". One of the known comp languages of SR
Matrix
> is
> >> "HoloLISP". So somewhere along the lines they get changed over.
>
> Yeah, and somewhere along the lines, they added a few features
> to a language known as "Fortran" and marketed it as "C". :)
>
You mean, "they took away the pain of assembly, made it look pretty,
and marketed it as 'C'". :-)

> >> If we knew
> >> what LISP was better at doing than say, "C++", perhaps we could
> formulate
> >> what taking a specific language would be good for doing>
>
> Sounds like no one else has used LISP since a mandatory
> graduation requirement, so I'll give it a shot. :) Keep in mind that
> this is coming on the fly, but here's my first attempt at HoloLISP
> development rules:
>
We actually used Scheme. I thought "functional languages could be
cool, but this is slow and huge - forget it". Then I played around
with ES (Extensible Shell) - it's a cross between functional and
procedural languages implemented in terms of a unix shell. Awesome.
I spent hours rewriting the command-line parser. By setting an
environment variable. :-)

> + LISP is good at AI work.
> ++ LISP has massive standard libraries build into the interpreter.
> * LISP can run uncompiled source code.
> ** LISP is easy to modify on the fly.
> *** LISP is an interpreted language.
> **** LISP is a less common language.
>
Perhaps we should break this down for use with other languages:

Interpreted languages allow faster development
Compiled executables allow faster execution
Large existing libraries allow faster development
Shared libraries shrink executable size (usually meaning access to
standard OS functions)
Self-documenting code increases development time, but decreases
maintenance time (things like declaring the type of all variables,
even if you don't really have to)
Low-level languages produce smaller, faster executables and take longer
to write and maintain
High-level languages produce slower, larger executables but are
faster to write and maintain
OO - difficult to quantify (you can write in an OO manner without
having an "OO" language). I'll try to use this responsibly. :-)

So, some of the languages I've used (I'll try to stick to the most
common usage - most people don't use a C interpreter, for example,
although at least one exists):

ASM compiled, very low-level
C compiled, libraries, shared, declared, low-level
Java interpreted, compiled, libraries, mid-level, OO
Modula-3 compiled, declared, mid-level, OO
Pascal compiled, libraries, shared, low-level
Scheme interpreted, libraries, mid-level
SQL interpreted, declared, high-level
VBasic interpreted, compiled, libraries, shared, mid-level

> >Counting brackets can get tedious. :-)
>
> Really, it's not any worse than the ()[]{} you'll find in C.
> I suspect that you consider it tedious because you've spend one
> semester or two coding in LISP, but the majority of your life being
> proficient in C. It's all just silly notation, and they're about the
>
Well, mostly because you tend to end up with a lot more nesting in LISP
than in C. Yes, it's all a matter of notation and having a good editor.
That's partly why the :-)...

James Ojaste

From:	Ojaste,James [NCR] James.Ojaste@**.GC.CA
Subject:	[semi-OT] programming languages' evolution
Date:	Mon, 1 Feb 1999 15:34:50 -0500

Message no. 39 Josh Munn wrote (on the old server):
> >> > Useless Trivia: with the exception of Fortran, LISP is the oldest
> >> > computer programming language to still be in use.
> >>
> >> Really? And here I thought that COBOL (Certifiably Objective
> BOnehead
> >> Language) is actually still in use in some places.
> >>
> >Actually, I managed to leave out the qualifier 'common' on use. Though
> >I'm not sure how far back the individual languages date, so I can't
> >make any comparisons.
>
> COBOL is in "comon" use. Why do you think we are having such a problem
> with the Y2K bug. Cobol is used in most large companies for data
>
"We" are not having problems with the Y2K "bug" (I really dislike that
appellation - it's like saying we've got massive problems with the
"Off By One Bug"). Most Y2K-related problems aren't really problems,
or any worse than innumerable other bugs - the hype surrounding the
thing is mind-boggling.

In any case, most Y2K-related problems aren't caused by COBOL -
they're caused by a) the original designers not expecting their
code to have to last for 20 years, b) just plain forgetfulness and
c) wild hysteria. None of which (with the possible exception of c)
are the cause of COBOL. :-)

> processing (which it is very good at). They have even come up with a
> visual COBOL for use with Win 95. COBOL is probably the most common
> language in use in the busisness world.
>
COBOL was designed to be a "user-friendly" language written in an
english-like syntax so that any PHB would be able to do their own
programming. Gee, looks like it missed its mark a bit... ;-)

James Ojaste

From:	Mark A Shieh SHODAN+@***.EDU
Subject:	[semi-OT] programming languages' evolution
Date:	Mon, 1 Feb 1999 16:34:31 -0500 (EST)

Message no. 40 "Ojaste,James [NCR]" <James.Ojaste@**.GC.CA> writes:
> Mark A Shieh wrote (on the old server):
> Perhaps we should break this down for use with other languages:

That's how I'd work things out. However, VR2 is the only
rulebook I haven't read through carefully, since I still feel that
decking should be simplified to less than a half dozen rolls, or
should be done by NPCs. :P (That and Tir Na Nog. I need Tir Na Nog,
of all things, to complete my sourcebook collection...Tir Na Nog, a
1st edition softcover, a 2nd edition hardcover, and a BABY...)

> Interpreted languages allow faster development
> Compiled executables allow faster execution
> Large existing libraries allow faster development

The key is for these libraries to come standard with the
language, and you can treat these as shared. 3rd party libraries
don't have as many of these benefits, but all languages of note have
"large existing libraries".

> Shared libraries shrink executable size (usually meaning access to
> standard OS functions)
> Self-documenting code increases development time, but decreases
> maintenance time (things like declaring the type of all variables,
> even if you don't really have to)

I haven't noticed this to be the case. All self-documenting
code does is force you to produce minimal documentation. If you did
that anyways, it doesn't make a difference.

> Low-level languages produce smaller, faster executables and take longer
> to write and maintain
> High-level languages produce slower, larger executables but are
> faster to write and maintain
> OO - difficult to quantify (you can write in an OO manner without
> having an "OO" language). I'll try to use this responsibly. :-)

In addition, OO is generally a feature. You don't have to use
most of OO if you don't want to. I'm not sure it has enough of an
effect on development to make an effect in SR terms.
You may also want to see if you can make platform independence
worthwhile. LISP and Java are the two most independent languages I
know of, while ASM and VisualWhatever are the least. :) Maybe you
could oversimplify and claim that all Fuchi decks are compatible and
run the same software.
Oh, umm... uhh, all, uhh, all Novatech decks are compatible
and run the same software, and have a 95% chance of running Renraku
software, and a 100% chance of running all Novatech subsidiary soft...
nevermind.

> So, some of the languages I've used (I'll try to stick to the most
> common usage - most people don't use a C interpreter, for example,
> although at least one exists):
>
> ASM compiled, very low-level
^^^^^^^^
Heh. barely...

> C compiled, libraries, shared, declared, low-level
^^^^^^^^
Declared? You never defined what you think you get out of a declared
language. (What do you mean by declared, anyways, strongly typed?)

> Java interpreted, compiled, libraries, mid-level, OO
> Modula-3 compiled, declared, mid-level, OO
> Pascal compiled, libraries, shared, low-level
> Scheme interpreted, libraries, mid-level

I thought Scheme compiled, just like LISP. It's been quite a
while since I've used it though, so I'm not sure any more.

LISP interpreted, compiled, libraries, OO, mid-level

[Oh, you noticed the similarities between Java and LISP too, eh? :) ]

> SQL interpreted, declared, high-level
> VBasic interpreted, compiled, libraries, shared, mid-level

<cough> There's no way I can think of VBasic as anything but a
high-level language. I think it has to do with the ability to churn
out VB code at record speed, and the performance issues I've seen with
VB apps.

Mark

From:	Lehlan Decker DeckerL@******.com
Subject:	[semi-OT] programming languages' evolution
Date:	Mon, 01 Feb 1999 16:52:29 -0500

Message no. 41 >I haven't noticed this to be the case. All self-documenting
>code does is force you to produce minimal documentation. If
>you did that anyways, it doesn't make a difference.

If I understand this one right I have to disagree. There is no
excuse for not having code documented well. Sure I can write up
documentation, but then 5 years from now I have to have the
source code, and the documentation and look at the
documentation while I modify the code. Much easier to look
at the the comments in front of a section of code etc, and see
what it does, then to try and track it down in a manual.
In a previous job incarnation, I had to go back and modify
multiple's people's code, and I spent more time cussing them
then I did anything else. I have to admit its one of the few things
that they actually harped on and took points off for in college.
I remember a few folks loosing nearly a letter grade for
ill-documented code. The way to check it, they gave it to someone
else to fix or change.
To tie this to shadowrun.....I have no idea. I'll get back to you on
that one.

------------------------------------------------------------------------------------
Lehlan Decker, Unix Admin (704)331-1149
deckerl@******.com Fax 378-1939
Moore & Van Allen, PLLC Pager 1-888-608-9633

From:	Mark A Shieh SHODAN+@***.EDU
Subject:	[semi-OT] programming languages' evolution
Date:	Mon, 1 Feb 1999 17:10:42 -0500 (EST)

Message no. 42 Lehlan Decker <DeckerL@******.com> writes:
> >I haven't noticed this to be the case. All self-documenting
> >code does is force you to produce minimal documentation. If
> >you did that anyways, it doesn't make a difference.
>
> If I understand this one right I have to disagree. There is no
> excuse for not having code documented well.

I agree, there's nothing worse than going through someone
else's undocumented code. However, I'm saying that a language that
produces self-documenting code doesn't inherently do anything unless
your coding style was pretty atrocious to begin with. If you produce
good code with documentation in a language without this ability,
you'll produce the same stuff in a language with self-documenting
code.

> Sure I can write up
> documentation, but then 5 years from now I have to have the
> source code, and the documentation and look at the
> documentation while I modify the code. Much easier to look
> at the the comments in front of a section of code etc, and see
> what it does, then to try and track it down in a manual.

Sure, definitely. But does it really make a difference
whether the documentation consists of some comments at the beginning
of each relevant section of code and some general advice in a text
document, or whether javadoc has turned the documents into html form?

> To tie this to shadowrun.....I have no idea. I'll get back to you on
> that one.

Undocumented code is almost on the scale of decompiled code
for readability. :P The only saving grace of undocumented code is
that you can sometimes track down the original programmer and get him
to give you some verbal documentation.

Mark

From:	Mark A. Imbriaco mark.imbriaco@*****.com
Subject:	[semi-OT] programming languages' evolution
Date:	Mon, 1 Feb 1999 17:51:05 -0500 (EST)

Message no. 43 On Mon, 1 Feb 1999, Ojaste,James [NCR] wrote:

> So, some of the languages I've used (I'll try to stick to the most
> common usage - most people don't use a C interpreter, for example,
> although at least one exists):
>
> ASM compiled, very low-level
> C compiled, libraries, shared, declared, low-level
> Java interpreted, compiled, libraries, mid-level, OO
> Modula-3 compiled, declared, mid-level, OO
> Pascal compiled, libraries, shared, low-level
> Scheme interpreted, libraries, mid-level
> SQL interpreted, declared, high-level
> VBasic interpreted, compiled, libraries, shared, mid-level

Perl compiled then interpreted, libraries, shared, high-level, pseudo-OO

Can't forget that one. :-)

-Mark

From:	Lehlan Decker DeckerL@******.com
Subject:	[semi-OT] programming languages' evolution
Date:	Mon, 01 Feb 1999 17:26:54 -0500

Message no. 44 <SNIP>
>Undocumented code is almost on the scale of decompiled
>code for readability. :P The only saving grace of undocumented
>code is that you can sometimes track down the original
>programmer and get him to give you some verbal
>documentation.
Heh..I see your point now. If the code explains itself your fine.
I spend too much time using perl and regular expressions, and
that is not selfdocumenting. :) (Except for the scary folks among
us who can actually interpret regular expressions in their heads)
The problem is tracking down the former programmers, since
they no longer work for the company, and aren't getting paid,
most could give a damn if you can't decipher their code.
And the boss is paying you to decipher the code, so he really
doesn't care either. Sigh..I now remember why I got into
sysadmin versus straight programming.
------------------------------------------------------------------------------------
Lehlan Decker, Unix Admin (704)331-1149
deckerl@******.com Fax 378-1939
Moore & Van Allen, PLLC Pager 1-888-608-9633

From:	Mark A Shieh SHODAN+@***.EDU
Subject:	[semi-OT] programming languages' evolution
Date:	Mon, 1 Feb 1999 18:07:05 -0500 (EST)

Message no. 45 Lehlan Decker <DeckerL@******.com> writes:
> <SNIP>
> >Undocumented code is almost on the scale of decompiled
> >code for readability. :P The only saving grace of undocumented
> >code is that you can sometimes track down the original
> >programmer and get him to give you some verbal
> >documentation.
> Heh..I see your point now. If the code explains itself your fine.

Eep! That's still not my point. :) If the code explains
itself, with the help of whatever documentation is necessary, there's
no need for the programming language to force selfdocumenting code
onto you.

When I think of selfdocumenting code, I'm thinking of stuff
written with something like Javadoc as part of the spec, not code
where it should be intuitively obvious what's going on just by looking
at undocumented code. (Which, IIRC, was one of the basic concepts
around C. :P ) If my terminology is off-base, please correct me. I
don't believe in the existence of fully selfdocumenting code, so I
assume we're talking about something like forcing Javadoc into your
spec, which just isn't going to change the way you do things. Either
you wrote legible code before, and you'll do it despite Javadoc, or
you didn't, and you'll have a bunch of illegible code with Javadoc
stubs. I feel really silly documenting a variable called
"OrderWindow" with the comment, "this is the pointer that stores the
OrderWindow for the UI.", but Javadoc wants you to spend that effort.

> The problem is tracking down the former programmers, since
> they no longer work for the company, and aren't getting paid,
> most could give a damn if you can't decipher their code.

It doesn't give you a great chance, but it beats
machine-generated code by giving you some small hope. I had a look at
some of that in LISP recently, and it's really hard to make out.

> Sigh..I now remember why I got into sysadmin versus straight programming.

I've been debating making the switch. Seems like you need to
learn a lot of UNIX guts and be on call a whole lot though. I like my
flexhours. :)

Mark

From:	Robert Watkins robert.watkins@******.com
Subject:	[semi-OT] programming languages' evolution
Date:	Tue, 2 Feb 1999 09:09:15 +1000

Message no. 46 Ojaste writes:
> In any case, most Y2K-related problems aren't caused by COBOL -
> they're caused by a) the original designers not expecting their
> code to have to last for 20 years, b) just plain forgetfulness and
> c) wild hysteria. None of which (with the possible exception of c)
> are the cause of COBOL. :-)

Nope... the original decision to use 2 digit dates (which are the
fundamental cause of the Y2K problem) was made by the original designers of
the COBOL team, largely 'cause their bosses wanted to skimp on paper tape
costs. A few years later, the picture clause was added to COBOL to allow 4
digit dates, but it was extra work to implement it, and besides dozens of
other companies were using 2 digit dates. It became a tradition, and
managers liked it that way... kept data entry costs down. Which just goes to
show that managers are boneheaded.

> COBOL was designed to be a "user-friendly" language written in an
> english-like syntax so that any PHB would be able to do their own
> programming. Gee, looks like it missed its mark a bit... ;-)

Actually, it was so any PHB would be able to read and understand the
programs their staff spat out. You don't really expect a PHB to sully his
hands writing code, do you?

(Mind you, it still missed its mark...)

--
Duct tape is like the Force: There's a Light side, a Dark side, and it
binds the Universe together.
Robert Watkins -- robert.watkins@******.com

From:	Robert Watkins robert.watkins@******.com
Subject:	[semi-OT] programming languages' evolution
Date:	Tue, 2 Feb 1999 09:16:59 +1000

Message no. 47 Mark Shieh writes:
> > Self-documenting code increases development time, but decreases
> > maintenance time (things like declaring the type of all variables,
> > even if you don't really have to)
>
> I haven't noticed this to be the case. All self-documenting
> code does is force you to produce minimal documentation. If you did
> that anyways, it doesn't make a difference.

Hmm... have you ever done any literate programming?

Literate programming is a logical extension of self-documenting code. You
actually embed the technical documentation into the program code, as
comments. You then run a parser over the code to extract the technical
documentation from the code.

Such a technique does not reduce the amount of documentation you would
produce, though a bit of discipline is required. And the maintainence cost
is decreased, because:
a) Odds are you'll change the comment when you change the code.
b) You don't have to do that silly management trick of updating comment
blocks at the start of functions, and then having to update another document
seperately (which you usually forget about anyway, even though that document
is the offical technical reference for your program).

Java is an example of a programming language set up for literate
programming. You can also get tools for literate programming for C and C++
in Unix (free, of course...). A good IDE that knows about literate
programming will take advantage of it. As an example, check out Microsoft's
J++... function descriptions, parameter descriptions, reminder tags, etc,
are all displayed at appropriate times (e.g.: type a function name, the
description appears in a floating window. Start entering a parameter, a
description of the parameter appears, etc etc). I was so pissed off to see
that Microsoft had built this really cool technology into their J++ (I won't
call it Java) development environment, then left it largely out of their VB
and VC environments, which is where I do my work. Stupid gits.

--
Duct tape is like the Force: There's a Light side, a Dark side, and it
binds the Universe together.
Robert Watkins -- robert.watkins@******.com

From:	Robert Watkins robert.watkins@******.com
Subject:	[semi-OT] programming languages' evolution
Date:	Tue, 2 Feb 1999 09:19:14 +1000

Message no. 48 Mark A Shieh writes:
> Sure, definitely. But does it really make a difference
> whether the documentation consists of some comments at the beginning
> of each relevant section of code and some general advice in a text
> document, or whether javadoc has turned the documents into html form?

Umm... yes it does. If the source of the documentation is in a seperate
location from the source of the program, then changes in one are harder to
reflect in the other, due to extra effort. In many cases (especially with
maintainence programming), the changes won't be carried over. Embedded the
source of the documentation in the program source, and you'll at least make
the effort smaller, if not remove it entirely.

--
Duct tape is like the Force: There's a Light side, a Dark side, and it
binds the Universe together.
Robert Watkins -- robert.watkins@******.com

From:	Robert Watkins robert.watkins@******.com
Subject:	[semi-OT] programming languages' evolution
Date:	Tue, 2 Feb 1999 09:29:09 +1000

Message no. 49 Mark A Shieh writes:
> When I think of selfdocumenting code, I'm thinking of stuff
> written with something like Javadoc as part of the spec, not code
> where it should be intuitively obvious what's going on just by looking
> at undocumented code. (Which, IIRC, was one of the basic concepts
> around C. :P ) If my terminology is off-base, please correct me. I
> don't believe in the existence of fully selfdocumenting code, so I
> assume we're talking about something like forcing Javadoc into your
> spec, which just isn't going to change the way you do things. Either
> you wrote legible code before, and you'll do it despite Javadoc, or
> you didn't, and you'll have a bunch of illegible code with Javadoc
> stubs. I feel really silly documenting a variable called
> "OrderWindow" with the comment, "this is the pointer that stores the
> OrderWindow for the UI.", but Javadoc wants you to spend that effort.

The problem isn't generally with variables. It's more commonly with
functions, and I don't mean their internals...

Good documentation should let you treat a function totally as a black box:
enter these inputs, you get this output, and these side effects occur. And
functions do have side effects... for example, a SaveToDisk function takes
inputs of a file name, a block of data, and a size parameter. It returns a
status code indicating success or what type of failure. The side effects may
be that it creates a file, deletes the old one if necessary, and writes out
data to disk.

When you write the function spec, you'll typically be writing the technical
documentation, and then you'll write the code. If you have to change the
code, you could very well change what the function actually does, so you
have to update the documentation. This is easier if the documentation is in
the code already.

The other point about documentation is that it should say why you're doing
it. Sure, I can read a program and say: Yep, you're walking through this
array, setting data values. But why are you doing it? Legible code (which is
what is meant by self-documenting code) doesn't describe this.

If you don't have documentation, I can assure you that you are not writing
complex programs, which have to be written by multiple people, and
maintained by different multiple people who don't have your level of
programming skill anyway... On the other hand, I don't mean that you should
be putting comments like this (which I have actually seen):

int LoopCounter; // A loop counter.

// Set LoopCounter to Zero
LoopCounter = 0;

.
.
.

--
Duct tape is like the Force: There's a Light side, a Dark side, and it
binds the Universe together.
Robert Watkins -- robert.watkins@******.com

From:	Mark A Shieh SHODAN+@***.EDU
Subject:	[semi-OT] programming languages' evolution
Date:	Mon, 1 Feb 1999 19:19:59 -0500 (EST)

Message no. 50 "Robert Watkins" <robert.watkins@******.com> writes:
> Mark Shieh writes:
> > > Self-documenting code increases development time, but decreases
> > > maintenance time (things like declaring the type of all variables,
> > > even if you don't really have to)
> >
> > I haven't noticed this to be the case. All self-documenting
> > code does is force you to produce minimal documentation. If you did
> > that anyways, it doesn't make a difference.
>
> Hmm... have you ever done any literate programming?

It appears not. :( I haven't had access to any of the IDE
features you describe, which seem to take self-documenting code from a
minor feature into something useful. I still visualized the
documentation as something that just exists, not something that can
integrate with the code like you describe.

> Literate programming is a logical extension of self-documenting code. You
> actually embed the technical documentation into the program code, as
> comments. You then run a parser over the code to extract the technical
> documentation from the code.
>
> Such a technique does not reduce the amount of documentation you would
> produce, though a bit of discipline is required. And the maintainence cost
> is decreased, because:
> a) Odds are you'll change the comment when you change the code.
> b) You don't have to do that silly management trick of updating comment
> blocks at the start of functions, and then having to update another document
> seperately (which you usually forget about anyway, even though that document
> is the offical technical reference for your program).

We've been producing code for internal use, so our technical
documentation is the comment block at the start of a function. Most
of the techniques you describe sound most useful if you're producing a
library to distribute for commercial use, or the internal equivalent
at a large company. I admit that I haven't had to do any coding on
that scale yet. So far, I haven't had any problems reading the
comments at the start of each function and skimming the code I won't
need to comprehend. (Actually, it hasn't been that simple. Most of
the previous code is undocumented, but I'd rather not talk about
agreed-upon bad SE practices.)

However, I can see a literate programming style becoming
useful when well integrated with an IDE, but all of the
self-documenting tools I've seen have been pretty standalone.

Mark

Message no. 51 "Robert Watkins" <robert.watkins@******.com> writes:
> Mark A Shieh writes:
> > I feel really silly documenting a variable called
> > "OrderWindow" with the comment, "this is the pointer that stores
the
> > OrderWindow for the UI.", but Javadoc wants you to spend that effort.
>
> The problem isn't generally with variables. It's more commonly with
> functions, and I don't mean their internals...

I agree with you on documentation style, it just seemed like
the selfdocumenting stuff wants you to document the tiniest little
details.

> Good documentation should let you treat a function totally as a black box:
> enter these inputs, you get this output, and these side effects occur. And
> functions do have side effects...

Yeah, they've been drilling this into me for ages. I've never
claimed that you shouldn't have this type of documentation, only the
format that the documentation needs to take. My main point is that
that a programmer who produces poorly documented code isn't going to
start producing good code just because he's coding in a language and
environment that produces self-documenting code. As a result, I don't
see that a language with built-in selfdocumenting tools like Java and
Javadoc provides any intrinsic advantages over a language that does
not have these tools (built in).

> When you write the function spec, you'll typically be writing the technical
> documentation, and then you'll write the code. If you have to change the
> code, you could very well change what the function actually does, so you
> have to update the documentation. This is easier if the documentation is in
> the code already.

Ah. I think I glossed over this issue, because I think of the
function spec the way you think of documentation. I'm used to my
documentation appearing next to the function already. I can see where
you're coming from, but it seems to me that you have to be working on
a very large project in order for this to be a problem (not being able
to skim for comments already embedded within the code).

> The other point about documentation is that it should say why you're doing
> it. Sure, I can read a program and say: Yep, you're walking through this
> array, setting data values. But why are you doing it? Legible code (which is
> what is meant by self-documenting code) doesn't describe this.

Sure, definitely. However, this is more of an issue of what
makes up good documentation, not the issue of whether self-documenting
code makes a big difference. I expect a discussion of what good
documentation should consist of to be pretty short and dull, as all
sides are likely to agree on the matter.

> If you don't have documentation, I can assure you that you are not writing
> complex programs, which have to be written by multiple people, and
> maintained by different multiple people who don't have your level of
> programming skill anyway...

Actually, this isn't true. This is what happens at work, and
it's hell. :) Documentation has been working its way into the code
written by some of the people trained to do so, but there's so much
legacy code... Now, if you were to claim that we would be able to
write at least an order of magnitude more effectively if the original
programmers had started with good documentation, I won't disagree. :)

Mark

Message no. 52 Mark A Shieh writes:
> > Good documentation should let you treat a function totally as a
> black box:
> > enter these inputs, you get this output, and these side effects
> occur. And
> > functions do have side effects...
>
> Yeah, they've been drilling this into me for ages. I've never
> claimed that you shouldn't have this type of documentation, only the
> format that the documentation needs to take. My main point is that
> that a programmer who produces poorly documented code isn't going to
> start producing good code just because he's coding in a language and
> environment that produces self-documenting code. As a result, I don't
> see that a language with built-in selfdocumenting tools like Java and
> Javadoc provides any intrinsic advantages over a language that does
> not have these tools (built in).

Okay... a programmer that produces poorly documented code isn't going to
magically start producing good code. But an environment which encourages
documented code will produce better documentation that an environment that
doesn't. Given that documentation is a goal to be desired, tools that reduce
the effort in creating the documentation, and that reduce the effort of
_maintaining_ that documentation, are highly useful. And if the IDE has
enough smarts to use the data itself, that's even better.

--
Duct tape is like the Force: There's a Light side, a Dark side, and it
binds the Universe together.
Robert Watkins -- robert.watkins@******.com

Message no. 53 My take on the whole documentation issue is that its really a moot point
as far as Shadowrun goes anyway <ducks carp from the programmers in the
audience>.

A couple of reasons for this:

a.) Programmers must be taught (or beaten into submission) to document
this well. This happens when compsci profs deduct major points for poor
documentation, or when they get real jobs and find out that they either
document or piss a lot of people off and have to find another job.

b.) Shadowrunner deckers generally don't have real jobs. My take is that
the majority of them are more akin to hackers than software engineers.
They write their code and tinker with it until it works. There are
exceptions of course, but most of them are this type:
"It's my code; I know what I'm trying to do. If nobody else can read it
so what? That way they won't try to steal my warez."

Doubtless there are exceptions, but (IMNSHO) they are few and far
between.

Eric
esh7695@******.sdsmt.edu

Message no. 54 Mark A. Shieh wrote:
> > Large existing libraries allow faster development
> The key is for these libraries to come standard with the
> language, and you can treat these as shared. 3rd party libraries
> don't have as many of these benefits, but all languages of note have
> "large existing libraries".
>
Scheme? Modula-3? Compare what *they* offer with the C standard
libraries. *I* see the difference. :-)

> > Self-documenting code increases development time, but decreases
> > maintenance time (things like declaring the type of all variables,
> > even if you don't really have to)
> I haven't noticed this to be the case. All self-documenting
> code does is force you to produce minimal documentation. If you did
> that anyways, it doesn't make a difference.
>
Well, *I* don't document the use and type of every variable I declare.
I do try to use consistent, self-explanatory variable names (I detest
Hungarian notation, though). Yes, more documentation helps (provided
that it's well organized, clear and thorough) - that's why languages
that require you to minimally document make things clearer later on
down the road.

> You may also want to see if you can make platform independence
> worthwhile. LISP and Java are the two most independent languages I
> know of, while ASM and VisualWhatever are the least. :) Maybe you
> could oversimplify and claim that all Fuchi decks are compatible and
> run the same software.
>
Actually, VB is reasonably portable - it's compiled to Pcode, don't
forget. Nobody cares enough to make Pcode interpreters for other
boxes, though... :-)

C is very independent. BASIC is trivial as well as interpreted, and
thus independent. SQL is too fragmented to be called portable.

> Oh, umm... uhh, all, uhh, all Novatech decks are compatible
> and run the same software, and have a 95% chance of running Renraku
> software, and a 100% chance of running all Novatech subsidiary soft...
> nevermind.
>
Yeah - not much point.

> > So, some of the languages I've used (I'll try to stick to the most
> > common usage - most people don't use a C interpreter, for example,
> > although at least one exists):
> >
> > ASM compiled, very low-level
> ^^^^^^^^
> Heh. barely...
>
OK, "translated" - that better? :-)

> > C compiled, libraries, shared, declared, low-level
> ^^^^^^^^
> Declared? You never defined what you think you get out of a declared
> language. (What do you mean by declared, anyways, strongly typed?)
>
Pretty much - it was a short, one-word alternative to "self-
documenting".

> > Scheme interpreted, libraries, mid-level
> I thought Scheme compiled, just like LISP. It's been quite a
> while since I've used it though, so I'm not sure any more.
>
We used an interpreter.

> LISP interpreted, compiled, libraries, OO, mid-level
> [Oh, you noticed the similarities between Java and LISP too, eh? :) ]
>
I haven't actually programmed in LISP - my LISP knowledge is derived
from going "Ick!" looking at some emacs code and knowing that it's
damned close to Scheme. I'm a vi person, myself. :-)

> > VBasic interpreted, compiled, libraries, shared, mid-level
> <cough> There's no way I can think of VBasic as anything but a
> high-level language. I think it has to do with the ability to churn
> out VB code at record speed, and the performance issues I've seen with
> VB apps.
>
Well, I think that it's too close (in syntax) to something like Pascal
to be called high-level. The performance issues are another problem
entirely. It's got some high-level *objects* (collections, for one),
but those are easily replicated. The only reason I would veer towards
high-level would be the GUI layout stuff.

James Ojaste

Message no. 55 Mark A Shieh wrote:
> > If I understand this one right I have to disagree. There is no
> > excuse for not having code documented well.
>
> I agree, there's nothing worse than going through someone
> else's undocumented code. However, I'm saying that a language that
> produces self-documenting code doesn't inherently do anything unless
> your coding style was pretty atrocious to begin with. If you produce
> good code with documentation in a language without this ability,
> you'll produce the same stuff in a language with self-documenting
> code.
>
Ah, but then the programming style modifies the development and
maintenance time the same as a similarly structured language would.
In short, the language enforces base compliance. It's all the same
in terms of mechanics. :-)

Just sacrifice development time for a lower maintenance TN. :-)

James Ojaste

Message no. 56 >I've been debating making the switch. Seems like you need to
>learn a lot of UNIX guts and be on call a whole lot though. I like
>my flexhours. :)
There is a lot to learn don't get me wrong. And yeah I'm oncall
almost all the time, but in general that is because most unix
systems are running mission critical stuff. On the upside my unix
systems are far more stable then the NT or Novell boxes, and
their uptimes aren't even comparable. I tend to get paged for
network issues related to NT more often then the unix system.

------------------------------------------------------------------------------------
Lehlan Decker, Unix Admin (704)331-1149
deckerl@******.com Fax 378-1939
Moore & Van Allen, PLLC Pager 1-888-608-9633

Message no. 57 "Ojaste,James [NCR]" <James.Ojaste@**.GC.CA> writes:
> Mark A. Shieh wrote:
> > > Large existing libraries allow faster development
> > The key is for these libraries to come standard with the
> > language, and you can treat these as shared. 3rd party libraries
> > don't have as many of these benefits, but all languages of note have
> > "large existing libraries".
> >
> Scheme? Modula-3? Compare what *they* offer with the C standard
> libraries. *I* see the difference. :-)

Ohh... standard libraries. I took "existing libraries" at
face value. For example, we had an implementation of OpenGL that had
been ported to Scheme in out Graphics 1 class that I consider an
existing library. (We also complained enough about coding in Scheme
that they went back to C the next year)

> Ah, but then the programming style modifies the development and
> maintenance time the same as a similarly structured language would.
> In short, the language enforces base compliance. It's all the same
> in terms of mechanics. :-)

That's where I disagree. Language attempts to enforce
base compliance, but so does a minimum of computer training. It's the
programmer and his coding style, not the language. Certain languages
may suggest good coding style more than other languages, but it's
still the programmer's task to make sure they obey it.

> Just sacrifice development time for a lower maintenance TN. :-)

I just feel that this should be available to any competent
programmer no matter what language they're using, and available to a
lousy programmer in a self-documenting language by making them become
better programmers.

Mark

Message no. 58 Mark A. Imbriaco wrote:
> > So, some of the languages I've used (I'll try to stick to the most
> > common usage - most people don't use a C interpreter, for example,
> > although at least one exists):
> >
> > Pascal compiled, libraries, shared, low-level
> > Scheme interpreted, libraries, mid-level
>
> Perl compiled then interpreted, libraries, shared, high-level, pseudo-OO
>
> Can't forget that one. :-)
>
Doh! Didn't mean to... I intended specifically to include that.
*sigh*

I'm not entirely convinced that Perl is high-level. It allows you to
do all sorts of wonky stuff, but it also allows you to do lots of
lower-level stuff.

Perl is also *both* compiled and interpreted, though not in series
(I'm counting Pcode as interpreted, but Perl2C counts as compiling).

James Ojaste

Message no. 59 Mark A Shieh wrote:
> > > > Large existing libraries allow faster development
> > > The key is for these libraries to come standard with the
> > > language, and you can treat these as shared. 3rd party libraries
> > > don't have as many of these benefits, but all languages of note have
> > > "large existing libraries".
> > Scheme? Modula-3? Compare what *they* offer with the C standard
> > libraries. *I* see the difference. :-)
>
> Ohh... standard libraries. I took "existing libraries" at
> face value. For example, we had an implementation of OpenGL that had
> been ported to Scheme in out Graphics 1 class that I consider an
> existing library. (We also complained enough about coding in Scheme
> that they went back to C the next year)
>
OK, OGL may be "large" from the viewpoint of executable size, but it's
a very narrow area. The C standard libraries cover everything from
files to user interaction to string manipulation. On top of *that*,
just about every library ever written is accessible from C. C has,
IMO, the best library support of any language.

> > Ah, but then the programming style modifies the development and
> > maintenance time the same as a similarly structured language would.
> > In short, the language enforces base compliance. It's all the same
> > in terms of mechanics. :-)
>
> That's where I disagree. Language attempts to enforce
> base compliance, but so does a minimum of computer training. It's the
> programmer and his coding style, not the language. Certain languages
> may suggest good coding style more than other languages, but it's
> still the programmer's task to make sure they obey it.
>
If it won't compile unless you declare your variables, you have to
declare your variables. Yes, programming style matters a whole heap,
but most languages enforce at least some basic style.

> > Just sacrifice development time for a lower maintenance TN. :-)
>
> I just feel that this should be available to any competent
> programmer no matter what language they're using, and available to a
> lousy programmer in a self-documenting language by making them become
> better programmers.
>
That's what my point was. If you take more time for development,
you can decrease the TN for maintenance. Certain languages, however,
will *force* the programmer to spend X extra time on this "enforced
documentation". If the programmer is willing, they can spend as much
time as they like - this is just a minimum standard.

James Ojaste

Message no. 60 On Tue, 2 Feb 1999, Ojaste,James [NCR] wrote:

> > Perl compiled then interpreted, libraries, shared, high-level, pseudo-OO
> >
> > Can't forget that one. :-)
> >
> Doh! Didn't mean to... I intended specifically to include that.
> *sigh*
>
> I'm not entirely convinced that Perl is high-level. It allows you to
> do all sorts of wonky stuff, but it also allows you to do lots of
> lower-level stuff.

I think the same could be said about any language that is a "high level"
language.

> Perl is also *both* compiled and interpreted, though not in series
> (I'm counting Pcode as interpreted, but Perl2C counts as compiling).

It is indeed in series. When you invoke the standard perl "compiler"
(read: binary) it compiles into pcode which is then interpreted. There
are also the new compiler backends that turn the pcode into other things,
but since they're not very stable yet I tend to leave them out of
practical discussions.

-Mark

Message no. 61 According to Ojaste,James [NCR], at 9:23 on 2 Feb 99, the word on
the street was...

> Doh! Didn't mean to... I intended specifically to include that.
> *sigh*

Yeah, that's what I always used to say after exams, too :)

--
Gurth@******.nl - http://www.xs4all.nl/~gurth/index.html
If it's no use pretending, then I don't want to know.
-> NERPS Project Leader * ShadowRN GridSec * Unofficial Shadowrun Guru <-
->The Plastic Warriors Page: http://shadowrun.html.com/plasticwarriors/<-
-> The New Character Mortuary: http://www.electricferret.com/mortuary/ <-

GC3.1: GAT/! d-(dpu) s:- !a>? C+(++)@ U P L E? W(++) N o? K- w+ O V? PS+
PE Y PGP- t(+) 5++ X++ R+++>$ tv+(++) b++@ DI? D+ G(++) e h! !r(---) y?
Incubated into the First Church of the Sqooshy Ball, 21-05-1998

Mailing List Logs for

Further Reading

Disclaimer