For further actions, you may consider blocking this person and/or reporting abuse
For further actions, you may consider blocking this person and/or reporting abuse
Austin Cunningham -
Shakir -
Gursimrat saini -
Sandeep Nautiyal -
Top comments (16)
why should it, as classes are nothing else but the combination structs and methods, and
chas methods and structs, there is all you need, to code with an OoP mindset,.... if that is what you prefer.You're getting this backward. C did get classes, and that is called C++. Early versions of C++ were largely based on C.
Perhaps the right question here would be, why do people still use C? Part of the answer is, they don't. But then again they do, and in some places C remains relevant as a much smaller, much less tortured high level language that's also close to the hardware; so you find C-like dialects in GPU compute, Arduino and other similar tech.
So, if C++ is C with classes, then what in the hell warranted C# to be its own language?
There's a couple of answers here. One is you may assert C++ is a superset of C without rousing (many) programmers, another is that C# is more of an IL/CLR language - or perhaps a bastard sibling of Java - and in other words, a "bytecode language". Now that puts it in another ball-park, perhaps even another ball-kim.
What's so special about a "bytecode language"?
Two perspectives here. One is interoperability. Bytecodes are virtual machine code so you compile to bytecode on one computer, and distribute the compiled product across several OSes (win/mac/nix) or architectures (such as x86 or ppc64) (Java's once famed "write once run anywhere"). Another is how much the runtime knows about your program while it is running. In Java or C# you can ask a class what it is. You can create a class and methods at runtime and more generally your program is "self-aware" (via 'reflection'). This flexibility still has a cost ( < performance ).
At runtime C and C++ know almost nothing about the program being run, so there is no "C++ runtime" per se.
Wow. You need a tutor : P ?
-- Anyways. Note some of these properties are hard set, others are not. You cannot run compiled C/C++ across another architecture (or only via emulation of the target processor/architecture) but you could (at least in theory) bake information about classes inside compiled code; in practice compiled languages don't often take this approach - what they do is leverage every opportunity to optimize your code for the target architecture.
Okay, the interoperability one is what I thought.
Thanks for your explanation.
Historically? C originated before OOP became a big enough mainstream thing to warrant major languages being built for OOP.
In modern times? Because it doesn’t need them. A class is just a structure and a group of associated functions. In other words, a struct with a bunch of function pointers in it. In fact, many big C projects do use OOP principles in their design just fine without any formal ‘class’ syntax. See the Linux kernel for a good example, a lot of the driver APIs are built in an OO manner.
It’s important to remember also that OOP is not the panacea that many make it out to be, it brings along plenty of it’s own issues, and should only be used when you either have no other option (because of the language itself not allowing you to do it any other way) or have properly evaluated it against other paradigms (a lot of things I see OOP designs get used for don’t need it at all and would be both faster and more memory efficient as simple procedural code).
I think you just invented C++ 😉
C++ was literally created to be "C with classes", and while it has grown well beyond that today, C++ is still at it's core C, but with classes. Because there's already C++ for developers wanting classes, C today is kept intentionally lightweight for bare-metal programming or ultra high performance code.
Well now they are more like separate languages, but the commission tries to remain backwards compatibility
Yes, but it would just be a different way of writing the same thing.
Wouldn't it be easier to write:
instead of:
?
I strongly recommand this talk of Richard Feldman about history of languages and programming paradigms.
It answers your question (and others), and draws a wider picture of the evolution of concepts that lead to the techosystem we see today.
because if you add classes you'll get C++ 😆
I tried it many times and I don't see the point of OOP / classes. I mean everything you need are functions.
That's not exactly true :) All you need to get a Turing-complete language is just some kind of jump instruction, some way to modify memory, a conditional branching operation, and maybe a handful of operations.
ASM has these. But you'll agree that this is not a very practical way of programming these days. OO is one of many higher level concepts that have been developped to handle complexity. The one you're refering to without naming it is Functional Programming. But "just methods" is a bit harsh, and tends to explosion of complexity. You'll also need some FP concepts such as pattern matching, immutability, variadic functions, monads, or whatever solution FP languages came up with.
I'm an advocate of FP, but I would definitevely not recommand using an OO language that does not have those in an "functions only" style on a large codebase. Trust me. Spaghetti code ahead. I've seen that happen enough :/
(ps: watch the talk in my comment, you might like it :) )
But why go through the effort, even JavaScript had
classadded as a shortcut, why did C never get any update with the sugarcoat treatment?