Hacker News Reader

Comment by behnamoh | Hacker News Reader

I find it funny and also ironic that a lot of modern languages re-discover Lisp's amazing features decades later. The other day I was infuriated to see my Python program halt after 9 hours of API calling to my own home server. The API calls were similar (calling an LLM with a pre-defined prompt template, constrained using grammars). I wanted to save the state of the program and exit it before running the remaining iterations separately. So I needed a way to modify the current running Python code and inspect the variables. I couldn't figure out a way to "dig into" the running Python process and save the state and/or fix it. So I lost 9 hours worth of work.

A couple days later, I saw this:

https://malisper.me/debugging-lisp-part-1-recompilation/

The fact that CL had this feature built into the language decades ago just blows my mind. Not to mention numerous other features (like the most powerful macro system there is), etc.

View on HN

> I find it funny and also ironic that a lot of modern languages re-discover Lisp's amazing features decades later.

This is never surprising as Lispy languages are some of the most flexible and expressive languages. But that's the problem, it is too expressive. The Lisps always reminded me of mixed media (visual) art, where the freedom of expression from the mixed media sounds good on the face of it but in the end it generally produces sub-par works compared to more traditional single media art. It turns out that the restrictions of the medium are just as important as the expressiveness.

thats a great analogy.

Thanks!

I've seen shitty code running in 'prod' at every employment I've had as a developer. The language isn't that important, the people and the organisation are.

Language is very important. Bad code in python is at least still python. Bad code in lisp can be an inpenetrable eldritch abomination where the only option is to rewrite from scratch. I believe this is actually the primary reason google build go. You can't write good code. But you also can't write really bad code.

Why do you believe it impossible for Python to be impenetrable?

A Common Lisp will likely be much more introspectable and debuggable than your average CPython.

I think Google designed Golang to be a small language for implementing network services that will tie newcomers to programming hard to that specific language and then also Google. Hence the syntactic quirks and the err spectre. That it enables development of CLI applications was likely an unexpected bonus.

It's not impossible for python to be impenetrable, but it usually isn't.

But Lisp usually is, or what?

the pip fiasco?

It's not impossible. But rather much less likely. And even less likely to do by accident. Lisp by itself basically encourages programming deviating from standard practices. That the entire reason it's so powerful. It takes a real genius in addition to strong restraint to keep writing good code in that environment.

What do you mean, "encourages programming deviating from standard practices"?

He means he once read an article written by a web developer with no Lisp development experience called "The Lisp Curse", and that's his entire Lisp development experience.

Right, yeah, seems likely. Such comparisons are usually pretty weird, putting non-hygienic macros against ordinary programming in some other language, rather than macros against the metaprogramming used there.

Experience with macros and their footguns arguably prepared me pretty well for using JAXB and reflection professionally.

He means it's hard to do Java(script)

Lisp Macros are encouraged. In most other language you can't even write syntactical extensions. Such things are, generally, horrendous for readability. Like I said you can wield them effectively. But the average developer won't be able to.

Why not? Is "the average developer" hampered by some neurodevelopmental deficit?

How come the freedom in naming of functions and data doesn't have the same effect?

If you disagree that Lisp has a tendency to become unreadable then maybe the typical developer might have a "neurodevelopmental deficit" compared to you. bindings don't change the language that's executing. That's the entire point why Macros can quickly make code unreadable.

Macros do not change the language that is executing (as in self-modifying code).

Self-modifying code is possible to express by other means in traditional Lisps that have a quote operator.

In Common Lisp, it is undefined behavior to modify a quoted part of the program.

E.g. this wold be undefined:

  (defun counter () (inc (car '(1))))

The function is referring to a piece of its own syntax (1) which initially holds the integer 1 and incrementing that. This may have the expected effect under some circumstances. Or it could have the expected effect, plus some unexpected effect, or not have the expected effect at all. It may signal an error, also.

You can easily write unreadable Java code. So what?

stack overflow syndrome?

> are encouraged {by-whom}

Google Lisp style guide: Use macros when appropriate, which is often. Define macros when appropriate, which is seldom.

Heinrich Taube's "Lisp Style Tips for the Beginner": Beware of macros. They are a very important feature of Lisp but a poorly implemented macro can cause bugs that are very difficult for a beginner to solve. Avoid writing macros until you understand how the Lisp reader and evaluator work. Never write a macro to make things "more efficient".

Guy Steele and Kent Pitman, "Tutorial on Good Lisp Programming Style" [1993]: Decide if a macro is really necessary. [...] Don't use a macro where a function would suffice.*

Carnegie-Mellon Lisp FAQ: Never use a macro instead of a function for efficiency reasons. [...] Don't define a macro where a function definition will work just as well -- remember, you can FUNCALL or MAPCAR a function but not a macro.

I've never seen a book, tutorial or style guide document saying that Lisp coders should be writing lots of macros, and constantly looking for any excuse to write another macro or some such advice.

> In most other language you can't even write syntactical extensions.

C? C++? Rust? Erlang? Scala? Julia? R?

> Such things are, generally, horrendous for readability. Like I said you can wield them effectively. But the average developer won't be able to.

Macros actually are widely used to improve readability. In Lisp that's one of its main purposes. It leads to more compact, declarative, domain specific code. Large programs usually benefit the most. Programs can be much short and more readable.

Take for example in Common Lisp the Common Lisp Object System. It has three layers: an object-layer at the bottom, then a functional layer and on the top is the macro layer. The macro layer is what the typical developer uses, which is compact and which shields the developer from the details of the lower layers. The Common Lisp Object System blends seamlessly into the rest of the language and the usual basics can be easily learned.

@cess11 on Golang, no, rather Ken Thompson and colleagues designed a language stripped off things they find as an unnecessary cruft and they could finally get back to the fun they had before Java and OO.

"Finally".

I don't disagree that Java has cruft, but Go didn't fix data races, nulls or lack of sum types. It's not a "fun" language for me.

Yeah that's ok for you to think like that, at the same time it's fun for the creators and for a number of users, including me. Btw there so many languages with sum types (and almost none that fixed data races) that everybody can choose.

The point is, I was aiming to refute one cummenter's claim that Go was created to lure specific people into Google as devs. Highly unlikely, Go's adoption in Google wasn't bad but also wasn't exactly a bed of roses.

Wait until you learn about Go's custom """portable""" (it's not) ASM dialect.

"I believe this is actually the primary reason google build go." Well the actual quiet part is that they built Go to reduce costs of paying those highly trained software engineers and replace them with moderately trained monkeys.

Actually it was because some engenieers take pride in creating complex solutions for problems that a moderately trained monkey could solve in a managed language.

> Bad code in lisp can be an inpenetrable eldritch abomination where the only option is to rewrite from scratch.

That’s also true for good lisp.

Py-spy or Pystack to inspect the state to certain degree.

Or https://github.com/malor/cpython-lldb.

Or more here: https://github.com/albertz/pydbattach/

If you have a process running for multiple hours, it should be saving work to disk and be ready to pick up where it left off.

Indeed. Using Joblib for instance (https://joblib.readthedocs.io/).

Was there no exception being thrown?

I don't know how that would have helped. Most languages (including Python, AFAIK) unwind the stack when an exception is thrown, all the way up to the nearest catch. Whatever you wanted to do at the place of throwage is no longer possible because that stack doesn't exist other than as an incomplete printout.

In contrast, Common Lisps condition system keeps all stack between throw and catch so you can resume from anywhere in between, possibly with altered code or local variables.

Basically, Common Lisps exception stack traces are interactive by default.

Ironically that stack unwinding is exactly why I like a straight old sigsegv.

Just dump the core and analyse the frozen state. One thing that annoyed me in go is that even when it core dumps on panic and after I worked on the backtrace analyser for gdb, most of the core dumps were useless as everything of worth was already unwound and lost.

Hidden in plain sight is the fact is that structured exception handling in 32-bit Windows (the linked-list-on-the-stack version[1,2], not saying anything about the gigantic-tables “zero-cost” version) is a resumable exception system a la Common Lisp conditions—inevitably, seeing as it subsumes SIGSEGV coredumps!

[1] http://bytepointer.com/resources/pietrek_crash_course_depths...

[2] http://bytepointer.com/resources/pietrek_vectored_exception_...

I don’t quite understand what sort of state the system is in at this stage. So the process has errored but not exited?

I know that during the exception you can pry into the variables from the stack. When do they get cleaned up?

https://stackoverflow.com/a/5328139/171450

For that to happen, you must have implemented what that SO answer says in your code. In contrast, CL allows you to modify the current running code and apply fixes.

I guess I’m confused about what running code even means after the exception. The process has crashed. Is it waiting to be reaped by a parent process?

If there is an exception a matching error handler will be selected and called in the context of the error. A default handler could be a debugger, a break loop (which is a Lisp REPL), something which asks the user waht to do or it could be a handler provided by the software, which could do anything, including looking for restarts and using one.

For example the variable a is unbound and we try to add 3.

    CL-USER 37 > (+ 3 a)

CL shows an UNBOUND-VARIABLE error and provides Restarts. Restart 3 is a USE-VALUE restart.

    Error: The variable A is unbound.
      1 (continue) Try evaluating A again.
      2 Return the value of :A instead.
      3 Specify a value to use this time instead of evaluating A.
      4 Specify a value to set A to.
      5 (abort) Return to top loop level 0.

    Type :b for backtrace or :c <option number> to proceed.
    Type :bug-form "<subject>" for a bug report template or :? for other options.

We are now in a break loop, a REPL one level deeper, in the context of the error. Let's see what the condition (-> exception) is:

    CL-USER 38 : 1 > :cc
    #<UNBOUND-VARIABLE 8010002EC3>

we call one restart (listed above, number 3) interactively, it uses the new value and continues to compute the expression. It asks for a value. I enter 5 -> 5 + 3 = 8

    CL-USER 39 : 1 > :c 3

    Enter a form to be evaluated: 5
    8

We can do it also programmatically. HANDLER-BIND establishes a handler for UNBOUND-VARIABLE. It invokes the restart USE-VALUE with 4 -> 3 + 4 = 7

    CL-USER 40 > (handler-bind ((unbound-variable #'(lambda (c)
                                                      (invoke-restart 'use-value 4))))
                   (+ 3 a))
    7

All this is the default behavior. There is no special "debug mode", attaching a debugger or "instrumentation of code" needed.

In the CL condition system they have separated error detection (exception thrown) from handler selection (catching exception) and handler implementation (what are called "restarts".)

So basically instead of registering one handler (catch block) that is responsible both for determining the proper course of action and implementing it, the condition system allows you to register multiple "restarting points" which the handler can select from when deciding how to handle the error.

One of the restarts often used in debugging is restarting any of the functions in the call chain, i.e. just trying the same thing again. But just as common is varying some parameter or local variable and then restarting the function.

The process hasn’t crashed after an exception. It still might even exit with a success error code, if you really want it to.

An exception is raised when you attempt to parse HTML as JSON. The process doesn’t end. You catch the exception, see what happened, and respond with a 400.

> Most languages (including Python, AFAIK) unwind the stack when an exception is thrown, all the way up to the nearest catch.

You might have to use a few tricks/hacks, but I'm pretty sure you can set up python in a way to breakpoint at an exception, including all local state at the throw site. Otherwise pdb would not work.

Definitely.

It’s very possible to pause (pdb-like) or persist the local state/stack.

But there needs to be an actual exception.

If someone pulls the power cord, you’re out of luck.

Can the program be recovered once the exception is thrown and you start debugging? Or is the keeping of the stack the last allowed state before exiting?

It can be caught and managed, or frozen and examined, but that branch of code has no way forward.

Reply on news.ycombinator.com