The Unreasonable Effectiveness of C • Hacker News Board

Re: The Unreasonable Effectiveness of C

#231

Post by makmanalp » Thu, Jan 10, 2013, 6:59 PM UTC

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…

Oh no, I think slapping linux on it is the way to go, don't get me wrong :)

But I got stuck with it because I had to do ios dev at some point, so I learned to adapt ...

I hear arch and ubuntu both work great out of the box on macbooks.

Re: The Unreasonable Effectiveness of C

#232

Post by tyree732 » Thu, Jan 10, 2013, 7:00 PM UTC

waffenklang wrote: post #146

pcwalton wrote: post #129

Earlier quoted context omitted.

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

So what you're saying is that C lets you write it on your own. In fact, and this might sound crazy, but you can do that exact same thing in C++, it's just that people don't because the C++ standard library provides plenty of performant and featureful data structures for you.

Besides, anything the C++ standard template library map does when implementing a red-black tree is exactly what you would need to do if you wrote your own, minus having things like allocators (which are incredibly useful for those that need them). You speak of overhead due to "objects, classes and implicit memory management". Inevitably, any implementation of a data structure of substance in C ends up looking like c++-ified C. Want to create your hashtable? Call hashtable_init and get back a hashtable_t. Want to insert into it? Pass your hashtable_t, a key and a value into hashtable_insert. Even worse, you either have the choice of making all of your data void* in the data structure and casting into and out of your interface or making awful macros to define the various methods and structures for the types you would like to use. It's like you're stubbornly writing C++ in C.

Re: The Unreasonable Effectiveness of C

#233

Post by smosher » Thu, Jan 10, 2013, 7:00 PM UTC

scott_s wrote: post #230

smosher wrote: post #215

Earlier quoted context omitted.

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. C does no such thing. That is the job of the MMU, and C has nothing to say about it. You're going to have a hard time convincing anyone that a language without a runtime somehow has a VM. That's nonsense.

See the above discussion about what he meant by "virtual machine." It's not what you think it is, and it does exist.

It doesn't matter, his description is still the same kind of nonsense in line with having a VM. I get the feeling that he thought the thing he meant to say is actually the thing he said.

Re: The Unreasonable Effectiveness of C

#234

Post by groby_b » Thu, Jan 10, 2013, 7:08 PM UTC

Locke1689 wrote: post #196

groby_b wrote: post #189

Earlier quoted context omitted.

No, C does not define a single contiguous block of memory with consecutive addresses. It _does_ qualify that pointers are scalar types, but that does not imply contiguity or consecutive addresses (with the exception of arrays) There is no requirement in C that you be able to execute data. You certainly could have a C implementation that bounds-checks strings and arrays. (See e.g. http://www.doc.ic.ac.uk/~phjk/BoundsC…

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' ;)

Re: The Unreasonable Effectiveness of C

#235

Post by sbmassey » Thu, Jan 10, 2013, 7:12 PM UTC

peterevans wrote: post #69

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…

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

Under that classification, what is a low level language then? Even Forth abstracts away registers, and allows structured programming (or a sort). Is the set of low level languages that people have heard of in 2013 an empty set?

Re: The Unreasonable Effectiveness of C

#236

Post by betterunix » Thu, Jan 10, 2013, 7:12 PM UTC

xyzzy123 wrote: post #207

betterunix wrote: post #183

Earlier quoted context omitted.

"good clean C" Is there such a thing? It seems like every C program, even ones that are praised as being excellently written, are a mess of pointers, memory management, conditional statements that check for errors, special return value codes, and so forth. To put it another way, look at the difference between an implementation of a Red/Black Tree in C and one written in Lisp or Haskell. Not only are basic things over…

Um. Read Bentley. Get back to me. Yesterday's old shit is last week's high level. Turns out clear thought in any language is the main thing.

"Turns out clear thought in any language is the main thing."

No, the ability to express your thought clearly is the main thing -- and that is why languages matter. If your code is cluttered with pointer-juggling, error-checking conditional statements, and the other hoops C forces you to jump through, then your code is not clear.

Try expressing your code clearly in BF, then get back to me about this "languages don't matter as long as your have clear thought" philosophy.

Re: The Unreasonable Effectiveness of C

#237

Post by neumann_alfred » Thu, Jan 10, 2013, 7:16 PM UTC

scott_s wrote: post #230

smosher wrote: post #215

Earlier quoted context omitted.

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. C does no such thing. That is the job of the MMU, and C has nothing to say about it. You're going to have a hard time convincing anyone that a language without a runtime somehow has a VM. That's nonsense.

See the above discussion about what he meant by "virtual machine." It's not what you think it is, and it does exist.

More importantly, all other languages have it, too. So why even bring it up?

Re: The Unreasonable Effectiveness of C

#238

Post by scott_s » Thu, Jan 10, 2013, 7:19 PM UTC

smosher wrote: post #233

scott_s wrote: post #230

Earlier quoted context omitted.

See the above discussion about what he meant by "virtual machine." It's not what you think it is, and it does exist.

It doesn't matter, his description is still the same kind of nonsense in line with having a VM. I get the feeling that he thought the thing he meant to say is actually the thing he said.

Sorry, I don't see that. What he said is clear to me: The C virtual machine does not provide an accurate model of why your code is fast on a modern machine.

He's saying that the abstraction that C provides has deviated significantly from the underlying hardware. Considering the kinds of hoops that modern processor go through, this is a valid point.

And the above should answer the sibling's question, too.

Re: The Unreasonable Effectiveness of C

#239

Post by jerven » Thu, Jan 10, 2013, 7:20 PM UTC

pcwalton wrote: post #127

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…

You may like Rust (disclaimer: I work on Rust). You get the choice of manual or automatic memory management, but no matter which you choose you don't sacrifice safety. The language is simpler than C++ but can be about as fast as idiomatic C++ and supports a bunch of higher-level features like closures and generics.

Rust is the one language that we as a mixed java/c++/perl/scala shop look at, and see a future in. Exactly because of its safety features. Keep up the good work!

Re: The Unreasonable Effectiveness of C

#240

Post by sbmassey » Thu, Jan 10, 2013, 7:20 PM UTC

digeridoo wrote: post #179

stinos wrote: post #121

Earlier quoted context omitted.

well the thing is, it also works for std::vector , or std::vector , or anything you want. Last time I checked in C you'd have to either duplicate all your array code for each type or resort to something like void*. Only for that I'd use C++ (yes, you can use it without classes if you want).

Last time I checked in C, all pointer types where the same storage size. There's no need to define the same data structure multiple times by using templates. You just use casts.

... which is fine for creating data structures containing pointers to things created elsewhere, but it doesn't work if you want your data structures to contain more complex data types, without the overhead of another layer of pointer redirections.