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

Taking C Seriously

subfurther.com

Post reply on HN
Print view View original

41–50 of 61 posts

Re: Taking C Seriously

#41

Post by xentronium »

angrycoder wrote: post #24
cageface wrote: post #17

Pure C seems to be enjoying a bit of language fad hipness lately but I don't know anybody that has to maintain a large body of non-trivial, low-level code that chooses pure C over C++. There's a good reason that everything from Solaris to V8 to Photoshop to Quake is written in C++ and not C. That C is still in wide use after 40 years is a testament to the elegance of its original design but let's not get carried away…

Quake was not written in C++. All of id's games until Doom 3(2004) were written in C.

I think, wolf 3d is C++ too.

Re: Taking C Seriously

#42

Post by strait »

malkia wrote: post #9
jonathansizz wrote: post #3

Those TIOBE numbers (linked to in the article) are quite interesting. As well as C refusing to go away, there's a noticeable surge for C#, Objective-C and Lua, and a substantial erosion in the popularity of trendy languages like Python and Ruby.

Lua is small and embeddable. You can run multiple independent instance of it in the same process. The lua table is a very useful data structure. Then you have luajit - also a small, easy to embed solution, that approaches standard "C" written code, and it's main weakness, from what I understood (Mike Pall had a post about it) is it's garbage collector. On top of that, ffi bindings make "C" calls extremely fast, when…

Using LuaJIT with minimal FFI C code to optimize, seems to be the best way forward in maximizing both performance and maintainability.

What would be really interesting is to see someone highlight specific cases where this approach ultimately fails to measure up in performance with using pure C.

I would think that the LuaJIT approach would be tens of times more maintainable for a sufficiently large application, so it's really imperative here that we ask 'Why not?'

Re: Taking C Seriously

#43

Post by wladimir »

pjscott wrote: post #16
onan_barbarian wrote: post #13

Earlier quoted context omitted.

Wow, talk about strawmen: > for a large, complex application a good GC will be more > efficient than a zillion pieces of hand-tuned, randomly > micro-optimized storage management vs: > Note that I said a good garbage collector. Don't blame > the concept of GC just because you've never seen a good > GC that interfaces well with your favorite language. Ok, so we're comparing 'state of the art GC' to 'zillion pieces of…

In other words, he's comparing what we're likely to get with a large C project and what we're likely to get in a modern garbage-collected environment. I don't think he's claiming more than that; where's the problem?

Having practical experience working at a company that has a large number of developers trying their stab at C, I'm bound to agree.

It's clear that you can make great code in C, if you're a good programmer and get enough time to plan things like memory management done right. Enough examples of that.

But when you don't, C is a terrible language. It is very verbose, it makes you repeat yourself and the macro system is so error-prone to the point that it's usually forbidden to use. So you have to resort to custom code generators (we have at least three!).

Most companies don't want to be in the business of worrying about buffer overflows and memory leaks and segmentation faults. They want the requested functionality implemented robustly ASAP. If there is less code to be written, there is less to test and worry about, so a high-level language that takes those concerns (largely) away is a great help.

So my advise would be to limit using C to the performance-critical parts (found using benchmarking), and only make developers work on that which understand every detail about C. Also, give them enough time to test every nook and cranny threefold.

Re: Taking C Seriously

#44

Post by mzl »

qdog wrote: post #14
derleth wrote: post #4

The problem is, nothing in this article even begins to address the actual criticism people have of C, instead saying that it's possible to write good C code and that Java is a memory hog. The first is true, the second is debatable, both as to whether it's the case and whether it matters. For example, read this: http://www.jwz.org/doc/gc.html > In a large application, a good garbage collector is more efficient than ma…

JWZ also states "Java and Emacs are really bad examples of GC-oriented environments." in that same article. And later, in 2000, he states "Today, I program in C." http://www.jwz.org/doc/java.html JWZ is an entertaining read, but unless he's updated in a post somewhere in the last 11 years, it isn't clear to me where he comes down on C at the moment. Btw, I program in C.

From the "Coders at Work" interview in 2009, JWZ says that he mostly writes Perl scripts for small one-off tasks, and every now and then a new screen-saver in C.

Re: Taking C Seriously

#45

Post by angrycoder »

xentronium wrote: post #41
angrycoder wrote: post #24

Earlier quoted context omitted.

Quake was not written in C++. All of id's games until Doom 3(2004) were written in C.

I think, wolf 3d is C++ too.

Why would you think that? That was their first FPS released way back in 1992.

If you are thinking of Return to Castle Wolfstein, that was C as well, using the Quake 3 engine. But id didn't even make that game.

Re: Taking C Seriously

#46

Post by comex »

pvarangot wrote: post #19
cageface wrote: post #17

Pure C seems to be enjoying a bit of language fad hipness lately but I don't know anybody that has to maintain a large body of non-trivial, low-level code that chooses pure C over C++. There's a good reason that everything from Solaris to V8 to Photoshop to Quake is written in C++ and not C. That C is still in wide use after 40 years is a testament to the elegance of its original design but let's not get carried away…

The Linux kernel, Subversion and PHP are pure C. And don't get me started on the BSDs or binutils... ld and libbfd are pure C and its C++ replacement (gold) is still not widely used. And this came without thinking about it... surely in two more minutes or by going to ohloh I could fire a couple more large bodies of non-trivial low-level C code at you.

> The Linux kernel, Subversion and PHP are pure C. And don't get me started on the BSDs or binutils... ld and libbfd are pure C and its C++ replacement (gold) is still not widely used.

Please pick gcc to mention or, indeed, any other C program ever written, before libbfd ;)

Re: Taking C Seriously

#47

Post by hesdeadjim »

psykotic wrote: post #22
cageface wrote: post #17

Pure C seems to be enjoying a bit of language fad hipness lately but I don't know anybody that has to maintain a large body of non-trivial, low-level code that chooses pure C over C++. There's a good reason that everything from Solaris to V8 to Photoshop to Quake is written in C++ and not C. That C is still in wide use after 40 years is a testament to the elegance of its original design but let's not get carried away…

All RAD's products are pure C at the interface level. Most of them are pure C at the implementation level, too. The one exception is that Telemetry (which I work on) uses C++ to implement the C interface, but only minimalistically.

I've had the pleasure of integrating your Granny SDK into our engine at the indie iOS shop I work at and it's been a total pleasure to work with and a perfect example of solid C interface design.

Now when can we get telemetry support? ;)

Re: Taking C Seriously

#48

Post by comex »

DiabloD3 wrote: post #6
zeteo wrote: post #2

>C was developed between 1969 and 1973, making it nearly 40 years old [...] C ha[s] already made an exceptionally good start on a century-long reign In all fairness, development continued past 1973. Most C programmers today would have some trouble even reading the code from the 1978 first edition of K&R; and the void* pointer, that the author refers to later in the article, was a part of ANSI C (~1990).

Development on C hasn't stopped. C1x is coming soon (probably 2012 or 13), and has a lot of interesting enhancements including bounds checking.

Bounds checking is just for library functions, and there isn't something like automatic array bounds checking, right?

Still, whoa -

    > #define cbrt(X) _Generic((X), long double: cbrtl, \
    >                               default: cbrt, \
    >                               float: cbrtf)(X)
Fun stuff.

Re: Taking C Seriously

#49

Post by bonch »

DiabloD3 wrote: post #5

I'm confused. Did C stop being taken seriously at some point? C is the only language that you can truly get things done without having to fight the language every step of the way. I can't say the same of... well, any other language I've used in the past 5 years.

> I'm confused. Did C stop being taken seriously at some point?

On social news sites, bashing C has been trendy for years. Bashing C++ was also trendy, but that has diminished somewhat since the new standard, and I suspect the same will happen for C. Basically, if something seems new and shiny, people like it more.

Re: Taking C Seriously

#50

Post by microtonal »

comex wrote: post #46
pvarangot wrote: post #19

Earlier quoted context omitted.

The Linux kernel, Subversion and PHP are pure C. And don't get me started on the BSDs or binutils... ld and libbfd are pure C and its C++ replacement (gold) is still not widely used. And this came without thinking about it... surely in two more minutes or by going to ohloh I could fire a couple more large bodies of non-trivial low-level C code at you.

> The Linux kernel, Subversion and PHP are pure C. And don't get me started on the BSDs or binutils... ld and libbfd are pure C and its C++ replacement (gold) is still not widely used. Please pick gcc to mention or, indeed, any other C program ever written, before libbfd ;)

But then, the new star (clang/LLVM) is written in C++.
Post reply on HN