Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“C is how the computer works” is a dangerous mindset for C programmers

words.steveklabnik.com

Post reply on HN
Print view View original

351–360 of 387 posts

Re: “C is how the computer works” is a dangerous mindset for C programmers

#351

Post by pjmlp »

armitron wrote: post #218
jcranmer wrote: post #203

Earlier quoted context omitted.

> the 2017-11-17 working draft of the C++ standard is 1,448 pages in PDF format. To be fair, that contains both language documentation and library documentation. The language specification portion itself is only ~400 pages, which is smaller than the Java Language Specification and JS's specification (both about 700-800 pages, although JS does include its [meager] standard library in there).

When it comes comprehensibility, the C++ standard is orderS of magnitude more difficult than the JLS due to the numerous interdependencies and layers upon layers of cruft. There is no single, cohesive model to understand. That is the fatal flaw of C++ and I guess what led to Stroustrup's couple-of-decades-too-late "Remember the Vasa!" proclamation.

As someone that has been using Java, .NET, C++, OpenGL, DirectX, Win32, Linux and Web since their early days, you will never have a cohesive view in any of them, specially if not being there when that decision X was discussed in the community and there are no written traces of why it was taken that way.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#352

Post by adev_ »

lliamander wrote: post #272
jeffdavis wrote: post #204

Earlier quoted context omitted.

The "right tool for the job" is a myth (EDIT: exaggerating; clearly it applies in some cases). Languages don't work together very well, so you need huge, thick boundaries between them, such as serialization/deserialization. Data types don't match up, GCs require special data formats and don't line up with the GCs of other languages, other runtime weirdness, etc. At minimum, you need lots of copying/transformation of…

A really thought-provoking argument. I suppose that when it comes to choosing "the right tool" the important thing is to optimize globally across the problems that your organization will be solving. But if you want to be able to optimize both globally and locally, well that's just an engineering problem! Two examples spring to mind: 1. Lisp. Lisp's metaprogramming facilities allow you to build the language into the s…

You got it yes. And very few Software Engineer understand that unfortunately.

The reason C is so successful is named ABI.

C (and C++ to some extend) can be used to produce library that can be used from any higher level language in existence. And this is strictly required in the heterogeneous world we live in.

If you have to write a system components, long lifetime, implementing a protocol / database / format / any-low-level-staff: You do not have choice, safety or not. It is going to be C or C++, because it is the only thing reusable in most other environment.

Python has pybind11, Java has JNI, Lua operate beautifully with C/C++, Node is itself C++, go has cgo, Ruby is in C, any proper programming language can interface with C or C++.

They are the only languages allowing that, and that is why they are still alive, very well alive, even if they are unsafe.

As long as new language authors will be more obsessed about supporting new fancy feature instead of providing a well defined ABI (C compatible). The situation will not change.

Rust might be the new comer in this area that has its chance. But for the time being, it is still too young: you have to map every Rust API to a C one manually to make it exportable.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#353

Post by pjmlp »

pdimitar wrote: post #219
amiga_500 wrote: post #207

Earlier quoted context omitted.

C++ should only be used as a last resort. It's complex, development is slower, the tooling is poor, some universities have stopped teaching it. It's very hard to hire good C++ devs, and they are typically not cheap. I manage a c++ team btw. Our app has to be fast.

As your parent said, this is also an answer I can understand. Still, have you guys looked at alternatives -- and seriously evaluate them? Rust, Zig, Nim, D, others? If you tell me "we can't afford to, we have too much work" then that's also a valid answer (for a while at least).

Our alternatives are Java and .NET languages, with native bindings to C++ libraries.

C++ alternatives still need to grow up to this kind of mixed language development, where I can have .NET code with C++ libraries and easily debug across them on the same Visual Studio session.

Same applies to Java and C++ development experience.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#354

Post by pjmlp »

jeffdavis wrote: post #316
ChrisSD wrote: post #286

Earlier quoted context omitted.

To be precise, C does not have a defined ABI (the spec goes out of its way to avoid this). Platforms (OS+Arch) define a C ABI for their own tools. Since this ABI is required to interop with the OS APIs, this will usually become the de-facto standard for the platform. This might seem like nitpicking but it's an important distinction because you can't assume that C data structures can be passed between different platfo…

What is the right way to say that without sounding too pedantic every time? "Most platforms define a stable C ABI"?

The only platforms that define a stable C ABI are those whose OS is written in C and exposes a C API to userspace.

Symbian did not had a C ABI for example, nor do mainframes, in ChromeOS or Android you also don't have a C ABI exposed to userspace, in Windows a C ABI also won't help you much if you need to speak COM or now UWP.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#355

Post by pjmlp »

saagarjha wrote: post #211
andrepd wrote: post #195

Earlier quoted context omitted.

There's no "bitcast" operator that changes the type of a value without affecting the value. The most common workaround involves going through memory and praying the compiler will optimize that away (while violating strict aliasing semantics to boot). Access through a union allow the same region of memory to be interpreted as different types. No support for multiple return values (in registers). There's structs, but t…

> Access through a union allow the same region of memory to be interpreted as different types. …only in C. > No mainstream compiler will ever not optimise that. Actually, it's mandated by the System-V ABI for structures of an appropriate size.

Which is not supported in every OS out there.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#356

Post by pjmlp »

steveklabnik wrote: post #275
badtuple wrote: post #267

Earlier quoted context omitted.

Does anyone code directly in LLVM IR? I've had the thought of toying with it as a better portable assembly with a crazy optimizer behind it...but since the LLVM folk want it to be an implementation detail they warn against it due to how volatile it is across versions. I'd be really interested to hear experiences of people who have done it though, even as a toy.

LLVM IR isn't exactly portable, so that doesn't really work.

The bitcode variant used by Apple for their OSes tends to be more clean in that regard.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#357

Post by pjmlp »

overgard wrote: post #20

To be fair, even assembly language isn't how the computer works (gets translated into micro code). Not to mention other integral components like the GPU that are coded in an entirely different model. I think what's fair to say is: the "abstract C machine" tends to have a minimal amount of concepts on top of the machines instruction set, compared to other languages, and generally provides the least friction if you nee…

Except that those concepts are also available in Modula-2, Ada, Object Pascal, PL/I, Basic among other possibilities.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#358

Post by pjmlp »

pcwalton wrote: post #242
alharith wrote: post #113

Earlier quoted context omitted.

Just pains me that the Rust team is so oblivious to the fact that they need a spec if they ever hope to have a chance to replace C.

And yet C, which had no spec at the time, beat out Algol, which had one.

You had to pay for Algol compilers, while C came for free with UNIX tapes that landed on university labs out of Bell Labs.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#359

Post by pjmlp »

yjftsjthsd-h wrote: post #283
rhinoceraptor wrote: post #215

Earlier quoted context omitted.

OpenBSD has almost a singular focus on security, and even they have vulnerabilities. If they can't write safe C 100% of the time, what hope does anyone else have?

So... Is there an OS with zero vulnerabilities written in Rust/Go/Ada/anything that I should know about? If nobody's written safe Rust/Go/Ada/whatever 100% of the time, what hope do I have? Now, I think that particular argument is poor. The more defensible version would be to look at the proportion of errors that occurred in C that would not occur in your language of choice, versus the number of errors that occur in…

Yes, Unisys ClearPath MCP, written in NEWP, a secure systems language 10 years older than C.

It is still in use, because when governments want safety above anything else, they buy such OSes, not UNIX clones.

https://www.unisys.com/offerings/clearpath-forward/clearpath...

Re: “C is how the computer works” is a dangerous mindset for C programmers

#360

Post by quietbritishjim »

quietbritishjim wrote: post #319
aidenn0 wrote: post #294

Earlier quoted context omitted.

I keep hearing this rumor, but C99 did not erroneously include unions-as-type-punning in a list of undefined behavior. The normative language is unclear, but clarifications were added1][2]. 1: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_257.htm 2: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_283.htm

The parent comment seems to be saying that C99 does allow type punning with a union, with an explicit clarification as you say. In C89 it was ambiguous and in C++ it is explicitly disallowed (you are supposed to use memcpy).

Sorry, I misread the parent comment. Now it's too late to delete mine, please ignore.
Post reply on HN