Jonathan Hartleytartley@fosstodon.org
Sep 1, 2026, 5:43 PM@wronglang I have no exposure to academic / numerical computing, having only worked in commercial / industrial domains, and have never run Jupyter, nor ever seen a peer running it at work.
Replies
- Jonathan Hartleytartley@fosstodon.orgSep 1, 2026, 5:56 PM
@wronglang like, as an illustrative example that would have horrified me in my C++ days: currently working on a 15 million line codebase, and consider type annotations an occasional "nice to have", 50% for the purpose of documenting intent to future human readers.
Krzysztof Sakrejda 🏳️⚧️ 🏴☠wronglang@bayes.clubSep 1, 2026, 7:01 PM@tartley I would take rust or c++ over that any day but instead most of the code I write is in R out of necessity for collaboration so.. I can't judge.... 🫣
- Jonathan Hartleytartley@fosstodon.orgSep 1, 2026, 7:44 PM
@wronglang well, I used to be a straight static typing zealot, so I hear you, but on the other hand, I began wading through so much evidence to the contrary that eventually I snapped and flipped like only a true believer can.
- Jonathan Hartleytartley@fosstodon.orgSep 1, 2026, 7:46 PM
@wronglang By way of one example: I ran developer interview questions as a side-role for a few orgs now, and keep detailed stats. On questions designed to be language agnostic (which tend to be pretty unfriendly to Python tech and culture, eg. consisting of complex byte twiddling exercises.), when candidates are allowed to choose their own programming language...
- Jonathan Hartleytartley@fosstodon.orgSep 1, 2026, 7:49 PM
@wronglang The candidates who chose Python average 2.6 times the successful progress through the problem in the allotted time than the next best scoring language, Go.
This goes back to what I said about making code simpler and more expressive. They literally make the problem simpler by building abstractions that required them to write less code. Python lends itself to that, and if one is going to take a stand about theoretical correctness, one had to at least understand data points like this.
- Jonathan Hartleytartley@fosstodon.orgSep 1, 2026, 7:55 PM
@wronglang Because those rapid Python solutions were correct. We built extremely robust test suites to run against candidate solutions, precisely to uncover subtle bugs not evident from experienced inspection. So if that can be true under some circumstances, how much is the type safety really buying you? Figuring out the boundaries and nuance there, on both sides, is huge.
- Krzysztof Sakrejda 🏳️⚧️ 🏴☠wronglang@bayes.clubSep 1, 2026, 9:33 PM
@tartley you do have the issue of measuring two correlated things: Pr[success], Pr[choose python] whereas what you want to measure is Pr[success|chose Python] ... but that said I wouldn't have a problem with choosing it over something more strongly typed for any project I've been involved in. In academic code usually the problem is being able to get a team to work coherently at all so you gotta be flexible on technical details.
- Jonathan Hartleytartley@fosstodon.orgSep 1, 2026, 10:30 PM
@wronglang Right, that is true, with the probabilities, but given constrained time and resource, which is always the case, we are lumping the 'not finished yet' solutions in as pragmatically equivalent to the 'not demonstrated bug free' solutions, in which case the numbers I quote above is the final measurement we actually want.
But yeah, it's not a ubiquitous slam dunk. There are times when taking extra time to gain extra correctness confirmations is worth it.
- Jonathan Hartleytartley@fosstodon.orgSep 1, 2026, 10:49 PM
@wronglang oh and, forgot to say explicitly, choosing the right tool is one of the skills we desire to hire. Where "right" means "whatever tool solves the following problems more correctly, maintainably, and implemented faster than the next guy"