Live data from Hacker News

Taking C Seriously

subfurther.com

21–30 of 61 posts

Re: Taking C Seriously

#21
Saying that "TIOBE rankings are at least the best system we currently have" for gauging uptake of a programming language is like saying that astrology is the best system we have for predicting the future.

Re: Taking C Seriously

#22

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.

Re: Taking C Seriously

#23

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, Quake II and Quake III are C.

Re: Taking C Seriously

#24

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.

Re: Taking C Seriously

#25

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…

Solaris is written in C. Same is true for all BSDs, PostgreSQL, nginx and a lot of other high-quality software.

Re: Taking C Seriously

#26

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.

"Subversion"

And don't forget Git! ;)

Re: Taking C Seriously

#27

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…

http://www.tarsnap.com/kivaloo.html

The author is pretty active here on HN. Very well documented design and goals. Also well documented for what problems it does not solve.

I think around 20k LOC. Seems pretty non-trivial.

Re: Taking C Seriously

#28
post #18

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…

>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. How about the Linux kernel?

And all the BSDs.

Re: Taking C Seriously

#29

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…

You subverted your argument by including the term 'low-level'. Of course, that's all written freshly in C to this day.

Assuming that you meant only 'non-trivial': aside from the embedded space, C and GCC still represent the first-tapped resource in many companies. C is terse, well-known, fast and predictable.

I'd go marginally further and claim that, done correctly, gmake and a proper directory hierarchy remain the most effective way of organizing and maintaining a large software project.

Re: Taking C Seriously

#30

Saying that "TIOBE rankings are at least the best system we currently have" for gauging uptake of a programming language is like saying that astrology is the best system we have for predicting the future.

It would be interesting - but a lot of work - to add "time to modify" and "time to debug" metrics.

Each task would come with a modification, and an error to make in implementing the original task. You'd recruit undergraduates, who hadn't used the language before. Some would be given the original program to modify, others the broken version to fix. You'd measure how long they took to do it.

This way, language communities that gamed the machine benchmarks would pay a price on the human ones.

Post reply on HN