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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 

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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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, 

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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
next sibling 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 2019
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 2019
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 2019
prev sibling parent reply Paul <paultjeadriaanse gmail.com> writes:
On Thursday, 11 April 2019 at 12:09:10 UTC, Dejan Lekic wrote:

 What I really find as an annoying problem is that almost all D 
 features are half-baked...


I'm curious what you mean with half baked.
I'm also surprised people say there's too many features, when I'm 
of the opinion several features I'd like, that have been stuck in 
DIP hell for like 3 years, would only make the language simpler.
For example:

- I consider the disability to use struct initialization inline 
as an unexpected limitation.
- I think the way tuples currently work is also confusing, it 
requires a lot of looking into aliasSeq & Tuple library stuff.
- Removing the comma operator entirely, as seems suggested in the 
tuple DIP, would remove a feature some people might not use, but 
it's not a complex concept to understand and thus feels like an 
unnecessary limitation.
- static if & static foreach seem like nice features, but their 
naming is not at all logical. Reuse of the 'static' keyword only 
creates confusion. And it's a halfbaked concept too! There is no 
static switch, and I can't have a compiletime only piece of code 
to work with static if & mixin without creating A LOT of manifest 
constants or having to use functions for it. Why have CTFE, 
static if/foreach, mixin but not just CT? (Hence my suggestion of 
using a ct/comp/compile keyword for static if/foreach & new 
compile-time non-constant 'compile' variables)
- I don't know if I'm the only one, but I believe having a 
seperate 'manifest' keyword for manifest constants would make 
them less confusing.
- The inability to create a non-argument constructor for structs 
is one of those edge-cases one doesn't expect and has to make a 
workaround for. Why can't we have this?

TLDR; Sorry for the rant, I'm just of the opinion that no, there 
are not too many features in D.
Rather the opposite, I'm of the opinion D has a DIP hell problem.
Jan 28 2021
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 28, 2021 at 03:30:52PM +0000, Paul via Digitalmars-d wrote:
[...]

 Why have CTFE, static if/foreach, mixin but not just CT?


[...]

https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time


T

-- 
Tell me and I forget. Teach me and I remember. Involve me and I understand. --
Benjamin Franklin
Jan 28 2021
prev sibling next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 28 January 2021 at 15:30:52 UTC, Paul wrote:

 On Thursday, 11 April 2019 at 12:09:10 UTC, Dejan Lekic wrote:

 [...]


 I'm curious what you mean with half baked.
 I'm also surprised people say there's too many features, when 
 I'm of the opinion several features I'd like, that have been 
 stuck in DIP hell for like 3 years, would only make the 
 language simpler.
 For example:

 [...]


Partially agree actually. I do hope however that the new 
recruitments can help w the DIP-problem. Like, one by one focus 
and either reject or approve, instead of it being discussed to 
the end of the multiverse and staying open.
Jan 28 2021
next sibling parent Paul <paultjeadriaanse gmail.com> writes:
Teoh, thanks for wiki post, it talks about things I wasn't aware 
of. Regardless of implementation however, I believe my criticism 
of the current use to remain valid.

On Thursday, 28 January 2021 at 15:58:07 UTC, Imperatorn wrote:

 I do hope however that the new recruitments can help w the 
 DIP-problem. Like, one by one focus and either reject or 
 approve, instead of it being discussed to the end of the 
 multiverse and staying open.


Do you know of an indication of a timespan for this? I picked up 
hints here and there this was a thing but I haven't read about 
any specifics.
Jan 28 2021
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 28 January 2021 at 15:58:07 UTC, Imperatorn wrote:


 Partially agree actually. I do hope however that the new 
 recruitments can help w the DIP-problem. Like, one by one focus 
 and either reject or approve, instead of it being discussed to 
 the end of the multiverse and staying open


What DIP problem?
Jan 28 2021
parent Max Haughton <maxhaton gmail.com> writes:
On Thursday, 28 January 2021 at 16:37:17 UTC, Mike Parker wrote:

 On Thursday, 28 January 2021 at 15:58:07 UTC, Imperatorn wrote:


 Partially agree actually. I do hope however that the new 
 recruitments can help w the DIP-problem. Like, one by one 
 focus and either reject or approve, instead of it being 
 discussed to the end of the multiverse and staying open


 What DIP problem?


DIP1000 comes to mind. Hopefully the times are changing now but 
we need to be more aggressive when the DIP is actually approved

Beyond that the other problems seem like realities of life
Jan 28 2021
prev sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Thursday, 28 January 2021 at 15:30:52 UTC, Paul wrote:

 On Thursday, 11 April 2019 at 12:09:10 UTC, Dejan Lekic wrote:

 What I really find as an annoying problem is that almost all D 
 features are half-baked...


 I'm curious what you mean with half baked.
 I'm also surprised people say there's too many features, when 
 I'm of the opinion several features I'd like, that have been 
 stuck in DIP hell for like 3 years, would only make the 
 language simpler.
 For example:

 - I consider the disability to use struct initialization inline 
 as an unexpected limitation.


Yeah struct literals as primary epression you mean.
This request comes back often.

People don't always realize but the semantics of struct literals,
**without touching to the syntax**, would be difficult to 
implement.

The type of the expression, so the struct type, in particular 
would have to
be always deduced from other expressions while for other 
primaries the content gives the type **immediatly**.

   void foo(T)(T t){}
   foo({a:10, b:8}) // huh ...

Impossible.

   void foo(T : S)(T t){}
   foo({a:10, b:8}) // okay but painful...

So here you see that to retrieve the literal type you can use the 
template type specalization. But that's not a natural way of 
doing things.


 - I think the way tuples currently work is also confusing, it 
 requires a lot of looking into aliasSeq & Tuple library stuff.
 - Removing the comma operator entirely, as seems suggested in 
 the tuple DIP, would remove a feature some people might not 
 use, but it's not a complex concept to understand and thus 
 feels like an unnecessary limitation.


Slight ptoblem for `for` ;). Also note that it is used
everywhere in the compiler as a way to insert expressions,
e.g dtor calls, so most of the compiler code would have to remain
Jan 28 2021
parent Paul <paultjeadriaanse gmail.com> writes:
On Friday, 29 January 2021 at 05:09:14 UTC, Basile B. wrote:

   void foo(T)(T t){}
   foo({a:10, b:8}) // huh ...

 Impossible.

   void foo(T : S)(T t){}
   foo({a:10, b:8}) // okay but painful...


It looks like

 foo((Type){ bla bla bla })


In C right? Which seems like a simple syntax to me.
(Or is that actually a cast?)

On the note of casts, as I forgot to add this earlier.
I'm slightly confused as to why dlang chose to use 'cast(Type)' 
instead of '(Type)', but even more confused why dlang has no 
'reinterp(Type)' (for as far as i know), instead requiring to use 
'*cast(Type*)&var' (iirc).
Jan 29 2021
prev sibling next 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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
prev sibling next sibling parent reply adam77 <adamevans3217 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


https://openweb.vip/whatsapp-web/	https://19216801.onl/	https://routerlogin.uno/

 features ?

 Any help will be appreciated!




issue solved!!!!!
Dec 29 2019
parent reply Eva759 <kenna178015crook gmail.com> writes:
On Sunday, 29 December 2019 at 22:39:05 UTC, adam77 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


 https://openweb.vip/whatsapp-web/	https://mcdvoice.me/	https://routerlogin.uno/

 features ?

 Any help will be appreciated!




 issue solved!!!!!


also, issue solved!!!!!
Jan 28 2021
parent sighoya <sighoya gmail.com> writes:
On Thursday, 28 January 2021 at 09:40:35 UTC, Eva759 wrote:

 On Sunday, 29 December 2019 at 22:39:05 UTC, adam77 wrote:

 issue solved!!!!!


 also, issue solved!!!!!


Which issue you are talking about?
Jan 28 2021
prev sibling parent reply zeno56 <sharmkapil989 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...

 [...]


See how many D users shout if you recommend particular features 
to delete. There will always be zealous users of almost every 
feature.
Mar 28 2022
parent reply Abdulhaq <alynch4047 gmail.com> writes:
On Monday, 28 March 2022 at 08:36:01 UTC, zeno56 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...

 [...]


 See how many D users shout if you recommend particular features 
 to delete. There will always be zealous users of almost every 
 feature.


OK this is an old thread, but I think that when adam77 actually 
tries writing a web server in Turing machine ticker tape, he'll 
soon realise that in fact Turing machines *don't* manage, and 
those extra features are actually really useful. As for where you 
draw the line on all those extra features.... yes, less is 
sometimes more.
Mar 28 2022
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Mar 28, 2022 at 12:57:16PM +0000, Abdulhaq via Digitalmars-d wrote:
[...]

 OK this is an old thread, but I think that when adam77 actually tries
 writing a web server in Turing machine ticker tape, he'll soon realise
 that in fact Turing machines *don't* manage, and those extra features
 are actually really useful.


[...]

Ever tried writing a webserver in lambda calculus? I mean, hey, it's
Turing-complete... ;-)


T

-- 
Skill without imagination is craftsmanship and gives us many useful objects
such as wickerwork picnic baskets.  Imagination without skill gives us modern
art. -- Tom Stoppard
Mar 28 2022
parent Sergey <kornburn yandex.ru> writes:
On Monday, 28 March 2022 at 14:30:50 UTC, H. S. Teoh wrote:

 On Mon, Mar 28, 2022 at 12:57:16PM +0000, Abdulhaq via 
 Digitalmars-d wrote: [...]

 Ever tried writing a webserver in lambda calculus? I mean, hey, 
 it's Turing-complete... ;-)


 T


Hmm web server.. what about CPU? :)
https://hackaday.com/2020/11/21/a-computer-in-the-game-of-life/
Mar 28 2022