Ruby Specifications

(Peter Fitzgibbons) #1

In article <20050818193338.C0A2533D5F@beryllium.ruby-lang.org>,

Who needs specs when you can just have exegenesis/apocalypse style
fluffing around? :slight_smile:

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

I don't get it, what's the issue? Ruby as it exists in it's

current

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

Hm... Unless there is a company that is running about 10,000,000 (yes 10
million) lines of ruby, then I doubt that it could spend millions on a
language change like returning [] instead of nil. Um.. Unless they're
updating language version majors without any testing. BTW: Microsoft
releases language version majors with every new Visual Studio. Guess
what? They've "broken" code compatibility all over the place, up and
down the library stack. You can't even convert a project from one
version of VS to another without major pain.

So, I don't think this makes Ruby a "hacker" language. Any hacker can
use ANSI C or C# or PHP or Python or Perl or Ruby and make a mockery of
the language and version updates. A professional programmer and

vendor<< will know that producing a valuable product for his/her

client requires responsibility, building stability into their product,
and following a protective process in upgrading.

I have worked at many companies, each who have been spending anywhere
from $100's to $100,000's on software development, and I'll tell you, to
any one of them, updating a production system without testing more than
once or on purpose would have been immediate dismissal, even from the
most forgiving of them. Backups are a rescue here, but that's no
excuse.

So, all of you making money on Ruby and maybe Rails, you are NOT using a
hacker language (BTW: at its inception, languages like C++ and VB were
"hacker" languages). I don't hear in the group any of you asking how to
dance around the question of Ruby's respect in the development
community.

What do you think?

Peter J. Fitzgibbons
Applications Manager
Lakewood Homes - "The American Dream Builder"(r)
Peter.Fitzgibbons@Lakewoodhomes.net
(847) 884-8800

路路路

Dion Almaer <dion@almaer.com> wrote:

--

Best regards, emailto: scholz at scriptolutions
dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

(Tesla) #2

Peter Fitzgibbons wrote:

In article <20050818193338.C0A2533D5F@beryllium.ruby-lang.org>,

Who needs specs when you can just have exegenesis/apocalypse style fluffing around? :slight_smile:

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

I don't get it, what's the issue? Ruby as it exists in it's

current

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

Hm... Unless there is a company that is running about 10,000,000 (yes 10
million) lines of ruby, then I doubt that it could spend millions on a
language change like returning [] instead of nil. Um.. Unless they're
updating language version majors without any testing. BTW: Microsoft
releases language version majors with every new Visual Studio. Guess
what? They've "broken" code compatibility all over the place, up and
down the library stack. You can't even convert a project from one
version of VS to another without major pain.

So, I don't think this makes Ruby a "hacker" language. Any hacker can
use ANSI C or C# or PHP or Python or Perl or Ruby and make a mockery of
the language and version updates. A professional programmer and

vendor<< will know that producing a valuable product for his/her

client requires responsibility, building stability into their product,
and following a protective process in upgrading.

I have worked at many companies, each who have been spending anywhere
from $100's to $100,000's on software development, and I'll tell you, to
any one of them, updating a production system without testing more than
once or on purpose would have been immediate dismissal, even from the
most forgiving of them. Backups are a rescue here, but that's no
excuse.

So, all of you making money on Ruby and maybe Rails, you are NOT using a
hacker language (BTW: at its inception, languages like C++ and VB were
"hacker" languages). I don't hear in the group any of you asking how to
dance around the question of Ruby's respect in the development
community.

What do you think?

Peter J. Fitzgibbons
Applications Manager
Lakewood Homes - "The American Dream Builder"(r)
Peter.Fitzgibbons@Lakewoodhomes.net
(847) 884-8800

Microsofts breaking of compatibilty is the reason I was looking for something like Ruby. Who wants to do 1.0 1.1 2.0(late and looking later) 3.0 ... ad infinitum. The changes not only sucker punched many companies but also IDE makers like Macromedia who can't upgrade or improve until the final release of a change. PHPs popularity partially lies in the fact that improvements have committed the faux paus of not just breaking a script but stopping it cold with complete paradigm changes.

If Ruby turns into a monster like .NET is then those books I ordered from Amazon are worthless :frowning:

路路路

Dion Almaer <dion@almaer.com> wrote:

--

Tesla - Alternating current, the first modern day opensource project?

(Patrick Gundlach) #3

Hi

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.

Isn't that where (unit) testing comes into play? So that errors like
this will be detected before upgrading? Thats at least how I handle it.

Patrick

(Josh Charles) #4

So, I don't think this makes Ruby a "hacker" language. Any hacker can
use ANSI C or C# or PHP or Python or Perl or Ruby and make a mockery of
the language and version updates. A professional programmer and
>>vendor<< will know that producing a valuable product for his/her
client requires responsibility, building stability into their product,
and following a protective process in upgrading.

in the case of .NET, however, the changes that are going to happen
have been documented ahead of time so that you can plan. The Specs
for C# 2.0 have been around for what, 2 years now? The change to
generics and other things is going to break alot of currently working
.NET code, but that change is still several months in the future,
giving everyone alot of time to prepare.

I think that a well communicated roadmap would be alot better than
specs. Does such a roadmap exist for ruby? I don't know. I'm new
here.

(Tesla) #5

Josh Charles wrote:

So, I don't think this makes Ruby a "hacker" language. Any hacker can
use ANSI C or C# or PHP or Python or Perl or Ruby and make a mockery of
the language and version updates. A professional programmer and

vendor<< will know that producing a valuable product for his/her

client requires responsibility, building stability into their product,
and following a protective process in upgrading.

in the case of .NET, however, the changes that are going to happen
have been documented ahead of time so that you can plan. The Specs
for C# 2.0 have been around for what, 2 years now? The change to
generics and other things is going to break alot of currently working
.NET code, but that change is still several months in the future,
giving everyone alot of time to prepare.

I think that a well communicated roadmap would be alot better than
specs. Does such a roadmap exist for ruby? I don't know. I'm new
here.

Yes a road map is a better way. Mostly because the specifications don't really solve the problem breaking compatiblility. Ruby is a scripting language. At least there is nothing I have found that says different. Scripting languages do not need specifications when they don't have a home. PHP,PERL and others do not have a spec because they are fluid enough to fit in where ever they are at the time. Javascript is an exception because to has to live in a client web browser.

聽聽.NET languages are not scripting any longer, which is probably why I think ASP.NET sucks. They have also jumped on adding javascript as default language to the CLR because of its spec. Visual Basic 6 never really had a finished spec so they are dumping it and vbscript is gone with it.

But there are two ways of handling a specification. The first is to take it and build on it and make sure you have backwards compatibility ie. c and c++. The second is to use it to create something completely different or "better" ie. C# 1.0 and C# 2.0

So if Ruby becomes a scripting language without a home but with a specifiction then I would hope that it is because someone wants to build on it not change it into something different every 2 years.

路路路

--

Tesla - Alternating current, the first modern day opensource project?