Go generator

[Matt Aimonetti]

Blockly currently doesn't have any generators for typed languages and I'm interested in looking into making that happen with Go: https://golang.org/ 

Talking with Neil offline he asked me to consider for a moment what Go code you'd generate for these blocks:

As you can see, the problem here is typing, `thing` could be a string or an integer depending on the result of the random condition.

There are two ways I can think about solving this issue. 

One is to use an empty interface as illustrated in the following example allowing a variable: https://tour.golang.org/methods/14

The nice thing with this approach is that it is very flexible, the bad thing is that any code down the road using the `thing` variable would have to do a type switch to verify the method can be dispatched to the receiver (making the code more complex).

The other approach is to walk down the AST and assign the best type based on how the variable is used. For instance, in this case, `thing` would be of type string and it the test is set to false, thing would be set to "42".

Any thoughts, feedback, suggestions, interest?

[Daaron Dwyer]

Hi Matt,

I'd be interested to see a Go generator. I've been wanting to play with Go, and this might be a good way to do it. I'm also very curious about how people are trying to solve the sticky typing problem in typed languages, as you're illustrating. While I generally come down on the duck-typing side, with blockly I resorted to everything as strings (even objects, converting to JSON), dodging the whole typing conundrum by ignoring it altogether. My choice has clear implications for more complex values, so I stay tuned to this sort of question.

Cheers,

Daaron

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

[Austin Bart]

For BlockPy, we parse the AST and process it using a static program analyzer. This allows us to ascertain the types of variables, and we can change the types of blocks to enforce constraints - in theory we could be changing block shapes or types too. We do this because we felt it was a safe reduction in the kinds of the program users should be writing. If you're coding in BlockPy, it's okay to assume certain constraints about the user being a student who should only be coloring inside the lines, so to speak. I think it's helpful to strongly consider what kind of audience you're developing for. Do you want this to be more general purpose, or are you okay with enforcing constraints for the sake of teaching?

~Cory

[Andrew Stratton]

Hi Matt

  Interesting - I have considered before creating a Blockly version of Go. I think (as Austin says) it depends very much on your purpose/audience.

  If you want to teach Go - then I would create a Go specific set of blocks - I can't see that reusing the current blocks is going to easily fit the type system - and channels are a major concern for me.

  If you want to teach programming - then I (personally) wouldn't choose Go as a first language - it's a great language, but I think it's best as a second/third language.

  If you want to teach concurrency/parallelism - then again, I would go for a Go specific set of blocks - which could nicely allow for go routine, wait groups, channels, etc.

  By 'A Go specific set of Blocks', I mean to develop the Go Blocks from scratch and not to reuse the current language block s- which I can't see fitting well.

  Hope this helps - and best of luck - Andy Stratton

[Matt Aimonetti]

I am interested in teaching programming. I disrespectfully disagree with you about Go not being a great first language. I think it's small scope, reduced complexity and consistency makes it for a great first language (and so does the fast compiler giving immediate feedback to the programmer).

Concurrency and parallelism are great but they are advanced feature of the language and you can code Go without those.

That said, later on it might be nice to add Go specific Blocks to teach those concepts, but we aren't there yet.

--
You received this message because you are subscribed to a topic in the Google Groups "Blockly" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/blockly/_y6rK_NhtNs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blockly+u...@googlegroups.com.

[GB-)]

I apologise if I seem negative, I'm still new here.
Also, it sometimes seems like it is easier to try to come up with an ingenious answers than decide a question is not appropriate.

That 'test/if true/if false' seems like a block that I would want to remove if I were using Blockly to edit Go.

Go is not an 'expression language', and has moved further away from that than C/C++. I'd be happy to have that block in SmallTalk, Scheme, even C, etc. where it has a plausible meaning (in reasonable, properly reviewed code).

However, IMHO, in Go that construct can lead to 'atypical' Go code. I'd characterise Go's philosophy as "do the 80% very well, then allow the other 20%, but it won't be automagic".

Either 'thing' would have to be declared (with its type) already outside the scope of the 'if true/if false' or their would be two different type 'thing' inside the 'if true/if false'. 

As you wrote, in the second case, 'thing' would have to be an interface.
However, it is generally better to avoid using an empty interface in Go, the most uses of an interface are not the empty interface, all the useful types have some common behaviour.

So I'd suggest waiting to see the Variable Type proposal mature (https://groups.google.com/forum/#!topic/blockly/jiRR_gi0-T8).
IMHO, the 'test/if true/if false' block is still a poor fit for Go, and hence not a good use case to test the Variable Type proposal.

I'll go further and say that I'd prefer control constructs that map easily onto Go.

For example, Go can return multiple values from a function.
However the shape of the existing 'functions' and 'variables' that I see at https://developers.google.com/blockly/ don't allow that.
Further, because Go treats errors as ordinary values, functions *often* return two or more values.
Multiple return values are assigned to multiple variables (often of different types) when the function returns.
It would be practically impossible to use much of the I/O library without handling multiple return values. Put another way, you couldn't write a robust program that could give any indication of what it did, like a relative of 'the halting problem'.

Just my $0.02

GB-)

[GB-)]

Matt, I agree with you.
Go seems to be a near perfect teaching language for Computer Science undergrads, and a good first textual language for anyone (I can agree that a visual block language is even easier to get started).

Go has types without the drudgery of other typed languages. (It can be quite hard to explain to a beginner why they have to say apparently the same thing several times.)
Go hasn't got a lot of syntax. In our experience, language syntax is a significant problem for beginners (hence also the value of visual 'block' languages).
Go has quick, simple-to-use, effective development tools. Fast turnaround on compilation is a must-have, or its interpreters only.
Go has an excellent, locally installable, documentation system. This is especially useful if you believe reading existing working code is 'a good thing' for learners
Go runs on most major platforms, has cross-compilation in-the-box, with simpler deployment than almost anything else near/in the mainstream. We can email one file, without any further 'packaging process' and it works. That reduces barriers for beginners to share and 'muck about'.

I'd like to try running some teaching experiments with Go later in the year, resources permitting.
I would very much like a tasteful, light, stylish Go block editor.

GB-)

[Dewey Gaedcke]

Has anyone made any progress creating a Go generator for Blockly?

I need this and would be happy to kick some resources to help get it done.