Post Processing: Dark Mode Reconsidered, Inefficiency Revisited, and a Linked List Reversed

A lamp post.
I first shared my enthusiasm for dark mode in the post Automate Dark Mode in Apple OS Mojave.  Not everyone likes dark mode though, and Victoria Song of Gizmodo recently wrote a light hearted essay to Stop Using Dark Mode. She made some fair points.  Color themes for light mode have been around longer and their designs have had more time to evolve; the result is superior contrast and better readability than their dark mode counterparts.

I've also found dark mode limitations in Apple's Mail App. While Mail is dark mode capable, html email is rendered in light mode and the harsh contrast is painful to the eyes.

Where dark mode shines is when I'm using one application exclusively such as Xcode or Android Studio. The colors are consistent, and free of competing themes, the experience is immersive and harmonious.

Discussions of inefficiency continue to trend. I contributed with the post The Hidden Cost Of Efficiency, where resiliency is inversely proportional to efficiency.   Bruce Schneier, security and technology expert, connects inefficiency to security in his blog Schneier on Security. He's careful to note that inefficiency doesn't have to mean sloppy and wasteful. The good kind of inefficiency includes redundancy, diversity, and overcapacity -- qualities that only regulation, rather than a free market, can provide.

When I wrote the post Symmetry, I pointed out that knowing how to reverse a linked list doesn't necessarily make you a good programmer.  Linked lists are mainly taught in a college curriculum; the data structure is useful, and traversal illustrates the beauty and power of recursion. And while I agree recursion is pretty to read, it makes unnecessary demands on the computer. In the real world, the iterative approach is preferred.

Still, I was remiss not to post that code.  For the sake of completeness, voila . . . in light mode.

// Reverse a linked list
// 1 -> 2 -> 3 -> 4 -> 5 -> 6
// to
// 6 -> 5 -> 4 -> 3 -> 2 -> 1

#include <stdio.h>
#include <stdlib.h>

struct Node
    int  payLoad;
    struct Node *next;

void print (struct Node *node);
void reverse (struct Node *node);

void reverse (struct Node *node)
    printf ("Hello from reverse, node %d\n", node->payLoad);

    if (node->next == NULL)

    reverse (node->next);    // recursive call

    // first time thru:
    //     node is node5
    //     node->next is node6
    //     node->next->next is node6->next which gets assigned to node5
    node->next->next = node; 
    printf ("Goodbye from reverse, node %d\n", node->payLoad);

void print (struct Node *node)
    while (node != NULL)
        printf ("Node payLoad = %d\n", node->payLoad);
        node = node->next;

int main()
    struct Node node1;
    struct Node node2;
    struct Node node3;
    struct Node node4;
    struct Node node5;
    struct Node node6;

    node1.payLoad = 1; = &node2;

    node2.payLoad = 2; = &node3;

    node3.payLoad = 3; = &node4;

    node4.payLoad = 4; = &node5;

    node5.payLoad = 5; = &node6;

    node6.payLoad = 6; = NULL;

    // print linked list starting with node 1 (head)
    printf ("Printing linked list...\n");

// reverse merged list
    printf ("Reversing node... \n");

    // start recursive call to reverse
    reverse(&node1); = NULL;    // node1 is now the tail
    printf ("Printing linked list...\n");
    print(&node6);        // print from node6, which is the new head

    return 0;



Popular posts from this blog

Bookshelf Classic: The C Programming Language

Post Processing: Swift, Kotlin, Team Scaling Fallacy, Levandowski