View mode: basic / threaded / horizontal-split · Log in · Help
March 10, 2012
Re: Breaking backwards compatiblity
On 3/9/12 8:40 PM, Adam D. Ruppe wrote:
> (For example, take dmd out of the box on CentOS. Won't
> work.)

Why? I have CentOS at work and it seems to work.

Andrei
March 10, 2012
Re: Breaking backwards compatiblity
On 3/9/12 8:46 PM, Adam D. Ruppe wrote:
> We might have a stable language, but if the library doesn't
> do the same, we'll never be Windows.

I hear ya.

Andrei
March 10, 2012
Re: Breaking backwards compatiblity
On Saturday, 10 March 2012 at 05:15:32 UTC, Andrei Alexandrescu 
wrote:
> Why? I have CentOS at work and it seems to work.

My work server is CentOS 5.6 (32 bit), maybe it is this specific
version, but the fresh dmd always gives:

1) a libc version mismatch. I fix this by recompiling from source.

2) a linker error on warn-mismatch or something like that not
   being a valid option. Editing dmd.conf takes care of this one.
March 10, 2012
Re: Breaking backwards compatiblity
On 3/9/2012 8:40 PM, Adam D. Ruppe wrote:
> On Windows though, even if you relied on bugs twenty
> years ago, they bend over backward to keep your app
> functioning. It is really an amazing feat they've
> accomplished, both from technical and business
> perspectives, in doing this while still moving
> forward.

I agree that Windows does a better job of it than Linux. MS really does pour 
enormous effort into backwards compatibility. You could legitimately call it 
heroic - and it has paid off for MS.
March 10, 2012
Re: Breaking backwards compatiblity
On 3/9/2012 9:14 PM, Andrei Alexandrescu wrote:
> On 3/9/12 8:35 PM, Walter Bright wrote:
>> On 3/9/2012 3:14 PM, bearophile wrote:
>>> D will naturally progressively slow down the rhythm of its new breaking
>>> changes, but even very old languages introduce some breaking changes (see
>>> some of the changes in C++11),
>>
>> What breaking changes are there in C++11, other than dumping export?
>
> Deprecating exception specifications :o).

I don't think that broke any existing code, because there wasn't any :-)

Consider that I and some others agitated for dumping trigraphs. A couple of 
people voiciferously claimed that their entire code base depended on it, so it 
stayed in.

Never mind that that codebase could be easily accommodated by writing a 
literally trivial filter.

But now, to support raw string literals, C++11 has mucked up trigraphs. It's no 
longer possible to deprecate them without writing a filter that is pretty much a 
full blown C++ compiler itself.
March 10, 2012
Re: Breaking backwards compatiblity
On Friday, March 09, 2012 21:54:28 Walter Bright wrote:
> > Deprecating exception specifications :o).
> 
> I don't think that broke any existing code, because there wasn't any :-)

Sadly, there's code that will break because of that where _I_ work. For a 
while, they were recommended/required, because some of the people dictating 
coding standards didn't understand them properly. Fortunately, much of the 
newer code doesn't use them, but there's still plenty that does. I think that 
it stems primarily from Java programmers expecting them to work as checked 
exceptions and not realizing how they really work. The only thing that will 
likely stop code from breaking where I work due to the deprecation of 
exception specifications is the fact that it'll be years before we use C++11, 
and it'll probably only be newer projects that get compiled that way when it 
_does_ finally happen.

- Jonathan M Davis
March 10, 2012
Re: Breaking backwards compatiblity
"Walter Bright" <newshound2@digitalmars.com> wrote in message 
news:jjelk7$7fm$1@digitalmars.com...
> On 3/9/2012 3:09 PM, Nick Sabalausky wrote:
>> Keep in mind, too, that Linux has decades of legacy and millions of 
>> users.
>> That's a *very* different situation from Phobos. Apples and oranges.
>
> Linux has had a habit of not breaking existing code from decades ago. I 
> think that is one reason why it has millions of users.
>
> Remember, every time you break existing code you reset your user base back 
> to zero.
>
> I'm *still* regularly annoyed by the writefln => writeln change in D1 to 
> D2, and I agreed to that change. Grrrr.

Are you kidding me? I'm *thrilled* with how much of an improvement writeln 
is *every time I use it*.

Seriously how the hell did writeln ever hurst *anyone*? We're bitching about 
trivialities here.
March 10, 2012
Re: Breaking backwards compatiblity
"Adam D. Ruppe" <destructionator@gmail.com> wrote in message 
news:wirsowklisbhbkbujewr@forum.dlang.org...
> On Saturday, 10 March 2012 at 04:40:11 UTC, Adam D. Ruppe wrote:
>> Yeah, the kernel is decent about it, but the rest of the
>> system sure as hell isn't.
>
> Let me tie this into D. A couple weeks ago, I revived one of
> my work D projects - about 30,000 lines of code - that was
> dormant for about a year.
>
> The language worked fine. The library was a bit more of
> a pain.
>
> std.date's deprecation still makes me mad.
>
> And the move of std.string.replace over to std.array meant
> not one of the modules compiled without a change.
>
> (Really easy change: "import std.string : replace;" why
> that works and  "import std.string;" doesn't I'm not sure.
> I'm probably relying on a bug here!)
>
>
>
> But still, the D language manages to move forward without
> much breakage. dmd pretty much gets better each release.
>
>
> Phobos has some breakage though. Not really bad; updating
> this code went quickly. I think I spent half an hour on it.
> But, there was some minor changes needed.
>
>
>
> We might have a stable language, but if the library doesn't
> do the same, we'll never be Windows.

If we start freezing things now, we're going to be Windows 9x.
March 10, 2012
Re: Breaking backwards compatiblity
"Walter Bright" <newshound2@digitalmars.com> wrote in message 
news:jjeqak$f3i$1@digitalmars.com...
> On 3/9/2012 9:14 PM, Andrei Alexandrescu wrote:
>> On 3/9/12 8:35 PM, Walter Bright wrote:
>>> On 3/9/2012 3:14 PM, bearophile wrote:
>>>> D will naturally progressively slow down the rhythm of its new breaking
>>>> changes, but even very old languages introduce some breaking changes 
>>>> (see
>>>> some of the changes in C++11),
>>>
>>> What breaking changes are there in C++11, other than dumping export?
>>
>> Deprecating exception specifications :o).
>
> I don't think that broke any existing code, because there wasn't any :-)
>
> Consider that I and some others agitated for dumping trigraphs. A couple 
> of people voiciferously claimed that their entire code base depended on 
> it, so it stayed in.
>
> Never mind that that codebase could be easily accommodated by writing a 
> literally trivial filter.
>
> But now, to support raw string literals, C++11 has mucked up trigraphs. 
> It's no longer possible to deprecate them without writing a filter that is 
> pretty much a full blown C++ compiler itself.

So making improvements that involve trivially-handled breaking changes is 
good for C++ but bad for D?
March 10, 2012
Re: Breaking backwards compatiblity
On Sat, Mar 10, 2012 at 01:44:59AM -0500, Nick Sabalausky wrote:
> "Adam D. Ruppe" <destructionator@gmail.com> wrote in message 
> news:wirsowklisbhbkbujewr@forum.dlang.org...
[...]
> > We might have a stable language, but if the library doesn't do the
> > same, we'll never be Windows.

Really? D is a stable language as of this moment? Interesting.


> If we start freezing things now, we're going to be Windows 9x.

You mean Windows 3.1.


T

-- 
Without outlines, life would be pointless.
1 2 3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home