Ideas.....

[ghost]

The dev version works well. Its quite fun too to kind of visually code.

I have some ideas and i am kind of allowed to because i used to do a fair bit of Generative Design for Code and Architecture...
Also its great to see someone being brave enough to try this...

Brain dump .......

• grasshopper is the merge of coding and 3D Design and has a runtime display of the channels. The output of the channel can be done with a mini excel spreadsheet type of widget. Also Victor has a similar demo ( cant remember his last name but he is a Design UX god in the world of Parametric software). Its a good first step to see the values running through the channels.

• GRPC and gopherjs.
  I like that your using this. I have used it on a few projects too.

• Run your IDE in a Desktop app and distribute on the Windows, Apple stores.
  https://github.com/zserge/webview
  Easy to use and fast. Not like Electron.

• About Pins and Channels.
  I wonder if you want to consider abstracting it ? What i mean is that Protobufs and GRPC is a higher order abstraction than golang channels. This would make it much easier to plug anyones code into the "svgo pipeline" and it would be cross language. Also GRPC gives ou this abstraction too:
  a. calls acroos cross computer so you get scaling
  b. same computer but out of process . Basically IPC with grpc - saw a few github golang projects doing it that way
  c. same computer and same process. This is done using cmux.
  d. And browsers to computer . Of as as you seeing using GRPC and gopherjs you can also bring the browser into the pipeline too.
  So basically you also get Physical Topology independence.

Also GRPC and protobufs is common now and pretty accepted.

I would definitely keep the pure go channels approach you have now BTW !!! But i am just seeing how GRPC and protobuf will make this thing more reusable later thats all.

• go wagon and WASM
  You can also look into compiling to WASM. But why ?
  Mobiles and desktops go-interpreter/wagon#56
  Sure you get magic web browser speed. But the real interesting part is what you can run the WASM on a Mobile phone or something else that only accepts compiled code. And its not an awful hack like Otto etc. This is kind of huge. This is one of the reasons react native was popular - the mobile apps can download new code and run it without having to go through the app store.

i am pretty terrible at explaining my self so yell if i am not making sense and i will elaborate.

Anyway super cool stuff, and intrigued where this will go.

[DrJosh9000]

Thanks @gedw99, I'm glad that this little project of mine has some value. I'm no expert in this specific area so I'm all ears.

I just started playing with Grasshopper. I think I see what you mean. I hope to have implemented the ability to "watch" values travel through channels before July, but we'll see. You aren't referring to Bret Victor perhaps?

Thanks for the link to webview, I think something like this will be an absolute necessity.

gRPC is bread and butter inside Google so it was nice to finally be able to ditch the JSON-based glue I was manually coding up (there was probably a better way at the time, but I didn't really look).

I am looking forward to playing around with the upcoming WASM output in the Go compiler, but just haven't had much time (I'm actually on holiday in Europe right now). Glad to have the reminder!

Physical topology independence with gRPC etc - this is pretty appealing. Maybe it will be possible to combine both approaches in a single graph, say with the gRPC connections between "blocks" and channels inside blocks. In a similar vein I was also thinking of adding things like io.PipeReader/io.PipeWriter as "channels of a different colour".

[ghost]

Bret Victor - thanks it was there in the cobwebs somewhere. I am from oz. My Waverly , Victoria but have lived in Europe for almost 20 years now. Berlin these days. There is a grpc IPC library somewhere out there. Will find it when I get time ... Enjoy the hols !!!

…

On Fri, Apr 20, 2018, 9:16 PM Josh Deprez ***@***.***> wrote: Thanks @gedw99 <https://github.com/gedw99>, I'm glad that this little project of mine has some value. I'm no expert in this specific area so I'm all ears. I just started playing with Grasshopper. I think I see what you mean. I hope to have implemented the ability to "watch" values travel through channels before July, but we'll see. You aren't referring to Bret Victor perhaps? Thanks for the link to webview, I think something like this will be an absolute necessity. gRPC is bread and butter inside Google so it was nice to finally be able to ditch the JSON-based glue I was manually coding up (there was probably a better way at the time, but I didn't really look). I am looking forward to playing around with the upcoming WASM output in the Go compiler, but just haven't had much time (I'm actually on holiday in Europe right now). Glad to have the reminder! Physical topology independence with gRPC etc - this is pretty appealing. Maybe it will be possible to combine both approaches in a single graph, say with the gRPC connections between "blocks" and channels inside blocks. In a similar vein I was also thinking of adding things like io.PipeReader/io.PipeWriter as "channels of a different colour". — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#25 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ATuCwhxmy2RNmLF5VOK5tt04AN2jKCsgks5tqjP8gaJpZM4Tb4UW> .