Live data from Hacker News

Why I Always End Up Going Back to C

deplet.ing

71–76 of 76 posts

Re: Why I Always End Up Going Back to C

#71
post #55

Earlier quoted context omitted.

It's not the "string library" that's important, but standardized interface types - so that different libraries can pass strings to each other while still being able to select the best string library that matches the project's requirements. In C this standardized string interface type happens to the poiinter to a zero-terminated bag of bytes, not exactly perfect in hindsight, but as long as everybody agrees to that st…

Are you saying that if you join existing project which uses acuozzo_strzcpy, and you need to do some string copying, instead of using the same functions that everyone already uses, you'll bring your own library and start using flohofwoe_strjcpy in all code _you_ write? (Assuming both of those work on char* types, that is)? This.. does not seem like a very good idea if you want your contributions to be received well.

I mean, it depends? The fact that it's possible doesn't mean it's a good idea, but at least it's possible. Maybe flohofwoe_strjcpy has a slight performance advantage in an extremely esoteric edge case but extremely hot loop that wasn't considered by acuozzo_strzcpy.

Re: Why I Always End Up Going Back to C

#72
post #58

Earlier quoted context omitted.

It is, because C is nothing special, those features are available in other languages. Proven before C was even a dream at AT&T, and by all other OS vendors outside Bell Labs using other systems languages. Then people get to argue C can X, yeah provided it is the Compiler XYZ C dialect.

Not quite. C took off because system programmers could not do with other languages what they wanted, with the ease and flexibility that C offered. Having a feature in a language is not the same as how easy it is to span hardware, OS and application in the same language and runtime.

Not really.

C took off because it was free, shipped alongside with an operating system that initially was available for a symbolic price, as AT&T was forbidden to take advantage of UNIX.

Had UNIX been a commercial operating system, with additional licenses for the C compiler, like every other operating systems outside Bell Labs, we would not be even talking about C in 2026.

Re: Why I Always End Up Going Back to C

#73
post #55

Earlier quoted context omitted.

Are you saying that if you join existing project which uses acuozzo_strzcpy, and you need to do some string copying, instead of using the same functions that everyone already uses, you'll bring your own library and start using flohofwoe_strjcpy in all code _you_ write? (Assuming both of those work on char* types, that is)? This.. does not seem like a very good idea if you want your contributions to be received well.

I mean, it depends? The fact that it's possible doesn't mean it's a good idea, but at least it's possible. Maybe flohofwoe_strjcpy has a slight performance advantage in an extremely esoteric edge case but extremely hot loop that wasn't considered by acuozzo_strzcpy.

(Not a GP) I think you can see how poorly the string abstraction argument looks in context of a team-based project. Instead of dismissing it completely I would like to provide an example of a context where C is perfectly fine now.

Consider data compression library like Oodle. Even with closed source and use of dangerous things like multiple threads it is perfectly reasonable deal if game project's budget has money to be spent on performance.

The thing is if game project have money it is not likely to be interested in written in C game engines or core middleware libraries (like physics, sound or occlusion culling). Because after buying a license your team is still expected to work in that code even if official support is very active.

Disclaimer, I work in gamedev and never needed to touch C code.

Re: Why I Always End Up Going Back to C

#74

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.

  > Brad Cox's Object-Oriented Programming: An Evolutionary Approach
i liked this one and got some good insights from it, though it was so old it was hard to get through...

the snake-oil aspect though, i think is true to a large extent:

oop became a huge hype and a marketing term, and things like c++ and java oop are so far away from the original ideas of the original 'oop' of smalltalk and we have been suffering from really bad/low quality abstractions (javas infamous FactoryFactory pattern, subclass everything etc) for a long time...

Re: Why I Always End Up Going Back to C

#75
post #72

Earlier quoted context omitted.

Not quite. C took off because system programmers could not do with other languages what they wanted, with the ease and flexibility that C offered. Having a feature in a language is not the same as how easy it is to span hardware, OS and application in the same language and runtime.

Not really. C took off because it was free, shipped alongside with an operating system that initially was available for a symbolic price, as AT&T was forbidden to take advantage of UNIX. Had UNIX been a commercial operating system, with additional licenses for the C compiler, like every other operating systems outside Bell Labs, we would not be even talking about C in 2026.

Being easily affordable/available in those times was the initial "hook" but C's subsequent and sustained success was due to a happy confluence of various design decisions.

Not too high-level, Not too low-level, easy access to memory/ISA, simple abstract machine, being imperative procedural, spanning bare-metal/OS/app, adopted by free software movement producing free compilers/tools, becoming de-facto industry standard ABI etc. all were crucial in its rise to power.

Note that its main competitor at that time, Pascal; lost out in spite of being simpler, having clean high-level features, promoted by academia, safety focused etc.

As Dennis Ritchie himself said in "The Development of the C Language" (https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist...);

C is quirky, flawed, and an enormous success. While accidents of history surely helped, it evidently satisfied a need for a system implementation language efficient enough to displace assembly language, yet sufficiently abstract and fluent to describe algorithms and interactions in a wide variety of environments.

Re: Why I Always End Up Going Back to C

#76

Earlier quoted context omitted.

> 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.

> Brad Cox's Object-Oriented Programming: An Evolutionary Approach i liked this one and got some good insights from it, though it was so old it was hard to get through... the snake-oil aspect though, i think is true to a large extent: oop became a huge hype and a marketing term, and things like c++ and java oop are so far away from the original ideas of the original 'oop' of smalltalk and we have been suffering from…

> c++ and java oop are so far away from the original ideas of the original 'oop' of smalltalk

This is the fundamental misunderstanding; there is no "original OOP" but different "strains of OOP" viz. the Simula67 vs. Smalltalk models.

C++ followed the Simula approach (i.e. static object model) while Java is hybrid mixing both Simula and Smalltalk approaches (i.e. dynamic object model but with static typing). You have to look at the entirety of the OOD/OOP domain to understand how modern languages have evolved OOP support.

See also OO History: Simula and Smalltalk - https://www.cs.cmu.edu/~charlie/courses/15-214/2014-fall/sli...

Post reply on HN