Le 19/01/2012 11:11, Walter Bright a écrit :
> On 1/19/2012 2:06 AM, Patrick Stewart wrote:
>> Long story short - I find new things added and premature optimizations
>> The
>> worst enemy of language at the moment. They might look like selling
>> point to
>> you, to me they look like distractions from fixing D's shaking legs and
>> solving some real problems underneath.
>
> Take a look at the D changelog.
>
> https://github.com/D-Programming-Language/d-programming-language.org/blob/master/changelog.dd
>
>
> I just don't see how it can be argued that we aren't doing exactly what
> you suggest we do.

I know that a lot of bugs are fixed. This is a thing, and this is good.

But another point is that a lot f bugs exists. This point is much more revelant. It may sound harsh but the only thing that matter is the result. As computer scientist we all should know that. And the result for know is a bugguy compiler. No matter how much bugs are fixed in each release, what is important is how many bugs remains and how severe they are.

And let's face it, if you start to use some advanced feature of D, you trigger bugs really easily. Workaround exists for most of them, but what is the point of advanced feature if they always explode on your face ? And what is the point of D if its features cannot be used safely ?

I would be happy to help, but frankly, I have no clue how dmd works. I'm pretty sure many people are like me in D community. Maybe a good thing may be produce some documentation about dmd internal, to reduce the entry ticket to dmd internals.

On 1/19/2012 12:27 PM, Andrei Alexandrescu wrote:
> On 1/19/12 1:30 PM, Brad Roberts wrote:
>> Another interesting tool is github's impact grph:
>>    https://github.com/D-Programming-Language/dmd/graphs/impact
> 
> I was never able to interpret that saliently.
> 
> Andrei

>From below the graph:
Blocks represent "impact". Impact is (lines added + lines deleted) for all non-merge commits during a week period.

So, for a given day, it's showing the people who's contributed changes for that day.  For each person, their contributions through time are linked into one flow.  You can click on any day+person block and it will highlight that flow across time to make it easier to follow.

Or at least, that's how I read it.  It's more cute than super useful, but it does give a quick visual description of who's contributing.

Le 18/01/2012 21:41, Walter Bright a écrit :
> On 1/18/2012 12:10 PM, deadalnix wrote:
>> Usually, a newcomer isn't even sure if the bug comes from his/her code
>> or from
>> the compiler. How can you expect them to fill a bug about the spec ???
>
> That's what these forums are for - to ask.

Seriously, that isn't a solution at all. Just imagine yourself as a newcomer.

You have this idea of program, and think this is a good opportunity to start using a language that seems promising : D.

You write some code and they face an error. As you are new to the language, unless you are crazy, you'll asume that the mistake comes from you and not from the compiler (this is an usual experience in other languages : I almost never encounter compiler bugs).

So you begin to dig more and more in every documentation you can find and try several alternatives. You also search on the web for article about a similar problem and face a desert. After 1, 2 or 3 hours you decide to post on this newgroup. At this point, your program as made no significant progress.

After several hours again (probaly one or two days later in fact) you discover in the newgroups that you faced a compiler/phobos bug and that you have to use a dirty hack or another way to do your stuff. At this point, you program has made no progress, and worse, you know you have to recode a part of it.

Repeat the process 2 or 3 times. Give up and go back to java, C#, python or whatever.

We need a more reliable technology for the compiler and the standard lib. I would say that even if it require to break some existing code (like to solve the toString issue and make it const compilant). This have to be annonced in advance, but shouldn't stop us. The code base will only grow (and if it stop to grow, we can consider the language as actually dead). So the earlier we fix thoses, the better.

Let me explain an exprience of mine. I was studying std.concurrency when I figured out that it can be greatly improved (using something close to a disruptor for message passing). I wanted to propose a patch for that, but I figured out that shared was actually broken and that the compiler is unable to ensure what is specified in the doc. This is a deal breaker for disruptor. So no disruptor in std.concurency, poorer performance and still problems with shared.

It's time to secure the basics. Ensure a good experience for newcomers. thoses people will be embassador of D tomorow.

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

On 1/19/2012 11:30 AM, Brad Roberts wrote:
> Focusing on dmd for this email, phobos and druntime are essentially not dependent on Walter in any way:

There is also a fair amount of low hanging fruit in bugzilla. For example, there are patches that can be turned into pull requests, and some one liners.

On 19 January 2012 18:10, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org
> wrote:

> On 1/19/12 3:25 AM, Manu wrote:
>
>> On 16 January 2012 02:23, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org <mailto:SeeWebsiteForEmail@**erdani.org<SeeWebsiteForEmail@erdani.org>
>> >>
>> wrote:
>>
>>    I do have ties with the gaming community; I taught a course at ENDI
>>    and I am well acquainted with a few game developers. Also, at
>>    conferences and events gaming programmers are represented. Finally,
>>    game developers who are reading TDPL are likely to send me book
>>    feedback and questions in proportion to their representation. From
>>    where I stand, I can say there is more interest in D in other
>>    communities than in gaming.
>>
>>
>> I'd just like to add one more point, that gamedev is, in general, windows-centric. And D's support for windows is basically disgraceful.
>>
> [snip]
>
>> You probably /won't/ hear from the gamedevs either until they are able to do anything more than dismiss it within 5 minutes.
>>
>
> This notion is akin to my "if we considered gamers a core market, we would have done a lot of things differently".
>

But with this in mind, do you think it's possible that your perceived
'interested users' statistics may be slightly skewed. What IS your core
market?
It stands to perfect reason that, while the linux toolchain is the only one
that works properly, the majority of users you will come in contact with
will be researchers and students through universities, and the occasional
linux/language geek, who is generally interested from a research point of
view too.

What commercial industries are using/interested in using D?

I really feel that the state of the tools excludes a potentially huge industry from being interested, but it sounds like that was intentional, ie. not identified as a core market, and therefore the windows tools were never made a priority?

On 19 January 2012 22:52, deadalnix <deadalnix@gmail.com> wrote:

> You write some code and they face an error. As you are new to the language, unless you are crazy, you'll asume that the mistake comes from you and not from the compiler (this is an usual experience in other languages : I almost never encounter compiler bugs).
>
> So you begin to dig more and more in every documentation you can find and try several alternatives. You also search on the web for article about a similar problem and face a desert. After 1, 2 or 3 hours you decide to post on this newgroup. At this point, your program as made no significant progress.
>
> After several hours again (probaly one or two days later in fact) you discover in the newgroups that you faced a compiler/phobos bug and that you have to use a dirty hack or another way to do your stuff. At this point, you program has made no progress, and worse, you know you have to recode a part of it.
>
> Repeat the process 2 or 3 times. Give up and go back to java, C#, python or whatever.
>
> We need a more reliable technology for the compiler and the standard lib. I would say that even if it require to break some existing code (like to solve the toString issue and make it const compilant). This have to be annonced in advance, but shouldn't stop us. The code base will only grow (and if it stop to grow, we can consider the language as actually dead). So the earlier we fix thoses, the better.
>

As a new comer, I really felt this. I intended to write a program in 1
evening, it was about 100 lines. It took me over a week, thanks to the
reasons you listed and more.
I don't know why I didn't give up (probably because of how much I hate
C++), but the experience for a new comer is not good.

With regard to breaking changes, I know people are radically against it,
but I wonder, how many major/commercial programs are there written in D?
How many people are financially invested?
How many are small or hobby programs by contrast? and... as an early
adapter to D, do you accept that you might have to make some minor
modifications to your existing program due to a spec change?
If I had an active project, and I had more experience with D (such that I
wasn't a frustrated newcomer), I would not mind mending my code due to
breaking changes one little bit where it was clear that the fix was for
good reason.

I personally think getting the experience right, for new comers, and in general, far outweighs asking some experienced people with mature projects to make some small changes occasionally. I am quite sad that a lot of the broken things in there now are un-fixable.

Manu:

> I am quite sad that a lot of the
> broken things in there now are un-fixable.

If you want to write a short list of such broken things... :-)

Bye,
bearophile

On 20 January 2012 14:47, bearophile <bearophileHUGS@lycos.com> wrote:

> Manu:
>
> > I am quite sad that a lot of the
> > broken things in there now are un-fixable.
>
> If you want to write a short list of such broken things... :-)
>
> Bye,
> bearophile
>

Renaming receiveOnly() to receive() is a trivial example. I have
encountered others which I can't recall off the top of my head of a
similarly trivial nature that would really enhance the intuitive
application of libraries.
I wonder if libraries become 'std' too soon? They should go through some
incubation process for a year or something, or some minimum number of
successful usages within real applications before they become 'std'...?

virtual-by-default is my single biggest gripe in the entire language, which has perfectly workable, I'd argue better&more well defined solutions, but would be a breaking change, and will never be considered. (No, I'm not trying to open this topic again)

Le 20/01/2012 13:47, bearophile a écrit :
> Manu:
>
>> I am quite sad that a lot of the
>> broken things in there now are un-fixable.
>
> If you want to write a short list of such broken things... :-)
>
> Bye,
> bearophile

toString to begin with. This isn't const compliant.

Just like a big part of the standard lib.

.sort on array is broken.

I have a recent piece of code implementing a radix sort, it has 3 or 4 workaround compiler bugs (that are in the buglist).

Interfacing with C in 64bits can silently screw up your memory when you manipulate struct.

shared isn't working as specified, making writing lock free concurent code almost impossible in practice (it is not like even smartphone have multi core processor nowadays . . .).

And so on . . .

And this is a 2 minutes answer. I can list more and more without thinking too much. All of them are known issue, filled in the bugtracker or discussed on github.