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

Why I Always End Up Going Back to C

deplet.ing

Post reply on HN
Print view View original

11–20 of 76 posts

Re: Why I Always End Up Going Back to C

#11

Post by nacozarina »

I did a lot of c++ in the mid-90s, often on teams with experienced C programmers new to C++.

They had little appetite for C++, it was 90% mgmt saying ‘use the shiny new thing we read about’. I was the FNG who ‘helped’ them get thru it by showing them the tools & lingo that would satisfy mgmt.

OOP is non-scientific and the snake-oil hype made it cancerous. C++ has ballooned into an absurd caricature. It obfuscates business logic with crypto-like strength, it doesn’t clarify anything. I feel like a war criminal. Replacing C++ is one thing but ridding the world of the OOP rot is a far deeper infection.

I later spent years doing my Typhoid Mary bit in the Java community before abandoning the heresy. Repent and sin no more, that’s all one can do.

Re: Why I Always End Up Going Back to C

#12

Post by imtringued »

jezze wrote: post #4

First off, I want to congratulate you on reaching this milestone. I think this is the state where the most seasoned programmers end up. They know how to write code that works and they don't need a language to "help" or "guide" them. Enjoy!

If software development taught me anything it is that everything that can go wrong will go wrong, the impossible will happen. As a result I prefer having less things that can go wrong in the first place.

Since I acknowledge my own fallibility and remote possibilities of bad things happening I have come to prefer reliability above everything else. I don't want a bucket that leaks from a thousand holes. I want the leaks to be visible and in places I am aware of and where I can find and fix them easily. I am unable to write C code to that standard in an economical fashion, which is why I avoid C as much as possible.

Re: Why I Always End Up Going Back to C

#13

Post by pjmlp »

ivanjermakov wrote: post #10

> In C, you can see what the machine is doing. Allocations don’t hide behind constructors, and destructors don’t quietly run during stack unwinding. You can profile at the machine-code level without feeling like you’re peeling an onion, appropriately shedding tears the whole time. This is why explicit control flow is important design goal for systems programming language. This is basically 2/3 of core design principl…

Like setjmp()/longjmp() and signal(), very explicit. /s

Re: Why I Always End Up Going Back to C

#14

Post by rramadass »

kianN wrote: post #3

> Code gets simpler because it has to, and architecture becomes explicit. > The real goal isn’t to write C once for a one-off project. It’s to write it for decades. To build up a personal ecosystem of practices, libraries, conventions, and tooling that compound over time. Each project gets easier not because I've memorized more tricks, but because you’ve invested in myself and my tools. I deeply appreciate this in th…

Agreed.

I generally try to use C++ as a "better C" before the design complexity makes me model higher-level abstractions "the C++ way". All abstractions have a cognitive cost and C makes it simpler and explicit.

Re: Why I Always End Up Going Back to C

#15

Post by rramadass »

nacozarina wrote: post #11

I did a lot of c++ in the mid-90s, often on teams with experienced C programmers new to C++. They had little appetite for C++, it was 90% mgmt saying ‘use the shiny new thing we read about’. I was the FNG who ‘helped’ them get thru it by showing them the tools & lingo that would satisfy mgmt. OOP is non-scientific and the snake-oil hype made it cancerous. C++ has ballooned into an absurd caricature. It obfuscates bus…

> OOP is non-scientific and the snake-oil hype ... ridding the world of the OOP rot is a far deeper infection.

You are spewing nonsense.

Read Bertrand Meyer's Object-Oriented Software Construction, Barbara Liskov's Program Development in Java: Abstraction, Specification, and Object-Oriented Design and Brad Cox's Object-Oriented Programming: An Evolutionary Approach for edification on OOD/OOP.

Re: Why I Always End Up Going Back to C

#16

Post by jezze »

imtringued wrote: post #12
jezze wrote: post #4

First off, I want to congratulate you on reaching this milestone. I think this is the state where the most seasoned programmers end up. They know how to write code that works and they don't need a language to "help" or "guide" them. Enjoy!

If software development taught me anything it is that everything that can go wrong will go wrong, the impossible will happen. As a result I prefer having less things that can go wrong in the first place. Since I acknowledge my own fallibility and remote possibilities of bad things happening I have come to prefer reliability above everything else. I don't want a bucket that leaks from a thousand holes. I want the leak…

This is, perhaps surprisingly, what I consider the strength of C. It doesn't hide the issues behind some language abstraction, you are in full control of what the machine does. The bug is right there in front of you if you are able to spot it (given it's not hiding away in some 3rd party library of course) which of course takes many years of practice but once you have your own best practices nailed down this doesn't happen as often as you might expect.

Also, code doesn't need to be bulletproof. When you design your program you also design a scope saying this program will only work given these conditions. Programs that misbehaves outside of your scope is actually totally fine.

Re: Why I Always End Up Going Back to C

#17

Post by rramadass »

pjmlp wrote: post #9
flohofwoe wrote: post #6

Earlier quoted context omitted.

> It needs to use basic data structures, so it uses GLib. It also need to support runtime-defined connection graph, so it is built on top of GObject. That's running into the age old trap of trying to shoehorn an OOP system into C, just don't do that ;) E.g. don't design your systems around the OOP paradigm in the first place.

If at least C solutions took advantage of abstract data types as advocated by modular design approaches before OOP took off, but no it is all reaching out to field data directly with macros, and clever pointer tricks that fail down. There are several books on the matter, that obviously very few read. Here one paper example from 1985 on the subject, "Modular programming in C: an approach and an example" https://dl.acm…

> If at least C solutions took advantage of abstract data types as advocated by modular design approaches

People have been writing C code with ADTs and "Modules" from the very beginning.

Two excellent examples which come to mind are; Andrew Tanenbaum's Minix book Operating Systems Design and Implementation and David Hanson's C Interfaces and Implementations: Techniques for Creating Reusable Software.

And of course the Linux Kernel is full of great modular C techniques which one can study.

Re: Why I Always End Up Going Back to C

#18

Post by jezze »

pjmlp wrote: post #7

> The language shows you the machine, a machine which is not forgiving to mistakes. Assembly does that, C not really, it is a myth that it does.

True, it doesn't give you the bare machine. What it gives you is the thinnest of machine abstraction with the possibility of linking to your own assembly if you have the demand for it.

Re: Why I Always End Up Going Back to C

#19

Post by rramadass »

acuozzo wrote: post #5
theamk wrote: post #2

C sounds nice if your task is simple enough, or at least if you can decompose this to a series of loosely-connected simple-enough tasks. But sometimes, there is an inherent complexity in what you are trying to implement, then C becomes way, way complex than C++. You build stuff, and there is so many manual steps, and none of them must be missing, or things will subtly break. A good example is "gstreamer", the multime…

> You build stuff, and there is so many manual steps "The real goal isn’t to write C once for a one-off project. It’s to write it for decades. To build up a personal ecosystem of practices, libraries, conventions, and tooling that compound over time."

Right.

The article is well written and the author has touched upon all the points which make C still attractive today.

Re: Why I Always End Up Going Back to C

#20

Post by pjmlp »

rramadass wrote: post #17
pjmlp wrote: post #9

Earlier quoted context omitted.

If at least C solutions took advantage of abstract data types as advocated by modular design approaches before OOP took off, but no it is all reaching out to field data directly with macros, and clever pointer tricks that fail down. There are several books on the matter, that obviously very few read. Here one paper example from 1985 on the subject, "Modular programming in C: an approach and an example" https://dl.acm…

> If at least C solutions took advantage of abstract data types as advocated by modular design approaches People have been writing C code with ADTs and "Modules" from the very beginning. Two excellent examples which come to mind are; Andrew Tanenbaum's Minix book Operating Systems Design and Implementation and David Hanson's C Interfaces and Implementations: Techniques for Creating Reusable Software . And of course t…

Unfortunely I have seen plenty of counter examples since 1991.

Starting with RatC from "Book on C", 1988 edition, over to Turbo C 2.0 in 1991, all the way to modern times.

That is just not how most C codebases look like.

Post reply on HN