Philosophical musings: interpreting models

[Laurent Martelli]

>>>>> "Jim" == Jim Little <jiml@inconnect.com> writes:

  Jim> Laurent Martelli wrote:
  >>  >>>>> "Jim" == Jim Little <jiml@inconnect.com> writes:
  >> 
  Jim> So it's important to know the limitations of a program's
  Jim> original metamodel.  And when modeling a new program, it's
  Jim> important to specify as little as possible (while still
  Jim> specifying everything necessary) so that metaprograms which
  Jim> operate on the model may have as much flexibility as possible
  Jim> to optomize the program for the user's current computing needs.
  >>  I fully agree. That's what I call abstraction. I believe this is
  >> the key to portability and reusability. I think it can be
  >> achieved by minimising the dependencies.

  Jim> I also think this kind of abstraction can lead to better
  Jim> optomizing compilers.  The higher the level of abstraction, the
  Jim> more the compiler can "know" about the program, and thus the
  Jim> better job it can do of optomization.

  Jim> I would say that the key is not so much minimizing
  Jim> dependencies, though, as it is using languages which provide
  Jim> high-level semantic constructs.  I.e., the language should be
  Jim> capable of expressing your goals exactly.  If your goal is to
  Jim> output 'hello world' and you don't care where, then 'PRINT
  Jim> STDERR "Hello, World!"' will work, but only 'OUTPUT "Hello,
  Jim> World!"' exactly expresses your goals.

I think that the problem is often not in the language itself, but in
the libraries, and the use of the language. OUTPUT should not be part
of a language. If a library provides you with an OUTPUT(stream,string)
you'll either use it and produce a non-portable program, or define a
new function MYOUTPUT(string) and not reuse what already
existed. That's why I think that it is not only a problem of language,
but also a problem of design in libraries and software. Note that in
the second case, you can reuse if you have access to the source code
of OUTPUT, and if you change it so that MYOUTPUT and OUTPUT both call
a third function _OUTPUT.

  Jim> The tricky part is finding languages with semantics which allow
  Jim> you to exactly express your desires.  I think the key is
  Jim> domain-specific languages rather than general-purpose
  Jim> languages.

I don't agree. The problem with domain-specific languages, is that
they often share some basic features, such as arithmetics and file
accesses. So in the end you have to duplicate a lot of work in order
to implement those features in all the domain-specific languages. Of
course, you can use a common low-level C library in order to share
something and speed up the work, but since DSL will very likely
implement the same features in a slightly different and incompatible
manner, a library written for one DSL won't be usable in an other
DSL. Unless you go into making a translation program that is unlikely
to work in 100% of the cases since all DSL are not equivalent. 

So I'd rather have one language (understand one semantic), and have
the opportunity to change the syntax to make it more user-friendly for
different domains. Take LISP. Most people think it has a very
inconvenient syntax because of all the parenthesis. However, it has
one of the cleanest semantic. What prevents us from wrting a special
editor that would allow us to write (2+5)*3 instead of (* 3 (+ 2 5)) ? 

-- 
Laurent Martelli
martelli@iie.cnam.fr