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

Two types of C programmers

utcc.utoronto.ca

Post reply on HN
Print view View original

61–70 of 225 posts

Re: Two types of C programmers

#61

Post by sparkie »

srcreigh wrote: post #59
sparkie wrote: post #51

Earlier quoted context omitted.

"register" is still supported by GCC for combined use with asm. eg, `register uintptr_t x asm ("edx");` Does D support anything like `__attribute__((section("t1")))`, so we can have the linker decide how to locate some compiled code, or computed gotos? Can we use D's inline assembler to clobber registers? I've had trouble even with clang and extended asm. For example, LLVM does not support the "g" constraint. I under…

GNU jitter right? I’ve seen (a few?) highly detailed slide decks about it. Extremely cool stuff I found this pdf but I thought there was a different one, anyone link to that? https://binary-tools.net/jitter-binary-tools-summit.pdf

Not jitter, but I'm familiar with it and have used some of its ideas. (More Jitter slides referenced on Luca Saiu's page:https://ageinghacker.net/talks/#jitter-talks)

The (experimental) VM I'm working on embeds type information into pointers. I place some functions at fixed virtual addresses and use the type information from the pointer to materialize these addresses at runtime, without having to dereference any pointers until I actually call the function. Essentially, if you have a pointer you will know the type of value it points to from the pointer itself.

This method places some tight constraints on how memory can be allocated, but I don't think it will be too much of a limitation for most applications intended to run on it. I have 12-bits in a 48-pointer which provide type information, which leaves a maximum 36-bits of virtual address space per type (or 35 bits if you discount the most significant bit which refers to kernel space).

I'm currently using the section attribute to implement it, but I'm aware there are other methods to achieve this. I could do it at runtime by `mmap`ing the virtual memory and then loading in the machine code at the addresses I need. This method might be more flexible in the long run and would free me up from using GCC specific attributes.

Re: Two types of C programmers

#62

Post by psyklic »

fargle wrote: post #19

I appreciate the sentiment, but: - there doesn't have to be "two kinds". Trivially you can fit both "types" at once, I certainly feel that way. And if there are 100 programmers, there'd be about 237 other reasons to use a language. False dichotomy. - a better categorization might be "there are two kinds of C programmers: those who eventually start using rust and those that don't." which is at least of course absolute…

I disagree that enjoying C automatically means you will like Rust. If you are obsessed with safety, Rust will be a nice solution. But Rust is a much more complex language than C, which will turn many C programmers away.

Re: Two types of C programmers

#63

Post by jenadine »

infamouscow wrote: post #35
bluejekyll wrote: post #34

Earlier quoted context omitted.

Out of curiosity, have you looked at the ASM inlining options in Rust? https://doc.rust-lang.org/reference/inline-assembly.html

Rust's inline assembly and configurable targets sets the standard going forward. I just wish their trademark policy relaxed some of the non-trademark related requirements making it a deal-breaker.

What does the trademark policy has to do with this?

Btw the recent fuzz recently was about some proposal and not the actual one. This is the policy: https://foundation.rust-lang.org/policies/logo-policy-and-me... and I don't see any deal breaker.

Re: Two types of C programmers

#65

Post by patrick451 »

pjmlp wrote: post #42
jesse__ wrote: post #33

Earlier quoted context omitted.

> yet they miss that for Plan 9 and Inferno, they also decided to go with automatic memory management languages And which of these three operating systems won?

The free beer one, because everyone likes to get source tapes for free, regardless of the quality, free usually wins out.

This doesn't seem to hold in the general case. Windows and Macos are not free in any sense, but vastly outnumber linux on the desktop.

Re: Two types of C programmers

#66

Post by phendrenad2 »

I think there are way more types, or subtypes. The first category can be broken down into "people who like C because it's simple" and "people who use C because they need to do manual memory management" (and that can be broken down into "has not tried Rust" and "has tried Rust and didn't like it"). The second category can be broken down into "people who wrote a program in the 1980s in C and are now stuck with it" and "people who learned C in the 1980s and haven't tried to learn a new language" and "people who learned C in the 1980s-1990s and think that Python and Ruby would be too slow for their purposes (no longer true)".

Re: Two types of C programmers

#67

Post by Gibbon1 »

up2isomorphism wrote: post #24

“My perception of the second sort of C programmer is that if they've moved to any more recent mainstream language, it's probably Rust.” If you are the first type, you likely get the second type’s taste wrong. Rust is very very different from C both in terms of syntax and philosophy.

I feel like another division is there are programmers who love mathy languages and syntax and those that hate mathy languages and syntax. The former looks down on the latter with contempt. And the latter thinks the former is annoying.

Re: Two types of C programmers

#68

Post by unionpivo »

psyklic wrote: post #62
fargle wrote: post #19

I appreciate the sentiment, but: - there doesn't have to be "two kinds". Trivially you can fit both "types" at once, I certainly feel that way. And if there are 100 programmers, there'd be about 237 other reasons to use a language. False dichotomy. - a better categorization might be "there are two kinds of C programmers: those who eventually start using rust and those that don't." which is at least of course absolute…

I disagree that enjoying C automatically means you will like Rust. If you are obsessed with safety, Rust will be a nice solution. But Rust is a much more complex language than C, which will turn many C programmers away.

But its not really.

Sure it seems so when you start. K&R and away you go, that programming is a lot easier than writing rust sure.

But unless you are writing for just yourself, no current C software get developed that way. You need to understand C standard, that is quite complex and you need to understand it in detail because of undefined behavior (and of course how your compiler interprets it and sometimes fight with compiler to emit right code).

Then you needed to know all the gotchas in the standard library, and how you properly use them. Then you need to know how to do basic arithmetic without having undefined behavior (that's where a lot of memory leaks happen). Or maybe the software you are working on has created their own implementation of most of those functions, so you need to figure how to use those. Even to just print out a debug statement can sometimes be nontrivial.

And of course you need a way to compile the damn thing, just figuring out what sane options you need to use to get decent warnings and what they mean takes a while.

And when you figure all of that out, you still need to keep track of most of the stuff that borrow checker does, but this time by hand using comments and conventions (that you also need to learn for each project.)

(I left out whole build setup, but its usually harder than Rust one too. )

I believe that programmer who has only programmed java or maybe C# before (or python, js...) will get up too up to speed faster on Rust than on C on most real-world projects

C is deceptively simpler.

Re: Two types of C programmers

#69

Post by sparkie »

humanrebar wrote: post #58
sparkie wrote: post #5

I'd consider myself the former: I use C because it's the only viable option for what I'm doing - but most of the time it's nothing to do with C itself, but the various extensions and builtins of GCC. It's the inline asm, the control of registers, placement of code and data, control of inlining, etc, which are missing from all of the C "replacements". The replacements assume you are building a user application on top…

> Obviously there is C++ which can leverage most of this too, but C++ traps you into an ABI which is difficult to use from any language which is not C++. To be fair to C++, all the other languages in this space are as bad at providing ABIs in their own languages. All (almost?) mostly provide ways to declare C ABIs, which C++ also supports. C++ has rough C++ ABIs, but mostly because it bothers to try in the first plac…

C's ABI is that much simpler because it doesn't really place any constraints on the memory layout of your types. With C++ (and others), the values passed around may also have vtables linked to them, so your language must then also provide an in-memory representation of objects which is compatible with the C++ representation in order to do FFI method calls. That places quite a constraint on your language because to do it efficiently you basically want a copy of the C++ object model. So you're developing a kind of C++ sibling language, and C++ is quite complex, and now any other languages which want to interoperate with yours has to do the same.

This is why it's pretty standard to just have a C FFI and provide a C wrapper for C++ libraries to use them with other languages.

Re: Two types of C programmers

#70

Post by thesuperbigfrog »

jesse__ wrote: post #33
pjmlp wrote: post #16

Some people like to workship whatever the UNIX founders have done, yet they miss that for Plan 9 and Inferno, they also decided to go with automatic memory management languages. While Alef failed, Limbo's design with GC was considered a revisit from what was missing from Alef. They also miss that lint was considered a must have tool for safer C code, introduced in 1979, and that Dennis actually proposed fat pointers…

> yet they miss that for Plan 9 and Inferno, they also decided to go with automatic memory management languages And which of these three operating systems won?

"Plan 9 failed simply because it fell short of being a compelling enough improvement on Unix to displace its ancestor.

Compared to Plan 9, Unix creaks and clanks and has obvious rust spots, but it gets the job done well enough to hold its position.

There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough."

Source: https://www.catb.org/esr/writings/taoup/html/plan9.html

Post reply on HN