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

341–350 of 381 posts

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

#341

Post by sys_64738 »

jimmaswell wrote: post #94
geofft wrote: post #86

Earlier quoted context omitted.

> What that means is that most C operations can be easily translated into the machine code equivalents and that makes debugging of compiled code so much easier. A disassembly of many binaries will reveal their C roots by function calls being equivalent to jump statements, as an example. If you have the C source then you can usually figure out what's going on. This is very much not true in my experience. Optimization…

Why would you turn on optimization while debugging?

Scaling your code for benchmarking criteria is a good example.

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

#342

Post by XMPPwocky »

pm215 wrote: post #291
XMPPwocky wrote: post #232

Earlier quoted context omitted.

Addition, subtraction, and stack-relative addressing are, in most architectures I'm familiar with, generic- stack-relative addressing ends up just being a special case of register-relative addressing, and addition and subtraction are rather important instructions in their own right. PUSH/POP are more obviously "hey store your locals on the stack, kids", but on, say, x64, how often do you actually see a push instead o…

There's a reason 32-bit ARM has 'move base register down and then do some stores' and 'do loads and then move base register up' (stmdb and ldmia) rather than just plain old ldm and stm, and I'm pretty sure it's because it makes the entry and exit sequences for function calls with a stack shorter. (The ARM ISA doesn't privilege a downward growing stack, so you can use stmib and ldmda if you want your stack to grow upw…

That's definitely a large part of it, but it also makes small memcpys nicer (load sizeof(foo)/4 registers from sourceptr with post increment, store them to destptr with post increment)

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

#343

Post by sevensor »

Sir_Cmpwn wrote: post #310
flyinglizard wrote: post #148

Earlier quoted context omitted.

Arguably those problems did not exist before the C-era as software wasn't large or complicated enough. C++ directly attempts to improve over C by providing new mechanisms to solve problems encountered by C developers every day. Point is that out of context, a lot of the things modern languages provide seem superfluous. Why have objects? Why have templates, closures, or lambdas? For a novice programmer, these are many…

When I see templates, I run in the opposite direction at a dead sprint. C++ has added very little of value to the language and templates are one of their worst offerings. Metaprogramming is an antipattern in C.

> Metaprogramming is an antipattern in C.

Yet we often see passionate arguments in its favor, as for instance from Sústrik (http://250bpm.com/blog:56) and Tatham (https://www.chiark.greenend.org.uk/~sgtatham/mp/) and a person on the internet who recommends replacing LAPACK with preprocessor macros (http://wordsandbuttons.online/outperforming_lapack_with_c_me...). Would you care to comment on its enduring popularity?

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

#344

Post by Sir_Cmpwn »

sevensor wrote: post #343
Sir_Cmpwn wrote: post #310

Earlier quoted context omitted.

When I see templates, I run in the opposite direction at a dead sprint. C++ has added very little of value to the language and templates are one of their worst offerings. Metaprogramming is an antipattern in C.

> Metaprogramming is an antipattern in C. Yet we often see passionate arguments in its favor, as for instance from Sústrik ( http://250bpm.com/blog:56 ) and Tatham ( https://www.chiark.greenend.org.uk/~sgtatham/mp/ ) and a person on the internet who recommends replacing LAPACK with preprocessor macros ( http://wordsandbuttons.online/outperforming_lapack_with_c_me... ). Would you care to comment on its enduring popula…

You can write bad code in any language, C is no exception. We also see people persistently arguing in favor of simpler and less magical C. If you want reliable, maintainable code in any language, do not use magic. Metaprogramming is cool, no doubt about it, but it's unnecessary and creates bad code.

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

#345

Post by diminoten »

sys_64738 wrote: post #338
diminoten wrote: post #322

Earlier quoted context omitted.

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…

C is their craft and they're experts so what's not to like? I'm not sure what this 'good enough' angle is and why you think it's specific to C. It's an issue to other language more than C as those other languages are often used by shops without proper software engineering practices in place. All the places I've worked which use C enforce those SW practices but it's not clear to me that the same could be said for othe…

You keep talking about Python's problems, and I'm trying to talk about the habits I've noticed C programmers form and are rewarded for, but are bad for Python development.

There are literally no habits in your mind that could be good in C but bad in Python?

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

#346

Post by GolDDranks »

kbenson wrote: post #117
GolDDranks wrote: post #4

What really made computers click to me was reading a book that had the premise: "learn just enough assembly to be able to implement C features by hand; we'll show you how". Sadly, I don't remember the title. Another revelation much later on, was, as discussed here, the realisation that C is indeed defined over an abstract machine. I think much of those realisations were because of reading about how crazy compiler opt…

I have to ask, because I've wondered for a couple years now, is your name a One Piece reference?

Yes it is! Thank you for noticing!

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

#347

Post by kbenson »

GolDDranks wrote: post #346
kbenson wrote: post #117

Earlier quoted context omitted.

I have to ask, because I've wondered for a couple years now, is your name a One Piece reference?

Yes it is! Thank you for noticing!

Nice! As of a couple months ago I'm actually going through the anime series again with my 9 year old. It's interesting getting his take on the characters, since it's a bit different than mine (and he's way younger than I was when I first watched it). For example, he's mostly bored by any Zoro fights, likely because at this point they are a lot of before and after cuts, but Zoro was always one of my favorite characters. We'll see if that continues, we're only just finishing the Spypeia arc.

I will say, waiting until he was capable and willing to read the subbed version was probably the right choice. Dubbed shows of any genre drive me nuts, and I'm not sure he would have the patience for the series if he was younger (the Alabasta arc was still taxing...). I do take a perverse pleasure in hinting about how crazy stuff becomes later, while also convincing him to not ruin it for himself by looking it up. ;)

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

#348

Post by Annatar »

lmm wrote: post #243
Annatar wrote: post #171

Earlier quoted context omitted.

It would be valid, though. A computer programmer must understand how a computer works lest she or he write slow, bloated, inefficient software.

Given how many person-years have been saved and how much value has been produced by "slow, bloated, inefficient software", I must disagree in the strongest possible terms. Producing "slow, bloated, inefficient software" is far, far preferable to not producing software at all.

I would rather have no software or write the software myself than waste all the time of my life I've had to waste because of such shitty software, and it is indeed the case I've had to write such software from scratch because the alternatives were utter garbage. So we deeply, vehemently disagree.

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

#349

Post by Annatar »

_cbsz wrote: post #253
Annatar wrote: post #166

Earlier quoted context omitted.

Register renaming was invented to give assembler code generated from C enough variables in the forms of processor registers, so that calling functions wouldn't incur as much of a performance penalty. The UltraSPARC processor is a stereotypical example, a RISC processor designed to cater to a C compiler as much as possible: with register renaming, it has 256 virtual registers!

Why do you claim that local variables and function calls are specific to C? They seem to be very popular among programming languages in general.

Because I'm an assembler coder, and when one codes assembler by hand, one almost never uses the stack: it's easy for a human to write subroutines in such a way that only the processor registers are used, especially on elegant processor designs which have 16 or 32 registers.

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

#350

Post by jcelerier »

lmm wrote: post #250
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).

If a language lets you cause undefined behaviour via FFI into C, I think it's fair to say that that remains a problem created by C. I do take your point about Rust, but I'd see that as deriving from LLVM's undefined behaviour which in turn descends from C; I'm not aware of any pre-C languages having C-style exploding undefined behaviour or of any subsequent languages inventing it independently.

> If a language lets you cause undefined behaviour via FFI into C,

FFI isn't into "C", it's into your operating system's binary format. And since no two systems behave the same, it's UB however you look at it.

Post reply on HN