BlocklyML visual programming tool for Machine learning and Python

https://github.com/chekoduadarsh/BlocklyML

by antman • 4 years ago

74 16 4 years ago

sdoering• 4 years ago

The environment (visual block "coding") reminded me of an environment for developing apps with kids.

I think it was developed (see edit) as a university project. Quite good for teaching the necessary concepts and enabling kids to build their first simple apps within an afternoon.

Edit: Based on Google Blockly [0]. The university project I was thinking of was MIT App Inventor [1].

[0] https://github.com/google/blockly

[1] https://appinventor.mit.edu/

vladsanchez• 4 years ago

https://scratch.mit.edu/

oneplane2• 4 years ago

It's strange to see "No code" being printed in bold as if that is the bestest feature everr!!!1!11oneone...

I get that simply having text to describe what you want a system to do can be intimidating at first, but once you look past the coloured blobs, you're really doing the same thing you'd be doing if you just called the instructions code. The process of thinking about a problem, mentally breaking it into its separate parts and turning it into a logic flow really isn't any different between writing the words yourself and dragging words encased in blobs around.

phil-martin2• 4 years ago

I’ve only taught a handful of people to build software, but what I’ve seen is there is a world of difference between writing words and dragging encased blobs around.

One person in particular has a real knack for breaking problems apart and understanding them. He could explain things really well that demonstrated understanding, but converting that understanding into the syntax the compiler would accept was an enormous barrier. He overcame it with time and practice and that was so exciting to see for them.

Could they have learned faster or differently with something like blockly? I don’t know. I’d like to think so.

You are right, you look past the coloured blobs you are doing the same thing, but for some people at least the syntax and keywords can be an enormous barrier. I suspect even more so for not-so-frequent developers

haswell• 4 years ago

but for some people at least the syntax and keywords can be an enormous barrier. I suspect even more so for not-so-frequent developers

This is the key thing.

I think it's hard for developers to remember what it was like to not have this skill that allows them to take a problem, translate that problem into code, and then use code to solve it.

I think devs (because most of us love to write code) also forget that the end goal isn't to write code, it's to solve the original problem. This bias makes it harder to see the value of a visual tool for the non-dev.

When you think about code as a solution to a problem as a non-dev, something like this emerges:

- I have a problem/question I want to solve/answer

- It can be solved using code

- I don't understand code (yet)

- Now I have two problems: 1) The original one (the one that matters) 2) I don't understand code

In order to make any progress on the thing that matters, I have to also make progress on literally learning a language.

A reasonable objection to this might be "but the user still has to learn the low code tool", and this is fair. But the #1 thing that low code tools bring IMO is:

Discoverability. In a visual tool, I can see and try things. Blockly makes this explicit by showing you where and how things can be connected using visual language almost everyone already understands (puzzle pieces). That same kind of experimentation is only possible in code once you understand the syntax, but first you must understand the syntax, and before you understand the syntax, fight through syntax errors, interface compatibility, etc. The chances of abandoning the effort altogether are pretty high.

Thinking about learning more generally, visual aids are almost always at the center of the teaching process. The very earliest thing almost every human learns: spoken language - also involves a learning period where the child might first point at a picture/object, later say the word, and even later, learn how to write that word.

Even after understanding a language fully, humans still point at pictures to communicate on a regular basis to optimize the communication process. Just look at your local fast food restaurant's menu.

Too often, no code tools are evaluated as if they must be "better" or "worse" than code. But these evaluations are asking the wrong questions and fundamentally miss the reason these tools exist to begin with.

shadowgovt• 4 years ago

I think there's a lot of meat on the bones of this style of programming that hasn't been unlocked yet, and most of the work remaining to do is in the user interface.

The huge advantage to this approach is that it makes it impossible to create syntactically invalid constructs in the language. A text based interface is hard to beat for simple speed of data entry... With lots of practice, people can type significant words per minute, and what you learn doing it in one language is completely transferable to every other text-based language. But when you consider the fact that the space of possible strings is so much larger than the space of syntactically valid programs, one does have to wonder how much time we burn on avoidable syntax errors. And nothing is stopping anyone from applying a keyboard to this programming approach... Somebody just has to sit down and figure out what that would look like.

What if the tools made it nearly impossible to write syntactically invalid code and were coupled with the discoverability to figure out what is valid in any given hole in the construct? Blocky isn't there yet, but it's an interesting foundation someone could build on.

QuadmasterXLII• 4 years ago

I wonder if something like TiBASIC is halfway there. All the keywords and function names are selected from menus instead of typed character by character so they cannot be misspelled. As a kid I found it way less frustrating than Python.

hoosieree• 4 years ago

Yeah, you could add keyboard shortcuts for some/all of the blocks, and some more keyboard shortcuts to navigate within/edit a block structure. Like Vim or Emacs keybindings for a block-based language.

jayd16• 4 years ago

Seeing as languages abstract machine code underneath, I'm not sure "it's really just the same" is a good argument.

That said, I also think visual programming is different at least in so far as one is able to layout code in two (or more) dimensions as opposed to the one dimensional layout of text lines.

It's often easier to see how data can flow through a complex transform in a shader graph than it might be to interpret text. In general flow can be visually displayed as graph edges whereas text requires the programmer to mentally track jumps through function names.

andybak2• 4 years ago

See my other comment above. I'm think Blockly is quite different to the more common node-based visual environments.

chekoduadarsh• 4 years ago

Hey! thank you for the feedback, I am the author of this project.

Yes I understand How implying No Code can manifest negatively. And programming with blocks can be quite restrictive. My belief is that this tool should be gateway to the world of programming.

To Achieve this, the user has to have a code view and manually run the code. With this they will understand what each block translates to in real world.

If you have any idea on improving it please raise and Issue in GitHub lets discuss further

andybak2• 4 years ago

I'm not sure I'd even call Blockly "No Code" - it is code and translates almost line by line to normal procedural code.

It gets murkier with node-based visual environments as you can express some things in ways that are very different to textual programming.

But Blockly is mainly just training wheels for code.

oneplane2• 4 years ago

While I do not have a fleshed-out idea ready, I think that some sort of method to (dynamically?) scale the difference between "encased blocks" and "code" would help everyone. Imagine having a program, or a set of instructions, and being able to drag a slider somewhere to make it 'more like blocks' and 'more like code'. It would be mostly a visual thing I suppose (considering the set of instructions and flow control can be described as an AST) but having a gradient instead of blocks vs. code would make transitioning as well as reasoning about it in conversation very easy.

robwwilliams• 4 years ago

In 1985 there was a great visual database system called File Vision—my fun introduction to database design. And it was highly intuitive to the user—almost like Pivot Viewer three decades later (https://www.microsoft.com/silverlight/pivotviewer/). And LabView also exploited block programming for complex lab workflows (https://www.ni.com/en-us/shop/labview.html).

The problem is not fundamental to this GUI approach but to the high overhead of “keeping up” with changes in underlying core core. The GUI adds a serious overhead and it rarely pays.

hrnn• 4 years ago

what's the consensus on Orange? I tried it one as it was offered to install from Anaconda and found it quite comfortable to test things out, but I rarely hear anyone else talking about it.

BlocklyML visual programming tool for Machine learning and Python

Related Stories