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.

 

[Tim Watts]

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

 

[ccc31807]

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.

 

[Peter J. Holzer]

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.

 

[Martijn Lievaart]

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

 

[Peter J. Holzer]

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.

 

[Peter J. Holzer]

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