Try the download link for 1.10.3.905 - that's the version mentioned in the original announcement.

Thanks, it worked!

It's also worth noting that 1.10.3 and 1.11.0-alpha1 are the versions of Clojure (the language) itself, not the CLI. The CLI has it's own versions -- http://clojure.org/releases/tools -- where the prefix indicates which version of Clojure it will use by default if you don't override it. But you can use any version of Clojure (from 1.0 all the way up to the latest 1.11 alpha) with the CLI.

top 10 blog posts of the decade

yes

i.e. (<!! (go-loop ,,,))

hey btw, would this work? (let handler (go-loop...)) (<!! handler)

yes, everything in Clojure returns a value. Go blocks return a channel which will contains the value of the expression which runs within them

I mean if the above 2 lines are in 2 completely different locations in the code, it is still going to wait for the handler to die... right?

Your code won't compile

Lexical scope constraints apply

err.... I must have missed something... assuming the handler is available in the scope... still?

(let [handler (go-loop ,,,)] ,,, (<!! handler))

oh yes this works as well... but in general if instead of let, if handler was a def , even then within the same ns you should be able to <!! handler) no?

Yes, but please don't def things with a state which might change over time, it's a recipe for trouble

I know 😄 I'll keep that in mind. Thanks for all your help!! Take care

Godspeed 🙂

But that won't synchronize, either. I need the result

or at least, to wait for it

alts with default returns immediately which I might not want

Which is exactly what go-blocks give me

The only way to "synchronize" but not block is using go-blocks, which means I had to keep my code in go-blocks, which means it has color

Possible. You just got up, I'm about to go to sleep, too many opportunities for communication error

Coffee is good, highly recommended

Thanks, we'll pick it up later. Take a look at the functions color post, it lays it out well

I think Ben just meant, if you want to work with non thread based concurrency you're stuck using go everywhere

You can use <!!, but now you're doing regular old OS thread concurrency, which defeats the point of using go in the first place.

A really good example of a function with color is core.async/map

or merge

merge takes channels, returns channel

the meaning of the content of the channels is somewhere else

If you program with the async versions of map, merge, filter, etc, you're programming with their async versions

i.e. not your regular functions

suddenly you're in a world of channels in, channels out

another thing is how exceptions aren't propagated "properly"

I agree with that there is still color, but I don't know if having it is as bad as in JS, because channels are continuous streams, it seems like the way CSP works, the normal programming style just doesn't apply. Where as with promise it makes sense, because functions normally return a single result, so it be great to just have something automatically sync the async function call with the thing that waits for its single result. But processes are meant to run more like services, so a channel could return many things, so having them behave like collections where you can use transducers over them, but also understanding their async nature, I don't think you can retrofit this into a normal programming flow, like its just a different style of programming.

Yeah, this is coming soon with https://github.com/teknql/tapestry

It's rather common, yeah. I often use it for maps, like id->entity.

@U01F1TM2FD5What do you mean by using it as a "map"? DO you mean the returned value is a map or the arg itself? @U11BV7MTK speaks about type signatures out of the thread.

It's a common naming convention for functions that convert one thing into another, where it goes:

(defn x->z
  "Converts an x into a z"
  [x]
  ...)

Seems like you @-ed a wrong person. :) I mean this: (def id->entity {1 entity-1, 2 entity-2})

Oh whoops. 🙂

@U0K064KQV very succinct explanation, thanks.

Other languages normally use to for the same, so when you see x->z Think of it as: xToz

I like some of the symbols in the function names, prevents verbose names.

You'll also see it sometime for constructor functions (sometimes called factory functions in some languages) where it'll have ->x which means to x

(defn ->person
  "Construct a person map with values as provided from name and address"
  [name address]
  {:name name
   :address address})

Clojure itself generates functions with -> for records, at the very least.

And again in other languages normally they'd use to instead, like toPerson(name, address)

Ya, so when you create a record, Clojure will auto-create two such functions:

(defrecord Person [name address])
(->Person "John" "1111 street")
(map->Person {:name "John", :address "1111 street"})

Which you can read as: toPerson and mapToPerson

Also, generally Clojure distinguishes an uppercase to indicate a record or type like Person with uppercase P because it is a record. While it uses lowercase to indicate the entity is a common data-structure like person would generally imply it's a map or a vector

Sorry I lost you at "When a var, often for the same or a map with keys of the left side of the arrow and values the right side of the arrow." I get the idea of expressing the function type signature in the name though.

(defn x->y [x] <computes y from x>) is a var named x->y (let [id->people {1 person-1 2 person-2}] ...) here the local of id->people is a map of id mapped to people. it is a map. but it's also a function since maps are invocable. so its kinda different, kinda the same

I can actually think of two reasons: • If the function that converts a to b is called b, what name would you bind the actual result of the function to? and • having multiple types of input (a->b, c->b etc) - which one would the function named b be? But even so I'm generally content with shorter names :man-shrugging:

I don't think there is a generic answer to any of those questions - it all depends on the context and on personal preferences, and even those fluctuate within the same person.

If you haven't already, I'd highly recommend reading Zach Tellman's "Elements of Clojure" which talks in depth about naming.

Yeah that's true @U2FRKM4TW ! I guess what I was trying to convey is that, from personal experience, I've found that trying to avoid the extra symbols has resulted in more readable code for the most part. It goes without saying that ymmv 🙂 There's actually a free sample online that includes the naming section and it's quite insightful, thanks @U04V70XH6

Not quite the same, but related: I definitely think person is all-around better than fetch-person or get-person.

I do less of the a->b stuff lately as well. I find it does work when the operation describes an actual conversion. For example, if you are transferring products from one system to another: product-a->product-b or (and this one’s odd) a->b:product

May I ask why having a verb is helpful?

(stepping out. bbl)

> if your function name is just a noun, what does the naming tell you about what the function does? > Well, take keys and vals for instance. Would ->keys or map->vals be better names for them? I don't see verbs as a requirement in function names but yeah sometimes they do give some context, e.g. in a namespace called email, fetch could be a nice name for a function (a similar example is actually in Elements of Clojure as well 😄 ).

If you don't care about the input type, then just use ->person

I do think its a Lisp-1 problem. You will for sure want to do: (def person (->person "John")) And you can't do:

(def person (person "John"))
(def other-person (person "Bob"))

> if your function name is just a noun, what does the naming tell you about what the function does? Ah. My current take: I read (person "John") as “it returns a person named John.” I don’t care what it does to get there.

and as for naming:

(def john (person "John"))
(def bob (person "Bob"))

(defn foo [name]
  (let [p (person name)] ...))

Ah yes!

I really prefer the component thing to signal i/o.

(person conn "bob")

^says to me “It’s going to use conn to get the person "bob" ”

Ya, like it's okay that m is map, which is necessary because map is a function, but then I find using p becomes cryptic, because p is not generally understood as a person, maybe you also have a provider entity in your app, and now things get weird, etc.

@U0K064KQV Notice I used it for a locally-scoped thing.

So if there’s a question, “what’s p ?” you look up at the definition, “oh, p is a person”

Also: if you do it regularly, it becomes like m for map in a codebase.

I saw it, and still think its not best for readability

like when you’re doing an http call?

I usually still pass that stuff in. It allows you to do things like rate limiting and circuit breaking.

Right AWS usually requires a client of some sort for connection pooling.

I would probably agree with others, functions perform computation, seem logical that they tend to be verbs, and variables define things, seems logical they tend to be nouns.

The "but my function is pure so it can be treated as a value" I don't really buy into, because it still needs to be parameterized, even if all it does is lookup the right output for the given input, that feels like an action to me

I have no idea what you’re trying to say 😂

@U0K064KQV ^

What gets weird are getter like "keys", but to me that makes sense a noun, because its really like a kind of field access

@U8QBZBHGD that’s basically what I do. I make a namespace for a particular service. Everything in there is expected to probably do some i/o.

Though I don’t use a verb in the name.

Ya, I'd verb them too.

I feel I'd rather the service be a detail I don't care about

So having a namespace for the service seems strange to me.

Like as a Clojure wrapper for Zulip? Or as like where you put your business logic for things that need stuff from Zulip?

As a zulip wrapper I do the same thing. And normally use get for lookup queries, and fetch for search

So get-message is lookup, so would take like an id, where as fetch-message would be a search so maybe say it takes a regex to find all messages of match in their content

Euh, sorry, I never use fetch lol, I meant find

Ya, I mean if I'm wrapping an API, I stick to their names

But I tend to not wrap APIs, and use the Java client directly though

So like on some API if I need to lookup a message somewhere I'd probably have a get-message function for it in the API namespace. If another API also needs to do the same then I'll just move the function to a shared helper namespace

And if it was a search, I'd call it find-message

Right, so this is my apps get-message for some API. The fact it uses Zulip would be like an implementation details. So inside get-messagemaybe I use Zulip, or something else, and maybe that has its own get-message. That's what I meant like this is different then if you created a ZulipClient namespace which was like a Clojure based client for Zulip

Anyways, style questions have no good answers, really just personal preference.