On Saturday, 28 April 2012 at 20:49:33 UTC, Maxim Fomin 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?
>
> 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 04/28/2012 09:22 PM, Dmitry Olshansky wrote:
> On 28.04.2012 22:47, 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?
>
>
> 1. Drop is(...) feature entirely. Extend __traits where needed and move
> compile-time reflection to "magic" meta namespace completely.
>
> 2. "enum as manifest constant". Use static or immutable/global.

static is not accessible at compile time, would you want to change that?
immutable is not an option because it infects the type.

Furthermore, I like 'enum' because it is concise.

What is the issue with enum?

> Compiler should be smart enough

Smart compiler fallacy. It really cannot be that smart in this case.

> to avoid putting immutable integers/doubles into
> object file as variables.
>

Their address might be taken by code that is unavailable! Furthermore, many of my enums are strings or arrays.

> 8. Something else. D is huge :)
>

I actually think D is not too large.

On Saturday, 28 April 2012 at 20:35:40 UTC, SomeDude wrote:
> 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.

This kind of attitude "we need big fat bullshit like Java and heavy use of OO and idioms and EH and all that other crap" is broken and false. And you have no way to prove that Python for example wouldn't scale for large projects; its main fault is that the default implementation is rather slow, but it's not pretty much missing anything required for a large project.

On Sat, Apr 28, 2012 at 09:58:02PM +0200, foobar wrote: [...]
> 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). This is nothing more than a fancy function with
> a delegate parameter.

I disagree. Having a dedicated foreach construct allows the compiler to optimize away the delegate in certain cases. I wouldn't want to incur the cost of creating and passing a delegate in something as simple as foreach (i; 0..100), for example.


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

Actually, I rather like the enum idiom of declaring compile-time constants. Though it could do with a renaming to something more befitting.


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

This is an interesting idea. But using separate git branches just for having versioned code seems a bit like total overkill... plus a maintenance nightmare since you have to continue pull and merge changes to every porting branch every time development happens. Whereas having everything represented in source means that whoever writes a new feature is also responsible for making it work with whatever versions are currently out there. After-the-fact fixes are always painful.


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

I proposed a while ago that .di files should be replaced by something better: omit ALL function bodies, template bodies, private members, etc., and just keep the "real" public API in the human-readable part of the file. Function and template bodies should be kept in as a binary blob readable by the compiler (which obviously needs to know them otherwise it won't be able to expand templates).

(Yes the binary blob can be reverse-engineered, but so can executables, so it's a moot point. We're not trying to write cryptographic security here, but it's nice to separate what the compiler needs to know vs. what the user of a library needs to know.)


> * This is a big one: get rid of *all* current compile time special syntax. It should be replaced by a standard compilation API and the compiler should be able to use plugins/addons. This would reduce the size of the language to half of its current size, maybe even more.

I have to disagree here. CTFE and compile-time features is a major reason I like D. I argue rather that compile-time features should be *improved*. The current situation is good, but not quite there yet. It can be made better.


T

-- 
Be in denial for long enough, and one day you'll deny yourself of things you wish you hadn't.

On Saturday, 28 April 2012 at 20:49:33 UTC, Maxim Fomin 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?
>
> 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.

That's a very well worded post. That's one more reason why the most important thing imho is to have the current feature set stabilized, and not adding or removing features every other month, because we don't have enough experience with D to be certain such feature is redundant. This kind of experience can only be gained with feedback from hundreds or thousands of users, and there aren't that many users in this newsgroup.

D is large enough that I'm pretty sure no two programmers use the same features. That's why we have so different answers to the question "which features is useless ?". Yet every programmer has his favorite feature that saves his ass at one point or another, and that's why everybody finds it's a joy to use. Were it missing, someone would complain. I'm pretty confident that in a sufficiently large program, nearly every single feature of the language will be put to good use.

Now what people don't like is when features or Phobos don't work as expected, I suppose that's what you call holes. And that's another matter. I've browsed through hundreds of bug reports last week, and I could see many many features don't work as expected. And that's the most important problem in my opinion. That's where most of the efforts should be put.

On 29.04.2012 0:57, Timon Gehr wrote:
> On 04/28/2012 09:22 PM, Dmitry Olshansky wrote:
>> On 28.04.2012 22:47, 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?
>>
>>
>> 1. Drop is(...) feature entirely. Extend __traits where needed and move
>> compile-time reflection to "magic" meta namespace completely.
>>
>> 2. "enum as manifest constant". Use static or immutable/global.
>
> static is not accessible at compile time, would you want to change that?
> immutable is not an option because it infects the type.
>
Oops, scratch that comment about static/immutable.

But how about:
alias thing = runSomeCtfe();

And bring the usual alias to new_name = <something>;
 form (even C++ finally got this right with C++11 aliases).

> Furthermore, I like 'enum' because it is concise.
>
> What is the issue with enum?
>
>> Compiler should be smart enough
>
> Smart compiler fallacy. It really cannot be that smart in this case.
>
>> to avoid putting immutable integers/doubles into
>> object file as variables.
>>
>
> Their address might be taken by code that is unavailable! Furthermore,
> many of my enums are strings or arrays.
>
>> 8. Something else. D is huge :)
>>
>
> I actually think D is not too large.

For what it does - surely not. But in general it's big.
For one it's not smaller then C++.

8. synchronized. scope(exit) mutex.unlock(); is fine in cases where RAII is awkward.

-- 
Dmitry Olshansky

On Saturday, 28 April 2012 at 20:50:30 UTC, H. S. Teoh wrote:
> 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.
>

Besides AA literals, library can handle this JUST FINE.

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

Too large collection becomes too hard to manage. Separating it and distributing in style "you pay for what you use" is IMO the right approach.

>
>> - Properties - they're kinda broken at this point and the value is
>> questionable
>
> What kind of properties are you referring to?
>

The @property crap. It's broken. If anything, it needs something like in C#.

>
>> - @trusted @system
>
> These are necessary.
>

They're far from 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.
>

The exception handling system via try/catch is as bad and tedious as error codes, except the added runtime. It all roots from the idea "catch everything that throws". This is broken, as you DON'T always need to handle all sorts of errors (letting it segfault or something sometimes simply proves to be better than trying to save the situation; or you can simply assert it). Also http://yosefk.com/c++fqa/exceptions.html#fqa-17.1

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

They're nearly unusable now. And the syntax simply makes no sense.

>
> T

On Saturday, 28 April 2012 at 20:59:48 UTC, q66 wrote:
>
> This kind of attitude "we need big fat bullshit like Java and heavy use of OO and idioms and EH and all that other crap" is broken and false. And you have no way to prove that Python for example wouldn't scale for large projects; its main fault is that the default implementation is rather slow, but it's not pretty much missing anything required for a large project.

Python has two big drawbacks for large projects:
- it's too slow
- it's a dynamically-typed language

The fact that it's flexible is because it uses duck typing, and AFAIK you can't do duck typing in a statically typed language.
So it's cool for small programs, but it can't handle large ones because it's not statically typed. And this opinion doesn't come just out of thin air, I speak from my own professional experience.

On Saturday, 28 April 2012 at 21:05:12 UTC, q66 wrote:
> On Saturday, 28 April 2012 at 20:50:30 UTC, H. S. Teoh wrote:
>> 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.
>>
>
> Besides AA literals, library can handle this JUST FINE.
>

Yeah, but core language AA are so useful it would be a MAJOR mistake to remove them. In Python too, you could put the AA in the libraries. Yet everybody uses the AA that are in the language.

Where I DO agree with you is, Phobos should be a two level library, i.e a minimalistic library, with about the same feature set as the standard C library + multithreading, and a superset with the full range of features (ranges, algorithms, etc). I've already advocated it somewhere else.

On Sat, Apr 28, 2012 at 10:07:54PM +0200, q66 wrote:
> 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 the contrary, being able to do stuff without having to reinvent the square wheel every single time is a big plus.

I used to have a strong NIH attitude -- years ago during my DOS days, I reimplemented video output routines in assembly because I wanted to use protected mode in DOS. Nothing in the C standard library worked because they are all tied to DOS or otherwise do stuff that breaks in protected mode. So I reinvented file abstractions, string processing, etc., in my own library. I was rather proud of it too: my video routines took advantage of features of my particular chosen video mode, so I could use the i386's built-in loop instructions and other such things to output characters really fast.

In retrospect, it was a fun and very educational experience. But to be frank, you can only reinvent the C standard library so many times before you get totally sick and tired of it. I mean, I've implemented linked lists, hand-made lexers, parsers, etc., who knows how many times, and nowadays the thought of having to do it all over again just makes me feel, "I should be doing better things with my time".

The whole point of a standard library is that if somebody has written that code before, and it's general enough for everyday use, then you shouldn't need to download this, install that, configure the other, before you can use it. It's a major plus if you're publishing code to be able to say, just download my sources and compile it with the language standard library and it will all work. As opposed to, if you want to compile my code, you need library X and Y which depend on W and Z, all of which have to be downloaded from different places all over the 'net and you better make sure you get the right versions otherwise everything will break.

Besides, the whole point of a library is that only what you need is actually linked in. You don't walk around carrying every book from your bookshelf just because you *might* need to refer to one of them on some rare occasion. But the library itself doesn't need to be minimal, in fact, rather to the contrary. (That's why it's called a "library".)


T

-- 
Latin's a dead language, as dead as can be; it killed off all the Romans, and now it's killing me! -- Schoolboy