On 2 September 2013 23:36, Joseph Rushton Wakeling < joseph.wakeling@webdrake.net> wrote:

> On 02/09/13 14:51, Dicebot wrote:
>
>> But do you seriously expect anyone with no personal business interest to
>> work on
>> brining more of such crap into something that is not broken? You would
>> have had
>> my sympathy but demand "Let's force everyone to use IDE" is just insane.
>> All
>> this thread would have made some sense if some enterprise D entity has
>> existed
>> but it simply does not work that way right now. And, to be honest, I am
>> glad
>> about it.
>>
>
> Personally I find, observing a number of different open source projects, that a very typical problem is a kind of "selection bias" among contributors that leads them to significantly under-appreciate the usability problems of their software.
>
> It goes something like this: anyone who has spent any length of time using that software (which of course includes most contributors) either had a workflow and toolchain that the software matched with, or they have been able to adapt their workflow and toolchain to enable them to use the software.  Usually they have managed to find ways of coping and working around any other usability issues that arise.  And that situation then compounds itself over time because new users come and either adapt in the same way that existing contributors have, or they leave.
>
> So, you wind up with a body of contributors who often have much in common in terms of their setup, their perception of the priorities, and in their ability to handle the software.  And that in turn can be very dangerous, because you get people who simply don't understand (or have any way to experience) problems that are brought to them by new users or by others.
>
> And of course there are always greater problems than usability, so those problems are the ones that get focused on, with the developers all the while bemoaning the lack of manpower and wondering why it is so difficult to attract and hold on to contributors.
>

I think this is a very interesting point.

The only way that I can see to avoid that trap is to have a strong focus on
> usability as part of your development process, to make sure that developers have good connections with a diverse range of potential users and their experiences, and (where possible) for developers to dedicate part of their time to actually trying to undergo that experience themselves.
>
> The TL;DR of what I'm saying here is: while it's certainly crazy to force D contributors to use IDEs, there's a great deal of value in making sure that a good number of contributors regularly get IDE experience, and regularly try out "fresh start" installs of D in IDE and non-IDE environments, because that way you have a sense of how easy or painful it is for new users to get things installed and just get hacking.
>

Thank you.

On Mon, Sep 02, 2013 at 10:11:28AM +0200, Jacob Carlborg wrote:
> On 2013-09-01 19:54, Walter Bright wrote:
> >On 9/1/2013 2:50 AM, deadalnix wrote:
> >>Considering DMD never deallocate anything, expect to restart your IDE every hour or so.
> >
> >DMD deallocates everything when its process ends. This should have zero effect on the IDE. If you need to restart the IDE every hour, it is not because of DMD.
> 
> That was in reply to if DMD was built as a library and included in the IDE. Then there wouldn't be a process to end.
[...]

	module libDmd;
	auto parseDCode(string code) {
		pid_t pid;
		if ((pid=fork())==0) {
			dmdMain(...);
			exit(0);
		} else {
			auto status = waitpid(pid);
			return getReturnValue(...);
		}
		throw Exception("fork error");
	}

Though, granted, this may cause unacceptable performance hits. :-P


T

-- 
The best way to destroy a cause is to defend it poorly.

On Monday, 2 September 2013 at 15:06:40 UTC, H. S. Teoh wrote:
> On Mon, Sep 02, 2013 at 10:11:28AM +0200, Jacob Carlborg wrote:
>> On 2013-09-01 19:54, Walter Bright wrote:
>> >On 9/1/2013 2:50 AM, deadalnix wrote:
>> >>Considering DMD never deallocate anything, expect to restart your
>> >>IDE every hour or so.
>> >
>> >DMD deallocates everything when its process ends. This should have
>> >zero effect on the IDE. If you need to restart the IDE every hour, it
>> >is not because of DMD.
>> 
>> That was in reply to if DMD was built as a library and included in the
>> IDE. Then there wouldn't be a process to end.
> [...]
>
> 	module libDmd;
> 	auto parseDCode(string code) {
> 		pid_t pid;
> 		if ((pid=fork())==0) {
> 			dmdMain(...);
> 			exit(0);
> 		} else {
> 			auto status = waitpid(pid);
> 			return getReturnValue(...);
> 		}
> 		throw Exception("fork error");
> 	}
>
> Though, granted, this may cause unacceptable performance hits. :-P
>
>
> T

dude, libd is conceived in with that in mind, and I'm craving for help. I'm putting quite a lot of effort into it, but D is big, and any help would be welcome.

While there has been a lot of back and forth with Manu in this thread, I think it's best to look at his game jam experience as a kind of stress test for D installation and usage, ie informative but extreme.  Game development, especially in a rush and with everything being installed automatically for the user, is not a use case that is well-plumbed in D right now.  It would be nice if debugging properly worked, but given the complexity involved that Walter mentioned, it's understandable that it doesn't.

Speaking of debuggers, there was a BSD-licensed debugger written in D around 2009, likely D1.  It was abandoned by the author, who told me he got busy with work, but Martin Nowak resurrected it for some time a couple years back:

https://github.com/dawgfoto/ngdb

Perhaps it can be resurrected as a debugger for D, since it is written in D.

On Monday, 2 September 2013 at 07:42:52 UTC, Jacob Carlborg wrote:
> On 2013-09-01 21:44, Brian Schott wrote:
>
>> It's a bit of a chicken-and-egg problem. I'd like to do this, but there
>> would have to be several companies already using D professionally for it
>> to be a viable business model. And for a company to invest in D, they'd
>> probably want the tooling to already exist.
>
> I would like that as well. But I feel the same things. Are there any customers?
It strikes me that commercial support is the correct way to fix a lot of these problems, which are about fit and finish, that many others have noted open source projects are notoriously bad at.  I suggested a licensing model for how D could provide commercial support in a different thread:

http://forum.dlang.org/thread/kq9r7t$nu$1@digitalmars.com#post-sglcqsiphpntcdlhvwvn:40forum.dlang.org

The usual open source zealots argued with me, suggesting that any closed source reference implementation would be unwelcome, even if always accompanied by an open source implementation that's available for free.  I won't get into the even sillier arguments used, ;) perhaps such people wouldn't mind as long it wasn't Walter and dmd, ie the reference implementation, that went closed/paid, ie if Brian or someone else did it.

As for needing "several companies already using D professionally for it to be a viable business model," most companies don't start that way.  You find a few users willing to pay for fit and finish or optimizations and you grow it from part-time work to as far as the business will go.  I certainly hope someone is willing to do that.

On Monday, 2 September 2013 at 17:39:45 UTC, Joakim wrote:
> ...

There is crucial difference between having a company providing commercial services for D users (good) and having anything closed/commercial in reference implementation (bad). Former is simply matching the demand from certain market segment. Latter is screwing the life for everyone else. There is hardly anything common here.

On Monday, 2 September 2013 at 08:30:26 UTC, Mike Parker wrote:
> On 9/2/2013 8:59 AM, Brad Anderson wrote:
>>
>> For a few releases now the D installer for Windows has created a start
>> menu shortcut that launches cmd.exe with dmd et al. added to the PATH.
>> It also adds to the PATH during installation if you let it.
>
> Good news. Does it allow multiple versions of DMD to be installed simultaneously?

The system PATH modification would conflict of course but you could use the start menu shortcuts that set the PATH just fine.

On Monday, 2 September 2013 at 16:16:48 UTC, deadalnix wrote:
> On Monday, 2 September 2013 at 15:06:40 UTC, H. S. Teoh wrote:
>> On Mon, Sep 02, 2013 at 10:11:28AM +0200, Jacob Carlborg wrote:
>>> On 2013-09-01 19:54, Walter Bright wrote:
>>> >On 9/1/2013 2:50 AM, deadalnix wrote:
>>> >>Considering DMD never deallocate anything, expect to restart your
>>> >>IDE every hour or so.
>>> >
>>> >DMD deallocates everything when its process ends. This should have
>>> >zero effect on the IDE. If you need to restart the IDE every hour, it
>>> >is not because of DMD.
>>> 
>>> That was in reply to if DMD was built as a library and included in the
>>> IDE. Then there wouldn't be a process to end.
>> [...]
>>
>> 	module libDmd;
>> 	auto parseDCode(string code) {
>> 		pid_t pid;
>> 		if ((pid=fork())==0) {
>> 			dmdMain(...);
>> 			exit(0);
>> 		} else {
>> 			auto status = waitpid(pid);
>> 			return getReturnValue(...);
>> 		}
>> 		throw Exception("fork error");
>> 	}
>>
>> Though, granted, this may cause unacceptable performance hits. :-P
>>
>>
>> T
>
> dude, libd is conceived in with that in mind, and I'm craving for help. I'm putting quite a lot of effort into it, but D is big, and any help would be welcome.

I've never heard of libd?  Is it the library-fication of SDC?  I assume this is it? https://github.com/deadalnix/libd

On 2013-09-02 19:54, Dicebot wrote:

> There is crucial difference between having a company providing
> commercial services for D users (good) and having anything
> closed/commercial in reference implementation (bad). Former is simply
> matching the demand from certain market segment. Latter is screwing the
> life for everyone else. There is hardly anything common here.

Yes, I agree. I think the tools, or most of the tools, need to be free. Then they need to make money on other things as support, education or similar.

-- 
/Jacob Carlborg

On 2013-09-02 10:30, Mike Parker wrote:

> Good news. Does it allow multiple versions of DMD to be installed
> simultaneously?

DVM already handles this. Although it doesn't handle Windows 64bit.

-- 
/Jacob Carlborg

On Sunday, 1 September 2013 at 19:44:11 UTC, Brian Schott wrote:
> On Sunday, 1 September 2013 at 18:36:39 UTC, SomeDude wrote:
>> I think at this point, what D needs is a bit of commercial support from a company like JetBrains or some equivalent. Maybe there is now an opportunity for founding such a company, one that would specialize in building professional tools around the D language. I believe the language and the compilers are stable enough to grow a serious business around them. If we compare to what the state of C++ compilers was before 2000, I believe we are much better off. And that was just over a decade ago. Who knows what the state of D will be in 5 years ? So yes, there is a case to be made for growing a company around pro D tools, and the first company that does it will grab the whole market.
>
> It's a bit of a chicken-and-egg problem. I'd like to do this, but there would have to be several companies already using D professionally for it to be a viable business model. And for a company to invest in D, they'd probably want the tooling to already exist.

Your concern is legitimate of course, but there has been historically many cases where small companies have created a market in IT. There is clearly a demand for D tooling even if it's not huge right now, so I believe the risk is not as great as you think. Of course one needs some good skills to be able to come up with usable tools. But when nearly every D newcomer's first question is "where are the tools ?", there is a market for that.