Philosophical musings: interpreting models
07 Sep 1999 12:06:19 +0200
>>>>> "Jim" == Jim Little <email@example.com> writes:
Jim> Laurent Martelli wrote:
>> >>>>> "Jim" == Jim Little <firstname.lastname@example.org> 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
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)) ?