Re: the disadvantages of mini-languages

Okay.. First of all, you need to spend some time meditating on the definition of the word 'language' as it applies to computer programming. It's a heavily overloaded term, and your post deals with a specific confusion of meaning between two very different definitions. On the one hand, we have 'languages' like Perl which are a collection of keywords and syntax. On the other hand, we have 'languages' like finite automata, pushdown automata, and Turing machines.

Languages like Perl are really just syntactic sugar coating for a set of basic concepts which we use to express automata or Turing machines. A 'general purpose' language (of which there are about ten bazillion) supports the concepts necessary to create a Universal Turing Machine, an idea more commonly expressed as: "a language that can't compile itself isn't worth using." Of course, that isn't terribly difficult.. you can build a UTM with the operations '++' and '--', two arbitrarily large named integer variables, a big lookup table, and a whole lot of time.

Things like finite automata and Turing machines are the theoretical languages which identify the various types of problems a computer programmer can solve. Broadly speaking, there are five such languages:

Simple expressions which support Atomic values
Parametric expressions which support Simply enumerable sets
Finite automata which support Regular sets
Pushdown automata which support Context free grammars
Turing machines which support Recursively enumerable sets

And at the end of the day, ain't a damnthing any programmer can do that doesn't fall into one of those categories.

Syntactic-sugar languages like Perl support several different ways to express any one of those theoretical languages. %Hashes and @lists are parametric expressions, but so is a function that takes a parameter and returns a value. Perl's regular expression syntax gives us a convenient way to define finite automata, but that doesn't stop any program from having its own state chart. You can build a pushdown automaton with a finite automaton and a stack, or you can just make a set of nested function calls.

When you get down to basics, programming consists of nothing but creating new syntactic-sugar languages appropriate to the task at hand. Every function you name is a new keyword with its own set of semantics. And unless you're really into frustration and wasted time, the language you create has to be powerful enough to solve the problem at hand. You can't balance parentheses with a finite automaton (1), and you can't do binary multiplication with a pushdown automaton.

(1) Yes, yes.. I know Perl's regex engine has a pragma for just-in-time compilation of targets which supports infinitely extensible, recursively defined patterns. A recursively-defined *anything* is a context free grammar at the very least. The pragma boosts Perl's regex engine into the realm of pushdown automata rather than proving you can solve PA-complete problems with a finite automaton. If you wish to argue otherwise, please include an implementation of the just-in-time pragma written only in Perl's regex syntax without the pragma.

Now, it's interesting that you chose to complain about the mini-languages associated with template systems, because arbitrary string replacement -- at least if you do it repeatedly -- happens to be a Turing-complete problem. In fact, 'arbitrary string replacement' is a fairly good description of lambda calculus.

So.. given that you need a Turing-complete language just to describe the problem any template system is trying to solve, you're pretty much stuck with two options:

Go the PHP route (like Greenspun), and turn every page into a first-class executable code object, or
Create a new language which supports string substitution, and write a compiler to process the pages.

Now, speaking as someone who's had to manage sites composed of first-class executable pages, I can say with conviction that the separation of concern issues others have raised are NOTHING compared to the synchronization and version-control issues inherent in trying to ride herd over a jillion different page/programs all loosely tied to the same code base. Sifting through all the pages in a site trying to find and update the cut-and-paste code for a given display item is time consuming. Trying to ferret out all the instances of cut-paste-and-modify code is exhausting. Factoring out a common code base for the entire site and then bringing all the pages in line is a dot-X upgrade at the very least. And it lasts right up to the point where someone wants to do something new.

So.. it seems to me that you're objecting to the creation of a specific kind of syntactic-sugar language, which just happens to be Turing complete because that's necessary to describe the problem at hand, without presenting any really detailed argument as to why this particular new lanugage might be bad. Your only two real points: "If you need to do something the author hasn't thought of, you lose," and "who wants to learn another language?" apply equally well to the API of any Perl module on CPAN. Those are mini-languages too, and some of them are fairly complex. Show us some evidence that you're familiar with the problem domain before dismissing one kind of solution out of hand.

Comment on Re: the disadvantages of mini-languages

Replies are listed 'Best First'.
Re^2: the disadvantages of mini-languages by robnagler (Novice) on Feb 18, 2005 at 04:49 UTC
We don't program Turing Machines, just like we don't program in machine code any more. Languages are a means of expressing what we think in terms a computer can understand. If we can't express ourselves, we can't tell the computer what to do. Put another way: Programming languages teach you not to want what they cannot provide. You have to think in a language to write programs in it, and it's hard to want something you can't describe. Paul Graham, ANSI Common Lisp, Prentice Hall, 1996, p2. Perl is an ugly language, because it has evolved over the past two decades driven by real customer requirements. That's a good thing. Languages like Lisp, Prolog, and Haskell are beautiful, but I would guess that more function has been delivered in Perl than in the other three combined. Perl is available, and availability matters more than beauty to most people. `print "Hello, world!\n";` [download] This code is available to just about any programmer. The \n is a term from a well-known mini-language. print is a well-known verb. "Hello, world!" is a well-known example. We understand the above, because it is familiar to our context. `main: mov dx,str mov ah,9 int 021 ret str: db "Hello World!$"` [download] You probably understand this, because you recognize it is a canonical example. And, I already established the context with the first example. However, unless you are an old DOS hacker, you probably don't know what 021 is. It's the name of an API, and ah and dx hold its parameters. Just like, [] is an API as in ("Hello, World!")[0], and ("Hello, World!") and 0 are its parameters. If you don't know Perl, it might be hard to see that, especially if it looked like: (0)[0]. What does that smiley mean? You probably understand this sentence: `http://www.bivio.com/goto?x=http://yahoo.com` [download] However, do you understand this one? `http://www.bivio.com/my-club-site/mail/post?fc=aMTc_!cZmlzY3Vz` [download] There are many mini-languages in the above sentence, but all arose out of necessity. ASCII provides a common character set, and won out over EBCDIC, for random reasons. http:// was needed to allow the browser to switch between multiple protocols. www.bivio.com arose, because the Internet needed a distributed naming system when the hosts file got too large to be shipped around every night. my-club-site arose, because our support team needed to give people generic URLs to their private clubs. /mail/post is just a name for a message, that's readable and short. It allows our programmers to read the server logs easily. fc= evolved, because HTML is stateless. The stuff after the fc= tells the interpreter where the particular browser window should return to after you post the message or cancel without storing anything on the server. The above mini-languages are simple, declarative, and satisfy a basic rule: keep it simple. They aren't beautiful. Mini-languages which diverge from the KISS principle are an excellent distraction from what you are being paid to do. That's when the mini-language takes on a life of its own, and ceases to be a tool to solve a problem, but a problem in itself. This can be excellent for job security. However, you are programming ineffectively, and you want to be a good programmer. Someone has already generalized and abstracted most programming constructs for you. If you ignore that fact, you are working for yourself, and cheating your customer. An excellent example of this is the syntax for formatting this reply. HTML was an excellent generalization. However, the special syntax for links is not HTML (although you can use HTML). While it is totally cool that you can make a link with square brackets, it's pretty odd all the same. It's not POD, it's not HTML, and it conflicts one of the most common syntactic elements in the subject matter of this site. You'd have to look at the source of this text to know that [ is the way to get a [ in your posts. And, I didn't have a ready example, and it took quite a bit of searching to figure out why my square brackets weren't showing up. This may be funny in this context. It isn't funny if it is Friday night, and you have to debug somebody else's undocumented, mini-language before you can check-in and go home.	[reply] [d/l] [select]
Re^3: the disadvantages of mini-languages by metaperl (Curate) on Feb 18, 2005 at 17:01 UTC
Languages like Lisp, Prolog, and Haskell are beautiful, but I would guess that more function has been delivered in Perl than in the other three combined. Funny you should mention Haskell. I am teaching myself this language right now. It took 1st and 2nd place in the 2004 Functional Programming Contest (which any language can enter).	[reply]


Perl: the Markov chain saw
	PerlMonks