"not really a programming language"

ta0kira · 06-06-2009, 06:26 PM

Quote:

Originally Posted by paulsm4

c) Finally, I would humbly suggest that, if your format isn't already XML, that might give you the biggest long-term gains. If you focussed on standardizing your "data format", that might ultimately prove to be far more beneficial that worrying about "programming syntax".

I'm trying very hard to avoid any sort of structure within the scripts, other than having each line stand alone (if that's the "data format" you refer to.) A wizard might be helpful, but hopefully it will be simple enough that it would be easier for any competent person to write them by hand (I avoid GUIs whenever possible.) The actual data being operated on is stored in an SQL database, the modules are capable of operating on that database, and the scripts specify exactly what operations which modules are to perform. The closest thing I can think of, in terms of script purpose, is a gnuplot file. Such a file merely sets up the environment to generate an image (e.g. setting up the PNG module and directing it to plot a set of data.) This application should require much less setup, however, because output will generally be a 2-D matrix.
Kevin Barry

ta0kira · 06-06-2009, 06:45 PM

Quote:

Originally Posted by paulsm4

XML, dude. Think XML...

I actually think XML is too complex for this purpose, and I strongly believe it shouldn't be hand-written (I see it as strictly an inter-application data format.) It would, therefore, have to either be written by a wizard or generated from a config file. I just don't think the hierarchical syntax of XML is relevant here, although it might be suitable for input and output data. The script files in question don't actually contain data; they merely sequentially control the behavior of the application, which incidentally might involve directing a module to a data source. The "control channel" (the scripts we're discussing) and "data channel" are 100% exclusive of each other.
Kevin Barry

paulsm4 · 06-06-2009, 07:18 PM

Hi, again -

Quote:

I'm trying very hard to avoid any sort of structure within the scripts

Exactly my point. Your scripts clearly have "structure"; whether you've explicitly thought about it is another question entirely.

It sounds like "data structure" is exactly the area you need to focus on, if you want your application to be as flexible (able to meet future needs) and robust (able to deal with invalid data; able to work with other "application" tools besides those you've already happened to write).

XML may - or may not - be the best choice for your application.

But I think XML - a mature, self-describing data representation format - is an excellent place to start.

Again - just my $.02 .. PSM

ta0kira · 06-06-2009, 07:57 PM

Quote:

Originally Posted by paulsm4

Exactly my point. Your scripts clearly have "structure"; whether you've explicitly thought about it is another question entirely.

Yes, but they have arguably less structure than even asm; they're nothing but flat, "forward-only" sequences of operations (literally top-to-bottom single-line execution, with no exceptions.) The only thing XML (or similar) would do is turn this:

Code:

command1 arg1 arg2
command2 arg3 arg4

into this:

Code:

<?xml version="1.0" encoding="UTF-8"?>
<MyProgram>
   <FileHeader>
      <Element>
         <Name><![CDATA[ScriptType]]></Name>
         <Value><![CDATA[do stuff]]></Value>
      </Element>
   </FileHeader>
   <CommandLine>
      <Command><![CDATA[command1]]></Command>
      <Argument><![CDATA[arg1]]></Argument>
      <Argument><![CDATA[arg2]]></Argument>
   </CommandLine>
   <CommandLine>
      <Command><![CDATA[command2]]></Command>
      <Argument><![CDATA[arg3]]></Argument>
      <Argument><![CDATA[arg4]]></Argument>
   </CommandLine>
</MyProgram>

That's quite an obfuscation of something that was previously a lot simpler, not to mention it would probably start in the first format in order to generate the XML. The indentation in the XML indicates nesting; there should never be a need for such clarification within these scripts. Such a format might be very useful if the files also contained data, but they won't. Most of the input data will be XML from another source, however.

Despite the meanings of the individual tokens in my implementation, each line is turned into an argv-like array of tokens and the newline tells the parser where each array ends. This results in an array of "argvs". The execution conditions and label substitution make it seem a lot more structured than it actually is; the first few tokens merely tell the interpreter what function to call, and the rest of the tokens are passed to that function.
Kevin Barry

paulsm4 · 06-06-2009, 10:29 PM

Hi, again -

Obviously, do what you think is best.

And as I said in my initial post, there's absolutely nothing wrong with exactly what you're doing now, with both your programs and your data - they both sound more than adequate for the job at hand.

But I'm very clear that worrying about "language" is probably a waste of time for your particular application - but investing a bit more thought about "data structure" and "data representation" could well yield big dividends. Both immediate gains, and long-term gains.

And frankly, the way the discussion has gone has even more convinced me that's probably the case. I don't buy your straw man argument against XML. But again, I want to emphasize that I don't necessarily consider XML the "best" solution: it's merely an excellent example of something that plays the "data representation" game really, really well. I honestly believe that you could probably do better than the flat files you're using now.

Good luck!

Your .. PSM