This revises my Keyword structs post to fix some mistakes, discuss the struct* match pattern, and rewrite the macro to use syntax-parse and support default arguments.
A good rule of thumb in Racket is to use a struct instead of list when you’re juggling more than two or three items.
My first-ever open source contribution, a couple years ago, was to a project called Pygments. My motivation? GitHub was displaying Racket source code poorly. Pygments didn’t have a Racket lexer. GitHub was using a Scheme lexer for Racket code. The Scheme lexer was highlighting square brackets in red as an “error”. This was really distracting and ugly.
I contributed a new Racket lexer to Pygments, and waited for that to roll into a Pygments release and in turn be deployed on GitHub. Finally Racket code looked good! Later Dave Corbett substantially improved the Racket lexer beyond my small start.
A few days ago, I was confused to see that Racket code was displaying poorly again on GitHub. The square brackets were highlighted in red as errors — again??
Cartoon-me’s thought balloons: WAT, OMFG, FML, &c. Why are we going in circles?
I haven’t posted here in awhile because I’ve been busy with a variety of things in September, including an interview for IEEE Computer magazine and a talk about Frog at RacketCon. And I’m writing this in Japan.
A C programmer preparing to use pointers
Someone1 in my Google+ circles posted about Understanding and Using C Pointers, a fairly recent (May, 2013) book by Richard Reese.
In my experience, the way to become a better programmer is to:
To learn why you should skim this post, please read it carefully.
In general I’m a big fan of web apps for many reasons:
You don’t need to migrate data when you buy a new computer or mobile device.
You don’t spend a bunch of time updating apps for security or improvements. Doing so may be easier on a mobile device than on a desktop. But there are days when my phone does more work updating apps than me actually using it.
Synchronization sucks. Using multiple native apps with local stores requires synchronizing state. Essentially this is N/A with a web app because the data is stored in one place. (Note: Caching doesn’t suck; just synchronizing.)
Developers can iterate and experiment — “release constantly”. This may sound like it’s an advantage for devs, but to the extent it makes better apps and saner feature accretion, it’s good for us, too.
Easier to hack, by which I mean customize for individual needs and preferences.
Easier (and generally safer) to use hacks created by others (in the form of browser extensions).
So great. But obviously the Google Reader shutdown brought me up short. Shook my faith. Am I wrong to prefer web apps?
On reflection, there are two reasons why it’s still OK to prefer web apps.
NOTE: You may want to skip to Keyword structs, revisited.
A good rule of thumb in Racket is to use a struct instead of list when you’re juggling more than two or three items.
UPDATE: This was an early post. For up-to-date info, see Frog.
When the code settles down a bit I’ll put it in a GitHub repo, and write a full README.md. Meanwhile, here’s an overview.
OK, I have my site generated using Frog and pushed it to GitHub Pages for http://www.greghendershott.com.
I want to tweak the CSS. It’s vanilla Bootstrap. Most importantly, I wish the headings were a few points smaller and the body text a few points bigger.
The other remaining item is to do the 301 redirect from Blogger to here. It turns out that this should be ridiculously easy to do with Amazon S3. You can make a bucket that does nothing but perform 301 redirects. I’ve created such a bucket already, and the redirects work fine. I simply need to update my DNS, for which I’m using Amazon Route 53.
I’d been trying to stick to a roughly Tuesday and Thursday schedule for posting here.
I haven’t this week because I’ve been trying to work up a replacement for using Blogger.
Basically, I want to write posts in simple Markdown, and generate the blog statically. To be hosted on GitHub or S3 or whatever. And I want it to use Bootstrap so I don’t have to reinvent that wheel.