
“Little Languages” by Jon Bentley (1986) [pdf] - akkartik
http://staff.um.edu.mt/afra1/seminar/little-languages.pdf
======
waterhouse
Counterpoint: "A Universal Scripting Framework, or: Lambda: the ultimate
“little language”"

"Abstract. The “little languages” approach to systems programming is flawed:
inefficient, fragile, error-prone, inexpressive, and difficult to compose. A
better solution is to embed task-specific sublanguages within a powerful,
syntactically extensible, universal language, such as Scheme. I demonstrate
two such embeddings that have been implemented in scsh, a Scheme programming
environment for Unix systems programming. The first embedded language is a
high-level process-control notation; the second provides for Awk-like
processing. Embedding systems in this way is a powerful technique: for
example, although the embedded Awk system was implemented with 7% of the code
required for the standard C-based Awk, it is significantly more expressive
than its C counterpart."

[http://www.ccs.neu.edu/home/shivers/papers/ll.ps](http://www.ccs.neu.edu/home/shivers/papers/ll.ps)

~~~
taeric
I'm torn. I think most polyglot projects I deal with are overly complicated.
However, I also feel most embedded languages I deal with are overly
complicated.

Some have clearly worked out. Format strings, for example, are much more
appealing to me than the equivalent code. Not even getting into the crazy
abilities of common lisp. (Seeing what you can accomplish just from the format
string, I really wonder why it isn't more widespread.)

And regexes, despite all of the well justified jokes about them being
problematic, are often much better than the code that would replace them. It
is a shame there is not a BNF equivalent, sometimes.

But it seems most "inner languages" I have had the pleasure to deal with
personally have not truly helped. My suspicion is that me and my colleagues
just tried to do it all. Knowing when to say "not supported" in a toy language
is tough. And the penalty for not doing so, is catastrophic, it seems.

~~~
sacado2
Agreed. Regexps and format strings are cool. Regarding small, dedicated
languages, I also like SQL and (to a lesser extent) CSS selectors.

~~~
edwintorok
I think the LittleLanguages [0] should be further subdivided into: * languages
for describing something (e.g. regular expression, format strings, graph .dot
format, LaTeX math equations, etc.) that are usable both from standalone UNIX
tools, and from inside programming languages * languages with a dedicated tool
(awk, etc.) that are not widely available embedded inside other programming
languages. Usually these languages allow you to perform some actions /
transformations

I think both papers agree that the former is "good" (the reimplementation of
awk in Scheme uses regular-expressions).

In the counterpoint paper it turns a LittleLanguage (Awk) into an Embedded
Domain Specific Language by embedding it inside Scheme.

SQL is more difficult to categorize: I think the SELECT expression should be
considered a LittleLanguage, however the UPDATE/INSERT part is better when
having a full programming language available (see procedural languages inside
SQL / triggers, which hint at the limits of the base SQL language).

[0] [http://wiki.c2.com/?LittleLanguage](http://wiki.c2.com/?LittleLanguage)

------
alexeiz
Little languages are good for little programs. Once your program grows up, a
little language starts holding it back. Your program needs a language for
grown-ups. The truth is all little languages are quite primitive, and this is
by design. Little languages are designed for a specific narrow purpose. Beyond
that narrow purpose they are much less expressive, clunky and inefficient.

Real life tasks often require more than one little language. You can start
with a simple text extraction using Awk, then use Sed for text conversion, and
glue it all together with Bash. But very soon it becomes hard to maintain and
extend this collection of scripts and easier to replace them with one Perl or
Python program, which can do all of the above and more.

So the bottom line is, use little languages then they suit your task, but know
their limitations.

~~~
tekknolagi
What would you say makes gluing those languages together hard to maintain?

I've found the opposite, where it's difficult to look through the many dark
corners of Perl to do something that could have been accomplished instead by a
smaller tool.

