Hello !

I'll start here a place to blame the D language with the intent of register here the dark sides of the language and it's libraries with the hope that it will drive efforts to fix then.

First a bit of my experience with the D language, I hear about it some years ago and it was an interesting language but it gave me the impression of immaturity like a bit more than a toy language, most recently I gave it another look and it seems that it progressed a lot since then.

I started searching the net for interesting opensource projects using D language to test then and compare with C/C++ in terms of performance.

Here are my folder with what I found interesting:

ae            dmd-script            harmonia-dad
arsd          DMDScript             harmonia-dad.tgz          tango-trunk
bcd.gen       dmd-script-1          HarmoniaDemo              Tiny-Redis
              dmd-script-2          Higgs
bindings      dranges               languagemachine-0.2.5     ubjsond
Croc          dstep                 ldc2-0.13.0-linux-x86_64  userman
ctags-d       D-templates-tutorial  libasync                  uv.d
d2sqlite3     d-tui                 LuaD                      vibe.d
decimal       d-tut-master                                    vibed.org
deimos        dwt                   minwin
dmd1                                monodHello                vibelog
dmd2          GDC                                             vibenotes
dmd-c++       goldie                Pegged
dmd-newmagic  harmonia

Then I started compiling then to test, most of then do not compile with the latest dmd compiler, I tried to fix then and on some of then after fixing several things I end up finding bugs on DMD compiler that I submit and some of then god fixed but then one dark side of the D language came to light:

There is no backport/bug fix for the stable releases like gcc or other well know software, gcc has at least the latest 3 stable version maintained, when a bug is found it's fixed on all of the maintained versions that suffer from it. The D language should take note/learn from gcc here. Another interesting example is Freepascal when a new compiler version is released they also release a guide that highlight the major changes and how old code will be affected by the changes and examples on how to change the code to work with the new compiler version.
I would like to see the dub packages to declare the minimal dmd compiler version that they guarantee it'll work, and before any new release of dmd use the whole dub packages as a test bed and for every project that do not compile write a how to on how to convert the code to compile or somehow modify the compiler to recognize old constructions and through warnings or other way compile then.

It's so sad to see interesting projects using the D language abandoned tired of code breakage with any dmd compiler evolution.

Let's talk about libraries now, there is some silly things like associative array not having a "clear/lenght=0" way to reset it, and people sugest create templates that does:

foreach(string key; aa.keys) aa.remove(key);

If we are on a memory pressure to liberate memory we need to allocate more memory for big associative arrays that's insane and generate more garbage to be collected (this is a small/silly insane dark side).

Now let's see std.str I expect some functions that are widely available on other languages to be present there but some of then are std.algorithm, std.array, std.container, std.format and even on std.str it's crazy for a new developer to find things on phobos.

And then the massive/crazy attributes/properties and its combinations that makes even harder to understand why some code do not compile and give error messages miles away from our actual offending code (thanks for templates everywhere).

Well I'll update time to time this post and encourage others to do the same hopping that this will drive positive changes to the D language.

Cheers !

On Wednesday, 22 October 2014 at 05:17:54 UTC, Domingo Alvarez Duarte wrote:

> There is no backport/bug fix for the stable releases

I understand now for each release 2.0XX there can be some bugfix releases like 2.0XX.Y. For example, 2.066.1 is a bugfix release for 2.066.


> Let's talk about libraries now, there is some silly things like associative array not having a "clear/lenght=0" way to reset it, and people sugest create templates that does:
>
> foreach(string key; aa.keys) aa.remove(key);

Yep, that one bugged me too. Then I realized this clearance just makes key-value pairs become garbage, so there is a simpler and more effective equivalent:

    A[B] freshCleanAA;
    aa = freshCleanAA;

(where A[B] denotes the type of aa)
That's it!

> There is no backport/bug fix for the stable releases like gcc or other well know software, gcc has at least the latest 3 stable version maintained, when a bug is found it's fixed on all of the maintained versions that suffer from it.

Yes, I agree. I've also complained about not having a stable version in the past. The attitude in the D community is that having one stable and one experimental branch is not desirable. And for some reason it is claimed that D is production ready. I don't agree, and I think exposing that view leads to problems.

It means that features that should have stayed experimental go into the mainline and remain there, and that more half-way features are being added rather than worked on theoretically until a general and more clean solution is found.

I believe you will be happier if you view D as being in an experimental state. And I think it is a valuable experiment too. Especially the static reflection capabilities in a C++ like language is interesting to think about. That is what makes D most interesting to me at the moment.

> It's so sad to see interesting projects using the D language abandoned tired of code breakage with any dmd compiler evolution.

The D designers have expressed an interest in gofix which upgrade source from an old version to a newer version.

Requirements for this to be fully automatic:
- Add a version identifier in the head of each source file, currently not possible?
- Remove string mixins!!
- Careful addition of new features.

> Now let's see std.str I expect some functions that are widely available on other languages to be present there but some of then are std.algorithm, std.array, std.container, std.format and even on std.str it's crazy for a new developer to find things on phobos.

Yes, I agree. Phobos is a mix of useful, esoteric and experimental features. It should be broken down in a different way.

I have recently started to map out the standard features of Haskell and looking at how to represent them in D.   The API and structure of phobos need some work. I think the overrated C++ standard library has influenced phobos too much.

I also want to see string mixins removed from phobos. It is a very ugly feature. I think phobos should move 100% to lambdas and work on the optimization of lambdas if it is a problem.

> Well I'll update time to time this post and encourage others to do the same hopping that this will drive positive changes to the D language.

I like your attitude, but keep in mind that C++ has many more people behind it. I've changed my view to look at D as being in an experimental state. I think the desire to expand features go beyond the capacity of the project both in the compiler and libraries.

And since the compiler is written in C++, it is difficult to make big changes. Compilers written in functional languages such as Haskell or OCaml are more open to experimentation.

On 10/21/2014 11:06 PM, thedeemon wrote:

>      A[B] freshCleanAA;
>      aa = freshCleanAA;
>
> (where A[B] denotes the type of aa)
> That's it!

Alternative:

    A[B] aa;
    aa = aa.init;

Ali

On Wednesday, 22 October 2014 at 06:42:06 UTC, Ali Çehreli wrote:
> On 10/21/2014 11:06 PM, thedeemon wrote:
>
>>     A[B] freshCleanAA;
>>     aa = freshCleanAA;
>>
>> (where A[B] denotes the type of aa)
>> That's it!
>
> Alternative:
>
>     A[B] aa;
>     aa = aa.init;
>
> Ali

`aa.init` is just `null`, which illustrates the problem better:

    int[string] aa = ["foo": 42];
    int[string] aaAlias = aa;
    aa = null;
    assert("foo" !in aa); // Ostensibly cleared...
    assert(aaAlias["foo"] == 42); // Until aliasing is introduced.

On Wednesday, October 22, 2014 06:59:02 Jakob Ovrum via Digitalmars-d wrote:
> On Wednesday, 22 October 2014 at 06:42:06 UTC, Ali Çehreli wrote:
> > On 10/21/2014 11:06 PM, thedeemon wrote:
> >>     A[B] freshCleanAA;
> >>     aa = freshCleanAA;
> >>
> >> (where A[B] denotes the type of aa)
> >> That's it!
> >
> > Alternative:
> >     A[B] aa;
> >     aa = aa.init;
> >
> > Ali
>
> `aa.init` is just `null`, which illustrates the problem better:
>
>      int[string] aa = ["foo": 42];
>      int[string] aaAlias = aa;
>      aa = null;
>      assert("foo" !in aa); // Ostensibly cleared...
>      assert(aaAlias["foo"] == 42); // Until aliasing is introduced.

Well, the reality of the matter is that you can't truly clear it safely, though we could definitely get closer. The in operator gives pointer access to the internals, and the byKey and byValue may do the same (not to mention, opApply), and they could be in progress when you try and clear out the AA, so if you cleared it out, all of those would still have to work (or maybe throw an Error in the cases where iteration is going on). To some extent at least, the internals would still have to be accessible or risk nasty, potentially @system things happening (though obviously, if nothing has references to them, then they're prime for garbage collection). So, I don't know how much of an AA you can truly clear out, and even once you do, it's going to be need to be left to the GC to collect it all. But it should certainly be possible to make it so that further calls to byKey, byValue, the in operater, etc. treat the AA as empty, even if previous calls which have data in use will need to still have access to that data.

So, I'm sure that the situation could be improved, but I don't know if it can be fixed completely. The AA implementation needs a _lot_ of work regardless though.

- Jonathan M Davis

Ola Fosheim Grøstad:

> I think the overrated C++ standard library has influenced phobos too much.

I agree.


> I also want to see string mixins removed from phobos. It is a very ugly feature.

What are your problems with those strings?

Bye,
bearophile

On Wednesday, 22 October 2014 at 07:46:18 UTC, bearophile wrote:
> Ola Fosheim Grøstad:
>> I also want to see string mixins removed from phobos. It is a very ugly feature.
>
> What are your problems with those strings?

1. Source level analysis: Hard to write programs that transform source.

2. Easy to write ugly code: It suffers from the same issues as macros.

3. Language integration: It is desirable to have an application level language that can integrate well with a low level language when calling out to system level libraries.

4. Uniform conventions: a lambda is more generic.

A lambda allows you to call into another language because it can be translated to the same intermediate format. An incomplete string is on a different level.

Ola Fosheim Grøstad:

> 2. Easy to write ugly code: It suffers from the same issues as macros.

Do you mean C macros? I think this is not true.


> 3. Language integration: It is desirable to have an application level language that can integrate well with a low level language when calling out to system level libraries.

I don't understand.


> 4. Uniform conventions: a lambda is more generic.

What's bad in using something less generic?

Bye,
bearophile

On Wednesday, 22 October 2014 at 08:27:53 UTC, bearophile wrote:
> Ola Fosheim Grøstad:
>
>> 2. Easy to write ugly code: It suffers from the same issues as macros.
>
> Do you mean C macros? I think this is not true.

Not C macros, because they are free form and happen before parsing.

On the other hand, C macros can be expanded and then you do source-to-source translation. With D mixins you might have to evaluate CTFE first? That's a source-to-source killer.

I also think AST macros is a bad idea. It works well for Lisp where you have a clean minimal language.

>> 3. Language integration: It is desirable to have an application level language that can integrate well with a low level language when calling out to system level libraries.
>
> I don't understand.

Let's say you create a tight new language "APP-C" that is easy to write application code in, but you use libraries written in a system level language "D" when the more restricted new language falls short. Then you want to call into the D libraries using lambdas written in "APP-C". If those libraries (built on top of phobos) take string mixins, then you have to know both "APP-C" and "D" in order to write an application.

What you want is this:

1. Compile APP-C => common IR
2. Resolve dependencies
3. Compile D => common IR
4. Resolve lambda optimization/inlining on the common IR

With string mixins you get: eh…?

>> 4. Uniform conventions: a lambda is more generic.
>
> What's bad in using something less generic?

It is bad when you get the disadvantages that lambdas do not have (in an optimizing compiler), but don't get advantages?!