• AdmiralShat@programming.dev
    link
    fedilink
    English
    arrow-up
    10
    ·
    edit-2
    1 year ago

    If you don’t add comments, even rudimentary ones, or you don’t use a naming convention that accurately describes the variables or the functions, you’re a bad programmer. It doesn’t matter if you know what it does now, just wait until you need to know what it does in 6 months and you have to stop what you’re doing an decipher it.

    • fkn@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      Self documenting code is infinitely more valuable than comments because then code spreads with it’s use, whereas the comments stay behind.

      I got roasted at my company when I first joined because my naming conventions are a little extra. That lasted for about 2 months before people started to see the difference in legibility as the code started to change.

      One of the things I tell my juniors is, “this isn’t the 80s. There isn’t an 80 character line limit. The computer doesn’t benefit from your short variable names. I should be able to read most lines of code as a single non-compound sentence in English with only minor tweaks and the English sentence should be what is happening in most of those lines of code.”

  • argv_minus_one@beehaw.org
    link
    fedilink
    arrow-up
    10
    ·
    1 year ago

    Dynamic typing is insane. You have to keep track of the type of absolutely everything, in your head. It’s like the assembly of type systems, except it makes your program slower instead of faster.

    • Cratermaker@discuss.tchncs.de
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      Nothing like trying to make sense of code you come across and all the function parameters have unhelpful names, are not primitive types, and have no type information whatsoever. Then you get to crawl through the entire thing to make sense of it.

    • lysdexic@programming.dev
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 year ago

      Python is only good for short programs

      Was Python designed with enterprise applications in mind?

      It sounds like some developers have a Python hammer and they can only envision using that hammer to drive any kind of nail, no matter how poorly.

      • witx@lemmy.sdf.org
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        1 year ago

        I mean, it’s still a very nice language. I can see someone, marveled by that, would endeavor to make bigger things with it. I just don’t feel it scales that well.

        • lysdexic@programming.dev
          link
          fedilink
          English
          arrow-up
          0
          ·
          1 year ago

          I agree. The GIL and packaging woes are a good indication that it’s range of applications isn’t as extensive as other tech stacks.

          • scubbo@lemmy.ml
            link
            fedilink
            arrow-up
            0
            ·
            1 year ago

            packaging woes

            My own hot take is that I hear this criticism of Python a lot, but have never had anyone actually back it up when I ask for more details. And I will be very surprised to hear that it’s a worse situation than Java/TypeScript’s.

            • r1veRRR@feddit.de
              link
              fedilink
              arrow-up
              0
              ·
              1 year ago

              We used to have a Python guy at my work. For a lot of LITTLE ETL stuff he created Python projects. In two projects I’ve had to fix up now, he used different tooling. Both those toolings have failed me (Poetry, Conda). I ended up using our CI/CD pipeline code to run my local stuff, because I could not get those things to work.

              For comparison, it took me roughly zero seconds to start working on an old Go project.

              Python was built in an era where space was expensive and it was only used for small, universal scripts. In that context, having all packages be “system-wide” made sense. All the virtual env shenanigans won’t ever fix that.

              • scubbo@lemmy.ml
                link
                fedilink
                arrow-up
                1
                ·
                1 year ago

                In that context, having all packages be “system-wide” made sense. All the virtual env shenanigans won’t ever fix that.

                Sorry, but you’ll need to explain this a little bit more to me. That’s precisely what virtual env shenanigans do - make it so that your environment isn’t referencing the system-wide packages. I can totally see that it’s a problem if your virtual env tooling fails to work as expected and you can’t activate your environment (FWIW, simply old python -m venv venv; source venv/bin/activate has never let me down in ~10 years of professional programming, but I do believe you when you say that Poetry and Conda have broken on you); but assuming that the tools work, the problem you’ve described completely goes away.

    • NBJack@reddthat.com
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      Python should not be used for production environments, or anything facing the user directly. You are only inviting pain and suffering.

      • witx@lemmy.sdf.org
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        I don’t mean it doesn’t work for larger projects. Just that it’s a pain to understand other’s code when you have almost no type information, making it, to me, a no go for that

        • fhoekstra@programming.dev
          link
          fedilink
          arrow-up
          0
          ·
          edit-2
          1 year ago

          Larger projects in Python (like homeassistant) tend to use type-hints and enforce them through linters. Essentially, these linters (with a well-setup IDE) turn programming in large Python projects into a very similar experience to programming a statically typed language, except that Python does not need to be compiled (and type-checked) to run it. So you can still run it before you have satisfied the linters, you just can’t commit or push or whatever (depending on project setup).

          And yes, these linters and the Python type system are obviously not as good as something like a Go or Rust compiler. But then again, Python is a generalist language: it can do everything, but excels at nothing.

          • nous@programming.dev
            link
            fedilink
            English
            arrow-up
            2
            ·
            1 year ago

            Go and rust are also generalist languages. Basically all main stream programming languages are and are equally as powerful (in terms of what they can do, rather than performance) as each other as they are all Turing complete. So you can emulate c in python or python in c for instance).

            Anything you can do in python you can do in basically any other mainstream language. Python is better at some niches than others just like all other languages are with their own niches - and all can be used generally for anything. Python has a lot of libraries that can make it easier to do a large range of things than a lot of other languages - but really so do quite a few of the popular languages these days.

          • witx@lemmy.sdf.org
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            That’s actually a good idea, enforcing it. Still, do these linters protect against misuse? E.g I have an int but place a string on it somewhere?

            • sirdorius@programming.dev
              link
              fedilink
              arrow-up
              1
              ·
              edit-2
              1 year ago

              Yes, in a good dev workflow mypy errors will not pass basic CI tests to get merged. Types are not really a problem in modern Python workflows, you can basically have a better type checker than Java out of the box (which can be improved with static analysis tools). The biggest problem with Python remains performance.

  • Vince@feddit.de
    link
    fedilink
    arrow-up
    6
    ·
    edit-2
    1 year ago

    Not sure if these are hot takes:

    • Difficult to test == poorly designed
    • Code review is overrated and often poorly executed, most things should be checked automatically (review should still be done though)
    • Which programming language doesn’t matter (within reason), while amount of programming languages matters a lot
    • Xylight (Photon dev)@lemmy.xylight.dev
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      I’ve been wanting to make my applications easier to test. The issue is, I don’t know what to test. Often my issues are so trivial I notice them immediately.

      What are some examples of common things in, let’s say a web server, that could be unit tested?

      • Carol2852@discuss.tchncs.de
        link
        fedilink
        arrow-up
        1
        ·
        5 months ago

        Sure try to replace the one or two people that hold the whole team together. I’ve seen it a couple times, a good team disintegrates right after one or two key people leave.

        Also, if you replace half the team, prepare for some major learning time whenever the next change is being made. Or after the next deployment. 🤷‍♂️

  • Elderos@lemmings.world
    link
    fedilink
    arrow-up
    4
    ·
    edit-2
    1 year ago

    The best codebase I have ever seen and collaborated on was also boring as fuck.

    • Small, immutable modules.
    • Every new features was coded by extension (the ‘o’ in S.O.L.I.D)
    • All dependencies were resolved by injection.
    • All the application life cycle was managed by configurable scopes.
    • There was absolutely no boiler plate except for the initial injectors.
    • All of the tests were brain-dead and took very minimal effort to write. Tests served both as documentation and specification for modules.
    • “Refactoring” was as simple as changing a constructor or a configuration file.
    • All the input/output of the modules were configurable streams.

    There is more to it, but basically, it was a very strict codebase, and it used a lot of opinionated libraries. Not an easy codebase to understand if you’re a newbie, but it was absolutely brain dead to maintain and extend on.

    Coding actually took very little time of our day, most of it consisted of researching the best tech or what to add next. I think the codebase was objectively strictly better than all other similar software I’ve seen and worked on. We joked A LOT when it came time to change something in the app pretending it would take weeks and many 8 pointers, then we’d casually make the change while joking about it.

    It might sound mythical and bullshity, and it wasn’t perfect, it should be said that dependency injection often come in the form of highly opinionated frameworks, but it really felt like what software development should be. It really felt like engineering, boring and predictable, every PO dreams.

    That being said, I given up trying to convince people that having life-cycle logic are over the place and fetching dependencies left and right always lead to chaos. Unfortunately I cannot really tell you guys what the software was about because I am not allowed to, but there was a lot of moving parts (hence why we decided to go with this approach). I will also reiterate that it was boring as fuck. If anything, my hot take would be that most programmers are subconsciously lying to themselves, and prefer to code whatever it is they like, instead of what the codebase need, and using whatever tool they like, instead of the tools the project and the team need. Programming like and engineer is not “fun”, programming like a cowboy and ignoring the tests is a whole lot of fun.

  • MrTallyman@programming.dev
    link
    fedilink
    arrow-up
    4
    ·
    1 year ago

    My take is that no matter which language you are using, and no matter the field you work in, you will always have something to learn.

    After 4 years of professional development, I rated my knowledge of C++ at 7/10. After 8 years, I rated it 4/10. After 15 years, I can confidently say 6.5/10.

    • BaskinRobbins@sh.itjust.works
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      Amen. I once had an interview where they asked what my skill is with .net on a scale of 1 - 10. I answered 6.5 even though at the time I had been doing it for 7 years. They looked annoyed and said they were looking for someone who was a 10. I countered with nobody is a 10, not them or even the people working on the framework itself. I didn’t pass the interview and I think this question was why.

  • asyncrosaurus@programming.dev
    link
    fedilink
    arrow-up
    4
    ·
    1 year ago

    SPAs are mostly garbage, and the internet has been irreparably damaged by lazy devs chasing trends just to building simple sites with overly complicated fe frameworks.

    90% of the internet actually should just be rendered server side with a bit of js for interactivity. JQuery was fine at the time, Javascript is better now and Alpinejs is actually awesome. Nowadays, REST w/HTMX and HATEOAS is the most productive, painless and enjoyable web development can get. Minimal dependencies, tiny file sizes, fast and simple.

    Unless your web site needs to work offline (it probably doesn’t), or it has to manage client state for dozen/hundreds of data points (e.g. Google Maps), you don’t need a SPA. If your site only needs to track minimal state, just use a good SSR web framework (Rails, asp.net, Django, whatever).

    • GaveUp [she/her]@hexbear.net
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      Preferring server side rendering is an interesting topic

      Client side renderering is currently the preference because the company gets to offload the compute costs of their servers onto the clients’ devices

      As long as every website has a profit motive, even if it’s just a single person trying to save some money on their AWS bills, server side rendering will never become the norm

    • railsdev@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      I loathe JavaScript heavy websites, especially when used for forms. Don’t break autofill and copy/paste. And don’t complain about the format just because I pasted! Seriously, why is pasting text in the correct format triggering some JavaScript framework? It all seriously gets to me.

      With that said, I really like Hotwire. HTML over the wire is bliss. Stimulus is perfect for sprinkling non-invasive JavaScript throughout an application.

    • nayminlwin@lemmy.ml
      link
      fedilink
      arrow-up
      0
      ·
      1 year ago

      I’m still hoping for browsers to become some kind of open standard application environments and web apps to become actual apps running on this environment.

      • icesentry@lemmy.ca
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        How are browser not that already? What’s missing?

        They are an open standard and used to make many thousands of apps.

  • r1veRRR@feddit.de
    link
    fedilink
    arrow-up
    4
    ·
    1 year ago

    Compiler checked typing is strictly superior to dynamic typing. Any criticism of it is either ignorance, only applicable to older languages or a temporarily missing feature from the current languages.

    Using dynamic languages is understandable for a lot of language “external” reasons, just that I really feel like there’s no good argument for it.

    • mindbleach@sh.itjust.works
      link
      fedilink
      arrow-up
      0
      ·
      1 year ago

      Tabs are literally designed for aligned indentation, and they’re configurable for clientside viewing. There is no excuse for spaces. I don’t care if your goddang function arguments line up once they spill out onto another line. You’ve got deeper problems.

      • xigoi@lemmy.sdf.org
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        Tabs are designed for tabulation (hence the name), not indentation. The side effect is that a tab’s length changes based on its position in a line, which is terrible for programming. If you use tabs in the Python REPL, it looks like this:

        >>> def frobnicate_all(arr):
        >>>     for item in arr:
        >>>             frobnicate(item)
        
          • xigoi@lemmy.sdf.org
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            A newline is the separator between lines, so the concept of length doesn’t make sense for it.

                • mindbleach@sh.itjust.works
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  1 year ago

                  Stops are indentation.

                  They’re what you indent… to.

                  Tab goes to the next stop, the same way newline goes to the next line. Exactly the same way. If you write more text before the next line, the amount of whitespace shrinks. That doesn’t mean the “length” of a newline changes. It always goes one line.

                  A tab always goes one stop.

        • spartanatreyu@programming.dev
          link
          fedilink
          arrow-up
          0
          ·
          1 year ago

          a tab’s length changes based on its position in a line

          What does this even mean? A tab is a tab.

          Tab’s don’t have multiple lengths inside a file, they all have the same length.

          That’s the point of tabs.

  • million@lemmy.world
    link
    fedilink
    English
    arrow-up
    3
    ·
    edit-2
    1 year ago

    Refactoring is something that should be constantly done in a code base, for every story. As soon as people get scared about changing things the codebase is on the road to being legacy.

      • FlumPHP@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        Today I removed code from a codebase that was added in 2021 and never ever used. Sadly, some people are as content to litter in their repo as they are in the woods.

  • hansl@lemmy.ml
    link
    fedilink
    arrow-up
    3
    ·
    1 year ago

    Hot take: people who don’t like code reviews have never been part of a good code review culture.