I wrote this essay as part of a school assignment, which mandated I write it in a certain style. This is why it is written in a different style from my other posts.

In this essay I'd like to explain why I came to the conclusion that visual programming languages should be taken more seriously. I should probably start by explaining why I use textual programming languages. When I was a kid I wanted to make my own video games, I had the option to take a game programming class and middle school. This is was where I learned my first programming language, it was a visual programming language called alice. It could only be used to create very simple video games, This was kind of fun to do but I couldn't make anything useful with it. All of the other visual programming languages I've used (snap! and scratch), were the same, they were easy to learn, but they couldn't be used to do any serious work. In addition, they all relied on a drag and drop model of programming, where I would drag and drop blocks that snapped together to write my programs. This meant every time I wanted to use a statement I would be forced to look through a menu and find what I needed. I could discover every feature of the language by snooping around. This is great if you're a child who's new to programming, but became a hindrance as I improved. I got to a point where I already knew what blocks I wanted, and yet I still had to look through menus to get them. It was like I was trying to carve a marble statue with a tooth pick. When I switched over to using textual programming languages these problems went away. Instead of having to look through a menu to find an “if statement block” I could simply write “if (condition) {statements}”. What used to be multiple clicks of a mouse turned into a many of key presses on a keyboard. The other advantage was that the textual programming languages were general purpose, I could use them automating all sorts of tasks that would be tedious to do manually. Sure, the textual programming languages had a steeper learning curve, since I had to read a manual to find the staments I could use, and I had to worry about mistyping words, or missing a semicolon. But once I learned them the textual languages, I was far more efficient in writing them than I was for any visual programming language. I came to view visual programming languages like training wheels, I was done with them, I could ride my bicycle, I didn't need them any more. I concluded visual programming languages were only good for education and couldn't be used get any serious work done. This seems to be the most popular opinion amongst programming language users and programming language developers. Visual Programming language designers usually market their languages for education, or for use by non-programmers (like musicians in the case of Pure Data).

I've mentioned two problems with visual programming languages in the above paragraph, That they are domain specific, and that they have clunky user interfaces (having to click through menus). There are a couple programming languages that solve the first problem, PWCT (Fayed et al, 2020) is an example. It's a general purpose programming language that is purely visual. The second problem can also be solved, but I haven't found a visual programming language that solves it. This is probably due to social reasons. A blog entry by Stanislav Datskovskiy titled “Englebart's Violin”, explains the reasons well, but the gist of his argument is that in the field of computing, most user interfaces are designed like kazoos, rather than violins. Kazoos are easy to learn, but sound quite bad, Whereas violins are hard to learn and sound much better (2012). In this case the Visual programming Language designers have been designing kazoos, rather than violins. They have made their user interfaces easier to learn, at the expense of making them harder to use for experts.

The good news is that there's no reason that we can't make a visual programming language like a violin. In my years of programming, I've looked at many text editors and integrated development environments. I eventually settled on using GNU Emacs because it was highly customizable, and had a large community of developers that are willing to make writing code more efficient. As I got better with Emacs, I started to realize that it's much more efficient to work with code structures rather than plain text. Instead of typing out an “if” statement by hand, Emacs has keyboard shortcuts that let allow you to insert an if statement with a single keystroke, and fill in the data as you go. There are also extensions that allow you to navigate and manipulate programs at a syntactic level (Esterhazy 2017), rather that manipulating them letter by letter. After using these features, I realized that they were much more efficient than typing everything out by hand, but I also saw an irony. The Irony was that it would be much easier to program these tools if they had started with a visual programming language, rather than making them manipulate plain text. The best text editors work with programs as if it were a tree of language statements, rather than a string of text. Visual programming languages don't have any strings of text, they only have language statements. In that sense, good text editors poorly emulate what a good visual programming language's UI would be. If the designers cut out the middle man (that being the strings of text) and kept the same user interface, then we'd be much better off. In my personal experience, it is a pain to write Emacs extensions that work with a program's syntactical structures, since you have to parse the code before you do anything with it. A visual programming language's editor necessarily has the blocks of code to work with, so there's no need to parse the program, I would only need to ask my editor for a tree of blocks and then write a program that works on the tree. It would also avoid the problem of syntax errors, structural editing only works on plain text if the program has no syntax errors. This becomes a problem because every time you type or delete a character, you have a chance of introducing a syntax error into the program. For instance in C, if you write half of a function call (eg. “foo(” ), then your program becomes unparsable until you fix add the ending parenthesis to the call (Turning “foo(” into “foo()”). This isn't a hypothetical problem. I often want to look back at code to figure out what I should put in my function before I close it. Visual programming languages obviate this problem because they force the programmer to always write syntactically correct code.

Visual programming languages have many other advantages to textual programming languages. I'll bring two of them to attention, the first is that formatting is automatic, In textual languages you usually have to format the code manually, which is frustrating. I have personally seen tons of programs written by others where the formatting was noxious to me. Even if the code is formatted well, there's only one representation of the code. Every piece of whitespace looks the same to each person reading the program. Which means that everyone has to choose standard way to format their code if they wish to work together. Much like HTML, Visual programming languages separate the content of programs from their presentation. So each person's editor could be configured display the source code however they want. Which means there's no need to force everyone to agree on the same standard.

The second improvement is related to metadata. A program benefits from having lots of meta data associated with each section of code. For instance, it would be nice to know if a block of code has any unit tests associated with it somewhere else. In textual programming languages, It's hard to keep meta data associated with programming language statements since the text is constantly changing. This isn't a problem with visual programming languages because they can track every change to a block as it happens, so It would be much easier to attach meta data to a block of code. As an example, when I want to comment my code I have very few options. The comments are embedded within the text, so they fight over the same space. If I make my comments long, then they clutter up the program, so I have to choose between making my comments long and explanatory, or making my program easier to skim. If I were to use a visual programming language, it would be easy to associate a comment with a block of code. I would then have a lot more options on how I want my comment to be displayed. If it is short, I could present the comment as a tab on the side of the code. If it was long, I could make it a hyperlink to a larger document. I also wouldn't have to worry about my lines becoming too long, since the program would know how to indent them. It would be like Microsoft Word, where each line could be as long as you want, and the Program Editor would know how to wrap the statements properly. Snap! is a visual programming language with this feature.

In conclusion I think that a visual programming language could be superior to a textual one, Given that we actually try to make one for experts. It would allow us to focus more on content, and less on presentation, while allowing us to document our code better, and edit it better proficiency.

Bibliography

Datskovskiy, Stanislav (2012). Engelbart's Violin.

Esterhazy, Paulus (2017). Structural Editing, a Guide for the Perplexed – Paulus Esterhazy.

Fayed, Mahmoud S. and Al-Qurishi, Muhammad and Alamri, Atif and Hossain, M. Anwar and Al-Daraiseh, Ahmad A. (2020). PWCT: a novel general-purpose visual programming language in support of pervasive application development, CCF Transactions on Pervasive Computing and Interaction.

Datskovskiy, Stanislav (2012). Engelbart's Violin. http://www.loper-os.org/?p=861 .

Esterhazy, Paulus (2017). Structural Editing, a Guide for the Perplexed – Paulus Esterhazy. https://youtube.com/watch?v=ubcERtDyLDw .

Fayed, Mahmoud S. and Al-Qurishi, Muhammad and Alamri, Atif and Hossain, M. Anwar and Al-Daraiseh, Ahmad A. (2020). PWCT: a novel general-purpose visual programming language in support of pervasive application development, CCF Transactions on Pervasive Computing and Interaction.

---

By Logan Andersen. This work is licensed under CC BY-ND 4.0

You can see my other blogs here.

List of programming notations I've used a bit and how well designed I think they are.

Very well designed * Scheme * Prolog

OK * Common Lisp * Emacs Lisp * Python

Mediocre * C * Java

Bad * x86 assembly

Very Poorly Designed * Perl * Bash * C++ * J

Horrifying * COBOL * English

List of notations that seem nice, but I haven't used them enough to know. * Smalltalk

Notations I'm not sure about * APL

---

Notes, * I Like Common Lisp more than python but it loses points due to its enormous size, separate function namespace, and weird naming conventions. It is very baroque with strange naming conventions (e.g. progn, prog1, prog2, progv, #', function, set, setq, setf, defun, defvar, defparamater, funcall, rplaca, rplacd, do, do*, dolist, dotimes). * Python is getting worse and worse over time. List comprehensions and generator expressions made the language much more ugly. * J is nice to type, but it's very ugly.

---

By Logan Andersen. This work is licensed under CC BY-ND 4.0

You can see my other blogs here.

1.

The language I learned to program in [1] was python. I had been reading the reference documentation and knew that that functions were “objects”. I also knew a function could return another object. So I came to the conclusion that a function could return another function. (I also came to the conclusion that you could take functions as arguments).

def foo() :
    return 1

def bar() :
    return foo

2.

I had read about lexical scope after reading the reference documentation, if I defined a variable outside of the functions, I could use it inside (with some arbitrary restrictions python gives)

a = 4
def foo() :
    return a 

3.

I guessed that I could define a function inside another function. Initially I did this to keep very specific functions outside of code. It came naturally to me because it didn't feel like anything was special about functions in python, you could nest other block structures so I should be able to nest functions.

def foo(a) :
    def bar(x) : 
        return x+2
    return bar(a)

4.

I realized that I could use lexical scope to make custom functions. I was pretty sure this wouldn't work, but I decided to try it anyways, It seemed like witchcraft. It ended up working just fine.

def foo(a)  :
    def bar() :
        return a
    return map(bar,range(100))

5. (final)

I realized that I could return the custom functions I constructed and use them elsewhere.

def foo(a) : 
    def bar(): 
        return a
    return bar

I was stoked when I figured this out, I could create custom functions by calling other functions it was amazing. I called this “invention” a “function factory”, a function that returned another function.

The moral of the story.

If you are familiar with computer science, you know this term by a different name. The correct term for such a construct is a “lexical closure”. I had never even read the term “lexical closure” before, yet I was able to stumble upon it because the language didn't treat functions as something special. There was never special syntax for doing lexical closures, they were something you could accidentally stumble upon. When functions are special, you stop asking yourself about what you can do with them, and simply think that you can't do anything with them other than what you already know. If C was my first language, my thought patterns would have ossified and I would have never thought about defining a function in another function for any language. I would have needed to read about lexical closures before could even think about doing them. When I learned C, I actually tried doing a lexical closure, and was disappointed I couldn't do it.

I don't think I could have stumbled upon (IE not read it in a book) lexical closures if Common Lisp was my first language either, although I might have. You have to jump through hoops to use functions as parameters, but you can still do it, It's just harder to figure out because functions reside in their own namespace.

notes

1. I had used other programming languages before, such as perl and C#, but I didn't learn to program in them. I never learned deeply about them, or understood the art of programming from them.

---

By Logan Andersen. This work is licensed under CC BY-ND 4.0

You can see my other blogs here.

In the previous post I talked about getting the authors of source code. In this document I am talking about getting the authors of documentation instead.

To get the author of a man page, you can either look for the AUTHORS field, or check the man page source code.

The Linux man-page project discourages using the AUTHORS field and recommends putting your name in the comments of the man page source code instead (see: man-pages(7), (Faith, Rikard E. and Wheeler, David A. and Kerrisk, Michael, 2022)). This policy makes it harder to know the authors of the documentation you read. I like to know the authors so I disagree with this policy. The main reason they discourage the AUTHORS field is because the list could be too big.

Citing Info pages

Info manuals sometimes have the authors of the manual on the front page, other times they only have the authors in the source code. Usually they are rigged up so that only some versions (pdfs for example) have the author names in them. The info manual could also have a chapter to credit the people who worked on the source code, or the people who wrote the info document.

Getting source code for man/info files

Downloading source code

On apt, you can download a program by doing

apt source name-of-program

On guix it can be done with

guix build —source name-of-program

After that you simply need to look for the man pages or info pages in the source code.

Extensions and locations

Man page source code filenames usually end in a number, eg manpage.1, texinfo source code filenames usually have .texi as their extension.

Most of the time, the files are stored in the doc/ directory.

Bibliography

Faith, Rikard E. and Wheeler, David A. and Kerrisk, Michael (2022). man-pages(7). https://www.man7.org/linux/man-pages/man7/man-pages.7.html.

---

By Logan Andersen. This work is licensed under CC BY-ND 4.0

You can see my other blogs here.

When I get an idea from a program, I like to cite it in case I decide to look back at the source code (Eg. Fleisher, Lukas and Culot, Frederic, 2018). The problem is the guix package manager doesn't have any useful bibliographical information, so I have to hunt for all of it myself. The only useful part is the software version. It would be good if package mangers would state the author, year, download url, and title of the software.

Example citation.

@software{calcurse2018Fleisher, author={Fleisher, Lukas and Culot, Frederic}, title = “CALCURSE”, titleaddon = “text-based organizer”, year=2018, version=“4.5.1”, url={https://calcurse.org/files/calcurse-4.5.1.tar.gz}, note={Downloaded with GNU Guix Package Manager} }

The is an example output of a package description.

name: calcurse version: 4.5.1 outputs: + out: everything systems: x86₆₄-linux i686-linux dependencies: [email protected] tzdata@2022a location: gnu/packages/calcurse.scm:31:2 homepage: https://www.calcurse.org license: FreeBSD synopsis: Text-based calendar and scheduling description: Calcurse is a text-based calendar and scheduling application. It helps keep track of + events, appointments and everyday tasks. A configurable notification system > reminds user of upcoming + deadlines, and the curses based interface can be customized to suit user needs. All of the commands + are documented within an online help system.

Other ways to get the data

For the calcurse program, I got most of the other data by downloading it, and using grep on the files to find author and year information. I realized that this is a fairly bad way to get the data. A much better way would be to use the `–version` option on the file, and to read the man page. The README.md and Contributor files usually have some bibliographical information too.

Man and info pages have the downside of possibly being out of date, or only listing the authors of the man page rather than the program.

Bibliography

Fleisher, Lukas and Culot, Frederic (2018). CALCURSE.

---

By Logan Andersen. This work is licensed under CC BY-ND 4.0

You can see my other blogs here.

This is a rant.

I find that most GUI applications are too cluttered. Every widget on a GUI comes at the cost of screen space, efficiency, and user attention.

Screen space

For each widget on the screen, there's less space for what the user actually wants to look at. The end result of too many widgets is that the user is left looking at a tiny square in the middle of the screen. Most of the stuff around that tiny square is neglected. Integrated Development Environments are the most egregious examples of this problem.

Anything made for viewing and reading stuff should give all of its screen space to the thing it's displaying. There's no reason you should have anything on the screen at all. All control and functions should be provided by keyboard shortcuts. It can be useful to have many document tabs, have it so a keyboard shortcut can toggle the tab view, or have keyboard commands to select different tabs. If you need to navigate a gallery, then it is better to have commands to move around, than a file browser on the side.

Anything made for editing stuff should primarily focus on the object that's being changed. Editing programs should have keyboard shortcuts for changing tools and running commands. Information should be given to the user when they ask for it, it should never permanently stay on the screen. Most editing programs fail to have these properties.

The reason why programs fail to have these properties is because UI designers confuse user friendliness with beginner friendliness. The crutches beginners use to get their work done must be ditched as they grow into experts. Tricycles are beginner friendly but they are not friendly to expert cyclists. Almost all modern applications are tricycles.

Efficiency

When you have more widgets on your screen, it takes more time to find any individual widget. You spend more time bouncing your mouse around, this is especially bad if you need to use your mouse to input 2 dimensional data into what you're editing (eg painting applications). You spend most of your time moving from the button area, to where you want to edit and back.

As a band aid, you could make it so you could pop the mouse pointer position to a previous location on a stack. This would be useful in applications where you'd otherwise spend a lot of time bouncing back and forth. For a paint application, you would save your mouse position whenever you click the canvas, and save your mouse position whenever you click a button. You could middle mouse click to go back to a previous position. It would be good to make the mouse pointer grow and blink after a stack pop so the user knows where it went.

Attention

Some widgets can be distracting to use. This is only a problem in certain applications. Tabs on web browsers are distracting because people tend to have some tabs for play and others for work. In addition, the tabs encourage multi tasking, and multi tasking leads to doing everything worse.

Window managers are even worse, The average window manager has a task bar, people often have fun programs and work programs open at the same time. Every time you glance at the task bar, you are tempted to open the time wasting application. Even if you never do it, temptation slows you down, and makes work less enjoyable. People often leave windows floating around, which take up screen space and can act as distractions. Window managers should have every application start at full screen, and no buttons anywhere. Ratpoison or StumpWM are good examples. The desktop metaphor was a mistake; tiling window managers are superior. (Note: I've changed my mind about this. The desktop metaphor could actually work quite well. I've become disillusioned with tiling window managers.)

The Mouse is good

The cause of mouse hate is due to misuse of its features. Most mouse applications fail because the mouse is used to click buttons. UI designers essentially create a keyboard that can only be used with one finger (your mouse cursor). It is much slower to move your mouse around the screen than it is move your fingers to any location on the keyboard. There are tons of buttons on a keyboard, there's no reason why the UI designer should put any on the screen (other than beginner friendliness).

The mouse is fine if you are editing something two dimensional, Or need to move focus to some other area. In the case of focus, there should be search commands in addition to the mouse.

Right Click menus are also an abuse of mouse. You have to move your mouse to select the button you want. You are moving the pointer around way too much. The right mouse button should have an action associated with it, instead of a menu. Emacs, xterm, and ACME (text editor) are all programs that use right click better. You could pop the mouse back to its previous location after you close a right click menu.

The main problem is that the average mouse has too few buttons. If the mouse had more buttons, and if you could use it like a ([https://en.wikipedia.org/wiki/Chorded_keyboard)[chorded keyboard] then it would be much more useful.

Mouse chording is awkward to use. You lose dexterity when you are pressing the mouse button, so it becomes harder to move the mouse around.

A personal problem I have with the mouse is that moving it around a lot makes my fingers go numb (I have carpal tunnel syndrome).

Separating window focus from mouse cursor

If window focus functionality was separated from using your mouse cursor, then each window could have a mouse cursor, there would be less moving the mouse around.

As an example, You could use your eyes to change window focus. Webcams can track your eye movements to see where you're looking. I am unsure how well this would work in practice. It would be idiotic to replace your mouse entirely with your eyes. People's eyes move around much more than they think, and it is very hard to stare only at a spot the size of a computer icon, for any extended period of time. Application windows are probably big enough for your eyes to handle. Blinking should have no functionality.

Alternatively you could use your keyboard to change window focus.

Visual Keyboard

If every button on your keyboard had a screen that applications could use to display icons. There would be no need to put buttons all over the main screen. Every keyboard shortcut would have an icon attached to it. A touch screen keyboard could do this, but it would be less tactile than a regular keyboard. For Text editing applications, you would need multiple symbols on one key. They could also dynamically display icons, in the case of commands that are activated by pressing keys in a sequence.

In the previous section, I complained about not being able to find what you're looking for if you have too many buttons. This is less of a problem on keyboards because the letters of the key serve as mnemonics.

Normal Touch Screen

On a touch screen, it's easier to press buttons on the screen. The down side is that the buttons have to be bigger. You are trading screen space for efficiency.

This text editor

As an experiment, I used the write freely text editor to write this article. I set my web browser to full screen mode and wrote what came to mind.

This text editor is fairly good when it comes to visual minimalism. The main problem I have with it is that there's very little functionality. Generally speaking, I like to be able to view notes and cite things while I am writing text. Emacs has good faculties for this. This rant was made without using any notes, it is less informative than some of the other things I've written inside and outside of the platform as a result.

Using markdown for formatting is a good idea, it makes it so you don't need to have buttons to format things. I like Emacs org mode and LaTeX more than markdown but it's good enough.

---

By Logan Andersen. This work is licensed under CC BY-ND 4.0

You can see my other blogs here.

This is a repost from my rant.li post. I figured out that rant.li was full of spam so I decided to move over to a less spammy website.

Table of Contents

1. The requirements for optimal software.
2. Other notes
3. Works Cited

The requirements for optimal software.

I was reading the wikipedia article for programming and would like to give my own short description of a perfect program.

I am speaking only of programs made to be systems in and of themselves, if a program exists to extend a system (like GNU/Linux command line programs) then they need different properties. I do not know of any graphical user interfaces that allow one to combine graphical programs with significant power [2,3], so every GUI program that's meant to be used frequently must be viewed as a system in and of itself. Video games and programs only meant to be used once have different criteria and they will not be considered.

• Reliability, A program should always be correct, the correctness of the program should be proven with a formal method such as Hoare logic [but see 8] (Hoare, C. A. R., 1969), or a constructive proof system like coq (used for an OS kernel in (Klein, Gerwin et al., 2009)).
• Robustness, The program should never crash. It should either never need to reboot, (Yegge, Steve, 2007), or it should reboot so quickly that you do not recognize it reboots. In the latter case it must also be able to save the state of the computation before shutting down [4].
• Usability, The program should focus on usability for experts, and should not necessarily be friendly to new users. (Datskovskiy, Stanislav, 2012) makes the same point. Vim is a program that is not friendly to new users, but very ergonomic in its text editing anyways. The program should have a good help system that can teach the user how to use and extend the program (Yegge, Steve, 2007). The program must be able to save all of its state before shutting down and reboot where it left off.
• Extensibility [5], the program should be easy to understand and add new features to. The program should have a good shell that lets you change the source code while it is running[6] (Called Hot Swapping) (Yegge, Steve, 2007). The shell does not necessarily have to be built into the program, you could use an external shell that can connect to the program (eg. SWANK). The program should allow you to change its behavior without directly editing the source code using features such as: hooks, advice systems, customization variables, etc (Yegge, Steve, 2007). The user should be able to package and share her changes with others.
• Efficiency/performance, the program should be fast enough to where the user does not ever recognize the program is loading. A program should still accept input even if it has tasks running in the background. The program should not waste any computing resources, it should delete temporary files and free memory when they're no longer needed.
• Politeness, The program should not make a mess of the user's filesystem or automatically edit files other programs use without the user's knowledge.
• Readability, The program should be a literate program (Knuth, Donald Ervin, 1984), the source code and prose (or verse[9]) should be easy to read. See [7] for what I consider a good literate programming environment.

In addition to the technical criteria, the program should be free software (GNU Project, 2023).

I know a total of zero programs that have these properties. Depending on the task, the efficiency requirement is basically impossible.

Other notes

1. As far as I know, coq has not been given a formal proof of its correctness. I am not sure if you could use coq to check a proof of its own correctness but I assume you cannot.
2. A Smalltalk Virtual machine (such as Squeak) may allow for composing GUI programs with enough power. I am not familiar enough Smalltalk to be sure.
3. Somebody else made a similar point in a video. He mentioned GNU Xnee as something that could let you write scripts for gui programs. He did not know about Xdotool. I think I saw the video on planet.gnu.org a year ago, It may have been made by Jose E. Marchesi, but I am not 100% sure on that. Scriptability and Composability are different things but his complaint about most GUI programs being unscriptable influenced me anyways.
4. If your operating system can do this for you, then the program does not have to do it itself. (Proven, Liam, 2023) mentions that LISP machines the ability to save their state before powering down. A more modern system, PhantomOS perserves the state of userlevel programs across reboot (Zavalishin, Dmitry, 2020). The EROS based operating systems (EROS, CAPROS, Coyotos) are also said to have this property (Chakraborty, Pinaki, 2010). I am not as sure about the EROS operating systems.
5. The Wikipedia article lists this as “maintainability” but “program maintenance” isn't a real thing. Programs don't wear down and do not need to be “maintained” in the same way you would maintain a car ((Edsger W. Dijkstra, 1988) talks about this in more detail). What we call “program maintenance” is two unrelated tasks: Fixing program errors, and adapting the program to a new system. The former isn't necessary if you formally prove the correctness of a program, the latter is necessary if your system updates, or your libraries change.
6. One thing I worry about with extensibility, is that giving the user unlimited ability to change its behavior code can cause the program to lose its correctness. The user must be allowed to do this anyways so, The program should be able to handle having incorrect user components without crashing or extreme loss of functionality.
7. A good literate programming environment should support hypertext, citation management, and mathematical equations (in the prose and in source code comments). The hypertext system should let you import source code and functions from other files through hyperlinks. This would support writing programs as a series of index cards in a slip box (for more information on why I want this, read: (Ahrens, Sonke, 2022)). I would also want to have many different ways of importing the source code, some hygienic, and others unhygienic (In the sense of hygienic macros). I will describe my ideal literate programming environment in another blog post.
8. If you use Hoare Logic, you must prove that the program terminates separately. Standard Hoare Logic does not prove the program terminates.
9. All though it is out of style today, non fiction works used to be written in verse. Indian mathematical sutras were partially written in verse, some (or all?) essays by Alexander Pope were also in verse.

I do not like the text editor in rant.li, I wrote this in emacs org mode, exported it as markdown, and copy pasted it.

I skipped the portability section of the Wikipedia article because I don't find it very important.

Works Cited

Ahrens, Sonke (2022). How to take smart notes: One simple technique to boost writing, learning and thinking, Sonke Ahrens.

Chakraborty, Pinaki (2010). RESEARCH PURPOSE OPERATING SYSTEMS-A WIDE SURVEY., Computer Science & Telecommunications.

Datskovskiy, Stanislav (2012). Engelbart's Violin. (http://www.loper-os.org/?p=4012)

Edsger W. Dijkstra (1988). On the cruelty of really teaching computing science.

GNU Project (2023). What is Free Software?. (https://www.gnu.org/philosophy/free-sw.html)

Hoare, C. A. R. (1969). An Axiomatic Basis for Computer Programming, Association for Computing Machinery.

Klein, Gerwin and Elphinstone, Kevin and Heiser, Gernot and Andronick, June and Cock, David and Derrin, Philip and Elkaduwe, Dhammika and Engelhardt, Kai and Kolanski, Rafal and Norrish, Michael and others (2009). seL4: Formal verification of an OS kernel.

Knuth, Donald Ervin (1984). Literate programming, Oxford University Press.

Proven, Liam (2023). War of the workstations: How the lowest bidders shaped today's tech landscape, The Register. (https://www.theregister.com/2023/12/25/the_war_of_the_workstations/)

Yegge, Steve (2007). The Pinocchio Problem. (https://steve-yegge.blogspot.com/2007/01/pinocchio-problem.html)

Zavalishin, Dmitry (2020). Phantom OS Orthogonal Persistence-based OS Intro and Design Concepts. (https://video.fosdem.org/2020/K.4.601/uk_phantom.webm)

---

By Logan Andersen. This work is licensed under CC BY-ND 4.0

You can see my other blogs here.