Hacker News Reader

Comment by giantdude | Hacker News Reader

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

View on HN

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.

> Why would anyone pretend to program in Lisp without any benefit?

Because it is superior way of writing a program. Pure, consistent and unambiguous.

Surprising how not everybody picked up on the superiority of this.

It certainly is superior. Now get rid of the inferior part (python) and use SBCL. No more pretending to be a Lisper!

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

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

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.

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.

Clojure is definitely more than an experiment. It processes many millions of dollars daily through things like banks and even at Walmart. It might not be used a lot, but experiment is not accurate at all. You didn't flesh out your comment about Java, they used to also transpile to C# and still to Javascript. I think Java's fast memory allocator is particularly suitable to the immutable data structure memory requirements. I also find the JVM a very robust and mature platform. It's also a great gateway being able to interop into corporate environments as a way to get traction. I am curious what other language you think would be better given those desired traits that Hickey designed for.

There's also CLOJERL - Clojure on BEAM (Erlang), and recently CljDart, clojure to dart transpiler was released and seem to have a lot of momentum.

i know it's not a full fledged thing like clojure, but it never had that scale in mind either. I should have added a modal in my comment above :)

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

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.

> Also, Python is the worst imaginable engine for running Lisp

What exactly do you mean by this?

slow. bloated. not particularly good at managing conses. is there tail recursion?

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.

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 :)

Common lisp doesn't require tail call elimination either, fwiw

But every implementation except clisp, ECL and clisp do it reliably.

I think you may have meant to substitute ABCL for one of those clisps?

sbcl doesn't always do it, depending on optimization settings, and clisp does do it when compiling; by "reliably" perhaps you meant "by default"?

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.

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

> because one can write tail recursion in any language that supports subroutines.

If only! For anyone else who got saddled with some FORTRAN 77 code, you may or may not have recursion available even with subroutines. It wasn't required by the language standard, but some implementations supported it. Not the one I "got" to use (and quickly moved on from) a while back, though.

Reply on news.ycombinator.com