A ship carrying silverware has sailed (Blog.Posted_2024_01_01)
dpldocs.info
  • lysdexic@programming.dev
    ·
    10 months ago

    From the blog post, it sounds like the underlying motivation is not tied to technical aspects but control over the language. If I had invested any of my personal time onboarding onto D and migrated any of my projects to D, I would be concerned about the negative impact these political stunts have on the tech stack.

    • Corbin@programming.dev
      ·
      10 months ago

      Walter Bright has fairly odious political opinions; like many social conservatives these days, he likes to complain about wokeness and communism, and I would completely understand a community fork simply to remove his control over various parts of the D language.

      Also, just for a quick sanity-check: Which languages have you invested/migrated to, only to find that "political stunts" had a "negative impact" on your planned development?

      • lysdexic@programming.dev
        ·
        10 months ago

        Walter Bright has fairly odious political opinions;

        I fail to see the relevance of what personal opinions and beliefs he may or may not have. You're making it sound like the goal is not to improve a language ir fix issues, but to take something away from a person just because you disagree with their political opinions. That's hardly good use of anyone's time, and sounds terribly petty behavior.

        I wish I had that much free time to be able to waste it being so vindictive about such trifling issues.

        Which languages have you invested/migrated to, only to find that “political stunts” had a “negative impact” on your planned development?

        I don't waste my time with meaningless irrelevant stuff. Either a tech stack serves it's purpose, or it doesn't. I don't have enough free time to waste it trying to cancel others.

        • Corbin@programming.dev
          ·
          10 months ago

          PLDI is political; in general, any sort of language-design process is political. This is because language is expressive and also constraining, so the expressible and easy-to-express concepts in any language are its de facto default policies.

          Social conservatives tend to produce languages which are patrician and sadistic in their demands upon their users; C and Go, D, Hoon and Nock, Hare, and V all come to mind. They see these languages as offering "choice" and power to the end-user, and see languages which have redundant structures and safety, like Ada or Pascal, as "bondage & discipline".

          You're likely familiar with the frustration of using designed-by-committee languages, too; say, C++ or Python. These systems tend to evolve social conservatism as a way of preventing an explosion of features, as happened to Perl and is happening to Rust.

          Hopefully this is good food for thought. Your choice of language is not politically neutral, but occurs within a social context and has policy implications. Work at a PHP shop for a few years and you'll suddenly care quite a bit about which languages you use!

            • Corbin@programming.dev
              ·
              9 months ago

              In this case, we are discussing the leadership of a community project; the leaders are the ones who set policy for the project. In this sense, yeah, it's a political situation.

              Given your username, I'm a little surprised that you wouldn't recognize that the leaders of community projects are politically important...

  • QuadriLiteral@programming.dev
    ·
    10 months ago

    I read through the better part of a linked thread: https://forum.dlang.org/thread/ncbawciyybdksecurmsc@forum.dlang.org?page=1. And wow, as a C++ user, I'm not sure if I should feel blessed about how stable and backwards-compatible the language is, or that D users must be bonkers to put up with the breakages. Using C++ both professionally and for hobby projects, in the last 5 or so years I can remember encountering exactly 1 (gcc) compiler bug. There was a simple workaround + someone else had already reported it so with the next minor update the bug was fixed. And the code that triggered it was a nested CRTP spawn of hell so I didn't blame the compiler from borking on it in the first place, it would've been better for everyone had it never compiled :p

    Upgrading a major C++ compiler version was never free in my experience, but even when working in a codebase with ~2M LOC the upgrade (e.g. 14 -> 17) was something that could be prepared in a set of feature branches by one person over the span of one, maybe two weeks. That's for fixing compile errors, I don't remember if we had issues with runtime errors due to an upgrade, but if we did it must've been minor because I remember the transition to 17 was pretty smooth. Note that 14 -> 17 requires changing the requested C++ version for the project, which is different from upgrading the actual compiler, i.e. you can do the latter without the former and your code should not require any changes.

    • lysdexic@programming.dev
      ·
      10 months ago

      Upgrading a major C++ compiler version was never free in my experience, but even when working in a codebase with ~2M LOC the upgrade (e.g. 14 -> 17) was something that could be prepared in a set of feature branches by one person over the span of one, maybe two weeks.

      That greatly depends on your project, what dependencies it has, and what's involved in the migration. For example, I recall a previous project I worked on that experienced a considerable amount of non-trivial issues when upgrading to C++14 due to unforeseeable curve balls. One of them was caused by a third-party dependency toggling constexpr versions of its member functions only on C++14, which caused a bunch of obscure linker errors as old symbols were no longer available.