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

131–140 of 177 posts

Re: The Problem with C (2020)

#131

Post by gk1256 »

BirAdam wrote: post #119
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 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.

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

In other languages, which parts you are unable to held in your mind?

The only instance where I need references in C++ is STD library features. But if we measure, it take less time than if we were to reinvent it on C.

Re: The Problem with C (2020)

#132

Post by sylware »

throwaway17_17 wrote: post #113
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.

I use FASM, and FASM has probably one of the most powerfull macro languages out there. FASM actually implements _only_ this macro language and _not_ the x86_64 assembler itself. The x86_64 assembler is actually written using this macro language, like the support of ELF, COFF, etc, binary formats. Some ppl have implemented an ARM assembler with this macro language (and I am thinkink about RISC-V). Its author likes to refer to this macro language as an "assembler writting toolkit" which looks to me more than fair. As a practical example, this macro language has full support of modular and hierarchical namespaces. I found myself lost into dividing my code paths in basillions of namespaces and that way too much. Excessively, I also started to write my "own" language using this macro language: I was not writting assembly anymore, only macros and some with hardly any assembly in them. This is actually a bias that happens with any computer language: the tendency of devs to "maximize" the usage of some syntax, which kind of increase exponentially with this very syntax complexity, to reach a point where a Rube Goldberg machine looks efficient and sane (yes, this is severe irony).

Re: The Problem with C (2020)

#133

Post by vkazanov »

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.

Well, one of the problems of C is that it's not as simple as it wants you to think it is. :-)

Re: The Problem with C (2020)

#134

Post by gk1256 »

google234123 wrote: post #29
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).

Your examples for why C++ is bad are references, classes, and templates? So I guess you like Fortran77?

What's bad for him is good for me. Those C++ features helped me a lot. Actually, in terms of business value they saved me a lot of time.

Re: The Problem with C (2020)

#135

Post by gk1256 »

notacoward wrote: post #81

As far as I can tell, the definition of C++ is mostly driven by compiler folks (and wannabes), motivated to add features for their own career benefit and generally doing so in the way that's most convenient for them (e.g. std::move as a pseudo-function instead of as real syntax that the already-insane parser would have to handle). Since only the in-group's interests are considered, the much more numerous regular C++…

I don't think they are wannabes. Getting a feature accepted to C++ is hard. That's why most people push their features into Boost (well, MVP style). The C++ committee has respected people with years of experience.

Re: The Problem with C (2020)

#136

Post by marwis »

pjmlp wrote: post #122
marwis wrote: post #101

Earlier quoted context omitted.

Where did you see in-proc D-Bus? It would be wildly inefficient compared to COM/gobject anyway.

COM nowadays runs mostly out of process unless you like crashing the whole application, hence the reference to nano-COM for in-proc APIs that are basically OO ABI. That is why any modern Windows has plenty of COM Surrougate processes running at any given time. As for D-BUS, I stand corrected, I though it had such optimization in place, just as other mechanisms offer.

There's a ton of new in-proc COM usage through WinRT.

Re: The Problem with C (2020)

#137

Post by bicolao »

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

Earlier quoted context omitted.

> 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 w…

> one does not simply make pointer arithmetic by accident

I'm not sure about that. This has bitten me a few times (in more complicated form)

    "hello " + 12

Re: The Problem with C (2020)

#138

Post by badsectoracula »

pjmlp wrote: post #79
badsectoracula wrote: post #77

Earlier quoted context omitted.

D-Bus is for IPC not an ABI. If there was something similar it'd be gobject, but i don't think any language other than Vala speaks it "natively" (and considering how much Gtk cares about backwards binary compatibility, i don't think it'd be a good idea to target it anyway).

It can run in-proc and fits the scenarios being given on previous comment. I remeber Bonobo, DCOP and KPart days, so I know pretty well what D-Bus is capable of. In micro-kernels the IPC infrastructure is the userspace ABI, as it is the only way to call into OS services, beyond the little glue library to make it possible to do so.

DBus is an IPC protocol, it is the first thing the specification[0] mentions, there isn't any way where it would make sense for it to be used in-process nor the spec provides for such functionality. Some higher level library could potentially provide an API for exposing and consuming (object) interfaces that can be accessed either in-process or out-of-process, though only the latter would really be using DBus and the former would bypass it (and both would be only really usable only by users of that library, not anything using DBus).

DCOP is/was also an IPC protocol, though much simpler than DBus as it was essentially about passing arbitrary data between processes with some IDs attached (the higher level API did pretend that they were objects and method calls but the -still public- lower level API worked in terms of string identifiers and data streams), which makes it unsuitable for a cross-language ABI. KPart however (which is still being developed and part of KDE) is sort of a relative idea to COM in that it is really something similar (in concept) to ActiveX, so it could handle some uses (though it lacks the genericness of COM), except it being C++ based also makes it impractical for a cross-language ABI - which is the entire reason COM was brought up (and why IPC approaches like DBus and DCOP aren't relevant to what was discussed).

[0] https://dbus.freedesktop.org/doc/dbus-specification.html

Re: The Problem with C (2020)

#139

Post by pjmlp »

marwis wrote: post #136
pjmlp wrote: post #122

Earlier quoted context omitted.

COM nowadays runs mostly out of process unless you like crashing the whole application, hence the reference to nano-COM for in-proc APIs that are basically OO ABI. That is why any modern Windows has plenty of COM Surrougate processes running at any given time. As for D-BUS, I stand corrected, I though it had such optimization in place, just as other mechanisms offer.

There's a ton of new in-proc COM usage through WinRT.

You mean the market failure that no one wants to use any more, even those of us that were early adopters?

I am betting in 2 to 3 years we will have yet another reboot from WinUI and WinAppSDK.

How things are, I wouldn't be surprised with Blazor with WebWidget2 as the new cool desktop UI.

Re: The Problem with C (2020)

#140

Post by pjmlp »

badsectoracula wrote: post #138
pjmlp wrote: post #79

Earlier quoted context omitted.

It can run in-proc and fits the scenarios being given on previous comment. I remeber Bonobo, DCOP and KPart days, so I know pretty well what D-Bus is capable of. In micro-kernels the IPC infrastructure is the userspace ABI, as it is the only way to call into OS services, beyond the little glue library to make it possible to do so.

DBus is an IPC protocol, it is the first thing the specification[0] mentions, there isn't any way where it would make sense for it to be used in-process nor the spec provides for such functionality. Some higher level library could potentially provide an API for exposing and consuming (object) interfaces that can be accessed either in-process or out-of-process, though only the latter would really be using DBus and the…

2h30m before of your comment, I already acknowledged my mistake, you could have saved yourself some typing.
Post reply on HN