-
Notifications
You must be signed in to change notification settings - Fork 142
New Programming Taxonomies #63
Comments
So I guess that makes me a semi-classist, neo-copypaster, and an object, macro and closure maximalist. |
I've been looking for a way to define myself for some now, and thankfully people like you are doing the groundbreaking research needed. |
@VelocityRa There's an incomplete/naive assumption in that article which is this:
This is correct, but programmers choose to identify as X or Y programmers because those languages or styles fit their personalities. The same applies to politics. People choose to identify as X or Y politically because those views fit their personalities really well. One aspect of this (borders vs. no borders) that I went over recently can be seen here: https://twitter.com/a327ex/status/1339222944078295046. There will never be no religious wars over any issues that deal with biological differences between people, because those biological differences will always be there. The best way to actually diminish the effect of those differences is not to deny that they exist, which is basically what PG and every rational-type of person naturally tries to do, but to lean in on them heavily and really understand exactly what they are, so that you can then more accurately take them into account when dealing with people who are wildly different from you personality wise. In a way, PG's interest in "avoiding religious debate" is a part of his personality that is guiding him towards a solution that diminishes the amount and intensity of that kind of debate. But not everyone is like that. I'm certainly not like that. I love debating with people, and the more intense and contentious the topic the better. The point being, PG is not actually interested in primarily finding the truth necessarily, he's interested in "fruitful debate", which will help finding the truth, but which also comes with all sorts of assumptions, like people are going to be this polite, and they aren't going to call each other names, etc. Which is a fine set of assumptions, the majority of people are like that and maybe finding the truth will be better if everyone is like that. But often times the truth is only going to be found in contentious, religious-like topics, and just saying no a priori to those doesn't seem like a good strategy to me.
To expand further, this is not a step beyond, but a step before. PG has decided to not understand what his biases are, and in doing so he has negated completely the possibility of actually thinking clearly about ideas that are outside his natural inclinations. I have read a few articles from PG recently and it seems to me like he really makes this mistake repeatedly, I even wrote a comment in one of these discussions on HN: https://news.ycombinator.com/item?id=25228196. So yea, I just disagree with this fairly strongly. |
What about the following:
What exactly would you gain from such a discussion?
Hm that's not how I interpreted him. PG is suggesting that we should, after the above happens, try and fight back ([1]). As a conscious decision. [1] Or perhaps even simply not present & talk about ourselves as PS: Excuse me if I missed something obvious, I haven't really thought much about this. This is why I only linked the PG article instead of expressing my actual thoughts too. |
Some discussions are only going to happen in a partisan manner because they're essentially discussions about people trying to impose their personality preferences on other people, and those other people fighting back. But that doesn't mean that there's nothing to be gained from this interaction. What people are doing when they're discussing in this manner is very slowly nudging each other in the opposite direction to their natural tendencies, such that each person has a more complete view of how the other person thinks. This process is slow and tiresome, but it cannot happen when you ignore it. Think about a time when you were having an argument with someone, things got a bit too heated, then you both decided to drop it. Then a few weeks or months later you have the same argument with that same person, and things get a bit too heated again, but both you and that same person have a better understanding of each other's position, so now you're able to engage slightly better. Then a few more months pass and the same argument happens again, and now you have a pretty good idea of what the other person thinks, where they're more likely to change their minds, where they aren't, and how you should approach talking to them about it. And the other person has this same model of you in their minds regarding this subject. This constitutes a true understanding of a position that is opposite to yours, built through months of heated debate and friendly conflict. The more open you are to having these kinds of continued heated discussions, the more you'll be able to truly understand other people. The more closed you are to them because you only want "polite" debate, the less you'll be able to do it, and if you do it at all it will happen at a slower pace, simply because there's less conflict, and therefore less true understanding of the actual differences in thought that can't really be reconciled due to biological differences in personality.
You don't have to assume that. There's nothing wrong with presenting arguments in a partisan way. As I just said, that's the only way people can figure out where the true differences in ways of thinking are. Trying to hide it just slows the process of understanding each other. The problem here is fundamentally that PG, and most people, due to their personalities (too high in politeness, as defined in this paper), simply cannot stand combative environments too much. And so this shapes the kinds of interactions they'll want to have, and interactions that become too heated or emotional become a no-go. It's perfectly fine to be like this and to avoid interactions like that, but you also have understand that you're giving up on a massive amount of potential benefit because of this. And in his article PG does not acknowledge this.
I don't think PG is saying that at all. Take this, for instance:
Here he is saying that the best thing to do is to not identify as anything, because when people identify as something it increases the chances they'll become partisan about it, and thus decrease their ability to think clearly about things as well as the quality of their ideas. He's not saying something like: "after you clearly understand what your identity is like, deny it", he's saying: "deny it". But if all you do is try to deny it you're missing the pretty critical step of defining what exactly to even deny. If you're someone who is highly polite, as I believe PG is, not identifying this properly in yourself will lead you to highly bad ideas, like, for instance, the idea that partisanship is inherently bad and that there's little value to it. You'll just be acting out your natural biases (your distaste for conflict) and trying to explain things from that perspective, not realizing that you're not really explaining things from an actually neutral perspective, but only from your very particular point of view. In most cases it's fine to do this and only look at things from your own point of view, but it's definitely not if your explicitly stated goals are to be neutral and to understand things from a rational, non-emotional perspective. |
Lately I've been thinking about programming taxonomies and why programmers don't have more specific words to describe the way they develop and organize their code. The words that currently exist are very general to the point of being almost useless.
Things like OOP, FP, TDD, etc, operate at a very high level. They tell you generally what's going on with some codebase or with some programmer, but if you want more details that would be relevant to you, the programmer, on a day to day basis of working in that codebase, you're not really getting anything from these descriptors.
With this in mind, I started thinking about what kinds of words I would find useful to describe myself and my codebases as to other people. And so in this post I will explain why I'm now an Omni-Classist Neo-Copypaster Meta-Closure Maximalist Immediatist Game Monofiler type of programmer.
Classism
Classism refers to the act of using Classes in your codebase. This is similar to the OOP denomination except that it differs in how it's actually used because we can use modifiers. For example:
Omni-Classism
The act of making everything in your code a class. Languages like Java, C#, Haxe, and similar ones are omni-classist languages, as everything from a user perspective has to be inside a class. If you primarily use one of those languages then you're an omni-classist programmer.
Most languages aren't omni-classist, like the language I use the most, Lua. But if you're a programmer who uses one of those languages and you still prefer to make all your code reside in classes then you're also an omni-classist programmer. And that happens to be the case with me, which is why I can describe myself as an omni-classist.
Semi-Classism
The act of making some things in your code a class, but not others. Most languages and most programmers are semi-classist, making this a fairly useless description. However I'm adding it here for completion's sake.
Mono-Classism
Logically it would follow that this pertains to the act of making everything in your code a single class. No one actually does this because it would make no sense, so given that the natural meaning is useless, this could be used to describe those who have no problems with so called God classes, or those who have no problems with Singletons and encourage their liberal usage.
Since we're essentially creating new words, the actual meaning the word takes depends on how people use it, and for this one I can see either (or maybe even something else that I didn't think of) making sense.
Anti-Classism
The act of making everything in your code not a class, that is, not using object orientation at all. Most functional programming languages would be like this and a fair number of programmers could describe themselves like this too.
Copypastism/Repeatism
Copypastism or Repeatism refers to the act of defaulting to copypasting your own code rather than defaulting to abstracting it and trying to be DRY. Copypasters can either be described as people who do this knowingly or unknowingly.
Early Copypastism
In the early days of programming, programmers were mostly copypasting unknowingly. They naturally did it without fully understanding its drawbacks. As those drawbacks became more clear over time, copypastism became extremely unpopular and shunned by general programming society. Some also refer to this period as the Dark Age of Copypastism.
However, after some decades, a few Techpriests and Techmonks started noticing that most of the bias against copypastism was actually false. They started experimenting and playing around with different ways to do it, now conscious and aware of their actions, and they realized that copypasting had its role to play and its place be in the programming technique arsenal.
Slowly, tomes such as this one (Premature Generalization section) or this one started being released by respected individuals such as High Techmonk a327ex of the Order of Lunatic Dynamicism, and over time it became more acceptable to consider both the benefits and drawbacks of copypastism. This movement became known as Neo-Copypastism or Neo-Repeatism.
Neo-Copypastism/Neo-Repeatism
The act of knowingly defaulting to copypasting your own code instead of defaulting to abstracting it. Practitioners will often take multiple factors into consideration before deciding to abstract a piece of code away, such as how often it has changed in the past and how often it's likely to change in the future, or how complicated it would be to change it in the future if that piece of code is formalized into an abstraction erroneously or too early.
Some devouts prefer to refer to themselves as Neo-Repeatists instead of Neo-Copypasters, given that the word "copypasting" still has a fairly negative connotation in the community after decades of repudiation.
Monofilism
The act of taking one or multiple logical aspects of your codebase and having them be contained entirely to one file for some purpose. Monofilers believe that they gain advantages by not dividing their code across multiple files, although they often believe that this advantage is contained to certain aspects of their codebase, for instance:
Lib Monofilism
The act of making one's libraries contained to a single file. This is most commonly seen among some C programmers, with examples visible here. This makes sense from a practical perspective for C programmers, although programmers in other languages (such as Lua) are also monofilers if the library isn't too big.
Game Monofilism
The act of making one's game contained to a single file. Very few people would describe themselves like this, but I am definitely one. I believe and aim for every game I make to be contained to a single file now, and this works really well for me for a variety of reasons. Note that this does not mean my engine code, for instance, is in a single file, otherwise I would also have to call myself an Engine Monofiler. So that's why the "Game" modifier is there.
Maximalism
As opposed to minimalism. In programming, it would refer to the use of some specific feature or way of thinking in an extravagant, excessive, overly complex or unnecessary manner. Programmers may be maximalists because they want to take some concept or idea to its extremes and see if anything interesting happens, or simply because they like some idea a lot and enjoy seeing it used everywhere. Some examples:
Macro Maximalism
The act of using macros in a maximalist manner. This is more common among C programmers, although programmers in other languages with easy access to macros, such as Lisp, also can do it. This is a common example that many game developers use that I think falls into this category.
Object Maximalism
The act of using objects in a maximalist manner. This seems similar to Omni-Classism, but I think it's a more general descriptor, and so it differs in some important ways. For instance, Ruby is an object maximalist language because every (or almost every) construct in the language is an object, however, it's not an omni-classist language because the end user doesn't really need to have their code inside a class all the time.
Meta-Closure Maximalism
This is the one that I subscribe to and it refers to metatables and closures. Another way to read it would be "Metatable and Closure Maximalism", but since I'm making words up I can just decide on something that sounds cooler.
One good example of Meta-Closure Maximalist Lua code I've seen is the Amulet framework. I've spent some time using it and it's a really refreshing, different, and creative framework that abuses these two features in Lua to create something slightly different to most other game frameworks.
Just take a look at this code. It's clearly visible that the library is built such that you're using closures left and right in a very ergonomically sound way. But what's also interesting is that its scene graph uses metatable operator overloading and it leads to the creation of fairly unique looking code. Most people don't really think this kind of stuff is that cool, they say it's "too clever", but I think it's cool when used in this really different way.
Currently, my own code is mostly closure maximalist, such as in this example (
->
represents a new function being defined):But I've been meaning to make it more metatable maximalist as well and Amulet is a nice example inspirationally.
Immediatism
Finally, Immediatism refers to the act of writing code without too many unnecessary layers of abstraction. I think Carmack has outlined this argument partly here, and many others after him have echoed similar feelings. In a way it's an adjacent way of thinking to the Neo-Copypaster one.
People can focus on making specific aspects of their codebase immediate, like for instance, the trend with Immediate Mode UIs. People can also just more generally be API Immediatists, meaning that they believe that APIs to libraries they build or use should be as direct and connected to what's actually going on under the hood as possible.
One good example of this is rxi's lite editor. I've written about it here. One of the really nice things about this editor's API is that because of the way Lua works it essentially doesn't exist. You have some basic organizational guidelines set up by the author, i.e. "your plugin code should be in this folder", but other than that, when you're writing code to change or extend the editor you're writing code at the same level of abstraction that the author himself wrote it.
Since it's all Lua functions, your plugins can overwrite functions defined by the author so that the function now does what you want instead. Want to change how text lines are drawn? Just define a function with the same name in your plugin (thus overwriting the original) that draws a text line and change it to do what you want instead. Want to add vim-like modal editing? Just rewrite the input handling functions to add a "normal mode" (as the editor by default only has "insert mode") and then literally just do it. There's nothing stopping you.
Encountering an immediatist codebase is very refreshing because it seems like very few people value this type of stuff. But it seems important enough to me that it should have its own word.
So now after all this I hope it's clear why I am an Omni-Classist Neo-Copypaster Meta-Closure Maximalist Immediatist Game Monofiler. Yes, these words are just made up nonsense. Yes, it's really dumb. But also, it's definitely clear and precise. If someone tells me they're an Omni-Classist Neo-Copypaster Meta-Closure Maximalist Immediatist Game Monofiler, I already know what to expect of their ideas about programming and of their code (it's going to look very messy). And hopefully when I show you something like this, you can also go: "yea, that's totally an Omni-Classist Neo-Copypaster Meta-Closure Maximalist Immediatist Game Monofiler codebase, heh, typical".
Here are some other things that I also could define myself as but that I didn't think were as important to expand on in this article: I'm also an Aclassed Snake Case Supremacist (everything is snake_case except class names, and all style guidelines are by definition supremacist because only one can live in the same codebase); a Mono-Folderist (everything needed to make a program run should be contained in the project's folder); a Lunatic Dynamicist (a strong preference for dynamic languages, especially ones that are Lua-like); and an ECS denier (the validity of the entity-component-system narrative pushed by Big ECS is questionable).
The text was updated successfully, but these errors were encountered: