Live data from Hacker News

Getting started with C

not.cafe

91–100 of 106 posts

Re: Getting started with C

#91
post #5
post #3

Introducing newbies to GTK is a great way to show them a lot of code they don't understand, will take a while to understand, and will break in non-obvious ways.

I would be really interested in a course that actually holds true to the premise in the title here. I know my way around the JVM and python and started learning a little Rust on the side. However, I feel the need to at least dive my toes into C for a couple of weeks for completeness sake. Do you have a recommendation for something that is a little less than a book and a little more than learnCin10minutes?

https://github.com/mcpcpc/kirc/blob/master/kirc.c

read this.

Re: Getting started with C

#92
post #65

Earlier quoted context omitted.

Strong disagree. Unless you're using it as "C with classes", C++ is a nightmare hell language that you should only use if you're forced to by your environment. Stay far away. C is a fine language, but it is from the 60s and 70s and feels like it. Rust is very nice, although poor for half-assed prototyping (which is actually maybe a good thing). Both are fine choices for systems-level programming.

I've been working on this which you might find of use: https://github.com/glouw/ctl

That's interesting. Do I understand correctly though that the performance of CTL is mostly on a par with that of the STL?

Re: Getting started with C

#93
post #78

The absolute beginner technical guide may be the most difficult kind of writing there is. You have to know what's already in the head of the absolute beginner. If it's garbage, you need to set that straight before anything else can happen. You also have to know what's not in the head of an absolute beginner. Then you need to fill the gaps with background material. Not too much or your audience will tune out. Not too…

> You also have to know what's not in the head of an absolute beginner. Then you need to fill the gaps with background material. Not too much or your audience will tune out. Not too little or you'll lose your audience in a puff of confusion. There needs to be just enough instant gratification to keep the reader with you.

Couldn't agree more.

I've spent probably a year incrementally revising a "getting started with Ruby" resource for a local software development program. [0]

I ended up with a 45 minute (!!!) walk-through of how to run a test file of string manipulation exercises. [1] I treasure each of the ~500 views it's got.

I spent probably 25 hours making, editing, and writing about that video.

I think this video is the single most impactful thing I've ever made, in the last 10 years I've spent making things. I treasure the DMs I've gotten in Slack, from students who have found the video extremely helpful, encouraging, etc.

[0]: https://github.com/turingschool/ruby-exercises [1]: https://www.youtube.com/watch?v=aeAkLxr5diE&feature=youtu.be

Re: Getting started with C

#94
post #78

The absolute beginner technical guide may be the most difficult kind of writing there is. You have to know what's already in the head of the absolute beginner. If it's garbage, you need to set that straight before anything else can happen. You also have to know what's not in the head of an absolute beginner. Then you need to fill the gaps with background material. Not too much or your audience will tune out. Not too…

Yea, if I were writing something with the bold title "Absolute Beginner's Guide To..." I'd want to test it on my 8-year old who only knows how to launch the web browser and Minecraft. If she can use it successfully to cobble together a working Hello World program, then it's indeed an absolute beginner's guide.

Not only can she cobble it together - it has to be something that helps her feel a sense of pride, dignity, and understanding.

Some guides get someone to "the end", but they don't scaffold an understanding of the underlying principles, and the student feels even more confused at the end than at the beginning.

I always go to great lengths to show the mistakes that I make all the time, and to show how much of a given domain I don't know.

For example, in a Make an OSS contribution walk-through I did, I mention over and over how myself or the senior dev I was pairing with didn't understand something. [0] Most of the job of a modern software developer seems to be surfing across an ocean of complexity, avoiding everything except the _one specific issue_ we're working on.

To persons unfamiliar with the field, they might think that we actually understand everything to any degree of depth. They would be deeply mistaken.

[0]: https://intermediateruby.com/matt-swanson-jekyll-bug-p2

Re: Getting started with C

#95
post #55

Can AI generate a better tutorial? To test my theory, I asked the OpenAI API to complete the following sentence: This tutorial will guide you through writing the "Hello World" program in the C programming language. And here's the result: This tutorial will guide you through writing the "Hello World" program in the C programming language. Hello World Program Structure The "Hello World" program is a very simple program…

Is the AI messing up the newline? or is that just HN formatting

quite impressive. now ask it to solve the K&R exercises ;)

Re: Getting started with C

#96

The most critical prerequisite to being a good C developer is to really understand pointers on an intuitive level. The biggest block is that most people don't take the effort to develop mental fluidity. So when they see something like a dereference to a pointer of a pointer, or a cast from a pointer to an array, it interrupts flow while they consciously work out what's going on.

I'd say the most critical thing is to understand the relationship between ISO C standard, compiler implementations, and you, the programmer. Understanding that "seems to work" is not good strategy to deal with C, nor is trusting that things work in a sensible manner. Seeing how nasal demons might lurk at every corner. Distrust all advice and guidance that is not founded upon current C standard and/or compiler documentation. If you internalize that mode of thinking, then pointers will be just a minor detail in the end.

Re: Getting started with C

#97

Earlier quoted context omitted.

I've been working on this which you might find of use: https://github.com/glouw/ctl

That's interesting. Do I understand correctly though that the performance of CTL is mostly on a par with that of the STL?

Yes, I'd say at worst its 20% slower. The implementation is naive and readable (and therefor hackable). I did not have the time to implement all the heuristics that make STL as fast as it. The goal is hackability and ease of use (think text book function examples), while giving embedded engineers (or even desktop engineers with an aversion to C++) a chance to focus on getting their work done.

That, and lighting fast compile times, where programming feels like (oh, the heresy) a _drastically reduced C++_.

Re: Getting started with C

#98

The most critical prerequisite to being a good C developer is to really understand pointers on an intuitive level. The biggest block is that most people don't take the effort to develop mental fluidity. So when they see something like a dereference to a pointer of a pointer, or a cast from a pointer to an array, it interrupts flow while they consciously work out what's going on.

Personally, my major issue with pointers is the C syntax for them. While I understand why the & and * symbols were chosen for the task way back when, but it feels like a kludge. Smart pointers in C++ provide a more logical and consistent interface for using pointers.

I would be really interested in reading about why & and * were used as the symbols for pointers when C was originally conceived. Can you share a link or point me in the right direction for why that is? Please and thank you!

Re: Getting started with C

#99
post #38

Earlier quoted context omitted.

There should only be one way to succeed. Returning 0 for success makes complete sense. You can add layers of macros or enums to sugar coat this but retuning 0 for the success case makes complete sense

Yes, but if you use "magic constants" in your code, you will flunk code review in any halfway competent shop. Always use the constant symbols.

Have you seen any syscall implementation?

Re: Getting started with C

#100
The C programming language 2nd Edition from K&R is much better than this.

Just compile all code with "cc -o file file.c", except for the math library, where you need to add "-lm".

Use whatever editor you like. Nano, nvi, emacs, whatever.

Post reply on HN