• 1 Post
  • 425 Comments
Joined 2 years ago
cake
Cake day: September 2nd, 2023

help-circle
  • There are use cases. Like containers where the pointer to the object itself is the key (for example a set). But they are niche and should be implemented by the standard library anyway. One of the things I hate most about Java is .equals() on strings. 99.999% of times you compare strings, you want to compare the contents, yet there is a reserved operator to do the wrong comparison.



  • I don’t like this article. The only 2 options considered are:

    • One color for each different token equally spaced by hue + colorized brackets.
    • Almost no coloring at all.

    There is a huge range of options in between.

    I use my own theme because I dislike every theme I’ve tried so far.

    It is basically all browny orange (because it is easy on the eyes) on a #000000 black background. However, each token type has a distinct color (within the same hue). This makes it easy to read since there is no constant color switching. But it’s also very easy to see which type a token is, since the colors are distinct enough. Obviously no colored brackets.

    And I still have room for highlighting special tokens that I care about. For example self/this is dim pistachio green instead of orange. String literals are greeny yellow and numerical constants bright orange. And punctuation is dark green.

    It also not only doesn’t colorize variables as the article suggests, it colorizes them with semantic highlighting. Parameters, and local variables are different colors. They also differ if they are mutable (for rust for example). Which means at least 4 different colors just for variables. And it helps a lot.

    I also dislike that the article dismisses the main purpose of colorizing keywords, which is typos. Colors allow to see typos as you write them. Having a section of code and saying “find me the typo” is not a realistic scenario. As you type “return”, you expect that it is red whole writing, and blue when you type the last “n”. If it doesn’t turn blue when you finish writing it, you know you didn’t do what you wanted to do. Which is instant feedback. This goes for all tokens, not just keywords. If I write the name of a struct, but it has the color of a variable, I probably wrote it wrong or I need to import it.





  • I haven’t tried using a GUI library for this. But it is possible (and relatively easy) to build for Android using rust.

    I found this tool called “x build” that works basically out of the box. It was a bit tricky to set up the release build, but got it working too.

    I made a small App using winit+wgpu and it seems to work. Win it also has touchscreen-specific events.

    Iced does use winit+wgpu, so if they are listening to the touchscreen events, it should work for Android. Haven’t tested it though.



  • In C, goto is basically a necessity though. There is really no good way of error handling.

    Options:

    1. Using goto
    void func(void *var) {
        void * var2 = malloc();
        if var == Null {
            goto err;
        }
    
        do_something();
    
    err:
        free(var2);
    }
    
    1. Early returns:
    void func(void *var) {
        void * var2 = malloc();
        if var == Null {
            free(var2);
            return;
        }
    
        do_something();
    
        free(var2);
    }
    
    1. Skipping with conditionals:
    void func(void *var) {
        bool error = false;
        void * var2 = malloc();
        if var == Null {
            error = true;
        }
    
        if !error {
            do_domething()
        }
    
        free(var2);
    }
    
    1. Early return + cleanup function.
    void cleanup(void *var2) {
        free(var2);
    }
    
    void func(void *var) {
        void * var2 = malloc();
        if var == Null {
            cleanup(var2);
            return;
        }
    
        cleanup(var2);
    }
    

    Option 1 is really the only reasonable option for large enough codebases.

    Option 2 is bad because duplicate code means you might change the cleanup in one code path but not some other. Also duplicate code takes up too much valuable screen space.

    Option 3 has a runtime cost. It has double the amount of conditionals per error point. It also adds one level of indentation per error point.

    Option 4 is same as option 2 but you edit all error paths in one single place. However, this comes at the cost of having to write 2 functions instead of 1 for every function that can error. And you can still mess up and return while forgetting to call the cleanup function.

    You must also consider that erroring functions are contagious, just like async ones. I’d say most of the time a function is propagated upwards, with very few being handled just as it ocurrs. This means that whichever downside your option has, you’ll have to deal with it in the whole call stack.



  • calcopiritus@lemmy.worldtoFunny@sh.itjust.worksRight of way
    link
    fedilink
    arrow-up
    2
    arrow-down
    3
    ·
    25 days ago

    If there’s literally a bike lane along the road, there’s no reason to use the road on a bike unless you’re an asshole.

    I do pay the water company, which doesn’t give me the right to throw wet wipes down the toilet.

    I do pay a waste management tax. That doesn’t give me the right to throw dogshit in the paper container.

    We all pay to build bike lanes. Since people using bike lanes helps both cyclists and drivers. Just use the damn bike lane if there is one.





  • When I want to draw raw polygons, I use wgpu. When I want a GUI I used iced. And when I want both, I use wgpu+imgui.

    Learning wgpu is quite steep, and it has tons of boilerplate. So unless you’re certain that you will use it a lot. I would just use iced.

    When I say wgpu I mean wgpu+winit. Though winit is quite simple and light. So the main part is wgpu.





  • Yes that is me. Someone’s beliefs are their opinion, that is correct, whether they are ignorant or not.

    I’m not saying I should be immune for criticism or retaliation. In fact I wish my comment was criticized so I can know what part of it people disagree with. Instead I’m met with “go eat farts, transphobe”.

    In my opinion, claiming that “it is possible to not have fascism and whatever ‘trans rights’ means to you at the same time” is not transphobic.