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

The Development of the C Language (1993)

bell-labs.com

Post reply on HN
Print view View original

181–190 of 536 posts

Re: The Development of the C Language (1993)

#181

Post by marcosdumay »

chongli wrote: post #175
marcosdumay wrote: post #163

Earlier quoted context omitted.

> These statements are not true in languages which support operator overloading I guess I will never understand the C and Java developers incredible fear of operator overloading. Do you have the same reaction to user-defined functions? Because they are exactly the same thing. Is it because of the bad type system that won't let you know what operator you are using?

I guess I will never understand the C and Java developers incredible fear of operator overloading. The answer is in the sentences right before the one you quoted: Relatedly, it's more explicit than almost any other language. If a line of code doesn't look like a function call, it's not calling anything. There is no hidden control flow. Consider the use-cases for C: operating system kernels, hard real-time software, l…

The control flow is the same; you evaluate the parameters, and then evaluate the operator. Just like any other function call, there's nothing implicit or hidden. The only difference is that you can't create other operators with the same name for different types.

And whether something is called or run inline is always decided by the compiler. Modern C doesn't promise you any relation between the way you break down your functions on your code and the actual function calls on the assembly it generates.

So, I keep seeing people complaining about overloading; always with the same reasons; that are patently not valid unless there's some implicit assumption they keep not stating. What is that assumption that breaks the equivalence between user-defined functions and operators?

Re: The Development of the C Language (1993)

#182

Post by haberman »

xscott wrote: post #82
haberman wrote: post #71

Earlier quoted context omitted.

> The point to me is that using memcpy instead of pointer casts is NOT an improvement. The improvement comes when there are multiple accesses that could potentially point to the same memory. Consider a silly function: void f(int16_t* a, int32_t* b) { for (int32_t i = 0; i If type-based alias analysis is enabled, then the compiler can assume that a[0] does not alias b[i] because they are different pointer types. So it…

> Strict aliasing is one of the few tools we have to tell the compiler that aliasing will not occur. I can see the argument, but there's a much better way to indicate what you want with your example: void f(int16_t* a, int32_t* b) { const int16_t a0 = a[0]; for (int32_t i = 0; i Now a clean (well defined) compiler could do what you asked. I've seen other people suggest that UB is a mechanism to have these magical bac…

You are entitled to your opinion. C isn't perfect, but as someone who spends my life trying to optimize the efficiency and code size of critical loops to the max, I like the direction C has gone with UB and optimizations. It's not the right tool for every problem, but for the most size/speed critical code it's hard to beat IMO.

Re: The Development of the C Language (1993)

#183

Post by c_crank »

babarock wrote: post #6

People who still write C, honest question: Why? C is full of quirks. From cryptic "undefined behaviors" to a type system that isn't really a type system (more like "size hints for the compiler"), the language doesn't feel easy to use/debug. Add to this CPP macros, a universally recognized bad idea, a clunky import system, and lack of a single reference implementation of the compiler/libC, and you have a language that…

Writing C code is fun and enjoyable. C programs are typically fast due to the use of primitives and low overhead. C's set of tools and abstractions typically forces you to think about how best to implement a particular data structure or interface, which is the kind of problem I most enjoy.

>I used to think "C presents the most honest representation of the low-level mechanisms of the computer", but... even this is shaky. I've been programming for almost 15 years now, and I don't think I've ever seen a computer where memory is actually a continuous array of bits sorted by memory address. The C representation of memory (and all the pointer arithmetic) is not a real representation of your hardware, and this too is an abstraction.

Pointers are an abstraction, but they are less abstract than most languages simply assuming there is just one giant sheet of memory to take from.

Re: The Development of the C Language (1993)

#184

Post by zabzonk »

pjmlp wrote: post #140
zabzonk wrote: post #130

Earlier quoted context omitted.

they should simply use c++, like k&r did to compile their example code in their 2nd ed - see preface to book if you don't believe. i will never understand why C programmers get so upset about C++. of course, the latest revisions of C introduce some new features not in C++, but nothing really major. if you want good type checking, compile your C code with C++, and fix all the type errors you will get.

Petzold did the same on his highly acclaimed book for Windows 3.x book, also with a note on the preface regarding type safety. Likewise, Microsoft introduced windowsx.h header file, to improve type safety while using C for Windows 3.x applications.

> Petzold did the same on his highly acclaimed book

takes me back. i thought it was crap. i used to work at The Instruction Set (one of UK's biggest tech training companies at the time) and everyone hated the Windows/C course based on Petzold. my boss came up to me (somehow I was the windows guy in a unix company) and said "we need a new windows course" and me said "OK, i need a framemaker license and to work at home for a week" - worked out great.

this was early 90s, i suppose?

Re: The Development of the C Language (1993)

#185

Post by varjag »

Philip-J-Fry wrote: post #26
moffkalast wrote: post #19

Earlier quoted context omitted.

So we're gonna be stuck writing a precambrian prototype language till the end of time because there's so much legacy code already written in it? Never seemed to stop people moving from Pascal, or Perl or literally all other languages that are now obsolete. I really hate how for microcontrollers the only two choices are either C++ or Micropython, I mean how about some fucking middle ground instead of two polar opposit…

>I really hate how for microcontrollers the only two choices are either C++ or Micropython There's TinyGo as well. https://tinygo.org/ I'd say that's the middle ground for me.

There's a niche doing C++ (vs. straight C) on microcontrollers but the rest are just tinkerer choices.

Re: The Development of the C Language (1993)

#186

Post by pkkm »

jrvarela56 wrote: post #168
pkkm wrote: post #68

Earlier quoted context omitted.

1. It gives me a lot of control over how the program works, which lets me create programs that work faster and use less memory than would be possible in most other languages. 2. Relatedly, it's more explicit than almost any other language. If a line of code doesn't look like a function call, it's not calling anything. There is no hidden control flow. These statements are not true in languages which support operator o…

Thank you for the input, one point that stood out for me was that you prefer to write command-line utilities with C. Why is that? I use scripting languages mostly in my day work (Ruby and some Python bc AI) and have found my productivity using command-line utilities is amazing with Ruby. Do you do it bc of performance, ease of use bc you are proficient, a mix of both or something else?

Oh, I don't use C for every command-line utility. If it's something IO-bound like parsing a webpage and downloading a bunch of files linked from it, I write it in Python. The convenience of modules like argparse and requests is very hard to beat, and it would take me a lot longer to do it in C.

I reach for C when performance matters, for example when processing multi-GB files or looking for perceptual hashes that are similar. It can be a difference between minutes and hours of running time.

Re: The Development of the C Language (1993)

#187

Post by c_crank »

creata wrote: post #148
pkkm wrote: post #68

Earlier quoted context omitted.

1. It gives me a lot of control over how the program works, which lets me create programs that work faster and use less memory than would be possible in most other languages. 2. Relatedly, it's more explicit than almost any other language. If a line of code doesn't look like a function call, it's not calling anything. There is no hidden control flow. These statements are not true in languages which support operator o…

> If a line of code doesn't look like a function call, it's not calling anything. Why is that important to you?

Some of the worst bugs I have experienced are ones where code is executing without it being clear where it is executing. The front end stack is the most awful about this, where at any given moment all kinds of things might happen without notice. A clear, sequential program can be stepped through and understood.

Re: The Development of the C Language (1993)

#188

Post by c_crank »

lordnacho wrote: post #57
babarock wrote: post #6

People who still write C, honest question: Why? C is full of quirks. From cryptic "undefined behaviors" to a type system that isn't really a type system (more like "size hints for the compiler"), the language doesn't feel easy to use/debug. Add to this CPP macros, a universally recognized bad idea, a clunky import system, and lack of a single reference implementation of the compiler/libC, and you have a language that…

> I used to think "C presents the most honest representation of the low-level mechanisms of the computer", but... even this is shaky. I've been programming for almost 15 years now, and I don't think I've ever seen a computer where memory is actually a continuous array of bits sorted by memory address. The C representation of memory (and all the pointer arithmetic) is not a real representation of your hardware, and th…

C presents a fairly honest representation of the low level mechanisms of x86 Assembly. The way Assembly has drifted away from actually CPU instructions is interesting, but not something a programmer will get much benefit from trying to deal with. Itanium was an interesting experiment, but the new set of instructions did not offer large gains in practice.

Re: The Development of the C Language (1993)

#189

Post by aap_ »

babarock wrote: post #6

People who still write C, honest question: Why? C is full of quirks. From cryptic "undefined behaviors" to a type system that isn't really a type system (more like "size hints for the compiler"), the language doesn't feel easy to use/debug. Add to this CPP macros, a universally recognized bad idea, a clunky import system, and lack of a single reference implementation of the compiler/libC, and you have a language that…

> People who still write C, honest question: Why?

It was my first programming language and I still think it's a simple and fun language. Also many things have a native C interface so it's a natural choice in those cases. It's certainly not the only language I use, but for many things my default. What's nice is that I don't have to consciously think much about the language when I use it because I know it well.

Re: The Development of the C Language (1993)

#190

Post by c_crank »

kaba0 wrote: post #128
xyzzy_plugh wrote: post #124

Earlier quoted context omitted.

What are you talking about? "in-built"? Have you ever written SIMD assembly before? It's comically easy to integrate SIMD optimizations into a C program.

Through in-built assembly, or some compiler-specific annotation. None of them is vanilla C , which was my point.

Part of what makes C touted as a 'low level language' is the relative ease of inlining assembly.
Post reply on HN