[desponsible]

> One of the absolute worst features of C++ is how it makes a lot of things so context-dependent - which just means that when you look at the code, a local view simply seldom gives enough context to know what is going on.

Good point. Very good point.

Having spent few years developing for the Linux kernel I can say that the most cluttered code I dealt with was the network stack. And exactly because it was done in C++-ish way. It makes an extensive use of tables of function pointers, which is basically an analog of a C++ virtual table. A socket depending on its type would get a pointer to a different table and that table would define the actual flow, say, of the recv() call in the kernel. The concept is very elegant, and it translates into a more compact code, but it also makes tracing the code by hand hard.

So, yeah, Linus got a point there :)

[stcredzero]

I started designing a language where you had lexically scoped "contexts" to specify the meanings of words. In general a package/library would be a context, and could declare its dependency on other contexts. Any words with conflicting interpretations would have to use its full global specifier to compile.

[chromatic]

Perl does this, Perl 6 especially.

[alnayyir]

Sadly x86/arm/mips/sparc/power processors aren't Perl machines and Perl6 thusly can't be used to make a kernel for a Unix derivative.

[stcredzero]

One could probably get Scheme to do this and use it to make a kernel. But what would be the point of making it a Unix machine then? Make it a Scheme machine.

[eru]

They aren't C machines, either. But I agree, that Perl is probably harder to compile to native code than C.

[bdr]

Yes, I think we all wept when we first learned that.

[jrockway]

Actually, you refute his point. If they were actual classes instead of ad-hoc vtables, the flow would be clear.

[bnoordhuis]

No, he didn't. A call to ipv4_recv() is obvious, a call to impl->recv() less so.

[mikeklaas]

I think your example proves that it is how features are used, not the mere fact of the possibility for use in a language, that creates the problems linus refers to.