April 29, 2012 Re: Does D have too many features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | On 29-04-2012 00:18, Manu wrote: > On 28 April 2012 21:47, Walter Bright <newshound2@digitalmars.com > <mailto:newshound2@digitalmars.com>> 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 personally find the wealth of features in D to be one of it's major > selling points. It helps simplify user code a lot, but I think there is > room for some things to be more consistent: > > * version refuses to allow boolean logic, I need boolean logic, thus > version is redundant to me. I find myself using static if almost > exclusively in its place. I like the *idea*, but it's un-usably limited. +1. > * Consolidation of meta/introspection: __traits(), std.traits, is(), and > a few other tricks, I often don't know where I should look to perform a > particular introspection task. __traits is unsightly, it looks more like > a hack rather than a feature, but it fills perhaps one of the most vital > roles in the language. > * D has a lot of attributes, many of which I haven't used + don't > understand. I suspect many of them could be removed and implemented in > the library with a proper user attribute system (which would be really > useful to compliment D's introspection anyway). This would also free > those keywords when those libraries aren't imported/used. > * I don't know the value of AA's in the language, I've only used them > once or twice. Because AA's can be implemented in numerous ways (map, > hash table, etc), and may be ordered or unordered, the the choice of > which to use is actually important to the problem more often than not. > As long as the same convenience can be achieved in the library (literal > expression?), maybe it should be there. -- - Alex |
April 29, 2012 Re: Does D have too many features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On 29-04-2012 03:06, bearophile wrote: > Jonathan M Davis: > >> * foreach_reverse is essentially redudant at this point (not to mention >> confusing if combined with delegates), since we have retro. > > retro() can't replace foreach_reverse until the front-end > demonstrability produces asm code equally efficient. > Loops _must_ be fully efficient, they are a basic language construct, > this is very important. Even foreach() is sometimes not equally > efficient as a for() in some cases... > > >> * I hate C style struct initializers and would really like to see them >> go, but >> for reasons that I don't understand, people actually use them rather >> than using a proper constructor call, > > For single structs I prefer D-style initialization. > But take a look at this code, if you replace those C-style initializers > with D-style, even using aliases to shorten the code to single letters, > that data section becomes more noisy: > http://rosettacode.org/wiki/Ray-casting_algorithm#D > > >> * As for features that add little value, the first one that comes to >> mind is >> with. I think that I've used it all of once, and I don't think that >> I've seen >> it in other people's code very often. > > It's rather common in Pascal/Delphi programming. I use it now and then. > > For a case where it's very handy see here, with an enumeration: > http://rosettacode.org/wiki/Stable_marriage_problem#Alternative_version > > >> It's hard to grep for (since with is >> used in comments quite often), > > Try to search for "with(" or "with\s(", that are less common in normal > text. > > >> * Increasingly, I don't like UFCS. I think that in most cases, it >> complicates >> code for little value. And I _really_ don't like how it results in people >> flipping chains of a(b(c(d(5)))) calls into something like >> d(5).c().b.().a(). I >> think that it makes the code way harder to read. > > For me it makes that kind of code way simpler to read... Completely agree. > > >> The code is completely backwards. > > It means call d on 5, then call c on the result, then call b on the > result, and then call a on the result. It's better than before :-) Amen. > > Bye, > bearophile -- - Alex |
April 29, 2012 Re: Does D have too many features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On 29-04-2012 03:40, Jonathan M Davis wrote: > On Sunday, April 29, 2012 03:06:53 bearophile wrote: >>> * Increasingly, I don't like UFCS. I think that in most cases, >>> it complicates >>> code for little value. And I _really_ don't like how it results >>> in people >>> flipping chains of a(b(c(d(5)))) calls into something like >>> d(5).c().b.().a(). I >>> think that it makes the code way harder to read. >> >> For me it makes that kind of code way simpler to read... >> >>> The code is completely backwards. >> >> It means call d on 5, then call c on the result, then call b on >> the result, and then call a on the result. It's better than >> before :-) > > I know that you find easier to read. A number of people do. But it is just so > backwards in comparison to how stuff normally works, that it hurts my brain. > But I've done enough functional programming that I find something > likea(b(c(d(5)))) to be completely straightforward, and for some reason not > everyone does. And while I _never_ intend to use UFCS in this manner, I'm > going to forever have to read the code of others who do, which I find to be a > major negative. I've done ML, F#, Erlang, Haskell, Lisp, and others, and I still don't like that style. It's the very reason F# has the pipelining operators like |> and <|. > > But regardless of my personal opinion on the matter, it's clear that enough > people like UFCS that it's not going anywhere unless something seriously wrong > is found with it which makes it untenable. > > - Jonathan M Davis -- - Alex |
April 29, 2012 Re: Does D have too many features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | On Sunday, 29 April 2012 at 20:00:27 UTC, Alex Rønne Petersen wrote:
>
> Let's get a standard package manager that we either advocate on dlang.org or include in the releases before we start talking about reducing the amount of modules in Phobos.
Don't get me wrong. I don't want to reduce the amount of modules in Phobos. I think it's a great standard library.
A little bit buggy in some places, and lacks a few important features (that are in the review queue), but great overall.
I fear the risk with a package system is, having some parts of Phobos not being correctly maintained with time. And I want to be able to have the whole thing with a single download.
No, my concern was, for smaller applications, in embedded systems for instance (Android, iOS, etc), there is not really a small basic library. So I would think of a two level standard library, one on top of the other.
OTOH, Jonathan Davis made the remark that we can always use the C lib and its bindings, so this mostly satisfies my concern.
|
April 29, 2012 Re: Does D have too many features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | On 4/29/12, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:
> I hate to nitpick and all that, but opBinaryRight!"in" actually works now. ;)
Yes and then you get to have those nice template instantiation errors, which make no sense at all:
struct Foo {
auto opIn_r(string op)(int i) { return 1; }
}
struct Bar {
auto opBinaryRight(string op)(int i) { return 1; }
}
void main()
{
Foo foo;
auto x = "" in foo;
Bar bar;
auto y = "" in bar;
}
Foo:
test.d(34): Error: template test.Foo.opIn_r does not match any
function template declaration
test.d(16): Error: template test.Foo.opIn_r(string op) cannot deduce
template function from argument types !()(string)
Bar:
test.d(37): Error: rvalue of in expression must be an associative array, not Bar
The Bar error message is completely useless.
|
April 29, 2012 Re: Does D have too many features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to ponce | On 29-04-2012 03:20, ponce wrote: > Le 28/04/2012 20:47, Walter Bright a écrit : >> What's your list? > > - builtin complex types (I don't _need_ be able to write "4 + 5i") +1. > - builtin associative arrays > - some builtin properties like arr.sort +1, and .reverse. I'm also against .dup and .idup being properties, but these don't modify the array in place, so I take less issue with them. > - lazy, I use it only for logging lazy is horribly broken in many ways. Try to make a lazy value where the producing delegate is pure. (Hint: You can't.) > - foreach_reverse, never used it > - comma operator: when do you ever need it? I've never used it intentionally, ever, but have been bitten in the ass countless times because of it. > - in operator Disagree. However, I do think it needs to made more useful (for instance, I simply don't understand why I can't use in to test for existence in an array). > > > Other than that, as a user I can't say having a lot of features is a big > problem, it's a major selling point. -- - Alex |
April 29, 2012 Re: Does D have too many features? | ||||
---|---|---|---|---|
| ||||
On 4/29/12, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> struct Foo {
> auto opIn_r(string op)(int i) { return 1; }
> }
Sorry that's wrong, should be:
struct Foo {
auto opIn_r(int i) { return 1; }
}
And then you get:
test.d(25): Error: function test.Foo.opIn_r (int i) is not callable
using argument types (string)
test.d(25): Error: cannot implicitly convert expression ("") of type
string to int
which much better than Bar's error message.
|
April 29, 2012 Re: Does D have too many features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paulo Pinto | On 29-04-2012 08:31, Paulo Pinto wrote: > Am 28.04.2012 20:47, schrieb Walter Bright: >> 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? > > - two different ways of creating function pointers is confusing > (function and delegate) > > I understand the reasoning, but makes one think all the time when > to use what. > > - sometimes D code looks like template and mixins gone mad > While I do appreciate the power, it can be quite confusing to try > to understand what the code does. Specially with the lack of support > in mixin's debugging > > - __traits should be given a proper name > It looks out of place in regard with the rest of the language, by making > use of the underscores > > - AA should be a library type > I am on the C++ and Scala camp where the language should be extendable > via the library > > - misuse of enum to declare constants > I prefer that the use of const would be possible > > - conditional compilation is hard to follow without syntax highlighting > Other languages with conditional compilation make it easier to follow > what is what. e.g. Turbo Pascal/Delphi, C#, Modula-3, Ada > > - unit tests > I would rather have them as a library. D unit tests were never really useful for anything beyond single-library projects IMHO. They don't scale for large, real-world application projects with lots of libraries and executables. > > While it is fun to discuss what we like and not like, I vote that > priority should be given to make the language stable and have better > tooling. > > We need to have safer languages with native code generation for systems > programming in the mainstream OS, that take us away from the buffer > overflow exploits and dagling pointers legacy that C and C++ brought > upon us. > > Someone that does not know D and sees the amount of bugs still existing, > or this type of discussions, will run away to Go or some future version > of C#/Spec#/Bartok, or back to whatever he/she was using before. > > I don't agree D is complex, any language that aims to be used in large > application domains, needs a certain set of abstractions. If it does not > support them, it is condemmend to keep getting new features until it > turns in what the language designers were fighting against. > > -- > Paulo -- - Alex |
April 29, 2012 Re: Does D have too many features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | Alex Rønne Petersen:
>> - lazy, I use it only for logging
>
> lazy is horribly broken in many ways.<
Sometimes I use std.exception.enforce(), that uses lazy.
Bye,
bearophile
|
April 29, 2012 Re: Does D have too many features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | Alex Rønne Petersen:
> D unit tests were never really useful for anything beyond single-library projects IMHO. They don't scale for large, real-world application projects with lots of libraries and executables.
I think D has to offers means to library writers to instrument the built-in unit-testing machinery, to allow the implementation of a good unit testing system.
Bye,
bearophile
|
Copyright © 1999-2021 by the D Language Foundation