On Thursday, 3 October 2019 at 11:29:35 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 3 October 2019 at 10:49:47 UTC, LocoDelPueblo wrote:
>> The strategy of "Y is a better X" is to make people moving from X to Y. So far in D successes are not movers, it's new projects, corporate or not.
>
> That is an interesting metric. There is at least one larger project moving from Pascal to D, based on what has been stated in public. Although, I guess, most native languages could have been used as the target if you transition from Pascal.

Yes indeed, I think that this comment is related to Bastian V.
Still not accomplished move I think. Also I didn't deny that it can work "to some extant".

On Thursday, 3 October 2019 at 11:32:13 UTC, LocoDelPueblo wrote:
> On Thursday, 3 October 2019 at 11:29:35 UTC, Ola Fosheim Grøstad wrote:
>> On Thursday, 3 October 2019 at 10:49:47 UTC, LocoDelPueblo wrote:
>>> The strategy of "Y is a better X" is to make people moving from X to Y. So far in D successes are not movers, it's new projects, corporate or not.
>>
>> That is an interesting metric. There is at least one larger project moving from Pascal to D, based on what has been stated in public. Although, I guess, most native languages could have been used as the target if you transition from Pascal.
>
> Yes indeed, I think that this comment is related to Bastian V.
> Still not accomplished move I think. Also I didn't deny that it can work "to some extant".

and the move is not from cpp to D BTW ;)

On Thursday, 3 October 2019 at 11:14:41 UTC, Chris wrote:
> In Python and Java for example I can download stuff I need, install dependencies (pip and gradle/maven) and that's usually it.

Yeah,  I think that is the primarily driving force behind Java and Python,  that and platform support.  Once you've learned the ins and outs of Python you cannot put it aside because of the swiss-army-knife aspect of it.

Basically all platforms support Python in one way or another, even embedded, it has taken the generic high-level position that C has on the low level.

On Thursday, 3 October 2019 at 08:20:55 UTC, Chris wrote:
> Python is often used for prototyping too, and then the real app is written in C++. This begs the question, is D becoming a native Python?

I don't know about that, but I think Python works both ways. Some use Python for application-scripting or application-plugins, others use Python for the main program and use C/C++ for "plugins". So there is a lot of flexibility in using Python for prototyping that few other platforms provide.

For instance, if you design a vector-drawing-app, you might start by looking for Python libs then set it up with a simple interface then replace each component. Few other languages let you start from that level of "patching things together" (except outdated languages like Perl, Common Lisp or *choke* Visual Basic).

Prototyping in Nim or D doesn't sound very attractive to me. They probably should aim for production.

At this point TypeScript/node.js/electron/angular would probably be a more likely candidate for prototyping.

On Thursday, 3 October 2019 at 11:14:41 UTC, Chris wrote:
> One reason (among many) why even
> great projects in D are ignored is D's atrocious ecosystem.

The rhetorical value of hyperbolic language like this is that it's so
rare in these forums. Everyone's just so peppy and ra-ra about D all
the time that it's very startling to see any dissent.

> In
> Python and Java for example I can download stuff I need,
> install dependencies (pip and gradle/maven) and that's usually
> it.

Hi. I don't know what you're talking about, because I've done
exactly this with dub, but I have some guesses.

Option #1: Python and Java are super popular, so anything you happen
to need will probably be downloadable and immediately usable. "People
don't use D because people don't use D."

Potential technical answer to option #1: use D. By this measure
you'll contribute to people using D, and by an increment solve
the problem of people not using D.

Option #2: with Python and Java it's much more common for tools to be
written in only Python and Java, and to only depend on other
pure-Python and pure-Java libraries, so that when you want something
you can just download a bunch of Python or Java code and it works.
With D you'll more often hit a requirement to install some system
libraries, and then you have to look that up, which is a pain.

Potential technical answer to option #2: teach dub about common OS
package systems so that it can A) suggest OS dependencies, and B)
install OS dependencies. "I noticed that the binary I just built is
linking to these libraries, because I ran ldd on it. Then I did a yum
whatprovides /path/to/libraries and I found some RPMs. Do you want to
add those as CentOS 7 OS dependencies for this project? This won't
prevent anyone from installing your library, but it will make
installation much easier on CentOS 7."

Option #3. There are a bunch of technical inconveniences with dub that
you won't describe because you've mentioned them before and nothing
happened and now everyone agrees that D has an atrocious ecosystem,
right?

In the third case, sorry for intruding on your established consensus,
but could you at least mention an actual problem with dub when it
comes up? Any one of the actual problems, as opposed to the fake
problem of "you can't just download D stuff and use it the way you
can with Python."

On Thursday, 3 October 2019 at 11:59:08 UTC, mipri wrote:
> comes up? Any one of the actual problems, as opposed to the fake
> problem of "you can't just download D stuff and use it the way you can with Python."

IMO a package manager is only needed for scripty throw-away programming. I sincerely doubt it has a big effect on serious application development.

If you build something with a long horizon you don't need a package manager. The time it takes to download and build libraries from github is negligible compared to the overall development time. Besides, if you build something big you also ought to understand the code you are using and the build process, even if it is a library. You have to be able to maintain the library in case it is abandoned...

On 04/10/2019 12:59 AM, mipri wrote:
> 
> In the third case, sorry for intruding on your established consensus,
> but could you at least mention an actual problem with dub when it
> comes up? Any one of the actual problems, as opposed to the fake
> problem of "you can't just download D stuff and use it the way you
> can with Python."

From my experience, there is a tendency from some people especially those that are more experienced in D, to fight how dub wants to do things.

Do it dub's way, and it should "just work" for pure-D code bases.

That isn't to say it doesn't or shouldn't be improved. It does need to be improved, to cover more advanced use cases.

On 10/3/19 3:13 PM, Ola Fosheim Grøstad wrote:
> On Thursday, 3 October 2019 at 11:59:08 UTC, mipri wrote:
>> comes up? Any one of the actual problems, as opposed to the fake
>> problem of "you can't just download D stuff and use it the way you can with Python."
> 
> IMO a package manager is only needed for scripty throw-away programming. I sincerely doubt it has a big effect on serious application development.
> 
> If you build something with a long horizon you don't need a package manager. The time it takes to download and build libraries from github is negligible compared to the overall development time. Besides, if you build something big you also ought to understand the code you are using and the build process, even if it is a library. You have to be able to maintain the library in case it is abandoned...
> 
> 
> 
> 
Totally disagree to you. Package manager is the thing especially if you develop big projects. It allows you easily maintain the infrastructure without manual scripting all dependencies to build your product, test it and deploy. It's really hard to overestimate the value of good package manager.

On Thursday, 3 October 2019 at 11:59:08 UTC, mipri wrote:
>
> The rhetorical value of hyperbolic language like this is that it's so
> rare in these forums. Everyone's just so peppy and ra-ra about D all
> the time that it's very startling to see any dissent.

I know that D is "the best language in the world" and anyone who points out serious flaws is a heretic. But thanks for pointing it out.

>
> Hi. I don't know what you're talking about, because I've done
> exactly this with dub, but I have some guesses.
>
> Option #1: Python and Java are super popular, so anything you happen
> to need will probably be downloadable and immediately usable. "People
> don't use D because people don't use D."
>
> Potential technical answer to option #1: use D. By this measure
> you'll contribute to people using D, and by an increment solve
> the problem of people not using D.

I used D for years. Got cured though. I think you get it only once. After that, you are immune.

> Option #2: with Python and Java it's much more common for tools to be
> written in only Python and Java, and to only depend on other
> pure-Python and pure-Java libraries, so that when you want something
> you can just download a bunch of Python or Java code and it works.
> With D you'll more often hit a requirement to install some system
> libraries, and then you have to look that up, which is a pain.

In other words, a mess of dependencies.

> Potential technical answer to option #2: teach dub about common OS
> package systems so that it can A) suggest OS dependencies, and B)
> install OS dependencies. "I noticed that the binary I just built is
> linking to these libraries, because I ran ldd on it. Then I did a yum
> whatprovides /path/to/libraries and I found some RPMs. Do you want to
> add those as CentOS 7 OS dependencies for this project? This won't
> prevent anyone from installing your library, but it will make
> installation much easier on CentOS 7."
>
> Option #3. There are a bunch of technical inconveniences with dub that
> you won't describe because you've mentioned them before and nothing
> happened and now everyone agrees that D has an atrocious ecosystem,
> right?

There are loads of D users who dislike dub (I always used it for convenience though). I don't know if it's dub itself or just the fact that those who dislike it won't accept anything but make files. I never cared, tbh. The docs used to be hard to read, though, I don't know if that has improved.

> In the third case, sorry for intruding on your established consensus,
> but could you at least mention an actual problem with dub when it
> comes up? Any one of the actual problems, as opposed to the fake
> problem of "you can't just download D stuff and use it the way you
> can with Python."

To be clear, dub is NOT "D's ecosystem", it's a tiny part of it, and most issues are not related to dub but to broken packages due to compiler upgrades and other toolchains. For example, is there a tool to streamline D integration into Android and iOS (cf. Nim)? Where are the plugins for the major IDEs? D doesn't care, but it sure won't scale this way.

On Thursday, 3 October 2019 at 12:53:58 UTC, Chris wrote:
> For example, is there a tool to streamline D integration into Android and iOS (cf. Nim)?

yes, it already just works on android command line and gui coming very soon