It's an OOP world... is it? ...still?
-
Honestly I love OOP. From the very beginning of my programming career I loved breaking things into small units, reassembling them to bigger objects and then make them do the work they were supposed to do. Over the time I got that "feeling" how the problem I am trying to solve can be splitted and how the object structure should look like (at least in my opinion). So far I was happy, but times are changing, don't they? What are the alternatives (functional programming, etc)? What kind of alternative do you like most and why? Into what direction should I turn my head to maybe fall in love with another paradigm? What's your opinion? I am looking foreward to you replies cheer Andy
When your a hammer everything looks like a nail -- except maybe an egg. Efficient, maintainable code in a language that is not to syntactically complex or vague is a good objective. Sometimes this is OOP and sometimes OOP makes things artificially difficult. I try to pick the language based on the type project, specifics of the design, and capabilities of the team to use it and maintain it in the long run. Functional languages like Haskell may be great for developing compilers and interpreters but probably not for an invoicing application. Javascript is great for a lot of web apps but what about SQL and NOSQL database sections. This is stating the obvious, I guess. I enjoy using different languages, libraries, and frameworks. There is always a best choice for each project. In academia, elegant is important. In non-academia function and form, and utility are often more important.
"Courtesy is the product of a mature, disciplined mind ... ridicule is lack of the same - DPM"
-
When your a hammer everything looks like a nail -- except maybe an egg. Efficient, maintainable code in a language that is not to syntactically complex or vague is a good objective. Sometimes this is OOP and sometimes OOP makes things artificially difficult. I try to pick the language based on the type project, specifics of the design, and capabilities of the team to use it and maintain it in the long run. Functional languages like Haskell may be great for developing compilers and interpreters but probably not for an invoicing application. Javascript is great for a lot of web apps but what about SQL and NOSQL database sections. This is stating the obvious, I guess. I enjoy using different languages, libraries, and frameworks. There is always a best choice for each project. In academia, elegant is important. In non-academia function and form, and utility are often more important.
"Courtesy is the product of a mature, disciplined mind ... ridicule is lack of the same - DPM"
I agree that there is always a best choice for each project. But isn't that a highly personal question? If I have to find the best choice for a project to start I might come up with a different solution than another one who has different preferences/points of view. I read an article a while back (sorry, I can not remeber the source) about the "ego" of software developers and how they sometimes choose a complex solution over a simple one just to satisfy their ego? Personally I can not totally resent that statement. I feel more joy in what I am doing when I can create something interesting than just by doing the job as fast and as cheap as possible. Of course, egos should not make you choose the wrong solution, but don't you somethimes sit back and just feel good about an elegant, more complex solution than a dirty hack? Maybe it's the experience that makes someone choose the right solution over the "personally enjoyable" solution... or time pressure ;)
-
Honestly I love OOP. From the very beginning of my programming career I loved breaking things into small units, reassembling them to bigger objects and then make them do the work they were supposed to do. Over the time I got that "feeling" how the problem I am trying to solve can be splitted and how the object structure should look like (at least in my opinion). So far I was happy, but times are changing, don't they? What are the alternatives (functional programming, etc)? What kind of alternative do you like most and why? Into what direction should I turn my head to maybe fall in love with another paradigm? What's your opinion? I am looking foreward to you replies cheer Andy
hoernchenmeister wrote:
Honestly I love OOP.
I love what works. I use the component model vs. the object model, but not to the exclusion of one over the other.
hoernchenmeister wrote:
So far I was happy, but times are changing, don't they?
No, not really. I still whip out a hex editor to tweek small programs. I use a plethera of assemblers when the need arises. I'm also not afraid to GOTO when it's logical to do so.
hoernchenmeister wrote:
What kind of alternative do you like most and why?
What works is the best alternative, IMHO.
hoernchenmeister wrote:
Into what direction should I turn my head to maybe fall in love with another paradigm?
ALL OF THEM!
hoernchenmeister wrote:
What's your opinion?
About the same as any technophile.
-
OriginalGriff wrote:
Then he went and designed PASCAL, which had no useful concept of data structures and was functional programming all the way through. So, he was talking b*llocks then!
Sorry, you're the one talking b*llocks here - PASCAL is Procedural, not functional. There's a huge difference.
Agreed. And Niklaus Wirth is the man. Look at the Oberon OS and language from 1985! KISS to the max. I think OOP and Functional can co-exist - like in Scala? For me the next paradigm would be "language oriented programming" / "domain specific languages". Levels of re-use (keeping the code to the minimum): Datatype Function OOP (inheritance, dynamic binding, etc) domain specific language
-
Years and years ago, Nicklaus Worth wrote a book: Algorithms + Data Structures = Programs[^] where he set out pretty much the principles that OOP is based on: that you should not separate the data from the processes that act on it. Then he went and designed PASCAL, which had no useful concept of data structures and was functional programming all the way through. So, he was talking b*llocks then! :laugh: Many, many tasks (particularly in a message-based environment) are Object Oriented, and should be treated as such. But when they aren't, functional programming works like a charm! I wouldn't code for Windows in a functional language - it's way too much work. I wouldn't code for embedded software in C# - it's way to much work. I think they will both proceed, side by side, until someone comes up with a new, radical shift in the way we design software. [edit]would. wouldn't. No real difference... - OriginalGriff[/edit]
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
OriginalGriff wrote:
Then he went and designed PASCAL, which had no useful concept of data structures and was functional programming all the way through
Huh? PASCAL definitely supports data structures and is most definitely a proecedural rather than a functional language.
-
Honestly I love OOP. From the very beginning of my programming career I loved breaking things into small units, reassembling them to bigger objects and then make them do the work they were supposed to do. Over the time I got that "feeling" how the problem I am trying to solve can be splitted and how the object structure should look like (at least in my opinion). So far I was happy, but times are changing, don't they? What are the alternatives (functional programming, etc)? What kind of alternative do you like most and why? Into what direction should I turn my head to maybe fall in love with another paradigm? What's your opinion? I am looking foreward to you replies cheer Andy
I do not think that OOP will go away soon. It is usefull because it allows you to model the world around. All programs, that we write are ment to solve real worlds problems. Since the real world is created from objects which have relations and communicate OOP is good tool, because it allows the dev to reflect the real world. This also explains that maybe for real time or other problems OO is not at all useful. regarding functional programming - it can be compatible with the OO approach. FP tries to eliminate the global state, puts accents to concepts such as functional composition, but there is nothing which would make it incompatible with OO, is there? So I think we have to wait, if some future concept will substitute OO, maybe it will, but I think it will not get rid of entities, or objects, or whatever you want to call it...
-
Honestly I love OOP. From the very beginning of my programming career I loved breaking things into small units, reassembling them to bigger objects and then make them do the work they were supposed to do. Over the time I got that "feeling" how the problem I am trying to solve can be splitted and how the object structure should look like (at least in my opinion). So far I was happy, but times are changing, don't they? What are the alternatives (functional programming, etc)? What kind of alternative do you like most and why? Into what direction should I turn my head to maybe fall in love with another paradigm? What's your opinion? I am looking foreward to you replies cheer Andy
Don't think of it as A supplants B supplants C. As our industry grows from its infancy through childhood perhaps into adolescence - remember, it didn't really exist before the '50s - we learn ways of thinking that work. New ways of thinking don't supplant what we've learned before. We still use structured programming in writing functions. We use functions in writing objects. We use objects in design patterns. We use design patterns in Test-Driven Development. Cohesion and coupling are still primary considerations in design. This growth happens when what we're programming on changes. Today this would definitely include cloud computing - using computes as needed on pooled computation resources - and massively parallel programming - 8, 16, 64, 128, more processors. Both of these affect how you think about and manage objects. Both of them affect the algorithms you use. Most importantly, they both force you to think of computation cycles as a pooled resource, like memory or disk space, that your program explicitly asks for as needed, rather than something implicitly woven into the design and taken for granted. So if you want something to sink your teeth into, start there. There are a lot of good ideas out there and some of them will coalesce into the generally accepted approach to computing in the next decade - and yes, the work will continue to involve structured algorithms and functions and objects and patterns and unit tests.
-
I agree that there is always a best choice for each project. But isn't that a highly personal question? If I have to find the best choice for a project to start I might come up with a different solution than another one who has different preferences/points of view. I read an article a while back (sorry, I can not remeber the source) about the "ego" of software developers and how they sometimes choose a complex solution over a simple one just to satisfy their ego? Personally I can not totally resent that statement. I feel more joy in what I am doing when I can create something interesting than just by doing the job as fast and as cheap as possible. Of course, egos should not make you choose the wrong solution, but don't you somethimes sit back and just feel good about an elegant, more complex solution than a dirty hack? Maybe it's the experience that makes someone choose the right solution over the "personally enjoyable" solution... or time pressure ;)
I see your point. If this is a Team effort maybe the lowest common denominator rules. If it is a smaller or single developer project then I think your point is stronger. For example, I have tried a few Perl Golf challenges over the years, and written some reasonably powerful scripts that would take a lot more code in other languages. Perl, IMO, is a great language but not for everyone or every type of project. Unfortunately its prominence peaked several years ago. C# can be very rewarding in its own way. Some apps can be created very quickly after you get into the "rest of the story" in its capabilities. Probably a medium learning curve by today's standards. Nose to the grindstone can be a bit boring sometimes. Especially for creative minds like developers.
"Courtesy is the product of a mature, disciplined mind ... ridicule is lack of the same - DPM"
-
Agreed. And Niklaus Wirth is the man. Look at the Oberon OS and language from 1985! KISS to the max. I think OOP and Functional can co-exist - like in Scala? For me the next paradigm would be "language oriented programming" / "domain specific languages". Levels of re-use (keeping the code to the minimum): Datatype Function OOP (inheritance, dynamic binding, etc) domain specific language
I'd really like to see influences of meta-programming (MetaLanguages) spread too, but don't see much evidence so far.
-
It was in a first day explain the concepts type section of the course, nothing to do with Java as such. He was just a really good teacher. Lots of people know stuff, plenty of them might even understand it, but getting others to understand it is not something that many do well.
Every man can tell how many goats or sheep he possesses, but not how many friends.
OK, I agree the principles of OOP are fairly independent of language. Unfortunately, languages which offer only partial support are open to abuse of such techniques, which end up tarring the technique with the same brush as the flawed language. (ps. Sorry for that sentence)
-
Slingshot II wrote:
When I started programming C++ I got very confused as it used a whole new set of jargon and those in the know seemed to enjoyed showing off their knowledge by ensuing no one else could understand what on earth they were talking about.
Here here! The best advise I was given was to learn how to program in OOP, in terms of what objects were and how they interacted, and not try and understand how the OS/framework handled things - this got me going then understanding how the OS/framework handles things was the cherry on the icing...
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
I seem to remember a quote by Alan Kay: "C++ was definitely not what I had in mind when I coined the phrase Object-Oriented Programming".
-
Tell when we will keep writing code to build applications! I think new technologies will appear in the Applications Builders field that will allow the most of programmers to build complex applications through wizards without the need for coding. Someday the software industry will reach to the maturity point where programming language will be just to describe the required business roles. And let the programmer focus on what he need rather than How to do it.
-- Hasan Al-Halabi Chief Operation Officer "COO" What's Next! for Business Solutions Queen Rania Str. Building 313, 4th Floor, Office 409 P.O.Box: 143882 Amman 11814, Jordan Mob: 962 7 97958819 Tel: 962 6 5334478 hasanhalabi@whats-nxt.com http://www.whats-nxt.com
Don't hold your breath, I remember that was a common belief with a number of 4GL and app-builders in the 1980's.
-
Honestly I love OOP. From the very beginning of my programming career I loved breaking things into small units, reassembling them to bigger objects and then make them do the work they were supposed to do. Over the time I got that "feeling" how the problem I am trying to solve can be splitted and how the object structure should look like (at least in my opinion). So far I was happy, but times are changing, don't they? What are the alternatives (functional programming, etc)? What kind of alternative do you like most and why? Into what direction should I turn my head to maybe fall in love with another paradigm? What's your opinion? I am looking foreward to you replies cheer Andy
OOP has been found to be a complete failure in commercial IT organizations. This the result of an in-depth study a number of years ago that I wish I still had access to. OOP is always touted but rarely used properly except in those organizations that have a good understanding in how to implement technological solutions, which are rather few in the United States. Nonetheless, it still remains the best tool to compartmentalize and organize a well defined application. Unfortunately, there are no alternatives... Anything new today is simply a new whim or fad not worth wasting much time over...
Steve Naidamast Black Falcon Software, Inc. blackfalconsoftware@ix.netcom.com
-
Functional programming made some sort of a comeback recently, but IMO, OOPS still runs strong!
Too much of heaven can bring you underground Heaven can always turn around Too much of heaven, our life is all hell bound Heaven, the kill that makes no sound
Abhinav S wrote:
Functional programming made some sort of a comeback recently, but IMO, OOPS still runs strong!
Get F# installed into an instance of Visual Studio and see how both can be used. Though I have to be honest, my graduate education in C.S. gave me a better feel for how objects, when treated as values or as aggregations of values (and a method call that returns no value still affects some value, and that value changed as a side-effect becomes part of the list of values which a functional paradigm would see when looking at an object.
-
Honestly I love OOP. From the very beginning of my programming career I loved breaking things into small units, reassembling them to bigger objects and then make them do the work they were supposed to do. Over the time I got that "feeling" how the problem I am trying to solve can be splitted and how the object structure should look like (at least in my opinion). So far I was happy, but times are changing, don't they? What are the alternatives (functional programming, etc)? What kind of alternative do you like most and why? Into what direction should I turn my head to maybe fall in love with another paradigm? What's your opinion? I am looking foreward to you replies cheer Andy
I don't think there's a better alternative to OOP so far. OOP feels so natural, maybe it's the definitive answer for our current reality. If you think about it, you'll realize that almost everything can be related to OO. The very chair you're sitting in, there are several instances of it which are made of smaller objects assembled together. Sometimes they brake and make you feel an exception on your ass. Some chairs have implement different interfaces, but all implement the ISittable interface. For chairs that implement IMovable interface, we also often see it implementing the LazyAss abstract class. And the chair would violate the single responsibility principle if it was used for something else other than sitting. I mean, OOP just makes sense... Edit: Of course OOP is not best paradigm for all situations. Some situations require different approaches the same way quantum mechanics are handled in a different way of classic physics.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
-
Honestly I love OOP. From the very beginning of my programming career I loved breaking things into small units, reassembling them to bigger objects and then make them do the work they were supposed to do. Over the time I got that "feeling" how the problem I am trying to solve can be splitted and how the object structure should look like (at least in my opinion). So far I was happy, but times are changing, don't they? What are the alternatives (functional programming, etc)? What kind of alternative do you like most and why? Into what direction should I turn my head to maybe fall in love with another paradigm? What's your opinion? I am looking foreward to you replies cheer Andy
Take a look at this: http://www.schloerconsulting.com/quantum-computer-q-lisp-programming-language[^] And this: http://en.wikipedia.org/wiki/Quantum_programming[^] Do you know why Functional programming is the first choice for the next generation of computers? The answer is simple: because it's declarative and it's all about PROBABILITY (quantum computing is about probability), and functional programming is too good for calculate probability: http://www.schloerconsulting.com/ibm-speech-schloer-slovenia[^] When hardware changes too much like that, C, C++ or whatever language stay close to the machine will die. All are now moving to declarative languages. Finally, you may want to contact the author of this blog: http://axisofeval.blogspot.com/2011/01/why-lisp-is-big-hack-and-haskell-is.html[^] He may have loads of information for you.
Hey! Yo!
-
Honestly I love OOP. From the very beginning of my programming career I loved breaking things into small units, reassembling them to bigger objects and then make them do the work they were supposed to do. Over the time I got that "feeling" how the problem I am trying to solve can be splitted and how the object structure should look like (at least in my opinion). So far I was happy, but times are changing, don't they? What are the alternatives (functional programming, etc)? What kind of alternative do you like most and why? Into what direction should I turn my head to maybe fall in love with another paradigm? What's your opinion? I am looking foreward to you replies cheer Andy
Wow, that's almost my sig right there in the title :D Although my sig isn't necessarily about programming...
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
hoernchenmeister wrote:
Into what direction should I turn my head to maybe fall in love with another paradigm?
My advice is to not fall in love with any paradigm - just use whatever is best for the problem you are trying to solve. I was trying to make everything pure OOP when I was young and silly, but then I learned it didn't make much sense. Nobody even agrees what "pure OOP" is. If you need a class hierarchy, go and make one; if a problem is better solved with a simple function, make one and don't feel guilty about it. There is even a buzzword for the approach I suggest: Multiparadigm Programming[^]
Don't just write as function - use a static class...
-
Functional programming made some sort of a comeback recently, but IMO, OOPS still runs strong!
Too much of heaven can bring you underground Heaven can always turn around Too much of heaven, our life is all hell bound Heaven, the kill that makes no sound
Functional programming might someday be interesting, but today we don't know how to compile functional programs efficiently. OOP is the way to go for the next 5-10 years unless some academic gets off their lazy butt and brings it to functional programming. Oops, did those words come out of me?
-
Honestly I love OOP. From the very beginning of my programming career I loved breaking things into small units, reassembling them to bigger objects and then make them do the work they were supposed to do. Over the time I got that "feeling" how the problem I am trying to solve can be splitted and how the object structure should look like (at least in my opinion). So far I was happy, but times are changing, don't they? What are the alternatives (functional programming, etc)? What kind of alternative do you like most and why? Into what direction should I turn my head to maybe fall in love with another paradigm? What's your opinion? I am looking foreward to you replies cheer Andy
hoernchenmeister wrote:
What are the alternatives (functional programming, etc)?
Functional programming isn't new. Technology of any sort which people find beneficial will rapidly evolve to the norm. Technology that is not beneficial will be discarded or relegated to niches. This will happen regardless of how it is packaged (re-packaged) or promoted. Examples of successes are OO, relational databases and cell phones. Examples of failures are web only computers, object oriented databases and Java J2EE Entity objects. One will fail at attempting to predict future successes (and if not find a avocation where you can make real money predicting the future) and doesn't matter much because specializing even in something that will someday rule the world means that until that time comes your skill set will not meet the needs of most businesses because they will be using the norm. And functional programming has been around long enough that I seriously doubt it will make any inroads except that one must deal with maintaining code created by those that rationalize it at the time as a good choice.
