Greatest Software Ever Written 4234

This is where I have to digress. Making a small, simple interpreter is "programming 101" stuff. If you are doing a large project you will deal intensively with data representation and configurations; you will make a language out of that. Rather do it well!

Almost all large computer projects I have been in have had their main problems centered around taxonomy; i.e. making a good and sound clbuttification and description in the relevant problem space. A surprisingly high part of the projects has been down to detail and clbuttification issues.

here I agree. But I see professionals screaming for a way to express their instructions to the computer; it just has to grok the primitives they operate in.

Just look at how excel gets abused.

Example : A proper accounting system should have a small interpreter (or even compiler) handling the accounting objects. It should have t-accounts, transactions, batches-lists of transactions, and a way to trap on reference in this language. The language can also solve the audit-trail problems in a way the user cannot step out of.

It should take care of a decent database interface to the database of choice.

Then build all the business logic on top. Make the language user-friendly and the professionals will write their own code, just as they do in excel; except they pretend they are not writing code.

-- mrr