August 31, 2007
eao197 wrote:
> Java 1.5 (with generics) and C# 2.0 ware major versions, but didn't
> break old code.
> 
>>
>> An D /does have/ a stable language version, D1.
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=302  -- very strange bag for _stable_ version.
> 
> Try to imagine _stable_ Eiffel with broken DesignByContract support :-/
> 
I have to agree on this. Sometimes, when I write code and run into a feature that's documented, but not implemented yet (GC, I'm looking at you) or supposed to be working, but broken in strange ways, I can't help thinking D isn't nearly 1.0 yet, let alone 2.0.
September 04, 2007
eao197 wrote:
> On Thu, 30 Aug 2007 15:44:25 +0400, 0ffh <spam@frankhirsch.net> wrote:
> 
>> eao197 wrote:
>>> I mean changes in languages which break compatibility with previous code. AFAIK, successful languages always had some periods (usually 2-3 years, sometimes more) when there were no additions to language and new major version didn't break existing code (for example: Java, C#, Ruby, Python, even C++ sometimes).
>>
>> I rather think, that a "new major version" of any language that "doesn't
>> break existing code" could hardly justify it's new major version number.
>> A complete rewrite of the compiler, e.g., would justify a majer new
>> compiler version, but not even a teeny-minor new language version.
> 
> Java 1.5 (with generics) and C# 2.0 ware major versions, but didn't break old code.

Actually, I think new features that make old code obsolete (even if it still compiles and works perfectly) are even more of a problem -- breaking "mental compatibility". I don't think Java and C# have avoided this. It's certainly been a problem for C++ and D.
If you get 500 compile errors you need to fix, that's annoying and tedious. But when your code uses a technique that still works, but isn't supported by recent libraries, you're locked into the past forever.
September 04, 2007
On Tue, 04 Sep 2007 12:34:14 +0400, Don Clugston <dac@nospam.com.au> wrote:

> If you get 500 compile errors you need to fix, that's annoying and tedious.

If you get 500 compile errors in old 10KLOC project its annoying.
If you would get 500 compile errors in each of tens of legacy projects that is much more that simply 'annoying and tedious'.

> But when your code uses a technique that still works, but isn't supported by recent libraries, you're locked into the past forever.

There is a good example in C++ world: the ACE library. It has been started a long time ago, it has been ported to various systems, it outlived many changes in the language and suffered from different compilers. Because of that ACE use C++ almost as "C++ with classes", even without usage of exceptions. In comparision with modern C++ (over)designed libraries (like Crypto++ or parts of Boost) ACE is an ugly old monster. But it has no real competitors in C++ and it allow me to write complex software more easyly than if I try to write part of ACE on modern C++ myself. So I don't think that old ACE library look me in the past (even if I can't use STL and exceptions with ACE).

IMHO, the real power of any language is its code base -- all projects which have been developed using the language. And any actions which descriminate legacy code lead to decreasing the language's power.

-- 
Regards,
Yauheni Akhotnikau
September 07, 2007
eao197 wrote:

> On Thu, 30 Aug 2007 15:44:25 +0400, 0ffh <spam@frankhirsch.net> wrote:
> 
>> eao197 wrote:
>>> I mean changes in languages which break compatibility with previous code. AFAIK, successful languages always had some periods (usually 2-3 years, sometimes more) when there were no additions to language and new major version didn't break existing code (for example: Java, C#, Ruby, Python, even C++ sometimes).
>>
>> I rather think, that a "new major version" of any language that "doesn't break existing code" could hardly justify it's new major version number. A complete rewrite of the compiler, e.g., would justify a majer new compiler version, but not even a teeny-minor new language version.
> 
> Java 1.5 (with generics) and C# 2.0 ware major versions, but didn't break
> old code.

Oh, btw, Java 1.5 did break old code. I used to use Gentoo during the transition phase so I had some experience compiling stuff. :) There were at least a couple of commonly used libraries and programs that broke. One minor problem was the new 'enum' keyword. Of course at least Sun Java compiler allows compiling in 1.4 mode too. I think Gentoo has a common practice nowadays to compile each Java program using the oldest compatible compiler profile for best compatibility. IIRC there were also some incompatible ABI changes because of the generics.
September 07, 2007
eao197 wrote:
> On Thu, 30 Aug 2007 15:44:25 +0400, 0ffh <spam@frankhirsch.net> wrote:
>> I rather think, that a "new major version" of any language that "doesn't
>> break existing code" could hardly justify it's new major version number.
>> A complete rewrite of the compiler, e.g., would justify a majer new
>> compiler version, but not even a teeny-minor new language version.
> Java 1.5 (with generics) and C# 2.0 ware major versions, but didn't break old code.

Well, yeah, maybe (apart from what Jari-Matti said about Java 1.5 breaking
code). But anyways, adding something to a language without breaking old
code does only work so often. C++ tried to add to C without breaking code
(it still does, but it tried) and you can see what came from it.
New language features tend to need new syntax. If you want to remain
compatible, you'll have to find a way to introduce that new syntax without
breaking the old ones. This is usually quite hard to achieve without
making the new syntax either cumbersome or fragile and hard to grok.

Regards, Frank
1 2 3 4
Next ›   Last »