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

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.

> 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

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.

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

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.

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

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.

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.

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.