 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I don't like regular expressions. Or rather, I don't like the mangled
ASCII pea-soup typically used to /represent/ regexes. I have nothing
against the formal /concept/ of a regular expression. I just dislike the
lack of separation between commands and arguments. (And the fact that it
looks like pea-soup!)
Apparently other people dislike them far more:
http://tinyurl.com/ydb4j9j
My best answer on Stack Overflow got about 12 votes. This one got FOUR
AND A HALF THOUSAND! o_O
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 16/07/2012 12:28, Invisible a écrit :
> I don't like regular expressions. Or rather, I don't like the mangled
> ASCII pea-soup typically used to /represent/ regexes
Issue number 1: there is too many syntaxes for regexes.
SQL has its own. Unix ed/sed/vi... has another. Windows try to have some
but not all, and so on (including unix shells)...
(SQL uses % and ? where Unix classical uses * and . )
Regexes is useful for small items.
Trying to recognize a book from another with a regex is silly.
(I want a regex that catch all transcriptions in any language and any
encoding of the work of William Shakespeare but it should avoid all
other books, including the one talking about the work of William
Shakespeare... go to hell!)
Trying to implement a BNF syntax with a regex is asking for trouble as
soon as recursion or reordering is allowed. And interesting BNF syntax
have always a recursion somewhere (just to allow more than one item...),
and most are also cool about the required order of appearance of
sub-items or properties.
Regex for syntactically correct email address: yes
Regex for valid ip address: yes
Regex for validating your income's tax form: No way!
>. I have nothing
> against the formal /concept/ of a regular expression. I just dislike the
> lack of separation between commands and arguments. (And the fact that it
> looks like pea-soup!)
Command ?
There is no command in regexes. Commands are from a programming
language. They often make more issues with regexes too.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> I don't like regular expressions. Or rather, I don't like the mangled
> ASCII pea-soup typically used to /represent/ regexes.
That complaint is mostly irrelevant. regexes are excellent for their
most common use, which is to match extremely simple patterns.
"hello" is a regex. It might not look like it, but it is. And that's the
beauty of it. If you use that for example as a search pattern, you will
find all occurrences of those five consecutive characters.
The absolute beauty of it is that there's *no* extraneous syntax *at all*
to perform such a simple match. If you were to separate the syntax into
"commands and arguments", you would only be making the pattern needlessly
complicated and more laborious to write.
But how does that differ from a trivial matching that simply searches for
those consecutive characters and that's it? Well, you can refine the pattern
by adding a few additional key characters to it, to make it perform a more
elaborate search, and in the vast majority of cases it does not become
needlessly complicated or long.
For example, suppose you wanted to search for either "hello" or "Hello".
You would write the pattern as "[Hh]ello".
You would have to be really pedantic if you were to argue that's complicated
and difficult to understand. However, imagine that you were to separate that
into "commands and arguments", how much more complicated and lengthy the
pattern would become.
You can argue against regexes by giving examples of really long and
complicated patterns, but then you would be complaining about extreme
fringe cases, not about *the most common* usage for them, for which they
are just superb.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 16/07/2012 12:43 PM, Le_Forgeron wrote:
> Issue number 1: there is too many syntaxes for regexes.
Well, that's true enough.
> Trying to implement a BNF syntax with a regex is asking for trouble as
> soon as recursion or reordering is allowed. And interesting BNF syntax
> have always a recursion somewhere (just to allow more than one item...),
> and most are also cool about the required order of appearance of
> sub-items or properties.
I believe the correct phrase is "regular expressions can only recognise
regular languages", and "most languages described by BNF are not
regular". Followed shortly by "most regex implementations are not
actually regular".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 16/07/2012 12:48 PM, Warp wrote:
> You can argue against regexes by giving examples of really long and
> complicated patterns, but then you would be complaining about extreme
> fringe cases, not about *the most common* usage for them, for which they
> are just superb.
In my limited experience, people don't use regexes for simple pattern
matches. They only use them for insanely complex cases - cases where it
would be far, far better to spell out exactly what you're trying to do,
rather than encode it into a tangle of punctuation.
I can see how if you're just trying to quickly search some document for
a piece of information, being able to throw together a short text string
and get nearly the right results might be useful. And hey, if you're
only doing this once, who /cares/ that it's completely non-maintainable.
It's a one-off task; you don't /need/ to maintain anything.
But for building large, complex applications, regexes seem like a
stupendously bad idea.
Also, the usual formulation of regexes as text strings means that you
can only match against text strings. Admittedly that's the most common
case for wanting to do complicated matching. But if, say, you wanted to
match against a binary file... sorry, you can't do that. As far as I can
tell, there's no reason why a formal regular expression can't be matched
against binary data; it's just that most real-world implementations
don't allow this.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
He doesn't dislike regexes at all. He dislikes using the wrong tool for
the job, as he wisely puts it:
"HTML is not a regular language and hence cannot be parsed by regular
expressions."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> In my limited experience, people don't use regexes for simple pattern
> matches.
Yes, because you have decades of extensive experience on how eg. unix users
typically use regexes.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 16/07/2012 05:22 PM, nemesis wrote:
> He doesn't dislike regexes at all. He dislikes using the wrong tool for
> the job, as he wisely puts it:
>
> "HTML is not a regular language and hence cannot be parsed by regular
> expressions."
And yet, this seems to be how people almost always try to use regexes...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> And yet, this seems to be how people almost always try to use regexes...
No, it isn't.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 17/07/2012 07:28 AM, Warp wrote:
> Invisible<voi### [at] devnull> wrote:
>> In my limited experience, people don't use regexes for simple pattern
>> matches.
>
> Yes, because you have decades of extensive experience on how eg. unix users
> typically use regexes.
Perhaps you mean like
grep -e "ntpd\[[[:digit:]]\+\]" /var/log/messages.4
which obviously searches for... wait, what does it search for exactly?
So how about this?
egrep
'\b(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)'
Yeah, that's pretty clear. If by "clear" you mean "it's going to take me
five minutes to figure out exactly what this is supposed to do".
Or how about
dmesg | egrep '(s|h)d[a-z]'
At least that one only takes a minute or two to figure out.
And then we come to horrifying things such as
while(<STDIN>)
{
my($line) = $_;
chomp($line);
if($line !~ /<DIR>/)
{
if ($line =~ /.{28}(\d\d)-(\d\d)-(\d\d).{8}(.+)$/)
{
my($filename) = $4;
my($yymmdd) = "$3$1$2";
if($yymmdd lt "971222")
{
print "copy $filename \\oldie\n";
}
}
}
}
I don't even want to contemplate what the hell that does...
Still, I suppose the fact that you can do bad things with regexes
doesn't automatically mean that regexes are bad.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 17/07/2012 09:21 AM, Warp wrote:
> Invisible<voi### [at] devnull> wrote:
>> And yet, this seems to be how people almost always try to use regexes...
>
> No, it isn't.
That would explain why the question "how do I parse XHTML with a regex?"
is so common on Stack Overflow that a guy actually lost his mind trying
to answer it.
Actually, no it wouldn't.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> On 17/07/2012 07:28 AM, Warp wrote:
> > Invisible<voi### [at] devnull> wrote:
> >> In my limited experience, people don't use regexes for simple pattern
> >> matches.
> >
> > Yes, because you have decades of extensive experience on how eg. unix users
> > typically use regexes.
> Perhaps you mean like
You don't seem to grasp what "the most common usage" means. It does not
mean "the most prominent examples displayed on webpages" or "the most
prominent examples that I have seen". It means the forms that people
*most commonly* use, as in raw numbers. Count how many people use a
completely syntax-less regex or with just a simple wildcard, vs. the
times when someone has to write a really large and complex expression.
I'd estimate that the former wins about a million to one.
> Or how about
> dmesg | egrep '(s|h)d[a-z]'
If you want to build your straw man, at least use examples that conform
to your straw man. That's a bad example because it can be understood in
about 2 seconds.
> while(<STDIN>)
> {
> my($line) = $_;
> chomp($line);
> if($line !~ /<DIR>/)
> {
> if ($line =~ /.{28}(\d\d)-(\d\d)-(\d\d).{8}(.+)$/)
> {
> my($filename) = $4;
> my($yymmdd) = "$3$1$2";
> if($yymmdd lt "971222")
> {
> print "copy $filename \\oldie\n";
> }
> }
> }
> }
Also, if you are building your straw man, at least try to use actual
regexes and not some unrelated scripting language.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> On 17/07/2012 09:21 AM, Warp wrote:
> > Invisible<voi### [at] devnull> wrote:
> >> And yet, this seems to be how people almost always try to use regexes...
> >
> > No, it isn't.
> That would explain why the question "how do I parse XHTML with a regex?"
> is so common on Stack Overflow that a guy actually lost his mind trying
> to answer it.
It seems to me that we have a different understanding of the expression
"almost always".
To me it means, well, almost always. To you it seems to mean "a couple of
times".
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 17/07/2012 10:40 AM, Warp wrote:
> Invisible<voi### [at] devnull> wrote:
>> On 17/07/2012 07:28 AM, Warp wrote:
>>> Invisible<voi### [at] devnull> wrote:
>>>> In my limited experience, people don't use regexes for simple pattern
>>>> matches.
>>>
>>> Yes, because you have decades of extensive experience on how eg. unix users
>>> typically use regexes.
>
>> Perhaps you mean like
>
> You don't seem to grasp what "the most common usage" means. It does not
> mean "the most prominent examples displayed on webpages" or "the most
> prominent examples that I have seen". It means the forms that people
> *most commonly* use, as in raw numbers. Count how many people use a
> completely syntax-less regex or with just a simple wildcard, vs. the
> times when someone has to write a really large and complex expression.
> I'd estimate that the former wins about a million to one.
Well, you can say "I estimate that it's X", and I can say "well I
estimate that it's Y", and without some actual facts to back any of this
up, it's a bit of an empty discussion.
Also, if the most common search terms really are just literal strings,
that doesn't really prove that regexes are a valuable search tool. It
proves that /literal strings/ are a valuable search tool, no?
>> Or how about
>
>> dmesg | egrep '(s|h)d[a-z]'
>
> If you want to build your straw man, at least use examples that conform
> to your straw man. That's a bad example because it can be understood in
> about 2 seconds.
OK, so what does it do?
Clearly it runs dmesg and searches the output for some search term. But
what is the search term?
>> while(<STDIN>)
>> {
>> my($line) = $_;
>> chomp($line);
>> if($line !~ /<DIR>/)
>> {
>> if ($line =~ /.{28}(\d\d)-(\d\d)-(\d\d).{8}(.+)$/)
>> {
>> my($filename) = $4;
>> my($yymmdd) = "$3$1$2";
>> if($yymmdd lt "971222")
>> {
>> print "copy $filename \\oldie\n";
>> }
>> }
>> }
>> }
>
> Also, if you are building your straw man, at least try to use actual
> regexes and not some unrelated scripting language.
Come on, regexes are the number one use-case for the entire Perl
programming language.
Exhibit A: "Perl" stands for "Practical Extraction and Reporting
Language". Regexes are how Perl does that.
Exhibit B: http://xkcd.com/208/
Perl and regexes are practically synonymous. (Even if /technically/
they're not all that closely related.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> Well, you can say "I estimate that it's X", and I can say "well I
> estimate that it's Y", and without some actual facts to back any of this
> up, it's a bit of an empty discussion.
The difference is that I have actual extensive personal experience using
systems where regexes are very commonly used, and with people who use them.
Now, granted, I really don't know if you are really a unix guru who has
been using unixes all of his life, but I have got the impression that
you aren't.
> Also, if the most common search terms really are just literal strings,
> that doesn't really prove that regexes are a valuable search tool. It
> proves that /literal strings/ are a valuable search tool, no?
Please read again my original reply. The beauty of regexes is that if you
want to just search for a literal string, you usually need no ancillary
syntax at all, and if you need a simple wildcard or other simple pattern,
the search string still remains short and simple. And these two are by
far the most common usages for regexes.
A search (or other pattern matching) system that *only* supported literal
strings and nothing else would be significantly less useful.
> >> Or how about
> >
> >> dmesg | egrep '(s|h)d[a-z]'
> >
> > If you want to build your straw man, at least use examples that conform
> > to your straw man. That's a bad example because it can be understood in
> > about 2 seconds.
> OK, so what does it do?
I can't believe that you are arguing that a regex is complicated because
you have never used regexes and don't understand their syntax.
Imagine this:
A: "Haskell sucks. It's really hard to understand!"
B: "How much Haskell have you ever written?"
A: "I once tried to write one small program but couldn't figure it out."
B: "Right."
Don't complain about the complexity of a syntax if you haven't even
learned the syntax.
> Come on, regexes are the number one use-case for the entire Perl
> programming language.
If you want to complain about perl, then complain about perl.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2012-07-17 04:47, Invisible wrote:
>>> dmesg | egrep '(s|h)d[a-z]'
>>
>> If you want to build your straw man, at least use examples that conform
>> to your straw man. That's a bad example because it can be understood in
>> about 2 seconds.
>
> OK, so what does it do?
>
> Clearly it runs dmesg and searches the output for some search term. But
> what is the search term?
*I'LL* handle this one! Wa ha.
It's looking for one of the following:
ada adb adc ... adx ady adz
hda hdb hdc ... hdx hdy hdz
...I think.
--
Tim Cook
http://empyrean.sjcook.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2012-07-17 06:10, Tim Cook a écrit :
> On 2012-07-17 04:47, Invisible wrote:
>>>> dmesg | egrep '(s|h)d[a-z]'
>>>
>>> If you want to build your straw man, at least use examples that conform
>>> to your straw man. That's a bad example because it can be understood in
>>> about 2 seconds.
>>
>> OK, so what does it do?
>>
>> Clearly it runs dmesg and searches the output for some search term. But
>> what is the search term?
>
> *I'LL* handle this one! Wa ha.
>
> It's looking for one of the following:
> ada adb adc ... adx ady adz
> hda hdb hdc ... hdx hdy hdz
>
> ...I think.
Yep, but you have a typo in your answer.
Basically, it parses the output of the dmesg command looking for lines
that talk about hard disks (hda-hdz for IDE/SATA and sda-sdz for SCSI)
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 17.07.2012 12:10, schrieb Tim Cook:
> On 2012-07-17 04:47, Invisible wrote:
>>>> dmesg | egrep '(s|h)d[a-z]'
>>>
>>> If you want to build your straw man, at least use examples that conform
>>> to your straw man. That's a bad example because it can be understood in
>>> about 2 seconds.
>>
>> OK, so what does it do?
>>
>> Clearly it runs dmesg and searches the output for some search term. But
>> what is the search term?
>
> *I'LL* handle this one! Wa ha.
>
> It's looking for one of the following:
> ada adb adc ... adx ady adz
> hda hdb hdc ... hdx hdy hdz
>
> ...I think.
No.
sda sdb sdc ... sdx sdy sdz
hda hdb hdc ... hdx hdy hdz
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2012-07-17 09:22, Francois Labreque wrote:
> Yep, but you have a typo in your answer.
'a', 's'...the keys are like right next to each other! Also I was tired.
...yeah, I'll go with that.
<_<
--
Tim Cook
http://empyrean.sjcook.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>>> dmesg | egrep '(s|h)d[a-z]'
>>>
>>> If you want to build your straw man, at least use examples that conform
>>> to your straw man. That's a bad example because it can be understood in
>>> about 2 seconds.
>
>> OK, so what does it do?
>
> I can't believe that you are arguing that a regex is complicated because
> you have never used regexes and don't understand their syntax.
>
> Imagine this:
>
> A: "Haskell sucks. It's really hard to understand!"
> B: "How much Haskell have you ever written?"
> A: "I once tried to write one small program but couldn't figure it out."
> B: "Right."
>
> Don't complain about the complexity of a syntax if you haven't even
> learned the syntax.
Imagine if instead, somebody had written
oneOf "sh"
char 'd'
letter
You don't even need to know which parsing library or what programming
language this is to figure out that it matches three characters. (Or
maybe do you. It's perhaps not /completely/ obvious what the final line
does.) There's barely anything to learn.
It's a lot more typing, of course. But personally, that doesn't bother me.
>> Come on, regexes are the number one use-case for the entire Perl
>> programming language.
>
> If you want to complain about perl, then complain about perl.
Have I ever mentioned that I also really hate Perl?
Of course, the only reason that anybody ever uses Perl is because it has
built-in regex support. This, together with low-level text munging, is
literally ALL PERL DOES! >_<
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 19.07.2012 12:53, schrieb Invisible:
> Imagine if instead, somebody had written
>
> oneOf "sh"
> char 'd'
> letter
>
> You don't even need to know which parsing library or what programming
> language this is to figure out that it matches three characters. (Or
> maybe do you. It's perhaps not /completely/ obvious what the final line
> does.) There's barely anything to learn.
It will become less obvious as soon as the example becomes non-trivial.
>> If you want to complain about perl, then complain about perl.
>
> Have I ever mentioned that I also really hate Perl?
>
> Of course, the only reason that anybody ever uses Perl is because it has
> built-in regex support. This, together with low-level text munging, is
> literally ALL PERL DOES! >_<
... which maybe is because that's what it was /designed/ for? :-P
The only thing I know about Perl though is that its support for calling
existing C libraries dearly sucks: You cannot, for the sake of your
life, pass a NULL pointer.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2012-07-19 06:53, Invisible a écrit :
>>>>> dmesg | egrep '(s|h)d[a-z]'
>>>>
>>>> If you want to build your straw man, at least use examples that conform
>>>> to your straw man. That's a bad example because it can be understood in
>>>> about 2 seconds.
>>
>>> OK, so what does it do?
>>
>> I can't believe that you are arguing that a regex is complicated because
>> you have never used regexes and don't understand their syntax.
>>
>> Imagine this:
>>
>> A: "Haskell sucks. It's really hard to understand!"
>> B: "How much Haskell have you ever written?"
>> A: "I once tried to write one small program but couldn't figure it out."
>> B: "Right."
>>
>> Don't complain about the complexity of a syntax if you haven't even
>> learned the syntax.
>
> Imagine if instead, somebody had written
>
> oneOf "sh"
> char 'd'
> letter
>
> You don't even need to know which parsing library or what programming
> language this is to figure out that it matches three characters. (Or
> maybe do you. It's perhaps not /completely/ obvious what the final line
> does.) There's barely anything to learn.
Actually it's not obvious that the three statements are actually
supposed to be applied to the same string or that it must match all three.
It might be a tad more readable than a regular expression, but it's not
inherently more obvious what it does. Having nothing but english words
instead of various puctuation signs does not guarantee clarity. Case in
point:
=IF(AND(OR(UPPER(LEFT(A1,1))="S"),UPPER(LEFT(A1,1))="H"),UPPER(MID(A1,2,1))="D",NOT(ISERROR(SEARCH(MID(A1,3,1),"ABCDEFGHIJKLMNOPQRSTUVWXYZ")))))
(I hope I didn't mess up my parentheses!)
>
> It's a lot more typing, of course. But personally, that doesn't bother me.
>
>>> Come on, regexes are the number one use-case for the entire Perl
>>> programming language.
>>
>> If you want to complain about perl, then complain about perl.
>
> Have I ever mentioned that I also really hate Perl?
>
> Of course, the only reason that anybody ever uses Perl is because it has
> built-in regex support. This, together with low-level text munging, is
> literally ALL PERL DOES! >_<
Yes, and a all a hammer does is push (and in some cases pull) on nails.
It doesn't mean that a hammer is not useful, or the best tool for that
particular job.
Text munging is a big part of many people's lives. (If you consider
sysadmins to be people, of course)
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2012-07-19 10:55, Francois Labreque a écrit :
>
>
=IF(AND(OR(UPPER(LEFT(A1,1))="S"),UPPER(LEFT(A1,1))="H"),UPPER(MID(A1,2,1))="D",NOT(ISERROR(SEARCH(MID(A1,3,1),"ABCDEFGHIJKLMNOPQRSTUVWXYZ")))))
>
>
> (I hope I didn't mess up my parentheses!)
I didn't mess up my parentheses, but forgot to put
,"Hard disk is on fire",""
before the last parenthesis.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Having nothing but english words
> instead of various puctuation signs does not guarantee clarity.
No. But it can help a lot. I won't have to go look up what my code
snippet does if I come back to it in 6 months' time.
>> Have I ever mentioned that I also really hate Perl?
>>
>> Of course, the only reason that anybody ever uses Perl is because it has
>> built-in regex support. This, together with low-level text munging, is
>> literally ALL PERL DOES! >_<
>
> Yes, and a all a hammer does is push (and in some cases pull) on nails.
> It doesn't mean that a hammer is not useful, or the best tool for that
> particular job.
>
> Text munging is a big part of many people's lives. (If you consider
> sysadmins to be people, of course)
The thing is, text munging is fundamentally /wrong/. It's something that
should be avoided at all costs. So an entire language designed to
perform a task that you shouldn't perform in the first place...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/19/2012 3:53, Invisible wrote:
> oneOf "sh"
> char 'd'
> letter
>
> You don't even need to know which parsing library or what programming
> language this is to figure out that it matches three characters.
Really? I would not have guessed that "one of sh" means "one of the
characters in the string" vs "one instance of the string 'sh'"
> Of course, the only reason that anybody ever uses Perl is because it has
> built-in regex support. This, together with low-level text munging, is
> literally ALL PERL DOES! >_<
It's a report generation language. It's right in the name. What did you
expect? Did you ever read any RPG (Report Program Generator) code?
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> oneOf "sh"
>> char 'd'
>> letter
>>
>> You don't even need to know which parsing library or what programming
>> language this is to figure out that it matches three characters.
>
> Really? I would not have guessed that "one of sh" means "one of the
> characters in the string" vs "one instance of the string 'sh'"
OK. So it's not completely trivial. Easier than trying to guess what
"[s|h]" is meant to mean though. :-P
>> Of course, the only reason that anybody ever uses Perl is because it has
>> built-in regex support. This, together with low-level text munging, is
>> literally ALL PERL DOES! >_<
>
> It's a report generation language. It's right in the name.
Funny, I could have sworn I already /said/ that. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 19.07.2012 21:34, schrieb Orchid Win7 v1:
>>> oneOf "sh"
>>> char 'd'
>>> letter
>>>
>>> You don't even need to know which parsing library or what programming
>>> language this is to figure out that it matches three characters.
>>
>> Really? I would not have guessed that "one of sh" means "one of the
>> characters in the string" vs "one instance of the string 'sh'"
>
> OK. So it's not completely trivial. Easier than trying to guess what
> "[s|h]" is meant to mean though. :-P
Nonsense. First of all it's "(s|h)". Now, the parentheses should be no
problem to decipher for anyone familiar with the basics of mathematics:
There, it is used to override operator precedence by grouping parts of
the term into a sub-term. Same in RegExes; it should be pretty easy to
come to the presumption that "(s|h)" means "a group of characters that
matches 's|h'".
Now for the "|", this is quite a well established symbol for an "or"
operation in various languages (e.g. C, POV-Ray SDL, etc.). With this in
mind, it's a matter of seconds to realize that "s|h" might mean "'s' or
'h'".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2012-07-19 16:30, clipka wrote:
> Now for the "|", this is quite a well established symbol for an "or"
> operation in various languages (e.g. C, POV-Ray SDL, etc.). With this in
> mind, it's a matter of seconds to realize that "s|h" might mean "'s' or
> 'h'".
And the "s|h" form is visually similar enough to the more-common
"and/or" that even if you didn't happen to know that | meant 'or', you'd
have a better-than-zero chance of guessing its intent.
(So what is the result of &/| anyways?)
--
Tim Cook
http://empyrean.sjcook.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 20.07.2012 00:04, schrieb Tim Cook:
> On 2012-07-19 16:30, clipka wrote:
>> Now for the "|", this is quite a well established symbol for an "or"
>> operation in various languages (e.g. C, POV-Ray SDL, etc.). With this in
>> mind, it's a matter of seconds to realize that "s|h" might mean "'s' or
>> 'h'".
>
> And the "s|h" form is visually similar enough to the more-common
> "and/or" that even if you didn't happen to know that | meant 'or', you'd
> have a better-than-zero chance of guessing its intent.
>
> (So what is the result of &/| anyways?)
Related question: 2b|!2b?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/19/2012 06:14 PM, clipka wrote:
> Related question: 2b|!2b?
LOL ... clever and thought provoking at the same time
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/19/2012 3:14 PM, clipka wrote:
>
> Related question: 2b|!2b?
True, very true.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid Win7 v1 <voi### [at] devnull> wrote:
> >> oneOf "sh"
> >> char 'd'
> >> letter
> >>
> >> You don't even need to know which parsing library or what programming
> >> language this is to figure out that it matches three characters.
> >
> > Really? I would not have guessed that "one of sh" means "one of the
> > characters in the string" vs "one instance of the string 'sh'"
> OK. So it's not completely trivial. Easier than trying to guess what
> "[s|h]" is meant to mean though. :-P
Your complaint seems to be that the meaning of regexes may be hard to
guess for somebody who does not know their syntax. That's an inane
complaint.
I tried to explain that in my previous post, but seemingly you didn't
understand.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
