Clojurians Log v2

@valtteri The Project itself is a Colordatabase for painters with features like create your own palette and download a pdf of it and if possible current prices in the most known shops. Maybe Clojure is overkill for such a small need?

@sova Since i basically would start from almost 0 prior programming (besides elisp) i would prefer some leads and templates, luminus looking promising, Got both "frameworks" saved for later when i know a little more clojure

Is there a commonly accepted way to structure ”large” programs with multiple namespaces etc? Is there documentation/guides? :)

I don't think there's a generally applicable way, no. I have my own pattern for web apps and try to split namespaces/folders by areas of responsibility in general. Here some examples: • a smallish library https://github.com/valerauko/vuk • a smallish website (actually the first clojure one i ever made) https://github.com/valerauko/books • a way bigger service https://github.com/valerauko/kitsune I hope you can use these for reference. (All are using leiningen so source code lives in src.) If you have questions ask away!

Okay, thanks :)

A weekend of Clojure and i feel very overwhelmed still dont know how to create a working programm even if its only say hello and work as a very unnecessary calculator 😄 I am reading the "brave Clojure" book. are there more practical examples out there?

Hi @thomasfuston do you have a REPL working? Since you say you are using Brave Clojure, I presume you have lein installed? If so, does lein repl give you a usable REPL? Just trying to figure out where you are in your journey.

At work, we have over 100K lines of Clojure, stretching back across a decade. We were all learning in the beginning so we hadn't really figured structure. Over time, our code organization has changed -- which means, unfortunately, the various apps in our code base are not very consistent, and as we continue to add functionality, we are constantly refactoring, and trying to improve the structure.

Is there an integer division function in Clojure that truncates towards negative infinity (rather than towards zero, as quot does)?

I found a StackOverflow question via a quick Google search that links to this Java method that may be of use to you: https://docs.oracle.com/javase/8/docs/api/java/lang/Math.html#floorDiv-int-int-

Google search terms I tried: java division round to negative infinity

StackOverflow question found early in search results: https://stackoverflow.com/questions/37308248/java-integer-division-doesnt-give-floor-for-negative-numbers

I am not aware of anything built into Clojure that does what you wish.

Awesome thanks, I’ll take a look… I didn’t think to look at Java 🙂

I believe that Java's integer division also rounds towards 0, which might be the reason that Clojure's quot does so.

Even in Java, it's a fair bit of work, depending on whether you need it to work with long as well as int.

(based on that same SO answer that Andy found)

There is also a variant of the floorDiv method that takes primitive long args instead of int: https://docs.oracle.com/javase/8/docs/api/java/lang/Math.html#floorDiv-long-long-

Well the best I could come up with prior to asking here was (int (Math/floor (/ x y))) … floorDiv feels marginally less painful 🙂

I would guess there are versions for float and double args, too.

🙂

The Java math libs are pretty extensive, even the stuff that comes with every JDK without requiring a separate Java lib. If you go for 3rd party Java libs, it gets even more huge.

Many thanks for the help… I really appreciate it 🙂

Thanks @seancorfield 🙂 Yeah, I’ve been doing “hexagonal design”/DDD in other languages, I guess that could work in Clojure as well.

@thomasfuston I had the same problems initially, and it turns out that my initial idea "I'll learn the basic Clojure stuff and jump directly in trying to create a CRUD App" did not work at all. It takes some time to learn the language itself and the best baby step after figuring out the basics is to implement "data" only programs (such as algorithms and stuff) to get acquainted with the collection library. Once you're there, you'll likely understand what more and be able to write a web app with Pedestal for example. Ultimately, although the Clojure for the brave is a good book, it did not help me that much. What really helped me was this video: https://www.youtube.com/watch?v=P76Vbsk_3J0 I hope that's gonna help in your journey! 🙂

I'm coming to Clojure from Django where I've learned to love the ORM. What is the recommended approach for using SQL in Clojure? Is something like Toucan the right place to start? https://github.com/metabase/toucan

@randumbo Since we don't have objects, we tend not to use any sort of ORM in Clojure.

https://github.com/seancorfield/next-jdbc is the best JDBC wrapper to start with. You'll see https://github.com/clojure/java.jdbc in a lot of books/tutorials (which I also maintain), but that isn't getting updates any more.

There's a #sql channel where you can ask SQL/JDBC-related questions. If you want to work with SQL in .sql files, take a look at HugSQL (which also works with next.jdbc and clojure.java.jdbc). If you want a DSL to programmatically build SQL from data structures, take a look at HoneySQL. There are #hugsql and #honeysql channels for those too.

I don't believe there is a single approach (no sliver bullet... and why would there be?) https://github.com/seancorfield/next-jdbc - if you want to use SQL code https://github.com/seancorfield/honeysql - if you want to write Clojure data structures rather than SQL https://www.hugsql.org/ - aims to make a clean separation between Clojure and SQL code. An toucan is already mentioned in your question. which as is says is as close as it gets to ORM without the O

Which approach would you recommend, of those two?

@jr0cket You shouldn't really recommend clojure.java.jdbc these days. I'm not updating it any more.

pasted the wrong link...

At work, we use HoneySQL very heavily because we have a lot of complex queries that are built programmatically.

Some people like to keep all their SQL in separate .sql files which is why I mentioned HugSQL.

Do those tools have protections against low-level stuff like injection attacks?

Yes.

What are your thoughts on Toucan? It says it's built on HoneySQL, although still seems to use clojure.java.jdbc.

I think it adds a layer of unnecessary complexity, personally.

Understood. I get the sense that it's against the Clojure way.

I'd definitely recommend starting with basic libraries so you understand what's going on and then composing the libraries you like best. Choose simple over easy.

Looking at HugSQL, it's a bit concerning that it doesn't look like it's actively maintained. Last commit was Sept. 30, 2019.

I've worked with a lot of ORMs in other languages -- dating back to full-on object databases in the '90s -- and I much prefer Clojure's approach.

Thanks @jr0cket.

@randumbo You'll get used to a lot of Clojure libraries seeming to be "unmaintained" -- Clojure favors small, composable libraries, that tackle one problem and therefore can often be "done".

Backward compatibility is also very important in Clojure, so don't be put off by pre-1.0 versions, or things seeming to stay alpha for a long time 🙂

heh, I've read that in many places, but I still find it kinda hard to believe.

At work, we started with Clojure 1.3 and went to production on alpha 7 or 8. We've run pretty much every release of Clojure in production in alpha versions. Stability is important in the Clojure world.

If I don't need complex queries for now, would HugSQL be a better choice for the time being?

(we're running Clojure 1.10.2-alpha2 in production right now with 1.10.2-alpha3 in QA and 1.10.2-alpha4 in dev)

Start with just next.jdbc and see how you get on.

If you decide you prefer your SQL in external files, then take a look at HugSQL.

It's not an approach I like, so it's not really my place to recommend you do or don't use it.

Going to have to brush up on my SQL a bit. Been a while since I've written raw SQL.

For simple CRUD, you won't need it: next.jdbc (and clojure.java.jdbc) can save hash maps to tables without SQL and read them back.

I'll do so anyway, but that's good to hear.

(next.jdbc.sql/insert! ds :table {:name "Sean" :country "USA"}) for example

(next.jdbc.sql/get-by-id ds :table 123) (defaults to using :id but you can override that) -- returns a single hash map

(next.jdbc.sql/find-by-keys ds :table {:country "USA"}) returns a vector of hash maps for everyone WHERE country = ? and "USA" as that parameter.

Looks pretty straight forward indeed. Thanks @seancorfield, I'm going to work on integrating that into my Fulcro project on the backend.