mj's Logbook

Tag: programming remove

Hybermedia Systems

A book on htmx cowritten by the author of htmx.

books programming web htmx

1 month ago

Ted Kaminksi Article Archive

cs programming blog

1 month ago

Master the Go Standard Library

YouTube playlist for Golang Cafe’s series.

golang video tutorial programming

3 months ago


See Introduction to Unxtal, the assembly language, and Intro to Uxn Programming.

programming fantasy console

8 months ago

Build Your Own X

A list of tutorials for projects in various languages.

programming projects

1 year ago

Design of Computer Programs

A free course taught by Peter Norvig

programming courses peter norvig

1 year ago

The Raytracer Challenge

books programming jamis buck

1 year ago

Compiler Podcast: The Race to Replace C and C++

podcasts zig programming odin

1 year ago

Teaching How to Code is Broken

pedagogy programming

2 years ago


zig programming challenges

2 years ago

NASM Assembly Language Tutorials

asm tutorial assembly programming

2 years ago


“Learn RegEx step by step, from zero to advanced.”

regex tutorial programming

2 years ago

A Programmer's Introduction to Mathematics

Recommended by Keith Peters

books programming math

2 years ago

Let's create a basic CRUD with Rust using tide

rust tide programming web tutorial

2 years ago

The Little Book of Rust Macros

rust macros books programming

2 years ago

Malleable Systems Collective

Promoting malleable systems (programs/solutions that can be changed by the user).

programming design tools

2 years ago

Learn Go with Tests

books programming golang

2 years ago


languages programming lisp carp

2 years ago

Choosing an Error Handling Strategy

From Real World OCaml. The whole page on error handling is good, but I’m mostly interested in Exceptions vs explicit Result/Error types:

Given that OCaml supports both exceptions and error-aware return types, how do you choose between them? The key is to think about the trade-off between concision and explicitness.

Exceptions are more concise because they allow you to defer the job of error handling to some larger scope, and because they don’t clutter up your types. But this concision comes at a cost: exceptions are all too easy to ignore. Error-aware return types, on the other hand, are fully manifest in your type definitions, making the errors that your code might generate explicit and impossible to ignore.

The right trade-off depends on your application. If you’re writing a rough-and-ready program where getting it done quickly is key and failure is not that expensive, then using exceptions extensively may be the way to go. If, on the other hand, you’re writing production software whose failure is costly, then you should probably lean in the direction of using error-aware return types.

To be clear, it doesn’t make sense to avoid exceptions entirely. The maxim of “use exceptions for exceptional conditions” applies. If an error occurs sufficiently rarely, then throwing an exception is often the right behavior.

Also, for errors that are omnipresent, error-aware return types may be overkill. A good example is out-of-memory errors, which can occur anywhere, and so you’d need to use error-aware return types everywhere to capture those. Having every operation marked as one that might fail is no more explicit than having none of them marked.

In short, for errors that are a foreseeable and ordinary part of the execution of your production code and that are not omnipresent, error-aware return types are typically the right solution.

programming ocaml advice

2 years ago

Tools for Thought

Tools For Thought by Howard Rheingold

books programming technology

2 years ago