Quote:

I think we can all agree that if the core language allows you to do a job in fewer keystrokes, and more intuitively, then that is the better option.



I understand what you mean however I don't think that we'd all agree on that statement without a few major qualifications

There are libraries available for all sorts of discrete functions - XML, mail, network, maths, forms, 3D graphics, HTTP, HTML, updates, security, SNMP, AD, regular expressions and many more. These provide discrete functionality and are written by experts in their field - at least you'd hope they are anyway.

I don't think that it's a good idea to implement a crippled version of any functionality that is already available - it doesn't make sense. You surely want to use the libraries with the most recent enhancements and bug and security fixes and not have to wait until Ruud can update KiXtart?

The best compromise would be if Ruud added functions that simply called the APIs directly. That however adds no real benefit over loading an XML UDF library at the top of a script with your own ReadXML() and WriteXML() functions to call the APIs.

An XML support library to provide these sort of functions has already been written by board members and is available elsewhere - this will add the simplified function calls to KiXtart without requiring it to be hard-coded into the interpreter.

Rather than duplicating already available functionality into KiXtart we'd be better off improving the interface to COM to allow more objects to be used - event sinks and support for "out" variables for example. Promoting use of COM and providing extensive examples in the manual to help starters and COM-ophobics wouldn't hurt either.