Holger @schaueho@functional.cafe
- Languages
- German, English
Living in Germany, interested in #clojure, #softwarearchitecture, #agile, #emacs, #opensource, #nlp, #security and #privacy.
Joined Feb 2019
Which brings me back to my humble and minor disagreement with Luke's gist: for sure, I would agree that his recommendations apply to any public API. But generally asking that all data structures that are needed to call a non-private function should be governed like he describes, seems to me to be too much. #clojure 5/5
The overall point here is that in #clojure (like in many other languages) the distinction between "public" and "private" might not be as clear cut or simple as it seems. It is likely that a number or even the majority of "public" functions are likely to be actually more implementation details and not intended as a public API (albeit not signified as such by anything). If you think that this is just a lack of discipline, I would half agree but also point to the annoyances that anything declared private brings. 4/5
There is also the convention that libraries have a .core namespace which is defining the public API of a library. Obviously, there is nothing in #clojure that would enforce this convention. And if you're not working on a separate library but more an internal module of a bigger system, having multiple .core namespaces might even be not so pleasant to work with (eg. switching buffers).
Also, of course what you put into your .core module is completely up to you, so it's up to the intention or carefulness of the programmer if any non-private symbols in said .core module really form a public API or not. 3/n
I guess there is a broader point here to be elaborated on: #clojure provides the :private meta data as a way to signify, well, something akin to encapsulation. However, this is not particular strict, as you can see from the availability of both ns-publics and ns-interns. 2/n
Luke VanderHart has written a nice gist about data modelling in #clojure. I like the distinction between private and public data and also the recommendations for the public data. The main point I'm not entirely convinced of is the strong correlation between public functions and the public data structures: maybe it's just me being lazy, but I'm not using private functions too much.
https://gist.github.com/levand/c97dd272bfd2f88fe5089eb81f85f98f
Came across a blog post comparing #clojure editors, which in the first paragraph speaks and links to an article about the #dygma raise keyboard and the setup the author uses. https://www.karimarttila.fi/keyboard/2020/09/28/dygma-raise-reflections-part-1.html
Quite different from my setup which aims a lot more to be closer to normal keyboards. I guess I should put together a blog post on my setup, too.
TIL that there is a clojure-lsp project that tries to build support for the generic language-server protocol that editors like VSCode are using. Maybe I should take a look at Emacs' lsp-mode, I guess?
https://github.com/snoe/clojure-lsp
https://emacs-lsp.github.io/lsp-mode/
Fantastic talk by mourjo on "Building resilient services in Clojure" on day 2 at #reclojure today. He uploaded the slides already:
https://speakerdeck.com/mourjo/building-resilient-services-in-clojure
#clojure @clojure
Today the re:Clojure 2020 conference is happening, a free and on-line conference for all things #clojure.
https://reclojure.org/
See you in the virtual hallways. @clojure
The results of the clojureD survey are in. Apparently, most would want to have a real-world conference, so the team will look into organizing something for summer 21. Good news!
Details on https://clojured.de/
Railway oriented programming in #clojure. ROP is a style in which you want to chain multiple functions but want a single track to catch any errors happening. My main issue with this is that all too often you want more flexibility than just a single unified error handling.
#clojured (the Berlin conference on #clojure) is running a survey to figure out what people would prefer for a 2021 summer edition. Please boost!
https://clojured.de/clojured-2021-survey/
(Note: I'm not affiliated with the conference, I just think it's great.)
Dan Lebrero summarizes Zach Tellman's "Elements of Clojure" book (https://danlebrero.com/2020/08/12/elements-of-clojure-book-summary/)
I agree with this one-sentence summary of the book: "There are some elements of Clojure on the book, but most of the content covered is universal to any language." I should probably follow up with my impressions of the book, but I'm not sure I have the energy to do it.
New online Clojure Europe meetup announced:
https://clojureverse.org/t/new-online-meetup-clojure-european-summer-time/6018/9
This is a course on the foundations of computational linguistics, using #clojure:
From what I can see from a quick glance from the table of content, it contains a lot of stuff, from formal languages over bag-of-word approaches to Markov chains, but is not addressing more high-level aspects of CL, like semantics or discourse.
https://foundations-computational-linguistics.github.io/chapters/01-Introduction.html
After a very long time, I wrote a blog post with some #clojure content: How to download content from a ClojureScript application. Enjoy.
http://blog.find-method.de/index.php?/archives/218-File-download-with-ClojureScript.html
"Monads and transducers are literally 100% the same" -- only that, of course, they are not, but the way they are getting discussed is the same.
https://buttondown.email/hillelwayne/archive/monads-and-transducers-are-literally-100-the-same/
"superv.async is a Clojure(Script) library that extends core.async with error handling and includes a number of convenience functions and macros."
"Erik Naggum invented Clojure syntax in 1997"
https://www.xach.com/naggum/articles/3070821916847636_-_%40naggum.no.html
- Languages
- German, English
Living in Germany, interested in #clojure, #softwarearchitecture, #agile, #emacs, #opensource, #nlp, #security and #privacy.
Joined Feb 2019
