Hi Mark, I greatly appreciate your response to this topic.
> 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. It’s good to hear that you folks are willing to provide a migration tool / method for bringing older code up to date. > Indeed, we have tried and do continue to try our very best not to break > people's code as the platform evolves… I’m also glad to hear that the team is mindful of this issue, and weighs those concerns heavily. I understand that computer hardware/software is evolving at a faster rate than ever, such that other companies' changes significantly impact the LiveCode product, such that some past code of the LiveCode codebase simply won’t be able to function anymore in the future. These are mitigating circumstances that are unfortunately beyond our control. This impact however should be minimized for users of LiveCode as much as possible by the team. LiveCode has to retain a solid bedrock of code for it to remain a viable platform for it’s users to accomplish their work. A computer language that evolves too fast without taking that into consideration can become abandoned by it’s users, simply because too many changes make it too difficult for users to keep up with it. That is why “Standards Committees” were brought into existence for the more formal languages. We don’t want “Open Language” for LiveCode to suddenly evolve the language from “English Like” into “Greek Geek Speak” that only a few people can understand or work with. If LiveCode somehow evolved into something looking more like C++, Objective C, or something worse, users would start looking elsewhere for some other more “English Like” computer language. I realize I’m probably preaching to the choir here. I’m glad to hear that your team is certainly much more concerned about code changes than the company that totally screwed me, and many other users. Thanks again for your responses, and clarifications. Rick > On Oct 26, 2015, at 11:27 AM, Mark Waddingham <m...@livecode.com> wrote: > > 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 ~ m...@livecode.com ~ http://www.livecode.com/ > LiveCode: Everyone can create apps > > > _______________________________________________ > 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 _______________________________________________ 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
