30 comments

  • 0x445442 2 days ago

    Weak/Dynamic vs. Strong/Static typing.

    I used to complain about the latter then I grew up.

    • austin-cheney an hour ago

      I am a convert as well. I wouldn’t say that I gave or grew up but that I was arguing from ignorance. On a group project someone proposed trying TypeScript and I jumped in and completely fell in love.

      My only arguments against were slower development due to an imposed build/compile step and that error reports would not reflect the source code.

    • chistev a day ago

      What were your reasons then for complaining

      • 0x445442 a day ago

        Oh, the typical ones, like all this type checking is stifling and slowing me down.

        • matt_s 20 hours ago

          If you’re checking and validating inputs into a method and you’re writing web applications where everything is text over HTTP, having type checking notations, etc. are a bit overkill.

          • mattmanser 18 hours ago

            If you use a staticly typed language it does all that for you automatically.

        • cdaringe 20 hours ago

          Don’t beat yourself up, we all had that phase!

  • cdaringe 20 hours ago

    Rust v Go.

    I was firmly in the Rust only camp, specifically in the business environment. I’m still strongly biased towards it, but I appreciate the nuance and needs for some teams and needs.

    Writing this prompted me to check my https://cdaringe.github.io/programming-language-selector/, and it’s clear go’s dev ux scores are relatively underrated

    • meowface 18 hours ago

      I was also a major Go skeptic and now use it very frequently. It seems bad on paper but it's quite good in practice.

  • jf22 21 hours ago

    Fixing tech debt is rarely worth the effort.

  • drewlander a day ago

    I used to be a vim snob and thought everyone should use what I use. I am now an Emacs lover and believe everyone should use what works for them. I grew up!

  • geophph 17 hours ago

    I no longer care about tabs vs. spaces, just that each further indentation follows the Fibonacci sequence.

  • oumua_don17 16 hours ago

    - Vim vs Emacs

    - Mac HW vs Linux OS (I really want a combo else give me Snow Leopard)

    - Staying put vs Leaving/Sabbatical (AI nonsense is boring/burning me out)

  • rgreekguy a day ago

    I was Emacs, got tired of some stupid things, Vim or other things now. Every other thing has some Vim mode thingy anyway... (Which I always used, regardless.)

    Same stupid reasons make me pretty much drop Linux. I have it on Steam Deck, but that's all. MacBook, and Haiku for cool stuff. (Or for worky stuff, because I hate MacOS.)

  • aristofun a day ago

    Scala is not that bad. It’s still bad and overkill for most people and most projects, but not that bad for some

  • meowface 2 days ago

    Font ligatures. Used to hate them with a burning passion. Now they're table stakes for trying different fonts.

    • jjgreen 2 days ago

      Change of heart due to the æsthetics?

      • stop50 a day ago

        for me it helps especially with comparisons. Some operators are also better looking than their non ligature equivalents.

      • meowface a day ago

        Basically, yes.

  • al_borland a day ago

    I moved from tabs to spaces.

  • incomingpain a day ago

    >Vim vs. Emacs,

    Nano has always won. Yes, vim is everywhere. I dont fathom why emacs exists.

    >tabs vs. spaces

    tabs make much more sense. python should fix this mistake. I guess my IDE fixes it for me?

    >Mac vs. Linux,

    100% linux; i tend to stick to the debian field, but certainly never actual debian. I really need to try alma; but dnf/yum/rpm and what the hell happened to centos? fedora is a mess like it always was. KDE? really we havent found one of the dozens of better DE?

    >static vs. dynamic typing

    Dynamic, ill never ever switch to a language that's static. I started in C++, never ever going back.

    >JSON vs. YAML

    JSON all the way.

    • chistev a day ago

      Why dynamic over static?

      • dcminter a day ago

        Speaking for myself I'm static or death, BUT I can see how one might come away scarred from C++ and conflate static with the wild degree of ceremony and clunky tooling.

        Nowadays the better static languages do a lot of type infererence so that a lot of that ceremony is pushed aside.

        I recently did some semi-serious python work and I see some of the appeal; I definitely missed mandatory type declarations at the function argument level but barely if at all within functions.

        There's a great Steve Yegge post about this topic of static/dynamic alliegence (via someone's gist because Google can't run a service long term for love or money): https://gist.github.com/cornchz/3313150

      • matt_s 20 hours ago

        My rationale given on another comment is when writing web apps, everything comes in as text so you have to parse/convert and validate parameters anyhow.

        Dynamic makes a lot of sense for web programming. Static should definitely be used in high risk software where its life and death, medical devices, rockets, nuclear plants, etc.

        • mattmanser 18 hours ago

          As I said on your other comment, when you're in a statically typed language they do that for you automatically.

          It appears that you might not have even even tried a statically typed language yet.

      • incomingpain a day ago

        >Why dynamic over static?

        I started my coding career in C++. I know static well enough for my lifetime. It makes sense that if you're in the 1980s and choose static as the designer of the language.

        But now the choice is available, why would you want to declare the variable. In my code I want to write "bob =" and the language figures that all out. If I feed a string into it or a number, why does it matter?

        It saves me oodles of time not having to be concerned at all about that.

        It's also very interesting in functions. Yes, I have been using the typing in python. def process_bob(self, bob: int) -> bool:

        Technically i can shove whatever i want into that arg of bob. Imagine the function was a network protocol. v 1.1 did X, v1.2 did X and Y. That int becomes perhaps a list and that's totally fine. Very reusable, because iterating, process_bob can just become if bob == int: elif bob == list.

        Why would I want my programming language to make things harder on myself for literally no gain?

    • msgodel 21 hours ago

      >tabs make much more sense. python should fix this mistake. I guess my IDE fixes it for me?

      I think tabs make sense when you're by yourself and spaces make sense when you're working with others.

      • Jtsummers 14 hours ago

        It varies so much by language. In C, Go, C++, etc. I'm inclining, these days, towards tabs. You can always adjust the tab width for display, but you generally end up with a clear block structure since they're statement and block-oriented languages (syntactically):

          func foo(...) ... {
              if bar > 10 {
                  if baz < 100 {
                      ...
                  }
              }
          }
        
        But then I go back to Lisp and would absolutely hate it, without a formatter to help, because for readability you sometimes want the equivalent of the above but other times not:

          (defun greet (name)
            (format t "Hello ~S~%" name))
        
        Two spaces, could be a tab and a small width, but you also see this a lot (imagine a, b, and c being long enough to justify the line breaks):

          (+ a
             (truncate b
                       c))
        
        You want a variable amount of whitespace on each of these lines for alignment. Tabs won't do since you can't guarantee the tab width. Once you've chosen to use spaces for some lines, you're forced to do it for the rest or you mandate that tab widths are specifically equivalent to N spaces, which defeats the purpose of using them in the first place.

        So it ultimately comes down to the language and what makes it more or less readable.