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

Tom Freeman tfreeman at intel.digichem.net
Sat May 31 21:38:33 EDT 2014


Jeff

I think you make some seriously valid points - although this child is "I 
don't know what I need - so I'll learn something new just in case it 
becomes useful."

In any event - I've passed the information along

On Sat, 31 May 2014, Byron Jeff wrote:

> 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
>
>


More information about the Ale mailing list