Python 3.12

It's not in the highlights, but one of the things that excites me most is this: https://docs.python.org/dev/whatsnew/3.12.html#pep-669-low-i...

> PEP 669 defines a new API for profilers, debuggers, and other tools to monitor events in CPython. It covers a wide range of events, including calls, returns, lines, exceptions, jumps, and more. This means that you only pay for what you use, providing support for near-zero overhead debuggers and coverage tools. See sys.monitoring for details.

Low-overhead instrumentation opens up a whole bunch of interesting interactive use cases (i.e. Jupyter etc.), and as the author of one library that relies heavily on instrumentation (https://github.com/ipyflow/ipyflow), I'm very keen to explore the possibilities here.

Check out D language, it should be suitable for math, signal processing, data science, embedded, etc, and it's intended to be better than Fortran, C and C++ [1].

[1] Is Fortran easier to optimize than C for heavy calculations?

https://news.ycombinator.com/item?id=37606477

I’m speaking from my real-life lived experience with dynamic typing. I feel that dynamic typing is truly harmful for any project that involves involving complex logic, needs collaboration / where there’s more than 1 person working on it, or even for any large project (even if only 1 person is working on it).

It was a massive waste of time to have to read piles of code code, use a debugger and inspect object structure, to understand how some parts of certain large codebases worked.

In my experience, dynamic typing has simply been horrible for team collaboration, code readability (and ease of understanding), and it results in a large number of bugs that could easily have been eliminated with static type checking.

> But this debate is decades old and people always dogmatically choose one side, so not really any point in trying to convince you.

You’re right about that. I am indeed very dogmatic and take a hard-line on this. I take a stronger position on this than most things (for example: something very subjective like curly braces versus white space indentation), to the point that I’ll say this: dynamic typing is simply a wrong and bad engineering decision.

Another example of a bad language design decision is allowing null to be a part of every type instead of requiring an explicit ? in the type, or the use of an Optional wrapper. This has been recognized as an ill, andis something many modern languages (to name a few: Rust, Kotlin, etc) fixes.

But that isn’t meant to level a personal attack against the languages designers of the past (or to say that they were stupid). Allowing every type to be Union[T, null] was a simply a language design mistake (that potentially cost wasted billions of dollars), but it's been recognized as a mistake today that we need to rectify and move forward from (as is reflected by decision made by more recent languages).

However, imo, in comparison, dynamic typing is a 100 times worse than not having null safety (or not having memory safety like C or C++). I can work with a C or C++ without much trouble, but not with dynamic typing. Dynamic typing makes it difficult and unpleasant to work with a large codebase, to an inexcusable degree.

Well, who hasn’t used that classic datastructure `dictstack` (and famously the dict.pop operation)?

At first I was kinda giggling. But actually there are such things, if the Mapping is also ordered.

LRU cache, trees, tries… and—oh wait—all CPython dicts are ordered these days!

(Honestly I have only used the modern ordered-nature of `dict` for serialization to versioned or human-editable files. But why not an algorithm with a “`stackdict`” I guess?)

A couple big things: Fortran natively performs operations on arrays directly like Matlab or Numpy in Python (Matlab was originally a REPL-style front-end to Fortan), and Fortran compilers tend to yield quite fast code (though specific cases will have another language outperform Fortran).

You can read more about the language and its high-level features here: https://fortran-lang.org

That website/community was created in part by the original author of the Python Sympy library, Ondřej Čertík. He is also working on his own Fortran compiler that you can use via webassembly to play around with Fortran; find links if you want to play here: https://lfortran.org

I've only dabbled a little, but I like the general idea, and I appreciate a F/OSS Fortran compiler being developed like this alongside actively seeking to grow the Fortran community & push the language & its libraries forward.

I expect more widespread adoption of Fortran to be quite a ways out, but what Ondřej is doing for Fortran is necessary (not sufficient) for such adoption to be the case.