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