Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Control Flow

2 (2.2%)

Arrays, Strings, Pointers, and References

8 (9%)

Functions

4 (4.5%)

Basic object-oriented programming

30 (33.7%)

A bit more advanced OOP (Composition, Operator overloading, Inheritance, Virtual Functions)

18 (20.2%)

Templates

8 (9%)

Other (Explain)

4 (4.5%)

Working with files?  (Streams)

15 (16.9%)

Total Members Voted: 89

[Siquo]

I once got warned by Toady for talking to people like Blank. So I won't.

[Blank Expression]

I do not understand your passive-aggressive post. His claim with regards to C# is nonsensical given the rest of his post and his assertion with regards to C++ is apparently based on information that is counterfactual. I have not made a judgement on him as a person; he is simply wrong.

Now, aside from passive-aggressive snark, do you have anything to actually contribute to the discussion?

[G-Flex]

I once got warned by Toady for talking to people like Blank. So I won't.

I'm pretty sure warnings are given based on behavior, not guilt by association.

[Willfor]

I once got warned by Toady for talking to people like Blank. So I won't.

I'm pretty sure warnings are given based on behavior, not guilt by association.

I think it was more of a "them's fightin' words in Texas" sort of thing.

[Siquo]

Now, aside from passive-aggressive snark, do you have anything to actually contribute to the discussion?

Nope, let's not

[Shades]

You will be very hard pressed to substantiate this. C++ has an antiquated memory model, requires the use of brutal hacks like the *_ptr classes from Boost, and nearly demands leaky abstraction via friend, MI, and other methods of tangling the class hierarchy. Languages on the .NET framework, by and large, lack these problems.

You don't need to use leaky abstraction to have sensible memory models, nor is C++'s model antiquated, a term that really doesn't make sense in this situation. .NET has certainly improved of late, although there were major issues with earlier versions if you wanted to write stable code, however I personally still find it much more clunky than using boost or stl equivalents much of the time. Although some things are handled much better, and the deep class hierarchy does push heavily for object methodology which is certainly a good way to learn to code well.

As well, I find it very interesting that you make the curiously irrational claim that C# is not a cleaner model, but Java is. You are aware, I hope, of the similarities between the two (damned near identical in most aspects that matter to a novice)?

Although it's true to a novice the api's are very similar for a lot of the code there is enough difference, especially in the graphical side of it which is often of more interest to novices, where java provides a much cleaner model to learn from. Python of course is a different style of language but allows a lot of power in clean and easy to understand ways.

I have to admit that recently I've been moving towards less use of object hierarchies in favour of light weight objects in a more data driven style of development. Of course this is generally pushed with the need I have for parallelism at work. I've also been looking at more functional languages such as erlang so that has also coloured my recent views on development.

I apologise if my previous posts came across brash to you I never meant to cause offence, my opinion mearly differs from yours.

[Blank Expression]

You will be very hard pressed to substantiate this. C++ has an antiquated memory model, requires the use of brutal hacks like the *_ptr classes from Boost, and nearly demands leaky abstraction via friend, MI, and other methods of tangling the class hierarchy. Languages on the .NET framework, by and large, lack these problems.

You don't need to use leaky abstraction to have sensible memory models,

You are conflating two points. C++'s memory model has nothing to do with leaky abstractions. C++ not being fundamentally object-oriented is. Event-based programming is onerous in C++. Dealing with interacting objects is a chore, and as I noted, it is rare to find a nontrivial C++ application that isn't screwing itself into the ground with MI or happily fucking data encapsulation with friend members. (For example, I would look at the Unreal Engine, if you can find a code license--that is considered to be some of the finer C++ out there, and it is replete with broken abstraction in places it just shouldn't be.) In C++, unless you are a Boost wizard, you are writing "object-oriented" code that is in truth essentially procedural-with-objects. This is true under-the-hood in .NET code as well...but you never see it there, and as such the abstractions hold up much more cleanly.

(One could mention the "internal" modifier in .NET as an analogue to "friend", and there would be some truth to that, but for obvious reasons it's nowhere near as dangerous or silly as "friend".)

nor is C++'s model antiquated, a term that really doesn't make sense in this situation.

For any sort of desktop-driven development, it certainly does make sense to call the C++ "deal with it yourself" model of memory management "antiquated.". This is 2011. Generational garbage collection is spectacularly effective in the general use case and only tremendously effective in most others. It is a rare desktop application that requires memory management that is not eminently suited to standard generational garbage collection. Hell, it's even fast enough to do so on consoles (XNA) and the iPhone (Monotouch) without significant issues. The computer is better at handling stupid, detail-oriented tasks than the programmer driving the computer. Let it do what it is good at.

.NET has certainly improved of late, although there were major issues with earlier versions if you wanted to write stable code, however I personally still find it much more clunky than using boost or stl equivalents much of the time. Although some things are handled much better, and the deep class hierarchy does push heavily for object methodology which is certainly a good way to learn to code well.

Please provide citations of duplicable instability that occurs in normal programming practice, because otherwise I am comfortable with stating that your claim here is counterfactual. .NET has not had stability problems of any significant note, ever, in its history. One thing Microsoft does do very well is anything related to their development stack. I know a number of developers at MS DevDiv, and they're incredibly sharp.

As for Boost, etc. versus the BCL--this is much more of a "taste" thing, but the fact that Boost must even exist is damning. Boost::Bind should never have been necessary. The language lacks what modern programming practices consider very standard features. Some fakery exists to pretend that this isn't true, and C++0x or whatever they're calling it now might eventually take steps to address this, but this is now and C++0x is still a pipe dream for standard usage. I would find it interesting that you would term the use of the STL less "clunky" than .NET, because the libraries are virtually identical in implementation and exposed API. The .NET BCL libraries are iterative developments on top of Java Collections, which itself cribbed from the STL.

As well, I find it very interesting that you make the curiously irrational claim that C# is not a cleaner model, but Java is. You are aware, I hope, of the similarities between the two (damned near identical in most aspects that matter to a novice)?

Although it's true to a novice the api's are very similar for a lot of the code there is enough difference, especially in the graphical side of it which is often of more interest to novices, where java provides a much cleaner model to learn from. Python of course is a different style of language but allows a lot of power in clean and easy to understand ways.

Please substantiate this claim with examples. I am skeptical of this claim, because .NET provides the fantastic XNA Framework, which is beyond simple to use--simpler even than PyGame. If you need a little more flexibility, there's SlimDX - or there's OpenTK, which is head-and-shoulders above JOGL on the Java side of things.

Seeing as how JNI et al. are absolute creeping horrors compared to P/Invoke, I fear that this one might be hollow, too.

I apologise if my previous posts came across brash to you I never meant to cause offence, my opinion mearly differs from yours.

It's not about disagreement, and I'm not offended. It's about everything you're saying being rather counter to what I've encountered in my programming career. I do Java development professionally today, but I've worked in .NET and Mono (including some contributions to Mono) in the past. For the most part, these are not really "opinion" things you're trotting out; you are making claims that should be substantiable, and I'm looking forward to seeing you do so.

[Virex]

The problem with C/C++/Fortran/Algol is of course that it's very easy to shoot yourself in the foot. If you're the kind of person that learns best if you can get down to the metal and likes learning the inner workings of a system by tracking down illusive bugs and memory leaks, then by all means, try them (though a base course in assembly might also help in that case. It certainly helped me to understand pointers). But anything with a good garbage collector and a higher level of type-safety is going to make it easier to pick up the basics. (My only criticism of C#, Java, Python and many other languages would be that it's often not obvious when you're dealing with a value or a pointer, so it's harder for a newbie to predict if their function's going to alter whatever they pass to it or not. In Java there's the rule of the thumb that if you've got something with a capitalized type, you've got a reference, but even then things sometimes get wonky. Take for example an Integer, is that passed by value or by reference?)

[Blank Expression]

(My only criticism of C#, Java, Python and many other languages would be that it's often not obvious when you're dealing with a value or a pointer, so it's harder for a newbie to predict if their function's going to alter whatever they pass to it or not. In Java there's the rule of the thumb that if you've got something with a capitalized type, you've got a reference, but even then things sometimes get wonky. Take for example an Integer, is that passed by value or by reference?)

I do not mean to pick on you, but after reviewing this thread, this is the sort of common misconception that does not happen when you understand your tools. It's actually not a hard question, and isn't unclear or non-obvious. Java never passes by reference, because "Java is Pass-by-Value, Dammit!". (C# exhibits the same behavior by default, but you can explicitly pass-by-reference - that is, change the actual variable passed in - with the ref or out keywords. There are ways within very deep-magic C# to cause the compiler to pass-by-ref without the ref or out keywords, but nobody does it except in places You Really Don't Need To Be.)

It comes from not understanding that a variable holds a reference, not is a reference, to a reference type. The only difference between a pointer and a reference is that a reference can only indirect to a valid object or to null. Just like C, where you have an int* variable, you have a variable that holds a reference.

I do agree with the rest of your post, with the caution that many (if not most) people who think that they learn better by "getting down to the metal" are simply wrong, and will burn themselves out.

[lordnincompoop]

This is more of a side-question I guess, but BE could you explain to me how/why the friend operator is so dangerous?

[Siquo]

Or explain to me why it is useful? I haven't found a use for it yet.

[Virex]

(My only criticism of C#, Java, Python and many other languages would be that it's often not obvious when you're dealing with a value or a pointer, so it's harder for a newbie to predict if their function's going to alter whatever they pass to it or not. In Java there's the rule of the thumb that if you've got something with a capitalized type, you've got a reference, but even then things sometimes get wonky. Take for example an Integer, is that passed by value or by reference?)

I do not mean to pick on you, but after reviewing this thread, this is the sort of common misconception that does not happen when you understand your tools. It's actually not a hard question, and isn't unclear or non-obvious. Java never passes by reference, because "Java is Pass-by-Value, Dammit!". (C# exhibits the same behavior by default, but you can explicitly pass-by-reference - that is, change the actual variable passed in - with the ref or out keywords. There are ways within very deep-magic C# to cause the compiler to pass-by-ref without the ref or out keywords, but nobody does it except in places You Really Don't Need To Be.)

It comes from not understanding that a variable holds a reference, not is a reference, to a reference type. The only difference between a pointer and a reference is that a reference can only indirect to a valid object or to null. Just like C, where you have an int* variable, you have a variable that holds a reference.

I do agree with the rest of your post, with the caution that many (if not most) people who think that they learn better by "getting down to the metal" are simply wrong, and will burn themselves out.

I don't want to return the favor, but my point was exactly that you can't expect that people that are learning know that an integer variable holds an integer and an object variable holds a reference to an object. Someone who is completely new to programming would expect the variable to be an object instead of point to an object, in which case pass by value would mean the object itself is copied. Also, saying that a variable isn't an object but refers to an object is pretty cryptic for most beginners and it's often not fully explained what that means. It would seem to someone learning to program that the two behave differently, while in fact it's consistent. Hence my claim that from a didactic point of view, the standard ALGOL-like syntax most programing languages use is not ideal for people who're new to programming.

[Blank Expression]

This is more of a side-question I guess, but BE could you explain to me how/why the friend operator is so dangerous?

Put shortly: don't violate encapsulation unless you have a damned good reason for it. The friend keyword is an ugly hack to expose private members to other objects. If your object model is horked enough that this is necessary, your design is flawed and should be refactored. Your objects shouldn't give a damn about the implementation details of other objects so long as all objects adhere to the defined contract between them.


In short:

1. Sometimes friend is the only way to do something. The cases where this is true are few and far between. I actually can't think of one.

2. Sometimes friend is the cleanest way to do something. I can't think of one of these either, but I concede that they might exist.

3. Sometimes friend is used as a patch to connect classes within a poorly constructed codebase. If this happens, punch yourself in the pills and fix your code.

The people who should use friend are the people who already know when you do and do not use friend. Much like the people who should be using C++, who themselves are few and far between.



(Friend also is a problematic concept for developing verifiable code. There may be some maths wizard who can find a way to verify code with arbitrary encapsulation violation, but one of the stated reasons for not providing friend in .NET languages that seek verifiability is this problem. Internal in C#, on the other hand, encapsulates at the namespace level, and while not ideal is less ugly than an arbitrary list of friends who can play with your members--it also does allow for verifiable code.)

Or explain to me why it is useful? I haven't found a use for it yet.

Unit testing comes immediately to mind, though I am still skeptical of the unit testing paradigm as a whole. (This would be case #3 above, IMO.)

I don't want to return the favor, but my point was exactly that you can't expect that people that are learning know that an integer variable holds an integer and an object variable holds a reference to an object. Someone who is completely new to programming would expect the variable to be an object instead of point to an object, in which case pass by value would mean the object itself is copied. Also, saying that a variable isn't an object but refers to an object is pretty cryptic for most beginners and it's often not fully explained what that means. It would seem to someone learning to program that the two behave differently, while in fact it's consistent. Hence my claim that from a didactic point of view, the standard ALGOL-like syntax most programing languages use is not ideal for people who're new to programming.

I can't think of a procedural language that doesn't do this; even functional languages use the symbol table in a mostly identical way. Doing it otherwise would be sheer hell--you'd be value-copying every time you went "a = b" for a structure or object.

You're assuming a fault in the language when instead it is a fault in the rafts of poorly-written tutorials out there. No decent book written by a competent professional (Head Start C#, for example, or the Accelerated books in C++) will conflate the terms in the way you're positing. If your hypothetical beginner is a derp who goes to the nearest poorly-written Internet tutorial, then I can see your point, but a beginner who does that has critical thinking skills he needs to work on before he writes code.

Step 1: Understand your problem.
Step 2: Understand your tools.
Step 3: Write code.

This is as true for a complete beginner as it is for somebody who's been doing it for twenty years. You cannot skip Step 2 because you're new. You might try, but that's not the language's fault, that's yours.

[Siquo]

Step 1: Understand your problem.
Step 2: Understand your tools.
Step 3: Write code.

When learning a new language, I do these steps exactly the other way around. 

[Blank Expression]

Which is problematic for obvious reasons. Read about what you're doing. Understand how it works. Writing code without a purpose may luck into doing something useful, but discipline and practice are how you turn from a code grinder into a programmer.

The perceived problem with the aforementioned programming languages that Virex mentioned is one I am sure is widespread, and exists solely because of willful ignorance. It doesn't need to be. It's extremely well-documented and covered in depth in good learning resources.