I believe that learning procedural programming should be prior to learning object oriented, because for a good informatics engineer and a programmer in general, it is important to develop a good analytic way of thinking and salving problems on a more basic, or should I say, low level scale instead of using a high abstraction approach.

In the end, even in object oriented programming, methods are nothing other than procedures, so if you teach someone object oriented programming at first, they will, of course, know how to efficiently and optimally design and decompose a system into smaller functional parts, i.e. object classes and to identify properties, methods and interfaces, but when it comes down to actually making all that work, they will have to write code in a procedural way at some point.

I do not think that learning different programming languages for each approach is needed, although it couldn't hurt. One way do to it could be teaching procedural programming in C/C++ and then introducing abstraction and explaining its benefits by teaching OO C++. Also, both can be done in Java, but there isn't much you can do in Java that doesn't involve objects. Even printing on console output and getting input data is through objects and their methods, so the choice regarding programming language is a whole different topic and question, but my answer certainly is to teach procedural prior to introducing object oriented programming.

I learned procedural approach first, and then, OO, but with just 4 months of difference.

I think that maybe you have to learn procedural approach in the beginning. The reason being that despite the OO abstractions and organization, you end up programming the "important" stuff in a procedural way. OO programming rules in terms of organization, design patterns and having a "correct" and organized mind but the low level programming is always procedural.

But I do not think there should be a great time-leap between the 2 approaches.

I believe that learning procedural programming should be prior to learning object oriented, because for a good informatics engineer and a programmer in general, it is important to develop a good analytic way of thinking and salving problems on a more basic, or should I say, low level scale instead of using a high abstraction approach.

In the end, even in object oriented programming, methods are nothing other than procedures, so if you teach someone object oriented programming at first, they will, of course, know how to efficiently and optimally design and decompose a system into smaller functional parts, i.e. object classes and to identify properties, methods and interfaces, but when it comes down to actually making all that work, they will have to write code in a procedural way at some point.

I do not think that learning different programming languages for each approach is needed, although it couldn't hurt. One way do to it could be teaching procedural programming in C/C++ and then introducing abstraction and explaining its benefits by teaching OO C++. Also, both can be done in Java, but there isn't much you can do in Java that doesn't involve objects. Even printing on console output and getting input data is through objects and their methods, so the choice regarding programming language is a whole different topic and question, but my answer certainly is to teach procedural prior to introducing object oriented programming.

I would suggest functional, and then object-oriented. Procedural then becomes a way of writing functions and methods. I am not necessarily suggesting full functional paradigm but the use of functions and ultimately procedures and methods as a way of building programs. This also enables the writing of automated tests as a way of understanding what is required of the code they are to write.

The research on which way to teach is currently inconclusive. Most of it still comes down to what the teacher believes. My own preference is based partially on my PhD research on the nature of a program and my experience in teaching programming both procedural and object-oriented over the last 20 years.

Hi!

Based on my own experience both as a student and teacher, I would suggest to address functional programming as the first paradigm. Then I would follow procedural and, only after that, object oriented.

I strongly believe that functional programming is better for connecting programming to mathematical reasoning. I believe procedural and object oriented a very important to learn after because: (1) they are mainstream in industry; (2) they are better to structure mathematical ideas in to actual engineering artfacts!

What is clearly think that is wrong (in my humble opinion) is to teach procedural programming through object orientation...

The biggest difficulty that I have with these debates is that we really have no sound research data that confirms what really works best. Most discussions of this type that I have observed or been involved with are based on opinion or the experience of individuals. That includes my own comments.

Dear Errol,

With 20 years of experience, you already know very well what works and what does not. Consequently, your opinion IS important.

I agree with the contributors of this thread. OO first would be very difficult to teach as an initial CS/IT basic programming course. It seems more reasonable to start with a functional/procedural approach and then quickly move on to OO.

Dear Pavel,

Indeed, if the students spend a LOT of time with procedural programming, then they will become used to it and therefore the shift to OO will be quite difficult. On the other hand, if the students receive a short introductory course on PP just to get the basic programming skill and if they quickly move on to OO then the transition will be much easier.

Dear Pavel

Thank you very much for sharing your ideas.

As a matter of fact, I know some faculty members in various institutions who use exactly the same strategy you describe. Such a strategy would certainly work well with a population of students with a sufficiently high level of abstraction. On the other hand, for students who are at the other end of the spectrum, I think they are likely to have a much harder time during the course, although most of them will eventually manage to grasp the fundamentals.

The strategy I like most is inspired by Thomas Carruthers : "A teacher is one who makes himself progressively unnecessary". This strategy consists of using PP first, for about 4 months just to get the basics. This initiation period ends with a small COMMON project. Then, in the next course, the OOP paradigm is introduced by discussing in details the previous project and by showing one by one all the limitations of PP. In other words, OOP is introduced progressively as a better way to solve a problem. Thus, not only the students will understand the utility and the power of OOP but often some of them will propose, all by themselves, a good OOP solution before even receiving a complete formal course on the subject.

Best regards.

What really makes the teaching of programming easier is ensuring that students have relevant patterns to follow. My most successful teaching of procedural programming (1992-1993) was based on coding patterns such as counted loops. Because I moved out of teaching for a while, when I returned the focus was on object-oriented and I had to start over again.

The other thing that I did was use variations both in the way of presenting the design of the code (flowcharts and structured diagram) and solutions to the problems (while vs. for loop). I also introduced a new feature in a theory lecture and followed it with a practical session led from the front and then a practical lab where they solved a number of programming problems using the concept.

The more time, I have spent in teaching, the more I realise that we are stuffing more and more into the same period of learning time. The consequence is that we are not giving the students time to consolidate their learning. As well now, I find that many students are focussed on the grades rather than on the learning. With this focus, they complete what gives them marks and not the exercises designed to reinforce the learning.

I suspect that I could equally teach any programming paradigm first but that doesn't ensure easy transfer to a second paradigm. It is the transfer to a second paradigm that makes me say functional first.

Hi, it is important to start with OO since the most difficulty is to understand abstraction before introducing object oriented languages such as C++, Java, etc.

Hi, in my experience, conceptual structure provides students mark their relation to current and future techniques in lifelong learning of new languages​​, algorithms and methods. That said I believe that conceptual structure should be as flexibe with solid knowledge, what OO can give an initial course to students.

Pavel, I tend to agree with you. If the person has no prior knowledge or concept of the nature of a program then we have the opportunity to influence their conception in whatever direction we desire.

I wonder whether the problem with our teaching of novice programmers isn't the learner but our assumptions as teachers. The impression is that most of us have learnt to program procedurally or imperatively and then learnt other paradigms. Since we learnt that way, we expect others to learn that way. But what happens if we seek to understand the building blocks of languages and to develop sequences that help foster understanding based on the logical dependencies in those building blocks?

I am aware of research into novice programmers and into conceptions of the nature of programming languages but I see some of this biased toward the understanding that the researcher brings into the studies.

If we take something like the Dreyfus' model for the stages in developing expertise then at the novice level, we are teaching them patterns for solutions. Those patterns could be constructing objects, or functions, or procedures. The question then becomes which patterns do we feel are best for achieving the desired programming skills. If object-oriented is our objective then maybe the starting point isn't procedures. Maybe it is objects or the building bocks for creating objects (i.e. methods or functions).

The question that I see is one of identifying the threshold concepts for the teaching of a subject and how those threshold concepts should be sequenced to achieved the desired learning outcomes. Threshold concepts are concepts that tend to be difficult to understand but once understood change dramatically the way that the subject is understood.

Eugène Ezin,

I am wondering how you introduce abstraction in your teaching. Can it be introduced away from a programming language? I think most people would accept that the use of classes and inheritance involves understanding abstractions but is the use of procedures and functions also introducing abstractions?

What depth of understanding of abstraction is necessary before introducing OO? Remember that a novice is more interested in solutions than the big picture (Dreyfus model) and as a result the concept of abstraction is of little relevance to them but can I get past that resistance by helping them use patterns of solutions so that by default they are using abstractions and then lead them to producing their own abstractions?

I wonder whether our teaching problem is that we are throwing people into the deep end when they haven't learnt to swim and as a consequence they are drowning in the complexity. Can we simplify what we teach into a almost robotic implementation of patterns of solutions and then slowly extend the problems so they are having to adapt the patterns and then think more conceptually about the problem and what they are doing.

Our assessment practices could also be aligned with this in the sense that the lowest grades are given for being able to apply known patterns and higher grades for being able to discuss concepts and apply them in a broader context.

At a conceptual level, writing a class looks easy. It is writing the methods beyond a simple getter or setter that seems to cause problems for students and then understanding the way objects can interact to form a solution to a much bigger problem. I would contend that it is understanding that an object-oriented program is more about interactions between objects than it is about procedural code that seems to cause problems both for learners and educators.

Most programming code that has been written is procedural and OO code only has about 30 years of a programming base available. OO Programming is the direction that most programming environments and code bases is transitioning towards, and when well-explained, is a more natural way to teach programming to beginners. But realistically, given that the procedural code base will not disappear, new programmers should learn both ways of programming. We must note that all OO Programs contain multiple procedural statements inside each (implemented) class to implement the class, so we need to teach procedural programming and OO Programming.

Some would argue that the new programming base is functional (i.e. Haskel, Java 7, etc.). From a teaching perspective, I want to influence what the students how students will program and enable them to support existing systems. I see too much code that follows poorly written texbook examples. We need to provide the programming patterns that will set the standard benchmark for how systems will be written. They may mean introducing a paradigm which isn't currently the primary paradigm in use but somewhere in their learning, they have to be able to learn what exists and to evaluate possible options.

I would argue that at least at the university level, we want to inspire innovation and that may mean challenging current practice.

The other element of good teaching is to use a sequence that will foster easier learning of the threshold concepts. From this perspective, I would argue a functional style first followed by OO and procedural. To some extent, I would introduce procedural as simply the building block for methods. Why this approach. Functions and methods encourage good code structuring practice. OO requires functions and methods to implement object behaviours. I can foster test-driven approaches to coding from very early on hopefully further encouraging code design for testability.

What I am looking at is the end result and how I can get learners there without putting them into a road block caused by a threshold concept.

This response concerns teaching OO first when using Java. References are given at the end of this comment.

One principle that I try to follow is this: Refrain as much as possible from showing students things that you cannot explain right away

Doesn't that make sense?

Based on that, starting off a course on Java showing the students a program that prints "Hello World" makes no sense at all. Almost every line of a Java program has to do with a class or object, and you can't tell them anything useful about them on the first day. Therefore, one almost HAS to start teaching OO first.

But to do this, one needs an IDE that lets one execute Java statements or evaluate expressions without using a complete Java application. The IDE to use in this case is DrJava, a simple IDE with few bells and whistles but with an interactions pane, which works as required by the first sentence.

Here's how my course starts (the course has had anywhere from 150 to 450 students):

Day 1. Talk about type: a set of values together with (primitive) operations on them.

Types int, double, boolean. The fact that 7 / 2 is 3, following the Java principle that int primitive operations yield ints. All this is accomplished by DEMOING EVERYTHING. I type expressions in the DrJava interactions pane and have them evaluated.

Day 2. Objects: Tell the students their are two aspects to a language: (1) recipes, to be executed, like recipes in a cook book. This is the procedural part. (2) Structure and organization. How one organizes to keep things simple, allow for maintenance and reuse. We do (2) first: OO.

They have a name like C@20abde14 (C is the class, the hexadecimal digits following @ are the address of the object in memory) and they contain methods that can be called --functions and procedures. I draw objects for them, looking like manilla folders with the object name on the tab. I tell them about variables that can contain the name of an object. I tell them about the new-expression.

This is demoed using objects of class JFrame, which are associated with a window on the monitor. Put this in the interactions pane and execute it.

j= new javax.swng.JFrame();

I execute the call j.show() --calling method show in the object-- and the window appears on the monitor. I show them what j.setTitle("tt"); does.

The students thus learn about calling functions and procedures. They see calls work, because I am demoing the whole time.

I will also do k= j; and demo that both k and j contain the name of the same object --everything is indirect. This indirectness happens in real life. In a dentist office, the secretary, doctor, and nurse may all want to get at folder of the same patient at the same time.

Day 3. Class definition and method declarations. I show them a declaration of a class C with o components. I create an instance of it and we see that j.show(); doesn't work --there is no such procedure. I add to the definition "extends javax.swing.JFrame", compile, create an object and store its name in j, and do j.show(); Aha! Now it works.

i then how them how i draw objects with a superclass and subclass and talk about inheritance.

I then give their first function definition: compute the area of the JFrame window. And their first procedure definition: set the height of the window to its width.

Day 3. Fields. modifier private. setters, getters, constructor, and JUnit testing.

On it goes.

Here is the last version of the course I taught; you can see ppt slides and also assignments:

http://www.cs.cornell.edu/courses/cs1110/2011fa/index.html

I have written papers on this: Frames and folders (2001), Keynote talk at a conference in Lisbon (2007), SIGCSE 2008, OOPSLA 2008 (invited). You can download these from this website:

http://www.cs.cornell.edu/gries/programlive/plive.html

The website talks about a book that we used in the course.

David Gries

Excellent discussion and I think Erol hit all nails on the head....there is teaching the students to abstract and teaching the students to articulate the abstraction in different methods. I can articulate abstractions in procedural or OO languages and for those of us old enough to remember the days prior to OO languages, OO is little more than a natural extension of good procedural software development practices. With that said, sometimes we have to escape into other knowledge domains to find good solutions. For abstraction techniques I think TRIZ (despite all controversy) provides some really good approaches and concepts you should consider in your teaching abstraction. In the end it is not about what we consider better, right, or wrong, but what works for the student.

I believe that the didactical and methodological best choice should depend by a previous evaluation of competences, of motivations and expectations of students, as well as consequently by a detailed analysis of formative objectives.

Any technologically oriented programming I think should be consequent to these principles.

In essence our work depends anyway from "who's in the room".

Regards,

Mauro

I would say that both are interesting and should be given appropriate attention. Furthermore, it also depends on the targeted audience and their knowledge in programming. The outcome is also a parameter to be considered, which mean it depends on the current technologies available and what do one want to achieve via programming. Form my perspective both are important to get a good grasp of programming and then let the audience which one they enjoy best

I started with functional programming (SML) and still think it is the best that could happen to me. I learned many basic concepts like recursions, higher order functions etc. Besides, SML also allows to learn imparative and OO programming, which was part of my first programming course.

Old programmer here so my comment is a little dated, but here it goes.

The Forth programming language is free to use, thus a cheap resource for teaching. It is a simple language having much in common with basic and easy to learn.

It is a procedural language, that has many object oriented features and there for useful for teaching both concepts. The GoSub command was removed from Basic by Microsoft, but remained in Forth. Subroutines can be given a name and called just as in object oriented programming languages, but without the complications of OOP.

Forth has a long history, making a comeback every decade or so and as a self-booting operating system and language, it has Java like aspects as well.

My old friend Chuck Moore has an updated version of Forth called Color Forth and has a line of RISC chips using the Forth operating system. Here is a link.

http://www.colorforth.com/

There are a number of older Forth versions back to 8 bit CPU's available on the web for free, so there are a number of choices depending on what the teacher has available to use.

Anyway, hope that helps.

I would say it depends the previews experience of students, even if it's a basic course, your students can have some experience. Do you have a curriculum designed specifically to IT? does students take subjects depending their mood? Is this a bachelor subject? is this a very specialized topic? what kind of skills do you want to develop? if you have a designed curriculum, is there any other topic you can use as bridge between two topics?

What skills have, where you want to go, what skills do you want to build? I think those are key questions... Sorry I reply with questions and not answers!

It is with some trepidation I have to say that I disagree with David Gries - or perhaps he's teaching a different course than I would. Live demonstration is, of course, very good, but I would avoid the turbid swamp that is Java, and especially anything related to GUI programming. I would be talking about values, and numbers, and state machines and instructions and registers and memory and pointers and arrays and structures/objects. The fundamentals, in other words - you have to know that stuff to be competent, rather than merely literate. Of course, it could be that I would teach a terrible course, and that the students would much rather have a bit of showmanship with GUI stuff closer to their day-to-day experience - maybe the fundamentals should be taught in a follow-up course, sort of a "spiral" model of teaching...

Its always object oriented approach that's required in real time projects especially for ones who wants to lead a career in IT.

Procedural approach is easy to learn. Develop an algorithm and translate it into codes!

I think that every good programmer must know at least three programing paradigms, namely, procedural, object oriented and functional.

On the one hand, if you want to write fast code, your choice must be procedural, mainly C. Take into account that most of programming languages are based on C; for instance, C++, java, ObjectiveC and Python. Many others can insert C code as subroutines; for instance Haskell.

On the other hand, if you want to write code fast, your choice must be OO or functional; however functional languages with laziness, like Haskell, are almost bug-free and teach you to concentrate in algorithms instead of in machine structure.

There are also multi-paradigm languages like Ocaml that combine object-oriented, procedural and functional. In addition, provides a good IDE by means of which every piece of code can be tested.

To learn OO paradigm a good choice is java, because of the great library available together with powerful IDEs and tutorials.

In any case, a good programmer must know Haskell. Haskell allows us to see the algorithm structure, disregarding memory and machine features. In addition, Haskell forces you to separate side-effect code from pure functional one. After knowing Haskell, not only you can enjoy with its advantages, but you become a better programmer in both paradigms procedural and Object Oriented. Take into account that every paradigm can be imitated in procedural languages like C. Likewise, in Object Oriented, like java or Objective-C, you can imitate functional style. However, being ignorant of both paradigms hardly you can imitate any of them.

In my opinion, it doesn't matter. As first programming courses include several different topics, there are some that can be taught better with procedural and other with object-oriented languages. Otherwise, this means also that some topics are hard to understand when starting with the other one.

Look for example at the following exploratory study: http://www.ehlert.oszimt.de/dokumente/EhlertSchulteLearnersViewsOnObjectsFirstOrObjectsLater.pdf

As this study shows, the difficulty level for topics such as sort algorithms or abstract data types strongly depends on the first choice. For example, starting with OOP-first leads to difficulties in teaching arrays and strings, while procedural-first hinders the concept of methods.

Nevertheless, in the end all participants had a similar difficulty level for all topics together.

We have done similar observation during our introduction courses for students. Interestingly, if we teach pupils programming with Etoys or Scratch, oop-first is the best choice. It seems that is easier for pupils to really think in objects than in procedural algorithms... but this can also be a side-effect of Etoys' object-oriented IDE.

Dear Ani,

Decomposing problems into smaller ones is the only strategy in lazy pure functional languages like Haskell; because they are absolutely independent from machine and memory structure.

@Ani. I am of the opinion that every body is logical in his/her thoughts/actions/day to day life. But for a given problem, while putting their logic into words they become conscious and find it difficult to put it step wise. This is what I have experienced as a student and teacher for computer programming languages. I have taught the programming to some scientists who were not aware of abc of programming at all, and now they are fine programmers in their respective fields.

In my university, the procedural is taught in the first year, and OOP in the second year. It works well.

In my faculty, we have different courses in programming, depending on the level of studies: As first programming courses, named "Programming 1" includes Java (in the first year of study); the second course is "Programming 2" that include C++ (developed in second year of the study). The third course is "Programming in Internet" (at the end of Bsc Study). In Master Study, than we have 2 other courses: "Advanced Programming in Web" that include PHP & MySQL Web Development etc; and "Software Engineering". It works well too.

The commonly used teaching languages, now mainly Java with some C++ enduring, are object oriented and require some minimal understanding of the OO paradigm even to do basic I/O.

I use a spiral approach. I start with design -- first basic OO design via UML and then structured design via flowcharts, pseudocode, and module hierarchy. Later in the first course, I present Java, naming the application class as a class and 'main' as a method, and naming the I/O related classes as such, but emphasizing the procedural aspects. In a later topic, I present how to define a class.

I would be curious to hear how others have answered this question.

The procedural approach is foundation for the Object oriented. OOP was introduced to reduced the disadvantages that we face in Procedure oriented programing, and hence before learning OOP we should understand the the foundation from where it was developed.. For your initial learning of programing it depends on your need and understanding of the concept. But its better to start from the beginning

I forgot to mention, regarding my first answer in this topic, as Mr Peshawa Muhammad Ali wrote above, the conclusion that teaching procedural language prior to introduction of OOP concepts gives better results is based on experience drawn from practice the University I've attended and taught at.

I agree with Hidam. The OO approach is based on the structured approach.

In addition, the coding for defining classes is more advanced than coding algorithms; two steps more advanced (procedural abstraction; data abstraction).

I explain at the start that the class and method coding that are required for every Java program are like an incantation to the new programmer.

Certainly the loop is a more fundamental concept to master than the class.

However, students can begin to understand classes from day one. Whatever the mouse touches in a GUI Is an instance of a class, and its attributes and methods are typically accessible with a right-click in Windows.

Procedural or object-oriented approach? Of course, for CS/1 we do use procedural approach. When I used to teach that course, I did it mostly without any language, just different algorithm structures in order to teach students machine reasoning! Later on, different programing languages were applied!

I find it interesting the number of people (and it includes textbook authors) who make the statement that object-oriented is an extension or based on procedural programming. If I recall correctly from my reading the designing of the first object-oriented concepts and languages never saw it that way.

My own research in the field showed that there are those who seldom create their own objects who see it as procedural. Others see it as being driven by libraries of objects. A third group see objects basically as a way of introducing new abstract data types to a procedural language. The more interesting perspective are those who see it as creating a set of interacting entities to achieve some task. The final group, I refer to as liberated objects because they see program as an artificial concept and what to be able to create objects that can interact in ways that enable bigger applications to be built.

From my research, I would contend that these two later groups would contend that object-oriented is not an extension of procedural programming but is a new way of thinking about programming or application / system implementation. They acknowledge that they use procedural concepts to implement methods in many object-oriented languages because of the nature of the language but they do not see procedural as necessarily being required. They could build a functional object-oriented programming language or ...

This research led me to the view that starting with procedural programming isn't necessarily the appropriate place to start when fostering object-oriented thinking. I personally favour starting with functional programming (i.e. writing methods / procedures / functions that perform calculations but do not have side effects (i.e do not store data)). Why? Well storing data and grouping a set of functions that perform calculations leads more naturally to objects.

Functions also allow me to explore test driven concepts of programming before dealing with classes and objects. If I start procedurally, I have to use a scripting language or have them write code within a supplied code structure of which most simply seem overhead. I also find that students develop bad habits that need to be broken later. I have also found when using graduate students and research associates that many who learnt procedurally argue that objects is unnecessary overhead and still write large complex methods.

I would like to conduct more research in this area because I believe we are teaching a lot of topics based on our personal preferences without really understanding the longer term impact on our learners. I personally feel this is one of the reasons that we have a lot of crappy software out there that is difficult to maintain and makes poor utilisation of the programming paradigm concepts that the languages were designed to implement.

Good reply, Errol.

When we teach Java, as explained in an earlier reply on this thread, we make clear the second day of the course that there are two aspects to Java:

1. The procedural aspect: how does one write recipes, as in cookbooks --sequences of instructions to get things done. Some cookbooks even have procedure calls, e.g. Make the icing on page 20 and put it on the cake.

2. The structural/organizational aspect. Basic Matlab, for example, is just like a cookbook, giving a large set of functions/procedures, perhaps arranged in chapters or directories, like a cookbook. Want more functionality? Add some more recipes. OO provides a totally different way of organizing programs. Now, one can put procedures/functions inside objects. And reuse easily through subclassing and inheritance.

An object is much like a manilla folder in a doctor's office. It has an identifying name on its tab (in Java, the name of the class followed by @ followed by its memory location in hexadecimal). It has fields into which secretaries and doctors and financial people keep information. But in addition it has methods. Put in each manilla folder the sets of instructions to be carried out in various situations, and you have a nice analogy, which students can hang on to. The dentist office even has pointers. Both a doctor and a nurse may ask for file Patient John (the name on the tab of the manilla folder). Variable doctor and variable nurse contain the name on the tab of that folder. Only one of them can have it, and the other has to wait.

Use this analogy, along with demoing using DrJava, and non-programmers can get the idea during the second lecture of the course.

David, I have no doubt that what you are doing works for your students to achieve what you do in your assessments but I do wonder whether they come away with abstract data type understanding of object-oriented programming. As I read what you do, that is how I would understand the outcome but then I might be missing something about the way you do the teaching.

Possibly, I should have said earlier that you can introduce objects however you want if it achieves what you are looking for as the way to do object-oriented programming. From the perspective about making claims about the way our students understand object-oriented programming, we need to look at how and what they are coding two or three years after they have been taught the fundamentals. We may not be so confident about our teaching methods at that point.

I'd like to add to this discussion a short explanation on why I stand on the "procedural first" side of the discussion. It is strictly based on personal experience and observation of my friends and colleagues over the years.

Just like a number of my friends, I have started learning programming with procedural approach in languages that ware mainly procedural in use (Pascal and then C). Latter on, I (just like friends I've mentioned) have moved to OOP languages (Borland C++, C# .Net, Java) where I've started working with objects, classes, abstract classes etc.

Another group of people I know, who have started learning OOP first (Java and C#) ended up (all of them) having a distinct disadvantage. They did not "understand" on a deeper level what they ware doing. And when doing something wrong or not very optimal, they didn't know how to fix it. Of course, they know how to make a bigger and more complex application in these languages, but most of the times, not with a very well organized class structure.

I have an impression that they know "how to use" objects, classes, methods, but that they do not "understand" what is being done underneath the cover (inside the box - computer, not box as in class object visualisation).

This is why I always insist that it is better to teach basic lover level workings of a computer to newbies (not down to bit and register low level, but lower level). Procedural is closer to the computer than object oriented. Even though it might take a few more years of learning and teaching, I still believe that it is better to start with that which will result in better understanding, than with something that will result in a LEGO (or in the worst case scenario, duck-tape) programmer.

Procedural First.

Milan and others who promote procedural first.

I conducted research where I talked to people about their perceptions of the nature of a program and how they went about creating a program. What I would like to be able to do is talk with people who are procedural first and see how they describe the nature of a program and what are the key design aspects. What I am sure I will find is that many who learnt procedural first, still program in a procedural way. Objects may be equated with modules or ways to structure code rather than as behavioural entities.

Some will have made the transition to object-oriented thinking and object interactions. Some may be implementing object-oriented patterns. However, without talking with them and hearing what they actually say, I can't assess their focus.

With respect of procedural being closer to the lower level workings of the computer, this is certainly the impression given by Intel processor architecture but maybe not micro-code or some of the more innovative architectures. When it comes to multi-core processors, is procedural programming the best way to think about organising code for efficient execution? I would argue our own limitation in the way that we think about the nature of a computer, its architecture, and instruction set design is holding us back from potential revolutions in computer system implementation and behaviour.

My MSc (Computer Science) completed in 1980, looked at the nucleus of a general purpose computer. After examining architectures of a range of computers available at the time, I could see that although an individual computing core may use sequential instructions, there was coming a time when the design of programs had to be organised so that distribution of processing across different processing units within the same computer would be easy to implement. I proposed a self managing system based on this idea but I never pursued it.

I say this because if we want to see innovative designs then we need to be encouraging students to use different ways of thinking and not simply blinding following the current trend because that is how we see things implemented (I could get side tracked here into economics). What I would argue is that a lot of the complexity we have in systems is caused by limitations in the way we think about system design and if we really want intelligent systems then we need to break free from some of our current thinking constraints.

By the way, if anyone is interested in funding research into the consequences of thinking patterns of program design and the learning of programming then I am open to offers.

Thanks by the way to those who are voting up my answers. It is nice to gain support for views that are often not popular.

The question makes me think about the objective pursued, I think because they are in an initial course is best to start with the object-oriented approach, not only because it is the latest fad or fashion, but because the object-oriented approach includes a way of looking at dynamic programming.

Moreover, it is important to note that there may be a gentle introduction to programming in general, check the level of depth and interaction, and the expectations of the institution to determine what guidance or approach that requires expertise and level language, among other things. In this way, you can choose the language, IDE, and even the most appropriate examples, if programming requires a procedural approach, object-oriented, or oriented aspects.

Some people like to choose procedural approach and some prefers object-oriented approach. It doesn’t matter what approach we learned first. Both approaches have its own advantages. What matters is the technique (coding style) used when the output is required no matter what approach being used. If the techniques used are easier to understand and change by the programmers who will take over the system, then it will do. As a system developer, we should developed systems that are easy to be maintained not only by consumers but also by other development team.

My main point: If you want to use Java as the tool in a beginning course, you almost HAVE to start off with OO stuff, because otherwise you have to forgo the principle of not showing the student stuff they can't understand. That principle is key for me.

So, if you want to teach procedural stuff first, then don't use Java.

Second point: If you teach OO first, the students "get it", because right from the beginning they are using classes and objects in a good, sound, sensible way. If you teach procedural stuff first, they may get objects and classes at the end of the semester, but they really won't understand OO because they don't exercise it much in the class.

As Mohammad says, learning OO after doing procedural stuff for a long time may be difficult --simply because it appears so foreign.

The problem is not which approach you use (procedural or OO). The succes depend of good explanatin of this approach. The important is to learn students, that the "algorithms" are the same, only representation of data structures are different. I thaught also procedural C and now I teach Visual Basic for Application the students with no proggramming experience. And they like it :D The most important is explanation of teacher.....What you choose depend on kind of education. For technical oriented students is good start with C, but for example for students in Business Informatics I prefer OO approach, because they need "build the model of world" and it is more understable by using OO approach (not to play games with pointers :) )

In my experience when you teach procedural first, then it is more difficult to understand object-oriented programming. I can show you my experience, but you will have to excuse me, it is in Spanish. https://www.researchgate.net/publication/237008787_Introduccin_a_la_Programacin_desde_un_enfoque_Orientado_a_Objetos?ev=prf_pub

Conference Paper Introducción a la Programación desde un enfoque Orientado a Objetos

In my university, we have been studing this matter for years, and we observe that is very dangerous for students begin with procedural programming. The students with a fixed procedural thinking, spend a lot of work to understand object-oriented concepts.

We have been experimenting with non-informatic (people that had never seen anything about computing) students teaching them OOP from scratch, and we have obtained wonderful results. On the contrary, people who had knowledges about procedural programming take more time to learn the object-oriented paradigm. This is the reality we find.

I was taught procedural before OO or functional languages.

I think OO is a very intuitive way to organize the code, it is easier to learn to thinking in programming language. It should be learn first.

Yes, but you need a good way to do it. You need an IDE that allows you to dispense with method main for 10 weeks!. DrJava's interactions pane allows you to this. See earlier posts by gries (me) on this topic

...and the good plan for students work, good IDE..., and you've to look in advance, to "see" the whole picture i.e. what you want to present to students in CS1 course, as well as to "see" the entire curriculum they're studying and you offer... and the good examples..., yes I agree with David, OO first, could give more opportunities, to students and to teachers. More fun.

@For all Followers: What happens with "Project CS4EDU: Computer Science for Education". Namely, in 2008, the National Science Foundation (US) started the ambitious effort, project CS/10,000, which supports developing a new high school curriculum for computing, revising the computer science AP curriculum, and having computer science taught in 10,000 schools by 10,000 well-qualified teachers by 2015.

Does anyone know anything about this project?

It has non sense to study procedural programming and You must define first  which kind of OOP language are  you thinking about.

Ricardo, Is (maybe) the OOJ and PJ the same thing in different covers, i.e. is it (maybe) the way how to solve the problem (bottom-up or down)? Or, what is difference between Libraries in PJ and class in OOJ in a seance Stefan say above.