On Sunday, 24 May 2020 at 11:13:03 UTC, Bastiaan Veelo wrote:
> On Saturday, 23 May 2020 at 19:12:14 UTC, mw wrote:
>> On Saturday, 23 May 2020 at 18:45:25 UTC, Bastiaan Veelo wrote:
>>> Your run-of-the-mill manager would think like that, I guess.
>
>> (I even don’t bother the personal attack in your words)
>
> No attack intended!

Ah now I see how my words may have come out hostile. I was not insinuating anything about _your_ manager. I meant something like "the typical manager". I thought that's how the phrase is typically used ("Your run-of-the-mill ...") but I'm not a native English speaker.

-- Bastiaan.

On Sunday, 24 May 2020 at 16:26:33 UTC, Bastiaan Veelo wrote:
> Ah now I see how my words may have come out hostile. I was not insinuating anything about _your_ manager. I meant something like "the typical manager". I thought that's how the phrase is typically used ("Your run-of-the-mill ...") but I'm not a native English speaker.

No worries, neither am I.

On Sunday, 24 May 2020 at 06:57:01 UTC, Luis wrote:
> On Sunday, 24 May 2020 at 01:56:13 UTC, mw wrote:
>>
>> I would say libraries can make a language, or destroy one.
>>
>> Numpy has made Python’s fame. I think currently D is on the other side of this spectrum (after 20 years).
>
> And Ruby had Rails...
>
> The question is... we have something with these potential to become popular ?


D is late in the game, but still have potentials because of D's good performance and language features, e.g.

-- If vibe.d can catch up on the easy of use, and fast-prototyping with Django, Rails (performance-wise, we have trust in D), people may want to switch over to use it, after all compiled language ensures type safety for web services.

-- maybe numD? numpy is great, but because of the Python language's Global Interpreter Lock (GIL), people who want parallel data processing can only run on separate tasks via multiple processes, which sometimes is inconvenient when exchange information via shared memory is needed. This problem is *inherently unsolvable* in Python because of the GIL. If numD can offer everything numpy has offered, and plus parallel processing via multiple threads on multi-cores, it will have an edge.

-- the recent change @safe as default opt-in is good thing: without a @nogc phobos, nobody is going to write @system level software using D. I think this @safe change means the shift of D's focus from system software to application software. And I'm glad to see the the template project that dub generate starts with "app.d", which is the right direction for D.

-- anyone have more ideas to throw in?

On Sunday, 24 May 2020 at 17:29:54 UTC, mw wrote:

> -- anyone have more ideas to throw in?

Pegged have a good potential. Nobody catches how powerful it's a parser library that can parse stuff on compilation time ?

On Sunday, 24 May 2020 at 17:48:37 UTC, Luis wrote:

> Pegged have a good potential. Nobody catches how powerful it's a parser library that can parse stuff on compilation time ?

Bastiaan Veelo at DConf 2017: Extending Pegged to Parse Another Programming Language
https://www.youtube.com/watch?v=NoAJziYZ4qs&feature=youtu.be

On Friday, 22 May 2020 at 21:01:58 UTC, mw wrote:
> Hi,
>
> I'm new here, try to start using D on my hobby projects, and I quickly run into issues when looking for supporting libraries.
>
> I'm searching for a fixed point (decimal) type. On code.dlang.org, I found two packages having the functionalities that I need:
>
> https://code.dlang.org/packages/decimal
> https://code.dlang.org/packages/money
>
> But I then run into issues with these packages (one has bug, and the other has compilation issues:
> https://github.com/qznc/d-money/issues/11
> https://github.com/rumbu13/decimal/issues/9)
>
> And worse, it looks like both packages are no longer maintained by their original owners.
>
> Then I found other people experienced the same difficulties, and started to re-invent those wheels, and the new packages are in 0.0.x stage with limited functionalities.
>
> I think we are wasting our community effort here. I'm wondering:
>
>
> 1) can we form a dub packages maintenance group, to take care of these no longer maintained packages
>
>
> 2) can we change the code.dlang.org to allow other users take over those packages, e.g. after 2 weeks no reply from the original owner:
>
> https://github.com/rumbu13/decimal/issues/9#issuecomment-632843049
>
> '''
> I would be willing to take over and fix the package.
> I have forked it already months ago.
> The most important think would be to give me access on code.dlang.org, so users would find it.
> '''
>
> https://github.com/rumbu13/decimal/issues/8 (this issue has been more than half year now).
>
>
> 3) make the new "may-take-over-when-needed" policy explicit on https://code.dlang.org/, when people register new packages.
>
>
> 4) create a "dub packages maintenance" group in this forum, so people can discuss these issues.
>
>
> Anything else? thoughts?

I am back, if you need me (ref decimal). Explanation for the failed test is here:
https://github.com/rumbu13/decimal/issues/9#issuecomment-767776857

On Friday, 22 May 2020 at 21:01:58 UTC, mw wrote:
> Hi,
>
> I'm new here, try to start using D on my hobby projects, and I quickly run into issues when looking for supporting libraries.
> Anything else? thoughts?

I think there should be one universal library that should contain modules for everything, that way all work would be done with only one library, that would make it more organized and maintainable since there would be only one library to take care of.

On Wednesday, 27 January 2021 at 18:18:51 UTC, Murilo wrote:
> On Friday, 22 May 2020 at 21:01:58 UTC, mw wrote:
>> Hi,
>>
>> I'm new here, try to start using D on my hobby projects, and I quickly run into issues when looking for supporting libraries.
>> Anything else? thoughts?
>
> I think there should be one universal library that should contain modules for everything, that way all work would be done with only one library, that would make it more organized and maintainable since there would be only one library to take care of.

https://xkcd.com/927/ ;)

On Wednesday, 27 January 2021 at 18:18:51 UTC, Murilo wrote:
> I think there should be one universal library that should contain modules for everything, that way all work would be done with only one library, that would make it more organized and maintainable since there would be only one library to take care of.

And the usage of only one language would also unify the power of maintenance and organization, but which language should be the one... :)

On Wed, Jan 27, 2021 at 08:57:30PM +0000, Petar via Digitalmars-d wrote:
> On Wednesday, 27 January 2021 at 18:18:51 UTC, Murilo wrote:
> > On Friday, 22 May 2020 at 21:01:58 UTC, mw wrote:
> > > Hi,
> > > 
> > > I'm new here, try to start using D on my hobby projects, and I quickly run into issues when looking for supporting libraries. Anything else? thoughts?
> > 
> > I think there should be one universal library that should contain modules for everything, that way all work would be done with only one library, that would make it more organized and maintainable since there would be only one library to take care of.
> 
> https://xkcd.com/927/ ;)

Not to mention, one giant, monolithic library that tries to do everything will be a nightmare to maintain; after a certain point you couldn't change anything without breaking or becoming incompatible with other parts of the library, and it would be a slog just to get a simple change implemented.

My inclination these days is small, self-contained libraries with few (preferably no) dependencies. Adam Ruppe's arsd library is an excellent example.  With a small, independent codebase you can move much faster without being held back by large-scale considerations inevitable in a large codebase.


T

-- 
PNP = Plug 'N' Pray