It all depends of course. Having said that, the main paradigm today is probably OO. Certainly in web server-programming. This is strange because a server is very much a procedural apparatus. It makes no sense for a server to instantiate his internal wiring for every request and then dispose of it after having sent the response. It makes much more sense to see a server as a signal processor, like the one that is standing in your audio-rack, like the equalizer or amplifier. With all circuits pre-wired (like in procedural), the signal, not the circuit, being the variable. OO is even more problematic when used with relational databases. Ideally you choose the programming paradigm that suits the application metaphor best. So sometimes, for simulations, one would choose OO. Other times, for data transformation, one would choose declarative, like XSLT. Other times, it is 'just' procedural. To be a good programmer, being skilled in all main paradigms is key. Where to start just depends on whatever suits you best at that moment. Otherwise I would argue procedural is probably easiest and because of that a logical starting point.

I vote OOP only because it's the hardest to understand if you're already mentally wired for the others. It's at least the approach I wish I'd learned first. Thanks a lot, Perl.

All three of them.

Programming is closely tied to problem of visualisation.

If you cannot visualise the problem in your head, you most certainly won't be able to solve it. Also if you aren't able to modularise the problem, it is going to be a huge mess.

In both of these cases what really helps is the ability to visualise the problem, and then solve in small chunks/modules.

For a beginner, it is much more easier to visualise problem as real world entities than on how something works.

Example: OOP

class Employee {   // classname
private:
   float salary;         // Data members (variables)
   string name;
   int x, y;           // Other Properties
public:   
   Employee(name, salary){
       this.name = name;
       this.salary = salary;
   }

   string getName(){         // Member functions
       return this.name;
   }
   float getSalary(){
       return this.salary;
   }
   void changeSalary(float newSalary){
       this.salary = newSalary;
   }
}

Usage:

employees = [
     (new Employee("Foo", 10000.0)),
     (new Employee("Bar", 12000.0))
]

for (... employees){          //loop
     emp.changeSalary(emp.getSalary() + 2000)
}

The above example is much simple to understand, we know that there exists an employee whose salary can change, and we have a method to do so. Also, all the information about the employee are part of this object, and when required we can get these informations using some method (eg: getName())

Lets do this in functional programming way. Typically, we will have to store this information in some manner which isn't like an entity. I will do this using array of arrays.

employees = [
    ['Foo', 10000.0],
    ['Bar', 12000.0]
]

To change salary we need to have a method which changes salary of the employee and since there is no construct of an object, we will actually have to iterate over each element of an array.

changed_employees = change_salaries(employees)

Although, not a very good example, what ends up happening here is it is difficult to visualise change_salaries as entity vs what was in the case of OOP (Employee.changeSalary)

Please note, I am not saying that one paradigm is better or worse than the other, only that as a beginner learning an OOP language will push you in right direction much faster than functional or procedural.

There are other aspects to this debate, strengths and weaknesses of various paradigms, but you shouldn't worry about those, as a beginner.

Unless you learn Haskell, procedural programming is the first step. Objects are just abstractions that only make sense when you understand the basic concept of programming. If you go for Haskell, you start from scratch anyway... so it makes no difference.

Okay, there is no one right answer to this. I will try to answer from my own humble experience, and those of others, along with whom I've had been fortunate enough to grow as a programmer.

Don't worry about these paradigms, especially if you are beginning programming, just build things; pick a programming language, and build small trivial programs, like a simple arithmetic calculator, a rock-paper-scissors game; then gradually move on to programs that will make your life a tad easy, probably write a program which will rename the files in a folder, and then keep improving upon it. What happens with this process is you're strengthening your foundations in programming... starting right from the basics; variable declarations, assignments, conditional constructs, looping constructs, recursion; make these foundations so strong that you can build anything upon them.

After a while of doing the above, you will realise that you were programming procedurally all the way along; and it will all be intuitive when you read more about the paradigm; then challenge yourself to write the same programs, the OOP way; it will probably break at a lot of places, but that is okay, invest your time in understanding why the code broke, what is the underlying principle ... and after a while of doing this, it will all be second nature; and then you could go on to investigate other paradigms; say, Functional Programming, by asking many questions along the way; "Why do I need this?", "Okay, so what are pure functions, exactly?", "Why is there a lot of recursion at places where I can have simple loops?"; "Ah! only function level state!"... what I'm trying to say is, it will all eventually make sense.

Choose a book/course/mentor; and then exhaust what it/he/she has to teach you; pick something that not only teaches you a programming language, but one that valuably guides you into "thinking" programming, and enables you to become good enough that you'd be confident to pick up anything else; or build upon the knowledge that you've gained; be it a new programming language, or a new programming paradigm, that you've never heard of.

(If JavaScript is your pick; I recommend 'Eloquent JavaScript", if it's Python, I recommend this Udacity course called "Introduction to Computer Science" ... and I'm sure after a few searches, and few more mentions from the excellent lot here, you will find a lot of excellent resources, for whatever pick you've made.)

Happy Programming! :)

Which pedal is the best pedal to use when learning to drive a car, the clutch, the brakes or the petrol ?