[ale] [OT] First Programming Language for Adult??

[Byron Jeff]

Tom,

I'm sorry I'm late to the party. I wanted to throw in my two cents since
this area is part of my job description.

Before she dives in, I would strongly suggest that she step back and take a
30000 ft view of the issue. Specifically:

Programming isn't about languages. Programming is about solving problems.

Programming languages are a black hole that frankly sucks all the oxygen
out of the room of the programming process. If you start the programming
process by learning a language, you often miss the point.

The first of the most important ideas to get her understand is that it's
impossible to program anything if you cannot solve the problem yourself, by
hand. The second is that a programming language is simply an expression of
how to explain to an automatic system how to execute the solution to the
program that she (as the programmer) has already solved. Their utility is
in how they can help you express solutions. Be mindful they are not the
solution. Pretty much anything that needs to be programmed can be done in
any programming language.

Programming language books an tutorials spend all their time explaining HOW
to do something in a programming language. Unfortunately, they spend very
little time on WHY the process needs to be done (to solve problems) and
WHAT process needs to be done (algorithmic development).

Programming in general is like the process of writing a recipe for baking a
cake. You cannot explain to someone else how to bake a cake without first
knowing how to do it yourself. Then the process of explaining how to bake a
cake is different than the actual process of baking the cake. How many
times have you gotten frustrated trying to give directions to someone to a
place that you know how to get to? Knowing how to get there and explaining
how to get there are different activities. Now add on top of that idea that
you do not know how to get to the destination but you still need to explain
to someone else how to get there. Finally the person that you are giving
directions to only speaks Mandarin. Hopefully you can see the real
problems.

Welcome to the wonderful world of programming.

Programming language books teach Mandarin. They don't teach how to write
recipes. They don't teach how to bake. They presume that the student
already knows how to do the first two. It's often a flawed assumption.

I currently have on my whiteboard a list of steps for the Problem Solving
and Programming process. They are adapted from concepts from George Polya's
book: How to Solve It. There's a Wikipedia entry that outlines the process.
They book isn't perfect because Polya was a mathematician. But it's
actually helpful that it was written in 1945 (and updated of course over
the years) because it doesn't focus on computer languages. The steps:

1. Read, Understand, and Explain the problem.

To reiterate, you cannot solve a problem that you do not understand
yourself.

2. Design potential solutions for the problem, then test to see if those
solutions actually solve the problem. This should be done in an adhoc non
programmatic environment (such as paper).

This is the algorithic design step. Shackleford's book is good for this
because he deliberately abstracts out the programming language.

3. Map the solution elements from step #2 onto the programmatic elements
available in the programming language of your choice.

After problem solving the next programming step is translation into
whatever limited programming language is going to be used for the task.
This is where knowing the actual language is useful. Also this is a place
where design patterns are helpful because they are prepared mappings of
common solutions onto programmic language elements.

4. Write/Debug the program using the mappings from step #3.

Caution your student not to start here. The tendency is to want to generate
the artifact. But clearly it cannot be done without a plan.

5. Test, Test, and Test the final artifact.

There has to be empiracal evidence of correct operation. Just because a
program is written doesn't mean that it is correct.

Expert programmers tend to internalize the first 3 steps. Some muttering
along with some hastily jotted notes is typically enough to get them
through steps 1-3 for most small to medium sized projects. However, novices
are not practiced enough or exposed enough to that process to simply
presume that they know how to do it. 

The early process is complicated by the fact that the tools that many of us
learned for doing algorithm development (flowcharts, etc.) have fallen by
the wayside as design tools. I've been searching for the appropriate tools
for novice programmers. Nothing is a perfect fit:

- Nassi-Shneiderman Charts seem to be a useful alternative to traditional
  flowcharts. However, like flowcharts they are strictly procedurally
  based.

- UML at some level is appropriate for object oriented design. The
  challenge here is trying to avoid "Love what you learn first." syndrome
  because procedural and object oriented are two completely different
  design processes complicated by the fact that object oriented programming
  is a superset of proceduraal programming so that you really cannot do
  OO programming without understanding procedural concepts first. Check
  out: http://www.agiledata.org/essays/objectOrientation101.html for
  an introductory discussion. Also I would suggest the book "The Object
  Oriented Though Process" by Matt Weisfeld for a good discussion on
  the design process as opposed to the language focus.

Anyway I hope some of this motivates the process.

BAJ


On Fri, May 30, 2014 at 08:10:35AM -0400, Tom Freeman wrote:
> To chip, Ed, leam, Jay, JD, and Stephen in particular - thank you
> very much. I will be passing full text on for her consideration.
> 
> In summary, Python & Java (in that order) are considered solid first
> languages. Go is of significant interest. Language direction after
> that is pretty much go where life leads, although MS Access does get
> a down check in comments.
> 
> I haven't dug properly into the links suggested, but the digging at
> this point says they are solid - as expected from this group.
> 
> Thank you to one and all for the use of your bandwidth
> 
> On Thu, 29 May 2014, Tom Freeman wrote:
> 
> >
> >My apologies for using up people's bandwidth for something not
> >really linux, but this list is the best resource I know of for
> >access to computer people with an insane breadth of backgrounds
> >and opinions. And they are willing to share.
> >
> >A few days ago my daughter asked for an opinion as to a computer
> >language for her to learn. No, she doesn't have a project in mind,
> >which would have at least focused the discussion a little bit. She
> >is a university librarian, however, should that have any bearing
> >on the discussion. She has access to a moderate amount of
> >materials for "Alice", which apparently her school uses for
> >programming introduction.
> >
> >My advice, which should be considered highly flawed, was to take
> >advantage of the "Alice" materials as a first, quick step. Follow
> >that with perhaps either some work in Python or Java, with the
> >Java due to her constant involvement in tiny web projects.
> >
> >If the Python or Java settles, and the itch continues, I was
> >suggesting a second language, possibly data base oriented for the
> >library work, or something derived from either FORTH or LISP for
> >the mind expansion properties. As yet another alternative -
> >cshell(?) since she prefers the macintoy.
> >
> >(I had a relative utterly in love with FORTH and very good at it
> >also. Unfortunately, he thought _everybody_ should program in
> >it... Not a very successful idea unfortunately.)
> >
> >The multipart question here seems to be:
> >1) Is there a proper solid resource for building some programming
> >skill that I should have know about and don't?
> >2) Did I suggest a moderately reasonable approach in the eyes of
> >people who _actaully_ program?
> >3) Is there probably a better approach I should have known about?
> >
> >Thanks to all for the use of their bandwidth.
> >
> >_______________________________________________
> >Ale mailing list
> >Ale at ale.org
> >http://mail.ale.org/mailman/listinfo/ale
> >See JOBS, ANNOUNCE and SCHOOLS lists at
> >http://mail.ale.org/mailman/listinfo
> >
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo

-- 
Byron A. Jeff
Chair: Department of Computer Science and Information Technology
College of Information and Mathematical Sciences
Clayton State University
http://faculty.clayton.edu/bjeff