Live data from Hacker News

Linus vs C++, again

realworldtech.com

161–170 of 209 posts

Re: Linus vs C++, again

#161

Because the Linux kernel is so important, and so difficult to replace, people will put up with whatever language inconveniences they must in order to get their contribution accepted. Therefore, I don't see Linus' choice as having any larger significance. I already know that C++ is a vastly superior language to C for small to medium scale programs where computational time+space efficiency is paramount.

Excuse me but C++ is only vastly superior of C if you are a C++ programmer and do not know C. I am a C++ programmer, and I would never make such a claim. And for time and space efficiency? That doesn't make sense.

Re: Linus vs C++, again

#162
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…

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…

ActiveRecord is godawful as soon as you want to use for something that wasn't in mind when people designed it. I'm working on a Ruby application that has to talk to a legacy database with composite keys and does so via ActiveRecord. Oh, the pain.

As others say in this thread: ActiveRecord makes easy/simple things very easy. Unfortunately, it makes harder things damn near impossible. To aggravate matters, people that only use it for what it was designed for, tend to blame you, instead of acknowledging that it may very well be that their favorite tool doesn't support a particular kind of use.

Re: Linus vs C++, again

#163
It makes a lot of sense if you think about it as optimising code readability for the case of seeing it through the lens of

  diff -pu -c 3
which is basically what Linus does all day. This also implies that the argument has little meaning in the context of projects that aren't comparable in scale (both code size and contributor pool size).

Re: Linus vs C++, again

#164

Earlier quoted context omitted.

Well, he did create git. Not that your point isn't valid, just pointing out Linus is actively helping forward progress.

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 might have dozens of branch points that are never referenced by name, but that doesn't mean they don't exist.

You can even consider the whole set of repositories for a single project as forming a logical DAG in this manner. However, because of the distributed nature of git, there will be branches that are not visible to you.

Given this, what does it mean to somehow "separate" the concept of repositories from branches?

Re: Linus vs C++, again

#165

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.

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.

Re: Linus vs C++, again

#166
post #150

Earlier quoted context omitted.

"a tool that make simple things easy" - thank you for this =)

I was quoting Larry Wall who said that a programming language should "make easy things easy and hard things possible". (Or something close to that... the internet seems a little uncertain on his exact wording.)

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.

Re: Linus vs C++, again

#167

There are so many large scale C++ projects that prove Linus wrong every day. One of them, you probably use it every day. hint: it's a search engine. Whatever language you use, you need rigor and diligence. You need to manage the project and follow up on developers. You need to agree on a subset of the language, that will become your local dialect. I'm pretty sure that Linus doesn't accept "any C source code". C++ has…

I would inject into your list of what really matters something Linus said: communication. Having each member of the team (1000 contributors to the kernel by Linus's estimation) in a different corner of the world is a huge consideration.

Re: Linus vs C++, again

#168

Earlier quoted context omitted.

Would a search tool other than grep change how you write code?

Probably not. I just said "grep" because it's such a basic standard, I really meant "easily searchable from a command line."

What about a syntax-aware search? If this were as responsive as grep, wouldn't that be better? I think so. I use one in Smalltalk all the time.

Re: Linus vs C++, again

#170
post #148
post #109

Earlier quoted context omitted.

> 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?

Probably operator() and passing classes that have this operator implemented around. For me it isn't better than function pointers, also because of method - function distinction we have 2 different incompatibile kinds of functions.

The operator() does not bring you any closer to functional programming. It's just syntactic sugar, maybe even nice sugar.
Post reply on HN