From: Tesla Date: 2005-08-19T21:48:56+09:00 Subject: Re: Ruby Specifications Lothar Scholz wrote: >Hello Phil, > >PT> In article <20050818193338.C0A2533D5F@beryllium.ruby-lang.org>, >PT> Dion Almaer wrote: > > >>>Who needs specs when you can just have exegenesis/apocalypse style fluffing >>>around? :) >>> >>>A spec would be good from a "business" sense. I know of a few large >>>companies that are worried about "betting on one Japanese fellow". >>> >>> > > >PT> I don't get it, what's the issue? Ruby as it exists in it's current form >PT> is usable - How would a language spec make them feel any better? I could > >I think a language needs a formal specification. > >If you have mission critical applications it's a little bit hard to >take this "C is the specification" argument. > >I posted into the past that i really don't like it that matz break >compatibility in minor release changes. Suddenly returning a "[]" instead >of "nil" might be a small change but it can cost millions of dollars if it >happens in a critical environment. > >If we had a specification for this it might restrict matz to make >changes like this, just because it feels better. This works for a >hacker language but i know that many companies got afraid when hearing >about this. > > > > I think this is one of the reasons that PHP is controlled mostly by Zend and the reason for Zend being. There was a great deal of compatiblity issues surrounding the upgrading of php4 to OOP. The result was PHP5 and the transistion to php5 from php4 is gradual and not mandatory (although I think php4 is at the end of its cycle) for companies that have major investments in PHP. So if Matz is thinking of making some heavy changings that are outside of a spec then it would be cause for a branch of Ruby rather than a teardown and the problems that come with it. This is the one major problem I have with the Drupal CMS project. Point version changes are major swings from the previous ones and cause a tidelwave of work every 6 months. This means that companies will continue to go with "enterprise" ready solutions like Typo3 and ezPublish where the dev cycle is on point versions but major changes without backwards compatiblity are very few. My own selfish wish is that the Ruby dev mailing list be in english so I can see what the core developers are working on. -- Tesla -