|
![](/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) |