4 ms·

>The reason I like Common Lisp is not because it has been influential But that's not what I was saying, I wasn't saying that you should like those languages, I

>The reason I like Common Lisp is not because it has been influential But that's not what I was saying, I wasn't saying that you should like those languages, I was saying that Common Lisp is not special compared to them and nobody is specifically "re-inventing" it, it's a pretty vanilla (by 2000s standards) language descended from a 1960 grandpa. >my personal quality metric How would that convince anyone who is not you ? >To me, making programming as easy as possible is the whole point of high level languages Lisp syntax fails spectacularly on this one, it's painful and tedious, it forces you think about the explicit nesting between structures, like how assembly forces you to explicitly think about data flow between instructions. In any sane programming language, you just write a+b, in lisp, it's (+ a b). A bizarre 1980s-calculator world where you have to think carefully about every operation and read it outloud. It can be gotten used to with experience off course, but it's not effortless, it's far from the language making it easy for you. The entire point of conrete syntax and grammars is that the compiler builds the syntax tree for you, you just lay out a nice and readable specification of it in the mathematics\english mixed notation that is most programming languages, and the parser infers all the dependencies in the implicit tree structure and builds it for you. Lisp inverts this relationship, making you into a human parser that translates your own ideas into its simplistic notation. S-Expression is a 1960s hack to simplifiy parsing. >The only real innovation in programming languages since Common Lisp is static type inference. This dismissal shows an astonishing ignorance of PL design and history. Haskell lets you design your own control structures with lazy evaluation. Perl6\Raku has first class support for BNF grammars built right into the language. Both languages doesn't treat operators as special and let you define arbitary unicode symbols as operators and control their precedence and associativity, enabling unparalled DSL development. OCaml has a module system that represents code as first class structs and runs arbitary functions to transform them at compile time. Ironically for the community that invented the "Blub Paradox", CL programmers have an unfortunate syndrom of the Blub Programmer. "CL is all I know, therefore CL is all I need and the most powerful language in existence". >Yeah, that is not necessarily a good thing I wasn't saying it's necessarily a good thing, I was saying it (and Python, and Groovy) beats Lisps in dynamicity, which was once (and sometimes still is) a common selling point that lisp advocates repeat. >Also, Ruby can't change its surface syntax. Common Lisp can. Plenty of others can, some with systems that are not inspired from lisp. I mentioned some of them in a point that you skipped right over.

lispm 4y ago
> S-Expression is a 1960s hack to simplifiy parsing. S-Expressions were invented as a way to write (externalize), read (internalize) and represent list like data structures. The original Lisp design had two different syntaxes for code (m-expressions) and data (s-expressions). It turned out that programs can be represented on top of s-expressions and that simple execution engines and compilers can be written for it. Further it turned out that one can write user interfaces which in simple ways can read, write, execute s-expressions. Thus s-expressions seem particular useful for interactive programming. > you just write a+b, in lisp, it's (+ a b) Lisp does not care much about that, since much of it was to implement tools on top of itself. Thus some of the first systems who could manipulate mathematical formulas were written in Lisp. Much of Lisp is concerned with all kinds of symbolic notations - some use s-expressions, some are not. For example, the first ML was implemented in Lisp and did not use s-expressions. Scheme OTOH also was first implemented in Lisp and did use s-expressions. Lisp macros and special forms implement syntax on top of s-expressions - what makes it convenient, is that the syntactic extensions are transformation programs written and executed with the same language they extend. That makes it a very powerful and relatively easy to use syntactic extension mechanism - which is widely used in Lisp. > but it's not effortless, it's far from the language making it easy for you Some tools need some learning. Once learned, the Lisp user has access to a language which provides a simple and well-integrated syntactic meta-level level.
lisper 4y ago
> Lisp syntax fails spectacularly on this one, it's painful and tedious, To the contrary, Lisp syntax is much simpler than traditional syntax. It does not draw an arbitrary distinction between operators and functions. Operators are a notational hack. We write sin(x), sqrt(x), log(x), so why not sum(x,y), expt(x,y), xor(x,y)? > it forces you think about the explicit nesting between structures Traditional syntax forces you to think about operator precedence. It's also much harder to parse. > Haskell lets you design your own control structures with lazy evaluation. Lisp lets you do the same thing with macros and closures. > Perl6\Raku has first class support for BNF grammars built right into the language. Why would you want that? What benefit is there over having parsers available as library code? > beats Lisps in dynamicity > Plenty of others can I think you're missing the point. The reason Lisp is cool is not that it has the most powerful version of any given feature (except for CLOS -- that is indeed still unmatched). The reason Lisp is cool is that it gives you the right combination of all of these things packaged in a way that is, at its core, very simple and easy to learn. Nothing else comes close in terms of power-to-learning-curve ratio.

lispm 4y ago

> S-Expression is a 1960s hack to simplifiy parsing. S-Expressions were invented as a way to write (externalize), read (internalize) and represent list like data structures. The original Lisp design had two different syntaxes for code (m-expressions) and data (s-expressions). It turned out that programs can be represented on top of s-expressions and that simple execution engines and compilers can be written for it. Further it turned out that one can write user interfaces which in simple ways can read, write, execute s-expressions. Thus s-expressions seem particular useful for interactive programming. > you just write a+b, in lisp, it's (+ a b) Lisp does not care much about that, since much of it was to implement tools on top of itself. Thus some of the first systems who could manipulate mathematical formulas were written in Lisp. Much of Lisp is concerned with all kinds of symbolic notations - some use s-expressions, some are not. For example, the first ML was implemented in Lisp and did not use s-expressions. Scheme OTOH also was first implemented in Lisp and did use s-expressions. Lisp macros and special forms implement syntax on top of s-expressions - what makes it convenient, is that the syntactic extensions are transformation programs written and executed with the same language they extend. That makes it a very powerful and relatively easy to use syntactic extension mechanism - which is widely used in Lisp. > but it's not effortless, it's far from the language making it easy for you Some tools need some learning. Once learned, the Lisp user has access to a language which provides a simple and well-integrated syntactic meta-level level.

lisper 4y ago

> Lisp syntax fails spectacularly on this one, it's painful and tedious, To the contrary, Lisp syntax is much simpler than traditional syntax. It does not draw an arbitrary distinction between operators and functions. Operators are a notational hack. We write sin(x), sqrt(x), log(x), so why not sum(x,y), expt(x,y), xor(x,y)? > it forces you think about the explicit nesting between structures Traditional syntax forces you to think about operator precedence. It's also much harder to parse. > Haskell lets you design your own control structures with lazy evaluation. Lisp lets you do the same thing with macros and closures. > Perl6\Raku has first class support for BNF grammars built right into the language. Why would you want that? What benefit is there over having parsers available as library code? > beats Lisps in dynamicity > Plenty of others can I think you're missing the point. The reason Lisp is cool is not that it has the most powerful version of any given feature (except for CLOS -- that is indeed still unmatched). The reason Lisp is cool is that it gives you the right combination of all of these things packaged in a way that is, at its core, very simple and easy to learn. Nothing else comes close in terms of power-to-learning-curve ratio.