4 ms·

All this talk of rvalues, auto, and string_view is PRECICELY the problem with cpp. There are so many details you need to keep track of, and eventually you make

All this talk of rvalues, auto, and string_view is PRECICELY the problem with cpp. There are so many details you need to keep track of, and eventually you make a mistake. Now, yes, i know what all of that does, and how they are supposed to be used, but it does not remove the cognitive load. Many languages have a substantially lower cognitive load when doing something trivial, such as ToLower().ToUpper(), etc.

opportune 4y ago
Every systems-level language will have these sharp edges handled differently. Have you heard of borrow checkers? Many languages don’t have to concern programmers with rvalues or equivalents at all because they are garbage collected - should everything be garbage collected? Let’s not make this a language war, there has to be some programming language that does low-level memory operations without batteries included for some types of technologies. When I write code in C++ and I want something like garbage collection or ref counting I can reach for a shared_ptr. If you don’t want to concern yourself with types, values vs references, or manual memory management don’t choose C++. The default handling is sane if not necessarily intuitive. You shouldn’t create a ref or pseudo-ref (string_view) to data that is not on the heap and no longer allocated to the stack - seems sane. This problem could be easily caught by breaking function calls into separate lines and explicitly specifying the types at each step.
- pjmlp 4y ago
  Many languages don’t have to concern programmers with rvalues or equivalents at all because they are garbage collected - should everything be garbage collected? From Xerox point of view, yes. Unfortunely they lost to the UNIX workstation market. Interlisp-D, Smalltalk and Mesa/Cedar.
  - brobdingnagians 4y ago
    There might be a reason they lost. Believing that one size fits all is a sure way to alienate a lot of people who don't fit that size. Right tool for the right job and giving the freedom for people to solve their problems in the best way is a better way to win people over.
    - pjmlp 4y ago
      Free beer UNIX on cheaper hardware, plus bad management, basically. Nothing to do with the technology. Hence why I love why Android is so locked down to native code, and Apple is doubling down on Swift.
    - deleted 4y ago
      [deleted]
- hot_gril 4y ago
  Yeah, you shouldn't have GC in systems-level code any more than I should have lifetime concerns in application-level code. Problem is leaders end up choosing C++ for both and saying y'all should know how to deal with it. Google also has a lot of stuff in the middle where they're fine with sacrificing a little speed for a lot more safety, but Java etc are too slow. Golang was supposed to satisfy that, but I'm guessing it was too big of a leap from C++.
- arka2147483647 4y ago
  > Every systems-level language ... Is Cpp systems-level language? As I see, the problems arrives from the fact that Cpp is a multi-paradigm language, and as such contains a near endless wealth of features to combine. Also modern Cpp takes a clear direction away from low level to (relatively) more high-level language. The problem really comes from the combination of low level and high level paradigms in the same language/codebase, where the expectations of the behavior of each piece of code can vary wildly. > ... will have these sharp edges handled differently Perversely, plain C, often has a lower cognitive load than Cpp. This is because you must always manually handle pointers, types, object lifetimes, etc. Now, this does result in a high cognitive load, BUT, the cases as in Cpp where you might combine auto, with a temporary, with a pointer inside, referring to some unseen resource, cannot happen, because you cant do that in C. So the worst case in cognitive load is never as bad as in Cpp. The lack of features means less possible combinations to shoot yourself in the foot. (Though C does still have many, nor is C an ideal language) > Let’s not make this a language war Discussing the problems of Cpp is not language war. Nor is understanding the merits and problems of the Design of Cpp. > If you don’t want to concern yourself with types, values vs references, or manual memory management don’t choose C++ But IF YOU DO write Cpp, there is no escaping them. Which is my point.

opportune 4y ago

Every systems-level language will have these sharp edges handled differently. Have you heard of borrow checkers? Many languages don’t have to concern programmers with rvalues or equivalents at all because they are garbage collected - should everything be garbage collected? Let’s not make this a language war, there has to be some programming language that does low-level memory operations without batteries included for some types of technologies. When I write code in C++ and I want something like garbage collection or ref counting I can reach for a shared_ptr. If you don’t want to concern yourself with types, values vs references, or manual memory management don’t choose C++. The default handling is sane if not necessarily intuitive. You shouldn’t create a ref or pseudo-ref (string_view) to data that is not on the heap and no longer allocated to the stack - seems sane. This problem could be easily caught by breaking function calls into separate lines and explicitly specifying the types at each step.

pjmlp 4y ago
Many languages don’t have to concern programmers with rvalues or equivalents at all because they are garbage collected - should everything be garbage collected? From Xerox point of view, yes. Unfortunely they lost to the UNIX workstation market. Interlisp-D, Smalltalk and Mesa/Cedar.
- brobdingnagians 4y ago
  There might be a reason they lost. Believing that one size fits all is a sure way to alienate a lot of people who don't fit that size. Right tool for the right job and giving the freedom for people to solve their problems in the best way is a better way to win people over.
  - pjmlp 4y ago
    Free beer UNIX on cheaper hardware, plus bad management, basically. Nothing to do with the technology. Hence why I love why Android is so locked down to native code, and Apple is doubling down on Swift.
  - deleted 4y ago
    [deleted]
hot_gril 4y ago
Yeah, you shouldn't have GC in systems-level code any more than I should have lifetime concerns in application-level code. Problem is leaders end up choosing C++ for both and saying y'all should know how to deal with it. Google also has a lot of stuff in the middle where they're fine with sacrificing a little speed for a lot more safety, but Java etc are too slow. Golang was supposed to satisfy that, but I'm guessing it was too big of a leap from C++.
arka2147483647 4y ago
> Every systems-level language ... Is Cpp systems-level language? As I see, the problems arrives from the fact that Cpp is a multi-paradigm language, and as such contains a near endless wealth of features to combine. Also modern Cpp takes a clear direction away from low level to (relatively) more high-level language. The problem really comes from the combination of low level and high level paradigms in the same language/codebase, where the expectations of the behavior of each piece of code can vary wildly. > ... will have these sharp edges handled differently Perversely, plain C, often has a lower cognitive load than Cpp. This is because you must always manually handle pointers, types, object lifetimes, etc. Now, this does result in a high cognitive load, BUT, the cases as in Cpp where you might combine auto, with a temporary, with a pointer inside, referring to some unseen resource, cannot happen, because you cant do that in C. So the worst case in cognitive load is never as bad as in Cpp. The lack of features means less possible combinations to shoot yourself in the foot. (Though C does still have many, nor is C an ideal language) > Let’s not make this a language war Discussing the problems of Cpp is not language war. Nor is understanding the merits and problems of the Design of Cpp. > If you don’t want to concern yourself with types, values vs references, or manual memory management don’t choose C++ But IF YOU DO write Cpp, there is no escaping them. Which is my point.