 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 25 Feb 2010 23:11:33 -0800, Kevin Wampler wrote:
> Jim Henderson wrote:
>> On Thu, 25 Feb 2010 19:15:40 -0800, Kevin Wampler wrote:
>>
>>> On 02/25/2010 05:20 PM, Jim Henderson wrote:
>>>>> http://web.mit.edu/~axch/www/writing_rant.html
>>>> 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. :-)
>
> At least I have something to show for all the effort my teachers spent
> hammering the difference into my head!
LOL
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Why would a beginner need to deal with constructors, destructors,
> exceptions and the like?
Because they'll be using libraries that require such. Even in your example,
you'd have to talk about the std::string constructor and how it creates an
empty string if you don't pass it arguments. As opposed to (say) integers,
that don't get initialized to zero. And what happens if you run out of
memory in your concatenate function.
> No, C is a lot more complicated for the beginner precisely because it's
> less powerful.
I disagree. It's more complicated to get things done, but easier to understand.
> std::string concatenate(const std::vector<std::string>& strings)
> {
> std::string result:
> for(int i = 0; i < strings.size(); ++i)
> result += strings[i];
> return result;
> }
> Show me the same function implemented in C and explain how it would be
> easier for a beginner (especially without any danger of memory leaks).
It would be easier to explain what's happening. I don't have to explain the
syntax for method invocation, const, references, the difference between
references and pointers, the differences between method invocations on
references and pointers, overloaded operators, or what namespaces are. The
function will be longer and more dangerous, but the only "unusual" things to
be explained are pointers and strings. Basically, in the C equivalent, the
only *confusing* part is that C doesn't allocate multi-word objects for you.
I take it you've never actually taught beginner computer programming
classes, yes?
It's not "how much power do you have." It's "how much do you have to
dismiss as magic before you have a full understanding of the entire language."
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> Warp wrote:
> > Why would a beginner need to deal with constructors, destructors,
> > exceptions and the like?
> Because they'll be using libraries that require such. Even in your example,
> you'd have to talk about the std::string constructor and how it creates an
> empty string if you don't pass it arguments.
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".
As opposed to char*, which defaults to... what?
> As opposed to (say) integers, that don't get initialized to zero.
Well, in C++ they decided that if you don't initialize an integer, its
value is not guaranteed. Bummer, but nothing to do with constructors.
> And what happens if you run out of
> memory in your concatenate function.
Your program will be ended because it ran out of memory.
> > No, C is a lot more complicated for the beginner precisely because it's
> > less powerful.
> I disagree. It's more complicated to get things done, but easier to understand.
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.)
> 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?
> 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.)
> const, references
The C version will also have a const (the function should take a const
pointer) if it's well written. So it's not all that different.
If you really want to avoid the reference in the C++ version, you can:
std::string concatenate(std::vector<string> strings)
{
...
}
It will still work (although will probably be less efficient). No such
luck in C, though. You can't pass an array of strings by value. You'll
have to have a pointer (a const one, preferably).
> the difference between references and pointers
You don't need to know the difference between references and pointers in
order to implement the "concatenate" function in my example. (And as
mentioned, you don't *necessarily* even need references at all if you
really want to avoid them.)
> 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.
> 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.
> The
> function will be longer and more dangerous, but the only "unusual" things to
> be explained are pointers and strings.
No. The C version would require explaining lots of things about how C
null-terminated strings work internally (which you don't have to with
std::string), how you allocate space for them in your code (which you don't
have to with std::string), how you make sure you have allocated enough space
for the result (again, no need with std::string) and how you concatenate
the strings with strcat (the only thing more or less equivalent to the
+ operator of std::string).
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.)
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.
> 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.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kevin Wampler wrote:
> As I understand it's pattern matching uses a recursive backtracking
> algorithm,
Now that you mention it, yes, I remmber that.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
