53 replies to this topic

[davepermen]

only newbies fight against procedural. professionals know bether.

this i have learned over the last years. helps me to distinguish.

doesn't mean professionals don't use oo of course :D but they know what its really all about. oo is just a buzzword all newbies hype onto.

i'm very happy to write in c# with quite object oriented structure and a language that allows me to. i'm happily compiling to a CLI, to bytecode, and not having to bother at all about whats really going on.

but you know why i'm happy with this? _BECAUSE_ i know whats going on. following closely all the in-between-levels of runtime compilation with nicks project, having programmed down till to asm myself, i can say by myself i've seen all levels of coding.

and only now, i'm starting to grasp what i really do in highlevel. now that i know whats below it.

it's like car driving. you don't need to know wtf your car really does. but if you know, you can react bether once he struggles, or save him from some mechanics - checks, letting the car life longer.. it doesn't mean you have to build an own one. but knowing more about how the car works always helps. it never hurts, at least.

knowing how a pc "thinks" shows you how dumb he is. and how clever, at the same time..

i just don't have the time anymore.. :(

[xeonx]

davepermen:
i agree that you should understand the run-time, the byte code or IL and how what how this bytecode interacts with the OS, i spent much time reading about and researching C# and the .NET framework, but have also spent quite a bit understanding how it works and what specific commands are compiled into in both java and C#. This is critical for understanding how to optimize the code that you write and i am never glad to simply use something as a black box without any knowledge of the implementation.

Just becuase OOP is a buzzword (and actually has a whole slew of associated buzzwords) doesnt mean that it isnt an effective mode of software development. It is. My note on the different average salaries for different kinds of programmers was meant simply to substantiate this. I also mentioned many times that you learn procedural programming in the course of learning OOP in C#, VB.NET, Java, C++. It is not as if procedural programming is "replaced" by OOP, you still find it in the methods as well as the ordering of how specific methods are called, and threads are started from the entry point of an application. I dont see how newb it is to advocate a mode of development which has been proven effective and simply allows for easier conceptualing of the application as a whole.

Quote

only newbies fight against procedural. professionals know bether.

This is a very absolute and statement and is very self-congradulating. You consider your self the "true professional" becuase you support procedural programming. Well instead I go for the best tool for the job which is always a better decision. anubis, your brought up robitics programming and other low level tasks such as writing drivers, well these are obviosly not tasks for OOP, and likely involve languages such as C which dont even provide facilities for OOP, so why are they even relevent to the discussion of "IF you intend to use OOP, should you learn if first". It is not a mater of "fighting" against procedural programing, it is a mighter of understanding the big picture of programming right off then bat when learning how to program. It is also a matter of being able to gain a grasp of the software which you are developing and this is much easier if you start off thinking in an object oriented fashion. Are you trying to say that it is *eaiser* to think in an object-oriented fashion after thinking in a procedural fashion !!??? This is certainly not the case. Frankly any developer that considers OOP as nothing more then a buzzword hasnt come seen a large application in development which has benifited from the use of it. But i am sure that that is not the case with you as you say yourself you have come to understand OOP. If you start out thinking about OO design and designing systems and applications to solve problems then you can always (I suggest that you do) go back and learn how it works, we both agree on that point, but it is my persepective (as well as those of Microsoft and IBM according to there courses and curriculum) that you learn first what is most pratical, what you will be working with, and what wont be counter productive and make it difficult to being OOP design. We both agree that you should understand how things work, but even you yourself state that there isnt always time to learn about everything so why not spend the majority of the time learning on something that you will *actually* use.

Its like learning a world language, if you intend to spend your life in Mexico and will be speaking Spanish 24/7, would you study latin to gain a better understanding of the Spanish language and then study spanish. I think that knowing latin would defintly help you to learn spanish and have a better understanding of the roots of particular words and how to use them, but why not learn spanish first, especially if you will have to *think* in it for the rest of your life. It may be beneficial to learn latin, but it will be counterproductive when you start trying to teach yourself to think in the language you willl be using, so save it as something you will just start learning on your own to gain a greater understanding of what you already know and work with.

On the subject of messy code, i did not say that procedural programming leads to it, but that it *lends* to it. Procedural code - when in a large or complex application - is almost always harder to follow and debug then OOP. That is basicly all that OOP is, away of thinking how to solve a problem is a way which emulates the real work and which is easily maintainable. Forget the buzzwords, its intuitive and productive and thats what matters.

[Nodlehs]

I think some people are getting way to stuck on a specified language instead of a programming style. As Michael said on page 2,

Quote

Also, don't neglect the fact that you can program non-procedural style in a procedural language - in quite a concise way, actually, given a certain set of linguistic abstractions.

For instance, consider programming OO style in C or Pascal (or to a lesser extent, simulating generics using the C preprocessor).

You can easily program in an OO way in C, or in just about another language. Consider in C creating all your classes in seperate files. If I wanted a class foo, I could create foo.c and foo.h, and _foo.h. Anything I wanted hidden from the user I would make static and put in _foo.h and only give the foo.h to the end user to look at the public accessor functions available to them, they don't need to see the static functions declared in _foo.h(they couldn't call them anyway). Worked in this fashion you can have an OO mentality but have the advantages of the C speed and low level access. Even beyond that, as I think anubis stated (or someone else) OO isn't for everything, yea, its great for lots of things, but there is still driver code to be written, still embedded systems needing code. OO usually isn't small enough or depending on which OO language you are using, fast enough, for such applications. For every project you shouldn't base your decision on using a language because its what you know, you should base it on what that language was created for, and what it is best at.

To top all that off, you shouldn't limit yourself to being literate in a few languages, learn as many as you can, it will give you more options when you get that next contract, or start that next project, and it will cut down on your loss of productivity when you actually need to learn something new, if you already know it, there is no need to waste time learning it. Try out C, Lisp, Scheme, Assembly, Java, C++, PHP, Lua, learn scripting languages, learn low level, learn high level, your work will show that you know what you are doing when you deliver a product that was programmed in a language that didn't need to be 'forced' into doing things it doesn't do on a normal basis. It will be more maintainable in the end, (most likely not by you). And you will thank yourself in the end, cause you will have that much more to offer your next client, or your boss, when you expand your resources (Brain resources).

[Michael]

Quote

Procedural code - when in a large or complex application - is almost always harder to follow and debug then OOP. [...] Forget the buzzwords, its intuitive and productive and thats what matters.

This is a "very absolute statement" as well and kind of disagrees with:

Quote

Well instead I go for the best tool for the job which is always a better decision. anubis, your brought up robitics programming and other low level tasks such as writing drivers, well these are obviosly not tasks for OOP [...]

Why do you think this is the case? Are you thinking of orthogonal language features such as automatic garbage collection often mentioned in connection with the OO paradigm? Or is there another reason why in your opinion OOP isn't as "intuitive and productive" for those?

Quote

[...]and likely involve languages such as C which dont even provide facilities for OOP

As I tried to point out in my previous post, you can very well program in an OO style in procedural languages.

After spending about 15 minutes on typing elaborations on possible implementation techniques, I found this link while verifying my post (which renders my draft kind of obsolete):

http://ldeniau.home..../oopc/oopc.html

Cheers,
Michael

[xeonx]

Quote

QUOTE
Procedural code - when in a large or complex application - is almost always harder to follow and debug then OOP. [...] Forget the buzzwords, its intuitive and productive and that’s what matters.

This is a "very absolute statement" as well and kind of disagrees with:

QUOTE
Well instead I go for the best tool for the job which is always a better decision. anubis, your brought up robotics programming and other low level tasks such as writing drivers, well these are obviously not tasks for OOP [...]

The two statements don’t disagree; I qualified the statement for the use in large applications. At this point it is critical the code is logically partitioned and - for more flexible applications - is easily extendable or replaceable. The operative words are "large applications". You were to write a one-off app to accomplish a very specialized task, perl or python would likely be the best bet and if you were to write a driver or work with low level, cpu critical processing or even a driver then go with C. If you are working with MS Office, then VBA (ok but that is out of necessity).

Of OOPC, i don’t understand why you wouldn’t just use C++ since it implements everything in C under the hood. Why rewrite the wheel.

The reason that i think robotics and the like wont necessarily stand to benefit from a managed language is because of the both the lesser size of the required framework and how wasteful it would be to implement say GC. You will hardly need the complexities of languages like C# or C++ (in terms of things like metadata attributes, JIT, and interop) as well as the full frameworks (from GUI to Web-based development). C++ compiled into a byte code like MSIL and interpreted as a command set on a robot might be good idea though, you just wouldn’t include the framework and the compiler and JIT'r. Many mobile devices utilize managed languages now for RAD and device/platform-independent applications.

But I’m getting off topic. I don’t see much point in continually arguing as to whether it is better to learn OOP or procedural programming first when aiming to be a OO programmer (especially since you learn procedural with OOP) since our views are stated and no one is going to change his or her stance. But if anyone has a comment about what this thread is about: whether C# is a viable option for game development, i would be happy to throw in my 2 cents.

[davepermen]

you hail oo too much imho. oo is a tiny part of coding actually. it's a very visible part, but a tiny one non-the-less.

and you don't learn procedural with oop.

and my statement holds true. the ones that know 'the right tool for the job' is the only thing to care know that oo is just a small part of the whole business. all the other ways to program (even functional) apply in every language anyways, the trick is to see all sides all the time and work in a good way with all of them.

once you got that far, oo is really just one of many. a small one of many, actually.

[anubis]

word

[xeonx]

Quote

the ones that know 'the right tool for the job' is the only thing to care know that oo is just a small part of the whole business.

Did i say that you should consider the different types for different tasks? yea i did.

Quote

all the other ways to program (even functional) apply in every language anyways, the trick is to see all sides all the time and work in a good way with all of them.

This is my point, that you end up learning functional or procedural programming when you go to actually implement the methods for the classes. When you learn how to program initially, you learn how to implement these. having an OOP-based intro class to programming does not mean that you dont learn these things. If you think that you just design empty shells of classes then you are gravly mistaken.

Quote

and you don't learn procedural with oop.

Wrong in this situation at hand. The subject (yet again) is that of the incorporating OOP into the intro to programming classes. You are totaly off the mark in trying to explain that OOP is not all that there is to programming. That is not the issue, did you even read the posts? I agree with your statements of the obvious, they actually reinforce what i have said in earlier posts, but the issue it should OOP be taught in the intro classes. You learn procedural or functional programming when you are learning how to program, it is an essential aspect of programming and *just* learning purely OOP is not a intro to Comp-Sci class it is a Software Development class. So you will learn procedural and functional programming. The issue is whether you should skip right over the chapters of the textbook on OOP altogether like was brought up by anubis. This is an isane idea when considering that it gives students a understanding of what they are desiging and provides them a way to organize their code and gain an understanding of the technique that they will actually be using in software development (since the issue when should OOP-based software developers learn OOP, not if they should). Why are you trying to point out that OOP is not the only aspect of programming when that is in no way revelent to the issue at hand??

[xeonx]

anubis said:

you know... i have the feeling that all that you are concerned about is application writing. i even agree with you that when you are only dealing with business world programming and writing apps in that area you are better of with never careing too much about low level things besides how you can write efficent code for your CLR.

First, i am very concerned with app design as it is the first and most critical part of software development. But notice that i did not suggest that you dont understand the CLR, actually I suggested quite the opposite: that you do gain an understanding of the innner workins and not be like the lazy java students you cited earlier and consider the computer as a black box. So the issue is not whether you learn about the nitty grity and low level operations (as we both agree that they are critical), but when.

anubis said:

but there are other things to do than that. people do write code for the linux kernel and people do design low level network logic or programm AI into robot (or write high performance code ala Nick's swshader/softwire). about all research projects, my university is involved in, require skills in object oriented programming as much as writing specfic assembler code or work at lower levels that don't permit the luxury of object orientation. so you have two sides that both need to be covered and the question that remains is how you should teach about both of them. we have different opinions on that and that's ok

What is the revelveince of this statement. I am aware that there are fields of programming which do not require or even have the facilities for OOP. I was under the impression that we were discussing whether OOP just be learned first or second when you intend to develop with it. This stipulation then is that you will *need* to learn it and that you *will use* it. If a robotics programmer wont ever use it but will instead use procedural programming then he obviosly wont be learning OOP first, or likely even all all.

Quote

QUOTE
Other then that I don’t think that learning to do something in a *very* old and *very* ineffective way first helps you in any way


it's not very old. it is how your computer does it. today.

The issue is that you woudnt be use stricly procedural programming for developing a even moderatly sizable software application when the ability is provided. I have yet to see a newly written large-scale application writen procedurally and not be considered very old fashion in design.

Quote

QUOTE
This API is very complex, cryptically-named, and for the most part with a linear (non-OOP or hierarchal ) in C and C++, but is very intuitive and well-documented in C#


that problem is specific to the windows API ? (counter example OpenGL)

My point exactly, C++ and other languages which make *often* heavy use of non-OOP are very difficult to learn if not simply for the high-shortened names and lack of a highly heirchachial structure. My point is if you dont intend to work with C++, why force on the lazy java students painstacking trouble of learning it (especially when it is far different from the types of apps they will be developing and frameworks that they will be working with). I would suggest gaining and understand at least of how the java runtime and byte code works, but why would the start out with the sizable task of learning C++ and then move over to java, when they could learn the language that intend to develop in first and then learn C++ if they have both the time and inclination to learn.

[xeonx]

Sorry if I seem blunt or critical, but it is understandably frustrating when we are trying to argue several entirely different points (ie should OOP be used) when we pretty much agree that it should be used when necessary and possible. The original issue with the conflicting perspectives is whether or not to start out with OO or Procedural programming.

[davepermen]

the only issue i have is you hail oop too much, as if it would be the one big thing, and the others only if neccesary. oo doesn't do much, and doesn't mean much.

i for myself don't use the term oo at all. i use terms that have meaning. like objects, inheritance, delegates, messages, functions, callbacks, events, structures, etc.. wich are definable.

oo can be everything, or nothing at all.


and you won't learn procedural with oo. but you may reinvent it. same as the other way around. you have to specifically learn both to really know them. but you can always 'accidentally' reinvent them.

[anubis]

Quote

The issue is whether you should skip right over the chapters of the textbook on OOP altogether like was brought up by anubis.

could you send me a link or the ISBN of that textbook that covers OOP first and then moves on to procedural programming ?

xenox said:

anubis said:

but there are other things to do than that. people do write code for the linux kernel and people do design low level network logic or programm AI into robot (or write high performance code ala Nick's swshader/softwire). about all research projects, my university is involved in, require skills in object oriented programming as much as writing specfic assembler code or work at lower levels that don't permit the luxury of object orientation. so you have two sides that both need to be covered and the question that remains is how you should teach about both of them. we have different opinions on that and that's ok

What is the revelveince of this statement. I am aware that there are fields of programming which do not require or even have the facilities for OOP. I was under the impression that we were discussing whether OOP just be learned first or second when you intend to develop with it. This stipulation then is that you will *need* to learn it and that you *will use* it. If a robotics programmer wont ever use it but will instead use procedural programming then he obviosly wont be learning OOP first, or likely even all all.

the relevance of this statement is that once you go to univeristy you will most likely be involved in projects that go deeper than constructing applications using whatever language suits you. as you said a robotics programmer might very well never use OOP. my point is that when you start your academic education you don't know with what you will be involved in your career or during your stay at the university. the bottom line is that you need to adapt to many different situations and my position on this is that it is harder to descend to lower levels after you learned to strictly work with OOP than it would have been if you learned about "programming the machine" right from the start.

xenox said:

The issue is that you woudnt be use stricly procedural programming for developing a even moderatly sizable software application when the ability is provided. I have yet to see a newly written large-scale application writen procedurally and not be considered very old fashion in design.

are you sure that you are writing applications of ANY scale when you enter university ? i know i didn't... why not see OOP as a tool for software design and teach about it when you actually do need it ?

[Michael]

xeonx said:

Quote

QUOTE
Procedural code - when in a large or complex application - is almost always harder to follow and debug then OOP. [...] Forget the buzzwords, its intuitive and productive and that’s what matters.

This is a "very absolute statement" as well and kind of disagrees with:

QUOTE
Well instead I go for the best tool for the job which is always a better decision. anubis, your brought up robotics programming and other low level tasks such as writing drivers, well these are obviously not tasks for OOP [...]

The two statements don’t disagree; I qualified the statement for the use in large applications.

But you contrasted "large" with "low-level" :)

[TheNut]

Just a few weeks ago I made a shift over from C++ to .NET C# and ASP.NET. I’ve been following the .NET architecture for just over 2 years, but never made it a priority given the nature of its slow startup. Now that it has become mainstream and millions of updated computers automatically have the runtime installed, I’m quite happy to make it my official choice for development. The new ClickOnce deployment feature integrated into .NET 2.0 will also broaden the .NET architecture to virtually anyone.

The thing I like most about .NET is that programming is made both easier and fun (the way it should be!). There are of course a ton of other benefits to using the architecture, but I’ll leave that to the thousands of reviews and books to explain =)

Also, I wouldn’t quarrel over design paradigms. After all, it doesn’t matter what way you like to program because when you work for a company you have to conform to their standards, unless you’re a consultant with no obligations to code design. Also, even C++ has OO design flaws. Threads and function pointers (for delegation) come to mind.