Objective C (OT)

[ccc31807]

I'm going to be teaching a young girl how to program a computer this
summer, and I've been thinking about likely candidates for a starter
language..

I've about settled on Objective C, primarily because of its use in
mobile apps, but secondarily because I don't know it and would like to
learn a little something about it. (The other two I thought about were
JavaScript and Python).

Two quick questions:

1. What's the 'best' reasonably priced book that's strong on the
basics and not too technical?

2. Is there any real good reason not to start off a young girl on this
language? My main goal is to show how source code turns into an
executable on a computer -- I don't want to get bogged down into heavy
duty stuff.

Thanks, CC.

[Adam Russell]

(1) I liked Cocoa and Objective-C by O'Reilly.
http://shop.oreilly.com/product/9780596804817.do
Like you I am interested in Objective-C just because of
its use by Apple. This book seemed to be a good introduction to both.
If I ever move beyond the basics I might invest in a book dedicated
to Objective-C but this is enough for now.
(2) I think that there is no reason whatsoever to not use this language.
I learned to program with Fortran and Pascal. Plenty of people learned
to program in Assembly. People need to give children more credit. The
move towards high level languages to teach basic programming is a bad
one imo. As her instructor its up to you to pace the lessons and
introduce more advanced concepts when she is ready. It may take longer
to get to interesting data structures than if you used say, Perl
but she is young so she has the advantage of time to learn difficult
concepts on her side. Just be sure to keep it fun to hold her interest.
I wonder though, just how young is "young"? I doubt many children under
the age of 12, say, have the attention span necessary to really engage
in a big project. From what I remember of learning to program in junior
highschool and highschool projects tended to be very focussed and
pretty short. From a pedagogical standpoint that may make sense (IANAT)
in that many short projects teaches and re-inforces more than one big
project. Thinking of books like K&R's C and even The Little Schemer
that approach is used for a far more advanced audience so it is likely
sound.

[Tim Watts]

ccc31807 wrote:

> I'm going to be teaching a young girl how to program a computer this
> summer, and I've been thinking about likely candidates for a starter
> language..

How young exactly?

> I've about settled on Objective C, primarily because of its use in
> mobile apps, but secondarily because I don't know it and would like to
> learn a little something about it. (The other two I thought about were
> JavaScript and Python).
>
> Two quick questions:
>
> 1. What's the 'best' reasonably priced book that's strong on the
> basics and not too technical?
>
> 2. Is there any real good reason not to start off a young girl on this
> language? My main goal is to show how source code turns into an
> executable on a computer -- I don't want to get bogged down into heavy
> duty stuff.
>
> Thanks, CC.

Without knowing much apart from a quick glance, unless the objective is
specifically to demonstrate writing an app for an iPad/iPhone, I suspect
Obj-C is a bit obtuse - and limited in the sense it's not so widly used
outside of Apple/NeXT

I taught my young daughter (aged 8) some perl (seriously!) - written in a
very Sinclair BASIC style - eg not use of warnings/strict - just simple
procedural things wiht console I/O.

The approach I used was:

1) Very simple 1-2 liners - eg print 1+2, then introduce variables

2) Some very basic loops to knock out times tables

3) Generate a pair of random numbers say 0-10 and hav eit print a question:

X plus Y = ?

and have it read the answer and check it, with suitably humerous responses.


Method was to dictate code and have it do something (however minimal) after
every few lines. Then let her play the game (which did go down very well,
despite the "lameness".

Then I asked her if she could change it to produce numbers in the range
0-20, change it to doing "times" rather than "plus". With very little
hinting, she managed and was immediately pleased.


If the girl in question is older, you could teach perl in a more C like
fashion - which would form a good foundation for moving to C or Java (OK,
Java is OO, but she will not be so alienated by the general block syntax by
then).

Cheers,

Tim

--
Tim Watts

[Ben Morrow]

Quoth ccc31807 <cart...@gmail.com>:

> I'm going to be teaching a young girl how to program a computer this
> summer, and I've been thinking about likely candidates for a starter
> language..
>
> I've about settled on Objective C, primarily because of its use in
> mobile apps, but secondarily because I don't know it and would like to
> learn a little something about it.

That's perhaps not a good idea. It would probably be better to start
with a language you know well, since otherwise you will find questions
come up you don't know the answer to.

> (The other two I thought about were JavaScript and Python).

IMHO either of those would be better choices, as would Perl. For
learning the basics, an interpreted, dynamic language with automatic
memory management is much easier than anything like C. You need to
understand notions like 'variable' and 'reference' before you can even
start to understand malloc and type-safety.

(Although it's rightly condemned as a serious language, some variants of
BASIC make very good teaching languages. I started on BBC BASIC, and I
rather quickly found out for myself why unrestricted use of GOTO is a
bad idea...)

The only other thing I would say is that anyone who wants to be a
serious programmer ought to learn C at some point, just not first.
Getting a decent sense of what is actually being executed at the machine
code level is important, even if you don't intend to write at that level
in practice.

Ben

[Shmuel Metz]

In <qhsa89-...@anubis.morrow.me.uk>, on 05/15/2012

at 09:56 PM, Ben Morrow <b...@morrow.me.uk> said:

>The only other thing I would say is that anyone who wants to be a
>serious programmer ought to learn C at some point, just not first.
>Getting a decent sense of what is actually being executed at the
>machine code level is important, even if you don't intend to write
>at that level in practice.

Learning C will not give you a sense of what is actually being
executed at the machine code level.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[ccc31807]

On May 15, 4:38 pm, Adam Russell <ac.russ...@live.com> wrote:

Thanks for all the replies, guys, but the question is now moot.

The girl is ten and attends a computer magnet school. She will be in
the 5th grade, and while there isn't any programming now, later on
they will get C++ and Java.

I was told last night that the 'language' of choice is HTML. This is
actually fine by me, because not only can I leverage the excitement of
a public site (giving her a domain for < $15.00) but I can also teach
command line FTP, and later on start small with JavaScript, and even
later (like in the coming years) delve into server side programming
and databases (perhaps via Java and JSP).

Thanks again for the replies and also thanks for the absence of flames
for an OT topic.

CC.

[bugbear]

Shmuel (Seymour J.) Metz wrote:
> In<qhsa89-...@anubis.morrow.me.uk>, on 05/15/2012
> at 09:56 PM, Ben Morrow<b...@morrow.me.uk> said:
>
>> The only other thing I would say is that anyone who wants to be a
>> serious programmer ought to learn C at some point, just not first.
>> Getting a decent sense of what is actually being executed at the
>> machine code level is important, even if you don't intend to write
>> at that level in practice.
>
> Learning C will not give you a sense of what is actually being
> executed at the machine code level.

Counter example: it did for me.

BugBear

[Shmuel Metz]

In <Peadnc1DmNuYIC7S...@brightview.co.uk>, on 05/16/2012

How did learning C teach you, e.g., the register structure of an Intel
x86 processor?

[Peter J. Holzer]

On 2012-05-17 20:51, Shmuel Metz <spam...@library.lspace.org.invalid> wrote:
> In <Peadnc1DmNuYIC7S...@brightview.co.uk>, on 05/16/2012
> at 03:43 PM, bugbear <bugbear@trim_papermule.co.uk_trim> said:
>
>>Shmuel (Seymour J.) Metz wrote:
>>> In<qhsa89-...@anubis.morrow.me.uk>, on 05/15/2012
>>> at 09:56 PM, Ben Morrow<b...@morrow.me.uk> said:
>
>>> Learning C will not give you a sense of what is actually being
>>> executed at the machine code level.
>>Counter example: it did for me.
>
> How did learning C teach you, e.g., the register structure of an Intel
> x86 processor?

By reading the output of "cc -S" :-).

Seriously: While it is difficult in retrospect to determine what was the
greatest influence (I already knew BASIC, Pascal and a bit of Z-80 and
6502 assembler, and it was the first semester of CS, so I also attended
a lot of introductory courses), I do think that C is just low-level
enough that by comparing the C source code and the generated machine
code you can get a "feeling" for common high-level language constructs
are translated into machine code. I didn't see the connection between
pointers in Pascal and addresses in 6502 assembler, but when I learned
C, it became clear to me.

As an introductory language, "Processing"[1] might be a good choice. I
haven't really used it but I played around with it a bit and it reminded
me of my BASIC days: You can get pretty fast to the point where can
produce simple graphics, little games, etc. I think that's important for
children. (Perl is similarly simple[2] as long as you stay with text -
but there is no simple graphics interface)

hp

[1] http://processing.org/

[2] I think it was Horshack who talked about the virtues of "baby perl"
on the first Vienna Perl workshop.


--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | h...@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on as...@irtf.org

[Martijn Lievaart]

On Fri, 18 May 2012 19:50:46 +0200, Peter J. Holzer wrote:

> Seriously: While it is difficult in retrospect to determine what was the
> greatest influence (I already knew BASIC, Pascal and a bit of Z-80 and
> 6502 assembler, and it was the first semester of CS, so I also attended
> a lot of introductory courses), I do think that C is just low-level
> enough that by comparing the C source code and the generated machine
> code you can get a "feeling" for common high-level language constructs
> are translated into machine code. I didn't see the connection between
> pointers in Pascal and addresses in 6502 assembler, but when I learned
> C, it became clear to me.

May be I was more ready for it at that time, but for me as well, C made
me understand Pascal pointers.

M4

[Shmuel Metz]

In <slrnjrd2vm.jq...@hrunkner.hjp.at>, on 05/18/2012

at 07:50 PM, "Peter J. Holzer" <hjp-u...@hjp.at> said:

>I do think that C is just low-level enough that by comparing the
>C source code and the generated machine code you can get a
>"feeling" for common high-level language constructs are
>translated into machine code.

That will only give you a feel for how a particular compiler
translates C constructs into machine code. It won't give you a feel
for, e.g., the architecture, translations of constructs in other
languages, instructions generated only from assembler code.

>As an introductory language, "Processing"[1] might be a good choice.

Probably kinder than what they did to us, which was to teach us
machine language before introducing the concept of an assembler :-(

[Peter J. Holzer]

On 2012-05-20 02:45, Shmuel Metz <spam...@library.lspace.org.invalid> wrote:
> In <slrnjrd2vm.jq...@hrunkner.hjp.at>, on 05/18/2012
> at 07:50 PM, "Peter J. Holzer" <hjp-u...@hjp.at> said:
>
>>I do think that C is just low-level enough that by comparing the
>>C source code and the generated machine code you can get a
>>"feeling" for common high-level language constructs are
>>translated into machine code.
>
> That will only give you a feel for how a particular compiler
> translates C constructs into machine code.

The context was "learning C". You don't learn C by only observing what a
particular compiler does - C has lots and lots of implementation-
defined, unspecified and undefined behaviour. If you really learn C[1],
you learn that almost any feature can be implemented differently.

So by examining the output from your C compiler you may find that it
evaluates arguments for functions from right to left, pushing each on
the stack immediately. But the C standard (and every textbook worth its
salt) tells you that the order is unspecified[2], so you start thinking
about other ways a compiler could implement this (e.g., evaluate from
left to right but push in reverse order, evaluate from left to right and
pass an argument count, pass the first n arguments in registers, do
it differently for functions with a fixed number of arguments and
functions with a variable number of arguments, ...) and why it was
implemented in this specific way.

Of course it helps if you actually have access to different compilers
and different architectures. As I said, I already knew a bit of 6502 and
Z80 assembler (and machine code - those were the days of PEEK and
POKE). I first learned programming C on an 8086 and at the university I
had access to a VAX. And I discovered comp.lang.c, where lots of very
knowledgeable people (among them Henry Spencer, Doug Gwyn and Chris
Torek) were quick to disabuse you of any superstitions you may have
aquired by lack of experience.

> It won't give you a feel for, e.g., the architecture, translations of
> constructs in other languages,

Yes, it does. "A feel" is not the same as knowledge. But if you have
seen what a C compiler does you do have a feel for what a compiler in a
similar imperative language might do.

> instructions generated only from assembler code.

True, but mostly irrelevant in this context. Very little code today is
hand-crafted in assembler, so "what is actually executed at machine code
level" (as you wrote in an earlier posting) is usually generated by a
compiler. And you don't have to understand every detail to get "a sense"
or "a feel".

>>As an introductory language, "Processing"[1] might be a good choice.
>
> Probably kinder than what they did to us, which was to teach us
> machine language before introducing the concept of an assembler :-(

Helmut Schauer did that in his excellent "Introduction to CS" course at
the TU Vienna in the mid-1980's. And he introduced microcode before
machine code, adders before microcode, nand and nor gates before adders,
transistors before gates, and semiconductors before transistors. The
bottom-up approach makes sense, as does the historical approach (teach
concepts in the order they were invented). At least for a university
course. If you want to teach a bit of programming to a kid, you probably
should take a different approach.

hp


[1] You can't do that in 21 days. See http://www.norvig.com/21-days.html

[2] I think its unspecified, not undefined or implementation-defined.
Too lazy to look it up, and it doesn't make a difference here.

[Shmuel Metz]

In <slrnjrnt6v.n1...@hrunkner.hjp.at>, on 05/22/2012

at 10:19 PM, "Peter J. Holzer" <hjp-u...@hjp.at> said:

>The context was "learning C".

The claims made in that context were "Getting a decent sense of what

is actually being executed at the machine code level is important,

even if you don't intend to write at that level in practice." and, in
response to "Learning C will not give you a sense of what is actually
being executed at the machine code level.", "Counter example: it did
for me."

[Peter J. Holzer]

On 2012-05-23 04:06, Shmuel Metz <spam...@library.lspace.org.invalid> wrote:
> In <slrnjrnt6v.n1...@hrunkner.hjp.at>, on 05/22/2012
> at 10:19 PM, "Peter J. Holzer" <hjp-u...@hjp.at> said:
>
>>The context was "learning C".
>
> The claims made in that context were "Getting a decent sense of what
> is actually being executed at the machine code level is important,
> even if you don't intend to write at that level in practice." and, in
> response to "Learning C will not give you a sense of what is actually

^^^^^^^^^^
Here it is.

> being executed at the machine code level.", "Counter example: it did
> for me."

And yes, it did for me, too.

hp