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

141–150 of 225 posts

Re: Two types of C programmers

#141

Post by vivegi »

pjmlp wrote: post #25
vivegi wrote: post #15

I learnt C in college but C++ was emerging as the language of choice circa 1995 when I got into my first job. This was before C++ was standardized and we had to make do with whatever MSVC 1.5 would do. It did not even support templates back then and even the highly polarizing STL did not exist yet -- in a cross platform way; The STL source itself was available from 1994, and if I recall right, the C++ compiler on Sun…

Borland did templates since 1993, Borland C++ 2.0 and Turbo C++ had early support for them, and BIDS 2.0 changed from pre-processor macros into the templates experimental design. MSVC was always behind until Borland management messed up.

Yes, that’s right. In fact, in college we used Borland compilers.

But my first job had standardized on MSVC. So, that determined what I used on the job.

Loved Turbo Pascal and Turbo C++ IDEs in those days. Simple and fast!

Re: Two types of C programmers

#142

Post by kps »

fsckboy wrote: post #138
kps wrote: post #98

C programmers are implicitly converted to the required type. Implicit conversions are one thing I don't like about C, or at least the way it ended up as int grew (maybe it would have been better if ANSI had picked unsigned-preserving, but maybe that's just grass-is-greener thinking). I also don't like how UB turned into “a license for the compiler to undertake aggressive optimizations that are completely legal by the…

> C programmers are implicitly converted to the required type. stop trying to coerce me

Consider it a promotion.

Re: Two types of C programmers

#143

Post by zabzonk »

gavinhoward wrote: post #119
zabzonk wrote: post #111

Earlier quoted context omitted.

i have written a fair bit of code using the windows and posix APIs, and they are OK - what features of these, often written by talented programmers, do you despise so much?

To pick the same example from both, I hate both fork() and CreateProcess(). Microsoft wrote "A fork() in the Road" [1] describing the problems with fork(), and they are right: fork() is too simple, it doesn't scale, it is inefficient, and error handling becomes next to impossible. (In my code, I have the child process return exit codes from 255 on down for error handling. It assumes, probably wrongly but right enough…

and does your library support threads? in my opinion, MS made the better design decision - first-class support of threads over forking new processes.

but this is why we have different software architectures :-)

Re: Two types of C programmers

#145

Post by throwawaymaths »

preseinger wrote: post #140
asveikau wrote: post #129

Earlier quoted context omitted.

What you mean to say is you have no shot at correct C, and so the language scares you, and you believe since you can't do it nobody does. It's true that the community at large writes lots of bugs. But that doesn't mean some people aren't productive with the language and write a relatively low number of bugs. There are some projects with better track records at this than others.

no, that is not what i mean to say at scale, it is not possible for humans to hand-write C programs that are free of segmentation fault class errors this is not controversial or in any way arguable

Sel4 would like to have a word.

Inb4 you move the goalposts for "at scale". This is an operating system with capability-based access control which is not something that most operating systems even have.

Also the cryptographic constraints are part of the proof system.

Re: Two types of C programmers

#146

Post by gavinhoward »

zabzonk wrote: post #143
gavinhoward wrote: post #119

Earlier quoted context omitted.

To pick the same example from both, I hate both fork() and CreateProcess(). Microsoft wrote "A fork() in the Road" [1] describing the problems with fork(), and they are right: fork() is too simple, it doesn't scale, it is inefficient, and error handling becomes next to impossible. (In my code, I have the child process return exit codes from 255 on down for error handling. It assumes, probably wrongly but right enough…

and does your library support threads? in my opinion, MS made the better design decision - first-class support of threads over forking new processes. but this is why we have different software architectures :-)

My library does support threads. In fact, it has structured concurrency as a theme through the whole codebase, based on OS threads.

I do agree that first-class thread support is better.

Re: Two types of C programmers

#147

Post by gavinhoward »

throwawaymaths wrote: post #144
gavinhoward wrote: post #87

Earlier quoted context omitted.

I hate it.

Care to explain why?

Several things, but I'll name two.

comptime just doesn't fit my brain well.

Async Zig gives me a headache. [1]

[1]: https://gavinhoward.com/2022/04/i-believe-zig-has-function-c...

Re: Two types of C programmers

#148

Post by throwawaymaths »

klyrs wrote: post #20

I'm old enough to be in both camps. After years of toodling around in a variety of BASIC languages, I took a class on C. For the first time, I went from a vague text-to-result association to a clear picture of machine and its inner workings*. I then learned C++ and Java which were both hot garbage at the time, and a variety of scripting languages. The scripting langues are great for high productivity and mediocre per…

> Zig is there on performance, but for my purposes, the language gets in the way

I guess zig for me is indeed a slightly more complicated language than c, and it's way more verbose, but what I appreciate about it is that straightforward code looks good and code that is on shakier ground looks hairier which is basically a "this code is sus, plz review the fuck out of it" sign.

In the end though, what gets in the way for me with C is everything else to ship a "real c program", especially when you want/need someone else's code. Lexical macros, header/code separation, flat namespace, errno, architecture dependent definitions for int, char, etc, having to think about object (file) units, make, automake, config...

At that point the cognitive burden is enough that a small added complexity in the language is worth it

Re: Two types of C programmers

#149

Post by throwawaymaths »

gavinhoward wrote: post #147
throwawaymaths wrote: post #144

Earlier quoted context omitted.

Care to explain why?

Several things, but I'll name two. comptime just doesn't fit my brain well. Async Zig gives me a headache. [1] [1]: https://gavinhoward.com/2022/04/i-believe-zig-has-function-c...

Got it. Thank you for your perspective. I can appreciate that comptime is tricky. Indeed, async zig is hard and annoying (but you're wrong about the function coloring... Here is someone's project where they call an async function alternately from a sync or async context with zero lines of code:

https://youtu.be/lDfjdGva3NE?t=1999

Yielding is async and threaded is sync)

Re: Two types of C programmers

#150

Post by gavinhoward »

throwawaymaths wrote: post #149
gavinhoward wrote: post #147

Earlier quoted context omitted.

Several things, but I'll name two. comptime just doesn't fit my brain well. Async Zig gives me a headache. [1] [1]: https://gavinhoward.com/2022/04/i-believe-zig-has-function-c...

Got it. Thank you for your perspective. I can appreciate that comptime is tricky. Indeed, async zig is hard and annoying (but you're wrong about the function coloring... Here is someone's project where they call an async function alternately from a sync or async context with zero lines of code: https://youtu.be/lDfjdGva3NE?t=1999 Yielding is async and threaded is sync)

I'm not wrong.

He claims that you can call functions fine in either mode if the functions are known at compile time. I never disputed that.

If he tried to call those functions with possibly unknowable function pointers at runtime, I doubt it would work as well.

There is a difference between compile time and runtime. At compile time, Zig can transform known functions to async to allow turn to call async functions. At runtime, that's not possible.

The 75 examples in my post show that.

Post reply on HN