Hacker News Reader

Comment by goalieca | Hacker News Reader

people write better c than c++ because they are less tempted to over-architect. We've all come across terrible meta-templated c++ code with abuse of OOP all in the name of "information hiding". The main problem against c is the puny standard library. It would be nice to have a few more built-ins.

I think c++ without inheritance would be a very nice language.

View on HN

C has so many design flaws, from the lack of reasonable iterators to null pointers to the preprocessor to bizarre type syntax to switch fall through to terrible error handling to no generics, etc. The attempts to patch the more broken parts of its design (e.g. ergonomics favoring signed induction variables in for loops) have resulted in more problems (e.g. signed overflow being undefined behavior). As a language from 1978, it was good in its day, but it's not worth saving anymore. It should become a respected piece of history.

I am always startled by people who hate inheritance "lock stock and barrel". I have long-running memories of being utterly appalled by multiple inheritance - all the way back to having to learn how to answer those damn "how many pure virtual base classes can dance on the head of a pin?" type questions in my 3rd-year C++/soft-eng class.

But single inheritance, used judiciously, has really led to some vastly better designs in my experience and doing away with inheritance would generally mean those designs would just be redone with a clumsy "let's fake up inheritance" interface.

I think you can write bad code in any language. Bad C++ is especially egregious, as it's possible to make the bad code practically incomprehensible even at a surface level. However, I suspect that carving feature after feature away from C++ leaves a language that is now just as good for writing toy programs ("hey, look how elegant the language is now that pesky inheritance/template/exception/<insert hated feature of choice> is gone"), but will now allow you write verbose and shitty (but shallowly more understandable) code in place of the C++.

I do find the sheer size of C++ objectionable (the usual arguments about how nearly all C++ programmers seem to program in subset "house styles" of the language). I am generally very suspicious of efforts to replace C++ that come from people who don't seem to understand it at all, however. Generally I like Rust in this regard as the Rust approach seems to display a mature understanding of what was actually good about C++ (constrast: Go).

What do you want to use inheritance for? In my experience, it is usually better to use composition and sum types.

Inheritance is usually really great when you want to extend the type outside the context it was created in. GUI is a very clear example of that where composition may work but is greatly tedious (reimplementing the whole interface, exposing it, and rewiring), and sum types are right off the bat inapplicable.

C was already quite poor in 1993 when I got to compare it with Turbo Pascal 6.0 for MS-DOS, my main tool at the time.

With all these years the amount of UB, memory corruption issues and security exploits only got bigger.

We need a major IoT meltdown to get rid of it, unfortunately it won't happen until the industry lets UNIX clones go.

> unfortunately it won't happen until the industry lets UNIX clones go

Redox is a Unix-like system.

UNIX like is not the same as being UNIX.

UNIX is married with C by design, just how browsers are with JavaScript.

Actually you are right in one thing, if Redox offers POSIX support then it needs to sandbox them.

In the context you said "Unix clones", it sounded pretty obvious you were including Linux in there. Linux is a "Unix-like" rather than an Unix.

I was including Linux there, as it follows a standard UNIX architecture.

There is a big difference in having POSIX support and being a UNIX.

Windows, IBM i, IBM z/OS, Unysis MCA ClearPath, Green Hills INTEGRITY OS, Genode and many other OSes have POSIX support, yet their architectures have nothing to do with UNIX.

> We need a major IoT meltdown to get rid of it, unfortunately it won't happen until the industry lets UNIX clones go.

Rust isn't going to stop IoT makers from leaving ports open and default passwords set.

No, but it may protect (to some degree) those that do use good authentication practices from also being exploited from exploitable libraries.

Bad defaults is a problem with IoT devices, but far from the only problem.

No, but there is a whole class of errors related to UB, memory corruption and data conversions that just by avoiding C will never happen.

You don't even need Rust, Algol 68 would be enough.

But absolutely no one forces you to use inheritance.

Not using a feature X yourself means you might still need to deal with code written by somebody who uses the feature.

In lesser languages this tends to translate to "you need to deal with code using bizarre pre-processor coding and/or external code generators". glib*-stuff is a neat example for the former (although a lot of it's code and most of the architecture is overall bizarre, not just the pre-processor parts), things like Qt and some libraries parsing stuff using generated parsers / lexers are typical examples of the latter.

Reply on news.ycombinator.com