Type-Safe Error Handling In TypeScript, Writing Python like it's Rust, Modern work requires attention. Constant alerts steal it, What are Casual Creators?
Now imagine a month later, you are working on your project when you or a colleague forget to wrap
makeHttpRequestinside of atry / catchblock.Two things happen here:
The compiler is no longer able to tell you whether your code is safe from runtime errors. In other words, using
throwis not typesafe. And is just as dangerous asany. They both dilute the benefits of using TypeScript in the first place. Because neither the compiler nor the types tell you thatmakeHttpRequestcan fail (read:throw), you will eventually get a runtime error. This is a waste of time, money and happiness for everyone. People begin to ask why they're using TypeScript if the compiler isn't helping them with something so basic as adding atry / catchblock. So the question is:How do we encode failability into the typesystem?
First, let's begin by acknowledging that
throwis not typesafe. We must use a different approach in order to get the TypeScript compiler on our side.
Un article intéressant sur la gestion des erreurs. Je n’avais jamais vu throw comme n’étant pas "typesafe". Et je réalise que d’autres langages sont dans la même situation et bénéficieraient de l’approche présentée ici, comme python. Même avec des type hints / mypy et tout ce que l’on peu utiliser pour rendre ce langage plus maintenable pour des projets complexe. Et je réalise aussi qu’implicitement j’étais en partie protégé de ce genre de choses en Java, car l’application ne sera pas "compilée" si une méthode contient un appel à une exception qui n’est pas gérée.
La proposition de l’article est intéressante, surtout pour gérer des cas d’erreurs avec le même flow d’exécution qu’un succès, et encore mieux si on a du pattern marching, comme souligné dans les commentaires. Mais comme le disent ces mêmes commentaires, la stratégie "never throw" n’est pas possible lorsqu’on interagit avec des dépendances qu’on ne maîtrise pas. Récemment j’ai fini par abonner une méthode de gestion générale d’erreur à l’événement unhandledException pour attraper et gérer d’une façon ou d’une autre tout ce qui n’est pas connu / géré (le but étant de les mettre en évidence à travers ce « catch all », d’avoir une façon générale et imparfaite de gérer le comportement des ces cas là et de réintégrer progressivement leur gestion au sein de l’application).
To be clear, by “guarantees” I don’t mean memory safety here (Python is reasonably memory safe as-is), but rather “soundness” – the concept of designing APIs that are very hard or outright impossible to misuse and thus prevent undefined behaviour and various bugs. In Rust, an incorrectly used interface will usually cause a compilation error. In Python, you can still execute such incorrect program, but if you use a type checker (like pyright) or an IDE with a type analyzer (like PyCharm), you can still get a similar level of quick feedback about a possible problem.
[…]
One of the sources of this mess is code that tries to track the object’s invariants at runtime. It has to consider many situations that can happen in theory, because they were not made impossible by the type system (“what if the client has been asked to disconnect, and now someone tries to send a message to it, but the socket is still connected” etc.).
[…]
The core of the problem is that the client can exist in various (mutually exclusive) states, but instead of modelling these states separately, they are all merged in a single type.
[…]
Object detection is a computer vision task that I sometimes work on, where a program has to detect a set of bounding boxes in an image. Bounding boxes are basically glorified rectangles with some attached data, and when you implement object detection, they are all over the place. One annoying thing about them is that sometimes they are normalized (the coordinates and sizes of the rectangle are in the interval [0.0, 1.0]), but sometimes they are denormalized (the coordinates and sizes are bounded by the dimensions of the image they are attached to). When you send a bounding box through many functions that handle e.g. data preprocessing or postprocessing, it is easy to mess this up, and e.g. normalize a bounding box twice, which leads to errors that are quite annoying to debug.
>
Des pratiques top pour du python un peu plus sûr ! Quelques exemples d’application viennent de l’expérience de l’auteur en machine learning, mais ceux-ci peuvent très bien s’utiliser dans les cas plus courants de réalisation de service classique ou BFF.
On top of that, we regularly juggle multiple tasks simultaneously. Our attention is pulled in multiple directions, regardless of whether you live an inbox zero life or not. Flow states require sustained attention over time, and our days get chopped into pieces by interruptions and meetings. Researchers at UC Irvine found that on average, office workers switched tasks or were interrupted about every three minutes. Recovering from those interruptions could take workers up to 20 minutes to get back to where they were. In fact, these interruptions could cost individuals up to six hours every day.
When we have multiple demands on our attention, we try multitasking—splitting our spotlight or shifting it rapidly to focus on the many tasks that come our way. The truth is, we’re bad at multitasking. There’s a mental cost to switching tasks, and that cost translates to up to 40% more time to complete the tasks. Small errors of inattention slip in—typos, missed cues, and quickly forgotten details. Even trying to do only two things at once can mean you do both badly.
J’ai placé celui-ci, assez court, ici rien que pour avoir les chiffres sous la main. Je compte les dégainer sous peu dans ma mission : le backlog n’est pas respecté par qui que ce soit, quand un sujet est considéré important il est traité comme urgent, et plusieurs contacts par messagerie asynchrone attendent une réponse synchrone. Adieu la concentration.
Why hasn’t anyone identified this field yet?
Partly, audience. Though there are exceptions, this field has traditionally been sold as a young, or female, which is a recipe for not being taken seriously by either academics or software engineers. It’s easy to spot a parallel with the field of casual games: both get derided as the amusements of “housewives” and “children”, as though these humans are less worthy of entertaining than…say, 26 year old male games engineers (or that engineers don't want to be playfully creative). Like casual games, they are often simple, and designed for short periods of engagement, rather than long term mastery, so those who have spent years mastering an extensive and arcane interface, whether Maya or Final Fantasy, are not often enthusiastic about something that attempts greater simplicity at the cost of reduced control.
But it’s also an economic problem.
Remember that part of the definition of a casual creator is “privileges enjoyment of the creative process above productivity”. Most of the creativity tools, like Maya, GarageBand, Photoshop, and Final Cut Pro, were designed for professional people who were trying to get work done. They are priced astronomically because they are sold, not to people, but to corporations who want their employees to do more work. Even a self-employed designer will not turn to a client and say “You know, I couldn’t really make the exact website you asked for, but I’ve made something surprising and I feel great about myself” and expect payment. It’s also telling that a lot of the creativity research is sponsored by the military, with the goal of enhancing workflow and generating better ideas.
This economic view creeps into our definitions of creativity.
Creativity is any act, idea, or product that changes an existing domain, or that transforms an existing domain into a new one.
Well, that takes care of all our world-changing creatives, those producers of creative acts of great cultural, social, and usually economic, significance. But we colloquially use “creativity” for many more situations than a universally novel, globally significant act of creation. We speak of children being creative, of moments of creative problem-solving in our daily lives, of creativity in art therapy or as a hobby.
[…]
To cite wallpaper designer, socialist and futurist, William Morris, we are creative so that “our days will be happy and eventful.” We can scientifically demonstrate that people who do art therapy are happier, healthier, more at ease, less in pain, and more social after having a creative experience. The existence of pottery-painting and paint-by-numbers kits shows proof that people enjoy being creative, even if the world won’t be noticeably changed by their output. It also turns out that restrictions, constraints, and support structures and guided assistance don’t fundamentally undermine the creative process, but often enhance it.
So if this type of human activity already exists, why make software for it? And why write about that software? As happens when any activity it translated into software, a potentially huge new world of possibilities arise that would not have been possible while then activity remained non-digital, but in many ways, it continues to fill the same niche. Chess became computer chess, but then also became Call of Duty and League of Legends, products that would not have been possible without the exploration of possibilities that were exposed when the desire for tactical competition made the jump to the digital space. And why write about it? Because this period of translation and exploration has just begun for Casual Creative software. It remains uncategorized, falling into a half-dozen different categories on the app store. The focus of thinkers and researchers, both in academia and in industry, remains focussed on “creativity support tools” and the broad, professional productivity tools, like Maya and Photoshop, while this area remains unexamined. And, for a field of such seemingly simple pieces of software, there’s a lot to examine.
Un article à part sur les outils et la créativité, ou plus spécifiquement sur les outils qui n’ont pas vocation à servir une quelconque productivité
