41–50 of 60 posts
This is great. Every developer should be familiar with writing C and how to hook into it from higher-level languages (Ruby, Python, etc). This is a VERY powerful combination. C isn't appropriate for everything these days, but it can kick ass and take names at very specific tasks that need performance or access to OS primitives.
C is not simple and brief for all things, though - for example, details of resource management leak across library interfaces, complicating things. Sometimes using C is a reasonable trade-off, sometimes not. Still, it's small and simple, and it's weaknesses are reasonably well known. It's a useful tool, though prototyping and exploratory programming are not its strong suit. I find I'm happiest working in a language t…
I think that what's particularly hard with C is not the details about pointers, automatic memory management, and so forth, but the fact that C is at the same time so low level and so flexible. So basically if you want to create a large project in C you have to build a number of intermediate layers (otherwise the code will be a complete mess full of bugs and 10 times bigger than required). This continue design exercis…
C just starts requiring these layers at a slightly earlier point in the abstraction continuum. On the other hand, the low-level abstractions are the easy ones: my experiences verify that in a medium-size project and up, with C you will have quickly built your own vocabulary and primitives and you get to the meat only a bit later than with some higher-level language.
I don't mean that C is all you need but that it's not the big problem in practice. I've seen so many large C projects where most of the code is about the problem domain itself and only a minor part is dedicated to overcome the C's lack of features and primitives.
I somehow recognize it as a good thing in C, forcing the programmer to build these layers early. You'll have to do that eventually and if you're so used to doing it already, you'll have more brain left for the actual problem itself.
I recently have concluded the same thing. I suppose all programmers reach that conclusion at some stage in their education. However, in context its pretty entertaining: a programmer explaining why C is better -- because for him, certain benefits of C outweigh certain deficiencies -- while simultaneously pointing out that programming is the art of manipulating data, which is largely an abstraction that lies above the particular representations in language X (well, mostly).
That being said, I thought he did a good job. I would have been proud to write this page.
The criticism of Java language is very much to the point (re: verbosity, inheritance). There's some confusion where he calls anonymous classes implementing interfaces "abstract classes with virtual methods"; that's not to say that it's not an awkward approach to closures and function pointers. There's also criticism of synchronized and the Thread class, but there's no mention of the strong points (Doug Lea's java.uti…
Honstly, OOP isn't that bad. This would be a lot better of a read if he focused on how C is good, not how he hates OOP. OOP is a valid way to solve any problem, though certainly not the only valid way. Incidentally I wrote an article in defense of OO: http://www.zideck.com/blog/article.php?id=1
> Well, not everything is an object. And I'm not talking about Java
> primitives, either, which should be objects. For instance, functions
> are not objects in most languages, and when they are it is confusing.
> See Javascript for further info on how this doesn't work.
....
I stopped reading here. It works very well.
(how the heck do we do preformatted text on HN?)
Earlier quoted context omitted.
The problems of C are not a universally recognized truth. There are plenty of C programmers who believe that C is perfectly fine. Maybe the issue with C is just people misusing the language. /snark Whether a truth is universally recognized has no bearing on whether it is true, quite irrespective of what OO advocates believe or who/what they choose to blame. The big issue with C? It's tough to use correctly. The criti…
Perhaps because it isn't a coding issue, it is a design issue and the fact that advocates of any stripe tend to gloss over the problems with whatever they are advocating.
Honstly, OOP isn't that bad. This would be a lot better of a read if he focused on how C is good, not how he hates OOP. OOP is a valid way to solve any problem, though certainly not the only valid way. Incidentally I wrote an article in defense of OO: http://www.zideck.com/blog/article.php?id=1
From http://www.zideck.com/blog/article.php?id=1 : > Well, not everything is an object. And I'm not talking about Java > primitives, either, which should be objects. For instance, functions > are not objects in most languages, and when they are it is confusing. > See Javascript for further info on how this doesn't work. .... I stopped reading here. It works very well. (how the heck do we do preformatted text on HN?)
preformatted codeEarlier quoted context omitted.
This isn’t a blog post. It’s the preface to a longer work – contents at the left.
My comment should have read, "there isn't much good about C."
I think it's telling that the very first example to use dynamic allocation has a memory corruption bug. struct { int n; char c[0]; } *foo = malloc(16); /* sizeof(*foo) probably 4, so 12 bytes follow */ foo->n = 16; for(int i = 0; i n. oops. */ foo->c[i] = 'a' + i; } Not that I don't love C for terseness and power or appreciate the systems one can build in it, but seriously.
His warning against using #ifdef is also misplaced. I have written assembler (GAS) using the GAS x86 asm preprocessor to write portable x86/x86-64 assembly code in one file. Far simpler and shorter than writing the same code in two files. Basically, whenever he says "never" do something he means he doesn't like to do it. For example, his answer to not having a multi-level function break is a nested helper function. G…
Earlier quoted context omitted.
His warning against using #ifdef is also misplaced. I have written assembler (GAS) using the GAS x86 asm preprocessor to write portable x86/x86-64 assembly code in one file. Far simpler and shorter than writing the same code in two files. Basically, whenever he says "never" do something he means he doesn't like to do it. For example, his answer to not having a multi-level function break is a nested helper function. G…
I'm curious: are the standard IO functions that much more efficient than a mmap'd file? What makes you choose one over the other? I usually just use standard IO, unless I have a large file that might be randomly accessed by multiple processes. In that case I'll use a mmap. But, I don't code in C very much anymore, so I was wondering how much of a difference there really is.
Basically, there's a reason why it's called "standard" IO. Generally you shouldn't use system calls unless you are absolutely, 100% sure that your code will only ever need to work on one system.