Open Language and stability

[Mark Waddingham]

On 2015-10-25 12:06, Graham Samuel wrote:
> The discussion about Open Language is interesting, and the idea may
> well be a good thing. But I for one would rather hear that for the
> actual development team, delivering a rock-solid version of LiveCode
> on all supported platforms is taking a massive priority over even
> thinking about this stuff. Peter Brett, can you reassure me, as a
> member of the use list?

Obviously delivering a rock-solid version of LiveCode on all supported 
platforms is the most important thing. It is something I have been 
working on ensuring ever since I joined the company in 2004.

We have done many significant things over the years to help reach this 
goal - starting off in 2004 with auditing the bug database (as it was 
then) and putting the engine source code under version control.

In more recent times, we have:
    - Implemented an out-of-tree test system which is run on all new 
releases.
    - Implemented unit testing frameworks at all levels (C++, LiveCode 
Builder, LiveCode Script)
    - Started requiring tests to be added to PRs (at least for things 
which tests can currently be written for).
    - Refined our internal process for handling and managing bugs and 
issues.
    - Refined our internal process for ensuring patches to the engine are 
at the required standard.
    - Considerably raised the expected standard of code which can be 
accepted as a patch for both internal engineers and external 
contributors.
    - Instituted the requirements for code review on every single patch 
which goes in (which is a requirement - via integration with our build 
system - for a PR to be progressed).
    - Implemented an automated build system which produces LiveCode 
distributions for all platforms.
    - Implemented integration of the build system with GitHub, enabling 
easy communication of build failures.
    - Implemented continuous integration of all Pull Requests, ensuring 
that one will not be merged if it does not build on all platforms.
    - Working towards running the unit test stack on each PR as part of 
continuous integration.

One of the goals of the 7.0 refactor was to move a very old, 
undocumented, difficult to maintain and spaghetti-like code forward to a 
new model which is cleaner, easier to maintain and more amenable to use 
in the ways we need it to be to move the platform forward (indeed, it 
has been a 'happy' side-effect that in doing this process the actual 
semantics of what things are meant to do has become a great deal clearer 
- the code itself in many cases is now almost documentation in and of 
itself - assuming you can 'read the runes' in that regard). Of course, 
this process alone has been quite long and difficult - but well worth 
the effort in terms of what it will enable moving forward.

However, please understand, that we would be entirely remiss if we spent 
no time at all thinking about how the LiveCode technology needs to 
evolve and change as we move into the future. A lot of what we have 
planned has taken a long time to work out how to do, even before we've 
actually started to do it. Indeed, future direction *hugely* impacts the 
choices you make in the present.

The pace at which computers and software technology evolves is 
breath-taking, so unless you want to be relegated to the warehouse of 
great ideas which never quite got there (as so many 4GLs have), you find 
yourself in an eternal juggling act between ensuring you definitely have 
a future, and ensuring that you have a present...

Needless to say, this is not an easy task, but certainly one which 
brings with it a wealth of interesting problems.

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps