On Monday, 30 September 2019 at 10:41:21 UTC, Ola Fosheim Grøstad wrote:
> Haskell is very successful. It completely dominates the niche it was aiming for, a shared language for functional programming researchers. Sure, it lacks some namespace capabilities needed for writing large programs, but that is not needed for research...

Last time Haskell was a research language was 10 or 15 years ago. There are now better research functional programming languages than Haskell, like Idris or Agda. Haskell is used by industry much more than D, by big corporations as well as start-ups.

The thing with Haskell is that it is a dead simple language. There are algebraic data structures, functions, typeclasses, some syntactic sugar and a few compiler extensions. No „alias this“, no structs and classes, no delegates and functions, no loops, no attributes, no function overloading, no casts – well, some of them may be useful for systems programming, but sure not everything. Instead it provides abstractions that can be used in different situations. D (and the most imperative languages) introduce language features for each use case and languages become bloated (particulary if it is a mainstream language). This joke „Avoid success at all cost“ probably means: Don‘t just follow trends, think about features you‘re going to introduce. As result Haskell has great GC and a compiler which is good at optimizing, it doesn‘t have the greatest infrastructure, but at least a set of libraries, you can build almost everything on. The only language I used, that is as buggy as D is Facebook‘s Hacklang. But well, Facebook is known for low quality software.

When I first came to D, I thought: Wow, what a nice, simple language. But after some years it isn‘t simple, it gets terribly complicated. Therefore I like Zig‘s slogan: „Focus on debugging your application rather than debugging your programming language knowledge.“
Even the last DIP says: It is the first step, more is coming later. And I‘m 90% sure, it will be never finished. Not because it is D, but because this „I finish it later“ just never works in engeneering. And this kind of things just doesn‘t happen anymore to Haskell (or at least not to the same extent).

On Monday, 30 September 2019 at 11:05:58 UTC, IGotD- wrote:
> I though this thread was about Nim. Nim hit 1.0 which I think is great because we need alternative systems languages. Instead this thread becomes some kind of panic for the D community because Nim advances and many think D doesn't.
>

While I don't fully subscribe to the language war theory, I don't see Nim as any competition. I just don't see anything going on for Nim right now. I expect it will linger on the same level of popularity as say Pascal, with some dedicated community, support in most online compiler tools, some IDE plugins, but nothing else. Even compared to D... I just don't see Nim ever going big

> libraries/interfaces are more immature. Rust is the most competitive contender but as complicated Rust can be D can really be an option here. Most companies want a solution quickly and with good quality and D could provide this fast path. For my next project, I will suggest using D instead for those kinds of services.

Many people mistakenly assume Rust's popularity comes down to borrow checker & memory safety features. But it is just a bonus. Most of the Rust's popularity comes from active community and good language focus. Lack of language runtime is a plus too, because it makes it a very good language for targeting embedded/WebAssembly.

> I don't mind GC that much but removing GC from Phobos isn't bad either so the priority is not that high for me. Could someone please explain why @nogc is a priority. What I think is one high priority is to get reference counted GC in D because that opens up D for the performance crowd who do not want stop the world GC.
>

I think no matter what you do, C++ folks will complain. They're just triggered by the word GC. That's why every single discussion thread about D outside of this forums starts at the GC. Then someone will mention @nogc or refcounting. Then someone will chime in about how you lose most of the packages and standard library because it assumes GC is present. And then people will just go "oh man, that is so complicated".

On Monday, 30 September 2019 at 16:39:22 UTC, Eugene Wissner wrote:
> Last time Haskell was a research language was 10 or 15 years ago. There are now better research functional programming languages than Haskell, like Idris or Agda. Haskell is used by industry much more than D, by big corporations as well as start-ups.

Alright then, in my mind languages like Haskell and ML will always primarily be academic PL references, although they also have commercial applications. Anyway, both Haskell and ML are successful considering the use context they evolved in.

> As result Haskell has great GC and a compiler which is good at optimizing, it doesn‘t have the greatest infrastructure, but at least a set of libraries, you can build almost everything on.

Right, I am not a Haskell programmer, but I think the naming of some functions are odd, although I understand that there are historic FP traditions that has led to it.  It does bring with it FP-cultural baggage... It could do better from a usability point of view.

> Even the last DIP says: It is the first step, more is coming later. And I‘m 90% sure, it will be never finished. Not because it is D, but because this „I finish it later“ just never works in engeneering. And this kind of things just doesn‘t happen anymore to Haskell (or at least not to the same extent).

It is not a good idea in software in general, considering that common wisdom says that initial development is only 10% of the overall life-time-costs. If you keep pushing forward without completing existing features I think the ratio will be a lot worse...

On Monday, 30 September 2019 at 16:47:51 UTC, JN wrote:
> Many people mistakenly assume Rust's popularity comes down to borrow checker & memory safety features. But it is just a bonus. Most of the Rust's popularity comes from active community and good language focus. Lack of language runtime is a plus too, because it makes it a very good language for targeting embedded/WebAssembly.

Probably true, but I think Rust is the hipster language of imperative languages. The fact that they had a fairly active community before it was usable says something, I think.

That hipster-factor came from referencing advanced type theory (the theoretical foundation for the borrow checker) and also providing a ML-ish academicish syntax.

C++/D is bread-and-butter in comparison

> And then people will just go "oh man, that is so complicated".

Memory management ought to be integrated into the language semantics and not delegated to libraries though. Otherwise it quickly becomes complicated for the programmer...

So, that is a weakness that C++ and D shares.

On Mon, Sep 30, 2019 at 04:47:51PM +0000, JN via Digitalmars-d wrote: [...]
> I think no matter what you do, C++ folks will complain. They're just triggered by the word GC. That's why every single discussion thread about D outside of this forums starts at the GC. Then someone will mention @nogc or refcounting. Then someone will chime in about how you lose most of the packages and standard library because it assumes GC is present. And then people will just go "oh man, that is so complicated".

+1 LOL, that's totally how such discussions tend to go.

It's just like Walter himself has said on several occasions. Why bend over backwards to please the non-adopting crowds who will just move on to the next excuse not to use D once you've addressed their current complaint?  Rather, we should be concerned about making *existing* users happier -- and there's no shortage of action items there.


T

-- 
Unix is my IDE. -- Justin Whear

> I think no matter what you do, C++ folks will complain. They're just triggered by the word GC. That's why every single discussion thread about D outside of this forums starts at the GC. Then someone will mention @nogc or refcounting. Then someone will chime in about how you lose most of the packages and standard library because it assumes GC is present. And then people will just go "oh man, that is so complicated".

Exactly. ILHO the "BetterC' approach won't help D get new adopters.

One the contrary, all the effort spent in removing the GC is useless, as the GC is precisely what makes D a better language over C++.

I'm convinced his huge amount of effort should have been spent on making D a better Go/Crystal/etc.

As I said earlier, I *REALLY* wanted to implement Cyclone, my CQL/SQL script runner in D.

The problem is it was SO MUCH easier to do it in Go, despite is EXTREMELY limited compared to an object oriented language like D : no genericity, no parametric polymorphism, no virtual inheritance, etc.

But the language and its standard library provides ALL the building blocks you need to implement web servers (coroutines, HTTP, etc), and the official CQL/SQL database drivers are complete, optimized, well maintained and used extensively.

As I already said, it takes you just a few very simple lines of code to implement this script runner in Go, because you can clearly see that the language itself was designed especially for that : manage efficiently HTTP and database connections.

Which is nice, because it's the world most developers live in now.

Putting so much effort in trying to convince the few developers developing C++ embedded applications to switch to D, while D is a very nice garbage collected language, and so many of us use other ones (Java, C#, JavaScript, Python, PHP, etc) to develop connected applications a completely ineffective strategy, if D wants more contributors.

Because as one has said above, with so few contributors working on their spare time or funded by the D sponsors, I think the language should strive to remain as SIMPLE as possible, and first be enhanced to provide what most STANDARD developers need, not to add complicated micro-features which are useless to most of us.

And unfortunately, despite their imperfections, it seems that several new languages like Go and Crystal have at least perfectly understood those principles.

On Tuesday, 1 October 2019 at 05:35:22 UTC, Ecstatic Coder wrote:
> As I already said, it takes you just a few very simple lines of code to implement this script runner in Go, because you can clearly see that the language itself was designed especially for that : manage efficiently HTTP and database connections.

I don't disbelieve you, but I also really don't want to learn Go just
so that I can understand what D is missing. Do any of these threads
ever result in arewexyet type webpages, or even wiki lists of features
that D would need to be as good at some role as some other technology?

Say, a category of "D Gaps", and pages of the pattern, "I looked at
using D for <purpose>, and I missed these conveniences: [list]".

Some purposes:

1. data science
2. bioinformatics
3. machine learning
4. scripting Microsoft applications through COM
5. writing CGI scripts
6. writing an Apache module
7. rewriting Python and Perl sysadmin scripts
8. mobile app development
9. desktop app development
10. quick CLI tools that fetch some webpages

I've done a lot of these but for bioinformatics f.e. my list
of features ends at:

* they use 'FASTA files'
* they want fast regular expressions
* some preferences stemming from them not being 'real programmers' --
not pejoratively, but look at https://www.youtube.com/watch?v=9ZxtaccqyWA occasional remarks about scientists using Python.

I bet that a lot of people would deny that #4 or #5 are even valid
things to want to do in the current millennium.

> I think the language should strive to remain as SIMPLE as possible, and first be enhanced to provide what most STANDARD developers need

Are you sure that 'STANDARD developers' even exist? This might be
unfair but I see a lot of solipsism in complaints like this. To put it
a kinder way, I think you are underestimating how valuable your own
experience is in your own industry.

On Tuesday, 1 October 2019 at 06:29:30 UTC, mipri wrote:
> On Tuesday, 1 October 2019 at 05:35:22 UTC, Ecstatic Coder wrote:
>> As I already said, it takes you just a few very simple lines of code to implement this script runner in Go, because you can clearly see that the language itself was designed especially for that : manage efficiently HTTP and database connections.
>
> I don't disbelieve you, but I also really don't want to learn Go just
> so that I can understand what D is missing. Do any of these threads
> ever result in arewexyet type webpages, or even wiki lists of features
> that D would need to be as good at some role as some other technology?
>
> Say, a category of "D Gaps", and pages of the pattern, "I looked at
> using D for <purpose>, and I missed these conveniences: [list]".
>
> Some purposes:
>
> 1. data science
> 2. bioinformatics
> 3. machine learning
> 4. scripting Microsoft applications through COM
> 5. writing CGI scripts
> 6. writing an Apache module
> 7. rewriting Python and Perl sysadmin scripts
> 8. mobile app development
> 9. desktop app development
> 10. quick CLI tools that fetch some webpages
>
> I've done a lot of these but for bioinformatics f.e. my list
> of features ends at:
>
> * they use 'FASTA files'
> * they want fast regular expressions
> * some preferences stemming from them not being 'real programmers' --
> not pejoratively, but look at https://www.youtube.com/watch?v=9ZxtaccqyWA occasional remarks about scientists using Python.
>
> I bet that a lot of people would deny that #4 or #5 are even valid
> things to want to do in the current millennium.
>
>> I think the language should strive to remain as SIMPLE as possible, and first be enhanced to provide what most STANDARD developers need
>
> Are you sure that 'STANDARD developers' even exist? This might be
> unfair but I see a lot of solipsism in complaints like this. To put it
> a kinder way, I think you are underestimating how valuable your own
> experience is in your own industry.

If you disregard Windows as deployment platform, then #4 is not a valid thing to do in currently millennium, given that since Windows Vista COM has been the bread and butter of Windows APIs (nowadays known as UWP), and of recently device drivers as well (universal drivers).

Likewise #5 has been reborn as the new fad "serverless computing", again it depends on how long this fad might keep going on the cloud computing generation.

On 01/10/2019 8:45 PM, Paulo Pinto wrote:
> If you disregard Windows as deployment platform, then #4 is not a valid thing to do in currently millennium, given that since Windows Vista COM has been the bread and butter of Windows APIs (nowadays known as UWP), and of recently device drivers as well (universal drivers).

The direct equivalent of COM on *nix is D-Bus.
And desktop environments like KDE are pushing a lot of behavior through it.

So its written very specifically, but in a more generic form it is entirely valid.

On Monday, 30 September 2019 at 18:41:07 UTC, H. S. Teoh wrote:
>
> It's just like Walter himself has said on several occasions. Why bend over backwards to please the non-adopting crowds who will just move on to the next excuse not to use D once you've addressed their current complaint? Rather, we should be concerned about making *existing* users happier -- and there's no shortage of action items there.
>
>
> T


How do you reconcile that with people leaving D again? Anyway, there are two things in the statement above:

1. Walter admits that D only caters for a few users with very specific use cases (niches). There's nothing wrong with that, but please state it _publicly_ on dlang.org. Of course people will be p****d off when they are sold one thing (general purpose language), only to find out later that they don't count at all, that D is only for the "chosen few". Also, the "chosen few" shouldn't go on about how great things are with D, of course it's great for _them_, because they get their pet features implemented.
2. Given 1., it makes even less sense that D is such a mess. If you have a small target audience with a more or less small set of requirements, then D could focus on that and have a sound and compact language for special purposes.

In other words, D fails in both ways. It disregards the ordinary programmer, but it doesn't provide its pet users (the "chosen few") with a sound and stable language either. So what is D all about then?