Mia

Yeah they’ve been doing that for a while

Your comment shows you fundamentally do not understand how societal expectations and rejection affect people psychologically. If half the world was constantly trying to make your life hell, I bet your mental health wouldn’t be the best either.

It is far too common to point at depression or anxiety as the problem instead of a symptom of the actual problem.
But making that distinction would require critical thinking, a skill that, for someone calling other people “brainwashed idiots”, seems to be sorely lacking…

I see. Either way there are some substantial improvements over fsync in some cases, so it should benefit Proton as well.

I don’t think Proton has anything special going on in that regard actually. It’s got DXVK and all the other stuff built-in, but for the synchronization primitives I think it just uses fsync just like Wine does, so this might be interesting…

American culture is one of the few I’ve found to be actively “anti-knowledge”. It’s not just their educational system being bad, it’s a genuine cultural tendency of not just dismissing experts, but straight out refusing to learn and snobbing those who do.

Every time I see someone write “sorry for my bad english” their writing is several times better than many of the native speakers I interact with on a daily basis.

I have no way of verifying this is real, but I wholeheartedly believe it.

No no, just sand. That’s what silicon is at conception, so you can only write on sand.

But sometimes it’s just what people need to get their shit together. People get too complacent sometimes, and when everyone has to deal with the consequences sometimes a little emphasis on how bad things are is necessary.

And I know much of it is not necessarily the fault of the devs, with management and deadlines preventing them from doing the best possible job, I myself was forced to release half broken updates a few times because of that, but they are not the only problem.

There’s a real problem in today’s programming culture with thinking that computers are so fast, any garbage code you write will be fast enough, or that you only need to optimize the hot path. Apply that philosophy throughout all your codebase, and suddenly there is no hot path, everything runs like shit. People should also actually learn how things work, not just frameworks, otherwise they won’t be able to make informed decisions about what they write.

Also stuff like “Clean Code” and other similarly dogmatic principles still permeate many of the codebases I see. Nigh implementable jungles of <10 lines long functions and OOP garbage that make working with everything a massive pain, other than making every function call virtual and thrashing performance. You need to maintain such a massive amount of context in your head just to figure out the flow of a particular piece of code, with the aid of a debugger because everything is done through abstract classes or interfaces, that even making the smallest change becomes a tedious and error prone task.

Also fuck dynamically typed languages. They suck, every single one of them.

No it just makes me even more frustrated. The amount of incompetence and neglect I see and have to deal with on a daily basis, even with software developed by multi-million dollar corporations, is astonishing.

Why is modern webdev such a clusterfuck? Why does VisualStudio take multiple seconds to open an empty project? Why does Nvidia’s control panel have multiple seconds long pauses to switch between settings categories or loading lists? Why does this game run like garbage on a 4090 when it has mostly static environments and the graphics aren’t even that good?

I could go on but I’d be here all day. All of those things, with the exception of webdev (because god there’s so much shit in there…), could be easily fixed* or should’ve never gotten that bad in the first place.

*Provided the entire architecture isn’t garbage, otherwise see the rest of the sentence…

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.