On Thu, Sep 25, 2014 at 08:40:50PM +0000, eles via Digitalmars-d wrote:
> On Thursday, 25 September 2014 at 15:58:11 UTC, eles wrote:
> >On Thursday, 25 September 2014 at 13:50:10 UTC, Jacob Carlborg wrote:
> >>On 25/09/14 09:38, Atila Neves wrote:
> >>
> 
> >Andrei spoke about an idiom that they constantly use at Facebok, because there aparrently nobody runs *main and unittests*. So they keep a special empty main for the -unittest version.
> 
> This idiom here:
> 
> http://forum.dlang.org/post/ljr5n7$1leb$1@digitalmars.com
> 
> "Last but not least, virtually nobody I know runs unittests and then main. This is quickly becoming an idiom:
> 
> version(unittest) void main() {}
> else void main()
> {
>    ...
> }
> 
> I think it's time to change that. We could do it the non-backward-compatible way by redefining -unittest to instruct the compiler to not run main. Or we could define another flag such as -unittest-only and then deprecate the existing one.

Please don't deprecate the current -unittest. I regularly find it very useful when in the code-compile-test cycle. I'm OK with introducing -unittest-only for people who want it, but I still like using the current -unittest.


T

-- 
Making non-nullable pointers is just plugging one hole in a cheese grater. -- Walter Bright

On 9/25/14, 2:03 PM, eles wrote:
> On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote:
>
>> lack of attention paid to tightening up what we've already got and
>> deprecating old stuff that no one wants any more.  And inconsistency
>> in how things work in the language.
>
> The feeling that I have is that if D2 does not get a serious cleanup at
> this stage, then D3 must follow quickly (and such move will be
> unstoppable), otherwise people will fall back to D1 or C++next.

I'm not sharing that feeling at all. From that perspective all languages are in need of a "serious cleanup". -- Andrei

On 9/25/14, 2:10 PM, eles wrote:
> On Thursday, 25 September 2014 at 21:03:24 UTC, eles wrote:
>> On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote:
>>
>
> BTW, am I the only one whose eyes/ears are suffering when reading this:
>
> std.algrithm
>
> "he stripLeft function will strip the front of the range, the stripRight
> function will strip the back of the range, while the strip function will
> strip both the front and back of the range. "
>
> Why not, for God's sake, stripFront and stripBack?

Because they are called stripLeft and stripRight. -- Andrei

On Thursday, 25 September 2014 at 22:49:06 UTC, Andrei Alexandrescu wrote:
> On 9/25/14, 2:10 PM, eles wrote:
>>
>> Why not, for God's sake, stripFront and stripBack?
>
> Because they are called stripLeft and stripRight. -- Andrei

Psh, they should be called stripHead and stripFoot.  Or alternately, unHat and unShoe.

On Thursday, 25 September 2014 at 22:56:56 UTC, Sean Kelly wrote:
> On Thursday, 25 September 2014 at 22:49:06 UTC, Andrei Alexandrescu wrote:
>> On 9/25/14, 2:10 PM, eles wrote:
>>>
>>> Why not, for God's sake, stripFront and stripBack?
>>
>> Because they are called stripLeft and stripRight. -- Andrei
>
> Psh, they should be called stripHead and stripFoot.  Or alternately, unHat and unShoe.

stripLady and stripGentleman?...

On Thursday, 25 September 2014 at 13:49:00 UTC, Andrei Alexandrescu wrote:
> I've recently used Rust a bit and the curse of D users as of 6-7 years ago reached me: most code I download online doesn't compile for obscure reasons, it's nigh impossible to figure out what the fix is from the compiler error message, searching online finds outdated documentation that tells me the code should work, and often it's random name changes (from_iterator to from_iter and such, or names are moved from one namespace to another).

That's more than a bit unfair. Rust's developers have made it abundantly clear that things will keep changing until version 1.0. If you want to play with some Rust that's guaranteed to work, go to

http://www.rust-ci.org

and find a bit code that interests you which isn't failing, and then download the nightly. The docs on the Rust home page are either for a fixed version (0.11.0) or the nightly. Let's wait for a bit of time after 1.0 is out before you critique the annoying changes; they deliberately are developing in the open to get community input and avoid getting stuck with too many mistakes (though it looks like they are stuck with C++ template syntax, ugh!). So far, I haven't found it too hard to update code, and they've been good at marking breaking changes as breaking changes, which can be searched for with git.

In the case of D, the main D2 book was published 4 years ago and that should correspond to Rust 1.0 or even later, since D already had a D1 to  shake out the mistakes and bad namings. That's gone perfectly, with no code breakage between releases during those four years, right?

On Thursday, 25 September 2014 at 22:48:12 UTC, Andrei Alexandrescu wrote:
> On 9/25/14, 2:03 PM, eles wrote:
>> On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote:
>>
>>> lack of attention paid to tightening up what we've already got and
>>> deprecating old stuff that no one wants any more.  And inconsistency
>>> in how things work in the language.
>>
>> The feeling that I have is that if D2 does not get a serious cleanup at
>> this stage, then D3 must follow quickly (and such move will be
>> unstoppable), otherwise people will fall back to D1 or C++next.
>
> I'm not sharing that feeling at all. From that perspective all languages are in need of a "serious cleanup". -- Andrei

Those *all* languages, at least some of them, have good excuses (C++'s roots in C and the great advantage that is able to compile C code too, to some extent - history is on his side) and powerful driving factors (the whole might of Oracle and Microsoft). And, most of all, they already have a fair share of the market.

And they served a lot of users quite well and those users aren't ready to drop them quite easily for what happens to be the cool kid of the day in the programming language world.

D has to provide quality in order to compensate for the( lack of the)se factors.

On Thursday, 25 September 2014 at 23:04:55 UTC, eles wrote:
> On Thursday, 25 September 2014 at 22:56:56 UTC, Sean Kelly wrote:
>> On Thursday, 25 September 2014 at 22:49:06 UTC, Andrei Alexandrescu wrote:
>>> On 9/25/14, 2:10 PM, eles wrote:
>>>>
>>>> Why not, for God's sake, stripFront and stripBack?
>>>
>>> Because they are called stripLeft and stripRight. -- Andrei
>>
>> Psh, they should be called stripHead and stripFoot.  Or alternately, unHat and unShoe.
>
> stripLady and stripGentleman?...

Ah, now this thread is going to interesting places! :P

On Thursday, 25 September 2014 at 22:49:06 UTC, Andrei Alexandrescu wrote:
> On 9/25/14, 2:10 PM, eles wrote:
>> On Thursday, 25 September 2014 at 21:03:24 UTC, eles wrote:
>>> On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote:
>>>
>>
>> BTW, am I the only one whose eyes/ears are suffering when reading this:
>>
>> std.algrithm
>>
>> "he stripLeft function will strip the front of the range, the stripRight
>> function will strip the back of the range, while the strip function will
>> strip both the front and back of the range. "
>>
>> Why not, for God's sake, stripFront and stripBack?
>
> Because they are called stripLeft and stripRight. -- Andrei

One day you will need to call this guy here:

http://dconf.org/2014/talks/meyers.html

He will say: "I told you so. At DConf."

On Thu, Sep 25, 2014 at 10:56:55PM +0000, Sean Kelly via Digitalmars-d wrote:
> On Thursday, 25 September 2014 at 22:49:06 UTC, Andrei Alexandrescu wrote:
> >On 9/25/14, 2:10 PM, eles wrote:
> >>
> >>Why not, for God's sake, stripFront and stripBack?
> >
> >Because they are called stripLeft and stripRight. -- Andrei
> 
> Psh, they should be called stripHead and stripFoot.  Or alternately, unHat and unShoe.

Nah, they should be behead() and amputate().


T

-- 
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- D. Knuth