as opposed to human-generated code

i cast str to int

tldr

1. Keep Commits Small: Ensure commits are small and manageable to facilitate easy reverts and debugging.
2. Continuous Refactoring: Prioritize frequent, minor refactorings to simplify future changes.
3. Deploy Continuously: Regularly deploy code to ensure it works in production, as working software is progress.
4. Trust Frameworks: Avoid over-testing framework capabilities; focus on application-specific logic.
5. Create Independent Modules: Place functions in new modules if they don’t fit existing ones, preserving code organization.
6. Write Tests Early: Use tests to design APIs and guide development, but don’t be rigid about TDD.
7. Avoid Duplication: Prevent repeated code by abstracting similar implementations after copying once.
8. Embrace Change: Accept and adapt to evolving designs, understanding that change is intrinsic to software development.
9. Manage Technical Debt: Focus on minimizing immediate blockers and plan for potential future issues.
10. Prioritize Testability: Ensure that your code and design facilitate easy testing to maintain code quality and coverage.

Scientists using macs connecting to servers and other machines running Linux.

Unknown share is high too; Linux usage on desktop in Antarctica could be as high as 15%.

valid question, idk why would people downvote it

broken websites on desktop are rare and not nearly enough to drive a browser change, but they usually fall into two categories:

1. websites that "break" on purpose for no good reason when they detect it's not chromium. Either avoid the site or change the user agent.

2. websites that degrade some functionalities because they rely on newer features or on how things appear on chromium. They're usually CSS breakages and do not affect browsing that much.

Support for manifest v2 greatly outweighs these potential issues imo.

top 5 best things I've done in the last year

mah man

those damn romans, man...

one month would need to be more flexible for the division remain and leap years, but it would I suppose.

It makes budgeting easier, for one. But it's just a really arbitrary way to have a measure when a week is too little and a season / year too much.

man man

oh man

classic 5pm pussy breakfast

no wonder it was taking long to load; it's a 58MB HTML file.

really cool stuff though - I'd love to see more information of what's on the screen:

• Number of postings (updated when filtered using the search);
• Some way to visualize posts in the intersection of these clusters e.g. Software Dev with Education; AI and DevOps.
• Word cloud of most common terms in the posting selection;
• Ways to export the filtered data.

bit of a useless twitter post

alphaxiv https://www.alphaxiv.org/

example https://www.alphaxiv.org/abs/2407.15734v1

they have moved, but I wouldn't call a 40" TV large for almost 10 years now.

so... people who take typing lessons and actively try to improve it have better typing skills than the ones who don't. Shocking.

Because you're assuming foo won't be renamed when it becomes a function. A function should start with a verb, say get_foo(), because just foo() tells me nothing about what the function does (or what to expect as output). If you make it a property, get_ is implicit.

So if the age is computed from the year of birth for example, it's really e.g. thing.age or thing.get_age() - both of which are fine, but I'd pick the property version.

I like it. Months are useful on Earth, but their absence in other planets' calendars will go a long way to simplify things. Seasons can remain a function of Sols with periodic corrections over centuries to account for rotational speed changes.

that we agree on: properties should be cheap to compute.

Making a simple ternary condition as a function instead of property is a wasted opportunity to make its usage cleaner.

Properties make semantic sense. Functions do something, while properties are something. IMO if you want to name something lazily evaluated using a noun, it should be a property.

The misleading behavior is about what you expect to execute in the source code you're looking at vs what's actually executed.

What you describe is a logic ambiguity that can happen in any program / language.