Hacker News Reader

Comment by sdegutis | Hacker News Reader

<offtopic>As someone obsessed with writing C code, something just clicked. I think I understand better why there are so many JavaScript programmers, so many tools and frameworks written in and around JS every day.

For me, C is the gateway to the computer. It's ubiquitous. It's deceptively simple. I can literally write anything I want in C. It's an exciting thing to have an open main.c file sitting in front of me.

That must be how JS developers feel about the browser. The browser is a natural way to start learning programming for someone new to it these days. When I was growing up, we didn't really have JS and the web was brand new. I had to learn from QBasic's "Help" menu!

I bet there's an age correlation, too. I bet over a certain age, it's way more C programmers, and under it is way more JS people. (And above us is probably FORTRAN and above them is probably COBOL.)</div>

View on HN

I agree completely about C being the gateway to the computer. It really is the only way to go if you want to learn real programming. That doesn't mean I'm discounting JavaScript developers, but I like C better and it's more fun.

I think you're right that C is a gateway to learning how computers work. But I think using the term "real programming" in any context is flame bait...

Sure, with C, you will learn about some "low-level" things about computers that you never will if you only program in most other languages. I am talking about things like memory, bytes, addresses, the stack, binary arithmetic, bit twiddling... But that's pretty much it. Yet, there is much more to how computers work than that, and many (far from all, though) of those things you can only get a feel for if you learn some assembly programming. From there, you will see that C is a high-level, rather abstract, programming language, if only somewhat reflective of the idea of a computer of the von Neumann type. That's all. In the end, even the "machine language", of which assembly is a human-readable representation, today is usually interpreted or otherwise translated into a "true" machine instructions that get executed by the hardware. To get but a glimpse of what is going inside a computer - still on a somewhat high level - take a look at an excellent article by Mark Smotherman at https://people.cs.clemson.edu/~mark/uprog.html. If you really want to go deeper, there are transistor-level CPU simulators that run in the browser, such as the famous "visual 6502".

Slightly off topic: The way I look at it, C and C++ are the bedrock of all programming languages, because the popular compliers (llvm/clang, gcc and VisualStudio) are written in C and C++.

JavaScript, for example requires a browser to compile, which requires gcc or clang to compile. Python, Rust, etc all depend on programs written in C and C++.

Go is one recent exception of a popular language whose main implementation is completely self hosted. Though, Go doesn't host other popular languages.

I hate that way of looking at it because I think it's totally wrong.

C (this view is usually presented as only about c) isn't fundamental or bedrock in any way. Most of our current stacks just happen to be written in it.

The original Mac OS for instance was written in Pascal and C. The most popular open source compilers are written in c++. Most browsers are written in c++ not in c.

And there's no reason these days you couldn't rewrite llvm (a set of compiler libraries and compilers mostly written in c++, not that rust compiler uses llvm for code generation but the frontend is in rust) in haskell or java or javascript(they'd be slower but they would work). Haskell has useful features for writing compilers and a lot of language analysis libraries already. If you re-wrote in in rust it'd be just as fast.

Hell this guy (https://github.com/jameysharp/corrode) wrote a rust-c source-to-source compiler in literate haskell. Also in a few years servo will be a full browser in rust and Firefox is already adding components written in rust.

Other then os interface & c binary api linking there is nothing special about c or c++.

> Most of our current stacks just happen to be written in it.

Sure, there's nothing special about the languages themselves, but _currently_ C and C++ are the foundation for (almost) all other languages. In theory you could rewrite llvm (or use a different complier), but I don't see that happening any time soon. That's why I call it bedrock, because it would be very hard to change.

(Though, I do wonder when llvm will stop depending on Python 2 :)

> Go is one recent exception of a popular language whose main implementation is completely self hosted. Though, Go doesn't host other popular languages.

It wasn't self-hosted in the beginning, only since version 1.5 IIRC.

I'm not sure something can be self hosting from the beginning in the context of computing.

> I agree completely about C being the gateway to the computer. It really is the only way to go if you want to learn real programming.

Nonsense. That's as absurd as claiming assembly is the only way to go if you want to learn real programming.

> but I like C better and it's more fun.

Which is the only reason you think the above, nothing to do with reality, everything to do with personal preference.

I used to write C but now I do Coffeescript/JS. When I was just starting in C (as a teenager) I'd get really excited to learn the GNU's C standard library. I wanted to know how to make better and better console applications and networking applications. It felt like there was a huge learning curve to using graphics toolkits. Now that I do JS I feel like Web APIs are the new "C standard library". I can make console or apps with a GUI. I can do more because there already exists a large amount of interfaces abstracted over things that would take me a while to learn. At the same time, people are always figuring out new ways to abuse existing web standards for fun and profit - like how page visibility was done before the Visibility API existed: https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibi...

I like being a JS dev. It's a very fun runtime to poke around... I'd almost prefer all apps to live within the heavily sandboxed browser. It's the best effort made toward portability and it's been a community effort. :x

It depends on what kind of programs you like to write. Personally I like to write things like programming languages or VT100-based text editors. And I like the added challenges that C presents, especially related to data modeling, memory management, lack of first-class functions, etc. So C is a natural choice for me, whereas JS adds little to no value, and actually takes away the challenge.

I hate installing things. :x I get pretty turned on by offering up something like Google Sheets as a webapp that installs and is usable in seconds over the Internet. I used to really love Lua but even though it was <1MB to install people didn't want to download it and then run my script on its interpreter. I remember I made the choice to play in Lua after Python because Python was a large install at the time (60MB for interpreter + standard libs). I honestly feel like the desktop experience is moving into the browser. It's very convenient to "install your runtime" by going to a web address. I love being somewhere near the front lines of that. :3 </zealous-panting>

Sure, unless you're the guy who writes Minecraft. People installed that. And Atom. And Spotify. There's still some room for desktop apps like these, granted not as much as before.

I'm not saying people won't install desktop apps - I just like that there is a diminishing reason to do it outside the browser. [High performance] games, browsers themselves, video players (VLC), and dev environments, are some of the last things left...

As a non-C user, C was always too forboding. I wrote a bit of it, and read K&R, but places like HN bang into your head that you'll likely make a horrible screw-up writing C, your code won't be secure, and it's better not to bother. Maybe I should spend some more time with it.

It's definitely a worthwhile educational experience, even if you never write in it professionally.

If you can solve the problems in K&R, a good book to work through next is Computer Systems: A Programmer's Perspective [0].

Coursera used to have a course called The Hardware Software Interface [1] which covered the same material, but it doesn't seem to be availble right now.

[0] http://csapp.cs.cmu.edu/

[1] https://www.coursetalk.com/providers/coursera/courses/the-ha...

You might enjoy trying some embedded development. Memory management and object lifetimes are usually less complex, and security is not an issue unless the device talks to the internet. You rarely feel like you are "fighting" C; it feels like the right tool for the job.

Well, that's because it IS the right tool for the job. C was built for systems programming: kernels, filesystems, and the like. It really wasn't built for applications space programming.

No, C wasn't built for those things. Rather, it just so happens to be suitable for them. C was built as a higher-level alternative to assembly, for writing any kind of computer programs.

You can say that, but Dennis and Ken were writing Unix. The language got its feature set from what they needed for that application. And that application was systems programming.

Right, and Unix had things like calculator programs, spreadsheet programs, email programs.

Yes, but those aren't the projects that dictated the featureset of C.

You _will_ make a horrible screw-up and your code _will_ be insecure. However, it's worth the bother as an educational experience. For anyone wondering, I write C for a living, learned C 22 years ago and I hate writing every line of it (now, I liked it in the beginning).

Legends say that in the mist of time there was an age of people between FORTRAN and C, that used to know better ways to the soul of the machine than C.

Rumors are coming to town that those druids are now gathering on the valley between the Misty C++ mountains, Ada forest and Rusty valley.

And above us is probably FORTRAN and above them is probably COBOL.

Actually, I think assembly language would probably be the next age "peak". If you know Asm you'll be far better at C; things like pointers and indirection immediately make sense. The effect is weaker, but still there in the other direction.

(FYI, FORTRAN predates COBOL by a few years.)

> If you know Asm you'll be far better at C; things like pointers and indirection immediately make sense.

Be sure not to confuse cause and effect there: if you managed to learn ASM, you must not be the sort of programmer who is confused by pointers and indirection.

Somehow tens of thousands of people from the 60s to the 90s managed to learn asm, so I highly doubt that's the direction the cause and effect goes. Assembly isn't particularly complicated, just tedious.

I never understood what is so complicated to grasp about pointers.

Granted I am a 70's kid that started with Timex BASIC and Z80, but we learned pointers in one afternoon drawing boxes and lines on a piece of paper and that was it.

No because in x86-64 assembly main memory is effectively just a very big byte array and a "pointer" is just a index into that array. In C a pointer can be many different things depending on the underlying architecture.

When Intel made their 16bit cpus they still could address 20bit of memory so they decided to create the DS (current segment) and DX (offset) register.

The problem with far pointers is that they could have different values but point the same physical address and C still carries that legacy with it in the form of undefined behaviour which makes everything needlessly complex.

I don't think you can draw that conclusion either.

At my university, the Electrical & Computer Engineering curriculum teaches freshman assembly language before C. All of the ECE students understand pointers immediately. The Computer Science curriculum teaches C++ (with raw pointers) before assembly language. Pointers are significant source of frustration for many students in CS.

> If you know Asm you'll be far better at C; things like pointers and indirection immediately make sense.

A lot of recent issues with compilers "introducing security issues" has come from this sort of understanding of C (overflows, other undefined behavior, etc). The places where C differs from just writing the assembly yourself are really really hard.

And this is generally about compilers behaving badly.

Some languages do a good job of creating an abstracted universe above the hardware that plays by its own rules. This allows the language/runtime to map programming constructs to hardware behaviour in highly inventive ways.

C never was such a language, it's hardware abstractions are -- by design -- as leak-free as a fishnet. And yet compiler writers feel they need to get creative.

> I bet there's an age correlation, too.

Only 90's kids will get JS this.

Reply on news.ycombinator.com