7 ms·

I don't get it. I am a Smug Lisp Weenie. Lisp is not a syntactic sugar - the only reason it looks like it does is for metaprogramming. Those parens are not s

I don't get it. I am a Smug Lisp Weenie. Lisp is not a syntactic sugar - the only reason it looks like it does is for metaprogramming. Those parens are not syntax - they indicate the underlying structure of the code, a tree which may be manipulated by Lisp macros. Why would anyone pretend to program in Lisp without any benefit? Also, Python is the worst imaginable engine for running Lisp. [correction: I see there are some kind of macros...]

wiseowise 4y ago
> Why would anyone pretend to program in Lisp without any benefit? Because it is superior way of writing a program. Pure, consistent and unambiguous.
- bloppe 4y ago
  Surprising how not everybody picked up on the superiority of this.
- giantdude 4y ago
  It certainly is superior. Now get rid of the inferior part (python) and use SBCL. No more pretending to be a Lisper!
agumonkey 4y ago
think of it as clojure to java, even without embodying the whole lisp ethos, it gives you a lispy base to write python code, plus extra niceties (threading -> IIRC) plus you get to benefit from paredit under emacs
- skissane 4y ago
  Clojure is more than just a Lisp for the JVM – it is a Lisp for the JVM with a big focus on immutable data structures – whereas traditionally most Lisps put mutability first instead. There are other Java-based Lisps, such as Armed Bear Common Lisp (ABCL), which are more traditionally Lisp-like in this regard. I think Hy is more of a traditional Lisp, since it shares Python's native focus on mutable data rather than trying to foreground immutability.
  - eduction 4y ago
    Let’s not be too pedantic, it was just an analogy, not a bad one, nor perfect but none are. As a Clojurist I think it behooves us not to put on gatekeeping airs (because we’re up against those too).
    - skissane 4y ago
      I wasn't trying to gatekeep anyone (and I make no claim to be a "Clojurist"–my Clojure experience is rather minimal). I was making a point about categorisation, taxonomy. There is a certain category of Lisp-like languages – of which Hy, Fennel and LFE are good examples – which take an existing language, and provide a Lisp-like syntax for it, but generally keep the semantics reasonably close to that of the underlying language. Beyond the syntax, the other main addition tends to be a Lisp-style macro system. Maybe we might call them "veneer Lisps", since they put a Lisp veneer on another language, but beneath the surface it is largely the same. Clojure isn't a veneer Lisp, because its semantics are quite different from Java – Java is primarily about mutable data, and Clojure-style immutable data structures aren't the mainstream Java approach. A JVM Lisp which dropped Clojure's emphasis on immutability could be a veneer Lisp. Armed Bear Common Lisp and Kawa Scheme are examples of mutability-oriented JVM Lisps, but they don't belong to the category of veneer Lisps either, since they are ports of pre-existing languages to the JVM, and their mutability comes from those pre-existing languages not a desire to conform to Java/JVM semantics. I'm not saying there is anything wrong with immutability, or that Clojure's focus on it is a mistake, or that one ought to either prefer (or avoid) "veneer Lisps": I'm attempting descriptive taxonomy, not prescriptivism.
  - giantdude 4y ago
    That! Clojure is an elegant experiment with immutability. The implementation details of Clojure's datastructures are a pure joy to look at. JVM is an unfortunate choice as I see it, but it's a pretty solid system which is benefiting from decades of research on JIT, GC, etc, so not entirely unreasonable as a back-end. I have few good things to say about Python, other than it sort of works. I classify it in the big-sack-of-stuff languages, along with Perl and shells. Not much elegance or style.
lordgroff 4y ago
I'm not sure what this comment is getting at to be honest. That is the benefit: that you can do macros and manipulate out the syntax in a way you never could in Python.
funklute 4y ago
> Also, Python is the worst imaginable engine for running Lisp What exactly do you mean by this?
- giantdude 4y ago
  slow. bloated. not particularly good at managing conses. is there tail recursion?
  - xapata 4y ago
    No, Python does not have tail recursion optimization, because Guido decided that he wanted to preserve stack frames for better tracebacks. The language team may revisit that decision someday. I assume you're referring to an optimization, because one can write tail recursion in any language that supports subroutines.
    - giantdude 4y ago
      Thanks, that is what I thought, but didn't trust my memory. Yes, I did mean optimization - without it you can blow through your stack quickly (and the traceback will be long and redundant :)
      - xapata 4y ago
        In those cases, you may wish to use a dynamic programming technique. A bit of caching might be a greater optimization than tail call elimination. The `@functools.lru_cache` tool is very easy to experiment with.
      - xapata 4y ago
        > will be long and redundant They made a highly redundant traceback display much more pleasant a couple years ago, writing "the same thing 1,998 more times ..." or something like that.
      - aidenn0 4y ago
        Common lisp doesn't require tail call elimination either, fwiw
ahungry 4y ago
I believe homoiconicity is more related to the syntax than the underlying implementation - fans of homoiconic code use it to treat code as data (macros and eval) rather than to reason about performance concerns/having a transparency into the underlying implementation (see: Clojure).
deleted 4y ago
[deleted]

wiseowise 4y ago

> Why would anyone pretend to program in Lisp without any benefit? Because it is superior way of writing a program. Pure, consistent and unambiguous.

bloppe 4y ago
Surprising how not everybody picked up on the superiority of this.
giantdude 4y ago
It certainly is superior. Now get rid of the inferior part (python) and use SBCL. No more pretending to be a Lisper!

agumonkey 4y ago

think of it as clojure to java, even without embodying the whole lisp ethos, it gives you a lispy base to write python code, plus extra niceties (threading -> IIRC) plus you get to benefit from paredit under emacs

skissane 4y ago
Clojure is more than just a Lisp for the JVM – it is a Lisp for the JVM with a big focus on immutable data structures – whereas traditionally most Lisps put mutability first instead. There are other Java-based Lisps, such as Armed Bear Common Lisp (ABCL), which are more traditionally Lisp-like in this regard. I think Hy is more of a traditional Lisp, since it shares Python's native focus on mutable data rather than trying to foreground immutability.
- eduction 4y ago
  Let’s not be too pedantic, it was just an analogy, not a bad one, nor perfect but none are. As a Clojurist I think it behooves us not to put on gatekeeping airs (because we’re up against those too).
  - skissane 4y ago
    I wasn't trying to gatekeep anyone (and I make no claim to be a "Clojurist"–my Clojure experience is rather minimal). I was making a point about categorisation, taxonomy. There is a certain category of Lisp-like languages – of which Hy, Fennel and LFE are good examples – which take an existing language, and provide a Lisp-like syntax for it, but generally keep the semantics reasonably close to that of the underlying language. Beyond the syntax, the other main addition tends to be a Lisp-style macro system. Maybe we might call them "veneer Lisps", since they put a Lisp veneer on another language, but beneath the surface it is largely the same. Clojure isn't a veneer Lisp, because its semantics are quite different from Java – Java is primarily about mutable data, and Clojure-style immutable data structures aren't the mainstream Java approach. A JVM Lisp which dropped Clojure's emphasis on immutability could be a veneer Lisp. Armed Bear Common Lisp and Kawa Scheme are examples of mutability-oriented JVM Lisps, but they don't belong to the category of veneer Lisps either, since they are ports of pre-existing languages to the JVM, and their mutability comes from those pre-existing languages not a desire to conform to Java/JVM semantics. I'm not saying there is anything wrong with immutability, or that Clojure's focus on it is a mistake, or that one ought to either prefer (or avoid) "veneer Lisps": I'm attempting descriptive taxonomy, not prescriptivism.
- giantdude 4y ago
  That! Clojure is an elegant experiment with immutability. The implementation details of Clojure's datastructures are a pure joy to look at. JVM is an unfortunate choice as I see it, but it's a pretty solid system which is benefiting from decades of research on JIT, GC, etc, so not entirely unreasonable as a back-end. I have few good things to say about Python, other than it sort of works. I classify it in the big-sack-of-stuff languages, along with Perl and shells. Not much elegance or style.

lordgroff 4y ago

I'm not sure what this comment is getting at to be honest. That is the benefit: that you can do macros and manipulate out the syntax in a way you never could in Python.

funklute 4y ago

> Also, Python is the worst imaginable engine for running Lisp What exactly do you mean by this?

giantdude 4y ago
slow. bloated. not particularly good at managing conses. is there tail recursion?
- xapata 4y ago
  No, Python does not have tail recursion optimization, because Guido decided that he wanted to preserve stack frames for better tracebacks. The language team may revisit that decision someday. I assume you're referring to an optimization, because one can write tail recursion in any language that supports subroutines.
  - giantdude 4y ago
    Thanks, that is what I thought, but didn't trust my memory. Yes, I did mean optimization - without it you can blow through your stack quickly (and the traceback will be long and redundant :)
    - xapata 4y ago
      In those cases, you may wish to use a dynamic programming technique. A bit of caching might be a greater optimization than tail call elimination. The `@functools.lru_cache` tool is very easy to experiment with.
    - xapata 4y ago
      > will be long and redundant They made a highly redundant traceback display much more pleasant a couple years ago, writing "the same thing 1,998 more times ..." or something like that.
    - aidenn0 4y ago
      Common lisp doesn't require tail call elimination either, fwiw

ahungry 4y ago

I believe homoiconicity is more related to the syntax than the underlying implementation - fans of homoiconic code use it to treat code as data (macros and eval) rather than to reason about performance concerns/having a transparency into the underlying implementation (see: Clojure).

deleted 4y ago

[deleted]