BLOG POSTS

READING A PAPER: DERIVATIVES OF REGULAR EXPRESSIONS RE-EXAMINED

R

Reading paper in computer science is itself an important skill, one you should master. I've detailed some of my problems before in my series on A Play On Regular Expressions, and now that I have a little free time on my hand I'm going to dive into some of the issues that I want to cover in the future.

My Regular Expressions series talked mostly about two different papers: Fischer, Huch and Wilke's A Play on Regular Expressions, and Matt Might's Parsing with Derivatives. One isn't about Brzozowski's derivatives at all; it's about identifying a common mathematical principle by which the boolean yes/no Finite State Automata of the classic Kleene Algebra can be tranformed into a Finite State Transducer by abstracting "up one level" what the automata does. The second describes a long-neglected algorithm for solving the Kleene Algebra that promises some interesting characteristics. My contribution was to show that these papers are compatible— that Might's combinators are actually semirings in disguise— and that Brzozowski's algorithm can be expressed in a systems language with strict memory requirements.

But that's not where the story starts. The story starts with two other papers, one of which I'll be reviewing today. The first paper is Joshua Goodman's 1999 paper, "Semiring Parsing," which I'll be addressing later.

Today's paper is

Regular Expression Derivatives Re-Examined

... by Scott Owens, John Reppy, and Aaron Turon.

Continue Reading

THE TRANSFORMATION PRIORITY PREMISE AND FUNCTIONAL LANUGAGES

T

Alice laughed. "There's no use trying," she said. "One can't believe impossible things."

"I daresay you haven't had much practice," said the Queen. "When I was younger, I always did it for half an hour a day. Why, sometimes I've believed as many as six impossible things before breakfast."

I know I've commented before on how, while Clean Code has its place, there are adherents who adhere to it so literally and unthinkingly that they've constrained their careers and condemned themselves to the same silos for the rest of their professional lives.

Continue Reading

NOTESMACHINE: THE LAYOUT PROBLEM

N

As I'm building out the design and model of Scarlett (which seems dangerously likely to get renamed 'Notesmachine' at the rate I'm going), I've hit one of those architectural things that annoys me. Allow me to ruminate on the problem.

As mentioned in the previous post, the traditional organization of any notes system is that of the Forest; each Box contains notes, some of which are the roots of trees, and the rest of which are nodes of the tree leading to leaves, which are notes that have no descendant notes.

On the other hand, I have interests that are orthogonal to that design. Let's take them in order:

Continue Reading

A WILD INSIGHT INTO MY CAREER

A

There's a difference between "What you do" and "What you really do."

An I mentioned earlier, I'm looking for work. Given that I'm not working, and doing the looking only takes half the day, I'm spending the other half of the day diving back into Rust. Those two events came together in a conversation I had today with a "career coach" in an unexpected way.

My career coach loves my elevator pitch:

I have a very broad range of experiences, but what I do comes down to this: using industry standard application servers like Django and Swagger for the back-end and familiar tools like React or Backbone for the front-end, I build user interfaces for complex business process that make them easy to understand and a pleasure to use.

Continue Reading

NOTESMACHINE: ARCHITECTURAL DESIGN RECORD

N

If you're like me, you have more than one hard-drive full of random stuff: notes, PDF files, Epub files, ZIP and TAR files, GIT repositories of (mostly incomplete) projects, and so on and so forth. Also, if you're like me, these projects devolve into a bunch of different areas: my professional life, my artistic and creative life, my open-source footprint, my personal life like my kids and my wife, the infrastructure of my life like the current projects in home maintenance, and in my case an imperial buttload of recipes.

My Rust has gotten rusty, so to speak, so I've decided to try and write something to help me manage it. This post is mostly me rambling about what I'm going to write, gods help us all, and how I want to manage writing it.

Basically, I want a knowledge base. That's it. That's the simplest thing possible. In fact, pretty much what I want is some kind of Roam clone, but one with extra superpowers.

I'm going to use a term that doesn't exist in the real world: "egotonin." Egotonin is a mythical substance that gets used when you're exerting willpower; it is the thing that is depleted in the concept of ego depletion.

So lets talk about Knowledge Bases.

Continue Reading

ORGANIZING YOUR BASH PATH

O

If you've ever looked at your .bashrc file and wondered how the heck it got so weirdly out of control, look no further than the slow migration of "local changes" to the .local folder, and the number of language– or framework-specific environments that are now kept there.

There's much to recommend this move, not the least of which is decluttering the $HOME directory. But my biggest pet peeve was the $PATH variable, which seemed to just grow and grow in my .bashrc file into an unreadable string. I've decided to fix that. Here's how.

Continue Reading

HOMEWORK ASSIGNMENT: WHAT I LEARNED

H

I just finished one of those take-home programming assignments that companies are sending out these days in lieu of whiteboarding exercises, a process that I'm genuinely thankful for. Whiteboarding is just a way to stress someone out; it doesn't prove anything (except excessive cleverness, sometimes). We work with a fully immersive IDE (even if Emacs is still making itself difficult in that regard), we work with StackOverflow available, and we work surrounded by books, notes, and cheatsheets. We even work with our fellow workers on the other end of Slack and Zoom.

A lot of what I did was "re-learning," but it's always good to go over it again, just in case. Here's a lot of what I absorbed:

Continue Reading

A NEW LOOK FOR A NEW PHASE

A

You may have noticed a few changes in the place. I've gone to an all-static engine. I chose Zola, because although it wasn't sufficient for what I wanted out of my story site, it's perfectly fine here.

Continue Reading

WORKING ON SCARLETT 2.0, AND THE SQL IS FUN!

W

I’ve been hacking on a secret project that I’ve had in the works since, oh grief, the first check-in was:

<code>commit ccb93ca5f2b256babfa0f2ef9110ac0ac4019527
Author: Elf M. Sternberg <elf.sternberg@gmail.com>
Date:   Mon Feb 4 23:03:01 2013 -0800

Initial check-in for Scarlett.</code>

The original project (yes, it’s named “scarlett”, deal with it) was in a combination of Python and Javascript, with Backbone as the front-end. It was, quite frankly, a terrible project, but it did what I wanted it to: it kept track of my notes. I have a directory named “Wiki” into which I dump markdown files, and have for years, and all it does is give me a slightly better UI for ‘grep,’ but it’s better than nothing.

Continue Reading

IF YOU CAN SPOT THE LEAK IN AN ABSTRACTION, YOU CAN DESIGN ALMOST ANY PROGRAM

I

I’m going to use the word “abstraction” in two different ways, but bear with me for a moment and consider this:

  1. Every startup is based on an insightful abstraction of a complex idea.
  2. Every software abstraction is leaky in some critical way.

Uber is an abstraction of taxis. How do we abstract “what a taxi is” using the higher-level technologies we have now? Amazon is an abstraction of mail-order sales, which have been around since Sears pioneered them in 1897. Google is an abstraction of card catalogs and yellow pages. And so forth.

In programming, an abstraction is a higher-level description of a process or mechanism that is designed to hide some level of complexity behind a simple set of controls. The menu on a word processor hides the complexity of the software behind it. The API we use to “log in with Facebook” or “log in with Google” hides the complexity of securing your authorization across multiple websites and applications while revealing your identity to advertisers.

Continue Reading

IS AGILE COMPATIBLE WITH CLEAN CODE?

I

I’ve been through Agile training several times before at different jobs, and the current job is no different. June is Agile Training Month, and since I started last September I’m obliged to go through this again. Previously, we had a Clean Code Training period that lasted two months, and I realized today why I’m having such a hard time with the Clean Code part of the training.

The Agile process says that the product should have value to the customer at the end of the first month, and that the value to the customer grows as the development team puts more intellectual work into building out its functionality.

Continue Reading

REVIEW: CLEAN CODE, BY ROBERT MARTIN

R

It might seem like I’ve been harsh on Robert Martin’s Clean Code for the past couple of posts, and that’s valid. I have been. It’s such a good book, full of strong advice on any number of topics.

It’s just that it feels old. Programming is a young discipline in the world, probably one of the youngest, and one of the most consequential. It changes with absurd speed, and everyone in it struggles to keep up. Clean Code came out in 2006 and already there are dusty corners within that feel out of date, even irresponsible.

Continue Reading

IF YOU'RE A SENIOR DEVELOPER, YOU HAVE TO ACCEPT SOME WET CODE.

I

In some programming languages there is an essential, powerful tension between two common pieces of advice: Don’t Repeat Yourself and Meaningful Names over Code Comments. Both are really good pieces of advice.

“Don’t Repeat Yourself” (DRY) means that if you can find an abstraction that allows you to avoid repetition in your code, you can remove the need to debug multiple code blocks if you find an error, and you can test the abstraction more reliably and more efficiently. The opposite of DRY is, of course, WET, “Written-out Every Time.”

“Meaningful Names over Code Comments” means that if you have strong, descriptive names for classes, functions, and variables, then code comments are often not merely unnecessary but possibly harmful as they drift out-of-date with the actual content of the code.

At my ${DAY_JOB}, I ran into this conflict in a big way. This example is in Python, but it applies to any language with metalanguage capabilities, which includes Ruby, Lisp, Rust, and even C++.

Continue Reading

DEAR "CLEAN CODE" FANBOYS: SQL IS A PROGRAMMING LANGUAGE.

D

One thing that irks me beyond all reason is Robert Martin’s seething dislike for databases. In every presentation he’s ever given, the one thing he’s sneered at is people who “write their code around a database.” In one of his lectures he says, “I don’t want to see a database in your design. I want to see the objects you’ll use, and I want their names and locations in your project file to reflect how you’ll use them.”

This is probably the lousiest piece of advice he’s ever given. Because let me say this once and simply:

SQL is a programming language, not a storage mechanism.

Continue Reading

"CLEAN CODE" IS THE CODE SMELL OF A MISSING LANGUAGE FEATURE.

"

Uncle Bob has a passage early in his book where he criticizes the function below, calling it “too long” and “missing context”. I agree that it’s cluttered and hard to read, but his representative solution is, frankly, absurd. He turns this into a C++ class with static methods for providing the modifiers to the text, all the while ignoring the huge elephant in the code: it does two things.

Continue Reading

LAB NOTES, FIRST TWO WEEKS OF JANUARY: PAMSEAM W/LATTICE EXPERIMENTS

L

Lab notes for the first two weeks of January.

I’ve been fiddling with a branch of the PamSeam project named Lattice in an effort to streamline the base and speed up the runtime. There are three algorithms enabled and all of them have similar processes. The basic engine is also very slow, with lots of large allocations and copying the image over and over.

Continue Reading

MATH IS NO HARDER THAN DRAWING

M
My great legacy to the world, a small bit of observability in web server configuration.

I recently read an article on the economics of ancient Rome that suggested that, while the written arts, especially those that involved education or erudition, were highly valued, the visual and performance arts were not. The visual arts, especially, were regarded as the work of the lowly and demeaned, as almost all the arts we see from Rome, Pompeii, and Herculaneum, all of the frescoes and mosaics that have survived to this day, were made by slaves.

Continue Reading

MY NEW JOB REQUIRES I AVOID LEARNING SOME THINGS!

M

I realized the other day that my role in my current job requires that I do something very, very strange, as far as I’m concerned. I realized there are some things I have to avoid learning, and I have to avoid them quite strenuously. I have to know they exist, but I have to not know any more than that.

One of my tasks is to help software engineers write their own tests and documentation. To be good at that, I have to help them focus on the kind of documentation they’re writing, and at the moment that documentation is “pager duty” how-tos: short instructions for how human beings must respond to problems and issues with the running system.

Continue Reading