Hacker News Reader

Comment by catnaroek | Hacker News Reader

> too long build times, hard to debug templates, etc.

These are symptoms of language issues.

And hopefully somewhat mitigated by modules once they land and (if it happens) everyone migrates.

Asking out of total ignorance: How exactly do modules interact with templates? Is template specialization restricted to the module where the template is defined? If not, I don't see how modules could help much.

Still ongoing design. This is the Microsoft view of them

https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-modules...

Regarding templates, the approach is similar to the deprecated export keyword, so partially compiled templates and inline functions are stored in the metadata database used by the compiler for modules.

I love how the second and third paragraphs describe modules as if they were some sort of novel, perhaps even futuristic, language feature that no programmer has ever seen before. “Oh, it's totally not like we're catching up with what other programming languages had for decades.”

The problem is that in the C culture practically ignored everything that was done in computing up to the late 70's.

Bjarne was of course aware of modules, being brought on Simula and other programmer friendly languages, but then he had to make C++ code fit into UNIX linkers that only knew about AT&T Assembly and C binary formats.

So no modules there, and along the years you got a culture of developers, specially those that only learn on the job, that never learned about modules and its history.

You see it happen also when cache friendly code and RAII get discussed.

Those things were also possible outside the C family of languages, before they won the market. So most millennials think that they are some special language capabilities only possible in C and C++.

> You see it happen also when cache friendly code and RAII get discussed.

To be honest, I can't talk intelligently about cache-friendliness at all. I know that there exist models of computation (say, for complexity analysis purposes) that explicitly take memory hierarchies into account, but I've never seen them actually used on anything but the simplest data structures and algorithms.

With respect to RAII, I think the main benefit isn't cache-friendliness, but rather deterministic destruction - you can't delay relinquishing a scarce resource that someone else might want to use.

> So most millennials think that they are some special language capabilities only possible in C and C++.

I'm a millennial, and have to admit with shame that I grew up thinking C++ is the best thing ever. But it's possible to recover from it. :-)

> but I've never seen them actually used on anything but the simplest data structures and algorithms

Take a look at a typical performance-oriented GPU coding, cache is the major analysis parameter there. Data structures are mostly 2D and 1D arrays, but they may be scrambled in a very complex way, and the algorithms are arbitrarily complex.

Thanks for the pointer. Will have a look.

> With respect to RAII, I think the main benefit isn't cache-friendliness, but rather deterministic destruction - you can't delay relinquishing a scarce resource that someone else might want to use.

I never said it was related to it, I said it was the other feature many think it is C++ specific, or introduced via C++.

Ada also has RAII via controlled types and Object Pascal also had destructors when it was introduced.

Functional programming languages that allow for rich macros, support trailing lambdas or currying also allow for RAII like implementations using those features.

For example, with-open-file in Common Lisp.

"I like work; it fascinates me. I can sit and look at it for hours." -- Jerome K. Jerome. Especially when it's the high priests of the C++ orthodoxy reinventing the wheel 30 years late.

Reply on news.ycombinator.com