I was tired of having to rely on a browser for fetching torrents from torrents-csv.com so I sat down for a few hours and put together an Emacs front-end for it. It is very minimal and all it does is get the magnet for a selected torrent, but it's one step away from the browser :)

I eventually want to have a general torrent search engine inside Emacs but for that I need a better way than relying on fishy crawlers, I'd probably self-host bitmagnet.io. But that'll be in the future.

https://codeberg.org/divyaranjan/torrents-csv.el/

It took only a few hours of dealing with JSON to remind myself of something a lot of people don't think about:

How absolutely terrible JSON is as a language to store and parse data and how absolutely beautiful S-Expressions are at doing the same.

To those who somehow feel bad about working with parentheses, though personally I can't fathom such inflexibility in my own disposition, a fellow Lisper created a way to keep much of the goodness of S-Expressions but take the parentheses out.

I would never wish to edit Lisp like this, but if someone "really" wants to learn Lisp and "really" it's the parentheses that's stopping them, then the answer is here:

https://readable.sourceforge.io/

Apparently, *sigh*

Arguably the best blogpost I've read on this topic (of ownership):

https://without.boats/blog/ownership/

I and just about every designer of Common Lisp and CLOS has had extreme exposure to the MIT/Stanford style of design. The essence of this style can be captured by the phrase the right thing. To such a designer it is important to get all of the following characteristics right:

* Simplicity -- the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.
* Correctness -- the design must be correct in all observable aspects. Incorrectness is simply not allowed.
* Consistency -- the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness.
* Completeness -- the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.

I believe most people would agree that these are good characteristics. I will call the use of this philosophy of design the MIT approach. Common Lisp (with CLOS) and Scheme represent the MIT approach to design and implementation.

The worse-is-better philosophy is only slightly different:

* Simplicity -- the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.
* Correctness -- the design must be correct in all observable aspects. It is slightly better to be simple than correct.
* Consistency -- the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency.
* Completeness -- the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must be sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.

Early Unix and C are examples of the use of this school of design, and I will call the use of this design strategy the New Jersey approach. I have intentionally caricatured the worse-is-better philosophy to convince you that it is obviously a bad philosophy and that the New Jersey approach is a bad approach.

However, I believe that worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing, and that the New Jersey approach when used for software is a better approach than the MIT approach.

Richard P. Gabriel, Lisp: Good News, Bad News, How to Win Big (1991)

Richard P. Gabriel, Lisp: Good News, Bad News, How to Win Big (1991)

The urge among mathematicians to save the 'convention' after the rise of paradoxes in foundations. Even the rigorous formalist that Hilbert was, famously relied upon Cantor's paradise.

Nicholas Bourbaki, Elements of the History of Mathematics (1984)

On the approach of Brouwer's intuitionism that eventually lead to modern-day constructivism.

Nicholas Bourbaki, Elements of the History of Mathematics (1984)

Got a reprint of this classic earlier this month. Good memories of learning exterior products for the first time from this. I wish/hope someone writes a biography of Spivak, always fascinates and inspires to know about people who dedicated their life to see the universe through the keyhole of a specific area. Spivak did that for all things related to geometry. A rare persona, and much rarer today.

I'll be reposting some posts from here and the other channel to my Mathstodon account, found some really good people and communities there. I'll eventually automate a bridge, but that has to wait until my self-hosting setup is ready.