• lad@programming.devEnglish
        17·
        5 days ago

        I think, the point is Haskell is more CS theoretical than practical language and anyone who uses it (or any other FP) has never written a single line of production code (the last statement is even in the meme)

    • Rusty Shackleford@programming.devEnglish
      8·
      5 days ago

      Personally, I love that series. I guess whoever made this meme thinks people who watch the show are trying to implement their code examples in production.

    • yogurtwrong@lemmy.world
      8·
      4 days ago

      Imperative stoneagers getting an old MacBook from somewhere and going “huh, I guess its UNIX” is probably true though

      • dantel@programming.dev
        2·
        3 days ago

        The imperative stoneager feels like the most favored one, there are no real negatives listed there. All that’s listed are things they usually pride themselves on.

      • ulterno@programming.devEnglish
        0·
        4 days ago

        Yeah, that Mac offended me.
        My imperative programming journey was a few months on a handed down P2 followed by 3 years of pen and paper.

  • palordrolap@fedia.io
    21·
    5 days ago

    history | grep -E '(sed|grep|awk|perl)' | wc -l 107

    Dang. That’s out of 1000. I need to up my game. Also three of those seds are part of something with a -basedir and don’t count.

    So yeah, about 10% of my commands are iterating shell pipe things for poops and giggles, I guess.

    … and this got me going down the rabbit hole of writing a filter for my history to pull out the first command on the line. This is non-trivial because of potential preceding variable assignments. Most used commands are currently apt and man and ls. I think apt is a Spiders Georg situation because the system is fairly fresh and I keep finding things that I haven’t installed yet. Also I went through a patch of trying to parse its output.

    … oh, er… unga bunga.

    • flying_sheep@lemmy.ml
      1·
      4 days ago

      I just use nushell’s builtins instead of wrangling with IFS and bash idiosyncrasies. It’s been years since I’ve corrupted data by parsing text wrong.

      But even if someone doesn’t want that: apart from using it in legacy scripts, grep is just a strictly less useful ripgrep these days, no?

  • potatoguy@lemmy.eco.br
    24·
    5 days ago

    Hear me out:

    Mixing OOP and functional code to abstract the shit out of everything making 5k loc in around 500 loc in java. You can do magic using this trick.

    • passepartout@feddit.orgOP
      25·
      5 days ago

      Functional programming in Java is kind of an afterthought and it shows. That’s one of the reasons why Scala was created!

      • Custodian6718@programming.dev
        3·
        3 days ago

        I mean Yeah it is an afterthought in the Sense of that Java was Originally an oop Language but fp in Java was added on very sensibly imo. I use functional Programming in Java a Lot and try to make Everything immutable where I can and honestly coding like that feels clean and very practical.

        • marcos@lemmy.world
          132·
          5 days ago

          Just let C++ die already, and stop pretending it’s a reasonable thing to compare other languages with.

          If you can’t do it in C, you are better in Java, Python, Haskell, whatever.

      • potatoguy@lemmy.eco.br
        10·
        5 days ago

        Yeah, Scala is the GOAT, but while I can’t use, why not final everything, use 300 streams and pass Suppliers around?

        (I’m building a lot of libraries at work)

        • silasmariner@programming.dev
          4·
          5 days ago

          Do people still use vavr? When I wasn’t allowed to use scala that made up for a fair few shortcomings but it’s probably less relevant than it used to be

          • potatoguy@lemmy.eco.br
            4·
            5 days ago

            I didn’t know about vavr, I think a lot of things from it were added since Java 17, but this Try<T> seems cool.

            Edit: Either would be nice too. I’m going to test some of those things, thanks for the recommendation!

            • silasmariner@programming.dev
              4·
              5 days ago

              Very pleased to have been of help! I love scala but Java really isn’t too bad (streams API is fine except that you need to explicitly move in and out, rather than getting to do the cool scala thing of just using methods in the phenomenal collections library) and I don’t like dunking on it, but it really does need a few helper libs. Tuples, either and try I think vavr has. Java seems to have covered most other stuff now. But been a half decade since I’ve written more than 10 lines at a time so hasn’t come up for a while. Sorry. Reminiscing. Sunday night blues.

  • andioop@programming.devEnglish
    20·
    5 days ago

    OOP boilerplater except for the Windows bit; trying to slowly move off proprietary software and choose open source when I can

  • freohr@lemmy.world
    13·
    4 days ago

    Uses neovim with gruvbox theme on arch

    Damn, why are you calling me out personally? Though I use it to write python scripts and LaTeX, not rust…

  • 9point6@lemmy.world
    231·
    5 days ago

    Oh, I guess I’m a stoneager with a penchant for functional elitism then.

    Though I will admit OOP is valid for involved data modelling, everything else should be functional though.

    I’ve also trained myself out of most short variable names for maintainability reasons

    • masterspace@lemmy.caEnglish
      18·
      5 days ago

      Outside of the for loop counters i and j, short variable names are awful. Coming back to old code written with abr var nams is like talking to someone in the military who just constantly throws out jargon and acronyms that they know you don’t know.

      But so are Java style ObserverFactoryManagerTemplateMachinistTemplater names.

      There’s a sweet middle ground of short, but actually descriptive name. Sometimes it’s not possible but that’s usually a code organization / language / framework smell.

      Too short variable names is usually a sign that you need to use a proper ide, with auto complete, or that you need to use a proper build process that will minify your code after the fact.

      Too long names are usually a sign that your module of code (function, class, namespace, etc) is too large, or that your language/framework naming conventions are too strict, or the language doesn’t encapsulate scope properly.

      • red_tomato@lemmy.world
        111·
        5 days ago

        Outside of the for loop counters i and j, short variable names are awful.

        I’ve started to prefer writing it out as ”index” or ”iteration” even in for loop counters. It’s easier to read, and not much harder to type.

        • FishFace@piefed.socialEnglish
          71·
          5 days ago

          Keeping things that can be on one line to one line is a good reason to use short variable names where it won’t be confusing. Writing “iteration” sounds absolutely perverse!

          The thing is, everyone understands i and j. The reason calling variables hcv or iid is dumb is because noone knows what that means - quite a different situation.

          • red_tomato@lemmy.world
            5·
            5 days ago

            Writing “iteration” sounds absolutely perverse!

            I like it to make it clear when the for loop is about iterating lists and when it’s not. For example, the iterations in Monte Carlo algorithms doesn’t correspond to items in a list.

            • silasmariner@programming.dev
              2·
              5 days ago

              I is a vowel too but you sure can!

              Edit: also I noticed you dropped one ‘y’ but not the others. Is this an accident or some subtlety to do with y’s ‘semi-vowel’ status? To be discussed.

              • lad@programming.devEnglish
                2·
                4 days ago

                I had to leave most of first letters, and sometimes if all vowels are removed there’s nothing left

                But yeah, we need a committee and come up with a standard for that

        • masterspace@lemmy.caEnglish
          3·
          5 days ago

          I typically do too, or userIndex or something for nested loops, but I will accept i and j for the first two levels of nesting when reviewing a PR because they’re such a convention. I wouldn’t accept variable names like that anywhere else though and try and avoid them myself.

      • marcos@lemmy.world
        7·
        5 days ago

        The length of variable and function names should be proportional to the size of the code that can potentially call them. And preferably segmented in namespaces, explicit modules, or something like that.

    • Valmond@lemmy.dbzer0.com
      5·
      5 days ago

      Yeah, it’s wild people “don’t like OOP” 100%, it’s like most good things, don’t put it where it shouldn’t be.

      • ozymandias117@lemmy.worldEnglish
        3·
        4 days ago

        If you’re really going down that route, you need to also remember that even the C programmed Linux Kernel is highly OOP

  • dreadbeef@lemmy.dbzer0.comEnglish
    7·
    4 days ago

    ocaml and haskell and erlang power like… a shitton of industry production code. If erlang software disappeared, internet dies for a bit until people replace all the broken routers.

    • Kache@lemmy.zip
      2·
      4 days ago

      Isn’t functional stuff closely related to type theory & type systems in all langs? In that sense, it’s prevented whole classes of bugs from ever getting to prod in the first place.

      Responsible for 0% of code in production

      Best code is no code at all

      • Crazazy [hey hi! :D]@feddit.nl
        1·
        3 days ago

        Depends very much on the language you’re using. Haskell and ocaml do fall into that category, whereas erlang and scheme are also functional languages with fairly weak typing.

        If there is one thing that connects functional programming as a whole, it is that in FP, program flow is managed mostly through function application, instead of if statements and for/while loops.