Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Shortened form of condition |
| Date | 2015-11-12 09:29 +0000 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <n21m65$rem$1@speranza.aioe.org> (permalink) |
| References | (6 earlier) <lnvb99u5jg.fsf@kst-u.example.com> <d68831c0-2df8-4060-93dc-f326708cd1a1@googlegroups.com> <ln7flptzt0.fsf@kst-u.example.com> <cee1605c-0e59-446a-b940-ba59caff9af6@googlegroups.com> <8737wcmsh9.fsf@bsb.me.uk> |
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.
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.
> 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.
> 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'.
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.
<snip>
-- glen
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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