This is Part 2 of a look at the software I used at the start of my career. Be sure to read Part 1 for some background on Pick and how I came to work with it so late in its history.
In many ways, my work & free time used to be the opposite of what they are now. I used to spend 9–5 working on obsolete technology and come home to play with the latest web platforms. Now, I get paid to work with the hottest web technologies and kick back with vintage machines for fun.
If I wanted to stick with Pick, I could’ve written my own ticket anywhere. Pick developers are in short supply, and toward the end I was passing up gigs all over the world. I even turned down a company that offered to rent me an apartment in Paris just because the contract involved Pick. Out of desperation, I had taken a job with an obscure, obsolete platform, and now that’s all anybody wanted me for.
You think recruiters are calling you a lot? I got calls every day, several times a day, all with amazing opportunities…in Pick. I sent out resumes every week for jobs doing C++, Java, and Javascript, but without work experience in those languages I was back to being entry level, only with higher salary and benefit expectations because by 2003 I had four years of experience, a spouse, and a mortgage. I even applied for internships, offering to work for free and bring my experience to the job in exchange for a line on my resume, but nobody wanted me. Every day, I dreamed of getting away from Pick and writing real, modern software for a living, but that day didn’t come until 2005.
Post-relational before it was cool
Today, NoSQL or post-relational datastores like MongoDB and Redis are hot, winning mindshare in industries where Pick never caught on. As a schema-less system, Pick was decades ahead of its time. But Dick Pick’s innovation wasn’t the database itself. What set GIRLS apart was right there in the name.
GIRLS predated SQL by almost a decade, so I guess it can be excused for zigging when the rest of the world zagged. The Information Retrieval Language in GIRLS was called English, and it lived on in Pick’s various incarnations until it evolved into Access — not to be confused with Microsoft’s English Query tool or Access database. And if you used UniData or UniVerse, two popular Pick variants, the language was called UniQuery because…who knows?
Like I said, English predates SQL, and may have even influenced it. This SQL query:
SELECT first_name, last_name FROM employees WHERE state = “MA”
would look like this in English/Access:
LIST EMPLOYEES WITH STATE = “MA” FIRST_NAME LAST_NAME
Not too bad, huh? FIRST_NAME, LAST_NAME, and STATE map to entries in the EMPLOYEES file’s dictionary, which tells the system to look in a certain attribute and maybe a certain multivalue or subvalue inside of it. And just to make things interesting, you use WHEN instead of WITH if there are multivalues involved. There are also modifiers splitting up multivalues for display. See the UniQuery documentation for more examples if you’re curious.
Things might have been fine if Pick acted like a key/value store, but Access tried to make Pick act like a relational database with a query language and loose foreign key relationships defined in its dictionaries. It never was a good fit. Queries just got downright goofy.
Also, there’s no such thing as an INSERT or UPDATE query in Pick. For that kind of data manipulation, you have to use the line editor. Yes, a line-based editor like the old EDLIN editor that shipped with MS-DOS or the ed editor in Unix.
You could also use PickBASIC.
PickBASIC
In addition to being an operating system and database, Pick has its own programming language called PickBASIC. Except on UniData & UniVerse, that is, where it’s called UniBASIC. PickBASIC shouldn’t be confused with PicBASIC, a programming language for microcontrollers. PicBASIC is way better. I mean, it doesn’t come with a database, but you can make LEDs blink on & off. Ask any three year old which is cooler!
PickBASIC programs are stored as records in a Pick file (table) and edited with the line editor. Most Pick users keep a single file for programs, and PickBASIC stores compiled bytecode versions in the file’s dictionary.
PickBASIC is really similar to the BASIC on those 8-bit computers I loved as a kid (and still do!). The main addition is a set of commands for running queries to retrieve a list of primary keys and reading those records one at a time. There are also functions for manipulating multivalues and subvalues in a string.
And, yes, there is a GOTO command.
Pick has a debugger to step through running processes line by line, and it also lets you edit values deep within the Pick runtime itself. I once witnessed a senior Pick support engineer rescue a mostly-crashed system by commandeering a telnet session that was still responsive and messing with the runtime’s memory.
Recognizing that PickBASIC wasn’t enough for a modern application, modern Pick versions include ways to call C functions linked against the Pick runtime, and can even call into native functions for socket I/O and access to the host’s filesystem. At one job, the sysadmin refused to install curl or wget on the underlying Unix so I wrote my own web server and HTTP downloader in PickBASIC, using the socket interface. I wish I still had that code to throw up on Github.
This proprietary setup made it practically impossible to work with IDEs, version control, diff tools, and other things we take for granted in modern software development. Pick developers have a strong cowboy coding culture, reinforced by this major difference in toolsets.
In Part 3, I’ll tell you what on Earth I was using this technology for in the early 2000s and how I escaped.
