Another day for the HN crowd to express their distaste for C :)
Except it isn't.
It's just a hammer, with a handle of a hammer.
> And also sometimes explodes killing
Except it doesn't.
At best, some people are reckless and end up causing problems due to their recklessness.
Enough with these silly hyperboles. Cushioned environments lead to less problems.
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 is JavaScript, python and plethora of other safe and cozy languages, but: the low level has to be done.
Simply most of us don't have your towering intellect to appreciate it. Got it.
Tools are tools, some are used with a great amount of care: jackhammers, routers, compression hammers, chainsaws etc.
Heck: driving a vehicle is probably the single most dangerous activity we do on a daily basis.
This is a tautology.
What do you expect to happen on signed overflow?
We shouldn't have to work like this anymore. C's been an amazing language, but it's getting time to gently, respectfully, move on. There's active and interesting development in alternatives which attempt to retain C's primary advantages while also allowing the compiler to keep you out of trouble as much as possible.
We have hugely powerful computers available to use as developers. We can contemplate designing and compiling languages with a complexity which would have completely defeated the systems available when C was developed. Why shouldn't we use some of that power to make our lives easier?
thought you were talking about java bloatware for a second. Oh your OS doesn't have 1.2gb for HelloWorld.class? Enjoy your OutOfMemoryException!
If you are in for cutting a tree, go for it.
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.
- A lack of suitable replacement for C?
- C is too ubiquitous?
- C has been an integral part of most of the best software ever written?
I would guess the "C apologism" in the original comment is referring to defenses of C that pretend C is safe "in practice" (or "for people who know what they're doing") or minimise/ignore the strong correlation between the use of C and serious problems/vulnerabilities.
Otherwise, I'd say try something like Rust. And if Rust doesn't make the cut, maybe go write your own C-like dialect, with less undefined behaviour.
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... a bug.
B: "I've been using syringes for 35 years and clean needles won't get rid of HIV entirely".
Well no duh. But that isn't really a counter argument.
> become so bloated it was in itself
Whereas C is the pinnacle of expressiveness?
I realise the compiler/runtime can't stop all bugs but fixing these simple errors goes a long way to producing robust secure software.
The black-and-white security fallacy again!
The simple fact (and this is a fact, not an opinion) is that the most severe security problems—remote code execution, in particular—are found way way way more in programs written in C and C++ than in other languages.
However, the nature of where C/C++ code is used does lend itself to severe problems. When you have a JVM vulnerability, you shouldn't be able to get any farther than a regular user with only sandbox privileges. When you have a kernel vulnerability, by definition you have the keys to the kingdom.
Of course there are always holes that can be used to escalate, but that also comes back to the problems of having a primarily C/C++ ecosystem...
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. But just like this place's obsession with Rust would lead to derisive mockery by "real" systems people, so too is C hated here.
It also doesn't help that universities, at least in the US, seem hellbent on teaching along these lines. A few years ago Eclipse was "the thing you use when you are poor or doing Java". These days? I am seeing disturbing numbers of graduates who refuse to use Visual Studio for a project on Windows and insist on boostrapping together something that is only half functional. And talking to my academia friends (and even doing a fair amount of guest lecturing for them), I know where the indoctrination is coming from.
We were supposed to be able to use C in the OS design classes from our C++ learnings.
My problem is the almost dogmatic indoctrination that goes along with it. My cousin's Intro to CS class was taught by a professor who spent about a third of the time basically parroting Stallman (he actually would regularly bring up blog posts and articles on the screen and read them to the class...) and screaming about how everyone needs to use either Vim or Jetbrains tools. That isn't teaching. That is pushing an agenda. And it just makes for worse students and hell for those of us who still spend some time with the interns and new hires.
Always explore new and better tools. But understand why. Sous-vide is awesome and has the potential to make some of the best food you will ever eat. But it also understand that even a "worse" method can be much more efficient or effective.
To quote Alan Kay: Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind.
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.
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.)
That nomenclature has been around for decades. We ALL know they're different languages.
Most generalizations about HN are merely projection based on sample bias, so please don't post such generalizations unless you have representative data.
We're thinking about adding that sentence to the site guidelines, because spurious general claims about HN are a cliché here.
And, I thought it was pretty clear with the "probably something like" and "99%" that it was a number being pulled out of my arse for the sake of discussion.
That being said, actual data on the skillsets and interests of the more active members would be a very interesting bit of data. But it is also really hard to measure as lurkers don't contribute to discussion but will gladly vote in a poll.
It's extremely common to do this (I'm not picking on you personally!), but such generalizations have no objective value and lead to repetitive, low-quality discussion, which is why I think we're going to add a guideline asking people not to do it.
And if your issue is actually that I very clearly pulled a number out of my arse and went out of my way to make it clear that I had: Are you also going to make it mandatory for everyone to preface every non-cited statement with "in my opinion"?
Look, I get that this is your bread and butter and that it is important for HN to be presented as being THE place for tech and blah blah blah and being pigeonholed into "a site for web and app developers who like silicon valley" isn't necessarily what you want, but trying to pretend that a rule to not "generalize" as a way to not have people speculate and discuss why some topics just aren't particularly welcome here isn't the way to go. Just make it a rule, you aren't fooling anyone.
Also, if you REALLY wanted to improve discussions here: Make a rule against pseudo-technical naval gazing (is there a term for that? "Naval gazing" is more associated with philosophy and potheads) as far too many threads devolve into "We can't help but be introverted because our minds are designed that way and I need to be isolated to code because I need to optimize everything".
On the other hand, where the language gets promoted, I haven't seen anyone really promote C in a way that would sound modern in any sense, where people who have years of experience with C stick with C89 or use C99 in a C++ compatible fashion (i.e. without any C99 syntax which C++ has not adopted officially like restrict keyword or designated initializers). While that is fine for personal preferences, I think it does a disservice to people who have to learn the language and use the language for various justified reasons of their own and there isn't a unified response in how to really teach C to them.
I think the author really hits the hammer on the head with this part in the introduction.
"In contrast to the ubiquitous presence of C programs and systems, good knowledge of and about C is much more scarce. Even experienced C programmers often appear to be stuck in some degree of self-inflicted ignorance about the modern evolution of the C language. A likely reason for this is that C is seen as an "easy to learn" language, allowing a programmer with little experience to quickly write or copy snippets of code that at least appear to do what it’s supposed to. In a way, C fails to motivate its users to climb to higher levels of knowledge."
But on this book, from what I have read from past revisions, it's very well written and I have even learned some things from it I didn't know existed in C, like using the keyword static in array indices in parameter declarations. While it is not a perfect resource and I don't think anyone new to programming would be able to read this without guidance, it does some things extraordinarily well which I haven't really seen other C books touch on. Its treatment of undefined behavior is top notch and the way that it tries to explain the memory model of C is pretty good as well.
But had this book been written for another "antique" language, like Modern Fotran or Modern Cobol (which both had their last ISO standards most recently in 2008 and 2014 respectively, mind you), I doubt there would be this much polarization in the comments section.
Sniper rifles are improving every year. Yet a rifle from the 40's can kill people too. Both deadly in the hands of an expert and dangerous in the hands of an amateur. It's the same with C. You should be able to understand the computer on that level but you don't need C just to prove it.
We both know that is not always true and heavily depends on the type of software though.. Take https://github.com/micropython/micropython for instance: what higher level language but C would allow that to run with the same performance as it has now, on as much different devices? C++ would be a viable answer, but when used e.g. as C + templates it's basically still a form of C and anyway your complaints have been raised in nearly the exact same wordings about C++ laguage as well..
The availability of compilers for a specific architecture is orthogonal to the language.
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.
It was already like that 10 years before C was invented, but their authors didn't want to invest too much resources creating an Extended Algol, PL/I or similar compiler.
ESPOL and NEWP were already available in the 60's.
This CPU power galore is just a short lived period before people want full phone VR on a battery for two hours or what have you. You can sort of see what's in demand now for $200k jobs and the tools there don't appear to be very high level or user friendly. If anything they all require few heavy courses in statistics.
It could have been written in any other language that compiled to native code, if we had more options available.
1. the type that do something
2. the type that claim they could do it better than the first group (this is by no means limited to programming, it is for example pretty common in politics)
So please show me an OS written in Go or Rust or Ruby or Python or Java that people can actually use for day-to-day tasks.
Yes, C++ is very entrenched. That is a problem. We should be fixing that.
Now the historical accident theory is pretty obvious: it could have been an Algol, Fortran derivative instead of C, if only UNIX used that as a basis. C itself could have been designed differently, and if so would probably have different flaws and qualities.
Asking for a Rust/Go/Whatever OS is dishonest, because you know full well it will fail for reasons that have nothing to do with the underlying language's intrinsic qualities: even if that OS is great, nobody expect it to be so great we all have to switch away from Windows and Linux. Well, except maybe if we prove the correctness of the kernel, hence ensuring the absence of many vulnerabilities. Research is ongoing, I'd like to see where that goes.
Lots of Pascal, but Pascal really was an engineering constraint at the time if you were doing actual system programming. And back then, that was a serious consideration.
In the 80's using C on MS-DOS, was only seen by those that had UNIX at work or universities and wanted to work home.
It wasn't even C, rather SmallC or any other K&R dialect.
In any case, everyone that cared about performance was using TASM and MASM, writing everything in Assembly.
I go along with historical accident to account for Unix's success, though Richard Gabriel thought it was a case of Worse Is Better trumping The Right Thing.
UNIX is the VHS of operating systems.