Interesting Opinion Piece at The Chronicle

On my Facebook feed I saw an interesting opinion piece published on The Chronicle by André da Loba titled, "Is Deep Thinking Incompatible With an Academic Career?"  As a computer science researcher who is interested in long-term, speculative research projects, and also as a person who, like the author, grew up in a low-income family and was considered a "gifted student," this article resonates with me, and I recommend reading it.

Our economy promotes short-term gains and not long-term initiatives; I blame over 30 years of artificially-low interest rates for this. This short-term thinking has affected not only industry, but also academia.  The heyday of 1970s-era Bell Labs and Xerox PARC with their focus on inventing the future, which requires long-term, risky research, has long ended; it's all about getting something shipped next quarter. Academia is not much better with its grant cycle and its "publish or perish" demands.  I believe one of the biggest problems in modern American society is its structural disregard for the future. Instead of saving and planning for the future, we collectively spend and live like there's no tomorrow. But what happens when tomorrow comes? From the standpoint of research, where will tomorrow's inventions come from if there's so much emphasis on next quarter's earnings or the next performance review cycle?

Alas, we need to pay our bills, and so we adapt and make do. But I'm starting to think that there needs to be an "alt-economy" for researchers, scholars, and creators who want to create, build, and pursue scientific discovery without the pressures of modern industry and modern academia.  I'm always contemplating my career, and I'm considering pursuing this vision when it is time for me to make my next career move.

Some Updates Regarding My Flexible, Composable, Libre Desktop Environment Project

Back in April I posted a proposal for a flexible, composable, libre desktop environment that will run on top of Linux and various BSDs.  Since April I have been fleshing out some of the design decisions, though I haven't started writing code yet, partly because there are other design decisions I want to make before coding, and also because there are some technologies that I still need to learn; I have experience building GUI applications (particularly using GTK and Glade), but I'm not as familiar with the lower levels of the graphics stack, and thus I need to gain more familiarity with 2D graphics programming in order to carry out this project.

Here are some key decisions I have made:

• The desktop environment will be written in Common Lisp in order to take advantage of the Common Lisp Object System, a dynamic object system that supports multiple dispatch.  I feel that using a dynamic object system will make it easier for me to implement a component-based desktop environment.  I plan to write demo programs that are also written in Common Lisp.
• The desktop environment will be for Wayland, which is expected to replace X for new GUI development in the future.
• This desktop will be written using its own BSD-licensed GUI toolkit, written for Wayland (although support for non-Wayland backends may be possible) and also written in Common Lisp.  There seems to be few options for BSD-licensed GUI toolkits; GTK+, Qt, and GNUstep are under the LGPL.  Having a BSD-licensed toolkit will maximize its adoption.
• This new GUI toolkit will be fully themable; programmers will be able to describe windows using an S-expression syntax.  For example, we could describe a window that contains the label "I'm a window!" and two buttons (one to change the color of the label and the other to close the window) using two S-expressions: one for describing the contents of the window, and one for describing its format:

; Content definition file
(window main
  (label i-m-a-window)
  (button change-color)
  (button close))


; Layout definition file
(window (main)
  :size (300 400))


(label (i-m-a-window)
  :text "I'm a window"
  :font "Helvetica"
  :font-size 20
  :position (20 5)
  :align left)


(button (change-color)
  :text "Change Color"
  :size (50 150)
  :position (100 100))


(button (close)
  :text "Close"
  :size (50 150)
  :position (260 100))

• Underneath the GUI toolkit will be a 2D graphics system that renders directly to a Wayland pixel buffer.  I am still exploring possible design options, but I've always been intrigued by the Display PostScript system used by NeXTSTEP and Sun NeWS, and I personally love macOS's Quartz 2D graphics system, which uses the same graphics model as PDF.  I am leaning toward also using PDF as the 2D graphics model of this desktop environment.

As I mentioned before, I haven't started coding yet.  Because there are still many technologies I need to learn, as well as other responsibilities that I have, I anticipate development of my side project to be slow.  Nevertheless, I hope to have a working prototype of the desktop environment completed sometime in either late 2021 or early 2022.

Where Did Personal Computing Go Wrong: The Abandonment of User Empowerment, The Rise of "Big Platforms," and Solutions

Earlier today I found out about a documentary being created by Daniel Krasner, Matt Rocker, and Eric Gade called Message Not Understood, which plans to show the history of personal computing and how personal computing deviated from the values that pioneers such as Alan Kay (a former Xerox PARC researcher who worked on the Smalltalk programming language/environment and who greatly contributed to the development of the graphical user interface) imparted.

I believe that one value that was originally stressed by pioneers such as Alan Kay and Bill Atkinson (an early Apple employee who created Hypercard, a programming environment that was quite popular with non-software engineers before the Web became widespread) that has fallen by the wayside is the notion of empowering the user through technology.  Personal computers were supposed to be about making people more productive by having access to computational power at home.  Computational power was no longer controlled by gatekeepers; it could be harnessed by anyone with a few thousand dollars and the willingness to learn.  The transition from command-line interfaces to GUIs such as the classic Mac OS and Windows helped democratize computing by making them more accessible to people who found command line interfaces difficult to use.  When the World Wide Web started reaching people's homes in the mid- and late-1990s, this added an entirely new dimension of power: the ability to have access to large amounts of information and the ability to communicate with people throughout the world.

What I believe was the fundamental shift that transformed personal computing (and, by extension, the Web) away from empowerment is the realization from industry giants that the platforms that they built, whether they are operating systems, web browsers, or web services, were lucrative sources that they could exploit.  Making the user dependent on a platform resulted in additional revenue.  The platform has to be good enough for users to be able to perform their desired tasks, but the platform can't be so empowering that it allows the user to operate in a platform-agnostic way without imposing serious costs, both in terms of inconvenience and sometimes in terms of money (for example, it's harder to switch from iOS to Android when one has invested hundreds of dollars in iOS apps that must be repurchased for Android).  Microsoft realized how lucrative platforms are when it made a lot of money selling MS-DOS licenses in the 1980s, and we are all familiar with the history of Windows and Internet Explorer.  I am of the opinion that Apple shows favoritism toward its walled-garden mobile platforms over the relatively-open macOS, and macOS is becoming more closed with each recent release (for example, the notarization requirement in later versions of macOS).  In some ways Google Chrome is the new Internet Explorer, and Facebook is the dominant social networking platform.

I argue that innovation in personal computing has stagnated since the advent of smartphones in the late 2000s.  Windows 7 and Mac OS X Snow Leopard, both released in 2009, are still widely praised.  Even in the world of the Linux desktop, which has been less affected by commercialism (although still affected in its own ways), GNOME 2 received more praise than the controversial release of GNOME 3, which led to the development of forks such as MATE and Cinnamon.  In my opinion, there are no compelling advantages of Windows 10 (besides Windows Subsystem for Linux) and macOS Catalina over Windows 7 and Mac OS X Snow Leopard.  But why would the world's biggest platform maintainers spend money on innovating these platforms when they are already so lucrative today?  Coincidentally, any one with a compiler could write a Windows app or (in pre-notarization days) a macOS app, but distributing an Android or iPhone app requires paying for access to an app store.

In many ways computing has become just like the rest of the media industry; computing is a medium, after all.  There are plenty of technologists who work on their craft who write excellent software and who help push computing forward, but it's hard to compete against platforms with valuations worth ten or more figures.  But it's the same with media, literature, and film; for example, there is plenty of good music being created by passionate people, but unless they are backed by huge budgets, they'll never reach the Top 40, yet the Top 40 is often lowest-common-denominator stuff.

Could industrial research turn things around and make personal computing more innovative?  Unfortunately I am pessimistic, and this has to do with the realities of research in a global economy that emphasizes quick results.  (I personally feel this is fueled by our economy's dependence on very low interest rates, but that's another rant for another day.)  The days of Xerox PARC and Bell Labs where companies invested in research for the pure advancement of science are over; it's all about short-term, applied work that has promises of an immediate ROI.  Moreover, why would Google, Apple, or Microsoft fund research on making personal computing more empowering when such empowerment would threaten the bottom lines of these companies?

What's the solution?  I believe future innovation in personal computing that encourages user empowerment is going to have to come from academia, government, non-profits, non-VC-funded companies, or hobbyists; there is no incentive for the major platform companies to switch.  One idea that I'm thinking about is the development of some type of "PBS for personal computing" as an alternative to "big platforms."  I am fond of The Internet Archive, as it is an example of a non-profit that is so important to the Web, and I hope the situation at Mozilla improves.  I also believe another important step to user empowerment is making programming easier for casual users, and making it easier for casual users to contribute to open-source software.  Back when Alan Kay was at his Viewpoints Research Institute, researchers there worked on a project called STEPS, which attempted to build a fully-working desktop environment with a minimal amount of code by developing domain-specific languages for implementing each part of the system.  If I remember correctly, they were able to implement a complete desktop environment with just 20,000 lines of code, most of it written in domain-specific languages.  The purpose of STEPS was to develop a system that was just as understandable as the Apple II and Commodore 64 and MS-DOS environments of the past, yet was just as feature complete as modern desktop environments, which are implemented in hundreds of thousands or even millions of lines of code, which is too much code for one person to understand.

Another Nice Blog Post about Component Software

I just ran across another great blog post about component software, this time from Graham Lee.  This article describes Brad Cox's vision of software ICs, components inspired by physical integrated circuits.  Brad Cox is the creator of Objective-C, a superset of C that implements a Smalltalk-like object system and is the foundation of the application-level APIs of NeXTSTEP, macOS's Cocoa API, and GNUstep.

Nice Blog Post about Composable Software

I just found this 2013 blog post from Paul Chiusano advocating composable software, including for web applications.  A lot of the ideas overlap with the ideas I discussed in my previous blog post proposing a new desktop environment for Linux/BSD that emphasizes composable software.

A Proposal for a Flexible, Composable, Libre Desktop Environment

Note: I posted a better-formatted version of this document here as a PDF file.  Unfortunately there are some formatting glitches with Blogger's HTML editor.

Disclaimers:

1. This is not an official project. This document describes my thoughts about a desktop environment intended for Unix-based operating systems that is libre (i.e., free software per the definition of the Free Software Foundation), is composable (where users can create command-line and GUI tools by connecting smaller tools together), and is flexible (where software tools do not impose a particular user interface, allowing the user to modify the UI of the tool to best suit the user's preferences). Whether or not I will work on it is something I still need to consider, but I'm sharing my thoughts for feedback to see if pursuing this as a side project is worthwhile.
2. I will be expressing many opinions in this document. In the words of LeVar Burton, "You don't have to take my word for it."

Problems with Today's Desktop Environments and Applications

1. Smartphone- and tablet-based UI/UX metaphors have been inappropriately applied to some desktop environments, resulting in a loss of usability compared to the desktop environments of the 2000s. This is especially apparent in Windows 8, GNOME 3, and (to a lesser extent) Windows 10. When Apple introduced the iPhone and iPad in 2007 and 2010, respectively, there was much talk in the personal computing world about mobile computing replacing desktop computing. The developers of Windows and GNOME were heavily influenced by this thinking, and they sought to develop versions of their desktops that aimed to be suitable for both desktop and mobile computing. Now, I must commend the developers of Windows and GNOME for taking risks. Windows 7 and GNOME 2 were well-received by many people, and it was a gamble changing these environments. The results were Windows 8 and GNOME 3. While these environments were well-received by mobile users, some desktop users were disappointed, feeling that the user experience was a downgrade from Windows 7 and GNOME 2. For Windows this led to people refusing to upgrade from Windows 7, and for GNOME this led to the fracture of the GNOME-based desktop community into GNOME 3, MATE, and Cinnamon, with both MATE and Cinnamon aiming to serve those alienated by GNOME 3’s changes. I believe the lesson in this is that developers of desktop environments should respect the fact that desktop computing has fundamentally different use cases than mobile computing, and trying to create a common interface winds up in misapplying UI/UX metaphors.
2. The UI/UX design fads of the 2010s, including “flat design” and the gratuitous use of screen space, are a usability regression from the desktops of the 1990s and the 2000s. Consider the Windows 95 and Mac OS 7.5 interfaces. It is largely clear to see which elements are clickable and which ones are not. This held true as late as the late 2000s with Windows 7 and Mac OS X 10.6 Snow Leopard. Contrast that with the flat interfaces of a lot of software products today where it’s much harder to visually determine which elements are clickable and which ones are not. It’s not just flat design that’s problematic; there are other design decisions I disagree with. In macOS, what were once easily-visible scroll bars that were colored in bright blue have been replaced with thin, gray scroll bars that are harder to use, with the assumption that we’ll be using our mouse’s scrollwheel or our laptop’s touchpad’s scroll gestures instead of the actual scroll bar. In Windows 10, the title bars look excessively large relative to the menu bar (the reason for the large bars is to be able to move the window in a touchscreen interface; this is an example of a design decision that would be appropriate for mobile computing but is unnecessary in desktop computing), and its windows in new-style programs often consume large amounts of whitespace. I would love to be able to switch to Classic mode (i.e., a Windows 2000-style interface) in Windows 10; on Windows I feel most productive in Classic mode. There’s just one problem….
3. Modern desktop environments and applications are increasingly curtailing the ability for users to control the appearance of their desktop environment and their applications. For Mac users this is not a new development. Ever since the transition from Mac OS 9 to Mac OS X in 2001, Apple has not provided mechanisms for users to apply themes that are different from the Mac OS X Aqua interface. Windows, however, used to support many modifications to its default themes. This changed in Windows 10 when it became more difficult to theme the desktop environment. In 2019 some GNOME developers wrote an open letter urging Linux distributions to not apply custom themes to their applications. Here is a key excerpt from the letter:

   “On a platform level, we believe GTK should stop forcing a single stylesheet on all apps by default [emphasis original]. Instead of apps having to opt out of this by hardcoding a stylesheet, they should use the platform stylesheet unless they opt in to something else. We realize this is a complicated issue, but assuming every app works with every stylesheet is a bad default.”

   Although the signatories of the open letter have explicitly stated that they are not opposed to end-users “tinkering” with the style of their applications, I feel that their suggestion to require GTK applications to explicitly opt into theming will, if implemented, make it more difficult for users to apply themes to their desktop environments and applications.
4. Many desktop environments and applications lack the ability for users to customize the UI based on their needs and preferences. UI/UX decisions are a major cause of complaints about software. In some situations users respond by rejecting that software, instead seeking out alternatives. In other situations, though, sometimes the user doesn’t have a choice, but instead must learn how to cope with the UI.
   But what if users had another choice? What if users were able to modify the UI of their software as they saw fit without resorting to modifying its source code? For users who are not comfortable with adjusting their UI settings, what if they could download UI configurations from a repository of user-submitted configurations, including from UI experts who ran formal usability tests? This would increase user satisfaction with software products, since users won’t feel that they have to accept the UI decisions that were made by the product’s developers and designers.Microsoft took a step in the right direction by allowing its ribbon in Microsoft Office to be user-modifyable. When the ribbon was introduced in Office 2007, it had few configuration options, and it was controversial among long-time Office users, particularly since there was no way to switch back to the menu-and-toolbar-based interface of Microsoft Office 2003. However, while later versions of Microsoft Office still do not provide a means to return to menus and toolbars, the ribbon has been made to be much more customizable.

Monolithic Applications versus Composable Tools

Contemporary desktop environments promote the use of monolithic applications where the application itself is expected to provide the functionality that users need in order to perform a task. Often these applications are “silos,” where they tend to not interact well with each other unless they are part of a common suite of applications such as Microsoft Office and the Adobe Creative Suite. While some of these applications may provide internal scripting support (such as Microsoft Visual Basic for Applications), most applications don’t provide external scripting support (e.g., the ability for a bash script or a Python program to be able to access Adobe Photoshop’s image cropping functionality in order to programmatically crop images).
I contrast this with the traditional Unix approach of combining small tools to perform large tasks. While there are many tenets of the Unix philosophy, there are three tenets that I will emphasize the most:

• There is no distinction between user and programmer.
• Programs should do only one thing, and do them well.
• Users are encouraged to combine small tools into larger tools using mechanisms such as pipes, I/O redirection, and shell scripting instead of developing large, monolithic applications that perform multiple tasks.

This philosophy is expressed and taught in the 1984 book The Unix Programming Environment by Brian Kernighan and Rob Pike, Bell Labs researchers who have played a major role in the development of Unix.
The idea of a user environment as a suite of composable tools is not inherently limited to command-line environments. OpenDoc was a project spearheaded by Apple, IBM, and other companies in the mid-1990s that encouraged software vendors to develop and sell components than can be combined by users and other developers to create larger solutions that were either in the form of a document or a larger application. The business goal was to challenge the dominance of large, monolithic applications by creating an ecosystem of smaller, composable utilities, allowing for more software companies to be able to compete in the software marketplace and also providing users and developers increased flexibility in their workflows. These components would run on the classic Mac OS, Apple’s eventually-cancelled Copland project, IBM OS/2, and other supported operating systems. Unfortunately, other than the influential Cyberdog web browser and a small handful of other OpenDoc components, OpenDoc did not last very long in the marketplace, and its impact was limited. OpenDoc’s development stopped in 1997 when Apple cut many engineering projects in order to focus on adapting the technology from the newly-acquired NeXT to its operating system strategy, which ultimately led to the release of Mac OS X 10.0 in March 2001.
Despite this setback, I believe OpenDoc was a victim of Apple’s circumstances, and I believe the ideas of OpenDoc should be re-explored for today’s desktop software.

Composable Tools Are Objects

One important key to building composable tools that work in programmatic, command-line, and GUI environments is using objects. OpenDoc was a C++ API backed by IBM’s System Object Model. However, there are rich dynamic object models that we can explore as alternatives, including Smalltalk’s derivatives such as Squeak and Pharo, Objective-C (which was heavily influenced by Smalltalk), and the Common Lisp Object System. By using dynamic objects as the foundation for software components, we can overcome the limitations of Unix’s pipeline approach to program composition, which relies on the weak link of parsing streams of text, and we can take advantage of the flexibility that dynamic objects provide as opposed to static objects. In fact, we can think of Unix utilities as objects with a run() method that accepts the utility’s command-line arguments and outputs a string. By explicitly expressing tools as objects, we allow for a much wider range of inputs and outputs that are not limited to text streams, resulting in a richer experience.

Separating UI from Core Functionality

A very important design tenet when developing composable tools is to separate the tool’s user interface from the tool’s core functionality. By not tightly coupling the UI with the underlying functionality, it is easier for the tool to be used under a variety of circumstances, whether those circumstances are (1) being invoked as an API call, (2) being run as a command line utility, (3) being run as a desktop GUI application, or even other circumstances.
As an example, suppose I want to provide a component that supplies a calendar. The object implementing the core functionality would supply methods such as retrieving the days of the week, figuring out whether the current year is a leap year, computing the numbers of days between two dates, storing events into a provided database, exporting to iCalendar format, etc. The Unix cal utility and GNOME Evolution can be rewritten to use the calendar component. This is how the same core calendar functionality can be used in a variety of settings, with the benefits of being able to use the same functionality without being restricted to a particular application.
This is also a guideline for converting existing software. Suppose GIMP’s core functionality were separated from its interface. This will allow for the creation of programs and command-line utilities to leverage GIMP’s image manipulation features without having to open the GIMP GUI application. This will also allow for the easier development of alternative UIs for GIMP, especially when combined with the ability for users to be able to customize the UI themselves.

UI Customizability and Themability

How will users be able to customize the GUI? I envision this to be a combination of two technologies:

1. OpenDoc’s ability to merge components in a free-form style as part of a visual container structure known as a Document.
2. With the exception of Microsoft Office 2007, since at least Microsoft Office 97 there has been extensive support for users to be able to change menus, toolbars, and/or the ribbon as they see fit.

How is this exposed programmatically? Each GUI component exports methods that implement some type of command. For example, a text editor would have commands corresponding to “Save File,” “Find/Replace,” “Delete Specified Lines,” etc. These commands would correspond to either menu items or toolbar buttons. Users can then modify how menus look, whether to use icons or words to describe commands in toolbars, whether to have a horizontal toolbar or a vertical one, etc.
All UI elements would be implemented under a common framework, and the framework chosen or developed will allow theming.

Not a New Operating System

For some time I’ve thought of the idea of creating either a Smalltalk-based operating system (e.g., imagine Pharo running on bare metal instead of as a siloed VM) or a Lisp operating system influenced by Symbolics Genera. The underpinnings of these systems would make an excellent base for implementing the ideas discussed in this document.
However, there are two main challenges with this approach of creating a new operating system:

1. A new operating system will lack device drivers. One of the things that hinder the development of non-Linux libre operating systems such as Plan 9, Haiku, and ReactOS is their relatively limited driver support. It will be a major effort writing device drivers for a new operating system.
2. There is also the “chicken-and-egg” problem of switching to a new operating system. Without certain key components such as a web browser (which will require porting Firefox or Chromium, a large effort, or creating a new web browser, which is an even larger effort), it would be hard to convince people to switch to the new operating system. But if the operating system has few users, then developers would be less likely to develop for it.

As much as I’d love to use a Smalltalk or Lisp operating system, I believe that instead of a new operating system, I think the best approach would be to leverage the libre GNU/Linux/BSD ecosystem and to build on top of it. This solves both the problems of device problems and the “chicken-and-egg” problem. Users can still run existing applications and use existing tools side-by-side with new components. These new components can even leverage the same GUI toolkits of existing applications in order to ensure overall system consistency.

Decisions to Make: Object Systems and GUI Frameworks

Two core decisions I’m considering are the object system and the GUI framework. For the object system I am enamored by the powerful Common Lisp Object System and it would allow for Common Lisp’s impressive live debugging features, but Objective-C is appealing due to its ability to call C and C++ code without the use of any wrappers. For the GUI framework I am partial to GNUstep due to its Objective-C foundation, which supports dynamic dispatch and would thus make it easier to implement component-based systems. Using GNUstep also has the side bonus of being able to bring macOS users into the fold and by providing native support for macOS.

Conclusion

Today’s desktop environments and applications suffer from a lack of flexibility, a lack of customizability, and a lack of composability among applications. This document proposed a new type of desktop environment and approach to application development that emphasizes components, objects that can be composed in ways that are even more powerful than Unix’s composable command-line tools. This document also advocates the development of GUI components that can be themed and also have malleable user interfaces. This new desktop environment will be built on existing Unix-like operating systems such as Linux and BSD.