Dark Chocolate, Dark Coffee, Dark Mode, All Good

Back in the monochrome days of PC computing, our choices were green on black, or amber on black.  The amber monitors actually cost a bit more because European studies of the day showed amber was easier on the eyes.

Apple's Macintosh Computer introduced the black text on white paper look.  In emulating paper though, I found my eyes fatiguing more quickly.  I expressed to a friend and colleague that it felt like a swath of electrons beaming into my eyes, in which he replied, "okay."

To this day, I'm not sure if he was in solid agreement, or patting my head and humoring me.  Judge for yourself with the sample color schemes I've created at the end of this post.

With macOS Mojave, Apple introduced Dark Mode, which in essence, is a return to the calm and focused energy levels of green, amber, and black. I really like it, but one cannot live on dark chocolate and dark coffee alone.  We can switch between Dark Mode and Light Mode via the System Preferences.

But wouldn&#…

Bookshelf Classic: The Mythical Man-Month

More than 250,000 copies were printed, and yet, that was not enough to spare me countless programming and management fads.  So popular was this title that it earned a 20th Anniversary Edition and still, buzzwords like "pair-programming," "open workspaces," "test driven development," and "military style management" forced their way into my vocabulary.
Frederick P. Brooks, Jr., in 1964, managed the software side in the creation of the IBM 360 Mainframe Computer.  Working on the famed project also afforded him a view of the hardware management side, and by way of comparison, he noticed that no developments in software could, or ever would, improve productivity, reliability, and simplicity in the same way hardware improved with advances in electronics, transistors, and large-scale integration.  Noting Moore's law, Brooks writes "We cannot expect ever to see two-fold gains every two years." 
The essays in The Mythical Man-Month shed lig…

A Tale Of Two Sundials

It was the best of times, it was the worst of times, ... it was the season of Light, it was the season of Darkness, it was the spring of hope, it was the winter of despair ... With apologies to Charles Dickens, I am writing about two sundials on Cornell's campus. One is outside Goldwin Smith Hall in the Arts Quad while the other is in the Engineering Quad.

As an undergrad, I didn't pay much attention to either of these works of art.  Apparently, neither do current students as they hurried past me while I was taking pictures.

But these two sun dials merit contemplation.  One is from the past, and with the gravitas that a layer of patina brings, provokes thoughts of time and mortality. The other looks outward, and with modern, shiny arms, seeks to embrace a future where the sky's the limit.

When family and friends talk about college, and when college bound students ask me what they should study, I show them these two photos and ask them which one piques their curiosity.


Tools Of The Trade

"Like many artists, I am very attached to my brushes. I love them all individually and I’m very familiar with their individual characteristics. I can distinguish between brushes of the same make, series and size. I know their degree of spring, their shape, their balance, and, most importantly of all, the marks I can make with each of them."

This was the opening paragraph from an article on Artists and Illustrators.  I'm no artist, but I felt an instant kinship.  Developers -- the passionate ones -- care about their tools in the same way.

A good computer configuration would include a fast multi-core cpu with two 24" displays.  Dual monitors were fantastic, letting me code on one display and allowing me to read email or web pages on the other.  They became less fantastic when I began to code on both displays.  The angles between the monitors were awkward and the frame separating them was distracting.  A single large monitor became more suitable, and I found 27" i…

The C Programming Language, Part 3

I found C easy to pick up.  Yet, it had the wonderful property in that the more you used the language, the more there was to learn.

The book in the middle with the red title -- The C Answer Book -- provided solutions to the exercises presented in The C Programming Language (topmost book).  It was neatly done, and kept pace with the concepts presented in the source material.  Depending on how you learn, the answer book can be useful.  Back in the day, before the internet matured, it certainly was.  Today, it's not as essential because sample code abounds.

The book at the bottom was the second edition of The C Programming Language and described the ANSI standard.  A new one on Amazon sold for about $60, which made my first edition quite the bargain.  Emphasizing C's main strength, and at the same time, acknowledging a major source of difficulty, K&R expanded Chapter 5: Pointers and Arrays with diagrams of how memory was organized, how arrays were imagined, and how pointers …

The C Programming Language, Part 2

The leftmost book was a first edition, and it beckoned me, sometime around 1984, from the shelves of Barnes & Nobles.  Priced at $17.95, the book was a significant out-of-pocket expense for someone on their first job, but it would prove to be quite the investment.

Turning to the Introduction, I noticed it was denoted as Chapter 0. This was a delightful self-reference to the C language itself, where arrays started with an index of 0, instead of 1.  Think of it as an elevator that marks the ground floor as "G" and the next floor up as "1."

C's array and pointer capabilities were what made the language especially powerful, compact, clear, and efficient, but it also took discipline to use them right.  Pointers let you access memory, but sloppy use can take your pointer to bad places, leading to security holes, and ultimately crashing your program.

One technique I've used to corral stray pointers was to set them null after I was done with them.  It was stil…

Bookshelf Classic: The C Programming Language

My first job had me programming in Microsoft BASIC for the IBM PC (DOS).  BASIC worked well enough, but its limitations were clear.  The language was interpreted and therefore slow.  More importantly, it wasn't a modern structured language, and instead, relied on line numbers and the GOTO statement.  Anyone who has read Dijkstra knew GOTO was a bad thing.

Having learned a structured language in college (PL/I), using BASIC felt unnatural.  When a C compiler became available for the PC, I saw a chance to improve and modernize our software.  The problem was selling the idea -- a problem made harder because I wasn't fluent in C.

"It would be a staffing problem.  Not many people know C, but we can find a lot of programmers who know BASIC," noted one manager.

The argument was strong as my knowledge of C was weak.  But I knew that C, by design, was a small language and thus easy to learn.  "It has about 30 keywords," I proffered to another manager.

Unimpressed, h…