[Haskell & FP in Education] Welcome and introductions

[Chris Smith]

Hi Brent,

On Sun, Dec 16, 2018 at 10:26 PM Brent Yorgey <byorgey at gmail.com> wrote:

> 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%3Afunblocks+label%3Abug>.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/education/attachments/20181217/bd7a7f16/attachment.html>