How do I sort a list based on an ordered sequence. For example [:low :medium :high], I want my list sorted so lows are first highs are last.

You turn the vector into a map of element to index, then sort-by with that map

ah so { :low 1 :medium 2 :high 3 }

What the problem with my standalone jar?

Error: Could not find or load main class 
Caused by: java.lang.ClassNotFoundException: 

the message is telling you that the jar does not contain genomics/app.class

you can see inside the jar with jar tf whatever.jar - probably good to see what it includes

you might need to add (:gen-class) to that namespace and aot compile it

Yes. Guess that's the problem. Where should I put it?

(ns 
  (:require [genomics.gui :as gui]
            [cljfx.api :as fx]))

before :require?

I added :gen-class but it still shows the same exception

can be either before or after require

and then you need to make sure you aot compile the code

if you're using leiningen, adding :aot :all should do it

It's not helping. Lein just hangs. It's probably libriary-specific problem. I asked in #cljfx but still no answer

if it's hanging, what's probably happening is that you have top-level defs in your code that are being run during compilation

which is generally a bad idea

but that's what I'd look for

I don't know what's ment by "top-level expression". Why it runs in lein run?

perfectly

Hi all! There is a rather small Website I wanted to try Clojure on but got stuck early. I use the Luminus Template with HugSQL for it - the database behind is (must be) MySQL I will need all text of the entities to be multi-lingual and wondered what would be the best way to treat it with HugSQL. One way would be to write out the table-spanning multi-lingual queries for every entity but that would kind of be a huge verbose bunch of SQL. I wondered if someone already made a good setup / has some ideas for how to structure those queries with HugSQL. I'm using a single translation table together with a single language table but I'd be happy to change the table layout if it makes the usage better

Hey team, curious question for you: What is clojure’s thought on “data abstraction”, as in: say you use a map to represent some data-structure — user You would use functions to operate on the user data structure like (name user) (address user) , rather then keying directly: (:name user). The main reason being: could change the underlying implementation of user (i.e from map to list or something) (I see this pattern a lot in the older lisps: norvig talked about it paradigms of ai programming, and sicp mentions it) I see the benefit, but at least for clojure some of these function seem unnecessary. What is the clojurists way when it comes to this?

the whole benefit of maps and being able to use keywords as functions directly is that we don't need to make another layer, so my pov is that that kind of "abstraction" is not abstraction, it's indirection and it's downsides are bigger than its benefits

don't make functions that duplicate what you already have

We've used it at work only where we are migrating from mixed case keys to lowercase keys or to namespace-qualified keys and some code has to be able to hand "both" while we are transitioning, but I would not recommend it as a normal mode of operation.

The distinction that Clojure makes between a string — "A" — and a literal character — \A — is pretty awesome. This seems useful.

@stopachka The function (:foo m) is already a data abstraction, because it is implemented not for PersistentMap, but for anything that implements ILookup. And Associative implements ILookup, and that's also an abstraction which PersistentMap implements. So you have 2 layers of data asbtraction happening when you call (:foo m) already 😛

Gotcha, thanks for the clarity folks!

Ya, it means in theory, you could create a new data-structure and have keyword as function work on them to retrieve some associated value. Though since Clojure is implemented in terms of Java interfaces and not Clojure Protocol, you cannot extend it yourself, you need to modify the source code of the data-structure itself, so you can't for example add support for it to PersistentLists or sets or strings, etc.

https://github.com/arohner/clj-wallhack/blob/master/src/wall/hack.clj#L38-L55 is an example of a custom ILookup

But I think fundamentally, what you're reading about data abstraction has some other concept in it which is kind of different, which implies creating custom user defined types, such as a User type. This gets complicated, and I don't know if I should venture about this in "beginner" but here goes 😛 {:name "John" :email ""} is a Map which contains information about a user. We did not create a "User" abstraction here. We just put information about some user in an existing reusable abstraction called a Map. This means that if you want to manipulate the information about the user, you can use all the existing Map functions to do so. You do not need any new functions. This is a common pattern in Clojure. We commit to the way we decided to represent information and just choose to use this directly. It does mean that if you decide to represent the information in a different way later, you break all usage of it. So if you change :name to :first-name you broke a bunch of code. Similarly, if you choose to change the model to a list like so: [:user "John" :email ""] you also broke all the code that was using the map directly. You can decide yourself if you mind this possibility or don't care. I think most people in Clojure wouldn't care, because in practice, you almost never change the structure 😛 So you can think of it as, maybe it takes you a little longer to refactor in the rare case you would need to change it, but you saved yourself a bunch of time not bothering with some half-baked User abstraction that most of the time will just be more inconvenient to work with than a Map/List/Set would be. In a language with mutable data-structures this would be a huge risk! Because you need to protect the usage of the data from uncoordinated concurrent modification. So when data is mutable, you would definitely want to protect access behind a function. And Clojure enforces that if you create a deftype for example, which provide mutable structures, like it forces you to always have data accessors and prevents you from changing the mutable data directly. Even with simple structure, like a single mutable field, Clojure forces you to use some data abstraction to change it like with atom where you can only do atomic changes to it.