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
On Wed, 20 Jul 2016 at 14:28, Nick Sarbicki <nick.a.sarbi...@gmail.com>
wrote:
> 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.
>
> On Wed, 20 Jul 2016, 12:07 Michael Jones, <michael.jo...@gmail.com> wrote:
>
>> 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.
>>
>>
>>
>> *From: *<golang-nuts@googlegroups.com> on behalf of Egon <
>> egonel...@gmail.com>
>> *Date: *Wednesday, July 20, 2016 at 3:31 AM
>> *To: *golang-nuts <golang-nuts@googlegroups.com>
>> *Subject: *[go-nuts] Re: Go is for everyone
>>
>>
>>
>>
>>
>> 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.
>>
>>
>>
>>
>> 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.
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
- from my thumbs to yours
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
