Lothar Scholz wrote:

>Hello Phil,
>
>PT> In article <20050818193338.C0A2533D5F / beryllium.ruby-lang.org>,
>PT> Dion Almaer <dion / almaer.com> 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 -