Morning

Morning (yawns)

morning

Morning

@jasonbell I don't think @agile_geek needs a mobility scooter to prove he's having a mid life crisis. I think his CBR-all the CCs proves that

🙂

I'm sure he does

Morning.

Bore da pawb

❤️

mornings!

Morning

Mornin'

Morning!

Morning all!

Anyone up in the Stafford area? I'm here for a cat show this weekend (at the pet show at the county fairgrounds).

Good morning!

Morning

o/

The weather is a lot more bearable than when I was here last month! :barely_sunny:

Also: yay, pet shows! I used to hang out with small animal/rat show breeders and judges, it can be great fun to get to know the owners and the pets 🙂

http://tonsky.me/blog/readable-clojure/#dont-rely-on-implicit-nil-to-false-coercion what is the point of advising not to use higher order functions ?

that list is highly questionable

and the terminology there is incorrect, it's talking about "point-free" style but referring it as higher-order functions -- both examples are using higher order functions, the first is in point-free while the second isn't

The guy advises to avoid these functions because he hasn’t internalised the pattern they use enough that he can speed-read it. It’s his personal preference.

i found that blog really interesting

If i read that when i first started clojure i would totally agree

but as ive been working with clojure for longer periods of time i don’t really like what hes saying

To me it feels like most of his points would help beginners learn a new code base but i find most of his suggestions frustrating

Incidentally, I do find myself annoyed by the lack of clarity between nil (null) and false and various ways to indicate “not found” or “error” in a different language (PHP), so I’m actually glad for the -some varieties. I like when the author takes extra time to be clear about their intentions.

I still prefer https://github.com/bbatsov/clojure-style-guide

rather than just someones blog post

:man-shrugging:

I would assume (maybe wrongly) that if you followed the above links style, then people who have done clojure before will have an easier time of reading your code

anyways ill stop 😅 i think im a bit tilted haha

Several things in Tonsky's blog post are very non-idiomatic (and to be fair he does sort of acknowledge that). But I think learning to read and write idiomatic Clojure is more important than catering to potential newbies.

(because they will have to learn the idioms to be effective -- and to read most Clojure library code out there)

I wrote a long rant about idioms....among a load of other stuff... for why I find some Clojure/Clojurescript codebases hard to grok. The idioms help you scan code faster but the big payback for me personally is when I have something that tells me the 'shape' of the data every fn is expecting. You can get some of this from Spec and/or Schema but that tends to just be at the boundaries of the app not deep inside the app. Most of it comes down to giving the next developer (or the future you) breadcrumbs to follow. So I find example based unit tests and integration tests among the most useful things for describing the expected input if you don't add spec to every fn.

Along the lines of my other rants about evolutionary architecture, I think the trick with Spec/Schema is adding it at the point where the abstractions (and associated data) stabilise. Don't impose abstractions too early before you're sure they're required as that's a decision that becomes a 'legacy' (in a bad way) that you carry the cost of maintaining for as long as the codebase hangs around.

All of this eventually comes back to: 1) A clear, but evolving, architectural vision understood by all the team(s) (and the underlying reasons for choices made tied back to business benefit/needs) 2) Developers using the right disciplines at the right time to implement said vision All of which is context specific and can't be taught by rote.

Here endeth the lesson...

And please understand I think that you are making good points @agile_geek

>2) Developers using the right disciplines at the right time to implement said vision I think the hard part here is the right time. It's not easy to know when the right time is and just use the same disciplines all the time

i see you have the sultan part of 'consultant' covered

Consultant spelt Con$ultant 🙂

@jasonbell not enough $'s .. Con$$$$$$$$$ultant!

🙂

lollllll

2nd mornings

Can anyone explain to me what schema.core/named is doing here https://github.com/plumatic/schema/blob/60bf36a8d63c15216f366c73ccf7ff8e7cd6baad/src/cljx/schema/core.cljx#L434-L445

it looks like its creating a NamedSchema record ?

I’m not sure i understand what question you are really asking

NamedSchema. is java interop for creating an object i believe? and its just passing in the schema and name

named is a constructor

I remember reading that it’s recommended to not create records by using the (Thing. ) notation, but to create a function wrapper for that

https://clojuredocs.org/clojure.core/defrecord

I would usually use the ->map thing

let me find it

@yogidevbear @lady3janepl that's just for convenience, (Ctor.) requires requiring the namespace and importing the class, a wrapper function just requires requiring the namespace

(map->WereWolf {:name "Lucian" :title "CEO of Melodrama"}) Taken from : https://www.braveclojure.com/multimethods-records-protocols/

defrecord autogenerates map->Ctor and ->Ctor functions

I guess they prefer exposing ctor instead of ->Ctor as their public api, so that's what named is there for

Its a common pattern i think where u create a defrecord then create a function below that calls the constructor inside the fn.

^ my english isnt very good sorry, let me rephrase

it's common mostly when that constructor function is exposed as a public API, for internal APIs the autogenerated ->Ctor function is just the same

imposter syndrome setting in

for completeness, map->Ctor is only generated on defrecord, while ->Ctor is generated for both defrecord and deftype

ooh thats neat to know

TIL; :thumbsup:

So reading and re-reading, my understanding is that I can use schema.core/named to define a custom named schema validation type. Does that sound about right?

(named some-schema some-schema-name)

yeah i think so

Also, annoyingly when you do a deftype and implement some protocols at the same time, you cannot use ->MyType inside the implementations. However, you can use the constructor function, if you declared it before starting the type definition.

@lady3janepl yeah there's already a ticket + patch for that, one sec

https://dev.clojure.org/jira/browse/CLJ-1044

only been open for 6 years 🙃

6 years and 5 days actually

puts things in perspective

@bronsa isn't Jira just a black hole for things you wish would be implemented. Like that in most orgs!

jira in this case is a black hole for things I have already implemented over and over and wish they would just get merged or even looked at

but whatever, all the major patches I cared about have already made it eventually, it's just the minor things that are left over

i'm not as bitter about it as I was a few years ago :)

i find it so hard to come up with talk ideas 😓

I'm not saying they're good ideas!

haha

@bronsa - 1. Siphon off the last three hundred talk titles from your favourite conferences. 2. Lower case the titles, remove words like "and", "it", "is" etc. 3. Use Clojure to split the words by space into one big vector and then run frequencies function against it.

Works for me 🙂