On Saturday, 28 April 2012 at 19:57:08 UTC, SomeDude wrote:
> On Saturday, 28 April 2012 at 19:23:00 UTC, q66 wrote:
>>
>> - AAs integrated in the language; you barely ever use AA literals and having them purely in Phobos would help get rid of the runtime fat, as well as better implementations
>> - Phobos is too fat - it needs to shrink to just a few core modules, others being distributed via some system like CPAN for Perl
>> - Properties - they're kinda broken at this point and the value is questionable
>> - @trusted @system
>> - Exception handling - a lot of runtime, questionable value
>> - Versions - not redundant, but needs a better system (with AND/OR, possibility of de-versioning, the assignment op to set versions is kinda bad)
>>
>> I think I would find some more, but these are the ones I can recall now.
>
> I disagree with every single point here.

So you don't agree version() is horribly half assed without AND/OR (how do you generate the same code for two different versions without copying or creating a new version covering both cases then?) and that "version = FOO;" makes no sense?

On 4/28/2012 12:36 PM, Andrej Mitrovic wrote:
> Also there's mixin templates. What exactly is the difference between
> mixin templates and regular templates?

A mixin template is instantiated in context of the instantiation point, while a regular template is instantiated in the context of the template definition point.

This becomes relevant when looking up symbols that are not defined within the template.

On 4/28/2012 1:00 PM, bearophile wrote:
> "Phobos is too fat"

As opposed to Phobos being phat?

On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
> Andrei and I had a fun discussion last night about this question. The idea was which features in D are redundant and/or do not add significant value?

A more general answer. From my experience the real problem with language features is not their high number, because I am able to learn hundreds of them well. The main problem comes from bad/broken interaction between features, hard to see side effects of features, and so on.

Bye,
bearophile

On Saturday, 28 April 2012 at 19:21:51 UTC, Nick Sabalausky wrote:
> "Walter Bright" <newshound2@digitalmars.com> wrote in message
>
> - Version blocks: They should be replaced with something that utilizes
> "static if".

Version could be replaced with "static if", but I like them, it makes code more readable, so I don't think they should go. We don't want to have a "static if hell", where templating code is mixed with version configuration. I think the version keyword is very good.

I think instead of thinking about removing features, the more important thing is polishing the existing ones so that they work properly.

D is a big language because it tries to span a broad range of uses. Removing complexity from the core language often means adding complexity in the user code, and that's what we don't want.

On Saturday, 28 April 2012 at 20:04:11 UTC, Walter Bright wrote:
> On 4/28/2012 1:00 PM, bearophile wrote:
>> "Phobos is too fat"
>
> As opposed to Phobos being phat?

Well my concern is so that it doesn't end up like Python standard library, half-bitrotting and half-crap :) Huge standard library is not a good idea even for a very big language/library team, and D doesn't have one.

On Saturday, 28 April 2012 at 20:02:12 UTC, q66 wrote:
> On Saturday, 28 April 2012 at 19:57:08 UTC, SomeDude wrote:
>> On Saturday, 28 April 2012 at 19:23:00 UTC, q66 wrote:
>
> So you don't agree version() is horribly half assed without AND/OR (how do you generate the same code for two different versions without copying or creating a new version covering both cases then?) and that "version = FOO;" makes no sense?

Sorry, with that, I agree. Nick Sabalausky proposed to remove version entirely.
But I agree there could be something like:
version(LINUX|OSX){
...
} else {
...
}

On Saturday, 28 April 2012 at 20:05:30 UTC, SomeDude wrote:
> On Saturday, 28 April 2012 at 19:21:51 UTC, Nick Sabalausky wrote:
>> "Walter Bright" <newshound2@digitalmars.com> wrote in message
>>
>> - Version blocks: They should be replaced with something that utilizes
>> "static if".
>
> Version could be replaced with "static if", but I like them, it makes code more readable, so I don't think they should go. We don't want to have a "static if hell", where templating code is mixed with version configuration. I think the version keyword is very good.
>
> I think instead of thinking about removing features, the more important thing is polishing the existing ones so that they work properly.
>
> D is a big language because it tries to span a broad range of uses. Removing complexity from the core language often means adding complexity in the user code, and that's what we don't want.

There are minimalistic languages that don't add too much complexity, instead it results in code being kept simple. D needs to do something it does really well and concentrate on that. Otherwise the language will remain being rather vague and doing "a bit of everything, but nothing truly well".

Instead of adding more and more features into a rigid language, it needs to be made more flexible and extensible, both syntactically and semantically.

On 04/28/2012 08:47 PM, Walter Bright wrote:
> Andrei and I had a fun discussion last night about this question. The
> idea was which features in D are redundant and/or do not add significant
> value?
>
> A couple already agreed upon ones are typedef and the cfloat, cdouble
> and creal types.
>
> What's your list?


- Associative array literals as non-associative array initializers [1]
- C style array declarations [2]
- 'align' declaration [3]
- 'synchronized' [4]
- special treatment of built-in types during parsing [5]
- the arcane restrictions on which exact kind of argument can be
  used to substitute which kind of template parameter


I think all other language features are useful and except for new instance.Class and 'this' template parameters, I think they all occur in my code. (But those would certainly come in handy for a somewhat more OO-like style of programming.)


(There are a few features that I'd like to give a (mostly syntactic) overhaul, but that is not what is discussed here.)


Explanations:


[1] Actually I think the functionality is very useful, but the syntax is probably confusing for many fellow D programmers. CTFE should enable a library implementation.

[2] They violate the 'same syntax, same behaviour' rule, and they don't add a lot of value.

[3] I have not understood until now what exactly the guarantees are that it gives, so take this with a grain of salt. I know that it is not useful as implemented DMD for typical alignment tasks, and that GDC implements different semantics. Can you explain to me what it is useful for?

[4] It adds memory overhead for the monitor to every single class, even though most classes are explicitly _typed_ as unshared.

[5] It is for example impossible to directly string mixin "int".

On 4/28/12, Walter Bright <newshound2@digitalmars.com> wrote:
> A mixin template is instantiated in context of the instantiation point,
> while a
> regular template is instantiated in the context of the template definition
> point.

Ooooh. Suddenly that explains some of my compilation errors.