• Troy@lemmy.ca
    link
    fedilink
    arrow-up
    74
    arrow-down
    1
    ·
    2 months ago

    I’ve done a bit of C++ coding in my time. The feature list of the language is so long at this point that it is pretty much impossible for anyone new to learn C++ and grok the design decisions anymore. I don’t know if this is a good thing or not to keep adding and extending or whether C++ should sail into the sunset like Fortran and others before it.

    • Buttons@programming.dev
      link
      fedilink
      English
      arrow-up
      36
      ·
      2 months ago

      Fortran is still a good language for some purposes I think.

      And I feel the same way, C++ tries to solve the problem of having too many features by adding more features.

      • Troy@lemmy.ca
        link
        fedilink
        arrow-up
        14
        arrow-down
        1
        ·
        2 months ago

        Don’t get me wrong. There is still a time and a place for Fortran. And this will also likely always be the case for C++. But I’m not sure it is entirely wise to choose it if you’re creating a new project anymore.

        • Clay_pidgin@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          7
          arrow-down
          1
          ·
          2 months ago

          I’m barely competent at programming. What is the use case for Fortran, besides maintaining ancient code?

          • lad@programming.dev
            link
            fedilink
            English
            arrow-up
            14
            ·
            2 months ago

            A lot of computational heavy tasks for science were done in Fortran at least ten years ago (and I think still are). I was told that’s mainly because Fortran has a good deal of libraries for just that, and it was widely taught in academia so this is a common ground between the older and newer generations.

            I think it may be gradually superseded by Python, but I don’t know if it is

            • Troy@lemmy.ca
              link
              fedilink
              arrow-up
              10
              ·
              2 months ago

              A lot of the underlying libraries in python are actually written in Fortran (or were when they were conceived, and the Fortran components later replaced). Numpy, for example, was originally pretty much a wrapper on top of BLAS and LAPACK.

        • Valmond@lemmy.world
          link
          fedilink
          arrow-up
          5
          ·
          2 months ago

          You might be right, but I have heard that song a lot of times, python, java, ml, pascal, obscure webdev.languages, AI will do it, typescript, etc etc etc

          I’d go with a better python than rust, you can put that “once in a lifetime asm optimized memsafe multi threaded code” in a package and just use it from python. But python has GIL and you can’t just remove it so who knows what will be the next shiny thing? Probably several languages, like for easy peasy stuff up to hardcore multi threaded memory safe stuff. Gotta push us oldtimers out in some way, right :-) ?

    • tal@lemmy.today
      link
      fedilink
      English
      arrow-up
      13
      ·
      2 months ago

      The feature list of the language is so long at this point that it is pretty much impossible for anyone new to learn C++ and grok the design decisions anymore.

      Even if it is possible, it’s a high bar. The height of that bar matters in bringing new people in.

      I have seen decades of would-be “C++ killers” come and go. I think that in the end, it is C++ that kills C++. The language has just become unusably large. And that’s one thing that cannot be fixed by extending the language.

      • MajorHavoc@programming.dev
        link
        fedilink
        arrow-up
        6
        ·
        edit-2
        2 months ago

        I have seen decades of would-be “C++ killers” come and go. I think that in the end, it is C++ that kills C++.

        I think you’re right.

        I am, admittedly, a card carrying member of the C++ curmudgeon club. But I would gladly gravitate to a sexy new C++ subset for my projects, if one gains some momentum.

        I do a lot with goLang, right now, instead.

        But I would adore joining with a community effort to choose reasonable safe default C++ libraries for a bunch of use cases, if one gained the traction to cover my own use cases.

    • thingsiplay@beehaw.org
      link
      fedilink
      arrow-up
      7
      arrow-down
      2
      ·
      2 months ago

      C++ innovates often first and adapts it into mainstream. And its kind of a swiss-army knife. You don’t need to use and learn everything, just pick what you need. Unless you need to get into an old existing code base…

      Just an idea: The language could be divided into multiple standard levels, where each level has more features and functionality. It would be essentially a “restricted”, “standard” and “full” version of the language, where full is basically what it is now and the others are constrained versions with less functionality (no multiple inheritance and what not rules). But at this point, if you don’t use the language in its full, why bother with it at all? Just thinking a bit…

      • lad@programming.dev
        link
        fedilink
        English
        arrow-up
        8
        ·
        2 months ago

        You don’t need to use and learn everything, just pick what you need.

        I used to think the same, but now I think you should at least skim through everything. Reason being otherwise you may reinvent the wheel a lot, and there are many use-cases where you really don’t want to do that (but C++ makes it so easy, I was constantly tempted to just do what I want and not look for it being already available)

        • Troy@lemmy.ca
          link
          fedilink
          arrow-up
          6
          ·
          2 months ago

          This gets even more complex if you’re using a toolkit of some sort. C++ has a batteries-included way of doing something, then STL has another, and Qt yet another… Etc.