Regarding C and C++ I sometimes think of them like this:
If you want a language that's like C but better, tough, just use C.
If you want a language that is better than C, do not use C++.
Linus vs C++, again
61–70 of 209 posts
Re: Linus vs C++, again
#62Linus has a touch of what I think makes Steve Jobs great: the ability to say no and stick by those convictions. No argument from me that Linux is wildly successful and one of the most important tech developments in the last 10 years. However, I always cringe when I read some of his comments that seem to reject any element of forward progress. While C++ certainly has its share of issues, Linux will never evolve if the…
It is very silly to say that something is bad because it started a long time ago. I do not see how any of the modern languages of the 21th century would be even remotely suitable to write an OS kernel with. Considering that most of those languages are at least partially interpreted and require GCs, a kernel written in them would be painfully slow. Just because something is old does not mean it is worse, and just beca…
>. I do not see how any of the modern languages of the 21th century would be even remotely suitable to write an OS kernel with.
Not true. You just have to be smart enough to implement the stack and structure properly. Have a look at some of the experimental operating systems out there. Singularity is especially worth a look.
Re: Linus vs C++, again
#63Earlier quoted context omitted.
No, what he means is that something like foo * bar; Can mean two different things. If foo is a defined type (typedef int foo, for example) then that declares a variable bar of type foo. If it is not, then we're multiplying variables foo and bar.
Yes, that is context-sensitive, but it's pretty tame. First of all, if I look at that, I can tell it's probably a pointer. After all, it doesn't make much sense to multiply two variables and then not do anything with the result, does it? On the other hand, it can mean a variety of things in C++. Are we multiplying numbers? Is foo or bar an instance of a class that has the * operator overridden? Is there a global over…
But in a well-written program the use of overrides would make sense. Just as much as this function:
ExitProgram();
should be clear in the context of a program. Now it's possible that this function actually creates a new process that then plays tic-tac-toe. But in a decent program, it will do its best to be consistent with what you expect. Likewise, if I see A * B, I expect that we're multiplying A and B. What does multiplication mean? Depends on the application, but I expect it to make sense.
And with a decent IDE you should easily be able to get the def for the '*', just like you'd get the def for any other function.
The problem isn't in the C++ language, but rather the C expectation that many developers have.
Re: Linus vs C++, again
#64> 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++-…
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.
Perl does this, Perl 6 especially.
Re: Linus vs C++, again
#65Even if the Linux kernel were rewritten in Erlang and it won't change the fact the vast majority of *NIX systems level code is entrenched in C. The most popular LAMP stack ingredients are also written in C. Face it; it's a good language.
Re: Linus vs C++, again
#66"And the best way to avoid communication is to have some
"culture" - which is just another way to say "collection of
rules that don't even need to be written down/spoken, since
people are aware of it". Sure, we obviously have a lot of
documentation about how things are supposed to be done,
but exactly as with any regular human culture, documentation
is kind of secondary."
This is so true - I have zero problems with context sensitivity and difficulty reading C++ if its all consistently done according to my prefered standards (which I mostly inherited from an especially well managed employer), avoiding the "bad practices" that introduce these problems like namespaces and such. Yet if I dive into some poorly organised and written code I can easily spend a whole day debugging a trivial problem - simply because the time is wasted trying to understand what is happening.
The sad truth is that the latter case is more common - its not C++'s fault though (although it could just /not/ try and provide every imaginable feature) - its more bad management than anything else. Though I can't help but wonder if that is just unavoidable for inherently difficult to manage projects like this...
Re: Linus vs C++, again
#67Earlier quoted context omitted.
As with most things, there are tradeoffs. If the expressive code was written with a good level of abstraction, it should be pretty straightforward to figure out what it does. Of course, it means that you need to understand those abstractions before you understand the code, and you might have to do more jumping around to figure them out. But in the long run, it makes it much easier to remind yourself how certain featu…
If the expressive code was written with a good level of abstraction, it should be pretty straightforward to figure out what it does. Abstractions are necessary, of course, but they also leak. Good judgment in these issues is one of the hallmarks of an experienced programmer. I'm just finding in my own code that I'm gravitating towards less abstraction, not more. Clojure in it's current incarnation is a great example…
Gotta disagree.
Good stack traces are about the maturity of the compiler and tool support- they have absolutely nothing to do with clarity of the language. Clojure is simple and Clojure opts for explicit context over implicit context almost everywhere (dynamic binding being a big exception)- this is exactly what Linus argues for. All you have in Clojure are functions and values - how much straightforward can you get? No objects, no hidden behaviors, no private variables, everything in namespaces, etc.
After two years of hacking on Clojure, I haven't really found macros to obfuscate anything. But that's because I learned not to use them unless I need them.
But, yeah, I'm looking forward to the community growing and providing better error messages and tools for deciphering raw Clojure stacktraces.
Re: Linus vs C++, again
#68Wow, Linus is getting older : he didn't flame the poor guy down.
I feel a bit concern that Linus don't write code anymore but still decide on how code is written, etc... Happily, he has some experience.
Linus has good reasons, nobody is going to rewrite linux in C++ anyway, this has been debated to death.
Why I am still loosing my time commenting on this ?
Re: Linus vs C++, again
#69As I get older and grumpier I tend to appreciate Linus' point of view more and more. It's easy to get swept up by arguments of the expressiveness of a language, particularly in small examples. However, I think in the long run it's better to have very explicit code. The less jumping around and inference I have to do to figure out what a block of code does the more likely it is that I understand it and that I can quick…
How do you explain the success of ActiveRecord? Do you think it's illusory? The exception that proves the rule? Something else? http://blog.objectmentor.com/articles/2009/07/13/ending-the-... "The fact that it took decades for the industry to arrive at something as useful as ActiveRecord in Rails is due primarily to the attitude that some language features [in this case, meta-programming] are just too powerful for ev…
I think ActiveRecord has exactly the sort of problems that Linus describes, when you get to large codebases and large teams. For example, what does 'save!' do? Well, it doesn't just update the row in the database; it also runs any validations on the object, and any before/after validation/save hooks. So, in general, you need that context to know whether a patch that updates something is correct or reasonable. And if you've got any triggers in your DB, there's a whole other area where something unobvious might be happening.
There's also lots of subtle ways for the DB and a particular object or set of objects in memory to get out of sync and cause hard-to-understand bugs.
ActiveRecord is definitely one of those tools that "make easy things easy". But, at the same time, it's not hard to get overly clever and make a mess with it as well.
Re: Linus vs C++, again
#70I've seen some pretty clean C++ code and some ugly C code. I think what's important is how a programmer use a language rather than what language he uses. I mean, if someone enjoy writing clever one liners, he/she will probably do it in all languages, might it be Perl or C. However, the important point here is that C does a good job and the programmers are used to it and like it. THEY, people that submit patches, like it, period.