OIL review ?
08 Nov 1999 15:42:34 +0100
>>>>> "Jim" == Jim Little <email@example.com> writes:
Jim> Laurent Martelli wrote:
>> I think that I've implemented almost all the features that I
>> wanted to have in OIL, so I believe that it's time for a
>> review. Do you think it has flaws ? Is it missing important
>> features ? (I am not talking about performance issues here, just
Jim> As I imagine you are also discovering, useful responses are
Jim> hard to find on this list. :) So I'd like to critique OIL.
Jim> That's hard, though, because you haven't really issued a strong
Jim> statement of what it's for. But I'll do my best:
Jim> On your web page, you state that your goal is to support an
Jim> "open interpreter" that will support AOP. I don't know what an
Jim> open interpreter is, but it seems to me that OIL does not meet
Jim> the goal of supporting AOP, other than in the most general (and
Jim> not particularly useful) Turing-compatible sense.
This is perfectly true. For now, we only have an interpreter. In fact,
I'd like to have critism before we start opening it. By "opening the
interpreter", we mean providing generic means to specify the way it
interprets programs and specification. For the moment, it is not very
optimized, but we want to provide means to introduce special
Jim> In a previous email message to this list, you stated: "What I
Jim> really want to achieve is separation of concerns :
Jim> specification and implementation." I don't see how OIL meets
Jim> this goal, either.
You're rigth once again. It only allows users to specify.
Jim> It seems to me that what you do have is a system for lambda
Jim> abstraction, not too much different than any other programming
Jim> language that supports function calls. OIL's uniqueness
Jim> appears to lie in the fact that it's run-time extensible in
Jim> that you define new lambda abstractions at runtime -- its
Jim> interactive. It's also persistent, which is nice.
One thing that I'd like to know is : "Does OIL allow us to compute
anything that is computable". I think it does, but since I haven't
done a formal proof of this statement, I cannot be sure.
Jim> I see some things that could potentially be problems, but
Jim> without knowing what your concrete goals for OIL are, it's hard
Jim> to say if they're really problems or not. Without that overall
Jim> vision of where OIL is going, though, I can't see how OIL is
Jim> much different than an interactive Lisp -- and I'm not a Lisp
Jim> guru, but I believe that such things are already available.
I'd say that the main difference is that all objects but variables are
immutable. And the fact that bindings are not part of the core
semantics of the language.
Jim> So in summary, I'd say my biggest critique of OIL is not the
Jim> system itself but the lack of published direction. Without
Jim> that, it's impossible to say if OIL is feature-complete or not,
Jim> because I don't know what the feature set is supposed to be! :)
For the moment, it is supposed to be able to compute anything that is
Jim> PS: I'm not trying to be harsh, but I AM trying to provide
Jim> useful feedback -- something which is SORELY LACKING on this
Jim> list, HINT HINT folks!! (And I'm sure Brian would agree with
Jim> me on that point, even though we seem to disagree on everything
Jim> else. ;) )
I have to thank you very much. This was helpful. It showed me that my
question was not precise enough.