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

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