Your namespace is requiring guestbook.core -- but is ClojureScript and guestbook.core is Clojure, based on the extensions.

If both src/clj and src/cljs are on your classpath, you can't have the same named file in two places -- only one of them will be found.

So it's finding src/clj/guestbook/core.clj

ClojureScript apps do tend to have .clj files in them for macros (since ClojureScript relies on Clojure for macro definition and expansion, prior to compilation -- to JavaScript).

thanks. just tried renaming the cljs file and ns, but it’s still not finding it..must be something else im not seeing

Are you getting that same error, or a different one?

The error above is that it is finding guestbook.core but it's expecting a .cljc or .cljs extension on it.

oof…i was missing :source-paths [..., "src/cljs"] in my project.clj … build completed now with the original filenames maintained, there’s a core.clj and a core.cljs using the same ns in the project. Not sure if i’ll run into issues down the line…

i was using lein cljsbuild previously, and removed that config entirely which had its own source path prop

Glad you got it working, and thank you for reporting back with the solution!

Thanks I will try it.

(spit (get-seed-file-name name) "")

It's a built-in version of the code you posted:

user=> (source spit)
(defn spit
  "Opposite of slurp.  Opens f with writer, writes content, then
  closes f. Options passed to ."
  {:added "1.2"}
  [f content & options]
  (with-open [^java.io.Writer w (apply jio/writer f options)]
    (.write w (str content))))
nil
user=> 

Now I see the source, I guess you could even do (spit (get-seed-file-name name) nil) which might be more explicit?

Since (str nil) is ""

Thanks @seancorfield it worked like a charm

I wish we had a karma coin, so that I could give some to you. 🙂

(.createNewFile (io/file "bob"))

read javadocs for File and there's something that could help right away

Also, what do you want to happen if the file already exists?

Just error out.

(spit ... nil) will overwrite it with an empty string; (spit ... nil :append true) would append an empty string to an existing file (i.e., leave it unchanged apart from the mod date/time).

I suspect .createNewFile would error out if it already exists

Ah, no, it would just return false

(and it returns true if it successfully creates the file)

io/file is very confusing. I am using following code to list the files in a directory.

(->> (io/file "resources/seeds")
      (.list))

user=> (.createNewFile ( "/tmp/foo"))
true ; file did not exist, this created it
user=> (.createNewFile ( "/tmp/foo"))
false ; file existed so it was not touched
user=> 

io/file creates a .File object so you'll have to read the Java API docs for that.

But it's basically an abstraction for a file.

So it can be a file that doesn't exist, a directory, a file that does exist, or any implementation of something that can behave like a file.

hmm got it

For my use case I will use (.createNewFile

Java has dramatically improved its support for file ops in more recent versions, so now there's a java.nio.* package hierarchy with abstractions for paths and files and entire file systems 🙂

Clojure pretty much just delegates to Java interop for file stuff.

Yeah I can see that. I think clojure's biggest weakness is its error messages.

Most of the time the relevant files are buried somewhere in the middle of stack trace.

@suren You get used to reading (Java) stack traces but they can be daunting at first.

Yeah too much noise in the stack traces.

@U06FM9QN9 both are definitely for serious projects. I would go with ring/reitit but it’s because I’m more familiar with it and my colleagues are more inclined to it. I’d still go through both documentations and decide which is more to your liking. Also reitit comes with swagger support out of the box but that functionality is easily available for pedestal as well so they’re not too far apart. I’m still very much a clojure beginner so somebody with actual production experience with both should chime in.

I would check the reitit faq for some explanation of the differences https://github.com/metosin/reitit/blob/master/doc/faq.md

like if? (if x 1 0)

Yea, but the other way around 🙂

Oh nvm 😄

Thank you

({true 1 false 0} x)

Maybe you want a default result:

(defn judge [x] 
  (get {true 1 false 0} x -1))

maps have the same interface as get) ({true 1 false 0} x -1) also will give you default value

Thank you @U04V4KLKC, I have read from somewhere that only get can append a default value.

What did you try? Here's an example:

user=> (doseq [x (range 5)] (prn x))
0
1
2
3
4
nil

(doseq [operations chunks]
      (http/post
        (str (env :es-host) "/_bulk")
        {:body (str (string/join \newline operations) \newline)
         :content-type :json})
      (println "Inserted " (count operations)))

where chunks is

(->> documents
                    (map #(str (json/write-str {:index {:_index collection-name
                                                        :_id (get % id-key)}})
                               \newline
                               (json/write-str %)))
                    (partition-all max-chunk-size))

I don't see anything that's wrong. Do you observe your (println "Inserted " (count operations)) output?

> anyway in my case I can take advantage of parallelism so ended up using `pmap` and `dorun` Looks like you worked it out!

it depends on what you're trying to model so you may need to provide more context for a better answer. if you have getters that are simply just wrappers around specific keys, then they add a layer of indirection for little value. instead of getters/wrappers, it's may be worth creating protocols or multimethods that can provide an interface to your data model eg:

(defprotocol IShape
  (area [this])
  (perimeter [this]))

(defrecord Circle [r]
  IShape
  (area [this] (* Math/PI r r))
  (perimeter [this] (* 2 Math/PI r)))

(defrecord Square [l]
  IShape
  (area [this] (* l l))
  (perimeter [this] (* l 4)))

(area (->Circle 2))
(perimeter (->Square 4))

Thanks. Thing is, i don't really need polymorphism here. Just some sort of accessors to set and get fields while hiding the implementation.

protocols are the way to separate what from how (ie. hiding the implementation)

ok. what about accessors? the setters

how to set stuff.

(defprotocol IShape
  (area [this])
  (perimeter [this]))

(defprotocol IScale
  (scale [this s]))

(defrecord Circle [r]
  IShape
  (area [this] (* Math/PI r r))
  (perimeter [this] (* 2 Math/PI r))
  IScale
  (scale [this s] (->Circle (* r s))))

(defrecord Square [l]
  IShape
  (area [this] (* l l))
  (perimeter [this] (* l 4))
  IScale
  (scale [this s] (->Square (* l s))))

(area (->Circle 2))
(perimeter (->Square 4))
(scale (->Square 2) 2) 

see IScale

the idea is to have a stable interface that's independent of the implementation. it can be worth it even in cases where there's just one implementation.

I see. This forces me to declare a record even though i only have a single record type. That is, no square, just a circle.

ah ok

besides using protocols and records, is there another way to implement updaters?

one of the biggest improvements is just spending time thinking about what the stable interface should be

as for updaters, the answer is always "it depends" 😛 . you can also use multimethods

can you show an example?

my main concern is hiding the internal fields e.g. :field-a :field-b

i guess my question for you is what happens if you want to change :field-a?

nothing complex. just set the field. i just don't think it's a good idea to expose the field name, the key

do you change

(defn my-model->b [m] (:b m)

(defn my-model->c [m] (:c m)

or do you still have

(defn my-model->b [m] (:c m)

even if i do, just because refactoring tools exist to easily rename functions rather than fields (keys), it makes the job much easier

I think of the big insights I picked up from learning is using clojure is to focus on the data model and work with that directly

rather than focusing on the getters/setters and other functions around the data

there's a bunch of reasons why that mindset works well in the long run compared to the getter/setter approach

ok, so what do i do if i rename a field for example? i have to rename it everywhere i use it, either read or set it

it also breaks backward compatability

that's a good question

i understand your point. but this is the cost

it's the data that really sticks around, not the functions around it

so if you write your data to disk or send it over the network, it's the data that is being sent

so it's really worth trying to get your data model right and thinking about how it might evolve over time

writing getters/setters is convenient in the short term, but it's just kicking the can down the road

> so it's really worth trying to get your data model right and thinking about how it might evolve over time i can't plan 2 years ahead. no matter how hard i try

> plans are useless, but planning is essential

right, you can't predict the future, but that doesn't mean that the decisions you make about your data model won't affect you down the road

ok, i get it

the OO claim is that getters/setters will insulate you from these changes, but in my experience, that is a false promise

there's several reasons against using getters/setters, but as far as isolating you from changing field names, it only helps you within your program. if you write your data to disk or send it over the network, you still have to figure out how to deal with changing field names. further, if you package your code as a library, changing a field name can still break library users when they upgrade

i understand. thank you

also for being patient :)

these are all good questions

i don't think i'm explaining this alternate approach all that well

btw, this guy says something along your lines: https://clojureverse.org/t/do-you-encapsulate-domain-entity-maps/6147/5

I'm not generally against having helper functions that provide a way to explicitly list what the common operations are, but I would warn against pretending that it "encapsulates" your data. I also wouldn't start with defining getters/setters and would only consider adding them on a case by case basis. In my experience, getters/setters provide little benefit for data at rest or being sent over the network which is the important part to get right for maintaining long running programs and systems To address "what keys?" and "what entity?", I would just use spec. As he mentions in the talk, it's meant to address these problems. The big difference between spec's approach and defining getters/setters is that spec is data focused and getters/setters are operations focused. The differences between a data specification and an operational specification are really critical. Most programs would be better served by focusing on the data than on the operations. Depending on your domain, it may be useful to use something like specter or getters/setters to help declutter deeply nested code. In my experience, there are many domains where an extra layer of abstraction is unnecessary. I really wish computer science would be renamed data-ology.

i think this is an interesting discussion. i don't have anything to add except to note that re-frame basically has getters and setters on a big map (`app-db`) in the form of subscriptions and events. for a while i really felt like i was back in oop land, writing a getter and setter for each piece of data in app-db. in that context, i do think there's something to be said for separating out the data from "exactly where in this huge nested map does it belong"

i've run into many snags trying to reorganize the structure of app-db and unknowingly breaking code that depended on that exact configuration

I think if you're running into "what's the shape of the data supposed to be?", I would reach for spec or defining the data specification rather than getters/setters

it would be great to hear other's thoughts on the subject though

Per the docstring: "Sets ns to the namespace named by the symbol, creating it if needed."

So it will create a completely empty namespace if it doesn't already exist. It won't have any clojure.core functions referred in.

Is there a usecase for that? I'd hate to be derailed by an errant typo

Ahh, hmm so how does it differ from ns then?

ns does a whole bunch of stuff: creates the ns if needed, refer in clojure.core and a bunch of other stuff, requires specified namespaces, imports specified classes, etc.

in-ns is very low-level.

Wait, you meant *ns* right?

I see, I see

I mean the ns macro. Not *ns*. The latter is a dynamic Var.

user=> (in-ns 'foo.bar)
#object[clojure.lang.Namespace 0xdf5f5c0 "foo.bar"]
foo.bar=> (ns-publics *ns*)
Syntax error compiling at (REPL:1:1).
Unable to resolve symbol: ns-publics in this context
foo.bar=> (clojure.core/ns-publics *ns*)
Syntax error compiling at (REPL:1:1).
Unable to resolve symbol: *ns* in this context
foo.bar=> (clojure.core/ns-publics clojure.core/*ns*)
{}
foo.bar=> (clojure.core/ns-refers clojure.core/*ns*)
{}
foo.bar=> (clojure.core/ns-aliases clojure.core/*ns*)
{}
foo.bar=> 

BTW I saw your post earlier this year on whether or not switching to deps.edn is a good idea and it's the main reason I'm trying to do it now. Thanks!

See how I have to specify clojure.core/ in front of various symbol names? Normally -- when you use the ns macro -- those are automatically referred in.

I mean in your first reply, since *ns* appears as ns

Oh, this? Per the docstring: "Sets `*ns*` to the namespace named by the symbol, creating it if needed." Yeah, I just pasted in the docstring and forgot it would auto-format that!

Just checked ClojureDocs, I should probably check it more often. In any case, thanks for the detailed responses! Really starting to get the hang of this thing.

Don't forget you can use doc and source right there in your REPL.

Oh yeah, that's really helpful. Should probably get used to them.

I have doc bound to ctrl-; d and source bound to ctrl-; S in my editor so they are easily available 🙂

(aside from helping beginners with REPL sessions like the above, I never actually type into my REPL -- I always type into a source file, sometimes in a comment form, and then eval code directly into the REPL from the editor)

Note that (java.lang.System/getProperty "java.class.path") returns a string, so (seqing it will return a sequence of characters (which may or may not be what you’re after).

(clojure.string/split (java.lang.System/getProperty "java.class.path") #":") might be more like what you’re after?

yes, i am always surprised at how i mess up data presentation, and splitting on the ";" is just right

No worries - I do it all the time too. I find the REPL and (clojure.pprint/pprint) are my best friends for helping to visualise data. 😉

There are also fancier GUI-based tools that can graphically present Clojure data structures (often integrated with the REPL), but I’ve found (pprint) to be more than enough in most cases.

if you wanted to write a new faq entry for https://github.com/clojure/clojure-site/blob/master/content/guides/faq.adoc, this is a frequent question - I think you've said the critical bits here

Under Reader and Syntax?

"What do ? and ! mean in function names?" perhaps?

(following "What does an _ mean...")

That sounds like a good place for it

Can you say more about it? I think I heard that partial is "better" because it doesn't create a closure. Is #() considered more idiomatic?

Rich is on record (several times) as saying he considers #() to be more idiomatic than partial.

Huh. Thanks, I felt so too initially, actually.

partial definitely does create closures -- look at its source.

Well, I figured it must create at least something equivalent (callable and holding the arguments)

partial creates a closure with multiple arities -- since it doesn't know how many arguments your function takes (so it doesn't know how many are still "missing") so if you have a function that takes four or more arguments, you're going to be running via a variadic function using apply.

If you use #(f arg1 %1 %2) then you get a 2-arity closure and your function f will be directly invoked with three arguments -- so you'll get IDE/linter support on the call of f in terms of validating the arity, and you'll also get runtime arity checking when that closure is called. With partial, you lose any IDE/linter support at the call site when writing the code, and you also defer the runtime arity checking (since you go through another call layer between the source code and the actual call site of your function -- and it might go through apply, pushing the arity checking a little further away from what you wrote. All of which makes errors harder to spot and debug.

Yes, got it, thank you!

FWIW, when I got started with Clojure a decade ago, I was very enamored with comp and partial... but I hardly ever use them nowadays.

(I do still like juxt tho')

So partial seems to be a good fit for when you really want varargs, though? Like (partial + 10)

#(apply + 10 %&) would be the alternative, I guess

But in what contexts would you actually want a varargs (anonymous) function? I can't recall ever using %& in a decade of production Clojure and I think I've only used partial on a variadic function "by accident", i.e., when the actual call(s) of that expression are known arities.

Yeah, just grepped my code here: no instances of %& in well over 100k lines of Clojure (including all my OSS work). I have just a handful of (partial apply =) in test code (but that is not variadic, it takes a single collection argument -- so I could (and should) just use #(apply = %)

Across our entire codebase, we have just over 100 calls to partial in just under 60 files.

Yeah, I can probably come up with an artificial example, but I guess you're right, it's not common at all

By contrast, we have well over 500 anonymous functions with #(..) across nearly 200 files.

(I actually had to check the docs before even mentioning %& for its existence; never used it in real life)

Thank you!