On Tue, 28 Apr 2009 13:40:44 -0400, Bill Baxter wrote:
On Tue, Apr 28, 2009 at 10:23 AM, Steven Schveighoffer
wrote:
On Tue, 28 Apr 2009 13:12:41 -0400, Robert Fraser
wrote:
Steven Schveighoffer wrote:
On Mon, 27 Apr 2009 18:36:55 -0400, Sean Kelly
wrote:
== Quote from Andrei Alexa
On Tue, Apr 28, 2009 at 10:23 AM, Steven Schveighoffer
wrote:
> On Tue, 28 Apr 2009 13:12:41 -0400, Robert Fraser
> wrote:
>
>> Steven Schveighoffer wrote:
>>>
>>> On Mon, 27 Apr 2009 18:36:55 -0400, Sean Kelly
>>> wrote:
>>>
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)
On Tue, 28 Apr 2009 13:12:41 -0400, Robert Fraser
wrote:
Steven Schveighoffer wrote:
On Mon, 27 Apr 2009 18:36:55 -0400, Sean Kelly
wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
article
For the same reason, C accepts enum X { a, b, } but not ,a ,b.
Mechani
Steven Schveighoffer wrote:
On Mon, 27 Apr 2009 18:36:55 -0400, Sean Kelly
wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
article
For the same reason, C accepts enum X { a, b, } but not ,a ,b.
Mechanically generating enum values is easier if each value has a
trail
On Tue, Apr 28, 2009 at 9:49 AM, grauzone wrote:
>> This is one of my favorite rants, anywhere on the world wide internets:
>
> I believe it is "Internet".
It's "internets."
This is one of my favorite rants, anywhere on the world wide internets:
I believe it is "Internet".
http://steve.yegge.googlepages.com/ancient-languages-perl
That reminds me, will D templates ever be fixed not to auto-flatten
tuples? Does D really want to be its own father's sister?
On Mon, 27 Apr 2009 18:36:55 -0400, Sean Kelly
wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
article
For the same reason, C accepts enum X { a, b, } but not ,a ,b.
Mechanically generating enum values is easier if each value has a
trailing comma.
This has alway
Robert Fraser:
> For quick, simple, write-once scripts, I still haven't found anything that
> beats Perl.<
Even if now it is slowly going out of fashion, Perl is a language used for many
years by millions of people, so surely it's usable. For small text processing
scripts it's probably "better"
Brad Roberts wrote:
Actually, perl is a risky language to take _syntax_ from, but _semantics_
aren't nearly as dangerous. Obviously there's some semantics that are
horrible (see it's OOP mechanisms), but parts of the rest are quite good.
I grip and groan every time I find myself having to tou
bearophile wrote:
Walter Bright:
Expect, yes, but Andrei made a good point that (4) is not the most
useful behavior.
If your language acts in an intuitive and logic way, people need less time to
write programs, to debug then, and write less bugs in the first place. This
outweighs most other
Andrei Alexandrescu wrote:
Brad Roberts wrote:
Without looking at the docs, code, or compiling and running a test,
what will
this do:
foreach(x, splitter(",a,b,", ","))
writefln("x = %s", a);
I'll make it multiple choice:
choice 1)
x = a
x = b
choice 2)
x =
x = a
x = b
On Mon, 27 Apr 2009, bearophile wrote:
> Walter Bright:
> > Expect, yes, but Andrei made a good point that (4) is not the most
> > useful behavior.
>
> If your language acts in an intuitive and logic way, people need less time to
> write programs, to debug then, and write less bugs in the first
bearophile wrote:
Walter Bright:
Expect, yes, but Andrei made a good point that (4) is not the most
useful behavior.
If your language acts in an intuitive and logic way, people need less time to
write programs, to debug then, and write less bugs in the first place. This
outweighs most other
bearophile wrote:
Walter Bright:
Expect, yes, but Andrei made a good point that (4) is not the most
useful behavior.
If your language acts in an intuitive and logic way, people need less time to
write programs, to debug then, and write less bugs in the first place. This
outweighs most other
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> Brad Roberts wrote:
> > Without looking at the docs, code, or compiling and running a test, what
> > will
> > this do:
> >
> > foreach(x, splitter(",a,b,", ","))
> > writefln("x = %s", a);
> >
> > I'll make i
On Mon, 27 Apr 2009 15:12:59 -0700, Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> I have been convinced. I will modify splitter to do (4), i.e., prepend
>> or append an empty element if there's a leading, respectively trailing,
>> separator. Thanks to all for destroying me :o).
>
> Looks
Walter Bright:
> Expect, yes, but Andrei made a good point that (4) is not the most
> useful behavior.
If your language acts in an intuitive and logic way, people need less time to
write programs, to debug then, and write less bugs in the first place. This
outweighs most other things. If you ha
Leandro Lucarella wrote:
This thread shows that 4) is the result people expect. I think removing
unexpected behaviour (bugs) is a good reason to change it.
Expect, yes, but Andrei made a good point that (4) is not the most
useful behavior.
Since Perl has been very successful in its niche of
Andrei Alexandrescu wrote:
I have been convinced. I will modify splitter to do (4), i.e., prepend
or append an empty element if there's a leading, respectively trailing,
separator. Thanks to all for destroying me :o).
Looks like I must concede, too .
Andrei Alexandrescu wrote:
Robert Fraser wrote:
Andrei Alexandrescu wrote:
Jason House wrote:
Before reading your post, I was going to say that I'd expect 4, would
accept 1, and consider 2 or 3 to be buggy! Notice how under your new
proposal everyone would still get the behavior wrong when rea
On Sun, 26 Apr 2009 19:36:33 -0700, Brad Roberts wrote:
> Without looking at the docs, code, or compiling and running a test, what will
> this do:
>
> foreach(x, splitter(",a,b,", ","))
> writefln("x = %s", a);
I picked (4) ... then read Andrei's response.
> choice 4)
> x =
> x
bearophile wrote:
Robert Fraser:
bearophile wrote:
To design an API you have to start collecting possible (even ideal) users. Then
you trim them down to the few most important people, and give a face and a name
to each one of them.
LOL, user personalities. I remember catering to the user "Mus
Georg Wrede wrote:
An after-the-fact thought: if the function is called "splitter", then
one unavoidably starts thinking about separators. And not terminators.
Had the function been called "separate" or something else, then the
notion of "something in between" hadn't been that strong.
So
Steven Schveighoffer wrote:
On Mon, 27 Apr 2009 09:43:40 -0400, Andrei Alexandrescu
wrote:
Jason House wrote:
Before reading your post, I was going to say that I'd expect 4, would
accept 1, and consider 2 or 3 to be buggy! Notice how under your new
proposal everyone would still get the behav
bearophile wrote:
Andrei Alexandrescu:
Sheesh. DWIM taken to the extreme. That sounds pretty awful to me.
Python must die :o).
Python APIs are usually 5 times better than the ones you dream about.
I meant that in jest, so no need to get annoyed. I account emotional
load for your response.
Robert Fraser:
> bearophile wrote:
> > To design an API you have to start collecting possible (even ideal) users.
> > Then you trim them down to the few most important people, and give a face
> > and a name to each one of them.
>
> LOL, user personalities. I remember catering to the user "Mustaf
Andrei Alexandrescu wrote:
Robert Fraser wrote:
Yes, but it's a representative (albeit small) sample of the user base.
That I disagree with. I mean... you're just saying it. Participation to
a newsgroup is not necessarily correlated with much else than interest
and available time.
Exactly!
bearophile wrote:
To design an API you have to start collecting possible (even ideal) users. Then
you trim them down to the few most important people, and give a face and a name
to each one of them.
LOL, user personalities. I remember catering to the user "Mustafa" when
I was working at MS,
Andrei Alexandrescu:
> Sheesh. DWIM taken to the extreme. That sounds pretty awful to me.
> Python must die :o).
Python APIs are usually 5 times better than the ones you dream about.
To design an API you have to start collecting possible (even ideal) users. Then
you trim them down to the few mos
Bill Baxter wrote:
So the default is to act like Perl, but this only applies when
splitting on whitespace. Otherwise it acts like 4). re.split in
python seems to do 4) pretty much all the time.
Sheesh. DWIM taken to the extreme. That sounds pretty awful to me.
Python must die :o).
Andrei
On Mon, Apr 27, 2009 at 9:55 AM, Robert Fraser
wrote:
>
> Andrei Alexandrescu wrote:
>>
>> Jason House wrote:
>>>
>>> Before reading your post, I was going to say that I'd expect 4, would
>>> accept 1, and consider 2 or 3 to be buggy! Notice how under your new
>>> proposal everyone would still get
Andrei Alexandrescu Wrote:
> Jason House wrote:
> > Before reading your post, I was going to say that I'd expect 4, would
> > accept 1, and consider 2 or 3 to be buggy! Notice how under your new
> > proposal everyone would still get the behavior wrong when reading the
> > code.
>
> everyone posti
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Keep wrote:
|
| Andrei Alexandrescu wrote:
|> ...
|>
|> We might just go with the terminator semantics and ask people who
need
|> separator semantics to use a stripl() or a munch() prior to
splitting.
|> I'd personally prefer having an enum the
On Mon, 27 Apr 2009, Andrei Alexandrescu wrote:
> I have been convinced. I will modify splitter to do (4), i.e., prepend or
> append an empty element if there's a leading, respectively trailing,
> separator. Thanks to all for destroying me :o).
>
> Actually, Brad, since it was your idea, I sugges
downs wrote:
Andrei Alexandrescu wrote:
bearophile wrote:
Andrei Alexandrescu:
Splitter does what Perl's split does: 2.
Perl has to die. This is Python:
This answer is wrong for a number of reasons. First comes the fallacy
that if Perl "has to die", everything Perl did was wrong. Second come
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brad Roberts wrote:
| Without looking at the docs, code, or compiling and running a
test, what will
| this do:
|
| foreach(x, splitter(",a,b,", ","))
| writefln("x = %s", a);
|
| I'll make it multiple choice:
|
| choice 1)
| x = a
| x
Robert Fraser wrote:
Andrei Alexandrescu wrote:
Jason House wrote:
Before reading your post, I was going to say that I'd expect 4, would
accept 1, and consider 2 or 3 to be buggy! Notice how under your new
proposal everyone would still get the behavior wrong when reading the
code.
everyone po
Andrei Alexandrescu wrote:
> bearophile wrote:
>> Andrei Alexandrescu:
>>> Splitter does what Perl's split does: 2.
>>
>> Perl has to die. This is Python:
>
> This answer is wrong for a number of reasons. First comes the fallacy
> that if Perl "has to die", everything Perl did was wrong. Second co
Andrei Alexandrescu wrote:
Jason House wrote:
Before reading your post, I was going to say that I'd expect 4, would
accept 1, and consider 2 or 3 to be buggy! Notice how under your new
proposal everyone would still get the behavior wrong when reading the
code.
everyone posting heavily in thiss
Andrei Alexandrescu, el 27 de abril a las 08:39 me escribiste:
> ",a,b,".split(",")
> >['', 'a', 'b', '']
> >My lazy xsplit too works like that. I strongly vote for (4).
>
> Why? I'd be willing to change things no problem, but "perl must die, here's
> python" just doesn't seem to have much pe
Steven Schveighoffer wrote:
On Mon, 27 Apr 2009 09:43:40 -0400, Andrei Alexandrescu
wrote:
Jason House wrote:
Before reading your post, I was going to say that I'd expect 4, would
accept 1, and consider 2 or 3 to be buggy! Notice how under your new
proposal everyone would still get the behav
On Mon, 27 Apr 2009 09:43:40 -0400, Andrei Alexandrescu
wrote:
Jason House wrote:
Before reading your post, I was going to say that I'd expect 4, would
accept 1, and consider 2 or 3 to be buggy! Notice how under your new
proposal everyone would still get the behavior wrong when reading the
c
Jason House wrote:
Before reading your post, I was going to say that I'd expect 4, would
accept 1, and consider 2 or 3 to be buggy! Notice how under your new
proposal everyone would still get the behavior wrong when reading the
code.
everyone posting heavily in thiss group != everyone
Andrei
bearophile wrote:
Andrei Alexandrescu:
Splitter does what Perl's
split does: 2.
Perl has to die. This is Python:
This answer is wrong for a number of reasons. First comes the fallacy
that if Perl "has to die", everything Perl did was wrong. Second comes
the fallacy that if Python is overal
Andrei Alexandrescu wrote:
> ...
>
> We might just go with the terminator semantics and ask people who need
> separator semantics to use a stripl() or a munch() prior to splitting.
> I'd personally prefer having an enum there.
>
>
> Andrei
I'm going to invoke the principle of least surprise h
On Sun, 26 Apr 2009 22:36:33 -0400, Brad Roberts
wrote:
Without looking at the docs, code, or compiling and running a test, what
will
this do:
foreach(x, splitter(",a,b,", ","))
writefln("x = %s", a);
I'll make it multiple choice:
choice 1)
x = a
x = b
choice 2)
x =
Andrei Alexandrescu Wrote:
> Brad Roberts wrote:
> > Without looking at the docs, code, or compiling and running a test, what
> > will
> > this do:
> >
> > foreach(x, splitter(",a,b,", ","))
> > writefln("x = %s", a);
> >
> > I'll make it multiple choice:
> >
> > choice 1)
> > x
bearophile wrote:
Perl has to die. This is Python:
",a,b,".split(",")
['', 'a', 'b', '']
T-h-i-s I-s S-p-a-r-t-a:
immortals.split("xiphos")
Andrei Alexandrescu:
> Splitter does what Perl's
> split does: 2.
Perl has to die. This is Python:
>>> ",a,b,".split(",")
['', 'a', 'b', '']
My lazy xsplit too works like that. I strongly vote for (4).
Bye,
bearophile
Brad Roberts wrote:
Without looking at the docs, code, or compiling and running a test, what will
this do:
foreach(x, splitter(",a,b,", ","))
writefln("x = %s", a);
I'll make it multiple choice:
choice 1)
x = a
x = b
choice 2)
x =
x = a
x = b
choice 3)
x = a
x = b
Georg Wrede wrote:
Brad Roberts wrote:
Without looking at the docs, code, or compiling and running a test,
what will
this do:
foreach(x, splitter(",a,b,", ","))
writefln("x = %s", a);
I'll make it multiple choice:
choice 1)
x = a
x = b
choice 2)
x =
x = a
x = b
choice
On Sun, 26 Apr 2009 19:36:33 -0700, Brad Roberts
wrote:
>Without looking at the docs, code, or compiling and running a test, what will
>this do:
>
>foreach(x, splitter(",a,b,", ","))
>writefln("x = %s", a);
>
>I'll make it multiple choice:
>
>choice 1)
> x = a
> x = b
>
>choice 2)
>
Brad Roberts wrote:
Without looking at the docs, code, or compiling and running a test, what will
this do:
foreach(x, splitter(",a,b,", ","))
writefln("x = %s", a);
I'll make it multiple choice:
choice 1)
x = a
x = b
choice 2)
x =
x = a
x = b
choice 3)
x = a
x = b
eh, x = a and x = b
On Mon, 27 Apr 2009 06:36:33 +0400, Brad Roberts wrote:
Without looking at the docs, code, or compiling and running a test, what
will
this do:
foreach(x, splitter(",a,b,", ","))
writefln("x = %s", a);
I'll make it multiple choice:
choice 1)
x = a
x = b
choice 2)
x =
x
"Brad Roberts" wrote in message
news:mailman.1196.1240799812.22690.digitalmar...@puremagic.com...
Without looking at the docs, code, or compiling and running a test, what
will
this do:
foreach(x, splitter(",a,b,", ","))
writefln("x = %s", a);
Is it a trick question?
Replacing ,
Jarrett Billingsley wrote:
> On Sun, Apr 26, 2009 at 10:36 PM, Brad Roberts wrote:
>> Without looking at the docs, code, or compiling and running a test, what will
>> this do:
>>
>>foreach(x, splitter(",a,b,", ","))
>>writefln("x = %s", a);
>
>> choice 4)
>> x =
>> x = a
>> x = b
On Sun, Apr 26, 2009 at 10:36 PM, Brad Roberts wrote:
> Without looking at the docs, code, or compiling and running a test, what will
> this do:
>
> foreach(x, splitter(",a,b,", ","))
> writefln("x = %s", a);
> choice 4)
> x =
> x = a
> x = b
> x =
This one.
Without looking at the docs, code, or compiling and running a test, what will
this do:
foreach(x, splitter(",a,b,", ","))
writefln("x = %s", a);
I'll make it multiple choice:
choice 1)
x = a
x = b
choice 2)
x =
x = a
x = b
choice 3)
x = a
x = b
x =
choice 4)
x =
59 matches
Mail list logo
