Linked by Hadrien Grasland on Sun 29th May 2011 09:42 UTC
OSNews, Generic OSes It's funny how trying to have a consistent system design makes you constantly jump from one area of the designed OS to another. I initially just tried to implement interrupt handling, and now I'm cleaning up the design of an RPC-based daemon model, which will be used to implement interrupt handlers, along with most other system services. Anyway, now that I get to something I'm personally satisfied with, I wanted to ask everyone who's interested to check that design and tell me if anything in it sounds like a bad idea to them in the short or long run. That's because this is a core part of this OS' design, and I'm really not interested in core design mistakes emerging in a few years if I can fix them now. Many thanks in advance.
Permalink for comment 474970
To read all comments associated with this story, please click here.
RE[6]: Comment by Kaj-de-Vos
by xiaokj on Sun 29th May 2011 21:36 UTC in reply to "RE[5]: Comment by Kaj-de-Vos"
Member since:

Define declarative data, Google and Wikipedia have no idea what this is and I haven't either ;)

Let me help, whatever I can, here. If, and that is a very big "if", I am correct, he is referring to something really esoteric. It should be a design philosophy coming straight out of things like "Art of Unix Programming".

Apparently, he is trying to tell you that there is a very much more abstract way to deal with stuff than the RPC. To work with RPC, you will need to define the function name and its accepted parameters, and that would then be set in stone. If you used declarative data, then, what you would do is to have the library export a datasheet of "what can I do" and when you pick a specific function, "what options are here", complete with version numbers. Preferably XML. Then, the clients can make do with whatever that is provided.

The benefits of this is that major changes can be done a lot easier than before. However, there is a major downside too: it is much harder to code in that form. The benefits tend to pay out over the long run, but still.

The main point of doing things like this, other than the obviously stated one, is that it makes you get used to declarative data structures. They, on the other hand, make much more sense! As the Art of Unix Programming notes, the human mind is a lot better at tackling complex data than complex code flows. Declarative data structures push the complexity into the data side, so that the overall code becomes a lot cleaner, and it is in there that the benefits can be most easily reaped.

Take the pic language for example. It is a lot easier to declare that you want a rectangle of a certain size, and that its top left corner (NW) corner is connected to an arrow that points to a circle of radius so and so. The code then takes care of the rest. These kinds of code tend to stay sane even with extreme longevity whereas if you tried to define things by coordinates, sooner or later your API will be replaced, for such simplistic API are a dime a dozen. Declarative programming is something like that, and it is really time-saving.

I hope I have correctly captured his idea. I don't know anything, actually, so take some salt with this.

Reply Parent Score: 2