On Friday, 8 March 2013 at 21:07:23 UTC, Jakob Ovrum wrote:
On Friday, 8 March 2013 at 20:07:50 UTC, Dicebot wrote:
Opinions/proposals?
I completely agree that the needs of users who want stability
over everything are not being met. There's no way to choose to
get just the updates that don't break code (such as
non-breaking bug fixes), and I think you're right in that there
should be a way to do that.
However, I just want to make clear that there's another
(probably rather big) camp out there: the camp that thinks the
current D platform needs a lot of improvement and are more than
willing to accept breaking improvements.
I want more language features to be implemented and cleaned up.
I want Phobos to be changed, cleaned up, trimmed as well as
expanded. All this regardless of the cost of breaking code. I
don't mind fixing broken code if the replacement code is simply
better.
Thankfully, both the language and standard library are
currently being improved in such ways, but not without a fair
amount of inertia from parts of the community (particularly
from Walter) who want stability at all costs.
For example, I don't think the current std.process is adequate
at all and it would feel like a defeat if we have to name the
new one std.process2 and have it live alongside the old trash
(unless it's temporary). What do you think new users will think
when they see or hear about the story around this? Many other
standard modules are in the same position or are going to be in
the same position at some point in the foreseeable future.
I just hope we can find a way to satisfy both camps, both
ensuring the viability of the language at present by providing
a stable interface, as well as securing the future of the
language by iteratively improving upon it without compromising
at every turn. Having LTS releases might be a good way to do
that.
Personally I think we need to consider D3 as breaking. We can
leave out any major changes till then or at least that would be
nice. That way we can use D2 for LTS once we begin on D3.
How ever this will bring back e.g. the old python 2.x vs 3.x
divide which would be a shame. But at the same time it'll mean we
can do some big stuff that would just not be acceptable in
breaking old projects.
