On Thu, 24 Jan 2013 09:47:32 +0100
Jacob Carlborg <doob@me.com> wrote:

> On 2013-01-24 06:16, Nick Sabalausky wrote:
> 
> > Heh, actually, case in point, take a look at my normal work setup:
> >
> > http://66.228.38.161/download/img/jobs-would-have-hung-employees-for-doing-this.jpg
> >
> > (Yes, I need to get a wireless keyboard/trackball ;) )
> 
> That's not a good work setup, in any way. Close the laptop and get a real, external monitor, or two.

I do, just not hooked up ATM. Been meaning to.

On Thu, 24 Jan 2013 09:52:38 +0100
Jacob Carlborg <doob@me.com> wrote:

> On 2013-01-24 00:16, Nick Sabalausky wrote:
> 
> > I'll certainly grant that, insofar as the written order is backwards from the execution order. I think the "ago" is that part that bugs me the most. It's too clever. I could live with "2.days", but I'd prefer "days(2)" since that looks like a type constructor, and "days" isn't a property of 2. Maybe "2.toDays()", but at that point I'd still rather just do the simpler "days(2)".
> 
> If you don't have "ago" how would you determine the differences compared to the opposite,

now - blah vs. now + blah

> which looks like this in Ruby on Rails:
> 
> time = 2.days.from_now
> 
> "2" is the duration, "days" is the unit and ago/from_now indicates if it's positive or negative.
> 

On 01/24/2013 04:02 AM, Nick Sabalausky wrote:
> On Thu, 24 Jan 2013 00:45:02 +0100
> Timon Gehr <timon.gehr@gmx.ch> wrote:
>
>> On 01/23/2013 11:46 PM, Nick Sabalausky wrote:
>>> On Wed, 23 Jan 2013 21:29:14 +0100
>>> ...
>>> Don't know if it's filed, but yea: Optional empty-parens and
>>> the practice of conflating properties with functions is riddled with
>>> corner-cases. We can either try to patch over these corner cases
>>> with increasingly detailed new rules,
>>
>> What are those "new" rules? The rules we already have are sufficient.
>> Now the compiler needs to implement them properly.
>>
>
> Andrei was just suggesting this:
>
> http://forum.dlang.org/post/kdpg5n$2qt2$1@digitalmars.com
>

This rule is not new. Also, it is about @property.

>>> as Andrei is proposing, or we
>>> can just accept "the writing on the wall" (if you'll pardon my
>>> 80's-ism) that properties != functions.
>>>
>>
>> That is not even the point of this discussion.
>>
>> a.map!(a=>foo(a,b).map!(a=>2*a)())().days().ago().writeln()
>>
>
> First of all, spacing helps:
>

I do not see that. It just blows up the code even more.

> a.map!( a => foo(a,b).map!(a=>2*a)() )().days().ago().writeln()
>
> So does not trying to cram everything into a one-liner:
>
> auto descriptiveName = a => foo(a,b).map!(a=>2*a)();
> a.map!descriptiveName().days().ago().writeln()
>

This is not valid code.

> And then there's a few () in there, but not only do I fail to see how
> those hurt anybody, they make perfect sense since "days", "ago" and
> "writeln" are not data access, they're actions (even if maybe a little
> too cutely-named in the case of "ago").
>

There is no universal rule that says () has any relevance for this.

(Arguably, it does not make any sense to distinguish concepts like 'data access' and 'action' syntactically. What is this distinction anyway?)

> (Of course, I'd question the meaningfulness and feasability of passing
> the "days" type constructor a range instead of a scalar, but I get that
> that's beside the point ;) )
>

No, that is spot on. I didn't even notice, which is partly owed to the paren spam.

On 01/24/2013 10:52 AM, Nick Sabalausky wrote:
> now - blah vs. now + blah

Now we have caught you.

On 2013-01-24 10:11, monarch_dodra wrote:

> IMO, it not currently doing so is a limitation

Yes, that's what I'm saying. You cannot swap properties and fields willy nilly using the current implementation.

-- 
/Jacob Carlborg

On 2013-00-24 05:01, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> On Wed, 23 Jan 2013 22:59:38 +0100
> "monarch_dodra" <monarchdodra@gmail.com> wrote:
>>
>> --------
>> IMO: We should be able to keep the optional parenthesis for all
>> functions (except maybe those that return delegates).
>
> I'm not a fan of that as I think the need for special-casing of
> functions returning delegates is not worth what I still don't see as a
> benefit.
>
> Side note: I know at least one person here likes this [ ;) ], but I
> really hate code like:
>
> foo.doStuff;
> foo.makeFizzBar;
> foo.updateBlorg;
>
> Have to do a double-take every time. Just looks like a bunch of
> no-ops, and sets off mental red flags every single time.

Amen!

I do understand Adam's view that foo.bar(10).baz(5) be allowed,
but that could be written with(foo){bar=10;baz=5}. Admittedly more
verbose, but also clearer.

On that topic, I occasionally do miss C#'s object initializers,
particularly because they could allow for immediate creation of many
const and immutable values.

-- 
Simen

On Thursday, 24 January 2013 at 05:16:32 UTC, Nick Sabalausky wrote:
> I think that shows how different editors or even just personal
> typing styles can affect our coding style. For me, I'll do stuff like:


Aye, I think this applies to my non-caring about identifier name length too - I use tab completion in my editor.

I've tried some of those auto parens things, and it just confuses me. I guess I could get used to it (I recently started playing one of those newer shooter games. I come from Perfect Dark on the N64, so I'm used to what Halo called "legacy controls". The new controls were totally unusable to me.... but I was forced to stick with it for a while and now kinda am ok. I just hope it hasn't ruined my aptitude at PD controls! Perfect Dark is still the best shooter ever.).

But still, it isn't that big of a deal, my way works very well 99.9% of the time.


> Probably not surprising that I avoid trying to code on anything but a full-size keyboard with a proper section of <arrows, del,
> home, end, pgup, pgdn>, because coding on, say, a laptop
> keyboard (even one with a numpad) is a huge slowdown.

Yeah, I spend some time on a laptop (a little 12" one too) and it isn't as nice as the real keyboard, but I got one with a decent key placement and remapped some of the keys to fit the muscle memory anyway, so it isn't that bad.

The worst thing about my laptop keyboard is the 9 key doesn't work right and needs extra force. Since that's also (, ugh! But I'm cheap so whatever.

> Heh, actually, case in point, take a look at my normal work setup:

lol, I got one of those ipads as a gift last year. I found it totally useless except for the angry birds and watching some video streams, i.e. not work at all.

But, I wanted a computer in my other room last week. My laptop is never at home, so I looked into buying something.

And my decision was sure to be painful to Steve Jobs: I bought an off brand usb thingy for the pad, and a full sized (Microsoft brand LOL) keyboard. Combined with an ssh app for the pad thingy (death to lowercase i), it became almost useful.

So I was only in for $20 and now have a halfway usable portable computer. No mouse though. Yes arrow keys (thank god, the morons at Apple refuse to put them in, which makes this thing utterly useless for anything other than their small set of sanctioned activities. OK, that apparently serves millions of people and turns an enormous profit, but that doesn't matter to /me/!). But, surprisingly, no to home and end!

Maybe it is just mapped wrong though, I haven't looked into the details.


Still though, 3/4 of a real keyboard is lightyears beyond the touch nonsense, and the price for the hack beat the crap out of buying a real computer.

> Geez, we still don't have that?

We spend too much time arguing over optional parenthesis!

On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei Alexandrescu wrote:
> We need a good DIP on this. UFCS has destroyed all arguments in favor of requiring parens. There is no question we must do this. Anyone inclined toward writing a detailed DIP?
>

Let me strongly disagree. Language feature should never be introduced where library solution is possible.

And library solution is possible. And opDispatch makes it possible.

On Thursday, 24 January 2013 at 14:25:18 UTC, deadalnix wrote:
> On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei Alexandrescu wrote:
>> We need a good DIP on this. UFCS has destroyed all arguments in favor of requiring parens. There is no question we must do this. Anyone inclined toward writing a detailed DIP?
>>
>
> Let me strongly disagree. Language feature should never be introduced where library solution is possible.
>

C has strings as a concept and C++ as a library solution. Which strings are better: C, C++ or D?

On Thursday, 24 January 2013 at 14:53:49 UTC, Maxim Fomin wrote:
> On Thursday, 24 January 2013 at 14:25:18 UTC, deadalnix wrote:
>> On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei Alexandrescu wrote:
>>> We need a good DIP on this. UFCS has destroyed all arguments in favor of requiring parens. There is no question we must do this. Anyone inclined toward writing a detailed DIP?
>>>
>>
>> Let me strongly disagree. Language feature should never be introduced where library solution is possible.
>>
>
> C has strings as a concept and C++ as a library solution. Which strings are better: C, C++ or D?

D string string is not builtin. string is merely a thing in D.

D have builtin slices, which is a generic feature that is used with whatever you want.