C# The Next Thing?

F699ebb187331fdf7f7875320e3e7e3e
0
starboarder2001 101 Nov 23, 2003 at 01:42

I am going to give it a try. Has anyone else programmed in it?

53 Replies

Please log in or register to post a reply.

F7485e361f5412896a7e3be4c15038c4
0
Luke 101 Nov 23, 2003 at 05:07

I tried C# for a while. It’s OK - a bit like Visual Basic. But I like C++ better.

F699ebb187331fdf7f7875320e3e7e3e
0
starboarder2001 101 Dec 05, 2003 at 16:03

Yup I bought Visual C# .Net…I havn’t tryed it long enough to realy make a decision on if I like it. It is very similar to C++…I also noticed some things that are similar to Java. Its lika a C++/Java hybrid. :P

61eaaaf126d14cafe589ca10542be3f2
0
squidfishes 101 Aug 25, 2004 at 14:49

I’ve been looking at Mono, which is an Open Source and cross-platform version of C#. It’s coming along nicely. I’ve been staying away from C# because it was a MS-only language, but I’m changing my mind now.

http://www.monodevelop.com/

6ad5f8c742f1e8ec61000e2b0900fc76
0
davepermen 101 Aug 25, 2004 at 15:04

i’ve never really touched it much for long.. then, those new free ms ide’s got available as beta, the Visual Studio .NET 2005 Express Edition BETA (woah, long name:D), for c++, for c#, etc..

then i thought, cool, c++ with high quality compiler, and the new c++/CLI wich is a quite impressive designed language to work with native and managed code. so i touched managed the first time really with c++ and thought its cool.

then i tried the c# version of 2005..

i never step back:D intellisence fast and perfectly knowing everything, a language easy as pie (once you mastered c++ c# is .. wow! :D), fast compilation, great exception help (so you really know what you did wich you shouldn’t), fast working binaries (haven’t benched. but they feel responsible, load quick, etc..).

i’m happy.. for me, c# is not the next thing. it’s the only thing right now. the package is so clean, so solid, so complete.. .NET 2.0, c# 2.0, vs 2005.. great work..

well.. that was my little microsoft-love-advertising:D

F7a4a748ecf664f189bb704a660b3573
0
anubis 101 Aug 25, 2004 at 15:07

i steared clear of it for the same reason and i regreted it from the moment i seriously tried it out. for me it also was mono and the fact that C# is becoming the standard for gnome that lured me into giving it a try. also there are so many features that make it more than just a java/c++ hybrid (the comparison is actually totally wrong)

6ad5f8c742f1e8ec61000e2b0900fc76
0
davepermen 101 Aug 25, 2004 at 15:26

indeed. way off..

2b97deded6213469bcd87b65cce5d014
0
Mihail121 102 Aug 25, 2004 at 16:25

Tried it for 2 days. Can’t say i’m impressed, can’t say i’m dissapointed. I must check it out further…

7543b5c50738e23b200e69fe697ea85a
0
NomadRock 101 Aug 26, 2004 at 04:44

I go into a little more depth in the C# vs Java thread. I will develop in it for a little while at least because I want to be familiar with all of the moderately popular languages. I will probably end up switching between several languages as I do now. I highly advocate using languages for the applications they are best at :)

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Sep 30, 2004 at 05:40

I have come to really love C#. The .NET framework is so robust, so complete while at the same time providing some of the most outstanding documentation that I have ever seen (which is an interesting thing to say about Microsoft). It works well with much of the latest technologies including Speech Synthesis/Recognition, 3D Graphics API’s, Security, Cryptography, GUI Development, Reflection, and even Class Meta-data or Attributes.

C# is far from being a restrictive language like Java, Reflection actually affords great power and – when used sparingly – can actually replace the need for more complex and potentially time consuming work-arounds. C# is very much a “self-documenting” language, but without being as verbose as either Java or VB (though I don’t advise the literal application of this self-documenting approach). It cuts out the need for header files, and provides unparalleled compilation speeds. The Just-in-time compilation optimizes the assembly for the target machine and even operating system and the fact that it is a managed language opens the door to seamless cross-platform development and deployment and removes the need for the a host of if-defs and the maintenance of separate builds.

In the future, C# will even allow for seamless deployment of many games to the X-Box II and other consoles which will make use of XNA (well XNA is some-what ambiguous as to its actual purpose at the moment, but I take that as the jist of it). C# affords maintainability and rapid application development: two features that are imperative for any successful software solution… especial game development. Sadly the stigma of being “to slow for game development” is associated with both Java and C#, though Java has made great strides in this and C# has proven very efficient and fast with often very minimal differences in speeds from native code (other then the quick and dirty comparison tests which don’t even run long enough for the JIT time to be compensated for or which perform simple computations).

I have seen Axiom, a C# port of OGRE actually run faster then its predecessor, and this speed will only grew by leaps and bounds with the advent of generics in .NET 2.0. It was tested with Axiom and resulted in a 5X FPS increase!! (not to mention all of the repetitive code which could be eliminated). The only class that I have seen to be slow in comparison to other languages implementation is the ArrayList, but this is likely due to the boxing/unboxing and will therefore be remedied in .NET 2.0. Many find C# a turn off and consider it nothing more then a proprietary, windows-only Java clone (J++ anyone?), but I find that for the most part it is implemented *very* well in both Mono and DotGNU Portable.NET.

The only thing that I could ask for is an excellent cross-platform, LayoutManager-driven, GUI library similar to that found in Java. This is largely remedied with Portable.NET’s (and to a lesser extent Mono’s) excellent cross-platform support for WinForms. It is also provided with C# binding for other mature cross-platform GUI solutions including wx.NET (for wxWidgets) and GTK# (for GTK+). I have found that the Visual Studio.NET to be the best IDE that I have ever encountered - and short of a couple stability issues – as productive as Eclipse. You can even write Server-side web applications with the same language and even integrate them into the same solution!!

I have worked with C# for a while and have found that it has allowed me to accomplish any given task very easily and because Microsoft was smart enough to take a page out of the book of every successful programming language (from C++ to VB Java to Perl), it has resulted in an excellent solution for every programming task that I have worked with thus far. Its excellent support for interoperability with native languages and the ability to be used with any one of the literally hundreds of .NET language makes it a very flexible solution. It is my opinion that C# and the .NET framework, will make and excellent game development solution as soon as some of the stigmas associated with it are debunked. It provides the maintainability, powerful, flexibility, and cross-platform deployment that are so critical to game developers at the moment and I think with time the speed hit will either be overcome, or rendered insignificant in comparison to productivity gained by its use. I wish to test my hypothesis and determine if C# is in fact a feasible solution for game development by continuing my work on the RealmForge GDK and I think that others should at the very least do themselves a favor and keep an open mind and give C# a try.

D5a77f73a82eeeafd6fb30177f2b5cc5
0
Decibit 101 Sep 30, 2004 at 08:46

Migrating from C++ to C# is like a change of cars. I wouldn’t recommend it without a reason because you’ll be unable to continue your work until you get used to new coding style.

I have been programming C++ for several years. At frirst it was shocking that:

  1. I can’t control the creation and destruction of my objects.
  2. I have no access to my traditional APIs. (I thought C# was a mere extension of C++ before.)

Anyway C# is a new refreshing trend. It has an overwhelming library of standard classes (NET Framework) and some features that make it easier than its predecessor. I know several projects that utilize it as a scripting language and that is also the right way to do.

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Sep 30, 2004 at 10:20

@Decibit

  1. I can’t control the creation and destruction of my objects.
  2. I have no access to my traditional APIs. (I thought C# was a mere extension of C++ before.) [snapback]12172[/snapback]

Actually you can control creation and destruction using constructors, destructors, and optionally the IDisposable interface, other then that garbage collection deletes then when needed, but you can even force that by called GC.Collect. See the following article:

http://www.developer.com/net/csharp/article.php/3343191

Also you can access all of the traditional API’s through the use of p/invoke. You can check out Tao (a C# convenience binding for many popular media and game related libraries) as simple example of this, and you can do the same easily with any API. Also, the .NET framework provides a wealth of base classes that i have seen replace the need for many misc. native libraries very well. Its much more then just a scripting language if you invest some to learning many of its intricacies. But i definlty agree that you must evaluate wether the amount of time invested getting used to a new language is worth the new features. I think that it would be useful to at least demanding a working knowledge of a managed language or at the very least become familiar with it for the sake of WinForms (as i have many dev-teams just use it for the GUI end and tie it into the native C++ app logic module).

F0dbce482fb45bfe805dc8d1df75275b
0
GameWriter 101 Sep 30, 2004 at 11:10

C# is a bit like C (only a little bit more powerfull), it’s easyer than C++ but less powerfull, it’s ok, better first learn C before you start with C++ or C#, C is much better organised and C++ is a total mess better first learn to program C after that the step to C++ and/ or C# is much, much smaller! :)

They are all three recommended but still; first learn C before you start with the others! :wink:

40d3c1d8f291e5f90cc05985e00da115
0
Michael 101 Sep 30, 2004 at 12:39

@Decibit

  1. I can’t control the creation and destruction of my objects.
  2. I have no access to my traditional APIs. (I thought C# was a mere extension of C++ before.) [snapback]12172[/snapback]

Regarding 1, check out the “using” statement. For 2, see p/invoke etc.

D5a77f73a82eeeafd6fb30177f2b5cc5
0
Decibit 101 Sep 30, 2004 at 13:26

@xeonx

Actually you can control creation and destruction using constructors, destructors, and optionally the IDisposable interface…

Also you can access all of the traditional API’s through the use of p/invoke.

[snapback]12173[/snapback]

@Michael

Regarding 1, check out the “using” statement. For 2, see p/invoke etc. [snapback]12175[/snapback]

Thanks a lot. You are good coding (driving) instructors. Anyway my final examination will be some project in C#. I just don’t have one right now.

To GameWriter: I don’t think learning C before is a good idea. Learning a new language involves writing a lot of programs in that language. And C programmer may develop a set of habits that will harm him when he will migrate to C++ or C#.

F7a4a748ecf664f189bb704a660b3573
0
anubis 101 Sep 30, 2004 at 13:52

i believe that the choice of first language is relatively unimportant. mostlikely your first steps will be using only one function (main). after that you learn procedural programming and after that you start to grasp the benifits of OOP. in that respect i see an advantage of starting out with a language that supports pure procedural programming, c++ does that as much as c so it doesn’t matter which one you pick. c’s stricter rules might be of benefit to some and might only bother others

40d3c1d8f291e5f90cc05985e00da115
0
Michael 101 Sep 30, 2004 at 15:41

@anubis

i believe that the choice of first language is relatively unimportant. mostlikely your first steps will be using only one function (main). after that you learn procedural programming and after that you start to grasp the benifits of OOP. in that respect i see an advantage of starting out with a language that supports pure procedural programming, c++ does that as much as c so it doesn’t matter which one you pick. c’s stricter rules might be of benefit to some and might only bother others [snapback]12177[/snapback]

Surely you mean “C++’s stricter rules”? Or what exactly are you referring to?

F7a4a748ecf664f189bb704a660b3573
0
anubis 101 Sep 30, 2004 at 21:35

a) what does it matter here ?
b) i find that c is stricter when it comes to structure of code. maybe you don’t… that’s the point… it doesn’t matter if you start with c++, c, pascal or *insert language of your choice*

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Sep 30, 2004 at 22:19

@anubis

in that respect i see an advantage of starting out with a language that supports pure procedural programming

@GameWriter

C# is a bit like C (only a little bit more powerfull), it’s easyer than C++ but less powerfull, it’s ok, better first learn C before you start with C++ or C#, C is much better organised and C++ is a total mess better first learn to program C after that the step to C++ and/ or C# is much, much smaller! They are all three recommended but still; first learn C before you start with the others!

I agree with Decibit, it will take quite a time to learn two languages and right now he is taking a class in C#, not another language. But moreover, working your way from procedural to Object-oriented is the worst possible strategy for learning C#. These are two fundamentally different paradigms and this would be largely counter-productive. Object-oriented programming is much easier to grasp if you being designing and writing it. Also, is far more intuitive the procedural programming (though some developers may disagree if they are only comfortable with the later). It is human tendency to abstract and make association between things, specifically systems to real-world objects or “classes”. Furthermore, C# is a far easier language to deal with bar none. It is very self-descriptive as opposed to the often cryptic coding style in C++ and C and it is written from the ground up to cater to the strengths of all the most powerful languages instead of hacked onto and internally implement everything in hideous structures the way C++ does. it is true that the ability to program and think programmatic solutions to problems and break them down into units is a universal concept in programming that allows the developers to acquire new languages very quickly, but C# is a far more object-oriented language then C++ and C doesn’t even support this methodology.

F7a4a748ecf664f189bb704a660b3573
0
anubis 101 Sep 30, 2004 at 22:50

you won’t use much OOP in the beginning since you are only learning the basic concepts. still you have to code that way (that might not be a problem for you) and i know many people who started out with java and never understood how programming lanuages work because of that (low level is good sometimes). after you learned the basics you will learn about methods (in OOP). most likely you will program in a procedural way and not in an OOP way at first. again that makes me think that there is an advantage in starting out with a procedural language (how long you stick to it is a different question). if you read more carefully what i wrote you will notice that i said that my opinion is that it doesn’t actually matter what language you use, so i don’t see why you singled that sentence out…

edit : another thing that you should consider is that while you think OO your computer does not and so you should have a good understanding of how the machine operates at the low level.
anyways, i didn’t intend to turn this into a “what language is better” discussion. i don’t question that OOP is superior and i like C# very much. it’s just a matter of which approach will give you the better learning experience and i believe that, as you can’t ignore the low level aspect forever, you should start from the bottom and work your way up. others might think differently though

40d3c1d8f291e5f90cc05985e00da115
0
Michael 101 Sep 30, 2004 at 23:22

@anubis

a) what does it matter here ?
b) i find that c is stricter when it comes to structure of code. maybe you don’t… that’s the point… it doesn’t matter if you start with c++, c, pascal or *insert language of your choice*

I am wondering in which ways C is stricter in your opinion.
@anubis

you won’t use much OOP in the beginning since you are only learning the basic concepts.

OTOH your basic concept could very well *be* OO (which would be the case in Smalltalk, a language usually considered to be very intuitive to learn). The same line of argument can be applied to, for example, the functional or logic paradigm.

6e0b32504d31ae07efc17f3322cdb147
0
SnprBoB86 101 Oct 01, 2004 at 01:24

C# rocks

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 01, 2004 at 02:51

I don’t think that just because you start out learning object-oriented programming, you will ignore the procedural aspect of programming, if any developer is interested enough in developing for the .NET framework that he would consider how different code is optimized, he or she would look into MSIL… a procedural and low-level language similar to assembly. I know that in my school, we start out students with a IDE which allows for executable UML, and this use of object-oriented programming right-off-the-bat has been largely successful especially when compared to the students who took C++ and just had OOP effectively graphed on as another feature added to C. I have seen the results in action as I haved helped out with many of the classes and students respond well to the former approach. Also, I had started out learning strictly Object-oriented programming, and it is what peaked my interest in developing and has allowed to to grasp systems design far eaiser then my peers who havent. I am also not speaking strictly of C or C++ (though i would not have suggested progressing from one to the other), i mentioned the procedural paradigm, which includes *quite a few* languages. New programmers are lucky enough to be able to concentrate on the high-level design and on abstraction and other object-oriented techniques. But i don’t see why you are suggesting the extraction of OOP from the initial curriculum. It is extraction, because procedural programming is what you will find at the method level, its just *generally* much shorter or more concise then you would find in a non-OOP program. OOP is not only an excellent introduction to programming as a whole, it allows developers to concentrate on the big picture (which is so often missed) and work in parts to complete it. This is no C#-is-better thread (though i did post a hefty list of features), it is more my take on the usefulness of managed in all applications, including games!! Managed languages such as Java and C++.NET or even native C++ are all nearly equally applicable to this rationale.
@Michael

@anubis

a) what does it matter here ?
b) i find that c is stricter when it comes to structure of code. maybe you don’t… that’s the point… it doesn’t matter if you start with c++, c, pascal or *insert language of your choice*

I am wondering in which ways C is stricter in your opinion.
@anubis

you won’t use much OOP in the beginning since you are only learning the basic concepts.

OTOH your basic concept could very well *be* OO (which would be the case in Smalltalk, a language usually considered to be very intuitive to learn). The same line of argument can be applied to, for example, the functional or logic paradigm.

[snapback]12198[/snapback]

I agree, you could just as easily throw out the procedural… until you actually need it. The vast majority of programming that i have done over the last 2 years has largely dealt with data structures, data manipulation, systems design, UI, and API abstraction: all things which lend themselves very well to OOP. Even in something as “flow-centric” as a game engine, you don’t have to use a lot of what is traditionally procedural programming, a object such as the RenderEngine manages where it is at and what is being called or updated, it not just a giant loop with jump statements but the interaction between objects. Instead of procedures, the game is rendered and the world interacts according to rules defined in data, and it would be difficult to define something this dynamic and extensible in just procedural programming. It just goes to say that if you are going to be working with OOP more, then i would learn if first instead of navigate the difficult transition from procedural to OOP, and otherwise (such as if you are working with a scripting language like JScript.NET or python) you can learn it as an after thought. It doesn’t make sense to “work your way up to it”, especially if you wont be concentrating on the procedural side of things.

D5a77f73a82eeeafd6fb30177f2b5cc5
0
Decibit 101 Oct 01, 2004 at 03:20

@anubis

…anyways, i didn’t intend to turn this into a “what language is better” discussion. i don’t question that OOP is superior and i like C# very much. it’s just a matter of which approach will give you the better learning experience… [snapback]12196[/snapback]

Right. And the best case is when you are not stuck with a single language or :ohmy: with a single compiler. Turning your favourite programming environment into a religion totally freezes any learning process.

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 01, 2004 at 04:41

@Decibit

Right. And the best case is when you are not stuck with a single language or :ohmy: with a single compiler. Turning your favourite programming environment into a religion totally freezes any learning process. [snapback]12202[/snapback]

I’m not quite sure what you are referring to, C++ or the .NET framework. C# is just the most effective tool for the job in most of the scenarios that I have encountered. When I worked with data migration, the best tool was Perl so that is what i used, and when working with say writing macros its VBA (though I don’t like VB syntax too much) and if you are writing a driver its C. It’s always best to use whatever is most effective for a given task. I also mentioned Java and Python as being excellent languages and I hardly think that they (normally) use the .NET framework or are even compiled into MSIL. And actually there are technically many compilers for MSIL, 3 for each .NET language (Mono, Portable.NET, and MS .NET) and then an additional 3 for JIT’ing. I was advocating OOP and the dynamic nature of managed languages, not specifically C# and I had previously made a note of this.

D5a77f73a82eeeafd6fb30177f2b5cc5
0
Decibit 101 Oct 01, 2004 at 08:50

@xeonx

I’m not quite sure what you are referring to, C++ or the .NET framework. [snapback]12204[/snapback]

I spent years learning C and C++. At first I was very suspicious to newly appeared managed languages. But that doesn’t mean they aren’t effective tools. I wanted to say that anybody should at least try .NET Framework (C#) even for their traditional tasks. So I discovered for myself.

F7a4a748ecf664f189bb704a660b3573
0
anubis 101 Oct 01, 2004 at 11:28

xeonx : i think we are just seeing two approaches to the problem here.

I don’t think that just because you start out learning object-oriented programming, you will ignore the procedural aspect of programming

i didn’t claim that you did. i just said that i think that it is good to know how your computer operates first and then abstract from that. i’ve seen many students at my university who learned java in the first two terms and to them the computer is still some kind of magic box that you feed some java code and out comes the result. they have no clue what the computer really does at all and chances are that they will never get it. you might probably say that you don’t have to know about this when you start out but that is the exact point where i think differently. chances are that once you totally adjusted your mind to OOP programming you will leave out lower levels for the pure reason of lazyness

Also, I had started out learning strictly Object-oriented programming, and it is what peaked my interest in developing and has allowed to to grasp systems design far eaiser then my peers who havent.

software architecture wise you are right. you will learn those aspects better using OOP. there is no doubt about that. when designing a specific algorithm though you have to understand how you computer processes data and not how your brain does it. a good grasp of low level concepts is crucial here. most likely you will be taught about processor architecture, assembly and other low level stuff as well in your first terms in university. for me it makes sense to program the computer at a similar level at that time or students will plainly forget about it again.

I know that in my school, we start out students with a IDE which allows for executable UML,

so your school is teaching software design and not computer science ?

40d3c1d8f291e5f90cc05985e00da115
0
Michael 101 Oct 01, 2004 at 12:27

I think my point would be that you can get a “complete enough picture” both bottom-up and top-down.

7543b5c50738e23b200e69fe697ea85a
0
NomadRock 101 Oct 01, 2004 at 17:49

If they were truely teaching computer science rather than software design then we wouldn’t be working in real computer languages at all, but would be working with mathmatical proofs and lambda calculus. His school just had a different way to approach practical computer science.

I would really like to know which program allows executable UML. I think this could be quite fun, and perhaps a good way to introduce youngins to programming similar to how Logo Writer introduced me to programming. http://www.cattanach.org/logowriter.html

75c2c31bcca10ef21a86d5f5f49279d2
0
Tufty 101 Oct 01, 2004 at 20:09

On the games programming degree I just started, one of our first year modules is C/C++ Programming. It’s a 2-part module, and we’ve been told by our main tutor that we’re basically ignoring object oriented stuff until the second part. To the point of skipping the parts in the official course book that deal with it. Quite a few of the other students are confused already - I’m not, because I studied C last year, and I’ve been reading up on C++ since then. Having read through this thread now, I think it’d be better all round if we were covering object oriented programming from the start. Not least because then I wouldn’t be on the verge of falling asleep in lectures :P

Anyway, to get moderately back on topic, I’ve also looked into and used C# a bit. One of my side projects is a .net version of a web photo gallery program my friend is developing in Java. I like it a lot, the only thing preventing me from taking it further is lack of time at the moment.

40d3c1d8f291e5f90cc05985e00da115
0
Michael 101 Oct 01, 2004 at 20:52

@NomadRock

I would really like to know which program allows executable UML.

Maybe he is talking about Together.

7543b5c50738e23b200e69fe697ea85a
0
NomadRock 101 Oct 01, 2004 at 21:29

I am assuming you mean Borland’s Together.

It is difficult to tell exactly what this system is capable of beyond UML modeling. Can you actually use it to form simple complete programs without any code?

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 02, 2004 at 14:58

@NomadRock

I am assuming you mean Borland’s Together.

It is difficult to tell exactly what this system is capable of beyond UML modeling. Can you actually use it to form simple complete programs without any code?

[snapback]12255[/snapback]

or programming will allow for this kind of visual construction of programs, but it is still a difficult concept to grasp, and well the technology and interest just isn’t there right now. What Together does is allow you to create properties, methods and classes in the UML diagram and have them creating in your code-base, you can quickly update, prototype, refactor, or test complex systems (and even smaller applications) this way and it allows you to quickly and effectively assess the cohesion and coupling of different classes and systems. Together also automatically updates your UML diagrams according to changes made in your code-base. This is called “round-trip” code generation in other UML utilities, but Together does it real-time, instead of having to update periodically. It also *updates* or *refactors* your code instead of replacing it with an empty shell of a class (which is fairly useless when refactoring). The application that I was referring to is BlueJ, a free Java IDE which actually integrates the same features that I described for Together. The problem is that this is not a very full-featured IDE and is simplistic since it is designed students new to OOP or even programming altogether. It is very impressive though and allow students to quickly grasp OO concepts and has even been used in many cases for just designing or evaluating larger systems and since it is written in Java, it is fully cross-platform.

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 02, 2004 at 16:40

@anubis

i didn’t claim that you did. i just said that i think that it is good to know how your computer operates first and then abstract from that. i’ve seen many students at my university who learned java in the first two terms and to them the computer is still some kind of magic box that you feed some java code and out comes the result. they have no clue what the computer really does at all and chances are that they will never get it. you might probably say that you don’t have to know about this when you start out but that is the exact point where i think differently. chances are that once you totally adjusted your mind to OOP programming you will leave out lower levels for the pure reason of lazyness

Well if it is the case that students are too lazy to learn about something as critical as understanding how something works, then you would simply have C++ a prerequisite for the Comp-Sci degree. Learning the OOP side of things is the most important thing to prevent them from being lazy in though, so instead of having them learn C++ and just be lazy in Java class, it is better to force the practical on them if OOP is what they will indeed be working with in their intended vocation. I would suggest that Comp-Sci students learn C++ because they may actually have to work with it (at the very least interop or using JNI for Java), but if what you are considered about is that they learn about how the Run-time environment in managed languages interacts with the OS API, then they would take a Computer Seminar type class or an advnanced Java or C# class which deals with the MSIL or bytecode. This is useful for understanding the optimizations for a given language. But I hardly think that forcing on students of managed languages to memorize the Windows API for a C++ class is an effective strategy. When programming in C++ or C#, the main thing that differs from the practical standpoint is the API. 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#. If you understand programming, learning a specific API is trivial, but it is a very large task in C/C++. Also, you can learn C/C++ without learning about how it works under the hood, so all you would be teaching is the API and about pointers and unmanaged code (which you could learn about just as easily in a class on C++.NET).

My school doesn’t teach about software development, we have Computer Seminar, Intro CompSci, and AP Comp-Sci classes. If you wish to be a good programmer, you would research software-development, OOP, and how the low-level stuff works anyways. I think that classes should be geared towards students who are actually interested in the topic and intend to dedicate some time to it, not just for the lazy ones who don’t care about how things work. I think that teaching OOP helps to give an understanding of how the application works and allow them to focus on a more abstract level and then on the individual implements of its methods (which is the object-oriented standard for implementation). You will cover “procedural” programming to the extent that it is needed when implementing the needed methods. Why make things more difficult or harder to read and understand by inlining everything and using jump statements and procedural programming when you could simply factor them out to other methods. Procedural programming is covered to the extent that is needed when the first few programs are written involving just the Main() method (and after that for larger applications it is replaced by OOP because it becomes nothing more then cumbersome). Teaching OOP does not inherently cause students to not understand how the computer works, it just allows them to effectively design and implement a program that is easily maintainable. You could teach it in C++ just as easily. I think that skipping over sections of a programming book that deal with OOP (or application design) is a horrible method of teaching. I think NomanRock his it right on the head: at that point you are simply dealing with algorithms, not effective software development (which is the point of Comp-Sci or programming). If you intend to work strictly with low-level hardware design or programming then you won’t be taking OOP or managed language classes. If you are dealing with simple web-programming or other script-based solutions then you also wont likely be dealing with OOP.

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 02, 2004 at 16:41

It boils down to this: if you aren’t using OOP (very low-level or script-based development), and if you intent to develop a complex application larger then a couple printed pages of code, then you should. Now if you are learning OOP… then you should probably learn how to think that way. If you wish to delve into the advanced topics of how it is implemented then more power to you, but this is not as critical as actually being able to work with what you need to in your intended vocation. If programmers are too lazy to understand how a computer works then that is there style and they will have a difficult career ahead of them. 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. That’s like saying you should learn and develop an application in assembly or machine code before you work with C++, its just not very useful beyond giving you a different perspective and is very tedious, wasteful, and time-consuming way of doing even that.

F7a4a748ecf664f189bb704a660b3573
0
anubis 101 Oct 06, 2004 at 09:32

i just read an article in a german computer magainze about the usefulness of pascal in universitys today. the cited a study, comitted by the us board of didactics, on this very topic. they concluded that procedural programming should be first and even that starting with oop is harmful. sadly they only mentioned the study to support their pascal arguement and didn’t really go into depth about it. also i don’t know exactly what the us board of didactics is but i’m trying to find out. surely they have a web page

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 06, 2004 at 21:43

Other then citing one study for pascal, do you have any comments about my earlier posts. Procedural programming is simply a highly unorganized method which both lends itself to spaghetti code and it not practical for any kind of large application of system which is modeled after the real world. You will find procedural programming within the actual methods so i hardly see a problem with not learning it. You are mixing two different arguments. You said that because people learned java and didn’t understand their computer that they should have learned procedural first. Java is a high-level language which abstracts you from specific calls into the OS’s API. OOP is a way of organizing code to be easily maintainable, debuggable, and extensible. You can not cite members of a java class not understanding how their computer works to substantiate the argument that you should learn OOP first. Also you should probably know what an organization is and what the study covered before citing that. What exactly are you advocating anyway, learning procedural programming first, or learning a low level language like C/C++ first. If you intend to work with a particular style of programming i would suggest learning that first, especially if it is easier to learn and the alternative won’t even be used in your intended vocation. And if you check the US Department of Labors 2004 Statistics for “Average Anual Salaries in Software Development” you will find that Object-oriented programmer make $68K (the highest of all soft-dev jobs listed) while non-OOP programmers make $59K (the lowest of all listed jobs). This may tell you something about which you might want to be learning.

f you are interested in how valuable the big contenders in software development view learning OOP first (and they really should have the best judgment of the subject) then you can consider how Microsoft and IBM worked together in created a new college which caters exclusively to Object-oriented programming and does not even have simple procedural programming in the core curriculum. They go right into OOP because these two companies as well as their 2 best software developers have designated it critical to jump right into OOP and start thinking that way. Frankly the fact that a college was started by them with this specific intent is *very* supportive of learning OOP first to say the least!!

7543b5c50738e23b200e69fe697ea85a
0
NomadRock 101 Oct 06, 2004 at 22:14

Procedural programming is not highly unorganized any more than a bedroom is highly unorganized. It may often be that way, but it is the result of the person not the room or the language.

40d3c1d8f291e5f90cc05985e00da115
0
Michael 101 Oct 06, 2004 at 22:26

Fully agreed.

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).

F7a4a748ecf664f189bb704a660b3573
0
anubis 101 Oct 06, 2004 at 22:39

Other then citing one study for pascal,

it wasn’t on pascal it was on beginning with OOP vs. procedural programming in universities.

What exactly are you advocating anyway, learning procedural programming first, or learning a low level language like C/C++ first

i advocate learning procedural programming first.

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.

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)

And if you check the US Department of Labors 2004 Statistics for “Average Anual Salaries in Software Development” you will find that Object-oriented programmer make $68K (the highest of all soft-dev jobs listed) while non-OOP programmers make $59K

what exactly does that have to do with wether it is better to learn procedural and build OOP on that or the other way round ? i told you before, i’m not questioning OOP. why do you constantly keep attacking me on that ?

You said that because people learned java and didn’t understand their computer that they should have learned procedural first

i based that observation on operating system courses we had to take in later semesters. you could easily see that they had difficulties in understanding what happend because they had little understanding of what the computer actually did so far.

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. 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

ps : i’m really sorry that i couldn’t find an online verison of that study. i couldn’t even find the website of the us didactic boards (do they exist ? i don’t know… mike’s pawnshop has a website… so you’d expect them to have one :) ). anyway…

6ad5f8c742f1e8ec61000e2b0900fc76
0
davepermen 101 Oct 06, 2004 at 22:52

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.. :(

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 07, 2004 at 01:32

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.

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.

Cff67041e0c439e1beefef7de6f864fe
0
Nodlehs 101 Oct 07, 2004 at 03:12

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

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).

40d3c1d8f291e5f90cc05985e00da115
0
Michael 101 Oct 07, 2004 at 03:35

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:

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?

[…]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.cern.ch/ldeniau/html/oopc/oopc.html

Cheers,
Michael

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 07, 2004 at 06:43

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.

6ad5f8c742f1e8ec61000e2b0900fc76
0
davepermen 101 Oct 07, 2004 at 10:00

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.

F7a4a748ecf664f189bb704a660b3573
0
anubis 101 Oct 07, 2004 at 10:01

word

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 07, 2004 at 10:27

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.

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.

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??

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 07, 2004 at 10:42

@anubis

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

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
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
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.

F7b189fe0cae25cd27e41b5cebb10b3d
0
xeonx 101 Oct 07, 2004 at 10:46

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.

6ad5f8c742f1e8ec61000e2b0900fc76
0
davepermen 101 Oct 07, 2004 at 12:32

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.

F7a4a748ecf664f189bb704a660b3573
0
anubis 101 Oct 07, 2004 at 13:04

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

@anubis

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

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 ?

40d3c1d8f291e5f90cc05985e00da115
0
Michael 101 Oct 07, 2004 at 13:09

@xeonx

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” :)

6837d514b487de395be51432d9cdd078
0
TheNut 179 Oct 09, 2004 at 14:19

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.