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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ary Borenszweig | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Gide Nwawudu | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | "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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jason House | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ary Borenszweig | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Simen Kjaeraas | "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. |
Copyright © 1999-2021 by the D Language Foundation