www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - does D already have too many language features ?

reply adam77 <adamevans3217 gmail.com> writes:
Hello everyone,

I started using D as an alternative to Java, what attracted me to 
D was the robust memory management (including the way arrays are 
handled), and interoperability with C (specifically libraries) so 
far so good, but almost every language out there (maybe with the 
exception of C) seems the eschew language stability in favour of 
adopting whatever the latest fad is in programming languages 
features. I see on forums for a number of languages how features 
like lambda's or auto properties are essential to their language 
or if they are missing some feature how its a major detriment to 
the language. I sometimes wonder how a Turing machine could ever 
manage...

I'd be interested to hear other peoples opinion, does the 
language have enough features? is it already overloaded with 
features ?

Any help will be appreciated!
Apr 08
next sibling parent Cym13 <cpicard purrfect.fr> writes:
On Monday, 8 April 2019 at 09:46:06 UTC, adam77 wrote:
 Hello everyone,

 I started using D as an alternative to Java, what attracted me 
 to D was the robust memory management (including the way arrays 
 are handled), and interoperability with C (specifically 
 libraries) so far so good, but almost every language out there 
 (maybe with the exception of C) seems the eschew language 
 stability in favour of adopting whatever the latest fad is in 
 programming languages features. I see on forums for a number of 
 languages how features like lambda's or auto properties are 
 essential to their language or if they are missing some feature 
 how its a major detriment to the language. I sometimes wonder 
 how a Turing machine could ever manage...

 I'd be interested to hear other peoples opinion, does the 
 language have enough features? is it already overloaded with 
 features ?

 Any help will be appreciated!
From my point of view, yes, but that's not the end of the story. I come from python where there's a strong community incentive to have everyone use a similar style and lots of discussions are focused on what's "pythonic", ie what is "the best way" to solve a problem or write a piece of code. This is not how D should be approached. D is more akin to C++ where every feature ever is present (or will eventually be as more people advocate for more features). Not all of these features work well together, far from it. This means that, like in C++, you should define at the beginning of the project what style you want to use and what set of features you want to base your code on. Then mostly restrict yourself to those core features. That's why you see C-like D, code based mostly on classes and OOP, fiber based code, safe code, range code, mallocator code... I don't know how things are in java, but understanding and accepting that it is in my best interest to restrict my set of features was somewhat new to me. That said it also means that D can tackle most issues without ever needing to change language and that's nice too. So while I dislike cluttering the language with features I guess the issue is more in how I see it.
Apr 08
prev sibling next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Monday, 8 April 2019 at 09:46:06 UTC, adam77 wrote:
 Hello everyone,

 I started using D as an alternative to Java, what attracted me 
 to D was the robust memory management (including the way arrays 
 are handled), and interoperability with C (specifically 
 libraries) so far so good, but almost every language out there 
 (maybe with the exception of C) seems the eschew language 
 stability in favour of adopting whatever the latest fad is in 
 programming languages features. I see on forums for a number of 
 languages how features like lambda's or auto properties are 
 essential to their language or if they are missing some feature 
 how its a major detriment to the language. I sometimes wonder 
 how a Turing machine could ever manage...

 I'd be interested to hear other peoples opinion, does the 
 language have enough features? is it already overloaded with 
 features ?

 Any help will be appreciated!
I think it has too many features, but that's really easy to say in hindsight and without actually ever developing a language myself. It's also hard to agree on what we'd cut out even if we had the code-breaking chance (which we don't). I'd do away with classes and OOP, but to call that divisise would be an understatement.
Apr 08
next sibling parent bauss <jj_1337 live.dk> writes:
On Monday, 8 April 2019 at 11:22:49 UTC, Atila Neves wrote:
 On Monday, 8 April 2019 at 09:46:06 UTC, adam77 wrote:
 Hello everyone,

 I started using D as an alternative to Java, what attracted me 
 to D was the robust memory management (including the way 
 arrays are handled), and interoperability with C (specifically 
 libraries) so far so good, but almost every language out there 
 (maybe with the exception of C) seems the eschew language 
 stability in favour of adopting whatever the latest fad is in 
 programming languages features. I see on forums for a number 
 of languages how features like lambda's or auto properties are 
 essential to their language or if they are missing some 
 feature how its a major detriment to the language. I sometimes 
 wonder how a Turing machine could ever manage...

 I'd be interested to hear other peoples opinion, does the 
 language have enough features? is it already overloaded with 
 features ?

 Any help will be appreciated!
I think it has too many features, but that's really easy to say in hindsight and without actually ever developing a language myself. It's also hard to agree on what we'd cut out even if we had the code-breaking chance (which we don't). I'd do away with classes and OOP, but to call that divisise would be an understatement.
The good thing is that most of the features are optional which means you don't need to know or use the features. Even using external libraries that uses said features will work without you using the same features such as function attributes etc. You can easily call library code that is full of attributions without ever adding it into your code. Of course there are certain limitations but overall you can avoid them as much as you want.
Apr 08
prev sibling next sibling parent reply bpr <brogoff gmail.com> writes:
On Monday, 8 April 2019 at 11:22:49 UTC, Atila Neves wrote:
 I'd do away with classes and OOP,
That D is just a -betterC switch away. Of course that may be cutting out more than you want. FWIW I agree with you about D's classes and OOP, as well as the fact that it won't happen.
Apr 08
parent reply bauss <jj_1337 live.dk> writes:
On Monday, 8 April 2019 at 14:13:03 UTC, bpr wrote:
 On Monday, 8 April 2019 at 11:22:49 UTC, Atila Neves wrote:
 I'd do away with classes and OOP,
That D is just a -betterC switch away. Of course that may be cutting out more than you want. FWIW I agree with you about D's classes and OOP, as well as the fact that it won't happen.
I'm gonna come in and say I disagree with that though. It's a feature I use all the time. I rarely use anything "low-level".
Apr 08
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Apr 08, 2019 at 04:01:48PM +0000, bauss via Digitalmars-d wrote:
 On Monday, 8 April 2019 at 14:13:03 UTC, bpr wrote:
 On Monday, 8 April 2019 at 11:22:49 UTC, Atila Neves wrote:
 I'd do away with classes and OOP,
That D is just a -betterC switch away. Of course that may be cutting out more than you want. FWIW I agree with you about D's classes and OOP, as well as the fact that it won't happen.
I'm gonna come in and say I disagree with that though. It's a feature I use all the time. I rarely use anything "low-level".
This is the problem with the claim that D has "too many features". The problem is that everyone has a different subset of features that they consider essential, and what one considers superfluous another considers indispensible. So if we were to take this claim at face value, the only reasonable solution is to split D into multiple, mutually-incompatible dialects. Which means (each respective) D community will become even smaller and lacking in manpower than it already is, and it will just fall by the wayside and die off. A more reasonable viewpoint recognizes that programming is an inherently and irreducibly complex task, and one cannot expect to fill every need with only a small number of features. Every feature is a tool for a particular task, and it is nice to have the tool in your toolbox even if you think you'd never need it, because one day you just might, and then you'll be very grateful it's there. In the meantime, there's nothing wrong with having an extra tool or two in your toolbox. Just use what you need, and don't worry too much about the rest. T -- Marketing: the art of convincing people to pay for what they didn't need before which you fail to deliver after.
Apr 08
prev sibling parent bpr <brogoff gmail.com> writes:
On Monday, 8 April 2019 at 16:01:48 UTC, bauss wrote:
 On Monday, 8 April 2019 at 14:13:03 UTC, bpr wrote:
 On Monday, 8 April 2019 at 11:22:49 UTC, Atila Neves wrote:
 I'd do away with classes and OOP,
That D is just a -betterC switch away. Of course that may be cutting out more than you want. FWIW I agree with you about D's classes and OOP, as well as the fact that it won't happen.
I'm gonna come in and say I disagree with that though.
That's fine.
 It's a feature I use all the time.

 I rarely use anything "low-level".
If classes/OOP was something I used all the time, and I rarely used low level features, I'd use a different language than D (Java/Scala or C#) and reap the benefits of a better GC and larger community. I prefer the Lisp influenced "OO" designs (some will say they aren't OO) that have multimethods, like Clojure and Julia. I'm looking forward to all of this work that Mike Franklin is pushing for a "pay as you go" D, because for me, D's OO does not pull its weight.
Apr 08
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On Mon, Apr 8, 2019 at 4:25 AM Atila Neves via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Monday, 8 April 2019 at 09:46:06 UTC, adam77 wrote:
 Hello everyone,

 I started using D as an alternative to Java, what attracted me
 to D was the robust memory management (including the way arrays
 are handled), and interoperability with C (specifically
 libraries) so far so good, but almost every language out there
 (maybe with the exception of C) seems the eschew language
 stability in favour of adopting whatever the latest fad is in
 programming languages features. I see on forums for a number of
 languages how features like lambda's or auto properties are
 essential to their language or if they are missing some feature
 how its a major detriment to the language. I sometimes wonder
 how a Turing machine could ever manage...

 I'd be interested to hear other peoples opinion, does the
 language have enough features? is it already overloaded with
 features ?

 Any help will be appreciated!
I think it has too many features, but that's really easy to say in hindsight and without actually ever developing a language myself. It's also hard to agree on what we'd cut out even if we had the code-breaking chance (which we don't). I'd do away with classes and OOP, but to call that divisise would be an understatement.
That would eject me from the boat. That said, I think classes as a discreet feature might be unnecessary. classes could be removed if the language were able to express class semantics in a struct as a library. That's tricky as hell without ANY compiler support though. I can't imagine a way to add concepts like `virtual` and `override` as library. It would probably require AST macros.
Apr 08
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 8 April 2019 at 17:20:00 UTC, Manu wrote:
 

 That would eject me from the boat.
 That said, I think classes as a discreet feature might be 
 unnecessary.
 classes could be removed if the language were able to express 
 class
 semantics in a struct as a library. That's tricky as hell 
 without ANY
 compiler support though. I can't imagine a way to add concepts 
 like
 `virtual` and `override` as library. It would probably require 
 AST
 macros.
I think some people have discussed on the forums before about how AST macros could be used to implement this (after all, C++'s metaclass proposal could probably also be implemented with AST macros). However, even if AST macros might be used to implement OOP as a library, I think the burden of proof is on those in favor of library solutions to show that they can get similar performance, both run-time and compile-time, and quality of error messages as the current implementation. Another option would be to keep classes, but implement other OOP features like interface and abstract as libraries, with AST macros if needed. Perhaps less disruption.
Apr 08
parent reply Abdulhaq <alynch4047 gmail.com> writes:
On Monday, 8 April 2019 at 18:45:24 UTC, jmh530 wrote:
 I think some people have discussed on the forums before about 
 how AST macros could be used to implement this (after all, 
 C++'s metaclass proposal could probably also be implemented 
 with AST macros). However, even if AST macros might be used to 
 implement OOP as a library, I think the burden of proof is on 
 those in favor of library solutions to show that they can get 
 similar performance, both run-time and compile-time, and 
 quality of error messages as the current implementation.

 Another option would be to keep classes, but implement other 
 OOP features like interface
 and abstract as libraries, with AST macros if needed. Perhaps 
 less disruption.
The problem with AST macros, and Walter seems to agree with this POV, is that every medium to large project will have its own private language that ripples throughout the code. Only a few of the developers will really understand this new language and how it can safely be used and where its pitfalls are. It will be poorly documented and a nightmare for new developers. Anyone who has coded or had to maintain a medium-to-large lisp code base has experienced this. A similar problem occurs with languages like C++ and, if people are not careful, D too. An overly large language like C++ drives teams to choose their favoured subsets of features. These change over time and don't play well with libraries where other choices have been made. It's hard for new developers to pick up if their previous feature set was different.
Apr 08
next sibling parent reply bachmeier <no spam.net> writes:
On Monday, 8 April 2019 at 18:59:25 UTC, Abdulhaq wrote:
 On Monday, 8 April 2019 at 18:45:24 UTC, jmh530 wrote:
 I think some people have discussed on the forums before about 
 how AST macros could be used to implement this (after all, 
 C++'s metaclass proposal could probably also be implemented 
 with AST macros). However, even if AST macros might be used to 
 implement OOP as a library, I think the burden of proof is on 
 those in favor of library solutions to show that they can get 
 similar performance, both run-time and compile-time, and 
 quality of error messages as the current implementation.

 Another option would be to keep classes, but implement other 
 OOP features like interface
 and abstract as libraries, with AST macros if needed. Perhaps 
 less disruption.
The problem with AST macros, and Walter seems to agree with this POV, is that every medium to large project will have its own private language that ripples throughout the code. Only a few of the developers will really understand this new language and how it can safely be used and where its pitfalls are. It will be poorly documented and a nightmare for new developers.
That's a valid criticism. It's also odd coming from a language like D where "good code" is generic on steroids and extremely hard to work with. I've been using D for six years and still struggle to use Phobos at times.
Apr 08
next sibling parent bauss <jj_1337 live.dk> writes:
On Monday, 8 April 2019 at 22:49:10 UTC, bachmeier wrote:
 On Monday, 8 April 2019 at 18:59:25 UTC, Abdulhaq wrote:
 On Monday, 8 April 2019 at 18:45:24 UTC, jmh530 wrote:
 I think some people have discussed on the forums before about 
 how AST macros could be used to implement this (after all, 
 C++'s metaclass proposal could probably also be implemented 
 with AST macros). However, even if AST macros might be used 
 to implement OOP as a library, I think the burden of proof is 
 on those in favor of library solutions to show that they can 
 get similar performance, both run-time and compile-time, and 
 quality of error messages as the current implementation.

 Another option would be to keep classes, but implement other 
 OOP features like interface
 and abstract as libraries, with AST macros if needed. Perhaps 
 less disruption.
The problem with AST macros, and Walter seems to agree with this POV, is that every medium to large project will have its own private language that ripples throughout the code. Only a few of the developers will really understand this new language and how it can safely be used and where its pitfalls are. It will be poorly documented and a nightmare for new developers.
That's a valid criticism. It's also odd coming from a language like D where "good code" is generic on steroids and extremely hard to work with. I've been using D for six years and still struggle to use Phobos at times.
And ironically nothing is stopping one from creating a language within D anyway. You can basically just create a parser for your language and then omit D code into a mixin. Now that would be nasty and way worse than a custom language using AST macros; and that's possible using D now.
Apr 08
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 8 April 2019 at 22:49:10 UTC, bachmeier wrote:
 On Monday, 8 April 2019 at 18:59:25 UTC, Abdulhaq wrote:
 The problem with AST macros, and Walter seems to agree with 
 this POV, is that every medium to large project will have its 
 own private language that ripples throughout the code. Only a 
 few of the developers will really understand this new language 
 and how it can safely be used and where its pitfalls are. It 
 will be poorly documented and a nightmare for new developers.
That's a valid criticism. It's also odd coming from a language like D where "good code" is generic on steroids and extremely hard to work with. I've been using D for six years and still struggle to use Phobos at times.
It can be countered by culture. Python is very flexible in what you can do, yet there is a culture that gives preference to libraries that are somewhat consistent with the standard library. Anyway, AST macros should not be available on the "application layer", only on the "library layer". The real problem with AST macros is that you need a minimal base language that is really solid. And you cannot modify that base language after release. (you can do it in a later major version, but you cannot automatically upgrade library code written for the previous version) It would be a completely different philosophy to what you have now. It would be on the other side of the spectrum in some ways.
Apr 12
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Monday, 8 April 2019 at 18:59:25 UTC, Abdulhaq wrote:
 On Monday, 8 April 2019 at 18:45:24 UTC, jmh530 wrote:
 I think some people have discussed on the forums before about 
 how AST macros could be used to implement this (after all, 
 C++'s metaclass proposal could probably also be implemented 
 with AST macros). However, even if AST macros might be used to 
 implement OOP as a library, I think the burden of proof is on 
 those in favor of library solutions to show that they can get 
 similar performance, both run-time and compile-time, and 
 quality of error messages as the current implementation.

 Another option would be to keep classes, but implement other 
 OOP features like interface
 and abstract as libraries, with AST macros if needed. Perhaps 
 less disruption.
The problem with AST macros, and Walter seems to agree with this POV, is that every medium to large project will have its own private language that ripples throughout the code. Only a few of the developers will really understand this new language and how it can safely be used and where its pitfalls are. It will be poorly documented and a nightmare for new developers.
Every medium to large project in a language *without* AST macros already has its own private language that is poorly documented and only a few of the developers really understand. It's just that this DSL is in the syntax of the host language.
Apr 09
parent reply Abdulhaq <alynch4047 gmail.com> writes:
On Tuesday, 9 April 2019 at 11:39:33 UTC, Atila Neves wrote:
 On Monday, 8 April 2019 at 18:59:25 UTC, Abdulhaq wrote:
 On Monday, 8 April 2019 at 18:45:24 UTC, jmh530 wrote:
 The problem with AST macros, and Walter seems to agree with 
 this POV, is that every medium to large project will have its 
 own private language that ripples throughout the code. Only a 
 few of the developers will really understand this new language 
 and how it can safely be used and where its pitfalls are. It 
 will be poorly documented and a nightmare for new developers.
Every medium to large project in a language *without* AST macros already has its own private language that is poorly documented and only a few of the developers really understand. It's just that this DSL is in the syntax of the host language.
Yes, and writing those DSLs for that big project is often the most fun part. However, those DSLs are normally tucked away in a specific functional area, whereas when the developer can create AST macros, the DSL can do crazy stuff and can be present or even required in every source file. For instance, take the named parameters proposals. With AST macros each person can implement their own ideas. We could end up with one library having them one way, another library having them implemented a very different way with different behaviour. It would be very annoying if you wanted to use both libraries. Then multiply that by all the other unapproved DIPs.
Apr 09
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Apr 09, 2019 at 04:56:39PM +0000, Abdulhaq via Digitalmars-d wrote:
 On Tuesday, 9 April 2019 at 11:39:33 UTC, Atila Neves wrote:
 On Monday, 8 April 2019 at 18:59:25 UTC, Abdulhaq wrote:
 On Monday, 8 April 2019 at 18:45:24 UTC, jmh530 wrote:
[...]
 The problem with AST macros, and Walter seems to agree with this
 POV, is that every medium to large project will have its own
 private language that ripples throughout the code. Only a few of
 the developers will really understand this new language and how it
 can safely be used and where its pitfalls are. It will be poorly
 documented and a nightmare for new developers.
Every medium to large project in a language *without* AST macros already has its own private language that is poorly documented and only a few of the developers really understand. It's just that this DSL is in the syntax of the host language.
Yes, and writing those DSLs for that big project is often the most fun part. However, those DSLs are normally tucked away in a specific functional area, whereas when the developer can create AST macros, the DSL can do crazy stuff and can be present or even required in every source file. For instance, take the named parameters proposals. With AST macros each person can implement their own ideas. We could end up with one library having them one way, another library having them implemented a very different way with different behaviour. It would be very annoying if you wanted to use both libraries. Then multiply that by all the other unapproved DIPs.
[...] It's the Lisp Curse in effect: http://www.winestockwebdesign.com/Essays/Lisp_Curse.html tl;dr: when a language (or language feature) becomes overly powerful, what were challenging programming tasks turn into trivial one-night hacks. This initially sounds good, since you can get a lot done in very little time. However, the secondary effect is that everyone will cook their own, unique solution to the problem, and none of these solutions will be compatible with each other. Interfacing them with each other and with other components will get drowned in endless complexity caused by unexpected interactions, and nobody except the original author can maintain the code since nobody else understands it well enough. For example, if we were to get rid of classes and interfaces from D, because UDAs, DbI, compile-time introspection, and/or AST macros can easily replicate the same functionality, then in 5 years there will be 15 different implementations of OO as D libraries. Each will work very well as long as you only use that one implementation. But as soon as you try to integrate two libraries that use two different OO implementations, you're screwed, because they will be inherently incompatible with each other, and will have all sorts of corner cases and exceptional behaviours that make interoperability total hell for whoever dares attempt it. You'll end up wasting a ton of time writing shim code to convert from one OO library to another and back, and the host application will have a "fun" time dealing with two (or more) incompatible object types, rather than actually getting work done in your problem domain. Some things ought to be baked into the language, because that's where you define standard interfaces that everyone else follows, thus ensuring mutual compatibility between code written by different authors. T -- Let's call it an accidental feature. -- Larry Wall
Apr 09
parent FeepingCreature <feepingcreature gmail.com> writes:
On Tuesday, 9 April 2019 at 18:06:27 UTC, H. S. Teoh wrote:
 It's the Lisp Curse in effect:

 	http://www.winestockwebdesign.com/Essays/Lisp_Curse.html

 tl;dr: when a language (or language feature) becomes overly 
 powerful, what were challenging programming tasks turn into 
 trivial one-night hacks.  This initially sounds good, since you 
 can get a lot done in very little time.  However, the secondary 
 effect is that everyone will cook their own, unique solution to 
 the problem, and none of these solutions will be compatible 
 with each other. Interfacing them with each other and with 
 other components will get drowned in endless complexity caused 
 by unexpected interactions, and nobody except the original 
 author can maintain the code since nobody else understands it 
 well enough.

 For example, if we were to get rid of classes and interfaces 
 from D, because UDAs, DbI, compile-time introspection, and/or 
 AST macros can easily replicate the same functionality, then in 
 5 years there will be 15 different implementations of OO as D 
 libraries. Each will work very well as long as you only use 
 that one implementation.  But as soon as you try to integrate 
 two libraries that use two different OO implementations, you're 
 screwed, because they will be inherently incompatible with each 
 other, and will have all sorts of corner cases and exceptional 
 behaviours that make interoperability total hell for whoever 
 dares attempt it.
On the other hand, I bet at least one of those implementations would have working interface contracts ... ;) With language features, you're beholden to the quality and maintenance of the language. Macros are hard to debug and improve, but the alternative is that the feature lives in the frontend, which is possible the one thing that's harder. And of course, D compiler features already have problems interacting internally.
Apr 10
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Monday, 8 April 2019 at 17:20:00 UTC, Manu wrote:
 On Mon, Apr 8, 2019 at 4:25 AM Atila Neves via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:
 [...]
That would eject me from the boat. That said, I think classes as a discreet feature might be unnecessary. classes could be removed if the language were able to express class semantics in a struct as a library. That's tricky as hell without ANY compiler support though. I can't imagine a way to add concepts like `virtual` and `override` as library. It would probably require AST macros.
I wonder if virtual and override could be done with UDAs.
Apr 08
parent Manu <turkeyman gmail.com> writes:
On Mon, Apr 8, 2019 at 3:45 PM Atila Neves via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Monday, 8 April 2019 at 17:20:00 UTC, Manu wrote:
 On Mon, Apr 8, 2019 at 4:25 AM Atila Neves via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 [...]
That would eject me from the boat. That said, I think classes as a discreet feature might be unnecessary. classes could be removed if the language were able to express class semantics in a struct as a library. That's tricky as hell without ANY compiler support though. I can't imagine a way to add concepts like `virtual` and `override` as library. It would probably require AST macros.
I wonder if virtual and override could be done with UDAs.
Probably not without AST macros ;)
Apr 08
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2019-04-08 13:22, Atila Neves wrote:

 It's also hard to agree on what we'd cut out even if we had the 
 code-breaking chance (which we don't). I'd do away with classes and OOP, 
 but to call that divisise would be an understatement.
In my opinion quite a few highly specialized features that are far less used the can either be removed or generalized. For example, foreach_reverse. Do we really need that built into the language? Or the foreach range statement. The range part, i.e. 1..10, could be a literal for a numeric range that works everywhere and not just a special syntax that works in foreach statements and slices. -- /Jacob Carlborg
Apr 08
next sibling parent aliak <something something.com> writes:
On Monday, 8 April 2019 at 19:35:52 UTC, Jacob Carlborg wrote:
 On 2019-04-08 13:22, Atila Neves wrote:

 It's also hard to agree on what we'd cut out even if we had 
 the code-breaking chance (which we don't). I'd do away with 
 classes and OOP, but to call that divisise would be an 
 understatement.
In my opinion quite a few highly specialized features that are far less used the can either be removed or generalized. For example, foreach_reverse. Do we really need that built into the language? Or the foreach range statement. The range part, i.e. 1..10, could be a literal for a numeric range that works everywhere and not just a special syntax that works in foreach statements and slices.
It'd be really cool if dmd could generate a "usage report" and ask the user if it could send it off to some dlang-controlled server so we could gather statistics on which features are seen by the compiler.
Apr 08
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 8 April 2019 at 19:35:52 UTC, Jacob Carlborg wrote:
 [snip]
 The range part, i.e. 1..10, could be a literal for a numeric 
 range that works everywhere and not just a special syntax that 
 works in foreach statements and slices.
Numeric range literals are a nice feature in Matlab and some other languages for some tasks.
Apr 08
parent reply Jacob Carlborg <doob me.com> writes:
On 2019-04-08 22:42, jmh530 wrote:

 Numeric range literals are a nice feature in Matlab and some other 
 languages for some tasks.
Yeah, I like it too. But 1..10 could be a generic range type that can be used everywhere and the foreach statement would need a specialized syntax. -- /Jacob Carlborg
Apr 09
parent reply bauss <jj_1337 live.dk> writes:
On Tuesday, 9 April 2019 at 09:45:15 UTC, Jacob Carlborg wrote:
 On 2019-04-08 22:42, jmh530 wrote:

 Numeric range literals are a nice feature in Matlab and some 
 other languages for some tasks.
Yeah, I like it too. But 1..10 could be a generic range type that can be used everywhere and the foreach statement would need a specialized syntax.
Yep could be similar to Python's range. import std.stdio; struct RangeImpl(T) { T from; T to; bool reversed; property bool empty() { return reversed ? from == to : from >= to; } T front() { return from; } void popFront() { if (reversed) { from--; } else { from++; } } } auto range(T)(T from, T to) { return RangeImpl!T(from, to, from > to); } void main() { foreach (i; range(0, 10)) { writeln(i); } // Same as foreach_reverse foreach (i; range(10, 0)) { writeln(i); } } Output: 0 1 2 3 4 5 6 7 8 9 10 9 8 7 6 5 4 3 2 1
Apr 09
parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 9 April 2019 at 12:19:20 UTC, bauss wrote:
 

 Yep could be similar to Python's range.

 [snip]
Or... import std.range; import std.stdio : writeln; void main() { foreach (i; iota(10)) { writeln(i); } foreach (i; iota(10, 0, -1)) { writeln(i); } }
Apr 09
prev sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Monday, 8 April 2019 at 11:22:49 UTC, Atila Neves wrote:

 I'd do away with classes and OOP, but to call that divisive 
 would be an understatement.
Yeah it's a controversial one. I also would support removing classes and interfaces from the language, but *only* if they could be implemented in a library. Interestingly, as demonstrated here (https://theartofmachinery.com/2018/08/13/inheritance_and_polymorphism_2.html) it's almost there. Zig and Rust have shown that structs are enough of an object system. Pointers and `ref` are enough for reference type semantics. Mix in D's design by introspection(DbI) features, `alias this`, `mixin`s, etc. and we're 70% there. Due to DbI, interfaces could probably go away today. I'm looking forward to hearing the proposal around ProtoObject at DConf, but I would suggest looking for language features that would make ProtoObject unnecessary. Mike
Apr 08
parent Dennis <dkorpel gmail.com> writes:
On Monday, 8 April 2019 at 20:38:57 UTC, Mike Franklin wrote:
 Mix in D's design by introspection(DbI) features, `alias this`, 
 `mixin`s, etc. and we're 70% there. Due to DbI, interfaces 
 could probably go away today.
I don't buy the notion that D classes are ready to be deprecated, even ignoring code breakage and familiarity for C++ / C# / Java programmers. Alias this and mixin simply still feel too immature to me; whenever I'm casually trying to get some subtyping done and I always get stopped by bugs or design limitations (examples [1][2][3]). Looking at this page: https://tour.dlang.org/tour/en/gems/subtyping I always associated alias this with subtyping, and any violations of the Liskov substitution principle were bugs / design aspects to be ironed out. However, from the generality creep thread [4] it became clear that "alias this to an rvalue is not subtyping". "Odd" was Andrei's reaction. It's really hard to sell "classes are totally not needed in D, just use alias this for subtyping" when it's so complicated to reason about and it fails so often. I didn't expect myself to defend classes here since I avoid them if I can (mostly for memory efficiency), but I have to say their design and implementation are much more robust than template meta-programming currently. I like that D offers subtyping without everything being an Object, but I tend to see templates as a more low-level, somewhat experimental way that accompanies classes, not a replacement of classes. [1] https://forum.dlang.org/thread/ibordxozjckquanrskap forum.dlang.org [2] https://issues.dlang.org/show_bug.cgi?id=19365 [3] https://issues.dlang.org/show_bug.cgi?id=19476 [4] https://forum.dlang.org/post/q6plhj$1l9$1 digitalmars.com
Apr 08
prev sibling next sibling parent reply Alex <AJ gmail.com> writes:
On Monday, 8 April 2019 at 09:46:06 UTC, adam77 wrote:
 Hello everyone,

 I started using D as an alternative to Java, what attracted me 
 to D was the robust memory management (including the way arrays 
 are handled), and interoperability with C (specifically 
 libraries) so far so good, but almost every language out there 
 (maybe with the exception of C) seems the eschew language 
 stability in favour of adopting whatever the latest fad is in 
 programming languages features. I see on forums for a number of 
 languages how features like lambda's or auto properties are 
 essential to their language or if they are missing some feature 
 how its a major detriment to the language. I sometimes wonder 
 how a Turing machine could ever manage...

 I'd be interested to hear other peoples opinion, does the 
 language have enough features? is it already overloaded with 
 features ?

 Any help will be appreciated!
What you believe is nonsense. For one a Turing machine is a mathematical abstraction. It doesn't have to be convenient nor expressive. The whole point of features is to reduce complexity. All these abstractions are to make manage complex problems. If they simply were to complicate things then we would all still program on punch cards. 1. No one is requiring you to use any language feature. You can program in assembly in D if you want, so you have that choice. It's true that the library does use some extended language features, but you don't have to use the library either. 2. Language features exist precisely to make certain types of problems easier to comprehend and easier to solve. If you never face those problems then you won't understand why those features were implemented. 3. Maybe the problem is that you yourself lack the intelligence to understand the features enough to understand why they exist? What is more likely, that you are you know what is best for programmers or people who have programmed 100x as much as you in far more complex situations knows more? This is not a personal attack, just a fact. Serious, for you to say that X is useless requires that you have some higher intellectual standing than those that say it is useful. Else it is far more likely that you cannot comprehend it's usefulness because you haven't learned/experienced enough about it. After all, there are billions of people that think programming is useless and they don't touch it but I'm sure you would disagree with it. If we use your logic then it means their opinion is actually valid. Imagine if the world was run that way? We'd still be living in caves. A person that doesn't have extensive knowledge of something can't possibly understand the use of that knowledge. It's moronic and ridiculous to think it is possible. It's like a person blind from birth claiming they understand sight more than someone that can see. 5. More features allows one to have more options to solve a problem. What if you had to program using punch cards abut you knew there was a better way to do it, would you be happy? Would you be content knowing that a problem that would take you 5 mins in D would take you 5 years using punch cards? It's ALWAYS better to have more options than less, assuming everything else is equal. Why? Because who says you have to use those options? That is why they are called options. 6. Make sure you are not coping out on learning how to actually program. Is it that these features really just confuse you and so instead of having to learn them you rather they just disappear? 7. No feature is *necessary*. We could all program in binary. Features exist SOLELY to abstract. If a problem can't be solved in binary then it can't be solved with any features on top because everything goes compiled down to binary at some point in some way. What it sounds like to me is that you are saying "I'm confused by all these gadgets and so I think they are not necessary". If you spend a 10th of the time actually learning why these things are useful and how they are used you will actually realize how important they are. Your argument is no different than someone coming in and saying "I think we should program with punch cards because is a compiler is just a bunch of fancy pancy stuff that we don't need". Really, you are saying that wether you realize it or not. How many programming languages have you used? See, 8. Language features have nothing to do with stability. The features themselves do not make a compiler stable or less stable. True that they correlate but that has nothing to do with language features but the quality of the programmers that implement them. So your argument is moronic: meaning you do not understand enough about programming to realize your argument makes no sense. I'm not trying to offend you, I'm trying to get you to realize you don't understand as much as you think about programming and so the gaps in your reasoning are due to your ignorance(it is the same for everyone, not just you, but the problem you posted here is a problem of your ignorance in programming and so the only solution is to be honest with you about it). The only way to help you is to try to convince you to actually learn these features. Meta programming in D is AMAZING. It is light years ahead of most other compilers and it can turn a complex problem in to a few lines of code. The compiler implementation itself is not amazing and the grammar is not amazing, but the "options" that it gives a person is amazing. No other compiler comes close to having all these capabilities to be used. Some functional languages such as Haskell are better in some ways but they lack in others. D is a good balance of providing superior "features" to procedural programming and there is no other language out there that compares(some are popping up though and C++ is taking a lot of D's ideas). If you learn these features you will become a better programmer and understand what it's all about and be more informed to understand. You cannot possibly judge something intelligently that you don't understand. It makes no sense to do so. What you are looking for is someone to prove to you why they are important so you can learn them and if they can't you will justify to yourself not spending the time to learn them... unfortunately that is not how life works. You must learn these things, have some faith they are useful since they obviously are rather popular, and then you will add the tools to your bag and eventually you will be able to properly use them. If, for example, I give a hammer(or say fire) to a money in the jungle, they will take it, bang it around a little then toss the hammer thinking it utterly useless. They don't give themselves time to learn how to use it and what it is useful for. This is why we force children to learn by going to school, because it is biological to not do something that one believes to be useless. Remember, no one is forcing you to learn these features... it's up to you to decide if you want to broaden your programming kung fu. What you will find in the D community(besides a few assholes) is virtually everyone here loves D for it's language features. I imagine the reason you are coming to D is because you actually are ready to learn new things in programming(sort of the universes way of guiding you). The more you fight though the more difficult it will be. There are several good "books" about D. I suggest you read them and familiarize your self with how D works by those who use it and it will get you far more up to speed then trying to program D like you do Java. And, BTW, D might not be the language for you... but you ultimately won't know until you actually learn it enough to make a truly informed decision. Ultimately you have to take a gamble. Personally, I might suggest you go learn Haskell. Or better, you could learn both. Every language will have it's pro's and con's. Language features are never a con.
Apr 08
next sibling parent reply Julian <julian.fondren gmail.com> writes:
On Monday, 8 April 2019 at 21:52:37 UTC, Alex wrote:
 Personally, I might suggest you go learn Haskell.
I would interpret this as a request to take a long walk on a short pier. It probably depends on the receiver's feelings for Haskell.
 Or better, you could learn both. Every language will have it's 
 pro's and con's. Language features are never a con.
Some examples of cons: - Perl's Java-style new. Never used in favor of ->new(), but since it's in the language we have this top-voted SO question: https://stackoverflow.com/questions/11695110/why-is-this-program-valid-i-was-trying-to-create-a-syntax-error - Perl's single-quote "dot syntax". Never used in favor of ::, but since it's in the language you have to escape single quotes in cases like "$who's" so that doesn't look like an invocation of an 's' method. - Perl's interpolation of arrays into strings. Almost never used deliberately, but since it's in the language you have to escape email addresses in strings. - Perl's scalar/list context system. It's super cute, and it also means that blah("hi") either returns "hi" or "ih" ... depending on the call. sub blah { my $x = shift; reverse($x) } It's not all Perl, but the more common 'con' is a feature that opens a window while closing a hallway of doors for a language's future development.
Apr 08
parent Alex <AJ gmail.com> writes:
On Monday, 8 April 2019 at 22:15:52 UTC, Julian wrote:
 On Monday, 8 April 2019 at 21:52:37 UTC, Alex wrote:
 Personally, I might suggest you go learn Haskell.
I would interpret this as a request to take a long walk on a short pier. It probably depends on the receiver's feelings for Haskell.
lol, ok. Well. Again, one can't make an informed decision about something without being informed. Even if one doesn't like something they can learn from it. People are so controlling of their time that they do more harm than good. Much of what Haskell does is the same as what D does. Haskell does typing far better(since it is formally based off of category theory and so deals with higher levels of typing that D doesn't even come close to). Haskell has it's own problems of course... but how do you know this stuff if you don't use it?
 Or better, you could learn both. Every language will have it's 
 pro's and con's. Language features are never a con.
Some examples of cons: - Perl's Java-style new. Never used in favor of ->new(), but since it's in the language we have this top-voted SO question: https://stackoverflow.com/questions/11695110/why-is-this-program-valid-i-was-trying-to-create-a-syntax-error - Perl's single-quote "dot syntax". Never used in favor of ::, but since it's in the language you have to escape single quotes in cases like "$who's" so that doesn't look like an invocation of an 's' method. - Perl's interpolation of arrays into strings. Almost never used deliberately, but since it's in the language you have to escape email addresses in strings. - Perl's scalar/list context system. It's super cute, and it also means that blah("hi") either returns "hi" or "ih" ... depending on the call. sub blah { my $x = shift; reverse($x) } It's not all Perl, but the more common 'con' is a feature that opens a window while closing a hallway of doors for a language's future development.
These are not language features but language design choices. There is a huge difference. The only con to a language feature is that if one person doesn't like it and reads someone else's code that does then they will not like the code. Again, if you have the option not to use it then you are not forced to use it(except he case just cited). The only language feature that is bad is the language feature you want but don't have. Language features are independent of grammatical construction/syntax. (any syntax can be given to a language feature to do something, it doesn't change what the language feature is, which is an abstract pattern to simplify work) Remember, Language features add something on top of something else. If they take something else away in the process they are not language features. They are not providing an option but a mutation. This is how language features work: class LanguageFeature : Language in essence, meaning that one can always use the base "class" to do their work in. It it doesn't work this way then it is not a feature. [Of course, it is true that in implementation of the feature it can cause problems, but that is not a problem of the feature itself but the implementation]
Apr 09
prev sibling parent reply Dennis <dkorpel gmail.com> writes:
On Monday, 8 April 2019 at 21:52:37 UTC, Alex wrote:
 3. Maybe the problem is that you yourself lack the intelligence 
 to understand the features enough to understand why they exist? 
 What is more likely, that you are you know what is best for 
 programmers or people who have programmed 100x as much as you 
 in far more complex situations knows more? This is not a 
 personal attack, just a fact. Serious, for you to say that X is 
 useless requires that you have some higher intellectual 
 standing than those that say it is useful. Else it is far more 
 likely that you cannot comprehend it's usefulness because you 
 haven't learned/experienced enough about it.
Please don't use such a hostile tone, it was just a question. There's no need to question the level of intelligence or experience of anyone.
Apr 08
next sibling parent Dennis <dkorpel gmail.com> writes:
On Tuesday, 9 April 2019 at 19:08:55 UTC, Alex wrote:
 Don't be an idiot trying to cause problems.
Thanks for that hilariously over the top reaction, it brightened my day a little. :) You seem very frustrated lately, I wish I could brighten your day too but I don't think there's anything I can say that won't trigger an angry reaction, so I'll stop engaging.
Apr 09
prev sibling parent Jordan Wilson <wilsonjord gmail.com> writes:
 You have taken a statement and warped it's intention through 
 your own myopic closed minded filters and decided it meant 
 something that it didn't mean, that is your ignorance.
He did not interpret as your post the way he has because he is myopic, closed minded, trying to pervert the truth, is a moron, or has a low IQ. He interpreted your post the way he has because that's how it naturally reads: questioning the OP intelligence level and experience, with a slightly hostile tone. You've explained it wasn't hostile, that you were trying to help the OP. Great. Confusion cleared. Jordan
Apr 09
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 8 April 2019 at 09:46:06 UTC, adam77 wrote:
 but almost every language out there (maybe with the exception 
 of C)
C adds a lot of features on a regular basis too. But no, D doesn't have too many language features. Each one is useful for some case and what makes D so nice is that it is useful for so many cases.
Apr 09
prev sibling next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
On Monday, 8 April 2019 at 09:46:06 UTC, adam77 wrote:
 I'd be interested to hear other peoples opinion, does the 
 language have enough features? is it already overloaded with 
 features ?
D is a general-purpose, multi-paradigm programming language. As such it must have "too many features" - to low-level programmers GC, OO, and related is most likely "too much". For high-level developers focused on enterprise services and applications on the other hand GC and OO are natural choice... What I really find as an annoying problem is that almost all D features are half-baked...
Apr 11
parent reply bpr <brogoff gmail.com> writes:
On Thursday, 11 April 2019 at 12:09:10 UTC, Dejan Lekic wrote:
 On Monday, 8 April 2019 at 09:46:06 UTC, adam77 wrote:
 I'd be interested to hear other peoples opinion, does the 
 language have enough features? is it already overloaded with 
 features ?
D is a general-purpose, multi-paradigm programming language.
Perhaps that's a problem. It's difficult to serve many masters, and serve them all exceedingly well.
 As such it must have "too many features" - to low-level 
 programmers GC, OO, and related is most likely "too much".
That's how I see it too. When I wear my "low level programmer" hat, I want something like DasBetterC, perhaps a bit more, but maybe with Rustish safety guarantees.
 For high-level developers focused on enterprise services and 
 applications on the other hand GC and OO are natural choice...
I don't work in that domain, but in, say, data science I'd prefer something like Julia, with GC and multimethods.
 What I really find as an annoying problem is that almost all D 
 features are half-baked...
That could, at least partly, be a consequence of trying to do too many things.
Apr 11
parent reply Andre Pany <andre s-e-a-p.de> writes:
On Thursday, 11 April 2019 at 13:27:49 UTC, bpr wrote:
 On Thursday, 11 April 2019 at 12:09:10 UTC, Dejan Lekic wrote:
 [...]
Perhaps that's a problem. It's difficult to serve many masters, and serve them all exceedingly well.
 [...]
That's how I see it too. When I wear my "low level programmer" hat, I want something like DasBetterC, perhaps a bit more, but maybe with Rustish safety guarantees.
 [...]
I don't work in that domain, but in, say, data science I'd prefer something like Julia, with GC and multimethods.
 [...]
That could, at least partly, be a consequence of trying to do too many things.
Do you know this science project https://github.com/biod? The develops really like the D Programming Language. (https://github.com/biod/sambamba/issues/389#issuecomment-468475615) Kind regards Andre
Apr 11
parent bpr <brogoff gmail.com> writes:
On Thursday, 11 April 2019 at 14:18:16 UTC, Andre Pany wrote:
 Do you know this science project https://github.com/biod? The 
 develops really like the D Programming Language. 
 (https://github.com/biod/sambamba/issues/389#issuecomment-468475615)
I do now, thanks. You should be aware that there are similar projects, not just in bioinformatics, where Rust is the language of choice. That doesn't make me think Rust is well suited for data science. As I said earlier, I now think of Julia as my preferred language for that set of tasks; that was the focus of its design. My sense is that D was originally going to be a better C++ but that that didn't pan out for a number of reasons. Of the current alternatives to C++, Rust appears to have the most traction and momentum, but is still a very long ways from being a serious competitor. Now that there seems to be a desire from on high to revisit some D issues and change things, maybe D will gain in popularity, but for what I would use D for, fewer features would make a better language IMO.
Apr 11
prev sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
Put simply: The question itself is flawed.

A language is a workshop.

Not having a helpful tool (feature) is a big problem: it makes 
accomplishing a task more complicated/difficult/time-consuming than 
necessary.

But conversely, having an unhelpful tool (feature) available isn't much 
of a problem: (With apologies to Kondo-san ;) ), sure it may take up a 
little extra space, or leave people scratching their heads when they see 
it and then simply don't use it. But that's all very minor as far as 
problems go.

Just because you have a drill press sitting in the corner collecting 
dust doesn't mean it's hindering your ability to work. Of course, if 
people keep tripping over it, or over some other unhelpful tool (or 
feature), then sure that's a problem, and the ideal thing to do is get 
rid of the misfeature (or to simply redesign it if it IS still useful 
but dangerous, unwieldily or otherwise problematic).

In any case, the idea that there's a roughly ideal number of features 
(tools) for a language (workshop) is just not a very meaningful concept 
- that's just looking at things the wrong way. What matters is the 
features themselves, whether anything helpful is missing (ie, a 
problem), and whether anything else is causing a problem.
Apr 11
next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 4/11/19 2:45 PM, Nick Sabalausky (Abscissa) wrote:
 Put simply: The question itself is flawed.
 
 A language is a workshop.
 
Another way to look at it: English has all sorts of words that are rarely, if ever, used. But does anybody really complain that English has too many words? No. Does the presence of all those extra unused words get in the way of millions of people successfully using the language to communicate ideas on a daily basis? No. Certainly there ARE things that hinder effective communication through English. Problems such as ambiguity, overly-weak definitions, or LACKING sufficient words for an idea being expressed. But English's toolbox (vocabulary) being too full isn't really such a big problem.
Apr 11
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Apr 11, 2019 at 03:00:44PM -0400, Nick Sabalausky (Abscissa) via
Digitalmars-d wrote:
 On 4/11/19 2:45 PM, Nick Sabalausky (Abscissa) wrote:
 Put simply: The question itself is flawed.
 
 A language is a workshop.
 
Another way to look at it: English has all sorts of words that are rarely, if ever, used. But does anybody really complain that English has too many words? No.
Second-language learners would object, but OK, I get your point. :-P
 Does the presence of all those extra unused words get in the way of
 millions of people successfully using the language to communicate
 ideas on a daily basis? No.
Exactly, there's a core of ideas that need to be communicated, and a language needs to have at least that set of basic vocabulary in order to be useful. One could argue that that's all that's needed -- if you're going for language minimalism. OTOH, having a way to express more advanced concepts beyond that basic vocabulary comes in handy when you need to accomplish more advanced tasks. Sure, any old Turing-complete language is in theory sufficient to express any conceivable computation, but the question is how effectively it can be used to communicate the ideas pertaining to that computation. I wouldn't want to write a GUI app in lambda calculus, for example. But how much to include and what to exclude is a complex question that, AFAICT, has no simple answer. Therein lies the rub. Personally, I see a programming language as a kind of (highly) non-linear, vector-space-like thing. You have the vast space of computations, and you need to find the "basis vectors" that can span this space (primitives that can express any conceivable computation). There are many possible such basis sets, but some are easier for humans to work with than others. Theoretically, as long as the set is Turing complete, that's good enough. However, amid the vast space of all possible computations, some computations are more frequently needed than others, and thus, in the ideal case, your basis set should be optimized for this frequently-used subspace of computations (without compromising the ability to span the entire space). However, this is a highly non-trivial optimization problem, esp. because this is a highly non-linear space. And one that not everyone will agree on, because the subset of computations that each person may want to span will likely differ from person to person. Finding a suitable compromise that works for most people (ideally all, but I'm not holding my breath for that one) is an extremely hard problem.
 Certainly there ARE things that hinder effective communication through
 English. Problems such as ambiguity, overly-weak definitions, or
 LACKING sufficient words for an idea being expressed. But English's
 toolbox (vocabulary) being too full isn't really such a big problem.
Actually, natural language is surprisingly facile, expressive, and efficient at every day conversations, because it's built upon the human brain's exceptional ability to extract patterns (sometimes even where there aren't any :-P) and infer meaning implied from context -- the latter being something programming languages are still very poor at. Even when a language doesn't have adequate words to express something, it's often possible to find paraphrases that can. Which, if it becomes widespread, can become incorporated into the language along with everything else. Where natural language falls down is when pressed into service for something it arguably wasn't designed for: precise technicalities, such as needed in math and computing, or in law. T -- Mediocrity has been pushed to extremes.
Apr 11
next sibling parent reply Julian <julian.fondren gmail.com> writes:
On Thursday, 11 April 2019 at 20:41:00 UTC, H. S. Teoh wrote:
 On Thu, Apr 11, 2019 at 03:00:44PM -0400, Nick Sabalausky
 English has all sorts of words that are rarely, if ever, used. 
 But does anybody really complain that English has too many 
 words? No.
Second-language learners would object, but OK, I get your point. :-P
My received wisdom from language school: - there are five categories of language difficulty - Spanish is an example Cat II language, so not that hard at all. You can be competent in it in less than a half a year of study. - Chinese is an example Cat IV language. For obvious reasons. - Korean is an example Cat V language. For this reason: Koreans speak really fast. Even though the language might intrinsically have learning advantages over Chinese, as practiced by Koreans, it's harder to be competent in it. - English is the only other Cat V language. Because of the unparalleled vocabulary bloat, it's extremely hard to present yourself as a competent speaker. Rather than hear that more features is axiomatically good, I'd like to hear that D's actual featureset is good. And from the opposite side I'd rather "this feature right here is too much for this reason". If it's just a battle of impressions, then yes I very quickly got the impression that D has tons of features. That was solidified when I tried a JS-style lambda and it worked(!) and then I couldn't even find any documentation showing that it *should* work. So, might this tend to make randomly-selected D code harder to understand, because it has the potential to use all these features that you then have to know about? Sure. It follows that D *should* be harder to read than a language with less features that other people's code could possibly exhibit. Do I get the impression that D is actually harder to read, though? Not yet. That's a feat of language design -- that even though there are many pieces, they fit together well enough that you focus on the whole rather than the parts. Bad example: it's easy to think of an esolang that's enormously simpler than D, but with code you'd have a much harder time having to understand than typical D code.
Apr 11
parent reply JN <666total wp.pl> writes:
On Thursday, 11 April 2019 at 22:21:30 UTC, Julian wrote:
 Do I get the impression that D is actually harder to read, 
 though?
 Not yet. That's a feat of language design -- that even though 
 there
 are many pieces, they fit together well enough that you focus on
 the whole rather than the parts. Bad example: it's easy to 
 think of
 an esolang that's enormously simpler than D, but with code you'd
 have a much harder time having to understand than typical D 
 code.
For me the toughest part of D is dealing with heavily templated code. Documentation often uses auto for those. Unfortunately IDEs don't always help with templates, so often I am stuck with an object and I don't even know what is the type of it and what I can do for it. Without example code, I am usually stuck. Also, many routines return something like Result!(Foo, Bar). In these cases it's recommended to use auto, which is OK for local variables, but if you want to pass the result to some other function - good luck figuring out what is the actual type of the variable so that you can declare it in the function parameters list.
Apr 14
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Apr 14, 2019 at 08:14:17PM +0000, JN via Digitalmars-d wrote:
[...]
 For me the toughest part of D is dealing with heavily templated code.
 Documentation often uses auto for those. Unfortunately IDEs don't
 always help with templates, so often I am stuck with an object and I
 don't even know what is the type of it and what I can do for it.
 Without example code, I am usually stuck. Also, many routines return
 something like Result!(Foo, Bar). In these cases it's recommended to
 use auto, which is OK for local variables, but if you want to pass the
 result to some other function - good luck figuring out what is the
 actual type of the variable so that you can declare it in the function
 parameters list.
There's no need to declare it yourself. Just use: alias MyType = typeof(someFunc(a,b,c)); MyType x; ... x = someFunc(a,b,c); Most of the time, when the return type is something like Result!(...), usually the intent is that user code *shouldn't* depend on the concrete type, because it may arbitrarily change between library versions. Using typeof() ensures that it won't break if the return type does change. T -- Some days you win; most days you lose.
Apr 14
prev sibling next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 4/11/19 4:41 PM, H. S. Teoh wrote:
 On Thu, Apr 11, 2019 at 03:00:44PM -0400, Nick Sabalausky (Abscissa) via
Digitalmars-d wrote:
 On 4/11/19 2:45 PM, Nick Sabalausky (Abscissa) wrote:
 Put simply: The question itself is flawed.

 A language is a workshop.
Another way to look at it: English has all sorts of words that are rarely, if ever, used. But does anybody really complain that English has too many words? No.
Second-language learners would object, but OK, I get your point. :-P
Ha ha, true, good point :). But I'd say that applies to ANY non-primary human-to-human language. There's other languages I've tried to learn - Turns out, I'm *HORRIBLE* at both memorization in general and at learning human-only languages. With the one-two combo of both great personal effort and great personal interest, I've managed to pick up a TINY bit of "nihongo" (which I take FAR too much pride in given the miniscule extent of my still sub-fluent ability). Much as I like to pride myself on ability to learn computer languages, I'm completely convinced I would NEVER have been able to gain any level of fluency in English if I hadn't been born into an English-speaking culture. Seriously, you don't even know how much respect and admiration I have for the ESL crowd - those folks who actually manage to learn any functional amount of this completely insane, nonsensical, absolutely ridiculous language as a secondary language. To me, the biggest real-world "superheroes"/"superpowers" are the bilingual/multilingual folk, no doubt about it. Seriously, I feel like I outright *CHEATED* by being born into an English-speaking culture!!!
 Does the presence of all those extra unused words get in the way of
 millions of people successfully using the language to communicate
 ideas on a daily basis? No.
Exactly, there's a core of ideas that need to be communicated, and a language needs to have at least that set of basic vocabulary in order to be useful. One could argue that that's all that's needed -- if you're going for language minimalism. OTOH, having a way to express more advanced concepts beyond that basic vocabulary comes in handy when you need to accomplish more advanced tasks.
Yup! Two basic truths are relevant here: A: Possessing a tool doesn't mean you have to use it, or even know how to use it. But lacking a tool GUARANTEES that you CAN'T use it. B: Problems have inherent complexity. This complexity can either be abstracted away by your language (or lib) or manifest in your code - your choice.
 Sure, any old Turing-complete
 language is in theory sufficient to express any conceivable computation,
 but the question is how effectively it can be used to communicate the
 ideas pertaining to that computation.  I wouldn't want to write a GUI
 app in lambda calculus, for example.
Actually, I find even that to give Turing-completeness FAR too much credit... A true Turing machine is incapable of O(1) random-access. A Turing machine's random-access is inherently O(n). Even worse, a Turing machine is also incapable of ANYTHING less than O(n) for random-access. But real-world computing machines (arguably) ARE capable of O(1) random-access. Or at the *very least*, accounting for cache effects and such, real-world machines are *at least* capable of better-than-O(n) random-access, which is clearly far beyond the capabilities of a pure Turing machine. Seriously, I'm convinced *all* CS students should be absolutely REQUIRED to take a mandatory course of "CS nnn: Everything Turing-Completeness Does **NOT** Imply". I've come across FAAAARRRR TOO MANY otherwise well-educated sheeple who erroneously seem to equate "Turing-completeness" with "Real-world computer capabilities", and that is just...patently...NOT...TRUE!!! The truth is that "Turing complete" (much like the incredibly misleading LR-parsing literature) is *purely* focused on "Can this be computed AT ALL?" and has ZERO relationship to anything else that actually matters *IN REALITY*, such as algorithmic complexity (ie, big-O) and anything relating to the practical usefulness of the resulting data. But...no CS student in the world seems to know *ANY* of this. Shame. For SHAME...
 
 But how much to include and what to exclude is a complex question that,
 AFAICT, has no simple answer.  Therein lies the rub.
 
 Personally, I see a programming language as a kind of (highly)
 non-linear, vector-space-like thing.  You have the vast space of
 computations, and you need to find the "basis vectors" that can span
 this space (primitives that can express any conceivable computation).
 There are many possible such basis sets, but some are easier for humans
 to work with than others.  Theoretically, as long as the set is Turing
 complete, that's good enough.  However, amid the vast space of all
 possible computations, some computations are more frequently needed than
 others, and thus, in the ideal case, your basis set should be optimized
 for this frequently-used subspace of computations (without compromising
 the ability to span the entire space).  However, this is a highly
 non-trivial optimization problem, esp. because this is a highly
 non-linear space.  And one that not everyone will agree on, because the
 subset of computations that each person may want to span will likely
 differ from person to person.  Finding a suitable compromise that works
 for most people (ideally all, but I'm not holding my breath for that
 one) is an extremely hard problem.
 
These are interesting ideas. I'll have to give them more thought...
 
 Certainly there ARE things that hinder effective communication through
 English. Problems such as ambiguity, overly-weak definitions, or
 LACKING sufficient words for an idea being expressed. But English's
 toolbox (vocabulary) being too full isn't really such a big problem.
Actually, natural language is surprisingly facile, expressive, and efficient at every day conversations, because it's built upon the human brain's exceptional ability to extract patterns (sometimes even where there aren't any :-P) and infer meaning implied from context -- the latter being something programming languages are still very poor at. Even when a language doesn't have adequate words to express something, it's often possible to find paraphrases that can. Which, if it becomes widespread, can become incorporated into the language along with everything else.
Excellent points...Frankly, I'm going to have to re-read all of this after some sleep...
Apr 13
parent Abdulhaq <alynch4047 gmail.com> writes:
On Sunday, 14 April 2019 at 06:01:23 UTC, Nick Sabalausky 
(Abscissa) wrote:

 Yup! Two basic truths are relevant here:

 A: Possessing a tool doesn't mean you have to use it, or even 
 know how to use it. But lacking a tool GUARANTEES that you 
 CAN'T use it.
When we're talking about *using* features in a clean mature language with orthogonal features then yes, the language user really can take them or leave them. But on the language compiler side, when a feature needs changing or extending, or a new feature needs to be added, then the compiler engineer has to consider every existent feature, geometrically combined with n other features, in who knows how many possible contexts, and convince herself that they can all be made to continue to work the way the language user expects. As the number of existent features goes up, the difficulty of this process grows at least geometrically, and you end up with a situation where very few people have the skill, intelligence, time and inclination to do the work and continue to maintain it. Ultimately it could even reach a point where making it 'whole' is practically impossible (I'm in no way referring to D here, just recognising the risk to uncontained feature growth).
 B: Problems have inherent complexity. This complexity can 
 either be abstracted away by your language (or lib) or manifest 
 in your code - your choice.
Apr 14
prev sibling parent Abdulhaq <alynch4047 gmail.com> writes:
On Thursday, 11 April 2019 at 20:41:00 UTC, H. S. Teoh wrote:
 On Thu, Apr 11, 2019 at 03:00:44PM -0400, Nick Sabalausky
 Personally, I see a programming language as a kind of (highly) 
 non-linear, vector-space-like thing.  You have the vast space 
 of computations, and you need to find the "basis vectors" that 
 can span this space (primitives that can express any 
 conceivable computation).
It's a good analogy and actually I think a lot of people think like this even if they are not familiar with the mathematics. For instance, it's common to think of features being 'orthogonal' and finding difficult 'corner cases'. I do strongly feel that the more features / dimensions / basis vectors that there are, the more corner cases there are - and perhaps the number goes up exponentially.
Apr 14
prev sibling parent Dennis <dkorpel gmail.com> writes:
On Thursday, 11 April 2019 at 18:45:48 UTC, Nick Sabalausky 
(Abscissa) wrote:
 Put simply: The question itself is flawed.
Allow me to alter the question then: Are D's features too situational / not orthogonal enough? Take for example these D features: -debug() statement -version() statement -if statement -static if statement -ternary operator (condition ? iftrue : iffalse) Now take the language Zig, which has just if. The if-statement there is also an expression, and together with lazy evaluation it spans an area covering those 5 D-features and more. Add first-class types, and you have generics (no need for templates, is-expressions, traits). Add a bottom type (`noreturn`) and you won't need a no-return pragma and special assert(0) semantics. Things like 'break' can be an expression too now. Zig may not be as expressive as D, but it gets its expressiveness from just a few rules. Having many features available doesn't mean you actually 'span many dimensions', since features can be restricted. Reading the recent __mutable proposal: "__mutable can only be applied to private, mutable members." [1] This is more special logic in the language, indicating __mutable is another situational feature instead of a flexible mechanism that can be combined with the rest of the language, creating another 'dimension'. Of course there's rationale; it's introduced to tackle a specific problem, and I don't have a better suggestion either. I'm afraid however that a stream of new situational features leads D down the same path as C++, just a few kilometers behind because C++ had a head start. Other examples of non-orthogonal features in D are: - foreach ranges (0..10) and switch case ranges (for general number ranges you need Phobos) - int notInitialized = void; (special case, doesn't follow at all from the type-system) - the many lexical constructs (3 comment types, I don't know how many string literals) I'm not saying D is bad per se for having more features than necessary, and I do think version() and debug() have merit over if-statements. But lots of features with own rules and special casings aren't necessary to have a versatile toolbox. In conclusion I don't agree with the 'bigger toolbox is better, just pick what you need' notion, even ignoring implementation costs. [1] https://github.com/RazvanN7/DIPs/blob/Mutable_Dip/DIPs/DIP1xxx-rn.md
Apr 14