Go is for everyone

[Matt Aimonetti]

I just wanted to point out a post I published today talking about the fact that we are often leaving new / less experienced Go developers high and dry:

https://medium.com/@mattetti/go-is-for-everyone-b4f84be04c43

I'd love to see what you all in mind to help new or junior developers. Maybe share some of the pain points you've experienced or seen (for instance setting up the Go path, finding resources to get started etc...) I'm thinking about a bunch of very short posts on basic topics and maybe a real beginner tour of Go. We are going to do a beginner night next month at our LA/Santa Monica Go meetup and hopefully better understand what the current pain points/blockers are.

What do you think?

[Daniel Skinner]

is the Go tour really that out of touch for people with little to no programming experience? I'd think there's enough in there to keep one busy for quite a while. Now, whether that work is actually interesting to them is another matter...

I sat my 9 year old daughter in front of the tour a few months back and she completed a number of samples. She had questions for words she's never heard so maybe extending the tour with pop-out help on jargon might be a nice contrast to how the tour currently compares itself to other languages for basic constructs (the inexperienced vs the experienced).

Understanding errors on the screen is another important part that's pretty much uncovered, and so biased towards those that have dealt with errors before from other languages.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Will Norris]

I don't think the GopherCon 2016 videos are online yet, but when they are I'd recommend taking a look at Katrina Owen's talk, "Mind the Gap" which touches on exactly this topic.  It might give you some ideas.

[Matt Aimonetti]

There are a lot of concepts we take for granted such as functions/methods, the main func, strings etc.. Then a lot of the exercises are quite technical/math related instead of being more day to day based.

I love the tour but I think it works best if you're already a developer.

[Konstantin Khomoutov]

On Tue, 19 Jul 2016 10:14:26 -0700 (PDT)
Matt Aimonetti <mattai...@gmail.com> wrote:

> There are a lot of concepts we take for granted such as
> functions/methods, the main func, strings etc.. Then a lot of the
> exercises are quite technical/math related instead of being more day
> to day based. I love the tour but I think it works best if you're
> already a developer.

I really don't want to discourage you but are you really sure Go is a
good candidate to be the someone's first PL? I, for one, doubt so.

I mean, some people (me included) learnt programming "from the bottom
up" by starting with some assembler and then gradually moving "upwards";
when you're progressing along this vector, concepts like memory layout,
pointers and difference between []T and []*T (and what the hell the
slice really is) are not that hard to grasp.

But when you start from another edge of this complexity continuum,
these concepts _will_ be challenging, and IMO Go was explicitly
designed to not be too high-level: it's definitely simpler than C but
keep in mind that it was actually envisioned to convert C++ programmers
so it still gives you enough raw power and control to be closer to the
hardware and the OS.

What I'm leading to, is that supposedly before actually learning Go,
a wannabe programmer starting with no prior CS-related knowledge should
start with something like ABC [1] to grasp the very basic concepts like
values, variables, functions, parameter passing, manipulating
collections etc.

But what I'm afraid even more is that tutoring is like parenting:
everyone thinks they know how to do it, but that's a delusion.
I'm not a professional tutor and I understand that I actually have no
idea what happens in the minds of those making their first steps in
learning how to program. (That's why I value very much the feedback
provided by Daniel Skinner--that was the real first-hand experience.)
I hence think that ideally you should get in touch with some person who
has learning expertise. Talking with seasoned programmers on this topic
appears to be somewhat pointless to me. ;-)

1. https://en.wikipedia.org/wiki/ABC_(programming_language)

[Konstantin Khomoutov]

On Tue, 19 Jul 2016 20:54:21 +0300
Konstantin Khomoutov <flat...@users.sourceforge.net> wrote:

[...]

> But what I'm afraid even more is that tutoring is like parenting:
> everyone thinks they know how to do it, but that's a delusion.
> I'm not a professional tutor and I understand that I actually have no
> idea what happens in the minds of those making their first steps in
> learning how to program. (That's why I value very much the feedback
> provided by Daniel Skinner--that was the real first-hand experience.)
> I hence think that ideally you should get in touch with some person
> who has learning expertise. Talking with seasoned programmers on
> this topic appears to be somewhat pointless to me. ;-)

[...]

In the hope to explain my point better, I'd like to refer to a blog
post by Caleb Doxsey [2] which explains what I'm afraid of in this
regard: seasoned programmers have hard time actually explaining how it
comes they possess the skills they have, and this makes their world
view biased. I beleive most programmers on this list could skim through
the Go Tour (I never did it FWIW) and won't supposedly spot any problem
with it because they possess the necessary knowledge to not spot any
problems newcomers could come to grips with.

2. http://www.doxsey.net/blog/tacit-knowledge

[Bakul Shah]

What worked for us: @ Work review of code written by anyone in
my team *had* to have my ok before it could be committed.
Initially people *hated* it and it added a lot of work for me.
But this allowed me to provide specific help on every little
or big thing they ran into. In addition to detailed comments
explaining why something needed to be done differently, I
pointed them to pertinent online documents/tutorials/talks
etc. And I added make targets for go vet, fmt, race, test,
coverage etc. that they had to run before submitting a code
review. In addition we had a local "developer's guide" with
links to various things that they started with.

I think what helped the most: a) they *had* to actually do the
work I suggested or argue why their way was better or discuss
design issues in some depth. b) they could reread review
comments & dialog. Basically all the good intentions are
not enough if you don't actually do the work and I needed
to give them an incentive to do so!

Pretty soon the person who hated it the most learned the
quickest way to get through his reviews + his reviews of other
people's code were as tough as mine so now he and I share the
code review load. We will add more people once they reach the
level I want.

Anotther thing I learned is that people use a looming deadline
as an excuse to slack off and once the code is committed,
their enthusiasm for fixing things goes way down. So I have
to stop being the nice guy on reviews!

As it happened, nobody other than me knew Go when we started
out and we had a number of junior programmers but by now I
think we do a decent enough job. [BTW, we *are* looking for
seasoned Go programmers! email me if interested]

Not suggesting this is what others should do; just stating my
experience.

[Jesper Louis Andersen]

On Tue, Jul 19, 2016 at 8:13 PM, Konstantin Khomoutov <flat...@users.sourceforge.net> wrote:

seasoned programmers have hard time actually explaining how it
comes they possess the skills they have, and this makes their world
view biased

This is true of any field in which you work. Your brain rewires itself and associates facts about the system you are studying. In the beginning everything is a stumbling block: pointers/references, recursion, monads, lambda calculus, group theory, topology, separation logic, quantum mechanics, and so on. You struggle to understand it all. But once you grasp it, and you get familiar with the subject, you automatically leap around in the field. Things _has_ to be a certain way for it to work. You can make the mental connection as to why it is so if you think hard about it, but usually you don't do that. And over time, your brain rewires its logic such that it _must_ be true, it cannot be otherwise. This gives you mastery in the field since you are not clawing yourself through the details anymore, but can look at the area from above and plot our a course to a solution easily.

Once this happens, it becomes gradually harder to explain the subject to a beginner unless you regularly teach the subject to others. If you forget the initial struggle, and you don't know what it is people can't cope with when they start out, then you get the bias you mention.

The trick to mentoring is to gauge the level of the mentee and challenge them a bit above their current level. In no time they get their own world view inside the field, which very often has a feedback effect on the mentor: you suddenly both understand the subject better. The other trick is to understand computer science can be complex and some parts of the field requires incubation in ones brain for a while before you "get" it. This is often measured in weeks or months as the brain rewires :) So as a mentor one needs patience. Lots of patience.

--

J.

[Nate Finch]

Great post, and I agree wholeheartedly.  Go is far simpler to learn than any other production-ready language (excluding languages that are only used for teaching, like Scratch)... but AFAIK, there's no "intro to programming, which happens to use Go".  I think this is pretty easily doable (and I would be surprised if there weren't any colleges/highschools/grade schools doing that yet).  I think it has real merit to use a "real" language to learn, because then there's no barrier at the end of the course... the language scales with you.  There's no time when you have to jump off and learn something else until you're ready to go try python or java or whatever.

The one drawback I see is that right now, Go is mainly (very) good for writing boring things - CLIs and servers, for the most part.  Many people who haven't yet ventured into programming get drawn in by the thought of writing cool flashy things - a GUI or a webpage or a game they can show off to their friends.  Now, obviously, those things are also exponentially more difficult to code in general... but it's those kinds of things that grab people.  No one enters the field of mechanical engineering to design screw heads, for example, even if that's like 50% of the reality of the job.  This is a harder problem to solve, but not impossible.  Notably, it doesn't matter if what you built is incredibly narrow, or incredibly similar to what everyone else who goes through the into session has made.  As long as it's flashy and impressive, with a personal touch, then the creator will be proud and others will be impressed.

 

[Dan Kortschak]

It's an interesting post and something I can see being true to an
extent, but I'd like to put forward an alternative from my own
experience.

I came to Go as an extremely inexperienced programmer - a couple of
years with Perl and a childhood with C64 basic/6502/Z80 and virtually no
formal CS background (one half year unit in first year undergrad).

When I started using Go it had only been open sourced for a year and a
half. I found the support for people starting to use Go to be
outstanding even when questions were only tangentially related to Go
(generic algorithmic problems were happily(?) helped with). In part it
seems this was due to decisions by the Go core developers to help foster
a helpful and welcoming environment (rsc has discussed the motivations
for this in the past). Maybe that "fresh scene" has diminished a little,
but it doesn't really seem so to me.

Dan

[simran]

I personally find Go just a joy to program in and show my kids some code all the time (my kids are 9 years old)... it's still complex for them as i haven't overwhelmed them with programming. What they do absolutely LOVE though is code.org ( https://studio.code.org/ ) - their school has a extra-curricular class around it, and all the kids have taken to it with a huge amount of enthusiasm. 

The main thing i think they like is that it's visual - for an introduction (as a first language), i think the visual components really really help. At the moment, you can see the "JavaScript" behind the visual components you build, and the kids are starting to progress to that. What i believe might be really good is if we can help adapt code.org to also show potential "Go" code (as an alternative to the javascript) and let people tweak the Go. The educational and fun structure has already been built by code.org and they have done such a marvellous job, why not build on that?

[Tim Hawkins]

My personal experience is as somebody comming from almost 3 decades of oop with c++ and java,  while there are a lot of tutorials etc for folks starting out with go as a first or second language. I find there is a lack of support for people moving from other languages and other methodologies.

[Matt Aimonetti]

So much great feedback, that's really awesome.

What I'm hearing is that there are many different kinds of "newbies", from people coming other languages, to kids without forgetting hobbyists...

I learn things bottom up, I need to understand "why" before I can start using the "how". Lots of people don't learn that way and there is nothing wrong with that.

There are languages that are more suited to writing basic games and GUI for newbies (Flash was actually great at that). I actually don't think Go is the perfect fit for all new programmers. I do think however that if you want to learn the basics and you're willing to pay a certain price upfront, that's the right approach.

In this context, I'd like to personally focus on helping new developers who are interested in building some knowledge foundations. I very much agree about having something tangible they can be proud of, but I also don't think Go mobile is currently a good fit for that. Maybe it's a bot, maybe it's a CLI, maybe it's audio or image processing. I don't quite know yet, but I do know that very basic things such as strings and numbers, use of the terminal, finding stuff in the standard library are very poorly covered and maybe we/I should start there.

Another  simple thing I've been meaning to do so many times: provide example tests for the standard library. This way users who get started and learn the basic, can browse the doc and find concrete examples of how to use an API. This is such a powerful feature, and whenever I find one of those examples I'm very thankful! I'm sure we could, as a community, provide way more examples (it will slow down the test suite, but I think that's ok).

Anyways, keep the feedback coming!

[Clark Wierda]

Katrina's talk is a good starting point for considering the approach needed for those that don't already know programming.

I particularly like her idea of a sequence of skills to acquire as one learns to program using Go.

I know of two books that are aimed at teaching new programmers.  Each has an established order of presentation we can consider as we develop our progression.  Both use Python, but I feel the skills and order are still relevant to Go.

The first was used in a Coursera class I took.  It is Python for Informatics by Charles Severance.  This book is aimed at users wanting to using a program to process data more than user that want to be programmers.

The second book inspired the first.  It is Think Python: How to Think Like a Computer Scientist, 2nd Ed by Jeffrey Elkner, Allen B. Downey, and Chris Meyers.  This book has a more traditional CS focus and uses a bit more math that the Severance book.

I think we could use a concept/skill sequence derived from these books and our own concept, examples, and practice sets as a framework for the progression of a new programmer.

I cannot have an opinion related to the Tour as I arrived with decades of experience using many languages.  It got me to where I needed and the reference material available worked from there.

I will say that Katrina's talk rang true for me and one of the things she mentioned that the Tour does not have is the drill needed to make the concept your own.  The Tour is very good at demonstrating what it intends to show, but it does not provide the directed practice that a new programmer needs.  Lots of  programming without direction is just typing practice.  Directed practice allows the programmer to develop a level of comfort with the concepts and skills needed for true competence.

[simran]

On Wed, Jul 20, 2016 at 1:10 PM, Matt Aimonetti <mattai...@gmail.com> wrote:

I learn things bottom up, I need to understand "why" before I can start using the "how". Lots of people don't learn that way and there is nothing wrong with that.

There are languages that are more suited to writing basic games and GUI for newbies (Flash was actually great at that). I actually don't think Go is the perfect fit for all new programmers. I do think however that if you want to learn the basics and you're willing to pay a certain price upfront, that's the right approach.

I couldn't agree with more with an approach that focuses on understanding the fundamentals. More than a decade ago (and the example still sticks in mind so vividly) i was working with one guy that had some bugs with that a webserver was sending back - i told him to look at the headers he was getting back, the cookies that were being set, etc as a starting point, and he looked at me blankly! It absolutely shocked me that he had been programming for 10 years and did not have any idea beyond drag-and-drop programming (yes, he was a "professional web programmer" being paid more than $100k/yr at that time) - my initial reaction was very judgemental; i pretty much put all windows / VB / etc programmers in the same basket - drag-and-drop without understanding the basics (i come from a very open source philosophy and background and it was not possible to be a web developer without hours of trying to compile apache (at least back in the mid 90's :) and understanding how things were linking together. Anyway, my judgement soon passed over me, as i'm sure others were looking at me and saying "how can that guy not understand how hardware works; that's the fundamental of all things"! 

Not sure if i am wiser, or just older, or more tolerant or more rigid... but i now believe that a visual learning style (in a walled environment (you can't export  your code and "ship it") like code.org is perfect for kids (and anyone new to programming). They can understand the concepts while being entertained; it's only the first step of many, but visual aids and assistance can lead to a deeper understanding - take for example concurrency vs parallelism - the amount of confusion around it is a lot, and yet, when you see this visual, everything is immediately crystal clear (yes, even 6 year olds i have shown this to get the difference with 2 minutes of explanation):

With regards to tour.golang.org, it is absolutely brilliant, but from memory, does not take you through things like "standard ways of writing unit tests", etc... that's where doing a fictitious but complete project would come in handy; code.org lacks this as well, but i feel if we had more "complete projects" for various levels, they would be the best help. Make going through the projects possible visually (like studio.code.org) but with the ability to slowly transition to the code written behind the visual, even better :) 

One could say there is a LOT of projects out there and we can learn from those, but the LOT of stuff out there is usually not good for "learning" as it's often missing documentation, stuff needs to be refactored, some of it is error prone, it's not structured the best or there's at least some issue with it (as it's not structured for someone to learn from). Anyway, i rant... but the TLDR version "studio.code.org is a brilliant start; i hope we can build on that, introduce some "complete projects" for various levels that ensure people understand the fundamentals, and can progress towards understanding and building "behind the scenes" stuff. 

[Tim Hawkins]

I would agree that a end to end tutorial on how to build a complete project,  say something simple like a blog site, using sqlite,  would be great, i could even be shipped with the distribution as a starter app.  Also the complexities of workspace layout, projecs standalone libraries, embedded libraries and using 3rd party libraries. However the tutorial would need to evolve as the laguage and environment did.

Having something that is a living and evolving example of best practices will creat a Resource that would get folks like myself with extensive development experience, just little go experience with a great starting point, and would also make a good boilerplate starter project.

[Egon]

So far my research, and small scale experiments (mostly one-on-one teaching), on this topic has lead me to these points.

I separated these into levels to make it easier to understand, however when teaching to some degree they can be mixed.

Level 0

These I consider fundamental, either you understand and learn them or you won't be able to program. Not knowing/understanding these are a better predictor than anything else I've seen:

1. Dealing with frustration

2. Problem Solving

3. Learning

Dealing and understanding frustration is one of the least taught things, but it has the biggest benefit to the learners. It helps with motivation and means people can stand more difficult problems when learning... also better willpower. Many seem to think that programming is similar to writing just a piece of text and when things don't go that easy, assume they are stupid and cannot learn it.

Dealing with frustration is essential part of programming. It can be avoided in two ways, either teach more gradually or teach how to deal and focus frustration.

There's a process how people solve problems and how they can solve them better. "How to Solve It" by Polya is great book on this book. Often people start randomly trying things rather than take a more structured approach to solving problems.

Learning here means that "learning the essence of things" rather than memorizing things. Some people have very good memorization skills, which means they can tell exactly what something is, but are not able to actually use it. "Learning How To Learn" is a good summary course on the topic https://www.coursera.org/learn/learning-how-to-learn 

Problem Solving and Learning can be made into a really good feedback loop -- i.e. you can "solve the problem how to learn faster/better" and you can "learn how to solve problems better"...

Using LightBot (https://lightbot.com/) it's possible to teach all of these ideas together. I.e. explain how people feel frustration, how to deal with it. Let them self-monitor how frustration builds and how they react to it. When getting stuck, show how scribbling on paper helps.

Level 1

Here we need to learn computational thinking, for better or worse. LightBot really helps here as well.

0. Syntax and tooling or "we need to communicate with the computer"

1. Meaning of things or "computers are very stupid"

2. Making things concrete or "mapping your mental model to code"

3. Progams do what they do or "computers are still stupid"

4. Reaching the goal or "learn the process not the end-result"

5. Limits or "we are stupid"

With this knowledge people should be capable of writing programs 1000-5000LOC, i.e. things that don't require architecural descisions.

Extended notes, but old: https://github.com/egonelbre/spark/blob/master/basics-of-programming.rst

Level 2

This is mostly leveling up your skill and knowledge

1. Read code

2. Write code

Pick some:

3. Algorithmics (http://www.algorist.com/)

4. Web programming

5. Machine code

6. How memory works

7. How floating point works

8. Concurrency

9. Few more languages

...

Level 3

Here we have skills that would help you to build 1MLOC+ programs.

1. Learning different tradeoffs

2. How to analyze tradeoffs between different solutions

3. Writing some real programs with someone reviewing

4. Process of writing large program or "gradual stiffening"

For 2. there is a really nice exercise - write at least 10 different ways for converting temperature units.

Mentorship is an essential part, i.e. getting better people to review your code is the best thing that can happen.

4. is currently incomplete and least formulated... I only have ~3000 pages still to read and ~5 projects to write :), before properly starting to write about it.

Hopefully this helps somehow...

Sidenotes/Disclaimers:

I haven't had a good chance in teaching this way, so there might be some essential parts missing. However one-on-one sessions seem to be promising. I'm aware that class-room situations are more difficult. E.g. people will learn these at very different speed and trying to homogenize it, would always frustrate some... it's better to let people advance at a different pace.

+ Egon

[Egon]

Just realized one very important point, that I should have highlighted:

In the initial Level 0 and Level 1, helping and googling must be very controlled. The important part is teaching the process of solving problems and writing code.

While teaching, if there's an obvious syntax error, you should not point it out, but rather teach a process that helps them find it. Not letting them find the problem has a negative effect for solving more difficult problems. In other words, you've just let them skip learning "dealing with frustration" and "process of finding bug locations" on small scale.

At all costs avoid giving them the answer. If necessary make up a similar situation and explain how you would solve it there, but let them solve the original problem. Only explain the process.

Once they learn the process, you can give the answers to move faster to the next step ... how ever, it prevents people from practicing those processes... so then use it with caution.

Now in Level 2, it's necessary to teach proper Googling skill and how to get help etc. Then you have learned the foundation so there's less problem with giving a direct answer.

+ Egon

[Simon Ritchie]

I taught C to second year undergraduates back in the 1990s.  By this time, they had done some COBOL (those were the days), Pascal and assembler.  Two things they had great difficulty with were pointers and multithreading.  Multithreading is not such an issue because you can avoid it while they are learning the basics, but you couldn't avoid pointers for long.  Go is, if anything, even worse, because pretty much as soon as you introduce functions you have to get involved in pointers, because without pointers you can't write a function that sets data.  Other languages such as Java manage to hide pointers sufficiently well that you don't have to get to grips with them until you have the rest of the language under your belt.  Actually, I'm guessing that there are lots of successful Java programmers out there who have never really understood those things that Java calls references.

To be honest, I'm not entirely sure why pointers are such a big issue for students who had done a bit of assembler, but trust me, for some they are.  I think one reason may be that they are one of a set of related concepts, and you have to understand them all before any one of them makes sense.

Multithreading is a different matter. I just found that many people have great difficulty visualising several threads working at the same time.

Apart from those specific issues, people new to programming have great difficulty with the idea of (a) variables and (b) expressions.  These very fundamental and crucial ideas are actually quite hard to grasp.  To a newcomer, it all just looks very arbitrary.  I have a variable called "total", but it could just as  easily be called "wibble".  Why is it called "total" then?  What are the rules?  This variable contains a string.  What's a string?  Oh, it's a bit of text.  Why would I want to store a bit of text?  Because the instructor understands these concepts very well, they often don't appreciate how difficult some people find them at first, and they take them at too fast a pace.

Changing tack completely, I've also encountered a different problem.  Most people are only interested in computers when they do useful things - useful to them.  So, the instructor shows them a program that takes two numbers, adds them together and displays the result.  They can do that themselves with a calculator.  Take a list ten numbers that are out of order and sort them.  Why not just write the list in the correct order in the first place?  What's the point of all this?  Many people are just not willing to go through many hours of artificial examples on the assumption that they might one day learn something useful.  You have to convince them before you begin that they are going to learn something useful (to them) and keep them on board throughout.

If you think about it, why not just write the list in the correct order in the first place? is actually a fundamentally important question, involving stuff that we are good at, and computers are bad at.  We can just look at a small list of numbers and write it down in sorted order.  Why can't the computer do that?   The answer to you is probably so obvious that it shouldn't need explaining, something on the lines of "it's not the same problem when you have a million numbers", but then why would I be interested in sorting a million numbers into order?

Sorry if this is a bit vague.  I've been thinking about this stuff ever since I gave up teaching many years ago.  I know what some of the problems are, but I'm really not certain of the answers.

[Egon]

On Wednesday, 20 July 2016 12:40:01 UTC+3, Simon Ritchie wrote:

I taught C to second year undergraduates back in the 1990s.  By this time, they had done some COBOL (those were the days), Pascal and assembler.  Two things they had great difficulty with were pointers and multithreading.  Multithreading is not such an issue because you can avoid it while they are learning the basics, but you couldn't avoid pointers for long.  Go is, if anything, even worse, because pretty much as soon as you introduce functions you have to get involved in pointers, because without pointers you can't write a function that sets data.  Other languages such as Java manage to hide pointers sufficiently well that you don't have to get to grips with them until you have the rest of the language under your belt.  Actually, I'm guessing that there are lots of successful Java programmers out there who have never really understood those things that Java calls references.

To be honest, I'm not entirely sure why pointers are such a big issue for students who had done a bit of assembler, but trust me, for some they are.  I think one reason may be that they are one of a set of related concepts, and you have to understand them all before any one of them makes sense.

I've explained pointers in terms of arrays...

var memory [1<<10]byte

// defining a pointer

p := 10

// assigning to a pointer
memory[p] = 123 // *p := 123

// dereference

fmt.Println(memory[p]) // *p

// indexing array starting at p

fmt.Println(memory[p+8])

// double dereference

fmt.Println(memory[memory[p]]) // **p

Then show how you can store bigger values, structs or strings... etc.

Multithreading is a different matter. I just found that many people have great difficulty visualising several threads working at the same time.

For multithreading "The Little Book of Semaphores" by A. Downey (http://greenteapress.com/wp/semaphores/), it has many exercises about "how things can go wrong", which is one of the fundamentals of concurrency.

[Michael Jones]

My favorite introductory C/C++/Basic/Pascal books are those by Donald Alcock—a master of progressive revelation and visual facilitation. If you don’t know these books, you might follow the link and have a preview.

 

http://www.cambridge.org/us/academic/subjects/computer-science/programming-languages-and-applied-logic/illustrating-c-2nd-edition

 

The other key thing for new students —beyond creating a visual model of concepts—is mutable examples. The Go Playground makes this very easy. It allows the “false” introduction of simple statements that work generally, then later, example input that causes problems, and then based on that motivation, code refinement to solve those problems (list size = 0, negative surd in a cubic equation, whatever…). If you know TeX and Donald Knuth’s TeX Book, then this is like the “Dangerous Bend” signs that he uses. Very valuable didactic approach.

--

[Nick Sarbicki]

I'm brand new to go (started on Saturday, haven't made my mind up yet) and have come over from python. I also teach kids to code (python) so thought I'd give my two cents.

Firstly, compared to languages like C, go is easy to learn, compared to languages like JavaScript and python, it isn't.

In my opinion a person's first language should be an easy one. As Egon said, the early struggles are almost entirely based on problem solving and bug fixing. If you can't focus on these because the languages complexities gets in the way, the learner gets put off.

In my experience kids can learn control flow in about 30 minutes. They can learn some paradigms like OO and why it's useful on maybe an hour. But they take much much longer to be able to come up with a solution to a problem by themselves. The easier it is to put the solution down in code the better.

So while I think go is a relatively easy language to learn and has some place in teaching, I'm not convinced it's the best starter language - which should be as easy as possible. There are a few added complexities and a bit more inertia which more seasoned programmers won't think about (setting up specific folder structures and compilation as an example).

That said I think it's a perfect second language. Personally I learn things at a high level first, and then as I dig in I find things which interest me and start slowly going more low level. Go isn't my first foray into the lower level. But I wish it was. It's easier to write and read then most. But it still teaches basic concepts like pointers, compilation and whatever else you can think of which are abstracted away in higher level languages.

In short, teach something higher level first to understand basic coding concepts and to start designing solutions. Teach go next to learn more about how languages work and get closer to the hardware.

As an aside: for those discussing the ability to teach a topic using your students level of understanding instead of your own more specialised perspective. The term for this is decentering.

- Nick.

[Ralf Schülke]

Hi,

Programming language is secondary level.
first must be clear as works as a Computer (machine) production.

In my early time, which was very clear but hard 8bit machines could one still imagine today the machine are a thousand times faster and their possibilities as well.

Alone GPU, I / O, the kernel and userland programming there is also so much you need to know.

In my time, BASIC was the only and my imagination and my own motivation, books and friends.

Today, we have the Internet, www and 100 of possibilities. Many new want to make games whose examples same (3d games etc). Only this day expenses with very large and it takes a long time and can not be done by a single person.

Conclusion:
-  Learn how works a Machine
 (Neumann architecture) or DCPU16 Emu. Number systems, bits & bytes, asm
- Programming paradigms, Unix philosophy, data structures
- Then golang as first language

Personally, I also think that one aspect, about the attitude as a programmer:
- Open source vs closed source
- Hacking (white vs black)
- Judge of techniques
- Behave in a network (jargon file)

[Egon]

Note, I do not agree that this is the best way for most beginners to start programming, however I think it's important for professional programmer to understand how computers work internally.

People can get a lot of value by just wiring libraries together... even if the code doesn't look great and/or breaks sometimes.

In a similar sense, I would not recommend learning piano by first seeing how the piano works. However, if you are a professional, you probably should know how to tune the piano, understand piano voicing and basic maintenance.

This sort of teaching has a high frustration level and low reward... however people who manage to get through it, would definitely be good programmers. And if you have intrinsic motivations, it makes it so much easier. There are of course ways to make reward higher, e.g. TIS-100 comes to mind. The younger the people, the higher you want the reward and lower the frustration.

It helps to keep in mind that there are different audiences for programming - children, teenagers, adults, personal programming, computer scientists, software developers, computer technology, robotics ... Of course people are different, so no single strategy for teaching can work, there should be multiple of them.

Sidenote: the best course for computer internals I've seen is http://www.nand2tetris.org/.

For computer technology and robotics people, it would be an excellent approach. For teaching children methodical thinking and problem solving to children, not so much.

But, I also do not consider "no-frustration" the best approach either. In a similar sense, to learn running you must eventually get tired and there's no way around it.

w.r.t paradigms, unix philosophy and data-structures... although important for professional developers, it's hard to convey the importance of them, without having real-world problems backing them. I.e. you can give a mathematical definition of functional programming, but people will just forget or don't pay attention to it -- basically they don't get the point and hence won't understand. Alternatively, it becomes a cult thing -- i.e. FP is good hence I will use it, without seeing it being used in real-world. (Just an example, I don't have anything against FP... I could say the same about SP, OOP, LP, AOP etc.)

There's one major additional concern with this sort of teaching -- it ignores the human aspects of software development. If you focus on learning technology instead of focusing on people, you get software that serves engineers rather than people using it. There must be a good balance between those two sides.

There's a ton of things I would consider worth learning for developers -- but there's just too much information... effective teaching means teaching the bits that are either hard to learn or things that empowers learning everything else.

+ Egon

[Nathan Fisher]

Hi,

If go run is the primary starting point you wouldn't need the GOPATH configured.

What I think would be interesting is the ability that most scripting languages provide which is to just start coding. No functions requiring definition and perhaps an auto-import of fmt, strings, io, etc. So you could write something like this:

''' hello.gos
fmt.Println("hello world")
'''

And then type 'go runscript hello.gos'. I know this is horrible for all sorts of reasons but I'm reminded of what a friend said about writing: "get it writ, then right"

For some one completely new to programming there's a reduced burden of the concepts to understand in the above. Thoughts?

Kind Regards,
Nathan

--

- from my thumbs to yours

[Nick Sarbicki]

If go run is the primary starting point you wouldn't need the GOPATH configured.

What I think would be interesting is the ability that most scripting languages provide which is to just start coding. No functions requiring definition and perhaps an auto-import of fmt, strings, io, etc. So you could write something like this:

''' hello.gos
fmt.Println("hello world")
'''

And then type 'go runscript hello.gos'. I know this is horrible for all sorts of reasons but I'm reminded of what a friend said about writing: "get it writ, then right"

For some one completely new to programming there's a reduced burden of the concepts to understand in the above. Thoughts?

 

Whilst I think the simpler something is the better it is for teaching, not sure I'd advocate changing a language just to make it slightly easier for beginners.

There are languages around which are ideal for getting people into the mindframe of coding. What should really be encouraged is the attitude of picking up multiple languages after you are comfortable.

Every course I've been on has always centered around how great coding is and why the language they are using is ideal. Not sure I've ever heard anyone at the end say "But you should really pick up x, y, z if you want to do a, b, c".

I think it would be better to accept a certain place in the teaching curriculum rather than try to cater for everyone - less code smell.

- from my thumbs to yours

You type with your thumbs? ;-)