Live data from Hacker News

Taking C Seriously

subfurther.com

31–40 of 61 posts

Re: Taking C Seriously

#31
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).

Definitely. Occasionally I'll run across some code in an old program (eg: Emacs), and be utterly unable to read it, because it's an older dialect of C (that I'm surprised most compilers still accept). I'll have to dig out a copy of K&R first edition just to read the code.

Re: Taking C Seriously

#32
post #10
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…

Yeah, the article is just praise of the minimalist C style I guess. To elaborate, the actual problem with C is that you have to deal with ownership semantics manually. In languages with things like uniqueness typing or automatic reference counting that problem goes away. Common to all these languages and all GCed languages is the need for memory management--clearing references or maps or just generally indicating (wi…

Every time I think about writing anything substantial in C I think about manual memory management and error handling via error codes and I quickly shelve the idea.

Re: Taking C Seriously

#33

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…

Some good counter-examples but these are outliers. You can't seriously argue that the vast majority of big, high-performance apps aren't written in C++ and for good reason. Cubase, Photoshop, Maya, Renderman, Chrome, Java/JVM, virtually all A-list video games etc.

People have codebases that are millions of lines of code in C++ that I don't think would even be possible in pure C.

Re: Taking C Seriously

#34

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…

Something about most C++ code I've read makes me a little sad. It's a great language, but many features seem to be abused.

Re: Taking C Seriously

#35
post #14
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.

> it isn't clear to me where he comes down on C at the moment

At the moment, his main focus seems to be his bar, so perhaps he isn't the best person to ask about the relative merits of C versus modern garbage-collected runtimes.

Not really the point, though: The point is that blanket statements about the inefficiency of gc amount to superstition, and should not just be let stand.

Re: Taking C Seriously

#36
post #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 communit…

Yes, because untrained undergraduates are the programming workforce in every industry, especially aerospace and medical device makers.

Re: Taking C Seriously

#37
post #10

Earlier quoted context omitted.

Yeah, the article is just praise of the minimalist C style I guess. To elaborate, the actual problem with C is that you have to deal with ownership semantics manually. In languages with things like uniqueness typing or automatic reference counting that problem goes away. Common to all these languages and all GCed languages is the need for memory management--clearing references or maps or just generally indicating (wi…

Every time I think about writing anything substantial in C I think about manual memory management and error handling via error codes and I quickly shelve the idea.

Any time I think about writing anything substantial in a language with exceptions, I think about non explicit exiting from my function and I quickly shelve the idea.

Re: Taking C Seriously

#38

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've consulted in the past on embedded projects. In my experience, maintaining a non-trivial body of C++ code is easily a factor of 2-10x harder than maintaining equivalent C code.

I have lots of reasons why this is true, many of which are specific criticisms about C++. There is one issue that is industry specific: Everyone working in embedded has either come from the bottom up (deep firmware in assembly or machine code) or the top down (Java in school), and when you get a dozen people where half of them treat C++ like "C with classes" and the other half treats C++ like it's Java, it's a guaranteed disaster.

Re: Taking C Seriously

#39
post #15
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…

Zawinski's point is true iff "large application" means an application which allocates and frees plethora of tiny chunks -- however I will argue that this is not a necessity, rather a style coming from a try to port scripting experience to lower-level languages to speed up development. Probably in most cases this is not a problem (no one will notice 100us speedup in GUI), but if one starts to tweak GC or new to rescue…

Because then you have to control ALL of the memory, not just the data that you're interested in optimizing. Not to mention that (at least in the JVM) the gc is pretty tweakable, and the entire team may not need to know about all of the tweaks.

Re: Taking C Seriously

#40
post #36
post #30

Earlier quoted context omitted.

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

Yes, because untrained undergraduates are the programming workforce in every industry, especially aerospace and medical device makers.

Hello, "Enterprise"? Beam me up, there's no intelligent life here.
Post reply on HN