As a beginner at programming, I have been programming with OO languages for 3 years and I can not really imaging programming in a non OO environment so I have a few questions:
Here is an intersting article about ColdFusion which started as a procedural language and then integrated OO capabilities. The arguments for OO or procedural typically relate to which language you first learned.
Click Here
Having learned procedural, it was really difficult to get my head around OO. Still having problems! Having said that, some languages like php don't always need the robustness of OO in every situation. Depends on the complexity of the site. If you can get away with the odd function of two, well great. However, as sites develop, I often find myself resorting to classes when I didn't think I'd need them. It's just a different way of doing things, appleas and pears (IMO). I think we all know the advantages of OO, but sometimes it can be overkill (again IMO).
- Is there any advantage using procedural than oo?
Advantages of procedural programming mostly boil down to simplicity. For one, a typical procedural program is just a straight-forward sequence of function calls and statements, which, if done well, are very clear and with no hidden behaviors like constructors, stateful function calls, etc... Basically, when a problem is simple, a simple approach is better, naturally. I have seen far too often people construct elaborate OOP class hierarchies to solve trivial problems, in total overkill fashion.
Procedural programming is also simpler in terms of infrastructure, i.e., all the "under the hood" or "ground work" code that the compiler / interpreter has to construct to support the language features. Typical language features for OOP require mechanisms for dynamic dispatching (virtual functions), run-time type identification (to check down-casts or match exceptions, or do run-time reflection), garbage collection, extra indirections, forced pessimizing assumptions (e.g., aliasing), etc... These things cause the run-time performance penalties you pay when using OOP features, and they can also be impossible or very undesirable in certain contexts such as hard real-time systems, embedded systems, kernel code (operating system), etc.. In these contexts, the simplicity of the infrastructure is a big advantage, for several reasons, and therefore, zero-overhead languages are used almost exclusively, like C or C++ (where the OOP overhead is only present if you explicitly use the corresponding OOP features).
Finally, procedural programs are simpler to analyse for correctness. It can be very difficult to formally establish the correctness in software when it uses many polymorphic objects with complex interactions between them, and when there are plenty of hidden side-effects.
- What kind of programmes do you write with procedural languages that do not require objects?
Who said that procedural programming cannot use objects? For some reason, there is a whole lot of people who entertain the insane idea that you can only program in a single programming paradigm at a time. It probably has something to do with languages being labeled as of a particular paradigm, and even sometimes designed to be restricted to a particular paradigm; two other insane ideas.
The truth is, people often write object-oriented code in C, and people often write procedural code in Java, just to name two examples. In reality, of course, most code is a blend of different paradigms, whichever language you use.
Programming paradigms are about how you see a problem, how you think about your code, and how you organize your code. For example, if I see my code as a sequence of specific operations to be done, each with some clear pre- and post-conditions that make the code progress towards accomplishing the overall task, then I am taking a procedural approach to the problem. I might, in the process, find that some of the operations could be better done with objects of some (polymorphic) class, and thus, mixing in some use of OOP techniques into the code. This is an extremely typical situation, in fact, it's my impression that most code that is called "object-oriented" has more procedural elements to it then OOP patterns, and that's not a bad thing, not a bad thing at all.
As far as giving examples of situation where you would use procedural programming without objects, that is kind of hard to do because nearly all code uses "objects" in the broadest sense. If you're mainly coming from a knowledge of "pure" OOP, then what you call "objects" probably means "objects of a polymorphic class". In other domains, the term "object" is more general, and part of virtually all programming paradigms, as meaning just a bundle of data with or without associated functions (member-functions / methods). For example, in C++, an "object" is, technically-speaking, anything that exists at run-time, from a primitive variable to an object of complicated class.
Here is a simple illustration:
// my_code.c
struct Foo {
int value;
};
void foo_init(Foo* pf, int aValue) {
pf->value = aValue;
};
void foo_print(Foo* pf) {
printf("Foo's value is %d\n", pf->value);
};
int main() {
Foo f;
foo_init(&f, 42);
foo_print(&f);
return 0;
};
And compare with this:
// my_code.cpp
class Foo {
public:
int value;
Foo(int aValue) : value(aValue) { };
void print() const {
std::cout << "Foo's value is " << value << std::endl;
};
};
int main() {
Foo f(42);
f.print();
return 0;
};
Besides the fact that the C++ version is more syntactically pleasing than its C counterpart, there is no real difference between those two code snippets. One would definitely call the C code there as being "procedural", and if so, how could one say that the C++ version is "object-oriented"? And vice versa too, of course. The C code is procedural code that uses objects, which is representative of most procedural code out there. When it doesn't use objects (i.e., coherently structured data), we just call it bad code, and unless the problem is extremely trivial, it's unacceptable code.
So, if we restrict the question to "what kind of programs do you write with procedural programming that does not use objects of polymorphic classes?", then the answer is a very large amount of programs. Probably most of the code that exists today qualifies in that category.
For instance, the majority of the code of most operating systems would fit that description, for reasons I already mentioned, and generally only select few peripheral features of operating systems are done in object-oriented style (still in C, of course) such as the file-system modules in the Linux kernel.
Also, a lot of small tools are small enough that any kind of OOP approach would be overkill, e.g., tools like cron, diff, SSH, etc... OOP is only useful for run-time flexibility, and many tools do not require that, just like a hammer does not require moving parts.
Also, a lot of numerical analysis code does not require much OOP design, because the complexity is mostly in the mathematics and the algorithms, not so much in the software architecture, which is where OOP patterns shine.
- What can procedual languages do for us that OO languages cannot?
Well, you should stop using expressions like "procedural languages" and "OO languages", because there are no such things, as I already explained, the programming paradigm resides in the brain of the designer not in the definition of a language's syntax rules.
As far as things that "procedural languages" do that "OO languages" cannot, I can't really say, because there aren't any languages, AFAIK, that could be said to be "OO languages" and that do not allow for procedural programming too.
However, what many so-called "OO languages" cannot do is turn off or optimize away the overhead imposed by their "always on" OOP features, even when those features are not being used. For example, if you implement the above code snippet (foo-printer) in Java, it would, technically, result in one heap-allocation, one dynamically-dispatched call, and one garbage collection pass (but in all fairness, modern Java virtual machines would optimize all that away for this trivial example, but only for such trivial situations, not in general).
There are many arguments along those lines (e.g., cache-optimized memory layouts) that argue against so-called "OO languages" because they tax you for feature whether you use them or not, i.e., when the problem does not require the use of an OOP feature or technique and is performance-critical, you cannot "turn off" the overhead.
The arguments for OO or procedural typically relate to which language you first learned.
Why would that matter? I can objectively see the advantages and application contexts for procedural programming even if I spent all my first several years of programming doing exclusively object-oriented programming in languages that would definitely be classified as such (some Visual Basic, mostly Delphi, and later, C++). But it is true that some narrow-minded people with limited experience tend to dive into subjective arguments about what is "superior", because they are still foolish enough to think that there is one paradigm or one language that is superior to all others in all contexts... a ridiculous idea, leading to ridiculous arguments. The link that you provided is a good example of that, making a ridiculous argument about information hiding in OOP as if it cannot be done in procedural programming (maybe it can't in ColdFusion, but certainly in other "procedural languages"), when, in fact, it has always been part of procedural programming to do information hiding, and as such, it's a ridiculous point on which to contrast procedural and object-oriented programming. In fact, if anything, I often find that typical procedural code (or APIs) tend to do too much information hiding, while a lot of OOP code out there only appears to hide information but expose much more than they should, both due to bad design.
I'm an advocate of multi-paradigm programming. You have to be aware of as many paradigms as possible and be smart enough to select the appropriate mix of approaches for a given problem, that's what software engineering is all about, IMHO. In my opinion, every programmer should be well-versed in at least the following paradigms: procedural, object-oriented, generic, (pure-)functional, and declarative. And one should be able to mix them with ease, because they all have important features.
My quick 2 cents.
I find that OOP is almost a natural extention to procedural programming. In fact, often my completly procedural programs will almost mirror OOP programs (not just me either). Going from one to the other is generally pretty easy. If I'm dealing with something more algorithmic, I generally prefer a more procedural style (mimicking math), and if I'm dealing with something more systematic, it will be closer to an OOP style. Sometimes I'll use a higher level language (python for example) to organize and "glue togeather" everyting in a more OOP style, and write the algorithm in a C API (or sometimes scheme, which is functional).
If you want to explore something new, take a look at functional programming. People often argue that it's the natural generalization of other programming styles (and this property has shown to be very effective in practice). It's going to be closer to mathematical, and you'll find it's quite substantially different then OOP/procedural.
Another interesting one to look at is array-based languages. I would say while functional languages are closer to mathematical, array-based languages are closer to numerical and are a little more applied.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.