On Monday, 22 May 2017 at 20:49:22 UTC, Ecstatic Coder wrote:

> Then, with all due respect, please remove these posts...
>
> IMHO, they are so incredibly off-topic that I don't see why they should remain here to pollute the pages of a D language forum.

The forum is a web frontend for a newsgroup server, which also has a mailing list interface. I think the NG server does support message deletion, and that may cause it to disappear from the web frontend, but it will still be in NG readers and inboxes.

On Sunday, 21 May 2017 at 05:52:11 UTC, Ecstatic Coder wrote:
> Since a few months, I'm using D for all my command-line tools.
>
> For that use case, the language and its standard libraries are really perfect, making it the best scripting language I know, completely exploding JavaScript, Python, Ruby, etc.

Glad to see you're happy with the language.

Let's break down each of these suggestions.

>   - std.database (connect/use MySQL/MongoDB/etc databases)

I while I don't agree that the connection facilities themselves should be included (shipping C libraries has been a huge pain), I agree that some form of either ORM or standardized format of DB API should be in Phobos. Like SQLAlchemy, let's leave the connection to other libraries.

>   - std.ui (draw 2D user interfaces)
>   - std.input (get mouse/touchscreen/etc events)

I would like to point out that users of the languages you mentioned almost never use the builtin versions of these types of libraries (and hasn't maintenance of Swing been a huge time burden on the Java devs, I remember reading this somewhere). Python users use either Qt or GTK, not Tk.

> * a soft-realtime garbage collector (like in Nim), which can progressively recycle the memory of a thread without blocking the whole application.

This is possible, just needs a champion.

>   - std.web (serve web data/files/pages)

There's a philosophical boundary here. There are many ways to make a web server, and there's no one right answer for every web problem. Standardizing one type of server seems improper.

Plus the below problem applies.

>   - std.audio (load/play/process/record sounds/musics)
>   - std.image (load/show/process/record images)
>   - std.video (load/show/process/record videos)
>   - std.graphic (draw 2D/3D graphics)
> * a dedicated IDE, allowing to effortlessly open/compile/execute/debug a single ".d" file as well as an entire project.

The problem with all of these suggestions is that the maintenance burden is so enormous that it would take a medium sized team of paid professionals. Let's take std.graphic as an example. To give a sense of the scale of the job, getting a cross platform graphics API is a task so large that it takes some of the largest corporations in the world (MS, Apple, etc.) to come together to make it happen. It's not so much a code problem as it is an organization problem. The result is OpenGL, an API that no one likes very much and literally no one understands.

So we would have to support OpenGL, because this has to work on Linux and OpenBSD. Next, you probably want to support DX 11, because that's what pretty much 99% of video games use, so that's another monolithic API that you have to incorporate into your agnostic API. Now how about DX 12? Because it's supposedly way faster, and if you're going after game devs, they tend to worry about speed. How about Vulkan? How about OpenGL 3 as well as 4 because Apple abjectly refuses to upgrade for no apparent reason. Speaking of Apple, how about Metal? Oh, and we want to support mobile so don't forget about OpenGL ES, plus all its different versions that have to be supported for different phone platforms.

I cannot stress enough how difficult a task a cross platform 3D graphics library is.

It's the same thing for audio and video too. Just look at all of the different encodings and features ffmpeg supports.

No, best to leave graphics/audio/video to C libraries that already exist. Even if it's painful, it's more painful to copy their work.

> But with some efforts...

D is 100% community run and none of us get paid. Bringing something into Phobos doesn't mean that it gets more work (it can actually mean the opposite). It's gotten to the point where each module in Phobos ostensively has one or two owners who's responsible for its condition in order to spread the load.

> For the web servers, vibe.d is already there.
>
> For desktop applications, there is gtkd and dlangui.

In order to make the existing libraries standard would require

1. An API freeze. Not something that anyone in the community is willing to concede, not even Vibed.
2. Constant, time consuming review of every change, as is required by any standard library for QA. This is why ndslice is no longer in Phobos.
3. Tons of hours of work fixing the bugs that are present in the existing solutions before even considering merging them into Phobos.

> I agree that at the moment, all these developments can be possible through several third-party libraries.

And that's the way it's going to have to stay TBH.

On Sunday, 21 May 2017 at 05:52:11 UTC, Ecstatic Coder wrote:
> Since a few months, I'm using D for all my command-line tools.
>
I consider that D and phobos are quite ready for constant use. As for alternative libraries, I selected a way of integration with Qt. One Small example of my operation on Mac OSX, is mini IDE c use of Qt 5.

https://www.youtube.com/watch?v=JbvUJwShN_c
https://github.com/MGWL/QtE5

Ok, I agree with what you say.

Indeed, it sounds logical to suppose that the developers of the best libraries in each domain won't probably accept that their work is adapted to be promoted to the status of standard libraries, just to keep the full control on them.

That's sad, because I still consider that D's popularity could improve a lot if it was also equipped "by default" to be a rapid application development environment for cross-platform connected web/desktop/mobile applications, but now I've clearly understood why this will never happen.

On Tuesday, 23 May 2017 at 07:33:04 UTC, MGW wrote:
> On Sunday, 21 May 2017 at 05:52:11 UTC, Ecstatic Coder wrote:
>> Since a few months, I'm using D for all my command-line tools.
>>
> I consider that D and phobos are quite ready for constant use. As for alternative libraries, I selected a way of integration with Qt. One Small example of my operation on Mac OSX, is mini IDE c use of Qt 5.
>
> https://www.youtube.com/watch?v=JbvUJwShN_c
> https://github.com/MGWL/QtE5

Thanks for proposing this C++ wrapper.

Qt will get the job done, obviously, so at least now I can implement my GUI with ease.

C++ back to the rescue ;)

On Sunday, 21 May 2017 at 05:52:11 UTC, Ecstatic Coder wrote:
>
>   - std.database (connect/use MySQL/MongoDB/etc databases)

http://code.dlang.org/packages/arsd


>   - std.web (serve web data/files/pages)

vibe.d
http://code.dlang.org/packages/arsd


>   - std.audio (load/play/process/record sounds/musics)

http://code.dlang.org/?sort=updated&category=library.audio


>   - std.image (load/show/process/record images)

http://code.dlang.org/packages/imageformats
http://code.dlang.org/packages/ae
http://code.dlang.org/packages/arsd


>   - std.video (load/show/process/record videos)

http://code.dlang.org/packages/ae
I sometimes process video with command-line pipes using https://github.com/p0nce/y4m-tools

>   - std.graphic (draw 2D/3D graphics)

http://code.dlang.org/packages/ae
Check out its explanation https://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/


>   - std.input (get mouse/touchscreen/etc events)

Honestly you are better off with using SDL.
http://code.dlang.org/packages/derelict-sdl2


>   - std.ui (draw 2D user interfaces)
http://code.dlang.org/packages/dlangui


> I agree that at the moment, all these developments can be possible through several third-party libraries.

So we just need ranking in code.dlang.org?

> So we just need ranking in code.dlang.org?

Again, I'm not saying that these libraries don't exist.

I'm saying that there are many alternatives to choose from, which is fine, but sometimes, not having to search, evaluate and test third-party libraries can be a benefit to the user of a new programming language.

It seems that I'm a good example of this kind of "dumb" programmer, who prefer to have everything already prepared.

Some people like to buy meat, vegetables etc, and cook all that to prepare lasagne or chinese food all by themselves.

Personally, my wife prepares these delicious dishes for me, and I'm perfectly happy with that.

Some people prefer that things are already prepared for them and immediately ready to use, some others don't, and prefer to do all the experiments by themselves until they have found exactly what is best for them.

Not everybody is the same, that's all what I'm saying.

And some of the programmers who try D might not like to take time searching for these libraries, and decide that D is not enough "operational" by their standard, whether it's true or not.

The problem is that all the people on this forum are by definition those who haven't rejected the D language for that reason.

I know at least two fellow programmers who tried it on my advice, and told me that "indeed D is nice but to do xxx it's still easier with yyy".

I tried to explained that with this post, and what could be a solution for that problem, but obviously that was pointless.

On Tuesday, 23 May 2017 at 22:14:22 UTC, Ecstatic Coder wrote:
>
> I tried to explained that with this post, and what could be a solution for that problem, but obviously that was pointless.

Hi,

You'll find agreement here. I wasn't framing my answer as a criticism of your post, which I think is well balanced. The leadership believes in a larger standard library too.

I just wanted to increase awareness of the (sometimes outstanding) libraries there is in the dub registry, that can be used right now. Some of it are below the radar but worthwhile.

On Tuesday, 23 May 2017 at 21:21:45 UTC, Guillaume Piolat wrote:
> http://code.dlang.org/packages/arsd

So actually, the dub thing for mine is

http://code.dlang.org/packages/arsd-official/~master

the other was a third party thing that is now obsolete (and imo this shows one of the weaknesses of dub right now... the list order is just most recent explicit update and old things can't be removed afaik)

>>   - std.input (get mouse/touchscreen/etc events)
>
> Honestly you are better off with using SDL.

oh my simpledisplay does that too! and 2d/3d drawing. and combined with minigui does user interface (though minigui still isn't quite done)


I am tempted to package my stuff with dmd as a one-stop download... but idk if it is really beneficial since my stuff is so easy to download and use anyway with my policy of independent files.

On 24/05/2017 5:04 AM, Adam D. Ruppe wrote:
> On Tuesday, 23 May 2017 at 21:21:45 UTC, Guillaume Piolat wrote:
>> http://code.dlang.org/packages/arsd
>
> So actually, the dub thing for mine is
>
> http://code.dlang.org/packages/arsd-official/~master
>
> the other was a third party thing that is now obsolete (and imo this
> shows one of the weaknesses of dub right now... the list order is just
> most recent explicit update and old things can't be removed afaik)

They can be removed, but that means projects stop being built hence not wanting to remove them.