dunbarx wrote:
> Several threads on the forum have bemoaned what is labeled an
> overarching bug issue in LC.
...
> I am really only concerned that LC not get a reputation for being
> unstable.
Most of us share that concern. To assess the issue soberly compels us
to examine the nature and sources of reputation.
Reputation is only partly a reflection of actual technical fitness. The
rest is a mix of factors that lie far outside of computer science, into
the realms of psychology, sociology, and political science.
This thread is a good example: What might have seemed at first like a
bug in LC turned out to be a limitation inherent in the nature of PDF
itself.
On the forums we see a another, with surprising frequency: when the
behavior of a script is not understood, the poster will sometimes
surmise that the cause is somehow file format corruption. Many cases
turn out to be just syntax errors, and IIRC few or none of those have
turned out to be file format corruption.
We see a similar pattern with the documentation: many posts point to a
need for additional information being added to the docs, with
recommendations for learning basics linking to any of a wide range of
resources spread out across the web, but on further examination we find
that the fairly comprehensive 655-page User Guide included with the
install hadn't yet been consulted at all.
None of this is to suggest that LiveCode is the world's first
million-line code base that's completely bug-free.
But neither is it a roach motel when we consider the scope and
complexity of the system with common metrics like bugs/kloc.
In the vast gulf between needlessly contentious allegations of
"apologists" at one extreme and "Henny Pennys" on the other is a middle
ground where meaningful product improvement can actually happen:
- Let questions be questions: When an unexpected outcome is observed,
we can keep an open mind about possible causes until the issue is
diagnosed. If we keep telling new users in advance that every
unexpected outcome is a bug in LC they'll eventually believe it, even in
the many cases where that isn't true.
- Let learning happen right in the box: We are blessed with a great many
contributions from community members all across the web. But to be
clear, many of these predate the expanded documentation effort the team
undertook several versions ago. Moreover, those written after LC
adopted an open source workflow missed the opportunity for greater
readership, keeping them in a relatively small corner of the
possibly-discoverable web rather than submitting them to the core docs
every user is directed to right in the Help menu. The docs are good,
and can always be made even better. We can help. Of course we want to
see as much LC info everywhere, but core basics might just as well be in
the box, and we do a good service to the learner to let them know when
they already are.
- Let pre-release builds realize their value: use them, whenever
practical. Putting off trying a new version until after Stable is the
one choice that guarantees any issues affecting your specific work won't
be fixed in that version. We know from our own experiences and decades
of industry literature that the earlier in the process bugs are
identified, the less impact they have, and thus the total systemic cost
to address them is much lower.
These are just suggestions, and certainly not any attempt at
establishing any sort of "rules". I have no authority to require anyone
to do anything, nor would I even try, as I understand that from time to
time there can be good reason to ignore each of these, and any other
common practices observable in healthy software communities.
But most of us have been around the block enough times to recognize the
value of such ordinary practices. And all of us want LC to improve -
both in terms of actual product quality, and its *perceived* quality,
its reputation.
LiveCode is moving its way up the TIOBE Index of programming language
popularity, slowly but steadily. For all the reasons Geoff Moore
outlined in Crossing the Chasm and many more, expanding LC's audience
benefits all of us: more tools, more libraries, more eyeballs, more hands.
There isn't a single language on the TIOBE Index that's bug-free, and
yes, that includes LiveCode.
We the community have at least as much power and influence over LiveCode
adoption as anything the core team can do, by virtue of our numbers and
reach. With any programming tool, the number of end-users who
ultimately benefit is orders of magnitude larger than the number of
developers using it.
Let's produce great work, and build upon those practices proven across
the industry to expand both real and perceived quality.
Along those lines, I'll extend an offer here:
> For my part, I only notice that LC 9x crashes intermittently, though
> regularly. I must add that I am working mainly on a single project
> when this happens, and am conditioned to save often. The other
> projects I have currently do not exhibit this at all, though that
> may be simply due to the fact that I am involved in them much less
> intensely.
> I suppose it is less worrisome that this is a problem in only a
> single project, than if it happened here and there, everywhere.
Crashers are of course serious, but the good news is that you're only
seeing it in one project. Feel free to email me directly if you're in a
position to allow me to review the errant code, and I'll see what we can
do to both find a workaround to keep your progress moving along well,
and submit a report for the underlying cause once we find it.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
