www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why I Use D

reply lurker <lurker lurker.com> writes:
I just love D and use nothing else anymore - if i can help it. 
The gripe i have is:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=11858
(Need to fill and find about 5000 tags and it is a real problem for now.)

Other than that it is great. I am developing a dicom reader/displayer and the
code is smaller and easier than anything i have seen and used before in c++ -
and i hope to be able to share it soon.
Soon after i hope i will be able to share a dicom server.

What to do i dislike?

1.) i hoped for an easer egg - bug fixes for 2.xx (see
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.lea
n&article_id=11858)  - macros and more
2.) i hope people will communicate more politely
3.) i wished somebody would port parts of tango to phobos - and phobos be the
standard and only library, since i think it hurts D more (tango) than most
people think

I am a beginner and  i enjoy D. 
I hope  - "The Safe Subset of D" will be done in a way, that no delays will
occure in D 2.XXXX


lurker

sorry for my english
Mar 28 2008
next sibling parent reply Russell Lewis <webmaster villagersonline.com> writes:
lurker wrote:

 I just love D and use nothing else anymore - if i can help it. 


I like this thread...griping is an easy trap to fall into.  Why do I use D?

* dynamic arrays
* delegates, particularly now that closures work (very cool!)
Mar 28 2008
parent "Scott S. McCoy" <tag cpan.org> writes:
I'll tell you what brings me to D.

I'm interested in business programming around event models in large
throughput applications.  What better environment than one which has
method references which retain their object scope, closures which retain
their references (although that only works in DMD currently and I mostly
use GDC, but I'm not missing it much just looking forward to it
working), what seems to be solid garbage collection and nice, expressive
programming at the system level...

The other interest I have, as it is the unfortunate reality of business
applications that many vendor libraries which are required for
integration just aren't meant for asynchronous applications (and for the
sake of scaling across multiple processing channels), is multithreadded
programming.  And when I first heard about const, I was excited.  When I
then looked into just how complex this topic has become, I got weary.

Some phase of D is just what I want in a programming language.  That
phase is somewhere in the middle of D 1.0 and D 2.0, where closures are
added and there weren't so many types of const/invariant behaviors and
syntaxes to figure out.  I like the idea of const, but I don't like the
idea of the language becoming inanely complex for the sake of trying to
solve a problem no other language is able to solve.

Personally, I think the immutability of a real const, read-only view, is
ideal.  The ability to return read-only references to a data structure
that isn't read only sounds like the compiler solving the never-ending
problem I've faced in java of programmers being too sloppy to properly
build immutable objects.

const fixes everything.  But what does invariant give me?  The way I see
it, it's just a way to qualify literal values for most purposes!  And
that I find unnecessary, because they may as well just implicitly be
const.  And theoretically, if const is really a read only view, once you
promote to const, you shouldn't be able to come back out of it.
Honestly, I don't see the reason for everything else...it makes sense to
qualify a method as "doesn't modify the object" so it can be accessible
from a const reference to that object, but 

I love the expressiveness that D has...and while I'm writing this, I'll
take a second to plug my thoughts on array slicing.

array[..] should be synonymous with array[0..$]
array[5..] should be synonymous with array[5..$]/array[5..length]
array[..5] should be synonymous with array[0..5].

This makes the language a little more expressive, makes sense, and
doesn't require $.

Cheers,
    Scott S. McCoy

On Fri, 2008-03-28 at 12:04 -0700, Russell Lewis wrote:


 lurker wrote:

 I just love D and use nothing else anymore - if i can help it. 


 
 I like this thread...griping is an easy trap to fall into.  Why do I use D?
 
 * dynamic arrays
 * delegates, particularly now that closures work (very cool!)
Mar 28 2008
prev sibling next sibling parent reply Extrawurst <spam extrawurst.org> writes:
What do i like ?

* dynamic arrays, slicing
* cleaner OOP (no multiple class inheritance)
* syntax goodies : foreach,foreach-range,the 
array/struct-literals,auto,loop-labels,nested comments
* and i like the transitive const (D2.0) !!!
* delegates
* powerful and yet much more transparent template programming (meta 
porgramming in D in general)

What i dislike ?

* two standard libraries, i think this is a real problem (keeps new 
users away, people i talk about D with consider it too unmature if there 
is such a gap between the stdlib of the reference compiler and the 
community-generated lib, and they simply wont give it a try cause of 
much stuff missing in phobos)
* IDE - We really need full code-completion/suggestion/outlining/goto 
support and all these goodies to convince larger scale teams to switch 
to D (i know Descent is on a good way...)
* some already "ancient" compiler Bugs

Thank you Walter for the great effort and the wonderful language that 
you are dedicating to this thankful but always critical community!


~Stephan
Mar 28 2008
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Extrawurst wrote:

 Thank you Walter for the great effort and the wonderful language that 
 you are dedicating to this thankful but always critical community!


You're welcome!

(And I'm aware that if nobody's grumbling about X, then nobody's using X!)
Mar 28 2008
prev sibling parent Graham St Jack <grahams acres.com.au> writes:
On Fri, 28 Mar 2008 22:02:42 +0100, Extrawurst wrote:


 What do i like ?
 
 * dynamic arrays, slicing
 * cleaner OOP (no multiple class inheritance) * syntax goodies :
 foreach,foreach-range,the array/struct-literals,auto,loop-labels,nested
 comments * and i like the transitive const (D2.0) !!! * delegates
 * powerful and yet much more transparent template programming (meta
 porgramming in D in general)
 
 What i dislike ?
 
 * two standard libraries, i think this is a real problem (keeps new
 users away, people i talk about D with consider it too unmature if there
 is such a gap between the stdlib of the reference compiler and the
 community-generated lib, and they simply wont give it a try cause of
 much stuff missing in phobos)
 * IDE - We really need full code-completion/suggestion/outlining/goto
 support and all these goodies to convince larger scale teams to switch
 to D (i know Descent is on a good way...) * some already "ancient"
 compiler Bugs
 
 Thank you Walter for the great effort and the wonderful language that
 you are dedicating to this thankful but always critical community!
 
 
 ~Stephan


This pretty much sums it up for me too.

I think D is fantastic, and I am close to being able to use it for 
project work in my day job. The team I work in is also keen - we are sick 
and tired of C++'s stupidities and ugliness. All that is holding us back 
is the standard litany of GUI, 64-bit, waiting just a bit longer for 2.x 
to mature and the Tango/Phobos split - and they won't hold us back much 
longer.

In preparation I have ported quite a bit of our library code and have had 
wonderful experience, ending up with about 1/3 as much code, and what is 
left is far easier to understand and easier on the eye.
Mar 29 2008
prev sibling next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Sometimes it's good to give Walter something to read that isn't 
complaints.  Could not be a bad thing if we all listed our reasons...

Reasons D is used by me:

1. String processing is easy, clean, and straight-forward (even with 
i18n, etc.) in similar ways to other languages I use.

2. When there are bugs in the compiler, I can find out why in many 
cases.  This just makes me happy, and allows me to submit a patch so I 
can hope it will be fixed.


has allowed me to work on tools for D (namely Visual Studio integration.)

4. With closures, associative arrays, "auto", and similar features I am 
able to (in cases) write code similar to how I would write JavaScript, 
PHP, and other languages I use which are not native.

5. I feel like I have (fairly limited but existing) some way to give 
feedback on the design of the language.

6. Emphasis on slicing and other features that are clearly better for 
performance, and just make sense anyway.


Reasons for which I might not use D:

1. Phobos has bugs/traps, Tango I haven't used as much but the style 
just isn't for me... tend to have to roll much of my own code (HTTP/XML 
processing, basic string handling, service/daemon hookup code, etc.)

2. It's fairly easy to link to other languages, but there are walls for 
sure... this can be a concern, since it's unreasonable for me to push D 
on developers who don't know the language (due to project/budget 
constraints.)

3. Haven't dealt with it too much yet, but I'm concerned const will be 
over-much red tape for some usage...

-[Unknown]


lurker wrote:

 I just love D and use nothing else anymore - if i can help it. 
 The gripe i have is:
 
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=11858
 (Need to fill and find about 5000 tags and it is a real problem for now.)
 
 Other than that it is great. I am developing a dicom reader/displayer and the
code is smaller and easier than anything i have seen and used before in c++ -
and i hope to be able to share it soon.
 Soon after i hope i will be able to share a dicom server.
 
 What to do i dislike?
 
 1.) i hoped for an easer egg - bug fixes for 2.xx (see
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.lea
n&article_id=11858)  - macros and more
 2.) i hope people will communicate more politely
 3.) i wished somebody would port parts of tango to phobos - and phobos be the
standard and only library, since i think it hurts D more (tango) than most
people think
 
 I am a beginner and  i enjoy D. 
 I hope  - "The Safe Subset of D" will be done in a way, that no delays will
occure in D 2.XXXX
 
 
 lurker
 
 sorry for my english
Mar 28 2008
parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Unknown W. Brackets wrote:

 Sometimes it's good to give Walter something to read that isn't 
 complaints.  Could not be a bad thing if we all listed our reasons...
 
 Reasons D is used by me:


Because I can safely troll at #D
// Seriously, speed/control of C(++) with the ease of Python.


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode
Mar 28 2008
prev sibling next sibling parent lutger <lutger.blijdestijn gmail.com> writes:
Me too:

Top features of D:
- arrays, including associative arrays and all their goodies (slicing etc.) 
- strings, unicode ftw
- GC AND pointers && friends PLUS C interop
- module system and object orientation
- delegates, including nested functions
- generic programming

D is such a rich language, supporting many styles of programming. Like in
C++ the programmer has a lot of freedom and can make her own tradeoffs,
like in python the language is really productive and enjoyable. 

I'm also very fond of the care that has been given to practical needs: ddoc,
function hijacking, even such simple things as disallowing 'for(int i = 0;
i < 10; i++);', etc. etc. 

And last but not least, although some harsh words have been said (this
always happens though) I think D does have a mature and helpful community
as well as design team, which inspires trust.

Ok, thanks everybody. </fanboy>
Mar 29 2008
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
Good to see a thread like this on the NG. Too much of the negative stuff -  
but
it's needed.

What do I like about D?

* Transitive const. I actually thought that const in other languages was
   transitive before Walter told us all it's not. (I never tested it, it  
just
   never occured to me that anyone would do something as illogical as
   non-transitive const :P)
* Array operations, slices, strings, as well as all the other stuff that  
has to
   do with this.
* Garbage collecting. Ok, so there are certain strings attached to using  
it,
   but you can turn it off.
* Code generation. Mixins, CTFE, templates - and so simple and logical.
* Easy linking to C. It's a must, and we know it.
* Compiles to native code.
* Multi-level language. It's assembler, C, Java and more.
* Inline assembler. Makes it easier for me to learn assembler, and having  
just
   one way to do it ensures that the next compiler I bump into will also  
compile
   my code. (at least such is the theory...)
* C++ without all the mucus, shamanic rituals, and eldritch incantations.


What do I not like about D?

* Enum. While I understand some people use keyword count as an indication  
of
   language worth, I heartily disagree. And enum is to me a list of elements
   related to each other, with no defined value except the name (unless you
   choose to assign them values, of course).
* Template/CTFE/Mixin error messages. Well, they're ok on their own, but  
I'd
   like to be able to tell the user 'this and that is wrong with your  
template
   instantion/CTFE function in file foo at line bar'.
* Old bugs. When something doesn't work, and the answer you get when you  
ask is
   "It's in bugzilla, been there since Adam and Eve walked the earth", it  
doesn't
   quite make me smile and dance and sing.


All in all, D is the language I want. It's not perfect (yet :P), but it's  
close
to what I want for most things.

Now, I think the only thing that remains is to say thank you. To Walter,
especially. But also to Andrei and the others who help, to the Tango team  
and
others who create important libraries for D, and to everyone on the  
newsgroup.
D wouldn't be what it is without you.

-- Simen
Mar 29 2008
prev sibling next sibling parent lurker <lurker lurker.com> writes:
hi all,

Glad to see that some people don’t think that i am a troll.

I am ashamed that I forgot to say THANK YOU Walter.

It is kind of funny, that a mentioning of the 2 libraries is like mohammed 
pictures with al kaida.
I AM NOT A TROLL!!!, just a learner - enjoying D and someone who thinks that D
has a great future.
One thing, - i think -, that made m$ so successful, is that everything seems to
be out of one cast; no one or two or ... libraries, - no matter how good or bad
they are. I wished that, now that phobos is open for everybody, the people of
tango would merge, so that the observers (and noubes) like me, will get the
impression that everything is of one cast.
Marketing is not just a thing for tango, it affects all of D.
Anyway, all of you should be more positive of D, such as some people who
answered this thread. Never could have written the facts and points as the
those people did.

Sorry for my bad english.
lurker






lurker Wrote:


 I just love D and use nothing else anymore - if i can help it. 
 The gripe i have is:
 
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=11858
 (Need to fill and find about 5000 tags and it is a real problem for now.)
 
 Other than that it is great. I am developing a dicom reader/displayer and the
code is smaller and easier than anything i have seen and used before in c++ -
and i hope to be able to share it soon.
 Soon after i hope i will be able to share a dicom server.
 
 What to do i dislike?
 
 1.) i hoped for an easer egg - bug fixes for 2.xx (see
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.lea
n&article_id=11858)  - macros and more
 2.) i hope people will communicate more politely
 3.) i wished somebody would port parts of tango to phobos - and phobos be the
standard and only library, since i think it hurts D more (tango) than most
people think
 
 I am a beginner and  i enjoy D. 
 I hope  - "The Safe Subset of D" will be done in a way, that no delays will
occure in D 2.XXXX
 
 
 lurker
 
 sorry for my english
Mar 29 2008
prev sibling next sibling parent reply "Neil Vice" <psgdg swiftdsl.com.au> writes:
What initially got me into D was seeing it as C++ without seperate header 
files - which when ur not using an IDE is a HUGE plus in my opinion.




beginning to hate it - and love D =)

With regularity can you hear me exclaiming to my coworkers "this would not 
be a problem if we were only using D".

Const-wise, I think I'm quite a fan of the recent const implementation - 
just can't wait for full integration into libs and operator overloading =)
Mar 30 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:



syntax of properties, the syntax of lambdas, LINQ, the help the IDE gives you,
the automatic support of multi core, the fact that it's used by more people,
the syntax of the "foreach", its associative arrays, some parts of its standard
library, some of its compilation at run-time, and few other bits. Among such
things some of them can be added into D too).

Have you written few benchmarks to compare the performance of the garbage

Phobos)?

Bye,
bearophile
Mar 30 2008
parent reply "Neil Vice" <sardonicpresence gmail.com> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:fsnu26$1a1u$1 digitalmars.com...


 =)<


 the syntax of properties, the syntax of lambdas, LINQ, the help the IDE 
 gives you, the automatic support of multi core, the fact that it's used by 
 more people, the syntax of the "foreach", its associative arrays, some 
 parts of its standard library, some of its compilation at run-time, and 
 few other bits. Among such things some of them can be added into D too).



methods in D has the potential to be confusing, with coding conventions I 
think it could work quite well.

The IDE is obviously a big plus and as such I wouldn't attempt a regular 
GUI-based Windows app in D myself, I find the IDE pretty unnecessary for 
console-based development - a decent debugger not-withstanding.

Run-time compilation can be frustrating - it obfuscates profiling and 
requires (as far as I'm aware) digital signing etc. to forcibly pre-compile 
for performance.


 Have you written few benchmarks to compare the performance of the garbage 

 Phobos)?



that it's performance is "lower than I would expect". Porting code from 
Delphi has resulting in typically neater, but slower code. Just the control 

machine code mean that D is basically guaranteed to be faster provided 
sufficient effort is put in if you know what I mean.

I suppose another thing that makes me look more favourable upon D is that my 
expectations are lower in certain areas. If a phobos method does something a 
bit strange I'm forgiving... if a .NET method which you expect to be 
thoroughly documented in the MSDN library throws an exception which is not 
in the list of exceptions that it should be able to throw, I get pretty 
annoyed =P
Mar 31 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Neil Vice:


Run-time compilation can be frustrating - it obfuscates profiling and requires
(as far as I'm aware) digital signing etc. to forcibly pre-compile for
performance.<


But it allows you to do some things that aren't easy to do with D (recently you
may have seen two libs to do similar things in D).




compiled directly to machine code mean that D is basically guaranteed to be
faster provided sufficient effort is put in if you know what I mean.<


That's a myth. I have personally found situations where that's very false. D
AAs and GC are sometimes slower or much slower, etc.

Bye,
bearophile
Mar 31 2008
parent "Neil Vice" <sardonicpresence gmail.com> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:fsqit4$67p$1 digitalmars.com...


compiled directly to machine code mean that D is basically guaranteed to 
be faster provided sufficient effort is put in if you know what I mean.<


 That's a myth. I have personally found situations where that's very false. 
 D AAs and GC are sometimes slower or much slower, etc.


My point was not that D is guaranteed to be faster out-of-the-box by any 

beyond a certain point you have to resort to writing a library in C for 

write this code directly in D.

If the built-in D GC is slower you can replace it; I believe Tango has 
already done this. Could you do this in .NET?

If the D AAs are slow you have the option to write whatever task-specific 
data structure you like that can be implemented in assembly if you wish. In 
.NET you are limited by the performance of the VM.



direct-to-machine-code compiler and a corresponding replacement 
standard-library, but this is a lot more work than writing your own AA 
template.
Mar 31 2008
prev sibling parent reply Helmut Leitner <leitner wikiservice.at> writes:
Neil Vice wrote:

 ...

 machine code mean that D is basically guaranteed to be faster 


No-one should write such a thing. Benchmarking is an empirical black art
and there are absolutely no guarantees whatsoever...

Helmut
Mar 31 2008
parent "Neil Vice" <sardonicpresence gmail.com> writes:
"Helmut Leitner" <leitner wikiservice.at> wrote in message 
news:fsql7g$cpr$1 digitalmars.com...

 Neil Vice wrote:

 ...

 to machine code mean that D is basically guaranteed to be faster


 No-one should write such a thing. Benchmarking is an empirical black art
 and there are absolutely no guarantees whatsoever...


That's like saying that the outcome is entirely non-deterministic. Just 
because the problem may be complex doesn't mean there are no guarantees.


allow less control than D, assuming the best-case scenario for both 
languages D will win out.

Alternatively I would have said that best-case C and D are probably 
equivalent as both languages can get incredibly close to assembler.

To be more specific, let's say you were to hand-code a routine in assembler 
for a specific architecture such that you had (ideally) obtained the optimal 
implementation. If D has embedded assembly support for the architecture then 
you can achieve the exact same result in D. If this support does not exist 
you could probably get quite close with a combination of intrinsics and 
careful (probably involving trial and error) implementation. I would suggest 
that, even with precompiled binaries, you would be very hard-pressed to
Mar 31 2008
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Scott S. McCoy:

 I'll take a second to plug my thoughts on array slicing.
 array[..] should be synonymous with array[0..$]


You can already do that: array[]


 array[5..] should be synonymous with array[5..$]/array[5..length]
 array[..5] should be synonymous with array[0..5].


That's equal to Python, where you can write: array[5:] array[:5]
Something very close is possible in Haskell too.

Bye,
bearophile
Mar 30 2008
parent reply "Scott S. McCoy" <tag cpan.org> writes:
On Sun, 2008-03-30 at 07:48 -0400, bearophile wrote:


 
 That's equal to Python, where you can write: array[5:] array[:5]
 Something very close is possible in Haskell too.
 



Right, I just think it's nicer than array[5..length] :-)

array[5..] and array[..5] seem to make perfect sense to me and get rid
of kludge like $.
Mar 30 2008
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 30/03/2008, Scott S. McCoy <tag cpan.org> wrote:

  array[5..] and array[..5] seem to make perfect sense to me and get rid of
 kludge like $.


But those constructions don't get rid of $ entirely.

Sure, you'd be able to write array[5..] instead of array[5..$]. But
you still wouldn't be able to write array[5..-1] instead of
array[5..$-1]. (Not so in Python, I believe).

So it only buys you the luxury of not having to type $ in one very
special case. In my view, that makes keeping it more consistent than
dropping it. (And come on - it's only one character!)
Mar 30 2008
parent reply Leandro Lucarella <llucax gmail.com> writes:
Janice Caron, el 30 de marzo a las 20:11 me escribiste:

 On 30/03/2008, Scott S. McCoy <tag cpan.org> wrote:

  array[5..] and array[..5] seem to make perfect sense to me and get rid of
 kludge like $.


 
 But those constructions don't get rid of $ entirely.
 
 Sure, you'd be able to write array[5..] instead of array[5..$]. But
 you still wouldn't be able to write array[5..-1] instead of
 array[5..$-1]. (Not so in Python, I believe).


In python this is array[5:-1], which seems a lot nicer to me...

I hope D some can do array[5..-1], array[..-4], array[..], etc. a la
Python.


 So it only buys you the luxury of not having to type $ in one very
 special case. In my view, that makes keeping it more consistent than
 dropping it. (And come on - it's only one character!)


Yes, only 1 character but it looks like an ugly hack to me. '$' has no
meaning except in array slices, and what not necessary anyway. I know it's
hard (impossible?) to get rid of it now, but I wanted to say it =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
22% of the time a pizza will arrive faster than an ambulance in Great-Britain
Mar 30 2008
next sibling parent "Scott S. McCoy" <tag cpan.org> writes:
On Sun, 2008-03-30 at 16:41 -0300, Leandro Lucarella wrote:


 
 In python this is array[5:-1], which seems a lot nicer to me...
 
 I hope D some can do array[5..-1], array[..-4], array[..], etc. a la
 Python.



Fwiw, this is a feature Python borrowed from Perl.  In Perl, a negative
index means "array length - Y".  But 5..-1 doesn't seem as pretty as 5..
I mean, if I didn't tell it where to go, where else is it going to go?
Inference is nice, we seem to all agree...I don't hear anyone
complaining about not having to specify their types in for-each
loops...so why not infer the beginning or end of the array, I mean...

if i say array[..5], where was I expecting to start other than the
beginning?



 

 So it only buys you the luxury of not having to type $ in one very
 special case. In my view, that makes keeping it more consistent than
 dropping it. (And come on - it's only one character!)


 
 Yes, only 1 character but it looks like an ugly hack to me. '$' has no
 meaning except in array slices, and what not necessary anyway. I know
 it's
 hard (impossible?) to get rid of it now, but I wanted to say it =)



I wouldn't think it'd be impossible.  D 2.0 is considered unstable.
Walter seems to be being careful not to make people too angry by
breaking their code.  My thoughts on that is "If the code you were
writing was important, it shouldn't have been in D 2 anyway since D 2
isn't done."  Although I appreciate that digital mars provides a
functional implementation of a totally in-development language
specification.  That's pretty cool beans.  People should be glad, not
bitch about stuff breaking.  You rarely get that type of luxury in other
languages.

Cheers,
    Scott S. McCoy
Mar 30 2008
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Leandro Lucarella:

 In python this is array[5:-1], which seems a lot nicer to me...


I know many languages, and in many situations I think Python has a good syntax
(like Python list comprehensions and generators, two things that I think D may
enjoy a LOT). But in this case I think D has chosen a better solution: if you
allow a syntax like [5:-1], then in every access to an array you have to
compute a modulus, or a sum, for the wrap around. ShedSkin does this, but in
tight loops on arrays this slows down the code (in ShedSkin there is a
compilation option to disable that, to increase running speed). For Python
that's not a big problem, because Python is designed to be the best for the
programmer first, and for the CPU then, but D is supposed to be fast almost as
C, and just adding a single $ character it avoids that slowdown, so I think
this is a really good compromise (that future languages will probably copy from
D).
The syntax array[..5] / array[5..] looks acceptable, but it allows you to avoid
just one char, so it's far from the top of the list of things I'd like to see
in D :-)

Bye,
bearophile
Mar 30 2008
parent reply Leandro Lucarella <llucax gmail.com> writes:
bearophile, el 30 de marzo a las 16:03 me escribiste:

 Leandro Lucarella:

 In python this is array[5:-1], which seems a lot nicer to me...


 
 I know many languages, and in many situations I think Python has a good syntax
(like Python list comprehensions and generators, two things that I think D may
enjoy a LOT). But in this case I think D has chosen a better solution: if you
allow a syntax like [5:-1], then in every access to an array you have to
compute a modulus, or a sum, for the wrap around. ShedSkin does this, but in
tight loops on arrays this slows down the code (in ShedSkin there is a
compilation option to disable that, to increase running speed). For Python
that's not a big problem, because Python is designed to be the best for the
programmer first, and for the CPU then, but D is supposed to be fast almost as
C, and just adding a single $ character it avoids that slowdown, so I think
this is a really good compromise (that future languages will probably copy from
D).


I really can't see any overhead in array[5..-1] being syntax sugar for
array[5..$-1]. I'm not talking about array[5..-1] returning an empty array
if the array.lenght is 3 for example (which is really nice too, but I
agree that the overhead could be ... polemic, so it might better suite
in the standard library).

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Una mujer en bicicleta, con sombrero de paja, es la más flagrante
violación a las leyes de la aerodinamia.
	-- Ricardo Vaporeso. 21 de Septiembre de 1917.
Mar 30 2008
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Leandro Lucarella wrote:

 bearophile, el 30 de marzo a las 16:03 me escribiste:

 Leandro Lucarella:

 In python this is array[5:-1], which seems a lot nicer to me...


 I know many languages, and in many situations I think Python has a good syntax
(like Python list comprehensions and generators, two things that I think D may
enjoy a LOT). But in this case I think D has chosen a better solution: if you
allow a syntax like [5:-1], then in every access to an array you have to
compute a modulus, or a sum, for the wrap around. ShedSkin does this, but in
tight loops on arrays this slows down the code (in ShedSkin there is a
compilation option to disable that, to increase running speed). For Python
that's not a big problem, because Python is designed to be the best for the
programmer first, and for the CPU then, but D is supposed to be fast almost as
C, and just adding a single $ character it avoids that slowdown, so I think
this is a really good compromise (that future languages will probably copy from
D).


 
 I really can't see any overhead in array[5..-1] being syntax sugar for
 array[5..$-1]. I'm not talking about array[5..-1] returning an empty array
 if the array.lenght is 3 for example (which is really nice too, but I
 agree that the overhead could be ... polemic, so it might better suite
 in the standard library).


Yeh, array[5..-1] wouldn't necessarily have any overhead, but how about 
array[5..a]?

--bb
Mar 30 2008
prev sibling next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Leandro Lucarella wrote:

 bearophile, el 30 de marzo a las 16:03 me escribiste:

 Leandro Lucarella:

 In python this is array[5:-1], which seems a lot nicer to me...


 I know many languages, and in many situations I think Python has a good syntax
(like Python list comprehensions and generators, two things that I think D may
enjoy a LOT). But in this case I think D has chosen a better solution: if you
allow a syntax like [5:-1], then in every access to an array you have to
compute a modulus, or a sum, for the wrap around. ShedSkin does this, but in
tight loops on arrays this slows down the code (in ShedSkin there is a
compilation option to disable that, to increase running speed). For Python
that's not a big problem, because Python is designed to be the best for the
programmer first, and for the CPU then, but D is supposed to be fast almost as
C, and just adding a single $ character it avoids that slowdown, so I think
this is a really good compromise (that future languages will probably copy from
D).


 
 I really can't see any overhead in array[5..-1] being syntax sugar for
 array[5..$-1]. I'm not talking about array[5..-1] returning an empty array
 if the array.lenght is 3 for example (which is really nice too, but I
 agree that the overhead could be ... polemic, so it might better suite
 in the standard library).
 


Except the mental overhead of interpreting -1 as array.length - 1.
Mar 30 2008
prev sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 31/03/2008, Leandro Lucarella <llucax gmail.com> wrote:

 I really can't see any overhead in array[5..-1] being syntax sugar for
  array[5..$-1].


You can't? Well, I can. Let me show you.

    struct MyArray
    {
        MyArray opSlice(int lower, int upper)
        {
            ...
        }
    }

    MyArray array;
    auto slice = array[5..-1];

This calls MyArray.opSlice(5, -1). Are you suggesting it should
instead call MyArray.opSlice(5, __dollar-1)? Can you not just see the
bug reports flying in?

And here's a second problem

    int[] array;
    int n = -1;

    slice1 = array[5..-1];
    slice2 = array[5..n];

You'd expect slice1 and slice2 to be the same, but in fact array[5..n]
will throw in a debug build, and cause a segfault in a release build.
Not good.
Mar 31 2008
prev sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 30/03/2008, Leandro Lucarella <llucax gmail.com> wrote:

  I hope D some can do array[5..-1], array[..-4], array[..], etc. a la
  Python.


No thanks. I don't want a runtime check slowing down all my array
accesses. array[5..$-1] can be identified as end-relative at
compile-time. Not so array[5..-1].

Worse, array[5..-1] might actually /mean/ "from 5 to minus one" (i.e.
it might be a bug). If so, under the current regime, the bug gets
found at bounds-checking time (in a debug build). If you suddenly make
it legal, the bug slips through.
Mar 30 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Scott S. McCoy wrote:

 array[5..] and array[..5] seem to make perfect sense to me and get rid 
 of kludge like $.


If $ were implicit, you couldn't do things like:

	array[5 .. $-3]
Mar 30 2008
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Sun, 30 Mar 2008 22:43:11 +0200, Walter Bright  
<newshound1 digitalmars.com> wrote:


 Scott S. McCoy wrote:

 array[5..] and array[..5] seem to make perfect sense to me and get rid  
 of kludge like $.


 If $ were implicit, you couldn't do things like:

 	array[5 .. $-3]



You could if it were only optional.

--Simen
Mar 30 2008
parent reply "Scott S. McCoy" <tag cpan.org> writes:
You also could if array[5 .. -3] implied length -3.

Similarly. array[-3] could imply array[array.length -3]...

But someone suggested against that, atleast for non-compile time
checking.  I would agree, for the non-literal instance that a negative
integer of -5 shouldn't result in magical figuring out if the element
needs to be pulled from the front or the back.  But the literal case
adds expressiveness, I think.

Cheers,
    Scott S. McCoy

On Sun, 2008-03-30 at 22:54 +0200, Simen Kjaeraas wrote:


 On Sun, 30 Mar 2008 22:43:11 +0200, Walter Bright  
 <newshound1 digitalmars.com> wrote:
 

 Scott S. McCoy wrote:

 array[5..] and array[..5] seem to make perfect sense to me and get rid  
 of kludge like $.


 If $ were implicit, you couldn't do things like:

 	array[5 .. $-3]


 
 
 You could if it were only optional.
 
 --Simen
Mar 30 2008
next sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Mon, 31 Mar 2008 00:26:10 +0200, Scott S. McCoy <tag cpan.org> wrote:


 You also could if array[5 .. -3] implied length -3.

 Similarly. array[-3] could imply array[array.length -3]...

 But someone suggested against that, atleast for non-compile time
 checking.  I would agree, for the non-literal instance that a negative
 integer of -5 shouldn't result in magical figuring out if the element
 needs to be pulled from the front or the back.  But the literal case
 adds expressiveness, I think.


T[int] foo;

What is foo[-3]?

And user-defined types with overloaded opIndex and opSlice.
Should [-X] work differently for them?

-- Simen
Mar 30 2008
parent reply "Scott S. McCoy" <tag cpan.org> writes:
The same thing foo[$-3] is now.

Whatever the heck that is.

:-)


On Mon, 2008-03-31 at 01:55 +0200, Simen Kjaeraas wrote:

 On Mon, 31 Mar 2008 00:26:10 +0200, Scott S. McCoy <tag cpan.org> wrote:
 

 You also could if array[5 .. -3] implied length -3.

 Similarly. array[-3] could imply array[array.length -3]...

 But someone suggested against that, atleast for non-compile time
 checking.  I would agree, for the non-literal instance that a negative
 integer of -5 shouldn't result in magical figuring out if the element
 needs to be pulled from the front or the back.  But the literal case
 adds expressiveness, I think.


 
 T[int] foo;
 
 What is foo[-3]?
 
 And user-defined types with overloaded opIndex and opSlice.
 Should [-X] work differently for them?
 
 -- Simen
Apr 11 2008
parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Fri, 11 Apr 2008 09:45:26 +0200, Scott S. McCoy <tag cpan.org> wrote:


 The same thing foo[$-3] is now.

 Whatever the heck that is.

 :-)


 On Mon, 2008-03-31 at 01:55 +0200, Simen Kjaeraas wrote:

 On Mon, 31 Mar 2008 00:26:10 +0200, Scott S. McCoy <tag cpan.org> wrote:


 You also could if array[5 .. -3] implied length -3.

 Similarly. array[-3] could imply array[array.length -3]...

 But someone suggested against that, atleast for non-compile time
 checking.  I would agree, for the non-literal instance that a negative
 integer of -5 shouldn't result in magical figuring out if the element
 needs to be pulled from the front or the back.  But the literal case
 adds expressiveness, I think.


 T[int] foo;

 What is foo[-3]?

 And user-defined types with overloaded opIndex and opSlice.
 Should [-X] work differently for them?

 -- Simen




I see. So I have an associative array foo, with indices possibly being
negative (int is signed), and I can't reach those due to negative indices
being wrapped around. Hardly a good thing, IMO.

My point is, there may be reasons to want to use negative indices, and
implicit $ will make that hard. Unless you suggest that to avoid that, I
should use [$-$-3]?

-- Simen
Apr 11 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Scott S. McCoy wrote:

 You also could if array[5 .. -3] implied length -3.


How would I do:

	array[5 .. foo($)]

?
Mar 30 2008
parent "Scott S. McCoy" <tag cpan.org> writes:
I don't think that's any fair, partially because I would have never
assumed that would even work.

you would say:

array[ 5 .. foo(array.length) ] naturally, and at the office in a code
review if I saw someone doing foo($) I would explicitly ask them to
change it to foo(array.length) anyway.

On Sun, 2008-03-30 at 19:04 -0700, Walter Bright wrote:

 Scott S. McCoy wrote:

 You also could if array[5 .. -3] implied length -3.


 
 How would I do:
 
 	array[5 .. foo($)]
 
 ?
Apr 11 2008
prev sibling next sibling parent BCS <ao pathlink.com> writes:
Reply to Scott,


 You also could if array[5 .. -3] implied length -3.
 
 Similarly. array[-3] could imply array[array.length -3]...
 


what about  "array[$/2]" or  "Fn(array[0..$/2]) + Fn(array[$/2..$])"
Mar 30 2008
prev sibling parent Georg Wrede <georg nospam.org> writes:
Scott S. McCoy wrote:

 You also could if array[5 .. -3] implied length -3.
 
 Similarly. array[-3] could imply array[array.length -3]...


I guess the problem you (and I guess quite a lot of people) ultimately 
have is, the $ looks like a after-thought, sticks in the eye in a 
language that otherwise doesn't use the $ too much, and if one is also 
used to some interpreted language it looks clumsy in this context.

Before $ got this role in D, there were months of (lively) discussion 
about the alternatives. Ultimately, this is short to type, has 
expressive power, is totally obvious as to the intent, and it is easy to 
spot a typo within the brackets.

So, it's not pretty, but to figure out a better alternative would need 
both hard work and luck. :-) And even then, one would have a hard sell 
in demonstrating the advantages, which would have to be significant. 
It's not like the $ issue is the easiest one to get really reopened.
Mar 31 2008