Live data from Hacker News

The Unreasonable Effectiveness of C

damienkatz.net

271–280 of 394 posts

Re: The Unreasonable Effectiveness of C

#271

"C is a weak, statically typed language" Wouldn't that imply that a variable of one type could be coerced into another type? I would say C is strong typed...

int i; float f = *(float*)&i; I'm not saying you should do this, but you can. Or to use an example the author didn't regret: struct foo { int a; int b; int c; }__attribute__((packed)); void print(foo* f) { int *p = f; int i; for (i=0; i

Here's one I used in a GC implementation a while back. That last 'uint_8t obj[]' is used to hold the object that was actually allocated.

   struct meta_obj {
       meta_obj_type *next; // next object in our list
       mark_type mark;
       size_t size;
       gc_type_def type_def;
       uint8_t obj[]; // contained object
   };
Or another (contrived) example:

   struct obj_type {
       obj_type_enum type;
   };

   struct string_obj_type {
       obj_type_enum type;
       char *c;
   };
You start with a collection of obj_type pointers and cast them to the appropriate pointer type when you have identified the actual contained struct. Useful if you need to have a heterogeneous list of things.

Re: The Unreasonable Effectiveness of C

#272
post #86
post #71

Earlier quoted context omitted.

modern FORTRAN is absolutely horrific, to the extent that F77 is far more popular than more recent flavors (like F90 or F95). It suffers from the same types of problems that the author identifies in C++ and Java. As for standard library, I learned from K&R and have never been surprised by the library (insofar as I can reasonably predict what will happen, given the guidelines). I cannot say that about the C++ standard…

It's not about being surprised by the standard library, there are no surprises there, it's about being appalled by the standard library.

The overarching point in the erlang example is that the bug stemmed from something in erlang itself. C and the standard library are sufficiently documented and tested that there is no ambiguity. (Regarding the natural counterpoint on indeterminate expressions like I++ + ++I, the language specification is also clear on the nature of indeterminate forms)

Re: The Unreasonable Effectiveness of C

#273
post #86
post #71

Earlier quoted context omitted.

modern FORTRAN is absolutely horrific, to the extent that F77 is far more popular than more recent flavors (like F90 or F95). It suffers from the same types of problems that the author identifies in C++ and Java. As for standard library, I learned from K&R and have never been surprised by the library (insofar as I can reasonably predict what will happen, given the guidelines). I cannot say that about the C++ standard…

It's not about being surprised by the standard library, there are no surprises there, it's about being appalled by the standard library.

The overarching point in the erlang example is that the bug stemmed from something in erlang itself. C and the standard library are sufficiently documented and tested that there is no ambiguity. (Regarding the natural counterpoint on indeterminate expressions like I++ + ++I, the language specification is also clear on the nature of indeterminate forms)

Re: The Unreasonable Effectiveness of C

#274
C is the language that doesn't force any preconceived notions about how the world should work onto you. Sure, C strings are NULL-terminated by convention, but even that is something you can almost completely ignore if you want to build up your own parallel stack of software that does it differently.

It is for this reason that C (and sometimes C++) are what people use when they have a new idea about higher-level programming abstractions. With C, you can be totally free of other people's big ideas (and their associated costs/complications) and invent something new.

Anyone who wants you to give up C in favor of their language/framework/VM/runtime is selling their own vision for how the world should work. That's fine and sometimes buying in will save you a lot of hassle. But what they're offering was almost certainly written in C or C++. Essentially their pitch is equivalent to "I have written the last C program you'll ever need."

In the early 90s that was Perl. In the late 90s, Java. In the early 2000s, .NET, then Ruby, then fast JavaScript.

This history is an oversimplification of course, but the real question is: would you really prefer a history in which we had, at some point, decided that the current VM that was in vogue should become the new replacement for C? That we'd tailor all our hardware to it, and no future VM would be "native" but would have to run on top of a different VM?

C is the key to why we have general-purpose computers that can run a wide variety of different languages efficiently, and why programs that need to be particularly efficient can always drop down to lower-level programming to get extra performance.

Re: The Unreasonable Effectiveness of C

#275
If you're C code is portable then you've chosen the wrong language. C is best when assembly would have been appropriate but you want to write something in a more maintainable, higher-level language. C shines when you need to optimize for a specific operating platform.

Re: The Unreasonable Effectiveness of C

#276

The author's next love affair will be Go, and he won't be back. I see it as a very real successor to C. I have written about 6k lines of Go (on a project that I had previously written in C) and I'm deliriously happy with it (partly because its just more fun to write than C). Granted, you can't write a dylib or kernel, but it sounds like for the author's case it would be a good fit.

I am not sure about this. Every analysis of performance when it comes to Go shows it lagging behind even Java. It is simply not mature enough.

Re: The Unreasonable Effectiveness of C

#277

I'm a language design buff, so you might be able to guess my biases: FP is good, OO is bad, every language should have higher-order functions, yadda yadda. I finally decided to get a deeper knowledge of C, something I've been saying I "should do" for years. I'm learning it via Zed Shaw's Learn C The Hard Way and I'm very impressed by the language. It does what it does very well. I wouldn't use it for a complex web ap…

I'd be interested to hear what you think of D.

Re: The Unreasonable Effectiveness of C

#278
post #121

Earlier quoted context omitted.

well the thing is, it also works for std::vector , or std::vector , or anything you want. Last time I checked in C you'd have to either duplicate all your array code for each type or resort to something like void*. Only for that I'd use C++ (yes, you can use it without classes if you want).

Last time I checked in C, all pointer types where the same storage size. There's no need to define the same data structure multiple times by using templates. You just use casts.

[deleted]

Re: The Unreasonable Effectiveness of C

#279

I always get bashed for saying I like C++, but I genuinely don't get how C programmers manage without code like this: std::map > foo; One line and you've set up a nontrivial data structure with automatic memory management. No macro horrors (which are a diabolical way of implementing what C++ templates do well). Since you can code like C in C++, I'm not sure why more people don't use C-with-templates as a programming…

What is equally powerful about modern C++ (quite possible to make it work on C++98 as well) is the ability to have template methods that can dump out pretty-printed fully customizable (by overloading operator Yes, template programming is not something I am likely to ever figure out but these things only need to be built once, by somebody other than me.

Re: The Unreasonable Effectiveness of C

#280

Earlier quoted context omitted.

It doesn't matter, his description is still the same kind of nonsense in line with having a VM. I get the feeling that he thought the thing he meant to say is actually the thing he said.

Sorry, I don't see that. What he said is clear to me: The C virtual machine does not provide an accurate model of why your code is fast on a modern machine. He's saying that the abstraction that C provides has deviated significantly from the underlying hardware. Considering the kinds of hoops that modern processor go through, this is a valid point. And the above should answer the sibling's question, too.

He also said "C runs on many systems with noncontiguous memory segments but presents it as a single contiguous space." That is 100% false. In C, pointers to different objects are different. They're not even comparable. There is no concept of contiguous memory beyond that of a single array. Two arrays are not contiguous.
Post reply on HN