Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linus vs C++, again

realworldtech.com

Post reply on HN
Print view View original

171–180 of 209 posts

Re: Linus vs C++, again

#171

Post by jonsmock »

jshen wrote: post #136
cageface wrote: post #72

Earlier quoted context omitted.

Interesting question. To be honest I'm kind of on the fence with AR. It makes trivial SQL very simple but I find myself forced to drop down all the time into raw SQL for a lot of cases and I also find that AR queries with a lot of options (order, group, select, limit etc) aren't much of an improvement in readability or abstraction over the raw SQL. What's more, I finally gave up after a year of waiting for this prett…

" I also find that AR queries with a lot of options (order, group, select, limit etc) aren't much of an improvement in readability or abstraction over the raw SQL." This was how I felt when I first scratched the surface, but by using find(...) instead of raw sql you leave open other options for the future like using :include

I think a lot of this will improve with Rails 3's new query syntax. It looks a lot like LINQ for .NET.

Yeah, a lot of times you're using the same keywords you might use in SQL, but the new chainable extensions are really nice for building up queries and reusing common chunks (either in LINQ or in Rails 3)

I should note that this new relational syntax is provided by a library called Arel (http://github.com/nkallen/arel)

Re: Linus vs C++, again

#172

Post by JoeAltmaier »

forgottenpaswrd wrote: post #75
mojuba wrote: post #31

Earlier quoted context omitted.

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

Hard to understand? Really? write a block of data of size on bytes "bytes" on the file-pipe-network... pointed by the file descriptor "fd"?? It is extremely simple to understand, it makes a very simple thing, always right. I doubt you can make it simpler. I have been using this all my life for NFS-mounted file, pipe, network or local socket... Never had any problems, and I have done very complex things. Of course, in…

I've actually done this. Wrote an Infiniband kernel driver, in C++.

Overcoming the obvious difficulties, including "new" being a variable name in a library, there were no technical difficulties. (Had no one in history EVER written in C++ on linux before?)

The argument FOR C++ in the linux kernel is the same argument for using C++ anywhere else - object abstractions are useful. The project took far less time. The bugs were fewer. The code was of course more readable - because of the tremendous wealth of context that C++ provides thru strong typing.

C people argue its easier to use simple constructs, since they are instantly understandable. What is NOT understandable is WHY the code is putting an int into an array. Those types have no obvious meaning beyond the line of code they are in.

In an object-typed language, you CAN learn the scenery and rapidly become familiar with the object set. The argument above (write) is largely silly - right-click and GoToDefinition works in almost any IDE - yes there may be more than one possibility, the IDE will display them all. So navigation thru code is vastly simpler than grepping for names.

Anyway, in 18 months we had an Infiniband layer integrated into linux, not too hard. Had to invent fundamental kernel/user page primitives that were missing. Interesting to note: Windows had all the driver support we needed, didn't have to invent anything.

Re: Linus vs C++, again

#173

Post by matthavener »

Could Linux explain spinlock.h then? Depending on which type you give to the PICK_OP macro, it performs a different operation. Its basically a C template. Seems a bit weird to complain about type context specific code and then use it in one of the most important parts of the kernel..

Here's the code: #define TYPE_EQUAL(lock, type) \ __builtin_types_compatible_p(typeof(lock), type )

#define PICK_OP(op, lock) \ do { \ if (TYPE_EQUAL((lock), raw_spinlock_t)) \ __spin##op((raw_spinlock_t )(lock)); \ else if (TYPE_EQUAL(lock, spinlock_t)) \ _spin##op((spinlock_t *)(lock)); \ else __bad_spinlock_type(); \ } while (0)

Re: Linus vs C++, again

#174

Post by eps »

shin_lao wrote: post #153

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…

Main problem with C++ is non-technical. Based on some experience interviewing a dozen people a week for several months, C++ programmers tend to routinely overestimate their proficiency with the language, while C programers tend to have the opposite self-assessment. To put it differently - on average C++ devs are cocky, eveyone is a guru and C devs are basically modest.

Re: Linus vs C++, again

#175

Post by shoover »

dan00 wrote: post #156

It's right, that in theory I can't know what a C++ function call means. But that's also the case for C. In C I can assign a function pointer to a variable. When the function is called through the variable, than I don't know which function is called. Almost never the language is the problem, but their usage. There's always context, and the quantity depends mostly on the complexity of the software. And regardless which…

Interesting point about function pointers. Maybe Linus is saying (in many more words) to use virtual dispatch only in appropriate places but not as a basis for an entire language? He would be in disagreement with every language designer who has added some kind of first class dispatch or pluggable modules. Not that such disagreement would be surprising, but that seems to be what he's saying. He suggested looking to other languages for GC and concurrency support, but in that thread I didn't see any desire for dispatch or modularity beyond what C offers.

Re: Linus vs C++, again

#176

Post by shin_lao »

xpaulbettsx wrote: post #137

Let's put it this way without any subjectivity: every production kernel that you folks use every day is written in C. NT is, Solaris is, Darwin is, and Linux is. Not one production-level kernel that is in wide use as a general-purpose operating system uses C++. I don't believe that to be a coincidence. (Nitpicker's corner: Darwin's device tree subsystem is written in Embedded C++, an extremely cut-down version of C++…

That's perhaps because all these kernels were written before C++ exists? The first C++ standard is from 1998, and stable STL/C++ support is even more recent.

FYI : in NT many device drivers are written in C++

Re: Linus vs C++, again

#177

Post by shin_lao »

eps wrote: post #174
shin_lao wrote: post #153

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…

Main problem with C++ is non-technical. Based on some experience interviewing a dozen people a week for several months, C++ programmers tend to routinely overestimate their proficiency with the language, while C programers tend to have the opposite self-assessment. To put it differently - on average C++ devs are cocky, eveyone is a guru and C devs are basically modest.

I agree with you. I often interview people who consider themselves "C++ expert" but struggle to use the STL's algorithms correctly.

Re: Linus vs C++, again

#179

Post by eru »

johnyzee wrote: post #166
kscaldef wrote: post #151

Earlier quoted context omitted.

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.

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

Re: Linus vs C++, again

#180

Post by ramidarigaz »

eru wrote: post #85
ramidarigaz wrote: post #81

Earlier quoted context omitted.

I've been meaning to ask this for a very long time: What does the (2) mean? I see (n) in lots of descriptions of calls, but I've never found out what it means.

It refers to sections of the man pages. They are organized like this: 1. General Commands 2. System Calls 3. Subroutines 4. Special Files 5. File Formats 6. Games 7. Macros and Conventions 8. Maintenence Commands

Exactly what I wanted to know. Thanks.
Post reply on HN