amthonyblack wrote:Now in answer to your previous questions one of the applications I am interested in is desktop and web automation.
Thanks for that. Knowing the focus of your interests is very helpful.
From what I am reading Livecode is not suitable to those tasks or perhaps any tasks that involved image recognition (which would include quite a few practical applications)
It depends on the specifics. There are those who might say LiveCode is best for everything, and those who might say it's best at nothing. As with any extreme position in any area of human endeavor, I believe both would be wrong.
Let's look at the areas you've mentioned:
Web Automation
I wouldn't attempt an HTML rendering engine in LiveCode, but then again very few even attempt that in C. Today there are only three such engines in common use (IE, WebKit, and Firefox); it's a daunting task in any language.
Similarly, WYSIWYG HTML authoring tools are an area where, although I've made some for specific sites, a generalized app for that is so challenging that there are only a handful in all the world worth using (Dreamweaver and Blue Griffon come to mind).
But "web automation" is a broad field, so broad that I don't think a single definition could apply.
Spidering, scraping, indexing, mashing and dozens of other methods may be relevant. While I've used LC for all four of those, in some cases it's a good fit and in other cases off-the-shelf systems, like Lucene for indexing, are a better choice than any custom one-off, regardless of the language you'd write it in.
In addition to my relatively simple WebMerge tool (which despite its simplicity has been used by AOL, the US Library of Congress, BMI Music Publishing, and thousands of smaller web shops), there have also been other web tools built with LiveCode like Altuit's Hemmingway CMS and Blue Mango's Screen Steps, and many more.
On my plate at the moment are two more projects involving web automation: one is a custom client-server CMS solution for one of the largest privately-held companies in America, and the other is a server-side CMS solution for more general use (I'll be making it available for free later this year; more on that later). Both of these use LiveCode exclusively, for everything all the way down to the data store.
The Web is largely comprised of just plain text: HTML, CSS, and JavaScript. LiveCode is unusually adept at manipulating text, and can use GET and POST over HTTP very easily. It's nearly as easy as Sed and Awk for working with delimited text (often easier), includes extensive XML support, with libraries for JSON and other common formats available. It also includes support for common data stores like SQLite, MySQL, and even Oracle, and I believe libraries for interfacing with MongoDB and CouchDB are being developed by members of the community.
Smartly applied, there's almost no end to what can be done with LiveCode to build Web production apps and services.
Desktop Automation
The situation is similar on the desktop: many automation solutions involve using LiveCode as middleware between other apps. With LC's ability to parse command line arguments sent to it, send and receive Apple events and AppleScript, send VBScript and shell scripts, read and write from serial ports, use sockets, stdIn and stdOut, read and write Registry settings, and with an externals API available for anything it doesn't handle out of the box, it can be very useful in a surprisingly broad range of contexts.
Even my modest WebMerge tool provides a very simple but useful mechanism to allow it to be used in larger workflow automation: its settings files include an option to automatically run, generate pages, upload them, and quit whenever the app is launched with such a document. Many of our customers take advantage of their DBMS' ability to launch documents with a specified app (FileMaker, Access and many others support this) to integrate WebMerge into completely automated solutions.
While the current version of LiveCode lacks direct support for generic Windows DLLs, anyone considering a lower-level language for that could write LiveCode externals for those, so they get the best of both environments.
But given what's in the box, most folks I know using LC for automation don't commonly need to write custom externals.
Image Recognition
As for image recognition, that's among the types of tasks so extremely computationally expensive that not even Java is widely used for that, and almost never any scripting language. C was invented as a replacement for Assembler, and as such it's a good choice for that sort of work.
But of course for any algo to be useful it also needs a UI. For command line utilities it wouldn't matter of course, but most apps will need a graphical user interface, so it can make good sense to implement an image recognition algo (or any computationally-intensive algo, like neural nets, graphs, etc.) in C, then access that from LiveCode's externals API where you could then get the strongest value from both languages.
In General...
John Ousterhout's seminal paper on the value of scripting languages helps identify the sweet spot for dynamically-compiled languages like LiveCode:
Scripting: Higher Level Programming for the 21st Century
http://citeseerx.ist.psu.edu/viewdoc/do ... 1&type=pdf
While originally written to promote TCL, the arguments he puts forth there apply well to other scripting languages, whether Lua, Python, or LiveCode.
He describes a good scripting language as being a sort of
glue, allowing a developer to tie together highly-optimized functionality compiled from C, but with the productivity benefits inherent in high-level typeless systems. This provides a strong balance for a wide range of applications programming tasks, with the business logic in script driving the heavy lifting done by the underlying engine.
Of course higher-level languages won't be the best solution for every task, but when GUIs are needed LiveCode can often be used well. LiveCode is among the most efficient scripting languages both in terms of developer productivity and runtime performance. Its native scripting language is most commonly used by itself to produce a great many products. When anything that's not already in the box is needed, its externals API allows it to integrate anything else you might need from other languages, so its scope is indeed almost limitless.
I can appreciate the desire for any entrepreneur to avoid tipping his hand too much on the details of a product in development, but as you find other specific questions the folks here will be happy to help. Hopefully you'll find enough interesting in LiveCode that it can play at least a supporting role in your work, and perhaps may even be attractive for the final product itself.
BTW you also in another thread gave me another reason to explain why i have not seen many commercial grade apps - previously being a proprietary language held back revolutions adoption. Makes great sense to me.
When I was a kid proprietary languages were very popular (Director, Toolbook, MS BASIC, others), and even the best tools for working with open languages like C and Pascal were themselves proprietary (Think C, Metrowerks, etc.). Back in those days, what we now call LiveCode was known as MetaCard, and being proprietary didn't hold it back as much as the marketing needed relative to industry giants like Macromedia. Indeed, even as they were promoting Java, at least one Sun office maintained a site license for MetaCard for many years.
But it's a different world now. Developers pretty much require open source for any language to be taken seriously. LiveCode has only been open source about 9 months now, and we're already seeing tremendous benefit from this move in so many ways, from rapidly increasing adoption to code contributions.