Hacker News Reader

Comment by EdSchouten | Hacker News Reader

I'm puzzled with what the market for these kinds of languages are.

C is sort of a dead end. There is very little innovation there. And that's fine; the users of the language seem to want it that way. They just want to write software the same way they've been doing for the last 20 years. Why would such a conservative user base want to switch to a different language like C3?

Linus once said this about Subversion: "Subversion has been the most pointless project ever started... Subversion used to say, 'CVS done right.' With that slogan there is nowhere you can go. There is no way to do CVS right." Could C3 be the Subversion of programming languages?

View on HN

> C is sort of a dead end. There is very little innovation there.

C is a small language. There are benefits to that. But it also has a handful of historical oddities. Innovation here means to keep C small while also getting rid of those quirks.

C++ is enormous. Rust is headed in the direction of similar enormity.

C is a small language which fails even at the most basic abstractions (you can’t really create a safe and ergonomic “zero-overhead” generic vector type). Due to the inherent complexity of low-level programming, expressive languages in this niche (C++, Rust) has to be reasonably complex just for this reason alone.

Zig is an interesting “exception” due to its strong compile-time metaprogramming capabilites, resulting in a small, but quite expressive language. But all 3 has a future. C is here to stay, but I really wouldn’t start any new project in it.

C++ is a monsterous cruel joke compared C, but if you’re just looking for some syntactic niceties, nothing stops you from writing C in C++.

C++ -ffreestanding is remarkably usable without the standard library, provided compiler intrinsics are used to fill in some gaps. I'm slowly coming around to using that instead of C for language runtimes.

> C++ is enormous. Rust is headed in the direction of similar enormity

I don't think this is a fair characterization of rust really. For the most part the things on the horizon still for rust seek to reduce complexity by filing down sharp edges that force you to write complicated code. Stuff like GATs seem complicated until you repeatedly slam your head into the lack of them trying to do things that "seem" natural.

C++ on the other hand (after 2011) just never saw an idiom it didn't like enough to throw on the pile and there's little coherence to the way the language has grown in the last decade.

> there's little coherence to the way the language has grown in the last decade.

IMHO it's been incoherent from the earliest times.

The lame exceptions without 'finally', and no consistency in exception types. Then the desperate attempts to make all resources into objects, except that practically no OS calls bothered with this.

The overloading of the shift operators in the standard library. Indeed, operator overloading itself is just a recipe for abuse. You read 'a=b+c' and you literally have no clue what that means.

Multiple inheritance with the brittle semantics.

The awful STL, with its multi-kB error messages (the allocator of the trait of the string of the tree of map of king Caractacus doesn't match ...)

There's no wonder the 'obfuscated C competition' never happened with C++ given the fact it's unreadable, right out of the box.

> You read 'a=b+c' and you literally have no clue what that means.

I never understood that argument. Even in C operators do different things depending on what types you pass it. Two very simple examples:

1. Adding a number to a char* vs adding a number to an int* (or a pointer to any other larger type). The second automatically creates an invisible multiplication. This was confusing for me when I first learned C after already knowing the concept of a memory address (which is just a number). It was an unexpected abstraction for me.

2. This regularly bites novices to programming: Dividing two numbers. If at least one of them is floating point, you get the 'correct' result, overwise rounded towards zero. To 'fix' it, you have to explicitly cast at least one of them to float or double. Then the language imlpicitly casts the other for you. std::pow went the other way, which is less confusing. It always promotes integers to floating point numbers and returns a floating point result.

As soon as your language has types and operators, you get operators that do different things based on the types of the values they are applied to. The only new thing that operator overloading adds is that it makes libraries first class citizens.

fwiw I'm with you even though I've gotten very frustrated with c++'s bloat in other ways. The shift operators were probably a poor choice for iostreams but I don't think the idea was inherently unsound, iostreams is just a very bad library in a bunch of ways.

The thing is that in the end, once you have "methods", there are a bunch of reasons you sometimes want to have "infix methods" and for various reasons languages have been reticent to add them as a general concept, so all you get is the operators you have. And it's not like in C++ types are hidden from you most of the time. I guess now that auto is more normalized it happens more but this argument goes back way before auto getting its modern meaning.

But fundamentally, I would rather concat strings with + and I'd rather use normal math operators for vector ops like matrixes or combinatorial concatenation. Every time I see code in a language that doesn't allow you to do this, but people write code doing those things, I cringe at the result.

At a more fundamental level, the fact that struct+struct has no meaning to begin with in C makes it fair game to add it as a concept.

And it's worth noting that addition of pointers is only really a trivial op in non-segmented architectures without any kind of pointer tagging anyways. The window on that assumption opened with 32bit archs and will probably close soon as CPU security primitives evolve.

> And it's worth noting that addition of pointers is only really a trivial op in non-segmented architectures without any kind of pointer tagging anyways. The window on that assumption opened with 32bit archs and will probably close soon as CPU security primitives evolve.

It was trivial on char* in the 16 bit segmented days (artihmetic was only applied to the offset part of the pointer, if you had a far pointer at all), unless you absolutely needed the huge memory model, which was discouraged anyway because of its slowness. What it did mean though, was that code and data lived in something akin to separate address spaces. But portable modern C code usually doesn't use performance tricks like self-modifying code anymore anyway, because even if it wasn't problematic it wouldn't really be needed anymore.

The difference is that you know (or can know, or predict) the outcome. In C++ a=b+c could be a simple addition or an operation that takes an hour, allocates 1GB of RAM, opens a socket and requests a JSON document from a server in China. You can't know wihtout looking at the code.

You don't know what the function called "add" does either.

There's no reason for the name "+" to be anymore special than "add" - especially in any language supporting unicode identifiers which allows even more crazy names.

But with "add" I'm explicitly calling a function.

> There's no reason for the name "+" to be anymore special than "add"

This is debatable. I want "+" to do just an addition.

Also a function "add", depending on the context, can mean different things.

See, framing it as a personal preference makes much more sense. Of course disallowing nontrivial work in operators will also mean you can't concatenate strings in them, so you will have few languages to choose from.

Sorry. I don't know if you are saying that you won't be able to concatenate strings without operators, or if you choose a language just because it allows you to use a "a = b + c" form with strings.

For the first case, of course you can create something like:

    str1.append(str2);

For the second... I don't know what to say.

> framing it as a personal preference

But follow my logic for a moment: if "str3 = str1 + str2" concatenates a string, what "str3 = str1 - str2" should do?

(Yes I know there is no minus operator for std::string)

And "str3 = str1 * str2"?

And "str3 = str1 % str2"?

I never said, that it is impossible to work without operator overloading (actually the opposite). Just that it is a very common feature in most programming languages, and I don't understand why an experienced developer would be confused by it. Even in maths expressions (where the operators come from), you have this behavior. If you multiply two matrices, it does something completely different. The result could be huge and thus in computing world require huge memory allocation. Also you can multiply matrices, but you can't divide them. The primary school level math you seem to be limiting the world to is not practical.

You can predict the outcome very well. It is a call to an operator, which can be trivial for simple types. But of course if you concatenate two 500MB strings using +, you will have a 1GB allocation. I don't see how that is a problem or even a surprise. Of course you could do something in that operator that nobody would expect to happen inside it. But the same is true if you give a function a bad name. For all intents and purposes, an operator is just a function with a particularly short name and (default) style of how it is called.

> You can predict the outcome very well

Not always. BTW, I don't know if you noticed it, but I was exagerating to make a point.

> Of course you could do something in that operator that nobody would expect to happen inside it

To me, this is the problem. For example, I do embedded. I have to know with a certain precision what is going on in my program.

It's a very different thing to call a bad-named or badly-done function. It's an unlucky case... I guess?...

But if I use an operator, there might be hidden code there I have to see.

Yes, I know you can use "=" to copy a struct. But also "a = b + c" might be doing something slow, like re-allocating internal pointers and making copies, allocating new objects, etc. I have to read the code to see what it will do. Believe me, I have done it with inherited embedded C++ projects.

I don't do embedded (anymore), so please consider that your use-case and concern is very specific.

But even in C++ you can't redefine what + means for types, where it already has a builtin meaning. The only thing you can do is define what it does for custom types. That means when you see the + operator applied to some class or struct type, you should already be aware that this is nothing built-in and equivalent to a function call. If you are not, you are just not fluent in your tooling. That is completely different problem. It is something learnable, not a fundamental problem of the tooling.

I was jokingly thinking C++ needs Douglas Crockford to write "C++: The Good Parts" but of course a quick search reveals there already is one

https://www.amazon.com/C-Good-Parts-Gregory-Satir/dp/1449319...

> I'm puzzled with what the market for these kinds of languages are.

There's a significant number of C programmers who want something slightly more modern and convenient but don't want to write C++ due to a number of reasons.

I think Zig, D are examples of this niche but syntax wise they don't completely look like C.

> I think Zig, D are examples of this niche but syntax wise they don't completely look like C.

This is technically true, but someone that likes writing C while wanting a few extra features would mostly be able to write the same C code they always have if they stick to D's betterC. (I'm not familiar enough with Zig to comment on that.)

Edit: Should also add that D now compiles C code, so a C programmer could continue to write C as they want, write a few D functions where those features help, and compile them without writing any binding code.

> I think Zig, D are examples of this niche but syntax wise they don't completely look like C.

That is because C's type declaration format is provably, as in actually provably, terrible.

There is a reason the majority of modern languages have switched away from how C declares types.

Honestly it'd be nice if the C committee could find a way to tack on a new variable declaration syntax to C, so everyone didn't have to keep looking up, or using tools, to declare non-trivial function pointers.

Please, just no.

The C committee should do basically nothing. If someone, somewhere, finds an actual bug in the spec, then fine -- fix that. But don't go adding new features.

If you want something new, then make a new language.

Leave C alone.

> If you want something new, then make a new language.

Adding an optional new declaration syntax isn't a new feature, it is a change to the parser.

C's declaration syntax is awful. In fact I'd go so far as to claim that one reason function pointers aren't heavily used in C as compared to modern C++, C#, JavaScript, etc, is purely because the syntax around them is so awful.

(They obviously are used, but no one likes using them)

As someone who actually uses C I think the C standards committee needs to be taken on a one way to trip out behind the barn for the crime of being useless. They've had 30 years to fix things like C not having arrays, lack of modules and name spaces.

Purists can always use std=-c89.

I love C because it’s so minimal.

And it’s not a dead end at all - embedded systems, wasm, wasi, really fast things, and aside from assembly it’s one of the first things on newer platforms (risc v for example).

I like Go for the same “try to keep it minimal” reasons, and keen to try Zig when I have some time.

I think the bias you are implying might be misplaced.

The problem with C is that its... kind of minimal, but it also needs tons of extensions to get things done.

Want multiple heaps? That'll be a compiler extension. Want to specify exactly where a variable is laid out in memory? Compile extension.

Have a memory layout that isn't just a flat map of address space? Better reach for a compiler extension.

Hardware registers? Eh, overlay it with a union or a struct or something, it'll be fine. Unless you want some sort of non-trivial typing on those registers.

People forget that C is written against an abstract C machine. C is not written against the underlying hardware platform. And the abstract C machine may differ from your target hardware by a fair bit.

> Want multiple heaps? That'll be a compiler extension.

That sounds like a library, not a compiler extension.

True enough, C doesn't care much about how allocation is done.

Which is part of the problem! Ugh.

Why would C be the requirement for “really fast things”? It doesn’t even have any support for SIMD instructions other than going inline assembly.

Using intrinsics is much more sensible option than dropping to inline asm. Each CPU with SIMD or any kind of specialised instructions provides an intrinsics library for C.

Which, correct me if I'm wrong, is also a compiler extension.

C is a great language. Actually it's not that small, it's just that modern languages often are very big (easy if you compare yourself to C++). The feature bloat is a fairly recent trend.

"C is faster/smaller/... than C++" hasn't been true in a long time.

I would argue that the time you need to invest to get something done correctly in C is a cost you can avoid with (modern) C++

Personally, I don’t like C++ - maybe it’s the friends function or templating or the usual build systems… and it’s not small by a long shot. My opinion is not really based objectively, I just don’t like it.

If I wanted / needed something more oo I’d probably learn rust.

C++ is everywhere doing amazing things so hate - unreal engine! - just really not my cup of tea.

C++ compile times would like to have a word with you ;) The biggest drawback of C++ are the atrocious compile times.

Are you serious?

I mean, of course, I also like short compile times... but since when are they considered a serious cost? What are we talking about? Seconds? Minutes? Hours?

Are you using your compiler as a syntax checker? Always compiling everything all the time?

Especially since you compile once, what you run a million times and now that everyone is running around with what would have been considered a supercomputer decades ago in their backpack, and a half in their pocket.

Of course I think stuff should compile fast (that's why we use Make, CMake, ninja, etc.) but I would never chose C over C++ because of compile times... Code that requires high mental load and solving the same stupid things again, and again, and again... still costs more time than my compiler can get me back IMO.

> C is sort of a dead

C is like a table saw without a blade guard. Simple yet precise, powerful, flexible, and will cut your fingers off if you aren’t careful.

But it’s often exactly the kind of dangerous saw we need sometimes.

There’s no point in trying to improve it - there are plenty of other, safer saws for that.

This is kinda my opinion too.

C is awful, C is terrible, C is almost always the wrong answer.

But when it hits the spot, it's a fantastic wrong answer for a bunch of things.

> They just want to write software the same way they've been doing for the last 20 years.

Actually I just want to write software the same way I've been doing it for the last 40 years, but otherwise yeah.

Reply on news.ycombinator.com