Hacker News Reader

Comment by hjk05 | Hacker News Reader

> The reason s-expressions are better than text is that they are more expressive

That has got to be a joke right? S-expressions are a subset of text it’s axiomatically impossible for them to be more expressive.

View on HN

As others have mentioned, "text" is rarely unstructured in practice: it's just that the "structure" is ad-hoc, relying on things like whitespace, newlines, various punctuation, etc.

I mean, there's a reason why regular expressions were one of the first things that went into Unix. But with lisp, you need neither regular expressions nor separate parsers for each format, because s-expressions enforce a uniform encoding of all structure in a data structure (a tree), which is parsed automatically by the interpreter!

Edit: And, as lisper clarifies, "S-expressions are more expressive than text that adheres to the typical unix conventions" [0], meaning that s-expressions make it trivial to arbitrarily extend that structure (whereas doing the same beginning from Unix conventions gets messy very quickly; see, e.g., lisper's example of parsing HTML).

[0] https://news.ycombinator.com/item?id=19274518

Sugar is better than sooty water. They are both C, H, O, but the sugar has useful structure.

s-expressions are structured text. Therefore, for some set of problems, s-expressions are "better" (contain more information, are more easily manipulated, etc.) than unstructured text.

Please provide an example of an s-expression that provides more information than can be encoded though a text string that is the same length, and in fact identical to said s-string.

I mean, I get it. Lispers like lisp, and think it’s “better”. But it’s more more expressive than text, and in fact operating on text gives you natural access not just to s-expressions but to any other programming languages or structured and unstructed examples of text.

If you shell operated only on s-expressions that would either have you reduce expresiveness, or just doing tricks to encode the text-stream as a s-expression which hardly qualifies as making it more expressive, that’s just adding extra redundant information around the original information.

The lisp interpreter can operate on s-expressions, but it cannot operate on arbitrary text. The specialization of encoding as s-expressions allows the development of the lisp interpreter.

Similarly, a C compiler operates on well-formed C programs.

Neither one can do its work on arbitrary text or on the other's text.

You can argue whether one is better than the other, but while each is a subset of "text" the limitations of the subset enable the expressiveness.

"I work on matter" vs "I sculpt" or "I paint" or "I cook".

> Please provide an example of an s-expression that provides more information than can be encoded though a text string that is the same length, and in fact identical to said s-string.

We're talking about a class of strings, not a single individual string. S-expressions are more constrained than arbitrary text, and therefore contain more structure than arbitrary text. Constraints are information.

You can't simply impose a tree structure on any arbitrary piece of text.

s/text/unstructured text/ in the OP. S-expressions are serialized by text, but the Lisp approach is more powerful than UNIX approach because Lisp approach works with structured text by default, while UNIX approach assumes unstructured text. UNIX approach forces every program to write its own arbitrary parsing and unparsing, and makes almost every shell one-liner to be half about converting output ad-hoc shapes of text to input ad-hoc shapes of text.

The only popular modern incarnation of Lisp philosophy in shells is... PowerShell - where instead of s-expressions, the tools exchange objects. That's AFAIK binary blobs, but if you wanted to retain a text-serializable form, then the most obvious way to do it would be... S-expressions.

OK, we get it. You can embed any language in plain text, so it's "expressive". lisper should have emphasized that "how Unix programmers default to using command-lines text" is less expressive than S-expressions, as history shows that programmers tend to fall into using a language of "records of fields".

> S-expressions are a subset of text it’s axiomatically impossible for them to be more expressive.

This reasoning is backwards. Structure creates expressiveness. A novel in correct, readable English is more expressive than an arbitrary pile of letters, because it follows a form. A painting, even when represented as a JPEG, is more expressive than a large number, because it is considered as a valid JPEG and a painting. A Bach chorale with no parallel fifths, and a mid-20th-century experimental atonal piece, are both more expressive than banging on a piano.

I think the GP was talking about what you might call "expressive range". Anything that can be expressed in a string of characters of a given length uses at most the full expressive possibilities of that string. I think it's a silly point, because the meaning of lisper's comment was clearly that the added structure makes s-expressions more powerful than the Unix convention of "plain text".

The Unix standard of lines within which there are fields delimited by some character is, itself, a very primitively constrained/structured form of text, so it too is less expressive than raw text could be. But this is a daft discussion.

This has to be intended as a joke in order to pretend to be dense right?

First of all, the notion that a subset being "more expressive" than its superset is "axiomatically impossible" is wrong. If I form a 20 letter string that's a sentence (e.g "Welcome to my house", it would be more expressive than the totality of 20 letter strings (even if it's a subset of them). That's because the totality of 20 letter strings includes all possible valid sentences and close to 20^26 (or more if we add space, numbers etc) arbitrary BS strings, and thus can't really express anything concrete.

Parent obviously speaks about common text treated with regular string/text manipulation functions (what 99% of Unix shell pipe work is) vs text formatted and interpreted as an S-expression structure.

The same way a structured english sentence is more expressive than a bunch of vocalizations (even if a sentence is just a bunch of vocalizations too -- it's the structure that makes it expressive).

It's not about the merits of plain text as a general format vs a specific plain text variant. It's about the merits of a specific structure, vs the kind of text files tools like sort/cut/tr etc were made to operate on.

In this context, think of "text" as shorthand for unstructured text. Which is another subset of text. The sort of text that Unix tools traditionally handle. Colon-separated files like /etc/passwd, line-oriented files like /usr/share/dict/words, etc.

So, now we have two subsets of text, and it makes sense they can have different levels of expressiveness.

(Actually, unstructured is too extreme since there is a little structure. Something like "isomorphic to CSV" isn't quite right, but closer.)

“Colon-separated files” are not unstructured though. And arguing that s-expressions are more expressive than text because “text” excludes all structured examples of text seems like an excessive in definitional acrobacy acrobacy.

But Unix didn't adopt everything-is-colon-separated-values. Everything being unstructured text leads to a lot of different, incompatible ways of structuring that text. S-expressions themselves aren't important, I think, it's just having some standard structure that's used everywhere and you don't have to parse yourself. Trees are a good choice for a universal structure, hence things like XML. S-expressions are just a very lightweight and flexible format.

Obviously I mean degrees of structure, not an absolute lack of structure.

The goal of the definition isn't to give S-expressions an advantage so they can be proven superior and Lisp people can win the argument. It's to describe the sorts of files that actual existing command-line utilities (like this in Unix/Linux) can conveniently operate on.

The "head" command deals in line-oriented fashion and can print the first N lines of a file. The "cut" command can select certain columns based on a line-oriented and character-delimited structure. There is no exact definition, but this gives you a general idea of what text files means in the context of "becoming a command line wizard".

Text is a subset of binary, it surely doesn't hold that a CLI interface that only took protocol buffer based binary input would be more expressive then a text oriented input?

Not at all. Less is more.

By using specific constraints (rules for sexprs), one creates a wider array of possibilities.

By having no rules (text), one has to provide a rubric on how to parse the text. And when you have to parse, you have to write a parser, and define the parsed format.

Let me rephrase that: S-expressions are more expressive than text that adheres to the typical unix conventions.

S-expressions are text with some constraints in its construction.

However, what would you expect from someone whose username is literally "lisper" ?

YMMD :D

Lisp people don't like being reminded about the theory of computation. Which is ironic, because they like Lisp because it is closer to raw mathematical syntax.

Reply on news.ycombinator.com