timbre VS ring

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.

* HTTP: Ring is the de facto way to manage HTTP request (see https://github.com/ring-clojure/ring/wiki/Concepts). Jetty and Aleph are common web servers (and https://github.com/clj-commons/aleph) that implement Ring interface.

https://youtu.be/LcpbBth7FaQ (really cool live coding session with REPL-driven development for a ring web app)

> In the HTTP handlers it makes sense that you don't have return values, because: What would you do with that value exactly?

I think that approach used by clojure's ring shows an elegant way to represent http responses https://github.com/ring-clojure/ring/wiki/Concepts#responses. They are essentially structs with the following fields:

status := number

headers := map of string->string

body := stream | string | seq | inputstream

Request handlers are handed a request struct that is similar. The handler is a function that maps a request to a response (it doesn't actually write to streams itself).

I like this style for an http library for a couple of reasons:

1. HTTP resources can be viewed as functions whose domain is the request, and range is the response. Having the abstraction match that makes for really nice code.

While you won't find your Spring here, you will find that many of those web libraries will tend to use or produce Hiccup, return Ring maps or maybe have pipelines built using interceptors. Composing libraries together is usually not that hard, but it does require you to leave the comfort zone of the framework's abstractions to try to understand what is actually happening e.g. when someone makes an HTTP request and something is returned and displayed in the browser.

On that note, are you able to support everything required by the ring spec?

You can check out my example project in Clojure with using Ring.

It uses already mentioned ring api (https://github.com/ring-clojure/ring/wiki).

I've tried to pair down to the simplest example which shows the issue, and raised it here as I couldn't see one you'd already created or similar: https://github.com/ring-clojure/ring/issues/436 This is so that I have something to link to/follow from our side, hope you don't mind, and many thanks for the diagnosis!