CapeWearingAeroplane @ CapeWearingAeroplane @sopuli.xyz

Posts

0

Comments

265

Joined

2 yr. ago

I use a GUI (GitKraken) to easily visualise the different branches I'm working on, the state of my local vs. the remote etc. I sometimes use the gui to resolve merge conflicts. 99 % of my gut usage is command line based.

GUI's definitely have a space, but that space is specifically doing the thing the command line is bad at: Visualising stuff.

I think you're mistaken about "getting it wrong" here. If a statistician says "Candidate A has a 99 % chance of winning", and the candidate loses, that doesn't mean the statistician was wrong, just that the improbable happened. If you have a repeatable experiment you can do the experiment many times to see if Candidate A wins 99% of the time, if they don't then the statistician is wrong.

Problem is: We can't do multiple, uncorrelated elections to test, so we can't ever disprove the statistician. What we can do, is look at a bunch of prior elections, the predictions made, and see if we prefer trusting the statistician over not trusting them.

I think if you look at a bunch of election results and predictions, and take confidence margins into account, that you'll find the statisticians are more often right than wrong. But you need to interpret the statistical predictions correctly.

Thinking like this just works against those of us trying to fight racism. Racism is, at its core founded in a belief that some people are inherently more valuable than others, based on ethnicity/how they look.

A factual statement about a group of people can be true or false, but in order to be racist it must also (explicitly or implicitly) say something about those peoples worth.

Saying "group A has lower IQ than group B" can be factually correct, and part in an analysis into why, and how the differences can be evened out. Saying "group X is dumber than group Y" can also be factually correct, but can be said in a context and with an implication that this makes them less valuable as people. Purely based on the statements themselves you can't tell if either is racist. You need to look at the implications, context, and intentions behind the statement.

One of the horrors of slavery was, in fact, the forced "breeding" of slaves. Even thinking about it makes me feel sick. That doesn't mean the statement "group X was bred differently from group Y" inherently racist. The racism comes in if that statement is said with the implication that the people in question were subhuman, or otherwise less (or more) valuable as people.

A good example that another commenter mentioned is the Ashkenazi Jews, which systematically eradicated a genetic disorder by tracking who should not have children. Saying "they bred the disease out of the population" may be imprecise and a poor choice of words, but it is not racist. It is a factually correct (albeit poorly phrased) statement about an impressive medical feat that has (presumably) improved a lot of lives.

In order to fight racism you need to be more nuanced than what you are being when you say that "statement X is racist, regardless of the intention behind it". A statement being poorly phrased can lead to it being misinterpreted, not to it being racist.

it will be a victory for them to push more

I don't see how maintaining the status quo can be seen as a "victory that makes them push for more"? That argument is much easier to push the other way:

If someone can play a sport based on undergoing X treatment, isn't that discriminatory against those that can't afford treatment but still identify a certain way? What about XYZ women's only spaces, should we allow anyone that proclaims self-identifying a certain way into those spaces?

That's the same "victory to make them push for more" just flipped.

There are a bunch of restrictions in F1, which largely make it harder to make fast cars. But think of it the other way around: Those restrictions make the engineering harder, and all teams have the same restrictions. That means you have to optimise even more within the limitations you have, because you're not allowed to make some of the "easy" optimisations like cutting weight by removing the roll cage.

The most likely argument I see is that Trump severely strained diplomatic bonds both between North America and Europe and also within North America and Europe. Additionally, he heralded in a new degree of isolationist policy and created doubt about the resilience of NATO. Furthermore, he tried to blackmail the Ukrainian government.

In summary: Not his fault directly but his politics led to a situation where Russia/Putin saw it as likely that they could invade without facing significant backlash from Europe + North America. That probably would have worked out as well if Ukraine had folded within the first couple of weeks. The argument is essentially that by convincing Russia that they could get Ukraine without significant consequences, his administration contributed to the invasion happening.

Make of that argument what you will. Personally, I think it's a bit of a stretch to say "Trumps fault", but reasonable to think that another administration might have been able to deter the invasion.

And the see-through kind of jellyfish

Hey, good news! The newer MacBooks (since like 2 years ago) have rolled back the Touch Bar, gotten back the ol' reliable scissors switches and MagSafe chargers, as well as having enough ports to plug stuff in.

As for arm vs. intel, I'm a huge fan of the arm chips. My largest issue with them is that I need to cross compile for intel chips if I'm distributing an executable or a compiled library.

Boy do I have news for you...

I like the other response here

assembly is a gauss gun... you just have to manually align the magnets

If you write C/C++ libraries for Python you can disable the GIL

I want to respond to your edit:

wait for consensus before you publish, don't publish anything that isn't peer reviewed and replicated multiple times.

You need to understand that publishing is the way scientists communicate among each other. Of course, all reputable journals conduct peer review before publishing, but peer review is just that: Review. The peer review process is meant to uncover obviously bad, or poorly communicated, research.

Replication happens when other scientists read the paper and decide to replicate. In fact, by far most replication is likely never published, because it is done as a part of model/rig verification and testing. For example: If I implement a model or build an experimental rig and want to make sure I did it right, I'll go replicate some work to test it. If I successfully replicate I'm probably not going to spend time publishing that, because I built the rig/implemented to model to do my own research. If I'm unable to replicate, I'll first assume something is wrong with my rig/implementation. If I can rule that out (maybe by replicating something else) I might publish the new results on the stuff I couldn't replicate.

Consensus is built when a lot of publications agree on something, to the point where, if you aren't able to replicate it, you can feel quite positive it's because you're doing something wrong.

Basically: The idea of waiting for consensus before publishing can't work, because consensus is formed by a bunch of people publishing. Once solid consensus is established, you'll have a hard time getting a journal to accept an article further confirming the consensus.

I really don't see the hassle.. just pick one (e.g. pip/venv) and learn it in like half a day. It took college student me literally a couple hours to figure out how I could distribute a package to my peers that included compiled C++ code using pypi. The hardest part was figuring out how to cross compile the C++ lib. If you think it's that hard to understand I really don't know what to tell you..

Im honestly surprised someone using Python professionally appears to not know anything about how pip/venv work.

The points you think you are making here are just very clearly showing that you need to rtfm...

I have to agree, I maintain and develop packages in fortrat/C/C++ that use Python as a user interface, and in my experience pip just works.

You only need to throw together a ≈30 line setup.py and a 5 line bash script and then you never have to think about it again.

Infinite recursion be like

My void* doesn't care about your const!

what if I honestly dgaf and prefer that people call me whatever they want?

I typically don't declare them as such - bring the pitchforks!

Unironically: For in-house scripts and toolboxes where I want to set stuff like input directory, output directory etc. for the whole toolbox, and then just run the scripts. There are other easy solutions of course, but this makes it really quick and easy to just run the scripts when I need to.