Modern C [pdf] • Hacker News Board

Re: Modern C [pdf]

#161

Post by CmdrSprinkles » Mon, Nov 28, 2016, 3:47 PM UTC

pg314 wrote: post #136

CmdrSprinkles wrote: post #100

Earlier quoted context omitted.

And I think that is the way to go. I am personally a fan of having more sciencey programs use matlab and more "pure" CS use python as the first languages. Save C/C++ for the lower level stuff (as in OSes and hardware interfaces and optimization). Although, I would argue that nothing beats C++ for teaching OOP and data structures My problem is the almost dogmatic indoctrination that goes along with it. My cousin's Int…

I would argue Smalltalk is a far superior language to teach the essence of OOP. Students in Smalltalk will be writing programs in the first hour while their C++ counterparts will still be struggling to understand #includes. To quote Alan Kay: Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind.

I am definitely biased, but I think the includes are important and are almost part of the lesson. Teach someone how to write their own containers and classes, then show them that there is a library they can easily access that does a much better job than they ever will and just how easy it is to use.

And while there are better languages from an educational standpoint, having something that is usable/"real" is quite valuable.

But I definitely approach things from a more practical/industry oriented perspective. so grain of salt.

Re: Modern C [pdf]

#162

Post by awinter-py » Mon, Nov 28, 2016, 3:47 PM UTC

Yikes. important words that don't appear in this: 'static analysis', 'verification'.

On the 'wow' side, had no idea there was a _Generic macro. Pretty cool.

Re: Modern C [pdf]

#163

Post by jpfed » Mon, Nov 28, 2016, 3:48 PM UTC

chrisd1100 wrote: post #114

I'm really surprised by the "hate" for C that is appearing in these comments. What ever happened to actually enjoying the danger of getting low level? Is assembly also useless because it isn't readable? There is a lot of great code written in C, and a lot of crappy code written in C. Because C doesn't protect you from yourself, it exacerbates any design flaws your code may have, and makes logical errors ever more ins…

>enjoying the danger

This is a hilariously bad attitude for any software that other people will use. When software crashes, people lose work and time. When software has vulnerabilities, bad guys take advantage of them and build stronger botnets. "The danger" isn't like wiping out when you're pulling a stunt; "the danger" is wasting the good guys' time and empowering bad guys.

>There is a lot of great code written in C, and a lot of crappy code written in C

This is true of any mainstream language, so it's completely uninformative and pre-emptively shuts down the possibility of any meaningful language criticism.

Re: Modern C [pdf]

#164

Post by pcwalton » Mon, Nov 28, 2016, 3:50 PM UTC

chrisd1100 wrote: post #114

I'm really surprised by the "hate" for C that is appearing in these comments. What ever happened to actually enjoying the danger of getting low level? Is assembly also useless because it isn't readable? There is a lot of great code written in C, and a lot of crappy code written in C. Because C doesn't protect you from yourself, it exacerbates any design flaws your code may have, and makes logical errors ever more ins…

> So in this sense, the quality of the C you write is really a reflection of you as a C programmer, not the shortcomings of the language.

Can't you substitute "C" with just about anything in this sentence?

It's all well and good to talk about how "beautiful" a language is, but when people are literally endangered because of totally preventable security vulnerabilities that don't happen in programs written in other languages, it's hard to sway me as to how important this so-called "beauty" is.

Re: Modern C [pdf]

#165

Post by nurettin » Mon, Nov 28, 2016, 3:51 PM UTC

quickben wrote: post #66

grabcocque wrote: post #57

Earlier quoted context omitted.

If the handle of the hammer you're holding was a chainsaw that randomly turns on and off. And also sometimes explodes killing your entire family and pet dog. Don't blame the explodey-chainsaw-hammer, it's just a tool . Okay an idiotically dangerous too that nobody in their right mind should use, but still just a tool.

Eh, no need to overreact that much. Look. Hardware is hardware, and this is where tire meets the road so people can lay the foundation for the upper levels. It is what it is. It's not user friendly because hardware just isn't, low levels aren't, and it has to just perform. > 'idiotically dangerous' Well, I don't want to sound harsh, but nobody forces anybody to do systems programming if they perceive C as such. There…

Look at all his comments in this thread. He is just fishing for an argument/attention.

Re: Modern C [pdf]

#166

Post by pcwalton » Mon, Nov 28, 2016, 3:51 PM UTC

bluetomcat wrote: post #138

rileymat2 wrote: post #126

Earlier quoted context omitted.

There is also the issue of undefined and implementation defined behavior. When developing on one platform for an extended period of time, it is human nature to forget which features are implementation defined as you use them day after day and then have unexpected errors/flaws when porting.

Undefined behaviour actually isn't the monster that most C language lawyers want you to believe it is. With tools like valgrind, address sanitizers and modern debugging toolchains, most of these issues can be caught. Compilers are also mature enough to issue warnings about the use of uninitialized variables, missing return statements or mismatched printf specifiers. Heck, Clang maybe has more than 250 -W options.

In theory, a good fraction of these can be caught. In practice, these issues keep coming up in production again and again and again.

Re: Modern C [pdf]

#167

Post by delinka » Mon, Nov 28, 2016, 3:52 PM UTC

jjesus wrote: post #61

pawadu wrote: post #48

Earlier quoted context omitted.

> We bind type modifiers and qualifiers to the left. Good idea in theory but your example shows how bad it behaves in practice.

Usually declare variables one per line, so, type is still clear when: char* var1; char var2;

I tend to see typedef on a pointer type to address this.

    typedef char * pchar;

    pchar var1, var2; // Now they're both pointers

I'm not really a fan, but it can address the problem.

Re: Modern C [pdf]

#168

Post by xamuel » Mon, Nov 28, 2016, 3:53 PM UTC

rileymat2 wrote: post #126

chrisd1100 wrote: post #114

I'm really surprised by the "hate" for C that is appearing in these comments. What ever happened to actually enjoying the danger of getting low level? Is assembly also useless because it isn't readable? There is a lot of great code written in C, and a lot of crappy code written in C. Because C doesn't protect you from yourself, it exacerbates any design flaws your code may have, and makes logical errors ever more ins…

There is also the issue of undefined and implementation defined behavior. When developing on one platform for an extended period of time, it is human nature to forget which features are implementation defined as you use them day after day and then have unexpected errors/flaws when porting.

Undefined/implementation-defined behavior are necessary if you want optimal performance (unless the compiler requires formal proofs of correctness).

>it is human nature to forget

High-performance programming is a job the average human does not do. A professional programmer should use spaced-repetition technology to rise above human nature, and use tools like valgrind for extra safety.

Re: Modern C [pdf]

#169

Post by wangchow » Mon, Nov 28, 2016, 3:53 PM UTC

fb03 wrote: post #151

ITT: Heated arguments and zealotry. In resume: "C is outdated, its ubiquitousness is just a historical accident" "Better tools exist to do this job" "C is not needed anymore" (Yet no contender has ever come close to it, hehehe --my2c) There, saved you a ton of reading time.

A time will come when our entire concept of programming will shift due to advances in hardware unlike what we have today. Consider quantum computers or some biological machine etc.

Those who use C and assembly I imagine would be better equipped to understand the new paradigms. It's best to understand how to implement data structures in their most rudimentary form because implementing them on new platforms becomes easier.

In addition, higher-level idioms become easy to understand if the parts that make up the whole are understood. And underneath all those layers of translation and compilation we have raw assembly and the bare machine.

Re: Modern C [pdf]

#170

Post by steveklabnik » Mon, Nov 28, 2016, 3:53 PM UTC

jandrese wrote: post #50

noir_lord wrote: post #41

Earlier quoted context omitted.

Pragmatism over "Oooh Shiny", one of the reasons I have huge respect for the sqlite project ;). Rust looks pretty decent but I'm still in the wait and see stage as well.

I was trying to teach myself some Rust and found the state of the documentation to be very frustrating. The core language is decently documented with the manual, but the standard library documentation was out of date in many places, most annoyingly in the first few hits on Google. I found 5 different ways to read a file on Google, and only one of them still worked. Plus I saw the release notes on the newest version t…

The docs should never be "out of date" as in not working, though some parts don't have more than type signatures yet. Working on it. Please file bugs if something is not working, or swing by #rust-beginners, we love to help!