You can't make C++ not ugly, but you can't not try (2010) • Hacker News Board

Re: You can't make C++ not ugly, but you can't not try (2010)

#101

Post by cmroanirgo » Thu, Feb 27, 2020, 9:33 AM UTC

pjmlp wrote: post #94

kllrnohj wrote: post #91

Earlier quoted context omitted.

> Because STL is part of the compiler, guaranteed to work on every platform supported by the compiler No it isn't and no it's not. There are even platforms where an STL isn't even provided out of the box, you have to pick one. And there's quite a few at that - libc++, libstdc++, stlport, etc... But clang, g++, etc... they don't care. To them it's just another library you're linking against, no different from any othe…

Only ISO C++ compliant platforms matter. As having multiple implementations to choose from, that is the beauty of language standards. Abseil and boost do not fall under that umbrella, and I belong to the C++ subculture that never ever touched them, or plans to.

STL by it's very name is a library, and because it ships with a compiler, doesn't mean it's part of that compiler. It's just a library, like Boost. It might have some ISO standards behind it: great! But it's still a library and not intrinsic to the language itself (see my orig question).

eg. to use an 'int' you just declare one and use it. To use strings, you need to include .

Re: You can't make C++ not ugly, but you can't not try (2010)

#102

Post by mbeex » Thu, Feb 27, 2020, 9:35 AM UTC

kllrnohj wrote: post #90

Espressosaurus wrote: post #62

Earlier quoted context omitted.

Because that way you don't need to haul in dependencies unless you have a real reason. std::function is fine for prototyping, but its size hit is extreme , so in embedded code we use other implementations. But where size and speed doesn't matter? Why bother?

> Because that way you don't need to haul in dependencies unless you have a real reason. These are all largely header libraries. You're already hauling in a dependency, and in every c++ file that uses it at that. > std::function is fine for prototyping std::function isn't part of the containers library of the STL (containers being all the stuff here: https://en.cppreference.com/w/cpp/container ). I agree std::functio…

> These are all largely header libraries.

That's not even true for boost, no matter if they always advertise that. The lib is also notorious for bad decomposability (using only a subset without installing the whole monster). Not to speak about idiosyncratic naming and build system, making it sometimes hard to include it in meta builds of other libraries and frameworks.

In sum: Anyone sensible, regarding different kinds of footprint and dependencies will think twice, before pulling in these kind of libraries.

Re: You can't make C++ not ugly, but you can't not try (2010)

#103

Post by praptak » Thu, Feb 27, 2020, 9:39 AM UTC

nineteen999 wrote: post #36

TheOtherHobbes wrote: post #28

Earlier 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.

Car and cdr are a shallow critique of Lisp, the equivalent of "omg, significant whitespace" critique of Python.

Re: You can't make C++ not ugly, but you can't not try (2010)

#104

Post by ggambetta » Thu, Feb 27, 2020, 9:49 AM UTC

  [The [] operator] is an absolute 
  failure of engineering!
  Do you want to know what real
  engineering is? It's this:

  map_set(m, 5, "foo");
  char *x = map_get(m, 5);

So like map::insert and map::at? Did these not exist in 2010?

Re: You can't make C++ not ugly, but you can't not try (2010)

#105

Post by lispm » Thu, Feb 27, 2020, 10:00 AM UTC

Munksgaard wrote: post #100

AnimalMuppet wrote: post #64

Earlier quoted context omitted.

I don't know about templating, but... is Haskell's Hindley-Milner type identification system Turing complete? For that matter, Lisp's macros are definitely Turing complete, and they are... a templating system on steroids, maybe? About mindshare: Lisp has zealots, but they are few, even if they are loud, and they are on HN more than many other places. C++ is perhaps not loved, but in some circles it is very well respe…

The beauty of Lisp's macros are that they're specifically _not_ expressed in a separate language: They're ordinary Lisp expressions that work directly on the AST.

Even better, they don't need an AST - they work with arbitrary s-expressions and thus in many cases simple list processing operations can be used for code transformations.

Re: You can't make C++ not ugly, but you can't not try (2010)

#106

Post by rumanator » Thu, Feb 27, 2020, 10:02 AM UTC

kllrnohj wrote: post #88

rumanator wrote: post #82

Earlier quoted context omitted.

> You have that backwards. The STL containers are for when you have a hyper-specific niche use case. That assertion makes no sense at all. The stl contrainers work very well as basic generic containers that can safely be used for pretty much any conceivable use where performance isn't super critical. I'm talking about cases like, say, you need to map keys to values but you don't really care about performance or which…

This makes no sense. The STL is the specialized containers with obscure performance characteristics & behaviors. Boost & abseil provide the generic, reasonable default ones. You're arguing it's better to use something that's across the board worse for nearly every user, and by a lot, just because... why? It's slightly more convenient?

> This makes no sense. The STL is the specialized containers

It really isn't. The whole STL is, by design, a template library packed with generic data structures that are designed to have very robust defaults and still be customizable and extensible.

When the defaults are good enough, which is the case in general, the STL will do. If you have a niche requirement (say, games) or feel adventurous, you adopt custom and/or specialized solutions.

This has been the case since the STL's inception. They are the standard, default library. I can't understand how someone is able to miss this fact.

Re: You can't make C++ not ugly, but you can't not try (2010)

#107

Post by gpderetta » Thu, Feb 27, 2020, 10:04 AM UTC

Rusky wrote: post #18

gumby wrote: post #2

This 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…

> Containers still do silly things when you use `c[..]` syntax with no element there. (Both when trying to insert and when trying to retrieve!)

FWIW, I find std::map operator[] creating an object extremely convenient and it is very annoying having to use defaultdict to get the same behavior [edit: in python]. So ugliness really depends on what you are used to.

> The general level of language size and complexity, especially around templates, has only gotten worse. Concepts will finally help in some ways here.

variadic templates and type deduction greatly help. A lot of complex template metaprogramming is suddenly not needed anymore (I've used boost::mpl a lot in the past, but not once in the last 10 years). constexpr functions also helped get rid a lot more use cases. Finally if constexpr made a lot of sfinae hacks obsolete.

Re: You can't make C++ not ugly, but you can't not try (2010)

#108

Post by pjmlp » Thu, Feb 27, 2020, 10:05 AM UTC

cmroanirgo wrote: post #101

pjmlp wrote: post #94

Earlier quoted context omitted.

Only ISO C++ compliant platforms matter. As having multiple implementations to choose from, that is the beauty of language standards. Abseil and boost do not fall under that umbrella, and I belong to the C++ subculture that never ever touched them, or plans to.

STL by it's very name is a library, and because it ships with a compiler, doesn't mean it's part of that compiler. It's just a library, like Boost. It might have some ISO standards behind it: great! But it's still a library and not intrinsic to the language itself (see my orig question). eg. to use an 'int' you just declare one and use it. To use strings, you need to include .

The S in STL stands for Standard, something that neither boost nor Abseil are, or will ever be.

Re: You can't make C++ not ugly, but you can't not try (2010)

#109

Post by pjmlp » Thu, Feb 27, 2020, 10:08 AM UTC

fctorial wrote: post #97

pjmlp wrote: post #87

Earlier quoted context omitted.

I rather have my phone be fast, without the apps taking ages to download.

Java apps are actually pretty small in size. It's the assets that make take up the most space, and that is independent of language. App installation is a one time cost anyways. Did you mean s/download/startup/?

I was giving a counter argument in a very not intelligent way.

Being a polyglot developer, with Java, .NET and C++ as my favourite stacks, means I don't suffer from Java hate from C++ point of view, rather enjoy how one can combine their strengths to achieve a good outcome.

Re: You can't make C++ not ugly, but you can't not try (2010)

#110

Post by gpderetta » Thu, Feb 27, 2020, 10:09 AM UTC

cmroanirgo wrote: post #101

pjmlp wrote: post #94

Earlier quoted context omitted.

Only ISO C++ compliant platforms matter. As having multiple implementations to choose from, that is the beauty of language standards. Abseil and boost do not fall under that umbrella, and I belong to the C++ subculture that never ever touched them, or plans to.

STL by it's very name is a library, and because it ships with a compiler, doesn't mean it's part of that compiler. It's just a library, like Boost. It might have some ISO standards behind it: great! But it's still a library and not intrinsic to the language itself (see my orig question). eg. to use an 'int' you just declare one and use it. To use strings, you need to include .

STL (if we use this name as a arguably incorrect alias for the c++ standard library) is intrinsically linked with the language. A lot of its implementation requires primitives that are not part of the language (although often exposed as intrinsics as an extension). An implementation can and often does treat the names under namespace std specially and assumes invariants and behavior.