As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I started in High School learning java and python and I guess I just always learned OOP and nothing else my question is What are the other programming paradigms or types of programming languages beside OOP?
"Opposite" isn't really a good way of putting it. What's the "opposite" of Democracy? OOP is a a paradigm -- a way of viewing the problem of programming.
The four main coding paradigms are:
functional (viewing programs as mathematical formulas)
imperative (programs are series of instructions for the computer)
logical (model information and the relationship between that information), and
OOP (Model objects and how it interacts with other data)
http://www.cs.aau.dk/~normark/prog3-03/html/notes/paradigms_themes-paradigm-overview-section.html#paradigms_logic-paradigm-overview_title_1
Logical is the most different by far and you have to jump through a lot of hoops to solve some problems in logical programming. The other three all solve the same problems, but the approaches are different.
Procedural Programming is one of the other forms used.
http://en.wikipedia.org/wiki/Procedural_programming
There is no such thing. OOP is a concept built on top of procedural programming, there is no opposite rather there is a choice of writing in OO or not.
These answers are all wrong ... and that is a VERY good question ... and the answer is .... "AOP" - i.e. an "Algorithmic Oriented Programming" entirely based on the "algorithm" being at the very centre of the concept - in an AOP the "data" or an "object" or "objects"are simply "passed to the algorithm" - i.e. THE ALGORITHM IS ENTIRELY KING (it "knows" what to do with the data) - the data carries around "nothing".
In fact "we" (at Inferix) think OOP is a blind alley!
AOP is a much better model of reality - OOP is fine for "images on screens" and "data processing" but it cannot encapsulate intelligence - because "relationships and dynamics and intelligence" are not at it's core!
So we think that "AI Entities" (coming soon) will use only AOP!
Practically speaking Algol60, Coral66 and Inferix-MTR are examples of AOP languages - Algol60 became Pascal and Ada and the likes - and these just became more and more OOP (e.g. Delphi)!
The start of "typing" of values marked the end of AOP!
However: MTR is still a strictly AOP language (but unfortunately at present it is designed for AI entities to use and not humans).
You could think of an AOP as a language that strictly "prohibits" the typing of data elements and is only concerned with "values" of "signals".
There are several but i would say Functional Programming is the most opposite.
http://en.wikipedia.org/wiki/Functional_programming
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I wrote a simple genetic algorithm to evolve the string "helloworld". I wrote it twice. The first time was written using classes. And the second time was written using just functions where the entire state of the genetic world is passed from one function to the next...to mimic the data flow paradigm. Surprisingly, the code worked well for both the implementations. However, I managed to get it working only after painstakingly removing each and every bug, which was quite a laborious process.
And I asked myself.. there has got to be a better way. Write the code using classes was comparatively difficult than writing the same code using simple functions and I believe writing the same code visually, using something like labview for example would be a lot more easier than writing it only using simple functions.
To that extent, I read about data flow programming and visual programming and quite frankly it seems like it is more natural and intuitive to program in a visual, data oriented manner than in a statement-wise manner, which is what most programming languages enable us to do today. My question is.. if this is the case, why hasn't data flow, visual programming like "labview" become the standard?
I do not believe that data-flow / "Visual Programming" has nearly the performance of well-designed code.
Text-based code can express far more complex and subtle data structures and flows than anything graphical. It gives programmers detailed control over what gets copied, what gets accessed, and precise control over sequences of steps. I have a hard time seeing how data-flow could be that expressive.
Ultimately, data-flow /visual programming can only describe things that are already known. Text-programming (for lack of a better term) actually lets you express more. Programmers can create entirely new data structures and algorithms that simply haven't been represented visually yet.
It is dangerous to use a single problem as the basis for how programming languages should be designed. I'm not sure how the data-flow paradigm would improve GUI framework design, for instance.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Why Objective-C is chosen as language for cocoa or cocoa touch, why not other? What are main usages in Objective-C that are not in other languages.
How I can Convince the interviewer about this.
The main reason is that Cocoa is descended from NeXTStep, which was written in Objective-C back before C++ had the STL (IIRC it didn't even have useful templates back then; I recall g++ having big warnings in its template implementation into the early 90s). Also, I gather Jobs & co. preferred the Smalltalk-like OO of Objective C.
Cocoa is it self implemented in Object-C. By using that language a developer can more easily leverage the features of the hose system. While C/C++ are valid languages ( because of Objective-C background in them ) the interface between C/C++ and Cocoa ( because it's Objective-C ) is harder than if you were to just stick with Objective-C.
See more on this from Apple.
First, I think any language with GC is far more productive than any language without. Especially when programming in the large across many different teams, developers and frameworks, other techniques like reference counting are flawed and lead to code bloat. Many years ago there was a formal study that showed that the theoretical best performance of Generational Garbage Collection was about 4% of cpu usage. The theoretical best using reference counting was just under 10%.
The second thing to look at is how confining the language chosen is and how easy it is to blend with other C / C++ code. Many languages, such as Java, pretty much limit you to a single paradigm. Objective C is set of OO extensions on top of C. It has a great deal of flexibility as a result. In Objective C 2.0 and later, new features such as properties and blocks have also been added.
All the above said there are things I don't like about Objective C. It is more verbose than I like in a programming language and does not provide sufficient capabilities to do much meta-programming. I really am not happy that it still does not have namespaces. I know some of the reasons used to explain this lack but I do not find them at all sufficient. A flat class and method/selector namespace is not excusable in the 21st century.
What I really want is for MacRuby to take off and be implemented very very efficiently. A return of Dylan would also be very greatly appreciated. :)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
When I'm learning a new language, I often program some mathematical functions to get used to the control flow syntax. After that, I like to implement some sorting algorithms to get used to the array/list constructs.
But I don't have a standard exercise for exploring the languages OO features. Does anyone have a stock exercise for this?
A good answer would naturally lend to inheritance, polymorphism, etc., for a programmer already comfortable with these concepts. An ideal answer would be one that could be communicated in a few words, without ambiguity, in the way that "implement mergesort" is completely unambiguous. (As an example, answering "design a game" is so vague as to be useless.)
Any ideas?
EDIT: I have to remark that the results here are somewhat ironic. 10 upvotes and (originally) 5 favorites suggest that this is a question others are interested in. Yet the most upvoted answer is one that says there is no good answer. Oh well. I think I'll look at the textbook below, I've found games useful in the past for OO.
I can't imagine there could be a standard set of exercises that would naturally introduce OO features of a programming language to everybody. A lot of the introductory OO tutorials are full of Animals, Cats, and Dogs which does not really cut it for me at least. Find a problem domain in OO you've struggled with a lot, and try to use that as your set of stock exercises for each language you pick up.
The OO constructs that we are used to thinking in terms of may not make sense in a language. Javascript comes to mind which shakes the entire foundation of how we think about objects in general. That said, you shouldn't adapt to a language but rather adapt the language for your purposes. Over time as your knowledge repository grows and improves with experience, you'll naturally want to implement what you think is best in each programming language that you use regardless of what the language offers.
Good question...
In my opinion the best teacher is just find a simple example of OO features and try to write something alone, creating new examples for Yourself and trying develop simple application in which You can connect all features of OO .
Implementing algorithm like merge sort which don't use OO feature, cause they don't need it is useless. Try real useful programs.
I remember when learning OO i write application with general "Animal" interface with methods and class which inherit it, like "amphibian". it was fanny time ;)
Some fun: implement the Shape/Circle/Ellipse hierarchy without falling into the trap (it can be done very nicely in Java, Scala, etc.).
edit implement it before looking at the proposed solutions in the Wikipedia article :)
I've used Hunt The Wumpus. The original implementation in BASIC was not at all OO, but if you start fresh it lends itself pretty nicely to this.
Here's what I use:
http://homepage.mac.com/s_lott/books/oodesign.html
I've done it enough times that it's "standard" in my opinion.
This might be too specific, but it's what I credit for really getting me to understand OOP personally. For my work I had to write code to extract data from a large variety of different sources. It seemed straightforward to me at the time that I should tackle the problem from the perspective of designing various "DataProvider" classes. What only gradually became clear was how much code I could reuse by breaking the different kinds of providers down into hierarchical categories, like this:
DataProvider
TextDataProvider
HtmlDataProvider
CsvDataProvider
XmlDataProvider
BinaryDataProvider
...and so on. I would suggest that any problem like this--where you need to accomplish a certain kind of task (in my case, extracting data) in a bunch of different ways (e.g., from multiple sources)--will be a great opportunity to delve into OOP and hopefully learn to appreciate how useful it is.
I personally find the best way to learn OO, is to write your own testing framework.
I find a layout of a Test Runner, owning one or more Test Suites, which each have their own Test Cases enough of a starting point, but you can easily grow it from there, and it might even be something you care to use in the future.
Alternatively, if you want something completely throw away, there's always Enterprise FizzBuzz. :)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
My friend was asked the following question: what's the difference between object language and object-oriented language?
It's a little unintelligible question. What does term «object language» correspond to? Does that mean «pure» object-oriented language, like the Wikipedia article says:
Languages called "pure" OO languages, because everything in them is treated consistently as an object, from primitives such as characters and punctuation, all the way up to whole classes, prototypes, blocks, modules, etc. They were designed specifically to facilitate, even enforce, OO methods. Examples: Smalltalk, Eiffel, Ruby, JADE, VB.NET.
Unless the person was interviewed by a philosopher talking about an abstract metalanguage, or an old-school engineer talking about the end result a compiler produces, the question sounds like semantic masturbation by someone who doesn't speak the same language as the rest of the industry.
So in other words, the distinction is whatever the interviewer wants it to be. (Or perhaps the question was misheard). I don't think most developers would think that the terms are connected enough to be worthy of comparison and contrast.
The right response would probably be in the style of a psychoanalyst: What do you think it means? Ask clarifying questions to make sure you understand what the interviewer is asking and assuming. Then leave and don't call the employer back, because you don't want to work there.
The term object does not have an official, widely used or otherwise well-known definition.
The term object language does not have an official, widely used or otherwise well-known definition.
The term object-oriented does have an official definition, but that is usually completely ignored, not widely used nor otherwise well-known.
The term object-oriented language does not have a single official, widely used or otherwise well-known definition, it is usually understood to mean
a language in which object-oriented programming is possible or
a language in which only object-oriented programming is possible or
a language in which object-oriented programming is easy or
a language in which object-oriented programming is easy and non-object-oriented programming is hard or
a language in which everything is an object or
any combination of the above or
something completely different (and note that in any of the above you can substitute arbitrary definitions for "object" and "object-oriented")
In short: the interview question roughly translates to "what's the difference between this thing I'm not going to tell you what it is and that other thing I'm also not going to tell you what it is?"
I'd suspect that the interviewer was looking for a distinction between object-based and object oriented.
This is, for example, using structs in C, with no polymorphism or inheritance.
The difference between the two for C and C++ is highlighted here.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Would like to know what a programmer should know to become a good at Designing particluarly in Java/J2EE technologies.
Firstly Good Design transcends whichever language you choose to use to implement the design. Good software design is about managing complexity to create easy to understand code which is robust and maintainable. Key points are
Work in the highest level of abstraction you can at any time
Encapsulate and hide areas of complexity
Understand what value there is in clear and consistent naming
In my mind Good design is achieved by a combination of understanding good practice and being creative. And in my experience the hardest part of design is in achieving the right functional decomposition of the problem into smaller sub-problems. It is important to understand that the process of achieving this decomposition is almost always an iterative process rather than a methodical top down process. You have to be prepared to modify or throw away your previous design decomposition until you have something which is maintainable.
It is hard to talk about good design and not to mention two things in particular
Object Oriented Proctices
Design Patterns
While some languages are object oriented, some are purely object based and others, like C, were created prior to object based design becoming wide spread, the principles and practices can be applied in any language. Most of the code I write is in C and I try to use object like practices where possible.
Design Patterns present good solutions to common problems and give these solutions names. I have found the study of Design Patterns a key to understanding what good design can achieve.
For beginning to understand design, you should probably first write some toy-projects. Write them, take a step back once in a while and reflect, go back and rewrite. Lather, rinse and repeat.
Making mistakes in design is the best way to understand how you should do better next time. There are of course some methodologies you should be aware of, most important of which patterns and information hiding. Beyond that there are various sources/books for software architecture. For example: Software Architecture in Practice (2nd Edition) (The SEI Series in Software Engineering) by Len Bass, Paul Clements, and Rick Kazman
Try to look closely at where information belongs. Should the interest-rate be a field in Account or AccountType for (a small) example.
Last but not least, try to involve yourself in discussions about design. Debate with your peers, but also pick the brains of more experienced designers/architects.
And stay critical! Although Software Design is more of an exact field than building design with (some) clear pros and cons, taste/preference and rhetoric is still part of the deal.
I would recommend a couple of things:
Read about some design patterns. The original Gang of Four book helps with OO design. If your are writing Enterprise applications I can't recommend Martin Fowlers Enterprise Application Architecture book too much.
Patterns give you the essential words to describe designs both to yourself and to others. Just reading about the different approaches makes you see new possibilities. If you are looking at J2EE, patterns like Inversion of Control are essential.
Obsess about loose coupling
The essentials of good design is preventing tight coupling. Anything that can be used to move your code in to loosely couples layers is going to help your overall design.
Read other people's code. Study some high profile open source code in the your technology area.
Just studying other peoples code quickly gives you a feel for nice looking designs compared to cluttered Big Ball Of Mud approaches.