4 ms·

The thing that matters is that code is written as s-expressions, which has a simple textual serialization format with lists, symbols, numbers, strings, vectors

by lispm 7y ago

The thing that matters is that code is written as s-expressions, which has a simple textual serialization format with lists, symbols, numbers, strings, vectors and a bunch of other data types. Thus any Lisp form is automatically data: not simple strings or complex syntax trees. This enables a bunch of stuff: code can be relatively easily treated as data. It allows easy code generation, transformations (-> macros), traversal (-> interpreters/compilers) or editing. The parentheses are just a part of the s-expression textual syntax. The s-expressions then are used by basic operations like READ, MACROEXPAND, PRINT and EVAL. Additionally many of the primitive data functions can be used to manipulate code: first/rest, list, append, reverse, map, ...

unlinked_dll 7y ago
The issue is that code is read more often than it is interpreted, written, or compiled. All the beautiful aspects of lisp make it decidedly unwieldy in production software. There’s a tendency of projects written in lisps to be unwritten in lisps as they mature.
- dreamcompiler 7y ago
  That has more to do with managerial ideas of programmer fungibility than Lisp's readability.
- naniwaduni 7y ago
  Frequently-used interpreted code is probably interpreted more than it is read. Most of the code in a large codebase is likely compiled more than it is read. One-off code is often written, compiled, and executed once, and read never. If a piece of code is read more often than it's interpreted, written, and compiled, it's probably example code.
- lispm 7y ago
  > The issue is that code is read more often than it is interpreted, written, or compiled. In a Lisp system, the code is always there and not just in textual forms. > All the beautiful aspects of lisp make it decidedly unwieldy in production software. There’s a tendency of projects written in lisps to be unwritten in lisps as they mature. There are two main factors which lead to Lisp software being rewritten: 1) deployment. In the early days it was the lack of resources (memory, speed, ...), but there are other factors like having a robust runtime or the ability to integrate in larger software around it. 2) familiarity. There are not many people available to maintain Lisp software. Not because the syntax is strange, but because the whole language is strange. There are no major other programming languages which work like Lisp, so few people can productively program in it. There are exceptions to it, like the simple Lisp used in AutoCAD and related software. These have millions of installations and the complexity on the Lisp side is not that huge - there it's mostly used as a simple interactive programming language. What makes Lisp actually difficult for programmers is not the syntax, but the pervasive use of code as data, code transformations, various ways of meta-programming, etc. It's the features it was developed for: computing with symbolic expressions - here even applied to itself. The language Lisp was built to compute with symbolic expressions, then the idea that a Lisp program is itself a symbolic expression is tempting... this then leads to center programming activities around this idea.
- p_l 7y ago
  The rewrites tend to involve managerial decisions and not technical (arguably Reddit was one of the few cases where I can point to clear cut technical reasons, the reason being "we wanted to run FreeBSD and threads sucked there"). Sometimes it's internal politics (like JPL's C++ developers giving Lisp as reason for their code segfaulting...). There's quite a lot of big systems written in Lisp. Unfortunately they rarely ever were opensourced, and we get to have blinders made out of our own limited experiences and common generational knowledge loss in IT.
mantap 7y ago
Yes exactly you have to separate the abstract idea of s-expressions in memory from their textual syntax (parentheses). S-expressions in memory are a really really good idea and chronically underused in modern programming languages. The parentheses are irrelevant to the core ideas of lisp. You can make a lisp using C-like braces and infix notation - what makes a lisp is the representation of the program in memory as a tree and the operations you can perform on that representation. All the interesting macro expansion in lisp is performed after parsing, unlike in the C preprocessor, so you can write your programs using Egyptian hieroglyphics for all lisp cares.
- dreamcompiler 7y ago
  An analogy for web programmers: Parentheses are HTML; S-expressions in memory are the DOM.
- lispm 7y ago
  > Yes exactly you have to separate the abstract idea That was thought around 1960. Lisp had m-expressions in books. The actual Lisp system used s-expressions. The next few decades were often spend trying to get rid of s-expressions on the surface. Most of these attempts failed. If they succeeded they were something different. Like ML. One can think of the early ML as a kind of typed Lisp with a different syntax. What Lisp made attractive was the similarity between internal and external representation. The Lisp system was internally manipulating programs as s-expressions - that was easier to understand when the external representation is similar. > The parentheses are irrelevant to the core ideas of lisp. S-expressions are an actual core idea of Lisp, while you focus on a minor aspect of s-expressions-> that s-expressions use parentheses to denote cons cells and lists. Since the Lisp uses a certain data representation internally, it is much easier to use a simple textual format for that data externally too - one which makes the mental transformation easy. Using a complex and unrelated syntax does not make that easier, it makes it actually harder. > All the interesting macro expansion in lisp is performed after parsing, unlike in the C preprocessor, so you can write your programs using Egyptian hieroglyphics for all lisp cares. Actually that's not true: that's one of the ideas of Lisp and large programming system have been built around this. A Lisp system will expose its inner working to the programmer. Live and interactive systems are not an exception, they are the default.
nikofeyn 7y ago
the racket people seem to disagree because they are moving away from lisp/scheme syntax supposedly to improve what they can do with macros.

by lispm 7y ago

unlinked_dll 7y ago

The issue is that code is read more often than it is interpreted, written, or compiled. All the beautiful aspects of lisp make it decidedly unwieldy in production software. There’s a tendency of projects written in lisps to be unwritten in lisps as they mature.

dreamcompiler 7y ago
That has more to do with managerial ideas of programmer fungibility than Lisp's readability.
naniwaduni 7y ago
Frequently-used interpreted code is probably interpreted more than it is read. Most of the code in a large codebase is likely compiled more than it is read. One-off code is often written, compiled, and executed once, and read never. If a piece of code is read more often than it's interpreted, written, and compiled, it's probably example code.
lispm 7y ago
> The issue is that code is read more often than it is interpreted, written, or compiled. In a Lisp system, the code is always there and not just in textual forms. > All the beautiful aspects of lisp make it decidedly unwieldy in production software. There’s a tendency of projects written in lisps to be unwritten in lisps as they mature. There are two main factors which lead to Lisp software being rewritten: 1) deployment. In the early days it was the lack of resources (memory, speed, ...), but there are other factors like having a robust runtime or the ability to integrate in larger software around it. 2) familiarity. There are not many people available to maintain Lisp software. Not because the syntax is strange, but because the whole language is strange. There are no major other programming languages which work like Lisp, so few people can productively program in it. There are exceptions to it, like the simple Lisp used in AutoCAD and related software. These have millions of installations and the complexity on the Lisp side is not that huge - there it's mostly used as a simple interactive programming language. What makes Lisp actually difficult for programmers is not the syntax, but the pervasive use of code as data, code transformations, various ways of meta-programming, etc. It's the features it was developed for: computing with symbolic expressions - here even applied to itself. The language Lisp was built to compute with symbolic expressions, then the idea that a Lisp program is itself a symbolic expression is tempting... this then leads to center programming activities around this idea.
p_l 7y ago
The rewrites tend to involve managerial decisions and not technical (arguably Reddit was one of the few cases where I can point to clear cut technical reasons, the reason being "we wanted to run FreeBSD and threads sucked there"). Sometimes it's internal politics (like JPL's C++ developers giving Lisp as reason for their code segfaulting...). There's quite a lot of big systems written in Lisp. Unfortunately they rarely ever were opensourced, and we get to have blinders made out of our own limited experiences and common generational knowledge loss in IT.

mantap 7y ago

Yes exactly you have to separate the abstract idea of s-expressions in memory from their textual syntax (parentheses). S-expressions in memory are a really really good idea and chronically underused in modern programming languages. The parentheses are irrelevant to the core ideas of lisp. You can make a lisp using C-like braces and infix notation - what makes a lisp is the representation of the program in memory as a tree and the operations you can perform on that representation. All the interesting macro expansion in lisp is performed after parsing, unlike in the C preprocessor, so you can write your programs using Egyptian hieroglyphics for all lisp cares.

dreamcompiler 7y ago
An analogy for web programmers: Parentheses are HTML; S-expressions in memory are the DOM.
lispm 7y ago
> Yes exactly you have to separate the abstract idea That was thought around 1960. Lisp had m-expressions in books. The actual Lisp system used s-expressions. The next few decades were often spend trying to get rid of s-expressions on the surface. Most of these attempts failed. If they succeeded they were something different. Like ML. One can think of the early ML as a kind of typed Lisp with a different syntax. What Lisp made attractive was the similarity between internal and external representation. The Lisp system was internally manipulating programs as s-expressions - that was easier to understand when the external representation is similar. > The parentheses are irrelevant to the core ideas of lisp. S-expressions are an actual core idea of Lisp, while you focus on a minor aspect of s-expressions-> that s-expressions use parentheses to denote cons cells and lists. Since the Lisp uses a certain data representation internally, it is much easier to use a simple textual format for that data externally too - one which makes the mental transformation easy. Using a complex and unrelated syntax does not make that easier, it makes it actually harder. > All the interesting macro expansion in lisp is performed after parsing, unlike in the C preprocessor, so you can write your programs using Egyptian hieroglyphics for all lisp cares. Actually that's not true: that's one of the ideas of Lisp and large programming system have been built around this. A Lisp system will expose its inner working to the programmer. Live and interactive systems are not an exception, they are the default.

nikofeyn 7y ago

the racket people seem to disagree because they are moving away from lisp/scheme syntax supposedly to improve what they can do with macros.