On Sunday, 7 November 2021 at 06:36:48 UTC, arco wrote:
> Many people have forgotten it now but at one point, Rust had classes with inheritance as well as a GC. It was concluded that those features didn't belong in a systems language and were removed. This is probably Rust's greatest strength over D: its consistency, the follow through to ensure that features that are declared stable are really rock solid and make sense within the language's general philosophy.
I agree.

Go still doesn't even have generics in stable and
> it hasn't slowed down its adoption.
I have noticed Go adoption has slowed down a lot. I wanted to love Go... but it was too slow to get anything done besides a hello world type program. Since you said this, I decided to double check and the tiobe index seems to agree, as does google trends. I think Go's decline in popularity is an example of all the problems D doesn't have. It's mild success includes all the things D lacks: standard tools, corporate backing, tutorials, etc..

> Regarding Python, its biggest advantage (other than its outstanding ecosystem) is that it's a dynamic language. Prototyping, testing, customising etc will always be easier and more flexible in Python than in any compiled language. Plus its conscious focus on a simple syntax makes it in my opinion the modern day heir to the BASIC of the 80s in terms of universal applicability and a kind of immediacy.

I agree that that is the appeal of python. It's dynamic but also has languages. What other languages is like that? Javascript is kind of like that, but it's such a horrible language anyway.

> D's general approach has been to always try to have its cake and eat it too. It wants a GC but at the same time wants to pretend that it doesn't need a GC, it wants to support OOP (with inheritance etc) and at the same time tries to downplay it, etc. Ultimately in each of these cases it fails to provide the advantages of either of the valid choices while retaining the disadvantages of both.

I have experienced this phenomenon a lot in my career, but I think D is pretty good at having more than one way of doing things. I like not having to have classes, but I like having them available. The way I feel about frameworks is how I feel about languages like python. You have to do it their way even though you know a better way. With D, I do feel like . This is one of it's strongest advantages. If I want to do string handling in a pointer-based way, I can! If I want to use normal methods, the language supports that. Arrays are a great example. You get most of, if not all of, the power of a list in another language, but you get all the power of arrays. I'd like to see an example that shows you get the worst of both! I have relied on that heavily this weekend.


> This is a hard lesson that D desperately doesn't want to learn. By trying to appease everyone it ultimately doesn't win for anyone in particular.

Although I agree with pretty much everything you have written, I think that is one of D's strengths. That was reiterated this weekend. I got a call for a job and they said the next interview would be on codesignal.com. I did about 100 practice problems and I found myself reaching for D a lot. There were some problems where I pretty much had to go to C# if I wanted to do it in 5 minutes (most things Linq related or string related. I don't know what D's equivalents are.)

I don't think D needs to stick to one way to do everything. I think Python is popular almost in spite of that because it's easy to start and it has good libraries. You get that constant success metric where you write something and it works right away and you tweak it and get little wins along the way. D is similar except for some safety stuff that I have ideas about (immutable, const, etc.)

There are two effects I see where being opinionated is VERY helpful - maybe essential - to a language.
1. Documentation and tutorials
Tutorials need to be opinionated. People need to see ONE way to do things when they learn. Once they understand, they can take advantage of all the different ways, but they need to see a path to success.
2. Whatever you expect people to do with the language, it needs to be designed so there is at LEAST one way to do the above things that is elegant. For example, web servers usually allow some kind of annotation-based routing system. If you use Jetty and you do your own routing, that is fairly confusing and time-consuming. That is something where the annotation-based method is a simple solution and allows you to not have to discuss much about routing and that part of the framework to a new user. It allows you to streamline. However, for Jetty (and technically others), you don't HAVE to do it that way. It's just the default way. Someone once said something like allow endless configuration but provide sensible defaults. That's what the D language is good at.

I would like to read your response to this.


 Then they can take advantage of the rest. It needs to provide a vision when teaching. I don't think the language needs to be opinionated, but the tutorials need to be. Also, they need to have a succe

On Sunday, 7 November 2021 at 06:36:48 UTC, arco wrote:
> Many people have forgotten it now but at one point, Rust had classes with inheritance as well as a GC. It was concluded that those features didn't belong in a systems language and were removed. This is probably Rust's greatest strength over D: its consistency, the follow through to ensure that features that are declared stable are really rock solid and make sense within the language's general philosophy.

I agree.

> Go still doesn't even have generics in stable and it hasn't slowed down its adoption.

I have noticed Go adoption has slowed down a lot. I wanted to love Go... but it was too slow to get anything done besides a hello world type program. Since you said this, I decided to double check and the tiobe index seems to agree, as does google trends. I think Go's decline in popularity is an example of all the problems D doesn't have. It's mild success includes all the things D lacks: standard tools, corporate backing, tutorials, etc. Maybe not libraries.

> Regarding Python, its biggest advantage (other than its outstanding ecosystem) is that it's a dynamic language. Prototyping, testing, customising etc will always be easier and more flexible in Python than in any compiled language. Plus its conscious focus on a simple syntax makes it in my opinion the modern day heir to the BASIC of the 80s in terms of universal applicability and a kind of immediacy.

I agree that that is the appeal of python. It's dynamic but also has libraries. What other language is like that? Javascript is kind of like that, but it's such a horrible language in comparison (I think).

> D's general approach has been to always try to have its cake and eat it too. It wants a GC but at the same time wants to pretend that it doesn't need a GC, it wants to support OOP (with inheritance etc) and at the same time tries to downplay it, etc. Ultimately in each of these cases it fails to provide the advantages of either of the valid choices while retaining the disadvantages of both.

I have experienced this phenomenon a lot in my career, but I think D is pretty good at having more than one way of doing things. I like not having to have classes, but I like having them available. The way I feel about frameworks is how I feel about languages like python. You have to do it their way even though you know a better way. With D, I feel like a library. I can use it's features if I want and not if I don't. This is one of it's strongest advantages. If I want to do string handling in a pointer-based way, I can! If I want to use normal methods, the language supports that. Arrays are a great example. You get most of, if not all of, the power of a list in another language, but you get all the power of arrays. I'd like to see an example that shows you get the worst of both! I have relied on that heavily this weekend.

> This is a hard lesson that D desperately doesn't want to learn. By trying to appease everyone it ultimately doesn't win for anyone in particular.

Although I agree with pretty much everything you have written, I think that is one of D's strengths. That was reiterated this weekend. I got a call for a job and they said the next interview would be on codesignal.com. I did about 100 practice problems and I found myself reaching for D a lot. There were some problems where I pretty much had to go to C# if I wanted to do it in under 5 minutes (most things Linq related or string related. I don't know what D's equivalents are.)

I don't think D needs to stick to one way to do everything. I think Python is popular almost in spite of it's one-way-only philosophy because it's easy to start and it has good libraries. (Although being easy to get started is probably helped by the one-way-only philosophy for reasons I get to below.) You get that constant success feedback where you write something and it works right away. Then you tweak it and get little wins along the way. D is similar except for some safety stuff that I have ideas about (immutable, const, etc.)

There are two effects I see where being opinionated is VERY helpful - maybe essential - to a language.
1. Documentation and tutorials
Tutorials need to be opinionated. People need to see ONE way to do things when they learn. Once they understand, they can take advantage of all the different ways, but they need to see a path to success.
2. Whatever you expect people to do with the language, it needs to be designed so there is at LEAST one way to do the above things that is elegant. For example, web servers usually allow some kind of annotation-based routing system. If you use Jetty and you do your own routing, that is fairly confusing and time-consuming. That is something where the annotation-based method is a simple solution and allows you to not have to discuss much about routing and that part of the framework to a new user. It allows you to streamline. However, for Jetty (and technically others), you don't HAVE to do it that way. It's just the default way. Someone once said something like allow endless configuration but provide sensible defaults. That's what the D language is good at.

I would like to read your response to this.

I hit send instead of save and preview on the previous post. If someone can delete it, please do.

On Monday, 8 November 2021 at 05:20:43 UTC, harakim wrote:


> I have experienced this phenomenon a lot in my career, but I think D is pretty good at having more than one way of doing things. I like not having to have classes, but I like having them available. The way I feel about frameworks is how I feel about languages like python. You have to do it their way even though you know a better way. With D, I feel like a library. I can use it's features if I want and not if I don't. This is one of it's strongest advantages. If I want to do string handling in a pointer-based way, I can! If I want to use normal methods, the language supports that. Arrays are a great example. You get most of, if not all of, the power of a list in another language, but you get all the power of arrays. I'd like to see an example that shows you get the worst of both! I have relied on that heavily this weekend.

This is great if you are an enthusiast who implements stuff this week-end. In large scale projects you unavoidably end up in the situation where you are convinced you know a better solution, and so does your colleague, and another colleague etc. Of course, each of you has a different solution and you all "know" that yours is the best. The bicycle sched fallacy is always lurking at every corner with this type of approach.

The examples to support my point are plenty. The GC to begin with. D relies on a GC so it's not really usable as a systems language. At the same time, since it doesn't want to fully commit to the GC and wear it with pride, it has a mediocre one and is not a good choice for projects where I feel that a GC-based language is the way to go. Developers are permanently wondering what kind of memory management they should use, because they can't see a clear picture or consensus and whichever decision they make, it will unavoidably clash with other parts of the ecosystem or even the same codebase.

Similarly you may want to handle your strings as pointers like in C, but Joe's output library expects std.string. What now? As a result, the developer spends time dealing with trivial issues like that instead on focusing on solving the actual problem.

It just keeps coming back to the same issue: the point of software development is not to have fun with the language or be "creative" with it, it's to provide a solution to a problem that other people will be able to use with as little friction as possible.

> Although I agree with pretty much everything you have written, I think that is one of D's strengths. That was reiterated this weekend. I got a call for a job and they said the next interview would be on codesignal.com. I did about 100 practice problems and I found myself reaching for D a lot. There were some problems where I pretty much had to go to C# if I wanted to do it in under 5 minutes (most things Linq related or string related. I don't know what D's equivalents are.)

You know D, you like D so it's natural that you would often reach for D to solve a problem. But the point of this thread is not that people who appreciate D can use it to do things, it's why the other people are not showing more interest in D.

>
> I don't think D needs to stick to one way to do everything. I think Python is popular almost in spite of it's one-way-only philosophy because it's easy to start and it has good libraries. (Although being easy to get started is probably helped by the one-way-only philosophy for reasons I get to below.) You get that constant success feedback where you write something and it works right away. Then you tweak it and get little wins along the way. D is similar except for some safety stuff that I have ideas about (immutable, const, etc.)

I think the fact that Python lives by its "one true way only" philosophy is precisely the reason it is so easy to get started with and has such good libraries. It's easy because tutorials make sense, if you are beginning and face a problem, other people can help you easily, and libraries provide APIs with little or no surprise and for the overwhelming part, they work well together. Perl, in contrast, said "there shall be more than one way to do it". Its ecosystem has always been a huge mess.

Now of course D doesn't need to stick to one way for absolutely everything, otherwise it would be a DSL which is obviously not its purpose. But it should at least have a clear and cogent memory management story (and not "you can do it absolutely every way you want and so can everyone else"). It should have a clear position on strings. Autodecoding was a bad idea and maybe it's now stuck with it, or maybe it's possible to introduce a new string type that doesn't autodecode and keep std.string for legacy code, but there should be The D Way of handling strings (and not "ok and you can also use pointers like in C, and by the way you can have an array of dchars" etc.). It should decide once and for all what its pointer aliasing and coercion rules are and not introduce a new function attribute every week on one hand and rely on hacks like "alias this" on the other. And then there is the tooling. D has dub but it's neither fully mature not universally used, which means that adding a 3rd party dependency to a project is much more of a chore than it needs to be (and should be).

>
> There are two effects I see where being opinionated is VERY helpful - maybe essential - to a language.
> 1. Documentation and tutorials
> Tutorials need to be opinionated. People need to see ONE way to do things when they learn. Once they understand, they can take advantage of all the different ways, but they need to see a path to success.
> 2. Whatever you expect people to do with the language, it needs to be designed so there is at LEAST one way to do the above things that is elegant. For example, web servers usually allow some kind of annotation-based routing system. If you use Jetty and you do your own routing, that is fairly confusing and time-consuming. That is something where the annotation-based method is a simple solution and allows you to not have to discuss much about routing and that part of the framework to a new user. It allows you to streamline. However, for Jetty (and technically others), you don't HAVE to do it that way. It's just the default way. Someone once said something like allow endless configuration but provide sensible defaults. That's what the D language is good at.
>
> I would like to read your response to this.

I've never personally used Jetty and admittedly web application development is not one of my areas of interest or expertise so I can't comment on that. On a more general level though, the notion of what is "elegant" is subjective. There should be at least one way that is idiomatic, well supported and proven to work for the proverbial 99% of the common cases. And if there is more than one way, then they should interoperate as easily as possible.