ketmar via D.gnu, el 27 de September a las 15:11 me escribiste:
> On Sat, 27 Sep 2014 11:47:33 +0000
> "Ledd via D.gnu" <d.gnu@puremagic.com> wrote:
> 
> > I don't think that the gcc team is slow on releasing new releases and patches
> they are much slower than D team.
> 
> > I think that on one hand it's true that D is currently a rapidly-changing language, but this also prevents a gain in popularity, no one wants to adopt a non-standard language that is constantly mutating for production code.
> at least three companies already adopted D: Facebook, Sociomantic and... sorry, i forgot the third. so your "no one" is a slight exaggeration. ;-)

I'm sorry, but at least the Sociomantic example is not a good one to defend your point. We are stuck at D1 because D2 was too unstable. So, yeah, if you want the industry to adopt the language, at least from my personal experience in Sociomantic, you need to provide stability and predictability. The new release procedure has been a huge improvement on this front, and the care it's being taken now in terms of not introducing breaking changes (with low ROI at least, as Don put it in DConf2013), and is why we can start thinking about a migration to D2.

GCC releases more or less every year a new minor version. I think introducing new feature *just* once a year is super acceptable. Then, they do a patchlevel release more or less once every 5 months. That might be a bit slow for DMD, but is not that bad either, specially when the compiler is getting more robust.

> > My assumption is that D needs to freeze at some point .
> ahem... we already have C++. ;-) it's not frozen, but it's legacy turned it to abomination.

And then you have Python, which has an history of providing a super stable language that evolves continuously. You keep pointing to the wrong examples ;-)

> i believe that shipping old D in distributives will harm D more than not shipping at all. people will write new code using obsolete features, fight with already-fixed bugs, and so on. being independent of GCC allow to avoid such problems, 'cause maintainer can build new package when new GDC is out. but if GDC will be the part of GCC, no updates will ship until new GCC is out, 'cause GDC release cycle will be dependent of GCC release cycle.

You got it all wrong. DMD is a compiler implementation and I didn't see anyone here suggesting to tie DMD releases to GCC releases in any way. What they are asking for is having GDC merged in GCC, that's all.

> i once dreamt about GDC as part of GCC, but i changed my mind.

You should keep dreaming :)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
El día que falten los niños, que sobren las mujeres y que se prenda
fuego el último árbol, será el Apocalípsis.
	-- Ricardo Vaporeso. Camino Negro, 1916.

On Sunday, 28 September 2014 at 11:19:21 UTC, ketmar via D.gnu wrote:
> On Sun, 28 Sep 2014 08:44:20 +0000
> "Ledd via D.gnu" <d.gnu@puremagic.com> wrote:
>
>> My point being that for the majority of people, the ones that
>> work on open source projects, large projects, productions for the
>> masses, a stable language and a predictable release cycle, is
>> more valuable then a cutting-edge feature-reach language .
> so they can take a stable language with predictable release cycle and
> so on. C, for example. D must change faster, not slower. i can't see
> why i should lose features which makes D valuable for me to please
> imaginary future adopters.

That's because you are not thinking about the "shipping date" as a feature, you are not even considering it as an option.

You will never get 1 single customer if you say "I can do X for you but I can't determine when I'll ship that" . And any developer interested in D is a customer of yours .

A predictable release cycle it's absolutely not about "losing features" C and C++ in the gcc compiler have all the bells and whistles, they even have the compiler support for technologies way beyond the ISO C or C++ standards .

Also, on average, you get a new release of gcc every 2-3 months, with a new milestone being published in about 11-12 months . I can't think about this as a problem, there are commercial C/C++ compilers that don't have half of the same features that gcc offers .

the first release of D1 is about 13 years old, D2 is about 7 years old, it's probably time to decide whether it will be a rolling-release language as long as it will live or to stabilize/standardize it . I don't think that keeping things as they are will do any good to D .

On Sun, 28 Sep 2014 14:50:25 +0200
"Leandro Lucarella via D.gnu" <d.gnu@puremagic.com> wrote:

> I'm sorry, but at least the Sociomantic example is not a good one to defend your point.
ok, two companies. ;-) it still beats "noone".

> GCC releases more or less every year a new minor version. I think introducing new feature *just* once a year is super acceptable. Then, they do a patchlevel release more or less once every 5 months.
but gcc package maintainers are not so fast. i still see gcc 4.9.0 on some distros, with it's known bug that makes ffmpeg flac decoder unusable, for example. ah, even gcc 4.8, 'cause "it's proven to be stable and we know it's bugs".

> And then you have Python, which has an history of providing a super stable language that evolves continuously.
especially Python3. and i seen real life examples of software that works with python2.5, but not with python2.7.

> You got it all wrong. DMD is a compiler implementation and I didn't see anyone here suggesting to tie DMD releases to GCC releases in any way. What they are asking for is having GDC merged in GCC, that's all.
no, i'm not wrong. i'm talking about GDC, not about DMD. yes, svn version of GDC can get all the freshy fixes and enhancements, but people will use the version that comes with their distro. the old one.

when GDC is not tied to GCC, maintaner can build GDC with new GCC backend, for example, and this will not force to upgrade to new GCC (my GDC is completely independed of my GCC, for example). and GDC maintainer can release packages when new GDC is ready, not when the whole new GCC is ready.

> > i once dreamt about GDC as part of GCC, but i changed my mind.
> You should keep dreaming :)
nonononono. ;-) GDC is my primary D compiler, yet i don't want it to be the part of GCC.

what i really want is GDC which is synced with current DMD, but this is another story. ;-)

On Sun, 28 Sep 2014 16:39:29 +0000
"Ledd via D.gnu" <d.gnu@puremagic.com> wrote:

> That's because you are not thinking about the "shipping date" as a feature, you are not even considering it as an option.
yes, 'cause FOSS projects has no "shipping dates".

> You will never get 1 single customer if you say "I can do X for you but I can't determine when I'll ship that" . And any developer interested in D is a customer of yours .
i'm not trying to sell them D. they either like it or not, but for me the primary goal of D is to satisfy *my* needs. i'm tired of tools that tries to satisfy someone else.

> A predictable release cycle it's absolutely not about "losing features"
i'm talking about long pauses between releases, not about "when it's done". and about desyncing between GCC and DMD release cycles.

> Also, on average, you get a new release of gcc every 2-3 months,
but not a packages in major distros. besides, main GCC languages (C and C++) aren't developing at the fast rate of D. and GCC's Go is old, and GCC's ObjC is old. can't see any good in adding another "always old" language to GCC.

> the first release of D1 is about 13 years old, D2 is about 7 years old, it's probably time to decide whether it will be a rolling-release language as long as it will live or to stabilize/standardize it . I don't think that keeping things as they are will do any good to D .
and i think that D must change alot faster. we still can't remove some annoyances due to "this will break some code". dfix tool was rejected, and users telling that they are ready for code breaking are not heard. damn it, if i want language with such disgusting legacy i can use C++!