I absolutely agree with you! The next version of Flash Fill that we are aspiring to build will not only handle a much larger class of transformations, but will hopefully also show you the code, and suggest you corner cases for inspection and soliciting more examples from the user. Allowing the user to browse through multiple alternatives is also a good idea.
What I meant to say was that such a rich interactivity should not be the default experience for simple and common cases. For simple and common cases, the technology should just work automatically without requiring much user interaction, thereby promoting usability and discoverability. However, you are absolutely right that for more sophisticated cases, instead of letting the user fall off the cliff, we should invest in a rich interactive experience where the AI can partner with the user to help complete more sophisticated tasks.
Thank you for your feedback. I would love to get more insights into your use cases---we can use them as inspiration as we continue to improve the technology in this space. Please feel free to send us your use cases where Flash Fill fails at [email protected].
You may consider watching this 5-minute video segment starting at 4:30 to get a sense of the current scope of Flash Fill (i.e., when it is expected to work, and when it isn't): <https://www.youtube.com/watch?v=X1YXge3C8RI&t=270s>
You would have to give multiple examples, at least one for each "different kind" of name (for which you would have programmed a different handling logic if you were programming the task yourself---the tool needs to see at least an instance of each of those logics---it has no understanding that something is a name; it simply treats the input as a sequence of characters).
Our program synthesis APIs are available publicly, but for non-commercial use only. <https://github.com/microsoft/prose> You want to look for API samples corresponding to Transformation.Text capability. This is a more powerful capability than Flash Fill. If you happen to try this out, we'd be very interested in getting your feedback on whether this is powerful enough to handle your use cases, and if not, we would love to be inspired by your use cases for a future version of this technology. You may reach us at [email protected].
Yes, text to Columns would work well for splitting tasks in a very uniform dataset. However, if you want to extract say Lastname from a column containing names some of which may have middle names (i.e., the dataset is not very uniform), then text to columns would not work correctly.
Also, if you would like to do more than substring extraction, say convert "FirstName LastName" into "f.l." or "lastname, firstname", then Text2Columns won't be sufficient by itself. You would need to do more post-processing or would need a more sophisticated scripting capability.
What I meant to say was that such a rich interactivity should not be the default experience for simple and common cases. For simple and common cases, the technology should just work automatically without requiring much user interaction, thereby promoting usability and discoverability. However, you are absolutely right that for more sophisticated cases, instead of letting the user fall off the cliff, we should invest in a rich interactive experience where the AI can partner with the user to help complete more sophisticated tasks.