This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-01-03
Channels
- # aleph (2)
- # announcements (13)
- # babashka (7)
- # beginners (36)
- # calva (26)
- # cider (11)
- # circleci (13)
- # clj-kondo (15)
- # clojure (105)
- # clojure-europe (79)
- # clojure-nl (3)
- # clojure-uk (6)
- # clojurescript (17)
- # conjure (4)
- # core-logic (2)
- # cursive (10)
- # data-science (5)
- # datalevin (11)
- # datalog (14)
- # eastwood (6)
- # emacs (2)
- # figwheel-main (1)
- # fulcro (34)
- # google-cloud (1)
- # graphql (3)
- # introduce-yourself (7)
- # jobs (1)
- # leiningen (17)
- # lsp (46)
- # malli (2)
- # minecraft (3)
- # missionary (19)
- # off-topic (31)
- # other-languages (49)
- # polylith (2)
- # portal (5)
- # practicalli (1)
- # quil (77)
- # releases (1)
- # remote-jobs (1)
This is an interesting article about the missing books that Haskell should have (according to the author). Wonder what kind of books are missing in Clojure? https://github.com/graninas/The-Voids-Of-Haskell
I'd like to see one called Leveraging Clojure. The hosted nature is truly coming into its own these days. People are deriving tremendous leverage across hosts (frontend, backend, mobile, scripting, ML/Stats, DBs, Ops/build tooling etc.). The why and how to truly Leverage Clojure still feels a bit like black magic. It's sort of "but of course" once we see the value of "it's just data", and develop a sense for the language of the system. But even then the knowledge is very tribal. Some people are waaaay ahead of the curve than most of us. I feel like there is increasingly a good business case, where the vast majority of one's software + staffing requirements could be served via the leverage of a combined Clj + Cljs + graal ecosystem.
I would like to see a book that covers the topic of "growing a system." I want to see a REPL-driven program grow over time into a production system, and I want to see how the author thinks about breaking up the system into subcomponents as it grows and how they manage the relationships between subsystems. Taking a developmental approach to "Clojure in the large" is probably the best way to teach the idioms of how to manage a program/system as it grows in complexity. Ideally such a book would be written with a minimum number of libraries; I would like to see how the built-in capabilities of Clojure as a language can be used to solve these problems instead of the "just use mount/integrant/whatever" suggestion.
1The closest analogue I can think of is https://aosabook.org/en/index.html , which blends architectural analysis, performance considerations, and project history a bit in each subject, but isn't a single sustained treatment of a single system changing over time.
I'd like to see one called Leveraging Clojure. The hosted nature is truly coming into its own these days. People are deriving tremendous leverage across hosts (frontend, backend, mobile, scripting, ML/Stats, DBs, Ops/build tooling etc.). The why and how to truly Leverage Clojure still feels a bit like black magic. It's sort of "but of course" once we see the value of "it's just data", and develop a sense for the language of the system. But even then the knowledge is very tribal. Some people are waaaay ahead of the curve than most of us. I feel like there is increasingly a good business case, where the vast majority of one's software + staffing requirements could be served via the leverage of a combined Clj + Cljs + graal ecosystem.
Game dev question. Any game IDE/framework/mix of tools that: • allows me to write the game logic in clojure on the editor of my choice • allows a graphic designer friend to be relatively independent with the assets, scene building, etc • is geared towards 2d games • can target the web Probably asking for too much, specially with that first bullet point. I’m mostly looking for something that would make a fun experience for both me and my non-coding friend. I’ve never tried Unity (Arcadia), but I’d probably find it too complex for what we want to do (graphically simple 2d games)
My best bet is probably something like a JS library (PixiJS?) + a separate graphic editor (Aseprite, Photoshop, …) and write something some glue code to connect the two (so we can have assets live-reload for example)
There is a project that lets you use Clojure with Godot engine/editor: https://github.com/arcadia-unity/ArcadiaGodot
This guy made a simple 2D game with it and put out the source as an example: https://github.com/russmatney/lil-shooter
Didn't knew that, thanks! Between unity or Godot I'd rather use Godot for sure. I'll check it out :)
can you elaborate on what you mean?
I have to admit the idea is pretty vague in my head 😅. I'm thinking something like "Working Effectively with legacy code" but for documentation. Basically how to document an old app where all the domain knowledge is in the head of one developer.
This message won't substitute a book, but seems like this approach works decently well: • Hire a middle dev • Make him change things gradually in all the parts of the codebase • Note every time he says "what the hell" and make him write a documentation page about that place once he achieves enlightenment
I would like to see a book that covers the topic of "growing a system." I want to see a REPL-driven program grow over time into a production system, and I want to see how the author thinks about breaking up the system into subcomponents as it grows and how they manage the relationships between subsystems. Taking a developmental approach to "Clojure in the large" is probably the best way to teach the idioms of how to manage a program/system as it grows in complexity. Ideally such a book would be written with a minimum number of libraries; I would like to see how the built-in capabilities of Clojure as a language can be used to solve these problems instead of the "just use mount/integrant/whatever" suggestion.
1Holy cow, there is semver version 2.0.0 published now. Now I'm curious what they changed to bump up the major version number 🙂
Makes you wonder if you switch your versioning scheme from semver 1 to 2, is that a major or minor version bump of your own?
Maybe you should adhere to <your-version>-<semver-version> e.g.: 0.1.0-2.0.0 to know how to interpret your version number.
Hmm, so I can use 0.x.y-1.0.0 to mean that the API can have breaking changes as long as it starts with "0.", but maybe I could also use "x.y.z-0.1.0" to mean "not following semantic versioning at all" 🙂
I saw a go lib that basically said that their lib version would always be http://1.999.xxx in protest of some versioning scheme that the go team was pushing for
Perhaps instead of having a semantic version, one should have a programmatic way to figure out if a library can be safely upgraded, like some sort of exception or warning if you go from version X to Y
I think that the practice that some popular JS libs have gone where they offer a "codemod" in the form of a CLI script that automatically upgrades call sites for breaking changes is nice
obviously it doesn't cover more complex breaking changes, but codemods can also potentially detect and warn against those cases
For Rust there is, https://github.com/rust-lang/rust-semverver haven't used it yet.
In case not everyone has this background, Rich Hickey has ranted a bit against semantic versioning: https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/Spec_ulation.md
And looking at that transcript, apparently there was already version 2.0.0 of semver in 2016.