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

111–120 of 177 posts

Re: The Problem with C (2020)

#111

Post by sirwhinesalot »

seiferteric wrote: post #106
sirwhinesalot wrote: post #103

Earlier quoted context omitted.

Unfortunately this doesn't work for managed or interpreted languages with their own runtimes, where you want the types to run on their VM. An example would be JIT-compiled C# data structures, no way to implement those on top of a shared library since specific instantiations have to be produced and compiled at runtime. Such a data structure and algorithm library as a springboard would be still be incredibly useful, bu…

I wonder though, I know a lot of tricks for performance are used, such as in python API, judicious use of inlining, putting some common functions in headers files etc. Depending on how far down the rabbit hole you want to go, could this library not also include code generation functionality for JIT's? Or even at compile time, is there anything stopping a library from generating code that could be included in your VM…

At that point you're effectively creating your own VM, and then you may ask why doesn't someone simply use the JVM or the CLR. Once you reach that degree of complexity, there are simply too many tradeoffs.

I certainly won't stop you from trying to develop such a thing, could be a nice way to get languages bootstrapped faster. Just keep in mind JIT compilation is forbidden in iOS, so e.g. C# needs an entirely different compilation strategy for that platform.

Re: The Problem with C (2020)

#112

Post by sylware »

I stick to lean and simple C89 with benign bits of c99/c11. With nice tables of functions and clever recursive pre-processor naming, you can scale that easily to large modular applications and keep everything very clean. The absolute and unquestionable truth: a c++ compiler is abysmally more complex and hard to write than a C (89 with benign bits of c99/c11) compiler, and this is mecanically true due to the syntax complexity difference. There are many shmol and cute alternatives C compilers out there (and there are working better each day which goes by, and some are doing more than enough optimizations), and I would like to use them, that which is not possible with c++, due to its complexity hence shuting the door hard on any reasonable efforts of writing a "working" alternative. That said, personnaly, I have high hopes (maybe too high) if RISC-V is successful: I see everything assembly (not even C anymore) with high level script languages of the like of python/javascript/lua/etc. I am writting more and more assembly these days (mostly x86_64 though, desktop RISC-V are only starting to ramp up in performance), and the main pitfall seems to be the abuse of the macro language of the assembler, which could be averted if explicitely aware of this bias.

Re: The Problem with C (2020)

#113

Post by throwaway17_17 »

sylware wrote: post #112

I stick to lean and simple C89 with benign bits of c99/c11. With nice tables of functions and clever recursive pre-processor naming, you can scale that easily to large modular applications and keep everything very clean. The absolute and unquestionable truth: a c++ compiler is abysmally more complex and hard to write than a C (89 with benign bits of c99/c11) compiler, and this is mecanically true due to the syntax co…

Can you expand a little on the pitfalls you see concerning the 'abuse of the macro language'? I have an undeniable pipe dream that my hobby language can be essentially a well-defined and explicit thin cover for assembly language primitives. I think your thoughts about the downsides of 'higher-level' idioms/practices when using assemblers would be very on point for me to consider.

Re: The Problem with C (2020)

#114

Post by loup-vaillant »

bitwize wrote: post #108
loup-vaillant wrote: post #65

Earlier quoted context omitted.

References are kind of redundant when you already have pointers, and they make the performance characteristic of the code you read less clear (am I passing down a pointer, or am I copying the whole thing?). C structs can already do most of what C++ classes can do. Including inheritance and virtual methods, when you really really need them. As for encapsulation, pointer to implementation provide a more stable, harder…

> References are kind of redundant when you already have pointers, No. They're not. References must point to valid objects (i.e., cannot be nullptr and cannot be random addresses in memory), and you cannot do arithmetic on them. They are much safer to use than pointers, so actually, references make pointers redundant. > C structs can already do most of what C++ classes can do. Including inheritance and virtual method…

Yes, references have nice constraints that makes them harder to misuse than pointers. The gap however is smaller than it first look: dangling references are still a thing, and one does not simply make pointer arithmetic by accident. Don't get me wrong, I do like references enough that my C++ code is littered with them. I'm just saying they don't add that much to the table. They're nice, but I never really miss them when I write C.

Yes, writing your own virtual table in C is mighty cumbersome. On the other hand, I need those about once every 3 years, even in C++.

Re: The Problem with C (2020)

#115

Post by loup-vaillant »

galangalalgol wrote: post #89
loup-vaillant wrote: post #62

Earlier quoted context omitted.

If C++ had just treated C from the start, it would have been much cleaner, and nobody would have used it. Humans are stupid, short-sighted creatures, and programmers are no exception. The only way to get C programmers to use C++ was to make C-with-classes a drop-in replacement for C. Replace "cc" by "CC" in your build system, and you magically get new features, without breaking old code (at least not too much). Sure…

Add to that c++ is infectious, both in a code base, because once you add c++ you can't go back, and in dependency chains. A c++ library that depends on c libraries often only exports c++ interfaces so the things that would build on them must be c++. Where julia might call into a rust library with a fortran and zig dependency.

Where I'm tempted to compare C++ and copyleft…

Re: The Problem with C (2020)

#116

Post by oconnor663 »

pornel wrote: post #104
_the_inflator wrote: post #40

Earlier quoted context omitted.

I agree with you. However, I think the real value of the language is that, despite flaws, it provides a reasonably consistent platform in this "glue" context. It better to have one imperfect language, than a dozen perfect.

I think it would be beneficial to create a better interoperable ABI description (one, not a dozen). Not in a form of a language header, but a data file that can be easily consumed by tools of any non-C language. 1. C headers are exceptionally annoying to correctly parse and interpret. You basically have to have a full C compiler, which is a PITA for a non-C tool. It's not just complexity of the C syntax, but dependen…

Could WASI grow into this role?

Re: The Problem with C (2020)

#117

Post by hobomatic »

slaymaker1907 wrote: post #7

I write a lot of code in a C++ codebase and I'd say C++ is horrific. Not just because of its roots in C, no I think it is actually a worse language than C. Notable detriments in the language include references, classes, a lot of template stuff (some of it is ok, but it makes separate compilation almost impossible).

The roots in c being a problem to me doesn't indicate the blame for them is necessarily inherited from c. The confusion about 'auto' elsewhere here is demonstrative.

C++ is superficially similar to c in a lot of ways that don't actually translate well across the boundary between the two.

So some c things get misattributed to c++ and many c++ things get misattributed to c and disentangling these is nearly impossible if you aren't intimately familiar with both of them.

Being intimately familiar with either is a detriment to maintaining unmuddled working knowledge of the other.

Re: The Problem with C (2020)

#118

Post by loup-vaillant »

pjmlp wrote: post #93
loup-vaillant wrote: post #88

Earlier quoted context omitted.

If only. For all the "moar strong types" goodness C++ claimed, in practice there was very little. The same could have been achieved with stricter warnings, that C compilers now have . With TypeScript at least you have the option to go from full dynamic typing auto cast madness to meaningful compile time checks. That being said, if I had to write a serious web app today (that is, something that absolutely requires cli…

The compilers might have them, yet the large majority doesn't care they exist. Unless devops plugs them into the CI/CD pipeline with -Wall -Werror, most people will keep coding as they ever did. Why do you think Google is sponsoring KSPP and pushing C cleanups of bad code, despite all review processes that the kernel has?

Goodness, I'm running a zero-warning policy with -Wall -Wextra all the time. They have removed tons of bugs in my code before I even touch the first sanitizer, they're my first line of defence.

Re: The Problem with C (2020)

#119

Post by BirAdam »

gk1256 wrote: post #107

C is a terrible language. You have to reinvent everything on it. The simplicity is just a lie. C++ on the otherhand is way simple to use and really straightforward. I like Zig too.

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 that I will give to C is that the entirety of the language can be held in the mind of the programmer using it, with zero need for reference. This is impossible in most other languages.

Re: The Problem with C (2020)

#120

Post by loup-vaillant »

galangalalgol wrote: post #91
loup-vaillant wrote: post #88

Earlier quoted context omitted.

If only. For all the "moar strong types" goodness C++ claimed, in practice there was very little. The same could have been achieved with stricter warnings, that C compilers now have . With TypeScript at least you have the option to go from full dynamic typing auto cast madness to meaningful compile time checks. That being said, if I had to write a serious web app today (that is, something that absolutely requires cli…

Will wasm ever get direct access to the dom so that isn't needed? I keep wanting to jump into wasm, but I don't really want to learn any more javascript than I already know, which is just enough to play codespells and screeps. And I certainly don't want to learn a framework which seems to follow the madden nfl release schedule.

Ideally I wouldn't learn a single thing about JavaScript, and go straight to WebAssembly. Possibly chose a language that already has a compiler for both so I don't even have to learn the standard.

And no framework either, I'd do my own things with as few dependencies as I can possibly manage. No point tying myself to some protean monstrosity that breaks code every 6 months and is abandoned 5 years later. (OK, not a web dev, so I don't know about that last one. It's just what I glean from the web's reputation.)

Post reply on HN