Emerald_Knight's recent activity

  1. Comment on Fortnightly Programming Q&A Thread in ~comp

    Emerald_Knight
    Link Parent
    Feature branches are a good idea even for a solo project. Ideally you would commit smaller changes as you progress and then merge the final result once the feature itself is completed and...

    Feature branches are a good idea even for a solo project. Ideally you would commit smaller changes as you progress and then merge the final result once the feature itself is completed and validated. If at any point in the middle of these smaller commits you decide that you don't want the feature, are unable to implement it due to some fundamental limitation, or need to switch to a higher priority task, you don't want to have to manually roll back these changes in the master branch. If you have it done in a feature branch then you can just abandon the branch and optionally return to it later.

    In other words, feature branches give you the freedom to abandon or postpone changes while still keeping them tracked via version control. Definitely use them.

    5 votes
  2. Comment on Whistleblower complaint alleges mass hysterectomies at ICE detention center in ~news

    Emerald_Knight
    Link
    I've felt a lot of negative emotions toward the things that have been happening to ICE detainees and in this country as a whole, but this is the first time that I've gone from desensitized or...

    I've felt a lot of negative emotions toward the things that have been happening to ICE detainees and in this country as a whole, but this is the first time that I've gone from desensitized or frustrated to truly feeling sickened and horrified. This is genuinely gut-wrenching to read, a sensation that I very rarely feel. There is a certain threshold of dehumanization that you need to cross to go from justifying inhumane detainment conditions to feeling free to slice open a human body with the intent of forcefully sterilizing them without their desire or consent.

    I honestly have nothing of value to add to this discussion other than expressing the pure, unbridled disgust, loathing, and shock that I feel right now.

    15 votes
  3. Comment on What's new in the Linux kernel in ~tech

    Emerald_Knight
    Link Parent
    Agreed. A mobile OS is very different from a desktop OS. Windows learned this the hard way with Windows 8, trying to cram the two "experiences" together into a single clusterfuck that failed on...

    Agreed. A mobile OS is very different from a desktop OS. Windows learned this the hard way with Windows 8, trying to cram the two "experiences" together into a single clusterfuck that failed on both platforms. A mobile OS is designed to be a stripped down, simplified interface with touch and swipe gestures and minimal screen real estate being central considerations in their design, whereas a desktop OS is designed with a mouse and keyboard as well as a much larger screen real estate in mind and therefore has a much more expansive feature set and layout. Take any Android or iOS device and compare them to any Linux distribution or macOS version and the experiences are wildly different. They simply cannot be equated and attempting to do so to pad numbers is disingenuous at best. It's even more absurd when you look at their source and see that desktop Linux distributions have a market share of a measly 0.85% as of August of this year.

    It's fine if they point out that Linux-based systems take a market share of 39% because of Android. That makes sense since the article is about the new Linux kernel update. Even more so since the article points out that Android is allegedly going to be tracking the latest stable updates from the kernel rather than maintaining a fork. So I have no problem with them bringing up the Android market share and pointing out that it essentially makes Linux "the most popular end-user operating system". It's a factual, relevant statement to make.

    But to basically compare Android market share to Windows market share is just comparing apples to oranges. Yes, they're both fruits, but we're not making apple pies out of oranges.

    6 votes
  4. Comment on The actual 2020 Tildes Unofficial Census in ~tildes.official

    Emerald_Knight
    (edited )
    Link Parent
    I don't think asking at what age you completed your education is the best way to go about it, either. I'll preface this by stating that the following is a U.S.-centric perspective and may not...

    I don't think asking at what age you completed your education is the best way to go about it, either.

    I'll preface this by stating that the following is a U.S.-centric perspective and may not entirely apply internationally. With that disclaimer out of the way, your typical K-12 education might have most students graduating grade 12 at around 18 years old, but there are enough edge cases with early or late graduation to start throwing that off. Then once you get into higher education, those numbers start making even less sense given the huge amount of variation in how quickly each student goes through their degree requirements as well as when they decide to start going to college in the first place. It gets even worse when you start breaking things down by race. If we take a look at some NCES data on graduation rates in the U.S., we can see that of those who graduate, about 32% of them take 5-6 years to graduate, with that number getting even higher at times across racial divides. It just doesn't line up with reality very well at all.

    It's a good thought, though. Perhaps using the range for years of education (e.g. "grades" in the U.S.) would make more sense, as that is age-independent. It would still not entirely be accurate for a university setting, but the years could then simply be omitted for those cases in favor of descriptive terms. No matter what, though, it's difficult trying to make a one-size-fits-all solution actually work without running into annoying little edge cases.

    Edit: Fixed some terrible wording that conveyed incorrect information.

    2 votes
  5. Comment on Programming is a losers game in ~comp

    Emerald_Knight
    (edited )
    Link Parent
    Agreed. It's analogous to the difference in the article's example between expert players and amateur players. You can't paint tennis as a whole as either a winner's game or a loser's game because...

    Agreed. It's analogous to the difference in the article's example between expert players and amateur players. You can't paint tennis as a whole as either a winner's game or a loser's game because it depends on the skill level of the players involved. Similarly, you can't paint programming as a whole as either a winner's game or a loser's game because there are many factors at play--including something as simple as the type of task you're performing, e.g. feature development vs. refactoring--so that any specific instance of programming you look at could be categorized one way or the other.

    Whether it's tennis or programming, you have to decide whether it's a winner's game or a loser's games based on the current frame of reference.

    4 votes
  6. Comment on What programming/technical projects have you been working on? in ~comp

    Emerald_Knight
    Link
    I haven't really dug into code for it yet, but I've been spending a lot of time thinking over the sources of friction in the code I've written and have been planning on building out a revamped...

    I haven't really dug into code for it yet, but I've been spending a lot of time thinking over the sources of friction in the code I've written and have been planning on building out a revamped version of a backend framework that I use for my work (I won't be mentioning what it is because it's obscure enough that simply knowing I use it would probably be enough to identify me). I plan on doing a full architectural overhaul to fix some of its underlying design problems and make it do what it was actually designed to do but currently does poorly, and then I plan on adding some wishlist items that I've been wanting for a while now but haven't had the time to get around to adding into production code.

    It could turn out really well, or it could turn out to be a complete disaster. Either way it'll be a fun exercise.

    1 vote
  7. Comment on A brief look at programming paradigms in ~comp

    Emerald_Knight
    Link Parent
    This is all true and I should clarify that I wrote this from the perspective of someone being stuck in an imperative programming mindset. It's definitely hand-waving and fudging some details, but...

    This is all true and I should clarify that I wrote this from the perspective of someone being stuck in an imperative programming mindset. It's definitely hand-waving and fudging some details, but I felt that since most code samples I've seen for showing the difference between functional and imperative programming have imperative implementations which can confuse someone new to functional programming, it's important to provide a starting point that is more easily grasped by treating it as an additional layer to what they already know. From there it becomes far less confusing when you see imperative code within projects built on functional programming principles.

    Once you can conceptualize that separation, understanding what functional programming truly is becomes much less difficult and more rigorous explanations start to hold much more value.

    1 vote
  8. Comment on A brief look at programming paradigms in ~comp

    Emerald_Knight
    Link Parent
    Good point, I meant to elaborate a little bit and didn't end up putting that in there. I'll be sure to add in a sentence or three to at least somewhat cover it.

    Good point, I meant to elaborate a little bit and didn't end up putting that in there. I'll be sure to add in a sentence or three to at least somewhat cover it.

    2 votes
  9. Comment on A brief look at programming paradigms in ~comp

    Emerald_Knight
    (edited )
    Link Parent
    That's fair. I'll add a note at the beginning to clarify the language and point out some of its quirks in some code comments. I might go back in and replace the examples with pseudo-code as well,...

    That's fair. I'll add a note at the beginning to clarify the language and point out some of its quirks in some code comments. I might go back in and replace the examples with pseudo-code as well, but for now that should at least help a bit.

    2 votes
  10. Comment on A brief look at programming paradigms in ~comp

    Emerald_Knight
    Link Parent
    First, it's important to note that PHP's arrays are pass-by-value by default. With that in mind, look very closely at the function signature. In the first example the parameter is a reference type...

    First, it's important to note that PHP's arrays are pass-by-value by default. With that in mind, look very closely at the function signature. In the first example the parameter is a reference type (note the & prefixing the parameter), which allows mutation of the input variable as a side effect. In the second example the parameter isn't a reference type and instead returns the modified data. While technically the function body does mutate the data in both instances, only the first example mutates the original data.

    2 votes
  11. Comment on How does Tildes enable you to express yourself in contrast to reddit/other? in ~tildes

    Emerald_Knight
    Link Parent
    I remember a long time ago seeing "tildenizen". I'm a big fan of that one myself :)

    I remember a long time ago seeing "tildenizen". I'm a big fan of that one myself :)

    4 votes
  12. Comment on A brief look at programming paradigms in ~comp

    Emerald_Knight
    Link
    I know some of you will probably want to correct some of the details in this, and I fully welcome any suggestions for improvement. This isn't meant to be some academically rigorous paper, but I'm...

    I know some of you will probably want to correct some of the details in this, and I fully welcome any suggestions for improvement. This isn't meant to be some academically rigorous paper, but I'm always receptive to recommendations.

    Also @mrbig this is more than a year over-due. I remember that you requested this late last year and I've only just now gotten around to writing something up. I hope that it still has some value for you.

    2 votes
  13. A brief look at programming paradigms

    Overview If you've spent any significant amount of time programming, then you've probably heard discussions about imperative, functional, and declarative programming. These discussions are often...

    Overview

    If you've spent any significant amount of time programming, then you've probably heard discussions about imperative, functional, and declarative programming. These discussions are often mired in technical knowledge and require a fair amount of intuition when trying to grasp the differences between the examples placed in front of us. These different programming styles, usually called programming "paradigms", are discussed as if they exist within a vacuum with complete and total isolation from one another. This only furthers the confusion and frustration among newer programmers especially, which runs counter to the goal of instructing them.

    In this post I'll be taking a look at the oft-neglected intersections where these paradigms meet with the hope that the differences between them will be better understood by reframing our existing knowledge of programming basics.

    Note: I'll be using PHP for my code examples and will try to provide comments when necessary to point out language quirks.


    Understanding Fundamentals is Imperative

    Let's start by first reviewing the most basic, fundamental programming paradigm: imperative programming. The term is a bit strange, but the important thing to understand about it is that imperative programming refers to writing software as a series of instructions where you tell the computer how to solve a specific task. For example, if we need to add together a bunch of numbers inside of an array, we might write code that looks like this:

    $numbers = [ 8, 31, 5, 4, 20, 78, 52, 18, 96, 27 ];
    $sum = 0;
    foreach($numbers as $number) {
        $sum += $number;
    }
    

    This is a pretty typical example that you've probably encountered in some form or another at some point in your programming studies or career--iterate over an array one element at a time from the first element to the last and add the current element to some accumulating variable that starts at 0. The kind of loop you use may differ, but the general format of the solution looks the same. This is very similar to the way the computer itself performs the task, so the code here is just a relatively human-friendly version of the actual steps the computer performs. This is the essence of imperative programming, the basic building blocks of everything you learn early on.


    Abstract Concepts

    As the software we write gets larger and more complex, we then tend to rely on "abstractions" to simplify our code and make it easier to understand, reuse, and maintain. For example, if we've written a program that adds arrays of numbers together, then we probably aren't doing that in only one place. Maybe we've written a tool that generates reports on large data sets, such as calculating the total number of sales for a particular quarter, gross profit, net profit, remaining inventory, and any number of other important business-related metrics. Summing numbers could be so common that you use it in 30 different places, so to avoid having to maintain 30 separate instances of our number adding code from above, we define a function:

    function sum($numbers) {
        $sum = 0;
        foreach($numbers as $number) {
            $sum += $number;
        }
    
        return $sum;
    }
    

    We do this so frequently in our code that it becomes second nature. We attach so many names and terms to it, too: DRY, abstraction layers, code reuse, separation of concerns, etc. But one thing experienced programmers learn is to write their functions and object and interface methods in such a way that anyone who uses them doesn't need to care about the underlying implementation details, and instead only need to worry about the method name, expected arguments (if any), expected return type (if any), and expected behavior. In other words, they don't need to understand how the function or method completes the intended action, they only need to declare what action they want performed.


    A Declaration of Understanding

    Anyone who has looked into the concept of the declarative programming paradigm should find those last words familiar: "they don't need to understand how the function or method completes the intended action, they only need to declare what action they want performed". This is the oft-touted explanation of what declarative programming is, the difference between detailing "how" and declaring "what", and I believe that it's this great similarity that causes imperative and declarative programming to become heavily entwined in a programmer's mind and makes it difficult to understand. Take this common example that authors tend to use to try to detail the difference between declarative and imperative programming:

    // imperative
    function sum($numbers) {
        $sum = 0;
        foreach($numbers as $number) {
            $sum += 0;
        }
    
        return $sum;
    }
    
    // declarative
    function sum($numbers) {
        return array_reduce($numbers, fn($x, $y) => $x + $y, 0);
    }
    

    The authors will go on to state that in the imperative example, you tell the computer how to sum the numbers, whereas in the declarative example you don't tell the computer how to do it since you don't know anything about the reduce implementation, but intuitively it still feels as if you're telling the computer how to perform its task--you're still defining a function and deciding what its underlying implementation details are, i.e. the steps it needs to take to perform the task, even if its details are abstracted away behind function or method calls that could have varying implementation details of their own. So how the hell is this any different from defining functions like we do in imperative programming?

    The answer is simple: it isn't. We've used so many names and terms to describe functions and methods in our ordinary imperative programming, but the truth is that a well-defined function or method serves as a declarative interface to an imperative implementation. Put differently, declarative programming is defining and utilizing simple interfaces that describe what you want accomplished while the underlying implementation details are inevitably written using imperative code.


    Functional Differences

    Now we can finally tackle one of the biggest trends in programming right now: the functional programming paradigm. But to understand this paradigm, it's important to understand what a "function" is... from a mathematical perspective.

    Yes, I know, math tends to be a enthusiasm sink for many, but don't worry, we're not actually going to be doing math. We only need to understand how math treats functions. Specifically, math functions usually look something like f(x) = {insert expression here}, which is loosely equivalent to the following code:

    function f($x) {
        return {insert expression here};
    }
    

    The important thing to note about functions in math is that you can run them a theoretically infinite number of times on the same input x and still get the same return result. Unlike in a lot of the programs we can write, math functions don't produce side effects. Files aren't written to or destroyed, database entries aren't deleted, some global counter somewhere isn't incremented, and your x doesn't suddenly change. The idea behind functional programming is to embody some of that nature of mathematical functions because they're predictable and always reproducible, and therefore simple to test as well. For example, take the following:

    // not functional
    function increment(&$x) { // pass by reference--$x will be modified outside of this function!
        $x++;
    }
    
    $x = 1;
    increment($x);
    increment($x);
    increment($x);
    
    // functional
    function increment($x) { // pass by value--$x will NOT be modified outside of this function!
        return $x + 1;
    }
    
    $x = 1;
    $y = increment($x);
    $y = increment($x);
    $y = increment($x);
    

    Note that the first example will change the value of $x on each call, meaning each subsequent call of increment($x) produces a different result. Meanwhile the second example doesn't change $x and so the return value of increment($x) is always the same. This may seem like a silly example, but in larger, more complex software this can be significant. So now that we have an understanding of functions from a mathematical perspective, we have everything we need to actually understand what functional programming is.

    Functional programming is a subset of declarative programming. Just like in declarative programming, you use simple interfaces to tell the program what you want to do rather than how to do it. But unlike declarative programming as a whole, functional programming imposes some additional restrictions on what you should and shouldn't do:

    • You should encapsulate behavior in pure functions, which always give a consistent output for a given input and don't have side effects.

    • You should write functions in such a way that you can compose them together, allowing you to combine and chain behavior to produce new functions or use the output of one as the input for another.

    • You should avoid side effects as much as possible.

    • You should avoid mutable state (e.g. changing the values in a variable).

    • You should avoid sharing state between components.

    These restrictions would require an entirely separate post on their own to properly cover and have been covered so many times in so many ways by others elsewhere that it would be superfluous for me to try to add anything more. It's important to note, however, that these restrictions are imposed because they provide some key benefits. By avoiding side effects and by avoiding mutable and shared states, the code you write becomes more predictable and tracing the behavior of an algorithm becomes far simpler. By writing pure, composable functions, you create reusable building blocks that can be strung together in virtually any configuration with predictable results. This makes writing, reading, maintaining, and debugging code easier and less error-prone.

    That said, I feel that it's important to note that in the real world when writing practical software that users can interact with, it's simply not possible to completely avoid side effects or mutable state. The very act of creating and updating database entries is itself an act of mutating state, which runs contrary to functional programming principles and is essential for many important software projects. But even if you can't adhere strictly to functional programming principles, it's possible to benefit significantly from being aware of them and integrating them into your own software development strategies.

    Let's consider a more practical example to illustrate this. Imagine that you've built a social media website and you're trying to test a push notification system that will be triggered when your user receives a new message. Now imagine your code and unit tests look something like this:

    function sendNotification(&$message) { // pass by reference--$message will be modified outside of this function!
        $notification_system = new NotificationSystem();
        if(!$message['sent_push_notification']) {
            $notification_system->sendPushNotification($message);
            $message['sent_push_notification'] = true;
        }
    }
    
    function testSendNotification() {
        $message = [
            'user_id'=>'{some_id}',
            'contents'=>'Hi!',
            'sent_push_notification'=>false
        ];
    
        sendNotification($message);
        sendNotification($message);
    }
    

    At a quick glance you probably wouldn't be aware of why the second message didn't send, but the fact that our sendNotification() function mutates the state of the data provided to it is the culprit. This is code that doesn't adhere to functional programming principles since the data provided to it is mutated. As a result, running the function multiple times on the same variable doesn't result in the same behavior as the first call. If we wanted to work around this without adhering to functional programming principles then we would need to manually set $message['sent_push_notification'] = false; between function calls, which makes our unit tests potentially more error-prone. Alternatively we can make a simple change to adhere better to those functional principles:

    function sendNotification($message) { // pass by value--$message will NOT be modified outside of this function!
        $notification_system = new NotificationSystem();
        if(!$message['sent_push_notification']) {
            $notification_system->sendPushNotification($message);
            $message['sent_push_notification'] = true;
        }
    
        return $message;
    }
    
    function testSendNotification() {
        $message = [
            'user_id'=>'{some_id}',
            'contents'=>'Hi!',
            'sent_push_notification'=>false
        ];
    
        sendNotification($message);
        sendNotification($message);
    }
    

    Now both notifications will be sent out, which is what we would intuitively expect. You should also notice that the above is also a blend of imperative, declarative, and functional programming. Our function definitions have imperative code, our sendNotification() function adheres to the functional programming principle of avoiding mutable state (well, mostly), and our NotificationSystem object provides a declarative interface for sending a push notification for a message.


    Final Thoughts

    By viewing these three paradigms not as completely separate concepts but as layers on top of one another, where functional programming is a type of declarative programming which is implemented using imperative programming, we can stop being confused by their similarities and instead find clarification in them. By understanding that imperative programming is the backbone of everything, that declarative programming is just simplifying that backbone with simple interfaces, and that functional programming is simply adding some additional guidelines and restrictions to the way you write code to make it more consistent, reusable, and predictable, we can start to see that we're not choosing one programming paradigm over another, but instead choosing how much consideration we place on the design of the programs we write. Except in purely functional languages, functional programming isn't some alien concept distinct from imperative or declarative programming, but is instead a natural evolution of the two.

    There are a lot of details I've glossed over here. Each of these programming paradigms is far too detailed to include a proper analysis in an already lengthy post that tries to separate them from each other and clarify their differences. Blog articles exist in a thousand different places that can do each one far more justice than I can, and programming languages exist that completely cut imperative programming out of the picture. But for your average programmer slinging JavaScript, C, Rust, PHP, or what have you, I hope that this serves as a crucial starting pointing to understanding just what in the hell these functional programming enthusiasts are on about.

    25 votes
  14. Comment on Flawed Algorithms Are Grading Millions of Students’ Essays in ~tech

    Emerald_Knight
    Link Parent
    A solid example of this is the time image recognition software flagged black people as gorillas. The training data used failed to account for race, so the machine learning algorithm failed to...

    A solid example of this is the time image recognition software flagged black people as gorillas. The training data used failed to account for race, so the machine learning algorithm failed to account for skin color. Human beings create the training data, so naturally that data is subject to human bias.

    6 votes
  15. Comment on I'm trying to get a programming job without a degree. Got any tips? in ~comp

    Emerald_Knight
    Link
    Shit, you'll do fine in a junior position. I had an intern with only nine months of coding experience. I spent maybe a few months mentoring him. He was incredibly bright, but had very little...

    Shit, you'll do fine in a junior position.

    I had an intern with only nine months of coding experience. I spent maybe a few months mentoring him. He was incredibly bright, but had very little experience to exhibit in a resume. He got a job in a QA position at another company we directed him to directly after the internship ended, with nothing more than a letter of recommendation to aid him. He's currently a junior developer with them now and apparently kicking ass.

    You have quite a bit more experience to work with, having actually had a prior QA analyst position and clearly showing enough passion in your work to pursue side projects and learn different technologies. Furthermore, it's generally well-accepted that a junior dev's code simply isn't going to be that great--variable names will be shit, comments will be lacking or unhelpful, etc.--and that frequent code reviews are going to be a part of the process for getting you up to speed with best practices before setting you loose onto more critical pieces of the software you'll be working on. Seeing as your code doesn't appear to be littered with single-letter variable names or other such abominations, you should be able to get up to the company's quality standards fairly quickly.

    But really, as long as you're competent, can keep your ego in check, know your own limitations, and won't have any issues fitting into the company culture (typically this is code for "you're not a massive dickhead"), you should be fine. Just be a decent person, have some humility, and be an eager and willing learner. You seem pretty capable on all of those fronts :)

    5 votes
  16. Comment on Topic Requests: What subject would you like to see covered in more depth? in ~comp

    Emerald_Knight
    Link Parent
    You're right, those kinds of resources often seem pretty difficult to nail down unless you're looking for something specific. Security is very much an oft-overlooked component of software and not...

    You're right, those kinds of resources often seem pretty difficult to nail down unless you're looking for something specific. Security is very much an oft-overlooked component of software and not nearly enough effort is made to make people aware of how to spot even the most basic of security holes.

    Most security boils down to taking ordinary functionality of some system and tricking it to do something its creator didn't intend to happen. I think if I were to do a topic (or series of topics) on security, I'd look into the most common types of vulnerabilities and give a detailed breakdown of how they work. For example, I'd likely focus on something like a breakdown of SQL injection or making the mistake of leaving unit testing frameworks in your webroot directory on a web server.

    Tightening your security is really primarily a matter of shifting your mindset from "what do I want this code to do?" to "how could someone make this code do something I don't want it to?", so I think most of my effort would be in trying to facilitate that transition in mindset.

    I'm glad to hear that my webhook topic was instructive. Security in general is certainly a worthwhile subject to write more about. I'll be keeping it under consideration as well :)

    2 votes
  17. Comment on Topic Requests: What subject would you like to see covered in more depth? in ~comp

    Emerald_Knight
    Link Parent
    Well, I should hope so. You're going to have a hard time understanding programming paradigms if you've yet to transcend the subject of assigning x the value 5 ;) All joking aside, I do my best to...

    In my experience everything written on functional programming is aimed at people who are programmers already.

    Well, I should hope so. You're going to have a hard time understanding programming paradigms if you've yet to transcend the subject of assigning x the value 5 ;)

    All joking aside, I do my best to gear my topics toward the appropriate audiences and I like to use concrete examples to make them as accessible as possible. Functional programming itself is a simple enough subject that it should be accessible even to beginners, as long as they've at least dabbled in a bit of programming to understand some of the core concepts.

    Worst-case scenario, if something still ends up being confusing, then there's a comments section for that. I'll be more than happy to clarify anything that needs clarifying.

    1 vote
  18. Comment on Topic Requests: What subject would you like to see covered in more depth? in ~comp

    Emerald_Knight
    Link Parent
    I've never been particularly good with formal logic, so I would have to leave that to someone else. Functional programming, however, is fairly straightforward and something I could easily write...

    I've never been particularly good with formal logic, so I would have to leave that to someone else. Functional programming, however, is fairly straightforward and something I could easily write something up on. It also lends itself nicely to lots of small example code snippets for comparing and contrasting to the more common object oriented paradigms.

    More importantly, your choice of paradigm has a significant impact on how you choose to architect your projects. It's absolutely within the realm of code quality subjects!

    I'll definitely put this one into consideration :)

    2 votes
  19. Comment on Twitch suspends popular leftist streamer after controversial 9/11 comments in ~misc

    Emerald_Knight
    Link Parent
    Just a small formatting suggestion, but using > [your text here] instead of enclosing in triple backticks might be more readable (it should get rid of the horizontal scrolling). Not strictly...
    • Exemplary

    Just a small formatting suggestion, but using > [your text here] instead of enclosing in triple backticks might be more readable (it should get rid of the horizontal scrolling). Not strictly necessary, just something to consider :)

    40 votes
  20. Comment on What purpose does Tildes serve that Reddit does not? in ~tildes

    Emerald_Knight
    Link Parent
    Haha, that's alright. It's probably a conditioned response from the toxic state of social media. It takes a while to readjust.

    Haha, that's alright. It's probably a conditioned response from the toxic state of social media. It takes a while to readjust.

    3 votes