gryan

Cool! What is their idea on the next step? Are they going to try to remove the front wall with the entire painting enact?

Beats being swayed by facts.

Arthur C. Clarke: Science fiction writer.

E.W. Dijkstra: Actual computer scientist.

So, you're an idiot?

Fortunately, Joel is not the first or last word on any subject.

"For example, you might start at the root resource http://foo.com/api/ . It returns, as content, a set of subresources that can be requested. The API documentation should describe what data the server sends for /api/ -- what format it's in (HTML, XML, JSON, etc), how to find its subresources (<a>, <form>, id'ed elements), and any relationship"

Good luck doing that for "FTP, SSH, whatever"

Don't be so sure that all of Linus' opinions are valid for all areas of programming, or even in all situations within the kernel.

I don't know what the OP's beef is. There's nothing semantically wrong or confusing about this.

However, for simple types like int and float, there's no performance advantage to passing the value as a reference. It generally takes as long to construct the temporary reference as it does to copy the value.

For more complex types like structures or objects, then yeah, you're better off passing by reference.

As far as this specific complaint goes, I've worked on large-scale C++ programs and I've rarely come across anything prohibitive as far as compile times are concerned. Granted, C is faster, as are some other languages, but in terms of overall project development time, compiling is dwarfed under requirements, design, coding, testing, collaboration, etc. It's a non-sequitur that improving compile time would have any overall impact on development.

It's unfortunate that Boost is an all-or-nothing set of libraries, and the meta-programming in there can be brutal to compile, so for that kind of platform you'd really need to weight the pros and cons of what you're using out of Boost vs. compile times.

However, building the library set and examples and tests is a one-time cost for the non-header-only libraries. And you don't need to compile the examples or the tests. Or the various debug-release combinations.

Plus, why wouldn't you cross-compile, anyway? I do lots of embedded sensor work and I wouldn't think of compiling anything directly on the hardware itself.

C++ isn't without it's age spots, but articles like this do nothing to give a balanced view of its usefulness vs. issues. Many languages have boasted to topple C++ and it hasn't happened it, mostly because C++ does its job well enough and other languages aren't better enough so that migrating large code bases is cost effective.

Speak for yourself. I use std::string frequently and there isn't anything awkward about it.

"I’d even argue that the main reason kernel code tends to be efficient is not because it’s written in C but because it’s written with parallelism and reentrancy in mind, by people who understand those issues."

It's used to build kernels because it doesn't require multiples of the needed RAM in order for the memory management to be timely.

Sometimes you don't want to suck up all of the RAM on a non-embedded machine, either. Also faster startup times and no collector pauses. A lot of times those are required.

I don't know if anyone else is going to read down this far, but I have something to say. The argument that outsiders need to understand the jargon is a red herring against the ultimate point. Even if someone took the time to learn the jargon and find some intelligent thoughts, there is also language purposefully designed to be unintelligible in order to conceal an absence of honest thought - this is regardless of the jargon.

I can do it with jargon you already understand, for example,

The totality of the colour blue is the sum of all of the integrals from one meta-point to another meta-point, formed in to spherical husk that can be opened by neither being within or without.

Even though those words are all well-established with their meaning, they are nonsense when strung together.