[HN Gopher] BlocklyML visual programming tool for Machine learni...
___________________________________________________________________
BlocklyML visual programming tool for Machine learning and Python
Author : antman
Score : 37 points
Date : 2022-03-27 17:52 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| sdoering wrote:
| 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/
| oneplane wrote:
| 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.
| shadowgovt wrote:
| 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.
| phil-martin wrote:
| 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 wrote:
| > _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.
___________________________________________________________________
(page generated 2022-03-27 23:00 UTC)