Show HN: Farolero – Common Lisp style-conditions and restarts for Clojure | Hacker News Reader

Show HN: Farolero – Common Lisp style-conditions and restarts for Clojure

github.com

150 pointssuskeyhose35 comments

farolero is a full, thread-safe implementation of Common Lisp conditions and restarts for Clojure. Most of the other implementations are incomplete or fail in cases related to threading, or don't include a debugger. This implementation is full.

I have plans to make an nrepl-integrated system debugger for integration with cider, although the existing debugger is quite good already.

This library has just hit RC3, which includes a test suite adapted from ANSI-TEST, and is ready for release after a tiny bit more testing.

I believe it would help if you could add a paragraph giving a brief intro to what the condition system means and detailing the advantages of the system for folks who are familiar with Clojure but not with Common LISP.

Here is an introduction by Peter Seibel:

http://www.gigamonkeys.com/book/beyond-exception-handling-co...

(it is a chapter from "Practical Common Lisp", an really excellent book!)

This is pretty cool, conditions/restarts were one thing I always missed in my repl-driven workflow when writing Clojure.

Now someone just needs to implement a reliable way to add/reload dependencies without restarting the REPL.

> Now someone just needs to implement a reliable way to add/reload dependencies without restarting the REPL.

Alex Miller is working on this as an official clojure functionality, see the add-lib, add-lib2 and add-lib3 branches of deps.alpha. It's just brewing very slowly... hopefully with Tonsky now on board they are able to speed up this and other topics!

Yeah, I’ve seen this work. It’s a bit annoying to me because the boot team basically solved this problem years ago too, but the Clojure core team seems to suffer from NIH syndrome.

The other issue, though, is that I think the JVM and a couple of Clojure’s core design decisions are hampering the “everything is reloadable” workflow you get with Common Lisp: in CL, I can leave my REPL running for months and load five or six projects in parallel with no problem. In Clojure, I’ve found that I’m continuously restarting the REPL because things like protocol implementations are hard to reload cleanly.

Protocols being tightly bound to their implementation in Java is a real bummer. Makes using them much more difficult and brittle than an equivalent CLOS-style system.

Also, ASDF makes the concept of a “project” a first class feature in the language: of the various Clojure tools around, only boot took this approach.

Do you mean Fogus, or have I missed something?

Yeah sorry; that would have been interesting, but fogus.

These have also been implemented in pure java - https://github.com/phoe/cafe-latte/

Quite a feat! Now I like to see one in Python, which ought to be easier.

I'm glad to know that my condition system book is of some really concrete use; an independent implementation of CL-style conditions and control flow in Clojure is probably the best example I can imagine for that.

Congratulations, and thank you!

Bought your book. It was a huge help to me understanding the CL condition system. Thank you very much for taking the risk to write a much-needed treatment on a niche topic of a niche language.

Which book are we talking about? could you post a link or a title please?

the-smug-one already posted the title. It was discussed on HN twice:

https://news.ycombinator.com/item?id=23843525

https://news.ycombinator.com/item?id=24867548

The Common Lisp Condition System: Beyond Exception Handling with Control Flow Mechanisms phoe is the author.

I bought and read your book. Unfortunately it is long winded and poorly written, so I advise others not to spend time and money on it. Bit disappointed that it gets misleading treatment online, I was expecting a book by an expert, but I guess lesson learnt when making judgement based on what is written online - those who post more aren’t necessarily any expert in the field!

Hey, could you please review the site guidelines and stick to the rules when posting to HN? Your comments here are breaking them badly—for example, the guidelines that say "Be kind," and "Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."

That doesn't mean that you can't be critical! But critical comments need more care—first, to make sure that they're informative, and second to make sure they're free of swipes and putdowns.

https://news.ycombinator.com/newsguidelines.html

I dare say that this is particularly important in Lisp-related threads. A constant caution to those of us here who love Lisp and related topics is what happened to c.l.l., a community that was once one of the richest in computing and then self-immolated because a few people, for whatever reason, decided to normalize behaving like assholes. So on HN, on all programming topics and especially on Lisp ones, people need to treat each other kindly and share information in a spirit of helping, not putting down.

(Also—please don't create accounts to break the site guidelines with.)

I'd say that comp.lang.lisp went into irrelevance at the same time Usenet did.

I don't think the tone there repelled many people; there must be other reasons, like Python (unfortunately!) replacing Lisp in several domains.

Most newsgroups had a moderated sibling, which was more polite but universally less popular than the main unmoderated one. If the repelled persons had wanted polite discussion, they could have gone there, but they didn't.

Sure, please tell me more about it; I'd like to know what in particular can be fixed in it to make it better. I already know that you're dissatisfied with it and you're up for getting personal at me, but I think that I'll need more details to ensure that whatever is wrong with this edition of the book doesn't get replicated in the future.

You're giving this troll way too much food.

You know, on the other hand, you're calling this person a troll.

I prefer to listen to what they have to say, especially if it means that I have a chance to make my future writing better in some way. (And I already have one concrete issue that I've remembered and passed on to the people that I've been working on my book with, so it's a net win for me.)

You need to write it a few more times so it is clearer. Also I’m sorry if this is harsh, but technical books should be written by experts who have taught the subject for many years and understand the best way to communicate the subject matter. Otherwise better leave it as a series of blog posts.

I don't understand the first sentence; do you mean writing it several times in succession and completely discarding all results but the last one, or more like an iterative process that actually looks back at what was written previously and improves upon that content?

Also, I don't think I can really make use of the latter part; it implies that only people who have taught the subject for years are qualified for writing technical books, which - given that I am not a teacher and likely won't be one - gives the resulting vibe of "just give up" without any possible improvements. I can't make any use of that in order to improve my current or future writing.

Take a few weeks break between each write, you will start to see areas that are clear and those that you will not like. Connect the flow of paragraphs and chapters to each other - hard to see all this when you first write it down; but after taking a reasonable break - you will start to see which areas to change.

I get your point on not being a teacher, but I would recommend doing it as blog posts then and not a book, a book implies something much more. Or maybe I’m just old school and not for the current times. After all, there are countless of ebooks of questionable quality on various programming topics.

OK - thanks, I'll keep that in mind for my future writing and for the second edition of TCLCS (if it happens). The first edition was written pretty fast (a total of six months?) and it did not have enough time to have enough of the "few weeks breaks" that you mentioned, so I can understand that it suffers from lack of text maturity.

I'm curious about "a book implies something much more" though. I have seen multiple series of blog posts that then grew to the point where they were actually published as books. What's the difference between the two when one wants to tell them apart via their content? What's this implication that you mention?

At least for me, those blog posts that become a book are not of very high quality. Very bad actually.

For example, books (at least used to) have editors, and reviews by multiple specialists in the field. I can’t think of distinct step between personal writing and something publishing, so I cannot add meaningful comments to your question.

I've had the book reviewed and edited by several people (mentioned in the front matter), and you're not the first person to complain about the long-winded style. This likely means that we collectively screwed up with regard to the English layer of the book.

Thanks for the feedback; I'll let my reviewers/editors know, get this fixed in the second edition, avoid doing that in my future writing.

Perhaps you could link to one of your books for an example of how it should be done?

While I think that arguments by sglisp could have been much more persuasive, I also tend to think that arguments along the lines of "If you don't like it, show us your own work" are disingenuous. One does not need to be a good baker, or even a baker at all, to recognize and reject stale bread.

Not many books pass this high a bar. CL is special, but many technologies won't remain relevant for many years -- how would we ever see books about those?

How does this system compare to algebraic effects?

How well does it play with common java libraries?

The unwinding mechanism that it uses extends from java.lang.Error, which means most catch blocks in Java code won't catch them, which means it should interact with Java libraries just fine in most cases.

Reply on news.ycombinator.com