I submitted a GitHub issue for the `main()` definitions and some other quibbles. https://github.com/akalenuk/wordsandbuttons/issues/12
So you think you know C? (2016)
311–320 of 344 posts
Re: So you think you know C? (2016)
#312Earlier 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.…
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)
#313Earlier 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…
>"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)
#314Earlier 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.
#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)
#315Earlier 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
Re: So you think you know C? (2016)
#316Having 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
Re: So you think you know C? (2016)
#317Earlier 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?
But if you want a competitive compiler, better pencil out 10 years.
Re: So you think you know C? (2016)
#318Earlier 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...
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)
#319Earlier 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.
Re: So you think you know C? (2016)
#320Earlier 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…