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

311–320 of 394 posts

Re: The Unreasonable Effectiveness of C

#311

Post by npsimons »

ori_b wrote: post #283
madhadron wrote: post #105

Earlier quoted context omitted.

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

If you're going to be pedantic, use the right terms. The C language defines an 'abstract machine', not a 'virtual machine'.

Second this; in all my years (granted, not a lot, but enough), this is the first time I've heard anyone claim that C has a virtual machine. You can hem and haw and stretch the definition all you want, but when it compiles to assembler, I think that most reasonable people would no longer claim that's a "virtual" machine.

Edit: if you want to argue that C enforces a certain view of programming, a "paradigm" if you will (snark), then say that. Don't say "virtual machine", where most people will go "what? when did C start running on JVM/.NET/etc?".

Re: The Unreasonable Effectiveness of C

#312

Post by johncarpinelli »

venomsnake wrote: post #93
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 not a fad. The sudden love for C is the logical backlash caused by the abuse of lasagna layer upon layer of enterprise oo mvc enabled, xml configurable, orm supporting, osgi friendly huge monolith frameworks. A whole generation of developers have barely known simple and small. And they got tired of big enterprise and are searching for something "not as clumsy or random as a blaster. An elegant weapon, for a more…

Totally agree. Learning object oriented frameworks gives me a headache. I learned C back in 1991 for first-year CS classes. Consider all the software built in C: Linux, FreeBSD, Apache, etc. It's the dominant infrastructure of the web.

What language will be used to build the first human-level AI? I think it will probably be C, and less than 1 million lines of code.

Re: The Unreasonable Effectiveness of C

#313

Post by alexchamberlain »

dakimov wrote: post #304
pjmlp wrote: post #246

Earlier quoted context omitted.

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.

There is a problem that each and every tool for semantic-aware C/C++ refactoring I have tried does not work 100% of the time (i.e. it sucks more than 0%). This happens particularly because C/C++ have header files that expand to huge source files and preprocessor macros driving the parsers nuts because the parsers of the refactoring tools are simplified for speed, and also in a typical C/C++ program there is a number…

If you are using macros in C++, you are doing it wrong. They are a relic of a bygone age.

Re: The Unreasonable Effectiveness of C

#314

Post by stmartin »

w3pm wrote: post #286
michaelochurch wrote: post #188

Earlier quoted context omitted.

Fair point. At this point, it's a very leaky abstraction because not all levels of "random access" (e.g. L1 cache vs. main memory) are created equal.

True, and this is my biggest problem with writing optimized code in C -- it takes a lot of guessing and inspecting the generated assembler and understanding your particular platform to make sure you're ACTUALLY utilizing registers and cache like you intend. If there were some way of expressing this intent through the language and have the compiler enforce it, that'd be fantastic :) That said, there's really not a bet…

What kind of a masochist are you, sir?

Re: The Unreasonable Effectiveness of C

#315

Post by yuushi »

dakimov wrote: post #221
kyrra wrote: post #65

Earlier quoted context omitted.

> 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…

I have done low-level and mobile programming on very restricted platforms and I cannot see any reason why in the world I would use C instead of C++. Basically there is always an opportunity to use C++ if you can use C. Myths that C++ is slower are spread by people who just do not know C++ well or are not skilled/clever enough to use it.

Indeed. And there are numerous reasons why C++ code can be/is significantly faster; firstly code inlining for code that would be required to use function pointers in C (ala qsort vs std::sort), secondly, things such as expression templates for things such as Matrix libraries.

Re: The Unreasonable Effectiveness of C

#316

Post by georgeorwell »

groby_b wrote: post #234
Locke1689 wrote: post #196

Earlier quoted context omitted.

I would argue that C's problem is not that it's too strictly defined, but that it's too poorly defined. An in-depth look into all the cases of undefined behavior in C will show what I mean. You want to really understand C? Read this[0]. John really understands C. [0] http://blog.regehr.org/

Can't upvote this enough. Well, except that I'd replace "poorly" with "vaguely". "Implementation-defined behavior" is there for very good reasons in every single case it's there. Sidenote: With John's name, I'd be tempted on a daily basis to change the last two letters of my name to a single 'x' ;)

You mean like this?

  $ whoami | sed 's/hr/xx/'

Re: The Unreasonable Effectiveness of C

#317

Post by dakimov »

alexchamberlain wrote: post #313
dakimov wrote: post #304

Earlier quoted context omitted.

There is a problem that each and every tool for semantic-aware C/C++ refactoring I have tried does not work 100% of the time (i.e. it sucks more than 0%). This happens particularly because C/C++ have header files that expand to huge source files and preprocessor macros driving the parsers nuts because the parsers of the refactoring tools are simplified for speed, and also in a typical C/C++ program there is a number…

If you are using macros in C++, you are doing it wrong. They are a relic of a bygone age.

Thanks for letting me know, I try to use the macros as little as possible, but there are such things as platform-specific code, compiler differences, third-party libraries, standard libraries such as WinAPI and legacy code.

Re: The Unreasonable Effectiveness of C

#318

Post by chipsy »

madhadron wrote: post #135
woodchuck64 wrote: post #114

Earlier quoted context omitted.

> So, before writing about the glories of C, please go familiarize yourself with modern FORTRAN, ALGOL 60 and 68, Turbo Pascal's compiler and environment, a good Smalltalk like Squeak or Pharo, and the state of modern pipelines processor architectures. All true, but how are you going to implement a single project using just the best parts of FORTRAN, ALGOL 60, Turbo Pascal and Smalltalk?

Yes, and that's the tragedy of it all...and the real reason everyone uses C. It's not that C is a well designed language appropriate for highly optimized compiling, with wonderful tooling and an elegant standard library that takes care of the difficult or insecure or repetitive tasks. It's that I used to be able to sit down at any Unix machine in the world, shove some code into an editor, call some system libraries,…

The fact that is it "not always anymore" may be a blessing in disguise. The focus of attention in the last decade or so has been all around heavier, VM-centric languages like Java or Ruby, but opportunities for new systems programming technology are coming up more often these days.

Re: The Unreasonable Effectiveness of C

#319

Post by yuushi »

abrichr wrote: post #255
luser001 wrote: post #175

Earlier quoted context omitted.

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!

Except the analogy to Python lacks one critical point: C++ headers and Python imports do not work in nearly the same way. Do not EVER use a "using namespace " in a header file; any code that #include's such a header will pull this in.

In .cpp files it's ok (and almost required if you're using boost, unless you want boost::foo:bar::type everywhere). It still requires a bit of thought, though.

Re: The Unreasonable Effectiveness of C

#320

Post by caf »

anonymfus wrote: post #166
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…

> You're not worrying about how many registers your CPU has But you need to worry about size of registers. How many modern languages have basic data types without strictly defined sizes?

The C basic data types have minimum defined ranges, with the actual ranges being available as compile-time constants, and that's really all you need in almost all cases.
Post reply on HN