One of the better ones I've seen.

http://web.mit.edu/~axch/www/writing_rant.html
-- 
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] sanrrcom> wrote:
> One of the better ones I've seen.

> http://web.mit.edu/~axch/www/writing_rant.html

  It's funny how everybody keeps repeating the same mantras about C++,
yet I don't experience them myself. It must be a different C++.

  I *honestly* can't remember when was the last time I got a segmentation
fault in a C++ program of mine. Maybe sometimes it happens, but really,
really rarely. I'd say that during the past year I might have got perhaps
one segmentation fault.

  Memory leaks? *That's* a really, really long time. I'd estimate 10 years
maybe?

  Out-of-bounds access is a lot easier to get, especially since off-by-one
mistakes are very easy to do (regardless of the language you are using,
at least if it's an imperative one). Don't remember the last time I had
to actually seriously hunt for one, though.

  Well, maybe it's just me. Since everybody keeps repeating the same mantras
then it must be true.

-- 
                                                          - Warp

Post a reply to this message

On 02/25/2010 02:02 PM, Warp wrote:
> Darren New<dne### [at] sanrrcom>  wrote:
>> One of the better ones I've seen.
>
>> http://web.mit.edu/~axch/www/writing_rant.html
>
>    It's funny how everybody keeps repeating the same mantras about C++,
> yet I don't experience them myself. It must be a different C++.
>

I imagine a large part of the difference if that you've learned a set of 
programming techniques in C++ which go a long way in avoiding these 
problems.  If, however, one hasn't programmed in C++ enough to make 
these things second nature then I think that it is indeed a relatively 
perilous language since part of its design philosophy is not to waste 
resources protecting you from yourself unless you explicitly ask for it. 
  In fact, I'd wager that some of the programming techniques which you 
use in C++ are exactly the sort of things that a higher-level language 
would do for you automatically (memory management, bounds checking, 
etc.), but which you had to learn/be told to do in C++.  Granted I 
rather like this design philosophy, but it took some work before I could 
program in C++ without being frustrated.

Also, his quip about cryptic compile-time error messages is definitely 
justified IMHO (at least as far as g++ goes).

Post a reply to this message

Kevin Wampler <wampler+pov### [at] uwashingtonedu> wrote:
>   In fact, I'd wager that some of the programming techniques which you 
> use in C++ are exactly the sort of things that a higher-level language 
> would do for you automatically (memory management, bounds checking, 
> etc.)

  Certainly. In most programming languages you don't have to care *at all*
about certain things which you have to be careful about in C++ (at least
in larger programs). Also many languages offer out-of-the-box features
that C++ doesn't (except as third-party libraries).

  On the other hand, it feels like in most of the "higher-level" languages
these features are usually mutually incompatible with memory efficiency
(and sometimes even speed). There are some languages which offer both the
features and the possibility of efficient resource usage, but these languages
often seem to lack good compiler support for most platforms (either there are
no compilers, or they are limited, awkward to use and don't interact with
the rest of the system very well). Many scripting languages are better in
the portability side, but they often also tend to be inefficient.

> Also, his quip about cryptic compile-time error messages is definitely 
> justified IMHO (at least as far as g++ goes).

  If it's your first time compiling C++ programs with gcc, the error
messages can be quite cryptic, but having used gcc for quite many years
I can recognize all the relevant parts quite fast. It's rare to get
messages I have hard time deciphering. (Usually you get quite far by
simply skipping all the "instantiated from" lines.)

  (gcc has improved a lot in its error messages. gcc 2.x tended to produce
extremely lengthy and cryptic messages, especially with template code, but
the current gcc has simplified it quite a lot.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   I *honestly* can't remember when was the last time I got a segmentation
> fault in a C++ program of mine. 

I fully believe that. I think the problem is you're not dealing with other 
peoples' code.  I think the people who bust on it are people who have had to 
deal with suboptimal code.

I'm dealing with crappy code now. When I say "this giant library core dumps 
when I do X, Y, and Z", and they say "It doesn't core dump on our test 
program. Must be your problem." then it's easy to get frustrated with C++ 
not being able to pin down who is at fault.

>   Well, maybe it's just me. Since everybody keeps repeating the same mantras
> then it must be true.

I think you're probably rarely talented. :-)

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

On 02/25/2010 02:34 PM, Warp wrote:
>
>    On the other hand, it feels like in most of the "higher-level" languages
> these features are usually mutually incompatible with memory efficiency
> (and sometimes even speed).
>

I certainly agree, and I actually rather like the approach that C++ has 
taken for tasks where I do care about the efficiency.  But I can see 
where the "knife fight" analogy came from (perhaps a better related 
analogy if it weren't so obscure is using a urumi -- very effective but 
you'd better know what you're doing or else you'll end up hurting yourself).


>> Also, his quip about cryptic compile-time error messages is definitely
>> justified IMHO (at least as far as g++ goes).
>
>    If it's your first time compiling C++ programs with gcc, the error
> messages can be quite cryptic, but having used gcc for quite many years
> I can recognize all the relevant parts quite fast. It's rare to get
> messages I have hard time deciphering. (Usually you get quite far by
> simply skipping all the "instantiated from" lines.)
>

Hmmm, even with the my current version of g++ (4.4.1) I still find the 
error messages to be cryptic.  This isn't to say that I have trouble 
understanding them, but I feel like this is due to gaining skill at 
decrypting them and learning that when I see message "x" it probably was 
actually caused by mistake "y".  Perhaps it's just a difference in what 
we mean by "cryptic".  That said, I do think that there's some further 
evidence for the need for better error messages by the attempted 
introduction of concepts into the C++0x standard (even if they didn't 
make the final cut).

Post a reply to this message

Kevin Wampler wrote:
> evidence for the need for better error messages 

I was actually pretty impressed by the C# IDE from MS. I wrote

void do_it(int a, int b, int c = 0) { ... }

and the error message wasn't ") or , expected" or "syntax error", but rather 
a pointer to the = and the message "C# does not support default arguments."

I was also impressed when I started up my program under test in full screen 
and the IDE bumped its debugger windows over to the second screen and put 
them back when the program exited. Cool attention to detail.  Not that this 
has anything to do with the current thread.

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

On 02/25/2010 02:58 PM, Darren New wrote:
> Kevin Wampler wrote:
>> evidence for the need for better error messages
>
> I was actually pretty impressed by the C# IDE from MS. I wrote
>

How have you liked C# so far?  I last tried it when it was a pretty new 
language and it came across as a slightly altered version of Java, but I 
imagine it's changed a fair bit since then.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> I was actually pretty impressed by the C# IDE from MS. I wrote

> void do_it(int a, int b, int c = 0) { ... }

> and the error message wasn't ") or , expected" or "syntax error", but rather 
> a pointer to the = and the message "C# does not support default arguments."

  But is that kind of message the rule or the exception?

  And it's not like gcc didn't have similar-sounding error messages:

error: ISO C++ forbids declaration of 'x' with no type

-- 
                                                          - Warp

Post a reply to this message

On Thu, 25 Feb 2010 13:39:25 -0800, Darren New wrote:

> One of the better ones I've seen.
> 
> http://web.mit.edu/~axch/www/writing_rant.html

He missed "Pseudocode", which I'd write as:

Coding in pseudocode is like a metaphor.

;-)

Jim

Post a reply to this message

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

Post a reply to this message

Kevin Wampler wrote:
> How have you liked C# so far? 

I do. I've been using it on and off from early on.

> I last tried it when it was a pretty new 
> language and it came across as a slightly altered version of Java, 

Well, at first glance it looks like that, but deeper in it has a whole lot 
of good stuff Java doesn't. Until you start going into complex stuff, it's 
just "Java, fixed."  Once you start trying to do something difficult (like 
access to native languages, deployment, web scripts, generating code at 
run-time, etc) it's way better.

> imagine it's changed a fair bit since then.

Indeed it has. C# 1.0 was sort of "Java, improved."  C# 3.x by now has all 
kinds of goodies in it that Java lacks.

-- 
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:
>   But is that kind of message the rule or the exception?

The error messages are all good, but I usually don't get an error at compile 
time because the IDE puts a red squiggly under compile-time errors and a 
green or blue squiggly for warnings, as you type. The IDE is really an order 
of magnitude better than anything else I've ever used.

That was just surprising, because MS anticipated that someone would do that 
and special-cased the parser just to handle a common error message.

>   And it's not like gcc didn't have similar-sounding error messages:
> error: ISO C++ forbids declaration of 'x' with no type

I've gotten a few of those and not understood them, actually. I don't 
remember what I had, but having something more along the lines of "you 
forgot an #include" would be a better error message, I think. :-)

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

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

Jim

Post a reply to this message

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!

Post a reply to this message

Darren New wrote:
> Kevin Wampler wrote:
>> How have you liked C# so far? 
> 
> I do. I've been using it on and off from early on.
> 
>> I last tried it when it was a pretty new language and it came across 
>> as a slightly altered version of Java, 
> 
> Well, at first glance it looks like that, but deeper in it has a whole 
> lot of good stuff Java doesn't. Until you start going into complex 
> stuff, it's just "Java, fixed."  Once you start trying to do something 
> difficult (like access to native languages, deployment, web scripts, 
> generating code at run-time, etc) it's way better.

Makes sense.  I think the runtime code generation was what I was 
particularly interested in, and I'm pretty sure it didn't have much in 
the way of that when I last looked at it.  Now that I have Visual Studio 
maybe I'll take a look at it again sometime.

Post a reply to this message

Coding in Haskell is like having sex with a girl
that wears horn rimmed glasses, you'll never quite
understand her, but it's a lot of fun.

Post a reply to this message

Tim Attwood wrote:
> Coding in Haskell is like having sex with a girl
> that wears horn rimmed glasses, you'll never quite
> understand her, but it's a lot of fun.

Dude, what the HELL...?? o_O

Post a reply to this message

Darren New wrote:
> One of the better ones I've seen.
> 
> http://web.mit.edu/~axch/www/writing_rant.html

The one for C++ seems about right. All the others don't match my 
experience at all. (E.g., since when does Java "always get the job done 
eventually"? I've lost count of the number of programs I was unable to 
finish because Java just makes it too difficult, lacks the necessary 
feature, or the spec sheet says the feature exists but it's not actually 
implemented!)

I'd say that Perl is like a tool that somebody wrote to solve the one 
particular problem they were trying to solve that day, and then tried to 
claim it was a general-purpose tool. It makes a small class of problems 
really easy to solve, and everything else almost impossible. The whole 
thing seems to be a steaming pile of ad hoc solutions with no unifying 
form or structure. Kind of like learning English, but harder.

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. (I started 
reading a Ruby tutorial, but the random inconsistant syntax put me off. 
And the ham.)

So anyway, since I'm sure you're all expecting it anyway... I'd say that 
coding in Haskell is like doing highschool algebra. (In more ways than 
one.) At first it seems weird and complicated. And then, assuming you 
"get it", it suddenly seems really simple and easy and "obvious". And 
then as you try to tackle harder problems, it starts seeming difficult 
again...

Post a reply to this message

Warp wrote:

>   It's funny how everybody keeps repeating the same mantras about C++,
> yet I don't experience them myself. It must be a different C++.

It seems to me that C++ is a language designed for experts. If you're a 
C++ expert, it works very well. If you're a clueless newbie, it works... 
not so well.

Still, at least it's better than C.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> >   And it's not like gcc didn't have similar-sounding error messages:
> > error: ISO C++ forbids declaration of 'x' with no type

> I've gotten a few of those and not understood them, actually. I don't 
> remember what I had, but having something more along the lines of "you 
> forgot an #include" would be a better error message, I think. :-)

  You can get that one if you write eg. "static x;"

  It should be rather clear: You have defined a static variable named 'x',
but with no type. (In C it would default to int, but the C++ standard forbids
omitting the type, which is what the error message is saying.)

-- 
                                                          - Warp

Post a reply to this message

"Tim Attwood" <tim### [at] anti-spamcomcastnet> wrote in message 
news:4b878b55$1@news.povray.org...
> Coding in Haskell is like having sex with a girl
> that wears horn rimmed glasses, you'll never quite
> understand her, but it's a lot of fun.

Coding in SNOBOL is like writing a phone book because... well, because that 
was all it was ever used for.

--
Jack

Post a reply to this message

Kevin Wampler wrote:
> Makes sense.  I think the runtime code generation was what I was 
> particularly interested in, 

Huh. That's one part I don't think changed that much.  The code generation 
is used by the compiler(s) as well as in various places in the libraries. 
(For example, regular expressions compile down to IL and then native code if 
you set the flag.)

The other one is the LINQ thing, where you can set a flag that says "give me 
this expression as a parse tree rather than generating code", but that's 
limited to LINQ so far.

It's the "Reflection.Emit" namespace you want.

-- 
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:
>   It should be rather clear: You have defined a static variable named 'x',
> but with no type. (In C it would default to int, but the C++ standard forbids
> omitting the type, which is what the error message is saying.)

Ah, I see. Yes.  A similar thing, that.  I think I got it because the 
47K-long compile line was missing one of the -D instructions that would have 
made
   static UINT32 x;
into a valid declaration or something. Which is why looking at it, it made 
no sense, and I couldn't find the header file that defined it.

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

Invisible wrote:
> Still, at least it's better than C.

Well, it's better than C for experts. For newbies, I think C is probably 
easier, since there's less magic going on you need to know.

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

Invisible wrote:
> I'd say that Perl is like 

PHP is exactly this, yes.

> 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. (I started 
> reading a Ruby tutorial, but the random inconsistant syntax put me off. 
> And the ham.)

Yep. And the fact that the guy who wrote the most definitive texts doesn't 
actually know what the language does. (At several points in the Axe book, 
the author says "It seems to do this" or "it apparently does that.") And the 
fact that between minor version 18 and minor version 19 they made a bunch of 
unneccesary and seemingly trivial changes to defaults that would 
nevertheless break any program that relied on those defaults. Those are the 
main reasons I never really pursued it.

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

>> I'd say that Perl is like 
> 
> PHP is exactly this, yes.

Oh dears.

>> 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. (I started 
>> reading a Ruby tutorial, but the random inconsistant syntax put me 
>> off. And the ham.)
> 
> Yep. And the fact that the guy who wrote the most definitive texts 
> doesn't actually know what the language does. (At several points in the 
> Axe book, the author says "It seems to do this" or "it apparently does 
> that.") And the fact that between minor version 18 and minor version 19 
> they made a bunch of unneccesary and seemingly trivial changes to 
> defaults that would nevertheless break any program that relied on those 
> defaults. Those are the main reasons I never really pursued it.

Yes.

And the thing with the ham...

Post a reply to this message

Darren New wrote:
> Kevin Wampler wrote:
>> Makes sense.  I think the runtime code generation was what I was 
>> particularly interested in, 
> 
> Huh. That's one part I don't think changed that much.

It's also entirely possible that I'm remembering 
incorrectly/incompletely here.

Post a reply to this message

Captain Jack wrote:
> 
> Coding in SNOBOL is like writing a phone book because... well, because that 
> was all it was ever used for.
> 

Wow, it's not often I hear that language mentioned.  Apparently it was 
also somewhat popular with people in non-technical academic fields since 
they found the string processing capabilities useful.

One of these days I'm going to learn it just because I'm curious about 
it, but I haven't gotten around to it yet.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Invisible wrote:
> > Still, at least it's better than C.

> Well, it's better than C for experts. For newbies, I think C is probably 
> easier, since there's less magic going on you need to know.

  You mean newbies don't need to handle dynamically allocated memory?

  Exactly which part of C is simpler for newbies than C++?

-- 
                                                          - Warp

Post a reply to this message

>>> Still, at least it's better than C.
> 
>> Well, it's better than C for experts. For newbies, I think C is probably 
>> easier, since there's less magic going on you need to know.
> 
>   You mean newbies don't need to handle dynamically allocated memory?
> 
>   Exactly which part of C is simpler for newbies than C++?

Simpler /= easier. ;-)

(If anybody out there still thinks simple and easy are in any way 
correlated, try learning the Waltz. It has THREE STEPS IN IT, and yet 
nobody can do it right for at least the first 20 minutes.)

Post a reply to this message

Kevin Wampler wrote:
> Darren New wrote:
>> Kevin Wampler wrote:
>>> Makes sense.  I think the runtime code generation was what I was 
>>> particularly interested in, 
>>
>> Huh. That's one part I don't think changed that much.
> 
> It's also entirely possible that I'm remembering 
> incorrectly/incompletely here.

It *is* relatively primitive. But then, you *are* creating essentially 
machine code. :-)  I just don't remember hearing of any significant changes.

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

It's simpler *because* it's less powerful, in the same way that using an axe 
is simpler for newbies than using a chainsaw.

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

Kevin Wampler wrote:
> One of these days I'm going to learn it just because I'm curious about 
> it, but I haven't gotten around to it yet.

It's sort of like Perl, only more ... tabular, somehow. People don't use it 
any more because computers are powerful enough to run things like Perl now.

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

  Why would a beginner need to deal with constructors, destructors,
exceptions and the like?

> It's simpler *because* it's less powerful, in the same way that using an axe 
> is simpler for newbies than using a chainsaw.

  No, C is a lot more complicated for the beginner precisely because it's
less powerful.

  In C++ the beginner can write things like this:

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

  And here I didn't even get to the things that the C standard library
doesn't support.

-- 
                                                          - Warp

Post a reply to this message

Darren New wrote:
> Kevin Wampler wrote:
>> One of these days I'm going to learn it just because I'm curious about 
>> it, but I haven't gotten around to it yet.
> 
> It's sort of like Perl, only more ... tabular, somehow. People don't use 
> it any more because computers are powerful enough to run things like 
> Perl now.
> 

As I understand it's pattern matching uses a recursive backtracking 
algorithm, which should give it a bit of a Prolog flavor too.  This 
seems distinct from the Perl way of doing things (although historically 
the latter seems to won out as being more useful in practice).

Not that I know SNOBOL or Perl mind you, so I'm talking based mostly on 
my impressions of Icon and Ruby respectively plus a bit of extra reading.

Post a reply to this message

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] sanrrcom> 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

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