<p dir="ltr">If she wants to become a good programmer, then she needs to learn REAL programming languages. Fortran and Assembly are the only ways to go! Do not settle for anything less!</p>
<p dir="ltr">=)</p>
<p dir="ltr">But really, Python is a great first language. </p>
<p dir="ltr">Java and C# are marketable, though both languages have their critics. These would make good second languages. </p>
<p dir="ltr">C should be learned eventually, but down the road. The general concept of how assembly works is also nice to understand, but proficiency in assembly is becoming a niche thing. </p>
<p dir="ltr">Functional programming is starting to get a buzz in some circles, so Haskell would be another good language down the road.</p>
<p dir="ltr">C++ is going through many exciting new changes, but it's a complicated language. I've never used D, but it's being worked on by a well respected C++ authority. </p>
<div class="gmail_quote">On May 31, 2014 9:41 PM, "Tom Freeman" <<a href="mailto:tfreeman@intel.digichem.net">tfreeman@intel.digichem.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Jeff<br>
<br>
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."<br>
<br>
In any event - I've passed the information along<br>
<br>
On Sat, 31 May 2014, Byron Jeff wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Tom,<br>
<br>
I'm sorry I'm late to the party. I wanted to throw in my two cents since<br>
this area is part of my job description.<br>
<br>
Before she dives in, I would strongly suggest that she step back and take a<br>
30000 ft view of the issue. Specifically:<br>
<br>
Programming isn't about languages. Programming is about solving problems.<br>
<br>
Programming languages are a black hole that frankly sucks all the oxygen<br>
out of the room of the programming process. If you start the programming<br>
process by learning a language, you often miss the point.<br>
<br>
The first of the most important ideas to get her understand is that it's<br>
impossible to program anything if you cannot solve the problem yourself, by<br>
hand. The second is that a programming language is simply an expression of<br>
how to explain to an automatic system how to execute the solution to the<br>
program that she (as the programmer) has already solved. Their utility is<br>
in how they can help you express solutions. Be mindful they are not the<br>
solution. Pretty much anything that needs to be programmed can be done in<br>
any programming language.<br>
<br>
Programming language books an tutorials spend all their time explaining HOW<br>
to do something in a programming language. Unfortunately, they spend very<br>
little time on WHY the process needs to be done (to solve problems) and<br>
WHAT process needs to be done (algorithmic development).<br>
<br>
Programming in general is like the process of writing a recipe for baking a<br>
cake. You cannot explain to someone else how to bake a cake without first<br>
knowing how to do it yourself. Then the process of explaining how to bake a<br>
cake is different than the actual process of baking the cake. How many<br>
times have you gotten frustrated trying to give directions to someone to a<br>
place that you know how to get to? Knowing how to get there and explaining<br>
how to get there are different activities. Now add on top of that idea that<br>
you do not know how to get to the destination but you still need to explain<br>
to someone else how to get there. Finally the person that you are giving<br>
directions to only speaks Mandarin. Hopefully you can see the real<br>
problems.<br>
<br>
Welcome to the wonderful world of programming.<br>
<br>
Programming language books teach Mandarin. They don't teach how to write<br>
recipes. They don't teach how to bake. They presume that the student<br>
already knows how to do the first two. It's often a flawed assumption.<br>
<br>
I currently have on my whiteboard a list of steps for the Problem Solving<br>
and Programming process. They are adapted from concepts from George Polya's<br>
book: How to Solve It. There's a Wikipedia entry that outlines the process.<br>
They book isn't perfect because Polya was a mathematician. But it's<br>
actually helpful that it was written in 1945 (and updated of course over<br>
the years) because it doesn't focus on computer languages. The steps:<br>
<br>
1. Read, Understand, and Explain the problem.<br>
<br>
To reiterate, you cannot solve a problem that you do not understand<br>
yourself.<br>
<br>
2. Design potential solutions for the problem, then test to see if those<br>
solutions actually solve the problem. This should be done in an adhoc non<br>
programmatic environment (such as paper).<br>
<br>
This is the algorithic design step. Shackleford's book is good for this<br>
because he deliberately abstracts out the programming language.<br>
<br>
3. Map the solution elements from step #2 onto the programmatic elements<br>
available in the programming language of your choice.<br>
<br>
After problem solving the next programming step is translation into<br>
whatever limited programming language is going to be used for the task.<br>
This is where knowing the actual language is useful. Also this is a place<br>
where design patterns are helpful because they are prepared mappings of<br>
common solutions onto programmic language elements.<br>
<br>
4. Write/Debug the program using the mappings from step #3.<br>
<br>
Caution your student not to start here. The tendency is to want to generate<br>
the artifact. But clearly it cannot be done without a plan.<br>
<br>
5. Test, Test, and Test the final artifact.<br>
<br>
There has to be empiracal evidence of correct operation. Just because a<br>
program is written doesn't mean that it is correct.<br>
<br>
Expert programmers tend to internalize the first 3 steps. Some muttering<br>
along with some hastily jotted notes is typically enough to get them<br>
through steps 1-3 for most small to medium sized projects. However, novices<br>
are not practiced enough or exposed enough to that process to simply<br>
presume that they know how to do it.<br>
<br>
The early process is complicated by the fact that the tools that many of us<br>
learned for doing algorithm development (flowcharts, etc.) have fallen by<br>
the wayside as design tools. I've been searching for the appropriate tools<br>
for novice programmers. Nothing is a perfect fit:<br>
<br>
- Nassi-Shneiderman Charts seem to be a useful alternative to traditional<br>
flowcharts. However, like flowcharts they are strictly procedurally<br>
based.<br>
<br>
- UML at some level is appropriate for object oriented design. The<br>
challenge here is trying to avoid "Love what you learn first." syndrome<br>
because procedural and object oriented are two completely different<br>
design processes complicated by the fact that object oriented programming<br>
is a superset of proceduraal programming so that you really cannot do<br>
OO programming without understanding procedural concepts first. Check<br>
out: <a href="http://www.agiledata.org/essays/objectOrientation101.html" target="_blank">http://www.agiledata.org/<u></u>essays/objectOrientation101.<u></u>html</a> for<br>
an introductory discussion. Also I would suggest the book "The Object<br>
Oriented Though Process" by Matt Weisfeld for a good discussion on<br>
the design process as opposed to the language focus.<br>
<br>
Anyway I hope some of this motivates the process.<br>
<br>
BAJ<br>
<br>
<br>
On Fri, May 30, 2014 at 08:10:35AM -0400, Tom Freeman wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To chip, Ed, leam, Jay, JD, and Stephen in particular - thank you<br>
very much. I will be passing full text on for her consideration.<br>
<br>
In summary, Python & Java (in that order) are considered solid first<br>
languages. Go is of significant interest. Language direction after<br>
that is pretty much go where life leads, although MS Access does get<br>
a down check in comments.<br>
<br>
I haven't dug properly into the links suggested, but the digging at<br>
this point says they are solid - as expected from this group.<br>
<br>
Thank you to one and all for the use of your bandwidth<br>
<br>
On Thu, 29 May 2014, Tom Freeman wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
My apologies for using up people's bandwidth for something not<br>
really linux, but this list is the best resource I know of for<br>
access to computer people with an insane breadth of backgrounds<br>
and opinions. And they are willing to share.<br>
<br>
A few days ago my daughter asked for an opinion as to a computer<br>
language for her to learn. No, she doesn't have a project in mind,<br>
which would have at least focused the discussion a little bit. She<br>
is a university librarian, however, should that have any bearing<br>
on the discussion. She has access to a moderate amount of<br>
materials for "Alice", which apparently her school uses for<br>
programming introduction.<br>
<br>
My advice, which should be considered highly flawed, was to take<br>
advantage of the "Alice" materials as a first, quick step. Follow<br>
that with perhaps either some work in Python or Java, with the<br>
Java due to her constant involvement in tiny web projects.<br>
<br>
If the Python or Java settles, and the itch continues, I was<br>
suggesting a second language, possibly data base oriented for the<br>
library work, or something derived from either FORTH or LISP for<br>
the mind expansion properties. As yet another alternative -<br>
cshell(?) since she prefers the macintoy.<br>
<br>
(I had a relative utterly in love with FORTH and very good at it<br>
also. Unfortunately, he thought _everybody_ should program in<br>
it... Not a very successful idea unfortunately.)<br>
<br>
The multipart question here seems to be:<br>
1) Is there a proper solid resource for building some programming<br>
skill that I should have know about and don't?<br>
2) Did I suggest a moderately reasonable approach in the eyes of<br>
people who _actaully_ program?<br>
3) Is there probably a better approach I should have known about?<br>
<br>
Thanks to all for the use of their bandwidth.<br>
<br>
______________________________<u></u>_________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/<u></u>listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/<u></u>listinfo</a><br>
<br>
</blockquote>
______________________________<u></u>_________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/<u></u>listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/<u></u>listinfo</a><br>
</blockquote>
<br>
<br>
</blockquote>
______________________________<u></u>_________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/<u></u>listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/<u></u>listinfo</a><br>
</blockquote></div>