Hi Brent,
On Sun, Dec 16, 2018 at 10:26 PM Brent Yorgey
I'm not aware of any *functional* block-based languages. If you know of any, please let me know!
I don't suggest you use this with your son, but if you're curious, a few years ago, Stefan Jacholke used Blockly to build a block-based front-end for CodeWorld, as part of Haskell.org's Summer of Haskell (in one of the years that haskell.org was not chosen for Google Summer of Code). It's still available at http://code.world/blocks. An interesting example is https://code.world/blocks#PIHIp7uCWam2t0iuN9w8zXA That said, though, it's not in great shape. There's quite a lot of code involved, including a significant amount of development on a custom fork https://github.com/stefan-j/blockly of yet another custom fork https://github.com/awmorp/blockly of Blockly. It's also a bit buggy https://github.com/google/codeworld/issues?q=is%3Aopen+is%3Aissue+label%3Afu.... This should be viewed as a proof of concept, from which we learned quite a bit about the task. Some of the lessons we learned: 1. Type inference in the client is a big deal. One should pay attention from the beginning to maintaining a correct incremental version of type inference, which should probably be based on something like Erdi's compositional variant of Hindley-Milner. Retrofitting the client-side implementation to CodeWorld Blocks led to a demoralizing game of whack-a-mole with consistency bugs, which was ultimately abandoned before we won. 2. Assuming a new version were again based on Blockly, it would be important to coordinate changes to Blockly with the upstream repository. While this is a challenging cross-team coordination problem made worse by the lack of engineering resources for the core Blockly project, forking Blockly is even more challenging in the long run. 3. The usability of Blockly's configuration panels is quite poor indeed; enough so that I found it nearly impossible to teach the portions of CodeWorld Blocks that needed them. This includes lists and user-defined functions. One would need to come up with a better approach to this, to have hope of success. Adding buttons and controls onto the block itself would be much more promising. 4. Blockly-based languages desperately need a more compelling compatibility story. Making a backward-incompatible change in a text-based language can require that programmers update their code, but doing the same in a Blockly-based language can cause the code to fail to load so much that the user may just as well start over and rewrite it entirely. 5. Blockly is also quite poor at usability. Being block-based is no panacea. It could likely be made much nicer with some intelligent search features. One could imagine clicking a connector to get a selection of blocks that would fit into that hole, or typing the first few letters of a function name to see a selection of blocks that begin with those letters. As is, though, building anything non-trivial in Blockly feels so tedious as to be off-putting. Anyway, this is just thoughts that came to mind from that question. Of course, there are deeper answers to how to design a visual functional language, too, based on dataflow diagrams and such. Since a key part of my goal in the CodeWorld project is to teach the conventional syntax of algebraic expressions and functions, I wasn't actually so interested in those more ambitious language designs. You might be, though. If so, I hope someone else can share some information there. Thanks, Chris