• 0 Posts
  • 239 Comments
Joined 2 years ago
cake
Cake day: September 2nd, 2023

help-circle
  • It’s not one thing or the other.

    For example I often end up using event loops. Where an event is a tagged union. Some events take up 1 byte, some 400. It’s almost effortless to put the big variants in the heap, and just keep a pointer in the union. So why not do it from the start.

    Sure, optimizing every loop to make it vectorizable is probably not worth it, since that loop you wrote on the 10th commit might not even exist when the software is released. But there are many low hanging fruit.

    Also, some optimizations require a very specific software architecture. Turning all your arrays of structs into structs of arrays may be a pain if you didn’t plan for making that switch.



  • I don’t understand why any user would have to care or even know what GUI toolkit an app uses.

    I don’t know why the burden is put on the user/DE. You shouldn’t have to care about what GUI toolkit your DE uses either.

    DE and themes should be decoupled from eachother. So the user can install whatever “theming system” they want, and GUI toolkits should aim to support as many theming systems as practical.

    GUI toolkits are implementation details, the user doesn’t care about implementation, it cares about what it sees. And what it sees is the colors and icons.







  • Maybe some people don’t delete the fork after their PR is done.

    In my case, I found another explanation.

    Sometimes, a random person comes and forks one of my repos. I check their profile, and it’s a techbro student with hundreds of forked repos without any commits. With their bio referencing AI or some shit.

    I’m pretty sure these people fork a lot of repos just to pad their CV or something. Make it look like you have a lot of repos. Because when you go to someone’s profile, it is not clear that a repo is a fork instead of their own creation.



  • The problem with that is that reviewing takes time. Valuable maintainer time.

    Curl faced this issue. Hundreds of AI slop “security vulnerabilities” were submitted to curl. Since they are security vulnerabilities, they can’t just ignore them, they had to read every one of them, only to find out they weren’t real. Wasting a bunch of time.

    Most of the slop was basically people typing into chatgpt “find me a security vulnerability of a project that has a bounty for finding one” and just copy-pasting whatever it said in a bug report.

    With simple MRs at least you can just ignore the AI ones an priorize the human ones if you don’t have enough time. But that will just lead to AI slop not being marked as such in order to skip the low-prio AI queue.




  • 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.







  • Rust is not fully functional. But I am legally obligated to recommend it any time I can.

    Jokes aside, this doesn’t apply to you, since you seem to actively learn functional programming. But for people that are scared of it, rust looks like “normal” languages, but has tons of features that can be attributed to functional programming. Even more so if you avoid using references. You can easily “mutate” objects the functional way, by passing the object to the function, and the function creates a new object with just some value changed.

    It has algebraic data types. Function pointers. Iterators. Pattern-based match statements. Don’t have class inheritance. Inmutable by default. Recursion. Monads. And probably other FP features that I’m missing.

    It has basically every functional feature while having familiar syntax.

    It’s also extremely easy to install. Which I didn’t use to appreciate, but then I tried to learn OCaml and had to give up because I couldn’t set up a proper dev environment on windows.