Hacker News Reader

Comment by chubot | Hacker News Reader

Yeah the way I frame it is that Lisp is about "interior" composition (functions and data), not "exterior" (processes andf iles)

Narrow Waists Can Be Interior or Exterior: PyObject vs. Unix Files

https://www.oilshell.org/blog/2023/06/narrow-waist.html

However the "exterior" extension seems obvious to me -- why hasn't anyone produced a distributed Lisp?

Well I guess Clojure/EDN is that, but nobody has produced a POLYGLOT system involving distributed Lisp. Common Lisp users probably don't use EDN very much, I gather.

---

I found this POSE exterior s-expression format, but it seems to have little interest from the Lisp community:

https://lobste.rs/s/lwf4jv/pose_portable_s_expressions_pose_...

It seems like JSON will have an "impedance mismatch" with Lisp data structures, but yeah that's the cost of interoperability

View on HN

> not "exterior" (processes and iles)

Common Lisp can read and write s-expressions from files. It can also compile source files and load files (both source and compiled).

The syntax for Common Lisp is standardized. Thus a lot of data may be shipped either in text or compiled files. Several implementations can also create snapshots of the runtime memory. A few domains use CL s-expressions (or a subset of that) as language syntax or as a data syntax.

Distributed Lisp applications exist, but may not use text to exchange data. For example there is a defined CORBA mapping for Common Lisp, which enabled Common Lisp software to take part in distributed software using a standard, which allows mixed language software.

> However the "exterior" extension seems obvious to me -- why hasn't anyone produced a distributed Lisp?

How about Lisp Flavored Erlang?

How does Lisp Flavored Erlang talk to Common Lisp? Probably with a byte stream. The VMs are different.

I've noticed Erlang/Elixir also favor interior composition! Parsing is not idiomatic there -- they're actually BAD languages for parsing text. (Though they do have good affordances for parsing bytes)

They prefer to pass around Erlang terms, which are copied inside the VM.

I get that -- it's more convenient. But it's also a reason why "the rest of the world" has more code reuse -- e.g. Go talks to JavaScript talks to Python.

Most projects have multiple languages. Monoglot projects become polyglot projects when they grow bigger.

---

So I say

- Lisp prefers its own (interior) narrow waist

- Erlang prefers its own (interior) narrow waist -- even the Lisp one is second class!

- The rest of the world uses the (exterior) byte stream narrow waist, but they complain about it a lot :)

Reply on news.ycombinator.com