Hacker News Reader

I think a lot of the evangelism happened before Python and other languages both picked up steam and integrated some of the powerful ideas, e.g first class functions / closures or a powerful object system, so the chasm is now much narrower.

I’ve read a few pieces by prominent lispers who moved on to Python for similar reasons, along with wider adoption with a bigger ecosystem.

So you’re not wrong in thinking that. But I do believe there are a few things beyond macros that Lisp makes fantastically trivial that wouldn’t be so in other languages. It just doesn’t seem as magical anymore since we’ve raised the baseline for what is possible, for what to expect from a language. That is due in part to the influence of Lisp itself - lambda the ultimate own goal.

Python is still pretty limited as a language & platform compared to Common Lisp though.

(just a famous example: https://tapoueh.org/blog/2014/05/why-is-pgloader-so-much-fas...)

I played around with Guile scheme for awhile. Also a bit of Perl. I wanted to write a simple utility, and chose Python. I am familiar with Python, but hadn't used it for some time. Getting back into it again, my conclusion was: Python, it Just Works.

For anyone interested in lisp I suggest guile. Especially if speed is important. Guile can be interpreted, but it becomes much faster when compiled. The beauty of it is one can mix and match compiled code with interpreted code in the same script/program (usually this is done to run the interpreted code in another security context, allowing it to only do some "stuff" - this is especially useful for software deployments etc) - they call this feature gexp. Of course all this can be done with python too, but IMO such things are ugly/convoluted/complex in python while in guile they are very simple /straightforward).

It is basically a lisp language, but with a "curated" set of standard libraries that do a lot of the stuff one may commonly need in a predictable way.

Documentation is definitely not ideal, but it exists and there is a lot of it. Often one has to look through already written code to figure stuff out, but there is lots of that code in for example guix.

In summary, would I suggest anyone uses guile(or lisp in general) for a commercial project instead of python? In 99% of cases the answer is "definitely no", but does this diminish benefits of learning it? No, too. IMO one almost always benefits from learning new languages as long as the new language introduces new concepts. One gains a wider perspective and who knows, perhaps one day, one is involved in scoping that 1% of commercially written software where one may think, yes guile is the way to go.

> The beauty of it is one can mix and match compiled code with interpreted code

That's a standard feature of many Lisp implementations since the dawn of time.

>That's a standard feature of many Lisp implementations since the dawn of time.

Yes, of course. I mean this from the point of view of someone who doesn't know any other lisp. Not as an advantage of "guile over lisp" . Guile is a lisp after all.

> I couldn't see many massive wins over my go-to Python.

A massive win over Python I get is performance! The performance of SBCL or another good implementation beats Python hands down. And I don't have to lose anything to gain that performance. The syntax is much cleaner and more enjoyable than Python. Quicklisp provides a wide variety of packages that I can use to build software. So it has the advantages of Python and superior performance.

Performance is of course very good for SBCL. I guess 90% of the time it's not a constraint for me, the rest of the time maybe yes.

On a broader "performance" side though, the executables are enormous. If I'm tinkering with a new language on the side, I like to build little utilities - like, say, transposing a csv file. Having a 60MB executable for doing it seems... weird. Can't quite put my finger on it.

Of course, if I were to "compile" Python that way, it wouldn't be much smaller.

> In fact (gasp) I couldn't see many massive wins over my go-to Python.

Everything is expression already makes Lisp beyond what Python can ever reach, unless it sacrifices backwards compatibility.

Yep that’s it, the code is data, data is code thing, which makes it trivial to write Lisp programs that produce Lisp programs (that in turn produce Lisp programs). Macros all the way down, and at the bottom a couple of elephants.

I suppose the "Eureka" moments were more impressive when Lisp started getting adopted (when the alternatives were to manage your own memory and even routines were not an object).

But it still has better compactness than Python, in my comparison full of caveats.

https://danuker.go.ro/programming-languages.html#overall-map

What Python needs 350-400 chars for, you can do in 250-300 in Lisp or Clojure.

The compactness is more to be expected in mid- to large-size software. Where one uses macros to develop internal domain specific languages, etc. Long ago I was at a talk where a project manager reported that their slightly over 100 people Lisp team could compete with a roughly 1000 people C++ team, both developing a similar product (an enterprise network switch).

funny, every time i see a pycon talk about metaprogramming, i can only think "nothing that CLOS couldn't do since forever" :)

as other said, python got a lot from lisp so of course it looks underwhelming

but the lisp history and culture is still worth a lot (and there's more to mainstream lisp than is usually shown, people did context oriented programming prototypes, aop, interface passing ideas. As always lisp evolves)

Yeah, I'm certainly not dissing Lisp! It looks nice, and if I didn't know Python, I'd certainly be more interested in it.

The ability to do interactive development in Common Lisp is something you won't find in basically any language. Smalltalk and Forth are probably the only other languages that have similar capabilities (modern Smalltalk images still have zombie processes and unreachable data from decades ago before the implementations had proper garbage collection).

Python REPL can't compare to what CL offers. In CL, I load up a bunch of files and start coding with my codebase running in a REPL. Whenever I make code changes, I can patch in those changes to the running instance. I can try them out instantly. If I've accidentally caused complex conflicts with running code, CL has the tools to deal with them. You can even do this kind of interactive updating against running CL instances (more importantly, you can do interactive debugging against production instances).

In Python, you can have a repl open, but there's not a good way to monkey patch everything. Loading all the things is painful. Stuff like adding new libraries to the repo can cause conflicts. If you update just one definition in a file, you must reload everything which makes those complex conflicts more likely, but Python also doesn't have the tools to solve those conflicts. You aren't getting anything interactive unless you are explicitly running your app in a debugger (and doing this in production just isn't going to happen).

Another fun thing about Common Lisp is dynamic bindings for some things. It's not strictly necessary, but makes certain things a lot easier where you can configure a variable that updates the variable in the called function(s) rather than having to pass it in every time you call those function(s).

Finally, on the macro front, macros are compile time while your Python equivalents are runtime. This is a huge difference when it comes to performance. Python is already dog slow and doing a bunch of dynamic stuff makes that even worse.

While Common Lisp is my favourite programming language, I didn’t necessarily get the Eureka moment by just programming in it (although I understood quite early how the interactive REPL driven way of programming is superior to any other form of programming) but instead when I started to learn more about lambda calculus. Then it really clicked for me.

The Eureka moment for me was when I realized that I can express LET in terms of LAMBDA. And why stop there? I can express DEFUN in terms of LAMBDA too. All of the code is just LAMBDAs and LAMBDAs. That's when it really clicked for me!

So did I, for instance here: http://lambdaway.free.fr/lambdawalks/?view=concepts

When I discovered that I could forget the cons, car, cdr of LISP and rebuild them from the ground, the lambda-calculus, a very basic "text rewriting" tool, the Swiss knife of the code, the TAO of code ...

I also dabbled and didn't have an overwhelming Eureka moment. I do firmly believe there is one to be had though. I suspect it comes when you discover that you can bend the language to your will to solve problems in ways you couldn't have imagined, or would be very difficult in other languages. Lisp is isn't just a program language, it's a programming language toolkit more than most.

The reason why I don't pursue it further is that as a language toolkit, each project evolves effectively into its own language with less portable knowledge if you were to work on a different project with a different team. [For that reason and I do like static types.] Lisp might be more comparable to Perl "there's more than one way to do it". If I were to pursue lisp, I might choose Clojure which has more 'batteries included' and an ecosystem that makes different projects perhaps share more.

I haven't been doing Lisp in a looong time. But in other languages, I do find it annoying that my own code has to abide by certain rules that the implementers of the language do not have.

For example, most languages have "if" statements, but I can't define my own "unless" statement. I have to make do with "if not". In Lisp, it's pretty trivial to make an "unless" that works just like "if" does (except for the negation, of course).

In practice, I'm working on a pretty large Java code base right now, and if I have the need to pass around a value that is evaluated "later", then I have to pass around a lambda expression, and the syntax makes it very clear that there is a lambda expression here. For example, if I want to pass a boolean and a number and I want to make sure that the number isn't computed unless the boolean is true, then I have to write, in Java:

    someMethod(b, () -> a + 5);

Here, "b" would be the boolean, and "() -> a + 5" is the lambda expression that allows "someMethod" to avoid evaluating it in the first place.

In Lisp, I can pass a lambda, too:

    (someFunction b (lambda () (+ a 5))

But I can also define a macro, so that I can call it like this:

    (someMacro b (+ a 5))

Much less ceremony. It does, of course, however, require that you know that this is a macro and that it has special evaluation rules. If you need someFunction/someMacro often in your code base, then it makes sense to go for the macro, and your fellow devs will learn how it works. But if there are just one or two spots in the code base, it might be better to go with someFunc and the lambda because then it will be obvious how it works.

I've basically resigned myself to passing around lambdas all over the place, but it doesn't make me happy.

I would say, keep writing things with it on the side. Maybe it will click like it does for many. For me syntax in other languages is noisy and annoying, but I cannot write lisp full time. I am building my own (as you do) just to be able to code some outside my regular work.

Also; I would forget about macros generally. In my opinion they should be used in very rare cases where other solutions are not pretty enough or really do not work for the usecase and these are rare in my experience.

also the state of the art got slowly most of lisp features.. Nowadays it is not rare anymore metaprogramming in the form of macros, introspection or compiler extensions.

With lisp is still trivial to make a metacircular editor and bootstrap another language, also to create DSLs, but the industry is not appreciating such things anymore as standarization and tool homogeinity seems to be nowadys much better valued.