System Control

Professionals Use Their Tools

In general, people today are afraid to surround themselves with equipment if they use the computer professionally. The computer companies also wish to portray the computer this way, as being self-contained without the need for any outside devices. The noted exception is the area of electronic music, where the musicians can be found filling their studios with racks of controller devices.

This time, for programming, going to the future means going back to the past, because in prior decades it wasn't considered strange to have extra controls for a high-end computer that was being used for professional purposes. Below is the PS300, a computer graphics system sold in the 1980s by Evans and Sutherland Computer Corporation.

To introduce the personal computer to the masses with the Macintosh, the average computer was shipped with just a keyboard and mouse. This notion stuck and became applied to everyone. Programmers in the 1980s and afterwards began to believe that what the average consumer uses to interact with the machine is all that they would ever need themselves.

A general use device like the mouse can have a negative side: if it is used too frequently for purposes that need specialized hardware, the situation becomes burdensome. But when everyone has been using it like this for a long time, you have to look to the past.

Professional video editors, who recognize that the machine (implemented in software) that they interact with-- the timeline device-- benefits from mechanical controls. The video timeline is really like a mechanical device implemented on screen. It would have various gears driving it. So, that's why even consumer video editors might be found using a control deck. It matches what they are doing.

Most 3D professionals appear to use keyboard and mouse to do their jobs, which is rather odd given what they are trying to manipulate on screen. Using external hardware isn't emphasized by 3D software companies today, they never sell 3D peripherals to go with their software.

Searching for new peripheral hardware and getting acquainted with it is its own chore, which is part of the issue.

A Custom Keyboard for Programming

Above: A single-handed Koolertron keyboard, with Xcode macro labels applied, sits above a regular keyboard.

The Razer Tartarus. (Razer)

The Elgato Streamdeck XL. (Elgato)

Providing More Than Just Convenient Macros

Just because you've only used a regular keyboard to write software doesn't mean that's all there is. Now more than ever, there are a large variety of external keyboards and macro devices that you can buy to assist you in the task of writing your code. Actually, there are so many available today you might not know where to start for this purpose.

After you buy a macro keyboard, the key issue is how you decide which macros to put on the device because, at first, this step is overwhelming if you are just reacting to whatever functions are in the menus in the software. That isn't the way to go. You have to put together an overall set of goals as to what you want the macro keyboard to be doing for you. It's not an area people are involved in today, but it definitely is worth it to keep revising your macro keyboard if the layout isn't where you want it to be.

Our view is that usually you don't want a macro keyboard that just works for one app at a time. You want to be able to access most parts of the computer because you will be moving around the computer as you program.

This section explains a Redesign.Codes approach for configuring a programmable keyboard for an IDE, in this case Apple's Xcode. The key arrangement provided here is intended for wide control of the computer. It facilitates movement across the IDE, apps, windows, tabs, and the web. There is a key that switches back to Xcode from any other app. You don't leave yourself just with a set of macros for the IDE because you will want the macro keyboard to help you elsewhere.

Whatever device you end up using for your macro keyboard, the discussion here should assist you in making your custom configuration.

Single-Handed Keyboards

It is possible to take an extra keyboard you have on hand and assign a macro to each key using third-party software, such as Keyboard Maestro for Mac or Autohotkey for Windows. That will work, but we like that a keyboard can fit right next to our existing one.

So on this page, our objective is to provide more of a normal product experience. That is why we use a single-handed keyboard. Our interactive layout is designed for the keyboard to sit above or to the left of a regular keyboard.

Since first publishing this article, it was discovered that a QMK-based macro keyboard is one that is supposed to be programmable for the future, as QMK is an open source firmware. That means the software doesn't have to be made by the manufacturer for you to program it later (apparently).

There are many of these devices available for purchase. The easiest way to find a macro keyboard is to type in "macro keyboard" into shopping websites. You can also type "QMK macro keyboard" for QMK-based devices. Many of them target a gamer audience, with the most recognized brand being Razer. Razer makes keyboards, mice, controllers, etc. specifically for gamers. Since this isn't a product review website, we have not purchased a wide range of macro devices and are just discussing the overall market situation.

Sometimes mentioned for this kind of task is the Elgato Streamdeck (below), which is more of a control deck than a keyboard. It is popular among live video game "streamers" who broadcast their video game playing to a live web audience, but the device is also used by photographers and it says video editors as well.

It's even more the case you need to make a plan for these kinds of devices if you make a macro setup for them. Since each key's transparent plastic sits atop its own LCD display, it is possible not only to provide a custom image for each key but also make navigable subtrees for the device in which pressing a button changes all of the buttons to contents of that folder. This device would certainly be helpful for programming because of its flexibility and its XL model (32 keys) could be very productive if tailored for an IDE. However, you would have to evaluate that on your own. The Streamdeck website appears to show that Elgato's configuration software is feature complete. The cost is higher for this device line than most options, and they are not exactly keys but buttons.

The Koolertron

To make a custom Xcode keyboard, we used the Koolertron Single-Handed Programmable Keyboard, which is not gamer-specific and is promoted as general purpose. Should you buy it? Not necessarily, because its configuration software is kind of raw.

The Koolertron Single-Handed Programmable Keyboard (48 keys). The software to configure this only works on Windows, unlike Razer Synapse, and we can't recommend its quality.

Putting Labels on the Keys

To make labels for the keyboard, the SF Symbols image set that Apple provides developers gets the job done quickly. and we placed symbols in a table in Pages (enlarged screenshot below). The row height and column width are both set to 0.5 inches.

In the case you don't buy transparent keycaps online, you just apply the labels to the top of the key. But the transparent keycaps have a plastic shell that sit on top of the keys and you don't have to print the labels out on label paper because it sits underneath the plastic.

Important to note is that not all label paper is intended to be peeled off and if you use regular label paper there will be some amount of adhesive residue permanently stuck to the keys. This is why a macro keyboard with replaceable keys can be valuable because its plastic keys can just be replaced if there is too much glue buildup. Of course, if what you replace a key label with is another key label, it doesn't matter too much that there is some glue residue leftover from before.

You can download the keyboard labels PDF here or the editable Pages (.pages) file here (note: utilizes two third-party fonts) so that you can print out the keys' labels on label paper with a color printer. Since there is no spacing in the table you can cut them out in pieces with scissors and place them on the Koolertron keys. The label paper to buy is the kind that has no cuts on it, such as this one.

Labels for a 48-key Macro Keyboard.

The keys in the image above are color-coded as follows.

• The aqua blue keys are specific to Xcode. You would make them specific to your IDE.
• The light green keys activate global GUI functions, such as Mission Control (Control↑), keyboard control of the Dock (Control F3), and keyboard control of the menubar (Control F2). On Windows you would make them specific to the equivalent OS features.
• The orange keys are specific to the web browser.
• The white keys are universal keys for navigating forwards and backward, moving across tabs, and making new tabs. (The blue tab keys exist for Xcode because Xcode uses separate tab shortcuts from normal apps.)
• The dark gray keys serve to exit, hide, or close (windows, apps).
• The light gray keys carry the three mouse clicks as well as minimize and maximize of windows.

Selecting Text and Using It

The Left Click key serves multiple purposes apart from normal clicking. Two mouse clicks selects a word, as usual, just as three mouse clicks selects a line, and this can be followed by other keys. The Left Click key will also make drag events if held down, allowing for multiple lines of text to be selected (or dragging of windows). After a selection is made, the text will be usable with the following keys in Xcode:

• Reindent
• Cut
• Copy
• Find in Project
• Find
• Find Selected
• Open Quickly

Configuring The Keys on The Koolertron Keyboard

To make our custom keyboard, all that we are doing is assigning key shortcuts to individual keys (inside the Koolertron software). A few key shortcuts have to be custom-made so that we can launch Xcode, a web browser, Launchpad, and the iCloud Finder directory, which are not tied to any existing Mac OS shortcuts. We tie them to custom Automator Quick Actions. You can only launch a Quick Action with the keyboard after you assign it a shortcut in System Preferences, which we talk about below.

One issue is that the Koolertron keyboard configuration app is only available for Windows, as mentioned. However, since all keyboard peripherals transmit the same HID codes-- the codes that travel across the USB cable to the computer-- it makes no difference for the Mac. In the Koolertron software, where you want the Command ⌘ key, you select the Windows ⊞ key. Where you want Option, you select the Alt key. That's it.

We have included the .bin Koolertron file for download here, so you can just load the shortcuts we already made into the Koolertron software and save it to the keyboard.

The Keys and Their Shortcuts

What is the most common sequence the programmer follows? Build the app to see if it builds, run the app (and build it if it is not), Stop the app, then switch back to the IDE after testing.

1. The Build, Run, Return to the IDE (Xcode) Keys

We first place the Stop (Command ⌘.), Build (Command ⌘B), and Run (Command ⌘R) shortcuts in the lower righthand corner. When these actions are assigned to individual keys and also placed next to each other, it is a much improved IDE build experience. To the left of these keys is Xcode, which lets you switch back to the Xcode app after you are done trying out your build. It will launch (or switch) to Xcode from any app.

We achieve this Xcode key by making an AutomatorQuick Action. After you make a Quick Action in Automator it right away shows up in the Services menu because it saves it to ~/Library/Services/. Next, we want to activate this service with our own shortcut of Option + F8, which is what we program on that Koolertron key, in the Koolertron software. Here is where you set up a keyboard shortcut for a Quick Action just after you have made it in Automator:

System Preferences > Keyboard > Shortcuts > Services.

There are other build-related commands we could put on the keyboard, such as Clean Build Folder, but the goal here isn't to make this key arrangement comprehensive. What we want is to cut down on Xcode and Mac GUI friction overall.

(Page in Progress.)

Why Apple's Old Desktop GUI Is More User-friendly

1. Fluid Keyboard Shortcuts

In 1980s and 1990s it was something new to use a GUI controlled with a mouse. Back then, it was a "shortcut" to activate an application's Quit function directly without moving the cursor up to the system menu. But few people regard it that way today.

Only the novice computer user relies entirely on the mouse to minimize and close windows, and open documents. And only in the 1980s, when the GUI was regarded as new, was it believed that the computer user would use the mouse most of the time for most tasks. Therefore, for any operating system, keyboard shortcuts are a core interface for using the computer, and they should not really even be called "shortcuts" anymore. On this topic, Apple has had held an advantage.

It is a smoother experience for long-time Apple users to use the Mac because the keyboard shortcuts were completely laid out in the 1980s, implemented as part of a considered plan. Microsoft's shortcuts were added in different stages and haven't been reworked into a systematic configuration. As a result, there is a lot of discord that occurs when interacting with the Windows 11 operating system.

In the Mac OS, command shortcuts that correspond to essential operations (Open, Save, Print, Close Window) grow from a single modifier key, the Command ⌘ key. From there, the more distant the function is from common usage, the more modifiers will be tacked on.

Windows has no unified, underlying scheme like this. Essential keyboard shortcuts could start with any one of three modifiers: Control, Windows ⊞, or Alt, and although Control often can be viewed as equivalent to the Mac's Command ⌘ key, this isn't always the case. Microsoft Windows keyboard shortcuts aren't kept consistent because they were added at different times and then when the apps were made no one could do anything.

There is a certain logic behind the Mac keyboard shortcuts because they start out simple (using only the Command ⌘ key) and grow in length as their functionality becomes more specific. This might be one of the biggest reasons people stay with Macs after buying them.

Essential Mac shortcuts are easier to deal with because of Command ⌘ being the foundation key and they adhere to this convention; it is less common to see a Mac keyboard shortcut that does not use the Command ⌘ key, but there are exceptions for pro apps. The Command ⌘ key is generally the foundation on which other modifiers are appended. (The more pro an app is, the more likely it is to make use of shortcuts that are independent of the command key.)

It's a lot harder to memorize Windows 11 keyboard shortcuts because they could start with one of the three keys. In multiple areas, Microsoft Windows has a longstanding problem of neglecting to establish a set of conventions and then promote them as the preferred standard across its entire GUI and operating system. It's just that this is especially noticeable when talking about its keyboard shortcuts.

The Windows ⊞ key, which could have been used to solve some problems where Control and Alt are used inconsistently, serves a category of functionality that doesn't necessarily need to be designated as a single key. The Windows ⊞ key usually activates global user interface functions, like the start menu.

The Windows ⊞ key appeared with the introduction of Windows 95, but just placing new keys on the keyboard won't fix the irregularity in Windows shortcuts if no effort is made to put some hierarchy into the situation. It matters where all of these keys are placed, too, and in what circumstances the user reaches for them.

Currently, the Mac follows a scheme that no other operating system matches because the thumbs are right next to the Command ⌘ key at any time. Had the Windows ⊞ key been made the focus of Windows when it was adopted in 1994, this still would not have worked as well as Alt because it is an additional key over from the spacebar.

The Command (⌘) Key Sits Next to the Mac Spacebar, Working as a Pivot for The Thumb

The entire system of Mac shortcuts is ergonomic. There are several aspects to this.

First, the placement of the Mac's Command ⌘ key matches the resting position of the thumbs on the spacebar, so activating a shortcut is a matter of moving one of your thumbs half an inch from the spacebar, holding down on Command ⌘, then pressing the specified alphanumeric key. After people change to this from Windows, they don't want to go back.

You can see the Command ⌘ key as working as a pivot for the thumb. You only have to move your thumb by one key to hit that pivot, too. The second key that you hit along with Command ⌘ with one of your fingers only has to be pressed briefly. This is very straightforward and works because it feel like the hands are bouncing if you are activating multiple commands one after another.

The Two Command ⌘ Keys Efficiently Map the Keyboard's Layout to Both Hands

There is another benefit to this setup, too. The two Command ⌘ keys on either side of the spacebar work in tandem because you will use the right Command ⌘ key to hit O for Open and P for Print, whereas you will use the left Command ⌘ key to hit Q for Quit and S for Save. They divide the keyboard up evenly for quick access to any alphanumeric key.

Therefore, when you sit in front of a Windows machine and swap out the Command ⌘ key for the Control key (which is three steps away from the spacebar) you no longer have that same fluid setup. You are now lacking the same pivot location for the thumbs, where you can quickly hit an alphanumeric key with one of your fingers. You are now using your pinky finger to hold down on the pivot location, not your thumb, because the Control key sits on the edge of the keyboard. This is when problems start to emerge for interacting with Microsoft Windows.

The Mac works well for the power user because it really does matter where the modifier key is located on the keyboard. It also matters which finger you end up using to press the modifier (especially if it acts as a physical pivot), and it is important how the modifiers are laid out in relation to their purpose. Windows does not take these issues into consideration and did not design all of the shortcuts in combination to enable power users to move fluidly across the computer.

This is why veteran Mac users always prefer the Mac. It's why they can get certain things done much faster, even if their computer happens to be slower than a PC.

Mac Shortcuts Are Usually Not Far from the Hands

Additionally, most Windows shortcuts require interrupting the resting position of the hands. Since the thumbs are usually hovering near the spacebar when using a computer, the shortcut for closing a window in Microsoft Windows requires semi-contortions of the hands (Alt + F4). Pressing Alt + F4 requires stretching your hand across the vertical span of the keyboard from the very bottom row all the way up to the top. This is the shortcut for one of the most commonly accessed functions.

There are some other shortcuts that are also more natural to use on the Mac. Renaming a file on Mac involves simply pressing the Return key. This works because your right pinky doesn't have to move very far to press the Return key (and it isn't acting as a pivot either). Meanwhile, for Windows, the shortcut for renaming a file is assigned to F2— a total interruption of the resting position of the hands. With F2, you have to lift your entire hand and reach up to the topmost row of the keyboard. What this tells us is that if an operating system is going to provide keyboard shortcuts, they also need to be laid out to be convenient.

In the table below, the keyboard shortcuts in Windows often require lifting the hand from its resting position.

2. GUI Issues in Windows

What you didn't know you had in Mac OS that makes you uncomfortable using Windows:

• Mac OS has always operated around a UI convention that Windows does not have, which is a critical difference: an app is still treated as open at the point all of its windows are closed because of the system menubar. At the point a Windows app has no open windows, it is treated as exited by the OS. A Mac OS app, when made active, has its command list loaded into the shared, fixed window element, the system menubar. On Mac OS, an app can receive commands through this global menubar, whereas on Windows an app only takes commands through the app's own generated windows. The Mac's global menubar serves the scheme of management for app interaction.
  
  On NeXT machines, this global menubar list of commands was set up vertically, as an independent window, and it sat in the upper lefthand corner of the screen. The added benefit of the Mac menubar is that other items can be added to it, like date and time, which condenses the current app's command list with other helpful global information.
  
  Mac OS centers around the "active" (current) application in its maintained list of open applications, and the global menubar reflects the active app's command list with or without windows present. If there are no applications open, there is still the Finder application that is never exited, and then it becomes the active application. There will always be at least one application open, then, and what the user cycles through is this list of open applications. Changing the active app alters the contents of the system menubar (that is always displayed). Because of the menubar on Mac, it is unambiguous when an application is the active application. Only when a specific application is made active will its windows receive the first mouse and key events.
  
  Windows instead focuses on what window is the active window. It does not center around the list of open applications. If all of a Windows application's windows are minimized, there is no way to control the app any longer. But a Mac app can be sent commands (through the menubar) even if it doesn't have any windows open or visible. Windows creates a mess by not placing the application windows underneath the applications themselves schematically.
• In Windows 11, it isn't natively supported to cycle through windows of the active application (pressing ⌘ + ~ on Mac). Win10 will cycle through all applications' windows, only, which you may not have noticed, and this isn't usually what the user would do. You can install a third-party app (Easy Window Switcher) to add this Mac functionality to Windows.
• In Windows 11, there is no shortcut for minimizing a window with one key press (pressing ⌘ + M on Mac). It requires pressing Windows ⊞ + ↓ twice.
• In Windows 11, minimized windows are not visible onscreen unless the mouse hovers over an the taskbar's open applications. In the Dock, a thumbnail of every minimized window is always visible.

The Application's Menubar Could Be Located Anywhere in Windows

Windows apps today are in active experimentation with respect to their menus. Some have turned into vertical lists, while others (like Microsoft Office apps) have turned their file menu options into vertical tab views.

3. User Experience Problems in Windows

• Many Windows apps use the local Documents folder as the space to deposit anything they want to save for internal purposes. This creates a lot of clutter in the primary location for saving files. On Mac, Documents is consistently reserved for a user's files. Most Mac applications do not deviate from this.
• The Windows 10 interface does not provide enough contrast. There are not enough defining features applied to the windows that would set them apart from their backgrounds or neighboring windows. The titlebar is also too large. Interface elements, especially in UWP apps, are spaced too far from each other as well. It was not good that Microsoft removed all shading and outlines from windows in Windows 10. -->
• In Windows 10, Microsoft sometimes moves apps and system controls around from one update to the next. It also has two sets of system controls windows: one from the previous era of Windows and one for today's Windows 10 settings.
• The operating system is bundled with what are essentially promotional pieces of software, even though it retails for $129 and lacks important consumer software. Some promotional software is hard to delete, too.

4. A Lack of Essential Software Applications, Which Should Be Bundled with Windows 10

In the 1990s, mainstream computers arrived with barely anything to use. Today, an operating system needs to arrive in a turnkey state, and Windows still does not conform to this requirement.

• On the Mac, Preview is a multi-purpose document viewer application that allows quick viewing of images and PDF documents. Windows does not have any equivalent image or PDF viewer bundled with it by default and its photo viewer is the same as its photo album application. Free alternatives exist to fill in for this, but this is a problem brought by Microsoft.
• On the Mac, QuickTime Player allows viewing of video files without VLC. On Windows, it is almost a must to download VLC to view video files.
• On the Mac, iMovie comes by default, allowing video editing in the case you ever want to. But if you ever feel like doing video editing on Windows, you will have to find a third-party app.

The problem with seeking out free Windows app alternatives to the essential apps shipped for free with the Mac is that the third-party apps each do their own thing, with their own interfaces, and some open source apps pay little attention to their overall appearance, or they have cheesy things going on in them.

You can modify your Windows machine to make it more Mac-like with third-party tools, but the problem is that Microsoft Windows was not built for that and not all applications will behave the same next to your custom workarounds.

Foundation of Mac OS X Frameworks

Shortcomings in the Mac OS UI

Features Missing Because of The Transition from Mac OS 9 to Mac OS X

Generally, most people were relieved to move from Mac OS 9 to Mac OS X because the stability and speed meant that system crashes were rare and a frozen application could be force-quit without destabilizing everything. That was 20 years ago, but Mac OS (X) has remained generally the same since it came out.

The transition from Mac OS 9 to Mac OS X was not without its downsides; there were many features in Mac OS 9 that would have benefitted everyone if they had been carried over, such as the ability to pin folders to the bottom of the screen as individual tabs. The UNIX underpinnings of Mac OS X also make it much less user-friendly compared to the file organization of OS 9, where there were relatively few hidden files and arcane conventions. There are communities of classic Mac fans that understand this and talk about it, that sometimes the old Mac interface was quicker to navigate, and the conventions of the operating system are more suited to power users who may not want to become proficient in UNIX.

WindowShade

WindowShade was a Mac OS 9 feature that allowed the collapsing of windows, leaving just their titlebars. Then, the title bars could be dragged around. This was a useful feature because it meant that a window did not have to be minimized (Command ⌘ + M); it only had to be double-clicked for the window frame to be restored. In fact, there was no window minimization functionality provided in Mac OS 9. But today, in Mac OS (X), every window has to be minimized to be individually hidden, meaning that the squeeze animation has to be shown frequently, when hiding or showing the window.

Another benefit of WindowShade is that there is less need to resize windows to make space for others. You can also hide your apps (Command ⌘ + H) less often.

The Mac OS 9 Launcher vs. The Dock

The Dock was present in NeXTStep, but when it was redesigned for Mac OS X, it presented a few shortcomings. It lacked the customizable tabs that were included in the Mac OS 9 Launcher. Today, you have one choice: put all of your apps and documents into a single row. This is quite limiting compared to organizing tabs of your own making. With the old OS 9 Launcher, you could place applications that you used into to your own custom categories. You might have a tab dedicated to music-playing apps.

An updated version of the OS 9 Launcher is DragThing. Consider how helpful it would be to have a Dock tab dedicated to frequently visited URLs.

DragThing reproduces the functionality once found in the Mac OS 9 launcher. It actually got its start as an alternative to the official Mac OS 9 launcher because it had more features.

On Windows the company that provides interface controls similar to this is called Stardock. Their software has not been tested here.

The Confining, Round Tabs of Mac OS X

At some point, Apple UI designers decided that Mac OS X tabs should no longer look like file folder tabs, but rounded segments. All of Mac OS X's tabs became centered at some point, too. For programming apps, this is too rigid because there are times when tabs should be left-aligned and carry the appearance of real tabs.

The Environment of Mac OS 9 Encouraged Usage of Custom Icons, Which Made It Easier to Organize The Filesystem

There is a marker in Mac history: before Mac OS X arrived, there were lots of people making custom icons that people used and shared in OS 9. Afterwards, though, because of interface differences in Mac OS X, people couldn't as easily apply them to files in the Finder, and the way they appeared made the custom icon less noticeable, so the culture of making icons disappeared. The helpful aspect of custom icons is that it makes files and folders distinct from each other like objects in the real world. When there are custom icons, it is obvious what type of project a folder belongs to. The way to bring this back is to make sure it is very easy for people to apply custom icons to files and folders.

The Relationship between Redesign.Codes and Computer Science

Most people look to Apple for technological advances that will be adopted later by the mainstream. Often it was the case that Apple lead the way, in programming, in GUI conventions, and in industrial design.

However, the topics discussed on Redesign.Codes are far from what any Apple team would work on, unless they are just copying or following it. This website comes from a different starting point, and is not within the range of pursuits of Apple, any computer science department, or any software engineering organization. Generally, the field of computer science does not approach problems the same way as Redesign.Codes, and Apple software engineers are always hired for their computer science training first, with few knowing about graphic design or user interfaces. Yet, that is precisely what is missing from modern code that will make it better for computer scientists: graphic design and user interface.

Even when the speed of a CPU multiplied for many years, Apple stuck to the plain text format to make programs, as did computer science departments in universities across the world. There is a reason for this. The types of people who become computer scientists and software engineers are not those who would ever redesign the appearance of computer code to build up its capabilities. If they ever come into contact with this subject, too often they regard it as some kind of veneer and not impactful on the overall state of programming. They know how they do things today, and that is good enough for them, is often the reaction a person will receive.

In their work, they focus on code's syntax, the concepts that programming languages offer the programmer, and how the code is implemented inside the machine. Working inside these topics is not enough to overcome the limitations imposed by plain text.

There appear to be some exceptions at first, like Wolfram Language, but the fact remains that Wolfram Language suffers from the issue discussed in Conceptual Contexts, that there are far too many functions for programmers to be looking up at any given time, and they are hardly ever reusable for different computing subjects that carry very similar programmatic needs. In short, programmers do not have the programming environment necessary for learning a core set of skills that apply broadly, to a wide range of circumstances, so that they can make all kinds of programs without consulting documentation. The constant reliance on documentation is a problem that needs to be addressed, and it is basically never brought up for discussion.

It is safe to say that without Redesign.Codes pressing the issue, C-like languages based entirely in plain text would be taught unquestioned into the distant future. Taking code to a new level of appearance isn't an area that interests computer scientists at universities or the software engineers they train, who are later hired by computer companies like Apple, Microsoft, or Google. Yet, computer scientists and software engineers everywhere will benefit greatly when this happens.

In a compiler, it is the lexical analyzer that takes a plain text file and asseses what code it contains. These lexical analyzers will have far less work to do when they are analyzing a file containing markup. They get a lot wrong because they don't know where they are in the file. Right now they have lots of processing to do when they encounter the totally unknown slate that is a plain text file. There is no reason for them always to be walking into a dark room and feeling their way around the plain text. Yet, no widely-accepted, mainstream programming languages use markup underneath. The benefits would emerge immediately, as all sorts of features could be incorporated into programming because of the markup. The error messages produced by the compiler would be accurate.

There won't be graduate theses on the topics talked about on Redesign.Codes, as there won't be any advisors who feel qualified to talk about them. Usually the professors are well-versed in the specifics of computer theories, the programming languages themselves, or the computer's relationship to mathematics. In other words, topics rooted in modern science.

There are science-minded people who say that C has been around for too long, but there are few people who say that its format, plain text, should be completely transcended or else the software industry will continue to stagnate in this area and remain entirely C-like.