Biggest Issue with D - Definition and Versioning

[deadalnix]

Are you reading in my mind ?

Le 19/01/2012 18:13, Heywood Floyd a écrit :
>
>
>> On 1/18/2012 2:15 PM, Adam Wilson wrote:
>>> [...] There are 2719 open issues in the
>>> bugtracker; that number alone will scare off many potential users.
>
> Walter Bright Wrote:
>> Take a look at the changelog. I just don't see how anyone could conclude that is
>> not exactly what we are doing. Here's the current list for the upcoming version
>> of D2:
>>
>>
>> 314 - [module] Static, renamed, and selective imports are always public
>> [...]
>> 7309 - [2.058] Regression caused by new inlining code
>
>
>
> Hello!
>
> I agree the changelog is impressive and a solid proof the D community is hard working.
>
> However, I still subscribe to Adam's view that the D bug situation _is_ a problem, even a scary one:
> http://d.puremagic.com/issues/reports.cgi?product=D&datasets=NEW
>
> That's over an ~8 year time frame. I think it's perfectly clear: D has a chronic monthly bug surplus.
>
> Of course, all software has bugs. The difference is healthy software has a "rhythm", and as far as I can tell, D doesn't. Compare with a text-book example (not exactly comparable, but close enough):
> http://bugs.debian.org/release-critical/
>
> The key here, I believe, is the psychological effects of bundling high-quality stable software with buggy components. Although the curve above doesn't mean all of D is "unstable", as features of course do get stable in time, it does mean the perception of D is bound to be mostly negative. Why? If you buy a car and it has a solid engine, good wheels, wonderful suspension, but the seats are uncomfortable and the radio switches stations randomly, you're not going to think "Ah, this is an overall nice car, because the awesome engine makes up for the bad seats and radio", no, you're going to get annoyed and think "this is a crap car that makes me irritated and hurts my back" and you'll wish you bought another one, even one without a radio. With D2, because it mixes new features and bug fixes into the same branch, there's always something that's the annoying radio.
>
> This is a perfectly good reason to add a lib namespace like "ext.*", "lab.*" or even "beta.*" and add all new libs there with the warning that it's experimental and not for production.
>
> Then again, that's not really a solution. The latest SIMD lib is a perfect example: It seems contained and like it could only do good for D's overall quality. Yet it doesn't take long before someone realizes SIMD could perhaps speedup regexp, then someone wants all float[4] to be optimized automatically, of course std.math must be picked apart and reassembled with SIMD in place sooner or later, then hashing, then crc, utf-8 tricks, who knows? The next tier is that 3rd party libs will start using the half-baked SIMD lib too, because they follow D's sloppy lead. And voil�, we have a bug souffl� spreading to all D code, and the end-user doesn't have a choice. There's no such thing as an isolated feature. Every new feature comes attached with a systemic cost. An alternative way of thinking about SIMD is that, sure, it will speed up some things, it will also add around 300 bugs over the next year to arbitrary parts of D, as a measure of the effort needed to sustain D's curre
nt quality level, with SIMD in place. And that would be ok, _if_ we could handle it, but not if it means an overall bug surplus, and especially not if there already is a surplus that it just adds to. Then D's quality will deteriorate from it.
>
> I think D really needs to start thinking economically about new features and bugs. New features must be picked carefully and strategically with a maintenance budget in mind. This economy needs to be balanced, with the means available here and now, not with some pie-in-the-sky idea that if we only get this feature we'll get 50 new users and then we'll fix all bugs in a month. That behavior will burn already existing users once the prediction fails, as it must, from time to time. New features are costly, over a long period of time, and need to be treated as such. New users typically do not evaluate software on the basis on how good it could get if they fixed all the bugs first.
>
> Then, I get the impression D is acting somewhat out of desperation, understandably. At some level I see a talented and skillful community, with an innovative and beautiful product, waiting for a lucky break. This can be a frustrating situation. There seems to be a belief, subconsciously perhaps, that if D would only have enough "wow" people would finally get impressed enough and start to use it. I think this is a fundamentally flawed belief that leads to a slow death sided by wasted efforts. I think when we all think about it, we chose software, when we can chose, that works well over software that's cool but annoying and frustrating. I mean look at other successful low-budget software projects. Most got their break by doing a particular thing really well, not by being impressive on paper or to an audience at a conference. D needs to stop "wowing" and start focusing on becoming a focused high-quality product, and given the psychology of humans and the things I've mentioned,
 I see no other way of doing that except getting that bug curve back on the ground, and then make an actual stable release. And getting a bug curve down can only mean one thing: Freeze all new features.
>
> Of course, halting development alltogether isn't good. Software projects needs to be actively developed, creativity needs to be kept warm, or it dries up. But this is a universal problem, not something unique to D, and it has already been solved, many times over. The conventional industry-standard way of releasing stable high-quality software, while still being able to work on the next cool version, is to use stable/testing branches. This is no mystery. The question is: Why doesn't D have this? If the answer is that D1 is the stable branch, then the problem is a different one, but equally troublesome: The stable release cycle of D, that is, the time the end-user have to wait for the next batch of stable features, is what, 6 to 9 years? No one will wait around for that long. D needs a new stable release every 1�2 years, especially in the beginning when new features are available in abundance. No one cares about how great D will be when all envisioned features are finally i
n place. People care about what's here and now.
>
> Summary
> D can not liftoff with this monthly bug surplus. The surplus is in one way good, because it shows there's creativity happening, but it needs to be confined in a separate branch, out of the sight of the end-users. The version of D that the end-users see needs to have a bug deficit, asap. Further, D needs to start to think economically about features and bugs, and there probably should be a policy in place that no new stable version is allowed to be released before the current one has fixed 90% of its bugs, or something like that. I think D is long due on putting the two activities of creative development and maintenance on two separate planets, or moons, in this case, I suppose.
>
> Just to be clear, I don't think SIMD should never have happened. Creativity must be allowed and creativity comes when it comes, but it shouldn't be triumphantly dumped in the laps of the end-user every month like a dead mouse the cat brought in. If D was an airline, it would be like you've just boarded the airplane and you're waiting for takeoff, but then the pilot comes on: "Dear passengers, we're just going to make a routine break here. Our engineers have just come up with a new better wing flap and we'll just wait 20 minutes while they install it". Huh? Is this a joke? you'd be thinking. Then you look out the window, and there they are, the engineering team, disassembling part of the wing. I mean it's madness to think the end-user will enjoy using a product while it's in active development, especially when it's such a low-level product as a programming language. It's also madness to think the end-user will wait 7 years for the next stable update. There needs to be a stro
ng separation between development and maintenance, and there needs to be regular timely stable releases with near zero known critical bugs.
>
> Anyway, I think D has great potential and I use it regularly for hobby stuff and like it very much, especially as I'm allergic to C++. (No really.) There's a lot of really good stuff in there.
>
>
> Kind regards
> /HF
>
>
> (PS. ...oh, I forgot to bring up the documentation, oh my, next time perhaps...)
>