[#7055] More on VC++ 2005 — Austin Ziegler <halostatue@...>

Okay. I've got Ruby compiling. I'm attempting to get everything in

17 messages 2006/01/05
[#7058] Re: More on VC++ 2005 — nobuyoshi nakada <nobuyoshi.nakada@...> 2006/01/06

Hi,

[#7084] mathn: ugly warnings — hadmut@... (Hadmut Danisch)

Hi,

22 messages 2006/01/10
[#7097] Re: mathn: ugly warnings — Daniel Berger <Daniel.Berger@...> 2006/01/10

Hadmut Danisch wrote:

[#7098] Design contracts and refactoring (was Re: mathn: ugly warnings) — mathew <meta@...> 2006/01/10

Daniel Berger wrote:

[#7118] Re: Design contracts and refactoring (was Re: mathn: ugly warnings) — mathew <meta@...> 2006/01/12

*Dean Wampler *<deanwampler gmail.com> writes:

[#7226] Fwd: Re: Question about massive API changes — "Sean E. Russell" <ser@...>

Hello,

23 messages 2006/01/28
[#7228] Re: Question about massive API changes — Caleb Tennis <caleb@...> 2006/01/28

>

Re: Question about massive API changes

From: Wilson Bilkovich <wilsonb@...>
Date: 2006-01-29 03:31:19 UTC
List: ruby-core #7239
On 1/28/06, Sean E. Russell <ser@germane-software.com> wrote:
> On Saturday 28 January 2006 17:13, Wilson Bilkovich wrote:
> > significantly.  I can't readily think of a language that had a
> > "compatibility or else" restriction when doing a major revision that
> > turned out to make people happy.
> > Java 1.0 -> 1.5, C -> C++, Perl -> Perl 6, etc, etc.
>
> Java 1.0 -> 1.5 didn't break anything.  Java 1.0 code is legal 1.5 code.

That's what I'm saying.  The majority of C code compiles perfectly
with a typical C++ compiler, and Javac 1.5 can compile 1.0 code.  In
my opinion, the decision to allow that greatly hindered what could be
done in each of those designs.  C++ isn't as clean as it could have
been due to C compatibility, and Java definitely is cluttered now.

Someone else compared the decision to use Ruby 2.0 to the decision to
switch languages.  I think that's great, because it means Ruby could
(deliberately, carefully) shed any clutter it has acquired during the
march through version 1.  I'd hate to see my favorite language grow
old and brittle.

> I understand what you're saying.  It is the easiest, most efficient solution
> for developers, but it is a major pain for people using the library.  And
> I'll get the hate mail. :-)

I feel your pain, since I'm involved with the maintenance of a
10-million LOC COBOL application. People "love" it when you change the
way something works.  :)
Whatever you decide will turn out well, I'm sure.
I'd just like to cast my vote for agility and change, rather than stasis.

--Wilson.


In This Thread