Software Maniacs blog

Here's a toy problem. Given a corpus of phone numbers for different countries determine a most prevalent display format in each country and use it to re-format an arbitrary phone number for its country. For example, if most US numbers in our data corpus are written like xxx-xxx-xxxx then the string (206) 1234567 should be converted to 206-123-4567.

For simplicity, let's assume that all numbers are local so we don't have to deal with complexity of international prefixes.

You wouldn't think a free syntax highlighting library would be a strong dependency for the development process of a business, and yet I'm waking up on a Monday to a flurry of comments and even one personal email from engineers eager to ask me to work for free for their employers.

So of course I took time to scathingly turn it into a teachable moment.

Hey, I almost managed an entire calendar year without a post! Not that I was ever adhering to any notion of schedule here, but I have to admit that lately I miss blogging more and more. It was nice to have a not-insignificant voice and be able to make some difference with things I used to care about, and still do.

Let's see if I can revive some activity here. No promises, of course…

I usually see HTTP status codes being checked as integer numbers:

if ((status >= 200) && (status < 300)) // or `<= 299`

This is rather verbose. But if you think about it, it's the first digit in the number that has a special value, and there are only five of them:

I thought I'd post something for no reason…

Tim Bray beat me to writing about this with some very similar thoughts to mine: Fixing JSON. I especially like his idea about native times, along with prefixing them with @ as a parser hint. I'd like to propose some tweaks however, based on my experience of writing JSON parsers (twice).

Almost exactly ten years ago on August 14 I wrote on this very blog (albeit in a different language):

So on yesterday's night I got worked up and decided to try and write [it]. But on a condition of not dragging it on for many days if it didn't work out on the first take, I've got enough on my mind as it is.

It did work out. Which makes August 14 the official birthday of highlight.js! Although it wasn't until 5 days later when the first meaningful commit was recorded. Using any form of source control was only an afterthought for me back then :-)

Working with pure functions is simple: you pass arguments, you get a result — no side effects happen. If, on the other hand, a function does have side effects, like mutating its arguments or global objects, it's harder to reason about. But we've got used to those too: if you see something like player.set_speed(5) you can be reasonably certain that it's going to mutate the player object in a predictable way (and may be send some signals somewhere, too).

Rust's ownership/borrowing system is hard because it creates a whole new class of side effects.

Catching up on my Rust learning diaries… Today I'm going to tell you about releaving my Lexer from its Pythonic legacy and what tangible results it produced, beside just being The Right Thing™.

We're now doing releases of highlight.js on a cadence of 6 weeks. The latest release 8.8 was the second in a row (which is what technically allows me to write "are now doing").