Jonathan M Davis Wrote:

> On Thursday, March 08, 2012 20:42:31 H. S. Teoh wrote:
> > On Thu, Mar 08, 2012 at 07:07:43PM -0500, Jonathan M Davis wrote:
> > > On Thursday, March 08, 2012 12:10:07 H. S. Teoh wrote:
> > > > IMO, making all abbreviations in Phobos consistent would be a big step forward.
> > > 
> > > You know, people keep saying that the abbreviations are inconsistent, but I don't buy that. _What_ abbreviations are inconsistent?
> > 
> > [...]
> > 
> > My comment was referring specifically to the pull request that adds "secs" as an alternative for "seconds". From what Walter said, he seems to be against any renaming changes, so any existing inconsistencies that we might find seems likely to be rejected as well.
> > 
> > But at the end of the day, this *is* just bikeshedding, so perhaps it's not worth spending so much time and energy on. People will get used to the quirky names eventually, and life goes on. *shrug*
> 
> I think that most of the major issues with inconsistencies have been fixed. Sure, there may be a few left, but the longer that they're there, the more costly it is to fix them. And D is reaching the point where it needs to be stable. Constantly tweaking the standard library just doesn't cut it. I made quite a few changes to try and fix inconsistencies (such as function names which weren't camelcased like they were supposed to be), and that was painful enough, and engendered plenty of complaints in spite of the fact that there were quite a few people arguing for fixing the names to make Phobos consistent.
> 
> I really don't think that Phobos is really any more quirky or inconsistent than your average standard library. It's not perfect, but it isn't particularly inconsistent either. We'll continue to make improvement to it (primarily by adding new stuff), but it's increasingly costly to make breaking changes. And, on the whole, it's not like what we have is horrible. The biggest problems involve whole modules (which are generally older) which need to be redesigned, and those will happen. But minor stuff like tweaking function names doesn't really buy us enough to be worth it anymore. If a function changes sufficiently to merit a full replacement, then maybe we can change its name and phase out the old one (e.g. if we change the functions in std.string which take patterns to take regexes instead), but changing a name to change a name just isn't worth it when we're trying to provide a serious offering with D and Phobos. We're too far along.
> 
> - Jonathan M Davis

make breaking changes at the same time provide a change list and provide a automatically batch changes the tools of third - party source code.

good luck

dolive

"Alix Pexton" <alix.DOT.pexton@gmail.DOT.com> wrote in message news:jjcn41$2g4g$1@digitalmars.com...
>
> and I have a theory that poetic languages would be good for programming in.
>

http://shakespearelang.sourceforge.net/

Hello World: http://shakespearelang.sourceforge.net/report/shakespeare/shakespeare.html#sec:hello

"Ary Manzana" <ary@esperanto.org.ar> wrote in message news:jjd21r$6ni$1@digitalmars.com...
>
> Sample Ruby session:
>
> > irb
> ruby-1.8.7-p352 :001 > [1, 2, 3].count
>  => 3
> ruby-1.8.7-p352 :002 > [1, 2, 3].length
>  => 3
> ruby-1.8.7-p352 :003 > [1, 2, 3].size
>  => 3
>
> I never saw *anyone* complaining about this. When you write, you choose whatever is convenient to you (whatever comes to your mind first). When you read it, it's understandable. Nobody wonders "why didn't he wrote 'length' instead of 'size'", because the meaning is clear.

I would wonder what the subtle distinction is. FWIW.

On Friday, March 09, 2012 10:01:19 Brad Anderson wrote:
> On Fri, Mar 9, 2012 at 1:46 AM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:
> > On Friday, March 09, 2012 09:33:20 deadalnix wrote:
> > > Le 07/03/2012 02:00, F i L a écrit :
> > > > I personally find it much easier to remember and use longer, more
> > > > sentance-like method names. However, Jonathan and others obviously
> > > > feel
> > > > more comfortable writing with a high level of abbreviation, which they
> > > > justify rather well. Still, if D's goal is to gain popularity, I think
> > > > it should take notices of other rising languages like C#.
> > > > 
> > > > The problem with making any change to Phobos is backwards
> > 
> > compatibility.
> > 
> > > We just need a politic for the change. IE: make the old name a warning, then deprecated, then remove it. Spread the process to a year or so.
> > 
> > We're not changing symbol names without a good reason. Yes, there's a deprecation process that allows us to change them if we need to, but it's still disruptive.
> > 
> > - Jonathan M Davis
> 
> The "secs" and "seconds" inconsistency is something I've seen people in IRC
> hit and complain about on several occasions. The dur!"seconds"(1) syntax
> I've seen complained about or confusion over on both IRC and on reddit by
> active and potential users. While I don't feel particularly strong about
> these issues I feel I should point out that actual users are hitting them
> and the issues bug them enough that they feel the need to
> complain publicly. Changes must be made with care but the former issue on
> inconsistency, I would argue, is a bigger issue than, say, the current
> symbol deprecation/replace of toISOExtendedString (though I don't know the
> history of the decision to make the change).
> 
> There shouldn't be two ways of expressing the exact same thing so the "secs"/"seconds" should be a substitute and deprecate process rather than just a simple alias if it were made. It looks like it's been rejected already, though, which is unfortunate. phobos is still a young library (or at least parts of it, like datetime, are) and so these types of wart removal could be made with limited disruption to current users.

As I explained in the pull request, if we switched to secs, it would just create a different set of inconsistencies:

https://github.com/D-Programming-Language/druntime/pull/173

There would just be a different set of complaints if seconds were changed to secs. No matter what we do here, we lose. Someone's going to be complaining. There is no perfect solution.

And while the library is young, it really needs to be stabilizing given that we want D to be real player in the programming world, and there is increasing resistance to changing it - especially from Walter and Andrei. If a breaking change is made, the change needs to be a clear win. And while using secs would certainly please some people, it would create it's own set of problems, so it's not at all a clear win IMHO.

- Jonathan M Davis

On Fri, Mar 09, 2012 at 01:29:03PM -0500, Nick Sabalausky wrote:
> "Alix Pexton" <alix.DOT.pexton@gmail.DOT.com> wrote in message news:jjcn41$2g4g$1@digitalmars.com...
> >
> > and I have a theory that poetic languages would be good for programming in.
> >
> 
> http://shakespearelang.sourceforge.net/
> 
> Hello World: http://shakespearelang.sourceforge.net/report/shakespeare/shakespeare.html#sec:hello
[...]

+1. I've seen that one before, but it cracks me up every time. Using insults to represent negative numbers and praises to represent positive numbers is just hilarious.

What would be really funny is if you wrote an actual play (with actual plot and dramatic buildup) that also does something useful.


T

-- 
If you think you are too small to make a difference, try sleeping in a closed room with a mosquito. -- Jan van Steenbergen

On Fri, Mar 09, 2012 at 01:34:38PM -0500, Nick Sabalausky wrote:
> "Ary Manzana" <ary@esperanto.org.ar> wrote in message news:jjd21r$6ni$1@digitalmars.com...
> >
> > Sample Ruby session:
> >
> > > irb
> > ruby-1.8.7-p352 :001 > [1, 2, 3].count
> >  => 3
> > ruby-1.8.7-p352 :002 > [1, 2, 3].length
> >  => 3
> > ruby-1.8.7-p352 :003 > [1, 2, 3].size
> >  => 3
> >
> > I never saw *anyone* complaining about this. When you write, you choose whatever is convenient to you (whatever comes to your mind first). When you read it, it's understandable. Nobody wonders "why didn't he wrote 'length' instead of 'size'", because the meaning is clear.
> 
> I would wonder what the subtle distinction is. FWIW.
[...]

Me too. I would assume that 'count' counts array elements whereas 'size' counts the number of bytes the array uses up.

IMAO, this sort of "write your mind and somehow it just works" thing only encourages lazy programming (guessing what something does without knowing for sure, and copy-n-pasting code without understanding it, which leads to bit rot and hideous patchwork code that houses all sorts of subtle bugs and corner-case failures).


T

-- 
Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at it. -- Pete Bleackley

On 09/03/2012 18:29, Nick Sabalausky wrote:
> "Alix Pexton"<alix.DOT.pexton@gmail.DOT.com>  wrote in message
> news:jjcn41$2g4g$1@digitalmars.com...
>>
>> and I have a theory that poetic languages would be good for programming
>> in.
>>
>
> http://shakespearelang.sourceforge.net/
>
> Hello World:
> http://shakespearelang.sourceforge.net/report/shakespeare/shakespeare.html#sec:hello
>
>

Not quite what I had in mind, but still amusing ^^

A...

On 3/9/12 4:09 PM, H. S. Teoh wrote:
> On Fri, Mar 09, 2012 at 01:34:38PM -0500, Nick Sabalausky wrote:
>> "Ary Manzana"<ary@esperanto.org.ar>  wrote in message
>> news:jjd21r$6ni$1@digitalmars.com...
>>>
>>> Sample Ruby session:
>>>
>>>> irb
>>> ruby-1.8.7-p352 :001>  [1, 2, 3].count
>>>   =>  3
>>> ruby-1.8.7-p352 :002>  [1, 2, 3].length
>>>   =>  3
>>> ruby-1.8.7-p352 :003>  [1, 2, 3].size
>>>   =>  3
>>>
>>> I never saw *anyone* complaining about this. When you write, you
>>> choose whatever is convenient to you (whatever comes to your mind
>>> first). When you read it, it's understandable. Nobody wonders "why
>>> didn't he wrote 'length' instead of 'size'", because the meaning is
>>> clear.
>>
>> I would wonder what the subtle distinction is. FWIW.
> [...]
>
> Me too. I would assume that 'count' counts array elements whereas 'size'
> counts the number of bytes the array uses up.

Indeed, count can be used to count elements:

ruby-1.8.7-p352 :002 > [1, 2, 3, 3, 3].count 3
 => 3
ruby-1.8.7-p352 :004 > [1, 2, 3, 3, 3].count &:odd?
 => 4
ruby-1.8.7-p352 :005 > [1, 2, 3, 3, 3].count { |x| x <= 2 }
 => 2

Just that when you use it without arguments it just counts everything.

size is an alias of length. But count just work as an alias as well, without arguments.

>
> IMAO, this sort of "write your mind and somehow it just works" thing
> only encourages lazy programming (guessing what something does without
> knowing for sure, and copy-n-pasting code without understanding it,
> which leads to bit rot and hideous patchwork code that houses all sorts
> of subtle bugs and corner-case failures).

We also write lots of tests in Ruby. :-P

"Nick Sabalausky" <a@a.a> wrote in message news:jj6gjm$2m6a$1@digitalmars.com...
>
> But, I'm thinking this whole "dur vs duration" matter is stupid anyway. Seconds, hours, etc *are* durations. What the hell do we even need the "dur" or "duration" for anyway?
>
> I say fuck it: Let's just toss this into core.time (or std.datetime or whatever) and be done:
>
> alias dur!"years" years;
> alias dur!"months" months;
> alias dur!"weeks" weeks;
> alias dur!"days" days;
> alias dur!"hours" hours;
> alias dur!"minutes" minutes;
> alias dur!"seconds" seconds;
> alias dur!"msecs" msecs;
> alias dur!"usecs" usecs;
> alias dur!"hnsecs" hnsecs;
>
> And then we have the brevity issue solved (and in fact, improved over "dur"), so then "dur" can (and should) change to "duration" without screwing up brevity. And all probelms are optimally solved. As for the possibility of new name collisions: Honestly, in this case I see no reason to give a shit.
>

https://github.com/D-Programming-Language/druntime/pull/174

https://github.com/D-Programming-Language/phobos/pull/485

https://github.com/D-Programming-Language/tools/pull/23

I completely understand the "secs==seconds" pull request being rejected and I think that's perfectly reasonable...

But I'm going to be really pissed if this one's rejected out of some misapplied, overly-puritanical obsession with "no aliases".

"Nick Sabalausky" <a@a.a> wrote in message news:jjdru9$1rv5$1@digitalmars.com...
> "Nick Sabalausky" <a@a.a> wrote in message news:jj6gjm$2m6a$1@digitalmars.com...
>>
>> But, I'm thinking this whole "dur vs duration" matter is stupid anyway. Seconds, hours, etc *are* durations. What the hell do we even need the "dur" or "duration" for anyway?
>>
>> I say fuck it: Let's just toss this into core.time (or std.datetime or whatever) and be done:
>>
>> alias dur!"years" years;
>> alias dur!"months" months;
>> alias dur!"weeks" weeks;
>> alias dur!"days" days;
>> alias dur!"hours" hours;
>> alias dur!"minutes" minutes;
>> alias dur!"seconds" seconds;
>> alias dur!"msecs" msecs;
>> alias dur!"usecs" usecs;
>> alias dur!"hnsecs" hnsecs;
>>
>> And then we have the brevity issue solved (and in fact, improved over "dur"), so then "dur" can (and should) change to "duration" without screwing up brevity. And all probelms are optimally solved. As for the possibility of new name collisions: Honestly, in this case I see no reason to give a shit.
>>
>
> https://github.com/D-Programming-Language/druntime/pull/174
>
> https://github.com/D-Programming-Language/phobos/pull/485
>
> https://github.com/D-Programming-Language/tools/pull/23
>
> I completely understand the "secs==seconds" pull request being rejected and I think that's perfectly reasonable...
>
> But I'm going to be really pissed if this one's rejected out of some misapplied, overly-puritanical obsession with "no aliases".
>

Note how much *nicer* it makes all the sample and unittest code.