• IndiBrony@lemmy.world
    link
    fedilink
    English
    arrow-up
    92
    arrow-down
    2
    ·
    edit-2
    10 months ago

    Fools haven’t even written it well! Translated:

    STOP WRITING

    • MEMORY WAS NEVER SUPPOSED TO BE AESSED DIRETLY

    • YEARS OF PROGRAMMING yet STILL ODE IS STILL WRITTEN with memory vulnerabilities

    • Wanted to aess memory diretly anyway? We had a tool for that: It was alled “ASSEMBLY”

    • “Yes please give me NULL of something. Please give me *&* of it” - Statements dreamed up by the utterly deranged

    LOOK at what Programmers have been demanding your Respet for all this time, with all of the omputers we built for them

    (These are REAL programs, written by REAL Programmers):

    ??? ??? ???

    They have played us for absolute fools

    • Jordan_U@lemmy.ml
      link
      fedilink
      arrow-up
      17
      ·
      edit-2
      10 months ago

      Fun fact!

      The Asahi Linux drivers for the Apple M1 GPU were originally written in Python: https://asahilinux.org/2022/11/tales-of-the-m1-gpu/

      GPU drivers in Python?!

      Since getting all these structures right is critical for the GPU to work and the firmware to not crash, I needed a way of quickly experimenting with them while I reverse engineered things. Thankfully, the Asahi Linux project already has a tool for this: The m1n1 Python framework! Since I was already writing a GPU tracer for the m1n1 hypervisor and filling out structure definitions in Python, I decided to just flip it on its head and start writing a Python GPU kernel driver, using the same structure definitions. Python is great for this, since it is very easy to iterate with! Even better, it can already talk the basic RTKit protocols and parse crash logs, and I improved the tools for that so I could see exactly what the firmware was doing when it crashes. This is all done by running scripts on a development machine which connects to the M1 machine via USB, so you can easily reboot it every time you want to test something and the test cycle is very fast!

      • I Cast Fist@programming.dev
        link
        fedilink
        arrow-up
        3
        ·
        10 months ago

        Good for testing and iterating, but what about performance? Though I guess getting everything right is more important right now, translating it into another language will probably require less work that way

        • Jordan_U@lemmy.ml
          link
          fedilink
          arrow-up
          6
          ·
          10 months ago

          It has already been translated into rust. Python wasn’t ever intended to be used in the “real” driver, but I thought it was a fun anecdote none the less.

    • gigachad@feddit.de
      link
      fedilink
      arrow-up
      6
      arrow-down
      1
      ·
      10 months ago

      Yes and let us build the environment with conda, it’s going to be a fun time!

  • RubberElectrons@lemmy.world
    link
    fedilink
    arrow-up
    45
    arrow-down
    2
    ·
    edit-2
    10 months ago

    I really like C because I can just get to the heart of an action and make it happen without much surrounding code.

    I could make classes and blah blah blah if I want to make a large, complex program but I’d rather write several small, simple to grok programs which pass information around so each program can do its one simple thing, quickly and easily. Chain the small programs together with bash or something, and bingo, you’ve got a modular high speed system.

    I’m not a programmer, actually a mechanical engineer. But the Unix philosophy of simple, modular tools is great, provided one properly checks and sanitizes inputs.

    • macaroni1556@lemmy.ca
      link
      fedilink
      arrow-up
      14
      arrow-down
      3
      ·
      10 months ago

      What you’re describing sounds like Python. Not really C’s strong suit.

      If you haven’t checked it out yet, you certainly should!

      • remotelove@lemmy.ca
        link
        fedilink
        arrow-up
        8
        ·
        10 months ago

        I agree with your main point. Python does a great job of replacing lots of tiny, chained scripts. Simple API calls with wget or curl have a place, but can spiral out of control quickly if you need to introduce any grain of control like with pagination, as an example.

        Maintaining one Python app (or “script”) can still adhere to the unix philosophy of simplicity but can bend some rules as far as monolithic design is concerned if you aren’t careful.

        It all boils down to whether you are introducing complexity or reducing it, IMHO.

        • macaroni1556@lemmy.ca
          link
          fedilink
          arrow-up
          4
          ·
          10 months ago

          I’m not suggesting replacing the small programs with one mega Python script, I meant that even C is not a good language for that either.

          If you’re chaining a bunch of stuff together through your shell environment anyway, you’re not using the low level benefits of C, so you’re just punishing yourself with having to implement everything by hand every time! Python is amazing because the syntax is clear and readable and the standard library has nearly everything you’d need if you’re not building a large application.

          However since most of these things are going to be one-liners then yeah you may want to just put them in one script!

          • RubberElectrons@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            10 months ago

            I’m supporting embedded devices, and I like the performance of C. I’ve used python, it’s meh. At least you don’t have to compile it.

              • frezik@midwest.social
                link
                fedilink
                arrow-up
                1
                ·
                10 months ago

                Rust is starting to show up in embedded. And micropython, though that obviously has some limitations.

                • macaroni1556@lemmy.ca
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  10 months ago

                  Totally, but I’m not aware of anyone using either properly in a truly production environment. Both are more on the hobbyist or tinkering side, or in the Linux space anyway where you can already just do anything.

                  (From what I’ve seen? Would be thrilled to see examples!)

                  I really like Micropython too. I made a “game” that communicates state between multiple boards over wifi in almost no time compared to how long it would take in C++.

  • MeanEYE@lemmy.world
    link
    fedilink
    arrow-up
    39
    ·
    10 months ago

    Just use brainfuck for everything. The entry barrier for the programming industry needs to be higher anyway.

      • dejected_warp_core@lemmy.world
        link
        fedilink
        arrow-up
        13
        ·
        edit-2
        10 months ago

        For the programmer? Very no.

        For saving space if run via interperter? No.

        For running compiled for conventional CPUs? No.

        Compared to CISC instruction sets? Absolutely no.

        BF might be highly efficient if crunched down to a bit-packed representation (3 bits per instruction) and run on an FPGA that understands it.

        • frezik@midwest.social
          link
          fedilink
          arrow-up
          6
          ·
          10 months ago

          For demonstrating to CS freshmen that Turing Completeness isn’t that remarkable of a language feature: very highly efficient.

      • MeanEYE@lemmy.world
        link
        fedilink
        arrow-up
        6
        ·
        10 months ago

        Can be compressed very efficiently. I do dread the thought of writing a driver in brainfuck.

        • MatFi@lemmy.thias.xyz
          link
          fedilink
          arrow-up
          5
          ·
          edit-2
          10 months ago

          Can be compressed very efficiently.

          Which basically means: “You have to write more code than actually needed”. It’s more a con than a pro in my eyes.

        • dejected_warp_core@lemmy.world
          link
          fedilink
          arrow-up
          2
          ·
          10 months ago

          Hot take: As a VM with only eight instructions, it’s very easy to code and securely sandbox. Maybe BF has utility as a compilation target?

          • MeanEYE@lemmy.world
            link
            fedilink
            arrow-up
            5
            ·
            10 months ago

            Hardware is complex and mysterious enough without added complexity of an esoteric language.

  • Ethanol@pawb.social
    link
    fedilink
    English
    arrow-up
    30
    ·
    10 months ago

    But what if I want a union struct to quickly interpret floats as ints and vice versa! I need my C hacks!

      • Jordan_U@lemmy.ml
        link
        fedilink
        arrow-up
        3
        ·
        10 months ago

        … Which compilers don’t consistently enforce, much like most undefined behavior in C.

          • Jordan_U@lemmy.ml
            link
            fedilink
            arrow-up
            2
            arrow-down
            1
            ·
            10 months ago

            By refusing to compile any code that has undefined behavior. This is what rust’s compiler does, and is simply not possible for a C compiler to do.

            • Jordan_U@lemmy.ml
              link
              fedilink
              arrow-up
              2
              ·
              10 months ago

              To put it another way:

              Strict aliasing is an invariant that C compilers assume you as a developer will not violate, and use that assumption to make optimization choices that, if you as the developer have failed to follow the strict aliasing rules, could lead to undefined behavior. So it’s a variant that the compiler expects, but doesn’t enforce at compile time.

              I guess it is possible to just disable all such optimizations to get a C compiler that doesn’t create UB just because strict aliasing rules were broken, but there are still many ways that you can trigger UB in C, while safe rust that compiles successfully theoretically has no UB at all.

              • uis@lemmy.world
                link
                fedilink
                arrow-up
                2
                ·
                10 months ago

                Strict aliasing exists not for optimization, but for type alignment. You may need more space on stack to save uint32_t than uint8_t[5] because former has 32-bit alignment.

                • Jordan_U@lemmy.ml
                  link
                  fedilink
                  arrow-up
                  2
                  ·
                  10 months ago

                  Either way, this is a rule that you as a human are required to follow, and if you fail the compiler is allowed to do anything, including killing your cat.

                  It’s not a rule that the compiler enforces by failing to build code with undefined behavior.

                  That is a fundamental, and extremely important, difference between C and rust.

                  Also, C compilers do make optimization decisions by assuming that you as a human programmer have followed these strict aliasing rules.

                  https://gist.github.com/shafik/848ae25ee209f698763cffee272a58f8

                  Has a few examples where code runs “properly” without optimizations but “improperly” with optimizations.

                  I put “improperly” in quotes because the C spec says that a compiler can do whatever it wants if you as a human invoke undefined behavior. Safe rust does not have undefined behavior, because if you write code which would invoke UB, rustc will refuse to build it.

            • uis@lemmy.world
              link
              fedilink
              arrow-up
              2
              ·
              10 months ago

              Compiler knows what is undefined behaviour better than all lemmy experts

    • jimbolauski@lemm.ee
      link
      fedilink
      arrow-up
      2
      ·
      10 months ago

      Or if your pulling 4 byte data from an AtoD converter and it’s ordered 2, 3, 0, 1 for a fixed point value that you need to convert to a standard float at an extremely high rate or else the ring buffer will fill and you’ll start losing data.

      That code review was a good time.

      • kevincox@lemmy.ml
        link
        fedilink
        arrow-up
        1
        ·
        10 months ago

        Well it is standard. The standard says that it is undefined behaviour. But I guess you are right that some compilers have non-standard options to make it not undefined behaviour.

  • mlg@lemmy.world
    link
    fedilink
    English
    arrow-up
    26
    ·
    10 months ago

    Python laughing nervously: “haha yeah… we shouldn’t write in C, amirite guys?”

  • MeanEYE@lemmy.world
    link
    fedilink
    arrow-up
    24
    ·
    10 months ago

    Do people still think, after all this time and so many different languages, that there will be one language to rule them all? I mean technically you can drive nails with a rock, but you don’t see a carpenter using one. Right tool for the job. Always was, always will be.

    • Pipoca@lemmy.world
      link
      fedilink
      arrow-up
      8
      arrow-down
      2
      ·
      10 months ago

      Right tool for the job, sure, but that evolves over time.

      Like, years back carpenters didn’t have access to table saws that didn’t have safety features that prevent you from cutting off your fingers by stopping the blade as soon as it touches them. Now we do. Are old table saws still the “right tool for the job”, or are they just a dangerous version of a modern tool that results in needless accidents?

      Is C still the right tool for the job in places where Rust is a good option?

      • Metype @lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        10 months ago

        There’s a project I could have written in Rust. Maybe some of the headache wouldn’t have ever happened using Rust.

        I also didn’t know Rust at the time and it was a large project with unkind deadlines. I think the right tool for the job can also depend on available resources. So while the more unsafe, older tool I used caused a few small issues that Rust would not have; the project wouldn’t have been finished if I’d used Rust.

        • Pipoca@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          10 months ago

          Yeah, projects also exist in the real world and practical considerations matter.

          The legacy C/C++ code base might slowly and strategically have components refactored into rust, or you might leave it.

          The C/C++ team might be interested in trying Rust, but have to code urgent projects in C/C++.

          In the same way that if you have a perfectly good felling axe and someone just invented the chain saw, you’re better off felling that tree with your axe than going into town, buying a chainsaw and figuring out how to use it. The axe isn’t really the right tool for the job anymore, but it still works.

  • slembcke@lemmy.ml
    link
    fedilink
    arrow-up
    22
    ·
    10 months ago

    I enjoy the selection bias in the comments for these sorts of posts. >_< There’s a few people saying “I kinda like C”, a few saying “use Python instead”, and a whole lot saying “Rust is my lord and savior”. Completely disjoint from the real world usage of the languages for whatever practical, pragmatic, or ideological measures they are used for.

    • MojoMcJojo@lemmy.world
      link
      fedilink
      arrow-up
      6
      ·
      10 months ago

      I know barely anything about programming languages and only ask as a fan, what are the real world usages of languages and what are their practical, pragmatic, or ideological measures that they are used for?

      • slembcke@lemmy.ml
        link
        fedilink
        arrow-up
        5
        ·
        10 months ago

        I guess by real world usage I mean what proportion of code is being made with them. You should be skeptical of their accuracy, but there are measures for that. Like there is this one: https://www.tiobe.com/tiobe-index/, but it describes it’s methodology as being about popularity based on articles, news, and other such things. Github publishes a very different chart as does RedMonk. Rust barely shows up on these charts, but Rust fans are very enthusiastic in threads like this. I like Rust well enough, but I also find the over-enthusiasm amusing.

        By practical/pragmatic I mean the ability to target a lot of hardware with C. Sometimes the tooling is crap, but it’s very universal. Being built on LLVM Rust can go onto plenty of hardware too, but it’s probably not the tooling given to you by a platform vendor. It’s also been around for a long time, so using Rust would mean a rewrite. Sometimes C is simply the choice. As for ideologically: Rust solves some pretty nasty programming issues, but sometimes I think it’s fans over-estimate the percentage of real world problems it actually solves while ignoring that Rust can be more expensive to write. (shrug) Sometimes there’s no such thing as a silver bullet.

    • hangukdise@lemmy.ml
      link
      fedilink
      arrow-up
      3
      ·
      10 months ago

      This is why the post and the thread are so funny (assuming people are being intentionally funny)

  • mindbleach
    link
    fedilink
    arrow-up
    19
    ·
    10 months ago

    Yesterday I tried using an honest-to-god pointer pointer pointer, and I think the compiler refused on moral grounds.

    • brakenium@lemm.ee
      link
      fedilink
      arrow-up
      1
      ·
      10 months ago

      That’s really cool! Rewriting sudo in Rust actually feels like a no brainer tbh