On Saturday, 22 September 2018 at 13:22:03 UTC, new wrote:
> On Saturday, 22 September 2018 at 10:53:25 UTC, bauss wrote:
>> On Saturday, 22 September 2018 at 09:42:48 UTC, Jonathan Marler wrote:
>>>
>>> I'd be interested to hear/read about the features that some developers don't like with D2.
>>
>> I'm going to guess it has to do with all the attributes for functions which you often have to remember is it @attribute or is it just attribute like is it @nogc or is it nogc etc.
>>
>> It's one of the things that probably throws off a lot of new users of D, because they feel like they __have__ to know those although they're often optional and you can live without them completely.
>>
>> They make the language seem bloated.
>
> the language is bloated. trying to read the source of D2 makes gives you the feeling of getting eye cancer.
> so we decided if D at all then it should be D1.

Hello,

You can have a pretty much "D1" experience if you avoid new features:
- @nogc
- shared
- avoid constness (well except strings), inout
- alias bit = bool; // :)
- struct postblit
- etc..

AFAIK if you port D1 code the only problem is with immutable(char)[] instead of string, and the only thing to know is that immutable(T) and T implicitely convert to const(T).

D2 the language has become longer to learn, but there is a subset that is very much like D1. It's a matter of introducing features as you go, one by one.

A lot of things are objectively better like build systems, ecosystems, stability, meta-programming, CTFE, OPTLINK, Phobos...

On Sunday, 23 September 2018 at 13:55:02 UTC, Guillaume Piolat wrote:
> A lot of things are objectively better like build systems, ecosystems, stability, meta-programming, CTFE, OPTLINK, Phobos...

I wouldn't say meta-programming and CTFE are 'objectively' better. It could be argued that such features lengthen compilation time and make it harder to parse D code (thus harder to write tools for it).

On Saturday, 22 September 2018 at 20:34:50 UTC, 0xEAB wrote:
> On Saturday, 22 September 2018 at 19:41:16 UTC, JN wrote:
>> Some code will break, sure, but it's a mechanical change that should be possible to apply by some tool.
>
> Who will run this tool? Who's gonna merge the PRs created with this tool?
> Compatibility fixes would have been easy in the past in many cases - nevertheless, it needs someone to apply them. Which often did not happen in the past, unfortunately.

The demon on my shoulder is telling me to add it to dub.

Record the last used compiler in dub.selections.json. Add every incompatibility to dfix. If your project was last built with, say, 2.079.0, then dub will detect the current compiler and run dfix with the necessary upgrades when building the project. And it runs `git reset --hard` before doing any of these checks, or applies them in your project's .dub directory.

This is pretty cruddy, but it protects you somewhat from unmaintained projects.

Though honestly, having a stable compiler version and recommending that people stick with it for multiple years would also help a lot.

On Sunday, 23 September 2018 at 13:55:02 UTC, Guillaume Piolat wrote:
> AFAIK if you port D1 code the only problem is with immutable(char)[] instead of string, and the only thing to know is that immutable(T) and T implicitely convert to const(T).

A lot of D1 code was 32-bit only, so there will be tons of uint instead of size_t.

Implicit string concatenation was also a thing. I tried porting Jarrett Billingsley's Croc (aka MiniD) to D2, and that was the most common issue I encountered.

> A lot of things are objectively better like build systems, ecosystems, stability, meta-programming, CTFE, OPTLINK, Phobos...

Most of the D1 ecosystem died with dsource.org, yes.

D1 code doesn't have a modern Phobos, but it does have Tango available, which might help.

On Saturday, 22 September 2018 at 19:04:41 UTC, Henrik wrote:
> On Saturday, 22 September 2018 at 15:45:09 UTC, Jonathan Marler wrote:
>> On Saturday, 22 September 2018 at 15:25:32 UTC, aberba wrote:
>>> [...]
>>
>> Yeah there's been alot of discussion around it over the years, which is why I put this together about 4 years ago:
>>
>> https://wiki.dlang.org/Language_Designs_Explained#Function_attributes
>>
>> Gosh I've forgotten how long I've been using D.
>
> Interesting article.
>
> "int safe = 0; // This code would break if "safe" was added as a keyword"

You don't have to turn the @ words to non-@s. You can go the other way and make attributes consistently use @ as well and remove them as keywords.

So

pure void f() {} // Deprecated, attributes must start with @

On Sunday, 23 September 2018 at 02:05:42 UTC, Jonathan M Davis wrote:

>
> With regards to D1 users who are unhappy with D2, I think that it makes some sense to point out that a subset of D2 can be used in a way that's a lot like D1, but ultimately, if someone doesn't like the direction that D2 took, they're probably better off finding a language that better fits whatever it is that they're looking for in a language. Trying to convince someone to use a language that they don't like is likely to just make them unhappy.
>
> - Jonathan M Davis

I think the problem is that D2 added too many things too fast, often based on what was the latest CS/industry fashion of the day. I'm not saying that all the features are useless, I'm just saying that sometimes it's better to lean back for a while and have a cuppa before you add and complicate things further. Not all features that have been added are indispensable. I've recently made the experience that you can get very far very fast with a small and compact language that has useful features, features that have been proven to be useful in _everyday programming_ and were added for exactly this reason.

Posters on this thread have pointed out that one should avoid certain keywords and features, if one wants a simpler experience. However, the D community encourages people to use all the latest fancy features and idioms, which to a certain extent you have to do anyway if you use Phobos. So it's very confusing for newcomers and sometimes for longtime users too and your code ends up reflecting the various development stages of D2.

Maybe it's time for D3. Pick and choose the things that work and really do make sense and discard others that don't add much value but only bring trouble. I think D2 is a nice collection of Lego bricks by now that could be used to build something truly great.

On Saturday, 22 September 2018 at 13:24:57 UTC, new wrote:
>> the language is bloated. trying to read the source of D2 makes gives you the feeling of getting eye cancer.
>> so we decided if D at all then it should be D1.
>
> sorry i meant D2-phobos

It's only a coding convention for phobos and a consequence of overengineering as phobos tries to satisfy all possible needs, it's not a property of the language. There's a D2 port of tango https://github.com/SiegeLord/Tango-D2 and it has almost no attribute creep, only @property, but that one is pretty superficial and shouldn't hurt to remove with simple sed '/@property //'.

On Monday, 24 September 2018 at 09:19:34 UTC, Chris wrote:
> On Sunday, 23 September 2018 at 02:05:42 UTC, Jonathan M Davis wrote:
>
>>
>> With regards to D1 users who are unhappy with D2, I think that it makes some sense to point out that a subset of D2 can be used in a way that's a lot like D1, but ultimately, if someone doesn't like the direction that D2 took, they're probably better off finding a language that better fits whatever it is that they're looking for in a language. Trying to convince someone to use a language that they don't like is likely to just make them unhappy.
>>
>> - Jonathan M Davis
>
> Maybe it's time for D3. Pick and choose the things that work and really do make sense and discard others that don't add much value but only bring trouble. I think D2 is a nice collection of Lego bricks by now that could be used to build something truly great.

I don't agree; the time for D3 is still many years away. Transitiong to D3 now would be suboptimal, as the D2 language is still being "explored". The D community as a whole needs more experience with the language to understand pain points, so we can make more informed changes in D3 (if D3 ever happens; it may not need to).

On 2018-09-22 10:48, Nemanja Borić wrote:

> So it is possible to use D2 language and compiler and avoid all the features that you don't like, at least to a reasonable degree, and as a bonus you still get to cherry pick D2 features you like (and there are some even for D1 minded person).

Yeah, for example, the DWT [1] code base use very few D2 features. It was originally written in D1 and then ported to D2 with as few changes as possible. It might actually still compile using a D1 compiler.

[1] https://github.com/d-widget-toolkit/dwt

-- 
/Jacob Carlborg

On 09/22/2018 10:31 AM, Jonathan Marler wrote:
> On Saturday, 22 September 2018 at 13:25:27 UTC, rikki cattermole wrote:
>> Then D isn't the right choice for you.
> 
> I think it makes for a better community if we can be more welcoming, helpful a gracious instead of responding to criticism this way. This is someone who saw enough potential with D to end up on the forums but had some gripes with it, after all who doesn't? I'm glad he took the initiative to provide us with good feedback, and he's not the first to take issue with the inconsistent '@' attribute syntax.  I'm sure everyone can agree this inconsistency is less than ideal but that doesn't mean D isn't right for them and we should respond this feedback like this with thanks rather than dismissal.
> 

Ordinarily yes, but most of what "new" has said above has been very trollish and borderline irrational.