Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should you learn C to “learn how the computer works”?

words.steveklabnik.com

Post reply on HN
Print view View original

321–330 of 381 posts

Re: Should you learn C to “learn how the computer works”?

#321

Post by steveklabnik »

Sir_Cmpwn wrote: post #311
steveklabnik wrote: post #230

Earlier quoted context omitted.

There are many languages which have undefined behavior. C does have a lot of it, and it can be anywhere. In many languages, you can cause undefined behavior through its FFI. Some languages, like Rust, have UB, but only in well-defined places (a module containing unsafe code, in its case).

Rust does not have a spec, so all Rust behavior is undefined.

This is literally true but also overly reductive; we do make certain kinds of guarantees, even if there isn't a full specification of the entire language yet.

The reason that a spec is taking so long is that we're interested in making an ironclad, really good spec. Formal methods take time. C and C++ did not have specs for much, much longer than the three years that Rust has existed. We'll get there.

Re: Should you learn C to “learn how the computer works”?

#322

Post by diminoten »

sys_64738 wrote: post #257
diminoten wrote: post #114

I just have so many problems working with the former C programmers on my team as a Python dev. They're constantly worried about memory management, they're not very concerned about architecture and don't make full use of the Python language, they're of the "if it works, ship it" mentality, and they're constantly writing code that violates my tastes. I can write a C program, but I am not in any way a C ninja. I sometim…

Python has scalability issues which are solved by calling into C libraries. What does that tell you about whom should be listening to who? There are many reasons C programmers are experts in their craft while python programmers are 10 a penny.

My point was that C programmers aren't experts at their craft, just experts at C, and all the habits that were possibly good in C carry over, making them less than good at Python.

Also, I think your comment is a great example of the mentality that C programmers I've worked with brought to the table (partially because it's true for C but untrue for other language, particularly python); that if you can write code that runs, you are "good", that "runnable code that solves the problem" is the end goal.

Finally, there are most certainly not a glut of python developers. Certainly many people who write python scripts, but far fewer people who are python developers. There's a difference, and I get the sense that's lost on some C programmers.

Re: Should you learn C to “learn how the computer works”?

#323

Post by Sir_Cmpwn »

steveklabnik wrote: post #321
Sir_Cmpwn wrote: post #311

Earlier quoted context omitted.

Rust does not have a spec, so all Rust behavior is undefined.

This is literally true but also overly reductive; we do make certain kinds of guarantees, even if there isn't a full specification of the entire language yet. The reason that a spec is taking so long is that we're interested in making an ironclad, really good spec. Formal methods take time. C and C++ did not have specs for much, much longer than the three years that Rust has existed. We'll get there.

In my opinion as an onlooker of Rust, it seems more interested in shiny features and breaking the language every month than in becoming stable and writing a spec. It's far from replacing C in this regard.

Re: Should you learn C to “learn how the computer works”?

#324

Post by bordercases »

It's worth learning as the prima facie example of a high-level language on top of the register memory model.

http://canonical.org/~kragen/memory-models/

Its perceived close relationship to the machine is precisely due to the fact that it exposes pointers & does not handle its own memory allocation with a garbage collector, both of which are direct consequences of the register model.

Why not Assembly? Because it's not a language that encodes propositions first class, and that's the grounding for structured/procedural programming. The majority of software requires some structured element and so regressing towards the assembly model, where abstractions are implicit, doesn't get new programmers on the path to understanding how to write nearly all software.

Re: Should you learn C to “learn how the computer works”?

#325

Post by jstimpfle »

lmm wrote: post #240
jstimpfle wrote: post #126

Earlier quoted context omitted.

> A computer does not need to implement a stack C doesnt "have", or require, a stack, either. It has automatic variables, and I think I looked once and it doesn't even explitly require support for recursive functions.

You might be thinking of Fortran? C does require support for recursive functions.

You're right. I searched the C99 for "recurs" and found the relevant section that briefly mentions recursive function calls.

That means static allocation is insufficient for an implementation of automatic variables in a conformant C compiler. Nevertheless I still like to think of it as a valid implementation sometimes. In contemporary practice many stack variables are basically global variables, in the sense that they are valid during most of the program. And they are degraded to stack variables only as a by-product of a (technically, unnessary) splitting of the program into very fine-grained function calls.

Re: Should you learn C to “learn how the computer works”?

#326

Post by steveklabnik »

Sir_Cmpwn wrote: post #323
steveklabnik wrote: post #321

Earlier quoted context omitted.

This is literally true but also overly reductive; we do make certain kinds of guarantees, even if there isn't a full specification of the entire language yet. The reason that a spec is taking so long is that we're interested in making an ironclad, really good spec. Formal methods take time. C and C++ did not have specs for much, much longer than the three years that Rust has existed. We'll get there.

In my opinion as an onlooker of Rust, it seems more interested in shiny features and breaking the language every month than in becoming stable and writing a spec. It's far from replacing C in this regard.

What breaks in the language every month? That’s not the experience our users report. There are some areas where we do reserve the right to tweak things, but we take great care to ensure that these breakages are theoretical, rather than an actual pain. We have large (hundreds of thousands of LOC, and maybe even a few 1MM ones) code bases in production in the wild now, we cannot afford to break things willy-nilly.

You are right that we are far, but that’s because it’s a monumental task, and it’s fundamentally unfair to expect equivalence from a young language. It is fair to say that it is a drawback.

Re: Should you learn C to “learn how the computer works”?

#327

Post by x0re4x »

rrauenza wrote: post #110
Sir_Cmpwn wrote: post #82

Earlier quoted context omitted.

You're joking. There's a very serious distinction between the stack and the heap - perhaps they live in the same memory but they are used very differently and if you mix them up your things will break.

...like returning a pointer to the stack: char *dupstr(const char *src) { char new[1024]; strlcpy(new, src, 1024); return new; }

stack_ret.c:5:10: warning: function returns address of local variable [-Wreturn-local-addr] return new;

Re: Should you learn C to “learn how the computer works”?

#328

Post by Sir_Cmpwn »

steveklabnik wrote: post #326
Sir_Cmpwn wrote: post #323

Earlier quoted context omitted.

In my opinion as an onlooker of Rust, it seems more interested in shiny features and breaking the language every month than in becoming stable and writing a spec. It's far from replacing C in this regard.

What breaks in the language every month? That’s not the experience our users report. There are some areas where we do reserve the right to tweak things, but we take great care to ensure that these breakages are theoretical, rather than an actual pain. We have large (hundreds of thousands of LOC, and maybe even a few 1MM ones) code bases in production in the wild now, we cannot afford to break things willy-nilly. You…

The language doesn't break as much today, but what constitutes "idiomatic" Rust is constantly changing. I don't use Rust but I spend a lot of time with people who do and am echoing what I've heard from them, and seen for myself as a casual user of Rust software and occasional drive-by contributor.

It doesn't have to be a monumental task. Rust is simply too big, and getting bigger.

Re: Should you learn C to “learn how the computer works”?

#329

Post by FartyMcFarter »

drb91 wrote: post #258
XMPPwocky wrote: post #204

Earlier quoted context omitted.

Here's the C99 standard: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf There are no occurrences of the words "stack" or "heap" in this document. What the spec actually discusses is "storage durations". Now, in many cases you can say, well, "automatic storage duration" means it's on the stack, but that's not something C has any opinions about. If you want to know about the stack and the heap, saying "learn…

People don’t learn C by learning the spec, and virtually every c implementation and runtime I know, it uses a stack and heap. Oddly you seem to recognize this, so I’m not sure what your point is.

Indeed. There's a place for language lawyering, but that place is not everywhere.

Re: Should you learn C to “learn how the computer works”?

#330

Post by steveklabnik »

Sir_Cmpwn wrote: post #328
steveklabnik wrote: post #326

Earlier quoted context omitted.

What breaks in the language every month? That’s not the experience our users report. There are some areas where we do reserve the right to tweak things, but we take great care to ensure that these breakages are theoretical, rather than an actual pain. We have large (hundreds of thousands of LOC, and maybe even a few 1MM ones) code bases in production in the wild now, we cannot afford to break things willy-nilly. You…

The language doesn't break as much today, but what constitutes "idiomatic" Rust is constantly changing. I don't use Rust but I spend a lot of time with people who do and am echoing what I've heard from them, and seen for myself as a casual user of Rust software and occasional drive-by contributor. It doesn't have to be a monumental task. Rust is simply too big, and getting bigger.

Thanks. That’s much more reasonable, IMHO.

Specs are always a monumental task. The first C spec took six years to make in the first place!

Post reply on HN