Earlier quoted context omitted.
Difference is, C++ actually has more than single digit mind/marketshare outside the safety of the HN eggcup.
Market share, maybe. Mindshare - Lisp has its zealots. C++ is tolerated rather than adored, because it's more of a Katamari Damacy of stray CS than a language with a coherent focus. How many other languages have a Turing complete sublanguage built into them just to handle templating?
You can't make C++ not ugly, but you can't not try (2010)
71–80 of 187 posts
Re: You can't make C++ not ugly, but you can't not try (2010)
#72That C code wouldn't work if the strings in the map are mutable (which they are in C++). It wouldn't work if the strings were allocated dynamically either. Once you write all the code required to get it working that way, the C starts comparing less favorably to C++.
I don't see why not? You'll have to decide the ownership semantics if they're dynamically allocated but that's it?
Re: You can't make C++ not ugly, but you can't not try (2010)
#73Earlier quoted context omitted.
To the contrary, modern C++ has solved very few, if any, of the problems described in the article. Being generous: * There's now `std::string_view` to address some of the problems with `std::string`, but the rest are still there. There are some attempts to specify the encoding now, at least. * Lambdas and `std::function` pretty much solve the function pointer complaints, with some added complexity. * Containers still…
If everyone can forgive my ignorance... I used to call everything in the std:: namespace as just that, the standard template library (STL) (whatever it's iteration). So is this C++03 /C++11 stuff just updates to this library, or is std::string recognised at the compiler level? (Genuinely confused). (In old man voice) We ended up rolling out own stuff and marking std:: verboten. Why? Stl was too slow, too verbose, and…
Re: You can't make C++ not ugly, but you can't not try (2010)
#74Earlier quoted context omitted.
I still think the STL containers are the sane default to reach for & switch to more obscure ones when the problem domain and performance requirements say to use a different one.
You have that backwards. The STL containers are for when you have a hyper-specific niche use case. They are otherwise terrible defaults and everyone should use boost or abseil by default otherwise. std::map, for example, is only appropriate if you need a red-black tree specifically. Which almost nobody does. std::unordered_map is less awful, but abseil has a literal straight upgrade. With the same API. So... why woul…
I want my OWL, VCL back, not an hash table able to do lookups in micro-seconds
Re: You can't make C++ not ugly, but you can't not try (2010)
#75Earlier quoted context omitted.
Difference is, C++ actually has more than single digit mind/marketshare outside the safety of the HN eggcup.
Market share, maybe. Mindshare - Lisp has its zealots. C++ is tolerated rather than adored, because it's more of a Katamari Damacy of stray CS than a language with a coherent focus. How many other languages have a Turing complete sublanguage built into them just to handle templating?
For lower-level programming, while my favorite is Rust, if I cannot use Rust for some reason (say the team against it) I'd use C++.
To be sure, what I mean is I would use my favorite subset of C++, and I adore that subset. The parts of C++ outside of my chosen subset are merely tolerated.
Re: You can't make C++ not ugly, but you can't not try (2010)
#76This decade old article describes an ancient and obsolete language (C++03 probably though some of the text suggests it might be C++98). It's not worth reading in 2020. Modern C++ is a very different language though it can still almost completely interoperate with quite old code. C++11 and C++14 already addressed most of the things brought up, and contemporary C++ (obviously most code is not in it yet) even supports g…
The author also seems to really, really want C++ to be Python, despite that they're completely different languages for completely different purposes that make completely different sets of design tradeoffs. In that respect, the author probably wouldn't be happy with modern C++, either. For example, C++ is never going to be a garbage-collected language (by default, at least). Modern C++ gives you better tools to deal w…
Re: You can't make C++ not ugly, but you can't not try (2010)
#77Earlier quoted context omitted.
Market share, maybe. Mindshare - Lisp has its zealots. C++ is tolerated rather than adored, because it's more of a Katamari Damacy of stray CS than a language with a coherent focus. How many other languages have a Turing complete sublanguage built into them just to handle templating?
> How many other languages have a Turing complete sublanguage built into them just to handle templating? On the bright side, C++ doesn't have obscure keywords like "cdr" and "car" that refer to specific hardware elements of an obsolete computer built in 1954.
Re: You can't make C++ not ugly, but you can't not try (2010)
#78This decade old article describes an ancient and obsolete language (C++03 probably though some of the text suggests it might be C++98). It's not worth reading in 2020. Modern C++ is a very different language though it can still almost completely interoperate with quite old code. C++11 and C++14 already addressed most of the things brought up, and contemporary C++ (obviously most code is not in it yet) even supports g…
To the contrary, modern C++ has solved very few, if any, of the problems described in the article. Being generous: * There's now `std::string_view` to address some of the problems with `std::string`, but the rest are still there. There are some attempts to specify the encoding now, at least. * Lambdas and `std::function` pretty much solve the function pointer complaints, with some added complexity. * Containers still…
The author, after a long and dubious appeal to authority, claims that:
* C++ exceptions are outright evil and should be avoided
* C++ string class "is so utterly godawfully stupid" because it has no garbage collection or refcounting, and in short doesn't precisely match Python's implementation. He also felt personally insulted by the fact std::string is a template class.
* He feels C function pointers are fine but believes function pointers in C++ weren't extended to support pointers to member functions, which he then backtracks and says they actually exist but they are "so horrendously ill-conceived that absolutely nobody uses it for anything", thus showing his ignorance and lack of experience.
* For some reason he criticised std::map for the way it's std::map::operator[] returns a reference to the mapped value, eventhough that's what it is supposed to do by design and by the principle of least surprise.
* The author made other claims, but the text grows so much in the style of "foaming from the mouth" that it's just better to stop reading after a point.
In short, this article is just a rant where someone vents that a programming language other than Python is not Python at the eyes of the author. It's a pretty unconvincing rant and full of logical and rational holes, but a rant nonetheless. So the author loves Python and his personal take on C++ does not match his view of Python. That's fine. It's just weird how this sort of text floats up in a technical forum after over a decade after it has been published, as if it's expected to add or say anything of value.
Re: You can't make C++ not ugly, but you can't not try (2010)
#79Why would you ever want this? Gives me Java nightmares.
Re: You can't make C++ not ugly, but you can't not try (2010)
#80https://twitter.com/apenwarr/status/1232848468156256256?s=21