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

251–260 of 394 posts

Re: The Unreasonable Effectiveness of C

#251

Post by jerven »

tlarkworthy wrote: post #29
skrebbel wrote: post #3

To nitpick on a single statement: > C has the fastest development interactivity of any mainstream statically typed language. What? Despite all its shortcomings, Java in a modern IDE effectively has zero build time. The level of interactivity is as fast as that of interpreted languages. I haven't seen anyone manage this with C yet.

C and Java both have terrible productivity loops because they have a tedious compile step. Python you just run after editing. I was more productive in python using a test editor the very first week I learnt it than I ever was in Java or C++ even with IDE support and years of experience. Google App Engine python dev server reloads modified python files whithout server restart . That feature blew my mind after doing Ja…

Yes modern java servers do this (if configured to do so of course).

Re: The Unreasonable Effectiveness of C

#252

Post by p0nce »

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…

But... you could have done it with a linked list!

Re: The Unreasonable Effectiveness of C

#253

Post by sramsay »

MichaelGG wrote: post #89
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…

Can you give me an example of a problem in Haskell, where the abstractions are so complicated you can't get your head around it, but putting it back in C makes it easy enough to deal with? A more plausible explanation is that you wouldn't even attempt a similar design in C because it'd be obviously impossible.

So, there are problems that are so complex that they can only be dealt with in Haskell?

That would explain why there are so few Haskell programs that anyone actually uses.

Re: The Unreasonable Effectiveness of C

#254

Post by _delirium »

tehwalrus wrote: post #206
makmanalp wrote: post #172

Earlier quoted context omitted.

Oh, yeah, definitely, I wish everything was as easy as "pip install". On the other hand, I can sympathize with nothing working on macs. This is because the environment plain sucks. All the installed tools and libraries are old as hell and rarely get updated, and it's riddled with quirks and tools that are subtly different on osx. I hear it's gotten better with Mountain Lion. Thank god for homebrew.

Macports is my tool of choice, but yes it's the only way to get things done! Unfortunately, plenty of scientific libraries are too obscure to be ported, leaving it to us scientists... Interesting what you say about 10.8 - I might give it a shot then. I will be upgrading soon from snow leopard (2009 MBP) and I was going to wipe and go debian/XFCE, because of all the "new ideas" like "let's not have save as" etc, but i…

I halfway solution I'm reasonably happy with is to have a VirtualBox install of Debian on top of OSX, and install most scientific libraries there. I've considered just wiping and installing Debian as the main OS, but when I first looked the Linux driver support for my MBP wasn't great, and since then I just haven't gotten around to it. VirtualBox works fine for anything that isn't too heavy duty, and anything heavy-duty I'm running on a beefier server machine anyway.

Re: The Unreasonable Effectiveness of C

#255

Post by abrichr »

luser001 wrote: post #175
abrichr wrote: post #88

Earlier quoted context omitted.

but what can you do... using namespace std; map > foo;

I used to do this. But then I realized I would be importing all symbols from std into my code. Including ones that might get defined in the future (similar to python's 'from foo import *'), which might conflict with some of my own symbols. Hence, I now implicitly import each symbol I need with something like 'using std::map;' (similar to python's 'from foo import bar, bar2'). I've found that the 'using' statement can…

Interesting; I never thought of that analogy to Python. I've just had it drilled into my head from everything I've ever read about C++ that "using namespace std" is terrible, and I shouldn't use it.

Great advice. Thanks!

Re: The Unreasonable Effectiveness of C

#256

Post by rayiner »

SeanDav wrote: post #109
madhadron wrote: post #53

Oh for heavens' sakes. Yet more ignorance. A more realistic view of C: - C is straightforward to compile into fast machine code...on a PDP-11. Its virtual machine does not match modern architectures very well, and its explicitness about details of its machine mean FORTRAN compilers typically produce faster code. The C virtual machine does not provide an accurate model of why your code is fast on a modern machine. The…

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…

The term "virtual machine" has several meanings, only one of which is what you're thinking of (something like the JVM or CLR). In the context Madhadron's using it, "virtual machine" means the abstraction of the hardware that the C compiler presents to the running program. E.g. it presents an illusion of sequential execution even on machines such as Itanium that are explicitly parallel at the hardware level. It presents the illusion of memory being a uniform array of bytes, when on a modern machine it's actually composed of several disjoint pieces.

CPU's and operating systems go to substantial lengths to present programs with a "C machine" on modern hardware. Your multi-core CPU doesn't look like a PDP-11, but it uses reorder buffers to make execution look sequential and cache coherence built on message passing to make memory look uniform.

Re: The Unreasonable Effectiveness of C

#257

Post by rayiner »

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".

Using the term "virtual machine" to refer to the "virtual PDP-11" that C exposes to programs is possibly older than the internet.

Re: The Unreasonable Effectiveness of C

#258

Post by sramsay »

pcwalton wrote: post #139
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…

What do you feel is too complex about Rust? The region system is obviously a source of complexity. But I feel as though sacrificing safety at compile time in the name of simplicity just leads to complexity later—you either pay the complexity tax at compile time, or you transfer the complexity of correct memory management to runtime, resulting in sessions sitting in front of gdb or valgrind.

I can't really disagree with what you're saying. But I take the point of the article to be that what makes development easy or hard is not as related to the feature set of the language as we think.

The common liturgy of language design is that x feature makes development easier, less error prone, safer, etc. Nearly always, the precise way in which x feature does this is as clear as a bell. But somehow, as we multiply the number of features, something truly destructive starts to happen. It's not just diminishing returns . . .

I think about a language like C++. I can see the reasons for every single thing in it. I can understand the arguments for why this or that is a good thing. But it is perilously easy to write very unmaintainable code in this language, and to understand why, I think we have to get beyond the usual debates (static vs. dynamic, functional vs. OO, compiled vs. interpreted, etc). Small vs. large might be one place to start.

Re: The Unreasonable Effectiveness of C

#259

Post by njharman »

> Faster Build-Run-Debug Cycles

Interactive languages blow anything with a Build-Run cycle away. "Faster" doesn't matter.

Having a Build cycle is not one of C's advantages. It is a trade off (and a good one, if you care about speed of execution vs speed of development).

Re: The Unreasonable Effectiveness of C

#260

Post by matthavener »

pjmlp wrote: post #246
dakimov wrote: post #225

Earlier quoted context omitted.

IntelliJ Idea for Java?

Yes. There are lots of refactorings that cannot be done by simple search and replace, even for C, because they require semantic knowledge of the language.

Very true, especially when you considering how many namespaces C has. In C++, its even harder.
Post reply on HN