On 1/18/12 6:46 PM, bearophile wrote:
> Andrei Alexandrescu:
>
>> 5. There's no sense of the "length of the pipeline", i.e. how long
>> it takes until a given bug is triaged.
>
> Instead of fixing the N most old bugs every DMD release, I suggest to
> fix the N (N = 2 or 3 seems enough) most Bugzilla-voted bugs every
> DMD release :-)  (If this happens, then probably people will start
> voting more often and better).


False choice. It's not "instead of".

Andrei

On Wed, 18 Jan 2012 15:13:19 -0800, Walter Bright <newshound2@digitalmars.com> wrote:

> On 1/18/2012 2:15 PM, Adam Wilson wrote:
>> I would argue that what would have the most effect is a concerted effort to
>> stabilize the compiler. That means normalizing the differences between DMD/DRT,
>> the Spec, and TDPL. That means taking a break from anything new (regardless of
>> how badly we want them ... *COFF*COFF*), doing a thorough audit of the open
>> issues and prioritizing compiler issues first. Then dedicated a release or three
>> to doing nothing but fixing those issues. There are 2719 open issues in the
>> bugtracker; that number alone will scare off many potential users. And the
>> number of ICE's is much higher than it really should be to call DMD stable. In
>> open-source terms, DMD is beta. I'm leaving out Phobos here specifically because
>> it doesn't interact with the compiler nearly as much as the runtime does.
>
> 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:
>

[snip]

I am not trying to devalue the work that you guys have done, it is frankly impressive. But D feels like it lacks any real direction, certain things get fixed while other languish. Bugs are fixed seemingly at random. To some people is says "to disorganized to work with" (no reasonable expectation my issue won't get forgotten in the hustle) to others it says "to many brush fires for the team to handle" (more critical issues than are acceptable, which means any blocking issues I may have will naturally fall down the list). I am not saying these are necessarily true, but D has a perception problem, and this perception is a large part of it.

I think what we are all trying to say that we need to know *when* things are going to get done ... and "sometime in the future" doesn't cut it. Then have those things actually GET done about when they were promised. People wouldn't feel like they had to get their issues addressed RIGHT NOW, if they had a reasonable expectation of when they will be addressed.

When large teams evaluate a language they care not only about what it can and can't do today, but also when it will be able to do what it was promised to do. As a project manager, I can work around the fact that something might not be working now, but will later, as long as I know roughly when it will start working. I'm not saying that we need a hard date, a window of a couple of months would be FANTASTICALLY useful in terms of planning a project, and I am sure that anyone else who has run a project would agree.

-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Wed, 18 Jan 2012 16:41:28 -0800
"Adam Wilson" <flyboynw@gmail.com> wrote:

> Harsh as it sounds I'd ignore them, what they are really asking for is for you to stop working on everything else and work on their feature. Doing that is planning to fail.

Right. Workers are out at the construction site and although they are capable to build big scycrapers, there is need to provide basic facilities for them in order they can start doing useful work.

Then when they prove that it's possible to build something useful, more investments can be made to extend the scope.

At the moment, D is to risky to invest in it for commercial agents, so open-source projects seems to be nice fit.

For a long time, GHC was practically the only serious project done (not 100% in Haskell (later Darcs appeared on the scene), what we have to show as written in D2?

As mentioned in another thread, D with its features for paralleism, FP-stuff etc. *could be* very  attractive as general programming language suitable for those imperative programmers which cannot easily grok monads and wants to take advantage of their multi-core CPUs idling at the moment.

So, as Adam wrote, let's provide rounded feature set which works so that, at least, (open-source) projects can write D2 code today, possibly without too much sacrifice. :-)


Sincerely,
Gour


-- 
A person who has given up all desires for sense gratification, who lives free from desires, who has given up all sense of proprietorship and is devoid of false ego — he alone can attain real peace.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

On 2012-01-19 01:29, Walter Bright wrote:
> On 1/18/2012 4:03 PM, Patrick Stewart wrote:
>> I am sorry to see many D community projects and libraries dead as they
>> are
>> targeted for D1 and not portable to D2, or just locked to specific
>> version of
>> D and not transferable to latest version due some bug.
>
> I am sorry about Tango apps being incompatible. I cannot do anything
> about that.

Tango for D2 is available: https://github.com/SiegeLord/Tango-D2
I ported one of projects from D1 Tango to D2 Tango with little effort.

-- 
/Jacob Carlborg

On 1/18/2012 11:38 PM, Jacob Carlborg wrote:
> On 2012-01-19 01:29, Walter Bright wrote:
>> On 1/18/2012 4:03 PM, Patrick Stewart wrote:
>>> I am sorry to see many D community projects and libraries dead as they
>>> are
>>> targeted for D1 and not portable to D2, or just locked to specific
>>> version of
>>> D and not transferable to latest version due some bug.
>>
>> I am sorry about Tango apps being incompatible. I cannot do anything
>> about that.
>
> Tango for D2 is available: https://github.com/SiegeLord/Tango-D2
> I ported one of projects from D1 Tango to D2 Tango with little effort.
>

Great!

On 15 January 2012 19:42, Kiith-Sa <42@theanswer.com> wrote:

> I'm interested in game development using D, so I'll post my opinion.
>
> I think the discussions here show how particularly specialized people
> here are. I've seen some Manu's posts and it was clear that he is a person
> in gamedev who thinks most development is like gamedev and can't see the
> bigger
> picture.


I just want to clarify, I don't think this is a fair call, but I can see
why you might think that.
I am obviously a professional gamedev, and I am interested in D. I'm just
trying to illustrate my case that, for me to consider D for
professional/commercial use, there are some (rather small really) features
that I need to do my job.
I can see the bigger picture, but I'm not a representative of any other
part of it. I can only present, with confidence, important points that are
important to my industry.
I expect other people from other industries to make sure their perspectives
are heard and assure they're covered.
I'm certainly not trying to turn D into a gamedev language, I'm just trying
to encourage proper implementation of some key missing features that
support being used in the gamedev environment (and for performance oriented
systems programming in general actually).

I think my single point that started this whole thing off was something to the tune of: "As a high end company, we could not possibly choose D for a high end title until this feature existed"
>From then on, it was just discussing details, and backing up my claim.


> For a gamedev person, SIMD support is not simply a cool feature, it's
> a gamechanger. Just like const, ranges, D threading features and so on.
> However,
> his posts often show that he doesn't understand positions of other people
> in other
> areas, e.g. people here working on scientific computing, who are also
> interested
> in SIMD but their thinking of terms such as "vector" is completely
> different.
>

I don't actually see how it really affects other users, except with library
maturity, they'll see faster libraries too.
Non-SIMD/conventional vectors are already well defined in D. Science will
need to deal with arbitrary sized vectors, and arbitrary sized matrices.
This is a fundamentally different topic than raw access to the hardware
instructions (something like 50% of the CPUs silicone (excluding
cache) that sit there dormant in any D program to date).
A nice library for use in scientific computing should exist for that
audience (if it doesn't already), and I'm sure it too can implement some
nice efficiency gains by using the low level API I have been proposing
under the hood.

What most people don't seem to understand is that the SIMD API I've been pushing for in D will NOT be used directly by almost anyone. It's too low level for general use. It exposes the hardware facilities for optimisation in the most efficient way possible to facilitate *library development*. This can be games oriented, physics oriented, scientifically oriented, anything. It's all about the libraries :)

I think you're making the same mistake here - you have very little (or no?)
> idea about gamedev and aren't exposed to game programmers, so you just
> assume
> specific gamedev issues don't exist or are unimportant. I don't think you
> get
> much of exposure to game devs when evangelizing D either - you don't
> evangelize
> D in game companies.
>

I support this point. We discuss D fairly regularly at work. Most people don't have the time or interest to involve themselves in the NG or IRC. I just like making a noise, and it's nice to see progress in a direction that supports us.

I realise you're actually arguing on my side of the fence in general, but I just wanted to clear those points up :)

On 16 January 2012 02:23, Andrei Alexandrescu <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.
I know numerous gamedevs who have grabbed it, tried it out, and immediately
dismissed it on account of immaturity.
I didn't find D on my own, I only EVENTUALLY looked into it because it kept
coming up in the office (ignored it for years actually).
What I *found* is a GCC toolchain (thank god, or... iain), and a reference
(windows) compiler that only supports x86, and no ability to link
against/with VisualStudio.
VisualStudio integration is still very raw, not supported by the community,
and I can imagine that had I looked a few months earlier and VisualD wasn't
there/usable, I wouldn't have humoured the language for more than 5 minutes
either myself, no matter its merits as a cool language.

You probably *won't* hear from the gamedevs either until they are able to
do anything more than dismiss it within 5 minutes.
VisualD and COFF, and to a slightly lesser extent x64, for me, are the
biggest tickets (bigger than SIMD, I don't need that until I'm working on
something)
As soon as those exist, I may consider introducing colleagues at work to
the language in some smaller tools/projects.

Funny aside: All I originally wanted from the SIMD threads was to be
assured it was on the map, and an acceptable design proposal
existed. Forunately for me, Walter was interested in implementing SIMD
himself, I had no part in that, and it appeared almost instantly! :) .. All
my early posts were LISTS of things that I felt were missing before I
confidently invest time in the language. It was certainly outside of my
control which of those things excited the most people, and started
conversations on the topic.

Clearly gamedev-specific issues do exist and are important. But that's not
> even remotely the point. Allow me to explain.
>
> Say we identified gaming programmers as an important community to address. If that happened, we would have done a /lot/ of things differently, and a ton of them before SIMD. That means focus on Windows64, graphic accelerators, and gaming CPUs. To claim that work on SIMD is good because it's good for gamers is to reverse engineer a rationalization after the fact. And the fact is - Walter has had the gusto to implement SIMD now. Technically, that's great. For gamers, that's an interesting development. Organizationally, that's a poor statement.
>
> Again: if D is a hobby we have, all's great. Otherwise, we must show people that we are serious about finishing the core language implementation, that we make promises that we are able to keep, and that we make plans that we follow even in the broadest strokes. If we want to play with the big boys, we need to change the way we approach planning and organization quite drastically.


I generally agree actually. For myself (and perhaps on behalf of my industry), Win64, COFF, and assurance that some VisualStudio integration team is getting proper support is far more important/should receive priority.

You lead me to an interesting though though...
I have been realising one thing that is concerning me more and more though,
and that is that for some reason, it always comes back to Walter. This
seems absurd.
Why should any feature be contingent on Walters time/excitement for the
feature? He should be allowed to work on the SIMD if he wants, and it
shouldn't significantly affect anyone. Is he being paid? (I don't actually
know)
I was initially under the impression that D was an open source language,
and there were a significant number of contributors... if Walter were hit
by a bus, what would happen to D?

This point is highlighted by your anger/frustration that Walter worked on the SIMD stuff out of step. If you're the second(?) most authoritive voice around here, what does that say about the state of the language development and the team responsible?

Walter Bright Wrote:

> On 1/18/2012 4:03 PM, Patrick Stewart wrote:
> > I am sorry to see many D community projects and libraries dead as they are targeted for D1 and not portable to D2, or just locked to specific version of D and not transferable to latest version due some bug.
> 
> I am sorry about Tango apps being incompatible. I cannot do anything about that.

Not only Tango, there is lot of work that staled and was abandoned or is frozen due to technical difficulties with core (compilers, lang. specs, manuals, whole bundle). It is significant number of man hours gone down the drain.

> 
> 
> > I think it is possible for community to make all necessary libraries and tools once the D is "carved in stone". I suppose D1 is attempt to do that, but not having ready substitute yet (D2 not working as advertised) and D1's clock ticking away, it is risky gamble to say at least.
> 
> What issue with D2 is blocking you?
> 

It is not what issue is blocking me, there are enough issues to block more than one user of D. In my opinion, that is not a way to direct development - by listening to loudest complainer. And community not complaining is not proof everything is going in right direction.

> 
> > To put it plain and simple, I have strong feeling D development is motivated by desire to add latest ideas and features and not by desire to produce practical and stable tool.
> 
> People often write postings, where in the very same posting, they'll write that they absolutely must have new feature X now, and that no new features should be added.
> 
> How would you resolve this?

First to say about myself is that my programming style is aimed at simplicity and maintainability. Feature set I find in D1 is 90% sufficient to solve problems my work places in front of me. Those 10% D1 lacks I solve with more lines of code, and I find it preferable and better solution than to switch to D2.

Direction I imagine could solve current state is frozing D2 specs. Declare that job is done. Announce that on site and NG. Take a week or month to think about what is done. Let all the users do that. After that month, put on list of only those rare cases and minor changes that could be added in matter of days as last chance before language is locked for significant time to come.

Then inspect it critically. Give it care and attention. Fix all bugs. Write new docs. Sync website with that docs. Give assurance language core is there to stay as it is. Assure community their work is appreciated and all they make in D will work with future compilers and not be in vain.

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.

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.

Walter Bright Wrote:

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

Changelog is not replacement for published plans and direction, same as NG is not replacement for documentation.

Time will tell.