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!

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.

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.

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.

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.

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

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.

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.

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.

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.