Jump to page: 1 25  
Page
Thread overview
Things that may be removed
Dec 17, 2008
bearophile
Dec 17, 2008
Ary Borenszweig
Dec 17, 2008
Gide Nwawudu
Dec 17, 2008
bearophile
Dec 17, 2008
Nick Sabalausky
Dec 17, 2008
Simen Kjaeraas
Dec 18, 2008
Nick Sabalausky
Dec 18, 2008
bearophile
Dec 18, 2008
Christian Kamm
Dec 19, 2008
cemiller
Dec 19, 2008
BCS
Dec 21, 2008
Stewart Gordon
Dec 21, 2008
Christian Kamm
Dec 21, 2008
Frits van Bommel
Dec 21, 2008
Christian Kamm
Dec 21, 2008
Stewart Gordon
Dec 18, 2008
Ary Borenszweig
Dec 21, 2008
Stewart Gordon
Dec 18, 2008
Jason House
Dec 22, 2008
Don
Dec 22, 2008
KennyTM~
Dec 22, 2008
bearophile
Dec 22, 2008
Stewart Gordon
Dec 22, 2008
bearophile
Dec 22, 2008
Bill Baxter
Dec 23, 2008
KennyTM~
Dec 23, 2008
Bill Baxter
Dec 22, 2008
bearophile
Dec 22, 2008
Max Samukha
Dec 22, 2008
Denis Koroskin
Dec 27, 2008
Max Samukha
Dec 22, 2008
dsimcha
Dec 22, 2008
John Reimer
Dec 24, 2008
Nick Sabalausky
Dec 24, 2008
bearophile
Dec 24, 2008
Don
Dec 24, 2008
Nick Sabalausky
Dec 24, 2008
Yigal Chripun
Dec 24, 2008
Yigal Chripun
Dec 25, 2008
Frits van Bommel
Dec 25, 2008
Max Samukha
Dec 24, 2008
Nick Sabalausky
Dec 24, 2008
Yigal Chripun
December 17, 2008
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
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
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
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
"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
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
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
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
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
"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