Onion Information

Page Clicks: 0

First Seen: 03/11/2024

Last Indexed: 10/22/2024

Domain Index Total: 56

WARNING
This Domain Has Been Reported 1 Time!

Human Trafficking: 1

Hidden Wonders Programming · Society · Technology The Importance of Perspective Published: 2022-10-25 Lastmod: 2023-01-09 Table of Contents Introduction [#] The world functions a lot better when there’s diversity of thought. It is difference in perspective that allows diversity of thought to exist. These various perspective are what make life interesting, and there are endless perspectives because everyone has different lives, lives full of different experiences that make individuals view the world in unique ways. Constantly, however, there is a force pushing against individuality, for humans have the potential to be ugly, oversocialized creatures who will push and shove to be accepted by the wider group. Psychologists (and regular people) refer to this phenomenon as groupthink , spelt weirdly as one word due to its derivation from George Orwell’s idea of wrongthink from the book Nineteen Eighty-Four (you should read it if you haven’t already). Also, that Wikipedia article seems a tad biased, so take everything past the first two paragraphs of it with a grain of salt. This older version seems a bit less opinionated. Anyway, I believe groupthink to be one of the greatest tragedies of humanity. It’s through the free flow of ideas and the freedom to discuss even the most bizarre, stupid, and revolting of opinions that has and will continue to allow the human race to move forward. This is true of any field, whether it be politics, philosophy, history, or--as I will discuss quite a bit--computer science. There is more knowledge to be gained from the crazy old man shouting on the street corner than the polite, mask-wearing, non-controversial woman subtly putting in the effort to ignore the lunatic. I’m hoping that, through this article, I can make people aware of how valuable differing perspectives are in our lives and to our societies as well as how important it is to understand the perspectives of others. A Programming Professor’s Strange Opinion [#] From a friend, I heard about an especially strange programming professor. There were a lot of weird things about him, but one of the strangest things were his opinions on how to write code. First, he was convinced that the only two languages anyone should be writing are Fortran or C. A strange requirement, but some teachers require code be written in certain languages, so whatever. His strangest opinion was the idea that a programmer should strive to use as few features of a language as possible. His reasoning was that if you use fewer features, you’ll be less likely to run into compiler bugs. As someone whose only ever used computers in the 21st century, it’s fascinating for me to wonder what kind of software bugs this professor must have run across due to compiler problems in the last 50 years--or, maybe he was just paranoid. In practice, this means students had to choose between writing using switch statements or if statements. They also had to choose between while loops and for loops, which likely led to students writing funny code like: int x = 0 ; //loop until x is true for (; !x;) { ... } It’s sounds like a crazy idea, and my friend and I laughed about it probably too much, but is there some merit to the idea of minimizing the usage of language features? Take the following code example: #include int main ( void ) { static int x, y, z; if (!x) printf ( "Static variables are 0 by default! \n " ); if (y == 0 ) printf ( "Static variables are 0 by default! \n " ); if ( 0 == z) printf ( "Static variables are 0 by default! \n " ); return 0 ; } The fact that this program is pointless put aside, we wrote the same check for if a variable is equal to zero in three different ways! Programmers will not agree on which way of writing the if condition is correct, but good programmers will agree that regardless of what syntax we choose, it should be consistent throughout the program. Similarly, there are two common ways of making loops that run forever in C: for (;;) {} while ( 1 ) {} // while(true) with stdbool.h Many prefer the while(true) method because it’s easier to see what’s happening, but others prefer the for(;;) method because it’s fewer characters (I like for(;;) , and so do the suckless devs). The correct answer here is that consistency is key. You’re not minimizing the chance of compiler bugs here, but you are minimizing the amount of syntactic and semantic variation a programmer needs to be familiar with to understand how your code works. This should make debugging easier as well. This may not have been what the programming professor’s point was in having his students write such strange code, but his perspective is an interesting one. It may not be the correct opinion, but treating his perspective seriously is insightful. Terry A. Davis [#] If you check my quotes page , you’ll find some quotes from Terry Davis. He was a very interesting man with some very interesting opinions . If you somehow don’t know him, Terry was the creator of TempleOS . He also wrote the Holy C programming language. He is dead now. Memes and schizophrenia aside, here is one of the most informative and interesting videos of Terry’s. There are so many valuable points he brings up in this video and other videos, I’ll have to make sub-headings for each of them. Terry is a guy with opinions not everyone will agree with, but we’d be fools to not to seriously entertain his technical ideas. Process Scheduling [#] It’s a common problem in computer science: let’s say we have 10 processes, but can only run 1 process at any given time. In this case, what is the best way of running the processes? Without teaching a whole operating systems lesson on process scheduling, a commonly agreed upon way of doing process scheduling is to assign processes priority levels (often implemented with data structures like priority queues and/or circular queues), which prevent what is called process starvation--when a process is unable to run on the CPU at all because other processes are running in front of it. It works fairly well. Terry rejects this method of process scheduling because he believes it’s too complex. In contrast, he uses a method called round robin, which gives all the processes an equal amount of time to run on the system in a loop, constantly switching between them. This is a lot simpler to implement, but runs into problems if there are numerous processes running on the system. Terry acknowledges that this is a problem, but he doesn’t see this as a problem that needs to be addressed. This sums it up pretty well: Everybody who's a Linux person would move heaven and earth just so that you could play two video games at once. They're full of pride. Terry’s OS doesn’t have many processes running at any given time. Terry says, why do you need to run so many processes at once on a consumer machine? Why should a single user machine need to be able to run two games at once? Terry’s operating system has no virtual memory, which make context switches--cycling from one process running on the CPU to the next--very low resource, minimizing the negative aspects of round robin. It’s a fascinating approach to process scheduling, one that an operating systems professor would probably laugh at. Consumer OS [#] This is Terry’s most interesting point for me: in creating Temple OS, Terry wanted to create a Commodore 64, a “user developer” computer. A computer where the user is in control of an incredibly minimal system, one designed for truly personal computing, not for enterprises or servers. As I mentioned earlier, Terry gets rid of virtual memory, saying “virtual memory? That doesn’t belong on a modern computer.” There are no permissions in Temple OS; this sounds like a security problem until you think a bit: why does a consumer OS--especially one with no Internet access--need the concept of user privileges? Permissions are most effective at minimizing the effects of malware and preventing the average computer user from deleting system32 because of a bad meme. On a “user developer computer,” as Terry puts it, the user is responsible for what happens to his system. Temple OS is “a motorcycle” as Terry puts it. By getting rid of user privileges, Terry is massively reducing the complexity of the system: the system resources needed to perform a context switch, the time it takes to read, write, or update a file, and the overall complexity of his entire codebase are greatly reduced by abolishing user permissions. I think Terry has a point here. Modern operating systems do a lot that most users are never going to use. This holds true for iOS, Android, Windows, MacOS, and even Linux. These systems are overly complex and excessively resource intensive for what operating systems once accomplished with a fraction of the resources. Temple OS tries to backtrack to a simpler way of doing things. Terry says (I paraphrase here): “when systems get bigger, they don’t get bad, they get worse.” We tolerate mediocrity in software because increasingly powerful hardware allows us to. Even if the systems get more convoluted in the process, it still remains sufficient to get the job done. Terry didn’t think that an operating system should be merely “sufficient”; I don’t either. Terry’s ideas are far from perfect, and are in many ways nonsensical. However, I believe they’re worth thinking about, especially in this instance. Compiler Optimizations [#] Terry is against compiler optimizations. Around seventeen minutes here , he says: “we can make an optimization in case we have this particular retard in there.” Terry is of the opinion that programmers should just know how to program. Often when writing bad code, programmers will think “eh, the compiler will just optimize that for me anyway.” Even if it works, this is lazy, and the optimizations would be unnecessary if we just wrote more performant code by default. This is an interesting line of thinking that has support from less schizophrenic people as well. One set of people are in agreement with Terry in that people should just be better programmers and use performant languages like C (I lean a bit this way too, but don’t think C is perfect). This line of thinking is a bit on the decline as evidenced by the rise of self-professed “safe” languages like Go or Rust, but there are still many people who think languages like C and C++ are best, even if their opinion is increasingly a minority position. Terry is evidently not concerned with memory safety: Just man up and learn what malloc and free are. Another group of people will agree with Terry because they are against overly aggressive compiler optimizations. A few agree directly with Terry’s line of thinking in that overly aggressive compiler optimizations produce worse programmers, but most people that are against compiler optimizations cite that implicit changes made by the compiler can sometimes make erro...