It angers me that they call out that most nomads are straight. They should have said that there are MORE LGBT folks who are nomads than the average in the USA.
While "nomads are disproportionately x, y, and z" would also be a great follow-up, "the average nomad" is separate and it's just as interesting to think about the archetype of 10,000 nomads put together!
Yeah. I've gotten into the habit of asking hosts to send me their exact up/down. Even then, they often have wifi routers that are just awful, so I have to plug in via ethernet and share it from my laptop.
I'm so glad my unexpected nomad journey is coming to an end. :-)
I can't help but attempt to apply Kant's categorical imperative to this approach. Is this something I would wish as a universal rule?
What about folks who have really bad luck and participate in organizations that are a bad fit for their personality? Their score immediately goes down, and then the odds of them finding a better fit plummet. There is no "fresh start," so to speak.
If everybody used this system to make a judgment about whether a person is worthy, it feels like we would immediately create a permanent caste system. There would be social outcasts that would only work with other outcasts, because, frankly who else would want to? They are, in a word, untouchable.
So, for me, it appears this system is unethical to the extreme.
if i work with outcasts that fit my personality i get positive points and get back to the top. No? (btw. is there a formula how that score works. maybe older votes expire)
How is the VSCode support? I've only used IntelliJ + Cursive for Clojure and am quite spoiled. That's the only reason I might not recommend Clojure for a VSCode user. Now, if said user is interested in switching to Emacs or IntelliJ, I'd think it would be a perfect fit.
Nowadays, you can get VSCode support for Clojure pretty much out of the box with calva[1] extension working together with clj-kondo [2] almost without any configuration. It works great - I've switched over from Cursive and I'm not looking back.
Chiming in since I'm a bit disappointed with Clojure VS Code support:calva (the clojure extension) works great, unless you also want vim bindings. In which case it's a bit of a cluster. It's documented and I understand why - but it's still a pain point (it makes the escape key not exit insert mode anymore, by default).
(nota bene: I understand these things are hard to solve and I don't mean to throw the stone without putting my own time on the line to fix it, but that's one reason I'm not using VS code for clojure. Doom emacs with cider is still better, even if not perfect). If people know of someone I could throw money at to solve the integration for VS code, I'd be happy to do that.
If you find a good/great experience for clojure with vim keybindings, I'm all ears.
As a Lisp and Clojure beginner, ehhhh. I could get work done, but I depended on the terminal for REPL and compiling & running. I ended up using Emacs, which along with .NET were the only cases where VSCode didn't feel ideal for me.
How is it that you think Clojure has trouble doing things in a non-functional way? I'm just curious, as I work in Clojure primarily and may have a huge blind spot I'd love to clear out!
For starters you'd need to have imperative control structures like `while`, `continue`, `break` and a `return` that basically returns from anywhere. That can probably be built with macros.
Then you would need to have ways to mutate variables, so you'd need to stop using Clojure's persistent collections and instead use the ones provided by the JVM.
Overall, you can do it if you want to, it is just somewhat painful to do so and the language will fight you. This is like my who tried to write functional Python which is possible but then it is just a much worse Clojure.
I don't have much of experience with Clojure myself - the above might be my first impressions from the little bit where I've tried it. Well, let me try to fix them then, and ask some questions.
In Clojure, how do you usually approach problems that are shaped in an object-oriented way? In object-oriented languages, this usually includes either some sort of method calls (and therefore mutable state) or message passing (which usually involves actors, like Erlang processes). Passing all state around as function arguments is one way, but it becomes somewhat tedious as state grows large.
What would be an example of "problems that are shaped in an object-oriented way"? That just doesn't sound like a thing to me. That may originate from a bias you may have from developing primarily in OO languages.
Clojure does have constructs to manage state. You don't need to shove it all into your function arguments.
Sorry for the mind shortcut. By that, I meant all sorts of problems where multiple state-bearing entities communicate via message passing - usually implemented via method calls in OO languages.
Well Clojure most definitely does support state-bearing entities that communicate using message passing (channels / agents / atoms...) and, while I confess I that I personally don't use them in _quite_ the same way that I use objects and method calls in an OO language, I find that programming in OO and functional languages is kind of converging towards the same point: functional programming in the small (immutable value objects that are worked on using pure functions) and OO in the large (state-bearing entities communicating using message passing).
I'm aware of this. How do you achieve setters if the state you close over is immutable? Isn't that the default in Clojure, since it seems to aim for immutability by default?
To define interfaces, you could check whether the map/object conforms to a spec, etc.
But obviously all this is not very idiomatic; in clojure you would keep those functions first-class through defn instead of tying them to the object / map, and would pass state as an argument. Something like:
(defn getter [obj] @obj)
(defn setter [obj val] (reset! obj val))
(def obj (atom 0)) ; This gives you the ability (and need)
; to explicitly track the list of
; existing objects in use lest they are garbage collected.
(setter obj 12)
If obj has structure (e.g. it is a map such as {:type :my.personal/type :val 12}) you can identify its type through the type keyval and can check conformance to a spec, etc.
As it was said in the previous post, it's equivalent. It's a matter of how to organize code.
You could have an atom that holds the state and a function which can update that atom. You might do something like the elm architecture where you pass a message to a reducer which produces the new state that the atom is set to. All the logic is contained in the reducer and is pure and immutable and the state change happens at a single controlled point.
OK. If I understood correctly, then you limit the mutable state to one point, and use functional logic everywhere around it. You can also optionally close over the atom to achieve encapsulation.
Thanks, TIL! That's equivalent to the "mostly functional" style that's doable in Common Lisp.
Yeah, Clojure is one of those languages where functional purity at all costs isn't really the goal. Like others have said its more about being careful how you set state and Clojure gives you loads of great functions for doing everything in a pure way. Its standard library is its greatest asset as far as I'm concerned
Exactly! This method of limiting the mutable part to one point is a pattern that is highly useful, and highly used, when working in clojurescript with react through reagent and re-frame, for example: you represent the whole state of your app in a tree of maps and define functions that, given a version of your app state, return the updated version. Then you just execute state-changing pure functions linked to a stream of events to move your one-point-mutable-app-state through a stream of valid states.
(and also obviously functions that map that state to HTML/CSS/SVG/etc.).
Using state is not functional programming, so you're really saying that functional programming is all about being mindful when to use functional programming versus when to abandon functional programming.
There's also the added benefit of Software Transactional Memory being available for operations on said mutable state, in case you need to access it from multiple threads.
Apologies in advance for going on a slight tangent here but it's my view that defining getters and setters is not considered idiomatic OO code either. If one object is using getters and setter to access the state of another then this suggests that there feature envy and excessive coupling between those two objects. These days, I try to follow the Law Of Demeter (https://en.wikipedia.org/wiki/Law_of_Demeter) and avoid that sort of thing. The logic that calls the getters and settings should really be in a class with a single responsibility that we call by invoking its methods in a tell-don't-ask style. As others have already pointed out, we can do similar things in a functional language like Clojure by encapsulating state in an atom (or an agent) and applying pure functions to that state.
Boy do I hate that phrase. It's absolutely incorrect from a neuroscience perspective. Words can in fact hurt you, and, depending on circumstances, cause long term psychological damage. Here's a place to start to learn more if you want: https://www.td.org/insights/the-neuroscience-of-reward-and-t...
Hurt has acquired multiple meanings. The phrase you hate refers to "hurt" of the bone-breaking variety. To me, that makes it clear. But maybe it's confusing.
Fun! Yup, metaphors can be great and apt. We can extend the word “harm” to any desired degree, and find motivations like this.
Then if we bring the new variable value (harm includes psychological harm) back to an older equation (words can never harm me), we can derive anything (the phrase is now wrong).
There is no logic police to stop us from doing this when it’s useful.
Another example: “beer will get me drunk”. I hate this phrase, so let’s fix it.
First, I can say that being “drunk” is similar to being “in love”. It has many similarities, after all, and I think those justify equivalence. From there, I can say that being “in love” is after all very similar to being “loved”.
Bringing it back, my statement is now “beer will get me loved”. It’s the clever hack underpinning many great nights.
It may well be harmful, but your reasoning seems spurious. It would imply that "marijuana can be so harmful that is made illegal almost everywhere in the world".
5% are gay/lesbian, 9% are bi. Compare to these metrics: https://en.wikipedia.org/wiki/LGBT_demographics_of_the_Unite... -- that's a higher ratio than all but 3 states in the USA.