Live data from Hacker News

Modern C [pdf]

icube-icps.unistra.fr

131–140 of 396 posts

Re: Modern C [pdf]

#131
post #123
post #90

Earlier quoted context omitted.

Turbo Pascal, Think Pascal, Quick Pascal, FreePascal, Modula-2, Ada, Delphi, MikroElektronika Pascal The availability of compilers for a specific architecture is orthogonal to the language.

hmm got me there I guess. Never looked closely into those, can you summarize in what way thay are better than C? Less shoot-yourself-in-the-foot maybe?

Yes.

Pascal dialects already in the late 80's, early 90's, allowed for:

- type safe sub ranges

- proper strings

- type safe enumerations, enumerations as vector indexes

- type safe allocation (new vs malloc)

- type safe out parameters via references instead of pointers

- bounds checking and checked arithmetic (you can explicit disable them if required for performance)

- real modules via units

- pointer arithmetic is more explicit

As for MicroPython, MikroPascal from MikroElektronika supports all those tiny chips.

http://www.mikroe.com/mikropascal/

Re: Modern C [pdf]

#132

Earlier quoted context omitted.

While I am all about C/C++ (even if I hate it), it makes sense HN is probably something like 99% web and app developers (I would argue that all are the former, but my definition may be a bit old). In those cases, you actively don't want to ever use C and anyone who does is kind of an idiot. It is the logic by which "systems project" means "script to run on a server" for a lot of people around here. And that is fine.…

> While I am all about C/C++ (even if I hate it), it makes sense There's no such thing as "C/C++". They're two totally different languages. (C++ actually has more in common with something like Haskell than C.)

Come on.

That nomenclature has been around for decades. We ALL know they're different languages.

Re: Modern C [pdf]

#133

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…

C was not the only way of doing it.

Many of us were enjoying the danger of getting low level with Think/Quick/Turbo Pascal and Modula-2.

Re: Modern C [pdf]

#134
post #133

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…

C was not the only way of doing it. Many of us were enjoying the danger of getting low level with Think/Quick/Turbo Pascal and Modula-2.

Turbo Pascal even allowed to mix in assembler right in your source code. That was super awesome at that time. No need to write separate assembly code, no need to link !

(not to say that Turbo Pascal was the only one to do that, just fond memories...)

Re: Modern C [pdf]

#135
Goto is considered useful by the book:

The use of goto and similar jumps in programming languages has been subject to intensive debate, starting from an article by Dijkstra [1968]. Still today you will find people that seriously object code as it is given here, but let us try to be pragmatic about that: code with or without goto can be ugly and hard to follow.

Re: Modern C [pdf]

#136
post #93

Earlier quoted context omitted.

My university in the mid-90's already knew it was better to teach safe practices in C++ and Pascal dialects than keep teaching pure C. We were supposed to be able to use C in the OS design classes from our C++ learnings.

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.

Re: Modern C [pdf]

#137

Earlier quoted context omitted.

This C apologism is holding the industry back. Software development has changed many times over since C came out and it just isn't a good tool for tackling a lot of the issues that we have today. Just about every software project written in C has some serious bugs. I personally judge a language by how well it lets you to define abstractions. In C's case, it doesn't let you do that very well.

"Just about every software project written has some serious bugs" There, fixed it for you. Seriously, vulnerabilities and bugs are found everywhere not just in C. I've been programming for 35 years, in so many languages I lost count, and every time I've seen the 'let's not use C because it'll lead to bugs' it was to be replaced by another thing that was ALSO leading to bugs, and/or become so bloated it was in itself.…

I hope you will agree that there are things where C is not the optimal choice (e.g. you wouldn't choose C for writing scripts). Many people argue that C is still suitable if you need maximal performance or do stuff that is very close to the hardware, like operating systems. Now, people who say that C shouldn't be used at all are just convinced that even in those applications there are now better choices than C. Safer languages like Rust exist that at least claim to fill the same niche as C.

Re: Modern C [pdf]

#138

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 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.

Re: Modern C [pdf]

#139
post #135

Goto is considered useful by the book: The use of goto and similar jumps in programming languages has been subject to intensive debate, starting from an article by Dijkstra [1968]. Still today you will find people that seriously object code as it is given here, but let us try to be pragmatic about that: code with or without goto can be ugly and hard to follow.

Have you ever used goto in C? I feel like most people bash on C just because they heard Dijkstra said it, and that's it.

Most code I saw while teaching it were not good cases, but sometimes it's a very interesting technique that can make the code easier to understand and shorter. I think that use is beautiful.

But it doesn't mean there aren't bad use cases.

Re: Modern C [pdf]

#140

Earlier quoted context omitted.

How detailed is your knowledge of undefined behavior?

We know when undefined behavior will occur(the specs are written very clearly), but not what will happen when it occurs. Our job as competent C programmers is to avoid undefined behavior. C isn't hard(perhaps tedious to do correctly) - it does exactly what you tell it to.

You'd be hard pressed to find a non-trivial C program that doesn't contain any undefined behavior.
Post reply on HN