I watched silently this discussion and turns out that it will end - as always - in some obscure debate about some obscure languages or more than obscure features.

I take the risk to be blamed, but let me tell you that the developer world does not spin around R, Python, Fortran, Haskell and Go. These are nice languages for a bunch of *nix nerds or very specialized engineers but their usage is very limited. The battle now is between C/C++/C#/Objective C/Java. Even the abominable Javascript has a larger user base that these languages.

Secondly, the same futile waste of energy is consumed in debates about portability. 97% of desktop system, believe-it-or-not, are using various flavours of Windows and some of them OSX. 95% of mobile devices are built on top of Androis/iOS. There is important *nix usage in the server OSes, but the usual developer will not start his programming career writing server applications.

The third mistake in my opinion is that the same "bunch of nerds" are making and documenting the standard library. What the heck is levenshteinDistance? What about largestPartialIntersectionWeighted? boyerMooreFinder? When the usual developer will try to eagerly learn D, he will say: "My place is not here, you must be some computer/mathematics genius to learn this language".

About built-in functionality: Let's say that I want to sort some strings. After I am shocked enough to find out that D has three types of string which in fact they are not strings but some weird arrays of something called immutable(char), I'll look at the sort function prototype:

SortedRange!(Range, less) sort(alias less = "a < b", SwapStrategy ss = SwapStrategy.unstable, Range)(Range r) if ((ss == SwapStrategy.unstable && (hasSwappableElements!Range || hasAssignableElements!Range) || ss != SwapStrategy.unstable && hasAssignableElements!Range) && isRandomAccessRange!Range && hasSlicing!Range && hasLength!Range);

Do you like it? I'll be very scared to use this unreadable brain damaging enumeration of characters. To sum things up, if someone wants to sort some strings, one must already mastering:
- templates;
- eponymous templates;
- alias declarations;
- ranges;
- enums;
- traits;
- dive enough into phobos to understand the meaning of another 8 templates depending maybe on another 1676327672 templates.

Now let's say my name is Hans and I live in Germany or my name is Ali and I live in Turkey. Do you think that the sort function above will meet my expectations? No, because, despite the fact that sort function will sort anything I can imagine, does not take into account the most used scenario: culture sensitivity.

You know, comparing strings with culture sensitivity is just one call to an API function on Windows, but I suppose that that "portability" obsession keeps phobos ignoring it. Let's say that I am not so lazy to call that function: this function is not declared in the so 1990ish std.c.windows, nor in the corresponding lib. So, to use that bloody function, I have two solutions: learn to use coffimplib or link it dynamically with LoadLibrary/GetProcAddress. Fighting the lazyness, I'll find that before using it, I must convert my string to UTF-16 and eventually zero-terminate it.

Another one: there is standard library support for complex numbers. Who's using these complex numbers? But who's using currencies? I bet that more people are using currencies then complex numbers. Despite the evidence, D has no standard support for them. We, mortals, are expecting that 1 / 10 is 0.1 not 0.1000000001 and we don't give a damn about the meaning of 2 + 3i.

So, IMHO, if you want to attract users, here is my list:
- concentrate on most used OSes - Windows/OSX and Android/iOS.
- don't write scary documentation;
- offer standard functionality instead of the obscure one. It's nice to have it, but the use case scenarios are rare. - a GUI will be nice. You know, that thing allowing the developer to put a button and writing events... instead of the sad black console used by nobody I know.

As you can see, there is nothing wrong with the language itself, but with the library.









Reply via email to