http://wyoos.org - Write Your Own Operating System

[algorithman]

Some people have complained about my statement that Procedural Programming is a thing of the past, so I want to go a bit deeper into what I mean:

Before the early 2000s, Procedural Programming was everything. There was some OOP, but it was underdeveloped. In the early 2000s, Borland C++ Builder and Java changed that. They were the first to bring OOP frameworks that were fit for professional use. These frameworks made GUI development easy and thus received widespread acceptance. The way they worked (Instantiate some kind of "Application" object, pass it a tree of GUI elements, call some kind of "run" method on it) can still be found in all major GUI Frameworks today.

Since then, things have changed. OOP has gone from being a niche product to dominating large parts of the programming market. Just look for Programming jobs - the large majority is in OOP. That doesn't mean Procedural Programming was dead - you still find jobs in Procedural Programming (mostly IoT firmware and maintenance of legacy software) - but it used to be the top-dog - now it is the niche product and the previous niche product OOP has become the top-dog.

That is what I mean, when I say that procedural programming is a thing of the past - and I stand by that statement!

[algorithman]

That doesn't mean that I disregard all other programming paradigms. Quite the contrary! I genuinely love Logic-Programming (I have worked at the chair for artificial intelligence at the RWTH Aachen and the chair for logic and semantics at the TU Berlin, after all!) and I also like functional programming a lot. I have even written my own functional programming language and Prolog interpreter. I have also written interpreters for mu-recursive functions, GOTO, WHILE and Turing Machines. I love programming everything that is turing complete. Even things that aren't turing complete (like LOOP and primitive-recursive functions). I am especially interested in the possibilities of translating between these and running them in native (virtual) machines. Just see http://algorithman.de/Algorithmen/compiler .

I have worked with 26 different programming languages and countless different paradigms. I wouldn't program an artificial intelligence in any language other than Prolog for example (look for GOLOG - I once wrote my own dialect of that, too).

That being said, I have to say that with all these languages and paradigms, I have hit some brick-wall at some point - some major deal-breaker that stopped me from going forward with them. Often file access, network access or GUI / GUI Designers being missing or unstable or just to hard to use. Sometimes, there were workarounds that allowed you to call C functions, but... why wouldn't I write the whole thing in C then in the first place?

The only languages that have never failed me, are C++ and C#. Sure you sometimes have to work around some shortcomings, but that has always been easier than switching the language.
Revealingly, all my interpreters and compilers are written in C++. Just like the Java Compiler, Java VM and the .Net Compilers and VM.

[algorithman]

Michael Bradley told me about this quote from Linus Torvalds

In fact, in Linux we did try C++ once already, back in 1992.

It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.

The fact is, C++ compilers are not trustworthy. They were even worse in
1992, but some fundamental facts haven't changed:

- the whole C++ exception handling thing is fundamentally broken. It's
especially broken for kernels.
- any compiler or language that likes to hide things like memory
allocations behind your back just isn't a good choice for a kernel.
- you can write object-oriented code (useful for filesystems etc) in C,
without the crap that is C++.

In general, I'd say that anybody who designs his kernel modules for C++ is
either
(a) looking for problems
(b) a C++ bigot that can't see what he is writing is really just C anyway
(c) was given an assignment in CS class to do so.

I understand Linus' point of view, but I don't agree with him. Infact, I think HE is writing C++ code without realizing it (plus he is wasting his time by hand-writing lots of code that C++ would generate automatically).

IMHO, it is mostly a question of HOW you think. Hardware guys (and I count Linus as such) think more concrete, in terms of the states and state-transitions of the devices and how to control them. These guys tend to write code that basically simulates hardware. For example they use bytes as if they were a bundle of 8 cables, being energized (1) or not energized (0) and every instruction turns some of them on and/or some of them off (I do that sometimes in the videos, too, although I tried to avoid it).
OOP - or better: polymorphic programming is more about expressing the semantics of the resulting system - the high-level idea of what the desired behavior is and then breaking that down further and further to more and more concrete sub-classes, until you reach the hardware-level. This video explains that well.

Although I don't use exceptions here: since Linus mentioned them, let me say something about that topic: C++ exception handling is not easy to do 100% right, but it solves more problems than it causes (see the 3 videos on http://exceptionsafecode.com). Without exceptions, C++ becomes very close to C, but you have stronger type-safety (I really like strict typing - it catches a lot of errors at compile-time that would otherwise cause run-time errors or worse) and you also get safer polymorphism. You can do polymorphism in C - and Linux does that (that is why I say Linus is actually writing C++ code), but it is harder, because you have to create the VTables manually, multiple inheritance is madness and you need to be more careful to not accidentally call the wrong "method". C++ solves these problems for you.

[algorithman]

When I started programming, I was considered a prodigy. I was able to develop small programs very fast, but the larger my projects got, the harder it became to work on them. I tried lots of programming paradigms and learned the hard way which properties of source-code cause this so called software erosion (or "code-rot") and how to avoid them. This way, my programming style turned more and more into the S.O.L.I.D. principles (see also this video).
By the way: My path was largely influenced by Declarative Programming, in particular my experience with PROLOG, where everything is immutable.

From my (real world) experience I can say that with procedural programming, you need about 100 times more code to achieve the same results as with OOP (and no, I don't mean 100% more code, I mean 10000% more code).
Ever since I truly embraced polymorphic programming, I have become incomparably more productive. My code is much more re-usable, readable, reliable and fast.
Granted, you can apply the S.O.L.I.D. principles to procedural programming also, but procedural programming really isn't designed towards them. You have to jump through hoops to achieve the same results (for example you must separate many things into their own files, making your project less readable) and that is why this is not really done in practice (the Linux kernel is the only example that I know of, where it is actually done).

[algorithman]

They say "if your only tool is a hammer, every problem looks like a nail", but I have tried more paradigms than I can remember (procedural, logical, functional, reactive, agent-driven, ...) and have found OOP to be really the be-all and end-all solution to everything. I was able to write anything I wanted in it - it hasn't failed me once in decades. OOP is not a hammer, it is not a screwdriver, it is a swiss army knife. It doesn't force you to turn your problems into nails or screws, it allows you to turn it into the tool you need for the problem at hand.

So why would you use a programming language like C, Basic or Pascal, that forces one tool on you, when you have a swiss army knife, where that tool is one of many you can choose from? That just limits your options - and for what? The only benefit I can see is the performance (which has become relatively irrelevant in most areas).

Of course OOP doesn't turn a bad programmer into a good one. You can do things wrong despite OOP, if you don't truly understand what OOP can do for you. I have seen a lot of "Pseudo-OOP" code that was basically just procedural code wrapped in so called "Pseudo-Classes". That is the equivalent of using only the hammer in your swiss army knife and turning your problems into nails again.

[Alexisneato]

At first I really didn't want to bother with this... but I guess we're doing this now. below is a screen capture of the conversation that triggered Algorithman. The conversation was in response to his comments in this video https://www.youtube.com/watch?v=1rnA6wpF0o4

Here is a link to the google drive image viewer of the captured comments, I can't seem to directly embed it without losing fidelity:
https://drive.google.com/file/d/0B888bH ... llYWM/view

I might regret engaging you here, as I'm sure it is not nearly as neutral territory as the youtube comments. Also for the record, this is not an argument of C vs C++, as both languages are capable of Object Oriented programming, and of procedural programming. It's only that C++ has some tools that aid object oriented programming that C lacks. Please stop conflating languages and paradigms. Additionally I do not care what your credentials are, what you've done, who you are, or who thought you were a prodigy when you were a kid. I don't give a fuck. Give me your argument. As your argument is all that is necessary.

[algorithman]

Hello Alexis,
thank you for your patience - I'm sorry it took a while to approve your message - I didn't realize it was waiting for approval (phpBB doesn't make that visible enough... shitty board, I admit).

[Alexisneato]

Additionally, for the record, disabling comments on your video, kind of a dick move, and doesn't erase history.
Can you address my actual point? Or... ?

That or an apology for being a fucking tremendous asshole.

Either way, your call.