Clojure Q&A - Recent questions tagged design

Clojure and Clojurescript as options for an Electronic Health Record project

Sat, 19 Feb 2022 16:09:36 +0000

I am the founder of a company that is building a next-generation Electronic Health Record system. The software will have both web and mobile UIs and make heavy use of bleeding-edge Natural Language Understanding and Artificial Intelligence.

I am exploring programming language options and am very interested in Clojure because of its functional language paradigm, robust support for concurrency, and reputation for high expressivity, among other things.

I am seeking input about the major pros and cons for this kind of project.

My company website is https://mpathysoftware.com/

Thank you!

design considerations for extracting values from properties file

Wed, 01 Dec 2021 21:07:31 +0000

Description

Hi everyone! I've got a Spring Boot config file I'm parsing. Values don't really matter:

server.port: 8000
spring.application.name: some application
spring.datasource.driver-class-name: org.whatever.Driver
spring.datasource.password: some_password
spring.datasource.platform: postgres
spring.datasource.url: jdbc:postgresql:does_not_matter
spring.datasource.username: some_username
spring.jpa.database: POSTGRESQL
some.service.endpoint: http://whatever
some.other.service.endpoint: http://something_else

I'm trying to extract / group different parts of that file, and I'm looking for what the suggested / idiomatic way of doing this is. I'm trying to follow the "data > functions > macros" idiom and the "better 100 functions for one data structure".

Specifically, I'm looking to parse / group the web endpoints, and then the database properties, in order to validate them using some business logic.

I've already parsed the file using java.util.Properties, so that's not of interest here. The file above is converted to a map.

Solution 1

Create a separate function for each "grouping" I want that parses what I want and returns a new map with just the data I want.

defn get-endpoints [props] returns

{
    "some.service.endpoint" "http://whatever",
    "some.other.service.endpoint" "http://something_else"
}

defn get-database-properties [props] etc.

Solution 2

Add additional keys to the original map to group what I want.

defn parse-groupings [props] returns

    {
        "server.port" "8000",
        "spring.application.name" "some application",
        "spring.datasource.driver-class-name" "org.whatever.Driver",
        ;; the rest of the original properties
       :groupings {
            :web-endpoints {
               ;; web endpoints go here
           },
           :database-props {
             ;; database properties get embedded here
           }

    }

Solution ???

There's a lot more solutions, of course, but I'm wondering what the community recommends.

Thank you!

What would transducers-first Clojure look like?

Sat, 02 Oct 2021 19:32:19 +0000

Rich says in the History of Clojure:

I think transducers are a fundamental primitive that decouples critical logic from list/sequence processing and construction, and if I had Clojure to do all over I would put them at the bottom.

This fascinates me, and I am really curious what would transducers-first Clojure look like? I don't really expect Rich to answer here (I should have asked this at his HOPL talk...) but perhaps someone who is closer to core might have some insight.

I would love to see a Clojure where transducers are the default and easiest way to solve things, where all the tutorials and gists and example code everywhere around would be using them and a context (vector, lazy, first etc.) was only chosen at the edges. Currently it is easier (but perhaps not simpler) to write lazy code than transducing code.

I am wondering if transducers-first Clojure would address the above or would it mostly be about the plumbing behind a clojure.core similar to the current one.

For my personal case, I actively have to fight laziness - I don't think I encountered a single place in our codebase where it would be beneficial but as it's still the easiest way of writing clojure I have to put in extra effort to not accidentally venture over to lazy land and to spot these patterns in PRs of others.

I would love a clojure.core2 where transducers are the default, it's easy to write transducing code, potentially with less typing/ceremonies, the likes of comp and into [] etc. And stepping over to lazy land is always an opt-in thing, like the impure parts of clojure - stm, transients etc. I'm not entirely sure how a core library like that would look but it's something I'd love to try.

Moreover, there are some transducer-specific optimisations like https://github.com/cgrand/xforms#on-key-value-pairs that could be considered. And perhaps there could also be a way to use the multiple-coll arities of map as part of a transducer somehow.

There could also be more baked-in support for an xform arg in functions that currently take a coll to preprocess them, like run! and str/join - if you actively use transducers you start to notice things like 'hey, I don't even need a collection there' and start to look for different transducing contexts - so instead of (count (into [] xform input)) you'd go (x/count xform input)

Function calls to generate docstrings?

Wed, 10 Feb 2021 05:36:58 +0000

I was curious if a function could be defined like the following:

(defn my-cli-func
  (docstr 
    :description "Some CLI function with complex args to do something cool"
    [["-p" "--port" :port "Port to listen for connections on"]])
  [args]
  "...")

The intention is that docstr could generate a docstring in a consistent format I can validate and such. That did not work as I get an error about where the Parameter declaration should be.

I'm guessing it could be done with a defn wrapper macro but probably not worth the hassle right now.

I was curious if there was a design decision to not allow meta programming there or if it's some kind of mechanical restriction due to the implementation.

Was auto-currying ever a consideration early in Clojure's design\development?

Fri, 09 Aug 2019 22:49:08 +0000

A question popped into my head today: Was auto-currying ever on the table for Clojure's design or implementation?

Let's say you have:

(defn add [x y] (+ x y))

(map (add 2) [1 2 3 4 5])

If Clojure auto-curried, that would result in [3 4 5 6 7] but currently it results in an error due to arity mismatch. To me, I feel that behavior would be more productive than an error. So I'm curious about why such a feature was deliberately avoided if it was ever on the table.

Clojure for Ecommerce platform?

Sat, 27 Jul 2019 09:49:24 +0000

We are trying to build a Ecommerce website using Clojure and ClojureScript. There are bunch of libraries and frameworks available to use, is there any recommendations for the libraries and framework to be use?

What is an opensource clojure project you like for its architecture, design choices?

Fri, 26 Jul 2019 12:13:32 +0000

What is an opensource clojure project you like for its architecture, design choices?

Can you explain why in abstract manner and perhaps give some links pointing to code?

It could be also something on the component level, like you used a channel or a clever clojure datastructure for solving a problem