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

61–70 of 394 posts

Re: The Unreasonable Effectiveness of C

#61

Post by makmanalp »

shadowmint wrote: post #22

It also has a few downsides: - The build system is broken. vs. make. qmake. cmake. autotools. scons. 'modern' makefiles (>_> what does that even mean? Yes, I'm looking at you Google) There's a whole ecosystem of tools out there to solve this. - There are a few rubbish IDEs, most of which support c as a second class candidate. VS has officially abandoned C; xcode grudgingly supports it. The CDT is mediocre. There's li…

For the record, I found cmake to be the best. The output is great, the convenience is awesome, the only thing that bugs me is the strange syntax, which is fine because once you set it up it gets out of your way fine.

Re: The Unreasonable Effectiveness of C

#62

Post by guilloche »

My humble opinion: Scripting languages like python do have merits.

As a 20+ years C++ programmer, I sadly found there seems no scenarios that C++ can play very well. Compared to C, C++ projects are much harder to maintain. Whenever C++ should be used, C is always a better option.

Re: The Unreasonable Effectiveness of C

#63

Post by sramsay »

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 thing about C is that you can get your head around it. 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. And to be honest, it's why I'm a little less enthusiastic than most of the people here about Rust.

Re: The Unreasonable Effectiveness of C

#64

Post by larskinn »

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?

Foul depths of hell? I've never programmed in C or C++, but this seems to me to be a map from strings to vectors of strings. Reads easily. I don't like the :: namespace separator, but what can you do...

Re: The Unreasonable Effectiveness of C

#65

Post by kyrra »

shadowmint wrote: post #22

It also has a few downsides: - The build system is broken. vs. make. qmake. cmake. autotools. scons. 'modern' makefiles (>_> what does that even mean? Yes, I'm looking at you Google) There's a whole ecosystem of tools out there to solve this. - There are a few rubbish IDEs, most of which support c as a second class candidate. VS has officially abandoned C; xcode grudgingly supports it. The CDT is mediocre. There's li…

> It's a tool for some jobs; definitely not all.

I'd completely agree. I would not use C for doing any web platform work (writing a REST service as you say). I may write a webserver in C if I had tight memory constraints.

Where I see C still being very useful: embedded applications, drivers, and latency sensitive code.

When you are trying to push the most I/O possible through a network interface or disk interface, C allows extremely tight controls on memory and CPU usage. Especially if you are coding to a specific CPU for an embedded product, you can really tweak the app to perform as required (though, this may require some assembly to do what you need).

Re: The Unreasonable Effectiveness of C

#66

Post by corresation »

cageface wrote: post #2

C is a fantastic high level language. Nonsense. This sudden C fad is totally baffling to me. C is a great language for low-level work and it does have an attractive minimal elegance but is in absolutely no sense of the term a high level language . A language with next to no standard containers or algorithms, manual memory management, raw pointers, a barely functional string type and minimal standard library and concu…

C is hardly a fad given that it is the foundation for the vast bulk of software that you interact with everyday (if not the top layer, ones below it). But of course at some point there is a looping back when silver bullets fail to pay off in the longer term.

Re: The Unreasonable Effectiveness of C

#67

Post by MichaelGG »

jsaxton86 wrote: post #9
cageface wrote: post #2

C is a fantastic high level language. Nonsense. This sudden C fad is totally baffling to me. C is a great language for low-level work and it does have an attractive minimal elegance but is in absolutely no sense of the term a high level language . A language with next to no standard containers or algorithms, manual memory management, raw pointers, a barely functional string type and minimal standard library and concu…

You can wind up with "an unmaintanable mess riddled with security holes" in any language -- that's not unique to C. Regarding the flaws you have mentioned in C: Its flaws are very very well known, and this is a virtue. All languages and implementations have gotchas and hangups. C is just far more upfront about it. And there are a ton of static and runtime tools to help you deal with the most common and dangerous mist…

That's a misleading statement and I think you know it. In general, you have to go extremely out of your way to end up with a remote code execution exploit with Java or C#.

Look at Microsoft's CVEs for 2012. Approximately all of the serious ones would be impossible with a proper type system. This is after all of Microsoft's static analysis tools and code reviews and security focus.

Re: The Unreasonable Effectiveness of C

#68

Post by pdw »

RodgerTheGreat wrote: post #58
mjs wrote: post #35

"bolted-on support for concurrency"--just what are your options when it comes to concurrency and C?

If you agree with Hans Boehm, "Threads Cannot be Implemented as a Library": http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf

The C11 standard added concurrency primitives to the language.

Re: The Unreasonable Effectiveness of C

#69

Post by peterevans »

ryeguy wrote: post #33
Thrymr wrote: post #15

Earlier quoted context omitted.

> C... is in absolutely no sense of the term a high level language. Of course it is. You're not worrying about how many registers your CPU has, or when you swap a register out to memory. All that has been abstracted away for you. The fact that you can access memory locations directly gives you some low-level access, but in a very real sense C is a high-level language. There are higher-level languages with more abstra…

The problem is that the "level" of a language is relative to other languages. If C is a high level language, that means you can group it into the same pool as Java, C#, Haskell, Python, and Ruby. Don't you see a bit of a difference here? Unless there is a significant number of actual languages , not concepts , that are below C, it logically has to be called a "low level language" because there really isn't much below…

Here's the thing: "high-level", when applied to a programming language, has a historical context. It means something specific (see: http://en.wikipedia.org/wiki/High-level_programming_language), and what it means and has always meant is that the language in question abstracts away registers and allows structured programming (as in, through the use of if, while, switch, for, as opposed to using labels and branching).

It's fine if you want to call "high-level" relative. But it should be acknowledged that "high-level" is not simply a strict comparison between the features of one language and another. And it SHOULD be acknowledged that C is, by convention, a high-level language. Python is definitely a higher-level language, but C is still a high-level language.

Re: The Unreasonable Effectiveness of C

#70

Post by revelation »

Thrymr wrote: post #15
cageface wrote: post #2

C is a fantastic high level language. Nonsense. This sudden C fad is totally baffling to me. C is a great language for low-level work and it does have an attractive minimal elegance but is in absolutely no sense of the term a high level language . A language with next to no standard containers or algorithms, manual memory management, raw pointers, a barely functional string type and minimal standard library and concu…

> C... is in absolutely no sense of the term a high level language. Of course it is. You're not worrying about how many registers your CPU has, or when you swap a register out to memory. All that has been abstracted away for you. The fact that you can access memory locations directly gives you some low-level access, but in a very real sense C is a high-level language. There are higher-level languages with more abstra…

I think what constitutes a "high level language" changes with every few iterations of moores law, as it becomes permittible to add layers and abstractions and virtual machines on top of the old "high level".
Post reply on HN