Philosophical musings: interpreting models
Thomas M. Farrelly
Fri, 17 Sep 1999 19:23:31 +0200
Jim Little wrote:
> Another way to look at it is to say that the fewer lines of code your
> program requires, the higher-level language you are using. This
> approach also demonstrates the analog rather than discrete nature of
> "levels". A language isn't so much "low" or "high" level -- it's
> "lower" or "higher" level.
Ok, that's a nice! By this defintion, the level of something messures
how rich a language is with respect to a problem domain - that has
actual practical value :)
Problems however is that it is very dependent on the problem domain. In
a way so that a SQL would be highlevel in the domain of relational
databases, while lowlevel in the domain of telephone operation.
Personally I'm very lowlevel in relation to football - but if I started
playing alot, more and more of the game tactics and techniques would be
assinged to my "instincts" and I would get more highlevel.
It's a definition of level that could fit well with RPG.
Another problem is that it makes any system lowlevel to the programmer,
because there wouldn't be any point in programming something unless what
you're doing is higher level - so to the programmer, everything is
low(er)level. But once I accept your defintion this is a nice angle to
view the construction of systems as building things on top of others. (
Sometimes, however, things are dependent on each other with out defining
different levels ).
> That's why I say Lisp is a low-level language -- for most tasks, its
> semantics aren't even close to those required for the task at hand.
Dependent on the task. It's highlevel when dealing with functions, lists
> Yes, you can write high-level functions, but there's a difference
> between a high-level language and a low-level language with high-level
> functions, which I address in my email to Laurent.
I'd read that first.
Thomas M. Farrelly email@example.com www.lstud.ii.uib.no/~s720