Mia

Yeah but if the class changes you need to update everything, you got all that boilerplate taking up space for no real reason, etc…

The Rust way’s just a lot cleaner imo.

At least it has something to complain about, unlike Karens.

I get the mistake. Wouldn’t even call it one tbh, just an oversight. But when someone points it out normally one doesn’t reply with “don’t force your political views onto me” as if non male devs was some weird “woke” concept. A simple “whoops, missed that” would have been perfectly fine and everyone would’ve moved on. With that said, having followed the whole debacle I can say it could have been handled better by both sides.

The problem was more the fact that the devs viewed using anything other than ‘he’ as political, not the presence of gendered language itself. The devs themselves made a big deal about changing it. The way I see it, it’s not even about trans people. How about just women? Is including women in software developent considered political? One would hope not, but here we are…

I find this to be true for every new language I try out. Since every language has a different way of doing things and gives me a new perspective, in the long run they all end up improving my programming style as a whole. I always end up integrating the best parts of each into my next project when possible.

Experience will always be more valuable than any set of rules these kind of books tout as “the way things are meant to be done”.

Oh for sure. I have nothing against getters and setters when they’re justified, but in the case of bare fields with no validation like that example it’s just annoying.
Also stuff like this just grinds my gears (oversimplified example again):

class IntegerAdder {
    private int a, b;
    public IntegerAdder(int a, int b) {
        this.a = a;
        this.b = b;
    }
    
    public int get_sum() {
        return a + b;
    }
}

Just make it a bloody function.
You may say it’s silly, but I’ve genuinely found code like this in the wild. Not that exact code snippet of course but that was the spirit.

It really depends on the context frankly. I did say it was a crappy example ;)
Try to read this snippet I stole from Clean Code and tell me if it’s readable without having to uselessly jump everywhere to understand what’s going on:

public class SetupTeardownIncluder {
  private PageData pageData;
  private boolean isSuite;
  private WikiPage testPage;
  private StringBuffer newPageContent;
  private PageCrawler pageCrawler;


  public static String render(PageData pageData) throws Exception {
    return render(pageData, false);
  }

  public static String render(PageData pageData, boolean isSuite) throws Exception {
    return new SetupTeardownIncluder(pageData).render(isSuite);
  }

  private SetupTeardownIncluder(PageData pageData) {
    this.pageData = pageData;
    testPage = pageData.getWikiPage();
    pageCrawler = testPage.getPageCrawler();
    newPageContent = new StringBuffer();
  }

  private String render(boolean isSuite) throws Exception {
     this.isSuite = isSuite;
    if (isTestPage())
      includeSetupAndTeardownPages();
    return pageData.getHtml();
  }

  private boolean isTestPage() throws Exception {
    return pageData.hasAttribute("Test");
  }

  private void includeSetupAndTeardownPages() throws Exception {
    includeSetupPages();
    includePageContent();
    includeTeardownPages();
    updatePageContent();
  }


  private void includeSetupPages() throws Exception {
    if (isSuite)
      includeSuiteSetupPage();
    includeSetupPage();
  }

  private void includeSuiteSetupPage() throws Exception {
    include(SuiteResponder.SUITE_SETUP_NAME, "-setup");
  }

  private void includeSetupPage() throws Exception {
    include("SetUp", "-setup");
  }

  private void includePageContent() throws Exception {
    newPageContent.append(pageData.getContent());
  }

  private void includeTeardownPages() throws Exception {
    includeTeardownPage();
    if (isSuite)
      includeSuiteTeardownPage();
  }

  private void includeTeardownPage() throws Exception {
    include("TearDown", "-teardown");
  }

  private void includeSuiteTeardownPage() throws Exception {
    include(SuiteResponder.SUITE_TEARDOWN_NAME, "-teardown");
  }

  private void updatePageContent() throws Exception {
    pageData.setContent(newPageContent.toString());
  }

  private void include(String pageName, String arg) throws Exception {
    WikiPage inheritedPage = findInheritedPage(pageName);
    if (inheritedPage != null) {
      String pagePathName = getPathNameForPage(inheritedPage);
      buildIncludeDirective(pagePathName, arg);
    }
  }

  private WikiPage findInheritedPage(String pageName) throws Exception {
    return PageCrawlerImpl.getInheritedPage(pageName, testPage);
  }

  private String getPathNameForPage(WikiPage page) throws Exception {
    WikiPagePath pagePath = pageCrawler.getFullPath(page);
    return PathParser.render(pagePath);
  }

  private void buildIncludeDirective(String pagePathName, String arg) {
    newPageContent
      .append("\n!include ")
      .append(arg)
      .append(" .")
      .append(pagePathName)
      .append("\n");
  }
}

That’s what I was talking about.

Yeah that was essentially what I was referring to (referring to your edit).

I generally dislike stuff like (crappy example incoming):

void do_stuff(int count, bool cond) {
	function1(count);
	function2(b);
	function3();
}

void function1(int count) {
	for (var i = 0; i < count; i++) {
		...
	}
}

void function2(bool cond) {
	if (cond) { ... }
	else { ... }
}

void function3() {
	...
}

I’m not a fan of this kind of code fragmentation.
If all those actions were related and it could have been just one thing, retaining a lot more context, then it should be one function imo.
If by not splitting it it became massive with various disconnected code blocks, sure, but otherwise I’d much prefer being able to read everything together.

If splitting the functions required producing side effects to maintain the same functionality, then that’s even worse.

Also (taking go as an inspiration), I (personally) find this very hard to read

Agreed. Go’s implementation of errors as values is extremely noisy and error prone. I’m not a fan of it either.

You can always ignore an error return value and pretend that the “actual” value you got is correct.

Then that’s a language design / api design issue. You should make it so you cannot get the value unless you handle the error.
I’m of the opinion that errors should be handled “as soon as possible”. That doesn’t necessarily mean immediately below the function call the error originates from, it may very well be further up the call chain. The issue with exceptions is that they make it difficult to know whether or not a function can fail without knowing its implementation, and encourage writing code that spontaneously fails because someone somewhere forgot that something should be handled.

The best implementation of errors as values I’ve seen is Rust’s Result type, which paired with the ? operator can achieve a similar flow to exceptions (when you don’t particularly care where exactly an error as occurred and just want to model the happy path) while clearly signposting all fallible function calls. So taking your example:

try {
  res = try_something()
  res2 = try_something_else(res)
  res3 = try_yet_something_else(res2)
  return res3
} catch (e) {
  // check which error it is and handle it appropriately
  throw_own_exception()
}

It would become:

fn do_the_thing() -> Result<TheValue, TheError> {
	res = try_something()?;
	res2 = try_something_else(res);
	res3 = try_yet_something_else(res2)?;
}

match do_the_thing() {
	Ok(value) => { /*Do whatever*/ }
	Err(error) => { /*handle the error*/ }
}

The difference is that you know that try_something and try_yet_something_else may fail, while try_something_else cannot, and you’re able to handle those errors further up if you wish.
You could do so with exceptions as well, but it wasn’t clear.

The same clarity argument can be made for null as well. An Option type is much more preferable because it forces you to handle the case in which you are handed nothing. If a function can operate with nothing, then you can clearly signpost it with an Option<T>, as opposed to just T if a value is mandatory.

Exceptions are also a lot more computationally expensive. The compiler needs to generate landing pads and a bunch of other stuff, which not only bloat your binaries but also prevent several optimizations. C# notoriously cannot inline functions containing throws for example, and utility methods must be created to mitigate the performance impact.

I’ve found it’s mostly two things: readability (ironically) and performance. I’ll describe a few crude examples, but I won’t get too much into specifics, otherwise I might as well write another book myself.

The performance part is simple: its excessive reliance on polymorphism and the presence of several levels of abstraction just doesn’t allow for good code generation. I’ve seen 10x+ performance improvements by dropping all of the above, with often minimal loss in readability; on the contrary, oftentimes the code became more readable as well.

The readability part is harder to explain; not only because it depends on the codebase and the problem at hand, but also on the coding style each programmer has (though in my opinion, in that particular case it’s the programmer’s problem, not the codebase’s).
I like to think of codebases as puzzles. To understand a codebase, you need to piece together said puzzle. What I’ve found with Clean Code codebases is that each piece of the puzzle is itself a smaller puzzle to piece together, which isn’t ideal.

Functions

They should be small and do one thing

I generally disagree, not because those ideas are wrong, but because they’re often too limiting.
What often happens by following those principles is you end up with a slew of tiny functions scattered around your codebase (or a single file), and you are forced to piece together the behaviour they exhibit when called together. Your code loses locality and, much like with CPU cache locality, your brain has to do extra work to retrieve the information it needs every time it needs to jump somewhere else.
It may work for describing what the code does at a high level, but understanding how it works to make meaningful changes will require a lot more work as a result.

Don’t repeat yourself

Once again, it makes sense in principle, but in practice it often creates more problems. I agree that having massive chunks of repeated code is bad, no questions about it, but for smaller chunks it may actually be desirable in some circumstances.
By never repeating code, you end up with functions that are over-parameterized to account for all possible uses and combinations that particular code snippet needs to work with. As a result, that code becomes more complex, and the code that calls it does too, because it requires you to know all the right parameters to pass for it to do the right thing.

Exceptions

Exceptions are just bad. They are a separate, hidden control flow that you constantly need to be wary of.
The name itself is a misnomer in my opinion, because they’re rarely exceptional: errors are not just common, but an integral part of software development, and they should be treated as such.
Errors as values are much clearer, because they explicitly show that a function may return an error and that it should be handled.

Classes, interfaces and polymorphism

I have lots of gripes with object orientation. Not everything needs to be an object, not everything needs to be polymorphic. There’s no need to have a Base64Decoder, much less an IBase64Decoder or an AbstractBase64Decoder. Base64 only works one way, there are no alternative implementations, a function is enough.

I’m a lot more on the data oriented side of the isle than the OO one, but I digress.
Object orientation can be good in certain contexts, but it’s not a silver bullet.

Encapsulation for the sake of it

Let’s say you have something like this:

class Point {
	public float X, Y;
}

With the Clean Code approach, it magically becomes:

class Point {
	private float x, y;
	
	public float get_x() {
		return this.x;
	}
	public float get_y() {
		return this.y;
	}
	public void set_x(float x) {
		this.x = x;
	}
	public void set_y(float y) {
		this.y = y;
	}
}

Why? Who the hell knows. It makes absolutely no tangible difference, it only makes your code longer and more verbose. Now, if a value needs validation, sure, but oftentimes this is just done regardless and it drives me insane.

Abstract classes for everything!

• “You’ll never know when you’ll need to add another implementation, right?”
• “You don’t need to know the underlying implementation”

The problem with wanting to create the most generalized code in advance is that you end up stuck in abstraction hell.
You may as well not need the ability to have arbitrary implementations, but now you need to plan for that.

Not only that, but it also makes reasoning about your code harder: how many times have you had to step through your code just to figure out what was being executed | just to figure out what particular concrete class was hiding behind an abstract class reference?
I myself, way too many, and there was often no reason for that.

Also, the idea that you shouldn’t know about the implementation is crazy to me. Completely encapsulating data and behaviour not only makes you miss out on important optimizations, but often leads to code bloat.

There’s more but I’m tired of typing :)

Take a look at these if you want more info or someone else’s view on the matter, I wholeheartedly recommend both:

• It’s probably time to stop recommending Clean Code
• “Clean” Code, Horrible Performance

I’m of the opinion that Uncle Bob did some massive damage to software development as a whole with that book.
With that said, this is genuinely funny.

Chaotic weird

Aside from some notable examples, I’ve had great luck with gaming on Linux. Wayland’s still rough (thanks Nvidia) but it’s not that big of an issue; general usage is fine and development is fantastic.

There is only one issue when it comes to games…
I have a VR setup…

You keep making up extreme scenarios, none of which have materialized, even in North America, because again: most people are reasonable when it comes to that stuff.

No matter how much right wing groups insist on it, it’s a made up reality meant to spread disdain. Queer visibility has increased in the last few years, but just like anything, it will plateau, much like left-handedness has plateaued after a while after people stopped being forced to be right-handed.

The worst offender, and the only real/relevant example I can find when it comes to forced inclusivity, is Disney, and nearly everybody hates it because… well… it’s forced, including minorities. But they do it to avoid backlash from very few but vocal people on Twitter that have nothing better to do.That, and it generates media coverage, which is free publicity.

I believe you’re just being paranoid, but you do you. I feel like trying to convince you otherwise would be a waste of time at this point.
Good luck with your endeavours…

Sure, no worries :3

I wasn’t criticising your comment, sorry if that’s what it looked like. It was just what came to mind reading a bunch of comments saying they’re abandoning Hyprland because of the controversies. Probably should have just replied to the post itself instead of your comment…

Less than six hundred intersex people are known to have ever existed. Fertile intersex people can have at most one reproductive organ that can generate offspring. Truly bisexual living beings have been observed in the animal kingdom […]

You… you didn’t seriously believe I was thinking of human hermaphrodites when talking about intersex people, did you…? -_-
There are FAR more intersex people than 600. It is estimated than 1.5% to 2% of the world’s population is born intersex, to varying degrees.

Now, about laws targeted at protecting marginalized communities:
They mostly focus on businesses, forbidding them from discriminating on the basis of sexual orientation, gender identity and the like. That is it.
There are penal consequences for citizens when it comes to hate speech, but those only apply when such remarks incite violence against individuals, or result in extremely negative outcomes, like suicide.
No one’s gonna arrest you for calling someone a slur on the street. Jails would be full if that were the case.
This is once again an overreaction to make it appear like people are out to get you.

My native language is highly inflected - we have nouns that are either feminine or masculine. Here we have marginalized left-wing organizations promoting a made up grammar that is so convoluted that even those who promote it can not manage to get acquainted with it.

Languages evolve.
I am familiar with the perils of gendered languages, being a speaker of one myself. They can be adapted, it undoubtedly takes effort.
Nobody in their right mind is arguing in favour of supporting every single made up pronoun. I myself am not a fan of neopronouns, some of them are pure madness in my opinion, but a simple they/them can be incorporated into a language. I’ve seen and heard languages being butchered in worse ways, and at least this one is useful. We can leave those who want to be referred to with “starself”, whatever that’s supposed to mean, to worry about explaining everything to everyone they know, to themselves. It would be utterly inpractical to appease everyone, but they/them is manageable.

because they want spaces that look less heterosexual and less white

You kinda gave yourself away if you have an issue with that. I agree that people should be hired on the base of expertise, not ethnicity or identity, but a more diverse environment is not just some whimsical idea “the woke mob” came up with. It fosters exchange of ideas, societal acceptance, and generally improves work environments for everyone who isn’t xenophobic, all things that are generally desirable in a well integrated society.

The “woke mob”, " woke ideology " or whatever you want to call it doesn’t exist. It is an invention of right wing groups to categorise everything they don’t like with, which in most cases just boils down to being decent human beings and not spreading hate. There are zealots, there’s no denying it, but if you just log off of social media and actually get out, you’ll find that no one is after you, no one is implementing all those crazy ideas an extremely small but vocal minority comes up with. So go live your life and relax. The woke mob won’t get you, Italian will still be the same language as it is now, and you’ll still be able to cuss at anyone you don’t like. You’ll be fine.

People should learn to separate technically impressive projects from the people running them. I’m not going to contribute or financially support the project, but I’m not going to stop using Hyprland because of its creator’s views and conduct. With that said, this stuff certainly doesn’t spark enthusiasm…

Look up intersex people and marvel at how loose the definition of being female is. People are born without a womb, mixed genitalia, any combination you can imagine. They’re still considered women. If one can get to such a state, or further, they should too.

Look up the various studies performed on transgender patients showing how their brain is more aligned to that of females (or males, whichever way they swing), at a biological level.

Look up how hormonal imbalances during pregnancy can cause such discrepancies. It’s not just a psychological thing, it’s a biological phenomenon that does appear in nature.

Or don’t. You’re free to remain ignorant, just like you’re free to say whatever you like, but don’t act like the victim when you knowingly say something that’s considered out of line and face consequences.

Facing consequences for your actions is nothing new, don’t act like it is. Work places and public spaces have had rules of conduct since the dawn of time; what is considered acceptable has shifted as society evolved. You may not like it, but that’s not going to change just because calling someone by their chosen name makes you uncomfortable. Would you consider being disallowed to call black people slurs totalitarianism?

You are free to say whatever you want, just like people and employers are free to not want to associate with you for the things you say.

I am familiar with the current PC and GPU architectures.

IO is a non issue. Even a massive file can be trivially memory mapped and parsed without much hassle, and in the case of a text editor you’d have to deal with IO only when opening or saving said file, not during rendering.

As for the rendering side, again, the amount of memory you’d have to transfer between RAM and VRAM would be minimal. The issue is latency, not speed, but that can be mitigated though asynchonous transfer operations, so if done properly stutters are unlikely.

Rendering monospaced fonts (with decorators and control characters) at thousands of frames a second nowadays is computationally trivial, take a look at refterm for an example. I suspect non-monospaced fonts would require more effort, but it’s doable.

As I said at the beginning, it’s not impossible, just a pain. But so is font rendering in general honestly :/