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.)


Reply via email to