Fork me on GitHub

I wrote depstar, let me know if you need help with it


I'm looking at which seems to imply that doesn't work in cljs. Why is that?


This video showcases an IDE for building games. The editor is a desktop app built with Clojure and JavaFX.


@U06BLR1C6 any reason why it's free but not open source 🙂


@U06BE1L6T I was thinking the same think.


It would have been awesome if we could program in clojure/script in it instead of lua.


AFAIK the plan is to open source the editor once it's out of beta.


The editor itself can be extended with Clojure. Lua is for the games.


Lua is more popular within gamedev, so is a smart choice to include it in this engine


almost makes you want to switch careers and start developing games...that is one cool editor


(Some of you might have seen the Conj talk I did a couple of years ago... This is the same editor but more complete. It's got a debugger now!)


@qqq Because Hiccup is written in .clj only?


@seancorfield: is there some fundamental reason that prevents all the .clj to be renamed .cljc and have it work in cljs too ?


I can't imagine any JVM specific things involved in "clojure data -> html sstring"


@qqq I'd say feel free to fork it, make those changes, and send a PR.


@weavejester: We were just discussing why hiccup was .clj instead of .cljc -- is there a fundamental limitation forcing it to be *.clj, or is it just most of the time, in cljs mode, people want dom nodes, not string representing html ?


@qqq my guess is he never felt the need to port it to cljs, and probably has some optimizations in place that make it difficult to port parts of the code over. It would be interesting to see it ported, since people might take more of an interest in using cljs for more backend stuff


I wonder how similar hiccups is to it, I believe hiccups was developed well before reader conditionals was a thing


There are something things that work on hiccup, which don't work on hiccups, I think a function to get the classname was one of them.


@qqq Certainly Hiccup long predates .cljc and ClojureScript in general...


The tooling and ecosystem has taken a long time to evolve. I maintain tools.cli and it has a separate .clj and .cljs implementation because it started supporting ClojureScript before Clojure 1.7 and .cljc files. And the Contrib build/CI pipeline didn't support .cljc for a long while.


(and tools.cli still supports back to Clojure 1.2.1 right now)


Looking at Hiccup, it still supports Clojure 1.6 -- it would have to drop that in order to switch to .cljc files.


I went through this with Expectations as well. It used to be .clj only, then moved to .cljx using the third party compile-to-clj-and-cljs plugin, then moved to .cljc...


Thanks @csm -- that certainly shows this is not an easy problem to solve.


Are there any open source web apps in clojure looking for contributors?


help pls 😂


@U61HA86AG Do you think it needs much contribution? It is pretty basic.


well, they are asking 😛


Is there a recommended case for Record keys? camelCase / snake_case / lisp-case?


kebab-case, yeah. Since they'll respond to keyword lookups


can someone remind me of that quote that goes something like “in clojure [lisp?] you write the language that you will write your software in”


Was it "Lisp isn't a language, it's a building material." (Alan Kay as quoted on


no, it was more-or less identical to what’s between the quotes but i cannot remember the source or who said it. that’s a good list of quotes tho, thanks


That sounds like the idea of Paul Graham's On Lisp, which is all about achieving this through macros. I don't know whether that's where your quote came from, though.


Searched through the first few chapters of On Lisp, found many expressions of this idea, none matching close enough to be what you remember.


Also search Seibel’s Practical Common Lisp, Graham’s ANSI Common Lisp, and several of Graham’s essays. Idea appears many times, never clothed exactly like this. Looks like you’re on your own. 😞


I think I saw it in a video somewhere, now that I think about it… yay searching video indexes?


Hmm, a video, eh? It wasn't this one, was it?


this quote is surprisingly hard to google, I tried variants of "lisp dsl quote / building up language" and getting all these blog posts on reader macros / quasi quoting


i couldn’t find it anywhere after 15 minutes of searching, but i know i’ve read it 3-4 times at least


which is the better practice, destructuring in the fn arguments vector or in a let afterwards. Since the arguments appear as is when doing a lookup in an IDE or docs, is it better to show exactly what the function is working with (mainly regarding :keys object destructuring), or just destructure in a let in the body of the function?


from my experience destruct right in the fn args, and prefer maps to positional arguments for easier growth/change, and if you’re exposing the fn to the edges use spec to document


what advantage do you get using a let block immediately as the first form in your fn?


I don't think you do, but I figure it would make reading the args of the function easier, but with spec you're right. I still am not used to the adding spec workflow since it requires some churn when trying things out, so maybe I just need to take that in consideration for documentation


i generally only spec the very edges of a module, or anything that’s exposed externally. to help with the churn make sure you’re REPL-testing as you go, and it will get a lot faster after just a few hours of familiarity


right, I use the repl as my main source of verification and experimentation, which is why I think it's a little staggering to add specs, tests, docs etc. as part of my development workflow, and usually save them for afterwards.


I saw that a while back, before I grokked a lot of clojure concepts, will take another look


@qqq There’s no fundamental restriction, but as you say, it’s more useful to have a DOM in JS rather than a flat string.


Thanks for link