Related
There are lots of different programming languages in 4 different paradigms:
Object-Oriented
Functional
Logical
Procedural
I could write a program in all programming paradigms e.g a fraction that I could write it using classes in OOP and also I could write it using functions in a functional programming language. So why do we need diferent proglangs and paradigms?
According the the master Hal Abelson almost every programming language is built upon three things:
Primitive elements
Means of combination
Means of abstraction
I write almost since some esoteric languages, like BrainFuck, doesn't have means of abstraction.
So what do one paradigm offer that another doesn't? Well a different solution to these 3 and perhaps that has a more suitable expressiveness for the certain tasks. I won't go into specifics since it becomes very opinion based so I suggest you try learning to program in the different paradigms and find out for yourself.
Now procedural is usually what you have at the hardware level no matter what language you are programming in so it is the real thing while all the others are more abstract.
Programming paradigms exists for the benefit of programmers themselves. They all represent different attempts at creating a common platform of abstraction that are as beneficial as possible when starting to solve arbitrary problems. Turing completeness clearly states that any program can basically be written in any programming language that satisfies a certain basic set of rules. Therefore it makes little difference once the program is running what paradigm it is written in. The important part is that there is a person or a group behind it that can maintain or enhance it well (and then again we are back at the persons writing the program).
I know that dynamic programming refers to an approach where we tend to break down a complex problem into smaller parts. In other words, it's a divide-and-conquer paradigm. Object-oriented programming also uses the concept of classes and modules, and therefore follows the separation of concerns (SoC) principle. Can we therefore say that OO is an example of dynamic programming?
Note: Dynamic here doesn't mean dynamic typing or dynamic scripting language. It refers to the general approach.
Dynamic programming is an algorithm designing approach.
Object Oriented programming is more like a code organising methodology.
Comparing them is like comparing kilometre with kilogram.
(And Linear programming is also a totally different thing. It is for optimizing complex linear equations. It is more mathematics than programming. And Integer programming is a special case of it.)
As far as I can infer from the first few paragraphs of the Wikipedia article, dynamic programming is about identifying subproblems that were already solved to reduce the run time, which of course requires splitting a problem into smaller ones, but the point is that this "happens at runtime": you're not looking for problems that can be solved by the same approach, you're looking for equivalent problems that have the same solution.
OOP, or other programming paradigms are about recognizing problems that can be solved in the same manner, with the same algorithms. Dynamic programming is not a paradigm, it does not tell you how to structure your program. It tells you how an algorithm can be specified so that it can take advantage of solutions of subproblems.
This is sort of a "best language" question, but hopefully with enough of a twist to make it worthwhile.
As someone who only uses C and C#, I'm curious to learn a dynamic language to expand my knowledge. I don't know which to choose.
The thing is that my motivation isn't necessarily to create any "real world" projects, or projects that integrate with other systems, but rather just to learn.
With that said, for someone only familiar languages such as those I mentioned, and possibly ignoring obscurity and lack of support..
Which dynamic language would be the biggest departure?
Which would introduce the most novel concepts?
Which is the exemplar of dynamic languages?
I would suggest learning IronPython. As a language it will still be a significant departure for you, but you'll be able to use everything in the .NET framework that you're familiar with. (I usually think it's a good idea to try to vary just one aspect of development radically at a time... work your way through the different aspects one at a time, and you'll always be comfortable with part of what you're doing, which will help you learn the new part more quickly, IMO.)
Also, with C# 4 you'll be able to call into IronPython from your C# code, including using its dynamic features that way.
The functional languages (LISP, Scheme, etc.) are always worth checking out. They may be some of the bigger departures.
JavaScript is a great stepping stone to go from the C arena to the functional arena. From there you can mess around with JQuery, which, although not a language, forces you to do things in non procedural ways.
Another often overlooked language is SQL. It's obviously a niche language, and as Josh points out, not really 'dynamic', but acquiring a deep understanding of they way set based languages work can really progress a coder.
Careful, if you 'Learn' to much you may end up frustrated with the older languages.
Which dynamic language would be the biggest departure?
Which would introduce the most novel concepts?
I guess that would include Scheme, Erlang and Oz
Which is the exemplar of dynamic languages?
I'd say Ruby and Python
I would suggest any Lisp dialect or Smalltalk. These are dynamic and had heavy influence on the design of other, more mainstream languages.
They also include interesting concepts that are not found in other languages.
Another interesting dynamic language to have a look at is Lua.
It is hard to say, it is definitely a matter of personal taste in a lot of ways. I like learning Python but I am sure that you could learn just as many good things from Ruby about a dynamically typed language.
If you are used to C and C# then any dynamically typed language is going to be a departure. So I say you should use Python because that is what I like, and hopefully you will like it too. If you start using it and you hate it then try something else (like Ruby, Perl, PHP, etc.).
I would say that Lisp fits most, if not all, of your criteria. It's definitely a big departure from C/C++ and C#. It has got alot of novel concepts, and many would argue that it's hard to find a more dynamic language.
Barring Lisp, I myself would go for Ruby.
I'm going to have to vote for Common Lisp here. It is a highly dynamic language that can be adapted to just about anything. You get not only functional programming, but also OO, and even procedural if you so desire. And macros in Lisp are very interesting to study, since to my knowledge no other language has its equivalent.
Plus, developing in a functional style tends to help development in other languages as well. For example, I've noticed that I do OO primarily with immutable objects, thanks to concepts influenced by Lisp and Scheme. And with this, I've noticed an improvement in the stability and maintainability of my OO apps. Just my two cents.
I've been a C++ and C# developer for a long time, and recently started experimenting and learning other languages. I played with Ruby for little while and like it, but it wasn't what I wanted.
I ended up choosing Erlang. After reading about Erlang, I've decided that I really wanted to learn it. I'm not learning Erlang with any hopes of getting a job writing Erlang code. I'm learning Erlang only to become a better developer.
I really do like this language so far. It's only been about a month, and the syntax still gets me sometimes, but I can really see the power of the pattern matching and get excited to write it again. I struggled with the concept of everything being non-mutable at first. But this was mostly because I've "grown up" on C# and C++. C# is a great language and has some amazing tools, but you really have fun with some other languages, particularly something like Erlang. Just don't expect to land a job as a full time Erlang developer. (At least not yet).
For anyone curious, my hobby project is multiple player iPhone app connecting to an Erlang server. For a Windows developer, this has been a major change. But it has renewed my passion for programming, which really was my goal.
If you really want to go crazy but want things to at least be slightly familiar (I know that sounds like a contradiction but it's true), look at F#. It's a type-inferred language but it supports a lot of dynamic type properties. It's a functional language built on top of the CLR so you get full use of the .Net object system which is cool. Because it's a functional language, there are enough novel concepts to really work your brain.
If you really want to go for "biggest departure", Clojure might be of interest. It's a Lisp dialect built on the JVM. It's getting some pretty serious attention both in the Java and Lisp world. It might suit your purposes.
I'm just getting a bit confused about all the language types out there. What's the difference - if there is one - between the high level / low level languages distinction compared to the object-oriented / procedural distinction? A lot of the analogies seem similar.
The high/low level distinction is more about abstraction than paradigm. Typically, the "lower" you are, the more you have to know about the machine you're running on - its memory, file system, and even processor instruction set.
A high-level language puts a layer of abstraction between you and the machine. It handles the gory details. This is both good and bad. Abstraction takes away some worry but also takes away control.
A high-level language can be procedural, object oriented, functional, etc...
Lower-level languages may not provide concepts like object orientation, because object orientation is an abstraction.
High level/low level refers to the perceived 'closeness' of the language to assembler and machine code (assembler is low-level, C is seen as lower level than C++ or Java, etc).
OO and procedural programming are language facilities provided to support a certain way of designing programs (called programming paradigms). They have nothing to do with if the language is high or low level beyond the fact that an OO language tends to not be low level as assembler doesn't know about objects and classes. There are a lot of other paradigms out there as well, such as functional programming.
not really.
c++ for example is object oriented and it is fairly low level.
"High level" and "low level" are somewhat vague terms that people can disagree about. You can take a look at the amount of abstraction a programming language provides by how much code you have to write to accomplish a particular task, then call the languages which need less code higher level. Of course, then you need a way to measure code size.
There isn't necessarily any causation across these two axes ("paradigm" and "level"), but I think the correlation is that logic and functional languages tend to be highest level, followed shortly by object-oriented languages, with procedural languages typically lower-level.
And not part of the question, but I also think that correlationally, dynamically-typed languages tend to be higher-level than statically-typed ones.
I think it might be an interesting visualization for someone to do a three-dimensional scatter plot of programming languages across the three axes: paradigm (logic/functional/oo/procedural) typing (static/dynamic) and level (see e.g. 'Code Complete' for various metrics on measuring level) .
I think a good analogy to make here is this.
Languages which are object oriented do tend to be higher level than purely functional ones. Look at c++ and c. Yeah c++ is still pretty low level, as mentioned by docesam, but c++ is still higher level than it's purely functional older brother, c.
No, its not quite that simple always, as object orientation isn't the only thing that makes a language high-level, but its definitely an indicator as object orientation means more abstraction over real raw machine instructions.
But object orientation isn't enough to determine which language is the highest level.
I'd look at the following things:
Does the language have static or dynamic typing? (Javascript & Python vs Java and c++)
object oriented or not? (c vs c++)
pure text macros or templates? (c vs c++)
Dynamic Binding vs static binding (again Javascript & Python vs Java & c++)
Does the language support named functions or do you have to use line jumps?
Does the language allow for things like comments?
many more
I like to say that - it all boils down to the machine instruction set. So, regardless of how high-level something is represented, it will still boil down to the machine instructions. So, high-level languages are abstractions of ideas, while low-level ones twiddle closer to the hardware.
The analogies are similar because it all boils down to one thing - machine code!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
What are the differences between these programming paradigms, and are they better suited to particular problems or do any use-cases favour one over the others?
Architecture examples appreciated!
All of them are good in their own ways - They're simply different approaches to the same problems.
In a purely procedural style, data tends to be highly decoupled from the functions that operate on it.
In an object oriented style, data tends to carry with it a collection of functions.
In a functional style, data and functions tend toward having more in common with each other (as in Lisp and Scheme) while offering more flexibility in terms of how functions are actually used. Algorithms tend also to be defined in terms of recursion and composition rather than loops and iteration.
Of course, the language itself only influences which style is preferred. Even in a pure-functional language like Haskell, you can write in a procedural style (though that is highly discouraged), and even in a procedural language like C, you can program in an object-oriented style (such as in the GTK+ and EFL APIs).
To be clear, the "advantage" of each paradigm is simply in the modeling of your algorithms and data structures. If, for example, your algorithm involves lists and trees, a functional algorithm may be the most sensible. Or, if, for example, your data is highly structured, it may make more sense to compose it as objects if that is the native paradigm of your language - or, it could just as easily be written as a functional abstraction of monads, which is the native paradigm of languages like Haskell or ML.
The choice of which you use is simply what makes more sense for your project and the abstractions your language supports.
I think the available libraries, tools, examples, and communities completely trumps the paradigm these days. For example, ML (or whatever) might be the ultimate all-purpose programming language but if you can't get any good libraries for what you are doing you're screwed.
For example, if you're making a video game, there are more good code examples and SDKs in C++, so you're probably better off with that. For a small web application, there are some great Python, PHP, and Ruby frameworks that'll get you off and running very quickly. Java is a great choice for larger projects because of the compile-time checking and enterprise libraries and platforms.
It used to be the case that the standard libraries for different languages were pretty small and easily replicated - C, C++, Assembler, ML, LISP, etc.. came with the basics, but tended to chicken out when it came to standardizing on things like network communications, encryption, graphics, data file formats (including XML), even basic data structures like balanced trees and hashtables were left out!
Modern languages like Python, PHP, Ruby, and Java now come with a far more decent standard library and have many good third party libraries you can easily use, thanks in great part to their adoption of namespaces to keep libraries from colliding with one another, and garbage collection to standardize the memory management schemes of the libraries.
These paradigms don't have to be mutually exclusive. If you look at python, it supports functions and classes, but at the same time, everything is an object, including functions. You can mix and match functional/oop/procedural style all in one piece of code.
What I mean is, in functional languages (at least in Haskell, the only one I studied) there are no statements! functions are only allowed one expression inside them!! BUT, functions are first-class citizens, you can pass them around as parameters, along with a bunch of other abilities. They can do powerful things with few lines of code.
While in a procedural language like C, the only way you can pass functions around is by using function pointers, and that alone doesn't enable many powerful tasks.
In python, a function is a first-class citizen, but it can contain arbitrary number of statements. So you can have a function that contains procedural code, but you can pass it around just like functional languages.
Same goes for OOP. A language like Java doesn't allow you to write procedures/functions outside of a class. The only way to pass a function around is to wrap it in an object that implements that function, and then pass that object around.
In Python, you don't have this restriction.
For GUI I'd say that the Object-Oriented Paradigma is very well suited. The Window is an Object, the Textboxes are Objects, and the Okay-Button is one too. On the other Hand stuff like String Processing can be done with much less overhead and therefore more straightforward with simple procedural paradigma.
I don't think it is a question of the language neither. You can write functional, procedural or object-oriented in almost any popular language, although it might be some additional effort in some.
In order to answer your question, we need two elements:
Understanding of the characteristics of different architecture styles/patterns.
Understanding of the characteristics of different programming paradigms.
A list of software architecture styles/pattern is shown on the software architecture article on Wikipeida. And you can research on them easily on the web.
In short and general, Procedural is good for a model that follows a procedure, OOP is good for design, and Functional is good for high level programming.
I think you should try reading the history on each paradigm and see why people create it and you can understand them easily.
After understanding them both, you can link the items of architecture styles/patterns to programming paradigms.
I think that they are often not "versus", but you can combine them. I also think that oftentimes, the words you mention are just buzzwords. There are few people who actually know what "object-oriented" means, even if they are the fiercest evangelists of it.
One of my friends is writing a graphics app using NVIDIA CUDA. Application fits in very nicely with OOP paradigm and the problem can be decomposed into modules neatly. However, to use CUDA you need to use C, which doesn't support inheritance. Therefore, you need to be clever.
a) You devise a clever system which will emulate inheritance to a certain extent. It can be done!
i) You can use a hook system, which expects every child C of parent P to have a certain override for function F. You can make children register their overrides, which will be stored and called when required.
ii) You can use struct memory alignment feature to cast children into parents.
This can be neat but it's not easy to come up with future-proof, reliable solution. You will spend lots of time designing the system and there is no guarantee that you won't run into problems half-way through the project. Implementing multiple inheritance is even harder, if not almost impossible.
b) You can use consistent naming policy and use divide and conquer approach to create a program. It won't have any inheritance but because your functions are small, easy-to-understand and consistently formatted you don't need it. The amount of code you need to write goes up, it's very hard to stay focused and not succumb to easy solutions (hacks). However, this ninja way of coding is the C way of coding. Staying in balance between low-level freedom and writing good code. Good way to achieve this is to write prototypes using a functional language. For example, Haskell is extremely good for prototyping algorithms.
I tend towards approach b. I wrote a possible solution using approach a, and I will be honest, it felt very unnatural using that code.