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.

Now I would like to also use it to develop :
- web servers.
- connected desktop applications & games.
- connected mobile applications & games.

D could also explode the competition for these uses cases, but I think that first it would need to be more *equipped* and *branded* for this.

IMHO, to convince many Java/C#/C++/PHP/Python/Ruby/JavaScript/etc developers to leave the comfort of their current ecosystem, D would need :

* the following *standard* libraries :

  - std.database (connect/use MySQL/MongoDB/etc databases)
  - std.web (serve web data/files/pages)
  - 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)
  - std.input (get mouse/touchscreen/etc events)
  - std.ui (draw 2D user interfaces)

* a dedicated IDE, allowing to effortlessly open/compile/execute/debug a single ".d" file as well as an entire project.

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

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

For the web servers, vibe.d is already there.

For desktop applications, there is gtkd and dlangui.

And for mobile applications, maybe using wrappers for SDL and a fast hardware accelerated UI library like TurboBadger/Nuklear/etc would do the job.

And I know that several IDE are already available.

For instance, Coedit is a nice little IDE, despite its bugs and limitations.

So I know that D could get the job done.

But with some efforts...

And it doesn't feel immediately "equipped" for that...

That's sad, because I think D could be the best tool on the market to develop cross-platform connected mobile/desktop applications, including mobile 2D games.

And even if it is already the case, at least that doesn't *show*, even from the dlang.org website.

A more complete standard library, and a more appealing website (à la juce.com) which would clearly "sell" D's strong advantages over its competition, could be of great help.

Because the day when D will make it really *easy* to do these kind of developments, just by simply installing the standard D environment and reading a few tutorials on how to do web/console/desktop/mobile app/games on dlang.org, it will be very hard for other languages to compete with it...

This is the work I am related to or created myself.

- std.ui.windowing[0]
- std.ui.gui
- std.graphics.image[1]
- std.graphics.color[2]
- std.events[0]
- std.events.loop[0]
- std.audio
- std.sockets[0]

Any assistance to improving my work including[3] would be appreciated as I am slow.

[0] https://github.com/Devisualization/spew
[1] https://github.com/rikkimax/alphaPhobos/tree/master/source/std/experimental/graphic/image
[2] https://github.com/dlang/phobos/pull/2845
[3] https://github.com/rikkimax/ogl_gen

Exactly what I was talking about :D

Thanks for your efforts !!!

I'll download and test them right away.

On 21/05/2017 7:51 AM, Ecstatic Coder wrote:
> Exactly what I was talking about :D
>
> Thanks for your efforts !!!
>
> I'll download and test them right away.

Keep in mind that they are not on code.dlang.org for a reason, they are not ready for general use. So take a developers mindset if you use them. You will find bugs and you will need to fix them if you wish to continue using it.

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.
>
> Now I would like to also use it to develop :
>
> [...]
>
> * a dedicated IDE, allowing to effortlessly open/compile/execute/debug a single ".d" file

It's one of the basement of Coedit. There is the runnable module system as well as the support for DUB single file package. http://bbasile.github.io/Coedit/features_runnables.

> as well as an entire project.

Also supported by the same product. I would be sad to learn you missed this !
http://bbasile.github.io/Coedit/features_projects

> [...]
>
> know that several IDE are already available.
>
> For instance, Coedit is a nice little IDE, despite its bugs and limitations.

(author here) I don't get much bug reports. Usually i find the bugs myself since i'm a hardcore user of the product. Don't think too much, if you encounter a problem then report it: https://github.com/BBasile/Coedit/issues

Coedit is actually by far my favorite IDE for D testing and debugging.

I liked it immediately after I saw that it doesn't need to create a project if all you need it compile and test a small D script.

I know I can create a project, but for tiny projects I don't use it on purpose, despite I personally prefer to have only one file per class, because projects tie the source code compilation to a particular IDE.

All my tools can be compiled with "dmd xxx.d", which is really as simple as it can possibly be.

I know that "dmd aaa.d bbb.d ccc.ddd ..." works too, but as long as my scripts are just a few hundreds of lines of code long, I'm ok with that.

My only concerns with Coedit are a few usability problems when editing the code.

By default :

* When I copy a block of code, I have to select it from the end of the previous line, or else the inserted code indentation goes wrong.

* When doing a find and replace, Coedit replaces the next occurrence despite I don't see it and I'm not sure I want to replace it, instead of the one highlighted under the cursor, which I'm totally sure I want to replace.

* A closing brace is automatically inserted at the wrong position and with a unwanted blank line if I put enter to insert a missing closing brace.

  I'm not sure, but I think the case is the following :
  {
      {
          {
          }<- editor bugs if I put enter to manually add the missing brace on the next line
  }

* The regular expressions are always enabled by default when searching text.

* When I change some preferences, Coedit only keeps them until the next restart.

I know that's really not much, but this bothers me enough so that I still prefer Geany for pure coding sessions.

Only after I've finished programming the core code and prettified it, I switch to Coedit to try compiling, testing and debugging it.

Except for these tiny annoyances when typing code, Coedit is an exceptionally good IDE, and I really like it a lot, that's why it's the only one I've mentioned.

I don't mind posting my usability remarks on your Github account if you confirm me that they can indeed be considered as "bugs"...

On Sunday, 21 May 2017 at 06:55:19 UTC, rikki cattermole wrote:
> On 21/05/2017 7:51 AM, Ecstatic Coder wrote:
>> Exactly what I was talking about :D
>>
>> Thanks for your efforts !!!
>>
>> I'll download and test them right away.
>
> Keep in mind that they are not on code.dlang.org for a reason, they are not ready for general use. So take a developers mindset if you use them. You will find bugs and you will need to fix them if you wish to continue using it.

Ok no problem :)

On Sunday, 21 May 2017 at 11:27:19 UTC, Ecstatic Coder wrote:
> Coedit is actually by far my favorite IDE for D testing and debugging.
>
> I liked it immediately after I saw that it doesn't need to create a project if all you need it compile and test a small D script.
>
> I know I can create a project, but for tiny projects I don't use it on purpose, despite I personally prefer to have only one file per class, because projects tie the source code compilation to a particular IDE.
>
> All my tools can be compiled with "dmd xxx.d", which is really as simple as it can possibly be.
>
> I know that "dmd aaa.d bbb.d ccc.ddd ..." works too, but as long as my scripts are just a few hundreds of lines of code long, I'm ok with that.
>
> My only concerns with Coedit are a few usability problems when editing the code.
>
> By default :
>
> * When I copy a block of code, I have to select it from the end of the previous line, or else the inserted code indentation goes wrong.

Indeed.

> * When doing a find and replace, Coedit replaces the next occurrence despite I don't see it and I'm not sure I want to replace it, instead of the one highlighted under the cursor, which I'm totally sure I want to replace.

There's a checkbox that allows to activate prompts when a match is found.

>
> * A closing brace is automatically inserted at the wrong position and with a unwanted blank line if I put enter to insert a missing closing brace.
>
>   I'm not sure, but I think the case is the following :
>   {
>       {
>           {
>           }<- editor bugs if I put enter to manually add the missing brace on the next line
>   }

This feature is still a bit dumb when you're in the middle of existing code.
When writing new code it works fine. It can be fully deactivated by the bye.
I encounter this issue as well but very occasionally.

>
> * The regular expressions are always enabled by default when searching text.

It doesn't mean that you have to fill the search field with a REGEX. It means that you CAN type one but it's not a requirement ! Plain text will be searched in a standard way, whatever is the state of the "Allow regex" option, which means "contains text" or "exact text" depedning on the "whole word" option.

> * When I change some preferences, Coedit only keeps them until the next restart.

That would be surprising. Please open an issue for this or let's talk on IRC.

> I don't mind posting my usability remarks on your Github

You should really. My level of satisfaction is not universal. Without feedback it'll stay specialized for my own usage.

Ok :)

Thanks for the quick answer !

On Sunday, 21 May 2017 at 05:52:11 UTC, Ecstatic Coder wrote:
> * the following *standard* libraries :

Suppose I made a dmd distribution with my libraries pre-packaged (I already have libraries for most the stuff you listed)... would that work for you? Or must it come from the dlang.org site and be `std.` for it to count?

I have no interest whatsoever in being in the official standard library though. Of course, using my libs is pretty trivial... download one or two files and add them to your build command, done.