Live data from Hacker News

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

github.com

21–30 of 37 posts

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

#21
post #20
post #6

Earlier quoted context omitted.

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

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

#22

Earlier quoted context omitted.

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.

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

#23

Earlier quoted context omitted.

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

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.

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

#24
post #7
post #6

Earlier quoted context omitted.

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

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?

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

#25
post #18

Earlier quoted context omitted.

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 s…

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.

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

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

#26
post #5
post #4

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!

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

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

#28
post #26
post #5

Earlier quoted context omitted.

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…

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.

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

#29
post #18

Earlier quoted context omitted.

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.

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.

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

#30

Earlier quoted context omitted.

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

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.
Post reply on HN