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

141–150 of 394 posts

Re: The Unreasonable Effectiveness of C

#141

Post by tehwalrus »

JulianK wrote: post #99
makmanalp wrote: post #61

Earlier quoted context omitted.

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.

Though it doesn't reach all the dark corners that cmake does, I found premake to be much easier to figure out and customize. All the configuration is done in Lua and you can customize the state with a normal programming language as opposed to the crazy cmake arcana you sometimes have to resort to.

To both parents: whenever I have to install and work out how to debug yet another C build system on my Mac (default build settings never work on Macs), it leaves me wanting to (and indeed going on to) rewrite entire libraries I should be just using. (notable exception: autohell seems to work, some of the time, and it even sometimes fails with an error telling me what's wrong.)

When I use python extensions (often written in C), this problem doesn't arise because distutils, and sometimes cython, handle everything.

Python isn't the best C build system, but frankly it scores better than cmake and friends for ease of use.

Re: The Unreasonable Effectiveness of C

#142

Post by plg »

If you tried to use an F1 racecar as your day to day commuter, of course you would complain about it. It would be horrible. Tune the engine every day!? Tire grip changes over TIME? Must watch oil temps so carefully? What a pain in the ass. Also easy to crash.

If you tried to use your soccer-mom minivan to participate in F1 races, of course you would complain. I can't tune the engine? I can't tinker with the oil pressure?!? How do I adjust performance for different tracks?! This thing sucks. Also it's slow.

These kinds of debates about C and other "higher" level languages are growing tiresome. We live in a wonderful world full of different tools for different purposes. Maybe your grandma doesn't want to worry about details under the hood, and she also doesn't need to race F1 cars, so a minivan suits her just fine. Maybe you value being able to tune your code for maximum speed and you don't mind (or even enjoy) the challenges involved in C code. Good for you.

yawn...

Re: The Unreasonable Effectiveness of C

#143

Post by betterunix »

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…

"You can wind up with "an unmaintanable mess riddled with security holes" in any language"

Sure, but it is much, much, much easier to do in C than in other languages. By default you have unchecked array access, fixed width integers, strings terminated by a special character, and tons of exploitable undefined behavior. Writing secure code in C takes substantial effort, substantially more than in other languages.

Re: The Unreasonable Effectiveness of C

#144

Post by alexkus »

gizmo686 wrote: post #38
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.

I have worked on several projects in Java (using Eclipse as an IDE). In my experience there is a 'significant' latency between when I hit run, and my program starts. (My suspicion is this time is spent starting the JVM, not compiling). Every (non kernel) C project I have worked with has effectively 0 build time after making changes. This is because they all used make which (like Eclipse and likely all IDEs) only reco…

> Every (non kernel) C project I have worked with has effectively 0 build time after making changes.

For trivial changes maybe. Rebuild time will depend on the size/complexity of the project and the number of dependencies on the thing that was changed.

A change to a header file of a core library may cause a rebuild of many parts of the project thanks to dependencies built on header files. We have such a library in our product and modifying a single file can cause ~40% of the product to need to be rebuilt.

Think about changing something like:

     #define VERSION "1.2.3"
which is compiled into every library and binary within the product.

Re: The Unreasonable Effectiveness of C

#145

Post by jfb »

looser wrote: post #130
madhadron wrote: post #105

Earlier quoted context omitted.

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

If C makes use of a virtual machine, then why we have to recompile it for every new machine/platform?

See silentbicycle's sibling comment.

Re: The Unreasonable Effectiveness of C

#146

Post by waffenklang »

pcwalton wrote: post #129
xamuel wrote: post #60

Earlier quoted context omitted.

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?

Binary search trees cannot be implemented in 5 (reasonably-wide) lines of C.

And can't be _implemented_ in any language. C gives you at least the charming fact that you can implement one without any overhead of objects, classes, implicit memory management or some other concept, just having a lightweight implementation that you may use in an environment without any libraries, like std or else..

Re: The Unreasonable Effectiveness of C

#147

Post by betterunix »

afandian wrote: post #48
ryeguy wrote: post #33

Earlier quoted context omitted.

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…

You can do some very interesting things with function pointers, structs, unions and judicious use of void pointers. I would absolutely group it with Java. Not saying they are very very similar, but you can do similar things. Now grouping Java with Haskell, that doesn't seem like a reasonable grouping. Of course, it's all swings and roundabouts really. You can draw lines anywhere.

"You can do some very interesting things with function pointers, structs, unions and judicious use of void pointers"

You can also do interesting things with straight assembly language. How does that make a language high level?

That you would ever deal directly with pointers is evidence that C is not really a high level language.

Re: The Unreasonable Effectiveness of C

#148

Post by slurry »

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 - if you had exotic tastes maybe Forth or something. If you were a Basic guy C was DANGEROUS (my programming teacher spoke of C the way Nancy Reagan spoke of crack cocaine) and if you were an assembly guy C was a slow hog.

And if you had access to a "real" computer, chances are it was running PL/I, COBOL or Fortran, not C.

The 1983 video game Tron had levels named after programming languages: "BASIC", "RPG", "COBOL", "FORTRAN", "SNOBOL", "PL1", "PASCAL", "ALGOL", "ASSEMBLY", "OS" and "JCL". C apparently did not merit mention; its complete dominance didn't come until some ways into the PC era.

Re: The Unreasonable Effectiveness of C

#149

Post by to3m »

hackinthebochs wrote: post #96
xamuel wrote: post #60

Earlier quoted context omitted.

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?

> because that line you posted looks like something out of the foul depths of hell. I must say I laughed-out-loud at that, mainly because I've been on both side of the divide when it comes to opinions on verbose std definitions. It is an odd feeling to simultaneously feel revulsion and nostalgia towards a line of code. I do think there is a non-trivial, and sometimes massive boon gained from concise definitions. It's…

I agree - I've found the STL a massive productivity boost, for all its ugliness. It's worth it for std::vector and std::string alone, and I also like std::map (even though the API teeters on the boundary between genius and insanity) and std::set. All there for your use, with your own data types, out of the box.

I discovered the STL one day in February 1999, by accident, when looking for something else in the VC++ help. Once I realised what I'd found, I gave up C entirely within about 1 week.

Re: The Unreasonable Effectiveness of C

#150

Post by sp4rki »

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

That's being deliberately obtuse. How many languages are lower level than C, besides assembly? If your ranking has every language in the "high level" camp, then your ranking is poorly calibrated.

Assembly is not one language (even if they all look very alike). It's a collection of opcodes or mnemonics specific to a specific architecture with a specific instruction set that map to the later. Even then writing assembly for MASM, TASM, WASM, or WhateverASM for Linux, Windows, or Winux (or whatever) can and will probably differ in structure and in the specific mnemonics used.

There's machine code, low level languages which are basically the plethora of different Assembly languages, and high level languages which provide abstractions to either or both of the former languages and resemble the actual written language. Putting C in the low level languages rank is doing a disservice to the language and not taking into account the bunch of people that program (for example) embedded devices in whatever architecture they're using.

Post reply on HN