What do you think of the C-family programming languages?

[Graf Zahl]

18 minutes ago, Cacodemon345 said:

I would be more interested in the modules but it seems to be one of those steps to take the C out of C++.

 

Yes, but that's a good thing. The include system and complex class definitions do not match.

Includes are the single most aggravating issue C++ suffers from because every sub-header's contents bleed into the current namespace and can create conflicts. In a large code base this can become a major maintenance hassle.

 

The iOS project I maintain at my job has two parts, a C++ backend and an Objective-C frontend. Compiling the backend takes 8 minutes, compiling the front end takes one minute. Why? It makes heavy use of C++ container classes which causes the inclusion of huge headers into every file and the compiler has no way to optimize it. The core feature of modules is that each declaration unit only needs to be compiled once, and can store the result in a ready-to-use file for later reuse.

 

 

18 minutes ago, Cacodemon345 said:

 

And as far as the iostreams are going, I almost never use them, expect for printing shit into the terminal output window and for accessing files. When I saw the FileStream interface in C#, I was glad it was a step forward because you can know the length of the file beforehand, and you can actually use the built-in BinaryReader and BinaryWriter classes for parsing binary formats. Trying to do such a thing would be more work in C++.

 

So you are using them for the narrow use cases they were made for. I find them useless even for that. Also, knowing the size of a file beforehand can be done with iostreams in the same way as with stdio: Seek to the end, read the position, seek back. Yes, it's stupid and clearly shows that the designers of this abomination, just like the designers of stdio saw character output streams as their primary target,not files.

 

 

18 minutes ago, Cacodemon345 said:

The language seems to be designed more for those who prefer a minimalistic approach to programming and for those who compiles everyday with all warnings as errors. Usually someone who knows Lua would be able to get into the Go language with less frustration.

 

Yes, that's my impression as well, it'd look good for an embedded scripting language, but I'm not sure if it is suitable for that.

 

24 minutes ago, Kronecker–Capelli said:

Okay, why it taken...*looking at an imaginary watch*... more than 30 years to come up to this?

 

Yeah, strange, isn't it? And it had been postponed for at least two standard drafts because some people were just too scared that it could cause problems.

 

[Jon]

8 minutes ago, Graf Zahl said:

So you are using them for the narrow use cases they were made for. I find them useless even for that. Also, knowing the size of a file beforehand can be done with iostreams in the same way as with stdio: Seek to the end, read the position, seek back. Yes, it's stupid and clearly shows that the designers of this abomination, just like the designers of stdio saw character output streams as their primary target,not files.

 

Or input streams, which aren’t seekable, are potentially infinite, etc

 

 

[Kronecker–Capelli]

12 minutes ago, Graf Zahl said:

Yeah, strange, isn't it? And it had been postponed for at least two standard drafts because some people were just too scared that it could cause problems.

Similar, if not literally same, package system exist in Java right from the beginning (not sure about "from the beginning"). And it work great there.
And I really doubt that "they" did not figure out all cons and pros of such system at the example of Java. Example of already working and wildly used programming language.

Well, better late than never, I guess.

[Graf Zahl]

13 minutes ago, Jon said:

 

Or input streams, which aren’t seekable, are potentially infinite, etc

 

 

What puzzles me most here is that even on an OS level there is no clear distinction between a file and a terminal and that the language developers also do not seem to want to make a clean break here and offer something for both that's actually good at the specific job, not these Frankensteinian monster APIs that try to mix both and doing neither right.

 

[Graf Zahl]

Just now, Kronecker–Capelli said:

Similar, if not literally same, package system exist in Java right from the beginning (not sure about "from the beginning"). And it work great there.
And I really doubt that "they" did not figure out all cons and pros of such system at the example of Java. Example of already working and wildly used programming language.

Well, better late than never, I guess.

 

The main difference here is called "backwards compatibility". C++ builds on C and needs to continue to interoperate with C - it's one of its biggest assets. Throw that away and you are guaranteed to lose. Java started from scratch.

[Kronecker–Capelli]

24 minutes ago, Graf Zahl said:

 

The main difference here is called "backwards compatibility". C++ builds on C and needs to continue to interoperate with C - it's one of its biggest assets. Throw that away and you are guaranteed to lose. Java started from scratch.

It could have been done in Python like way, by using "try: import name; catch: #include name;" or something like that. Not a big Python user.
Or even by making a "pro gamer move", by adding module support in C. Inline, const and such things was added to C after implementation in C++ after all.

They should at least try to do something with it, I mean.
But for now its like yelling on tree "WHY YOU GROW HERE AND NOT FIVE METERS TO THE RIGHT".

At least now I have right to say to my grandchildrens "back in my day we used keyboard and mouse to interact with computers, not yours virtu.....virtuous regally glasses....and we also used "#include" when programming, not this puny "import" " :)

 

Edited July 19, 2020 by Kronecker–Capelli

[andrewj]

26 minutes ago, Graf Zahl said:

not these Frankensteinian monster APIs that try to mix both and doing neither right.

That's how I view C++ these days, as a language that tries to mix both low-level unsafe do-whatcha-like semantics of C with a high-level mostly-safe language.  A franensteinian monster indeed.

 

Bjarne Stroustrop once said that within C++ is a clean language struggling to get out, it's a shame he never developed THAT language as a separate thing, but there's way too much momentum behind C++ now, and as Graf said the "easy" interfacing with C libraries is a massive win (ignoring the fact that many of them have #ifdef cplusplus in their headers).

[Graf Zahl]

4 minutes ago, andrewj said:

That's how I view C++ these days, as a language that tries to mix both low-level unsafe do-whatcha-like semantics of C with a high-level mostly-safe language.  A franensteinian monster indeed. 

 

Yes, but on the other hand, if that mixture wasn't possible it'd be just another language around the block. I think Swift is a good example of a language that just follows the current bandwagon and isn't afraid to deprecate 'obsolete' stuff. But it also makes it a language I wouldn't use.

 

4 minutes ago, andrewj said:

Bjarne Stroustrop once said that within C++ is a clean language struggling to get out, it's a shame he never developed THAT language as a separate thing, but there's way too much momentum behind C++ now, and as Graf said the "easy" interfacing with C libraries is a massive win

 

As much as I'd like to see that safe language emerge from C++, the price would be too high because it'd orphan too much old code. I see this with GZDoom all the time: It still depends on programming concepts from 30 years ago in parts and there is no good chance to get all this out again. Although TBH, the biggest problem spots are not in id's original code but in early ZDoom additions. That code has a tendency for awful implementations that value efficiency over maintainability. At least all that old code still works. ;)

 

4 minutes ago, andrewj said:

(ignoring the fact that many of them have #ifdef cplusplus in their headers).

Sure they have, otherwise you'd have to add extern "C" yourself everywhere.

 

[printz]

When I want to read simple space-separated values, I find ifstream much more convenient than fscanf.

[Antkibo]

C is probably the most influential programming language ever made, and it's the foundation for the most popular languages nowadays (C++, Python, JavaScript, Ruby, and so on).

 

Now, for me 'C-family' means those typed, compiled languages that looked to replace or improve upon C in some manner - C++, Go, and Rust to name a few. While they have their benefits, there hasn't been an proper successor of C since its inception if we consider that "The C Programming Language" says that

 

Quote

C is not a big language, and it is not well served by a big book.

 

Quote

But its absence of restrictions and its generality make it more convenient and effective for many tasks than supposedly more powerful languages.

 

Let's compare its descendants:

• C++. Messy and totally anti-compact. There are many ways to write C++ and more are added with time, but its main drawbacks have not been addressed (probably, they can't be). Its main strength - good C interoperability - has become a disadvantage in the form of #include macros and what not, creating a need to use equally complex building automation tools like CMake.
• Go. Simple, but feels constrained. Module system is a mess. Error handling feels too simple and very C (e.g. if START_PROGRAM() == -1). No generics. Fast compiler, though.
• Rust. Secure, but very alien. Developer productivity is on the low side, compiling times on the high side. Zero exploratory programming. Cargo is a godsend, however.

Also, Go and Rust are more or less "products" of Google and Mozilla, respectively. I don't give a f#@$ about that, but I wonder how many enterprises use Rust just to spite Google and vice-versa.

 

So here am waiting for a 'safe' dialect of C. We had one, Cyclone, but that didn't get far. Zig looks good, so does D (as in, D as a Better C). Let's see how things turn in a few years.

 

Edited July 19, 2020 by Antkibo

[Graf Zahl]

2 hours ago, Antkibo said:

Now, for me 'C-family' means those typed, compiled languages that looked to replace or improve upon C in some manner - C++, Go, and Rust to name a few. While they have their benefits, there hasn't been an proper successor of C since its inception if we consider that "The C Programming Language" says that 

 

Sorry, can't quote the quotes but those supposed "benefits" of C are also its biggest weaknesses. C is a language that allows everything and expects total responsibility from the programmer, and in most fields that is something absolutely unwanted. Trying to write very complex software with a very simple language will always end up a mess because of the high risk of errors that can be made and the language providing no help

 

2 hours ago, Antkibo said:

Let's see how its descendants compare:

• C++. Messy and totally anti-compact. There are many ways to write C++ and more are added with time, but its main drawbacks have not been addressed (probably, they can't be). Its main strength - good C interoperability - has become a con in the form of #include macros and what not, creating a need to use equally complex building automation tools like CMake.
• Go. Simple, but feels constrained. Module system is a mess. Error handling feels too simple and very C (e.g. if START_PROGRAM() == -1). No generics. Fast compiler, though.
• Rust. Secure, but very alien. Developer productivity is on the low side, compiling times on the high side. Zero exploratory programming. Cargo is a godsend, however. 

 

This looks correct on all accounts. The fun thing is that Microsoft has been working on a good library management system for C++ with vcpkg, but apparently nobody wants to support it with their toolchains. If this could be integrated into larger projects hassle-free we'd make a massive step forward but as things stand, we still face the same problem that each platform wants to do it differently.

 

Go and Rust both look like the products of ideological turf wars and in case of Rust an additional "how can we make it as hard as possible for C++ developers to switch" attitude to me. I find the language just awful, never mind the good concepts behind it. Now, if we could limit the C++ compilers to a safe subset of the language we'd be half way there without reinventing the wheel. That's actually one of my main issues with C++ - I want to program safely but all those minefield features like unsafe type casts cannot be switched off, so they remain undetected in the code.

 

2 hours ago, Antkibo said:

so does D (as in, D as a Better C). Let's see how things turn in a few years.

 

AFAIK D uses garbage collection as its means of memory management, so one more language that's DOA for a C replacement.

 

 

 

[Cacodemon345]

The D programming language is honestly too strict for my tastes. The syntax also feels worse than Go.

[Cruduxy Pegg]

I'd take C or C++ any day over that Frankenstein known as VB.

[Antkibo]

1 hour ago, Graf Zahl said:

Sorry, can't quote the quotes but those supposed "benefits" of C are also its biggest weaknesses. C is a language that allows everything and expects total responsibility from the programmer, and in most fields that is something absolutely unwanted. Trying to write very complex software with a very simple language will always end up a mess because of the high risk of errors that can be made and the language providing no help

 

Didn't quote them as benefits, but more as 'characteristics' that define C. As no other language has tried to follow these guidelines, I believe C has descendants but not a true successor.

 

Of course, this hypothetical 'better' C needs to lift off some complexity from the programmer while remaining simple and not overly restrictive just because (looking at you, Go). As Linux depends a lot on C, even a slightly safer C dialect would bring enormous profits.

 

That it'll be unwanted in most fields? That's true and that's okay: there's a lot more languages now than when C was designed - no need for it to be a swiss knife anymore.

 

Quote

This looks correct on all accounts. The fun thing is that Microsoft has been working on a good library management system for C++ with vcpkg, but apparently nobody wants to support it with their toolchains. If this could be integrated into larger projects hassle-free we'd make a massive step forward but as things stand, we still face the same problem that each platform wants to do it differently.

 

Funny, I had no idea such a thing existed until I played around with the source of HiveWE. Not enough advertising?

 

Quote

AFAIK D uses garbage collection as its means of memory management, so one more language that's DOA for a C replacement.

 

The -betterC flag makes D code work more like C. Among other things, it removes the garbage collector. Nevertheless, D is very niche and will remain so for the foreseeable future.

 

Edited July 19, 2020 by Antkibo

[Graf Zahl]

5 minutes ago, Antkibo said:

 

Didn't quote them as benefits, but more as 'characteristics' that define C. As no other language has tried to follow these guidelines, I believe C has descendants but not a true successor.

 

I don't think that these characteristics have much merit these days. In times of remote exploits and growing software complexity a language that demands total attention from the programmer is something that should be restricted to the lowest of low end tasks.

 

 

5 minutes ago, Antkibo said:

Of course, this hypothetical 'better' C needs to lift off some complexity from the programmer while remaining simple and not overly restrictive just because (looking at you, Go). As Linux depends a lot on C, even a slightly safer C dialect would bring enormous profits.

 

Actually, no. C is old - it s based on old concepts. We do not need another language following the same old concepts. What we need in the future is languages that can express parallelism in more accesible ways because that's where future performance improvements will come from. Most current languages are poorly equipped to handle this well.

 

 

5 minutes ago, Antkibo said:

The -betterC flag makes D code work more like C. Among other things, it removes the garbage collector. Nevertheless, D seems is very niche and will remain so for the foreseeable future.

 

And it disables half the language. If the selling point is range checked arrays, these can be done in C++ with relatively little effort.

 

[Cacodemon345]

12 hours ago, Graf Zahl said:

Actually, no. C is old - it s based on old concepts. We do not need another language following the same old concepts. What we need in the future is languages that can express parallelism in more accesible ways because that's where future performance improvements will come from. Most current languages are poorly equipped to handle this well.

Not to mention C's early origins come from the Unix days, which should explain why the C standard library lacks any distinction between the file and the terminal. At this point it's a language in development for 47 years.

[Jon]

15 hours ago, Graf Zahl said:

 

Sorry, can't quote the quotes but those supposed "benefits" of C are also its biggest weaknesses. C is a language that allows everything and expects total responsibility from the programmer, and in most fields that is something absolutely unwanted. Trying to write very complex software with a very simple language will always end up a mess because of the high risk of errors that can be made and the language providing no help

 

counter-example: the Linux kernel. I’d argue that chocolate doom is a very well organised, complex, pure C project too. 
 

 

[Graf Zahl]

I am not a kernel programmer, but from what I heard it's not all peachy over there and Linux does apparenly suffer from some issues caused by an old and crusty code base. It's also a kernel where other rules exist and a language that thinks too much may not be the right choice.

 

And Doom doesn't count. It may be C, but it does use advanced programming concepts and it also suffers from typical C problems like the overuse of global static variables, hard coded buffers and other niceties - and Chocolate Doom preserves all of these things, down to the crashes they cause. It may be intentional to preserve this but any crash counts as a bug to me. But as things stand, give me any 90's game's source and they all suffer from the same problems, and these problems are mainly caused by having used C as development language and being sloppy on error handling code.

[Cacodemon345]

16 minutes ago, Jon said:

 

counter-example: the Linux kernel. I’d argue that chocolate doom is a very well organised, complex, pure C project too. 
 

 

Linux is a Unix-like OS kernel, so C would be perfect for it. C nowadays is only fine if you are developing low-level stuff. Maybe for Doom engine ports, because they are generally well designed.

 

Another non-C example would be the Redox OS microkernel. It is written in Rust. And the OS itself is POSIX-compatible. But the microkernel does have unsafe code.

Edited July 20, 2020 by Cacodemon345

[DooM Bear]

Don’t wanna hijack this thread and feel free to tell me to piss off if this isn’t a simple answer but as someone who is interested in getting into some programming (just for fun) what do you guys think is the best language to learn these days?

 

I’m pretty much a blank slate (have some previous light experience with HTML and Basic... no not Visual Basic :-P) :-)

 

Most people I’ve spoken to IRL recommend python but that might just be the “industry” standard for their particular line of work or something.

 

Any recommendations? And again, if this is an in depth discussion please let me know and I’ll make another thread as to not hijack this one :-D

[Cacodemon345]

1 minute ago, DooM Bear said:

Don’t wanna hijack this thread and feel free to tell me to piss off if this isn’t a simple answer but as someone who is interested in getting into some programming (just for fun) what do you guys think is the best language to learn these days?

 

I’m pretty much a blank slate (have some previous light experience with HTML and Basic... no not Visual Basic :-P) :-)

 

Most people I’ve spoken to IRL recommend python but that might just be the “industry” standard for their particular line of work or something.

 

Any recommendations? And again, if this is an in depth discussion please let me know and I’ll make another thread as to not hijack this one :-D

I'd advise to make another thread instead of derailing one.

[DooM Bear]

4 minutes ago, Cacodemon345 said:

I'd advise to make another thread instead of derailing one.

 

No stress at all and will do :-) 

 

Figured I’d pop it up here just in case there was an overwhelming “go with X, it’s the only language you need to know these days” answer :-P

 

Thanks!

[Graf Zahl]

27 minutes ago, Cacodemon345 said:

Another non-C example would be the Redox OS microkernel. It is written in Rust. And the OS itself is POSIX-compatible. But the microkernel does have unsafe code.

 

You cannot write a kernel without using "unsafe" code. You cannot manage any "safe" code at all without switching off the safety features at some point.

 

[Kronecker–Capelli]

15 hours ago, Antkibo said:

hypothetical 'better' C

Problem with developing new programing languages is that nobody really know how this new language would be used.
For example, when Java was created nobody thought that in future it would be used as one of the main enterprise language (other is Python). It was assumed that it would be used as programming language for small household electronic devices.

[Ferk]

Imho, whether a programming language is "best" depends on your environment and conditions.

The statement "C sucks" or even "ASM sucks" is only valid within context. It might turn out C works quite well for a range of embedded environments and custom hardware. Even in videogames, if you are targetting say, NES homebrew, or some retro devices, what's "best" can radically change.

 

And what's more, there isn't a single language that is "suck"-proof, bad code is bad no matter what language you use and it's just as easy to write horrible unmaintainable code, with safety features or without.

 

In fact, sometimes the more safe and user-friendly languages may attract people who would rather be lazy. Or the opposite, the nicety of extra features can drive playful people to over-engineer solutions that do not hold up in the long run.

[Jon]

6 hours ago, Cacodemon345 said:

Linux is a Unix-like OS kernel, so C would be perfect for it. C nowadays is only fine if you are developing low-level stuff. Maybe for Doom engine ports, because they are generally well designed.

 

I don't disagree with any of that, and it also doesn't refute what I wrote.

 

6 hours ago, Graf Zahl said:

I am not a kernel programmer, but from what I heard it's not all peachy over there and Linux does apparenly suffer from some issues caused by an old and crusty code base. It's also a kernel where other rules exist and a language that thinks too much may not be the right choice.

 

It aint perfect of course but I still think it's quite a marvel of engineering. It's been a while since I worked in/on it myself though (and my contributions are extremely modest)

 

Quote

And Doom doesn't count. It may be C, but it does use advanced programming concepts

 

Why does using advanced programming concepts rule anything out? It's still C. You can use advanced programming concepts in C.

 

Quote

and it also suffers from typical C problems like the overuse of global static variables, hard coded buffers and other niceties - and Chocolate Doom preserves all of these things, down to the crashes they cause. It may be intentional to preserve this but any crash counts as a bug to me.

 

I think you are deliberately not distinguishing two types of crash here: an out-of-bounds memory access that causes a segmentation violation with memory protection, which vanilla doom is littered with, but are relatively uncommon in Chocolate Doom, and are removed when they are found; and detecting a future out-of-bounds memory access, followed by a deliberate, graceful program termination. I appreciate if your project goals are not to have your port suddenly stop under any circumstance then the distinction isn't important, but it is for Chocolate Doom, and the latter type is by design (and if it weren't by design, then we would simply do something else: the hard part is detecting the problem, which we do.)

 

Quote

But as things stand, give me any 90's game's source and they all suffer from the same problems, and these problems are mainly caused by having used C as development language and being sloppy on error handling code.

 

If you were holding up several contemporary examples of C++ games that did not have those problems you'd have a stronger argument. As it is you have 90s games written sloppily and lacking in discipline which results in problems, and the fact they used C is orthogonal.

[Jon]

 

8 hours ago, Cacodemon345 said:

Not to mention C's early origins come from the Unix days, which should explain why the C standard library lacks any distinction between the file and the terminal. At this point it's a language in development for 47 years.

 

Of course C (and UNIX) abstract over Real files and streams (what you are calling terminals here) by design. You don't know how large a stream might be and you have no idea whether it can even fit in memory all at the same time or not. Back when C and UNIX were designed the same was true for a lot of files, though; it's a modern luxury to manipulate an entire file in memory. The seek/tell approach for  getting a file size breaks down on a stream. But UNIX provides stat to address this for real files. If other platforms have cargo-culted some of the UNIX design and not other bits then, that's their fault.

 

it's still a useful abstraction even today. A command I just ran at home

 

cat Psychonauts_PC.zip.0* | md5sum - Psychonauts_PC.zip

 

[Graf Zahl]

1 hour ago, Jon said:

 

 

Of course C (and UNIX) abstract over Real files and streams (what you are calling terminals here) by design. You don't know how large a stream might be and you have no idea whether it can even fit in memory all at the same time or not. Back when C and UNIX were designed the same was true for a lot of files, though; it's a modern luxury to manipulate an entire file in memory. The seek/tell approach for  getting a file size breaks down on a stream. But UNIX provides stat to address this for real files. If other platforms have cargo-culted some of the UNIX design and not other bits then, that's their fault.

 

 

I think that a file library that is based on 40+ year old concepts and completely ignores more modern approaches like memory mapped files or asynchronous file access is just obsolete. Both stdio and iostreams just provide the barest minimum of what is needed to use files but it's all horrendously outdated. It's stuff I merely use because there is nothing better that's cross platform, not because it is good.

 

 

[Jon]

But I’m guessing you are always talking about local files that you can read entirely into memory (or map). My point is there are plenty of problems where this isn’t possible. And it’s a positive thing that a tool like md5sum in my previous example is abstracted over both so one can use them with either and it doesn’t have to care. 
 

 

[Cacodemon345]

The approach of reading from stdin is still more of a POSIX/UNIX concept; most Windows users would expect command-line programs to take another file as an argument.

 

What was true 40+ years ago isn't true nowadays. We nowadays have the luxury of 100GB+ hard disks, which wasn't the case back then. Back in the day terminals were commonplace, nowadays we got actual computer screens with graphics.

2 hours ago, Jon said:

Why does using advanced programming concepts rule anything out? It's still C. You can use advanced programming concepts in C.

One of the programming concepts used by Doom was pseudo-inheritance; that thing by itself relies upon type-punning that is disallowed in recent C (maybe?) standards and C++ standards.