Hacker News Reader

Comment by lisper | Hacker News Reader

The Lisp philosophy is very similar to the unix philosophy, but with one crucial modification: instead of "everything is text" the mantra becomes "everything is an S-expression".

The reason s-expressions are better than text is that they are more expressive. They allow arbitrary levels of nesting whereas text doesn't. Text naturally develops a record structure with only two levels of hierarchy: records separated by newlines, containing fields separated by some other delimiter (usually spaces, tabs or commas, sometimes pipes, rarely anything else). Going any deeper than that is not "native" for text. That's why, say, parsing HTML is "hard" for the unix mindset. But a Lisper naturally sees HTML (and XML and JSON and, well, just about everything) as just an S-expression with a more cumbersome syntax.

View on HN

you obviously know lisp and might be biased but i have a serious question, if i was going to waste a bunch of time learning a functional language in 2019 and wanted to use it in production (I am in consulting, so I would be recommending this to my clients) would you learn

1. LISP 2. Haskell 3. Erlang 4. Something else

No wrong answer, just a question I always like to hear answers to.

Erlang as the most pragmatic functional programming language.

Clojure as the most useful functional programming language.

Ditch both if/when you run into their limitations. You’ll then discover various degrees of FP in most languages.

I enjoyed Clojure and wrote a little production code using it but I'm finding F# much more fun and safer. F# is certainly far easier to refactor so that's another nice effect of having a static type system. Since .NET is so prevalent in business, it's easy to use almost anywhere.

I like a lot of F# but there's a lot of F# Person stigma to it in most shops that I've seen--condescending, shitty, and in many ways perceived, validly or invalidly, "different-to-be-different" (the Paket brouhaha comes to mind).

F# is a great language but I've found that it's usable when you can 1) convince C# people it's not that scary, and 2) convince them that you're not An F# Person.

Not GP, but: I recommend Standard ML. I can't see a better way to do this than to power through Dan Grossman's three course sequence, which goes back to the drawing board and teaches Standard ML [0] to introduce modern programming language features such as scope, closures, types, pattern matching, modules, and so on. Then, he uses the concepts introduced in Standard ML as a springboard to introduce Scheme in the second course, and Ruby in the third course. And in the end, you will see how each of the three languages implement in different ways the same powerful techniques.

But with just that first Standard ML course, you can already branch out to more popular languages such as Scala [1], which gives you the closest thing I've seen to "Standard ML on the JVM". But Standard ML (or Ocaml, which is very close) might even be your preferred language for prototyping [2], or compiler writing [3].

P.S.: To make Coursera tolerable, I usually pull the entire course with this nice little script [4]. Works great with ranger and mplayer!

[0] https://www.coursera.org/learn/programming-languages

[1] https://www.coursera.org/specializations/scala

[2] https://sanderspies.github.io/slides/dawn-of-reason.pdf

[3] http://flint.cs.yale.edu/cs421/case-for-ml.html

[4] https://pypi.org/project/coursera-dl/

thank you!

Caveat emptor: Standard ML is not widely used in industry and does not have a large library ecosystem, so if you do recommend it to clients, make sure it's clear that they'd want to follow up with something like Scala or Ocaml, which have far more users/libraries. It's just that for really understanding functional programming, Standard ML is fantastically clear. (Although actually, that Scala coursera course I linked to above is by Martin Odersky, and is also pretty darn good, especially if you're already committed to the JVM.)

Others have mentioned Elixir, which would also be an interesting option to explore. The main difference being that with Elixir you're leveraging Erlang and BEAM (which gives you a fantastic platform for actors and lightweight threads), versus Java and the JVM in the case of Scala (which gives you access to all of Java).

> Uses script to copy programming course.

That's a little meta, don't you think?

Welcome to Lisp: https://www.defmacro.org/ramblings/lisp.html :-)

I almost forgot to mention: Matt Might has an excellent blog post about what all of these "advanced" programming languages offer: http://matt.might.net/articles/best-programming-languages/

Probably Erlang, but potentially Ocaml.

I'll probably catch some flack for this (from both sides): You can (and should) use Ocaml as a Lisp where you lose the easy macros but gain strict typing. It's brilliant. The only downside is emacs; it's the only sensible IDE.

Haskell (and friends) are fantastic, but in my experience you have to be reasonably smart and work full-time with it, since every medium sized project gets turned into its own DSL (more so than with other languages). Maybe it's not ideal for consulting.

Erlang has Elixir which is used throughout industry. Clojure is out there, too. I've also seen OCaml and Haskell here and there. F# is gaining ground.

+1 for F# (though I have to admit, Elixir seems much preferred as the functional weapon of choice in industry).

Amazing ML-derived language with all the benefits of the .NET ecosystem. Highly suggest everyone dip their toe in.

I will always have a soft spot in my heart for Common Lisp, and Clozure Common Lisp (CCL) in particular. But all the cool kids seem to be using Clojure (with a J) nowadays.

> if i was going to waste a bunch of time learning

Your problem is not what language to learn, your problem is that you think that learning is "wasting time."

> a functional language in 2019

Lisp is not a functional language, so your question does not even make sense.

If you actually want to help your clients, instead of selling them on bogus, inappropriate solutions (which, with your attitude and lack of knowledge, I guarantee is what you are doing to your clients today), you need to start actually learning the fundamentals of your field. If you think that learning is "wasting time," then you are not learning, you are, indeed, only "wasting time."

I am also a consultant, have worked with all the languages you listed, and I say the above to help you, and other people who consult, and me. Consulting is all about having a very solid knowledge base, continuous learning, and professionalism (which, BTW, includes basic writing skills, like capitalization). Attitudes like yours are why consulting engagements fail, and why consultants get a bad reputation. That only makes it harder for all of us to get work.

> 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.

YMMD :D

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

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

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.

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?

> 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.

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".

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".

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

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.

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.

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

Reply on news.ycombinator.com