It's an OOP world... is it? ...still?
-
OriginalGriff wrote:
I would code for embedded software in C# - it's way to much work.
You must be a masochist ;P
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
:-O
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
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[^]
Nemanja Trifunovic wrote:
There is even a buzzword for the approach I suggest
The acronym: JGTFJD = Just Get The F**king Job Done.
Software Zen:
delete this; -
I really think OOP is becoming obsolete in many ways. There probably will not be some grand, obvious transition away from it, though. To some extent "OOP" has always meant whatever people have wanted it to mean, so people who really like that term will continue using it regardless. The crux of my obsolescence argument is that OOP encourages us to identify little bits of state, which is exactly what the developer should avoid in many concurrent applications. The way I managed concurrency in my article Scalable Processor Arrays for Cybernetic Control[^] is an example of how FP works better in a concurrent application (even a very low-level one). My approach in that article is fairly pure FP. (Take a look at the "Functional Programming" and "Concurrency" sections in particular.) If I had started out with the notion of identifying little bundles of state, then I would have had to manage concurrent access to these (or artificially limit access to them). I'm not sure I would ever have finished this work under such a design. I might have had to introduce locks / critical sections, which is something that would negatively impact other aspects of my design. More likely, I would simply have found OOP to be an unwelcome architectural burden. This was not the case for FP; as shown in the article, FP is really key to the ways in which I made my code work. OOP did work well for the desktop applications of, oh, 1995-2005. That is, OOP is very well-suited to GUI applications with limited parallelism, in my estimation at least.
-
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. 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.
-
IMHO OOP was always a bit to oversold. It can provide you good solutions in many cases but not everything works well with just OO. The use of singleton seems like a contra indication for the need of OO. What I think will happen is that the bothe Java and .NET will embrace functional programming and "design patterns" will emerge that use functional programming together with an OO hirarchy. The dynamic languages (e.g Python and Perl) already have this mix.
Indeed, and the use of Singleton is often considered an anti-pattern nowadays. They make unit-testing harder and introduce global state into your app - both considered bad. Wrapping a global in an object does not make it less global.
-
I don't think most people understand what OO really is, and how to do it properly. I certainly didn't until I went on a Java course a couple of years ago and the tutor explained it. Made me realise I had been missing the point a number of times in my understanding up until then. Was far more use than any of the actual Java stuff was. Of course that just could be me being simple and coming from a none OO background, but I think that for many programmers OO is good intentions without proper understanding or application.
Every man can tell how many goats or sheep he possesses, but not how many friends.
Strange, as I always think of Java, C# etc. as heavily flawed OO languages. To really grasp OO, I'd still recommend looking at Smalltalk - once you get used to the odd syntax there's some really powerful ideas that have rarely been matched since. This takes OO so far that there's really no old-style procedural "statements" - even if-blocks and loops are achieved by sending messages. Once you learn OO in that environment, you're really doing OO.
-
Strange, as I always think of Java, C# etc. as heavily flawed OO languages. To really grasp OO, I'd still recommend looking at Smalltalk - once you get used to the odd syntax there's some really powerful ideas that have rarely been matched since. This takes OO so far that there's really no old-style procedural "statements" - even if-blocks and loops are achieved by sending messages. Once you learn OO in that environment, you're really doing OO.
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.
-
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
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
-
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[^]
Nemanja Trifunovic wrote:
My advice is to not fall in love with any paradigm - just use whatever is best for the problem you are trying to solve.
A software architect's answer if ever I saw one.
Nemanja Trifunovic wrote:
Nobody even agrees what "pure OOP" is.
This made me laugh. I'm afraid to say OOP in case the pedantic OOP-nazis correct me. So I "structure" my code in to logical components intead. :-D
-
hoernchenmeister wrote:
What's your opinion?
Separating programming into declarative, imperative (OO is ok for this), function (not an OO tool), and [shameless plug] relational meta-modeling (see articles) [/shameless plug]. For most purposes, OO is nothing more than a glorified container. In limited cases, it's useful for extending functionality. Marc
My Blog
An Agile walk on the wild side with Relationship Oriented ProgrammingSounds interesting, I gonna take the walk on the wildside this afternoon ;)
-
The thing about OOP is it is natural for us humans to think in such a matter. Until the systems program themselves OOP is here to stay. Sure they will be other paradigms, but they will just meld together. For example, a system may use SOA. But if a programmer builds up a service with out using OOP principles it is likely to fail or become bloated. Or take a look at MVC/MVP which lead to MVVM. Strict MVVM may not be followed everywhere, but no programmer nor programming manager will question the reasoning of it (Seperation of Concerns), just as no one would question the reasoning of using OOP.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
Collin Jasnoch wrote:
Or take a look at MVC/MVP which lead to MVVM
While I like and use an implementation of MVP there is a flaw I can't reconcile when developing ajax web apps. That is much of what should be presenter code ends up as script which MUST live in the website (view). With the web services you can still use a presenter. But with script heavy webapps it feels like it negates the pattern.
-
Somewhat, but most classic Lisp dialects are not really "functional". Scheme is, but I've never heard it being used outside of academia. Clojure is probably the most used functional Lisp today.
Nemanja Trifunovic wrote:
I've never heard it being used outside of academia
http://www.siscog.pt/clients.htm[^] This company works solely with Lisp and it has deployed systems managing railway schedules of some of the most complex railway systems in the world like London Underground. :)
-
Nemanja Trifunovic wrote:
I've never heard it being used outside of academia
http://www.siscog.pt/clients.htm[^] This company works solely with Lisp and it has deployed systems managing railway schedules of some of the most complex railway systems in the world like London Underground. :)
That makes me feel old. My first full-time job was writing railway scheduling software for London Transport, (all done in-house) and we used Fortran. The more "commercial" departments that I moved to after that (accounting, advertising, and then bus garage stores management) were all COBOL. A little earlier I'd had a summer job internship at British Rail, and again there we were using Fortran for train path scheduling. How dare they chuck out my Fortran masterpieces!
-
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.
