Live data from Hacker News

Linus vs C++, again

realworldtech.com

31–40 of 209 posts

Re: Linus vs C++, again

#31
post #9

As 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…

   write(fd, buf, size);
Can you list all the caveats, possible side effects, reasons of failure of this simple C function call? Hint: remember, fd can be a file, as well as a NFS-mounted file, pipe, network or local socket, FIFO, device, etc. Hint2: I doubt anyone can give a comprehensive description of the possible consequences of this call.

Bottom line being, C can be incredibly hard to understand, or C++ can be clean, succinct and straightforward. Personally, I'm for the second, although I know probably 99.9% of all existing C++ code is just awful.

Re: Linus vs C++, again

#32
post #13

C as a context free language? Bullshit. How many global variables are there? How many functions with ridiculous names like htons? Edit: I realize that "context free language" was a poor choice of words; i meant it in the sense that linus did - his claim that you can 'look at a piece of code and understand what it does' is laughable in the face of accepted c programming styles.

I'm not really sure you understand what a context-free language[1] is. I suppose global variables can be seen as being context-sensitive, but functions with weird names definitely don't qualify a language as context-sensitive. [1] http://en.wikipedia.org/wiki/Context-free_grammar

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.

Re: Linus vs C++, again

#33
post #20
post #14

Earlier quoted context omitted.

Linux is FOSS, so if there are huge benefits to using C++ then the people who advocate such things should simply take the tree, fork it and start doing some C++ stuff. If their arguments are correct it should soon be fantastic and much better than Linux. Also, there is nothing wrong with programming paradigms from the 60s as evidenced by the popularity of Clojure and other functional languages that borrow heavily fro…

The clojure analogy actually works in favor of them switching to C++. Clojure takes the good ideas of Lisp and bolts extra convenience (and modernization) on top, just like C++ adds extra convenience to straight C.

Clojure actually removes a lot of things from lisp. So it might not be a very good analogy to c and c++. For eg clojure doesnt have an object oriented framework like CLOS, does not have reader macros, currently has a much smaller set of inbuilt functions. Not to say it hasnt added new stuff, it has, eg persistent data structures, deep integration with the jvm. Also importantly all valid lisp programs are not valid clojure programs. In short, its a clean break from lisp which carries the useful ideas and the spirit of lisp forward.

Re: Linus vs C++, again

#34
post #4

Linus 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…

> Linux will never evolve Do you terribly mind elaborating on this rather bold statement?

Great way to edit my comment, what I actually said was:

> Linux will never evolve if the programming paradigm stays in the 60s

C is a great language, but I firmly believe that OOP creates more maintainable code that is more robust. Sure, a simple C program is easy to understand, but the kernel isn't an easy program. Don't get me wrong, C++ has major downsides, but C isn't a magic bullet.

Re: Linus vs C++, again

#35
post #21
post #4

Linus 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…

From linus's post - "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, documentationis kind of secondary." He seems to suggest that s…

I don't think anyone can surprise us with something big now. It was easy to come up with a new, revolutionary OS in 80s/90s - you could write one yourself. Right now, anyone writing an OS for the OS itself (not for research) has failed before they start (unless they've got a large experienced team and loads of money to burn). You have hardware you cannot easily access, loads of applications you cannot make a compatibility layer for, etc. etc.

When you created a lisp machine, it was a lisp machine - everyone knew why and how you did it (to some extent). If you wanted to run it, you ported "the program" to it and all was good. Right now you have users expecting at least the stuff they can get from other popular systems - and that's years of work away for any new project.

The best you can probably do, as far as "progress" goes is to create a new research system and port the good stuff back to mainstream (singularity, plan9, etc.)

To some extent we know all there is to know right now... New languages, periferials, usage ideas are still created. But for a new system language you need to either create or port a system and gather some followers. That's a big step.

Edit: Actually I believe that there's a new hardware change coming that will make current computers ineffective in some way. We could switch to new hardware, new languages, new systems... we could start from scratch :) I don't believe the current ways of parallelising computation can do that.. but if someone constructs a concurrent bus/memory/cpu that could invalidate some of the normal programming ideas.

Re: Linus vs C++, again

#36
post #24
post #20

Earlier quoted context omitted.

The clojure analogy actually works in favor of them switching to C++. Clojure takes the good ideas of Lisp and bolts extra convenience (and modernization) on top, just like C++ adds extra convenience to straight C.

C++ is not just C with extra stuff. C++ programming and C progamming are different enterprises. The Linux kernel is full of all sorts of explicit "this block of memory is a struct txaz_fooblock and here's how we link them together" that C++ programmers simply don't write. This is before you even get into things like the template-y standard C++ library.

Agreed. C++ is more like Bjarne Stroustrup bolts everything he's ever heard of onto C than "C with classes".

Blatantly plagarized from: http://www.cvaieee.org/html/humor/programming_history.html

Re: Linus vs C++, again

#37

That is a huge problem for communication. It immediately makes it much harder to describe things, because you have to give a much bigger context. It's one big reason why I detest things like overloading - not only can you not grep for things, but it makes it much harder to see what a snippet of code really does. I think this is a limitation of our using flat text to program in. So long as our primary means of communi…

I came here to quote that same piece, but for a different purpose. I am in complete agreement with him.

I think writing grep-friendly code is a good thing. I do my best to make all my Perl code easily grepped, it just makes debugging infinitely easier.

Re: Linus vs C++, again

#38
post #13

C as a context free language? Bullshit. How many global variables are there? How many functions with ridiculous names like htons? Edit: I realize that "context free language" was a poor choice of words; i meant it in the sense that linus did - his claim that you can 'look at a piece of code and understand what it does' is laughable in the face of accepted c programming styles.

I'm not really sure you understand what a context-free language[1] is. I suppose global variables can be seen as being context-sensitive, but functions with weird names definitely don't qualify a language as context-sensitive. [1] http://en.wikipedia.org/wiki/Context-free_grammar

I think he means that many global variables create a big context. Which as you point out, it is not the same as context sensitive.

Re: Linus vs C++, again

#39
post #13

Earlier quoted context omitted.

I'm not really sure you understand what a context-free language[1] is. I suppose global variables can be seen as being context-sensitive, but functions with weird names definitely don't qualify a language as context-sensitive. [1] http://en.wikipedia.org/wiki/Context-free_grammar

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 overload of the * operator? Are we declaring a pointer?

Re: Linus vs C++, again

#40

> 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.
Post reply on HN