July 09, 2016
On 2016-07-08 20:46:21 +0000, Walter Bright said:

> On 7/8/2016 6:51 AM, Robert M. Münch wrote:
>> 1. Fixing (all) bugs before doing new things: If I look as a CTO, CIO or CEO on
>> ...
> 
> I have yet to find any engineering product in any field that doesn't have open issues. A more practical question is does the product deliver enough value to make up for its deficiencies.

I totally agree. But often it takes quite some time & experience to understand how the open deficiencies impact my context. I have seen to many tools where you can reach 80% and than things get hard / impossible. IMO a good or bad products is decided on the last 20%...


>> 3. How about a "D Master" online certificate? scrum.org is doing that. You have
>> ...
> 
> It's a great idea, do you want to work on it?

I would love to but it's unrealistic within the next 6 months... sorry.

I brought it up as an idea that can be put on the mid / long term roadmap, to shape the picture of D in the long run. I think these things are important for companies to see / know about before they will make a decision. It's a long, very long journey to establish a language in the "mainstream"...

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

July 09, 2016
On Thursday, 7 July 2016 at 19:55:51 UTC, Andrei Alexandrescu wrote:
> https://wiki.dlang.org/Vision/2016H2 -- Andrei

is it possible to make a modular D language(and a compiler), so one just could release new features of the language without releasing a new version of a compiler(ldc, etc.), and these features would be just extensions of the compilers?
July 10, 2016
On Sat, 09 Jul 2016 19:17:31 +0000, Eugene wrote:

> On Thursday, 7 July 2016 at 19:55:51 UTC, Andrei Alexandrescu wrote:
>> https://wiki.dlang.org/Vision/2016H2 -- Andrei
> 
> is it possible to make a modular D language(and a compiler), so one just could release new features of the language without releasing a new version of a compiler(ldc, etc.), and these features would be just extensions of the compilers?

That would be kind of terrible by default.

What ensures that two different modules are compatible? Nothing, by default. What happens if you try including two incompatible compiler modules in one project? Presumably an error. What if I try to depend on two libraries that have incompatible compiler modules? I can't.

So it's a lot of work and would just fragment the language.
July 10, 2016
On Friday, 8 July 2016 at 18:04:16 UTC, Andrei Alexandrescu wrote:
> It seems to me six months is a sweet spot. Large companies such as Google and Facebook also use a six-months horizon because it's long enough to avoid micromanagement hysteria and short enough to be verifiable and accountable. Yes, I do have a vision for a longer horizon, but it's too vague to be useful - "D will be a major programming language by 2020".

But we are not Facebook or Google. And I bet even they have some mid/long-term visions.

> I consider it competition with other things that Walter and I need to worry about. Walter put it cleverly: you can't add more administration without administrators.

IMO that is wrong, well not so much wrong as misleading. We don't just need more administration because we need more administration. We need more administration or lets say more management and delegation to get things done.

>
> A semestrial vision document summarizing our outlook and intentions is about as much as we can bear. ....

Well, you and Walter graduated from engineering to management. That, reviewing other peoples work and delegating is your job now. Like it or not.

> Would trello help with that kind of stuff?

Yes if anybody had access to the trello and would want to use yet another tool. I think that is unrealistic. But we already have the wiki and github. So extending the VD to rolling VD in the wiki is the way to go IMO. Or move everything to github including bugtracker and start using milestones etc.
Again, IMO in the long run a long term VD, updated on a need to basis with subtasks will save you work.

> I don't think preapproved work would lead to less rejection. Rejection is of work of insufficient quality, not of work that has not been preapproved. Conversely, preapproval does not guarantee any work will be actually approaved.

Considering the current event is disagree. Maybe preapproved work is not the right wording. Maybe preapproved designs.



July 10, 2016
On 2016-07-10 19:09, Robert burner Schadek wrote:

> Yes if anybody had access to the trello and would want to use yet
> another tool. I think that is unrealistic.

Trello is already used: https://trello.com/dlang

-- 
/Jacob Carlborg
July 14, 2016
On Thursday, 7 July 2016 at 19:55:51 UTC, Andrei Alexandrescu wrote:
> https://wiki.dlang.org/Vision/2016H2 -- Andrei

Folks,

One of the main obstacles I see to the adoption of a language is its ecosystem. Perhaps the vision should include a structure of frameworks we would like to see being developed, with a community process similar to what we follow for the language.

vibe.d is already a tremendous asset, but we are lacking the equivalent of DBI, slf4j, JMS, etc.

Does this sound like a good idea, and if so, does anybody want to help put something together like that?

j.
July 20, 2016
On Friday, 8 July 2016 at 18:04:16 UTC, Andrei Alexandrescu wrote:
> "Oops, can't let checkedint happen but I can't criticize without proposing an alternative so forget RCStr and let me work on that"
> ...
> On 07/08/2016 05:17 AM, Robert burner Schadek wrote:
>> People would have a go to place
>> looking for pre-approved work. Leading to no more gatekeeper rejection frustration.
>
> I don't think preapproved work would lead to less rejection. Rejection is of work of insufficient quality, not of work that has not been preapproved. Conversely, preapproval does not guarantee any work will be actually approaved.

My bid for inclusion of `checkedint` in Phobos fizzled because I want to solve a different (though overlapping) set of problems than you do.

No matter how much I iterate and improve my work you still won't be satisfied, because our goals are incompatible and I'm not interested in discarding mine in favor of yours. This is clear from the response you gave when I explained in some detail the reasons for my design:

https://forum.dlang.org/post/njss1a$2ig5$1@digitalmars.com
> Even if it were the case that there's no smaller design that conforms with the requirements, that means requirements have a problem.

You neither gave any *specific* suggestions as to how I could better meet my requirements, not did you state which of my numbered requirements, *specifically* was unreasonable or unnecessary. All of the major suggestions that you did give revolved around adding new requirements (like support for arbitrary bound ranges and user-defined error handling), while somehow shrinking the code base. Something had to give.

Repeatedly dismissing this obvious goals mismatch as "insufficient quality" on my part is abrasive and unhelpful.

Communicating clear requirements for projects ahead of time via pre-approval could help ensure that people who volunteer are actually working on something you want. Obviously I'm not the volunteer you're looking for, but maybe if we'd all known that I wouldn't have taken ownership of the project, and someone else would already have made what you want, instead.
1 2 3 4 5
Next ›   Last »