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

The Problem with C (2020)

cor3ntin.github.io

Post reply on HN
Print view View original

141–150 of 177 posts

Re: The Problem with C (2020)

#141

Post by notacoward »

gk1256 wrote: post #131
BirAdam wrote: post #119

Earlier quoted context omitted.

By “reinvent everything,” I believe you mean to say that you have to make your own linked-lists to have adjustable strings, and you have to create structs with function pointers to have objects… The simplicity is either in the language and tooling around the language, or it is in the code you read and write in that language. C chose to be simple in the language itself and not in the code. The single greatest praise t…

> By “reinvent everything,” I believe you mean to say that you have to make your own linked-lists to have adjustable strings, and you have to create structs with function pointers to have objects… Spot on. > C chose to be simple in the language itself and not in the code. But it market itself being simple so people even newcomers think that C is simple in every regard. Only few people rarely acknowledge this fact. >…

What I think a lot of detractors miss is that this reinvention need not be done by every single C programmer. In any significantly large and/or old C codebase, there will be local data structures, functions, macros, and idioms to solve the kinds of problems specific to that domain in a way suitable for that domain. For example, in my own domain of servers for distributed filesystems and similar things, the codebases I worked on had sophisticated ways of dealing with memory lifetimes across "discontinuous" control flows because of queuing, RPC, and so on. Those ways worked. I saw similar things in kernels, databases, etc. When I started working on a C++ codebase for yet another distributed storage system, every programmer seemed to be fighting to make C++/STL do the right thing in a memory-lifetime milieu that the language and library designers had apparently never contemplated. Worse, each programmer seemed to be solving those problems in different ways, leading to a proliferation of approaches which sometimes weren't even compatible with each other. That code had far more copies and memory leaks than the C code I'd worked on previously, despite the previous code having been worked on mostly by programmers with a significantly lower skill/experience level. Ironically, there was more wheel-reinvention in the C++ code than in C.

I'm not saying C is the right choice for every project. C++ isn't either. C++ might be a pretty good language for doing the sorts of mid-level things that the people on the C++ language committee like to do (surprise surprise) but there are many broad domains at both higher and lower semantic levels for which it can be a poor fit. For a lot of low-level stuff a language that lets people define their own domain-specific abstractions will beat an "every bell and whistle and all wrong for what we're doing" language every time.

Re: The Problem with C (2020)

#142

Post by alcover »

unwind wrote: post #14

As a long-time C aficionado, part-time wanna-be language-lawyer, and just general supporter and fan, the fact that there is no C conference was interesting. I guess I knew that, because if there was such a conference I would have known, at least I would like to think that. On the other hand I've never been to a programming language conference (probably self-fulfilling by being primarily a C programmer at heart) so it…

> there is no C conference

That's shocking to me. But this goes along the fact that C on the web is scarce..

> Code sight-seeing

I would love to attend such C workshops.

Re: The Problem with C (2020)

#143

Post by jvanderbot »

kstenerud wrote: post #4

C is the glue interface that connects all the different languages together. I wouldn't want to see anything new added to the language that complicates this lingua franca. I liked C in the 80s, 90s and 2000s. It was a neat and simple language, but that changed as compilers got more aggressive with their optimizations and exposed just how complicated and unintuitive the spec actually is (and the impossibility of avoidi…

I'm hopeful for Rust. I'm a C++ developer. I use Python all the time as well when I want something to just work, and fast.

But by god I love C. I use C for most of my library interfaces so that I can easily make C++, Python, etc versions in more pleasing versions for those languages. It's much, much easier to work from C and to another language than it is to cross language boundaries laterally.

That probably won't change, so I'll always use C at least a little bit when building tools.

In that respect, C is still winning. It's upstream of everything, easy to compile, and has libraries for everything.

Re: The Problem with C (2020)

#144

Post by loup-vaillant »

pjmlp wrote: post #126
flohofwoe wrote: post #97

Earlier quoted context omitted.

The comparison is flawed, because Javascript is a subset of Typescript, but C is not a subset of C++. A better analogy would be that C++ is to C what Dart is to Javascript.

It was when C++ came to be, 40 years ago. Don't mix stuff with how things are today.

Also, even now, the intersection between the two languages is large enough to be useful. I believe the entire Lua VM has been written in that subset, and so has my cryptographic library.

Though you'd have to be careful, it's still possible today to write useful C code that also compiles as C++.

Re: The Problem with C (2020)

#145

Post by zelphirkalt »

nnoitra wrote: post #23

I dislike C++ for the same reason I dislike all languages that try to be everything. You can use the language for years and there are still parts of it that you don't understand properly. C on the other hand has such a minimal and clear syntax that you can learn it pretty fast and feel confident about the language.

And then there are languages, which are fractions of the amount of syntax you have in C, much more consistent throughout, which can actually claim to minimalistic.

Re: The Problem with C (2020)

#146

Post by victorcharlie »

scoutt wrote: post #47

> > There Are No C Conferences. Maybe that’s why the C++ committee is now over 10 times the size of the C committee. I have this controversial thought: C people understood one thing before everyone else (including the creators of C++, Rust, and any other language), and is this: “Perfection is Achieved Not When There Is Nothing More to Add, But When There Is Nothing Left to Take Away” -- Antoine de Saint-Exupery. Supe…

Hey, do you mind pointing me to some learning material regarding firmware? I have a totally unrelated background (I'm a chemist) although I picked up some coding during my PhD (the usual "science stack": Python/shell scripts). After that I learnt C and fell in love with its simplicity and power and firmware/drivers always seemed like magic to me so I'd like to understand them a little bit better.

Thanks and have a great day!

Re: The Problem with C (2020)

#147

Post by bb88 »

pjmlp wrote: post #84
bb88 wrote: post #61

Earlier quoted context omitted.

> As a long-time C aficionado, part-time wanna-be language-lawyer, and just general supporter and fan, the fact that there is no C conference was interesting. There doesn't need to be a conference for everything under the sun. I don't see a screwdriver conference popping up around me anytime soon.

You might find the latest screwdriver tech at one of these ones, https://www.conexpoconagg.com/

Still not a screwdriver conference.

Re: The Problem with C (2020)

#148

Post by jstimpfle »

sirwhinesalot wrote: post #31
kstenerud wrote: post #4

C is the glue interface that connects all the different languages together. I wouldn't want to see anything new added to the language that complicates this lingua franca. I liked C in the 80s, 90s and 2000s. It was a neat and simple language, but that changed as compilers got more aggressive with their optimizations and exposed just how complicated and unintuitive the spec actually is (and the impossibility of avoidi…

> C is the glue interface that connects all the different languages together. I wouldn't want to see anything new added to the language that complicates this lingua franca. Indeed, this is one of the two things where C is still king, the other being running on weird hardware with specialized compilers. That said, C is not a great glue language: - Zero terminated strings are only used in C so every other language need…

> Zero terminated strings are only used in C so every other language needs to do a copy to pass a string to C, even C++ (for string_view at least).

This is one of the most frequent complaints and I find it ridiculous. C has string literals that encode zero-terminated strings, but you don't have to rely on these zero terminators. There are a few awquard "string functions" in libc, most of which you should just ignore. Besides maybe the printf() family (which you probably wouldn't want to use for interoperability there isn't anything that requires zero-terminated strings.

This language gives you memory to work with, and it's up to you how you want to achieve your goal.

> A lack of fat pointers means that buffers need to pass their pointer and length separately, which is awkward, or use a custom struct which other languages will know nothing about.

It could be considered a security problem that sizes have to be passed separately, but what I consider awkward is actually the slices approach: In general the count field in a "slice" is redundant data - think about parallel arrays, where with slices you need to synchronize the count information across all slices. Passing separate length is the correct approach from a normalization standpoint.

> It has no standardized error handling mechanism to help with writing automatic wrappers on the other language endpoints.

Similar to the point about slices, not including any notion of "errors" is the correct way of doing it. In general you don't want errors in a system, only data that you handle in an appropriate way. Also, returning what people usually consider errors is often a bad idea, as such error information should better be stored in a persistent handle or context struct.

> It has no modules or namespacing.

Not a problem, since there are names that you can already use for disambiguation. Namespaces only add more ways to identify the same object, which leads to ambiguity and/or hard to read and hard to grep code. (Namespaces encourage the use of not-fully-qualified identifiers - actually this is the only thing they really add, and apart from some metaprogramming tricks you can play I don't think it's a great addition).

Re: The Problem with C (2020)

#149

Post by Koshkin »

pjmlp wrote: post #83
kbob wrote: post #43

Earlier quoted context omitted.

Computer science is less than a century old. There's no reason to think we know enough to design perfect languages yet. But with an additional 30 years of hindsight, we can make somewhat better languages now, and we should.

We already had 20 years of hinsight that C's authors decided to ignore, had UNIX not been free beer for all practical purposes, history would have taken another path regarding C's adoption.

Yeah but the thought of living in a world where they use Ada++, AdaVM, and AdaScript makes me shudder...

Re: The Problem with C (2020)

#150

Post by Koshkin »

victorcharlie wrote: post #146
scoutt wrote: post #47

> > There Are No C Conferences. Maybe that’s why the C++ committee is now over 10 times the size of the C committee. I have this controversial thought: C people understood one thing before everyone else (including the creators of C++, Rust, and any other language), and is this: “Perfection is Achieved Not When There Is Nothing More to Add, But When There Is Nothing Left to Take Away” -- Antoine de Saint-Exupery. Supe…

Hey, do you mind pointing me to some learning material regarding firmware? I have a totally unrelated background (I'm a chemist) although I picked up some coding during my PhD (the usual "science stack": Python/shell scripts). After that I learnt C and fell in love with its simplicity and power and firmware/drivers always seemed like magic to me so I'd like to understand them a little bit better. Thanks and have a gr…

Not the GP, but to me the only difference between firmware and software is that firmware is often (but not always) "burned" right into a piece of hardware, which is usually a chip that has a microcontroller of some sort inside it. The PC BIOS is also called firmware sometimes - because it is "burned" into the PC itself.

A device driver, on the other hand, can be implemented in software or firmware, or, usually these days, as a combination of both. Drivers indeed are magic - since they usually designed to interact with, and to control, physical systems, they must work in real time, and writing a driver requires understanding the system's behavior to a minute detail.

Post reply on HN