git-of-theseus VS timbre

https://github.com/erikbern/git-of-theseus

A tangentially related tool you can use to look at a repo over time is Git of Theseus[1]. It shows things like "what percentage of the code in this repo survives 6 months.

[1]https://erikbern.com/2016/12/05/the-half-life-of-code.html

There're some more in the presentation article: https://erikbern.com/2016/12/05/the-half-life-of-code.html#:...

A kernel line has half-life 6.6 years.

Look at the codebase with Git of Theseus or Codescene

I guess one good example (that was mentioned just yesterday here on HN) would be Flask vs FastAPI: https://news.ycombinator.com/item?id=31953470 - "There are no open issues or pull requests on Flask "

Quick count finds that FastAPI has 48422 lines of code, while Flask has 9995. Flask just achieved "Zero standing issues/PRs" while FastAPI has 1.1K open issues and ~500 open PRs.

Large surface area/API quickly leads to be overwhelmed when you're trying to maintain it. Adding new features/fixing existing ones becomes harder as well.

Best bet to make sure something is maintainable over time is to add as little as possible to it, and if you really have to, make sure you're also removing something at the same time.

Otherwise you need a massive team just to be able to "survive" and not making things rot.

There is this blogpost as well about the "half-life of code": https://erikbern.com/2016/12/05/the-half-life-of-code.html

Someone run that tool on the Clojure codebase as well, and it really shows how well the Clojure codebase has been written, as most code that was initially written is still there and does what it needs, without having to be rewritten.

Some parts of technical debt, you can find with https://github.com/erikbern/git-of-theseus or https://codescene.com/

There are logging libraries that include syntactically scoped timers, such as mulog (https://github.com/BrunoBonacci/mulog). While a great library, we preferred timbre (https://github.com/taoensso/timbre) and rolled our own logging timer macro that interoperates with it. More convenient to have such niceties in a Lisp of course.

Mentioning μ/log and no mention of timbre (https://github.com/taoensso/timbre), that is an odd omission. Malli is a great mention, but there ought to be a mention of clojure.spec (https://github.com/clojure/spec.alpha) which has much more mindshare.

If you're not familiar with lisps in general, it might be hard to grok the differences between lisp-macros (as used in Clojure) and "normal" macros you see in other languages.

But, if you are familiar already, and just wanna see examples of neat macros that makes the API nicer than what a function could provide, here are a few:

- https://github.com/clojure/core.async/blob/master/examples/w...

- https://github.com/weavejester/compojure

- https://github.com/ptaoussanis/timbre

- https://github.com/krisajenkins/yesql

When clj is invoked, two libraries will be available in our code: timbre logging library which artifacts taken from Maven, and test-runner, taken from GitHub.

No, I don't think they were hyped at any point.

They are used in certain libraries like https://github.com/ptaoussanis/timbre but for things that are simply not possible without macros, for example (timbre/spy (+ 1 1)) will actually print both the expression and the result:

DEBUG [ss.experimental.scratch:1] - (+ 1 1) => 2

Perhaps if the macros are "simple" they can be unpacked relatively easily. I do understand how mentally challenging that can be for somebody who's just starting with Clojure. I've been using Clojure for ~8 years and only just recently became more comfortable with macros after I made a conscious effort in that direction. I'm still far from an "expert" in them.