Doc [skip ci]

This commit is contained in:
Michiel Borkent 2020-12-06 23:04:21 +01:00
parent 502a14b505
commit d6de7a1298

View file

@ -3,9 +3,9 @@
The raw data from the babashka survey held in November 2020 is now available The raw data from the babashka survey held in November 2020 is now available
[here](https://nl.surveymonkey.com/results/SM-8W8V36DZ7/). [here](https://nl.surveymonkey.com/results/SM-8W8V36DZ7/).
We had about 100 respondents just below the free tier of SurveyMonkey. Next time We had about 100 respondents (just below the free tier of SurveyMonkey). Next
I'll probably switch to Google forms and add an optional contact field, since I time I'll probably switch to Google forms and add an optional contact field,
would have liked to go deeper into some of the answers. since I would have liked to go deeper into some of the answers.
Here are the ten questions from the survey followed by the summarized outcome Here are the ten questions from the survey followed by the summarized outcome
and my commentary. and my commentary.
@ -58,8 +58,7 @@ programming. This is more than I could have hoped for when I started babashka.
*My comment:* Shelling out is a popular thing to do in babashka: *My comment:* Shelling out is a popular thing to do in babashka:
`clojure.java.shell` is the most widely used namespaces. The `babashka.process` `clojure.java.shell` is the most widely used namespaces. The `babashka.process`
namespace is already used quite a lot while it has only been out since a namespace is already used quite a lot despite its recent appearance.
2020-10.
Other popular ways to use babashka: Other popular ways to use babashka:
@ -148,26 +147,31 @@ work in progress [here](https://github.com/babashka/fs).
### Q5 What features or namespaces in babashka are redundant and could be left out? ### Q5 What features or namespaces in babashka are redundant and could be left out?
Most people did not suggest anything should be removed, maybe also related to Most people did not suggest anything should be removed, maybe also related to
the major answer to Q9. A few people expression confusion about multiple ways of the most given answer to Q9. A few people expressed confusion about multiple
making http requests. ways of making http requests.
*My comment:* If have attempted to write about this *My comment:* If have attempted to write about HTTP request in babashka
[here](https://book.babashka.org/#_choosing_the_right_client) and [here](https://book.babashka.org/#_choosing_the_right_client) and
[here](https://github.com/borkdude/babashka/wiki/HTTP-client-and-server-considerations). [here](https://github.com/borkdude/babashka/wiki/HTTP-client-and-server-considerations).
The summary is that both `babashka.curl` and `org.httpkit.client` have different The summary is that both `babashka.curl` and `org.httpkit.client` have different
use cases. In most small scripting scenarios or for downloading big files optimal use cases. In most small scripting scenarios `babashka.curl` will
`babashka.curl` will do. For making many small requests `org.httpkit.client` is do. For making many small requests `org.httpkit.client` is more optimal since it
more optimal. In the future both of these clients may be superseded by a client won't create an OS process. For downloading big files, `babashka.curl` is more
based on `java.net.http` (probably exposed as `babashka.http-client`), but this optimal, since there is no way to prevent `org.httpkit.client` from holding the
client isn't there yet and it may take a while before the Java 11 client space response into memory all at once.
has crystallized. Meanwhile you will have to do it with either of these
In the future both of these clients may be superseded by a client based on
`java.net.http` (probably exposed as `babashka.http-client`), but this client
isn't there yet and it may take a while before the Java 11 client space has
crystallized. Meanwhile you will have to do it with either of these
clients. Luckily both clients accept and return Ring-like maps, so upgrading to clients. Luckily both clients accept and return Ring-like maps, so upgrading to
the future client should not be hard, unless you are depending on something very the future client should not be hard, unless you are depending on something very
specific. I plan on keeping `babashka.curl` either way, since it's a very thin specific. I plan on keeping `babashka.curl` in babashka no matter what, since
layer over `curl` and doesn't complicate the compilation process of babashka it's a very thin layer over `curl` and doesn't complicate the compilation
much. There will be a transition period of having both `org.httpkit.client` and process of babashka much. There will be a transition period of having both
the `java.net.http` client after which `org.httpkit.client` will be phased out `org.httpkit.client` and the `java.net.http` client after which
and `babashka.http-client` will be the recommended HTTP client in babashka. `org.httpkit.client` will be phased out and `babashka.http-client` will be the
recommended HTTP client in babashka.
### Q6 Babashka prints the last value of an expression or script. Should this change? ### Q6 Babashka prints the last value of an expression or script. Should this change?
@ -181,14 +185,14 @@ and `babashka.http-client` will be the recommended HTTP client in babashka.
*My comment:* *My comment:*
The major answer is: no, keep it this way. Most of the `it depends` answers The most given answer is: no, keep it this way. Most of the "it depends" answers
said: I don't really care. Some suggested that printing should always be said: I don't really care. Some suggested that printing should always be
explicit and maybe should be controlled using a flag. explicit and maybe should be controlled using a flag.
The reason babashka always prints the list value of a script, unless it is The reason babashka always prints the list value of a script, unless it is
`nil`, is that in the very beginning, babashka was intended as a one-liner only `nil`, is that in the very beginning, babashka was intended as a Clojure-in-bash
Clojure-in-bash utility. So we basically only had the `-e` option and not the one-liner utility. We only had the `-e` option and not the `-f` option for
`-f` option for executing files. When the `-f` option got added, it was handled executing scripts from disk. When the `-f` option got added, it was handled
exactly the same as `-e`, with the difference that the expression was read from exactly the same as `-e`, with the difference that the expression was read from
a file. a file.