Difference between revisions of "Talk:ConfigurationFileFormat"

 
(One intermediate revision by the same user not shown)
Line 14: Line 14:
 
==Manus==
 
==Manus==
 
The format is just an internal mean and it is only in XML format to make it easy to store in source control management system. We will go towards the edition through a hopefully nice graphical interface, we have the experience of what currently exists in EiffelStudio to make something much easier to use.
 
The format is just an internal mean and it is only in XML format to make it easy to store in source control management system. We will go towards the edition through a hopefully nice graphical interface, we have the experience of what currently exists in EiffelStudio to make something much easier to use.
 +
 +
==Gmc444==
 +
After writing my initial post, I did get to see a demo of how the new file format works, and how it's represented in an Eiffel-like format for users. It surprises me a little that the Eiffel-like presentation would be considered harder to work with in source control than XML. Oh well, as long as I don't have to worry about hand-editing XML I can live with it =)
 +
 +
after giving this more consideration, I've come to two conclusions:
 +
 +
First, I still don't like XML. It's a marginal language for simple constructs, unreadable for complex constructs, and truly horrid for trying to use as a programming language.
 +
 +
A build specification language has to be a programming language, of that I'm convinced. You need variables (state), conditional statements (flow of control), input and output. I don't know of any really successful attempts to build a programming language using XML syntax.
 +
 +
One problem with Lace is that it's a declarative language that looks like Eiffel, an imperative language. I think this leads to problems in expressing programming notions that might otherwise be easy to express.
 +
 +
I think extending a declarative language like Lace will be problematic for people used to imperative programming.
 +
 +
Rebuilding that declarative language in XML will only lead to similar problems, but they'll just be harder to read.
 +
 +
What I would like to see is a set of specialized Eiffel classes that would be used to describe the system being built. I'll try to sketch out what this would look like, and if it looks viable, I'll put it forward.

Latest revision as of 10:16, 24 January 2007

Gmc44

This proposal for a configuration file format looks similar to what was done with geant and gexace.

Personally, I think XML is an inappropriate format for this job. It might be a good idea to talk to Gobo (Eric Bezault) about his experience with those tools.

Among the problems:

XML is very verbose, and while it can be read by a human, it's not very easy to read. In this respect it's much worse than Ace files.

To solve configuration problems, you need all the basics of a programming language: input, output, state, conditionals, and iteration. Using XML to represent these often becomes kludgy. Look at the effort that goes into solving what should be fairly simple if conditions.

I think it would be far better to evolve the Ace file specification, perhaps into a subset of Eiffel that allows us to write a clear, declarative specification of a system without a lot of <tag>s and </tags> and obtuse rules.

Manus

The format is just an internal mean and it is only in XML format to make it easy to store in source control management system. We will go towards the edition through a hopefully nice graphical interface, we have the experience of what currently exists in EiffelStudio to make something much easier to use.

Gmc444

After writing my initial post, I did get to see a demo of how the new file format works, and how it's represented in an Eiffel-like format for users. It surprises me a little that the Eiffel-like presentation would be considered harder to work with in source control than XML. Oh well, as long as I don't have to worry about hand-editing XML I can live with it =)

after giving this more consideration, I've come to two conclusions:

First, I still don't like XML. It's a marginal language for simple constructs, unreadable for complex constructs, and truly horrid for trying to use as a programming language.

A build specification language has to be a programming language, of that I'm convinced. You need variables (state), conditional statements (flow of control), input and output. I don't know of any really successful attempts to build a programming language using XML syntax.

One problem with Lace is that it's a declarative language that looks like Eiffel, an imperative language. I think this leads to problems in expressing programming notions that might otherwise be easy to express.

I think extending a declarative language like Lace will be problematic for people used to imperative programming.

Rebuilding that declarative language in XML will only lead to similar problems, but they'll just be harder to read.

What I would like to see is a set of specialized Eiffel classes that would be used to describe the system being built. I'll try to sketch out what this would look like, and if it looks viable, I'll put it forward.