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.

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.

As I said: There are tools in place in modern C++ that are designed to catch the errors you make. If you are using a raw pointer when you could have used a reference, or accessing an array without range checking, those are choices you’ve made. They may be valid choices in your use-case, but don’t go complaining that the language is “unsafe” when it gives you the option to code with guard rails and you choose to forgo them.

Memory unsafe C++ is a choice. With modern C++ you have no excuse for accessing raw pointers or arrays without range checking if memory safety is a priority.

set -e

I actually enjoy this part, where I’ve written some intricate code of sorts and get to spend some time writing a memo that explains how it works.

I usually don’t even end up reading them, because the process of writing a good memo will make me remember it.

Don’t worry, referring to yourself in third person leaves enough of an impression that what you answer probably doesn’t matter all that much.

I wholeheartedly agree: In my job, I develop mathematical models which are implemented in Fortran/C/C++, but all the models have a Python interface. In practice, we use Python as a “front end”. That is: when running the models to generate plots or tables, or whatever, that is done through Python, because plotting and file handling is quick and easy in Python.

I also do quite a bit of prototyping in Python, where I quickly want to throw something together to check if the general concept works.

We had one model that was actually implemented in Python, and it took less than a year before it was re-implemented in C++, because nobody other than the original dev could really use it or maintain it. It became painfully clear how much of a burden python can be once you have a code base over a certain size.

I have next to no experience with TypeScript, but want to make a case in defence of Python: Python does not pretend to have any kind of type safety, and more or less actively encourages duck typing.

Now, you can like or dislike duck typing, but for the kind of quick and dirty scripting or proof of concept prototyping that I think Python excels at, duck typing can help you get the job done much more efficiently.

In my opinion, it’s much more frustrating to work with a language that pretends to be type safe while not being so.

Because of this, I regularly turn off the type checking on my python linter, because it’s throwing warnings about “invalid types”, due to incomplete or outdated docs, when I know for a fact that the function in question works with whatever type I’m giving it. There is really no such thing as an “invalid type” in Python, because it’s a language that does not intend to be type-safe.

The whitespace doesn’t bother me at all, but holy hell! Any time I’m trying to understand a Python program/library that’s anything above a couple thousand lines of code, I instantly feel a burning hate for dynamic typing.

I love Python for scripting- in large part because of dynamic typing. IMO it’s just not a language made for building large infrastructures.

That’s what major versions are for - breaking changes. Regardless, you should probably be able to fix this with some regex hackery. Something along the lines of

new_file_content = re.sub(r'(?<=\bprint)(\s+)(?!\()', '(', old_file_content)
new_file_content = re.sub(r'(print\(.*?)(\n|$)', r'\1)', new_file_content)

should do the trick.

For someone starting out, I would say that a major advantage of Python over any compiled language is that you can just create a file and start writing/running code. With C++ (which I’m also a heavy user of) you need to get over the hurdle of setting up a build system, which is simple enough when you know it, but can quickly be a high bar for an absolute beginner. That’s before you start looking at things like including/linking other libraries, which in Python is done with a simple import, but where you have to set up your build system properly to get things working in C++.

Honestly, I’m still kind of confused that the beginner course at my old university still insists on giving out a pre-written makefile and vscode config files for everyone instead of spending the first week just showing people how to actually write and compile hello world using cmake. I remember my major hurdle when leaving that course was that I knew how to write basic C++, I just had no idea how to compile and link it when I could no longer use the makefile that we were explicitly told to never touch…

Yes, it’s a field. Specifically, a field containing human-readable information about what is going on in adjacent fields, much like a comment. I see no issue with putting such information in a json file.

As for “you don’t comment by putting information in variables”: In Python, your objects have the __doc__ attribute, which is specifically used for this purpose.

My test suite takes quite a bit of time, not because the code base is huge, but because it consists of a variety of mathematical models that should work under a range of conditions.

This makes it very quick to write a test that’s basically “check that every pair of models gives the same output for the same conditions” or “check that re-ordering the inputs in a certain way does not change the output”.

If you have 10 models, with three inputs that can be ordered 6 ways, you now suddenly have 60 tests that take maybe 2-3 sec each.

Scaling up: It becomes very easy to write automated testing for a lot of stuff, so even if each individual test is relatively quick, they suddenly take 10-15 min to run total.

The test suite now is ≈2000 unit/integration tests, and I have experienced uncovering an obscure bug because a single one of them failed.

This is a very “yes but still no” thing in my experience. Typically, I find that if I write “naive” C++ code, where I make no effort to optimise anything, I’ll outperform python code that I’ve spent time optimising by a factor of 10-30 (given that the code is reasonably complex, this obviously isn’t true for a simple matrix-multiplication where you can use numpy). If I spend some time on optimisation, I’ll typically be outperforming python by a factor of 50+.

In the end, I’ve found it’s mostly about what kind of data structures you’re working with, and how you’re passing them around. If you’re primarily working with arrays of some sort and doing simple math with them, using some numpy and scipy magic can get you speeds that will beat naive C++ code. On the other hand, when you have custom data structures that you want to avoid unnecessarily copying, just rewriting the exact same code in C++ and passing things by reference can give you massive speedups.

When I choose C++ over python, it’s not only because of speed. It’s also because I want a more explicitly typed language (which is easier to maintain), overloaded functions, and to actually know the memory layout of what I’m working with to some degree.