On Mon, May 14, 2007 at 02:36:10PM +0200, Thomas Wittek wrote: > Andy Armstrong schrieb: > >On 14 May 2007, at 12:31, Thomas Wittek wrote: > >>How did C, C#, Java, Ruby, Python, Lua, JavaScript, Visual Basic, etc. > >>know? > >>They didn't. > >>If there is a new release, you always have to check if your code still > >>runs. > > > >I think that may be the point I'm making. > > Your point is that you don't have one? > Do you believe, that new keywords are the only cause of breaking > backwards compatibility? I don't think so. > So you rely on testing your code anyway. Sigils won't save you from that.
Back in the 90's I was with a company that had a 20K line perl program. We would provide a copy of perl as part of the program suite, so that we could control which version was being used for our software and when it was upgraded while still allowing the customer to have their own version of perl that they could upgrade on their own schedule. Before any perl upgrade was built into our suite, we would of course test it extensivily to ensure that all of the code was still compatible. Until the perl4->perl5 change, there was never any problem - Larry is a wizard at adding totally new concepts and features in a way that just "happens" to include all of the old usage bits as a special case that falls magically out of the new, enhanced, more coherent whole. But there is no way that this would have been possible without the distinction between named operators and variables provided by sigils. Removing the sigil on a function call (it used to always be written &sub(args...)) did, I think, lead to the difficulty in perl5 where it became difficult to add new keyword operators to the language - because they could conflict with subroutine names in existing code. Needless to say, that level of dependable upgradability without requiring code rewrites was considered to e a huge benefit of using perl for our company. (For the record, we delayed converting from perl4 to perl5 for many years, woried about the possibility of subtle problems arising from the massive changes that had been made to the language. When I finally tried it out, there were only a few changes that really affected us. I had the code converted in about two weeks, although we then ran it in parallel with the old code for about two months before accepting that nothing tricky had snuck in.) --
