Hacker News Reader

Comment by cobrausn | Hacker News Reader

So while C may be as lightweight as it can get, it's not really suitable for projects with more than 10k LOC.

I believe John Carmack would have something to say about this.

http://en.wikipedia.org/wiki/Id_Tech_3

There's a difference between being suitable and being the only alternative currently available given the other constraints. There's lots of big software written in C not because C is convenient or well-suited for writing that kind of software, but because performance trumped the other concerns. Particularly in 1995, when computers were slower and other language implementations were slower than they are today.

For that matter, libc is considerably more than 10 kLOC (on FreeBSD 9.0, it's about 140 kLOC), and it's hard to think of a more stereotypical block of C code than that.

It is stereotypical library but not stereotypical software project per se. Functions in libc have (by design) very strict interface and little data interdependency.

I would say SQL or HTTP server or game or a word processor where you have to retain sizable chunks of data in memory for longer periods is a better example of big C project. And that's where lack of automatic memory management and data abstraction in C makes it hard.

Oracle is written in C.

Isn't the linux kernel more than 10k lines of code, too?

And GIMP?

And numerous compilers and interpeters and other system-level software.

The author might be talking about consumer-oriented software, but still saying that C isn't suitable for large codebases is very presumptuous.

disingenuous was the wrong word

Or ignorant.

"And numerous compilers"

Like for instance, C compilers. Cripes that 10k figure is so absurd...

If you want to put forth the requirement that you and everyone else on your team must be as good as John Carmack, sure.

Do you honestly think everyone on the team that developed the id Tech 3 engine was as 'good as Carmack'? I don't think he wrote the whole engine by himself.

There was one other programmer who worked with Carmack on Quake 3, John Cash.

My point is, even having one Carmack level developer on a team is a bridge to far for most.

Yes, you can write huge projects using just C, but you honestly don't think most people would recommend it unless every little drop of performance was really that important or you had no other choice or you had a super guru with an amazing track record writing the software.

At the time Q3 was written (13 years ago), console games were still being written in assembly language.

Playstation 2 and Nintendo 64 games were written in assembly? Really? I thought C and C++ were common by then.

You are ahead of yourself by a few years. Q3 came out in 1999, which means it was written in the late 90s, so think PSOne and late SNES/Genesis titles.

Aside from the PS2, I don't think so. N64 came out in '96, Dreamcast came out in '98 and PS2 came out in early 2000. In '99, we were only two years away from Xbox and GameCube. I know that at least N64 games were written in C.

PSX games were often written in C, as well. I suspect that developers had started to migrate to C near the end of the SNES era, although I'm not sure how many SNES games were written in C...

Playstation 2 had it's own devkit that was C or C++ I believe.

But yes, N64 games were written in assembler.

My own project (FLINT) is about 120k lines, and we're still going with C. I did spend a lot of time looking for a theoretical higher level language which could take us further when C ran out of puff, but we eventually decided to stick with C for the main project.

However, I did eventually spot Julia, which is totally awesome for my own personal higher level needs.

For what it's worth, I've done a lot in Lua, dropping to C (on rare occasions) to offload heavy processing elements where a scripting language would choke. Many game developers do their interface and game scripts in Lua then run the engine in C as well. It keeps the C code light and clean and brings down the number of manhours required to build and maintain a project.

I don't know what FLINT is or what Julia is used for (Wikipedia makes it sound like a functional language?) so Lua might not be the best fit, but it's designed from the ground up to mesh with C (to the point where the solution to many otherwise simple things is "write that bit in C")

FLINT is a library for number theory: https://en.wikipedia.org/wiki/Fast_Library_for_Number_Theory

Lua is not suitable from my point of view due to the lack of proper integer types (and many other features).

I understand it's not for every purpose (and I have no stake in if you use it or not), but it can be metaprogrammed and extended with C. I'm not really a programmer in my day job though, I use it mainly for automation of things I don't want to do by hand.

"some people use C" does not excludes "some people think C sucks"

One might think C sucks and still use it. You might think it sucks, but it's still less bad than everything else. Using something doesn't necessarily makes you blind towards its drawbacks. I think a lot of the things I use everyday sucks. But I still use them because there's nothing better... yet.

All those programs written in C that everyone is posting about (quake, linux, gimp etc). Were written before Go existed. So it's very plausible that the authors could agree that C sucks if they had the option to write in Go. Which is the point of the article.

C NOT GOOD FOR LARGE PROJECTS?

          MAKE QUAKE-C

Though for Doom3 and on, they did switch to C++, which makes absolutely minimal usage of the language features, heh. I guess old habits die hard.

"they did switch to C++, which makes absolutely minimal usage of the language features"

This is true of almost every C++ project I've ever worked on. Unfortunately they all used a slightly different minimal set of language features...

I guess you never worked on boost.

On it? No. With it? Yes.. Unfortunately.

Reply on news.ycombinator.com