earlier it was procedural programming, now its OOPs..will there be some other approach to programming. Hard to belive in future we or our future generations will find object oriented redundant and using some other approach. any views/ideas on what kind of approach might be favored over OOPs? [ January 12, 2005: Message edited by: Tanveer Rameez ]
Author of JPhotoBrush Pro (www.jphotobrushpro.com)
Originally posted by Tanveer Rameez: earlier it was procedural programming, now its OOPs..will there be some other approach to programming. Hard to belive in future we or our future generations will find object oriented redundant and using some other approach. any views/ideas on what kind of approach might be favored over OOPs?
[ January 12, 2005: Message edited by: Tanveer Rameez ]
What has getting more and more popular during the last couple of years is component based software. At it's extreem building software will be like building lego. Component based software development has it's roots in the OO world.
I hope, that the "connector" part* of the software will be given a bigger role - atm. you'll only see this in research projects as ArchJava for example.
* As in, software is made of components and connectors.
Component based programming often uses two programming languages together like, a scripting language combined with a low level for the component implementation. VB/C++, Python/C++ or Tcl/C and Jython/Java.
The low level language libraries are often implemented using object oriented technology , The application code of the scripting language does not need to be implemented in object oriented way. Take VB for instants, the developer doesn't need to be create a single object to take advantage of the ActiveX libaries.
I only make light use of object oriention in my application, because it can unnecessary complicate cod and kill reuability. Object Oriented Design/Programming is so bureaucratic take a look at the JAVA IO package for example.
You will create an object in 3d cyberspace and define it. Then you will define its relationships with other objects. You will have VR gloves that you can "physically" make the thing you need. VR hammers, chisels, screw drivers, even VR computers! Won't that be a hoot?
I see aspects as a way to deal with certain limitations in OO design. Namely, how to abstract 'cross-cutting' services out of objects so that, in part, it's easier to present a more coherent, less cohesive interfaces without making a lot of sacrificing.
Likewise, I see containering as a way to make aspects available while also making 'public' the rules for hooking into the container correctly. In general, this means the interface presented to the container-user is less complex and services are made part of the bargain.
Both aspects and containerization, with that mind, are ways to make OO programming more palatable, So much of the design pattern stuff out there, after all, implies lots of little objects, and you need some strategies to manage them and bring them together. Still, looking at all the little parts can numb the mind better than any nightstick.
I think first the industry has to recover from the giant step backwards in programming evolution known as markup languages. For as long as our newest generation of programmers see tagging as dumbed-down programming, we won't be seeing a lot of new ideas that promote the 'next step' anytime soon.
Make visible what, without you, might perhaps never have been seen. - Robert Bresson
In addition to the Aspect-Oriented Programming that was mentioned above (and is gaining recognition), there is also a concept of self-changing code -- it sort of mutates itself in response to changing business requirements.
Even more futuristic is quantum computing, although it applies more to the hardware, not the software. The idea is that the complex computational problems that take days (or even weeks) to solve on the current conventional computers can be solved in no time at all. "No time at all" is meant literally here: think of a classic double-slit experiment where the electorns traverse all possible paths at the same time, yet when you observe it, it appears to have traveled through a particular path. Apply this quantum effect to computing, and what you get is that you have the solution before you even pose the problem. All you need to do is to observe the solution.
I don't see the progression as "procedural" -> "object oriented". The previous big breakthrough prior to object oriented programming was structured programming. Will there be another such breakthrough? Hard to tell. Thus far, object oriented programming has not provided the improvements that structured programming did - unless you think "object oriented" implies garbage collected.
I'm not sure markup "languages" are all bad. Ant is a markup language, and you can do very simple programming in it. I think of it as a very primitive functional - as opposed to procedural - language.
Originally posted by Warren Dew: I don't see the progression as "procedural" -> "object oriented". The previous big breakthrough prior to object oriented programming was structured programming.
Will there be another such breakthrough? Hard to tell. Thus far, object oriented programming has not provided the improvements that structured programming did ...
Perhaps because pre-structured spaghetti-style programming was so hugely bad. Still, I cannot begin to imagine how the capabilities of Swing could be implemented in a non-OO language, or what non-OO APIs with the same capabilities would look like.
Joined: May 15, 2002
For those of you who never visited the OO, Patterns, UML and Refactoring forum whare a regulary preach the evils of OOP