Fork me on GitHub
quan xing02:08:37

In the next.jdbc I use jdbc/with-logging output: next.jdbc/execute-one! ["UPDATE bz_project SET sgt_review_no = ? WHERE ID=?" "A001" 100] is it can output the full SQL directly? like this : ["UPDATE bz_project SET sgt_review_no = "A001" WHERE ID=100"


Doesn't exist, so cannot be logged


next.jdbc never constructs a strong like that, the sql and the parameters get turned into a java.sql.PreparedStatement, which is handled internally in the jdbc driver for the database you use


And there is a good chance the jdbc driver you use doesn't construct such a string either, since databases often have some kind of prepared query with parameters feature in their wire protocol


@U025AG2H55F Per the docs the logging function is passed two arguments: a symbol indicating the operation and the vector containing the string and arguments. Your logging function can do whatever you want with those two things, but to produce inline SQL from parameterized SQL you would have to take care of that inlining yourself.

quan xing03:08:22

Ok, I got it. thanks. I can use honeysql with {:inline true} so I don't have to take care of that inlining myself.

Pedja Zolinsky15:08:15

What is the go-to IDE/ local dev setup for Clojure devs? I am seeing the Emacs, but as someone who exclusively uses the VIM, it just feels wrong


#vim is fine. Emacs is favored - I think - because it's written in a lisp. Calva, Cursive, and IntelliJ are also popular options. For vim, you might want to check out


I use nvim exclusively too and neovim + or vim + worked fairly well for me

πŸ‘† 1

There's a whole bunch of options. If you're a Vim user, you might be interested in,, or, for example.


I use vim + conjure + coc + clojure-lsp. It's a very workable solution. I live in vim all day πŸ™‚


Here's my vim config, it may be helpful (it may not!) πŸ™‚

Ben Sless16:08:44

Emacs has a great vim implementation called Evil πŸ™‚

πŸ’― 3

personal preferences imho. emacs is popular among Clojure devs purely because of historical reasons (inferior-lisp mode from the box, cider recently celebrated 10th anniversary, etc.) now there are plugins for almost every popular editor and they all very good for day to day work. just peek the one you know the most

πŸ‘ 2
Kelsey Sorrels16:08:01

Vim & Clojure user here. As long as I have rainbow parens, I'm a happy camper :)


VSCode with #calva is also great. Very easy to set up / get started with. REPL-driven workflows in clojure stand out compared to typical development in other languages, so the monolithic Calva experience might be nice to compare with an a la carte Vim setup.

☝️ 1

I'm not sure of the extensibility of other editors, but on Emacs, in a few lines of code I was able to add a feature I wanted to the clojure mode (CIDER) that would let me put a cursor over a function, press a hotkey, and be prompted for input args to execute the function with (as opposed to hard coding a temporary function call or typing the function name in the REPL) - this isn't something special with clojure, its just how Emacs works (you want it to run some custom code/logic that isn't in an existing package, you can just whip it up) - and the things you may enjoy with clojure (an iterative REPL approach) is exactly how you develop for Emacs (as opposed to writing some ugly vim macro language commands, or some external JS package that you then have to install in your non-emacs editor)


My recommendation to Clojure beginners is to always start with the editor you're already most comfortable with, as long as it has a Clojure integration that allows you to eval code from the editor into a connected REPL so that you can experience the iterative, incremental workflow that makes Clojure pretty unique. Trying to lean Emacs at the same time as Clojure is likely to be a frustrating experience. Stick to your "home" editor, learn how its Clojure integration works and once you're comfortable with that workflow, then maybe take a look at other editors. You can see the spread of editor usage over time here and you can see that as the community has grown, Emacs has dropped from about 50% to about 40% usage -- still the most widely-used -- with IntelliJ/Cursive steady at 30% and VS Code/Calva growing from 10% to about 20%. vim has remained steady at about 10%. There are channels here dedicated to each of the editors/plugins so you'll be able to get help no matter which you end up choosing @U03P01XST0W

thanks3 2
πŸ™Œ 1

There's no go-to, community is quite split. That's mostly because almost all editors have a very good Clojure story currently. You can get most features in Emacs, Vim, VSCode, IntelliJ, Sublime, etc. I think there's even someone who make a decent Notepad++ Clojure plugin. So really use what you want.


Does clojure have any date/time stuff in its core library, or is it all calls out to java? Where does one start with date & time if we don't know java already? There seems to be some change or updates when googling


juxt/tick is pretty good


built into the jvm is java time. An hour reading the docs and then using these native classes will save you a lot of headache

πŸ‘ 2

if you use java Time, be sure to note down how to do Date/Instance conversions


Thanks! Gonna be doing some work with the jira API and cycletimes, so converting from strings and doing math. Man I hate dealing with dates and times! πŸ˜„

Mario Trost19:08:28

I just researched a little bit this weekend and found this:

Mario Trost19:08:44

Perhaps it’s helpful

Daniel Craig05:08:30

avoid java.util.Date at all costs. Use java.time πŸ™‚


Hi, I am writting a toy programming language using clojure. I am writting some code for the tokenizing/lexing phase but I feel is not the best it can be but also I don't know how to make it more idiomatic. I basically have vector of tokens regex and I want to match it against the "source code" once I find one I want to return such token. The code currently looks like this

(def tokens-tys                                                                     
  [[:fun #"^\bfun\b"]                                                               
   [:ident #"^\b[a-zA-Z]+\b"]                                                       
   [:opar #"^\("]                                                                   
   [:cpar #"^\)"]                                                                   
   [:arrow #"^=>"]])                                                                
(defn next-token [code]                                                             
  (loop [tokens tokens-tys]                                                         
    (let [[ty re] (first tokens)                                                    
          matched (re-find re code)                                                 
          next-tokens (next tokens)]                                                
      (if matched                                                                   
        [ty matched]                                                                
        (if (empty? next-tokens) [:error "no token"] (recur next-tokens))))))
Then I try to accumulate all the token in a single vector, and thisi s the part of the code I am less happy about
(defn tokenize [code]                                                               
  (loop [tokens []                                                                  
         code code]                                                                 
    (if (s/blank? code)                                                             
      (let [[ty lexeme] (next-token code)                                           
            tokens (conj tokens [ty lexeme])]                                       
        (if (= :error ty)                                                       
          (recur (conj tokens [ty lexeme]) (s/trim #dbg (subs code (count lexeme)))))))))


would highly recommend instaparse


parsing the output of instaparse with core.match is very nice too. instaparse has it's own issues to deal with, but i think it's a lot more maintainable than using regex.


also, if you just want people to pick apart your code, you have to say why you are unhappy about it. people who use clojure for their job are used to looking at code that is very messy. your code doesn't look like it is going to be hard to debug.


the only suggestion i can make is, probably don't use subs, make your own that doesn't throw when given bad args


your tokenize function doesn't look like it should compile. lexeme is out of scope. actually that's just because my screen word wrapped the code. nvm.


with some rewriting you may be able to do something like (map :token (iterate tokenize {:token nil :code code}))


e.g. make not loop and instead take and return {:token token :code rest-of-code}


@U0NCTKEV8 iterate magic... i need to use that more often. however language parsers generate trees, do you think that iterate would also work in that scenario? like the tokenize function would have an iterate inside it as well.


tokenize doesn't generate trees


it generates tokens, the parser will look at tokens and build a tree


yeah I am not building the AST yet, just tokenizing. will take a look at iterate. Yeah I am aware of instaparse, but I want to do it without external libs as much as possible, just for learning.


ok, i got that messed up. more general idea is if people use iterate to generate trees


in theory you can, it isn't as elegant because iterate returns a seq of values, so each result would have a partial tree that the next result expands


which really only makes sense for LR (bottom up) parsing


where most people do LL I think


@UCDGC44GP i know the feeling, i tried something like this as well, and after making almost no progress i used instaparse and had a lot of fun learning to write grammars and building something useful after many attempts to make a grammar not ambiguous. highly recommend if you like playing with regex, cus you basically get a language where all your vars are regex bits


What I don't like about the code is that it has a many nested if expressions. which I feel should be simplified. Also I tend to use let alot because I am used to introduce variables in other languages, but I feel there should be a better way in clojure


probably defining my process using a thread macro and a bunch of small functions or something like that.


@UCDGC44GP to deal with nested ifs, i use cond/case, if cond looks ugly then i try core.match


but could come up with something myself


core.match is good if you don't care about speed, and care that your code is self documenting


i like code that has a lot of lets over code that has a lot of nested logic


you can use if-let and when-let some-let sometimes they make code a bit better


for your code, you could make your lets top level, and use cond instead of nested ifs, it means you do logic before your if, but it's not much


(empty? next-token) replace with (not-empty next-token)


that way you can just test next-token, as not-empty returns nil when empty


i always prefer not-empty


(not-empty (next tokens))


next will also return nil, wont it?


empty? is redundant


(defn tokenize [code]
  (loop [tokens []
         code   code]
    (let [[ty lexeme] (next-token code)
          tokens                          (conj tokens [ty lexeme])
          next-code                       (s/trim (subs code (count lexeme)))
          next-tokens                     (conj tokens [ty lexeme])]
        (s/blank? code) tokens
        (= ty :error)   tokens
        :else           (recur next-tokens next-code)))))

❀️ 1

my preference is to not do a bunch of logic in my return val, i sorta care about it's shape, or having control flow be self documenting. so i do all my logic in my let. it also means that debugging is pretty easy


because clojure is mostly lazy, it's ok to do expensive stuff in the lets, as the control flow determines what code gets run


but it means you need to figure out names for somewhat meaningless things. depends on the situation

Toni Vanhala05:08:33

Instaparse is a great suggestion. If you want to do this the hard way, building a tokenizer from scratch, you could follow the book (free html version) The book uses Java, though. I've worked on implementing the first parts in Clojure:


I have implemented many tokenizers and parsers from scratch, it's kind of my go to project to try out a language. Was I was trying was to get some ideas in idiomatic clojure. My tokenizer in clojure ended up being very procedural which is what I was trying to avoid, just to get a better understanding of clojure


If you haven't heard of parsec that might be interesting to check out, it is a Haskell parser combinator library (very functional) with some interesting design decisions. I have a toy clojure port (nothing published anywhere) that I've found to be pretty good. A lot of parser combinator libraries try to handle any grammar and have unlimited look ahead, and don't really have the concept of lexing, but parsec by default restricts grammars to ll(1), but for the parsers that parse individual lexemes you mark them as having unlimited look ahead, which makes everything work very similarly to a lexer+parser

hiredman21:08:38 is the original parsec paper, is a blog post that describes replacing a lot monadic case analysis with basically continuations


if you have any recommendation on how can I make it better it is welcome


is there any way to get weavejester/hashp to not sort map keys alphabetically? I'd like them printed in the same order as something like clojure.pprint does


(untested) (alter-var-root #'puget.printer/*options* dissoc :sort-keys)


If a function is defined in both clj and cljs in a library (not just as cljc), are there any safe assumptions you can make about it? Should they be considered roughly equivalent or treated as totally separate?


I would check the library's docs, then its source code. I wouldn't assume equivalency unless the docs explicitly say that somewhere.


(but I wouldn't start with the source so if the docs say (foo x) behaves in a particular way -- and the library indicates it's both clj and cljs compatible -- and there are no caveats about foo's behavior across platforms, I probably wouldn't even think to check whether foo is defined in clj, cljs, or cljc)


@U04V70XH6 interesting. It sounds like the safe approach is to always check, but in practice it matters less so. Thanks for your input.