View mode: basic / threaded / horizontal-split · Log in · Help
April 28, 2012
Does D have too many features?
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?
April 28, 2012
Re: Does D have too many features?
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.

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 .
April 28, 2012
Re: Does D have too many features?
"Walter Bright" <newshound2@digitalmars.com> wrote in message 
news:jnhe1i$2vcm$1@digitalmars.com...
> 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?

Off the top of my head:

- Using function stubs so the implementation can be provided in a separate 
source and linked in. (Outside of .di files anyway.)

- Comma operator

- Version blocks: They should be replaced with something that utilizes 
"static if".
April 28, 2012
Re: Does D have too many features?
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. Compiler 
should be smart enough to avoid putting immutable integers/doubles into 
object file as variables.

3. with statement (?). I kind of like it but bleh it's too boggy and it 
doesn't seem to pull its weight. (pointers? class references? a lot of 
stuff to go wrong) Fluent interfaces solve a good portion of its 
benefits to be specific.

4. foreach_reverse. Seriously let's kill this abomination. If it happens 
that foreach(x; retro(range)){...} is slower it just means compiler 
(inlining?) is no good and should be improved.

5. .tupleof looks like a hack. But I'd rather "refactor" than drop it.

6. Drop out arguments? There are tuples.
And auto (a, b) = getMeTwoThings();  is cleanerthan
<something> a, b;
fillTheseTwoThings(a, b);
// no indication whatsoever that a & b are modified heck even fn(&a, &b) 
in C is *better*
(ok no tuple unpacking for now but you got the idea)

7. I can live without homogenous varaidics. Since most of the time they 
readily progress to full-blown variadics that detect common type & 
forward things to an array version of function. Also given that 
sometimes people do things like:

this(int[] arr...)// ctor with cool syntax, yada-yada ;)
{
	this.data = arr; //boom! (pointer to stack-allocated stuff)
}

8. Something else. D is huge :)

-- 
Dmitry Olshansky
April 28, 2012
Re: Does D have too many features?
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?

- 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.
April 28, 2012
Re: Does D have too many features?
On 4/28/12, Walter Bright <newshound2@digitalmars.com> wrote:
> What's your list?

I don't mind extra features, just as long as they're properly
documented and implemented. For example, I have absolutely no uses for
anonymous classes right now, but I know DWT2 uses them and probably
other people do use them.

Personally I find the hardest threads to to follow are the ones
discussing in/out/inout/autoref. For one thing there are compiler
bugs, but then there are misconceptions between what developers vs
documentation vs core devs say about them. And then you mix in classes
and templates into the story and it all becomes a large forest of
information that is very hard to digest.

Another feature I'm curious about is .dup/.idup. It's basically
hardcoded for a couple of types, but why not instead use UFCS and
implement .dup/.idup in std.array as a free function? Then you might
even use it for user-types by requiring a type to implement .dup/.idup
functions.

Also there's mixin templates. What exactly is the difference between
mixin templates and regular templates? We can use the mixin statement
for both types right now, so there doesn't seem to be a distinction.
For example, if you take samples from the template mixin page
(http://dlang.org/template-mixin.html) and you remove "mixin" from the
template declaration, all of the samples will continue to work. You
could remove this declaration feature right now and you probably
wouldn't break any code at all. Seems like low-hanging fruit to me.
April 28, 2012
Re: Does D have too many features?
"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!
April 28, 2012
Re: Does D have too many features?
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.
April 28, 2012
Re: Does D have too many features?
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). This is nothing more than a fancy function with
a delegate parameter.

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

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

* 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. 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.
April 28, 2012
Re: Does D have too many features?
Walter:

> which features in D are redundant and/or do not add significant 
> value?
>...
> What's your list?

Finding things to remove now from D is hard, in my code I have 
used most D features now. And many suggestions I have seen in 
this thread are very bad, like removing foreach_reverse (that I 
use often), or "Phobos is too fat" (that is the opposite of what 
I'd like, I'd like D with more batteries).

The features I have not used in my programs so far are:

1) Typesafe Variadic Functions for class objects (never used so 
far).
2) >>>=  >>> (Never used so far).
3) Floating point comparison operators (never used).
4) Delimited Strings / heredoc strings (never used so far in real 
code, despite Perl programmers use them now and then).
5) lazy (as function argument. I have used "lazy" in some test 
programs, but not in real code so far).
6) Anonymous classes (used only in demo code so far).
7) Shortened floating point literals as .6 or 6.


Other things that I don't like:
1) Mixed C/D array declarations 
(http://d.puremagic.com/issues/show_bug.cgi?id=5807 )
2) I'd like to disallow (or fix!) default arguments of out and 
ref arguments (http://d.puremagic.com/issues/show_bug.cgi?id=5850 
).
3) Automatic joining of adjacent strings (a bug-prone 
anti-feature: ["red" "green", "blue"]).
4) Comma operator, it gives more troubles than flexibility.
5) The most complex parts of the is() syntax (to be replaced with 
other things).
6) Two kinds of tuples. I'd like a single tuple type in a 
language, but I understand this is hard to do.

-------------------------

I'd also like to see some limits removed like:

struct Foo {}
void main() {
  auto f = new Foo; // currently not accepted, silly
}


BigInt x;
switch (x) {
  case BigInt(0): break;
  default:
}


And I'd like some features added/improved, like:
- tuple unpacking syntax;
- computed gotos;
- a static foreach 
(http://d.puremagic.com/issues/show_bug.cgi?id=4085 );
- attribute hiding error or warning 
(http://d.puremagic.com/issues/show_bug.cgi?id=5187 );
- safer typesafe variadics 
(http://d.puremagic.com/issues/show_bug.cgi?id=5212 );
- Named arguments;
And few other things.

Bye,
bearophile
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home