3 ms·

It's more than that. For example, converting a string to uppercase in C++: #include <string> #include <cctype> #include <algorithm> #include <i

It's more than that. For example, converting a string to uppercase in C++: #include <string> #include <cctype> #include <algorithm> #include <iostream> int main() { std::string s("hello"); std::transform(s.begin(), s.end(), s.begin(), [](unsigned char c) { return std::toupper(c); }); std::cout << s; } Same thing in Python: print('hello'.upper())

Hizonner 5y ago
That takes advantage of the fact that Python puts a bunch of relatively obscure functionality in scope by default... thus increasing the chance that programs will use the wrong method or rely on stuff they don't really intend to. Case manipulation isn't something most modern programs should even be doing at all, since it's almost impossible to internationalize it. In fact it's really mostly name space management. Python doesn't require you to pull in "upper" because it starts with a relatively big name space. It doesn't require you declare the main program because you're relying on the fact that Python executes a file on loading it (and that reliance is arguably bad Python style). All of the "std::" stuff is a name space management choice. ... and the rest has nothing to do with static typing either. The way the code is indented on multiple lines is a stylistic convention. The transform primitive requiring you to specify bounds is a library choice, related to the language's apparent lack of a universal way to map over a container. I'm not sure why you need the lambda. The rewrite in place is memory model stuff inherited from C. In Haskell, which is fully compiled and is about the most rigid static typed language you could ever imagine: import Data.Char(toUpper) main = putStrLn (toUpper <$> "hello") If you'd asked for something that didn't require oddball functionality, then that could probably also have been a one-liner.
capitalsigma 5y ago
C++ is forcing a style on you that encourages you to avoid a copy. You could, of course, have a library like: std::string ToUpper(const std::string& str) { std::string as_lower(str); absl::c_transform(str, as_lower, std::toupper); return as_lower; } to enable: int main() { std::cout << ToUpper("hello"); return 0; } but this would be no good! You have chosen an API that forces your users to be gratuitously inefficient. Maybe that is OK for your personal project, but an API like that has no business in the standard library.
- WithinReason 5y ago
  You just explained why C++ will never be as productive as Python.
  - capitalsigma 5y ago
    No one is stopping you from writing your C++ inefficiently if you choose to. I am skeptical that spending a bit of time thinking about ownership/lifetimes is really such a big hit to productivity.

Hizonner 5y ago

That takes advantage of the fact that Python puts a bunch of relatively obscure functionality in scope by default... thus increasing the chance that programs will use the wrong method or rely on stuff they don't really intend to. Case manipulation isn't something most modern programs should even be doing at all, since it's almost impossible to internationalize it. In fact it's really mostly name space management. Python doesn't require you to pull in "upper" because it starts with a relatively big name space. It doesn't require you declare the main program because you're relying on the fact that Python executes a file on loading it (and that reliance is arguably bad Python style). All of the "std::" stuff is a name space management choice. ... and the rest has nothing to do with static typing either. The way the code is indented on multiple lines is a stylistic convention. The transform primitive requiring you to specify bounds is a library choice, related to the language's apparent lack of a universal way to map over a container. I'm not sure why you need the lambda. The rewrite in place is memory model stuff inherited from C. In Haskell, which is fully compiled and is about the most rigid static typed language you could ever imagine: import Data.Char(toUpper) main = putStrLn (toUpper <$> "hello") If you'd asked for something that didn't require oddball functionality, then that could probably also have been a one-liner.

capitalsigma 5y ago

C++ is forcing a style on you that encourages you to avoid a copy. You could, of course, have a library like: std::string ToUpper(const std::string& str) { std::string as_lower(str); absl::c_transform(str, as_lower, std::toupper); return as_lower; } to enable: int main() { std::cout << ToUpper("hello"); return 0; } but this would be no good! You have chosen an API that forces your users to be gratuitously inefficient. Maybe that is OK for your personal project, but an API like that has no business in the standard library.

WithinReason 5y ago
You just explained why C++ will never be as productive as Python.
- capitalsigma 5y ago
  No one is stopping you from writing your C++ inefficiently if you choose to. I am skeptical that spending a bit of time thinking about ownership/lifetimes is really such a big hit to productivity.