View mode: basic / threaded / horizontal-split · Log in · Help
December 17, 2008
Things that may be removed
There are some things I'd like to see added to the D language, but what things can be removed from it?

"Perfection is attained, not when no more can be added, but when no more can be removed."
-- Antoine de Saint-Exupéry.
:-)

"There should be one-- and preferably only one --*obvious* way to do it."
-- Python Zen, emphasis added by me :-)

Bye,
bearophile
December 17, 2008
Re: Things that may be removed
bearophile wrote:
> There are some things I'd like to see added to the D language, but what things can be removed from it?
> 
> "Perfection is attained, not when no more can be added, but when no more can be removed."
> -- Antoine de Saint-Exupéry.
> :-)
> 
> "There should be one-- and preferably only one --*obvious* way to do it."
> -- Python Zen, emphasis added by me :-)
> 
> Bye,
> bearophile

Why, of course, the C syntax for types:

int (*x[5])[3];
int (*x)(char);
int (*[] x)(char);

*Ugh*...
December 17, 2008
Re: Things that may be removed
On Wed, 17 Dec 2008 10:57:02 -0200, Ary Borenszweig
<ary@esperanto.org.ar> wrote:

>bearophile wrote:
>> There are some things I'd like to see added to the D language, but what things can be removed from it?
>> 
>> "Perfection is attained, not when no more can be added, but when no more can be removed."
>> -- Antoine de Saint-Exupéry.
>> :-)
>> 
>> "There should be one-- and preferably only one --*obvious* way to do it."
>> -- Python Zen, emphasis added by me :-)
>> 
>> Bye,
>> bearophile
>
>Why, of course, the C syntax for types:
>
>int (*x[5])[3];
>int (*x)(char);
>int (*[] x)(char);
>
>*Ugh*...

Totally agree, learning two ways of doing things is just more effort,
but then again I didn't like C's style of declarations in the first
place. Learning Pascal before C maybe toughen me up, I haven't
suffered RSI typing ARRAY OF :)

http://mindprod.com/jgloss/unmainobfuscation.html
[snip]
29. Exploit Schizophrenia: Java is schizophrenic about array
declarations. You can do them the old C, way String x[], (which uses
mixed pre-postfix notation) or the new way String[] x, which uses pure
prefix notation. If you want to really confuse people, mix the
notations: e.g. 
byte[] rowvector, colvector, matrix[];
which is equivalent to: 
byte[] rowvector;
byte[] colvector;
byte[][] matrix;


At least D doesn't allow the mixture of pre/postfix notations in a
declaration.

Gide
December 17, 2008
Re: Things that may be removed
Gide Nwawudu:
> Learning Pascal before C maybe toughen me up, I haven't
> suffered RSI typing ARRAY OF :)

But Pascal arrays have other qualities, an example:

type 
 TyArr = Array ['e' .. 'x'] of Integer;
var
 a1: TyArr;
begin
 a1['f'] := 10;
...

That array has that range of chars as indexes, and if you want the compiler at run time will control that only that range of chars is used. In D you can do that as (probably typedef is much less common in D code than the types section in Pascal programs):

typedef int['x' - 'e'] TyArr;
TyArr a1;
int main() {
   a1['f' - 'e'] = 10;
...

But maybe such things aren't common enough to deserve a special support.

Bye,
bearophile
December 17, 2008
Re: Things that may be removed
"bearophile" <bearophileHUGS@lycos.com> wrote in message 
news:gib2kj$2bib$1@digitalmars.com...
> Gide Nwawudu:
>> Learning Pascal before C maybe toughen me up, I haven't
>> suffered RSI typing ARRAY OF :)
>
> But Pascal arrays have other qualities, an example:
>
> type
>  TyArr = Array ['e' .. 'x'] of Integer;
> var
>  a1: TyArr;
> begin
>  a1['f'] := 10;
> ...
>
> That array has that range of chars as indexes, and if you want the 
> compiler at run time will control that only that range of chars is used. 
> In D you can do that as (probably typedef is much less common in D code 
> than the types section in Pascal programs):
>
> typedef int['x' - 'e'] TyArr;
> TyArr a1;
> int main() {
>    a1['f' - 'e'] = 10;
> ...
>
> But maybe such things aren't common enough to deserve a special support.
>
> Bye,
> bearophile

VB6 (and maybe VBScript) allows the lower bound of an array to be any 
interger less than whatever the upper bound is. Personally, I've never liked 
that. The mere possibility for that forces all code that uses arrays to use 
the ugly "UBound(array) - LBound(array)" to get length (unless you want to 
write and use a non-standard array length function) and start all iterations 
at "LBound(array)" instead of 0. Then again, since D has ".length" and 
"foreach", those might not be problems for D.

I think Andrei has previously suggested the idea of dropping the keyword 
"new" from class instantiations / heap allocations. I wouldn't like that. 
The "new" makes class instantiations / heap allocations easily greppable. I 
don't think I would want to give that up.

Also, as far as the quoted in the original post (such as "Perfection is 
attained, not when no more can be added, but when no more can be removed."). 
I normally agree with such sentiment, but I don't consider it to bve 
particularly applicable to language design. I see a progamming langauge as 
being not a tool, but a toolbox. You wouldn't design a real 
carpentry/construction/etc. toolbox with a "Perfection is attained, not when 
no more can be added, but when no more can be removed." philosophy, would 
you? If you did, it would end up containing nothing but a hammer and a note 
saying "If all you have is a hammer, everything looks like a nail". If you 
did it with language design, you'd ultimately end up with brainfuck.
December 17, 2008
Re: Things that may be removed
On Wed, 17 Dec 2008 23:45:55 +0100, Nick Sabalausky <a@a.a> wrote:

> I think Andrei has previously suggested the idea of dropping the keyword
> "new" from class instantiations / heap allocations. I wouldn't like that.
> The "new" makes class instantiations / heap allocations easily  
> greppable. I
> don't think I would want to give that up.

IIRC, the idea was to replace it with a member function, i.e. foo.new();

-- 
Simen
December 18, 2008
Re: Things that may be removed
SFINAE

Accidental use of SFINAE  is confusing.

Code using SFINAE is tough or impossible to follow.

Use of SFINAE can lead to longer compile times.

Removing SFINAE will expose shortfalls in D's metaprogramming facilities.

Combining all of these faults into a templated library and you have C++'s STL or Boost all over again. They're amazingly useful in C++, but D can do far better!

bearophile Wrote:

> There are some things I'd like to see added to the D language, but what things can be removed from it?
> 
> "Perfection is attained, not when no more can be added, but when no more can be removed."
> -- Antoine de Saint-Exupéry.
> :-)
> 
> "There should be one-- and preferably only one --*obvious* way to do it."
> -- Python Zen, emphasis added by me :-)
> 
> Bye,
> bearophile
December 18, 2008
Re: Things that may be removed
On Wed, Dec 17, 2008 at 7:14 PM, Jason House
<jason.james.house@gmail.com> wrote:
> SFINAE
>
> Accidental use of SFINAE  is confusing.
>
> Code using SFINAE is tough or impossible to follow.
>
> Use of SFINAE can lead to longer compile times.
>
> Removing SFINAE will expose shortfalls in D's metaprogramming facilities.
>
> Combining all of these faults into a templated library and you have C++'s STL or Boost all over again. They're amazingly useful in C++, but D can do far better!

There's one more - SFINAE has become all but unnecessary in D, at
least in D2.  static if and template constraints (the if() after the
template header) seem to be much more general (and easier to follow)
than SFINAE.
December 18, 2008
Re: Things that may be removed
Ary Borenszweig:
> Why, of course, the C syntax for types:
> int (*x[5])[3];
> int (*x)(char);
> int (*[] x)(char);
> *Ugh*...

Try porting code that uses heavily n-dimensional tensors from C to D, and you understand why supporting the C syntax for arrays (with inverted coordinates in the definition) is a godsend :-)

Bye,
bearophile
December 18, 2008
Re: Things that may be removed
"Simen Kjaeraas" <simen.kjaras@gmail.com> wrote in message 
news:op.umbxr0n41hx7vj@biotronic.osir.hihm.no...
> On Wed, 17 Dec 2008 23:45:55 +0100, Nick Sabalausky <a@a.a> wrote:
>
>> I think Andrei has previously suggested the idea of dropping the keyword
>> "new" from class instantiations / heap allocations. I wouldn't like that.
>> The "new" makes class instantiations / heap allocations easily 
>> greppable. I
>> don't think I would want to give that up.
>
> IIRC, the idea was to replace it with a member function, i.e. foo.new();
>

I was under the impression it was about changing this:

class Foo {}
auto f = new Foo();

To this:

class Foo {}
auto f = Foo();

Maybe I was mistaken though.
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home