May 11, 2012
On Friday, May 11, 2012 22:01:33 Era Scarecrow wrote:
> I remember reading from that book a bit on the ranges, and it all made wonderful sense when I did. That was something like a year ago, now I can't remember anything on it except it was good. Not having a good link to it does hinder your work quite a bit.

http://ddili.org/ders/d.en/ranges.html

- Jonathan M Davis
May 11, 2012
On 12-05-2012 00:05, Mehrdad wrote:
> On Friday, 11 May 2012 at 21:58:02 UTC, Jonathan M Davis wrote:
>> Then you do
>>
>> bool fun() { return cast(bool)(foo in bar); }
>>
>
> cast() scares the **** out of me

bool fun() { return !!(foo in bar); }

*flees*

-- 
- Alex
May 11, 2012
On Friday, 11 May 2012 at 22:11:21 UTC, Alex Rønne Petersen
wrote:
> On 12-05-2012 00:05, Mehrdad wrote:
>> On Friday, 11 May 2012 at 21:58:02 UTC, Jonathan M Davis wrote:
>>> Then you do
>>>
>>> bool fun() { return cast(bool)(foo in bar); }
>>>
>>
>> cast() scares the **** out of me
>
> bool fun() { return !!(foo in bar); }
>
> *flees*

lol

May 11, 2012
On Friday, 11 May 2012 at 21:55:37 UTC, akaz wrote:
>> What started out as C with classes started acquiring this feature and
>> that feature until the whole thing is just a haphazard heap of
>> misfitting self-contradictory pieces, which requires an enormous amount
>> of essentially-arbitrary rules just to clarify something as simple as,
>> for example, automatic type conversions.
>
> Partially, this also can be told about D, too. It started as a cleaner C++ (I think) and grew up a bit complicated.
>
> Before arguing the contrary, please remember that C++ looks not complicated to Stroustrup.
>
> Maybe simply addressing the most bitter drawbacks and inconsistencies of C++ (and when I say that, I say notably syntax stupidities, *then* conceptual stupidities) was enough for, let's say, D_v1. Then, more, for D_v2. Maybe trying to address too much at once?
>
> My feeling (I tried to port and work something in D) is that it is a good language. But a complicate one and the learning time tends to be limited today.
>
> C caught in the first place for its simplicity. Java, too ("hey, no pointers!"). Annotations and other hell were added later, *after* the naguage got assimilated. C# too ("hey! C++ made *simpler*!"). Then it was C#2, 3, 4 etc. True, C++ grew up a complicated beast, but *gradually*. At the beginning, it was not.
>
> D does not have that gradualism in growing complicated. Not for its developers, but for its (mass) users.

There is no arguing that D is a big and complex language. If it
wasn't, there wouldn't be huge discussions here about
interactions between features. It's complex because there is so
many new concepts to assimilate for newcomers from other
languages. The former Java programmers will have to face advanced
concepts coming from C++, the former C++ programmers will learn
to master concepts coming from Python and functional languages,
and former Python programmers will have to face lots of hurdles
associated to static languages. So basically, everyone has a
different learning curve.
I believe it takes no less than a year of full time programming
to become a proficient C++ programmer (by proficient, I mean a
programmer who doesn't fall in all the traps that the language
offers, and therefore spends more time coding than debugging). I
can't tell for D, I believe D is a net gain for C++ programmers,
but still a big investment.
May 11, 2012
On 05/11/2012 11:57 PM, Jonathan M Davis wrote:
>
> Then you do
>
> bool fun() { return cast(bool)(foo in bar); }
>
> It's not a big deal at all.

I didn't claim it was. Still, most issues people seem to have with D are trivial syntactic ones.

> It's just that if you expect in to return bool
> rather than a pointer, you're going to be surprised at what happens when you
> write a function like that rather than use it in an if condition.
> But since the documentation clearly states that it returns a pointer, it shouldn't
> really surprise anyone

I was surprised when I read the relevant parts of the documentation.

> - unless they failed to read either the documentation
> or TDPL and go completely off of what they _think_ the code should mean without
> actually reading anything which would teach them the language (which is a bad
> idea anyway).
>

Well I fully agree with that last point (having read the entire language documentation before the first attempt to install the compiler), but

1. that is perhaps not how the 'average programmer' works. it seems to
   be the case that many programmers who fail to rtfm blame the tool.
   (bringing up fuzzy terms like 'intuitive' to defend their pov)

2. 'in' is certainly a very non-descriptive name for what it does.
   It is similar to eg. naming subtraction '<'.

3. why are we always discussing syntax on this NG?
May 11, 2012
On Fri, May 11, 2012 at 05:27:11PM -0400, Nick Sabalausky wrote:
> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.597.1336760569.24740.digitalmars-d@puremagic.com...
> >
> > Templates are stencils for generating code. There's nothing confusing about that, unless you try to shoehorn them into a preconceived mental model of functions that take parameters and return something.
> >
> > Granted, proper tutorials need to be written and put in a prominent place so that newbies start on the right footing.
> >
> 
> https://semitwist.com/articles/article/view/template-primer-in-d
> 
> Written. It'd just need to be linked from somewhere, or copied somewhere.
[...]

Ah, I remember that. Yes, we do need to link to this from somewhere prominent, so that newbies have a higher chance of reading it *before* they decide to dive off the 3-storey diving board into std.algorithm.


T

-- 
It's amazing how careful choice of punctuation can leave you hanging:
May 11, 2012
On 05/12/2012 12:05 AM, Mehrdad wrote:
> On Friday, 11 May 2012 at 21:58:02 UTC, Jonathan M Davis wrote:
>> Then you do
>>
>> bool fun() { return cast(bool)(foo in bar); }
>>
>
> cast() scares the **** out of me

cast(bool) is peaceful.
May 11, 2012
On Friday, 11 May 2012 at 21:46:55 UTC, Nick Sabalausky wrote:
> "Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message
> news:op.wd5o86s3eav7ka@steves-laptop...
> On Fri, 11 May 2012 13:47:05 -0400, Alex Rønne Petersen
> <xtzgzorex@gmail.com> wrote:
>>>
>>> Complicated language structure? Long compilation times?
>>
>>I can attest that on certain types of projects (i.e. template heavy), D's lightning fast compilation time goes out the window.  It has improved greatly, but there are still some improvements that can be made.
>>
>>For instance, dcollections, which is about 10kloc takes 17 seconds to compile all the unit tests.  It used to be well over a minute, till walter changed a linear lookup to a hash lookup on the symbol table.  There's an outstanding issue which is similar still in bugzilla:
>
> Meh, that's still nothing compared to C++. The sample games included with
> Marmalade and the Marm-based IwGame engine take *serveral* minutes to
> compile - and those are just sample programs!
>
> Template-heavy projects don't throw D's lightning fast compilation times out
> the window, it just makes them less lightning-like. It's still an order of
> magnature faster than equivalent, or even merely similar, C++.

I remember g++ taking dozens of minutes on a SINGLE compilation unit on FreeFEM++, a very heavily templated project. Large C++ projects with lots of templates can take several hours to compile. So one has to be very careful with libraries like Boost on large projects, compilation times can explode.
May 11, 2012
On 05/11/2012 10:29 PM, Jonathan M Davis wrote:
> On Friday, May 11, 2012 21:02:46 Alex Rønne Petersen wrote:
>> On 11-05-2012 20:34, Mehrdad wrote:
>>> On Friday, 11 May 2012 at 18:25:17 UTC, Jonathan M Davis wrote:
>>>>> Actually, that is a WAT even for somebody coming from C/C++.
>>>>
>>>> Really? That's pretty much exactly what I would have expected, and it
>>>> would
>>>> really suck if it returned a bool. It's like what you get with find on
>>>> std::map, only it's a pointer instead of an iterator.
>>>>
>>>> - Jonathan M Davis
>>>
>>> Again, try to see it from the perspective of a Python user, not a
>>> C++ user.
>>
>> Speaking of which, 'in' on arrays.........
>>
>> *hint hint*
>
> Except that it would break the generally expected algoritmic complexity of in,
> so it'll never happen ( O(n) for arrays, whereas the worst case that would be
> acceptable would be O(lg n) - e.g. what a binary tree could achieve).
>
> - Jonathan M Davis

The main use case I see is replacing tedious

if(foo == 'a' || foo == 'b' || foo == 'c' || foo == 'd') { ... }

with

if(foo in "abcd") { .... }

And here the counter-argument cannot apply, because the operation is in O(1).
May 11, 2012
On Sat, May 12, 2012 at 12:43:00AM +0200, Timon Gehr wrote:
> On 05/11/2012 10:29 PM, Jonathan M Davis wrote:
[...]
> >Except that it would break the generally expected algoritmic
> >complexity of in, so it'll never happen ( O(n) for arrays, whereas
> >the worst case that would be acceptable would be O(lg n) - e.g. what
> >a binary tree could achieve).
> >
> >- Jonathan M Davis
> 
> The main use case I see is replacing tedious
> 
> if(foo == 'a' || foo == 'b' || foo == 'c' || foo == 'd') { ... }
> 
> with
> 
> if(foo in "abcd") { .... }

I always use this idiom:

	if ("abcd".canFind(foo)) { ... }


T

-- 
It only takes one twig to burn down a forest.