one hundred two things tagged “programming”

Fundamentals of Lambda Calculus for People Who Love Birds

This (beautifully formatted and well-paced-and-delivered and surprisingly sparsely attended) talk by Gabriel Lebec on the fundamentals of Lambda Calculus is one of my favorite talks ever.

As Lebec explains, the lovely bird names come from this book called “To Mock a Mockingbird” by mathematician and logician Raymond Smullyan. The naming is simply delightful. As Matthew Gilliard explains:

The premise is that there are enchanted forests which contain many (or sometimes very few) talking birds. Smullyan dedicated the book to Haskell Curry - an early pioneer in combinatory logic and an avid bird-watcher. The birds, which I suppose represent the combinators, have an interesting characteristic:
Given any two birds A and B, if you call out the name of B to A it will respond by calling out the name of some bird to you.

This bird whose name A calls when you call B is denoted as AB. Once you have several birds in place, a single call can cascade around the forest with each call following rules depending on who produces it.

The very first bird we are introduced to is the Mockingbird whose characteristic behaviour is that whatever name you call to the Mockingbird, it will reply as if it is the bird whose name you called. This is denoted:

Mx = xx

For any bird x we can say that Mx (the result of calling x to a Mockingbird) is the same as xx (the result of calling x to a bird of type x). It really does mock other birds! And what’s more, the existence of the Mockingbird, in combination with various others, unlocks some really fascinating group behaviour from these birds.

And!

Soon we discover that birds have certain properties: The can be fond of other birds, they can be egocentric if they are fond of themselves. The can be hopelessly egocentric if they only ever talk about themselves. There are happy birds, normal birds, agreeable birds and many others. We also meet other types of birds with specific properties - the Lark, the Kestrel, Sage birds, Bluebirds, aristocratic birds, Eagles, the list goes on and on. Luckily there is a Who’s Who list of birds in the back to keep track.

Enterprise Software - A Camel is a Horse Designed by Committee by Arvind Narayanan More Pasta

The point is, some products are sold directly to the end user, and are forced to prioritize usability. Other products are sold to an intermediary whose concerns are typically different from the user’s needs. Such products don’t HAVE to end up as unusable garbage, but usually do.

Jira and Confluence, which I use at work, come to mind as formerly amazing products which have gone down the shitter with unnecessary Enterprise™ feature-bloat over the past few years. I wonder if there’s a way out of this mire (maybe start saying “No”?) Until then, #jobsecurity I guess.

My university just announced that it’s dumping Blackboard, and there was much rejoicing. Why is Blackboard universally reviled? There’s a standard story of why “enterprise software” sucks. If you’ll bear with me, I think this is best appreciated by talking about… baby clothes!

There are two types of baby outfits. The first is targeted at people buying gifts. It’s irresistible on the rack. It has no fewer than 18 buttons. At least 3 people are needed to get a screaming baby into it. It’s worn once, so you can send a photo to the gifter, then discarded.

Other baby outfits are meant for parents. They’re marked “Easy On, Easy Off” or some such, and they really mean it. Zippers aren’t easy enough so they fasten using MAGNETS. A busy parent (i.e. a parent) can change an outfit in 5 seconds, one handed, before rushing to work.

The point is, some products are sold directly to the end user, and are forced to prioritize usability. Other products are sold to an intermediary whose concerns are typically different from the user’s needs. Such products don’t HAVE to end up as unusable garbage, but usually do.

OK, back to Blackboard! It’s actually designed to look extremely attractive to the administrators (not professors and definitely not students) who make purchase decisions. Since they can’t easily test usability, they instead make comparisons based on… checklists of features. 🤦🏽‍♂️

And that’s exactly what’s wrong with Blackboard. It has every feature ever dreamed up. But like anything designed by a committee, the interface is incoherent and any task requires at least fifteen clicks (and that’s if you even remember the correct sequence the first time).

Software companies can be breathtakingly clueless when there’s a layer of indirection between them and their users. Everyone who’s suffered through Blackboard will have the same reaction to this: try having less functionality! edscoop.com/how-canvas-cam…

The grumbling about Blackboard has finally gotten loud enough that schools are paying a modicum of attention to usability when evaluating alternatives. Blackboard’s market share has dropped dramatically and this will probably continue. Good.

Here’s the kicker, though. It’s extremely likely that whichever vendor emerges on top will fall into the same trap. The incentives almost guarantee it. Once profs and students put down the pitchforks, committees will go back to their checklists, and feature creep will resume.

Blackboard is 20 years old. If Twitter is around in 20 years, let’s see how this prediction holds up. And now I have to go rescue a three-month old from an extremely cute and equally uncomfortable outfit.

Plurals in Python

>>> n = 0
>>> print "%d item%s" % (n, "s"[n==1:])
0 items
>>> n = 1
>>> print "%d item%s" % (n, "s"[n==1:])
1 item
>>> n = 2
>>> print "%d item%s" % (n, "s"[n==1:])
2 items

# If you might want to print negative items, add abs to the test:
>>> n = -1
>>> print "%d item%s" % (n, "s"[abs(n)==1:])
2 items

# If a word has irregular plural morphology, use a list:
>>> n=1
>>> print "%d %s" % (n, ['abacus','abaci'][n!=1])
1 abacus
>>> n=2
>>> print "%d %s" % (n, ['abacus','abaci'][n!=1])
2 abaci

Source.

The Universal Estimation Table

Estimate Actual Time
Very Easy 1 Hour
Easy 2 Hours
Quite Easy 4 Hours
Looks Quite Easy 6 Hours
Average 8 Hours
Looks Average 12 Hours
No Clue 16 Hours
Seems Complex 24 Hours
Complex 30 Hours
Very Complex 40 Hours
Can Take Some Time 48 Hours
Fuck 60 Hours
Yeah Looks Pretty Easy 80 Hours

Combine: “No Clue. Can take some time, but yeah… looks pretty easy” = 16 + 48 + 80 = 144 hours.

Source Unknown. See also: “Midwest Distances

“Vertical Hanging Indent” is the One True Indentation Style

With the trailing comma and sorted properties/imports/arguments/whatever! It looks like this in Python:

from constants import (
    EXIT_CODE_ARTICLE_ROOT_NOT_FOUND,
    EXIT_CODE_NOT_A_GIT_REPOSITORY,
    EXIT_CODE_NOT_AN_ABSOLUTE_PATH,
    MARKDOWN_EXTENSION_CONFIG,
    MARKDOWN_EXTENSIONS,
    MARKDOWN_FILE_EXTENSION,
    MAX_NUMBER_OF_WORKERS,
    PATHS_TO_REMOVE,
)

In which universe are these shittier alternatives considered readable or maintainable?

from constants import (MAX_CHARS_IN_SEARCH_RESULTS,
                       MAX_CHARS_SURROUNDING_SEARCH_HIGHLIGHT,
                       MAX_SEARCH_RESULTS, MIN_CHARS_IN_SEARCH_TERM,
                       SEARCH_INDEX_PATH)

or

from constants import (MAX_CHARS_IN_SEARCH_RESULTS,
                       MAX_CHARS_SURROUNDING_SEARCH_HIGHLIGHT,
                       MAX_SEARCH_RESULTS,
                       MIN_CHARS_IN_SEARCH_TERM,
                       SEARCH_INDEX_PATH)

or

from constants import (
    MAX_CHARS_IN_SEARCH_RESULTS, MAX_CHARS_SURROUNDING_SEARCH_HIGHLIGHT,
    MAX_SEARCH_RESULTS, MIN_CHARS_IN_SEARCH_TERM, SEARCH_INDEX_PATH)

That’s for Python and the modes are from the excellent isort’s docs. I am glad that Prettier does VHI by default (although you have to specify the trailing-comma and object properties are not sorted.)

Real Programmers Don’t Use PASCAL by Ed Post, Copyright (c) 1982 More Pasta

Back in the good old days – the “Golden Era” of computers, it was easy to separate the men from the boys (sometimes called “Real Men” and “Quiche Eaters” in the literature). During this period, the Real Men were the ones that understood computer programming, and the Quiche Eaters were the ones that didn’t. A real computer programmer said things like “DO 10 I=1,10” and “ABEND” (they actually talked in capital letters, you understand), and the rest of the world said things like “computers are too complicated for me” and “I can’t relate to computers – they’re so impersonal”. (A previous work [1] points out that Real Men don’t “relate” to anything, and aren’t afraid of being impersonal.)

But, as usual, times change. We are faced today with a world in which little old ladies can get computerized microwave ovens, 12 year old kids can blow Real Men out of the water playing Asteroids and Pac-Man, and anyone can buy and even understand their very own Personal Computer. The Real Programmer is in danger of becoming extinct, of being replaced by high-school students with TRASH-80s!

There is a clear need to point out the differences between the typical high-school junior Pac-Man player and a Real Programmer. Understanding these differences will give these kids something to aspire to – a role model, a Father Figure. It will also help employers of Real Programmers to realize why it would be a mistake to replace the Real Programmers on their staff with 12 year old Pac-Man players (at a considerable salary savings).

LANGUAGES

The easiest way to tell a Real Programmer from the crowd is by the programming language he (or she) uses. Real Programmers use FORTRAN. Quiche Eaters use PASCAL. Nicklaus Wirth, the designer of PASCAL, was once asked, “How do you pronounce your name?”. He replied “You can either call me by name, pronouncing it ‘Veert’, or call me by value, ‘Worth’.” One can tell immediately from this comment that Nicklaus Wirth is a Quiche Eater. The only parameter passing mechanism endorsed by Real Programmers is call-by-value-return, as implemented in the IBM/370 FORTRAN G and H compilers. Real programmers don’t need abstract concepts to get their jobs done: they are perfectly happy with a keypunch, a FORTRAN IV compiler, and a beer.

  • Real Programmers do List Processing in FORTRAN.
  • Real Programmers do String Manipulation in FORTRAN.
  • Real Programmers do Accounting (if they do it at all) in FORTRAN.
  • Real Programmers do Artificial Intelligence programs in FORTRAN.

If you can’t do it in FORTRAN, do it in assembly language. If you can’t do it in assembly language, it isn’t worth doing.

STRUCTURED PROGRAMMING

Computer science academicians have gotten into the “structured programming” rut over the past several years. They claim that programs are more easily understood if the programmer uses some special language constructs and techniques. They don’t all agree on exactly which constructs, of course, and the examples they use to show their particular point of view invariably fit on a single page of some obscure journal or another – clearly not enough of an example to convince anyone. When I got out of school, I thought I was the best programmer in the world. I could write an unbeatable tic-tac-toe program, use five different computer languages, and create 1000 line programs that WORKED. (Really!) Then I got out into the Real World. My first task in the Real World was to read and understand a 200,000 line FORTRAN program, then speed it up by a factor of two. Any Real Programmer will tell you that all the Structured Coding in the world won’t help you solve a problem like that – it takes actual talent. Some quick observations on Real Programmers and Structured Programming:

  • Real Programmers aren’t afraid to use GOTOs.
  • Real Programmers can write five page long DO loops without getting confused.
  • Real Programmers enjoy Arithmetic IF statements because they make the code more interesting.
  • Real Programmers write self-modifying code, especially if it saves them 20 nanoseconds in the middle of a tight loop.
  • Programmers don’t need comments: the code is obvious.
  • Since FORTRAN doesn’t have a structured IF, REPEAT … UNTIL, or CASE statement, Real Programmers don’t have to worry about not using them. Besides, they can be simulated when necessary using assigned GOTOs.

Data structures have also gotten a lot of press lately. Abstract Data Types, Structures, Pointers, Lists, and Strings have become popular in certain circles. Wirth (the above-mentioned Quiche Eater) actually wrote an entire book [2] contending that you could write a program based on data structures, instead of the other way around. As all Real Programmers know, the only useful data structure is the array. Strings, lists, structures, sets – these are all special cases of arrays and and can be treated that way just as easily without messing up your programing language with all sorts of complications. The worst thing about fancy data types is that you have to declare them, and Real Programming Languages, as we all know, have implicit typing based on the first letter of the (six character) variable name.

OPERATING SYSTEMS

What kind of operating system is used by a Real Programmer? CP/M? God forbid – CP/M, after all, is basically a toy operating system. Even little old ladies and grade school students can understand and use CP/M.

Unix is a lot more complicated of course – the typical Unix hacker never can remember what the PRINT command is called this week – but when it gets right down to it, Unix is a glorified video game. People don’t do Serious Work on Unix systems: they send jokes around the world on USENET and write adventure games and research papers.

No, your Real Programmer uses OS/370. A good programmer can find and understand the description of the IJK305I error he just got in his JCL manual. A great programmer can write JCL without referring to the manual at all. A truly outstanding programmer can find bugs buried in a 6 megabyte core dump without using a hex calculator. (I have actually seen this done.)

OS/370 is a truly remarkable operating system. It’s possible to destroy days of work with a single misplaced space, so alertness in the programming staff is encouraged. The best way to approach the system is through a keypunch. Some people claim there is a Time Sharing system that runs on OS/370, but after careful study I have come to the conclusion that they are mistaken.

PROGRAMMING TOOLS

What kind of tools does a Real Programmer use? In theory, a Real Programmer could run his programs by keying them into the front panel of the computer. Back in the days when computers had front panels, this was actually done occasionally. Your typical Real Programmer knew the entire bootstrap loader by memory in hex, and toggled it in whenever it got destroyed by his program. (Back then, memory was memory – it didn’t go away when the power went off. Today, memory either forgets things when you don’t want it to, or remembers things long after they’re better forgotten.) Legend has it that Seymour Cray, inventor of the Cray I supercomputer and most of Control Data’s computers, actually toggled the first operating system for the CDC7600 in on the front panel from memory when it was first powered on. Seymour, needless to say, is a Real Programmer.

One of my favorite Real Programmers was a systems programmer for Texas Instruments. One day, he got a long distance call from a user whose system had crashed in the middle of some important work. Jim was able to repair the damage over the phone, getting the user to toggle in disk I/O instructions at the front panel, repairing system tables in hex, reading register contents back over the phone. The moral of this story: while a Real Programmer usually includes a keypunch and lineprinter in his toolkit, he can get along with just a front panel and a telephone in emergencies.

In some companies, text editing no longer consists of ten engineers standing in line to use an 029 keypunch. In fact, the building I work in doesn’t contain a single keypunch. The Real Programmer in this situation has to do his work with a text editor program. Most systems supply several text editors to select from, and the Real Programmer must be careful to pick one that reflects his personal style. Many people believe that the best text editors in the world were written at Xerox Palo Alto Research Center for use on their Alto and Dorado computers [3]. Unfortunately, no Real Programmer would ever use a computer whose operating system is called SmallTalk, and would certainly not talk to the computer with a mouse.

Some of the concepts in these Xerox editors have been incorporated into editors running on more reasonably named operating systems. EMACS and VI are probably the most well known of this class of editors. The problem with these editors is that Real Programmers consider “what you see is what you get” to be just as bad a concept in text editors as it is in women. No, the Real Programmer wants a “you asked for it, you got it” text editor – complicated, cryptic, powerful, unforgiving, dangerous. TECO, to be precise.

It has been observed that a TECO command sequence more closely resembles transmission line noise than readable text [4]. One of the more entertaining games to play with TECO is to type your name in as a command line and try to guess what it does. Just about any possible typing error while talking with TECO will probably destroy your program, or even worse – introduce subtle and mysterious bugs in a once working subroutine.

For this reason, Real Programmers are reluctant to actually edit a program that is close to working. They find it much easier to just patch the binary object code directly, using a wonderful program called SUPERZAP (or its equivalent on non-IBM machines). This works so well that many working programs on IBM systems bear no relation to the original FORTRAN code. In many cases, the original source code is no longer available. When it comes time to fix a program like this, no manager would even think of sending anything less than a Real Programmer to do the job – no Quiche Eating structured programmer would even know where to start. This is called “job security”.

Some programming tools NOT used by Real Programmers:

  • FORTRAN preprocessors like MORTRAN and RATFOR. The Cuisinarts of programming – great for making Quiche. See comments above on structured programming.
  • Source language debuggers. Real Programmers can read core dumps.
  • Compilers with array bounds checking. They stifle creativity, destroy most of the interesting uses for EQUIVALENCE, and make it impossible to modify the operating system code with negative subscripts. Worst of all, bounds checking is inefficient.
  • Source code maintainance systems. A Real Programmer keeps his code locked up in a card file, because it implies that its owner cannot leave his important programs unguarded [5].

THE REAL PROGRAMMER AT WORK

Where does the typical Real Programmer work? What kind of programs are worthy of the efforts of so talented an individual? You can be sure that no real Programmer would be caught dead writing accounts-receivable programs in COBOL, or sorting mailing lists for People magazine. A Real Programmer wants tasks of earth-shaking importance (literally!):

  • Real Programmers work for Los Alamos National Laboratory, writing atomic bomb simulations to run on Cray I supercomputers.
  • Real Programmers work for the National Security Agency, decoding Russian transmissions.
  • It was largely due to the efforts of thousands of Real Programmers working for NASA that our boys got to the moon and back before the cosmonauts.
  • The computers in the Space Shuttle were programmed by Real Programmers.
  • Programmers are at work for Boeing designing the operating systems for cruise missiles.

Some of the most awesome Real Programmers of all work at the Jet Propulsion Laboratory in California. Many of them know the entire operating system of the Pioneer and Voyager spacecraft by heart. With a combination of large ground-based FORTRAN programs and small spacecraft-based assembly language programs, they can to do incredible feats of navigation and improvisation, such as hitting ten-kilometer wide windows at Saturn after six years in space, and repairing or bypassing damaged sensor platforms, radios, and batteries. Allegedly, one Real Programmer managed to tuck a pattern-matching program into a few hundred bytes of unused memory in a Voyager spacecraft that searched for, located, and photographed a new moon of Jupiter.

One plan for the upcoming Galileo spacecraft mission is to use a gravity assist trajectory past Mars on the way to Jupiter. This trajectory passes within 80 +/- 3 kilometers of the surface of Mars. Nobody is going to trust a PASCAL program (or PASCAL programmer) for navigation to these tolerances.

As you can tell, many of the world’s Real Programmers work for the U.S. Government, mainly the Defense Department. This is as it should be. Recently, however, a black cloud has formed on the Real Programmer horizon.

It seems that some highly placed Quiche Eaters at the Defense Department decided that all Defense programs should be written in some grand unified language called “ADA” (registered trademark, DoD). For a while, it seemed that ADA was destined to become a language that went against all the precepts of Real Programming – a language with structure, a language with data types, strong typing, and semicolons. In short, a language designed to cripple the creativity of the typical Real Programmer. Fortunately, the language adopted by DoD has enough interesting features to make it approachable: it’s incredibly complex, includes methods for messing with the operating system and rearranging memory, and Edsgar Dijkstra doesn’t like it [6]. (Dijkstra, as I’m sure you know, was the author of “GoTos Considered Harmful” – a landmark work in programming methodology, applauded by Pascal Programmers and Quiche Eaters alike.) Besides, the determined Real Programmer can write FORTRAN programs in any language.

The real programmer might compromise his principles and work on something slightly more trivial than the destruction of life as we know it, providing there’s enough money in it. There are several Real Programmers building video games at Atari, for example. (But not playing them. A Real Programmer knows how to beat the machine every time: no challange in that.) Everyone working at LucasFilm is a Real Programmer. (It would be crazy to turn down the money of 50 million Star Wars fans.) The proportion of Real Programmers in Computer Graphics is somewhat lower than the norm, mostly because nobody has found a use for Computer Graphics yet. On the other hand, all Computer Graphics is done in FORTRAN, so there are a fair number people doing Graphics in order to avoid having to write COBOL programs.

THE REAL PROGRAMMER AT PLAY

Generally, the Real Programmer plays the same way he works – with computers. He is constantly amazed that his employer actually pays him to do what he would be doing for fun anyway, although he is careful not to express this opinion out loud. Occasionally, the Real Programmer does step out of the office for a breath of fresh air and a beer or two. Some tips on recognizing real programmers away from the computer room:

  • At a party, the Real Programmers are the ones in the corner talking about operating system security and how to get around it.
  • At a football game, the Real Programmer is the one comparing the plays against his simulations printed on 11 by 14 fanfold paper.
  • At the beach, the Real Programmer is the one drawing flowcharts in the sand.
  • A Real Programmer goes to a disco to watch the light show.
  • At a funeral, the Real Programmer is the one saying “Poor George. And he almost had the sort routine working before the coronary.”
  • In a grocery store, the Real Programmer is the one who insists on running the cans past the laser checkout scanner himself, because he never could trust keypunch operators to get it right the first time.

THE REAL PROGRAMMER’S NATURAL HABITAT

What sort of environment does the Real Programmer function best in? This is an important question for the managers of Real Programmers. Considering the amount of money it costs to keep one on the staff, it’s best to put him (or her) in an environment where he can get his work done.

The typical Real Programmer lives in front of a computer terminal. Surrounding this terminal are:

  • Listings of all programs the Real Programmer has ever worked on, piled in roughly chronological order on every flat surface in the office.
  • Some half-dozen or so partly filled cups of cold coffee. Occasionally, there will be cigarette butts floating in the coffee. In some cases, the cups will contain Orange Crush.
  • Unless he is very good, there will be copies of the OS JCL manual and the Principles of Operation open to some particularly interesting pages.
  • Taped to the wall is a line-printer Snoopy calender for the year 1969.
  • Strewn about the floor are several wrappers for peanut butter filled cheese bars (the type that are made stale at the bakery so they can’t get any worse while waiting in the vending machine).
  • Hiding in the top left-hand drawer of the desk is a stash of double stuff Oreos for special occasions.
  • Underneath the Oreos is a flow-charting template, left there by the previous occupant of the office. (Real Programmers write programs, not documentation. Leave that to the maintainence people.)

The Real Programmer is capable of working 30, 40, even 50 hours at a stretch, under intense pressure. In fact, he prefers it that way. Bad response time doesn’t bother the Real Programmer – it gives him a chance to catch a little sleep between compiles. If there is not enough schedule pressure on the Real Programmer, he tends to make things more challenging by working on some small but interesting part of the problem for the first nine weeks, then finishing the rest in the last week, in two or three 50-hour marathons. This not only inpresses his manager, who was despairing of ever getting the project done on time, but creates a convenient excuse for not doing the documentation. In general:

  • No Real Programmer works 9 to 5. (Unless it’s 9 in the evening to 5 in the morning.)
  • Real Programmers don’t wear neckties.
  • Real Programmers don’t wear high heeled shoes.
  • Real Programmers arrive at work in time for lunch. [9]
  • A Real Programmer might or might not know his wife’s name. He does, however, know the entire ASCII (or EBCDIC) code table.
  • Real Programmers don’t know how to cook. Grocery stores aren’t often open at 3 a.m., so they survive on Twinkies and coffee.

THE FUTURE

What of the future? It is a matter of some concern to Real Programmers that the latest generation of computer programmers are not being brought up with the same outlook on life as their elders. Many of them have never seen a computer with a front panel. Hardly anyone graduating from school these days can do hex arithmetic without a calculator. College graduates these days are soft – protected from the realities of programming by source level debuggers, text editors that count parentheses, and user friendly operating systems. Worst of all, some of these alleged computer scientists manage to get degrees without ever learning FORTRAN! Are we destined to become an industry of Unix hackers and Pascal programmers?

On the contrary. From my experience, I can only report that the future is bright for Real Programmers everywhere. Neither OS/370 nor FORTRAN show any signs of dying out, despite all the efforts of Pascal programmers the world over. Even more subtle tricks, like adding structured coding constructs to FORTRAN have failed. Oh sure, some computer vendors have come out with FORTRAN 77 compilers, but every one of them has a way of converting itself back into a FORTRAN 66 compiler at the drop of an option card – to compile DO loops like God meant them to be.

Even Unix might not be as bad on Real Programmers as it once was. The latest release of Unix has the potential of an operating system worthy of any Real Programmer. It has two different and subtly incompatible user interfaces, an arcane and complicated terminal driver, virtual memory. If you ignore the fact that it’s structured, even C programming can be appreciated by the Real Programmer: after all, there’s no type checking, variable names are seven (ten? eight?) characters long, and the added bonus of the Pointer data type is thrown in. It’s like having the best parts of FORTRAN and assembly language in one place. (Not to mention some of the more creative uses for #define.)

No, the future isn’t all that bad. Why, in the past few years, the popular press has even commented on the bright new crop of computer nerds and hackers ([7] and [8]) leaving places like Stanford and M.I.T. for the Real World. From all evidence, the spirit of Real Programming lives on in these young men and women. As long as there are ill-defined goals, bizarre bugs, and unrealistic schedules, there will be Real Programmers willing to jump in and Solve The Problem, saving the documentation for later. Long live FORTRAN!

ACKNOWLEGEMENT

I would like to thank Jan E., Dave S., Rich G., Rich E. for their help in characterizing the Real Programmer, Heather B. for the illustration, Kathy E. for putting up with it, and atd!avsdS:mark for the initial inspriration.

REFERENCES

  1. Feirstein, B., Real Men Don’t Eat Quiche, New York, Pocket Books, 1982.
  2. Wirth, N., Algorithms + Datastructures = Programs, Prentice Hall, 1976.
  3. Xerox PARC editors . . .
  4. Finseth, C., Theory and Practice of Text Editors - or - a Cookbook for an EMACS, B.S. Thesis, MIT/LCS/TM-165, Massachusetts Institute of Technology, May 1980.
  5. Weinberg, G., The Psychology of Computer Programming, New York, Van Nostrabd Reinhold, 1971, page 110.
  6. Dijkstra, E., On the GREEN Language Submitted to the DoD, Sigplan notices, Volume 3, Number 10, October 1978.
  7. Rose, Frank, Joy of Hacking, Science 82, Volume 3, Number 9, November 1982, pages 58 - 66.
  8. The Hacker Papers, Psychology Today, August 1980.
  9. Datamation, July, 1983, pp. 263-265.

On a Program’s Scope

“Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.” Coined by Jamie Zawinski (who called it the “Law of Software Envelopment”) to express his belief that all truly useful programs experience pressure to evolve into toolkits and application platforms (the mailer thing, he says, is just a side effect of that). It is commonly cited, though with widely varying degrees of accuracy.

Zawinski’s Law

The Chrome Dino

Here’s a fairly recent (Dec 2018) interview with the creators of chrome://dino. It was called Project Bolan (which I had to look up), had 270M games played every month1, with most users coming “from markets with unreliable or expensive mobile data, like India, Brazil, Mexico, or Indonesia” and took quite a bit of development to work on all platforms.

We built it to max out at approximately 17 million years, the same amount of time that the T-rex was alive on Earth… but we feel like your spacebar may not be the same afterwards.

  1. I suppose they know this thanks to the “I agree to everything” button one clicks while installing Chrome… ↩︎

The Scunthorpe Problem

The Scunthorpe problem (or the Clbuttic Mistake) is the unintentional blocking of websites, e-mails, forum posts or search results by a spam filter or search engine because their text contains a string of letters that appear to have an obscene or otherwise unacceptable meaning.

Wikipedia

Examples would be: shitake mushrooms, Herman I. Libshitz, magna cum laude, Arun Dikshit.

Latency Numbers “Every Programmer Should Know”

From a presentation by Jeff Dean. What about when technology evolves? Here’s a handy visualization. And here’s a way to think about these numbers. Nathan Hurst visualized the distances on Google Maps1.

Operation Time (ns) Light Distance (m) Approximate Light Distance
L1 cache reference 0.5 0.15 Diagonal across your smartphone
Branch mispredict 5 1.5 Height of Natalie Portman
L2 cache reference 7 2.1 Height of Shaq
Mutex lock/unlock 25 7.5 Height of a school flag pole
Main memory reference 100 30 Half a Manhattan city block (North/South)
Compress 1K bytes with Zippy 3,000 900 Width of Central Park
Send 1K bytes over 1 Gbps network 10,000 3,000 Width of Manhattan
Read 4K randomly from SSD* 150,000 45,000 NYC to Hempstead on Long Island
Read 1 MB sequentially from memory 250,000 75,000 NYC to Princeton/Trenton, NJ
Round trip within same datacenter 500,000 150,000 NYC to Scranton, PA
Read 1 MB sequentially from SSD* 1,000,000 300,000 NYC to Boston, MA
Disk seek 10,000,000 3,000,000 NYC to Austin, TX
Read 1 MB sequentially from disk 20,000,000 6,000,000 NYC to Paris, France (also the diameter of the Earth)
Send packet CA → Netherlands → CA 150,000,000 45,000,000 Once around the equator
  1. Cached: One, Two, Three. ↩︎

Naughty Letter Frequencies in English

Here’s a community-maintained "List of Dirty, Naughty, Obscene, and Otherwise Bad Words" across various languages on Github. I was curious about a naïve frequency distribution of consonants across the English-language corpus (NSFW, obviously) and wrote a small script. Here are the results:

Letter Count
t 211
s 208
n 193
r 186
l 167
g 147
c 124
b 121
p 116
h 97
d 91
m 91
k 72
y 70
f 48
w 41
v 29
j 21
x 19
z 7
q 5

Not sure what I’m going to do with this information but here it is. 🤬

Generative Pre-trained Deepak

Headed over to “Wisdom of Chopra” to get myself a slice of Deepak’s #cosmiconscious insight.

Deepak Chopra Generator

Took that and had GPT-2 use it as a seed for more wisdom. Behold:

The invisible is the foundation of total belongingness: When we feel like we belong and are at home, we are happy, healthy and in good spirits. Without our sense of belonging, we feel anxious, sad, depressed, disengaged, and negative.

In the struggle to locate our identity, we can limit our awareness of who we are. We become prisoners of our own identities, which is usually the result of trying to fulfill our parents’ or society’s expectations of us.

It takes wisdom and intelligence to become an invisible expert, and this is not only to create a safe space for self-knowledge, but also to create safe spaces for others to be able to be themselves.

Imagine all the different spiritual and emotional benefits when we do not see or know about another’s stories, feelings, anxieties or challenges.

Imagine how freeing it would be for a Buddhist monk or a leader to have all their body, thoughts and speech remain invisible to everyone, including themselves.

How liberating would it be to know your gifts and be free from the burden of being in constant search of knowledge or validation, simply knowing that you are a gift to yourself and the world, and you matter to you.

As the Torah tells us: “You have been born for such a time as this” (Ecclesiastes 3:11). We have been given the gift of life to explore our true identities, free of expectations and limitations, to finally reach out into the unknown to create the power and joy of the divine within.

In a world that seems to be in constant change and evolution, it is easy to feel alone and afraid. Yet we are never alone, and it is always safe to be true to ourselves.

There is power in transforming into the master of our own universe. In the words of the Buddha: “The job of a bodhisattva is not to be a creator, but to create a creator.”

In the depths of our souls, the divine resonates with us, nudging us to release our inner monologue of fear and the unconscious power it holds over us. Each and every one of us has within us the potential to embody divine love and compassion for ourselves and all of creation, and in the embodiment of this divine potential, we ignite our own personal power.

Gather the courage to become the master of our own universe and to discover the true magic that dwells within.

Aum Shanti 🙏

Disposable Software

The software industry is currently going through the “disposable plastic” crisis the physical world went through in the mid-20th century (and is still paying down the debt for). You can run software from 1980 or 2005 on a modern desktop without too much hassle, but anything between there and 2-3 years ago? Black hole of fad frameworks and brittle dependencies. Computer Archaeology is going to become a full-time job.

Source

On Good Commit Messages

On the developer side, what I hope people are doing is trying to make, not just good code, but these days we’ve been very good about having explanations for the code. So commit messages to me are almost as important as the code change itself. Sometimes the code change is so obvious that no message is really required, but that is very very rare. And so one of the things I hope developers are thinking about, the people who are actually writing code, is not just the code itself, but explaining why the code does something, and why some change was needed. Because that then in turn helps the managerial side of the equation, where if you can explain your code to me, I will trust the code.

A lot of open source in general is about communication. And part of it is the commit messages, part of it is just the email going back and forth. Communicating what you’re trying to do or communicating why something doesn’t work for you is really important.

– Linus Torvalds, in conversation with Dirk Hohndel (emphasis mine)

This is pretty much what mine look like. For my personal stuff, I get so lazy, I use a list of developer excuses to generate a commit log that looks like this 🤦‍♀️

My shitty, lazy commit log

I hereby swear to read this document and make writing good commit messages a habit ✋🚀

On De-Duplication

I’ve usually heard this phenomenon called “incidental duplication”, and it’s something I find myself teaching junior engineers about quite often.

There are a lot of situations where 3-5 lines of many methods follow basically the same pattern, and it can be aggravating to look at. “Don’t repeat yourself!” Right?

So you try to extract that boilerplate into a method, and it’s fine until the very next change. Then you need to start passing options and configuration into your helper method… and before long your helper method is extremely difficult to reason about, because it’s actually handling a dozen cases that are superficially similar but full of important differences in the details.

I encourage my devs to follow a rule of thumb: don’t extract repetitive code right away, try and build the feature you’re working on with the duplication in place first. Let the code go through a few evolutions and waves of change. Then one of two things are likely to happen:

  1. you find that the code doesn’t look so repetitive anymore, or,
  2. you hit a bug where you needed to make the same change to the boilerplate in six places and you missed one.

In scenario 1, you can sigh and say “yeah it turned out to be incidental duplication, it’s not bothering me anymore.” In scenario 2, it’s probably time for a careful refactoring to pull out the bits that have proven to be identical (and, importantly, must be identical across all of the instances of the code).

@burlesona on HackerNews (emphasis and formatting mine.)

Whatever. I say we continue to abstract away and make better and better hammer factories and beam at our sophistication in creating unnecessary complexity #jobsecurity

State, Coupling, Complexity, & Code

Dependencies (coupling) is an important concern to address, but it’s only 1 of 4 criteria that I consider and it’s not the most important one. I try to optimize my code around reducing state, coupling, complexity and code, in that order.

I’m willing to add increased coupling if it makes my code more stateless.

I’m willing to make it more complex if it reduces coupling.

And I’m willing to duplicate code if it makes the code less complex.

Only if it doesn’t increase state, coupling or complexity do I dedup code.

The reason I put stateless code as the highest priority is it’s the easiest to reason about. Stateless logic functions the same whether run normally, in parallel or distributed. It’s the easiest to test, since it requires very little setup code. And it’s the easiest to scale up, since you just run another copy of it. Once you introduce state, your life gets significantly harder.

I think the reason that novice programmers optimize around code reduction is that it’s the easiest of the 4 to spot. The other 3 are much more subtle and subjective and so will require greater experience to spot. But learning those priorities, in that order, has made me a significantly better developer.

crun1r on HackerNews (emphases and formatting mine.)

Process and Tooling

I thought using loops was cheating, so I programmed my own using samples. I then thought using samples was cheating, so I recorded real drums. I then thought that programming it was cheating, so I learned to play drums for real. I then thought using bought drums was cheating, so I learned to make my own. I then thought using premade skins was cheating, so I killed a goat and skinned it. I then thought that that was cheating too, so I grew my own goat from a baby goat. I also think that is cheating, but I’m not sure where to go from here. I haven’t made any music lately, what with the goat farming and all.

I’ve made this mistake all too often, especially when trying to learn something new.

Things that quote kinda reminds me of:

Dank Typefaces

Was looking try something other than my beloved Operator Mono and came across Dank Mono which claims to be a “rather special coding font.” I love it. Looks like the cooler twin of Inconsolata. I remain quite tickled by how many of my co-workers find the italic variants of monospaced fonts ‘disturbing’ when they look at my screen.

Dank Mono Sample

Data, Data, Data

Linus Torvalds on git

I’d also like to point out that unlike every single horror I’ve ever witnessed when looking closer at SCM products, git actually has a simple design, with stable and reasonably well-documented data structures. In fact, I’m a huge proponent of designing your code around the data, rather than the other way around, and I think it’s one of the reasons git has been fairly successful

[. . .]

I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

Because God Can See

When I was little — and by the way, I was little once — my father told me a story about an 18th century watchmaker. And what this guy had done: he used to produce these fabulously beautiful watches.

And one day, one of his customers came into his workshop and asked him to clean the watch that he’d bought. And the guy took it apart, and one of the things he pulled out was one of the balance wheels. And as he did so, his customer noticed that on the back side of the balance wheel was an engraving, were words.

And he said to the guy, “Why have you put stuff on the back that no one will ever see?” And the watchmaker turned around and said, “God can see it.”

Now I’m not in the least bit religious, neither was my father, but at that point, I noticed something happening here. I felt something in this plexus of blood vessels and nerves, and there must be some muscles in there as well somewhere, I guess. But I felt something. And it was a physiological response. And from that point on, from my age at the time, I began to think of things in a different way. And as I took on my career as a designer, I began to ask myself the simple question: Do we actually think beauty, or do we feel it?

Richard Seymour, How Beauty Feels

I want it to be as beautiful as possible, even if it’s inside the box. A great carpenter isn’t going to use lousy wood for the back of a cabinet, even though nobody’s going to see it. When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through.

Steve Jobs

Do quite a bit more, good and invisible things, than required for the MVP or for the bloody “sprint.” You will then smile a lot and sleep quite well indeed. Excellence is a habit. It is yours. Nobody steals this from you.

Saved here via Stephanie Harcrow’s post.

Two Levels of Not Giving a Fuck

No Code is the best way to write secure and reliable applications. Write nothing; deploy nowhere.

Start by not writing any code.

Brilliant. I love both the presence and contents of the Dockerfile in that repo. As is always the case with such projects, the issues and pull requests are 💯

And if one is tempted to go against the tenets of No Code, there’s always my beloved fuckitpy, a (strangely well-thought-out) “Python error steamroller”1:

@fuckit
def buggy_function():
    problem_solved

@fuckit
class BuggyClass(object):
    def __init__(self):
        everything_works_now

And:

This module is like violence: if it doesn’t work, you just need more of it.

  1. Inspired by FuckitJS. ↩︎

Simpler Gmail

Michael Leggett, lead designer of Gmail from 2008-2012

“It’s like Lucky Charms got spewed all over the screen,” he says to me, as he scrolls through his inbox. It’s true. Folders, contacts, Google apps like Docs and Drive–and at least half a dozen notifications–all clutter Gmail at any given moment. And of course, there’s that massive Gmail logo that sits in the upper left-hand corner of the screen. Just in case you forgot that you just typed “gmail.com” into your browser bar three seconds ago. “Go look at any desktop app and tell me how many have a huge fucking logo in the top left,” rants Leggett. “C’mon. It’s pure ego, pure bullshit. Drop the logo. Give me a break.”

Fast Company, “The former lead designer of Gmail just fixed Gmail on his own”

So he made this plugin for Chrome and Firefox that cuts out all the terrible visual noise of Gmail. I’m never uninstalling this one.

And while I’m on the subject, who signed off on this disaster?

Because we all know that the only way to attact attention to a UI element is to adorn it with a big blue goddamn fucking tumor.

The Korn Shell

Good talk by Siteshwar Vashisht at FOSDEM 2019 on maintaining the Korn shell and old codebases in general. I came by his work while reading up on the fish shell. Featured this nugget

He talks about how they removed dead/inapplicable code and micro-optimizations, refactored a lot of legacy code, improved tests, switched to a new build and CI system, and so on.

Began with this baffling one-liner that won the International Obfuscated C Contest in 1987

main() { printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}

And reminded me of this Aaron Sorkin-esque story about David Korn which I heard via BLN

Greg Sullivan, a MicroSoft product manager (henceforth MPM), was holding forth on a forthcoming product that will provide Unix style scripting and shell services on NT for compatibility and to leverage UNIX expertise that moves to the NT platform. The product suite includes the MKS (Mortise Kern Systems) windowing Korn shell, a windowing Perl, and lots of goodies like awk, sed and grep. It actually fills a nice niche for which other products (like the MKS suite) have either been too highly priced or not well enough integrated.
An older man, probably mid-50s, stands up in the back of the room and asserts that Microsoft could have done better with their choice of Korn shell. He asks if they had considered others that are more compatible with existing UNIX versions of KSH.

The MPM said that the MKS shell was pretty compatible and should be able to run all UNIX scripts.

The questioner again asserted that the MKS shell was not very compatible and didn’t do a lot of things right that are defined in the KSH language spec. The MPM asserted again that the shell was pretty compatible and should work quite well.

This assertion and counter assertion went back and forth for a bit, when another fellow member of the audience announced to the MPM that the questioner was, in fact David Korn of AT&T (now Lucent) Bell Labs. (DavidKorn is the author of the KornShell).

Uproarious laughter burst forth from the audience, and it was one of the only times that I have seen a (by then pink cheeked) MPM lost for words or momentarily lacking the usual unflappable confidence. So, what’s a body to do when Microsoft reality collides with everyone else’s?

Game of Thrones Ratings

Via Rotten Tomatoes and with the awesome ChartJS. Dots are episodes, contiguous lines are seasons (static version.)

A search for episode titles on GitHub yielded this indescribably amazing, mostly hand-curated GoT Dataset by Jeffrey Lancaster (who published a Medium article describing his process. Has a Stranger Things dataset as well.)

Update: MFW watching the final episode.

JavaScript Delenda Est

Back in the second century BC, Cato the Elder ended his speeches with the phrase ‘Carthago delenda est,’ which is to say, ‘Carthage must be destroyed.’ It didn’t matter what the ostensible topic of the speech was: above all, Carthage must be destroyed.

My opinion towards JavaScript is much like Cato’s towards Carthage: it must be rooted out, eliminated and destroyed entirely. I don’t know if I’d go quite so far as to say that the fundamental challenge of mass computing is the final destruction of JavaScript — but I want to say it, even though it’s false.

JavaScript is a pox, a disaster, a shame. It is the most embarrassingly bad thing to become popular in computing since Windows 3.1. Its one virtue (that it’s on every client device) is outshone by its plethora of flaws in much the same way that a matchstick is outshone by the sun, the stars and the primordial energy of the Big Bang added together.

JavaScript is the XML, the Yugo, the Therac-25 of programming languages. The sheer amount of human effort which has been expended working around its fundamental flaws instead of advancing the development of mankind is astounding. The fact that people would take this paragon of wasted opportunity and use it on the server side, where there are so many better alternatives (to a first approximation, every other programming language ever used), is utterly appalling.

JavaScript delenda est.

I don’t know what my newfound affection for it says about me. Via HackerNews.

Alan Kay on OOP

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I’m not aware of them.

Dr. Alan Kay on the Meaning of “Object-Oriented Programming”

So… Erlang? (RIP Joe Armstrong 🙏) And that was before this

(I’m not against types, but I don’t know of any type systems that aren’t a complete pain, so I still like dynamic typing.)

Indeed, Dr. Kay.

The “Not Invented Here Syndrome”

In programming, it is also common to refer to the “NIH syndrome” as the tendency towards reinventing the wheel (reimplementing something that is already available) based on the belief that in-house developments are inherently better suited, more secure, more controlled, quicker to develop, and incur lower overall cost (including maintenance cost) than using existing implementations. In-house developments are often collaborative with each other. When two in-house developments come together, it is informally known as “computer incest.”

Wikipedia

Found when I was looking for a dependency-free XML-to-JSON parser wherein the author notes the “fine NIH tradition of JavaScript developers everywhere.” Reminded me of this

Via

Node Modules

For a single project I made the mistake of working on in my Dropbox folder:

Wonder what the downsides are to hardlinking by default. And, fundamentally, why creating an amazing, Python-like standard library is such an intractable problem in the first place.

[. . .] core-js is also utils library, quite a big one honestly! It has so many functions inside I bet a lot of other packages will be using it!

Not really. Only babel-runtime has it in its deps. Oopsie.
And returning to the starting point, cli uses only 3 (trivial) methods from common-tags — stripIndents, stripIndent, oneLine. Oopsie daisy.

In order to use these 3 methods node_modules needs 1826 files. And that’s just 4 of mentioned 976 installed packages.

– Mateusz Morszczyzna, What’s really wrong with node_modules and why this is your fault

🤦‍♂️ The portion of the article that listed functionally similar packages and is-* packages was particularly dismaying. As he points out, there’s a good reason why jQuery and lodash are as immensely popular as they are1.

  1. Was wondering if we’ll ever get back to the magic of hand-crafted web pages and found this article which led me to this modern Geocities clone 💖 ↩︎