![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
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
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
will never die. Unix has already undergone several such transformations."
Think about that for a moment.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> "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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> "[the inventor of Ethernet] says that if something comes along to
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |