Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Unreasonable Effectiveness of C

damienkatz.net

Post reply on HN
Print view View original

151–160 of 394 posts

Re: The Unreasonable Effectiveness of C

#151

Post by emeraldd »

sramsay wrote: post #63

I feel like I'm always trying to make this point to people, and doing so with far less eloquence. The fact that Katz is (a) an experienced and accomplished developer and (b) someone with very non-trivial experience with hot, hip, super-high-level languages should not go unnoticed. He's not some cranky old embedded systems programmer; he's doing thoroughly modern development. Someone the other day said that the great…

> When Java, or C++, or Erlang, or Common Lisp, or Haskell programming becomes unbearable, it's almost always because the chain of abstractions overwhelms the person building the system.

I ran into a bug in an XOrg driver for an old r128 card a few years back. (I think I have that combination right.) As I remember it, I spent several hours tracing through layer upon layer of C macros to even begin to get an idea of what the code was doing. The bug turned out to be part of a structure getting overwritten clobbering a part of a vertex definition with a color value due to a mix up in the size of the structure. (I'm forgetting the details on this and I can't remember the bug number off hand or I'd look it up.)

In any event, those layers of macros made it almost impossible to trace what the heck the code was doing without intimate knowledge of every part layer involved. I'd say chains of abstraction are more a feature of programming style rather than the language itself. Albeit, the language can ease the load a little.

Re: The Unreasonable Effectiveness of C

#152

Post by xyzzy123 »

madhadron wrote: post #104
DigitalJack wrote: post #74

Earlier quoted context omitted.

I'm pretty ignorant about this stuff, so please don't think I'm trolling. I'm confused when you speak of a virtual machine with regard to C... can you explain what you mean by this? I had to wikipedia the Burroughs machine. I guess the big deal is that it's a stack machine? It looks very interesting and I plan to read more about it. But I guess I don't understand why that is a hindrance to C. The JVM is a stack machi…

The Burroughs was a stack machine, but that's only the beginning. Look at how it handled addressing hunks of memory. Bounds checked memory block references were a hardware type, and they were the only way to get a reference to a block of memory. So basically, null pointers didn't exist at the hardware level, nor out of bounds writes to arrays or strings. Similarly, code and data were distinguished in memory (by high…

As a C programmer this is like watching virgins attempt to have sex. Normal people just write some code which does some sh*t and that's OK. We don't need to deeply reflect on whether it's cache optimal, because that will change next week. Just good clean C. When did that become a strange thing to do?

Re: The Unreasonable Effectiveness of C

#153

Post by gsg »

jbooth wrote: post #97
rootbear wrote: post #73

Earlier quoted context omitted.

Can you elaborate on your first point a bit? How, specifically, does C's machine model not fit current architectures well, aside from multiple cores. How is Fortran's model better?

C is based on a simplistic view of the computer as a turing machine (or von neumann machine, if you'd prefer). Since the 70s or 80s, CPUs have gotten a lot faster while memory access has only gotten incrementally faster. This means that CPU manufacturers have put an increasingly sophisticated caching system on the CPU die to speed up access to main memory contents. C's simple model allowing pointer arithmetic, aliase…

Aliasing is not really an architecture specific concern.

Furthermore the vast majority of languages allow free aliasing, differing from C in what things pointers are allowed to point at and not in the number of pointers which may point at them.

Re: The Unreasonable Effectiveness of C

#154

Post by digeridoo »

silentbicycle wrote: post #122
madhadron wrote: post #105

Earlier quoted context omitted.

No, I am referring to the virtual machine defined by the C language.

It may be less confusing to say "C's underlying model of computation".

What's so confusing about the term virtual machine? It's an abstraction of the underlying machine.

Re: The Unreasonable Effectiveness of C

#155

Post by geophile »

slurry wrote: post #148
geophile wrote: post #46

C/C++/Java. A programmer's version of Rock/Paper/Scissors. Ignoring pre-history (BASIC, FORTRAN, PDP-11 assembler, Z80 assembler, Pascal), I started out in C, many years ago. I found myself using macros and libraries to provide useful combinations of state and functions. I was reinventing objects and found C++. I was a very happy user of C++ for many years, starting very early on (cfront days). But I was burned by th…

> Ignoring pre-history (BASIC, FORTRAN, PDP-11 assembler, Z80 assembler, Pascal) A side effect of C universalization, especially with open source, is that people forget all about that pre-history. Hacker culture now is mostly C/Unix with a dash of Lisp and Smalltalk heritage. But from what I remember of microcomputer culture in the early 80s, hackers in the field were doing line-numbered Basic and Assembly language -…

SNOBOL. I loved SNOBOL. A completely bizarre, very powerful language. I took two wonderful compiler classes from R. B. K. Dewar, who worked on the Spitbol implementation. He was also involved with the SETL language, which really impressed me.

Re: The Unreasonable Effectiveness of C

#156

Post by AshleysBrain »

jmaygarden wrote: post #91
AshleysBrain wrote: post #31

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…

Does that actually compile in C++11? I haven't used C++ in a while, but you used to need whitespace to separate the two closing angle brackets (i.e. ">>" should be "> >"). Personally, I use C for my embedded work and Python for test applications and data processing. C++ is in the middle and I haven't had a use for it.

A few compilers even before C++11 treated >> in template definitions as expected (e.g. VS2010) even though it wasn't standard, then the C++11 standard officially made it required. So I haven't found the >> thing to be a problem for a while now.

Re: The Unreasonable Effectiveness of C

#157

Post by SeanDav »

eropple wrote: post #117
SeanDav wrote: post #109

Earlier quoted context omitted.

Madhadron, you make a lot of claims but provide no detail. Also using terms like "virtual machine" with respect to C is plainly ridiculous and a case of bullshit baffles brains. Turbo Pascal vs C? Really? In its time Turbo Pascal was an amazing piece of software but in the grand scheme of things it is a pimple compared to the whale that is C. Please compare all software written in Turbo Pascal as opposed to C if you…

> Madhadron, you make a lot of claims but provide no detail. Also using terms like "virtual machine" with respect to C is plainly ridiculous and a case of bullshit baffles brains. C as a very thin virtual machine is a common conception and not an incorrect one--C runs on many systems with noncontiguous memory segments but presents it as a single contiguous space, for example. The idea of C as a virtual machine is muc…

> C as a very thin virtual machine is a common conception and not an incorrect one

I have worked extensively in the past with C and have never heard it referred to as a virtual machine, thin or otherwise. I understand that the OP probably means "computation model" or something similar but felt that the use of the phrase "virtual machine" was a bit on the bombastic side and that in addition to the general tone of the post made me think the post was borderline trolling.

BTW. I would be quite happy to be proved wrong about C commonly being referred to as a thin virtual machine - what books/literature refer to C in this way?

Re: The Unreasonable Effectiveness of C

#159

Post by cube13 »

eropple wrote: post #126
silentbicycle wrote: post #122

Earlier quoted context omitted.

It may be less confusing to say "C's underlying model of computation".

Given the way that LLVM has come onto the scene, I'm not sure I'd agree. C defines assumptions in the programming environment and does not guarantee that it at all resembles the underlying hardware. You are never coding to the hardware (unless you are doing heinous magic), you're coding to C. That's a "virtual machine" to me. The concept of C as a virtual machine isn't new (I first heard it around 2006 or so? I don't…

It's more descriptive, but somewhat incorrect.

The common definition of a process virtual machine is that it's an interpreter that can be written to that essentially emulates an OS environment, giving abstracted OS concepts and functionality. This aids with portability. Another concept of virtual machines in general is, for lack of a better term, sandboxing. You're limited to only the functionality that the VM provides.

C goes halfway with that. You generally don't need to care about most OS operations if you're using the standard library(which abstracts most OS calls), but you definitely do need to care about the underlying OS and architecture if you're doing much more than that. Also, simple C definition doesn't allow for threads or IPC, both of which are provided by the POSIX libraries. You're also allowed to directly access the ABI and underlying OS calls through C.

The best example of C not really having a VM is endianness. If C had a "true" virtual machine, the programmer really shouldn't need to be aware of this. But everyone that's written network code on x86 platforms in C knows that you need to keep it in mind. Network byte order is big endian, but x86 is little endian, so you need to translate everything before it hits the network.

EDIT: I think LLVM is somewhat of a red herring in this context. Realistically, unless you're writing straight assembly, there's nothing stopping anyone from writing a VM-based implementation for any language. The problem with C and the other mid to low level languages is that if you're writing the VM, you need to provide a machine that not only works with the underlying computational model, but also provide abstractions for all the additional OS-level functionality that people use.

So C could definitely become a VM-based language, especially if the intermediate form is flexible enough.

Re: The Unreasonable Effectiveness of C

#160

Post by AshleysBrain »

xamuel wrote: post #60
AshleysBrain wrote: post #31

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…

C guy here. I'm assuming you're serious and not being sarcastic... which is a nontrivial assumption, because that line you posted looks like something out of the foul depths of hell. You aren't going to run out of lines any time soon. Who cares whether your data structure definition is 1 line or 5?

Well, what I posted wouldn't be in a tidy codebase. You'd have something like:

    // foo.h
    typedef std::map> StringToVectorString;
    
    // foo.cpp
    // in several places you can just use:
    StringToVectorString foo;
Post reply on HN