dunbarx wrote:
Most typical bashing and complaining smacks of frustration, as if a miracle was expected but failed to deliver; these are lost souls that either did not spend enough time to reach a "eureka" moment, or just aren't built that way.
Not a miracle exactly, but it is true that expectations were raised high, and were not met. A few examples of things which I did not like - and your mileage may vary:
* Unhelpful error messages, no true strict compilation mode. There doesn't appear to be a method to detect calls to undefined methods, or incorrect calls, at compile time. Therefore, QA would need to execute a white box test where every code path has been traversed with all possible options - just in order to find what would be a compiler error in other languages. Not an acceptable basis for a quality product. (Edit) Just remembered the best term for what is missing is
early binding(/Edit)
* Mediocre debugger. Very annoying, especially since debugging a scripted application can be more powerful, flexible, faster and richer, compared to debugging a traditionally compiled language. Features missing include conditional breakpoints, 'run to cursor,' 'set next statement,' etc.
* Runtime system unstable without apparent reason. I forget the exact sequence, but I observed effects like this: create a button and assigning an icon to it depends on the exact sequence of seemingly unrelated property assignments. Once I had it working (through trial and error, even after consultation with this forum), I added code that did nothing but get the imageData and put it straight back in again, and the button was grey again. This forum alone has many similar reports. It is true that I got it working in the end (and dare not touch it now), but the effects observed are clear evidence for the fact that something just isn't right in the engine.
* Bloated language. I like the simple beginnings of
put x into y, but quickly the language became bloated. Almost every common word of the English language is a reserved keyword, and the grammar is not context sensitive. As a result, all my variables have to be called
myValue or
theColour or
currentPosition, and gone is the natural language-like beauty. More so when you enter the realm of abstract things like XML: We're back with the ugly names common to all other development environments.
* Limited runtime kit. Common UI controls such as spin buttons, pane splitters or tree views appear absent (but I didn't research this thoroughly). Support for creating re-usable custom controls is practically non-existent. XML-support is a joke. DTD? Are you kidding me? No built-in Schema validator, no support for XPath queries - This is no XML support fit for life in the 21st century.
* revlets may work on a subset of the officially supported browser and platform combinations, with wind behind. Those that work also often crash, without a way to debug this. RR received crash reports but found them not enlightening. Some popular browsers and platforms not supported: No Linux, no Chrome, etc. iOS and Android native support is present, but those can't access a revlet-enriched web page. Who in their right mind would create a web based application with those limitations?
* Other aspects of professional development not supported / weakly supported / with unknown support levels. Those aspects include versioning, obfuscation or encryption of intellectual property
I thank you for reading this extract from my personal list of things which I don't like about LiveCode. For me, LiveCode is a nice play thing and an interesting experiment, but nothing more. I can only encourage all LiveCode enthusiasts to an open-minded review of the current state-of-the-art tools: Microsofts .NET platform, Adobe's AIR, Embarcadero's (formerly Borland's) tools. All of these play in a very different league indeed.