Taking C Seriously
subfurther.com
Taking C Seriously
1–10 of 61 posts
Re: Taking C Seriously
#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).
Re: Taking C Seriously
#3Those 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.
Re: Taking C Seriously
#4The 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 malloc/free.
My point isn't necessarily to disagree with the article, but to point out that the article has practically nothing to disagree with. It has no substance.
Re: Taking C Seriously
#5I'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.
Re: Taking C Seriously
#6>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.
Re: Taking C Seriously
#7I'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.
Perhaps a better title would have been "Don't take C for granted."
Re: Taking C Seriously
#8Whoa, that page is hard on the eyes....I didn't get far in that article, but I think C has continued to live on as well as a foundation that has spawned other great languages. I don't see it (or variations of it) going away anytime soon.
Re: Taking C Seriously
#9Those 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 the jit is active, and not very bad when the interpretter runs (but slower).
And the lua/luajit license allows you to embed it in your application, without the need to share source code.
Mike Pall is working on ppc, arm versions (and I think there might be already ppc jit).
Not last to forget - awesome community (comp.lang.lua).
Re: Taking C Seriously
#10The 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 (with the language's particular idioms) its lifetime. Sometimes in a GCed language all that ownership gets untangled for you for free, but this may actually be a maintainability hazard. A trivial change might suddenly start retaining objects forever. See Haskell, where a seeming perfect program may suddenly gain space leaks upon mere removal of, say, a print statement.
Some GC implementations might be faster in practice if they can move around memory and improve cache locality and reduce fragmentation. On the other hand, some introduce long collection pauses (often an issue with C# on XNA for example), and the default malloc() on many systems is very slow and tends to fragment. But "sufficiently smart" GCs avoid these issues.
Ideally the solution is a hybrid approach: for data with obvious lifetime (bound to a scope or a certain area of the program execution) you want to actually show those intentions in the code or types. For short-lived objects that you're working with or object graphs you want garbage collection. This is what generational GC simulates, but I always find it asinine to fiddle around with references (possibly having to null out) and deal with non-deterministic deallocation when the lifetime is clear. Sigh. One day.