I mostly use IDEs for day to day coding, and pretty much every IDE supports vim keybindings, which I always have enabled. I also use vim in the terminal for small edits and one-off files, so it's not either/or.
After the initial learning curve and fiddling with settings, it just becomes natural and you can edit code or other text at blazing fast speeds. I also find that it helps with RSI by reducing arm motions reaching for the mouse.
Of course, there are other good options out there, but if vim fits your brain, it can significantly boost your editing speed. For those who say programmers don't spend that much time typing, that's true sometimes, but there are periods after the design/planning phase where we type a lot, and I want that to go as fast as possible while I have an implementation loaded into short term memory.
As someone who used to be a vim skeptic myself, I'd suggest you either give it another look or just accept that it works well for other people and go on with your day.
The issue isn't intelligence per se. It's ignorance (often willful ignorance), dogmatism, media illiteracy, political illiteracy, etc. There are many intelligent (but evil) people in the Trump administration and not every Trump voter is a dunce. Framing them all as stupid isn't useful, because it doesn't help us understand and counteract what's happening.
In that case following Alice's input is still the best strategy, but you'll be worse off: you'd only be right if both tell the truth, at 80%80%=64%, or both lie, at 20%20%=4%, for a total of 68%.
In the general case of n intermediate occasional liars, the odds of the final result being accurate goes to 50% as n grows large, which makes sense, as it will have no correlation anymore to the initial input.
Thanks. I came up with this Python simulation that matches your 68%:
import random
def lying_flippers(num_flips=1_000_000):
"""
- Bob flips a coin and tells Alice the result but lies 20% of the
time.
- Alice tells me Bob's result but also lies 20% of the time.
- If I trust Bob, I know I'll be correct 80% of the time.
- If I trust Alice, how often will I be correct (assuming I don't
know Bob's result)?
"""
# Invert flip 20% of the time.
def maybe_flip_flip(flip: bool):
if random.random() < 0.2:
return not flip
return flip
def sum_correct(actual, altered):
return sum(1 if a == b else 0 for (b, a) in zip(actual, altered))
half_num_flips = num_flips // 2
twenty_percent = int(num_flips * 0.2)
actual_flips = [random.choice((True, False)) for _ in range(num_flips)]
num_heads = sum(actual_flips)
num_tails = num_flips - num_heads
print(f"Heads = {num_heads} Tails = {num_tails}")
bob_flips = [maybe_flip_flip(flip) for flip in actual_flips]
alice_flips = [maybe_flip_flip(flip) for flip in bob_flips]
bob_num_correct = sum_correct(actual_flips, bob_flips)
bob_percent_correct = bob_num_correct / num_flips
alice_num_correct = sum_correct(actual_flips, alice_flips)
alice_percent_correct = alice_num_correct / num_flips
# Trusting Bob should lead to being correct ~80% of the time.
# This is just a verification of the model since we already know the answer.
print(f"Trust Bob -> {bob_percent_correct:.1%}")
# Trusting Alice should lead to being correct ?% of the time.
# This model produces 68%.
print(f"Trust Alice -> {alice_percent_correct:.1%}")
print()
How it is "luxury" to want to address large scale crimes such as wage theft, price collusion, corruption, unequal access, and institutional racism/classism that are major underlying factors in street crime, including the lack of enforcement you mention here? From a nerd perspective, it's seems obvious that addressing underlying causes is beneficial to all of us. In fact, it seems likely that it's the only thing that will work in the long run. Policing might also be necessary in some cases, but it's not going to fix our long-standing social issues.
It's luxury to suggest that street and property crime should take a backburner to whatever your issues are, because you are (demographically speaking; I have no idea who you are personally) (1) much less likely to experience street and property crime than someone in a low-income neighborhood and (2) much more able to metabolize the impacts of those crimes.
The whole thing is silly; it isn't the job of municipal police to investigate price collusion and corruption in the first place. You might just as meaningfully say that the trash collection service should be prioritizing institutional racism.
I agree we need to separate these responsibilities, but when it comes to mental health response, the police themselves are often opposed to alternatives, even while they complain that they're not mental health providers and often can't do anything in those types of situations.
In my city, we've had an underfunded street response program for a few years now, but a lot of people (including a lot of people who don't live here) see it as antagonistic to police and police funding, when really it should just be part of a holistic system to address social issues.
It makes no sense to me that the people who ostensibly care the most about addressing crime and "disorder" on the streets are often the most oppositional to programs that might actually address some of the underlying issues (not all of course, but some).
The call to logging.basicConfig happens at import time, which could cause issues in certain scenarios. For a one-off script, it's probably fine, but for a production app, you'd probably want to set up logging during app startup from whatever your main entry point is.
The Python standard library has a configparser module, which should be used instead of custom code. It's safer and easier than manual parsing. The standard library also has a tomllib module, which would be an even better option IMO.
Logging configuration is done at import time for "utils" module.
Imagine code like this:
main.py:
import logging
logging.basicConfig(...)
logging.info("foo") # uses above config
if __name__ == "__main__":
import utils # your config is overridden with the one in utils
logging.info("bar") # uses utils configuration
...
Or two "commands", one importing utils and another not: they would non-obviously use different logging configuration.
It gets even crazier: you could import utils to set the configuration, override it, but a second import would not re-set it, as module imports are cached.
Basically, don't do it and no unexpected, confusing behaviour anywhere.
As a non Python developer, what would be the use-case(s) for importing a module inside of the main function instead of importing it at the top of main.py with the others?
Since the entire evaluation and running is dynamic, you don't need to import (and thus evaluate) a module in certain branches.
Eg. that `if __name__` trick is used to allow a module to be both a runnable script and importable module.
Top it off with plenty of common libraries being dog-slow to import because they are doing some of the anti-pattern stuff too, and you end up executing a lot of code when you just want to import a single module.
Eg. I've seen large Python projects that take 75s just importing all the modules because they are listing imports at the top, and many are executing code during import — imagine wanting to run a simple unit test, and your test runner takes 75s just to get to the point where it can run that 0.01s test for your "quick" TDD iteration.
You can also look at Instagram's approach to solving this over at their engineering blog.
I've been writing client-side JS/TS for many years and still enjoy it, but there are scenarios—quite a few in my opinion—where targeting WASM is a better technical and business choice. It's just a "right tool for the job" kind of thing.
In its heyday, before the most recent acquisition, Twitter was really good for local info (ignoring celebrities, shitposting, and the like). Not just news but announcements, alerts, and other local stuff if you followed the right accounts.
Mastodon is cool, but it's hard to consistently find that local info. Bluesky seems like it has a chance of supplanting Twitter in this way, but it's not there yet. Some of the accounts I used to follow on Twitter are on Bluesky, but they don't post. If they started, I think they'd get tons of followers now.
I used to see a lot of furry accounts in the Discover feed, but I mute them when I see them, and now I rarely see them any more. I don't have anything against furries, but it's not content I'm interested in. This is more a comment that Bluesky does seem to have an algorithm (at least in the Discover feed) that is sensitive to what you do or don't show interest in. Or it could just be that a lot more people have joined recently, so the furry stuff just isn't as prevalent.
Discover has a separate "show more/less like this" button too.
Every feed on the site is its own algorithm, and most are made by third-parties. Some of the more interesting ones have fallen over and broken a little as the volume of posts has increased. The various "catch up" feeds that show the most popular recent posts give a good impression of what's happening site wide (minus any blocks/mutes).
After the initial learning curve and fiddling with settings, it just becomes natural and you can edit code or other text at blazing fast speeds. I also find that it helps with RSI by reducing arm motions reaching for the mouse.
Of course, there are other good options out there, but if vim fits your brain, it can significantly boost your editing speed. For those who say programmers don't spend that much time typing, that's true sometimes, but there are periods after the design/planning phase where we type a lot, and I want that to go as fast as possible while I have an implementation loaded into short term memory.
As someone who used to be a vim skeptic myself, I'd suggest you either give it another look or just accept that it works well for other people and go on with your day.
reply