What is "Open Language"?

[Mark Waddingham]

On 2015-10-26 15:51, Rick Harrison wrote:
> Whenever one deprecates code, it destroys someone’s code somewhere.
> Don’t do it.

Indeed, we have tried and do continue to try our very best not to break 
people's code as the platform evolves (even though this is a huge 
constraint to put on a programming environment which evolved from 
something born in the late 1980's - it makes the assumption that all 
decisions taken then and up until were correct then and correct relative 
to any future consequence and thus have no forward consequences - which 
is definitely not the case).

However, I'm not going to commit us to never deprecating things - we do 
and will continue to do so as needed. Deprecated features will continue 
to work for as long as it is feasible to do so.

> A work around is to let all previous versions work, and put the final 
> winning
> candidate into the dictionary, the others will no longer appear in the
> documentation.  This solves the problem with the least disruption as it
> doesn’t break anyone’s code, but helps to streamline the desired future
> syntax for the language.

The problem here is that you are assuming it is possible for 'all 
previous versions to work' from now until some arbitrary point in the 
future. This just isn't the case - code ages and computer technology 
continual renews.

For example, the 'liveResizing' property no longer does anything. Why? 
Because Cocoa has no facility to turn liveResizing off.

Similarly, things like the 'pixmapId' properties and such used to allow 
you to do really funky things on certain platforms which it was not 
possible to continue to make work when we brought the graphics 
capabilities up to scratch with other environments in 2.7. (Fortunately, 
long before these 'funky things' stopped working we provided a much 
better way to have the same effect - i.e. export/import snapshot from 
object).

In terms of syntax / synonym related suggestions - then the situation is 
much easier. We might deprecate some, just to make it clear what the 
'preferred' form is and to discourage further usage. We would never 
remove them until such a point that we do have a suitable migration tool 
/ method of expressing them which means people can choose to use them, 
or not, depending on their own personal preference.

In terms of current functionality (from a semantics point of view) there 
are a growing list of 'anomalies' in the bug database which are things 
which really aren't 'correct' at the moment (and never have been). It 
would be better for all new code and new users if they were not ladened 
with the baggage of those things being how they currently are. However, 
again, we aren't going to change that functionality until we can 
implement a compatibility mechanism meaning you don't have to update old 
code.

I suspect the environment you have been bitten by in the past was one 
which was hugely monolithic in terms of implementation. They probably 
redid the internals with little regard for backwards compatibility 
(because it wasn't a viable business avenue for them to be concerned 
about it - or they simply did not know how to) to reduce the engineering 
burden and to breath new life into it in the modern era (and thus 
continue to be viable).

The difference in LiveCode's case is that whilst the entire refactoring 
project, widgets and (eventually) Open Language is about turning 
something monolithic and hugely constrained into something modular and 
open, we are trying to do it in such a way that will ensure existing 
code will continue to run.

Warmest Regards,

Mark.

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