C was already sharp

0:00 Intro
0:58 C# Demo
2:00 C# Language
3:45 Bash
4:51 C Language
8:44 C Demo
10:38 Closing

[contextfree]

Thanks much to Serenity OS creator Andreas Kling for providing hi and bye in Swedish!

[wilfreddv]

Thank you for this interesting look on things! I've never thought of C programming this way.

[aypahyo]

I was working on a C# client that (re-)launched its own c# server in a separate process with the sole purpose to interact with poorly written c++ libraries. Keeping process boundaries in mind is still super useful and the fact that a rotting c++ carcass cleans up after itself when it crashes is a very nice effect.

[apestogetherstrong]

C being sharp also means you can cut yourself really easily

[oof-software]

Awesome video! I really enjoy the way you introduce one to the topic of the current video.
The examples combined with your explaining are perfect!
Thank you for this awesome and informative content!

[Nathankthanks]

I love this topic! I had been thinking recently that objects and "apps" are pretty much the same thing, and this demonstration makes me feel vindicated.

Mind expanding stuff! Thank you!

[neqkk]

Indeed the long-lived monolithic app is an anomaly in a sense. One thing here that’s nice with the OS as runtime is that it doesn’t need to track individual fine grained allocations but just the larger blocks, which is lighter weight. I believe this is how you also want to do it in monolithic long-lived programs

[homelessrobot]

Right, and threading gives you an additional level of granularity, since every thread gets its own stack, can handle signals independently, has its own set of global (thread local) variables, and a definite beginning and end to its lifetime in which initialization and cleanup can occur. Many people seem to think the existence of threads is simply to get your program to use more than one processor at a time, and don't seem to remember at all that mutithreading predates SMP in most operating systems and commodity hardware by quite some time.

On top of dynamic encapsualation/modularity, c also has quite a bit more in the way of static encapsulation and trickery than many people think. The linker is where most of this happens though, so its overlooked as a language feature. In general, c does not implement quite a lot of language features because they already exist in its tooling and environment. If you put in the time to figure out the tooling and environment that c is largely expecting to exist in, you will find that a lot of your favorite features in other languages don't actually even need language support.

[andrewherrera]

the hash in c# looks like overlapping +'s. so it is really c ++++

[AK-vxdy]

Very interesting and fun !!! Past days i saw decent size accounting system written that way (including own file based DB storage).
It was forced because it was used in odd method of "networking" or rather "timesharing" called MultiDOS.
Under MultiDos "server" RAM was divided beetween "clients" so if was 10 clients then one client had whooping 64kB (640kB/10).
So appilcations were keeped bellow 16kB. Also it was harder becase no power of bash... only mere command.com and *.bat files.

[Lukas-ernd]

Interesting look on how Unixey tools used to be written, though this isn't what we want for applications anymore, for good reason. If you want another approach to OOP in C, look up how the strongSwan project is built. Somewhat cumbersome, but still very much functional.

Easily usable modern style is what will replace C eventually IMO, which is why I put a lot of hope into the Zig project, it's probably the closest contender i know of. I love how it manages to achieve all that with very little drawbacks or bloat that would just kill some usecases. Almost all other higher-level languages come with too much baggage to do anything useful when coding in the hardware/embedded or system level. Even something as awesome as Golang is unfit for a lot of those uses (especially when it comes to interoperating with C and the relatively large runtime for a systems language).

[brujua]

Very interesting! Thanks for the video

[piotrarturklos]

Awesome perspective. Makes you wonder what was the original thinking behind languages of C era and to what extent the designers thought that this is the right way to do programming, as opposed to knowing about the need for stronger language mechanisms.

For the benefit of those that didn't notice, I have to point out that this doesn't scale, because you just can't make a huge number of processes like these for various reasons. Also, managing and communicating between those would be a mess.

Also, there are modern applications written with some of these rules in mind, for example the D language compiler front-end doesn't deallocate all memory, it just assumes it will finish compiling a file and die. So a useful idea nonetheless.

[MaxPicAxe]

Wow this was a very interesting video!

I've always wanted to create my own programming language, and in this language it would be possible for individual functions to be implemented as their own isolated processes (as shown in this video) without the callers of the functions having to know about these implementation details, and can just invoke them as normal.

[maisylover]

I don't know if I'd call that garbage collection, since most GCs (from what I understand) don't wait until the end of the program to clean the memory, but rather until a heap-allocated object's refcount hits 0 (or perhaps a little while after it hits 0). Still an interesting concept

[bjzaba]

Would be cool to maybe look at effects and handlers in the future, eg. in Eff, Frank, Koka, and Multicore OCaml. Kind of reminds me of how you were using exceptions in the C# example. Eg.

[mkvoq]

Interesting concept. But this is not really OOP, this is closer to the functional programming, such subprocesses is basically "pure functions". And this is the way how e.g. bash scripting works when your scripts have nested calls of each other.
And of course in reality spawning a lot of subprocesses is very resource consuming and low performant :)

[kim]

Maybe you could make a video on helpfulness of compiler error messages? Elm is pretty good at this, for example

[EssentialMotion]

How do you show your RAM usage in the status bar in vscode?

[akj]

1. The fact that you are using bash with C shows how limiting C is. This example could have worked without the use of Bash.
2. Concerning not cleaning up memory on exit and how modern programs don't do that anymore. Actually Golang does that. Try to run Valgrind on a Go executable, the compiler doesn't free everything. You can still find the original source code of Go written in C. Check the official git repo before version 1.4.3