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.

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

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.

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

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.

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.

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

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.

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.

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.