Hacker News Reader

Comment by greggman3 | Hacker News Reader

That strikes me as Stockholm Syndrome. No one in their right mind would consider C++ templates a good design for a meta-language. In fact the majority of older template patterns aren't based on good language design but hacks around conditional compiling via arrays of size -1 and crap like that.

A good meta programming language would be one that's as easy to program as a general language. lisp, nim, etc...

View on HN

I think this is.. quite wrong. I don't think C++ is an amazing language (it's not in my top 3 personally, but I do work with it daily), but templates are one of the best things about the language IMO.

I have a lot of experience with many different types of metaprogramming (cl macros, Rust macros, template Haskell (and Typeable/Generic), ... even CLR code generation) and C++ templates are better than everything I've used other than Common Lisp once you really understand them. A really common C++ theme I see is people that don't understand things railing against them (I used to be in this camp myself, so I can identify with the sentiment).

Templates allow you to choose at will between nominal/structural subtyping (in a way), perform type-level logic, generate code that can be thread-safe or lock-free at the caller's whim... They are very powerful, much more than most devs realize, and if you understand C++, writing them is not difficult.

The "really understand them" part is, of course, the hard part. You need to understand the core language and the template language to be effective with them. I can see why even some experienced C++ developers shy away from templates.

Even if they're a good general design, half the uses of SFINAE are absolutely insane and from what I understand it's significantly harder than it should be to make a fully generic template across all kinds of edge case and corner case types.

The attitude with templates seems to be that if something is at all possible with hacks then there doesn't need to be any language support added, even if it would be vastly simpler to read and write and probably to compile. I don't think that works out well.

I wouldn't call myself a c++ expert but I have used the language for a long time. In my opinion, templates have a lot of awesome uses outside of SFINAE and if you find yourself reaching for SFINAE, that's probably code smell and you can probably simplify the design elsewhere to avoid it.

Generally I find the best use of templates is the most basic: you want to write some code that operates on duck-types. As long as one is able to control themselves and pick the right use cases for maintainability, templates are simple enough. In my experience, this is very doable.

Concepts are also a really cool way to rein in which types are accepted as a template parameter and have a lot of potential to make templates easier to understand and teach. To me, this is the most exciting c++20 feature.

With C++17, if constexpr removed most of the necessity for crazy SFINAE uses. Before that it was definitely worse. C++20 adds even more to make things more "semantic"; they're constantly adding better language support for templates.

No one disputes that meta programming is useful. What is disputed is C++ templates being a "good" way to meta program.

I certainly understand metaprogramming, but navigating very dense C++ templates is one of the most complicated things I've had to do in my life. One or two levels of abstraction and you will lose your ability to hold everything you need to solve a problem in your head, and after a few dozen lines the source code is unreadable.

> You need to understand the core language and the template language to be effective with them.

this is a bug.

I guess that just hasn't been my experience at all. I don't think a nested C++ template is any more complicated than a CL macro with a corresponding level of nested `.

I also don't really see how requiring understanding of a language to generate that language could be considered a bug - every macro system carries that requirement. C++ just happens to be (much) more complex than most languages (and I do agree that a large amount of that complexity is probably not necessary).

I'd argue it's significantly more complex because you don't have access to the C++ AST, templates are ultimately non-hygienic macros, their results are invisible to both developer and user, and potential errors are inscrutable. They're difficult to abstract over, and you will wind up repeating yourself quite often since you can't just write normal C++ code with C++ includes for helper functions and data structures.

I should be more clear about what I meant on the bug. C++ templates force you to understand the entirety of the language at once and hack around its edges because it doesn't support actual meta programming. It's hard for me to come up with a concrete example, but my experience writing some advanced compile-time evaluation with SFINAE patterns left me forgetting how things worked within minutes of typing them. Compare to say Rust, where the generics implementation is much cleaner and macro system better flushed out and easier to read/understand. Or the LISPs where your macro is just more LISP code.

And not for nothing, templates destroy compile times. They take a long time to write and edit and make everyone else using them work slower. All told, templates do not make it easier to write C++ except in trivial cases and first-order abstractions.

The kind of stuff you are able to do with entt (https://github.com/skypjack/entt#code-example) like `entities.view<Position, Sprite>.each([&](auto &pos, auto &vel) { ... });` is super awesome IMO. And then it compiles down to just directly inlined straight walks over the respective arrays (looking in godbolt.org). It's basically almost optimal for it.

I do agree that you can go insane with templates and have a bad time. You just have to choose well. However if you have a problem with there existing other problematic code in the same language (that may be separate from your code), then C++ is maybe not the best fit. There's a lot of C++ out there.

Any recommendation for books/blogs/videos/code to learn about this ?

I consciously avoided C++ since the late 90s, lest its litany of accidental complexities crowd other more important things out of my brain. I was drawn into it recently by a work assignment, and have been pleasantly surprised by modern C++.

I find it much more pleasant to write, e.g., ODBC client code in C++ than in C, and templates have a lot to do with that. I'm not an expert with Lisp macros or other reportedly superior meta-languages, but I will say that when I write generic code in C# or Java, I really miss the power of C++ templates.

Template syntax is pretty awful, and accomplishing what I want can involve some really strange idioms, like SFINAE. The ergonomics are slowly improving with type deduction, constexpr, and now concepts.

Exactly, old hacks and techniques. Thirty years ago, C++ template were limited and clever people struggled with their limitations, but now there are vastly simpler ways to do much more.

As Stroustrup said to me years ago, “yes, I wanted a macro system but that word had already been colonized by the preprocessor, and we needed to avoid new keywords as much as possible if people were going to try it out.

Nowadays C++ and a powerful multi-paradigm programming language quite straightforward to use if you forget the word “C” in its name.

If would be a good instructional language if people didn’t fall into the lazy “a horse is a king of animal” OO trope.

It's true the templates weren't designed as a meta language. C++ has a lot of baggage.

But, at least, you no longer have to iterate over arrays with size-1, (size-1)-1 etc these days. We have variadic template expansion, we have the (ugly, still not decent design, but useful) std::integer_sequence , and better still - we have pretty strong constexpr capabilities.

Such examples speak more to C++ templates as a mechanism for capturing usage patterns in a convenient form, thus effectively creating a special-purpose, domain-specific language, than they speak to such templates as a meta-language. "Meta" means "information about information", so a meta-language in this case would describe the mechanisms used to capture such patterns, not the patterns themselves.

I do meta every day, meta-meta often, and triple-meta occasionally. The rules language for my Expert System is a true meta-language, because I designed it to (among other things) specify the manipulation of computer languages. So its domain knowledge is about the nature of computer languages and how to automate their assessment / analysis, transformation / re-engineering, translation, and generation.

To give a real-life example, we used our Expert System to automate the translation of complex compiler front- and back-end code from a proprietary system language to C++ for a major computer manufacturer. The translation rules don't really care what the code is doing; they care how the code is doing it. The compiler team created new templates and classes to provide the functionality their system language had that C++ doesn't, and we adjusted our translation rules to ensure that the translated code invokes those templates and classes in a clear, effective, efficient, and readable way.

> ... easy to program as a general language. lisp, nim, etc...

C++ templates are just a compile-time lazily-evaluated Lisp.

As always, the criticism of C++ comes down to "programming is hard, let's go shopping".

If you don't want to learn and you just want to do the bare minimum to keep your 8 hour coding job, there's already plenty of languages that nail this niche. C++ obviously is not for you, just move on and don't make a redundant comment.

What an asinine comment. I guess if you're real programmer you'll program everything in brainfuck. Isn't not hard to fathom that some language designs are easier to express and easier to understand than others and still get the same things done. C++'s meta programming via templates is clearly a hack and was never designed to do what it's being abused to do.

Other than lisp, which production ready languages do you think do it better?

I really liked camlp4 (an early fork of which is available as camlp5, but no longer a fundamental part of the OCaml ecosystem). I was able to use camlp4 to implement Erlang-style bitstrings, and they were as efficient as if you had written the most efficient code by hand.

https://people.redhat.com/~rjones/bitstring/html/Bitstring.h...

Reply on news.ycombinator.com