On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
> What's your list?

I think most the responses to this thread are insane.

But, there is one thing I don't think D needs: new.
I'm pretty sure it could be done in the library now
that we have robust templates, which I think would open
up some nice things.

Suppose:

module std.typecons;
NotNull!T new(T, Args...)(Args args) {
    return assumeNotNull(core.gc.new!T(args));
}

module core.gc;
T new(T, Args...)(Args args) {
 // implement the new we know now
}



And so on, then you could get new allocators
just by changing which module you import new from.



We could kinda sorta do it now, but it wouldn't be
as consistent, and of course, the name "new" is unavailable.

On Saturday, 28 April 2012 at 21:19:00 UTC, H. S. Teoh wrote:
> 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

Well I'm not obviously saying the features should disappear, what I had in mind was some kind of distribution system for small packages, kinda like luaforge or CPAN, where everyone could find what they need for their project. But keep Phobos itself small.

On Sat, Apr 28, 2012 at 11:21:52PM +0200, q66 wrote:
[...]
> Well I'm not obviously saying the features should disappear, what I had in mind was some kind of distribution system for small packages, kinda like luaforge or CPAN, where everyone could find what they need for their project. But keep Phobos itself small.

If you're talking about very specific, niche features (like parsing protein structure data files), then I agree they should be distributed in separate libraries. But generic stuff that can be used in a wide array of tasks should go in the standard library.

Again I say, being able to distribute your sources without requiring the user to download 50 different libraries just to compile it, is a big plus to me. Being able to say "just compile with the standard library" is best, because it means people can just download my code and compile it immediately. Same goes for binary distribution: it's much much better to say "here, just download this binary and run it with the language standard library" than to say "download this binary, then library X, then library Y, then library Z which is needed by library X, then library W needed by ...".


T

-- 
Freedom of speech: the whole world has no right *not* to hear my spouting off!

On 04/28/2012 11:05 PM, 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.
>

That is why they should be a narrow wrapper around a library defined type.

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

This sounds reasonable.

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

As I understand it, the 'agreed upon' design is that

@property int foo() { return x; }
@property void foo(int v) { x = v; }

Would be completely equivalent to C#:

int foo { set{ x = value; }; get{ return x; } }

I think it is even perfectly fine to just allow function calls without parentheses, but I wouldn't mind seeing that feature gone.

>>
>>> - @trusted @system
>>
>> These are necessary.
>>
>
> They're far from necessary.
>

Why? Memory safety is generally considered to be important.

>>
>>> - 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 can improve performance though, because the exceptional branches don't occur in the code that is normally executed.

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

Except that it won't necessarily segfault.

That is not how _reliable_ systems work. Robustness is an important property of critical systems. If your software might kill people if it behaves in the wrong way, you really really don't want to ignore error conditions.

> or you can simply assert it).

Certainly, if it is a consistency criterion internal to the program, then assertions should be used.

> Also http://yosefk.com/c++fqa/exceptions.html#fqa-17.1
> [snip.]

The part of this article relevant for D is this:

"Still, in many cases, the benefits of exceptions are more important than their problems. For example, if your language manages memory automatically, the problem of releasing acquired resources becomes a small one (you only have to care about files, etc., which are a tiny part of the "resources" used by a program - most of the "resources" are memory). If your language throws exceptions when you violate its rules (for example, upon out-of-bounds array access), these exceptions will help you find lots of bugs, especially if you can get the call stack from an exception. If the purpose of an application is automated testing, and/or it's used as a quick-and-dirty internal tool as opposed to a product for an end user, this kind of exceptions is all you need to handle errors of almost all kinds. In some languages, you can even resume the execution from the point where the exception was raised after fixing the problem at the point where it was caught."

Anyway, I generally avoid exceptions if they are not an obvious fit.

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?

Here's my list:

- Properties. They add no value and just start pointless discussions about what should and shouldn't be a property.

- UFCS. It's just sugar, but adds complexity.

- const/immutable/inout/shared/pure. These add massive complexity to the language for little (IMO) benefit. When I do multi-threading, I usually have to resort to casting. Maybe these will improve with time.

- opDispatch. I think it just promotes sloppy, obfuscated code for minor syntactical benefit. Member access through pointers should require -> like in C++ so that you can overload it for smart pointer/reference ADTs.

That's all I can think of for now.

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

I really don't care how it's implemented or what its syntax is. What I do want is begin able with a single glimpse, to see the different versions of the code, without having the impression to plunge into a "static if hell" with 5 levels of indentation. Having a different keyword helps for this. Besides, a specific keyword makes parsing code easier.

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?

OK longer answer.

 - is is messed up. It is a massive hack and have to be rationalized.
 - version is a bad version of static if. The static if part of the version must go.
 - comma expression is confusing and have very little benefice.
 - out arguments. We can return tuples, out argument is going backward in history.
 - many array properties (.sort for instance) are useless and would be way better as libs.

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?

Ho god D is HUGE !

OK a last one, synchronized on objects. Most of them are not even shared so it is useless, and is is bad separation of concerns between OOP and multithreading. If you want a mutex, declaring it explicitly is the best option.

Le 28/04/2012 22:25, Timon Gehr a écrit :
> 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.
>

Off topic. I discussed several proposals, and I invest time ever since to come up with a good solution. Introducing a whole new paradigm in a language isn't something light.

AST manipulation at compile time is the key.

On Saturday, 28 April 2012 at 21:51:42 UTC, deadalnix wrote:
>  - out arguments. We can return tuples, out argument is going backward in history.
>  - many array properties (.sort for instance) are useless and would be way better as libs.

What happens the day the language is actually fit for embedded programming, and you don't want to have to link against Phobos because it's too big ?