mj's Logbook

World of Horror

games toplay

5 hours ago

Hack Design

Design lessons in your inbox

design tutorials

1 week ago

Passerine

“A small extensible programming language designed for concise expression with little code.” Keep an eye on this.

languages pl ml

1 week ago

Automat by Hopper

Where: Des Moines Art Center

paintings toview edward hopper

2 weeks ago

Coolors

Color schema generator

design tools color

2 weeks ago

Serenity by Maxence

Where: Musée d’Orsay

toview paintings edgard maxence Musée d’Orsay

2 weeks ago

Pinside

Info, reviews, market, forum, map of pinball machines.

pinball

3 weeks ago

Local Pinball

stl pinball

3 weeks ago

Pomax's Introduction to Japanese

japanese language

4 weeks ago

WaniKani

Spaced repetition system for learning kanji.

kanji japanese language

4 weeks ago

Tofugu

Another Japanese learning site

japanese language

1 month ago

Andrei Chis' Moldable Tools thesis

His old home page which looks like it’s still current.

tooling andrei chis

1 month 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 months ago

St. Louis City Talk

A blog written by a St. Louisan who spent a day taking pictures and writing about each of the 79 neighborhoods.

stl blogs city

2 months ago

HN complaint about data collection

This rant by Catsandkites is a nice summation of what a non-growth oriented company should strive for with a web product people pay for. I agree with all their complaints.

rant projects

2 months ago

Clojure by Example

A Clojure tutorial by Hirokuni Kim

clojure tutorial

2 months ago

The Clojure Language

A series of tutorial videos on Clojure by Brian Will.

video tutorial clojure

2 months ago

Tools for Thought

Tools For Thought by Howard Rheingold

books programming technology

3 months ago

Koyo

A web “toolkit” for Racket. There’s a nice video of the author building a url shortener here. Something interesting about this project is that it uses Racket’s contracts.

racket scheme web

4 months ago

Nighthawks

Where: Art Institute in Chicago.

toview paintings art institute edward hopper

5 months ago