Linus vs C++, again • Hacker News Board

Re: Linus vs C++, again

#191

Post by Daniel_Newby » Fri, Jun 11, 2010, 8:04 PM UTC

eru wrote: post #109

Daniel_Newby wrote: post #51

This rings hollow. It's like saying "C++ feature X can go horribly wrong when used without adult supervision, therefore C++ is unusable." This is especially silly coming from someone who favors a professional stunt language like C. If somebody uses too much overloading, reject their patch. If somebody makes a template tarpit, abuses operator(), or gets too fancy with operator overloading, send it back to 'em. Context…

> Polymorphism also gives you what amounts to functional programming without touching C's awful function pointer syntax. Which aspects of functional programming are you talking about?

> Which aspects of functional programming are you talking about?

Passing around things that do work on other things -- easy with C++ worker objects, painful with C function pointers (or worse, pointers to structs full of function pointers).

Re: Linus vs C++, again

#192

Post by orblivion » Fri, Jun 11, 2010, 8:47 PM UTC

eru wrote: post #179

johnyzee wrote: post #166

Earlier quoted context omitted.

I usually hear it in the form of a denouncement of tools that "make easy things easier and hard things impossible". I think that perfectly describes a bad abstraction layer.

Haskell is claimed to make hard things easy, and impossible things happen. (Though, who knows, perhaps easy things will become impossible with it?)

Not before making easy things hard, though.

Re: Linus vs C++, again

#193

Post by tbrownaw » Fri, Jun 11, 2010, 9:05 PM UTC

chousuke wrote: post #164

tbrownaw wrote: post #101

Earlier quoted context omitted.

Not sure I'd call intertwingling the repository/workspace like that, or conflating branches and repositories, "progress". But I suppose it's better than svn/cvs/etc that it's largely taking its users from. (disclaimer: I work on a VCS that's written in C++ and uses a real database, nice object-oriented libraries, and nice C++ abstractions :)

The repository/workspace issue I can agree with (though there is an environment variable that you can use to specify a repository outside the current directory), but what do you mean with "conflating branches and repositories"? In git, branches are not a special entity. They are a property of the contents of the repository. The commits form a DAG, which is also a tree, and trees often have branches. A repository migh…

Perhaps a better way of saying that would be that they picked a very unique (re-)definition of what a branch is (something like "pair").

I tend to think of a branch more as "a buch of commits that go together", which seems to fit very nicely with common usage where you have a release branch, dev branch, etc. It just seems very bizzare that people working on the "dev branch" are actually working on entirely separate branches just because they're in different offices which use separate local mirrors in case the internet breaks.

Re: Linus vs C++, again

#194

Post by henry_flower » Fri, Jun 11, 2010, 10:14 PM UTC

Is that Linus post originally comes from some mail list? What is the name of the list? (google gives me only links to realworldtech, which is weird)

Re: Linus vs C++, again

#195

Post by sanderjd » Fri, Jun 11, 2010, 11:33 PM UTC

varjag wrote: post #165

tptacek wrote: post #110

Earlier quoted context omitted.

That's a true and valid argument but beware that any C++ advocate could knock it down by saying "then the kernel code standard should reject things like that".

And when you reject things like that you end up with C anyway.

Meh, this is a straw-man. Conventionally rejecting overridden -> and () operators is a very long reach from ending up back at C. Disallowing operator overriding in general (as opposed to specific operators), namespaces, and classes would be much closer, and it still wouldn't be all that close to C (reinterpret_cast, templates...) There is a goodly sized amount of gray area between the two. Or did you mean your "things like that" to be much broader than my interpretation?

Re: Linus vs C++, again

#196

Post by Daishiman » Sat, Jun 12, 2010, 1:55 AM UTC

ComputerGuru wrote: post #62

hristov wrote: post #43

Earlier quoted context omitted.

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.

Yes, and still hasn't solved its performance problems that span all of the OS's functionality. Performance is something we might not care about at a high level, but on a kernel it's a first priority, and a very difficult problem to solve.

Re: Linus vs C++, again

#197

Post by Daishiman » Sat, Jun 12, 2010, 2:01 AM UTC

yock wrote: post #182

I'm immediately skeptical of people who think modularity, inheretance, and polymorphism are a bad thing. Linus never comes out and says as much, but by indicating that he doesn't want to jump around to learn how a bit of code works he's implying it by desiring as few dependencies within code as possible. I certainly apprecate Linus' genius and the revolution he brought to computing, but we live in a different world t…

Who said C isn't modular? You're confusing language features with programming paradigms. C can and is modular and flexible. Objects are not just a language construct A struct with corresponding functions is just as much of an object. And he didn't claim those were bad things. He claimed that the context dependency, the massive size of the language, the different implementations, etc., contribute to an environment that's not good for kernel development. On that count, I must agree.

Re: Linus vs C++, again

#198

Post by wvenable » Sat, Jun 12, 2010, 2:19 AM UTC

NickPollard wrote: post #160

wvenable wrote: post #107

Earlier quoted context omitted.

C++ is one of the few languages where in "foo->perform()" the -> and () can be something completely different than what you expect. There's almost nothing in that simple statement you can be completely sure of.

They can be, but they shouldn't be. Operator overloading is useful when you want to do something that is semantically similar but implementationally different. Even mathematics has different processes for the same operators on different types. If you see 'a * b' you should be able to assume that it's multiplying two variables, but if those two are real numbers it's different than if they're two matrices of real numbe…

The STL overrides the bit shifting operators for output and the deference operator for accessing the current item in iterators.

Re: Linus vs C++, again

#199

Post by eru » Sat, Jun 12, 2010, 4:34 AM UTC

orblivion wrote: post #192

eru wrote: post #179

Earlier quoted context omitted.

Haskell is claimed to make hard things easy, and impossible things happen. (Though, who knows, perhaps easy things will become impossible with it?)

Not before making easy things hard, though.

You get used to it. The stuff that's easier in other languages than in Haskell is mostly done by hiding distinctions.

Re: Linus vs C++, again

#200

Post by jpr » Sat, Jun 12, 2010, 6:05 AM UTC

Xurinos wrote: post #185

jpr wrote: post #142

Earlier quoted context omitted.

Lisp-1 vs Lisp-2 is about whether functions and other variables are in the same namespace or not. Packages are orthogonal to this. Also, generic functions in Common Lisp don't suffer from nearly the same amount of complexity as can be found in C++: there is always only one signature (lambda-list) for any function name, whether generic or not, there are no implicit conversions, no memory-allocation details, value/poin…

By your wording, aren't CL packages considered to be just an implementation of a namespace? Is there another way to declare symbol namespaces in CL (outside of rolling our own organisms)? I was under the impression that the function signature was not the issue raised... but the fact that the same function name could lead to completely different behaviors depending on a context. In the case of generic functions, the s…

Finding a method definition is quite easy in CL: just use the function 'find-method':

http://www.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Bod...

Though grep would probably do just fine too, since method definitions are defined with 'defmethod' instead of 'defun', so you can see at a glance whether something is generic or not.