Live data from Hacker News

So you think you know C? (2016)

wordsandbuttons.online

311–320 of 344 posts

Re: So you think you know C? (2016)

#312
post #245

Earlier quoted context omitted.

As someone who was introduced to programming via map/filter/reduce, for loops are incredibly more complicated. I don’t think I’ve ever written one correctly on first try.

> I don’t think I’ve ever written one correctly on first try. Please don't take offense, but this is odd to me. I honestly severely doubt I am some sort of programming super genius, but I have never had any issues setting looping logic correctly. (I took four years to teach myself programming & CS and now I've been at my first professional dev job for ~6 months.) None of my colleagues seem to have such issues either.…

I mean, I've written at most a couple dozen in my 7 years as a professional programmer (usually tight loops for perf), so sheer unfamiliarity is a big factor.

But yeah, syntax (what order the arguments go in) and off-by-one issues are the majority, I think. Plus figuring out what my initial accumulator needs to be.

Idk, map/filter and friends are just a much more direct mapping of how I think of programming.

Re: So you think you know C? (2016)

#313

Earlier quoted context omitted.

>which is supposed to be the point of the exercise. I don't think that assumption is justified. Someone could say the point of the exercise is to illustrate that C is confusing.

You don't think the claim is justified because some might say otherwise. Some is irrelevant. Some might say lots of mutually exclusive interpretations. It's the author's intent that matters, and the context of the Author's post indicates the some interpretation isn't the author's intent. His post begins with the question "So you think you know C?". He then goes on to present a test that is, by his own words, intended…

If what "some" might say about what the author intends is irrelevant, then what you say about what the author intends is also irrelevant, because you are just some person (unless you're the author). My point was why should I trust your interpretation of what the author intends more than anyone else's.

>"So you think you know C?"

That goes along with the interpretation that the point is to illustrate C is confusing. It would go along with something like "You think you know it, you think it's simple, well actually you don't know it, it's confusing."

>intended identify to test takers whether or not they really understand the intricacies of C, and to think critically about that source of their knowledge

Yes, its intent is to indicate to test takers that a lot of them don't really understand the intricacies of C, which demonstrates that C is more confusing than they originally thought.

>Never once does the author mention that C is confusing, use the word confusing, or otherwise indicate that general idea.

Here are some quotes that indicate the idea that C is confusing:

>C is not that simple.

>It’s only reasonable that the type of short int and an expression with the largest integer being short int would be the same. But the reasonable doesn’t mean right for C.

>Actually, it’s much more complicated than that. Take a peek at the standard, you’ll enjoy it.

>The third one is all about dark corners.

>The test is clearly provocative and may even be a little offensive.

Then the author says that he did C for 15 years and thought he knew it, but then realized he didn't. That indicates to me either that the author is saying that he's not smart, or that C is confusing. The second appears to be the point the author is actually making.

Re: So you think you know C? (2016)

#314
post #245

Earlier quoted context omitted.

map/filter/reduce is simpler, but it takes some getting used to. Loops have worn a deep rut in my brain.

As someone who was introduced to programming via map/filter/reduce, for loops are incredibly more complicated. I don’t think I’ve ever written one correctly on first try.

I've used loops so much I don't even see the loop anymore as a collection of constructs, I see it as a single thing. There are a lot of easy mistakes to make with loops, but I don't make them anymore (of course, by writing that, I will make one!). For example:

    #include 
    #include 
    typedef long T;
    bool find(T *array, size_t dim, T t) {
      int i;
      for (i = 0; i 
There are 5 errors in that example.

Re: So you think you know C? (2016)

#315

Earlier quoted context omitted.

What would we write drivers in then if C was obsoleted?

Is still a little early, but as someone who works at the bare metal level, Rust shows early promise. The features required are still unstable (as in not in the stable version of the compiler), but it’s getting there, and doing it fast. In any case, firmware behaves a lot like banking software, language change will take time

Cargo feels like too bloated to me for it to be something suitable for something low level like embedded. Unless the rust team can make it more appealing to use the language without cargo, I don't think there's much future.

Re: So you think you know C? (2016)

#316

Having written a conforming C compiler, at one point I knew everything there was to know about C (I forget details now and then, or confusing them with C++ and D). But knowing every engineering detail is not the same thing as knowing how to program in C effectively. It's like being the engineer who designs a Grand Prix car. It does not mean you can drive it faster around the track than anyone else. Not even close. Fo…

How ('yeah im going to write this') do you start such project like a c compiler? Seems like a huge thing to write. What did you write first? Did you already have a lot of compiler knowledge so you had a good idea/structure/flow etc in your mind already? And how long did it take you? tia

I'd written a couple compiler like toys before, but nothing like a real compiler. I just started writing it. Took a couple years.

Re: So you think you know C? (2016)

#317
post #264

Earlier quoted context omitted.

How ('yeah im going to write this') do you start such project like a c compiler? Seems like a huge thing to write. What did you write first? Did you already have a lot of compiler knowledge so you had a good idea/structure/flow etc in your mind already? And how long did it take you? tia

A compliant C compiler is probably a year's work in a modern language give or take?

It takes 3-5 months just to write a compliant preprocessor. Writing a basic code generator is a year, writing a basic optimizer is another year.

But if you want a competitive compiler, better pencil out 10 years.

Re: So you think you know C? (2016)

#318

Earlier quoted context omitted.

> If my macros produce standards-compliant code and they make my code easier to read and understand, why shouldn't I use them? The problem is they don't make code easier to read and understand. Worse, the unhygienic nature of C macros makes it hard to contain them. I haven't seen your code, so I'm speaking based on what I've seen of mine and others' code. If you dial it back, the person who has to deal with your code…

I once worked at a place that had a platform specific "DEBUG" log macro. It worked something like: DEBUG(msg); Except, it was defined in such a way that you actually had to have two closing parens, like DEBUG(msg)); It looked syntactically invalid, but whatever the macro did required it. The entire code base was littered with WTFs like that...

I hated debug macros. There just was never a clean way to write them. I was determined that D would not suffer from that problem. `debug` is a keyword in D, and you can do things like:

    debug printf("I got here\n");
and the printf only gets compiled in when compiling with -debug. (Any statement can be used after the printf.) Even better, semantic checks for debug statements are relaxed - for example, purity is not checked for them.

Meaning you can embed debug printf's in functions marked 'pure', instead of having to use a monad.

Re: So you think you know C? (2016)

#319

Earlier quoted context omitted.

Is still a little early, but as someone who works at the bare metal level, Rust shows early promise. The features required are still unstable (as in not in the stable version of the compiler), but it’s getting there, and doing it fast. In any case, firmware behaves a lot like banking software, language change will take time

Cargo feels like too bloated to me for it to be something suitable for something low level like embedded. Unless the rust team can make it more appealing to use the language without cargo, I don't think there's much future.

We use rust in embedded and love cargo! Coming from C++ and the endless mess of build systems that exist there, cargo is a breath of fresh air! What don't you like about it?

Re: So you think you know C? (2016)

#320

Earlier quoted context omitted.

You don't think the claim is justified because some might say otherwise. Some is irrelevant. Some might say lots of mutually exclusive interpretations. It's the author's intent that matters, and the context of the Author's post indicates the some interpretation isn't the author's intent. His post begins with the question "So you think you know C?". He then goes on to present a test that is, by his own words, intended…

If what "some" might say about what the author intends is irrelevant, then what you say about what the author intends is also irrelevant, because you are just some person (unless you're the author). My point was why should I trust your interpretation of what the author intends more than anyone else's. >"So you think you know C?" That goes along with the interpretation that the point is to illustrate C is confusing. I…

My interpretation is based directly on what the author states. Your "some" is based on a vague aggregate group whose interpretations, in aggregate, would be diverse and often contradictory and mutually exclusive. Personally, I trust the explicit an implied interpretation of the author's direct statements than you mere speculation as to what others might interpret.
Post reply on HN