• adminofoz@lemmy.cafe
        link
        fedilink
        English
        arrow-up
        1
        ·
        16 days ago

        Portability, abstraction and inheritance are fundamental concepts, not buzzwords. Strongly typed languages can and does have all of these things.

    • jjjalljs@ttrpg.network
      link
      fedilink
      arrow-up
      1
      ·
      21 days ago

      Oh that’s a neat library. Type annotations in python are really nice, and you don’t have to add tooling like when you switch from JS to TS.

  • BenLeMan@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    21 days ago

    God, that reminds me of the debate on XML that I had with a developer about fifteen years ago.

    Both our companies were working for a client who needed to publish product catalogues in several languages twice a year.

    They had implemented a sort of Content Management System which they used with a plugin to feed data into Quark Xpress files as well as their website, IIRC. Cross-media publishing, essentially, and they had their own little set of format instructions to make words appear in bold, different colors, etc.

    Since my company was tasked with translating the text into various languages, I suggested they come up with a way to store their data as XML. The standard tools in the translation industry can be easily customized to work with that, and XML would be a good way to future-proof their software. After a lot of delaying, grumbling, and ho-hum, they agreed to implement this plan.

    Lo and behold, when the first meeting on the new XML format came around they showed it to me for the first time and… everything was in CDATA sections. Entire paragraphs of text with proprietary formatting instructions. 😐

    When I tried to explain, very politely, and very patiently, that this was not going to work, the lead dev started insulting me. I swear to God, I’ve never been this close to punching someone in the face at a business meeting. 🤬

    Thankfully, the client understood the issue and we eventually got an XML-based data exchange going. It is probably still in use today.

        • Ephera@lemmy.ml
          link
          fedilink
          English
          arrow-up
          0
          ·
          21 days ago

          Groovy will automatically convert integers into objects, as it sees fit. And one such case is when you assign null to an integer.

          There’s some more languages, which try to treat primitive types like objects, to make them more consistently usable. As I understand, nullability is a big part of the reason why it can’t be solved with syntactic sugar, so presumably this would be possible in all those languages.
          If I’m not mistaken, Ruby is another one of those languages.

          • JackbyDev@programming.dev
            link
            fedilink
            English
            arrow-up
            0
            ·
            21 days ago

            Groovy is pretty wild. It’s like, honey, you need me to make this a BigInteger for you? I got you honey, don’t even worry about it.

            • Ephera@lemmy.ml
              link
              fedilink
              English
              arrow-up
              1
              ·
              21 days ago

              Yeah, I kind of respect the stance, because it knows what it wants to be, but I also wrap number types into a separate data type to document that maybe you shouldn’t multiply a port number by the wheel count and pass that into the temperature parameter, because I want more fine-grained typing, not one-size-fits-all.

              • luciferofastora@feddit.org
                link
                fedilink
                arrow-up
                2
                ·
                edit-2
                5 days ago

                I think that somewhat reflects the “parse, don’t validate” advice I found somewhere. I’ll look for the link and edit if I find it (edit: I did!) but the idea is something like “when a value first enters your code, parse it into a type / struct the rest of your code proceeds to use”. That way, you check “does this make sense as a port number?” exactly once, throw it right back at the source if it doesn’t, put a “yep, this fits” stamp on it if it does and never worry about it again, thus saving repetitive boilerplate code.

                • Ephera@lemmy.ml
                  link
                  fedilink
                  English
                  arrow-up
                  1
                  ·
                  5 days ago

                  Ah, yeah, very familiar with that article. 🙃

                  It’s definitely part of the reason why I like these really narrow types. But the other big reason is that your internal APIs start to look like this:

                  Shape sorter game for babies

                  It just makes it almost impossible to pass the wrong value into a parameter. You don’t need to wonder, whether you should pass your port variable into a parameter called bind_port, if you introduced separate types BindPort and RemotePort for them.

                  Of course, this is a somewhat extreme example. It’s up to you to decide, whether you’re likely to encounter multiple values of the same type and whether it’s therefore helpful to make it impossible to confuse them.

    • unalivejoy@lemmy.zip
      link
      fedilink
      arrow-up
      1
      ·
      21 days ago

      Me: Puts a boolean into sqlite

      Me: Asks for that boolean

      SQLite: “Here’s that int you asked for”