Warp wrote:
>   You don't have to deal with constructors. You can simply say "if you create
> a string without initializing it, it defaults to an empty string".

And they ask "what does an integer default to?"  And then they ask why.

>   As opposed to char*, which defaults to... what?

Uninitialized. Like every single automatic variable in C, nothing gets 
initialized before you assign to it.

>   You seriously claim that eg. pointer arithmetic, null-terminated strings
> and the standard C string manipulation functions are easier for a beginner
> to understand than C++'s std::string? (And that's just one example.)

Yes, if you actually want to understand it. If you want to treat std::string 
as magic, then no.

>> It would be easier to explain what's happening.
> 
>   Does the beginner really need to know what the compiler is doing under
> the hood in this case?

If you want to treat the standard template library as magic, no.

>> I don't have to explain the syntax for method invocation
> 
>   There was no method invocation in my example. (Ok, operator+() *is* a
> method, and it's being called, but the beginner doesn't need to know that
> in order to use string concatenation.)

strings.size() isn't a method invocation? And in this case, += and [] are as 
well, but I agree you could probably skip over that bit.

>> the differences between method invocations on 
>> references and pointers
>   My example didn't need any such thing.
>> overloaded operators
>   The beginner doesn't need to know that to implement that example.

So you're arguing that the complexity can be brushed off as "magic you don't 
have to worry about."  That's OK, but in my experience that's not a good way 
to teach beginners.

I wasn't talking specifically about your example in some of these cases, but 
about the difference between teaching C++ and C in general.

>> or what namespaces are.
> 
>   Is it really a bad thing that the beginner is introduced to namespaces
> from the very beginning? It's not like they are very hard to understand.

To beginning programmers, *everything* is hard to understand.

>   No. The C version would require explaining lots of things about how C
> null-terminated strings work internally 

True.

>   You would also need to explain that if the function returns a pointer to
> a new C string it allocated itself, how the calling code needs to make sure
> that it's not leaked. (Again, no such need with std::string.)

Yes yes and yes.

>   So the C++ version is enormously simpler than the C version in all possible
> regards. The newbie needs to learn a lot less and can start doing some
> practical (and safer) code much more quickly.

We'll just have to disagree.

>> Basically, in the C equivalent, the 
>> only *confusing* part is that C doesn't allocate multi-word objects for you.
> 
>   No, it isn't. You have to understand null-terminated strings, how to
> calculate the length of strings, and how to manually manage the memory
> for the strings before you could write such a function in C.

Yep. Those aren't confusing, tho. They're tedious, and may seem like silly 
rules, but not *confusing*. You can explain that stuff with pictures.

Based on my experience teaching classes, treating something as "magic you 
don't have to understand", and having several elements that perform the same 
role differently, is what leads to confusion. You immediately start down the 
cargo-cult programming path, where you do it like this not because it's 
right, but because that's what the teacher said to do and you don't know why.

Plus, the concatenate example is a terrible example for teaching. There's no 
I/O, it's not a stand-alone program, and it's not complete.

-- 
Darren New, San Diego CA, USA (PST)
   The question in today's corporate environment is not
   so much "what color is your parachute?" as it is
   "what color is your nose?"

Post a reply to this message

>>> He missed "Pseudocode", which I'd write as:
>>>
>>> Coding in pseudocode is like a metaphor.
>> I like it! (although given your sentence construction shouldn't that be
>> "simile", or alternatively "Coding in pseudocode is a metaphor"?)
> 
> Technically, I guess "simile" would be correct there - I always get the 
> two mixed up.  :-)

Analogies are endofunctors in the category of bad explanations.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Fri, 26 Feb 2010 19:44:21 +0000, Orchid XP v8 wrote:

>>>> He missed "Pseudocode", which I'd write as:
>>>>
>>>> Coding in pseudocode is like a metaphor.
>>> I like it! (although given your sentence construction shouldn't that
>>> be "simile", or alternatively "Coding in pseudocode is a metaphor"?)
>> 
>> Technically, I guess "simile" would be correct there - I always get the
>> two mixed up.  :-)
> 
> Analogies are endofunctors in the category of bad explanations.

Now, of those, which is the hypernym and which is the hyponym? ;)

Jim

Post a reply to this message

>> Analogies are endofunctors in the category of bad explanations.
> 
> Now, of those, which is the hypernym and which is the hyponym? ;)

One would *presume* that analogy is a hyponym of bad explanation...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Fri, 26 Feb 2010 21:55:44 +0000, Orchid XP v8 wrote:

>>> Analogies are endofunctors in the category of bad explanations.
>> 
>> Now, of those, which is the hypernym and which is the hyponym? ;)
> 
> One would *presume* that analogy is a hyponym of bad explanation...

Certainly from your sentence construct, that would seem to be the 
case. :-)

Jim

Post a reply to this message

I believe this to be vaguely relevant:

http://i.imgur.com/hF6mS.jpg

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> One of the better ones I've seen.
>
> http://web.mit.edu/~axch/www/writing_rant.html

my gosh!  So many messages and all of them irrelevant!

what is truly amusing about this is that it was written by Peter Parker himself!
o_0

Post a reply to this message

Darren New wrote:
> Warp wrote:
>>   Exactly which part of C is simpler for newbies than C++?
> 
> You don't have to deal with constructors, destructors, exceptions, the
> difference between casing classes and casting pointers to classes, etc.

Right; instead, you have to deal with a dozen different library 
implementations of object construction, destruction and error handling;
such as GObject :)

Another example: POV-Ray 3.6 has virtual functions reinvented in C (to call 
"intersect with ray" on any Object* without knowing if it's a Sphere or an 
Isosurface). It's harder to figure out what's going on than if you just had 
a C++ class with virtual methods, because no other C program does it 
**exactly** the same way as POV 3.6.

Post a reply to this message

Invisible wrote:
> I'm not familiar with Ruby, Scheme, or Mozart. Of course I've heard of
> all these things, but I don't know anything about them. 

http://en.wikipedia.org/wiki/Ruby_(programming_language)
http://en.wikipedia.org/wiki/Scheme_(programming_language)
http://en.wikipedia.org/wiki/Wolfgang_Amadeus_Mozart

Post a reply to this message

Nicolas Alvarez wrote:
> Darren New wrote:
>> Warp wrote:
>>>   Exactly which part of C is simpler for newbies than C++?
>> You don't have to deal with constructors, destructors, exceptions, the
>> difference between casing classes and casting pointers to classes, etc.
> 
> Right; instead, you have to deal with a dozen different library 
> implementations of object construction, destruction and error handling;

Actually, I don't. Note the term "newbies". :-)

I honestly wouldn't teach either one as a first language. Even Pascal is 
pushing it, IME.

> Another example: POV-Ray 3.6 has virtual functions reinvented in C (to call 
> "intersect with ray" on any Object* without knowing if it's a Sphere or an 
> Isosurface). It's harder to figure out what's going on than if you just had 
> a C++ class with virtual methods, because no other C program does it 
> **exactly** the same way as POV 3.6.

Yep. And the problem is that no C program can possibly do it the same way as 
C++ in any sort of portable way. So every C++ library that uses any of this 
sort of feature is incompatible with being called by any sort of C program. 
Hence, the proliferation of such faux-OO libraries.


-- 
Darren New, San Diego CA, USA (PST)
   The question in today's corporate environment is not
   so much "what color is your parachute?" as it is
   "what color is your nose?"

Post a reply to this message