Good advice, clear, simple and to the point.
Stated otherwise: “whenever you need to add comments to an expression, try to use named intermediate variables, method or free function”.
Good advice, clear, simple and to the point.
Stated otherwise: “whenever you need to add comments to an expression, try to use named intermediate variables, method or free function”.
A fun read but it really seems that his writting style is hit or miss!
I never understood why python won agaist ruby. I find ruby an even better executable pseudo code language than python.
Awesome! It reminds me of that clip that uses the windows task manager to run doom on a 896 core CPU.
Read your own code that you wrote a month ago. For every wtf moment, try to rewrite it in a clearer way. With time you will internalize what is or is not a good idea. Usually this means naming your constants, moving code inside function to have a friendly name that explain what this code does, or moving code out of a function because the abstraction you choose was not a good one. Since you have 10 years of experience it’s highly possible that you already do that, so just continue :)
If you are motivated I would advice to take a look to Rust. The goal is not really to be able to use it (even if it’s nice to be able able to write fast code to speed up your python), but the Rust compiler is like a very exigeant teacher that will not forgive any mistakes while explaining why it’s not a good idea to do that and what you should do instead. The quality of the errors are crutial, this is what will help you to undertand and improve over time. So consider Rust as an exercice to become a better python programmer. So whatever you try to do in Rust, try to understand how it applies to python. There are many tutorials online. The official book is a good start. And in general learning new languages with a very different paradigm is the best way to improve since it will help you to see stuff from a new angle.
I wasn’t clear enough. But in a contry where the sun rise at 20:00, the weekday looks like:
And phares like "let’s meet on Tuesday“ without hour indication could either mean end of day 1 or start of day 2. Likewise "let’s meet the 20th” (assuming the 20th is a Tuesday) could either mean end of day 1 or beggining of day 2.
–
And alternative be to have
Which solve the issue of "let’s meet on Tuesday”, but not “let’s meet the 20th”.
The issue is that the notion of “tomorrow” becomes quite hard to express. If it’s 20:00 when the sun rose, when does tomorrow starts? In 5 hours ?
Interesting idea indeed. I’ve never used async yet, but I’m always surprised at how the problem space seems to be much more complicated than what it initially looks like.
You shouldn’t, it’s short and interesting
Yeah, this make sence
It’s also what I understood from what I read but I assume it was just a poor choice of word. Debug symbols are way too important for debugging to be stripped by default.
That’s only a summary of the introduction! The full story is much more interesting
Nice try kiddo!
That’s an interesting idea to use zig to test C code. It’s quite an achivement for zig to be better than C at testing C code. I really hope for them that this language will become popular.
And this post was interesting to see how a new user of zig approaches that language
That’s a very, very good read on how to make a very complex C project safer in practice. To sum-up: make it possible to introduce new module in a memory safe language (Rust in this case), make it harder to write bugs in C since the C part is not going to disappear overnight, and use as much tooling as you can to find any existing or newly introduced bugs (both memory bugs a logique error).
That’s extremely interesting and clear at the same time. This thesis is definitively a gem!
Something that I have never understood is why code ligature often try to combine two or more symbols into a single one. I like a lot what they did with “(” by fixing the vertical alignment of the “” while still keeping two separate symbols. I personally prefers when the number of symbols is preserved instead of merging them (like for “>=”).
I find “texture healing” a fantastic idea. It does indeed increase the readability of monospace font, without making them non-monospace.
IIRC the orbit of Mercure doesn’t work with Newton Model, and astronomers were predicted the discovery of Vulcain a small planet between Mercure and the Sun. So a new model had to be invented since Vulcain couldn’t be found.
I absolutely agree that method extraction can be abused. One should not forget that locality is important. Functionnal idioms do help to minimise the layer of intermediate functions. Lamda/closure helps too by having the function much closer to its use site. And local variables can sometime be a better choice than having a function that return just an expression.