This is actually a good question. For pretty’s much any previous president, the chance that they will be shot heavily outweighs the chance that they will shoot someone while in office. With trump, I think it’s more of an open bet.

Loudly cheer them on and clap when they finish.

Who dictates what’s stupid? Where does the sanity end and crazy name start?

Sanity ends when the name has an objectively high likelihood of causing the child harm, or otherwise severely hindering them in life. For example, naming your child “Hitler”, or “<insert slur of choice>” is objectively likely to be harmful to them. Likewise, naming them “Helicopter” or “Rollercoaster” is very likely to set them back in life through childhood bullying.

Who dictates this? In all countries I’m aware of that have laws around this: A government body of some kind.

Plenty of countries have this. Examples of forbidden names are “Hitler”, “Asshole”, “<Insert demeaning word here>”, and “Quisling” (name of a Nazi collaborator, commonly used as a synonym for “traitor” in daily speech).

The point is that “stupid” is defined as a name that is objectively likely to severely negatively impact the child. It’s not based on “I think X sounds stupid” but on whether “X” carries significant cultural baggage like being the name of a famous Nazi, a slur of some kind, etc.

These two are not interchangeable or really even comparable though? Make is a program that generates non-source files from source files, cmake is a high-level tool to generate makefiles.

If you’re writing anything more than a completely trivial makefile I would heavily recommend learning cmake. It makes your build system much, much more robust, far easier to maintain, much more likely to work on other systems than your own, and far easier to integrate with other dependent projects.

My primary experience with plain make was when I re-wrote a 2000+ line make-system in a project I maintain with about 200 lines of cmake, because we were setting up some CI that required us to clone and build some dependencies, which was an absolutely PITA to handle cross-platform with plain make, but was trivial with cmake.

PS. The cmake docs suck for anyone that hasn’t used cmake for 10 years already.

To be fair, I don’t think it’s “ridiculous” to sort e.g. jeans into the broad categories of “typically wider or slipper hips/thighs compared to length” or t-shirts into “typically broader back vs. typically larger chest”.

The mens/women’s categories are probably the coarsest categories that makes sense, since the average man’s and women’s body are so different in so many ways.

I recently learned that there’s a size rating for width. It goes from A to E, and says something about the length/width ratio of the shoe. Made my previous shoes a lot easier to buy (I also struggle to find wide enough shoes).

I never buy clothes online, exactly because I always try them on to check the fit before buying them. I haven’t measured my feet since I was around 15. I know my foot size, so I know that shoes in the range 42-43 are a good fit, depending on the shoe model. I don’t need to measure my feet when I buy shoes to confirm that they’re still around size 42.5.

The next best time is now

If my Easter break gets boring I might just start cleaning up that Python library… It’s the prime example of something that developed from a POC to a fully functional code base, was left largely unused for about a year, and just the past weeks has suddenly seen a lot of use again. Luckily we’re strict about good docstrings, but type hints would have been nice too.

I really do agree on all your points, so at the end of the day I think a lot comes down to use-case and personal preference.

My primary use cases for Python are prototyping and as a frontend/scripting tool for software written in C/C++/Fortran. In those scenarios, spending significant time on type hinting and unittests defeats the purpose of using Python (blazing fast development).

I’ve written/worked on only one larger code base in pure Python, and my personal opinion became that I heavily prefer strictly typed languages once the code base exceeds a certain size. It just feels so much smoother to work with when I have actual guarantees that are enforced by the language.

With that said, we were a bunch of people that are used to using Python for prototyping that developed this larger library, and it would probably have gone a lot better if we actually enforced use of proper type hinting from the start (which we were not used to).

Type hints are usually great, as long as they’re kept up to date and the IDE interprets them correctly. Recently I’ve had some problems with PyCharm acting up and insisting that matplotlib doesn’t accept numpy arrays, leading me to just disable the type checker altogether.

All in all, I’m a bit divided on type hints, because I’m unsure whether I think the (huge) value added from correct type hints outweighs the frustration I’ve experienced from incorrect type hints. Per now I’m leaning towards “type hints are good, as long as you never blindly trust them and only treat them as a coarse indicator of what some dev thought at some point.”

Then I absolutely understand you :)

How common it is 100 % depends on the code base and what practices are preferred. In Python code bases where I have a word in decisions, all Boolean checks should be x is True or x is False if x should be a Boolean. In that sense, if I read if x or if not x, it’s an indicator that x does not need to be a Boolean.

In that sense, I could say that my preference is to flip it (in Python): Explicitly indicate/check for a Boolean if you expect/need a Boolean, otherwise use a “truethiness” check.

I definitely agree that len is the preferred choice for checking the emptiness of an object, for the reasons you mention. I’m just pointing out that assuming a variable is a bool because it’s used in a Boolean context is a bit silly, especially in Python or other languages where any object can have a truthiness value, and where this is commonly utilised.

There is no guarantee that the comment is kept up to date with the code. “Self documenting code” is a meme, but clearly written code is pretty much always preferable to unclear code with a comment, largely because you can actually be sure that the code does what it says it does.

Note: You still need to comment your code kids.

Exactly as you said yourself: Checking falsieness does not guarantee that the object has a length. There is considerable overlap between the two, and if it turns out that this check is a performance bottleneck (which I have a hard time imagining) it can be appropriate to check for falsieness instead of zero length. But in that case, don’t be surprised if you suddenly get an obscure bug because of some custom object not behaving the way you assumed it would.

I guess my primary point is that we should be checking for what we actually care about, because that makes intent clear and reduces the chance for obscure bugs.

I would say it depends heavily on the language. In Python, it’s very common that different objects have some kind of Boolean interpretation, so assuming that an object is a bool because it is used in a Boolean context is a bit silly.

I write a lot of Python. I hate it when people use “X is more pythonic” as some kind of argument for what is a better solution to a problem. I also have a hang up with people acting like python has any form of type safety, instead of just embracing duck typing.This lands us at the following:

The article states that “you can check a list for emptiness in two ways: if not mylist or if len(mylist) == 0”. Already here, a fundamental mistake has been made: You don’t know (and shouldn’t care) whether mylist is a list. These two checks are not different ways of doing the same thing, but two different checks altogether. The first checks whether the object is “falsey” and the second checks whether the object has a well defined length that is zero. These are two completely different checks, which often (but far from always) overlap. Embrace the duck type- type safe python is a myth.

Of all youtube jackasses, this might be one of the biggest. Imagine making a living off pushing semi-scams on twelve year olds and being a nuisance at sporting events…

I agree on a general basis that it’s bad that these kind of decisions are offloaded to an AI. A human should be the one to consider whether the blind 70 year old is dangerous, because they definitely can be.

Operating a vehicle or weapon requires neither eyesight nor a clear mind if you don’t intend to do it safely.

I don’t mean to say that C++ is in any way without faults. If performance is crucial, that can definitely be a reason to forgo some of the guard-rails, and then you’re on your own.

I guess my issue with the “C++ is unsafe”-trope, is that it usually (in my experience) comes from people not having heard of all the guard-rails in the first place, or refusing to use them when appropriate. They write C++ as if they were writing C, and then complain that the language is unsafe when they’ve made a mistake that is easily avoided using stl-containers.