 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
http://web.archive.org/web/20080730063308/http://www.faqs.org/docs/artu/ch08s02.html
Some select quotations:
"Regular expressions are an extreme example of how concise a
mini-language can be. Simple regular expressions express recognition
behaviour that would otherwise have to be implemented with hundreds of
lines of fussy, bug-prone code."
Oh really? What what makes you think people don't use *libraries* for
pattern recognition? :-P
"Once you get past the verbosity of XML, Glade markup is a fairly simple
language."
LOL! Yeah... (This quote appears just below a 32-line "Hello World"
example for Glade.)
"The ultimate functional test of a minilanguage like this one is simple:
can I hack it without reading the manual? For a significant range of
cases, the Glade answer is yes. For example, if you know the C-level
constants that GTK uses to describe window-positioning hints, you'll
recognize GTK_WIN_POS_NONE as one and instantly be able to change the
positioning hint associated with this GUI."
Right... So if you're memorised 300+ cpp constants, you can hack Glade
without reading the manual? WTF?
"m4 is deliberately Turing-complete. But actually trying to use m4 as a
general-purpose language would be deeply perverse."
LOLz.
"We've included a glance at XSLT here partly to illustrate the point
that ‘declarative’ does not imply either ‘simple’ or ‘weak’, and mostly
because if you have to work with XML documents, you will someday have to
face the challenge that is XSLT."
Where I'm from, declarative = desirable. It's considered powerful,
expressive and succinct.
XSLT is XML of course, so it's a tad wordy...
"The troff(1) typesetting formatter was, as we noted in Chapter 2,
Unix's original killer application."
Oh really? Damn, I'm going to have to go look up what the hell troff is
now...
"There are some ways in which modern XML-based document markups and
toolchains are still, in 2003, playing catch-up with capabilities that
Documenter's Workbench had in 1979."
Uhuh. That's an interesting assertion.
"The traditional term for this sort of thing is syntactic sugar; the
maxim that goes with this is a famous quip that “syntactic sugar causes
cancer of the semicolon”. Indeed, syntactic sugar needs to be used
sparingly lest it obscure more than help."
And to think most people consider syntactic sugar to be a /good/ thing...
"Falling costs have changed the trade-offs in mini-language design.
Restricting your design's capabilities to buy compactness may still be a
good idea, but doing so to economize on machine resources is a bad one.
Machine resources get cheaper over time, but space in programmers' heads
only gets more expensive. Modern mini-languages can either be general
but non-compact, or specialized but very compact; specialized but
non-compact simply won't compete."
Language power, size and complexity are not necessarily related as
directly as this suggests.
The Iota calculus has 1 data type, 1 operator, and 1 constant, and it
manages to be Turing-complete. So it's as "capable" as you can get, and
just about as "small" as you can get. But powerful? Not really. Complex?
You betcha! o_O
Having fewer features can make a language /more complicated/ to actually
*use*. Sometimes a bigger language is easier to use. And sometimes you
can make a language smaller /and/ simpler /and/ easier to use. It's not
as simple as bigger = more complex = more powerful.
"Stack-based languages are famous for supporting extremely tight,
economical coding and infamous for being difficult to read. PostScript
shares both traits."
Really? The design of PostScript looks fairly UNeconomical to me. (It
forces the interpreter to implement dynamically-sized lookup tables, for
a start...)
"PostScript is a very well designed example of a special-purpose control
language and deserves careful study as a model. It is a component of
other standards such as PDF, the Portable Document Format."
And yet again we have the PDF = PS fallacy. >_<
"Syntactically JavaScript resembles Java with some influence from Perl,
and features Perl-like regular expressions."
Since when does JS have regular expressions?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05/11/2010 01:53 PM, Invisible wrote:
> Some select quotations:
Man, this thing is a mine of select quotations. For example,
"[the inventor of Ethernet] says that if something comes along to
replace Ethernet, it will be called “Ethernet”, so therefore Ethernet
will never die. Unix has already undergone several such transformations."
Think about that for a moment.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> "Regular expressions are an extreme example of how concise a
> mini-language can be. Simple regular expressions express recognition
> behaviour that would otherwise have to be implemented with hundreds of
> lines of fussy, bug-prone code."
> Oh really? What what makes you think people don't use *libraries* for
> pattern recognition? :-P
I have always found it curious that you are infatuated with a
programming language known for the brevity of its programs, yet have
an almost irrational prejudice against regular expressions.
This is doubly curious because both Haskell and regular expressions
are based quite heavily on mathematical backgrounds, so it's yet another
thing in common with them.
You might not realize it, but regular expressions were not designed
randomly on a whim, but there are strong mathematical ideas behind the
syntax. One thing where this can be seen is that matching strings against
a regular expression can be done extremely efficiently: The matching can
be done one character at a time, without having to buffer any characters
nor ever jumping back in the string being matched. In other words, the
algorithm simply goes through the string from beginning to end, without
ever needing to make a jump backwards (or buffering characters), comparing
it to the regexp, and that's it.
The way this is done is that the regular expression is first converted
into a state machine, and this is where the mathematical background
jumps in: Regular expressions have been expressly designed so that they
can be converted into state machines, for this exact purpose.
Or looking at it from the opposite direction: Regular expressions are
a very convenient way of defining a state machine (for matching strings).
What otherwise would take tens if not even hundreds of lines of data (or
code) can be written with relatively short strings using a few special
characters, in an intuitive way.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> "The troff(1) typesetting formatter was, as we noted in Chapter 2,
> Unix's original killer application."
>
> Oh really?
Yes. troff is what runs when you say "man bash" for example.
> And to think most people consider syntactic sugar to be a /good/ thing...
It depends if it's useful or not. Some people put in syntax sugar just to
make their language look like someone else's.
> "Stack-based languages are famous for supporting extremely tight,
> economical coding and infamous for being difficult to read. PostScript
> shares both traits."
>
> Really? The design of PostScript looks fairly UNeconomical to me.
No, the *program* is economical. Recognise that FORTH (for example) fits an
entire operating system, compiler, runtime, with disk drivers and
everything, into about 4K. It's often used to program boot roms, embedded
stuff like televisions, etc. Postscript is very economical in terms of
writing code to display stuff on paper. They're not talking about the
interpreter. They're talking about the code you write using the interpreter.
> "Syntactically JavaScript resembles Java with some influence from Perl,
> and features Perl-like regular expressions."
>
> Since when does JS have regular expressions?
Since when does javascript resemble Java at all? Or, for that matter, have
any influence from Perl?
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> "The troff(1) typesetting formatter was, as we noted in Chapter 2,
>> Unix's original killer application."
>>
>> Oh really?
>
> Yes. troff is what runs when you say "man bash" for example.
Oh, so *that's* what that does?
So when it says "reformatting manpage", it's running troff?
I've always thought that manpages and the ugliest, lamest, most archaic
thing ever, so I don't see that that's much of an advantage.
(On the other hand, today's reading suggests that troff is really
designed to control phototypesetters - whatever those are - and not
produce stuff on screen...)
>> And to think most people consider syntactic sugar to be a /good/ thing...
>
> It depends if it's useful or not. Some people put in syntax sugar just
> to make their language look like someone else's.
Well, there's syntax /sugar/, which lets you do something more easily or
more readably, and then there's just /syntax/ for no good reason. ;-)
>> Really? The design of PostScript looks fairly UNeconomical to me.
>
> No, the *program* is economical.
So you mean it lets you do what you want done without writing too much code?
>> "Syntactically JavaScript resembles Java with some influence from
>> Perl, and features Perl-like regular expressions."
>>
>> Since when does JS have regular expressions?
>
> Since when does javascript resemble Java at all? Or, for that matter,
> have any influence from Perl?
Well, it has C-style syntax and it has objects in it. That's Java,
right? :-P
(Then again, we all know why it's called JavaScript in the first place,
so...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible escreveu:
> On 05/11/2010 01:53 PM, Invisible wrote:
>
>> Some select quotations:
>
> Man, this thing is a mine of select quotations. For example,
>
> "[the inventor of Ethernet] says that if something comes along to
> replace Ethernet, it will be called “Ethernet”, so therefore Ethernet
> will never die. Unix has already undergone several such transformations."
>
> Think about that for a moment.
Unix was born out of Multics. The funny fact is that Multics remained
unique and Unix splittered among multiple incompatible flavors... :)
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> "[the inventor of Ethernet] says that if something comes along to
>> replace Ethernet, it will be called “Ethernet”, so therefore Ethernet
>> will never die. Unix has already undergone several such transformations."
>>
>> Think about that for a moment.
>
> Unix was born out of Multics. The funny fact is that Multics remained
> unique and Unix splittered among multiple incompatible flavors... :)
AFAIK, that's because Multics died shortly after birth, whereas Unix
will live forever (and therefore continue reproducing...)
It's natural selection, baby!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible escreveu:
> http://web.archive.org/web/20080730063308/http://www.faqs.org/docs/artu/ch08s02.html
> Some select quotations:
>
> "Regular expressions are an extreme example of how concise a
> mini-language can be. Simple regular expressions express recognition
> behaviour that would otherwise have to be implemented with hundreds of
> lines of fussy, bug-prone code."
>
> Oh really? What what makes you think people don't use *libraries* for
> pattern recognition? :-P
calling libs still far too verbose next to the power of regexes.
> "Once you get past the verbosity of XML, Glade markup is a fairly simple
> language."
>
> LOL! Yeah... (This quote appears just below a 32-line "Hello World"
> example for Glade.)
nobody writes GUI glade descriptions by hand, nor should.
> "The troff(1) typesetting formatter was, as we noted in Chapter 2,
> Unix's original killer application."
>
> Oh really? Damn, I'm going to have to go look up what the hell troff is
> now...
man pages, anyone?
> "The traditional term for this sort of thing is syntactic sugar; the
> maxim that goes with this is a famous quip that “syntactic sugar causes
> cancer of the semicolon”. Indeed, syntactic sugar needs to be used
> sparingly lest it obscure more than help."
>
> And to think most people consider syntactic sugar to be a /good/ thing...
it obviously does not cause cancer of the semicolon in non-C languages.
> Language power, size and complexity are not necessarily related as
> directly as this suggests.
>
> The Iota calculus has 1 data type, 1 operator, and 1 constant, and it
> manages to be Turing-complete. So it's as "capable" as you can get, and
> just about as "small" as you can get. But powerful? Not really. Complex?
> You betcha! o_O
>
> Having fewer features can make a language /more complicated/ to actually
> *use*. Sometimes a bigger language is easier to use. And sometimes you
> can make a language smaller /and/ simpler /and/ easier to use. It's not
> as simple as bigger = more complex = more powerful.
yes.
> "Syntactically JavaScript resembles Java with some influence from Perl,
> and features Perl-like regular expressions."
>
> Since when does JS have regular expressions?
since the beginning.
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05/11/2010 04:12 PM, Warp wrote:
> I have always found it curious that you are infatuated with a
> programming language known for the brevity of its programs, yet have
> an almost irrational prejudice against regular expressions.
>
> This is doubly curious because both Haskell and regular expressions
> are based quite heavily on mathematical backgrounds, so it's yet another
> thing in common with them.
It's not the concept of a regular expression as such. It's the fact that
all known implementations work by mixing up code and data in the same
encrypted string.
OK, so it's convenient to be able to say "foo*bar" and mean "any string
that starts with 'foo' and ends with 'bar'". But by the time you've
added 25 different special characters with a dense set of possible means
such that you have an almost Turing-complete language, my reaction is
"for God's sake, stop trying to encode the entire language grammar into
a text string and go use a /real/ programming language!"
FWIW, I dislike printf format strings for essentially the same reason...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible escreveu:
> OK, so it's convenient to be able to say "foo*bar" and mean "any string
> that starts with 'foo' and ends with 'bar'". But by the time you've
> added 25 different special characters with a dense set of possible means
> such that you have an almost Turing-complete language, my reaction is
> "for God's sake, stop trying to encode the entire language grammar into
> a text string and go use a /real/ programming language!"
>
> FWIW, I dislike printf format strings for essentially the same reason...
you dislike DSLs, point taken.
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> It's not the concept of a regular expression as such. It's the fact that
> all known implementations work by mixing up code and data in the same
> encrypted string.
I don't understand what you mean by that.
> OK, so it's convenient to be able to say "foo*bar" and mean "any string
> that starts with 'foo' and ends with 'bar'".
Actually it doesn't mean that.
> But by the time you've
> added 25 different special characters with a dense set of possible means
> such that you have an almost Turing-complete language, my reaction is
> "for God's sake, stop trying to encode the entire language grammar into
> a text string and go use a /real/ programming language!"
Regular expressions define less than 10 special characters (vertical bar
signifying in practice a boolean 'or', parentheses for grouping, two
quantification symbols and one "wildcard" symbol). Extended regular
expressions add a few more (the '+' quantification symbol and []), but
the total still remains under 10.
Regular expressions are nowhere near Turing strong. They are state
machines.
I don't know what you are confusing regular expressions with, but they
are not that complicated.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> I've always thought that manpages and the ugliest, lamest, most archaic
> thing ever, so I don't see that that's much of an advantage.
If you have to read a manual through a VT100 terminal, what would you
suggest as a better alternative?
(And yes, even *today* people still need sometimes do things through
ancient terminal emulation. Usually today the connection is encrypted
(ever heard of ssh?) unlike in the early days, but it's still the same
thing.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I've always thought that manpages and the ugliest, lamest, most archaic
>> thing ever, so I don't see that that's much of an advantage.
>
> If you have to read a manual through a VT100 terminal, what would you
> suggest as a better alternative?
Well, yes. But people say "the Amiga is associated with a strong
tradition of graphics work", and that's because it had really ace
software /and hardware/. So when somebody says "typesetting is /the/
killer application for Unix", you don't expect some ugly archaic looking
text-only interface...
> (And yes, even *today* people still need sometimes do things through
> ancient terminal emulation. Usually today the connection is encrypted
> (ever heard of ssh?) unlike in the early days, but it's still the same
> thing.)
Yes, I've used SSH myself. It's quite neat that I can have an old 386
laptop sitting in a cupboard somewhere and operate it basically as if I
was sitting in front of it. On the other hand, would it be so hard to do
so with a less primitive interface? (I suppose I should have installed X...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
>>> "The troff(1) typesetting formatter was, as we noted in Chapter 2,
>>> Unix's original killer application."
>>>
>>> Oh really?
>>
>> Yes. troff is what runs when you say "man bash" for example.
>
> Oh, so *that's* what that does?
>
> So when it says "reformatting manpage", it's running troff?
Well, technically, nroff, which takes the same input as troff and tries to
put it on an ASCII stream. Kind of like the difference between firefox and lynx.
> I've always thought that manpages and the ugliest, lamest, most archaic
> thing ever, so I don't see that that's much of an advantage.
Except it was (one of) the first macro-driven multi-output typesetting tool.
> (On the other hand, today's reading suggests that troff is really
> designed to control phototypesetters - whatever those are - and not
> produce stuff on screen...)
A phototypesetter is how you used to do high-quality typesetting before
laser printers. Think of it as a daisywheel laser printer.
>>> Really? The design of PostScript looks fairly UNeconomical to me.
>>
>> No, the *program* is economical.
>
> So you mean it lets you do what you want done without writing too much
> code?
Yes. Considering that it's designed to be shipped over a serial line,
that's a good thing compared to shipping gigabyte bitmaps.
> Well, it has C-style syntax
No it doesn't. Unless you mean curly braces.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
>you don't expect some ugly archaic looking
> text-only interface...
That's only because you don't know what typesetter machines looked like in
the 1970s.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> It's not the concept of a regular expression as such. It's the fact that
>> all known implementations work by mixing up code and data in the same
>> encrypted string.
>
> I don't understand what you mean by that.
I'd much prefer to see a much bigger separation between what's a literal
character and what's a command. In fact, if they didn't try to encode
the entire expression as a flat character string, you could probably use
it to match against streams of other data, not just characters.
(Although admittedly text is probably the most likely place you'd want
elaborate pattern matching.)
>> But by the time you've
>> added 25 different special characters with a dense set of possible means
>> such that you have an almost Turing-complete language, my reaction is
>> "for God's sake, stop trying to encode the entire language grammar into
>> a text string and go use a /real/ programming language!"
>
> Regular expressions define less than 10 special characters.
Depending on /which/ regular expressions you mean, of course. Is that
POSIX Basic Regular Expressions? POSIX Extended Regular Expressions?
Perl 5.0 Regular Expressions? Perl Compatible Regular Expressions?
Something else?
A quick inspection of Wikipedia suggests that POSIX ERE involves at
least .[]^$()\*{}?+|:, which is 16, not 10. (Still, it's not the
thousands it seemed like last time I tried to learn this stuff.)
> Regular expressions are nowhere near Turing strong. They are state
> machines.
I recall reading somewhere that Perl's "regular expressions" aren't
actually regular, and so require exponential time for matching. Truly
regular expressions apparently require only linear time.
> I don't know what you are confusing regular expressions with, but they
> are not that complicated.
Perhaps.
The other thing I dislike is that people seem to have a tendency to use
regexs where they should be using a real parser. For example, I recently
saw a Haskell example where they used a fistful of regexs to "parse" SVG
input.
OK, it was an example program. They did it that way so you can run the
example without having to download and install a real XML parser
library. But the result is still incredibly fragile. For example, if you
comment out a chunk of code using an XML comment, the "parser" will
completely fail to notice that the code is commented out and will
inspect it anyway, possibly producing very surprising results.
In short, people tend to use regexs for quick and dirty hacks that kinda
work, rather than doing the job properly with a full parser. And I'm
really not fond of hacks.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> I'd much prefer to see a much bigger separation between what's a literal
> character and what's a command.
Technically, they're all commands. The letter "s" means "match against the
letter s." :-)
> you could probably use
> it to match against streams of other data, not just characters.
You can. For example, Singularity uses "regular expressions" to match
permissions. "if it started as the FTPD server and then fred logged in and
it launched ls, *or* it started as the sshd server and any administrator
logged in, then you launched a shell *then* you launched ls, allow access to
this directory."
> A quick inspection of Wikipedia suggests that POSIX ERE involves at
> least .[]^$()\*{}?+|:, which is 16, not 10. (Still, it's not the
> thousands it seemed like last time I tried to learn this stuff.)
: and {} and ^ $ aren't original regular expression characters. Technically
not + either, so I think that's where the 10 come from. The rest are
short-cuts for what you can already otherwise specify (: + { }), or are
useful for programming but outside the theory (^$).
>
>> Regular expressions are nowhere near Turing strong. They are state
>> machines.
>
> I recall reading somewhere that Perl's "regular expressions" aren't
> actually regular, and so require exponential time for matching. Truly
> regular expressions apparently require only linear time.
Correct. And not only exponential time, but memory as well. A regular
expression is regular because it requires a fixed amount of memory to match
or reject.
> The other thing I dislike is that people seem to have a tendency to use
> regexs where they should be using a real parser.
Yes, well, that's because people are stupid, not regexps.
> But the result is still incredibly fragile.
Yes, because regular expressions can't parse XML. One of the benefits of
regular expressions is you can tell when they'll fail.
> In short, people tend to use regexs for quick and dirty hacks that kinda
> work, rather than doing the job properly with a full parser. And I'm
> really not fond of hacks.
Only stupid people. Learn regexps, and learn the theory behind them, so when
the boss asks you to write a parser, you know which one to use.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> >> It's not the concept of a regular expression as such. It's the fact that
> >> all known implementations work by mixing up code and data in the same
> >> encrypted string.
> >
> > I don't understand what you mean by that.
> I'd much prefer to see a much bigger separation between what's a literal
> character and what's a command.
It would become a burden with simple regular expressions.
> > Regular expressions define less than 10 special characters.
> Depending on /which/ regular expressions you mean, of course. Is that
> POSIX Basic Regular Expressions? POSIX Extended Regular Expressions?
> Perl 5.0 Regular Expressions? Perl Compatible Regular Expressions?
> Something else?
> A quick inspection of Wikipedia suggests that POSIX ERE involves at
> least .[]^$()\*{}?+|:, which is 16, not 10. (Still, it's not the
> thousands it seemed like last time I tried to learn this stuff.)
Well, regular expressions do not have all of those special characters,
extended regular expressions do. Also, I conflated [ and ] into one "special
character" because they are counterparts of the same special meaning
(in other words, I was more thinking of "keywords" of sorts rather than
individual characters). Likewise for () and {}. Also , is special only
inside {} and : is special only inside [], so I conflated them into the
same "special character".
> > Regular expressions are nowhere near Turing strong. They are state
> > machines.
> I recall reading somewhere that Perl's "regular expressions" aren't
> actually regular, and so require exponential time for matching. Truly
> regular expressions apparently require only linear time.
I wasn't really talking about perl. (Perl RE's add things like multi-line
matching, which is a lot more complex.)
> The other thing I dislike is that people seem to have a tendency to use
> regexs where they should be using a real parser. For example, I recently
> saw a Haskell example where they used a fistful of regexs to "parse" SVG
> input.
As Darren said, does the fact that regular expressions are abused for
purposes they are not really intended for make them detestable?
Regular expressions are not a really good way of tokenizing some
formatted input. There are other languages much better designed for
that purpose, such as BNF.
> In short, people tend to use regexs for quick and dirty hacks that kinda
> work, rather than doing the job properly with a full parser. And I'm
> really not fond of hacks.
Writing a parser, even with the aid of a specialized description language
such as BNF, is very laborious. Simple string matching can be often expressed
with very short regular expressions which you can write in a few seconds.
Writing a parser would be complete overkill.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> In short, people tend to use regexs for quick and dirty hacks that kinda
>> work, rather than doing the job properly with a full parser. And I'm
>> really not fond of hacks.
>
> Writing a parser, even with the aid of a specialized description language
> such as BNF, is very laborious. Simple string matching can be often
> expressed
> with very short regular expressions which you can write in a few seconds.
> Writing a parser would be complete overkill.
I think he meant using a parser library, not writing one from scratch.
Indeed writing a parser (or a regex library) would be a total overkill for
pretty much any project.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott <sco### [at] scottcom> wrote:
> >> In short, people tend to use regexs for quick and dirty hacks that kinda
> >> work, rather than doing the job properly with a full parser. And I'm
> >> really not fond of hacks.
> >
> > Writing a parser, even with the aid of a specialized description language
> > such as BNF, is very laborious. Simple string matching can be often
> > expressed
> > with very short regular expressions which you can write in a few seconds.
> > Writing a parser would be complete overkill.
> I think he meant using a parser library, not writing one from scratch.
I was talking about parser libraries (you know, those which eat BNF or
other such syntax definition languages).
If you had to code a parser from scratch, it would be a hundred times
more work still.
> Indeed writing a parser (or a regex library) would be a total overkill for
> pretty much any project.
*Using* a parser library for something which can be easily expressed with
a regexp string would be complete overkill.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/11/2010 10:11 PM, Warp wrote:
> *Using* a parser library for something which can be easily expressed with
> a regexp string would be complete overkill.
Yeah, that's true. Writing
string "foo"
many char
string "bar"
is drastically harder than just saying "foo*bar".
Oh, wait...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 08/11/2010 05:31 PM, Darren New wrote:
> Invisible wrote:
>> I'd much prefer to see a much bigger separation between what's a
>> literal character and what's a command.
>
> Technically, they're all commands. The letter "s" means "match against
> the letter s." :-)
Well, if you wanted to split hairs, it's the implicit command "match
against a specific character" plus the argument "s". :-P
>> you could probably use it to match against streams of other data, not
>> just characters.
>
> You can.
Not in any regex product I've ever seen. (Although I won't claim to be
an authority on the subject.) Most people seem to equate "regex" with
"shorthand for writing text parsers".
>> A quick inspection of Wikipedia suggests that POSIX ERE involves at
>> least .[]^$()\*{}?+|:, which is 16, not 10. (Still, it's not the
>> thousands it seemed like last time I tried to learn this stuff.)
>
> : and {} and ^ $ aren't original regular expression characters.
> Technically not + either, so I think that's where the 10 come from. The
> rest are short-cuts for what you can already otherwise specify (: + {
> }), or are useful for programming but outside the theory (^$).
So much for theory. Most "regular expressions" out there aren't even
regular. I don't know much about the theory; what I know about is the
actual regex tools that you can actually use.
>> I recall reading somewhere that Perl's "regular expressions" aren't
>> actually regular, and so require exponential time for matching. Truly
>> regular expressions apparently require only linear time.
>
> Correct. And not only exponential time, but memory as well. A regular
> expression is regular because it requires a fixed amount of memory to
> match or reject.
Is that the definition of "regular" then?
>> The other thing I dislike is that people seem to have a tendency to
>> use regexs where they should be using a real parser.
>
> Yes, well, that's because people are stupid, not regexps.
> Only stupid people. Learn regexps, and learn the theory behind them, so
> when the boss asks you to write a parser, you know which one to use.
My boss well never, ever ask me to write a parser. (Mostly because he
doesn't know what one is, or that such a process is actually necessary.)
Regardless, if you're trying to do complicated parsing, you should use
real parser tools, not a regex.
Now if you just want to do a quick wildcard search, then why not? It can
be useful to be able to say, for example, DELETE *.PNG or something. But
by the time you get to the point where your search term is practically a
predicate calculus, you really shouldn't be trying to encode the entire
thing as a flat character string. You should use a real language instead.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> On 09/11/2010 10:11 PM, Warp wrote:
> > *Using* a parser library for something which can be easily expressed with
> > a regexp string would be complete overkill.
> Yeah, that's true. Writing
> string "foo"
> many char
> string "bar"
> is drastically harder than just saying "foo*bar".
> Oh, wait...
Nice straw man. (And "foo*bar" still doesn't mean what you think it means
as a regex.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Nice straw man.
Wasn't his problem that he didn't have a brain?
> (And "foo*bar" still doesn't mean what you think it means
> as a regex.)
So, what, it means
string "fo"
many (char 'o')
string "bar"
Or am I reading this wrong?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Not in any regex product I've ever seen.
You don't even use text regular expressions, so that's not very
authoritative. ;-)
Seriously, any DFA is the equivalent of a regex.
> Most people seem to equate "regex" with "shorthand for writing text parsers".
Sure. But exactly the same theory works for any stream of tokens. You can
use most modern libraries to match, for example, unicode, which includes
chinese, so right there you're outside the "text" area, let alone if you
write your own parser.
> So much for theory. Most "regular expressions" out there aren't even
> regular.
Sure they are. Unless you use a back-escape (i.e., substitute in something
that you earlier matched) then it's all regular. Stuff like {} and + are
just trivial macros to reduce typing. I think I use a backmatch maybe once
every two or three years interactively, and I don't think I've ever used one
programmatically.
>>> I recall reading somewhere that Perl's "regular expressions" aren't
>>> actually regular, and so require exponential time for matching. Truly
>>> regular expressions apparently require only linear time.
>>
>> Correct. And not only exponential time, but memory as well. A regular
>> expression is regular because it requires a fixed amount of memory to
>> match or reject.
>
> Is that the definition of "regular" then?
Wikipedia is your friend. But yes, that's part of the definition. A language
is regular if it can be matched by a DFA.
> Regardless, if you're trying to do complicated parsing, you should use
> real parser tools, not a regex.
Again, it depends what you're trying to parse. Are you trying to parse a
file full of lines like
structure_size = 37
structure_drift = 92.7E13
etc? A regexp will do just fine.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> On 09/11/2010 10:11 PM, Warp wrote:
>
>> *Using* a parser library for something which can be easily
>> expressed with
>> a regexp string would be complete overkill.
>
> Yeah, that's true. Writing
>
> string "foo"
> many char
> string "bar"
>
> is drastically harder than just saying "foo*bar".
>
> Oh, wait...
OK, so how do you do
(\+|-)[0-9]+(\.[0-9]+)?(E(\+|-)?[0-9]{1,3})?
in your parser language?
(That is, optional sign, one or more digits, optional decimal point followed
by one or more digits, optional E followed by optional sign followed by one
to three digits.)
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> (\+|-)[0-9]+(\.[0-9]+)?(E(\+|-)?[0-9]{1,3})?
Btw, it's a surprisingly little known fact that at least in C and C++
things like 10. and 10.e5 are valid floating point literals (besides the
more usual .1 form).
If you wanted to take that into account in a regexp like the one above,
it actually becomes a bit verbose (so that a lone . wouldn't be considered
a valid floating point literal). Basically you need to write the above twice
(with slight differences, and the two parts separated with a |.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> OK, so how do you do
>
> (\+|-)[0-9]+(\.[0-9]+)?(E(\+|-)?[0-9]{1,3})?
>
> in your parser language?
OK, that's one big ol' complex regex, right there.
> (That is, optional sign, one or more digits, optional decimal point
> followed by one or more digits, optional E followed by optional sign
> followed by one to three digits.)
If I've understood the spec correctly, it's
do
option (char '+' <|> char '-')
many1 digit
option (char '.')
many1 digit
option (do char 'E'; option (char '+' <|> char '-'); many1 digit)
Enforcing that the exponent is less than or equal to 3 digits would be
slightly more wordy. The obvious way is
xs <- many1 digit
if length xs > 3 then fail else return ()
Notice that since this is written in a /real/ programming language and
not a text string, we can do
sign = char '+' <|> char '-'
number = do
option sign
many1 digit
option (char '.')
many1 digit
option (do char 'E'; option sign; many1 digit)
and save a little typing. You can also factor the task into smaller pieces:
sign = char '+' <|> char '-'
exponent = do
char 'E'
option sign
xs <- many1 digit
if length xs > 3 then fail else return ()
number = do
option sign
many1 digit
option (char '.')
many1 digit
option exponent
You can also do things like write a function that builds a special kind
of parser given a simpler spec.
With a regex, on the other hand, you cannot even statically guarantee
that a given string is even a syntactically valid regex. And that's
before you try to programmatically construct new ones. :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> (\+|-)[0-9]+(\.[0-9]+)?(E(\+|-)?[0-9]{1,3})?
>
> do
> option (char '+' <|> char '-')
> many1 digit
> option (char '.')
> many1 digit
> option (do char 'E'; option (char '+' <|> char '-'); many1 digit)
Hmm, now which one is more readable?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Basically you need to write the above twice
I would think at the worst you'd need to write the part before the "E" twice.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
>> OK, so how do you do
>>
>> (\+|-)[0-9]+(\.[0-9]+)?(E(\+|-)?[0-9]{1,3})?
>>
>> in your parser language?
>
> OK, that's one big ol' complex regex, right there.
That's a pretty simple regex, actually.
>> (That is, optional sign, one or more digits, optional decimal point
>> followed by one or more digits, optional E followed by optional sign
>> followed by one to three digits.)
>
> If I've understood the spec correctly, it's
>
> do
> option (char '+' <|> char '-')
> many1 digit
> option (char '.')
> many1 digit
> option (do char 'E'; option (char '+' <|> char '-'); many1 digit)
Bzzzt. Sorry. That requires at least a 2-digit number.
> Enforcing that the exponent is less than or equal to 3 digits would be
> slightly more wordy. The obvious way is
>
> xs <- many1 digit
> if length xs > 3 then fail else return ()
>
> Notice that since this is written in a /real/ programming language and
> not a text string, we can do
>
> sign = char '+' <|> char '-'
>
> number = do
> option sign
> many1 digit
> option (char '.')
> many1 digit
> option (do char 'E'; option sign; many1 digit)
>
> and save a little typing.
You can do that with many regexp engines too. That's what I meant by
"trivial macros".
> You can also factor the task into smaller pieces:
Yeah, that's just a text substitution in the regexp expression.
> With a regex, on the other hand, you cannot even statically guarantee
> that a given string is even a syntactically valid regex.
Nonsense. How'd you get that?
If you mean you can't use a regexp to parse a regexp, well, yeah, so?
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible escreveu:
>> Nice straw man.
>
> Wasn't his problem that he didn't have a brain?
>
>> (And "foo*bar" still doesn't mean what you think it means
>> as a regex.)
>
> So, what, it means
>
> string "fo"
> many (char 'o')
> string "bar"
>
> Or am I reading this wrong?
* means 0 or more of the previous pattern, in this case, letter 'o'.
+ means 1 or more.
"fobar" is accepted. The correct pattern should be foo+bar or foo.*bar.
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible escreveu:
>> OK, so how do you do
>>
>> (\+|-)[0-9]+(\.[0-9]+)?(E(\+|-)?[0-9]{1,3})?
>>
>> in your parser language?
>
> OK, that's one big ol' complex regex, right there.
I see you never looked at perl code.
>> (That is, optional sign, one or more digits, optional decimal point
>> followed by one or more digits, optional E followed by optional sign
>> followed by one to three digits.)
>
> If I've understood the spec correctly, it's
>
> do
> option (char '+' <|> char '-')
> many1 digit
> option (char '.')
> many1 digit
> option (do char 'E'; option (char '+' <|> char '-'); many1 digit)
so, besides the errors, are you satisfied to go the Lisp route and spell
out all functions rather than rely on specialized, more convenient
predefined syntax?
do you really believe spelling out "option (char '+' <|> char '-')" is
any worth as opposed to "(\+|-)"?
> Enforcing that the exponent is less than or equal to 3 digits would be
> slightly more wordy. The obvious way is
>
> xs <- many1 digit
> if length xs > 3 then fail else return ()
no, sorry. Truly overkill against "\d{3}".
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> xs <- many1 digit
> if length xs > 3 then fail else return ()
By the way, this also means you have backtracking, which means you have
exponential time and space requirements for your match rather than provably
linear time and constant space.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 escreveu:
> killer application for Unix", you don't expect some ugly archaic looking
> text-only interface...
>
> Yes, I've used SSH myself. It's quite neat that I can have an old 386
> laptop sitting in a cupboard somewhere and operate it basically as if I
> was sitting in front of it. On the other hand, would it be so hard to do
> so with a less primitive interface?
it's strange that I guy used to programming languages feels awkward
about a text interface. Plus, were you ever taught that one shouldn't
judge a book by its cover? Notepad in all its glorious graphical user
interface is much more featureless and rudimentar than vi on an old Unix
terminal.
There is power in words, they make spells and those magical enchantments
make things happen in the real world, like dispensing cash at your local
ATM.
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> I've always thought that manpages and the ugliest, lamest, most archaic
> thing ever, so I don't see that that's much of an advantage.
Oh, wait. Aren't you the one that goes on about LaTeX and Postscript? :-)
I'm not sure what you have against a text-based program for generating
typeset output.
> (On the other hand, today's reading suggests that troff is really
> designed to control phototypesetters - whatever those are - and not
> produce stuff on screen...)
Plus, they didn't produce stuff on screen. This is hardcopy land. Screens
were advanced stuff. :-)
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] gmailcom> wrote:
> Orchid XP v8 escreveu:
> > killer application for Unix", you don't expect some ugly archaic looking
> > text-only interface...
> >
> > Yes, I've used SSH myself. It's quite neat that I can have an old 386
> > laptop sitting in a cupboard somewhere and operate it basically as if I
> > was sitting in front of it. On the other hand, would it be so hard to do
> > so with a less primitive interface?
>
> it's strange that *a* guy used to programming languages feels awkward
> about a text interface. Plus, were you ever taught that one shouldn't
> judge a book by its cover? Notepad in all its glorious graphical user
> interface is much more featureless and *rudimentary* than vi on an old Unix
> terminal.
>
> There is power in words, they make spells and those magical enchantments
> make things happen in the real world, like dispensing cash at your local
> ATM.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> xs <- many1 digit
>> if length xs > 3 then fail else return ()
>
> By the way, this also means you have backtracking
No it doesn't.
Parsec doesn't backtrack by default; you have to explicitly request it
(which I haven't).
If there are more than three digits, the above parser fails, and no
other alternatives are tried (i.e., no backtracking).
(As an aside, there are other Haskell libraries that work similarly to
Parsec, but where backtracking is the default and turning it off is
explicit. Apparently this is more intuitive to work with...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> OK, that's one big ol' complex regex, right there.
>
> I see you never looked at perl code.
It's something I generally try to avoid, yeah. :-)
> do you really believe spelling out "option (char '+' <|> char '-')" is
> any worth as opposed to "(\+|-)"?
Um, *yes*. Why, do you think it doesn't have worth?
>> Enforcing that the exponent is less than or equal to 3 digits would be
>> slightly more wordy. The obvious way is
>>
>> xs <- many1 digit
>> if length xs > 3 then fail else return ()
>
> no, sorry. Truly overkill against "\d{3}".
So define a combinator for it:
manyN 0 _ = return []
manyN n p = do x <- p; xs <- manyN (n-1) p; return (x:xs)
And now, forever more, you can merely write
manyN 3 digit
Problem solved.
EDIT: Apparently this function is already predefined. I hadn't even
noticed. I could have just written "count 3 digit". In all the time I've
been writing parsers, I've never needed this.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> (That is, optional sign, one or more digits, optional decimal point
>>> followed by one or more digits, optional E followed by optional sign
>>> followed by one to three digits.)
>>
>> If I've understood the spec correctly, it's
>>
>> do
>> option (char '+' <|> char '-')
>> many1 digit
>> option (char '.')
>> many1 digit
>> option (do char 'E'; option (char '+' <|> char '-'); many1 digit)
>
> Bzzzt. Sorry. That requires at least a 2-digit number.
I don't follow. Where do you think by definition deviates from your spec?
>> Notice that since this is written in a /real/ programming language and
>> not a text string, we can do
>>
>> and save a little typing.
>
> You can do that with many regexp engines too. That's what I meant by
> "trivial macros".
I've never seen a system that can do that, but I guess that doesn't
prove a lot.
>> You can also factor the task into smaller pieces:
>
> Yeah, that's just a text substitution in the regexp expression.
Sure. Except without any guarantee of syntactic correctness.
>> With a regex, on the other hand, you cannot even statically guarantee
>> that a given string is even a syntactically valid regex.
>
> Nonsense. How'd you get that?
Not every string is a valid regex. You have to follow the syntax rules.
But this is not checked at compile-time (and usually /cannot/ be checked
at compile-time). So if you make a typo in your regex, you won't find
out until runtime.
If you start constructing regexs programmatically, your problems just
multiplied.
On the other hand, with a /real/ parser library, both of these grave
problems immediately vanish into thin air.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/11/2010 05:55 PM, scott wrote:
>>> (\+|-)[0-9]+(\.[0-9]+)?(E(\+|-)?[0-9]{1,3})?
>>
>> do
>> option (char '+' <|> char '-')
>> many1 digit
>> option (char '.')
>> many1 digit
>> option (do char 'E'; option (char '+' <|> char '-'); many1 digit)
>
> Hmm, now which one is more readable?
Exactly.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Yes, I've used SSH myself. It's quite neat that I can have an old 386
>> laptop sitting in a cupboard somewhere and operate it basically as if
>> I was sitting in front of it. On the other hand, would it be so hard
>> to do so with a less primitive interface?
>
> it's strange that I guy used to programming languages feels awkward
> about a text interface.
No, it feels awkward when you sit at a text terminal that's using ANSI
escape codes to generate colours and block graphics characters to "draw"
a "graphical" user interface. I mean, why not just have a /real/
graphical user interface?
> Notepad in all its glorious graphical user
> interface is much more featureless and rudimentar than vi on an old Unix
> terminal.
Sure. But that's because Notepad sucks beyond belief. ;-)
I'm not arguing that the CLI is useless. I'm arguing that ASCII-art
"graphical" UIs are silly.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/11/2010 10:07 PM, Darren New wrote:
> Invisible wrote:
>> I've always thought that manpages and the ugliest, lamest, most
>> archaic thing ever, so I don't see that that's much of an advantage.
>
> Oh, wait. Aren't you the one that goes on about LaTeX and Postscript?
> :-) I'm not sure what you have against a text-based program for
> generating typeset output.
TeX, PostScript, HTML, it's all good.
I'm just saying that the finished product looks awful.
The reason I put up with TeX, in spite of its innumerable and obvious
limitations, is that it produces very, very nice output. troff doesn't
seem to compare to that.
> Plus, they didn't produce stuff on screen. This is hardcopy land.
> Screens were advanced stuff. :-)
Apparently that's also why all Unix commands fail to offer even the most
basic feedback as to what's happening, unless something actually goes
wrong. It's to save paper.
So really, Unix invented environmentalism, 60 years ahead of the rest of
Western civilisation. :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible escreveu:
> I'm not arguing that the CLI is useless. I'm arguing that ASCII-art
> "graphical" UIs are silly.
and I agree here. However, ssh, bash or vi don't even attempt such
sillyness, so I wonder what's your point with ssh as example of that...
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible escreveu:
>> do you really believe spelling out "option (char '+' <|> char '-')" is
>> any worth as opposed to "(\+|-)"?
>
> Um, *yes*. Why, do you think it doesn't have worth?
it's far more verbose and, thus, hurts readability?
come on! do you even need those quotes around the symbols?
>>> xs <- many1 digit
>>> if length xs > 3 then fail else return ()
>>
>> no, sorry. Truly overkill against "\d{3}".
BTW, my mistake. Should be "\d{0,3}"
> So define a combinator for it:
>
> manyN 0 _ = return []
> manyN n p = do x <- p; xs <- manyN (n-1) p; return (x:xs)
>
> And now, forever more, you can merely write
>
> manyN 3 digit
>
> Problem solved.
then try this in your little language:
// A phone number with or without hyphens:
[2-9]\d{2}-?\d{3}-?\d{4}
It looks pretty much like a template for a phone number. I'm sure yours
will look like a little backwards forth script and will be much harder
to figure out.
I also wonder if it's the postfix nature of regexes that bothers you...
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] gmailcom> wrote:
> do you really believe spelling out "option (char '+' <|> char '-')" is
> any worth as opposed to "(\+|-)"?
Btw, "(\+|-)" is unnecessarily complex. Just use "[+-]". That's exactly
what the [] syntax is for.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> No, it feels awkward when you sit at a text terminal that's using ANSI
> escape codes to generate colours and block graphics characters to "draw"
> a "graphical" user interface. I mean, why not just have a /real/
> graphical user interface?
Do you understand the concept of bandwidth? And that it can be quite
limited?
The VT protocol was designed back when you were lucky if you could
transfer than a few kilobytes per second, so they had to maximize what
you could do while at the same time minimizing the need to transfer data.
Today this might be more obsolete than it was 20 years ago, but there
are still benefits to that. The standard is quite well-established and
has been around forever, so almost every system in existence supports it.
Also, being text-based (and low-bandwidth) you can create or port terminal
emulators to almost any system with a screen and a keyboard, even very
exotic ones. For instance, it's pretty common for unix-savvy people to
have a terminal emulator on their cellphones so that they can contact
their computer or whatever remotely. A remote GUI would simply not do.
> I'm not arguing that the CLI is useless. I'm arguing that ASCII-art
> "graphical" UIs are silly.
Sometimes you have to resort to them to organize what is displayed.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Um, *yes*. Why, do you think it doesn't have worth?
>
> it's far more verbose and, thus, hurts readability?
Far more verbose, and as a consequence it's almost self-explanatory what
it does. (Unlike a collection of symbols that have no widely-accepted
meaning outside of regex languages...)
> come on! do you even need those quotes around the symbols?
Yes. Because this is a real programming language, you could replace the
character name with a variable, for example. In this way you can make
the pattern parameterised.
> then try this in your little language:
>
> // A phone number with or without hyphens:
> [2-9]\d{2}-?\d{3}-?\d{4}
>
> It looks pretty much like a template for a phone number. I'm sure yours
> will look like a little backwards forth script and will be much harder
> to figure out.
I actually can't figure out what that does, so I can't implement it.
> I also wonder if it's the postfix nature of regexes that bothers you...
No, mostly it comes down to these:
1. Commands have cryptic names like "*" or "+".
2. Literal characters aren't quoted, so it's hard to tell what's literal
and what's a command.
(And 3. since spaces are literal characters, you can't even use spacing
to make the structure of the expression clearer.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Today this might be more obsolete than it was 20 years ago, but there
> are still benefits to that. The standard is quite well-established and
> has been around forever, so almost every system in existence supports it.
It sounds a bit like Unix itself: It's not actually a very good idea,
but everything in Creation supports it, and so it will remain around
forever.
Actually, I found a rather interesting description of the history of
Unix the other day. I'll have to see if I can find it again. As you read
it, you discover that many design decisions that look stupid are in fact
merely obsolete. They served a purpose 60 years ago, it's just that they
aren't the best choice any more.
> Also, being text-based (and low-bandwidth) you can create or port terminal
> emulators to almost any system with a screen and a keyboard, even very
> exotic ones. For instance, it's pretty common for unix-savvy people to
> have a terminal emulator on their cellphones so that they can contact
> their computer or whatever remotely. A remote GUI would simply not do.
These days, the fashion seems to be for everything from print servers to
network hubs to be controlled by HTML over HTTP. Which is equally
stupid, but looks more pretty...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> Actually, I found a rather interesting description of the history of
> Unix the other day. I'll have to see if I can find it again. As you read
> it, you discover that many design decisions that look stupid are in fact
> merely obsolete. They served a purpose 60 years ago, it's just that they
> aren't the best choice any more.
That would be quite strange, given that Unix was originally developed
41 years ago.
> > Also, being text-based (and low-bandwidth) you can create or port terminal
> > emulators to almost any system with a screen and a keyboard, even very
> > exotic ones. For instance, it's pretty common for unix-savvy people to
> > have a terminal emulator on their cellphones so that they can contact
> > their computer or whatever remotely. A remote GUI would simply not do.
> These days, the fashion seems to be for everything from print servers to
> network hubs to be controlled by HTML over HTTP. Which is equally
> stupid, but looks more pretty...
Well, it has the advantage that it's still relatively low-bandwidth and
usable with any web browser in any system, and you can do things with the
mouse.
Of course the downside is that you need something that can run a web
browser.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
