Are we sure that Git is really the best way to go?  Yes, it’s everywhere, but its representation in Iceberg seems awkward or incomplete.  I’ve been able to crash several Pharo VMs with routine repo operations.  This is why I backed away recently from Pharo--that and the mush (see below).

The other thing that keeps me planted firmly in VW is the sheer speed of it.  Pharo looks generally much better, but it’s mushy, and that’s a problem.  VW is not.  Gestural dynamics are very quick, well under 100 ms latency, often less than 20 ms.  I’m seeing 100, 150, and 200 ms regularly in Pharo.  It’s too mushy, and that slows the mind.   Any developer understands this, whether he talks about it or not.  So I’m wondering when the Pharo GUI will snap as well as VW.  One thing that would help is to give the option of button-down selection in Settings, but even this is not enough.  I tweaked the code, and made it so, but still was not happy:  not enough snap and crackle.   You may have acclimated and not noticed the problem, depending on how long you’ve been using Pharo.  

Otherwise, I like the Pharo DSL idea for JS.  I’m working with VW’s AppeX now.  I’m not sure I like it, but that’s mostly about finding JS to be one of the worst languages ever invented.  However, the reuse and leverage is there, but at what cost in poor reading/thinking?  I’m on the fence with AppeX, but will probably give it a chance.

How does PharoJS deal with the JS reuse issue?   There are lots of JS widgets out there that we would just like to use, but we don’t want to read JS if we don’t have to.  There are many wheels to reinvent, or at least recode in DSL, if I understand the PharoJS scheme correctly, but I may not.

Shaping