>> + one binary to distribute
>
> This goes for D as well.

I always wonder about this, it comes up often when people discuss Go favourably. Like "compiles fast", there seems to be a perception problem that most people think only Go has these attributes.* Maybe something for us to stress? I'd never have thought this would be the thing to draw people in, but it keeps getting mentioned for Go so...

>
>> + good for servers
>
> Doable with D (vibe.d), but not part and parcel of the language, although important.
>

Similarly, there's a marketing problem here. A friend of mine who knows I like D said once "but you wouldn't use it to write a server". Which is funny since that's exactly the kind of task I'd use D for.

Is Go good for writing servers? Yes. Is D? Yes!**

There's a good chance that if the concurrency parts of vibe.d made it into the library that we could market the bejeezus out of that. Plus the networking parts of vibe.d as well, of course.

Atila

* I also love that they say "fast" as if that has meaning by itself. Faster than C++? Well done in beating a known slowcoach...
** with vibe.d anyway

>>
>> You are correct, which is why D also supports:
>>
>>    immutable @safe pure {
>>       ... nice declarations ...
>>    }
>>
>>    ... naughty declarations ...
>
> The bottom line is we need a way to undo attributes. -- Andrei

+100

Good language has to attract write good things simple and dirty
things in more complex way. The current state of atribution is
contrary :(

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.

On Saturday, 14 March 2015 at 14:45:07 UTC, rumbu wrote:
> 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.
>

Regular desktop usage statistics don't apply to developer communities. The few times an OS survey was done here, it was overwhelmingly Linux IIRC. You can't expect people who don't use(or have access to) Windows/OSX to cater to those platforms.

D does not have a big corporation like Microsoft or Google backing it, it has people donating their own time.

D focuses on portability because it's a systems programming language, not .NET in native form.

>
> 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:

I can't really think of any language that doesn't implement strings as an array of characters.

> 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.

complex numbers are much easier to implement than a good currency system.


> 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.

Followed by renaming it to D#?

On Saturday, 14 March 2015 at 14:45:07 UTC, rumbu wrote:
> So, IMHO, if you want to attract users, here is my list:
> - concentrate on most used OSes - Windows/OSX and Android/iOS.

I actually think that going "populist" is a serious mistake. Abstraction layers create inefficiencies and inflexibility and D will be best suited for server programming in the near future. D eco system is nowhere near a state where D is suitable for commercial applications.

I'd much rather use a tool that has strong focus on one platform and totally kill on that platform than one that is being mediocre everywhere. D is spreading itself thin, chasing too many trails. OS/iOS/Android/Windows are very expensive trails to follow, because you have to provide comparable tooling which will never happen...

D could have chosen to be excellent on Linux server programming, but then you need to embrace Linux, and make the most out of the platform.

Linux devs are happy with an Emacs mode. Put a lot of effort on a single IDE, like Emacs, and you have something. Creating 10 different IDEs and N different GUI libs that supposedly will make commercial application programming a breeze... goes nowhere. Because it lacks realism.

On Saturday, 14 March 2015 at 14:45:07 UTC, rumbu wrote:
> 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.

+1000

On Saturday, 14 March 2015 at 15:13:44 UTC, weaselcat wrote:

>
> Regular desktop usage statistics don't apply to developer communities. The few times an OS survey was done here, it was overwhelmingly Linux IIRC. You can't expect people who don't use(or have access to) Windows/OSX to cater to those platforms.

This is the keyword: here. Don't expect to attract other kind of developers if you have nothing to offer them. I am using D for 4 years now and I didn't even respond to these polls because I fill as an outsider here. I don't find any use of levenshteinDistance in my LOB applications, i'm keeping to use D for personal experimental projects.

>
> D does not have a big corporation like Microsoft or Google backing it, it has people donating their own time.
>
> D focuses on portability because it's a systems programming language, not .NET in native form.

Portability limited to an OS with 3% usage? std.c.windows is older than my grandma and contains ANSI Windows bindings. But nothing about WinRT. Even the Windows API model has changed in the meantime: https://msdn.microsoft.com/en-us/library/windows/desktop/hh802935%28v=vs.85%29.aspx

"D is a language with C-like syntax and static typing. It pragmatically combines efficiency, control, and modeling power, with safety and programmer productivity." - this is on the landing page.

I see nothing about "system programming language". But I saw something about productivity.

> I can't really think of any language that doesn't implement strings as an array of characters.

I understand very well the meaning of "immutable(char)[]" but I try to walk in the first time user's shoes. The problem is that using a string you must understand before concepts like immutability. To sort them, well, you must buy a book.

> complex numbers are much easier to implement than a good currency system.

Again, just a some calls to WinAPI - https://msdn.microsoft.com/en-us/library/windows/desktop/ms221612(v=vs.85).aspx

Oops, I forgot, we need portability and probably a very versatile kind of currency supporting n bits instead a simple 128 bit standard one and we must write some efficient code, not like the one written by these illiterate programmers from MS. And these functions are not pure and @safe. Let's rewrite them.

>> 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.
>
> Followed by renaming it to D#?

So having built-in Windows/OSX/Andoroid/iOS support, nice documentation, real world functionality and a GUI system makes D some kind of C#? Did I understand it correctly, or it's just a pun?

On Saturday, 14 March 2015 at 16:24:19 UTC, rumbu wrote:
> On Saturday, 14 March 2015 at 15:13:44 UTC, weaselcat wrote:
>>
>> I can't really think of any language that doesn't implement strings as an array of characters.
>
> I understand very well the meaning of "immutable(char)[]" but I try to walk in the first time user's shoes. The problem is that using a string you must understand before concepts like immutability. To sort them, well, you must buy a book.

I'm the only one so old, that for me, studying a language from a book is the normal pattern to follow for learning it?

I remember well all the big books packed in Borland's products....
---
Paolo

Paolo Invernizzi:

> I'm the only one so old, that for me, studying a language from a book is the normal pattern to follow for learning it?

I think it's also a matter of how you usually learn. If you are a person that loves nonfinction books a lot, that reads nonfinction books a lot, then probably you also like to read a language with the help of a book.

Bye,
bearophile

On 3/14/15 1:40 AM, Russel Winder via Digitalmars-d wrote:
> On Fri, 2015-03-13 at 16:13 -0700, Andrei Alexandrescu via Digitalmars-d
> wrote:
>> On 3/13/15 2:22 PM, Russel Winder via Digitalmars-d wrote:
>>> On Fri, 2015-03-13 at 10:31 -0700, Andrei Alexandrescu via Digitalmars-d
>>> wrote:
>>> […]
>>>
>>>>
>>>>      File("/tmp/a").byChunk(4096).joiner.startsWith(s)
> […]
>>
>> How do you mean "conversely"? Maybe you meant "incidentally"? -- Andrei
>
> In functional languages, each stage in the pipeline returns Option to
> avoid error handling. Go does not give you this facility as it refuses
> to allow activity without proper error checking.

Go does not give you this facility for a multitude of reasons, starting with its lack of generic programming.

> So if byChunk returns a failed read, functional language just carry on,
> Go would force the error check, D does…

D throws an exception. Is that good or bad?


Andrei