From:	Ojaste,James [NCR] James.Ojaste@**.GC.CA
Subject:	[semi-OT] programming languages' evolution
Date:	Tue, 2 Feb 1999 09:17:48 -0500

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