macOS should new programmers learn procedural before object?

zimv20 · Feb 27, 2006

after a bit of time in this thread, where an assignment for a C++ class was being written procedurally, i started wondering how to best teach new programming students.

let's assume the ultimate goal is to make developers who are skilled in large-scale, object-oriented projects.

what do people think of the following?

1. procedural techniques make the transition to OO more difficult. for the above goal, starting with OO is preferred.

2. even OO projects require some degree of procedural knowledge, so:
a. start with procedural, then move to OO
b. start with OO, then introduce procedural once the OO skills are solid

3. procedural techniques are the basis of all coding and should be taught first:
a. with a procedural-only language, such as C
b. with a language capable of both styles, such as C++ or java

i think it's a crime to teach procedural programming and C++ simultaneously to new programmers. then again, i learned C well before C++ was even invented, so perhaps my own bias is tainting my opinion.

thoughts?

bousozoku · Feb 27, 2006

I'd rather someone go with OO programming as the first actual implementation. However, I'd want them to understand how to create objects on paper and further, how to turn them into either OO or procedural code. That would probably keep them from programming anything their first year but considering the compromises I've seen at that level, it would be time well spent.

At that point, the student could be taught both discplines concurrently. (You can't teach someone two different things simultaneously. You would have to switch.

)

zimv20 · Feb 27, 2006

bousozoku said:
I'd want them to understand how to create objects on paper and further, how to turn them into either OO or procedural code.

are you saying you'd teach design first? i think that's a great idea.

(You can't teach someone two different things simultaneously. You would have to switch. )

bousozoku · Feb 27, 2006

zimv20 said:
are you saying you'd teach design first? i think that's a great idea.

I've dealt with far too many who've been rushed into coding, for one reason or another. If they were my students, they would be well-versed in design before they coded and ran anything.

The current system used at most schools is that you design a little, code a little, compile and fix until it runs, run it and fix it until it runs properly. This is fine for a 64 KB programme/module. It's not fine for a 80 MB application.

How many applications sold commercially use a scrolling text interface? The number is near zero. Yet, the first thing taught is how to create such a programme without a thought to design. If you turned in an essay in such condition, you'd not receive the grade you thought you'd deserved for the work you'd put into it.

Design is everything.

I'm not just saying that any TUI or GUI is acceptable. Macromedia does a terrible job of making their applications powerful, yet inaccessible. Adobe's applications work virtually the same, yet you don't struggle to find the controls and options. Borland programming tools are famous for ease of use, while Microsoft's distance you further from getting the job done. Is a checkbox simpler than remembering to add /VSSE2 or some such to a line of options? Of course, it is.

Simplicity of thought engenders efficiency. Design is everything.

zimv20 · Feb 27, 2006

bousozoku said:
Design is everything.

i agree.

i have a friend who's interested in programming and we talk a lot about it. one thing i told him recently is how, in well-designed, large-scale OO projects, the class files themselves aren't that meaty. aside from the typical constructor / accessor / modifier methods, the methods that do anything typically do a small bit, hiding the bulk of the work by using other objects.

i then stressed that the power of such a project is the relationships among the objects as found in the design, and that's where one must go to understand the project as a whole.

i've found that the number of developers who can abstract and design is rather small indeed.

Soulstorm · Feb 27, 2006

bousozoku said:
I've dealt with far too many who've been rushed into coding, for one reason or another. If they were my students, they would be well-versed in design before they coded and ran anything.

The current system used at most schools is that you design a little, code a little, compile and fix until it runs, run it and fix it until it runs properly. This is fine for a 64 KB programme/module. It's not fine for a 80 MB application.

How many applications sold commercially use a scrolling text interface? The number is near zero. Yet, the first thing taught is how to create such a programme without a thought to design. If you turned in an essay in such condition, you'd not receive the grade you thought you'd deserved for the work you'd put into it.

Design is everything.

I'm not just saying that any TUI or GUI is acceptable. Macromedia does a terrible job of making their applications powerful, yet inaccessible. Adobe's applications work virtually the same, yet you don't struggle to find the controls and options. Borland programming tools are famous for ease of use, while Microsoft's distance you further from getting the job done. Is a checkbox simpler than remembering to add /VSSE2 or some such to a line of options? Of course, it is.

Simplicity of thought engenders efficiency. Design is everything.

I couldn't agree more to that.

And as for the first question, I should say that my first language was C++. I didn't learn C first and then moved to C++. Instead, I learnt C++ all the way from the ground up. Guess I didn't have a choice, since our university was teaching us C++ from the first semester.

Anyway, what I want to say is that even in C++ there is procedural programming, and I recommend anyone to start teaching that. If anyone wants to be sure his/her students learn things the best way possible, he/she just has to ensure that before starting explaining what is an object and how does it work, students must have fully grasped the knowledge of making a program in C++ without the use of objects.

In my opinion, objects in OOP can be intimidating to people who don't have the proper teachers, or books. My introduction to objects was made with a teacher who told us that a class is just what a species is in real-life nature.

For example, lets take as a class the Human class. I am Soulstorm, object of a Human class, and my variables are eyes, nose etc, and there are some functions that although they are the same for all the objects of the Human class, each person handles them differently according to the variables given.

I don't know about you, but I found that a very clever approach to introduce new programmers to OOP.

Also, if your ultimate goal is to make students to become OOP programmers, if you don't start with an OOP programming language first, it will be very difficult for the student to learn 2 languages with a slightly or entirely major syntax, and logic.

As far as OOP is concerned, i think that C doesn't introduce the student to the OOP features C++ or Obj-C has, so if the ultimate goal is proffessional OOP, the learning of C nearly as good as useless to me.

I know there are many people who don't have the same opinion though.

iMeowbot · Feb 27, 2006

The only reason people have problems switching from procedural to OO is that OO is almost invariably taught poorly. Students have their heads stuffed with terminology instead of some nice clear explanations of what the darned things do.

Adding to the frustration is the vapid promise that OO will magically make everything reusable, when OO really has little to do with that. Reusability comes from planning ahead, and objects don't help a whit unless the programmer has already learned how to do that.

zimv20 · Feb 27, 2006

Soulstorm said:
My introduction to objects was made with a teacher who told us that a class is just what a species is in real-life nature.

that's a pretty popular method, i've used it many time.

but the guy who i learned a lot of this stuff from summed up the transition from C to C++ this way: "you get extensible data types, and your functions can live with your variables".

that actually helped me a lot.

As far as OOP is concerned, i think that C doesn't introduce the student to the OOP features C++ or Obj-C has, so if the ultimate goal is proffessional OOP, the learning of C nearly as good as useless to me.

interesting, thanks for that. i would agree that teaching C++ too quickly after C will simply lead to confusion. i started learing C in 1985, but didn't get on a C++ project until 1992, so i had a ton of procedural programming in C by then.

if C++ is going to be the language for teaching both, then i agree that a differentiation must be made between object and procedural. and i agree that some of the lessons of procedural, such as top-down coding, do help in an OOP environment.

zimv20 · Feb 27, 2006

iMeowbot said:
The only reason people have problems switching from procedural to OO is that OO is almost invariably taught poorly. [...] Reusability comes from planning ahead, and objects don't help a whit unless the programmer has already learned how to do that.

excellent points.

this goes back to that abstraction issue. afaic, some people have it and most don't. reusability cannot happen w/ bad abstraction. hell, most projects don't even survive to the point where anyone would want to reuse parts.

should we discuss the abysmal success rate of s/w projects?

MarkCollette · Feb 27, 2006

I would teach procedural first, then OO. OOP is not some be all, end all. There are some (well, many, many) problems that are best solved with an OOP approach, and there are some that are best solved with a procedural approach.

Most business applications merely input, store, and output data. Nothing is really calculated, and nothing has to execute for any long duration of time. These can be modelled easily with an OO framework.

But, most scientific or engineering problems are highly procedural, or at least if you want to solve the problems with the fastest CPU execution, then a procedural approach is best. Heck, the thread you referenced, where someone had to calculate prime numbers, is a prime (couldn't resist) example of this.

So, I don't think that OO should come first, to try to reduce some learning curve from one approach to another.

As for the focus on design, all I can say is "thank god!" But, even there, you'll probably have to teach some rudimentary procedural and OO techniques first, so they have a working set of skills for which they can effectively design.

zimv20 · Feb 27, 2006

MarkCollette said:
there are some that are best solved with a procedural approach.

i agree with you, and it was with this thought that i qualified the original question for OOP to be the end goal.

a procedural approach is best. [...] to calculate prime numbers

not sure i agree here, especially going with the solution i'd suggested about saving off the primes already calc'ed, which calls for a bit of organization. i definitely see some OO design in there. and the procedure for testing a prime isn't really that complex, just a couple lines of codes.

however, if i were to go the recursion route, that might change my thinking.

admanimal · Feb 27, 2006

zimv20 said:
are you saying you'd teach design first? i think that's a great idea.

I don't think it's that simple. You can't really design something when you have no idea how it will be built. At the very least, designing a program requires you to know what classes, variables, methods, etc. are. And you have to have at least a rudimentary knowledge of how different design decisions affect the computational complexity. Even the fact that you can only do one thing at a time isn't obvious to someone with no programming experience.

For these reasons, I really think it is necessary to strike a balance between teaching design and actual programming. You can't really teach one without the other.

As for starting with OOP vs. procedural, I would definitely go with procedural. OOP is basically just procedural with additional design considerations which are difficult to grasp at first and can distract from the task of learning basic programming constructs. I don't think you can do OOP effectively without being comfortable with breaking a program into functions anyway. Once the students are ready for writing serious programs with serious designs, then OOP can come in. (Not that you can't write a serious program without OOP).

weg · Feb 27, 2006

zimv20 said:
thoughts?

I transitioned from GW-BASIC (my first lines of code ;-)) to Pascal, from there to C, C++, Perl, Java, SML and finally OCaml. Currently I'm writing code mainly in C++ and OCaml. It might seem strange, but I think functional languages are ideal to start with, because they are closer to what people now from school (in mathematics, you have no concept of a "state"). It might even be a good idea to use Mathematica as a first language... just to teach the concepts.

It doesn't make any sense to talk about design before the student understood the basic concepts. Think about what crappy houses you'd design if you knew nothing about statics.

MarkCollette · Feb 27, 2006

zimv20 said:
i agree with you, and it was with this thought that i qualified the original question for OOP to be the end goal.

Sorry, I think I read up until your link to the other thread, then read that thread, and when I came back, just read everyone else's posts, and not the rest of yours. In short, my post was retardedly redundant

So, as for the question you were asking, I'd just use C++. But, I'd start with the procedural C subset of C++. So, that would mean using printf instead of cout, but would allow syntax like "Coordinate topLeft;" instead of having to do the old C "struct Coordinate topLeft;". Also, they could use both /* */ and // comments. And they'd get the stricter typing that C++ offers, including the bool datatype.

Later, it's just a small step to flip structs to classes, so the technical hurdle is as small as possible, so they can focus on the mental paradigm shift.

zimv20 said:
not sure i agree here, especially going with the solution i'd suggested about saving off the primes already calc'ed, which calls for a bit of organization. i definitely see some OO design in there. and the procedure for testing a prime isn't really that complex, just a couple lines of codes.

however, if i were to go the recursion route, that might change my thinking.

Those prime number algorithms are more of teaching aids for programming in general, then actual algorithms one would use if the goal was to find primes. Once you start using any of the sieve algorithms, you start building up tables of information that you wouldn't want encumbered by objects. Well, you might want a vector, but you wouldn't want the elements of the vector to be objects.

AlmostThere · Feb 27, 2006

weg said:
It doesn't make any sense to talk about design before the student understood the basic concepts. Think about what crappy houses you'd design if you knew nothing about statics.

Tend to agree with this if learning is part of education (rather than as part of job training).

Build a good understanding of memory, pointers and function pointers. You can then wrap pretty much any programming philosophy around those building blocks.

As a follow up, you are nicely poised to demonstrate how different languages utilise and express those same features natively and how the same problem can be approached in many different ways.

zimv20 · Feb 27, 2006

admanimal said:
I don't think it's that simple. You can't really design something when you have no idea how it will be built. At the very least, designing a program requires you to know what classes, variables, methods, etc. are.

we need to consider different levels of design. from what i've quoted, it seems to me that you're thinking about a level design that's removed from coding by only a step or two. at that level, yes, language considerations could come heavily into play.

but there are higher levels where the language doesn't matter as much, if at all. indeed, i've done design sessions of the domain with the end users, who often don't know anything about coding (actually, the ones who do make it more difficult, because they zero right in on the code, which is out of scope at this point).

these design sessions can be very fruitful if done correctly. they can produce an accurate representation of the business, which is what they're meant to do. at this level, the business doesn't change its procedures if the IT department decides to switch from C++ to java.

another level is architectural. though i view this as possibly the highest level of design, it does concern itself with implementation technologies and does depend on the language. for example, when considering interprocess communication, i'd use CORBA for a C++ project, but consider RMI for a java one. this would be part of the architectural spec.

however, if i've done the work of designing the services available, details such as methods available would not change based on the underlying language. ints are still ints and extendible data types are available in both C++ and java, among other languages.

this stuff is hard to learn, but of vital importance in large projects and to success. i do believe that teaching it early on, perhaps even before some hands-on programming, could be useful to a number of people.

in the end, some developers can design, and some can't. starting with design would help both groups, imo.

Even the fact that you can only do one thing at a time isn't obvious to someone with no programming experience.

it's also not true, especially in large-scale projects where a number of services run simultaneously. for example, the database is its own process.

even within a single program, there's multi-threading. but that's not really a design consideration.

OOP is basically just procedural with additional design considerations

i don't agree with that. imo, the thought processes behind procedural and OOP are markedly different, and that's why so many programmers have trouble making the transition, hence the thread topic.

the best programmers know both, know when to use each, and can combine them.

zimv20 · Feb 27, 2006

MarkCollette said:
I'd just use C++. But, I'd start with the procedural C subset of C++. <chomp>

this seems a reasonable approach.

Those prime number algorithms are more of teaching aids for programming in general

you bring up a good point. this is a good example of a problem which can be solved using each approach, and it could be taught that way. "remember when we did prime numbers using procedural techniques? now let's approach the problem with OO".

MarkCollette · Feb 27, 2006

This reminded me of an old thread asking a similar question. Here was my post there.

zimv20 · Feb 27, 2006

MarkCollette said:
This reminded me of an old thread asking a similar question. Here was my post there.

some good stuff, yeah. i haven't read the thread, so perhaps you mentioned them later, but i'd add:
- linked lists
- trees
- debugging

...as more prerequisites to starting to learn computer science and real programming.

admanimal · Feb 27, 2006

zimv20 said:
...snip...

i don't agree with that. imo, the thought processes behind procedural and OOP are markedly different, and that's why so many programmers have trouble making the transition, hence the thread topic.

the best programmers know both, know when to use each, and can combine them.

I agree that the thought process behind OOP is very different than procedural. But I think that most of that thought goes into the design as I mentioned. The differences in actual language syntax are pretty trivial and everything ultimately comes down to the same basic programming constructs (which is why I think they are so important to master before you worry too much about OOP ideas).

I should qualify my previous post by saying I was thinking mostly in the context of what a student would be doing in classes. As projects become more and more complex, the differences in design methodologies become much more apparent.

gekko513 · Feb 27, 2006

Go straight to OO. And start out with a drawing Applet in Java. It's more fun.

admanimal · Feb 27, 2006

gekko513 said:
Go straight to OO. And start out with a drawing Applet in Java. It's more fun.

Noooo! I was a teaching assistant in an intro to programming class that used Java. And some of the first programs the students had to write were Applets. This just confused everybody. Why make the students worry about things like event-driven programming when they can't even effectively use a for-loop yet? By the time I graduated, they had stopped using Applets completely in the intro class and just stuck to text I/O.

I should say that this was a liberal arts college, so some of these students really had no clue about programming or really computers in general. I think perhaps the standards can be different depending on how advanced the students in the intro class are likely to be. (For more advanced students, starting with something fun like a drawing Applet may in fact be better)

whooleytoo · Feb 27, 2006

Just to add yet another 2 cents:

Since the topic related to new programmers, rather than software designer or engineer, the first thing I think a newcomer should have a firm grasp of computer architecture and programming concepts such as the various basic and advanced data types & collections, pointers, memory management (whether manual in C/C++ or 'automatic' as in Java).

Any fledgling developer is going to be starting at or near the bottom of any organisation anyway, so having to implement a more senior engineer's design a) is a good way to see actual designs first hand, and b) experience first hand the potential issues & pitfalls in software implementation.

Another thing I'd recommend, is NOT to stick to just one language / development environment. IMO, knowing a lot isn't nearly as valuable as being able to learn quickly. Being open to new development environments can expose you to new design methodologies as well.

In defiance of what my Software Engineering lecturer told me in university, I don't subscribe to his notion of Design -> Implement -> Game over. The reality is many software companies are small, under funded and over promising; staff are hired and lost; and thus specifications and schedules tend to be quite "flexible", in reality.

In this kind of industry, it's not uncommon (even with a good initial design) to have to go back to the design phase time and again.

zimv20 · Feb 27, 2006

admanimal said:
everything ultimately comes down to the same basic programming constructs (which is why I think they are so important to master before you worry too much about OOP ideas).

i think we're more or less agreeing, then. imo, a lot of the OO power comes from the interaction of the objects, and i suppose that means that proper OO code tends to reflect the design, which means it's coded that way. hadn't thought of it in those terms before.

I should qualify my previous post by saying I was thinking mostly in the context of what a student would be doing in classes. As projects become more and more complex, the differences in design methodologies become much more apparent.

gotcha.

gekko513 · Feb 27, 2006

admanimal said:
Noooo! I was a teaching assistant in an intro to programming class that used Java. And some of the first programs the students had to write were Applets. This just confused everybody.

I suspect that is mostly because the exercises weren't adjusted to fit newbie students.

I'm not talking about making event driven AWT or SWING Applets as first exersises, but drawing things is a lot more fun than text.

The text based I/O programming courses didn't feel like real programming to me at the time (high school). The first Java course with Applets at uni, on the other hand, was great fun.

macOS should new programmers learn procedural before object?

macrumors 601

Moderator emeritus

macrumors 601

Moderator emeritus

macrumors 601

macrumors 68000

macrumors G3

macrumors 601

macrumors 601

macrumors 68000

macrumors 601

macrumors 68040

macrumors 6502a

macrumors 68000

macrumors 6502a

macrumors 601

macrumors 601

macrumors 68000

macrumors 601

macrumors 68040

macrumors 603

macrumors 68040

macrumors 604

macrumors 601

macrumors 603

Our Staff