5 ms·

>Compiler makers must hate us developers I think that C or C++ were just written by people who never gave a single damn about UX until competition appeared and

>Compiler makers must hate us developers I think that C or C++ were just written by people who never gave a single damn about UX until competition appeared and then things started improving,

marginalia_nu 4y ago
The abysmal compile time for these languages may also have encouraged this fairly bare-bones UX philosophy.
- tester756 4y ago
  >fairly bare-bones UX philosophy. What do you mean?
marcosdumay 4y ago
C was created by people that didn't have any extra resource to spend on UX. Just another day there was an article here about emulating the computer C was written for in a RP2040 (the Raspbery Pi "competitor" for the Arduino), and yes, it has plenty of space for that. C++ had more of a choice about it.
- tester756 4y ago
  >C was created by people that didn't have any extra resource to spend on UX How many years have passed since that time?
  - marcosdumay 4y ago
    Oh, enough to improve things several times (to answer, 5 decades). People did some improvements, but clearly didn't keep-up with the times (and degraded some things too, UB being the elephant in the room). But large things almost never keep-up with the times.
    - nuancebydefault 4y ago
      Something else must be playing here and I'm pretty sure most of the annoyences did not get solved, mostly because of backward compatability guarantees. It is really a pitty that c/c++ did not get pushed away by competing languages that do/did not have so much of a legacy of sub-par development tooling. Friendlier and better designed languages like C#, Rust or even Python still seem to have some disadvantages that prevented that from happening.
      - deleted 4y ago
        [deleted]
      - JonChesterfield 4y ago
        C++ essentially killed C. Counterexamples exist but they're hard to find and sometimes involve there being no C++ compiler on the target. D didn't replace C++. I wonder if that was related to the single proprietary implementation. The language seems more sensible to me. Rust is aimed at replacing C and C++. There are others in the same field in various stages of development. Zig and carbon come to mind. There's an uphill battle where lots of existing code is in C++ and people fear changing it. C was partly dismantled by C++ compilers promising better error diagnostics and being able to compile most C with minimal patching. I personally think the end is in sight for C++ but the consensus seems to be it'll live forever.
        WalterBright 4y ago
        D is 100% Boost licensed.
        JonChesterfield 4y ago
        These days yes. Has LLVM and GCC front ends too, very easy to get going with it. D wasn't Boost licensed when I looked at it as a replacement for C++ about a decade ago. Wiki thinks the backend has been available since 2017. It looks like the source may have been available for longer than that but I missed the distinction between source available and open source if it was. That's how I ended up on the C++ path instead of the D one anyway, seems a credible risk others have the same experience.
- throw10920 4y ago
  > C was created by people that didn't have any extra resource to spend on UX This is irrelevant. The design of a language has little bearing on the quality of the error messages from any particular implementation. In particular, the constraints on C implementations in the '70s is irrelevant to constraints on implementations in 2023. There's absolutely nothing preventing the GCC/LLVM/ICC/MSVC developers from adding better error messages to their compilers, and the design of the language certainly isn't one.
  - WalterBright 4y ago
    > The design of a language has little bearing on the quality of the error messages Actually, it has a lot to do with it. https://www.digitalmars.com/articles/b47.html https://www.digitalmars.com/articles/b47.html
    - throw10920 4y ago
      The only point that that article makes that supports this point appears to be "semicolons in the syntax of a language can improve error messages". I don't think that that generalizes, especially because the topic of this comment thread is about C, which already has semicolons, and compilers explaining semantic problems to developers, as opposed to syntactic problems.
    - gavinhoward 4y ago
      Currently writing a compiler that I want to be production strength, so I read your article. Thank you! It's interesting that your specifically call out that putting source lines in is not good when most modern compilers seem to be moving the other direction and putting them in. Do you think it could be a preference thing? Would it be good to have the option for the user to turn it on? Also, thanks for the tip on the spell checker. That is something I'll add. You said they your just used the current symbol table as a dictionary in another comment; that is a great idea too.
    - JonChesterfield 4y ago
      D putting some container types in the language instead of the library is really interesting in this respect. The usual C++ experience of getting compiler failures in some iterator nested within unordered_map is thus avoidable.
- mhh__ 4y ago
  (GC)C isn't that old, and in fact was part of a generation of tools that shunned ye olde' "line too long" type errors
  - WalterBright 4y ago
    I discovered back in the early 80's that it was easier to allocate bigger buffers than to have "line too long" messages and recovery.

>Compiler makers must hate us developers I think that C or C++ were just written by people who never gave a single damn about UX until competition appeared and then things started improving,

marginalia_nu 4y ago

The abysmal compile time for these languages may also have encouraged this fairly bare-bones UX philosophy.

tester756 4y ago
>fairly bare-bones UX philosophy. What do you mean?

marcosdumay 4y ago

C was created by people that didn't have any extra resource to spend on UX. Just another day there was an article here about emulating the computer C was written for in a RP2040 (the Raspbery Pi "competitor" for the Arduino), and yes, it has plenty of space for that. C++ had more of a choice about it.

tester756 4y ago
>C was created by people that didn't have any extra resource to spend on UX How many years have passed since that time?
- marcosdumay 4y ago
  Oh, enough to improve things several times (to answer, 5 decades). People did some improvements, but clearly didn't keep-up with the times (and degraded some things too, UB being the elephant in the room). But large things almost never keep-up with the times.
  - nuancebydefault 4y ago
    Something else must be playing here and I'm pretty sure most of the annoyences did not get solved, mostly because of backward compatability guarantees. It is really a pitty that c/c++ did not get pushed away by competing languages that do/did not have so much of a legacy of sub-par development tooling. Friendlier and better designed languages like C#, Rust or even Python still seem to have some disadvantages that prevented that from happening.
    - deleted 4y ago
      [deleted]
    - JonChesterfield 4y ago
      C++ essentially killed C. Counterexamples exist but they're hard to find and sometimes involve there being no C++ compiler on the target. D didn't replace C++. I wonder if that was related to the single proprietary implementation. The language seems more sensible to me. Rust is aimed at replacing C and C++. There are others in the same field in various stages of development. Zig and carbon come to mind. There's an uphill battle where lots of existing code is in C++ and people fear changing it. C was partly dismantled by C++ compilers promising better error diagnostics and being able to compile most C with minimal patching. I personally think the end is in sight for C++ but the consensus seems to be it'll live forever.
      - WalterBright 4y ago
        D is 100% Boost licensed.
        JonChesterfield 4y ago
        These days yes. Has LLVM and GCC front ends too, very easy to get going with it. D wasn't Boost licensed when I looked at it as a replacement for C++ about a decade ago. Wiki thinks the backend has been available since 2017. It looks like the source may have been available for longer than that but I missed the distinction between source available and open source if it was. That's how I ended up on the C++ path instead of the D one anyway, seems a credible risk others have the same experience.
throw10920 4y ago
> C was created by people that didn't have any extra resource to spend on UX This is irrelevant. The design of a language has little bearing on the quality of the error messages from any particular implementation. In particular, the constraints on C implementations in the '70s is irrelevant to constraints on implementations in 2023. There's absolutely nothing preventing the GCC/LLVM/ICC/MSVC developers from adding better error messages to their compilers, and the design of the language certainly isn't one.
- WalterBright 4y ago
  > The design of a language has little bearing on the quality of the error messages Actually, it has a lot to do with it. https://www.digitalmars.com/articles/b47.html https://www.digitalmars.com/articles/b47.html
  - throw10920 4y ago
    The only point that that article makes that supports this point appears to be "semicolons in the syntax of a language can improve error messages". I don't think that that generalizes, especially because the topic of this comment thread is about C, which already has semicolons, and compilers explaining semantic problems to developers, as opposed to syntactic problems.
  - gavinhoward 4y ago
    Currently writing a compiler that I want to be production strength, so I read your article. Thank you! It's interesting that your specifically call out that putting source lines in is not good when most modern compilers seem to be moving the other direction and putting them in. Do you think it could be a preference thing? Would it be good to have the option for the user to turn it on? Also, thanks for the tip on the spell checker. That is something I'll add. You said they your just used the current symbol table as a dictionary in another comment; that is a great idea too.
  - JonChesterfield 4y ago
    D putting some container types in the language instead of the library is really interesting in this respect. The usual C++ experience of getting compiler failures in some iterator nested within unordered_map is thus avoidable.
mhh__ 4y ago
(GC)C isn't that old, and in fact was part of a generation of tools that shunned ye olde' "line too long" type errors
- WalterBright 4y ago
  I discovered back in the early 80's that it was easier to allocate bigger buffers than to have "line too long" messages and recovery.