On 03/10/2012 12:09 AM, Nick Sabalausky wrote:
> "Nick Sabalausky"<a@a.a>  wrote in message
> news:jje2cg$27tg$1@digitalmars.com...
>> "Walter Bright"<newshound2@digitalmars.com>  wrote in message
>> news:jje0er$24mb$1@digitalmars.com...
>>> This statement is from Linus Torvalds about breaking binary
>>> compatibility:
>>>
>>> https://lkml.org/lkml/2012/3/8/495
>>>
>>> While I don't think we need to worry so much at the moment about breaking
>>> binary compatibility with new D releases, we do have a big problem with
>>> breaking source code compatibility.
>>>
>>> This is why we need to have a VERY high bar for breaking changes.
>>
>> Freezing things against breaking changes is all fine and good, but NOT
>> before they're reached a point where they're good enough to be frozen.
>> Premature freezing is how you create cruft and other such shit. Let's not
>> go jumping any guns here.
>>

+1.

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

+1.

On Friday, March 09, 2012 15:14:39 H. S. Teoh wrote:
> On Fri, Mar 09, 2012 at 11:46:24PM +0100, Alex Rønne Petersen wrote:
> > On 09-03-2012 23:32, Walter Bright wrote:
> > >This statement is from Linus Torvalds about breaking binary compatibility:
> > >
> > >https://lkml.org/lkml/2012/3/8/495
> > >
> > >While I don't think we need to worry so much at the moment about breaking binary compatibility with new D releases, we do have a big problem with breaking source code compatibility.
> > >
> > >This is why we need to have a VERY high bar for breaking changes.
> > 
> > If we want to start being able to avoid breaking changes, we *really* need to finally deprecate the stuff that's been slated for deprecation for ages...
> 
> [...]
> 
> Does that include std.stdio and std.stream? When are we expecting std.io to be ready?
> 
> IMHO, this is one major change that needs to happen sooner rather than later. The current lack of interoperability between std.stdio and std.stream is a big detraction from Phobos' overall quality.

Note that he didn't say that we should _never_ make breaking changes but rather that we need to have a very high bar for making such changes. In particular, it's stuff like renaming functions without changing functionality that he's against.

If a module really needs a rewrite, then it'll get a rewrite, but we also need to do our best to avoid the need. And in the long run, it will hopefully be incredibly rare that we'll consider replacing modules. But there _are_ a few modules which are going to be replaced or rewritten. It's just that those are the modules that really need it and therefore meet the high bar required to make such changes.

- Jonathan M Davis

On Fri, 09 Mar 2012 18:14:39 -0500, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:

> On Fri, Mar 09, 2012 at 11:46:24PM +0100, Alex Rønne Petersen wrote:
>> On 09-03-2012 23:32, Walter Bright wrote:
>> >This statement is from Linus Torvalds about breaking binary  
>> compatibility:
>> >
>> >https://lkml.org/lkml/2012/3/8/495
>> >
>> >While I don't think we need to worry so much at the moment about
>> >breaking binary compatibility with new D releases, we do have a big
>> >problem with breaking source code compatibility.
>> >
>> >This is why we need to have a VERY high bar for breaking changes.
>>
>> If we want to start being able to avoid breaking changes, we
>> *really* need to finally deprecate the stuff that's been slated for
>> deprecation for ages...
> [...]
>
> Does that include std.stdio and std.stream? When are we expecting std.io
> to be ready?

Sadly, I have no guarantees for when it will be ready.  The rewrite is mostly in place, what I'm struggling with is how to make it backwards compatible with std.stdio.  Specifically, I think I need to rewrite std.typecons.RefCounted to be more flexible.

> IMHO, this is one major change that needs to happen sooner rather than
> later. The current lack of interoperability between std.stdio and
> std.stream is a big detraction from Phobos' overall quality.

I agree, as I watch other modules which would benefit from the rewrite get more attention, I cringe hoping that it doesn't introduce something that would necessitate a complete rewrite with the new system (thereby making my case for rewriting std.stdio weaker).

It's my number 1 priority for D.  The problem is that D is not my number 1 priority right now :(

If you want to take a look so far (I haven't compiled in a long time since starting the migration to backwards compatibility):

https://github.com/schveiguy/phobos/blob/new-io2/std/io.d

I also have a trello card for it...

-Steve

Linus would probably hate D just as much as he hates C++. :p

On Friday, 9 March 2012 at 22:32:59 UTC, Walter Bright wrote:
> This is why we need to have a VERY high bar for breaking changes.

Please remember this if someone proposes enforcing
@property by default.

The -property switch is a big mistake that breaks a
lot of code.

On Friday, 9 March 2012 at 22:32:59 UTC, Walter Bright wrote:
> This is why we need to have a VERY high bar for breaking changes.

Oh, and how do you intend to accomplish that with things like bug 314 still being open (and code relying on the buggy behavior), and not even the language being finalized (think: shared)?

David

On Sat, Mar 10, 2012 at 01:02:35AM +0100, Andrej Mitrovic wrote:
> Linus would probably hate D just as much as he hates C++. :p

Yeah... I can just imagine his eye scanning the description of D and stopping right at the word "GC", and immediately writing a flaming vitriolic post to LKML about how a GC is the absolutely worst thing one could possibly conceive of putting inside a kernel, and that any kernel developer caught flirting with the idea of using D ought to have all kernel patches ignored from that point on.

:-)


T

-- 
Amateurs built the Ark; professionals built the Titanic.

On Saturday, March 10, 2012 01:12:34 Adam D. Ruppe wrote:
> On Friday, 9 March 2012 at 22:32:59 UTC, Walter Bright wrote:
> > This is why we need to have a VERY high bar for breaking changes.
> 
> Please remember this if someone proposes enforcing @property by default.
> 
> The -property switch is a big mistake that breaks a
> lot of code.

As I understand it, it's like override, it's being phased in, and it _will_ become the normal behavior.

There are also a number of things in the language that are supposed to be deprecated but have been sitting around for ages without actually being deprecated (e.g. delete).

Walter's sentiments may be good, but there are a number of things which are still in a transitional phase and _will_ end up breaking code. Of course, I'd argue that stuff like deprecating/removing delete and fully enabling override and @property _do_ pass the very high bar.

I think that his biggest complaint is minor changes (such as changing function names) rather than the large changes that are still being made.

- Jonathan M Davis

On Friday, March 09, 2012 16:15:13 H. S. Teoh wrote:
> On Sat, Mar 10, 2012 at 01:02:35AM +0100, Andrej Mitrovic wrote:
> > Linus would probably hate D just as much as he hates C++. :p
> 
> Yeah... I can just imagine his eye scanning the description of D and stopping right at the word "GC", and immediately writing a flaming vitriolic post to LKML about how a GC is the absolutely worst thing one could possibly conceive of putting inside a kernel, and that any kernel developer caught flirting with the idea of using D ought to have all kernel patches ignored from that point on.

He hates function overloading! I question that he'd ever be happy with anything other than C. And he's so specialized in what he works on that I think that a number of his opinions are completely inapplicable to the majority of programmers. Some of what he says is very valuable, but he's a very opinionated person whose opinions often don't line up with the rest of the programming world. If you'll notice, Walter sometimes has similar issues simply due to the kind of stuff he works on (e.g. thinking that the fact that you could run your program in a debugger to see a segfault was enough (rather than getting some sort of stacktrace with a segfault), which works great for compilers, but works horribly for programs that run for weeks at a time). We all have our biases based on what we've worked on. Linus just so happens to be very famous and _very_ specialized in the type of stuff that he works on.

- Jonathan M Davis

On Fri, 09 Mar 2012 19:12:34 -0500, Adam D. Ruppe <destructionator@gmail.com> wrote:

> On Friday, 9 March 2012 at 22:32:59 UTC, Walter Bright wrote:
>> This is why we need to have a VERY high bar for breaking changes.
>
> Please remember this if someone proposes enforcing
> @property by default.

Clears the bar with room to spare IMO.

Not to mention it's not just a proposal, but in print in TDPL .

(dons flame war proof suit)

-STeve