Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #75812

Re: Shortened form of condition

Show all headers | View raw

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>  
> (snip)
>>> May I ask for an advice on a book that teaches professional coding and 
>>> helps to develop correct coding principles, unlike Kochan's one?
>  
>> I'm a bit out of date so I can't suggest any current books, but there is
>> a fundamental problem with trying to do what Kochan is trying to do.
>> He's trying to teach the basic concepts about procedural programming --
>> how to use variables, assignments, input/output, loops, functions and so
>> on to achieve some desired end result -- whist using C to do it.
>
> Seems to me that this is true of any book and any language.

Yes, that's true.  Maybe I should have swapped paragraphs, because the
issue is how particularly fiddly C is in this respect.  You always have
to teach programming whilst teaching a language to do it in, it's just
that C is an odd choice for that.

> You have to start somewhere, when you haven't yet taught all
> you need to know.
>
> In the case of Java, and presumably other object oriented languages,
> there is the 'objects first' and 'objects last' way of teaching.
>
> For those with no previous programming experience, it might be
> that objects last, which starts teaching static methods first,
> as one would teach a non-OO language. Then, after one has a good
> understanding of data types, expressions, and writing static 
> methods, teach instance methods. Note that you can't completely
> write using static methods, as you likely need to do simple I/O
> pretty early.
>  
>> Take one tiny point: testing if a character is "printable".  There's a C
>> function for that: isprint.  Now you may be able to skip the idea that
>> it's possibly macro as well, but "professional coding" requires a cast
>> of the argument in many cases:
>  
>>  if (isprint((unsigned char)ch)) ...
>  
>> That's not something that someone learning programming should have to be
>> fussing about, but it will come up here (as it should) if anyone posts
>> code.  And of course, you don't always need the cast.  When do you?
>> It's not a question I'd have wanted to answer in programming 101 class.
>
> You can either say 'do this and we will explain it later', or do
> it some other way, until later.

Yes, you can.  Again and again.  It just about works with very careful
choice of exercises and examples and you hope that the inventive joy of
programming is not lost in all that "just do it this way".

>> One of the key ideas in programming is orthogonality -- roughly the idea
>> that separate concepts don't interact in unexpected ways.  The better a
>> language is at manifesting this idea, the fewer the restrictions there
>> are on how you organise your programs.  But in C, there are lots of
>> entangled notions.  You can't pass an array to a function like you pass
>> almost any other value.  You can't return a function from a function.
>> You can't define functions in the same places you can define other
>> things.  Some arrays can be initialised with {...} notation and others
>> can't be.  The list goes on and on.
>
> Some of those obviously can't work, and others you just have to
> wait and learn later.

I don't get your point here.  You can't be saying that these
entanglements are a good thing, so presumably it's you opinion that they
don't matter much when teaching programming.  I don't think that's the
case.

>> These details can get in the way of learning the other skills -- how to
>> organise a program.  Of course you eventually need both, but it's way
>> more complicated than it needs to be to lean them at the same time.
>> (All programming languages have restrictions, constraints and odd
>> quirks, or course, but only the most obsessive would deny that C has
>> acquired more than it's share of them over the years).
>
> Some languages are less orthogonal for historic reasons. Fortran
> has a lot left over still from the early days, though many have been
> fixed in later updates.
>  
>> Writing bullet-proof C is not easy.  You need to know lots of little
>> details, and, in general, the result will be "fussier" than the
>> equivalent in a more modern language.  This is, therefore, a huge and
>> understandable temptation to simplify things to get going with the
>> programming, but this inevitably runs the risk of teaching bad C
>> programming, or at least sub-optimal C programming.
>
> Yes, but again this happens in any language.  You teach enough things
> as 'do it this way, you will learn why later'.

It happens more in C.  Do you think that because there is inevitably
some differed discussion of details, all languages are equally suitable
as a first language to learn?

What's more, in C you teach "do it this way and you'll find out why
later, and even latter you'll find out you don't need to do it all all
in other languages".

> Even more, it happens in other subjects.  You have to have some
> order for teaching concepts, even if you need others to understand
> them.
>
> It is especially interesting to consider, for example in physics or
> math, things that are taught in a different order than they were
> historically learned.

I disagree about this -- I don't see anything analogous.  There are few
subjects where the mechanism can get in the way so fundamentally.  You
need to teach some maths as you teach physics, and there will be places
where you need to defer some details, but you don't have to keep
explaining why the maths can't describe what's really going on.

-- 
Ben.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Shortened form of condition Alla _ <modelling.data@gmail.com> - 2015-11-09 06:23 -0800
  Re: Shortened form of condition Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-09 14:44 +0000
  Re: Shortened form of condition James Kuyper <jameskuyper@verizon.net> - 2015-11-09 10:17 -0500
  Re: Shortened form of condition Barry Schwarz <schwarzb@dqel.com> - 2015-11-09 09:20 -0800
  Re: Shortened form of condition Alla _ <modelling.data@gmail.com> - 2015-11-09 10:11 -0800
    Re: Shortened form of condition Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 10:35 -0800
      Re: Shortened form of condition Alla _ <modelling.data@gmail.com> - 2015-11-10 00:14 -0800
        Re: Shortened form of condition Barry Schwarz <schwarzb@dqel.com> - 2015-11-10 03:04 -0800
          Re: Shortened form of condition glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-10 21:42 +0000
        Re: Shortened form of condition Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-10 11:13 +0000
          Re: Shortened form of condition Alla _ <modelling.data@gmail.com> - 2015-11-10 07:58 -0800
            Re: Shortened form of condition Richard Heathfield <rjh@cpax.org.uk> - 2015-11-10 17:06 +0000
            Re: Shortened form of condition James Kuyper <jameskuyper@verizon.net> - 2015-11-10 12:11 -0500
              Re: Shortened form of condition James Kuyper <jameskuyper@verizon.net> - 2015-11-10 14:01 -0500
          Re: Shortened form of condition Keith Thompson <kst-u@mib.org> - 2015-11-10 08:30 -0800
            Re: Shortened form of condition Alla _ <modelling.data@gmail.com> - 2015-11-10 09:07 -0800
              Re: Shortened form of condition Keith Thompson <kst-u@mib.org> - 2015-11-10 09:29 -0800
                Re: Shortened form of condition Alla _ <modelling.data@gmail.com> - 2015-11-10 11:02 -0800
                Re: Shortened form of condition Keith Thompson <kst-u@mib.org> - 2015-11-10 11:33 -0800
                Re: Shortened form of condition Alla _ <modelling.data@gmail.com> - 2015-11-11 00:28 -0800
                Re: Shortened form of condition Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-11 16:05 +0000
                Re: Shortened form of condition glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-12 09:29 +0000
                Re: Shortened form of condition Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-12 10:56 +0000
                Re: Shortened form of condition Richard Heathfield <rjh@cpax.org.uk> - 2015-11-11 16:24 +0000
                Re: Shortened form of condition Keith Thompson <kst-u@mib.org> - 2015-11-11 08:53 -0800
                Re: Shortened form of condition Richard Heathfield <rjh@cpax.org.uk> - 2015-11-11 16:59 +0000
                Re: Shortened form of condition Alla _ <modelling.data@gmail.com> - 2015-11-11 06:42 -0800
                Re: Shortened form of condition Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-10 14:04 -0500
              Re: Shortened form of condition Barry Schwarz <schwarzb@dqel.com> - 2015-11-10 10:43 -0800
    Re: Shortened form of condition James Kuyper <jameskuyper@verizon.net> - 2015-11-09 13:44 -0500
    Re: Shortened form of condition Keith Thompson <kst-u@mib.org> - 2015-11-09 10:57 -0800
      Re: Shortened form of condition Philip Lantz <prl@canterey.us> - 2015-11-10 01:52 -0800
    Re: Shortened form of condition Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-09 19:35 +0000
      Re: Shortened form of condition Keith Thompson <kst-u@mib.org> - 2015-11-09 11:52 -0800
  Re: Shortened form of condition Alla _ <modelling.data@gmail.com> - 2015-11-10 00:33 -0800
    Re: Shortened condition Richard Heathfield <rjh@cpax.org.uk> - 2015-11-10 09:00 +0000
  Re: Shortened form of condition Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-10 16:01 -0800

csiph-web