On 04/28/2012 09:11 PM, deadalnix wrote:
> Le 28/04/2012 20:47, Walter Bright a écrit :
>> 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?
>
> I think many D features come from the lack of AOP in D. I already
> mentioned that in some other thread.
>

Many times, actually. But you have *never* sketched how support for AOP would look like.

> I would also mention the is expression which does way too many stuffs
> and many of them are not usefull or counter intuitive and may be
> replaced by lib support in std.traits .

On 04/28/2012 09:39 PM, Nick Sabalausky wrote:
> "q66"<quaker66@gmail.com>  wrote in message
> news:ihqjguujvoukhlqcwkyi@forum.dlang.org...
>>
>> - 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
>
> That's just craziness!
>
>

+1.

On 04/28/2012 10:02 PM, Walter Bright wrote:
> 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.

The implementation seems to disagree:

int x;
template X(){ // not a mixin template
    void y(){x=2;}
}

class C{
    int x;
    mixin X; // picks up local 'x'
}

void main(){
    auto c = new C;
    c.y();
    import std.stdio;
    writeln(x," ",c.x); // "0 2"
}

Or am I misunderstanding your statement?

On Saturday, 28 April 2012 at 20:09:50 UTC, q66 wrote:
> On Saturday, 28 April 2012 at 20:05:30 UTC, SomeDude wrote:
>
> There are minimalistic languages that don't add too much complexity, instead it results in code being kept simple.

I appreciate minimalistic languages. I love the simplicity of Scheme and the design of Lua. Lua and Python are extensible language, but truth be told, they cannot handle large scale programming. In fact, I don't know of any minimalistic language that can scale from hundreds of thousands to millions of lines of code. When you reach these sizes, their simple design becomes a drawback. You start missing lots of features. When you reach large scale programming, you want really powerful tools.

That's basically what the Java designers discovered after experience. The original language was simple and easy, but that simplicity translated into way  too much boilerplate code. So they kept adding features from version to version, generics, then annotations, a means to create new keywords. And now they would like to add delegates. These are all needed in large programs.

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

It does a lot of things well already. Our point of comparison should not be Python or Lua, it must be C, C++, C#, Haskell, Ocaml, i.e languages that are designed to develop large systems.

But most of all it needs to stabilize and polish, not change all the time. I think its feature set is very good already.
We are far from having explored all its possibilities.

> 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/12 22:02, Walter Bright wrote:
> 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.

Yeah, but this was actually the only suggestion so far in this thread that i could agree with... The issue is

   template t1() { int a = b; }
   int main() { int b; mixin t1; return a; }

which is currently accepted - and would enforcing the mixin annotation really help anything?

artur

On Sat, Apr 28, 2012 at 11:47:31AM -0700, 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.

D has typedef?? Wow. And I thought I had a good grasp of D.


> What's your list?

Comma operator.

foreach_reverse.

with statements. They make code hard to read, and besides you can (or should be able to) alias long expressions into a short identifier for this purpose anyway.

The great variety of string quoting syntax, while useful, seem to need some cleanup and unification. Get rid of r"", `` works just fine. (Or vice versa, but not both.) Delimited strings and token strings may be possible to be unified, perhaps?

It's about time octal literals went the way of the bit bucket.

There's probably more, I'll post them as I think of them.


T

-- 
Questions are the beginning of intelligence, but the fear of God is the beginning of wisdom.

On 04/28/2012 09:58 PM, foobar wrote:
> 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 couple already agreed upon ones are typedef and the cfloat, cdouble
>> and creal types.
>>
>> What's your list?
>
> D has a lot of ad-hock features which make the language
> needlessly large and complex. I'd strive to replace these with
> better general purpose mechanisms.
>
> My list:
> * I'd start with getting rid of foreach completely. (not just
> foreach_reverse).


foreach is very useful. Have you actually used D?

> This is nothing more than a fancy function with
> a delegate parameter.
>

That would be opApply.

> * enum - enum should be completely redesigned to only implement
> what it's named after: enumerations.
>

What is the benefit?

> * version - this does not belong in a programming language. Git
> is a much better solution.
>

So you'd maintain a git branch for every OS if there is some small part that is OS-dependent? I don't think that is a better approach at all.

> * di files - a library should encapsulate all the info required
> to use it. Java Jars, .Net assemblies and even old school; Pascal
> units all solved this long ago.
>
> * This is a big one: get rid of *all* current compile time
> special syntax.

What would that be exactly?

> It should be replaced by a standard compilation
> API and the compiler should be able to use plugins/addons.

Are you serious?

> This would reduce the size of the language to half of its current
> size, maybe even more.

I am certain that it would not.


You missed to present the 'general purpose mechanisms'.

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 couple already agreed upon ones are typedef and the cfloat, cdouble and creal types.
>
> What's your list?

I guess the underlying problem is inability to formulate the target state of the language with specified relations between different components. Being looking at the language since late 2011 I found problematic to know the language as a whole. When a newcomer looks for information he either gets a common overview "native efficiency, ..." at dlang.org with (outdated) documentation or videos on youtube which explains how scope(xxx) beats exceptions and templates are superior to that in C++ and similar posts in the web, let alone toolchain lack complaints.

My comment was provoked mainly by http://forum.dlang.org/thread/vwpzirpppabcgylmvpsx@forum.dlang.org discussion (D3 idea).

You ask which features are redundant or not significant, but this depends on how features are integrated in the rest of language and without clear and completed vision there is no answer. And please remember, that each of D member has its own (biased) information about D and what to do. The language is moving and it is hard to reveal how any change will affect other components. Even if you found a particular item redundant there is no guarantee that the situation will not change in future.

Currently I (who looked for a language that combines C# "usability" and C performance) view D as a ship which sails in unknown direction with lots of holes (look at bugzilla proposals how to make a language) and what I found the most dreaded is that the direction of the ship movement today is determined by which hole was fixed yesterday.

So, you are free to ask ship's crew about what hole and how to fix and expect that it will tomorrow bring ship to a better place, but without final destination this brownian movement may theoretically last infinitely, but of course, in practice it will lead either to ship crashing, departure of sailors or finally targeting an unexpected place with unsatisfactory result.

On Sat, Apr 28, 2012 at 09:22:59PM +0200, 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

On the contrary, AA's are a major reason I started programming in D. In this day and age, it's simply inexcusable to *not* have some kind of hash type available by default.


> - Phobos is too fat - it needs to shrink to just a few core modules, others being distributed via some system like CPAN for Perl

Um... that's what a *library* is supposed to be: a large collection of useful stuff from which you can pick the few that you need right now.


> - Properties - they're kinda broken at this point and the value is questionable

What kind of properties are you referring to?


> - @trusted @system

These are necessary.


> - Exception handling - a lot of runtime, questionable value

I completely disagree. No exception handling means lots and lots and lots of boilerplate code for checking error codes, return values, which are too tedious to write, which translates to many people leaving them out and ending up with unreliable code that fail silently or crash outright when a function call they assumed would work stopped working.

If you've worked in large multi-person projects, you'll see very quickly why you *need* exception handling. No modern language can do without exception handling. Maybe you have a beef with how it's currently done in D, but regardless, you *need* exception handling of some kind.


> - 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 find versions sorta neat... and they're simple enough that they don't add to much bloat to the language. (Whereas if you added AND and OR to them, then they start duplicating the function of static if, and that's when they become redundant.)


T

-- 
Your inconsistency is the only consistent thing about you! -- KD

On Sat, Apr 28, 2012 at 10:08:29PM +0200, SomeDude wrote:
> 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 {
> ...
> }

But if you're gonna do that, might as well just fold the feature into static if. The point of having a separate version construct was to provide a very basic, simple, easy-to-implement and easy-to-use way of versioning stuff. I don't think it was ever intended to be a full-fledged versioning system.


T

-- 
What doesn't kill me makes me stranger.