I don't think I've been to work consecutively for 10 weeks since I was 20.
I barely make it 4 weeks without having to take a 3 day weekend. The beginning of the year is rough in the at we have almost no holidays.
Hallmark needs to get on that.
How do you actually accrue any vacation time taking days off that often?
I get 15 days per year, and I would probably need 9 of them to fill in the holes for one 3-day weekend per month. That only leaves 6 more days per year, which I guess isn't that bad, since that's 6 leftover after taking a holiday every single month...?
Simple solution: declare all copy constructors & assignment functions, but never define them. This eliminates 4) and you can get rid of 5) by using the simple rule of "destructors are always made virtual if you have a virtual function"
I think the main thing we need to remember too is that Computer Science <> Software programming. It's Computing Science. Turing machines, AI, logic, etc are concepts not necessarily solvable problems by writing code. I think in my higher level classes, I was writing LESS code than in my earlier ones. I was doing more math but less programming.
I think (luckily) my university got it right. They have the distinction of Software Engineering and Computer Science. They treat the credits the same for graduation but if you want to emphasize on coding, you can.
I don't think I've been to work consecutively for 10 weeks since I was 20.
I barely make it 4 weeks without having to take a 3 day weekend. The beginning of the year is rough in the at we have almost no holidays.
Hallmark needs to get on that.
How do you actually accrue any vacation time taking days off that often?
I get 15 days per year, and I would probably need 9 of them to fill in the holes for one 3-day weekend per month. That only leaves 6 more days per year, which I guess isn't that bad, since that's 6 leftover after taking a holiday every single month...?
I don't have long vacations. I rarely take more than a day or two at a time.
I get 5 floating holidays a year, 5 holidays, and 2 weeks vacation a year.
I actually lost a holiday this year because apparently new year's landed on this year rather than last year, so I only (technically) get 4 floating holidays and 6 holidays.
Though I did not personally learn Java in school, I learned a languages that were very similar early in my career that, in the context of beginner-ism, were similar enough, C# and ActionScript 3
C++ has no business in introductory programming courses
C is fine but Java is just plain easier, and as he said you can get farther with less effort which is important if you are dealing with true novices
cranking on C files to make a command line tool is boring with a capital B. at least with Java you can put something in a window
I've been programming for over almost ten years and I still don't feel like I know enough about C++ to comprehensively write an object oriented program with breaking major rules, because C++ is as much about understanding C++ as it is about understanding program design, where as in Java the runtime basically takes care of you soup to nuts
C++ is a war crime of a language to be used only in the hands of they who are knowledgeable
one must walk before they can learn to run
Because in order to teach Java, you really have to understand objects, classes, and references from the get go. There's no getting around it because you're lazy. People will get ultramegafucking confusing because there's objects everywhere and you'll have to unlearn shit before you relearn it because they'll go, "Oh don't worry about that, it's not important"
I seriously disagree. It blows my mind that people see things this way.
You have to understand objects and classes? What about the ancient codex of banal knowledge you need about C++ to write anything worthwhile that extends beyond main()?
Objects and classes ain't hard. Except in C++.
So you say, well then just teach C. OK. Well, after they've learned how to add foo and and bar into foobar, then what? Straight to buffers and arrays? I think not.
The amount of information you need about objects in Java to do basic procedural programming can be easily abstracted away by any teacher, and there's an easy gradient into those intermediate and advanced subjects. I don't think the same can be done for C++. You're out of the frying pan and into the fire as soon as you start writing objects.
You're out of the frying pan and into the fire as soon as you start writing objects.
Expand that. You don't have to deal with the heap at all writing classes in C++. You could write a completely procedural program and use classes as really fancy structs. Sure you've got to deal with copy constructors and all that to do it right. But I've never met anyone, even in the professional world who "does it right."
Except for Ethea.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Why do I discourage teaching C++ in the context of intro? Here is a paraphrased email I sent to a colleague about the subject:
Good C++ is "all or nothing". That is, all the language features of C++ bleed together to create a cohesive whole. There is little-to-no separation of programming concepts that allow a student to incrementally build up programs. To build a "good" C++ program (read: idiomatic, type-safe, memory-safe), you need to pull together many concepts.
For example, to discuss dynamic dispatch, we need to:
(1) Talk about pointers and references because dynamic dispatch only occurs through pointers and references.
(2) With pointers, we need to talk about lifetime management. Who "owns" a pointer? And who is responsible for cleaning up that memory?
(3) Combining pointers and classes, we need to discuss lifetime management within classes. The destructor is responsible for this.
(4) However, this is insufficient to guarantee memory safety because the destructor is not the only special member function that deals with lifetime management. We must also introduce the copy constructor and the copy assignment operator to ensure that students author classes that are memory safe. In the process, we will need to discuss references (if we haven't done so already), copying vs. reference semantics in C++ (i.e., when the copy constructor is invoked), const, and operator overloading. This is known as the rule of three.
(5) Finally, if we talk about dynamic dispatch, we will need to also to mention virtual destructors and when they are necessary.
If you skip any one of these steps, then you run the risk of your students going out into the wild and writing memory unsafe code. This is what makes C++ a complicated language, but also a powerful language because C++ objects can act just like primitive types wrt functionality, esp. memory management. But this is why C++ is not a good beginning language. There's a lot of cruft you must go through in order to do things right.
Unless you need to teach C++11 and now you have to cover the rule of five and all the move semantics.
Given that I can barely get university instructors to talk about memory safe C++ as it is, talking about how C++11 shakes it up is a futile effort.
That being said, explicit memory allocation (i.e., fine-grained control of where objects are allocated) is the soul of C++. If you understand these mechanics, then you understand C++.
Pretending students getting in to the real world are going to make apps with Java that doesn't use some unsafe JNI is just as ignorant as needing to figure out the basics of memory management which should be covered as a precursor to data structures.
There isn't really a dispute about this sort of material being covered. The dispute is that if it is prudent and appropriate to do so in an introductory class. Every intro teacher wants to teach the world, but with only 10-15 weeks, you can only cover so much before you are overloading your students.
To me an intro course is all about basic structures and problem solving by thinking programmatically. In that context any language works fine; its perfectly okay to write functional c++ code without worrying about dynamic dispatch.
In that same vein, its an intro. They're not going to get a job after one class.
I used to think this. But I put a lot more emphasis these days on being true to the language that you are using which puts necessary (although not necessarily game-breaking) constraints on your presentation. One example of this is in the Java objects-late approach, you typically write programs in a procedural style consisting of static methods. This is not how idiomatic Java is written, but it allows you to avoid the difficulties of OOP early on.
In contrast, I think functional C++ is perfectly fine (and this is how Stroustrop teaches C++ in his text) but it isn't necessarily true to the language. You eventually need to use pointers, explicit allocation, and then classes. If you don't believe in these things (and I necessarily don't in the context of C++), then you have downstream clients of your students, i.e., instructors further in the curriculum, that need to know these concepts and expect them to be introduced earlier.
This is why I say there isn't a perfect language for teaching because no mainstream language (save perhaps Racket with its language levels) has staged its features in such a way that they parallel how you might want to present them in an introductory class. You'll always have to compromise between staying true to the language and developing a clean presentation for your students.
Simple solution: declare all copy constructors & assignment functions, but never define them. This eliminates 4) and you can get rid of 5) by using the simple rule of "destructors are always made virtual if you have a virtual function"
This has two problems. (1) This is akin to the "magic words" of Java, e.g., "public static void main(String[] args)" is the signature of the main function. You are forcing the students to write magic code that they "don't need to understand the details of" in order to make progress. (2) This is semantically incorrect behavior. The real higher-order bit is that the copy constructor, copy assignment, and destructor all manage the memory of a particular object in a consistent way. If the destructor exists, then the other two must exist to be consistent. Your alternative introduces the constraint that an object of this particular class can never be passed by-value or copied via assignment which impose unnecessary and arbitrary restrictions on how objects can be used in a program.
I've seen instructors make compromises similar to this, and I understand why they do it. However, it just reinforces my point that C++ is not a suitable first language rather than make it usable.
@TwitchTV, @Youtube: master-level zerg ladder/customs, commentary, and random miscellany.
You're out of the frying pan and into the fire as soon as you start writing objects.
Expand that. You don't have to deal with the heap at all writing classes in C++. You could write a completely procedural program and use classes as really fancy structs. Sure you've got to deal with copy constructors and all that to do it right. But I've never met anyone, even in the professional world who "does it right."
Except for Ethea.
Virtual methods, statics, object destruction, interactions between C types/handles and C++ code when necessary
these are all reasonably advanced things you kinda need to know if you want to do what I will casually refer to as "real programming" in C++
all more complicated to some extent than in Java IMO
I think the main thing we need to remember too is that Computer Science <> Software programming. It's Computing Science. Turing machines, AI, logic, etc are concepts not necessarily solvable problems by writing code. I think in my higher level classes, I was writing LESS code than in my earlier ones. I was doing more math but less programming.
I think (luckily) my university got it right. They have the distinction of Software Engineering and Computer Science. They treat the credits the same for graduation but if you want to emphasize on coding, you can.
This is true. And I'm a theoretician by trade, so I'm sympathetic to the viewpoint that computer science transcends programming. However, the reality is that the majority of your computer science graduates will be employed by the software industry. And if they are not employed as developers, they are working with developers in a way that requires some knowledge of programming. It thus behooves computer science educators to "get the programming parts of the curriculum right", for whatever vague notions of correctness we have for that.
@TwitchTV, @Youtube: master-level zerg ladder/customs, commentary, and random miscellany.
You're out of the frying pan and into the fire as soon as you start writing objects.
Expand that. You don't have to deal with the heap at all writing classes in C++. You could write a completely procedural program and use classes as really fancy structs. Sure you've got to deal with copy constructors and all that to do it right. But I've never met anyone, even in the professional world who "does it right."
Except for Ethea.
Virtual methods, statics, object destruction, interactions between C types/handles and C++ code when necessary
these are all reasonably advanced things you kinda need to know if you want to do what I will casually refer to as "real programming" in C++
all more complicated to some extent than in Java IMO
That's why I said "introduction to OOP" and not "be fully versed in all the ins and outs of C++ before using Java"
Java has similar concepts and even more snafus. Like objects getting dereferenced because of weird garbage collection issues. Though that was a symptom of something strange in 1.4 or earlier, I can't recall.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
I find people getting angry about C++ being used in place of Java in the same vein as some old graybeard going, "I see you defined int there, you should keep in mind that it's 32 bit and not 8 bit in this instance so you really should explain what you're talking about when you say int, ha ha ha."
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
You're out of the frying pan and into the fire as soon as you start writing objects.
Expand that. You don't have to deal with the heap at all writing classes in C++. You could write a completely procedural program and use classes as really fancy structs. Sure you've got to deal with copy constructors and all that to do it right. But I've never met anyone, even in the professional world who "does it right."
Except for Ethea.
Virtual methods, statics, object destruction, interactions between C types/handles and C++ code when necessary
these are all reasonably advanced things you kinda need to know if you want to do what I will casually refer to as "real programming" in C++
all more complicated to some extent than in Java IMO
That's why I said "introduction to OOP" and not "be fully versed in all the ins and outs of C++ before using Java"
Java has similar concepts and even more snafus. Like objects getting dereferenced because of weird garbage collection issues. Though that was a symptom of something strange in 1.4 or earlier, I can't recall.
Every language has corners. The things that you are describing with Java are relatively deep corners. C++ has its own deep corners and unfortunately some shallow corners that you need to be aware of in order to write good C++ code.
I find people getting angry about C++ being used in place of Java in the same vein as some old graybeard going, "I see you defined int there, you should keep in mind that it's 32 bit and not 8 bit in this instance so you really should explain what you're talking about when you say int, ha ha ha."
The troubling stuff about C++ in the context of intro isn't silly language lawyer stuff like that. It is fundamental language issues that if the student is not aware of will lead them to write memory unsafe code. In the context of intro, these are problems that most people have deemed complex enough to push out to later classes.
Kambing on
@TwitchTV, @Youtube: master-level zerg ladder/customs, commentary, and random miscellany.
"good C++ code" is different from "students learning how to program" :rotate:
Just like I said, Java is an object based language. Starting with java and ignoring objects is like learning to drive a car but don't know how to turn a wheel.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
"good C++ code" is different from "students learning how to program" :rotate:
Just like I said, Java is an object based language. Starting with java and ignoring objects is like learning to drive a car but don't know how to turn a wheel.
And like I mentioned before, objects cannot be entirely ignored in any reasonable intro class. What is done instead is that object use is introduced early but object design is deferred.
@TwitchTV, @Youtube: master-level zerg ladder/customs, commentary, and random miscellany.
Simple solution: declare all copy constructors & assignment functions, but never define them. This eliminates 4) and you can get rid of 5) by using the simple rule of "destructors are always made virtual if you have a virtual function"
This has two problems. (1) This is akin to the "magic words" of Java, e.g., "public static void main(String[] args)" is the signature of the main function. You are forcing the students to write magic code that they "don't need to understand the details of" in order to make progress. (2) This is semantically incorrect behavior. The real higher-order bit is that the copy constructor, copy assignment, and destructor all manage the memory of a particular object in a consistent way. If the destructor exists, then the other two must exist to be consistent. Your alternative introduces the constraint that an object of this particular class can never be passed by-value or copied via assignment which impose unnecessary and arbitrary restrictions on how objects can be used in a program.
I've seen instructors make compromises similar to this, and I understand why they do it. However, it just reinforces my point that C++ is not a suitable first language rather than make it usable.
It's much easier than properly implementing copy construction and assignment. Alternately, you can get them for free if you never store a raw pointer and instead use the STL objects,. A lot of the time though allowing copy construction is just asking for pain, most objects don't need to be copyable, and pass by value is so expensive it's a good idea to learn to not do that. Plus it emphasizes memory management, which is what most people need experience with, in exchange for telling students to "just write classname(const classname&); void operator =(const classname&); to tell the language to disable assignments"
"good C++ code" is different from "students learning how to program" :rotate:
Just like I said, Java is an object based language. Starting with java and ignoring objects is like learning to drive a car but don't know how to turn a wheel.
And like I mentioned before, objects cannot be entirely ignored in any reasonable intro class. What is done instead is that object use is introduced early but object design is deferred.
There's almost no semantic difference between "butt()" and "poopy.butt()"
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Sigh... Deployed out a broken build because I forgot to add the "skinny" profile in maven. Now I have to re-run Maven (45 minutes) send it out to our deployment guy (15 minutes) and have him get it back up and running.
Simple solution: declare all copy constructors & assignment functions, but never define them. This eliminates 4) and you can get rid of 5) by using the simple rule of "destructors are always made virtual if you have a virtual function"
This has two problems. (1) This is akin to the "magic words" of Java, e.g., "public static void main(String[] args)" is the signature of the main function. You are forcing the students to write magic code that they "don't need to understand the details of" in order to make progress. (2) This is semantically incorrect behavior. The real higher-order bit is that the copy constructor, copy assignment, and destructor all manage the memory of a particular object in a consistent way. If the destructor exists, then the other two must exist to be consistent. Your alternative introduces the constraint that an object of this particular class can never be passed by-value or copied via assignment which impose unnecessary and arbitrary restrictions on how objects can be used in a program.
I've seen instructors make compromises similar to this, and I understand why they do it. However, it just reinforces my point that C++ is not a suitable first language rather than make it usable.
It's much easier than properly implementing copy construction and assignment. Alternately, you can get them for free if you never store a raw pointer and instead use the STL objects,. A lot of the time though allowing copy construction is just asking for pain, most objects don't need to be copyable, and pass by value is so expensive it's a good idea to learn to not do that. Plus it emphasizes memory management, which is what most people need experience with, in exchange for telling students to "just write classname(const classname&); void operator =(const classname&); to tell the language to disable assignments"
Yeah, like I said, it is a compromise. But you need to understand what you are giving up when you go down this road. In particular, you are giving up the discussion of manual memory allocation (not lifetime management, but instead where objects are allocated) in C++ which is one of the greatest strengths of the language. And (in my opinion) is the more important concept for students to learn when they work with C++.
For similar reasons, I dispute that copy construction/pass by value is something you should avoid. Again the great strength that C++ is manual memory allocation. In OOP you have lots of cases where you will create small, short-lived objects that ought to be copied rather than passed by reference.
@TwitchTV, @Youtube: master-level zerg ladder/customs, commentary, and random miscellany.
"good C++ code" is different from "students learning how to program" :rotate:
Just like I said, Java is an object based language. Starting with java and ignoring objects is like learning to drive a car but don't know how to turn a wheel.
And like I mentioned before, objects cannot be entirely ignored in any reasonable intro class. What is done instead is that object use is introduced early but object design is deferred.
There's almost no semantic difference between "butt()" and "poopy.butt()"
And that's why people are generally fine with this approach. As background, many curriculums defer object design and do this sort of bastardized presentation Java because the last decade of computer science education was spent experimenting with an "objects-first" approach. This produced students that "understood" objects (but not their mechanics) but could not program themselves out of a wet paper sack. Like a pendulum, we've swung back to the Pascal days of yore in response where we emphasize programming-in-the-small over object-oriented design.
Unfortunately, the tools we teach have not caught up with this trend as industry and what is in vogue typically lags a decade behind the cutting edge (for both good and bad reasons).
(As an aside, you would be surprised at the number of students that don't grok the differences and similarities between free-floating functions and method calls.)
@TwitchTV, @Youtube: master-level zerg ladder/customs, commentary, and random miscellany.
There's almost no semantic difference between "butt()" and "poopy.butt()"
I had no problems with the intro to programming course I held in Ruby. Showed classes and objects and how they worked, never actually went into making your own classes.
Though we'll see what they think about PHP and having to do stinky(poopy(butt))) instead. PHP. :rotate:
If the goal is to give beginning students the language the need the least amount of meta knowledge to use, obviously we should teach programming using php.
That way you don't even need to deal with whether or not basic stuff even works until intermediate, and when you hit advanced, you go back to assuming it will be broken regardless of what you do.
I'd figure this aspect of java oriented programming is going to have less 'can't program out of a wet paper bag' and more 'drools on themselves and spins in circles'
Honestly they should be tackling memory far before they get that far either way. Because if you don't understand bits and bytes and allocation you're going to be fucked going any further. Best to weed them out early either way.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
If the goal is to give beginning students the language the need the least amount of meta knowledge to use, obviously we should teach programming using php.
That way you don't even need to deal with whether or not basic stuff even works until intermediate, and when you hit advanced, you go back to assuming it will be broken regardless of what you do.
Yeah, can't be bothered with learning types. That's too complicated, let's get to that later.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
If the goal is to give beginning students the language the need the least amount of meta knowledge to use, obviously we should teach programming using php.
That way you don't even need to deal with whether or not basic stuff even works until intermediate, and when you hit advanced, you go back to assuming it will be broken regardless of what you do.
Yeah, can't be bothered with learning types. That's too complicated, let's get to that later.
"Professor, I have this weird error. How do I fix it?"
If the goal is to give beginning students the language the need the least amount of meta knowledge to use, obviously we should teach programming using php.
That way you don't even need to deal with whether or not basic stuff even works until intermediate, and when you hit advanced, you go back to assuming it will be broken regardless of what you do.
Yeah, can't be bothered with learning types. That's too complicated, let's get to that later.
"Professor, I have this weird error. How do I fix it?"
"You don't. You just deliver it anyway."
Wait we're talking about PHP not Java.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Aside from a few cases where I wanted to create math-like objects (vectors, etc) I can't remember the last object I created that I would ever want to pass by value. Typically if I have a non-trivial destructor, then I also disallow automatic copying and create a Clone() call if I really want to make copies
Plus I think it's easier to go over that stuff later on once lifetime management has already been taught, since you have to do that bit anyway
I'd figure this aspect of java oriented programming is going to have less 'can't program out of a wet paper bag' and more 'drools on themselves and spins in circles'
Honestly they should be tackling memory far before they get that far either way. Because if you don't understand bits and bytes and allocation you're going to be fucked going any further. Best to weed them out early either way.
I agree with you in spirit, starting with core mechanics like manual memory management. What fucks that up is that they don't make for compelling material for an introductory class whose purpose is to introduce students to computer science which, as @Gilbert0 pointed out, is not just programming. At this point, it isn't a matter of weeding students but enticing students who were on the fence or did not consider computer science as a field in the first place.
The end result is that every computer science instructor is compromising between these ideals and the technology available in various ways to various ends. Some examples:
Posts
How do you actually accrue any vacation time taking days off that often?
I get 15 days per year, and I would probably need 9 of them to fill in the holes for one 3-day weekend per month. That only leaves 6 more days per year, which I guess isn't that bad, since that's 6 leftover after taking a holiday every single month...?
if you get 15 days per year, that's one per month with not much left over for accrual
personally I strongly prefer 3-4 day weekends to 1-2 week full vacations
i aint got nowhere to be
I get upgraded to 20 if/when I am at my company 5+ years. That will be pretty nice. That's a bit more than 6.5 hours of vacation per pay period.
I think (luckily) my university got it right. They have the distinction of Software Engineering and Computer Science. They treat the credits the same for graduation but if you want to emphasize on coding, you can.
everyone i know who has that can never actually take that many days off due to obligation
I don't have long vacations. I rarely take more than a day or two at a time.
I get 5 floating holidays a year, 5 holidays, and 2 weeks vacation a year.
Same policy over here as well.
I seriously disagree. It blows my mind that people see things this way.
You have to understand objects and classes? What about the ancient codex of banal knowledge you need about C++ to write anything worthwhile that extends beyond main()?
Objects and classes ain't hard. Except in C++.
So you say, well then just teach C. OK. Well, after they've learned how to add foo and and bar into foobar, then what? Straight to buffers and arrays? I think not.
The amount of information you need about objects in Java to do basic procedural programming can be easily abstracted away by any teacher, and there's an easy gradient into those intermediate and advanced subjects. I don't think the same can be done for C++. You're out of the frying pan and into the fire as soon as you start writing objects.
Expand that. You don't have to deal with the heap at all writing classes in C++. You could write a completely procedural program and use classes as really fancy structs. Sure you've got to deal with copy constructors and all that to do it right. But I've never met anyone, even in the professional world who "does it right."
Except for Ethea.
We also get 9 holidays, but those are in addition to the 22 as well.
Given that I can barely get university instructors to talk about memory safe C++ as it is, talking about how C++11 shakes it up is a futile effort.
That being said, explicit memory allocation (i.e., fine-grained control of where objects are allocated) is the soul of C++. If you understand these mechanics, then you understand C++.
There isn't really a dispute about this sort of material being covered. The dispute is that if it is prudent and appropriate to do so in an introductory class. Every intro teacher wants to teach the world, but with only 10-15 weeks, you can only cover so much before you are overloading your students.
I used to think this. But I put a lot more emphasis these days on being true to the language that you are using which puts necessary (although not necessarily game-breaking) constraints on your presentation. One example of this is in the Java objects-late approach, you typically write programs in a procedural style consisting of static methods. This is not how idiomatic Java is written, but it allows you to avoid the difficulties of OOP early on.
In contrast, I think functional C++ is perfectly fine (and this is how Stroustrop teaches C++ in his text) but it isn't necessarily true to the language. You eventually need to use pointers, explicit allocation, and then classes. If you don't believe in these things (and I necessarily don't in the context of C++), then you have downstream clients of your students, i.e., instructors further in the curriculum, that need to know these concepts and expect them to be introduced earlier.
This is why I say there isn't a perfect language for teaching because no mainstream language (save perhaps Racket with its language levels) has staged its features in such a way that they parallel how you might want to present them in an introductory class. You'll always have to compromise between staying true to the language and developing a clean presentation for your students.
This has two problems. (1) This is akin to the "magic words" of Java, e.g., "public static void main(String[] args)" is the signature of the main function. You are forcing the students to write magic code that they "don't need to understand the details of" in order to make progress. (2) This is semantically incorrect behavior. The real higher-order bit is that the copy constructor, copy assignment, and destructor all manage the memory of a particular object in a consistent way. If the destructor exists, then the other two must exist to be consistent. Your alternative introduces the constraint that an object of this particular class can never be passed by-value or copied via assignment which impose unnecessary and arbitrary restrictions on how objects can be used in a program.
I've seen instructors make compromises similar to this, and I understand why they do it. However, it just reinforces my point that C++ is not a suitable first language rather than make it usable.
Virtual methods, statics, object destruction, interactions between C types/handles and C++ code when necessary
these are all reasonably advanced things you kinda need to know if you want to do what I will casually refer to as "real programming" in C++
all more complicated to some extent than in Java IMO
This is true. And I'm a theoretician by trade, so I'm sympathetic to the viewpoint that computer science transcends programming. However, the reality is that the majority of your computer science graduates will be employed by the software industry. And if they are not employed as developers, they are working with developers in a way that requires some knowledge of programming. It thus behooves computer science educators to "get the programming parts of the curriculum right", for whatever vague notions of correctness we have for that.
That's why I said "introduction to OOP" and not "be fully versed in all the ins and outs of C++ before using Java"
Java has similar concepts and even more snafus. Like objects getting dereferenced because of weird garbage collection issues. Though that was a symptom of something strange in 1.4 or earlier, I can't recall.
Every language has corners. The things that you are describing with Java are relatively deep corners. C++ has its own deep corners and unfortunately some shallow corners that you need to be aware of in order to write good C++ code.
The troubling stuff about C++ in the context of intro isn't silly language lawyer stuff like that. It is fundamental language issues that if the student is not aware of will lead them to write memory unsafe code. In the context of intro, these are problems that most people have deemed complex enough to push out to later classes.
Just like I said, Java is an object based language. Starting with java and ignoring objects is like learning to drive a car but don't know how to turn a wheel.
And like I mentioned before, objects cannot be entirely ignored in any reasonable intro class. What is done instead is that object use is introduced early but object design is deferred.
It's much easier than properly implementing copy construction and assignment. Alternately, you can get them for free if you never store a raw pointer and instead use the STL objects,. A lot of the time though allowing copy construction is just asking for pain, most objects don't need to be copyable, and pass by value is so expensive it's a good idea to learn to not do that. Plus it emphasizes memory management, which is what most people need experience with, in exchange for telling students to "just write classname(const classname&); void operator =(const classname&); to tell the language to disable assignments"
There's almost no semantic difference between "butt()" and "poopy.butt()"
Yeah, like I said, it is a compromise. But you need to understand what you are giving up when you go down this road. In particular, you are giving up the discussion of manual memory allocation (not lifetime management, but instead where objects are allocated) in C++ which is one of the greatest strengths of the language. And (in my opinion) is the more important concept for students to learn when they work with C++.
For similar reasons, I dispute that copy construction/pass by value is something you should avoid. Again the great strength that C++ is manual memory allocation. In OOP you have lots of cases where you will create small, short-lived objects that ought to be copied rather than passed by reference.
And that's why people are generally fine with this approach. As background, many curriculums defer object design and do this sort of bastardized presentation Java because the last decade of computer science education was spent experimenting with an "objects-first" approach. This produced students that "understood" objects (but not their mechanics) but could not program themselves out of a wet paper sack. Like a pendulum, we've swung back to the Pascal days of yore in response where we emphasize programming-in-the-small over object-oriented design.
Unfortunately, the tools we teach have not caught up with this trend as industry and what is in vogue typically lags a decade behind the cutting edge (for both good and bad reasons).
(As an aside, you would be surprised at the number of students that don't grok the differences and similarities between free-floating functions and method calls.)
I had no problems with the intro to programming course I held in Ruby. Showed classes and objects and how they worked, never actually went into making your own classes.
Though we'll see what they think about PHP and having to do stinky(poopy(butt))) instead. PHP. :rotate:
That way you don't even need to deal with whether or not basic stuff even works until intermediate, and when you hit advanced, you go back to assuming it will be broken regardless of what you do.
Honestly they should be tackling memory far before they get that far either way. Because if you don't understand bits and bytes and allocation you're going to be fucked going any further. Best to weed them out early either way.
Yeah, can't be bothered with learning types. That's too complicated, let's get to that later.
"Professor, I have this weird error. How do I fix it?"
"You don't. You just deliver it anyway."
Wait we're talking about PHP not Java.
Plus I think it's easier to go over that stuff later on once lifetime management has already been taught, since you have to do that bit anyway
I agree with you in spirit, starting with core mechanics like manual memory management. What fucks that up is that they don't make for compelling material for an introductory class whose purpose is to introduce students to computer science which, as @Gilbert0 pointed out, is not just programming. At this point, it isn't a matter of weeding students but enticing students who were on the fence or did not consider computer science as a field in the first place.
The end result is that every computer science instructor is compromising between these ideals and the technology available in various ways to various ends. Some examples:
+ The University of Washington uses Java and objects late through their intro sequence.
+ Pamona college uses Java and events in a more objects-first approach.
+ Stanford uses a subset of Javascript for their CS0 course, Karel the Robot and Java for their CS1 course.
+ Berkely uses scheme with SCIP.
+ Northeastern uses Racket.
+ At UPenn, we start with Java, transition into OCaml and then back to Java.
Suffice to say, everyone is trying to make it work in their own way for better or worse.
Hawhaw.