YTechnology

  Beautiful Code was published nearly 20 years ago in 2007. The blurb on the back cover promises an over-the-shoulder look of leading developers creating elegant solutions to hard problems. Some of those shoulders belong to well-known heavyweights of an earlier period, including Brian Kernighan and Jon Bentley . A bit closer to the present, Yukihiro Matsumoto, nicknamed Matz and inventor of Ruby, writes "Treating Code As An Essay."  Notably, Matz argues that code is meant to be read by humans. Ideally, beautiful code would be simple, balanced, and make developers happy and productive. In contrast, I must point out, AI generated code is meant to be, at most, corrected. Separately, Bjarne Stroustrup had this to say when asked by  Lex Friedman  on how can you tell when your code has reached the Einstein level of  simplicity : "It's easier to recognize ugly than to recognize beauty in code. . . sometimes beauty comes from something that is innovative and unusual,...

With apologies to Shakespeare, the correct quote is "What's past is prologue," which eloquently states that events and actions of today shape and foreshadow the world of tomorrow. Prolog is an AI language of the past, and I had a little fun with it in the 1980s. I have long forgotten the language syntax, but do remember the program I wrote to answer a juvenile question: "If God's power is infinite, can he create a boulder he cannot move?" On the screen appeared the answer I expected: "Undefined." I shrugged, and was just a little disappointed the computer didn't crash or blow up, not realizing then, that "undefined" was a very good, if not the best possible answer. Enter the prompt today in the Duck.ai / ChatGPT-4o, I was amused by its answer: A second attempt produced a few paragraphs describing the nature of omnipotence and the logical paradoxes it can bring. The essay could have been written by a high school senior. In contrast, th...

Steve Wozniak continues to support Apple in unexpected ways. His book, iWoz , raises my iMac 27" 5K Retina Display computer to a comfortable eye level.  Long time users of the iMac will recognize this setup, as the stand is not height adjustable. I confess I have not read Wozniak's book, and no, I did not buy the book simply to adjust the height of my display. Rather, I purchased this book for my son in 2006, who needed a subject for a grade school book report.  Wozniak's goal was to share the thrill of engineering with young minds, and he succeeded. His hardcover book serving as a monitor accessory was a bonus. When Apple recently announced the Apple Studio Display with a height adjustable stand, my Apple Watch betrayed my heart rate. It was everything I wanted for my next computer:  display separate from the CPU 27" 5K Retina Display with native 2x resolution beautiful construction a height adjustable stand At $1600 I wouldn't hesitate.  But add $400 for the he...

  When I wrote " Beauty In The Eye Of The Coder ," my idea of beautiful code was how well it stood up to time: Requirements change, database fields are added, code is refactored by multiple authors. Time conspires to distort and contort programs, but the ones that endure are often considered beautiful.   The book  Software Engineering at Google  tackles the nearly incomprehensible scale of Google's software engineering efforts, and the subhead " Lessons Learned from Programming Over Time " caught my eye. Was there room for beauty in software that was engineered for scale, time, and cost? More on that later. I discovered  Software Engineering at Google  at an online  ACM TechTalk , and the book's curators, Winters and Wright, provided an excellent starting point for exploring the book's hefty 600 pages. The authors distinguished programming from software engineering, and they were careful to point out that one was not better than the other because the d...

  I first heard of Dijkstra from one of his quotes condemning the BASIC programming language: " It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. " I couldn't help but smile, and while I easily agreed, I wanted to know more about his thinking.  Dijkstra's full essay can be found in his book Selected Writings On Computing: A Personal Perspective . (See chapter EWD498, or go online .)  Titled "How Do We Tell Truths that Might Hurt?" his criticism extended to other languages such as FORTRAN and COBOL, and even to PL/I, a language I sort of liked :  "PL/I —'the fatal disease' — belongs more to the problem set than to the solution set." Ouch. Dijkstra's tone was understated humor -- less to make you laugh and more to have you reevaluate some of the norms in computer science. Keep in mind that this essay ...

It's August. IBM introduced their PC this month back in 1981, and connected the corporate and hobbyist computing worlds. Shown here are the reference manuals in their classic D-ring binders. I used the denim blue Technical Reference manual the most. It was filled with hardware information covering I/O ports, memory locations, and DIP switches. The most important bit to me, however, was the the ROM BIOS listing. Written in 8086/88 Assembler, it was neat, structured, and copiously commented. Below is a fragment describing how to interact with the keyboard: Keyboard INT 16H Despite the information being clearly written and readily available, IBM PC internals were considered by many as dense and arcane, which made it a natural filter for those seeking jobs programming for this machine; that is, only those who found this material fun and fascinating need apply. Over time, as programming went to higher level languages and turned to the web, knowledge of the ROM BIOS became less important...

  A man page will give you, in black and white, specific information about UNIX. Brian Kernighan's new book adds color and depth about UNIX you won't find anywhere else. I'm not a gray beard (yet), but I imagine they would plow through the book knowingly, but at the same time, learn a few things. Those new to UNIX -- recent college grads or those experimenting with Raspberry Pi -- would be better off starting with Chapter 8 which describes more relatable events and the descendants of UNIX, including Minux and Linux. It's when they start to ask questions like "Where does UNIX come from?" and "Why is Gamora grep?" that they should start from the beginning: Bell Labs, 1969. Kernighan opens with a birds-eye-view of Murray Hill New Jersey, zooms in on the buildings, the offices, the significance of Center 1127, and offers a brief look at some of the key players there. As I progressed through the book, the two factors that made UNIX not just possible, bu...

I'll take hexadecimal addresses for $200. Answer: Hex B000 Question: What is the starting video address for the IBM monochrome display. I'll take hexadecimal addresses for $400. Answer: Hex B800 Question: What is the starting video address for the IBM graphics display. August 12th marks the 39th anniversary of the IBM PC , making it a good time for a nostalgic look at Peter Norton's book, Inside the IBM PC . Before computers became personal, they were large machines housed in refrigerated rooms and guarded by stern, but good wizards in the tradition of Gandalf or Dumbledore. The PC, in contrast, sat on my desk, and without a gatekeeper, allowed me to explore, experiment, and crash the machine to my heart's content. Norton served as an excellent guide, and while the contents are mostly the stuff of trivia today, the book opened up a new world for me back then. Of course there were other personal computers from that era, such as the Timex Sinclair , the ...

Before the personal computer, there were minicomputers and mainframes. I understood them as large machines housed in refrigerated rooms and guarded by stern, but good, wizards (system administrators). The personal computer changed that. With a PC at home and sitting on my desk, the internals -- cpu, memory, graphics card, and disk drive -- became accessible. It was a revelation. Reading The Deficit Myth gave me that same revelatory feeling, although in the field of economics. Before Dr. Stephanie Kelton's book, I understood that deficits were bad, while balanced budgets were good. That is, the government should manage its money like a household: spend only what you can afford, and avoid debt. The household budget approach was relatable, and sounded right. But there were nagging inconsistencies that a household budget approach could not explain. If deficits were bad, how did they successfully fund the space race to put a man on the moon? Or pay for wars (necessary or not)? How ...

Rules are made to be broken , so the saying goes. The Art of UNIX Programming isn't exactly a rule book.  Rather, it explores the philosophy and culture behind UNIX -- its strengths, weaknesses, patterns, and associated tools.  First published in 2004, it is still relevant today and essential reading for server side developers. As for rules, in my career writing software, I may have broken two.  The first was using threads. I felt a little panic when I read the section titled  Threads -- threat or menace? It was in the early days of threads, and I had already implemented a threaded server. Did I make a mistake? Could I have done a better job with UNIX processes and IPC ?  Raymond argued that the complexity of threads outweighed their advantages.  Performance gains were lost to data locking and synchronization.  Abstraction was compromised because you needed to know the internals to prevent deadlock.  Threads were not portable. These...

This book is what you get when you ask 38 top software developers "What is beautiful code?"  An open ended question, you get diverging answers such as a deep dive into a regular expression matcher from Brian Kernighan, an optimization of population counts from Henry S. Warren Jr. (for bit-heads, not sociologists), and a treatise on why code is better treated as an essay from Yukihiro "Matz" Matsumoto. For this post though, I want to focus on Jon Bentley's contribution, curiously titled "The Most Beautiful Code I Never Wrote."  Elaborating, Bentley writes In software, the most beautiful code, the most beautiful functions, and the most beautiful programs are sometimes, not there at all. He then uses the Quicksort algorithm to illustrate his point, first reviewing the code, instrumenting it with counters, and optimizing it along the way.  But the pressing question he tries to answer is: "How many comparisons does Quicksort make, on average, f...

This is an odd book.  It is a classic, yet among the least useful books in my library.  The authors Gamma, Helm, Johnson, and Vlissides, affectionately referred to as the "Gang Of Four," wrestled with Object-Oriented Programming (OOP) to produce a catalog of solutions.  Inspired by the pattern languages used in architecture -- notably by architect, design theorist, and professor, Christopher Alexander -- they worked to imbue software development with the same formality, benefits, and gravitas of the age-old discipline. To some degree, the "Gang Of Four" succeeded. They explored and reinforced a working vocabulary regarding software design such as Model View Controller, Singleton, and Factory.  Unfortunately, they also promoted jargony and academic terms such as adapter which is better known as wrapper, observer for publisher/subscriber, and compositor and composition for formatting classes. OOP, while still popular, is waning, yielding to both new styles such ...

If you were to judge a book by its cover, you would, from the image of the keyboard, conclude this book is old.  If you were to judge this book by what's inside, you would conclude likewise because the examples are written in C and Awk.  But were you to look deeper, you would see that these are no ordinary pearls. Jon Bentley wrote a regular column for the Association for Computing Machinery (ACM) and his essays were collected into two of books: "Programming Pearls" and "More Programming Pearls."   The first book focused on speed and efficiency, while the second book covered that and more, including debugging, I/O, and enlightening "Aha!" moments. Because these essays were originally written for a monthly magazine, Bentley recommends taking it slow, reading one column per sitting, and trying the exercises.  Thankfully, he doesn't leave you hanging, and provides answers at the end of the book.  Chapters 5 thru 8 are the exception and can be ...

Where did that idea come from? How difficult was it to bring the idea into reality? What does it feel like to develop a major program? Susan Lammers interviewed 19 programmers along these lines to capture and understand what spawned the microcomputer industry.  With such an eclectic group (click on cover image), Lammers touched on the popular platforms, languages, and applications of the day, including CP/M, BASIC, and VisiCalc.  She also explored the boundaries where programming met music , mathematics, and gaming. One of my favorite quotes in the book came from the  conversation with Bill Gates where he talked about "technical inversions": GATES: The old rule used to be that a manager of a programmer was always a better programmer, and there were no what we called "technical inversions," where a programmer works for somebody who doesn't know how to program. We still follow that philosophy: At certain levels we've got business managers, but we don...

Anyone involved in computer programming should be familiar with the works of Donald Knuth (the K is hard and the name is pronounced Ka-Nooth).  If not, the New York Times can remedy that, having recently published a profile on Knuth titled The Yoda of Silicon Valley . Wise he is.  Show he does, the dark and light arts of algorithms: Volume 1: Fundamental Algorithms Volume 2: Semi-numerical Algorithms Volume 3: Sorting and Searching Volume 4A: Combinatorial Algorithms A very important concept, however, can be found in the title.  While students study computer science , Knuth reminds us it's still an art .  In that sense, I would compare his books to the collected works of Shakespeare -- creative, insightful, but difficult to read and better understood in a study group or book club.  Whether Knuth or Shakespeare, their works are rarely read in their entirety, but their impact can still be felt throughout society. Programming is a science, ...

While not a book, it is a classic. Published November 1983 with 720 pages, the magazine featured articles describing the innards of the IBM Personal Computer. The clever cover art shown here was created by Robert Tinney.   Byte's Robert Tinney era spanned from the mid-70s to 1990, and his covers showed an uncommon thoughtfulness.  Think vinyl record album sleeves of the day, where the artwork could have meanings on multiple levels. Inside, you can find an interview with Philip Estridge, president of IBM's Entry Systems Division, and it included a discussion about keyboards. IBM was renowned for building high quality keyboards , and the unique tactile and audible feedback carried over to the keyboard for the IBM PC.  But the atypical placement of the left shift key and the return key, along with the function keys being on the left instead of across the top, prompted Byte to remind Estridge that " some customers were upset. "  The layout didn't match the keyboa...

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-...

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 wa...

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 wa...

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...