Fork me on GitHub
#off-topic
<
2021-08-08
>
vemv00:08:54

How would you call a word/term that is thrown around without much backing reasoning? e.g. sometimes people say things like "this looks unscalable to me" or complex, magical, etc blanket statement seems close but it has a distinct meaning shallow dismissal also is close but I'm targeting the use of just one word. It bothers me because you can't just use a word and call that a piece of argumentation :)

bartuka01:08:52

I often use "arbitrary" to these situations

👀 3
vemv01:08:56

maybe I'll use "one-worder" 🕶️ as in one-liner.

emccue03:08:56

@U45T93RA6 Just call it a Vizzini

partywombat 3
emccue03:08:50

and if you haven't watched the princess bridge, thats a good one

emccue03:08:32

OR just throw that quote back at them

vemv03:08:58

recent articles have invited me to think whether github's "code reviews" are in fact a conflict-making machine I like the idea overall but making an empathetic review is hard. For one thing I'd remove the red button

noisesmith15:08:57

IMHO it's a mistake to treat review as if it were a technological process. When there's enough work so that not every programmer has input on every task, review is an excellent way to reduce bus factor and ensure that far away parts of an architecture are being used correctly

👍 2
noisesmith15:08:34

it's a way of pulling more people into conversation, and without that conversation code bases don't make sense

tolitius00:08:08

great discussion as always, a bit more opinionated that it could have been, but that only means we did something right :) one thing I’d like to point out to people who is afraid of “a global state without giving a context”: • your data store is a global state • your I/O is a global state • your message broker is a global state etc. all these usually have mechanisms to deal with it: data stores have transactions, I/O is usually based on file handles and OS tooling, message brokers use internal queues, etc. no need to hide behind an illusion that you are not using global state because of hypothetical dogma you like https://github.com/stuartsierra/component to manage state and it works for you? great! https://github.com/weavejester/integrant? even better! https://github.com/juxt/clip? all the power to you! for the last few years we have built not one, but several large systems with https://github.com/tolitius/mount that are happily living in production and helping humans to live a better life. so our experience is as good as yours as to strong opinions, don’t let them discourage you, especially if you are a beginner. start with nothing or go try many, it all depends on how you learn. Clojure community is so tiny and all this “strong opinions” about a library just make it even tinier I propose we grow vs. shrink

🙏 6
❤️ 4
vemv01:08:09

Practically every discussion over here on the topic ends up pointing out that there are unsurmountable limits to what Mount can accomplish, especially in tests, even more so in parallel tests That's a pretty specific thing. I don't think anyone hates on a given lib just for the sake of it. Instead the actual tradeoffs are shown Diversity is indeed a strength in our community, at the same time an awkward truth is that some ideas stood the test of time better than others. And that's perfectly fine, I think people remember Plumatic Schema quite fondly to put a neutral example :)

vemv02:08:25

Yes I did at $prev_job. And it kind of supports my view... we were quite happy with it but also considered Spec or Malli from time to time... which didn't mean something was wrong about Schema, much less with the authors that graciously shared it with the world In the end one generally pursues the simplest ideas. Code can always be swapped

Timur Latypoff08:08:47

From my experience, leiningen, mount and compojure are much easier to start with rather than tools.deps, integrant and reitit. For the scopes of relatively small projects I make (focused on delivering useful features rather than engineering perfection or large dev team coordination), the “easy” things work just fine and save me from a lot of learning. When the projects make enough money to justify hiring a team of Clojure devs, surely we’d spend a couple of weeks on gradually improving the tooling and library choices.