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.

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”.

I never understood why python won agaist ruby. I find ruby an even better executable pseudo code language than python.

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:

• day 1: Monday morning to Tuesday evening
• day 2: Tuesday morning to Wednesday evening
• day 3: Wednesday morning to Thurday,
• …

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

• day 1 == Monday == “end of the 19th” to “the start of the 20th”
• day 2 == Tuesday == “end of the 20th” to “the start of the 21st”
• day 3 == Monday == “end of the 21st” to “the start of the 22nd”
• …

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 ?

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 an interesting idea, but as someone else pointed using a voice modulator would be much better. Technical skills are importants, but human behaviors too. I would not trade a nice average coworker for someone who is better technically but doesn’t know how to communicate. And typing is complementary, not a replacement for voice communication since the amont of information you can share in a minute is 3-5 times higher by voice.

I don’t agree with the sentiment that debuggers are sub-optimal for Rust and that’s why they are not used. In C++, I hop in gdb all the time, and I’m very fluent with it. But I never had the need for it in Rust. So they may be sub-optimals, IDK, I never had an issue in Rust where the best tool would have been a debugger.

I would never do printf debugging in C++ because it’s too complicated to do. In Rust with Display/Debug it’s a breeze. And my best debugger for Rust is the compiler itself. But most importantly, most of my bugs are caught at compile time. The few remaining one are logic error and best analyzed with logging, aka printf debugging, and not a debugger that can pause the execution.

What do you mean by that?

It seems extremely interesting.

You seems to have a severe issue so I’m not sure what I’m going to say may help.

Learning something and then forgeting it is absolutely normal. Repetition over and exponentially long time and sleep in between helps a lot. Some people use flashcards to helps with memorisation. The idea is simple, when you learn something you write question + answers on a piece on paper (usually bristol for easy manipulation) and put it in a box. This box has multiple compartment: every day, every second day, once a week, once every second week, once every second month for example. When you add a card you add it to the “every day” compartment. Then each day you open all the compartment of the current day and ask yourself all the questions. If you correctly remember the answer you put it in the next compartment, and if you don’t you put it back to the “every day” one.

Another way to helps you understand and rembembering things is to explain them to others. If you don’t have someone to explain what you just learn you can create youtube video (even if noone will watch them but you do as if you had an audience). As bonus you now have a video that explains using your language something you just learn if you ever forget it!

Moving to git is nice but I don’t understand why they don’t self-host a gitlab instance.

step 1: learn to comment everything. This will helps code reviewer to catch errors because your code doesn’t match the comments

step 2: write your code in a way that makes comments useless and stop writting them

step 3: write your code just like you did in step 2, but documents all the things that you didn’t do, or why the code is more complicated than the naive approach. If your arguments are weak you are not in step 3, but in step 1.

It’s especially true when you want to parse some json/xml/whatever. Just describe your datastuctures with regular struct and enum, add serde and done! It’s like magic!

Syntax has never really be an issue. The closest thing to plain english programming are legal documents and contracts. As you can see they are horrible to understand but that the only way to correctly specify exactly what you want. And code is much better at it. Another datapoint are visual languages like lego mindstorm or LabView. It’s quite easy to do basic things, but it doesn’t scale at all.

I definitively love llogic comments when he(she?) has no submitions for the quote of the week!

That was a fantastic read. I’m both impressed by the stellar performance of C, and the stellar safety of Rust while keeping nealy best in class performances.

I do understant why old unicode versions re-used “i” and “I” for turkish lowercase dotted i and turkish uppercase dotless I, but I don’t understand why more recent version have not introduce two new characters that looks exactly the same but who don’t require locale-dependant knowlege to do something as basic as “to lowercase”.

Yes exacly. And I assume that the test suite of all of those project are long enough to average the usual jitter of wall time mesurement.

What I’m hoping to see is if rust+llvm vs rustc+gcc binary speed are within a few percents or if there is a real difference between the two (I’m expected that we eventually reach the former once thinLTO and other optimisations are implemented).

And while doing so it could also be possible to measure the difference in max RSS.